Niezawodność w Azure Batch

Azure Batch uruchamia zadania wsadowe obliczeń równoległych i o wysokiej wydajności (HPC) na dużą skalę w Azure. Usługa Batch tworzy pule węzłów obliczeniowych i zarządza nimi, instaluje aplikacje, które chcesz uruchomić, i planuje uruchamianie zadań na węzłach.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak zapewnić odporność Azure Batch na błędy przejściowe, awarie węzłów obliczeniowych, awarie strefy dostępności, awarie całego regionu i konserwację usługi. Opisano również zalecenia dotyczące wdrażania produkcyjnego, architekturę niezawodności usługi Batch, tworzenie kopii zapasowych i przywracanie oraz kluczowe informacje o umowie dotyczącej poziomu usług (SLA) Azure Batch.

Zalecenia dotyczące wdrażania produkcyjnego

W przypadku obciążeń produkcyjnych postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi Azure Batch, w tym następującymi zaleceniami dotyczącymi niezawodności:

  • Projektuj zadania w celu tolerowania przerw i ponownego wykonywania. Twórz zadania idempotentne, twórz punkty kontrolne dla długotrwałych operacji i utrwalaj wymagane dane wyjściowe i diagnostyczne w trwałym magazynie. Aby uzyskać więcej informacji, zobacz Odporność na błędy przejściowe i Odporność na błędy węzłów obliczeniowych.

  • Użyj wielu węzłów obliczeniowych, gdy obciążenie musi być kontynuowane po awarii węzła. Nie ma gwarancji, że poszczególne węzły obliczeniowe pozostaną dostępne. Aprowizuj wystarczającą liczbę węzłów, aby pozostałe dostępne węzły mogły uruchamiać przeplanowane zadania.

  • Użyj rozmieszczenia w strefie dostępności, jeśli jest obsługiwane. Skonfiguruj rozmieszczenie w strefach dostępności, gdy region, jednostka SKU maszyny wirtualnej i konfiguracja obciążenia go obsługują. Węzły w sprawnych strefach mogą nadal uruchamiać zadania podczas przestoju strefy, ale należy zaplanować mniejszą pojemność, ponieważ pojemność zastępcza zależy od limitu i dostępności maszyn wirtualnych w sprawnych strefach. Aby uzyskać więcej informacji, zobacz Odporność na błędy strefy dostępności.

  • Projektuj zadania tak, aby dynamicznie kierować je do pul, zamiast używać stałego identyfikatora puli. To rozwiązanie umożliwia przekierowanie zadania do puli w dobrej kondycji, jeśli oryginalna pula stanie się niedostępna lub nie będzie można jej przeskalować do żądanej pojemności. Poprawia ciągłość działania podczas konserwacji lub awarii puli.

  • Zachowaj bieżące konfiguracje puli. Monitoruj daty końca cyklu życia (EOL) obsługi Batch dla obrazów maszyn wirtualnych i jednostek SKU oraz migruj pule przed EOL. Postępuj zgodnie ze wskazówkami dotyczącymi konserwacji usługi, aby utrzymać agenta węzła usługi Batch w aktualnym stanie.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Azure Batch używa kilku typów zasobów do uruchamiania obciążeń wsadowych. Konfiguracja tych zasobów określa sposób reagowania obciążenia na awarie.

Wszystkie zasoby i przetwarzanie usługi Batch są skojarzone z kontem usługi Batch. Rozwiązanie Batch używa następujących składników logicznych:

  • Konto usługi Batch: Zasób regionalny, z którym są skojarzone pule, zadania, zadania podrzędne i inne zasoby usługi Batch. Konto należy utworzyć i wybrać jego region, tryb alokacji puli i ustawienia uwierzytelniania.

  • Klaster: Kolekcja węzłów obliczeniowych, na których są uruchamiane zadania. Konfiguracja puli definiuje obraz i rozmiar maszyny wirtualnej, liczbę węzłów docelowych, zachowanie skalowania, sieć i rozmieszczenie w strefach. Każda pula jest konfigurowana w celu zapewnienia pojemności, umieszczania i środowiska operacyjnego wymaganego przez Twoje obciążenie robocze. Docelowa liczba węzłów jest żądaną liczbą, ale liczba przydzielonych węzłów może być niższa z powodu limitów przydziału, ograniczeń pojemności lub błędów alokacji.

  • Zlecenia i zadania:Zadanie zarządza kolekcją zadań i jest skojarzone z pulą. Zadanie uruchamia aplikację lub skrypt w węźle obliczeniowym. Definiujesz zadania, czynności, ograniczenia, zależności, zachowanie ponawiania prób i pulę, na której jest uruchamiane każde zadanie.

  • Skojarzone konto usługi Storage: Konto usługi Azure Storage, które opcjonalnie łączysz z kontem usługi Batch. Większość rozwiązań usługi Batch używa skojarzonego konta magazynu dla plików aplikacji, plików zasobów zadań, danych wejściowych i danych wyjściowych.

    Po nawiązaniu połączenia konta magazynu z kontem usługi Batch usługa Batch odwołuje się do niego jako autostorage account. Konto autostorage jest wymagane dla pakietów aplikacji, a także może przechowywać pliki zasobów zadań.

    Niezawodność rozwiązania usługi Batch zależy od zasobów magazynowych. Odpowiadasz za wybranie konfiguracji nadmiarowości magazynu spełniającej wymagania dotyczące odzyskiwania podczas tworzenia konta magazynu. Przenieś dane wyjściowe zadania i inne trwałe dane z węzłów obliczeniowych do magazynu. Aby uzyskać informacje na temat opcji niezawodności Azure Storage, zobacz Niezawodność w Azure Blob Storage.

Aby uzyskać więcej informacji, zobacz Przepływ pracy usługi Batch i zasoby oraz konta usługi Batch oraz konta Azure Storage.

Architektura fizyczna

Azure Batch ma regionalną płaszczyznę kontroli, która przetwarza operacje zarządzania względem kont usługi Batch i innych zasobów usługi Batch, takich jak pule, zadania i czynności. Jest on oddzielony od węzłów obliczeniowych, które uruchamiają zadania.

Pule obliczeniowe Azure Batch używają Azure Virtual Machines i Virtual Machine Scale Sets. Węzeł obliczeniowy to maszyna wirtualna, która przetwarza część obciążenia usługi Batch. Każdy węzeł należy do puli i wykonuje zadania przypisywane przez usługę Batch. agent węzła Batch działa w każdym węźle i udostępnia interfejs dowodzenia i sterowania między węzłem a usługą Batch. Węzły obliczeniowe i ich pamięć lokalna są efemeryczne. Gdy węzeł opuszcza pulę, zmiany w systemie operacyjnym i plikach zostaną utracone.

Tryb alokacji puli konta usługi Batch określa, gdzie usługa Batch tworzy zasoby obliczeniowe i związane z maszyną wirtualną:

  • Tryb alokacji puli usług Batch: Usługa Batch przydziela zasoby w subskrypcjach Azure zarządzanych przez usługę Batch.
  • Tryb alokacji puli subskrypcji użytkownika: Zasoby są tworzone bezpośrednio w subskrypcji zawierającej konto Batch.

Obowiązki dotyczące architektury fizycznej są podzielone w następujący sposób:

  • Microsoft: Microsoft obsługuje regionalną płaszczyznę sterowania i infrastrukturę usługi Batch. Usługa Batch aprowizuje węzły obliczeniowe zgodnie z konfiguracją puli i dostępnymi zasobami, planuje zadania, monitoruje kondycję węzła i próbuje odzyskać węzły po awariach infrastruktury. Usługa Batch może ponownie kolejkować przerwane zadania do wykonania na innym dostępnym węźle.

  • Ty: Wybierasz obraz maszyny wirtualnej i rozmiar, typy węzłów, liczbę węzłów docelowych, konfigurację skalowania, sieć i rozmieszczenie w strefach dostępności.

    Odpowiadasz również za utrzymanie wystarczających zasobów, aby tolerować awarie węzłów, monitorowanie stanów węzłów i zadań, utrzymywanie bieżącego systemu operacyjnego gościa i agenta węzła, projektowanie zadań w celu tolerowania ponownego wykonywania i przenoszenie trwałych danych z węzłów obliczeniowych.

Odzyskiwanie węzła Batch nie gwarantuje, że obciążenie robocze będzie kontynuowane bez przerwy. Aby uzyskać więcej informacji, zobacz Odporność na błędy węzłów obliczeniowych.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

W rozwiązaniu Batch błędy przejściowe mogą mieć wpływ zarówno na aplikacje i skrypty uruchamiane jako zadania, jak i na wszystkie aplikacje wywołujące interfejsy API usługi Batch w celu zarządzania zasobami usługi Batch. Usługa Batch udostępnia mechanizmy ponawiania prób na poziomie zadania. Odpowiadasz za konfigurowanie ograniczeń zadań, tworzenie idempotentnych zadań (bezpieczne do uruchomienia więcej niż raz) i konfigurowanie zachowania ponawiania prób dla wywołań usługi Batch i innych zależności.

Ponawianie prób zadania i limity czasu

Skonfiguruj maxTaskRetryCount, aby kontrolować, ile razy usługa Batch ponawia próbę wykonania zadania po zakończeniu procesu z niezerowym kodem zakończenia:

  • Wartość domyślna, 0, oznacza, że usługa Batch nie ponawia próby wykonania zadania po niezerowym kodzie zakończenia.
  • Dodatnia liczba całkowita ustawia maksymalną liczbę ponownych prób po początkowej próbie.
  • Wartość -1 umożliwia nieograniczone ponawianie prób. Ta wartość nie jest zalecana, ponieważ utrzymujące się niepowodzenie może spowodować, że zadanie będzie uruchamiane w nieskończoność.

Zaprojektuj każde zadanie jako idempotentne, aby ponawianie prób nie powodowało uszkodzenia danych ani duplikowania danych wyjściowych. W przypadku długotrwałych zadań należy użyć tworzenia punktów kontrolnych, aby ponowiona próba mogła być kontynuowana od zapisanego postępu. Aby uzyskać więcej informacji, zobacz Projektowanie ponownych prób i ponownego wykonania.

Ustaw ograniczenie maxWallClockTime dla zadania lub zadania, aby zakończyć pracę, w której nie ma postępu w dopuszczalnym czasie. Limit czasu ogranicza również wpływ powtarzających się błędów. Wybierz liczbę ponownych prób i limity czasu, które są zgodne z celami odzyskiwania obciążenia roboczego.

Błędy przejściowe w zależnościach zadań

Aplikacje i skrypty uruchamiane jako zadania usługi Batch często wywołują inne składniki, takie jak Azure Storage, bazy danych lub interfejsy API. Usługa Batch nie zarządza poszczególnymi żądaniami, które kod zadania wysyła do tych zależności. Zaimplementuj obsługę błędów przejściowych w kodzie zadania lub użyj funkcji ponawiania udostępnianych przez zestaw SDK zależności. Postępuj zgodnie ze wskazówkami dotyczącymi każdej zależności, aby zidentyfikować błędy z możliwością ponawiania prób, wybrać odpowiednie ustawienia opóźnienia ponowień i limitu czasu oraz przestrzegać instrukcji ponawiania, takich jak nagłówek Retry-After. Spróbuj ponownie wykonać tylko operacje, które można bezpiecznie powtórzyć.

Jeśli błąd zależności powoduje zakończenie procesu zadania z kodem zakończenia niezerowym, usługa Batch może ponowić próbę wykonania całego zadania zgodnie z maxTaskRetryCount. Jednak usługa Batch nie ponawia próby pojedynczego żądania zależności w ramach uruchomionego zadania.

Ponowne próby żądań Batch API

Aplikacje działające poza usługą mogą wywoływać interfejsy API usługi Batch w celu tworzenia pul, zadań, zadań podrzędnych, węzłów obliczeniowych i innych zasobów usługi Batch oraz zarządzania nimi. Skonfiguruj tych klientów przy użyciu zasad ponawiania obowiązujących przez co najmniej pięć minut, aby obsługiwać przejściowe błędy usługi Batch lub sieci.

Użyj wbudowanej obsługi ponawiania prób zestawu SDK, gdy jest dostępna. Na przykład biblioteka klienta Azure.Compute.Batch client library for .NET uwidacznia zachowanie ponawiania za pomocą Azure.Core opcji ponawiania prób.

Jeśli korzystasz bezpośrednio z interfejsów API usługi Batch z poziomu kodu, zaczekaj kilka sekund przed ponowną próbą, użyj wykładniczego opóźnienia ponowień z losowością (jitter), aby uniknąć zsynchronizowanych żądań ponawiania prób, oraz uwzględniaj nagłówek Retry-After zwracany z odpowiedziami ograniczania przepustowości, takimi jak 429 Too Many Requests i 503 Service Unavailable.

Limit czasu żądania nie musi oznaczać, że usługa Batch nie przetworzyła żądania. Po przekroczeniu limitu czasu spróbuj ponownie wykonać operację, gdy jest to bezpieczne, lub pobierz stan zasobu, aby określić, czy operacja oryginalna zakończyła się pomyślnie. Aby uzyskać więcej informacji, zobacz Obsługa błędów i ich wykrywanie w usłudze Azure Batch.

Odporność na awarie węzłów obliczeniowych

Węzeł obliczeniowy może stać się niedostępny z powodu awarii infrastruktury, problemu z systemem operacyjnym lub problemu z konfiguracją. Usługa Batch próbuje odzyskać węzły, na które mają wpływ awarie infrastruktury, ale nie może automatycznie naprawić wszystkich problemów związanych z konfiguracją. Jeśli na przykład instalacja pakietu aplikacji lub kontenera nie powiedzie się, musisz rozwiązać podstawowy problem i może być konieczne usunięcie i zastąpienie węzła, którego dotyczy problem.

Jeśli awaria węzła przerywa zadanie, usługa Batch może ponowić próbę wykonania zadania na tym samym węźle, jeśli to możliwe, do limitu wewnętrznego. Jeśli zadanie nie może kontynuować w tym węźle, usługa Batch może ponownie kolejkować je do wykonania w innym dostępnym węźle. Te ponawiania odzyskiwania oparte na usłudze są niezależne od maxTaskRetryCount i mogą wystąpić nawet wtedy, gdy jego wartość to 0.

proces odzyskiwania węzła zarządzanego przez firmę Microsoft

Microsoft zarządza odzyskiwaniem węzłów sterowanym przez usługę i ponownym kolejkowaniem zadań. Jeśli usługa Batch przestanie odbierać sygnały heartbeat z węzła wystarczająco długo, aby wyzwolić odzyskiwanie, usługa Batch może wykonać następujące akcje:

  1. Izoluj węzeł: Usługa Batch traktuje węzeł jako w złej kondycji, ustawia jego stan na unusable, i zatrzymuje planowanie nowych zadań na nim.
  2. Identyfikowanie zadań, których dotyczy problem: Usługa Batch identyfikuje zadania uruchomione w węźle jako kandydatów do ponownego zaplanowania.
  3. Ponowne umieszczanie kwalifikujących się zadań w kolejce: Jeśli zadanie, którego dotyczy problem, nadal jest utrwalone w running stanie, usługa Batch może go zresetować, active aby harmonogram mógł przypisać go do innego węzła. Usługa Batch nie resetuje ani nie uruchamia ponownie zadania już utrwalonego w stanie completed.
  4. Odzyskaj węzeł: Usługa Batch próbuje przywrócić węzeł do stanu dobrej kondycji lub zastąpić podstawową maszynę wirtualną.

Odzyskiwanie nie jest natychmiastowe. Zadanie może pozostać w stanie running, gdy usługa Batch wykryje awarię węzła i spróbuje ponownie zaplanować zadanie. Jeśli żaden inny węzeł obliczeniowy nie jest dostępny, zadanie może pozostać w tym stanie, dopóki usługa Batch nie będzie mogła je ponownie zaplanować. Aby uzyskać więcej informacji, zobacz Znane ograniczenia dotyczące zadań usługi Batch.

Jeśli oryginalny węzeł wznowi prawidłowe sygnały heartbeat przed rozpoczęciem zamiany, usługa Batch może przywrócić go do stabilnego stanu. Jeśli zastępowanie zostało już rozpoczęte, usługa Batch może zamiast tego usunąć oryginalną maszynę wirtualną i udostępnić maszynę zastępczą.

Twoje obowiązki

Odzyskiwanie sterowane usługą nie gwarantuje nieprzerwanego wykonywania zadań ani wystarczających pozostałych zasobów. Odpowiadasz za następujące akcje:

  • Utrzymuj wystarczające zasoby: Jeśli obciążenie musi być kontynuowane, gdy węzeł jest niedostępny, aprowizuj wystarczającą liczbę węzłów, aby pozostałe węzły uruchamiały przeplanowane zadania. Bez innego węzła do użycia przerwane zadania muszą czekać.

  • Monitoruj dostępną pojemność: Śledź zagregowane liczby i stany węzłów, aby wykryć, kiedy pula nie ma już wystarczającej liczby dostępnych węzłów dla Twojego obciążenia. Stany, takie jak unusable, startTaskFailed, unknown i preempted, wskazują obniżoną wydajność. Więcej informacji znajdziesz w Monitorowanie rozwiązań usługi Batch przez zliczanie zadań i węzłów według stanu.

  • Zbadaj problematyczne węzły: Jeśli zadania wielokrotnie kończą się niepowodzeniem, są ponownie kolejkowane lub pozostają w stanie running po tym, jak przypisany węzeł stanie się bezużyteczny lub opuści pulę, użyj metadanych zadań, aby określić, czy problemy są skojarzone z określonym węzłem.

    Przed usunięciem węzła z problemem przekaż dzienniki agenta węzła usługi Batch i zachowaj odpowiednie dzienniki zadań, ponieważ usunięcie węzła spowoduje usunięcie jego plików lokalnych. Dzienniki agenta węzła mogą pomóc pomoc techniczna firmy Microsoft zdiagnozować problemy z usługą Batch lub węzłem, podczas gdy dzienniki zadań, takie jak stdout i stderr, mogą pomóc w zidentyfikowaniu problemów z aplikacją i konfiguracją. Aby uzyskać więcej informacji, zobacz Pliki dziennika agenta węzła.

  • Chroń postęp zadania i dane: Projektuj zadania tak, aby tolerowały przerwy i ponowne uruchomienie. Przenoś punkty kontrolne, dane wyjściowe i inne trwałe dane poza węzły obliczeniowe, ponieważ ich lokalna pamięć masowa jest efemeryczna.

Aby uzyskać więcej informacji, zobacz błędy puli i węzłów Azure Batch oraz Obsługa błędów i wykrywanie błędów w Azure Batch.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Usługa Batch obsługuje strefy dostępności na dwa główne sposoby:

  • Warstwa sterowania: Warstwa sterowania usługi Batch jest odporna na awarie stref w wielu regionach. W tych regionach operacje zarządzania względem kont usługi Batch i innych zasobów usługi Batch mogą być kontynuowane podczas awarii strefy. Microsoft nie publikuje, które regiony zapewniają tę odporność płaszczyzny sterowania.

  • Pule: Pulę usługi Batch można skonfigurować tak, aby korzystała z rozmieszczenia w strefach dostępności. Jeśli strefa stanie się niedostępna, węzły obliczeniowe w strefach w dobrej kondycji pozostaną dostępne do planowania zadań.

    W przypadku umieszczania węzłów obliczeniowych ten model obsługi jest podobny do nadmiarowości strefy w innych usługach Azure, ponieważ pojedyncza pula może zawierać węzły obliczeniowe w wielu strefach dostępności. Jednak usługa Batch dystrybuuje węzły między strefami w miarę możliwości. Próbuje użyć wszystkich stref w regionie, ale nie gwarantuje rozmieszczenia w każdej strefie lub równomiernej dystrybucji. Nie można wybrać określonych stref ani kontrolować liczby węzłów umieszczonych w każdej strefie.

Na poniższym diagramie przedstawiono przykładowe konto usługi Batch. Konto ma jedną pulę z węzłami rozmieszczonymi w trzech strefach dostępności:

Diagram przedstawiający pulę usługi Batch z węzłami obliczeniowymi rozmieszczonymi w trzech strefach dostępności.

Odpowiadasz za zapewnienie innym zasobom zależnym, takim jak konta magazynu, odporności strefowej. Zapoznaj się z przewodnikami dotyczącymi niezawodności dla każdej usługi. Aby uzyskać więcej informacji, zobacz Przewodniki dotyczące niezawodności usług Azure.

Requirements

Dystrybucja wystąpień między strefami

Po włączeniu rozmieszczania w strefach dostępności usługa Batch próbuje przydzielić węzły obliczeniowe we wszystkich strefach dostępności w wybranym regionie. Ta alokacja jest wykonywana w miarę możliwości. Usługa Batch kontroluje dystrybucję, a liczba węzłów w każdej strefie może nie być równa.

Cost

Usługa Batch nie dodaje opłat za włączenie umieszczania w strefie dostępności. Opłaty są naliczane za zasoby obliczeniowe, magazynowe, sieciowe i inne zasoby Azure używane przez obciążenie robocze. Jeśli udostępnisz dodatkowe węzły w celu tolerowania utraty strefy, te węzły generują normalne opłaty. Aby uzyskać więcej informacji, zobacz cennik Azure Batch.

Konfiguruj obsługę stref dostępności

  • Utwórz nową pulę z rozmieszczeniem w strefie dostępności: Aby utworzyć pulę z włączonym rozmieszczeniem w strefie dostępności, zobacz Utwórz pulę usługi Batch w strefach dostępności.

  • Zmień rozmieszczenie stref dostępności w istniejącej puli: Podczas tworzenia puli należy wybrać rozmieszczenie stref dostępności. Nie można zmienić istniejącej puli tak, aby korzystała ze stref dostępności.

    Możesz utworzyć pulę zastępczą i zaktualizować każde z zadań, aby jej używać, wykonując następujące kroki:

    1. Wyłącz zadanie: Użyj operacji Wyłącz zadanie i wybierz sposób, w jaki usługa Batch obsługuje zadania, które są uruchomione podczas przesyłania żądania:

      • Czekaj: Usługa Batch zatrzymuje uruchamianie nowych zadań i umożliwia ukończenie uruchomionych zadań w istniejącej puli. Zadanie pozostaje w stanie disabling do momentu zakończenia uruchomionych zadań.
      • Ponowne umieszczenie w kolejce: Usługa Batch przerywa działające zadania i zwraca je do kolejki. Zadania mogą być uruchamiane ponownie po włączeniu zadania wsadowego.
      • Zakończ: Usługa Batch przerywa działające zadania i oznacza je jako ukończone z informacjami o niepowodzeniu, które wskazują, że zostały zakończone. Zadania nie są uruchamiane ponownie po włączeniu zadania podrzędnego.

      Zadania, które są już w stanie active, co oznacza, że są one kolejkowane, ale nie są uruchomione, pozostają w kolejce z każdą opcją.

      Przed kontynuowaniem poczekaj, aż zadanie osiągnie stan disabled. W tym momencie żadne zadania nie są uruchomione, a usługa Batch nie będzie planować nowych zadań.

    2. Edytuj pulę zadania: Użyj operacji Aktualizuj zadanie, aby ustawić właściwość puli zadania poolInfo.poolId na pulę zastępczą. Usługa Batch zezwala na zmianę tej właściwości tylko wtedy, gdy zadanie jest w disabled stanie . Upewnij się, że pula zastąpień istnieje i ma pojemność do wykorzystania przed włączeniem zadania. Jeśli pula nie istnieje, usługa Batch akceptuje aktualizację, ale nie może zaplanować zadań do momentu utworzenia puli.

    3. Włącz zadanie: Użyj operacji Włącz zadanie . Zadanie przechodzi ze stanu enabling do stanu active. Następnie usługa Batch planuje zadania w kolejce, w tym zadania zwracane do kolejki przez opcję Ponowne kolejkowanie w puli zamiennej. Zadania zakończone, gdy usługa Batch zastosowała opcję Czekaj, oraz zadania zakończone za pomocą opcji Zakończ nie są uruchamiane ponownie.

Planowanie pojemności i zarządzanie nimi

Normalny proces odzyskiwania węzłów usługi Batch próbuje zastąpić węzły, które stają się bezużyteczne podczas awarii strefy, i przywraca pulę do skonfigurowanej docelowej liczby węzłów. Nie zwiększa wartości docelowej. Aby zachować wystarczającą pojemność, by obsłużyć obciążenie, gdy jedna strefa jest niedostępna, rozważ nadmiarowe przydzielenie zasobów puli przy użyciu skalowania automatycznego lub ręcznego:

  • Jeśli używasz skalowania automatycznego: Odwołaj się do $UsableNodeCountzmiennej zdefiniowanej przez usługę w formule automatycznego skalowania puli, aby wykryć, kiedy pojemność do wykorzystania spadnie poniżej planu bazowego wymaganego przez obciążenie. $UsableNodeCountto zmienna autoskalowania usługi Batch dla puli, której formuła jest obliczana, a nie metryka Azure Monitor. Azure Monitor publikuje metryki liczby węzłów usługi Batch w zakresie konta usługi Batch, a te metryki nie mają poolId wymiaru.

  • W przypadku ręcznego zarządzania pojemnością: Użyj operacji List Pool Node Counts, aby pobrać liczby węzłów dedykowanych i Spot w każdym stanie dla każdej puli. Operacja nie zwraca pojedynczej liczby użytecznych węzłów. Oceń stany obsługujące zadania, takie jak idle i unusable, w porównaniu ze stanami niedostępnymi lub problematycznymi, takimi jak unknown, offline, startTaskFailed i running. Zwrócone liczby mogą nie być aktualne, więc wylicz węzły obliczeniowe puli, gdy wymagana jest dokładna liczba.

Usługa Batch dystrybuuje węzły między strefami w miarę możliwości, więc rzeczywista dystrybucja może nie być równa. Nie zakładaj, że węzły są równomiernie dystrybuowane między strefami podczas planowania pojemności. Sprawdź, czy obciążenie robocze może spełniać cele odzyskiwania po awarii przy ograniczonej pojemności puli.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy pula usługi Batch korzysta z rozmieszczenia w strefach dostępności, a wszystkie strefy działają.

  • Operacja między strefami: Usługa Batch planuje zadania w dostępnych węzłach obliczeniowych w całej puli, niezależnie od strefy zawierającej każdy węzeł.

  • Replikacja danych między strefami: Węzły obliczeniowe usługi Batch są efemeryczne, a usługa Batch nie replikuje plików zadań między strefami. Odpowiadasz za przenoszenie danych wejściowych, wyjściowych, punktów kontrolnych i danych diagnostycznych, które muszą przetrwać utratę węzła do trwałego magazynu. Skonfiguruj nadmiarowość konta magazynu, aby spełnić wymagania dotyczące dostępności.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy pula usługi Batch korzysta z umieszczania strefy dostępności, a jedna strefa dostępności jest niedostępna.

  • Wykrywanie i reagowanie: Microsoft monitoruje kondycję usługi Batch i węzłów obliczeniowych. Podczas awarii strefy usługa Batch wykrywa trwałą utratę sygnału heartbeat z węzłów, których dotyczy problem, i uruchamia normalny proces odzyskiwania węzłów. Węzły w strefach w dobrej kondycji pozostają dostępne, a usługa Batch może nadal planować na nich zadania.

    Usługa Batch próbuje przywrócić pulę do skonfigurowanej docelowej liczby węzłów za pośrednictwem normalnego procesu odzyskiwania, ale nie zwiększa tego celu. Odpowiadasz za żądanie dodatkowej pojemności, jeśli obiekt docelowy nie zapewnia wystarczającej pojemności dla obciążenia.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Można jednak użyć Azure Service Health aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty Service Health w celu powiadamiania o problemach.

  • Aktywne zadania: Zadania uruchomione w węzłach, których dotyczy problem, są przerywane. Usługa Batch może ponownie planować zadania na dostępnych węzłach w ramach wewnętrznego mechanizmu odzyskiwania. Projektuj zadania tak, aby tolerowały ponowne próby i ponowne wykonywanie, zgodnie z opisem w temacie Odporność na błędy przejściowe i Odporność na awarie węzłów obliczeniowych.

  • Oczekiwana utrata danych: Pliki w węzłach obliczeniowych, których dotyczy problem, są niedostępne podczas awarii i są tracone, jeśli węzły są ponownie obrazowane lub usuwane z puli. Usługa Batch nie replikuje tych plików między strefami. Dane utrwalone w trwałym magazynie pozostają dostępne zgodnie z konfiguracją nadmiarowości tego zasobu magazynu.

  • Oczekiwany przestój: Zadania na sprawnych węzłach są nadal wykonywane. Przerwane zadania pozostają w stanie przestoju, dopóki usługa Batch nie będzie mogła ponownie przydzielić ich do dostępnych węzłów. Jeśli węzeł do użycia nie jest dostępny, zadanie może pozostać w running stanie, dopóki usługa Batch nie będzie mogła go ponownie zaplanować. Czas odzyskiwania zależy od dostępnej pojemności puli i obciążenia w kolejce.

    Operacje zarządzania względem kont usługi Batch i innych zasobów usługi Batch są kontynuowane, jeśli konto znajduje się w regionie, w którym płaszczyzna sterowania jest odporna na strefy. W innych regionach operacje zarządzania mogą być niedostępne do czasu odzyskania strefy, której dotyczy problem.

  • Redystrybucja: Po trwałej utracie sygnału heartbeat usługa Batch oznacza węzły, których dotyczy problem, jako unusable i zgłasza je do wymiany za pośrednictwem normalnego procesu odzyskiwania węzła. Usługa Batch próbuje przywrócić pulę do skonfigurowanej docelowej liczby węzłów, ale pojemność zastępcza zależy od limitu i dostępności maszyn wirtualnych w strefach w dobrej kondycji.

    Zadania pozostają skojarzone z pulą podczas tego procesu. Usługa Batch nadal planuje zadania z aktywnych zleceń w węzłach nadających się do użycia w strefach w dobrej kondycji. Jeśli węzły zastępcze zostaną przydzielone i staną się gotowe do użycia, usługa Batch może również zaplanować zadania w tych węzłach.

    Ten proces odzyskiwania nie zwiększa skonfigurowanej docelowej liczby węzłów. Jeśli obciążenie wymaga wydajności przekraczającej ten cel, zwiększ ją ręcznie lub skonfiguruj formułę autoskalowania puli, aby to zrobić.

Odzyskiwanie strefy

Usługa Batch zarządza procesem odzyskiwania, gdy strefa odzyska sprawność po awarii. Usługa Batch jest zgodna z tym samym procesem zdefiniowanym w temacie Odporność na błędy węzłów obliczeniowych.

Usługa Batch nie gwarantuje ponownego równomiernego równoważenia węzłów w różnych strefach dostępności po odzyskaniu. Umieszczenie strefy odbywa się w miarę możliwości.

Testowanie pod kątem niepowodzeń strefy

Nie można symulować rzeczywistej awarii strefy dostępności Azure na potrzeby testowania. Zamiast tego użyj puli nieprodukcyjnej, aby przerwać typowe zadania robocze i wyłączyć z eksploatacji wystarczającą liczbę węzłów obliczeniowych, aby przybliżyć oczekiwany spadek dostępnej mocy obliczeniowej. Rozważ użycie następujących obsługiwanych operacji węzłów:

  • Uruchom ponownie wybrane węzły.
  • Wyłącz planowanie zadań na wybranych węzłach.
  • Usuń wybrane węzły z puli.

Gdy operacja umożliwia wybranie sposobu obsługi uruchomionych zadań, wybierz opcję Requeue, aby usługa Batch mogła zaplanować przerwane zadania w pozostałych węzłach.

Podczas testu sprawdź, czy usługa Batch ponownie planuje przerwane zadania i czy ponowne wykonywanie nie generuje zduplikowanych ani niespójnych danych wyjściowych. Upewnij się, że punkty kontrolne i dane wyjściowe pozostają dostępne w trwałej pamięci masowej, monitorowanie wykrywa utratę węzłów i zmniejszoną pojemność, a obciążenie robocze może zostać ukończone przy użyciu pozostałej pojemności.

Te operacje weryfikują przerywanie zadań i ponowne planowanie, idempotentność, tworzenie punktów kontrolnych i trwałą obsługę danych wyjściowych. Jednak nie odzwierciedlają one każdego efektu awarii całej strefy.

Odporność na awarie całego regionu

Konto usługi Batch i jego pule są ograniczone do jednego regionu Azure. Jeśli w regionie wystąpi awaria, może to mieć wpływ na zadania i pule usługi Batch.

Usługa Batch nie replikuje kont, konfiguracji puli, zadań i zadań podrzędnych, pakietów aplikacji ani danych zadań do innego regionu i nie zapewnia wbudowanego trybu failover między regionami. Odpowiadasz za wdrażanie i obsługę rozwiązania usługi Batch w wielu regionach, gdy obciążenie musi tolerować awarię całego regionu.

Dostosowane rozwiązania wieloregionowe zwiększające odporność

Aby utworzyć rozwiązanie wieloregionowe, wdróż co najmniej jedno konto usługi Batch w każdym regionie używanym przez projekt odzyskiwania po awarii. Konta Batch działają niezależnie w różnych regionach. Odpowiadasz za wybieranie regionów, wdrażanie i obsługę zasobów w każdym regionie oraz koordynowanie konfiguracji, replikacji, trybu failover i powrotu po awarii.

Można zaprojektować podejście aktywne-aktywne , które przesyła pracę w wielu regionach podczas normalnego działania, lub podejście aktywne-pasywne , które utrzymuje pomocnicze wdrożenie gotowe do pracy w trybie failover. Architektury aktywny-aktywny mogą skrócić czas odzyskiwania, ponieważ oba wdrożenia przetwarzają zadania podczas normalnej pracy, podczas gdy architektury aktywny-pasywny mogą zmniejszyć koszty obliczeń w stanie stałym.

Poniższa lista zawiera przykłady obowiązków podczas projektowania rozwiązania:

  • Wdrożenie: Wstępnie utwórz konta usługi Batch, pule lub definicje wdrożenia puli, konta magazynu, zasoby sieciowe i inne zależności w każdym regionie. Sprawdź, czy każdy wybrany region obsługuje funkcje usługi Batch, rozmiary maszyn wirtualnych i usługi zależne wymagane przez obciążenie. Zachowaj każde konto usługi Batch i zasoby magazynu używane przez jego zadania w tym samym regionie, jeśli to możliwe, aby uniknąć niepotrzebnego opóźnienia. Zdefiniuj konta usługi Batch, pule i zasoby pomocnicze przy użyciu infrastruktury jako kodu, aby można było spójnie odtworzyć konfigurację w różnych regionach.

  • Limity przydziału i pojemność: Sprawdź odpowiednie limity przydziału konta, subskrypcji i rodziny maszyn wirtualnych usługi Batch w każdym regionie odzyskiwania po awarii i zażądaj zwiększenia przed awarią w razie potrzeby. Limit przydziału jest limitem, a nie gwarancją pojemności. Dostępność maszyn wirtualnych zależy od regionu, rodziny maszyn wirtualnych i chwili. Aby uzyskać więcej informacji, zobacz Konta usługi Batch i limity przydziału rdzeni.

  • Replikacja danych: Zachowaj pakiety aplikacji, obrazy kontenerów, dane wejściowe i dane referencyjne dostępne w każdym regionie odzyskiwania. Usługa Batch nie replikuje tych elementów dla Ciebie.

  • Replikacja magazynowania: Skonfiguruj nadmiarowość magazynowania i replikację danych między regionami na podstawie celu punktu odzyskiwania. Sprawdź, czy replikowane dane są dostępne z każdego regionu odzyskiwania. Aby uzyskać informacje o opcjach niezawodności magazynu, zobacz Niezawodność w Azure Blob Storage.

  • Określanie wartości docelowej regionu: Jeśli aplikacje współpracują z kontem usługi Batch, zaprojektuj je tak, aby mogły wybrać inne konto usługi Batch i skojarzone z nim zasoby magazynu bez konieczności wdrażania kodu.

  • Tryb failover: Usługa Batch nie przenosi obciążenia automatycznie do innego regionu. Odpowiadasz za wykrycie awarii, określenie, w jaki sposób awaria wpływa na Twoje obciążenie robocze, zatrzymywanie przesyłania na konto usługi Batch, którego dotyczy awaria, kierowanie nowej pracy do konta usługi Batch w sprawnym regionie i podejmowanie decyzji, czy ponownie przesłać przerwane zadania. Dane wyjściowe pracy lub zadania, które nie zostały zreplikowane poza regionem, którego dotyczy problem, mogą być niedostępne lub utracone. Czas przywracania zależy od modelu wdrażania, dostępnej pojemności, replikacji danych i automatyzacji.

  • Przywracanie regionu: Po przywróceniu dostępności usługi w danym regionie zweryfikuj konto usługi Batch, pule, zależności magazynu i stan zadania przed przekierowaniem pracy do tego regionu. Przed ponownym przesłaniem usuń duplikaty i dokończ częściowo ukończone zadania. Usługa Batch nie koordynuje tego procesu ani nie uzgadnia stanu między kontami regionalnymi.

  • Testowanie: Regularnie testuj pełny proces odzyskiwania regionalnego w środowisku nieprodukcyjnym. Zasymuluj sytuację, w której jedno wdrożenie regionalne staje się niedostępne, kieruj zgłoszenia do innego regionalnego konta usługi Batch, zweryfikuj dostęp do pakietów aplikacji i danych wejściowych, uruchom reprezentatywne zadania, zbierz dane wyjściowe i przećwicz przywrócenie odzyskanego wdrożenia do działania. Porównaj wyniki z docelowym czasem odtworzenia (RTO) i docelowym punktem odtworzenia (RPO).

Tworzenie kopii zapasowej i przywracanie

Azure Batch nie jest trwałym magazynem danych wejściowych i wyjściowych obciążenia roboczego. Microsoft obsługuje usługę Batch, ale odpowiadasz za zachowanie konfiguracji i danych potrzebnych do odtworzenia obciążenia roboczego:

  • Konfiguracja usługi Batch: Zdefiniuj konta usługi Batch, pule, zadania i zasoby pomocnicze przy użyciu infrastruktury jako kodu, takiego jak Bicep i definicji zadań kontrolowanych przez wersję. Te artefakty zapewniają powtarzalny sposób ponownego tworzenia konfiguracji w tym samym regionie lub innym regionie. Regularnie sprawdzaj, czy definicje mogą utworzyć pulę i uruchamiać reprezentatywne zadanie.

  • Metadane Batch: Batch zachowuje rekordy zleceń i zadań do momentu usunięcia skojarzonego zlecenia lub zadania, ale te rekordy nie są kopią zapasową. Jeśli chcesz zachować tę historię, zachowaj wymagane rekordy poza usługą Batch.

  • Dane na węzłach obliczeniowych: Węzły obliczeniowe są efemeryczne, a ich systemy plików nie są magazynem kopii zapasowych ani trwałym magazynem danych. Dane w węźle są tracone, gdy węzeł zostanie ponownie utworzony z obrazu lub opuści pulę. Usługa Batch może również usuwać pliki zadań po wygaśnięciu okresu przechowywania. Zapisuj wymagane dane wyjściowe i dzienniki diagnostyczne w magazynie trwałym przed ukończeniem zadania. W przypadku długotrwałych zadań utrwalaj punkty kontrolne podczas wykonywania. Aby uzyskać więcej informacji, zobacz Utrwalanie danych wyjściowych zadań i zadań podrzędnych oraz Monitorowanie usługi Azure Batch.

  • Dane na kontach usługi autostorage: Skojarzone konto autostorage może przechowywać pakiety aplikacji i pliki zasobów zadań. Oprócz konfigurowania nadmiarowości spełniającej cele odtwarzania po awarii należy rozważyć, czy należy chronić te dane przed przypadkowym usunięciem lub uszkodzeniem. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i odzyskiwanie w Azure Blob Storage.

Testowanie przywracania i odzyskiwania

Aby przywrócić działanie, wdróż usługę Batch i pomocniczą konfigurację zasobów, przywróć lub ponownie połącz wymagane dane wejściowe i artefakty aplikacji oraz prześlij ponownie zadania, które nie zostały ukończone. Należy okresowo testować zarówno rekonstrukcję zasobów, jak i przywracanie danych w izolowanym lub nieprodukcyjnym środowisku odzyskiwania. Użyj definicji kontrolowanych przez wersję i danych objętych kopią zapasową, uruchom reprezentatywne zadanie, zweryfikuj wynikowe dane wyjściowe i dostęp do zależności oraz zmierz osiągnięty czas odzyskiwania i punkt odtworzenia względem celów. Sprawdź, czy zadania są idempotentne, tak aby ponowne przesłanie zadań o niepewnym statusie nie powodowało uszkodzenia danych ani nie tworzyło zduplikowanych danych wyjściowych.

Odporność usługi na prace konserwacyjne

Microsoft wykonuje konserwację platformy i koordynuje aktualizacje infrastruktury dla Azure Batch i innych usług. Odpowiadasz za konfigurowanie zachowania aktualizacji puli i projektowanie zadań odpornych na przerwanie.

  • Konserwacja hosta: Azure używa technik konserwacji, takich jak migracja na żywo, jeśli jest to możliwe. Jeśli konserwacja wymaga ponownego uruchomienia lub przeniesienia węzła obliczeniowego, uruchomione zadania mogą zostać przerwane, a usługa Batch może je ponownie zaplanować. Spraw, aby zadania były idempotentne, i utrwal punkty kontrolne i dane wyjściowe w trwałym magazynie.

  • System operacyjny gościa: Odpowiadasz za utrzymywanie bieżącego systemu operacyjnego gościa i bieżącego agenta węzła usługi Batch. Zachowanie aktualizacji systemu operacyjnego zależy od obrazu i konfiguracji aktualizacji. Dzięki odpowiedniej konfiguracji automatyczne uaktualnienia obrazów systemu operacyjnego dla pul usługi Batch mogą aktualizować węzły puli bez przerywania wykonywanych zadań. Automatyczne uaktualnienia obrazów systemu operacyjnego nie obsługują każdego obrazu systemu operacyjnego Usługi Batch.

  • Aktualizacje agenta węzła: Automatyczne uaktualnienia obrazów systemu operacyjnego nie aktualizują automatycznie agenta węzła usługi Batch. Agenci węzłów usługi Batch nie są automatycznie uaktualniane, gdy pula ma węzły obliczeniowe. Aby otrzymać nowszą wersję agenta węzła, zmień rozmiar puli na zero węzłów, a następnie ponownie ją zwiększ lub zastąp pulę. Przed usunięciem węzłów zachowaj wszystkie wymagane dane wyjściowe zadania i dzienniki diagnostyczne. Aby uzyskać więcej informacji, zobacz Aktualizacje agenta węzła usługi Batch.

Postępuj zgodnie z zaleceniami dotyczącymi wdrażania produkcyjnego i wskazówkami dotyczącymi awarii węzła obliczeniowego, aby ułatwić kontynuowanie lub przywrócenie działania obciążenia, gdy konserwacja przerywa zadania lub sprawia, że węzły obliczeniowe są niedostępne.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Umowa SLA dotycząca dostępności Azure Batch dotyczy operacji wykonywanych względem interfejsu API usługi Batch. Aby uzyskać szczegółowe informacje o typach operacji, które zostały uwzględnione, zapoznaj się z treścią umowy SLA. Rozmiar puli, dystrybucja stref i usługi zależne wpływają na kompleksową dostępność obciążenia, ale nie zmieniają warunków umowy SLA usługi Batch.

Treści powiązane

  • Ostatnia aktualizacja o