Replikacja między regionami na platformie Azure: ciągłość działania i odzyskiwanie po awarii
Wiele organizacji wymaga zarówno wysokiej dostępności zapewnianej przez strefy dostępności, które są również obsługiwane z ochroną przed zjawiskami na dużą skalę i katastrofami regionalnymi. Regiony platformy Azure są przeznaczone do zapewniania ochrony przed lokalnymi awariami ze strefami dostępności. Jednak mogą również zapewnić ochronę przed awariami regionalnymi lub dużymi lokalizacjami geograficznymi dzięki odzyskiwaniu po awarii przez użycie innego regionu, który korzysta z replikacji między regionami.
Replikacja między regionami
Aby zapewnić obsługę klientów na całym świecie, platforma Azure utrzymuje wiele lokalizacji geograficznych. Te odrębne rozgraniczenia definiują granicę odzyskiwania po awarii i przechowywania danych w jednym lub wielu regionach świadczenia usługi Azure.
Replikacja między regionami jest jednym z kilku ważnych filarów strategii ciągłości działania i odzyskiwania po awarii na platformie Azure. Replikacja między regionami jest oparta na synchronicznej replikacji aplikacji i danych, które istnieją przy użyciu stref dostępności w regionie podstawowym platformy Azure w celu zapewnienia wysokiej dostępności. Replikacja między regionami asynchronicznie replikuje te same aplikacje i dane w innych regionach świadczenia usługi Azure na potrzeby ochrony odzyskiwania po awarii.
Niektóre usługi platformy Azure korzystają z replikacji między regionami w celu zapewnienia ciągłości działania i ochrony przed utratą danych. Platforma Azure udostępnia kilka rozwiązań magazynu , które korzystają z replikacji między regionami w celu zapewnienia dostępności danych. Na przykład magazyn geograficznie nadmiarowy platformy Azure (GRS) automatycznie replikuje dane do regionu pomocniczego. Takie podejście zapewnia trwałość danych, nawet jeśli region podstawowy nie jest możliwy do odzyskania.
Nie wszystkie usługi platformy Azure automatycznie replikują dane lub automatycznie wracają z regionu, który zakończył się niepowodzeniem, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W tych scenariuszach klient musi skonfigurować odzyskiwanie i replikację. Te przykłady to ilustracje modelu wspólnej odpowiedzialności. Jest to podstawowy filar strategii odzyskiwania po awarii. Aby uzyskać więcej informacji na temat modelu wspólnej odpowiedzialności oraz dowiedzieć się więcej o ciągłości działania i odzyskiwaniu po awarii na platformie Azure, zobacz Business continuity management in Azure (Zarządzanie ciągłością działalności biznesowej na platformie Azure).
Wspólna odpowiedzialność staje się sednem strategicznego podejmowania decyzji, jeśli chodzi o odzyskiwanie po awarii. Platforma Azure nie wymaga używania replikacji między regionami i można używać usług do tworzenia odporności bez replikacji krzyżowej do innego włączonego regionu. Zdecydowanie zalecamy jednak skonfigurowanie podstawowych usług w różnych regionach w celu skorzystania z izolacji i zwiększenia dostępności.
W przypadku aplikacji, które obsługują wiele aktywnych regionów, zalecamy użycie dostępnych wielu regionów z obsługą. Takie rozwiązanie zapewnia optymalną dostępność aplikacji i zminimalizowany czas odzyskiwania, jeśli zdarzenie wpływa na dostępność. Jeśli to możliwe, zaprojektuj aplikację tak, aby zapewnić maksymalną odporność i łatwość odzyskiwania po awarii.
Zalety replikacji między regionami
Tworzenie architektury replikacji między regionami dla usług i danych można zdecydować na podstawie poszczególnych usług. Musisz podjąć podejście do analizy kosztów i korzyści na podstawie strategicznych i biznesowych wymagań organizacji. Podstawowe i tętniące korzyści wynikające z replikacji między regionami są złożone, obszerne i zasługują na opracowanie. Te korzyści obejmują między innymi:
- Sekwencja odzyskiwania regionu: jeśli wystąpi awaria w całej lokalizacji geograficznej, odzyskiwanie jednego regionu jest priorytetem poza każdym włączonym zestawem regionów. Aplikacje wdrożone w zestawach regionów z włączoną obsługą mają gwarancję, że jeden z regionów ma priorytet na potrzeby odzyskiwania. Jeśli aplikacja jest wdrażana w różnych regionach, z których żadna nie jest włączona na potrzeby replikacji między regionami, odzyskiwanie może być opóźnione.
- Aktualizacja sekwencyjna: Planowane aktualizacje systemu platformy Azure dla regionów z włączonymi obszarami są zachwiane chronologicznie, aby zminimalizować przestoje, wpływ błędów i wszelkie błędy logiczne w rzadkim przypadku błędnej aktualizacji.
- Izolacja fizyczna: platforma Azure dąży do zapewnienia minimalnej odległości 300 mil (483 kilometrów) między centrami danych w regionach z obsługą, chociaż nie jest to możliwe we wszystkich lokalizacjach geograficznych. Separacja centrów danych zmniejsza prawdopodobieństwo, że klęski żywiołowe, niepokoje społeczne, przerwy w zasilaniu lub awarie sieci fizycznej mogą mieć wpływ na wiele regionów. Izolacja podlega ograniczeniom w obszarze geograficznym, takim jak rozmiar geograficzny, dostępność infrastruktury zasilania lub sieci oraz przepisy.
- Miejsce przechowywania danych: regiony znajdują się w tej samej lokalizacji geograficznej co ich włączony zestaw (z wyjątkiem Brazylii Południowej i Singapuru), aby spełnić wymagania dotyczące przechowywania danych w celach podatkowych i egzekwowania prawa.
Chociaż nie można utworzyć własnych par regionalnych, możesz jednak utworzyć własne rozwiązanie odzyskiwania po awarii, tworząc usługi w dowolnej liczbie regionów, a następnie używając usług platformy Azure do ich parowania. Na przykład możesz użyć usług platformy Azure, takich jak AzCopy , aby zaplanować tworzenie kopii zapasowych danych na koncie usługi Azure Storage w innym regionie. Korzystając z usług Azure DNS i Azure Traffic Manager, można zaprojektować odporną architekturę dla aplikacji, które przetrwają utratę regionu podstawowego.
Platforma Azure kontroluje planowaną konserwację i priorytetyzację odzyskiwania dla par regionalnych. Niektóre usługi platformy Azure domyślnie korzystają z par regionalnych, takich jak magazyn nadmiarowy platformy Azure.
Korzystanie z usług w ramach par regionalnych nie jest ograniczone. Mimo że usługa platformy Azure może polegać na określonej parze regionalnej, możesz hostować inne usługi w dowolnym regionie, który spełnia Twoje potrzeby biznesowe. Na przykład rozwiązanie magazynu azure GRS może sparować dane w Kanadzie Środkowej z elementem równorzędnym w Kanadzie Wschodniej przy użyciu zasobów obliczeniowych platformy Azure znajdujących się w regionie Wschodnie stany USA.
Pary replikacji między regionami platformy Azure dla wszystkich lokalizacji geograficznych
Regiony są sparowane dla replikacji między regionami w oparciu o bliskość i inne czynniki.
Ważne
Aby dowiedzieć się więcej na temat architektury regionu, skontaktuj się z przedstawicielem ds. sprzedaży lub klienta firmy Microsoft.
Pary regionalne platformy Azure
| Lokalizacja geograficzna | Para regionalna A | Para regionalna B |
|---|---|---|
| Asia-Pacific | Azja Wschodnia (Hongkong) | Azja Południowo-Wschodnia (Singapur) |
| Australia | Australia Wschodnia | Australia Południowo-Wschodnia |
| Australia | Australia Środkowa | Australia Środkowa 2* |
| Brazylia | Brazylia Południowa | South Central US |
| Brazylia | Brazylia Południowo-Wschodnia* | Brazylia Południowa |
| Kanada | Kanada Środkowa | Kanada Wschodnia |
| Chiny | Chiny Północne | Chiny Wschodnie |
| Chiny | Chiny Północne 2 | Chiny Wschodnie 2 |
| Chiny | Chiny Północne 3 | Chiny Wschodnie 3* |
| Europa | Europa Północna (Irlandia) | Europa Zachodnia (Holandia) |
| Francja | Francja Środkowa | Francja Południowa* |
| Niemcy | Niemcy Środkowo-Zachodnie | Niemcy Północne* |
| Indie | Indie Środkowe | Indie Południowe |
| Indie | Indie Zachodnie | Indie Południowe |
| Japonia | Japonia Wschodnia | Japonia Zachodnia |
| Korea | Korea Środkowa | Korea Południowa* |
| Ameryka Północna | East US | Zachodnie stany USA |
| Ameryka Północna | Wschodnie stany USA 2 | Central US |
| Ameryka Północna | Północno-środkowe stany USA | South Central US |
| Ameryka Północna | Zachodnie stany USA 2 | Zachodnio-środkowe stany USA |
| Ameryka Północna | Zachodnie stany USA 3 | East US |
| Norwegia | Norwegia Wschodnia | Norwegia Zachodnia* |
| Republika Południowej Afryki | Północna Republika Południowej Afryki | Republika Południowej Afryki Zachodniej* |
| Szwecja | Szwecja Środkowa | Szwecja Południowa* |
| Szwajcaria | Szwajcaria Północna | Szwajcaria Zachodnia* |
| Zjednoczone Królestwo | Zachodnie Zjednoczone Królestwo | Południowe Zjednoczone Królestwo |
| Zjednoczone Emiraty Arabskie | Północne Zjednoczone Emiraty Arabskie | Środkowe Zjednoczone Emiraty |
| US Department of Defense | US DoD East* | US DoD Central* |
| US Government | US Gov Arizona* | US Gov Texas* |
| US Government | US Gov Wirginia* | US Gov Texas* |
(*) Niektóre regiony są ograniczone do obsługi określonych scenariuszy klientów, takich jak odzyskiwanie po awarii w kraju. Te regiony są dostępne tylko na żądanie przez utworzenie nowego wniosku o pomoc techniczną.
Ważne
- Indie Zachodnie są sparowane tylko w jednym kierunku. Region pomocniczy Indii Zachodnich to Indie Południowe, ale region pomocniczy Indii Południowych to Indie Środkowe.
- Brazylia Południowa jest wyjątkowa, ponieważ jest sparowana z regionem poza jego geografią. Region pomocniczy Brazylii Południowej to Południowo-środkowe stany USA. Region pomocniczy południowo-środkowych stanów USA nie jest Brazylią Południową.
Regiony ze strefami dostępności i bez pary regionów
Platforma Azure nadal rozwija się globalnie wraz z Katarem jako pierwszy region bez pary regionalnej i zapewnia wysoką dostępność dzięki wykorzystaniu stref dostępności oraz magazynu lokalnie nadmiarowego lub strefowo nadmiarowego (LRS/ZRS). Regiony bez pary nie będą miały magazynu geograficznie nadmiarowego (GRS). Takie regiony są zgodne z wytycznymi dotyczącymi rezydencji danych , co pozwala na przechowywanie danych w tym samym regionie. Klienci są odpowiedzialni za odporność danych na podstawie potrzeb celu punktu odzyskiwania lub celu czasu odzyskiwania (RTO/RPO) i mogą przenosić, kopiować lub uzyskiwać dostęp do danych z dowolnej lokalizacji globalnie. W rzadkich przypadkach, gdy cały region świadczenia usługi Azure jest niedostępny, klienci będą musieli zaplanować odzyskiwanie po awarii między regionami zgodnie ze wskazówkami dotyczącymi usług platformy Azure, które obsługują wysoką dostępność i odporność platformy Azure — ciągłość działania i odzyskiwanie po awarii