Rozwiązywanie problemów z rozproszonym akceleratorem dla magazynowania w chmurze (wersja zapoznawcza)

Użyj tego artykułu, aby zdiagnozować rozproszony akcelerator do przechowywania danych w chmurze (DACS), obsługiwany za pomocą rozszerzenia zarządzanego. Zacznij od objawu odpowiadającego twojemu problemowi:

Uruchom polecenia w powłoce Bash z kubectl skonfigurowanym dla klastra AKS. Ustaw nazwę pamięci podręcznej i przestrzeń nazw. Zarządzane rozszerzenie instaluje zarówno kontroler, jak i wymagany wstępnie zestaw DaemonSet dla NVMe w kube-system. Zasoby cache i pody cache-server korzystają z przestrzeni nazw cache.

CACHE_NAMESPACE=<cache-namespace>
CACHE_NAME=<cache-name>

Instalacja kończy się niepowodzeniem

Sprawdź stan provisioningu rozszerzenia, zainstalowaną wersję oraz szczegóły błędów:

az k8s-extension show \
  --cluster-type managedClusters \
  --cluster-name <cluster-name> \
  --resource-group <resource-group> \
  --name distributedaccelerator \
  --query '{extensionType:extensionType,currentVersion:currentVersion,releaseTrain:releaseTrain,state:provisioningState,statuses:statuses}'

Typ rozszerzenia powinien być microsoft.distributedaccelerator, a jego stan powinien być Succeeded. Użyj currentVersion do identyfikacji zainstalowanej wersji; nie wyciągaj jej na podstawie publicznego wykresu, obrazu czy pakietu klienta. Sprawdź, czy spełniasz wymagania wstępne Azure CLI. Nie instaluj drugiego kontrolera ani nie zmieniaj bazowego wydania Helm rozszerzenia, żeby obejść błąd instalacyjny.

Status podglądu produktu nie wymaga, aby zainstalowane rozszerzenie releaseTrain było preview. Sprawdź zwróconą wartość. Żądanie katalogu lokalizacji, które zwraca HTTP 404 lub InvalidResourceType samo w sobie nie potwierdza, że DACS jest niedostępny w tym regionie. Sprawdź status rozszerzenia specyficznego dla klastra oraz wskazówki dotyczące obsługi wersji zapoznawczej DACS.

Sprawdź gotowość kontrolera i zdarzenia:

kubectl rollout status deployment/dacs-manager --namespace kube-system --timeout=5m
kubectl get events --namespace kube-system --sort-by='.lastTimestamp' | tail -50

• Odmowa polisy: Sprawdź zgłoszoną polisę. Wymagania wstępne dotyczące NVMe wymagają uprzywilejowanego dostępu do wykrywania, formatowania i montowania lokalnych dysków NVMe. Niech Twój zespół ds. bezpieczeństwa przejrzy wszelkie wymagane wyjątki od polityki.
• Operacja AKS już trwa: Jeśli OperationNotAllowed zgłasza kolejną operację AKS, poczekaj, aż ta operacja się zakończy, zanim spróbujesz ponownie. Nie rozpoczynaj nakładających się aktualizacji ani nie przerywaj automatycznie operacji zarządzanej przez AKS.
• Niepowodzenie alokacji VM: Błąd AllocationFailed podczas uzgadniania AKS może odzwierciedlać pojemność węzła lub węzła surge, a nie problem z obrazem DACS. Sprawdź stan aprowizacji puli węzłów oraz regionalną dostępność maszyn wirtualnych. Przeanalizuj zakłócenia obciążeń roboczych przed zmianą ustawień aktualizacji puli węzłów.
• Restart kontrolera: Sprawdź logi kontrolera i zdarzenia niepowodzenia sondy. Restart startu następujący stabilną gotowością różni się od powtarzających się restartów lub nieosiągnięcia statusu Gotowości. Nie wyłączaj webhooków dopuszczających jako obejścia.
• Awaria po aktualizacji: Sprawdź wymagania kompatybilności docelowej wersji i zbierz diagnostykę przed wprowadzeniem dalszych zmian. Nie usuwaj elementu Cache CRD jako kroku naprawczego: usunięcie go usuwa wszystkie zasoby Cache. Zobacz Przygotowanie do uaktualnień.

Pamięć podręczna nie jest gotowa

Zainstalowanie kontrolera nie tworzy serwerów cache. Jeśli nie istnieje zasób pamięci podręcznej, postępuj zgodnie z Aprowizuj pamięć podręczną.

Dla istniejącej pamięci podręcznej sprawdź jej warunki, liczbę serwerów, pody i zdarzenia:

kubectl get cache "$CACHE_NAME" --namespace "$CACHE_NAMESPACE" -o yaml
kubectl get pods --namespace "$CACHE_NAMESPACE" --selector app=cacheserver -o wide
kubectl get events --namespace "$CACHE_NAMESPACE" --sort-by='.lastTimestamp' | tail -50

Zdrowa pamięć podręczna ma Ready=True, zapełniony adres URL do wykrywania oraz zgodne bieżące i docelowe liczby serwerów. Jego pody serwera powinny być gotowe, a nie tylko uruchomione. Lista podów obejmuje wszystkie serwery cache w przestrzeni nazw. Użyj referencji właścicieli, aby zidentyfikować pody pamięci podręcznej, jeśli wiele cache'ów dzieli przestrzeń nazw.

Dla błędu na poziomie podu:

kubectl describe pod <cache-server-pod> --namespace "$CACHE_NAMESPACE"
kubectl get nodes --show-labels

Jeśli wystąpią błędy montażu lub nieoczekiwane zużycie dysku, sprawdź system plików pamięci podręcznej:

kubectl exec --namespace "$CACHE_NAMESPACE" <cache-server-pod> -- \
  df -h <cache-data-path>

Ścieżka musi znajdować się na lokalnym dysku NVMe, a nie na dysku systemu operacyjnego. Potwierdź, że punkt montażu sprawdzony podczas weryfikacji przygotowania NVMe jest zgodny z spec.storage.hostPath.nodeCacheFolderPath. Sprawdź zarządzony element wymagany DaemonSet i zidentyfikuj pod na dotkniętym węźle:

kubectl get daemonset dacs-prereq --namespace kube-system
kubectl rollout status daemonset/dacs-prereq --namespace kube-system --timeout=10m
kubectl get pods --namespace kube-system \
  --selector app.kubernetes.io/name=dacs-prereq --output wide
kubectl logs <prerequisite-pod> --namespace kube-system \
  --container nvme-raid-setup --tail=200

Logi konfiguracji dysku pochodzą z kontenera init nvme-raid-setup, a nie z domyślnego kontenera podu. Nie instaluj zduplikowanego chartu wymagań wstępnych, jeśli zarządzany DaemonSet nie jest gotowy. W przypadku wcześniej wdrożonych składników wstępnych wdrożonych inną metodą używaj ich rzeczywistej przestrzeni nazw i nazw kontenerów. Zobacz Sprawdź konfigurację magazynu pamięci podręcznej.

Obciążenie robocze nie może odczytać danych Blob

Użyj błędu odczytu obciążenia roboczego, aby rozróżnić problemy z uwierzytelnianiem, ścieżką i łącznością:

Informacje o konfiguracji tożsamości znajdują się w sekcji Przyznanie dostępu do odczytu danych modelu.

Jeśli aktualizacja modelu zwraca nieoczekiwane dane, należy użyć odrębnej, niezmiennej ścieżki Blob dla każdej wersji, zamiast nadpisywać ścieżkę zmienną latest . Zobacz Prefetch danych modelu przed wdrożeniem, aby zapoznać się z opisem procesu wdrażania wersji modelu.

Jeśli aplikacja ulegnie awarii przed wykonaniem operacji odczytu, ponieważ pakiet Python lub natywna biblioteka nie może zostać zaimportowana, sprawdź instalację pakietu i wymagania uruchomieniowe w Użyj rozproszonego akceleratora do przechowywania w chmurze z klientem Python.

Odczyty kończą się powodzeniem, ale nie korzystają z pamięci podręcznej

Klient może użyć Azure Blob Storage jako rozwiązania awaryjnego. Udane odczyty lub szybsze drugie odczyty same w sobie nie są dowodem na buforowanie.

W działającym podzie obciążenia sprawdź, czy obie wartości połączenia z pamięcią podręczną są ustawione:

kubectl exec --namespace <workload-namespace> <workload-pod> -- \
  printenv CACHE_DISCOVERY_URL CACHE_SERVER_PORT

Porównaj je z wybranym zasobem Cache:

kubectl get cache "$CACHE_NAME" --namespace "$CACHE_NAMESPACE" \
  -o jsonpath='{.status.discoveryURL}{"\n"}{.spec.port}{"\n"}'

Jeśli którejkolwiek z tych zmiennych brakuje, klient rejestruje Cache not configured. Working in Remote Blob mode only. Popraw konfigurację obciążenia i wdroż ją ponownie. Jeśli oba są poprawne, sprawdź rozwiązywanie nazw DNS i łączność z endpointem pamięci podręcznej z poziomu obciążenia.

Populacja pamięci podręcznej jest asynchroniczna: odczyt może zakończyć się zanim dane zostaną dostępne z pamięci podręcznej, więc dwa natychmiastowe odczyty mogą oba chybić. Powtarzaj ten sam zakres z opóźnieniem między odczytami, jak w przypadku pięciu odczytów w szybkim startie odstępowanych co sekundę. Ta sekwencja nie gwarantuje liczby ludności. Potwierdź liczbę trafień do pamięci podręcznej klienta oraz zwiększenie jej cache_server_request_counter{request_type="Download",status="Success"} we wszystkich modułach serwera dla wybranego zasobu pamięci podręcznej. Wartości etykiet rozróżniają wielkość liter. Procedurę i metryki można znaleźć w artykule Verify the Request path (Weryfikacja ścieżki żądania DACS).

Ładowanie modelu jest wolniejsze niż oczekiwano

Najpierw potwierdzić, że odczyty korzystają z pamięci podręcznej opisanej w poprzedniej sekcji. Następnie porównaj odczyty na zimno i powtórzone odczyty na ciepło, aby określić etap ograniczający:

Aby dostrajać klienta, zobacz Optymalizacja wydajności odczytu. Korzystaj z wskazówek monitoringu, aby korelować aktywność pamięci podręcznej z ruchem Blob.

Jeśli opcjonalne przygotowanie wstępne się nie powiedzie, użyj powyższych testów dostępu do Blob i gotowości pamięci podręcznej, popraw dotknięte ścieżki i ponów te odczyty. Weryfikuj trafienia pamięci podręcznej przed planowanym wdrożeniem rozgrzanej pamięci podręcznej; prefetch nie przypina danych ani nie gwarantuje pozostawania danych w pamięci podręcznej.

Zbieranie danych diagnostycznych

Jeśli te kontrole nie rozwiążą problemu, zbierz następujące dane wyjściowe i status rozszerzenia z sekcji instalacji przed otwarciem zgłoszenia do pomocy technicznej platformy Azure:

kubectl version
kubectl get nodes -o wide
kubectl get cache "$CACHE_NAME" --namespace "$CACHE_NAMESPACE" -o yaml
kubectl get pods --namespace "$CACHE_NAMESPACE" -o wide
kubectl get events --namespace "$CACHE_NAMESPACE" --sort-by='.lastTimestamp'
kubectl logs deployment/dacs-manager --namespace kube-system --tail=200
kubectl logs <cache-server-pod> --namespace "$CACHE_NAMESPACE" --tail=200

Przy restartach kontenerów zbieraj także wcześniejsze logi dla kubectl logs --previous dotkniętego kapsułu. W przypadku błędów konfiguracji dysku dołącz wcześniej pokazane dzienniki kontenera init nvme-raid-setup. W przypadku niepowodzeń odczytu aplikacji uwzględnij logi obciążenia roboczego. Aby zebrać metryki, zobacz Monitorowanie rozproszonego akceleratora dla magazynu w chmurze.

Uwzględnij zakres czasowy, operację, której dotyczy problem, wersję AKS, rozmiary maszyn wirtualnych, wersję rozszerzenia DACS, wersje klienta oraz wszelkie ostatnie zmiany konfiguracyjne. Usuń tokeny, wartości SAS, wrażliwe ścieżki Blob oraz inne poufne informacje z logów i danych wyjściowych zasobów przed ich udostępnieniem.

Następne kroki

• Zarządzanie rozproszonym akceleratorem dla pamięci masowej w chmurze.
• Monitor rozproszonego akceleratora dla pamięci masowej w chmurze.
• Opcje pomocy technicznej platformy Azure