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

Obciążenia robocze dotyczące aplikacji organizacyjnych i przedsiębiorstw mają wymagania co do wskaźników RTO (Recovery Time Objective) i RPO (Recovery Point Objective). 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, zbierz wymagania dotyczące odzyskiwania po awarii na platformie.

Uwagi dotyczące projektowania

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

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

  • Wymagania RTO i RPO 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):

  • Natywne wsparcie funkcji disaster recovery (DR) i wysokiej dostępności (HA).
  • Funkcje replikacji geograficznej i odzyskiwania danych po awarii dla usług PaaS.

• Obsługa wdrożeń w wielu regionach w celu zapewnienia przełączania awaryjnego, z bliskością składników dla poprawy 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 wpływają na domeny aktualizacji.
  • Procent obciążeń, które mogą być jednocześnie objęte konserwacją.
  • Strefy dostępności obsługują określone jednostki SKU 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.
  • Skarbce usługi Azure Backup Recovery Services.
  • Limity subskrypcji ograniczające liczbę skarbców usług Recovery Services i rozmiar każdego skarbca.

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

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

• Planowane i nieplanowane przejścia w tryb awaryjny.

  • 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.
  • Utrzymywanie możliwości DevOps w inżynierii.
  • Azure Key Vault DR dla kluczy aplikacji, certyfikatów i sekretów.

• 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 na platformie Azure.

Zalecenia dotyczące projektowania

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

• Użyj Azure Site Recovery do scenariuszy odzyskiwania po awarii maszyn wirtualnych w środowisku 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 RPO (celu punktu odzyskiwania) i RTO (czasu odzyskiwania). Usługa Site Recovery umożliwia przeprowadzanie symulacji 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.

• Użyj natywnych funkcji DR PaaS.

  Wbudowane funkcje PaaS upraszczają zarówno projektowanie, jak i automatyzację wdrażania dla replikacji i awaryjnego przełączania w architekturach rozwiązań obciążeniowych. 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 wymiany ruchu 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 działających na wypadek awarii.

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