Odzyskiwanie po obejmujących cały region zakłóceniach usługi

Artykuł
03/21/2023

Platforma Azure jest podzielona fizycznie i logicznie na jednostki nazywane regionami. Region składa się z jednego lub większej liczby centrów danych w bliskiej odległości. Wiele regionów i usług obsługuje również strefy dostępności, które mogą służyć do zapewnienia większej odporności na awarie w jednym centrum danych. Rozważ użycie regionów ze strefami dostępności, aby zwiększyć dostępność rozwiązania.

W rzadkich okolicznościach istnieje możliwość, że obiekty w całej strefie dostępności lub regionie mogą stać się niedostępne, na przykład z powodu awarii sieci. Można też całkowicie utracić obiekty, na przykład z powodu klęsk żywiołowych. Platforma Azure ma możliwości tworzenia aplikacji rozproszonych między strefami i regionami. Taka dystrybucja pomaga zminimalizować możliwość, że awaria w jednej strefie lub regionie może mieć wpływ na inne strefy lub regiony.

Usługi w chmurze

Zarządzanie zasobami

Wystąpienia obliczeniowe można dystrybuować w różnych regionach, tworząc oddzielną usługę w chmurze w każdym regionie docelowym, a następnie publikując pakiet wdrożeniowy w każdej usłudze w chmurze. Jednak dystrybucja ruchu między usługami w chmurze w różnych regionach musi zostać zaimplementowana przez dewelopera aplikacji lub za pomocą usługi zarządzania ruchem.

Określenie liczby wystąpień roli zapasowej do wdrożenia z wyprzedzeniem na potrzeby odzyskiwania po awarii jest ważnym aspektem planowania pojemności. Posiadanie wdrożenia pomocniczego na pełną skalę zapewnia, że pojemność jest już dostępna w razie potrzeby; jednak skutecznie podwaja to koszt. Typowym wzorcem jest posiadanie małego, pomocniczego wdrożenia, wystarczy na tyle duże, aby uruchamiać usługi krytyczne. To małe wdrożenie pomocnicze jest dobrym pomysłem, zarówno do rezerwowania pojemności, jak i do testowania konfiguracji środowiska pomocniczego.

Uwaga

Limit przydziału subskrypcji nie jest gwarancją pojemności. Limit przydziału jest po prostu limitem środków. Aby zagwarantować pojemność, wymagana liczba ról musi być zdefiniowana w modelu usługi, a role muszą zostać wdrożone.

Równoważenie obciążenia

Aby równoważyć obciążenie ruchu między regionami, wymagane jest rozwiązanie do zarządzania ruchem. Platforma Azure udostępnia usługę Azure Traffic Manager. Możesz również skorzystać z usług innych firm, które zapewniają podobne możliwości zarządzania ruchem.

Strategie

Wiele alternatywnych strategii jest dostępnych do implementowania rozproszonych zasobów obliczeniowych w różnych regionach. Muszą one być dostosowane do określonych wymagań biznesowych i okoliczności aplikacji. Na wysokim poziomie podejścia można podzielić na następujące kategorie:

Ponowne wdrażanie w przypadku awarii: w tym podejściu aplikacja jest wdrażana ponownie od podstaw w momencie awarii. Jest to odpowiednie dla aplikacji niekrytycznych, które nie wymagają gwarantowanego czasu odzyskiwania.
Ciepły zapasowy (aktywny/pasywny): dodatkowa hostowana usługa jest tworzona w regionie alternatywnym, a role są wdrażane w celu zagwarantowania minimalnej pojemności; jednak role nie odbierają ruchu produkcyjnego. Takie podejście jest przydatne w przypadku aplikacji, które nie zostały zaprojektowane do dystrybucji ruchu między regionami.
Hot Spare (Aktywny/Aktywny): aplikacja jest przeznaczona do odbierania obciążenia produkcyjnego w wielu regionach. Usługi w chmurze w każdym regionie mogą być skonfigurowane pod kątem większej pojemności niż wymagane do celów odzyskiwania po awarii. Alternatywnie usługi w chmurze mogą być skalowane w poziomie w razie awarii i przełączania w tryb failover. Takie podejście wymaga znacznej inwestycji w projektowanie aplikacji, ale ma znaczące korzyści. Obejmują one niski i gwarantowany czas odzyskiwania, ciągłe testowanie wszystkich lokalizacji odzyskiwania i wydajne wykorzystanie pojemności.

Pełna dyskusja na temat projektu rozproszonego wykracza poza zakres tego dokumentu. Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii i wysoka dostępność aplikacji platformy Azure.

Maszyny wirtualne

Odzyskiwanie maszyn wirtualnych typu "infrastruktura jako usługa" (IaaS) jest podobne do odzyskiwania zasobów obliczeniowych typu "platforma jako usługa" (PaaS) pod wieloma względami. Istnieją jednak istotne różnice ze względu na fakt, że maszyna wirtualna IaaS składa się zarówno z maszyny wirtualnej, jak i dysku maszyny wirtualnej.

Użyj Azure Backup, aby utworzyć kopie zapasowe obejmujące wiele regionów, które są spójne z aplikacjami. Azure Backup umożliwia klientom tworzenie kopii zapasowych spójnych na poziomie aplikacji na wielu dyskach maszyn wirtualnych i obsługę replikacji kopii zapasowych w różnych regionach. Możesz to zrobić, wybierając opcję replikacji geograficznej magazynu kopii zapasowych w momencie tworzenia. Replikacja magazynu kopii zapasowych musi być skonfigurowana w momencie tworzenia. Nie można go później ustawić. Jeśli region zostanie utracony, firma Microsoft udostępni klientom kopie zapasowe. Klienci będą mogli przywrócić dowolne ze skonfigurowanych punktów przywracania.
Oddziel dysk danych od dysku systemu operacyjnego. Ważną kwestią dla maszyn wirtualnych IaaS jest to, że nie można zmienić dysku systemu operacyjnego bez ponownego tworzenia maszyny wirtualnej. Nie jest to problem, jeśli strategia odzyskiwania ma być ponownie wdrażana po awarii. Jednak może to być problem, jeśli używasz metody Warm Spare do rezerwowania pojemności. Aby zaimplementować to poprawnie, musisz mieć prawidłowy dysk systemu operacyjnego wdrożony zarówno w lokalizacjach podstawowych, jak i pomocniczych, a dane aplikacji muszą być przechowywane na oddzielnym dysku. Jeśli to możliwe, użyj standardowej konfiguracji systemu operacyjnego, która może być podana w obu lokalizacjach. Po przejściu w tryb failover należy następnie dołączyć dysk danych do istniejących maszyn wirtualnych IaaS w pomocniczym kontrolerze domeny. Użyj narzędzia AzCopy, aby skopiować migawki dysków danych do lokacji zdalnej.
Należy pamiętać o potencjalnych problemach ze spójnością po przejściu w tryb failover geograficznym wielu dysków maszyn wirtualnych. Dyski maszyn wirtualnych są implementowane jako obiekty blob usługi Azure Storage i mają taką samą charakterystykę replikacji geograficznej. Chyba że Azure Backup jest używana, nie ma gwarancji spójności między dyskami, ponieważ replikacja geograficzna jest asynchroniczna i replikuje niezależnie. Poszczególne dyski maszyn wirtualnych są gwarantowane w stanie spójnym na poziomie awarii po przejściu w tryb failover geograficznym, ale nie są spójne na różnych dyskach. Może to spowodować problemy w niektórych przypadkach (na przykład w przypadku usuwania dysków).
Używanie usługi Azure Site Recovery do replikowania aplikacji w różnych regionach. Dzięki usłudze Azure Site Recovery klienci nie muszą martwić się o oddzielenie dysków danych od dysków systemu operacyjnego ani potencjalnych problemów ze spójnością. Usługa Azure Site Recovery replikuje obciążenia uruchomione na maszynach fizycznych i wirtualnych z lokacji głównej (lokalnie lub na platformie Azure) do lokalizacji dodatkowej (na platformie Azure). Gdy wystąpi awaria w lokacji głównej klienta, można wyzwolić przejście w tryb failover, aby szybko zwrócić klienta do stanu operacyjnego. Po przywróceniu lokalizacji podstawowej klienci mogą wrócić po awarii. Można je łatwo replikować przy użyciu punktów odzyskiwania za pomocą migawek spójnych na poziomie aplikacji. Te migawki przechwytują dane dysku, wszystkie dane w pamięci i wszystkie transakcje w procesie. Usługa Azure Site Recovery umożliwia klientom utrzymanie celów czasu odzyskiwania (RTO) i celów punktu odzyskiwania (RPO) w ramach limitów organizacyjnych. Klienci mogą również łatwo uruchamiać próbne odzyskiwanie po awarii bez wpływu na aplikacje w środowisku produkcyjnym. Korzystając z planów odzyskiwania, klienci mogą sekwencjonować tryb failover i odzyskiwanie wielowarstwowych aplikacji działających na wielu maszynach wirtualnych. Mogą grupować maszyny razem w planie odzyskiwania i opcjonalnie dodawać skrypty i akcje ręczne. Plany odzyskiwania można zintegrować z elementami Runbook Azure Automation.

Storage

Odzyskiwanie przy użyciu magazynu geograficznie nadmiarowego obiektów blob, tabeli, kolejki i magazynu dysków maszyn wirtualnych

Na platformie Azure obiekty blob, tabele, kolejki i dyski maszyny wirtualnej są domyślnie replikowane geograficznie. Jest to nazywane magazynem geograficznie nadmiarowym (GRS). Magazyn GRS replikuje dane magazynu do sparowanego centrum danych znajdującego się setki mil od siebie w określonym regionie geograficznym. Magazyn GRS został zaprojektowany w celu zapewnienia dodatkowej trwałości w przypadku wystąpienia poważnej awarii centrum danych. Firma Microsoft kontroluje, kiedy nastąpi przejście w tryb failover, a przejście w tryb failover jest ograniczone do poważnych awarii, w których oryginalna lokalizacja podstawowa jest uznawana za nieodwracalną w rozsądnym czasie. W niektórych scenariuszach może to być kilka dni. Dane są zwykle replikowane w ciągu kilku minut, chociaż interwał synchronizacji nie jest jeszcze objęty umową dotyczącą poziomu usług.

Jeśli nastąpi przejście w tryb failover geograficznie, nie zmieni się sposób uzyskiwania dostępu do konta (adres URL i klucz konta nie zmieni się). Konto magazynu będzie jednak znajdować się w innym regionie po przejściu w tryb failover. Może to mieć wpływ na aplikacje wymagające koligacji regionalnej z kontem magazynu. Nawet w przypadku usług i aplikacji, które nie wymagają konta magazynu w tym samym centrum danych, opóźnienie między centrami danych i opłaty za przepustowość mogą być przekonujące, aby tymczasowo przenieść ruch do regionu trybu failover. Może to mieć wpływ na ogólną strategię odzyskiwania po awarii.

Oprócz automatycznego przejścia w tryb failover zapewnianego przez magazyn GRS platforma Azure wprowadziła usługę, która zapewnia dostęp do odczytu kopii danych w dodatkowej lokalizacji magazynu. Jest to nazywane magazynem geograficznie nadmiarowym dostępu do odczytu (RA-GRS).

Aby uzyskać więcej informacji na temat magazynu GRS i RA-GRS, zobacz Replikacja usługi Azure Storage.

Mapowania regionów replikacji geograficznej

Ważne jest, aby wiedzieć, gdzie dane są replikowane geograficznie, aby wiedzieć, gdzie wdrożyć inne wystąpienia danych, które wymagają koligacji regionalnej z magazynem. Aby uzyskać więcej informacji, zobacz Regiony sparowane platformy Azure.

Cennik replikacji geograficznej

Replikacja geograficzna jest uwzględniana w bieżących cenach usługi Azure Storage. Jest to nazywane magazynem geograficznie nadmiarowym (GRS). Jeśli nie chcesz, aby dane są replikowane geograficznie, możesz wyłączyć replikację geograficzną dla konta. Jest to nazywane magazynem lokalnie nadmiarowym (LRS) i opłata jest naliczana w cenie obniżonej w porównaniu z magazynem GRS.

Określanie, czy nastąpiło przejście do trybu failover geograficznego

Jeśli nastąpi przejście w tryb failover geograficznie, zostanie on opublikowany na pulpicie nawigacyjnym usługi Azure Service Health. Aplikacje mogą jednak zaimplementować zautomatyzowane środki wykrywania, monitorując region geograficzny dla swojego konta magazynu. Może to służyć do wyzwalania innych operacji odzyskiwania, takich jak aktywacja zasobów obliczeniowych w regionie geograficznym, do którego przeniesiono magazyn. Zapytanie dotyczące tego można wykonać za pomocą interfejsu API zarządzania usługami przy użyciu polecenia Pobierz właściwości konta magazynu. Odpowiednie właściwości to:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

baza danych

SQL Database

Azure SQL Baza danych zapewnia dwa typy odzyskiwania: przywracanie geograficzne i aktywna replikacja geograficzna.

Przywracanie geograficzne

Przywracanie geograficzne jest również dostępne w bazach danych w warstwie Podstawowa, Standardowa i Premium. Zapewnia on domyślną opcję odzyskiwania, gdy baza danych jest niedostępna z powodu zdarzenia w regionie, w którym jest hostowana baza danych. Podobnie jak przywracanie do punktu w czasie, przywracanie geograficzne opiera się na kopiach zapasowych bazy danych w geograficznie nadmiarowym magazynie platformy Azure. Jest przywracana z kopii kopii zapasowej replikowanej geograficznie i w związku z tym jest odporna na awarie magazynu w regionie podstawowym. Aby uzyskać więcej informacji, zobacz Przywracanie bazy danych Azure SQL lub przechodzenie w tryb failover do pomocniczego.

Aktywna replikacja geograficzna

Aktywna replikacja geograficzna jest dostępna dla wszystkich warstw bazy danych. Jest ona przeznaczona dla aplikacji, które mają bardziej agresywne wymagania dotyczące odzyskiwania niż przywracanie geograficzne może oferować. Przy użyciu aktywnej replikacji geograficznej można utworzyć maksymalnie cztery czytelne sekundy na serwerach w różnych regionach. Możesz zainicjować przejście w tryb failover do dowolnego z plików pomocniczych. Ponadto aktywna replikacja geograficzna może służyć do obsługi scenariuszy uaktualniania lub relokacji aplikacji, a także równoważenia obciążenia dla obciążeń tylko do odczytu. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie aktywnej replikacji geograficznej dla bazy danych Azure SQL i inicjowanie trybu failover. Zapoznaj się z tematem Projektowanie globalnie dostępnych usług przy użyciu usługi Azure SQL Database i Zarządzanie uaktualnieniami stopniowe aplikacji w chmurze przy użyciu SQL Database aktywnej replikacji geograficznej, aby uzyskać szczegółowe informacje na temat projektowania i implementowania uaktualnień aplikacji i aplikacji bez przestojów.

Program SQL Server na maszynach wirtualnych platformy Azure

Dostępne są różne opcje odzyskiwania i wysokiej dostępności dla SQL Server 2012 (i nowszych) działających na platformie Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Wysoka dostępność i odzyskiwanie po awarii dla SQL Server w usłudze Azure Virtual Machines.

Inne usługi platformy Azure

Podczas próby uruchomienia usługi w chmurze w wielu regionach platformy Azure należy wziąć pod uwagę konsekwencje dla każdego z zależności. W poniższych sekcjach wskazówki specyficzne dla usługi zakładają, że musisz użyć tej samej usługi platformy Azure w alternatywnym centrum danych platformy Azure. Obejmuje to zarówno zadania konfiguracji, jak i replikacji danych.

Uwaga

W niektórych przypadkach te kroki mogą pomóc w ograniczeniu awarii specyficznej dla usługi, a nie całego zdarzenia centrum danych. Z perspektywy aplikacji awaria specyficzna dla usługi może być równie ograniczona i wymagałaby tymczasowej migracji usługi do alternatywnego regionu platformy Azure.

Service Bus

Azure Service Bus używa unikatowej przestrzeni nazw, która nie obejmuje regionów platformy Azure. Pierwszym wymaganiem jest skonfigurowanie niezbędnych przestrzeni nazw usługi Service Bus w regionie alternatywnym. Istnieją jednak również zagadnienia dotyczące trwałości komunikatów w kolejce. Istnieje kilka strategii replikowania komunikatów w różnych regionach świadczenia usługi Azure. Aby uzyskać szczegółowe informacje na temat tych strategii replikacji i innych strategii odzyskiwania po awarii, zobacz Najlepsze rozwiązania dotyczące izolowania aplikacji przed awariami i awariami usługi Service Bus.

App Service

Aby przeprowadzić migrację aplikacji Azure App Service, takiej jak Web Apps lub Mobile Apps, do pomocniczego regionu świadczenia usługi Azure, musisz mieć kopię zapasową witryny internetowej dostępnej do publikowania. Jeśli awaria nie obejmuje całego centrum danych platformy Azure, może być możliwe pobranie najnowszej kopii zapasowej zawartości witryny za pomocą protokołu FTP. Następnie utwórz nową aplikację w regionie alternatywnym, chyba że wcześniej to zrobiono, aby zarezerwować pojemność. Opublikuj lokację w nowym regionie i wprowadź niezbędne zmiany konfiguracji. Te zmiany mogą obejmować parametry połączenia bazy danych lub inne ustawienia specyficzne dla regionu. W razie potrzeby dodaj certyfikat SSL witryny i zmień rekord CNAME DNS, aby nazwa domeny niestandardowej wskazuje ponownie wdrożony adres URL aplikacji internetowej platformy Azure.

HDInsight

Dane skojarzone z usługą HDInsight są domyślnie przechowywane w Azure Blob Storage. Usługa HDInsight wymaga, aby zadania MapReduce przetwarzania klastra Hadoop były współlokowane w tym samym regionie co konto magazynu zawierające analizowane dane. Jeśli używasz funkcji replikacji geograficznej dostępnej dla usługi Azure Storage, możesz uzyskać dostęp do danych w regionie pomocniczym, w którym dane zostały zreplikowane, jeśli z jakiegoś powodu region podstawowy nie jest już dostępny. Możesz utworzyć nowy klaster Hadoop w regionie, w którym dane zostały zreplikowane i kontynuować ich przetwarzanie.

SQL Reporting

W tej chwili odzyskiwanie po utracie regionu platformy Azure wymaga wielu wystąpień SQL Reporting w różnych regionach świadczenia usługi Azure. Te SQL Reporting wystąpienia powinny uzyskiwać dostęp do tych samych danych i że dane powinny mieć własny plan odzyskiwania w przypadku awarii. Można również obsługiwać zewnętrzne kopie zapasowe pliku RDL dla każdego raportu.

Media Services

Usługa Azure Media Services ma inne podejście do odzyskiwania na potrzeby kodowania i przesyłania strumieniowego. Zazwyczaj przesyłanie strumieniowe jest bardziej krytyczne podczas awarii regionalnej. Aby przygotować się do tego celu, musisz mieć konto usługi Media Services w dwóch różnych regionach świadczenia usługi Azure. Zakodowana zawartość powinna znajdować się w obu regionach. Podczas awarii można przekierować ruch przesyłany strumieniowo do regionu alternatywnego. Kodowanie można wykonać w dowolnym regionie świadczenia usługi Azure. Jeśli kodowanie jest wrażliwe na czas, na przykład podczas przetwarzania zdarzeń na żywo, należy przygotować się do przesyłania zadań do alternatywnego centrum danych podczas awarii.

Sieć wirtualna

Pliki konfiguracji zapewniają najszybszy sposób konfigurowania sieci wirtualnej w alternatywnym regionie świadczenia usługi Azure. Po skonfigurowaniu sieci wirtualnej w podstawowym regionie świadczenia usługi Azure wyeksportuj ustawienia sieci wirtualnej dla bieżącej sieci do pliku konfiguracji sieci. Jeśli wystąpi awaria w regionie podstawowym, przywróć sieć wirtualną z przechowywanego pliku konfiguracji. Następnie skonfiguruj inne usługi w chmurze, maszyny wirtualne lub ustawienia obejmujące wiele lokalizacji, aby pracować z nową siecią wirtualną.
Istnieją zasoby związane z siecią wirtualną, które należy wziąć pod uwagę (np. sieciowa grupa zabezpieczeń, DNS, tabele tras). Metoda opisana w temacie Infrastruktura jako kod jest sposobem generowania tego samego środowiska za każdym razem i można ją wdrożyć w nowym regionie.

Listy kontrolne dotyczące odzyskiwania po awarii

lista kontrolna Cloud Services

Przejrzyj sekcję Cloud Services tego dokumentu.
Utwórz strategię odzyskiwania po awarii między regionami.
Omówienie kompromisów w rezerwowaniu pojemności w regionach alternatywnych.
Użyj narzędzi do routingu ruchu, takich jak Usługa Azure Traffic Manager.

lista kontrolna Virtual Machines

Przejrzyj sekcję Virtual Machines tego dokumentu.
Użyj Azure Backup, aby utworzyć spójne kopie zapasowe aplikacji w różnych regionach.

Lista kontrolna magazynu

Zapoznaj się z sekcją Magazyn tego dokumentu.
Nie wyłączaj replikacji geograficznej zasobów magazynu.
Omówienie alternatywnego regionu replikacji geograficznej w przypadku przejścia w tryb failover.
Tworzenie niestandardowych strategii tworzenia kopii zapasowych dla strategii trybu failover kontrolowanego przez użytkownika.

lista kontrolna SQL Database

Przejrzyj sekcję SQL Database tego dokumentu.
Użyj replikacji geograficznej lub geograficznej zgodnie z potrzebami.

SQL Server na liście kontrolnej Virtual Machines

Zapoznaj się z SQL Server w sekcji Virtual Machines tego dokumentu.
Użyj zawsze włączonych grup dostępności między regionami lub dublowania bazy danych.
Alternatywnie użyj kopii zapasowej i przywracania do magazynu obiektów blob.

Lista kontrolna usługi Service Bus

Zapoznaj się z sekcją usługi Service Bus tego dokumentu.
Skonfiguruj przestrzeń nazw usługi Service Bus w regionie alternatywnym.
Rozważ niestandardowe strategie replikacji dla komunikatów w różnych regionach.

lista kontrolna App Service

Przejrzyj sekcję App Service tego dokumentu.
Obsługa kopii zapasowych lokacji poza regionem podstawowym.
Jeśli awaria jest częściowa, spróbuj pobrać bieżącą witrynę za pomocą protokołu FTP.
Zaplanuj wdrożenie lokacji w nowej lub istniejącej lokacji w regionie alternatywnym.
Planowanie zmian konfiguracji zarówno dla rekordów CNAME aplikacji, jak i DNS.

Lista kontrolna usługi HDInsight

Zapoznaj się z sekcją tego dokumentu w usłudze HDInsight.
Utwórz nowy klaster Hadoop w regionie z replikowanymi danymi.

lista kontrolna SQL Reporting

Zapoznaj się z sekcją SQL Reporting tego dokumentu.
Obsługa wystąpienia alternatywnego SQL Reporting w innym regionie.
Zachowaj oddzielny plan replikacji obiektu docelowego do tego regionu.

Lista kontrolna usługi Media Services

Zapoznaj się z sekcją usługi Media Services tego dokumentu.
Utwórz konto usługi Media Services w regionie alternatywnym.
Zakoduj tę samą zawartość w obu regionach, aby obsługiwać przesyłanie strumieniowe w tryb failover.
Przesyłanie zadań kodowania do regionu alternatywnego, jeśli wystąpi przerwy w działaniu usługi.

lista kontrolna Virtual Network

Przejrzyj sekcję Virtual Network tego dokumentu.
Użyj wyeksportowanych ustawień sieci wirtualnej, aby ponownie utworzyć ją w innym regionie.