Przełączenie awaryjne i przełączenie powrotne
Usługa Azure Site Recovery zapewnia elastyczność przełączania się na platformę Azure w przypadku awarii oraz powrotu do maszyn lokalnych po zakończeniu awarii.
Teraz chcesz wykonać pełny tryb failover dla pozostałej części chronionego środowiska na platformie Azure. Po pomyślnym przeprowadzeniu ćwiczenia failover na pojedynczej testowej maszynie wirtualnej wykonujesz pełne przełączenie w tryb failover. Następnie wykonasz przywracanie po awarii systemu (failback) po pomyślnym zakończeniu przełączenia na awaryjny tryb pracy (failover).
W tej lekcji zapoznasz się z różnicami między trybem failover i powrotem po awarii. Dowiesz się również, jak automatycznie utworzyć politykę powrotu do normalnego działania po skonfigurowaniu zasad replikacji na platformie Azure.
Tryb failover i powrót po awarii
Przejście w tryb awaryjny (failover) to proces, który rozpoczyna się po podjęciu decyzji o uruchomieniu planu BCDR dla firmy. Tryb failover odbywa się, gdy bieżące środowisko na żywo chronione przy użyciu usługi Site Recovery jest przenoszone do środowiska repliki. To środowisko repliki docelowej zastępuje środowisko na żywo i staje się główną infrastrukturą.
Tryb powrotu po awarii jest odwrotnością trybu failover. Poprzednie środowisko na żywo (które jest teraz środowiskiem repliki, ponieważ miało miejsce przejście w tryb failover) przywraca oryginalną rolę i ponownie staje się środowiskiem na żywo. Po wystąpieniu przełączenia awaryjnego w pierwszym przypadku należy przeprowadzić fazę ponownej ochrony. W tej fazie przywracasz oryginalne środowisko do synchronizacji z nowym środowiskiem na żywo. Ten proces umożliwia przełączenie na tryb zapasowy i powrót do pierwotnego stanu bez utraty danych. Faza ponownego włączania ochrony może być długotrwałym procesem, ponieważ należy ustalić, że stare środowisko na żywo działa prawidłowo po awarii.
Cztery etapy działań w trybie awaryjnym i powrotu awaryjnego to:
- Przełączenie w tryb awaryjny na platformę Azure: Jeśli lokalizacja główna ulegnie awarii, zostanie podjęta decyzja o przełączeniu w tryb awaryjny na platformę Azure (lub lokalizację zapasową), co tworzy maszyny wirtualne z danych replikowanych z lokalizacji głównej.
- Ponowne włączanie ochrony maszyn wirtualnych platformy Azure: po przejściu w tryb failover należy ponownie włączyć ochronę maszyn wirtualnych platformy Azure, aby można było replikować zmiany z powrotem do środowiska lokalnego po wystąpieniu awarii. Maszyny wirtualne są wyłączone, aby zapewnić spójność danych.
- Przełączenie z powrotem do lokalnego: Gdy strona lokalna jest ponownie dostępna i działa, możliwe jest przełączenie z powrotem do tego środowiska. Następnie ponownie staje się środowiskiem produkcyjnym. Nie można wrócić do serwerów fizycznych. Wszystkie systemy muszą wrócić po awarii do maszyn wirtualnych.
- ponowne włączanie ochrony lokalnych maszyn wirtualnych: Ponowne włączanie ochrony lokalnych maszyn wirtualnych ma na celu rozpoczęcie replikacji do Azure po pomyślnym zakończeniu powrotu po awarii.
Zasady powrotu po awarii
Podczas tworzenia lokalnych zasad replikacji w celu skopiowania maszyn lokalnych na platformę Azure zostaną automatycznie utworzone skojarzone zasady powrotu po awarii. Zasady mają pewne stałe atrybuty, których nie można zmienić. Te atrybuty to:
- Można replikować tylko z powrotem do lokalnego serwera konfiguracji.
- Cel punktu odzyskiwania jest ustawiany na 15 minut.
- Czas przechowywania punktu odzyskiwania jest ustawiony na 24 godziny.
- Migawki spójne na poziomie aplikacji są ustawiane co godzinę.
Uruchomienie failbacku zatrzymuje maszyny wirtualne platformy Azure. Po zakończeniu replikacji uruchom lokalną maszynę wirtualną, aby przejąć obciążenia. Usługa jest zakłócana, dlatego zaplanuj powrót po awarii w czasie, który nie ma wpływu na Twoją firmę.
Plany ciągłości działania i odzyskiwania po awarii
Plany BCDR w usłudze Site Recovery umożliwiają dostosowanie i sekwencjonowanie trybu failover i powrotu po awarii maszyn wirtualnych oraz aplikacji uruchamianych na nich. Maszyny są grupowane razem, a akcje odzyskiwania można zautomatyzować przy użyciu skryptów podczas trybu awaryjnego lub powrotu do normalnego działania. Możesz również dodać więcej ręcznych kroków dla akcji, jeśli zajdzie taka potrzeba. Jeśli testujesz plan BCDR przed awarią, możesz być bardziej pewny pozytywnego wyniku. Aby osiągnąć cel czasu odzyskiwania firmy, musisz jak najszybciej ponownie uruchomić i wdrożyć infrastrukturę w lokalizacji zapasowej.
Elastyczne przełączenia awaryjne
Dzięki możliwości elastycznego przechodzenia w tryb failover usługa Site Recovery może uruchamiać tryb failover na żądanie w celach testowych. Izolowanie tych testów oznacza, że usługi na żywo nie są przerywane. Ta elastyczność umożliwia również uruchomienie trybu failover podczas planowanej awarii usługi na żywo. Awaria nie przerywa użytkownikom systemu, ponieważ są oni automatycznie przełączani na zreplikowane środowisko. Elastyczność działa również w drugą stronę. Powrót po awarii na żądanie może być częścią planowanego testu lub w ramach w pełni wywołanego scenariusza odzyskiwania po awarii.