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

Platforma Azure jest podzielona fizycznie i logicznie na jednostki nazywane regionami. Region składa się z co najmniej jednego centrum 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ęski żywiołowej. Platforma Azure ma możliwości tworzenia aplikacji dystrybuowanych 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 wolnych wystąpień roli do wcześniejszego wdrożenia na potrzeby odzyskiwania po awarii jest ważnym aspektem planowania pojemności. Posiadanie wdrożenia pomocniczego o pełnej skali gwarantuje, że pojemność jest już dostępna w razie potrzeby; jednak skutecznie podwaja to koszt. Typowym wzorcem jest posiadanie małego, pomocniczego wdrożenia na tyle duże, aby uruchamiać usługi krytyczne. To małe wdrożenie pomocnicze jest dobrym pomysłem, zarówno do zarezerwowania 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 ruchem między regionami, wymaga rozwiązania 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

Dostępnych jest wiele alternatywnych strategii 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 ponownie wdrażana od podstaw w momencie awarii. Jest to odpowiednie dla aplikacji niekrytycznych, które nie wymagają gwarantowanego czasu odzyskiwania.

• Ciepły zapasowy (aktywny/pasywny): pomocnicza usługa hostowana jest tworzona w regionie alternatywnym, a role są wdrażane w celu zagwarantowania minimalnej pojemności, jednak role nie otrzymują 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 w celach odzyskiwania po awarii. Alternatywnie usługi w chmurze mogą być skalowane w poziomie w razie awarii i przejścia w tryb failover. Takie podejście wymaga znacznych inwestycji w projektowanie aplikacji, ale ma znaczne korzyści. Obejmują one niski i gwarantowany czas odzyskiwania, ciągłe testowanie wszystkich lokalizacji odzyskiwania i wydajne wykorzystanie pojemności.

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

Maszyny wirtualne

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

• Usługa Azure Backup umożliwia tworzenie kopii zapasowych obejmujących wiele regionów, które są spójne z aplikacjami. Usługa 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 podczas tworzenia. Replikacja magazynu kopii zapasowych musi być skonfigurowana w momencie tworzenia. Nie można go ustawić później. Jeśli region zostanie utracony, firma Microsoft udostępnia klientom kopie zapasowe. Klienci mogą 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ć wdrażana ponownie po awarii. Jednak może to być problem, jeśli używasz metody Warm Spare w celu zarezerwowania pojemności. Aby zaimplementować to prawidłowo, musisz mieć wdrożony prawidłowy dysk systemu operacyjnego w lokalizacjach podstawowych 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ć dostępna 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ą tę samą charakterystykę replikacji geograficznej. Jeśli usługa Azure Backup nie 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 geograficznie, ale nie są spójne na różnych dyskach. Może to spowodować problemy w niektórych przypadkach (na przykład w przypadku usuwania dysku).

• Usługa Azure Site Recovery umożliwia replikowanie aplikacji w różnych regionach. W 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 działające na maszynach fizycznych i wirtualnych z lokacji głównej (lokalnej lub na platformie Azure) do lokalizacji dodatkowej (na platformie Azure). W przypadku wystąpienia awarii w lokacji głównej klienta można wyzwolić tryb failover, aby szybko przywró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 z migawkami spójnymi 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 utrzymywanie 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 usługi 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 maszyn wirtualnych 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 tryb failover jest ograniczony do poważnych awarii, w których oryginalna lokalizacja podstawowa jest uważana 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.

W przypadku przejścia w tryb failover geograficznego nie będzie można zmienić sposobu uzyskiwania dostępu do konta (adres URL i klucz konta nie zostaną zmienione). Konto magazynu będzie jednak znajdować się w innym regionie po przejściu w tryb failover. Może to mieć wpływ na aplikacje, które wymagają 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 może być przekonujące z powodów tymczasowego przenoszenia ruchu do regionu trybu failover. Może to mieć wpływ na ogólną strategię odzyskiwania po awarii.

Oprócz automatycznego trybu failover zapewnianego przez magazyn GRS platforma Azure wprowadziła usługę, która zapewnia dostęp do odczytu do kopii danych w dodatkowej lokalizacji magazynu. Jest to nazywane magazynem geograficznie nadmiarowym dostępnym 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 jest naliczane po obniżonej cenie w porównaniu z magazynem GRS.

Określanie, czy nastąpiło przejście w tryb failover geograficznie

Jeśli nastąpi przejście w tryb failover geograficznie, zostanie on opublikowany na pulpicie nawigacyjnym usługi Azure Service Health. Aplikacje mogą jednak implementować zautomatyzowane metody wykrywania tego, monitorując region geograficzny dla 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.

baza danych

SQL Database

Usługa Azure SQL Database udostępnia dwa typy odzyskiwania: przywracanie geograficzne i aktywną replikację geograficzną.

Przywracanie geograficzne

Przywracanie geograficzne jest również dostępne w bazach danych w warstwie Podstawowa, Standardowa i Premium. Udostępnia 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. Przywraca ona z kopii zapasowej replikowanej geograficznie i dlatego jest odporna na awarie magazynu w regionie podstawowym. Aby uzyskać więcej informacji, zobacz Przywracanie bazy danych Azure SQL Database lub przechodzenie w tryb failover do pomocniczej bazy danych.

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 odzyskiwania niż przywracanie geograficzne może oferować. Przy użyciu aktywnej replikacji geograficznej można utworzyć maksymalnie cztery możliwe do odczytu sekundy na serwerach w różnych regionach. Możesz zainicjować przejście w tryb failover do dowolnego z drugiego zestawu danych. 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 usługi Azure SQL Database i inicjowanie trybu failover. Zobacz Projektowanie globalnie dostępnych usług przy użyciu usługi Azure SQL Database i Zarządzanie uaktualnieniami stopniowego aplikacji w chmurze przy użyciu aktywnej replikacji geograficznej usługi SQL Database, aby uzyskać szczegółowe informacje na temat projektowania i implementowania uaktualnień aplikacji i aplikacji bez przestoju.

Program SQL Server na maszynach wirtualnych platformy Azure

Dostępne są różne opcje odzyskiwania i wysokiej dostępności dla programu SQL Server 2012 (i nowszych) działających w usłudze Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Wysoka dostępność i odzyskiwanie po awarii dla programu 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ć tak samo ograniczona i wymagałaby tymczasowej migracji usługi do alternatywnego regionu świadczenia usługi platformy Azure.

Service Bus

Usługa Azure Service Bus używa unikatowej przestrzeni nazw, która nie obejmuje regionów świadczenia usługi 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 usługi aplikacja systemu Azure, 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 przy użyciu 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 usłudze Azure Blob Storage. Usługa HDInsight wymaga, aby zadania mapreduce przetwarzania klastra Usługi 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.

Raportowanie SQL

W tej chwili odzyskiwanie po utracie regionu platformy Azure wymaga wielu wystąpień raportowania SQL w różnych regionach świadczenia usługi Azure. Te wystąpienia raportowania SQL 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 odzyskiwania do kodowania i przesyłania strumieniowego. Zazwyczaj przesyłanie strumieniowe jest bardziej krytyczne podczas awarii regionalnej. Aby to przygotować, 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 regionie podstawowym platformy 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 to sposób generowania tego samego środowiska za każdym razem i można go wdrożyć w nowym regionie.

Listy kontrolne dotyczące odzyskiwania po awarii

Lista kontrolna usług Cloud Services

1. Zapoznaj się z sekcją Cloud Services tego dokumentu.
2. Utwórz strategię odzyskiwania po awarii między regionami.
3. Omówienie kompromisów w rezerwowaniu pojemności w regionach alternatywnych.
4. Użyj narzędzi do routingu ruchu, takich jak usługa Azure Traffic Manager.

Lista kontrolna maszyn wirtualnych

1. Zapoznaj się z sekcją Maszyny wirtualne w tym dokumencie.
2. Usługa Azure Backup umożliwia tworzenie kopii zapasowych spójnych na poziomie aplikacji w różnych regionach.

Lista kontrolna magazynu

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

Lista kontrolna usługi SQL Database

1. Zapoznaj się z sekcją usługi SQL Database tego dokumentu.
2. W razie potrzeby należy użyć funkcji przywracania geograficznego lub replikacji geograficznej.

Lista kontrolna programu SQL Server na maszynach wirtualnych

1. Zapoznaj się z sekcją programu SQL Server na maszynach wirtualnych tego dokumentu.
2. Użyj zawsze włączonych grup dostępności między regionami lub dublowania bazy danych.
3. Alternatywnie użyj kopii zapasowej i przywracania do magazynu obiektów blob.

Lista kontrolna usługi Service Bus

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

Lista kontrolna usługi App Service

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

Lista kontrolna usługi HDInsight

1. Zapoznaj się z sekcją tego dokumentu dotyczącą usługi HDInsight.
2. Utwórz nowy klaster Hadoop w regionie z replikowanymi danymi.

Lista kontrolna raportowania SQL

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

Lista kontrolna usługi Media Services

1. Przejrzyj sekcję usługi Media Services tego dokumentu.
2. Utwórz konto usługi Media Services w alternatywnym regionie.
3. Zakoduj tę samą zawartość w obu regionach, aby obsługiwać przesyłanie strumieniowe w tryb failover.
4. Przesyłanie zadań kodowania do regionu alternatywnego w przypadku wystąpienia przerw w działaniu usługi.

Lista kontrolna sieci wirtualnej

1. Zapoznaj się z sekcją Sieć wirtualna tego dokumentu.
2. Użyj wyeksportowanych ustawień sieci wirtualnej, aby ponownie utworzyć je w innym regionie.