Niezawodność w usłudze Azure Batch
W tym artykule opisano obsługę niezawodności w usłudze Azure Batch i opisano zarówno odporność wewnątrz regionalną ze strefami dostępności, jak i linki do informacji na temat odzyskiwania między regionami 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 każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.
Aby uzyskać więcej informacji na temat stref dostępności na platformie Azure, zobacz Co to są strefy dostępności?.
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 interfejs API listy jednostek SKU zasobów i sprawdź
ResourceSkuRestrictionselement . Jeśli istnieje ograniczenie strefy, możesz przesłać bilet 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 sprawdzić, czy region obsługuje żądaną jednostkę SKU maszyny wirtualnej w więcej niż jednej strefie, wywołaj interfejs API listy jednostek sku zasobów i sprawdź
locationInfopoleresourceSku. 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.
Środowisko strefowe w dół
Podczas awarii strefy węzły w tej strefie stają się niedostępne. Wszystkie węzły w tej samej puli węzłów z innych stref nie mają wpływu 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 spadły z powodu awarii. Użytkownicy muszą dodać więcej węzłów do puli węzłów, które są następnie przydzielane z innych stref w dobrej kondycji.
Odporność na uszkodzenia
Aby przygotować się do ewentualnej awarii strefy dostępności, należy nadmiernie aprowizować pojemność usługi, aby zapewnić, że rozwiązanie może tolerować utratę pojemności 1/3 i nadal działać bez obniżonej 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 są tworzone w tym samym regionie co konto usługi 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ą co najmniej dwóch kont usługi Batch z każdym kontem znajdującym 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 usługi Batch i konto magazynu. 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.
Przed upływem czasu upewnij się, że odpowiednie limity przydziału są ustawione dla wszystkich kont usługi Batch subskrypcji użytkownika, aby przydzielić wymaganą liczbę rdzeni przy użyciu konta usługi 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 aplikacja niestandardowa do zainstalowania w węzłach puli jest przechowywana i przywołyowana przy użyciu pakietów aplikacji usługi Batch. Po wydaniu aktualizacji aplikacji należy ją przekazać do każdego konta usługi Batch i przywoływane przez konfigurację puli (lub ustawić najnowszą wersję domyślną).
W aplikacji wywołującej usługę Batch, magazyn i wszystkie inne usługi można łatwo przełączyć się na klientów lub obciążenie do różnych 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 odbierają ruch jednocześnie, odzyskiwanie po awarii jest szybsze niż w przypadku konfiguracji aktywne-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 odzyskiwania po awarii rozwiązania z obsługą usługi Batch. Najlepszym rozwiązaniem jest umożliwienie łatwego przełączania między ładowaniem klienta i usługi w różnych regionach.
Testowanie planu odzyskiwania po awarii dla usługi Batch może być tak proste, jak naprzemienne konta usługi 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 wieloma kontami do odzyskiwania po awarii zajmuje się oczekiwaniami celu odzyskiwania i celu punktu odzyskiwania w lokalizacjach geograficznych z jednym regionem lub wieloma regionami.
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 aktywne:
Zawsze należy wstępnie wdrażać drugie pliki. Wstępne wdrażanie pomocniczych jest konieczne, ponieważ nie ma gwarancji zdolności produkcyjnych w czasie wpływu na tych, którzy nie wstępnie przydzielili takich zasobów.
Utwórz wstępnie wszystkie wymagane usługi w każdym regionie, takie jak konta usługi Batch i skojarzone konta magazynu. 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ń usługi Batch w górę.
Uwaga
Jeśli planujesz uruchamianie obciążeń produkcyjnych w usłudze Batch, może być konieczne zwiększenie co najmniej jednego limitu przydziału powyżej wartości domyślnej. Aby zwiększyć limit przydziału, możesz zażądać zwiększenia limitu przydziału bez opłat. Aby uzyskać więcej informacji, zobacz Żądanie zwiększenia limitu przydziału.
Storage
Musisz skonfigurować magazyn usługi Batch, aby upewnić się, że kopie zapasowe danych są tworzone w wielu regionach; Odpowiedzialność klienta jest wartością domyślną. 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 podrzędne usługi Batch (w tym standardowe, uruchamiania oraz przygotowania i zwolnienia zadań) muszą określać pliki zasobów, które znajdują się na koncie magazynu. 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 (aktualnie obsługiwane w przypadku pul w konfiguracji maszyny wirtualnej)
Aby uzyskać więcej informacji dotyczących kont magazynu, zobacz temat Azure Storage account overview (Omówienie konta usługi Azure Storage).
Konto magazynu można skojarzyć z kontem usługi Batch podczas tworzenia konta lub wykonać ten krok później.
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 magazynu strefowo nadmiarowego (ZRS), ponieważ magazyn GZRS nie jest dostępny.
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ą zwiększyć wydajność rozwiązań usługi Batch, które zawierają dużą liczbę zadań równoległych odczytujących lub zapisujących na koncie magazynu.
Gdy konto magazynu jest połączone z kontem usługi Batch, należy traktować je jako konto automatycznego tworzenia magazynu. Konto autostorage jest wymagane, jeśli planujesz używać 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 dla plików zasobów zadań. Ponieważ konto automatycznego tworzenia magazynu jest już połączone z kontem usługi Batch, pozwala to uniknąć konieczności uzyskiwania dostępu do plików zasobów za pomocą adresów URL sygnatury dostępu współdzielonego ( SAS).