Testowanie i przeprowadzanie przełączenia awaryjnego

Plan odzyskiwania po awarii, który nigdy nie był testowany, jest tylko hipotezą. Funkcja testowego przełączania pozwala sprawdzić, czy maszyny wirtualne uruchamiają się prawidłowo, aplikacje startują, a łączność sieciowa działa w regionie docelowym — bez zakłócania środowiska źródłowego i przerywania trwającej replikacji. Wiele organizacji odkrywa luki w swoich planach DR dopiero podczas rzeczywistej awarii, czyli dokładnie wtedy, gdy niesprawny plan powoduje największe szkody. Regularne testowe przełączenia są wymagane w ramach zgodności z większością norm i regulacji.

ASR obsługuje trzy typy działań związanych z przełączaniem. Testowe przełączanie tworzy kopie przełączanych maszyn wirtualnych w odizolowanej sieci (należy określić docelową sieć VNet), nie wpływając na replikację ani środowisko źródłowe. Planowane przełączanie służy do zaplanowanych migracji lub prac konserwacyjnych — najpierw synchronizuje pozostałe zmiany, a następnie wyłącza źródło przed wykonaniem przełączenia. Nieplanowane przełączanie (stosowane podczas rzeczywistej awarii) następuje natychmiast z użyciem najnowszego punktu odzyskiwania, bez oczekiwania na końcową synchronizację.

Aby wykonać testowe przełączanie w portalu, należy wybrać chroniony element, kliknąć Test Failover, wybrać punkt odzyskiwania (najnowszy spójny awaryjnie, najnowszy spójny aplikacyjnie lub konkretny punkt w czasie), a następnie wybrać docelową sieć wirtualną (zazwyczaj dedykowaną, odizolowaną sieć VNet do testów). ASR uruchamia maszynę wirtualną w regionie docelowym przy użyciu dysków repliki. Testowa maszyna wirtualna jest wyświetlana obok repliki, ale jest całkowicie niezależna — środowisko produkcyjne pozostaje niezmienione. Po zakończeniu testów należy kliknąć Cleanup test failover, aby usunąć testowe maszyny wirtualne.

Podczas przełączania wybierają Państwo punkt odzyskiwania z okresu przechowywania ASR. Dostępne są następujące opcje: Latest (lowest RPO) — najbardziej aktualny punkt odzyskiwania spójny awaryjnie, minimalizujący utratę danych. Latest processed — ostatnio przetworzony punkt, który może być opóźniony o kilka minut. Latest app-consistent — najnowszy punkt odzyskiwania spójny aplikacyjnie; może być starszy, ale gwarantuje poprawne odzyskanie aplikacji. Custom — konkretny starszy punkt odzyskiwania, umożliwiający przywrócenie znanego, prawidłowego stanu sprzed wystąpienia incydentu.

Plan odzyskiwania grupuje wiele chronionych maszyn wirtualnych oraz określa kolejność i czas ich przełączania. Można wskazać, które maszyny wirtualne mają uruchamiać się jako pierwsze (np. serwery baz danych przed serwerami aplikacji), dodać bramki ręcznego zatwierdzania w celu wstrzymania przełączania na potrzeby weryfikacji przez człowieka oraz wstawić runbooki Azure Automation uruchamiające skrypty przed przełączeniem i po nim (np. aktualizujące rekordy DNS, konfigurujące moduły równoważenia obciążenia lub wysyłające powiadomienia). Plany odzyskiwania można testować niezależnie za pomocą testowego przełączania.

Testowe przełączanie umożliwia zmierzenie rzeczywistego RTO (Recovery Time Objective). Należy uruchomić stoper w chwili rozpoczęcia przełączania i zatrzymać go, gdy aplikacja będzie w pełni funkcjonalna i dostępna dla użytkowników. Typowe przełączanie Azure-to-Azure pojedynczej maszyny wirtualnej trwa 15–30 minut, jednak aplikacje wielowarstwowe z zależnościami mogą wymagać więcej czasu. Należy udokumentować wszystkie kroki, które nieoczekiwanie wydłużają ten czas (np. propagację DNS lub rozgrzewanie aplikacji), i rozwiązać związane z nimi problemy przed kolejnym testem.

Po planowanym przełączeniu (np. podczas migracji do nowego regionu) należy uruchomić polecenie Commit, aby sfinalizować przełączenie. Zatwierdzenie zatrzymuje replikację ze źródła i oznacza docelowe maszyny wirtualne jako nowe podstawowe. Po zatwierdzeniu można włączyć funkcję re-protection, aby odwrócić kierunek replikacji i uczynić pierwotny region źródłowy nowym celem DR. Umożliwia to powrót do pierwotnego regionu po rozwiązaniu problemu.

Failback to proces przenoszenia obciążeń z powrotem do pierwotnego regionu po awarii lub planowanej migracji. Obejmuje on następujące kroki: ponowne objęcie ochroną przełączonych maszyn wirtualnych (odwrócenie replikacji, tak aby dane były replikowane z nowego środowiska podstawowego z powrotem do pierwotnego regionu), oczekiwanie na zakończenie początkowej synchronizacji, a następnie wykonanie planowanego przełączenia do pierwotnego regionu. Failback wymaga, aby pierwotna infrastruktura źródłowa nadal istniała — jeśli została zniszczona, przed powrotem może być konieczne odtworzenie strefy bazowej.

Po testowym przełączeniu należy w portalu wykonać operację Cleanup test failover, aby usunąć testowe maszyny wirtualne i powiązane z nimi dyski. Bez czyszczenia testowe maszyny wirtualne nadal działają i generują koszty obliczeniowe. Ten krok resetuje również stan testowego przełączenia chronionego elementu, umożliwiając wykonanie kolejnego testu w przyszłości. Automatyzacja czyszczenia (np. zaplanowanie go na godzinę po rozpoczęciu testu za pomocą runbooka Automation) zapobiega pozostawieniu testowych maszyn wirtualnych uruchomionych przez wiele dni.

Każdy test DR powinien zakończyć się utworzeniem raportu z testu DR zawierającego: datę i testowany scenariusz, użyte punkty odzyskiwania, osiągnięte wartości RTO i RPO, wykryte problemy oraz podjęte działania naprawcze. Dokumentacja ta spełnia wymagania audytorów dotyczące standardów takich jak ISO 27001 i SOC 2, które nakazują regularne testowanie DR. Raporty z testów należy przechowywać w bezpiecznej lokalizacji dostępnej zarówno dla zespołów IT, jak i zespołów odpowiedzialnych za ciągłość działania.

Ceny Azure Site Recovery są naliczane za każdą chronioną instancję miesięcznie — opłata obejmuje zarówno usługę replikacji, jak i orkiestrację. Naliczane są również opłaty za miejsce zajmowane przez zarządzane dyski repliki w regionie docelowym oraz za konto magazynu pamięci podręcznej używane podczas replikacji. Transfer danych wychodzących między regionami Azure dla ruchu replikacji jest rozliczany według standardowych stawek transferu wychodzącego (w przeciwieństwie do Azure Backup, w którym transfer wychodzący między sparowanymi regionami jest bezpłatny). W przypadku replikacji z lokalnego środowiska do Azure licencje Windows Server dla maszyn wirtualnych Azure mogą korzystać z funkcji Azure Hybrid Benefit, aby obniżyć koszty.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: testowe przełączanie weryfikuje plan DR w odizolowanej sieci bez wpływu na środowisko produkcyjne; plany odzyskiwania określają kolejność przełączania wielu maszyn wirtualnych, wykorzystując ręczne bramki i kroki runbooków automatyzacji; natomiast failback przywraca obciążenia do pierwotnego regionu, odwracając kierunek replikacji po awarii. W następnej części omówimy Azure CDN służący do przyspieszania globalnego dostarczania treści.