Tworzenie kopii zapasowej i odzyskiwanie po awarii dla aplikacji platformy Azure

Odzyskiwanie po awarii to proces przywracania funkcjonalności aplikacji po katastrofalnej utracie.

Z góry potwierdzamy, że w chmurze zdarzają się błędy. Zamiast zapobiegać wszystkim awariom, dąży się do minimalizacji wpływu awarii pojedynczego składnika. Testowanie jest jednym ze sposobów zminimalizowania tych efektów. Zautomatyzuj testowanie aplikacji tam, gdzie to możliwe, ale musisz przygotować się na ich niepowodzenie. W przypadku awarii ważne staje się posiadanie strategii tworzenia kopii zapasowych i odzyskiwania.

Tolerancja na ograniczoną funkcjonalność podczas awarii to decyzja biznesowa, która różni się w zależności od aplikacji. Niektóre aplikacje mogą być niedostępne lub częściowo dostępne z ograniczoną funkcjonalnością lub opóźnione przetwarzanie przez pewien czas. W przypadku innych aplikacji wszelkie ograniczone funkcje są nieakceptowalne.

Kwestie kluczowe

  • Regularnie twórz i testuj plan odzyskiwania po awarii przy użyciu kluczowych scenariuszy awarii.
  • Zaprojektuj strategię odzyskiwania po awarii, aby uruchamiać większość aplikacji z ograniczoną funkcjonalnością.
  • Zaprojektuj strategię tworzenia kopii zapasowych dostosowaną do wymagań biznesowych i okoliczności aplikacji.
  • Automatyzowanie kroków i procesów trybu failover i powrotu po awarii.
  • Co najmniej raz pomyślnie przetestuj i zweryfikuj podejście do trybu failover i powrotu po awarii.

Plan odzyskiwania po awarii

Rozpocznij od utworzenia planu odzyskiwania. Plan jest uznawany za ukończony po pełnym przetestowaniu. Uwzględnij osoby, procesy i aplikacje potrzebne do przywrócenia funkcjonalności w ramach umowy dotyczącej poziomu usług (SLA) zdefiniowanej dla klientów.

Podczas tworzenia i testowania planu odzyskiwania po awarii należy wziąć pod uwagę następujące sugestie:

  • Uwzględnij proces kontaktowania się z pomocą techniczną i eskalacji problemów. Te informacje pomogą uniknąć długotrwałego przestoju podczas pracy nad procesem odzyskiwania po raz pierwszy.
  • Oceń znaczenie biznesowe awarii aplikacji.
  • Wybierz architekturę odzyskiwania między regionami dla aplikacji o znaczeniu krytycznym.
  • Zidentyfikuj określonego właściciela planu odzyskiwania po awarii, w tym automatyzację i testowanie.
  • Udokumentuj proces, zwłaszcza wszelkie kroki ręczne.
  • Zautomatyzuj proces tak bardzo, jak to możliwe.
  • Ustanów strategię tworzenia kopii zapasowych dla wszystkich danych referencyjnych i transakcyjnych oraz regularnie testuj przywracanie kopii zapasowych.
  • Skonfiguruj alerty dla stosu usług platformy Azure zużywanych przez aplikację.
  • Szkolenie pracowników operacyjnych w celu wykonania planu.
  • Regularnie przeprowadzaj symulacje awarii, aby zweryfikować i ulepszyć plan.

Jeśli używasz usługi Azure Site Recovery do replikowania maszyn wirtualnych, utwórz w pełni zautomatyzowany plan odzyskiwania, aby przetworzyć całą aplikację w tryb fail over.

Testowanie gotowości operacyjnej

Wykonaj test gotowości operacyjnej dla trybu failover do regionu pomocniczego i powrotu po awarii do regionu podstawowego. Wiele usług platformy Azure obsługuje ręczne przechodzenie w tryb failover lub testowe przechodzenie w tryb failover w ramach próbnego odzyskiwania po awarii. Zamiast tego możesz zasymulować przełamanie, usuwając usługi platformy Azure.

Automatyczne odpowiedzi operacyjne powinny być często testowane w ramach normalnego cyklu życia aplikacji, aby zapewnić efektywność operacyjną.

Testowanie trybu failover i powrotu po awarii

Przetestuj tryb failover i powrót po awarii, aby sprawdzić, czy usługi zależne od aplikacji wracają w zsynchronizowany sposób podczas odzyskiwania po awarii. Zmiany w systemach i operacjach mogą mieć wpływ na funkcje trybu failover i powrotu po awarii, ale wpływ może nie zostać wykryty do momentu awarii lub przeciążenia głównego systemu. Przetestuj możliwości trybu failover, zanim będą one wymagane do kompensowania problemu na żywo. Upewnij się również, że usługi zależne są w odpowiedniej kolejności w przypadku trybu failover i powrotu po awarii.

Jeśli używasz usługi Azure Site Recovery do replikowania maszyn wirtualnych, okresowo przeprowadzaj testy odzyskiwania po awarii, testując tryb failover w celu zweryfikowania strategii replikacji. Testowe działanie trybu failover nie ma wpływu na trwającą replikację maszyny wirtualnej ani na środowisko produkcyjne. Aby uzyskać więcej informacji, zobacz Run a disaster recovery drill to Azure (Uruchamianie przechodzenia do szczegółów odzyskiwania po awarii na platformie Azure).

Zależna usługa 3D

W przypadku każdej usługi zależnej należy zrozumieć implikacje przerw w działaniu usługi i sposób, w jaki aplikacja będzie odpowiadać. Wiele usług zawiera funkcje, które obsługują odporność i dostępność, dlatego niezależne ocenianie poszczególnych usług może poprawić plan odzyskiwania po awarii. Na przykład Azure Event Hubs trybie pracy w trybie pracy w pomocniczej przestrzeni nazw.

Network outage (Przesłoń sieć)

Gdy części sieci platformy Azure są niedostępne, dostęp do aplikacji lub danych może być niedostępny. W takiej sytuacji zalecamy zaprojektowanie strategii odzyskiwania po awarii w celu uruchamiania większości aplikacji o ograniczonej funkcjonalności.

Jeśli zmniejszenie funkcjonalności nie jest opcją, pozostałe opcje to przestój aplikacji lub trybu failover do alternatywnego regionu.

W scenariuszu z ograniczoną funkcjonalnością:

  • Jeśli twoja aplikacja nie może uzyskać dostępu do swoich danych z powodu 30-30-000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00
  • Dane można przechowywać w alternatywnej lokalizacji, dopóki łączność nie zostanie przywrócona.

Automatyzacja odzyskiwania

Kroki wymagane do odzyskania lub trybu failover aplikacji w regionie pomocniczym platformy Azure w sytuacjach awarii powinny zostać ujednolicene, najlepiej w zautomatyzowany sposób, aby zapewnić, że istnieją możliwości efektywnego reagowania na awarię w sposób, który ogranicza wpływ. Podobne ujednoznacznione kroki powinny również istnieć w celu przechwycenia procesu wymaganego do powrotu po awarii aplikacji do regionu podstawowego po rozwiązaniu problemu z wyzwoleniem trybu failover.

Podczas automatyzacji procedur trybu failover upewnij się, że narzędzia używane do organizowania trybu failover są również rozważane w strategii trybu failover. Na przykład w przypadku uruchomienia trybu failover z serwera Jenkins uruchomionego na maszynie wirtualnej wystąpią problemy, jeśli maszyna wirtualna jest częścią awarii. Azure DevOps Projekty są również w zakresie regionu.

Strategia tworzenia kopii zapasowych

Dostępnych jest wiele alternatywnych strategii wdrażania rozproszonych zasobów obliczeniowych w różnych regionach. Te strategie muszą 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 wdanie w przypadku awarii: w tym podejściu aplikacja jest ponownie wdowy w czasie awarii. Ponowne wdanie od podstaw jest odpowiednie dla aplikacji niekrytytycznych, które nie wymagają gwarantowanego czasu odzyskiwania.

  • Zapasowy (aktywny/pasywny): utwórz pomocniczą usługę hostowaną w regionie alternatywnym i wd wdrażaj role, aby zagwarantować minimalną pojemność. Jednak role nie odbierają ruchu produkcyjnego. To podejście jest przydatne w przypadku aplikacji, które nie zostały zaprojektowane do dystrybucji ruchu między regionami.

  • Zapasowy (aktywny/aktywny): aplikacja jest przeznaczona do odbierania obciążenia produkcyjnego w wielu regionach. Usługi w chmurze w każdym regionie mogą być skonfigurowane do większej pojemności niż jest to wymagane do celów odzyskiwania po awarii. Zamiast tego usługi w chmurze mogą w razie potrzeby skalować w poziomie w momencie awarii i trybu failover. Takie podejście wymaga dużych inwestycji w projektowanie aplikacji, ale ma znaczące korzyści. Obejmują one niski i gwarantowany czas odzyskiwania, ciągłe testowanie wszystkich lokalizacji odzyskiwania oraz wydajne wykorzystanie pojemności.

Planowanie awarii regionalnych

Platforma Azure jest podzielona fizycznie i logicznie na jednostki nazywane regionami. Region składa się z co najmniej jednego centrum danych w pobliżu. 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 przypadkach obiekty w całej strefie dostępności lub regionie mogą stać się niedostępne, na przykład z powodu awarii sieci. Lub obiekty mogą zostać całkowicie utracone, na przykład z powodu klęski żywiołowej. Platforma Azure oferuje możliwości tworzenia aplikacji rozproszonych między strefami i regionami. Taki rozkład pomaga zminimalizować prawdopodobieństwo, że awaria w jednej strefie lub regionie może wpłynąć na inne strefy lub regiony.

Następny krok

Wstecz do głównego artykułu: Testowanie