Błędy puli i węzła usługi Azure Batch

Niektóre operacje tworzenia i zarządzania pulami w usłudze Azure Batch są wykonywane natychmiast. Wykrywanie błędów dla tych operacji jest proste, ponieważ błędy zwykle zwracają się natychmiast z interfejsu API, wiersza polecenia lub interfejsu użytkownika. Jednak niektóre operacje są asynchroniczne, uruchamiane w tle i trwają kilka minut. W tym artykule opisano sposoby wykrywania i unikania błędów, które mogą wystąpić w operacjach w tle dla pul i węzłów.

Upewnij się, że aplikacje mają zaimplementować kompleksowe sprawdzanie błędów, szczególnie w przypadku operacji asynchronicznych. Kompleksowe sprawdzanie błędów może pomóc w szybkiej identyfikacji i diagnozowaniu problemów.

Błędy puli

Błędy puli mogą być związane z przekroczeniem limitu czasu lub niepowodzeniem zmiany rozmiaru, niepowodzeniem automatycznego skalowania lub niepowodzeniem usunięcia puli. Dzięki włączeniu bardziej szczegółowych komunikatów o błędach diagnozowanie i rozwiązywanie tych problemów stało się prostsze.

Szczegóły błędu dostawcy przekaźnika

Błędy dostawcy przekaźnika są przekazywane bezpośrednio z bazowych dostawców zasobów platformy Azure, takich jak zestaw skalowania maszyn wirtualnych platformy Azure (VMSS), a także oferują dokładniejsze informacje na temat przyczyn niepowodzenia operacji puli. Te błędy zwykle występują, gdy na tworzenie, zmianę rozmiaru lub usuwanie puli wpływa problem z usługą niższej warstwy.

Struktura błędu dostawcy przekaźnika

Te błędy są udostępniane w formacie JSON ze strukturą zawierającą następujące kluczowe składniki:

• Kod błędu: napotkany typ błędu (np. AllocationFailed, BadRequest itp.).
• Komunikat o błędzie: krótki opis błędu
• Kod Json błędu dostawcy: szczegółowy komunikat o błędzie wygenerowany przez podstawową usługę platformy Azure (np. VMSS).
• Błąd dostawcy obcięty: wartość logiczna wskazująca, czy komunikat o błędzie dostawcy został obcięty z powodu limitów rozmiaru.

Przykładowe błędy dostawcy przekaźnika

Przykład 1

Kod błędu:AllocationFailed
Komunikat o błędzie: Nie można przydzielić żądanej liczby dedykowanych węzłów
Błąd dostawcy JSON:

{
  "error": {
    "code": "BadRequest",
    "message": "The selected VM size 'STANDARD_A1_V2' cannot boot Hypervisor Generation '2'. If this was a Create operation, please ensure that the Hypervisor Generation of the Image matches the Hypervisor Generation of the selected VM Size. If this was an Update operation, please choose a Hypervisor Generation '2' VM Size."
  }
}

Błąd dostawcy: JSON przycięty: False

Ten błąd wskazuje niezgodność między rozmiarem maszyny wirtualnej a generowaniem funkcji Hypervisor. Komunikat o błędzie sugeruje wybranie zgodnego rozmiaru maszyny wirtualnej w celu rozwiązania problemu.

Przykład 2

Kod błędu:AllocationFailed
Komunikat o błędzie: Wystąpił błąd wewnętrzny podczas zmiany rozmiaru zasobnika
Błąd dostawcy JSON:

{
  "error": {
    "code": "ScopeLocked",
    "message": "The scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D' cannot perform write operation because the following scope(s) are locked: '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D'. Please remove the lock and try again."
  }
}

JSON obcięty z powodu błędu dostawcy: False

Ten błąd wskazuje, że operacja zmiany rozmiaru puli nie powiodła się, ponieważ zakres został zablokowany, uniemożliwiając operację zapisu; usunięcie blokady może rozwiązać problem.

Błędy dostawcy przekaźnika oferują bardziej szczegółowy wgląd w błędy operacji puli, co ułatwia diagnozowanie i rozwiązywanie problemów bezpośrednio z usług platformy Azure.

Zmiana rozmiaru - przekroczenie limitu czasu albo niepowodzenie

Podczas tworzenia nowej puli lub zmieniania rozmiaru istniejącej puli należy określić docelową liczbę węzłów. Operacja tworzenia lub zmiany rozmiaru jest wykonywana natychmiast, ale rzeczywista alokacja nowych węzłów lub usunięcie istniejących węzłów może potrwać kilka minut. Limit czasu zmiany rozmiaru można określić w interfejsach API tworzenia puli lub zmieniania rozmiaru puli . Jeśli usługa Batch nie może przydzielić docelowej liczby węzłów w okresie przekroczenia limitu czasu zmiany rozmiaru, pula przechodzi w stały stan i zgłasza błędy zmiany rozmiaru.

Typowe przyczyny błędów zmiany rozmiaru to:

• Zmień rozmiar limitu czasu za krótki. Zazwyczaj domyślny limit czasu 15 minut jest wystarczająco długi, aby przydzielić lub usunąć węzły puli. Jeśli przydzielasz dużą liczbę węzłów, takich jak ponad 1000 węzłów z obrazu witryny Azure Marketplace lub więcej niż 300 węzłów z niestandardowego obrazu maszyny wirtualnej, możesz ustawić limit czasu zmiany rozmiaru na 30 minut.

• Niewystarczający limit przydziału rdzeni. Konto usługi Batch jest ograniczone co do liczby rdzeni, które może przydzielić we wszystkich pulach, i zatrzymuje przydzielanie węzłów po osiągnięciu tego limitu. Możesz zwiększyć limit przydziału rdzeni, aby usługa Batch mogła przydzielić więcej węzłów. Aby uzyskać więcej informacji, zobacz Limity i ograniczenia usługi Batch.

• Niewystarczająca liczba adresów IP podsieci, gdy pula znajduje się w sieci wirtualnej. Podsieć sieci wirtualnej musi mieć wystarczającą liczbę adresów IP do przydzielenia do każdego żądanego węzła puli. W przeciwnym razie nie można utworzyć węzłów. Aby uzyskać więcej informacji, zobacz Tworzenie puli usługi Azure Batch w sieci wirtualnej.

• Niedostateczne zasoby, gdy pula znajduje się w sieci wirtualnej. Podczas tworzenia puli w sieci wirtualnej możesz utworzyć zasoby, takie jak moduły równoważenia obciążenia, publiczne adresy IP i sieciowe grupy zabezpieczeń (NSG) w tej samej subskrypcji co konto usługi Batch. Upewnij się, że limity przydziału subskrypcji są wystarczające dla tych zasobów.

• Duże pule z niestandardowymi obrazami maszyn wirtualnych. Duże pule korzystające z niestandardowych obrazów maszyn wirtualnych mogą wymagać więcej czasu na alokację, a mogą wystąpić przekroczenia limitu czasu przy zmianie rozmiaru. Aby uzyskać zalecenia dotyczące limitów i konfiguracji, zobacz Tworzenie puli za pomocą galerii obliczeń platformy Azure.

Błędy automatycznego skalowania

Można skonfigurować usługę Azure Batch do automatycznego skalowania liczby węzłów w puli, określając parametry formuły automatycznego skalowania tej puli. Następnie usługa Batch używa formuły do okresowej oceny liczby węzłów w puli i ustawiania nowych wartości docelowych. Aby uzyskać więcej informacji, zobacz Tworzenie automatycznej formuły skalowania węzłów obliczeniowych w puli usługi Batch.

Podczas korzystania z automatycznego skalowania mogą wystąpić następujące problemy:

• Automatyczna ocena skalowania kończy się niepowodzeniem.
• Wynikowa operacja zmiany rozmiaru kończy się niepowodzeniem i upłynął limit czasu.
• Problem z formułą automatycznego skalowania prowadzi do nieprawidłowych wartości docelowych węzła. Zmiana rozmiaru może działać lub upłynął limit czasu.

Aby uzyskać informacje na temat ostatniej automatycznej oceny skalowania, użyj właściwości Oceń skalowanie automatyczne puli . Ta właściwość raportuje czas oceny, wartości i wynik oraz wszelkie błędy wydajności.

Pełne zdarzenie zmiany rozmiaru puli przechwytuje informacje o wszystkich ocenach.

Błędy usuwania puli

Aby usunąć pulę zawierającą węzły, usługa Batch najpierw usunie węzły, co może potrwać kilka minut. Następnie usługa Batch usuwa sam obiekt puli.

Usługa Batch ustawia wartość poolState na deleting wartość podczas procesu usuwania. Aplikacja wywołująca może wykryć, czy usunięcie puli trwa zbyt długo, używając właściwości state i stateTransitionTime.

Jeśli proces usuwania puli trwa dłużej niż oczekiwano, usługa Batch okresowo ponawia próbę do momentu pomyślnego usunięcia puli. W niektórych przypadkach opóźnienie jest spowodowane awarią usługi platformy Azure lub innymi tymczasowymi problemami. Inne czynniki, które uniemożliwiają pomyślne usunięcie puli, mogą wymagać podjęcia działań w celu rozwiązania problemu. Te czynniki mogą obejmować następujące problemy:

• Blokady zasobów mogą być umieszczane w zasobach utworzonych przez usługę Batch lub w zasobach sieciowych używanych przez usługę Batch.

• Zasoby, które utworzyłeś, mogą zależeć od zasobu utworzonego przez usługę Batch. Jeśli na przykład tworzysz pulę w sieci wirtualnej, usługa Batch tworzy grupę zabezpieczeń sieci, publiczny adres IP i równoważnik obciążenia. Jeśli używasz tych zasobów poza pulą, nie możesz dokonać usunięcia puli.

• Dostawca zasobów Microsoft.Batch może nie być już zarejestrowany w subskrypcji, która zawiera Twoją pulę.

• W przypadku kont usługi Batch w trybie subskrypcji użytkownika, Microsoft Azure Batch może już nie mieć roli Współautora lub Właściciela w subskrypcji zawierającej twoją pulę. Aby uzyskać więcej informacji, zobacz Zezwalaj usłudze Batch na dostęp do subskrypcji.

Błędy węzła

Nawet jeśli usługa Batch pomyślnie przydziela węzły w puli, różne problemy mogą spowodować, że niektóre węzły będą niesprawne i niezdolne do uruchamiania zadań. Te węzły nadal generują opłaty, dlatego ważne jest wykrywanie problemów, aby uniknąć płacenia za węzły, których nie można używać. Znajomość typowych błędów węzłów i znajomość bieżącego stanu zadania jest przydatna do rozwiązywania problemów.

Błędy przy uruchamianiu zadań

Możesz określić opcjonalne zadanie uruchamiania dla puli. Podobnie jak w przypadku dowolnego zadania, zadanie startowe używa wiersza poleceń i może pobierać pliki zasobów z magazynu danych. Zadanie uruchamiania jest uruchamiane dla każdego węzła w momencie jego uruchomienia. Właściwość waitForSuccess określa, czy usługa Batch czeka, aż zadanie uruchomieniowe zakończy się pomyślnie, zanim zaplanuje jakiekolwiek zadania na węźle. Jeśli skonfigurujesz węzeł tak, aby czekał na pomyślne zakończenie zadania uruchamiania, ale zadanie uruchamiania zakończy się niepowodzeniem, węzeł nie będzie używany, ale nadal ponosi opłaty.

Błędy zadań uruchamiania można wykrywać przy użyciu właściwości taskExecutionResult i taskFailureInformation właściwości węzła najwyższego poziomu startTaskInformation.

Niepowodzenie zadania uruchamiania powoduje również, że Batch ustawia computeNodeState na starttaskfailed, jeśli waitForSuccess ustawiono na true.

Podobnie jak w przypadku każdego zadania, może istnieć wiele przyczyn niepowodzenia zadania uruchamiania. Aby rozwiązać problemy, sprawdź pliki dziennika stdout, stderr i inne pliki dziennika specyficzne dla zadania.

Zadania startowe muszą być wielokrotnie uruchamiane, ponieważ mogą być wykonane wiele razy na tym samym węźle, na przykład w przypadku ponownego zainstalowania obrazu lub ponownego uruchomienia węzła. W rzadkich przypadkach, gdy zadanie startowe jest uruchamiane po wystąpieniu zdarzenia, które powoduje ponowne uruchomienie węzła, jeden system operacyjny lub efemeryczny dysk są ponownie instalowane, a drugi nie jest. Ponieważ zadania początkowe usługi Batch i wszystkie zadania usługi Batch są uruchamiane z dysku efemerycznego, zwykle nie stanowi to problemu. Jednak w przypadkach, gdy zadanie uruchamiania instaluje aplikację na dysku systemu operacyjnego i przechowuje inne dane na dysku efemerycznym, mogą wystąpić problemy z synchronizacją. Odpowiednio chroń aplikację, jeśli używasz obu dysków.

Niepowodzenie pobierania pakietu aplikacji

Można określić jeden lub więcej pakietów aplikacji dla puli. Usługa Batch pobiera określone pliki pakietu do każdego węzła i usuwa pliki po uruchomieniu węzła, ale przed zaplanowaniem zadań. Często używa się polecenia startowego z pakietami aplikacji, na przykład do kopiowania plików do innej lokalizacji lub uruchamiania instalacji.

Jeśli nie można pobrać i usunąć kompresji pakietu aplikacji, właściwość computeNodeError zgłasza błąd i ustawia stan węzła na unusable.

Niepowodzenie pobrania kontenera

Można określić co najmniej jedno odwołanie do kontenera w puli. Usługa Batch pobiera określone kontenery do każdego węzła. Jeśli nie można pobrać kontenera, właściwość computeNodeError zgłasza błąd i ustawia stan węzła na unusable.

Aktualizacje systemu operacyjnego Node

W przypadku pul systemu Windows wartość enableAutomaticUpdates jest domyślnie ustawiona na true. Chociaż zalecane jest zezwolenie na aktualizacje automatyczne, aktualizacje mogą przerywać postęp zadań, zwłaszcza jeśli zadania są długotrwałe. Tę wartość można ustawić tak false , aby upewnić się, że aktualizacja systemu operacyjnego nie zostanie nieoczekiwanie wykonana.

Węzeł w stanie bezużytecznym

Usługa Batch może ustawić stan computeNodeState na unusable z wielu powodów. Nie można zaplanować zadań w węźle unusable , ale węzeł nadal ponosi opłaty.

Jeśli usługa Batch może określić przyczynę, właściwość computeNodeError zgłasza ją. Jeśli węzeł jest w unusable stanie, ale nie ma computeNodeError, oznacza to, że usługa Batch nie może komunikować się z maszyną wirtualną. W takim przypadku usługa Batch zawsze próbuje odzyskać maszynę wirtualną. Jednak usługa Batch nie podejmuje automatycznej próby odzyskania maszyn wirtualnych, które nie mogły zainstalować pakietów aplikacji lub kontenerów, nawet jeśli ich stan to unusable.

Inne przyczyny węzłów unusable mogą być następujące:

• Niestandardowy obraz maszyny wirtualnej jest nieprawidłowy. Na przykład obraz nie jest prawidłowo przygotowany.
• Maszyna wirtualna jest przenoszona z powodu awarii infrastruktury lub uaktualnienia niskiego poziomu. Usługa Batch odzyskuje węzeł.
• Obraz maszyny wirtualnej został wdrożony na sprzęcie, który go nie obsługuje.
• Maszyny wirtualne znajdują się w sieci wirtualnej platformy Azure, a ruch został zablokowany do kluczowych portów.
• Maszyny wirtualne znajdują się w sieci wirtualnej, ale ruch wychodzący do usługi Azure Storage jest blokowany.
• Maszyny wirtualne znajdują się w sieci wirtualnej z niestandardową konfiguracją DNS, a serwer DNS nie może rozpoznać usługi Azure Storage.

Pliki dziennika agenta węzła

Proces agenta usługi Batch uruchamiany w każdym węźle puli udostępnia pliki dziennika, które mogą pomóc, jeśli potrzebujesz skontaktować się z pomocą techniczną dotyczącą problemu węzła puli. Pliki dziennika dla węzła można przekazać za pośrednictwem portalu Azure, Batch Explorer lub interfejsu API Compute Node - Upload Batch Service Logs. Po przekazaniu i zapisaniu plików dziennika możesz usunąć węzeł lub pulę, aby zmniejszyć koszty związane z ich obsługą.

Pełny dysk węzła

Usługa Batch używa dysku tymczasowego na maszynie wirtualnej puli węzłów do przechowywania plików, takich jak następujące pliki robocze, pliki zadań oraz pliki udostępnione:

• Pliki pakietu aplikacji
• Pliki zasobów zadania
• Pliki specyficzne dla aplikacji pobrane do jednego z folderów usługi Batch
• Pliki Stdout i stderr dla wykonania każdego zadania aplikacji
• Pliki wyjściowe specyficzne dla aplikacji

Pliki takie jak pakiety aplikacji lub pliki zasobów zadań uruchamiania są zapisywane tylko raz, gdy usługa Batch tworzy węzeł puli. Mimo że zapisują tylko raz, jeśli te pliki są zbyt duże, mogą wypełnić dysk tymczasowy.

Inne pliki, takie jak stdout i stderr, są zapisywane dla każdego zadania uruchamianego przez węzeł. Jeśli duża liczba zadań jest uruchamiana w tym samym węźle lub pliki zadań są zbyt duże, mogą wypełnić dysk tymczasowy.

Węzeł potrzebuje również niewielkiej ilości miejsca na dysku systemu operacyjnego, aby utworzyć użytkowników po jego uruchomieniu.

Rozmiar dysku tymczasowego zależy od rozmiaru maszyny wirtualnej. Jedną z kwestii podczas wybierania rozmiaru maszyny wirtualnej jest zapewnienie, że dysk tymczasowy ma wystarczającą ilość miejsca na planowane obciążenie.

Po dodaniu puli w witrynie Azure Portal można wyświetlić pełną listę rozmiarów maszyn wirtualnych, w tym kolumnę Rozmiar dysku zasobu . Artykuły opisujące rozmiary maszyn wirtualnych zawierają tabele zawierające kolumnę Magazynu tymczasowego. Aby uzyskać więcej informacji, zobacz Rozmiary maszyn wirtualnych zoptymalizowanych pod kątem obliczeń. Aby zapoznać się z przykładową tabelą rozmiarów, zobacz Fsv2-series.

Można określić czas przechowywania plików zapisywanych przez każde zadanie. Czas przechowywania określa, jak długo mają być przechowywane pliki zadań przed ich automatycznym oczyszczeniem. Możesz skrócić czas przechowywania, aby zmniejszyć wymagania dotyczące magazynu.

Jeśli dysk tymczasowy lub dysk systemu operacyjnego zabraknie na nim miejsca lub jest bliski jego wyczerpania, węzeł zostanie przeniesiony do unusablestanu computeNoteState, a błąd węzła wskazuje na to, że dysk jest pełny.

Jeśli nie masz pewności, co zajmuje miejsce w węźle, spróbuj połączyć się zdalnie z węzłem i ręcznie zbadać. Możesz również użyć interfejsu API File - List From Compute Node, aby przeglądać pliki, na przykład wyniki zadań, w folderach zarządzanych przez Batch. API wymienia tylko pliki w katalogach zarządzanych przez Batch. Jeśli zadania utworzyły pliki w innym miejscu, ten interfejs API nie wyświetla ich.

Po upewnieniu się, że pobrałeś wszystkie potrzebne dane z węzła lub przekazałeś je do trwałego magazynu, możesz usunąć dane zgodnie z potrzebami, aby zwolnić miejsce.

Możesz usunąć stare ukończone zadania lub takie, których dane nadal znajdują się na węzłach. Spójrz w kolekcję recentTasks w taskInformation na węźle lub użyj File - List From Compute Node API. Usunięcie zadania powoduje usunięcie wszystkich zadań w zadaniu. Usunięcie zadań w zadaniu powoduje usunięcie danych w katalogach zadań w węzłach i zwalnia miejsce. Po zwolnieniu wystarczającej ilości miejsca uruchom ponownie węzeł. Węzeł powinien wyprowadzić się ze unusable stanu i przejść ponownie do idle stanu.

Aby odzyskać nieużywalny węzeł w pulach VirtualMachineConfiguration, możesz usunąć węzeł z puli przy użyciu interfejsu API Pool - Remove Nodes. Następnie możesz ponownie zwiększyć pulę, aby zastąpić zły węzeł nowym.

Dalsze kroki

• Dowiedz się więcej o sprawdzaniu błędów zadań i operacji.
• Dowiedz się więcej o najlepszych rozwiązaniach dotyczących pracy z usługą Azure Batch.