Ciągłość działania i odzyskiwanie po awarii

Obciążenia organizacji i aplikacji dla przedsiębiorstw mają wymagania celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO). Skuteczny projekt ciągłości działania i odzyskiwania po awarii (BCDR) zapewnia możliwości na poziomie platformy spełniające te wymagania. Aby zaprojektować możliwości BCDR, przechwyć wymagania odzyskiwania po awarii (DR, platformy disaster recovery).

Uwagi dotyczące projektowania

Podczas projektowania trasy BCDR dla obciążeń aplikacji należy wziąć pod uwagę następujące czynniki:

• Wymagania dotyczące dostępności aplikacji i danych:

  • Wymagania dotyczące celu odzyskiwania i celu punktu odzyskiwania dla każdego obciążenia.
  • Obsługa wzorców dostępności aktywne-aktywne i aktywne-pasywne.

• BCDR jako usługa dla usług typu "platforma jako usługa" (PaaS):

  • Natywna obsługa funkcji odzyskiwania po awarii i wysokiej dostępności (HA).
  • Funkcje replikacji geograficznej i odzyskiwania po awarii dla usług PaaS.

• Obsługa wdrożeń w wielu regionach na potrzeby trybu failover z sąsiedztwem składników w celu zapewnienia wydajności.

• Operacje aplikacji z ograniczoną funkcjonalnością lub obniżoną wydajnością podczas awarii.

• Użyteczność obciążenia dla zestawów dostępności lub Strefy dostępności:

  • Udostępnianie danych i zależności między strefami.
  • Strefy dostępności w porównaniu z zestawami dostępności, które mają wpływ na domeny aktualizacji.
  • Procent obciążeń, które mogą być jednocześnie objęte konserwacją.
  • Strefy dostępności obsługę określonych jednostek SKU (SKU) określonych maszyn wirtualnych. Na przykład usługa Azure Ultra Disk Storage wymaga użycia Strefy dostępności.

• Spójne kopie zapasowe aplikacji i danych:

  • Migawki maszyn wirtualnych.
  • Magazyny usługi Azure Backup Recovery Services.
  • Limity subskrypcji ograniczające liczbę magazynów usługi Recovery Services i rozmiar każdego magazynu.

• Łączność sieciowa w przypadku przejścia w tryb failover:

  • Planowanie pojemności przepustowości dla usługi Azure ExpressRoute.
  • Routing ruchu podczas awarii regionalnej, strefowej lub sieciowej.

• Planowane i nieplanowane przejścia w tryb failover:

  • Wymagania dotyczące spójności adresów IP oraz potencjalna potrzeba utrzymania adresów IP po przejściu w tryb failover i powrotu po awarii.
  • Obsługa możliwości metodyki DevOps inżynierii.
  • Odzyskiwanie po awarii usługi Azure Key Vault dla kluczy aplikacji, certyfikatów i wpisów tajnych.

• Miejsce przechowywania danych:

  • Zapoznaj się ze wskazówkami dotyczącymi przechowywania danych w kraju/regionie, które określają, czy dane powinny być przechowywane w granicach kraju lub regionu. Te wskazówki mają wpływ na projekt replikacji między regionami.
  • Regiony platformy Azure, które znajdują się w tej samej lokalizacji geograficznej, co ich włączony zestaw, mogą pomóc w replikacji między regionami w celu spełnienia wymagań dotyczących rezydencji danych, takich jak wymagania dotyczące podatku i egzekwowania prawa. Aby uzyskać więcej informacji, zobacz Replikacja między regionami platformy Azure.

Zalecenia dotyczące projektowania

Następujące rozwiązania projektowe obsługują trasę BCDR dla obciążeń aplikacji:

• Zastosowanie usługi Azure Site Recovery dla scenariuszy odzyskiwania po awarii między maszynami wirtualnymi platformy Azure.

  Usługa Site Recovery używa replikacji i automatyzacji odzyskiwania w czasie rzeczywistym do replikowania obciążeń między regionami. Wbudowane możliwości platformy dla obciążeń maszyn wirtualnych spełniają wymagania dotyczące niskiego celu punktu odzyskiwania i celu odzyskiwania. Usługa Site Recovery umożliwia uruchamianie próbnych odzyskiwania bez wpływu na obciążenia produkcyjne. Możesz również użyć usługi Azure Policy, aby włączyć replikację i przeprowadzić inspekcję ochrony maszyn wirtualnych.

• Korzystanie z natywnych funkcji odzyskiwania po awarii paaS.

  Wbudowane funkcje PaaS upraszczają zarówno projektowanie, jak i automatyzację wdrażania na potrzeby replikacji i trybu failover w architekturach obciążeń. Organizacje definiujące standardy usług mogą również przeprowadzać inspekcję i wymuszać konfigurację usługi za pomocą usługi Azure Policy.

• Korzystanie z funkcji tworzenia kopii zapasowych natywnych dla platformy Azure.

  Funkcje tworzenia kopii zapasowych natywnych dla usługi Azure Backup i PaaS usuwają potrzebę tworzenia kopii zapasowych oprogramowania i infrastruktury kopii zapasowych innych firm. Podobnie jak w przypadku innych funkcji natywnych, można ustawiać, przeprowadzać inspekcję i wymuszać konfiguracje kopii zapasowych za pomocą usługi Azure Policy, aby zapewnić zgodność z wymaganiami organizacji.

• Użyj wielu regionów i lokalizacji komunikacji równorzędnej na potrzeby łączności usługi ExpressRoute.

  Nadmiarowa architektura sieci hybrydowej może pomóc zapewnić nieprzerwaną łączność między lokalizacjami, jeśli awaria wpłynie na region platformy Azure lub lokalizację dostawcy komunikacji równorzędnej.

• Unikaj używania nakładających się zakresów adresów IP w sieciach produkcyjnych i odzyskiwania po awarii.

  Sieci produkcyjne i odzyskiwania po awarii, które nakładają się adresy IP, wymagają procesu trybu failover, który może komplikować i opóźniać tryb failover aplikacji. Jeśli to możliwe, zaplanuj architekturę sieci BCDR, która zapewnia współbieżną łączność ze wszystkimi lokacjami.