Czym jest rozproszony akcelerator pamięci masowej w chmurze? (wersja zapoznawcza)

Distributed accelerator for cloud storage (DACS) to rozproszona pamięć podręczna typu read-through, która przyspiesza ładowanie modeli z Azure Blob Storage na potrzeby wnioskowania AI w usłudze Azure Kubernetes Service (AKS). Wykorzystuje lokalne dyski NVMe w węzłach cache, aby utrzymywać często odczytywane dane blisko zasobów obliczeniowych GPU. DAC-y mogą również przyspieszać ładowanie zbiorów danych dla obciążeń treningowych, które wielokrotnie odczytują te same dane. Azure Blob Storage pozostaje trwałym i autorytatywnym źródłem plików modeli i zestawów danych.

Włączasz i zarządzasz DACS za pomocą usługi Azure Container Storage, która instaluje zarządzane rozszerzenie DACS i obsługuje jego cykl życia na AKS. DACS nie jest woluminem trwałym, klasą StorageClass ani zamiennikiem Azure Blob Storage. Aby utworzyć trwałe woluminy Kubernetes, zobacz: Co to jest Azure Container Storage?

Kiedy używać akceleratora rozproszonego dla pamięci masowej w chmurze

DACS został zaprojektowany do obciążeń AI wymagających intensywnego odczytu, które wielokrotnie ładują te same dane modelu z Azure Blob Storage. Rozważ DACS, gdy Twoje obciążenie ma jedną lub więcej z następujących cech:

• Pody inferencyjne czekają na duże pliki modelu, zanim będą mogły obsłużyć żądania.
• Dodanie węzłów GPU powoduje powtarzające się pobieranie danych modelu.
• Restarty poda, wymiana węzłów lub kolejne aktualizacje wielokrotnie pobierają te same dane modelu.
• Wiele obciążeń inferencyjnych wykorzystuje roboczy zestaw plików modeli przechowywanych w Azure Blob Storage.
• Klaster AKS ma pulę węzłów systemu Linux z lokalnymi dyskami NVMe, którą można przeznaczyć dla serwerów pamięci podręcznej.

W przypadku szkoleń rozważ DACS, gdy pracownicy ponownie wykorzystują fragmenty zbiorów danych w różnych epokach lub w różnych zadaniach. Korzyści z pamięci podręcznej zależą od ponownego wykorzystania danych, wielkości zestawu roboczego oraz tego, czy odczyty napotykają zimną czy ciepłą pamięć podręczną.

DACS obsługuje klastry z maksymalnie 100 węzłami. Nie zapewnia trwałego przechowywania danych dla wyjść treningowych ani punktów kontrolnych. pamięć podręczna KV, pamięć podręczna obrazów kontenerów, dostęp do plików współdzielonych ogólnego przeznaczenia oraz źródła inne niż Azure Blob nie są częścią tej wersji zapoznawczej.

Jak działa rozproszony akcelerator pamięci masowej w chmurze

DACS dodaje warstwę pamięci podręcznej NVMe lokalnej w klastrze, która obciąża dostęp poprzez wspieraną integrację klienta. Klient może odczytać Azure Blob Storage bezpośrednio przy nietrafieniach pamięci podręcznej lub podczas korzystania z mechanizmu awaryjnego.

Ścieżka odczytu

1. Aplikacja żąda zakresu model-danych poprzez obsługiwaną integrację DACS.
2. Klient odkrywa serwery cache i określa, który serwer jest właścicielem żądanego chunku.
3. Po trafieniu do cache klient odczytuje fragment z NVMe serwera cache, do którego należy fragment.
4. W przypadku braku trafienia w pamięci podręcznej klient odczytuje fragment z Azure Blob Storage i wypełnia pamięć podręczną asynchronicznie. Odczyt może zakończyć się, zanim populacja się zakończy, więc natychmiast powtórzony odczyt również może nic nie wykazać.
5. Jeśli pamięć podręczna jest niedostępna, klient wraca do Azure Blob Storage.

Dane modelu są podzielone na fragmenty i rozproszone na serwerach cache. Pierścień haszowania spójnego mapuje bloki na serwery bez zależności od scentralizowanej ścieżki przetwarzania danych. Serwery pamięci podręcznej mogą przesyłać dane przez Ethernet lub InfiniBand, w zależności od wybranego rozmiaru maszyny wirtualnej (VM) Azure i topologii klastra.

Wdrożenie zarządzane

Włącz DACS za pośrednictwem Azure Container Storage, używając Azure CLI z wartością distributedAccelerator. Ten krok instaluje osobne distributedaccelerator zarządzane rozszerzenie. Rozszerzenie wdraża kontroler DACS oraz wymagany DaemonSet NVMe w kube-system oraz rejestruje niestandardową definicję zasobu Cache. Wymagania wstępne wykrywają, formatują i montują lokalne dyski NVMe na oznaczonych węzłach pamięci podręcznej. Używaj dysków dedykowanych pamięci podręcznej; nie instaluj oddzielnego chartu wymagań wstępnych. Rozszerzenie nie tworzy automatycznie podów cache-server.

Po weryfikacji, że wymagania wstępne dla zarządzanego NVMe są gotowe dla każdego oznaczonego węzła cache, stwórz zasób cache, aby zdefiniować liczbę serwerów, pojemność, limity zasobów oraz kwalifikujące się węzły. Kontroler uzgadnia pody cache-server i publikuje informacje odnajdywania dla klientów. Kontroler zarządza zasobami; nie jest pośrednikiem dla odczytów danych aplikacji. Zobacz przewodnik szybkiego startu dotyczący instalacji i provisioningu pamięci podręcznej.

Główne korzyści

• Szybsze ładowanie rozgrzanego modelu: Udostępniaj często odczytywane fragmenty modelu z lokalnego lub równorzędnego dysku NVMe zamiast wielokrotnego pobierania ich z usługi Azure Blob Storage.
• Szybsze skalowanie i odzyskiwanie: Pozwól nowym lub zastępczym węzłom ponownie wykorzystać dane modelu już zbuforowane w klastrze.
• Zmniejszone powtarzające się odczyty obiektu blob: Utrzymuj aktywny zestaw roboczy modelu w pamięci podręcznej i używaj prefetchu przed planowanymi zdarzeniami skalowania.
• Bufor oparty na zakresach: Buforuj tylko te fragmenty obejmujące żądane zakresy bajtów, zamiast materializować każdy plik modelu w całości.
• Elastyczna integracja aplikacji: Użyj BlobFuse2, natywnego klienta Python, lub Run:ai Model Streamer, aby połączyć obciążenie robocze z pamięcią podręczną.
• Bezpieczny plan awaryjny: Zachowaj Azure Blob Storage jako trwałe źródło prawdy, gdy dane nie są buforowane lub pamięć podręczna jest niedostępna.

Integracje klienckie

Zakres zmian aplikacji zależy od integracji:

Aby uzyskać wyniki konfiguracji systemu plików i pomiarów dla magazynu Standard, zobacz Używanie rozproszonego akceleratora na potrzeby magazynu w chmurze za pomocą BlobFuse2. Aby poznać konfigurację klienta Python i przykłady, zobacz Korzystanie z rozproszonego akceleratora dla magazynu w chmurze za pomocą klienta Python.

Bezpośredni dostęp do źródła z Hugging Face nie jest obsługiwany. Umieść dane modelu w Azure Blob Storage przed użyciem rozproszonego akceleratora do przechowywania w chmurze.

Semantyka pamięci podręcznej

Zapoznaj się z tymi zachowaniami przed wdrożeniem rozproszonego przyspieszacza dla magazynu w chmurze:

• Trwałość: Dane w pamięci podręcznej są ulotne i nie są replikowane dla trwałości. Utrata węzła cache może usunąć chunki przechowywane na tym węźle; brakujące dane są ponownie pobierane z Azure Blob Storage.
• Źródło referencyjne: Azure Blob Storage pozostaje źródłem referencyjnym. Nie używaj DACS jako jedynej kopii plików modeli czy zestawów danych. Preferuj niezmienne, wersjonowane ścieżki obiektów Blob do ulepszania modelu.
• Usuwanie: Pamięć podręczna usuwa dane, gdy osiągnięte zostaną progi pojemności. Usunięte dane są ponownie pobierane na żądanie.
• Tryb awaryjny: Brak konfiguracji wykrywania lub niedostępna pamięć podręczna mogą spowodować, że klient będzie czytał bezpośrednio z usługi Azure Blob Storage. Weryfikuj trafienia do pamięci podręcznej klienta i wzrost licznika żądań serwera, zamiast traktować udany odczyt Blob jako dowód buforowania. Zobacz Zweryfikuj ścieżkę żądania DACS.
• Tożsamość: Obciążenia wykorzystują tożsamości Microsoft Entra lub podpis współdzielonego dostępu (SAS), aby uzyskać dostęp do Azure Blob Storage. Użyj roli o najmniejszych uprawnieniach wymaganych przez obciążenie robocze.
• Sieciowanie: Ruch pamięci podręcznej pozostaje w sieci AKS. Dostęp do punktu końcowego Azure Blob musi być dozwolony w przypadku chybień pamięci podręcznej i mechanizmu awaryjnego.
• Granica zaufania: Używaj DACS w zaufanym klastrze. Pamięć podręczna nie izoluje wzajemnie nieufnych tenantów.

Projekt open source

DACS to projekt open-source opracowany we współpracy między Azure AI Platform a Azure Storage. Projekt udostępnia implementację pamięci podręcznej do inspekcji, eksperymentów i wkładu społeczności, aby ograniczyć powtarzające się odczyty danych bez zastępowania trwałej pamięci masowej.

Repozytorium Azure DACS zawiera serwer pamięci podręcznej, natywnego klienta C/C++, adaptery języka Python, wrapper w języku Rust, wykresy i kontroler Kubernetes oraz przykłady wdrożeń. Zapoznaj się z plikiem README repozytorium w celu uzyskania wskazówek dotyczących zgodności z oprogramowaniem open source i konfiguracji oraz korzystaj z wytycznych dotyczących wkładu, aby dzielić się problemami możliwymi do odtworzenia, pomiarami obciążenia i ulepszeniami.

Projekt open-source oraz podgląd zarządzany przez Azure mają różne zakresy wdrożenia i wsparcia. Aby skorzystać z zarządzanego środowiska AKS, korzystaj z szybkiego startu Azure; opcje wdrożenia repozytorium nie są automatycznie obsługiwane w zarządzanej wersji.

Obsługa podglądu i ograniczenia

Poniższa tabela podsumowuje zakres wstępnej wersji podglądowej.

Kiedy użyć innej opcji przechowywania

Użyj innej opcji przechowywania Azure, gdy Twoje obciążenie wymaga możliwości wykraczających poza zakres DACS:

• Aby uzyskać trwałe woluminy Kubernetes na lokalnym NVMe, zobacz Użyj Azure Container Storage z lokalnym NVMe.
• Aby uzyskać trwałe woluminy blokowe, zobacz Używanie usługi Azure Container Storage z usługą Elastic SAN.
• O zarządzanym systemie plików równoległym zobacz: Co to jest Azure Managed Lustre?.
• Aby uzyskać bezpośredni dostęp do obiektów bez rozproszonej pamięci podręcznej, użyj biblioteki klienta Azure Blob Storage.

Następne kroki

• Rozpocznij pracę z usługą Distributed Accelerator for cloud storage na platformie AKS.
• Użyj akceleratora rozproszonego dla magazynu w chmurze z BlobFuse2.
• Użyj rozproszonego akceleratora do przechowywania w chmurze z klientem języka Python.
• Zarządzanie rozproszonym akceleratorem dla pamięci masowej w chmurze.
• Monitor rozproszonego akceleratora dla pamięci masowej w chmurze.
• Rozwiązywanie problemów z rozproszonym akceleratorem do przechowywania w chmurze.