Azure Storage 2026: AI, skalowanie i wydajność
Podsumowanie
Microsoft zapowiada, że roadmapa Azure Storage na 2026 rok będzie mocno skupiona na obsłudze obciążeń AI — od treningu i tuningu po inference — z naciskiem na większą skalę, przepustowość i prostszą eksploatację. Kluczowe nowości, takie jak Blob scaled accounts oraz Azure Managed Lustre z obsługą namespace’ów do 25 PiB i przepustowością do 512 GB/s, mają znaczenie, bo pomagają firmom efektywnie zasilać klastry GPU, obsługiwać miliony obiektów i lepiej przygotować infrastrukturę pod wymagające, zawsze aktywne systemy AI oraz aplikacje krytyczne biznesowo.
Wprowadzenie: dlaczego to ma znaczenie
AI przechodzi od okazjonalnych eksperymentów do zawsze-włączonej produkcji — zwłaszcza inference oraz autonomicznych obciążeń „agentic”, które generują trwałe wzorce dostępu o wysokiej współbieżności. Roadmapa Azure Storage na 2026 rok koncentruje się na umożliwieniu end-to-end przepływów danych dla AI (training → tuning → inference), a także na poprawie kosztów, prostoty operacyjnej i wydajności dla tradycyjnych systemów krytycznych, takich jak SAP, oraz platform tradingowych o ultra-niskich opóźnieniach.
Co nowego (i na co Microsoft kładzie nacisk)
1) Training w skali frontier: Blob i ścieżki danych o wysokiej przepustowości
- Blob scaled accounts są podkreślane jako sposób skalowania w ramach setek scale units na region, celując w obciążenia z milionami obiektów (typowe dla datasetów training/tuning oraz zarządzania checkpointami/plikami modeli).
- Microsoft wskazuje, że innowacje wykorzystywane do obsługi operacji w skali OpenAI stają się szerzej dostępne dla przedsiębiorstw.
2) Storage zaprojektowany pod AI compute: Azure Managed Lustre (AMLFS)
- Partnerstwo Azure z NVIDIA DGX on Azure łączy akcelerowane compute z Azure Managed Lustre, aby utrzymać odpowiednie zasilanie danych dla flot GPU.
- AMLFS obejmuje teraz wsparcie w wersji preview dla namespaces 25 PiB oraz do 512 GBps throughput, pozycjonując go jako czołową, zarządzaną opcję Lustre dla dużych scenariuszy badawczych i przemysłowych inference (np. automotive, robotics).
3) Integracje ekosystemu AI: szybsza droga od danych do inference
- Planowana jest głębsza integracja w ramach frameworków AI, w tym Microsoft Foundry, Ray/Anyscale oraz LangChain.
- Natywna integracja Azure Blob w Foundry ma wspierać konsolidację danych firmowych w Foundry IQ na potrzeby grounding wiedzy, fine-tuningu oraz niskolatencyjnego serwowania kontekstu — przy zachowaniu governance i security w ramach tenant.
4) Cloud-native aplikacje agentic w skali: block storage + orkiestracja Kubernetes
- Microsoft zwraca uwagę, że agenci mogą generować rzędy wielkości więcej zapytań niż aplikacje sterowane przez ludzi, obciążając warstwy storage/database.
- Elastic SAN jest opisywany jako kluczowy element architektur typu SaaS, multi-tenant, z zarządzanymi pulami block storage i guardrails.
- Kierunek rozwoju Azure Container Storage (ACStor) przesuwa się w stronę modelu operatora Kubernetes oraz intencji open source bazy kodu, wraz ze sterownikami CSI, aby uprościć rozwój aplikacji stanowych na Kubernetes.
5) Krytyczne cena/wydajność: SAP, ANF, Ultra Disk
- Dla SAP HANA aktualizacje serii M w Azure celują w ok. 780k IOPS oraz 16 GB/s throughput dla wydajności dysków.
- Azure NetApp Files (ANF) oraz Azure Premium Files pozostają kluczowymi opcjami shared storage, z usprawnieniami TCO takimi jak ANF Flexible Service Level oraz Azure Files Provisioned v2.
- Nadchodzi: Elastic ZRS service level w ANF dla zone-redundant HA z synchroniczną replikacją pomiędzy AZs.
- Podkreślana jest wydajność Ultra Disk (opóźnienia poniżej 500µs; do 400K IOPS/10 GB/s, oraz do 800K IOPS/14 GB/s z VM Ebsv6).
Wpływ na administratorów IT i zespoły platformowe
- Należy oczekiwać większego nacisku architektonicznego na throughput, współbieżność i lokalność danych dla aplikacji intensywnie korzystających z inference oraz agentic.
- Operatory Kubernetes oraz potencjalny open-source ACStor mogą zmienić sposób, w jaki zespoły standaryzują obciążenia stanowe na AKS.
- Dobór storage staje się bardziej zależny od obciążenia: Blob dla datasetów/kontekstu, Lustre dla pipeline’ów GPU, Elastic SAN/Ultra Disk dla transakcyjnych wymagań wysokiego IOPS, ANF dla współdzielonych obciążeń enterprise.
Działania / kolejne kroki
- Zmapuj obciążenia AI według fazy (training vs inference vs agentic) i dopasuj do typów storage (Blob + AMLFS + block/shared).
- Zweryfikuj limity preview AMLFS (25 PiB/512 GBps) i potwierdź bottlenecki w pipeline’ach GPU, gdzie Lustre może pomóc.
- Oceń Elastic SAN dla multi-tenant SaaS lub mikroserwisów o wysokiej współbieżności, które potrzebują pulowanego block storage.
- Zaplanuj ANF Elastic ZRS, jeśli potrzebujesz zone-redundant NFS o spójnej wydajności dla aplikacji enterprise.
- Dla zespołów AKS: śledź aktualizacje ACStor operator + open-source, aby ograniczyć niestandardowe zarządzanie storage dla aplikacji stanowych.
Potrzebujesz pomocy z Azure?
Nasi eksperci pomogą Ci wdrożyć i zoptymalizować rozwiązania Microsoft.
Porozmawiaj z ekspertemBądź na bieżąco z technologiami Microsoft