Niezawodność w Azure Batch

W tym artykule opisano obsługę niezawodności w usłudze Azure Batch. W tym artykule opisano, jak poprawić odporność wewnątrz regionalną przy użyciu stref dostępności, pul wsadowych i węzłów obliczeniowych w celu zminimalizowania przestojów i utraty danych. Zawiera również linki do informacji na temat międzyregionalnego odzyskiwania i ciągłości działania.

Obsługa 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 utrzymuje równoważność z platformą Azure w zakresie obsługi stref dostępności.

Wymagania wstępne

• W przypadku kont usługi Batch w trybie subskrypcji użytkownika upewnij się, że subskrypcja, w której tworzysz pulę, nie ma ograniczenia oferty strefy dla żądanej jednostki SKU maszyny wirtualnej. Aby sprawdzić, czy twoja subskrypcja nie ma żadnych ograniczeń, wywołaj API listy SKU zasobów i sprawdź ResourceSkuRestrictions. Jeśli istnieje ograniczenie strefy, możesz przesłać zgłoszenie do pomocy technicznej, aby usunąć ograniczenie strefy.

• Ponieważ rozwiązanie InfiniBand nie obsługuje komunikacji między strefami, nie można utworzyć puli z zasadami strefowymi, jeśli ma włączoną komunikację między węzłami i używa jednostki SKU maszyny wirtualnej obsługującej rozwiązanie InfiniBand.

• Usługa Batch utrzymuje równoważność z platformą Azure w zakresie obsługi stref dostępności. Aby użyć opcji strefowej, pula musi zostać utworzona w regionie świadczenia usługi Azure z obsługą stref dostępności.

• Aby przydzielić pulę usługi Batch w różnych strefach dostępności, region świadczenia usługi Azure, w którym utworzono pulę, musi obsługiwać żądaną jednostkę SKU maszyny wirtualnej w więcej niż jednej strefie. Aby zweryfikować, czy region obsługuje żądany SKU maszyny wirtualnej w więcej niż jednej strefie, wywołaj interfejs API Resource Skus List i sprawdź pole locationInforesourceSku. Upewnij się, że dla żądanej jednostki SKU maszyny wirtualnej jest obsługiwana więcej niż jedna strefa. Możesz również użyć interfejsu wiersza polecenia platformy Azure , aby wyświetlić listę wszystkich dostępnych jednostek SKU zasobów za pomocą następującego polecenia:

  
      az vm list-skus
  
  

Tworzenie puli usługi Azure Batch w różnych strefach dostępności

Aby zapoznać się z przykładami dotyczącymi tworzenia puli usługi Batch w różnych strefach dostępności, zobacz Tworzenie puli usługi Azure Batch w różnych strefach dostępności.

Dowiedz się więcej o tworzeniu kont usługi Batch za pomocą witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, programu PowerShell lub interfejsu API zarządzania usługi Batch.

Doświadczenie zmniejszania strefy

Podczas awarii strefy węzły w tej strefie stają się niedostępne. Dowolne węzły w tej samej puli węzłów z innych stref nie są dotknięte i nadal będą dostępne.

Konto usługi Azure Batch nie powoduje reallokowania ani tworzenia nowych węzłów w celu zrekompensowania awarii węzłów, które przestały działać wskutek awarii. Użytkownicy muszą dodać więcej węzłów do puli węzłów, które są następnie przydzielane z innych zdrowych stref.

Odporność na uszkodzenia

Aby przygotować się do ewentualnej awarii strefy dostępności, należy zaprojektować nadmiarową pojemność usługi, aby zapewnić, że rozwiązanie może tolerować utratę 1/3 pojemności i nadal funkcjonować bez spadku wydajności podczas awarii całego obszaru strefy. Ponieważ platforma rozprzestrzenia maszyny wirtualne w trzech strefach i musisz uwzględnić co najmniej awarię jednej strefy, pomnożyć liczbę wystąpień szczytowych obciążeń przez współczynnik stref/(strefy-1) lub 3/2. Jeśli na przykład typowe szczytowe obciążenie wymaga czterech wystąpień, należy aprowizować sześć wystąpień: (2/3 * 6 wystąpień) = 4 wystąpienia.

Migracja strefy dostępności

Nie można migrować istniejącej puli usługi Batch do obsługi stref dostępności. Jeśli chcesz ponownie utworzyć pulę usługi Batch w różnych strefach dostępności, zobacz Tworzenie puli usługi Azure Batch w różnych strefach dostępności.

Odzyskiwanie po awarii między regionami i ciągłość działania

Usługa Azure Batch jest dostępna we wszystkich regionach świadczenia usługi Azure. Jednak po utworzeniu konta usługi Batch musi on być skojarzony z jednym określonym regionem. Wszystkie kolejne operacje dla tego konta usługi Batch dotyczą tylko tego regionu. Na przykład pule i skojarzone maszyny wirtualne (VM) są tworzone w tym samym regionie co konto Batch.

Podczas projektowania aplikacji korzystającej z usługi Batch należy wziąć pod uwagę możliwość, że usługa Batch może nie być dostępna w regionie. Istnieje możliwość wystąpienia rzadkiej sytuacji, w której występuje problem z regionem jako całością, całą usługą Batch w regionie lub określonym kontem usługi Batch.

Jeśli aplikacja lub rozwiązanie korzystające z usługi Batch musi być zawsze dostępne, należy go zaprojektować tak, aby przejść w tryb failover do innego regionu lub zawsze podzielić obciążenie między co najmniej dwa regiony. Oba podejścia wymagają posiadania co najmniej dwóch kont usługi Batch, przy czym każde z nich musi znajdować się w innym regionie.

Odpowiadasz za skonfigurowanie odzyskiwania po awarii między regionami za pomocą usługi Azure Batch. Jeśli uruchamiasz wiele kont usługi Batch w określonych regionach i korzystasz ze stref dostępności, aplikacja może spełnić cele odzyskiwania po awarii, gdy jedno z kont usługi Batch stanie się niedostępne.

Podczas zapewniania możliwości przejścia w tryb failover do regionu alternatywnego należy wziąć pod uwagę wszystkie składniki rozwiązania; Nie wystarczy po prostu mieć drugie konto usługi Batch. Na przykład w większości aplikacji usługi Batch wymagane jest konto usługi Azure Storage. Konto magazynu i konto usługi Batch muszą znajdować się w tym samym regionie w celu uzyskania akceptowalnej wydajności.

Podczas projektowania rozwiązania, które może przejść w tryb failover, należy wziąć pod uwagę następujące kwestie:

• Utwórz wstępnie wszystkie wymagane usługi w każdym regionie, takie jak konto Batch i konto magazynowe. Często nie są naliczane opłaty za utworzenie kont, a opłaty są naliczane tylko wtedy, gdy konto jest używane lub gdy dane są przechowywane.

• Z wyprzedzeniem upewnij się, że odpowiednie limity są ustawione dla wszystkich kont Batch subskrypcji użytkownika, aby wymagana liczba rdzeni została przydzielona przy użyciu konta Batch.

• Użyj szablonów i/lub skryptów, aby zautomatyzować wdrażanie aplikacji w regionie.

• Zachowaj aktualność plików binarnych aplikacji i danych referencyjnych we wszystkich regionach. Zapewnienie aktualności zapewni szybkie przenoszenie regionu do trybu online bez konieczności oczekiwania na przekazywanie i wdrażanie plików. Rozważmy na przykład przypadek, w którym niestandardowa aplikacja przeznaczona do instalacji na węzłach puli jest przechowywana i odwoływana za pomocą pakietów aplikacji Batch. Po wydaniu aktualizacji aplikacji należy ją załadować na każde konto Batch, aby była odwoływana przez konfigurację puli (albo ustawić najnowszą wersję jako wersję domyślną).

• W aplikacji obsługującej usługę Batch, magazyn i inne usługi, można łatwo skonfigurować przełączanie klientów oraz obciążenia do innych regionów.

• Rozważ częste przełączanie do regionu alternatywnego w ramach normalnego działania. Na przykład w przypadku dwóch wdrożeń w oddzielnych regionach przełącz się do regionu alternatywnego co miesiąc.

Czas odzyskiwania po awarii zależy od wybranej konfiguracji. Sama usługa Batch jest niezależna od tego, czy używasz wielu kont, czy jednego konta. W konfiguracjach aktywnych-aktywnych, w których dwa wystąpienia usługi Batch przyjmują ruch jednocześnie, odzyskiwanie po awarii jest szybsze niż w przypadku konfiguracji aktywno-pasywnej. Wybrana konfiguracja powinna być oparta na potrzebach biznesowych (różnych regionach, wymaganiach dotyczących opóźnień) i zagadnieniach technicznych.

Odzyskiwanie po awarii w jednym regionie

Sposób implementowania odzyskiwania po awarii w usłudze Batch jest taki sam, niezależnie od tego, czy pracujesz w jednym regionie, czy w lokalizacji geograficznej obejmującej wiele regionów. Jedyną różnicą jest jednostka SKU używana do magazynowania i to, czy zamierzasz używać tego samego lub innego konta magazynu we wszystkich regionach.

Testowanie odzyskiwania po awarii

Należy przeprowadzić własne testy przywracania po awarii dla rozwiązania z obsługą Batch. Uważa się za najlepszą praktykę umożliwienie łatwego przełączania obciążenia klienta i usługi w różnych regionach.

Testowanie planu odzyskiwania po awarii dla usługi Batch może być tak proste, jak zmiana kont Batch. Na przykład można polegać na jednym koncie usługi Batch w określonym regionie przez jeden dzień operacyjny. Następnie następnego dnia możesz przełączyć się na drugie konto usługi Batch w innym regionie. Odzyskiwanie po awarii jest zarządzane głównie po stronie klienta. Takie podejście z wykorzystaniem wielu kont do odzyskiwania po awarii zajmuje się oczekiwaniami dotyczącymi czasu odzyskiwania (RTO) i celu punktu odzyskiwania danych (RPO) w lokalizacjach geograficznych obejmujących jeden region lub wiele regionów.

Wydajność i proaktywna odporność odzyskiwania po awarii

Firma Microsoft i jej klienci działają w ramach modelu wspólnej odpowiedzialności. Firma Microsoft jest odpowiedzialna za odporność platformy i infrastruktury. Odpowiadasz za rozwiązywanie problemów z odzyskiwaniem po awarii dla każdej określonej usługi, którą wdrażasz i kontrolujesz. Aby upewnić się, że odzyskiwanie jest proaktywne:

• Zawsze należy wstępnie rozmieszczać elementy wtórne. Wstępne wdrażanie zasobów pomocniczych jest konieczne, ponieważ nie ma gwarancji dostępności zasobów w momencie potrzeby dla tych, którzy nie przydzielili wcześniej takich zasobów.

• Utwórz z wyprzedzeniem wszystkie niezbędne usługi w każdym regionie, takie jak konta Batch oraz powiązane konta magazynowe. Za tworzenie nowych kont nie są naliczane opłaty; opłaty są naliczane tylko wtedy, gdy konto jest używane lub gdy dane są przechowywane.

• Upewnij się, że odpowiednie limity przydziału są ustawione na wszystkie subskrypcje z wyprzedzeniem, dzięki czemu można przydzielić wymaganą liczbę rdzeni przy użyciu konta usługi Batch. Podobnie jak w przypadku innych usług platformy Azure, istnieją limity dotyczące niektórych zasobów skojarzonych z usługą Batch. Wiele z tych limitów to domyślne limity przydziału stosowane przez platformę Azure na poziomie subskrypcji lub konta. Należy pamiętać o tych przydziałach podczas projektowania i skalowania obciążeń Batch.

Magazyn

Aby zapewnić tworzenie kopii zapasowych danych w wielu regionach, musisz skonfigurować magazyn usługi Batch; domyślnie za to odpowiada klient. Większość rozwiązań usługi Batch używa usługi Azure Storage do przechowywania plików zasobów i plików wyjściowych. Na przykład, zadania Batch (w tym standardowe, początkowe, przygotowania zadań i zwalniania zadań) zazwyczaj określają pliki zasobów, które znajdują się na koncie magazynowym. Konta magazynu przechowują również dane przetwarzane i wszystkie wygenerowane dane wyjściowe. Zrozumienie możliwej utraty danych w różnych regionach operacji usługi jest ważnym zagadnieniem. Należy również potwierdzić, czy dane można zapisywać ponownie, czy tylko do odczytu.

Usługa Batch obsługuje następujące typy kont usługi Azure Storage:

• Konta ogólnego przeznaczenia, wersja 2 (GPv2)
• Konta ogólnego przeznaczenia, wersja 1 (GPv1)
• Konta magazynu obiektów blob (obsługiwane obecnie dla pul w konfiguracji maszyn wirtualnych)

Aby uzyskać więcej informacji dotyczących kont magazynu, zobacz Omówienie konta magazynu Azure.

Konto pamięci można skojarzyć z kontem usługi Batch podczas tworzenia konta lub wykonać później ten krok.

Jeśli konfigurujesz oddzielne konto magazynu dla każdego regionu, w którym jest dostępna usługa, musisz użyć kont magazynu strefowo nadmiarowego (ZRS). Użyj kont magazynu geograficznie nadmiarowego (GZRS), jeśli używasz tego samego konta magazynu w wielu sparowanych regionach. W przypadku lokalizacji geograficznych zawierających jeden region należy utworzyć konto strefowo nadmiarowego magazynu danych (ZRS), ponieważ konto GZRS nie jest dostępne.

Planowanie pojemności to kolejna ważna kwestia dotycząca magazynu i powinna być aktywnie rozwiązywana. Wybierając konto magazynu, należy wziąć pod uwagę wymagania dotyczące kosztów i wydajności. Na przykład opcje konta magazynu GPv2 i Blob Storage obsługują większe limity wydajności i skalowalności w porównaniu z wersją GPv1. (Skontaktuj się z pomocą techniczną platformy Azure, aby poprosić o zwiększenie limitu magazynu). Te opcje konta mogą poprawić wydajność rozwiązań usługi Batch, które zawierają dużą liczbę zadań wykonywanych równolegle i które odczytują lub zapisują dane z konta magazynu.

Gdy konto magazynu jest połączone z kontem Batch, można je traktować jako konto automatycznego magazynowania. Konto autostorage jest wymagane, jeśli planujesz korzystać z możliwości pakietów aplikacji , ponieważ jest ono używane do przechowywania pakietu aplikacji .zip plików. Konto autostorage może być również używane do plików zasobów zadań; ponieważ konto autostorage jest już połączone z kontem usługi Batch, pozwala to uniknąć konieczności używania adresów URL sygnatury dostępu współdzielonego (SAS) do dostępu do plików zasobów.

Dalsze kroki

• Niezawodność na platformie Azure