Testowanie DR bez wpływu na środowisko

Plan odzyskiwania po awarii, który nigdy nie został przetestowany, jest tylko hipotezą. Doświadczenia z rzeczywistych wdrożeń pokazują, że plany DR często ujawniają luki — rozbieżności w konfiguracji, brak automatyzacji, nieaktualne elementy runbook lub dłuższy od oczekiwanego czas uruchamiania — które wychodzą na jaw dopiero podczas testów. Regularne testowanie DR to jedyny sposób, aby mieć pewność, że plan zadziała wtedy, gdy będzie najbardziej potrzebny.

Test Failover to wbudowana funkcja Azure Site Recovery, która umożliwia zasymulowanie przełączenia awaryjnego do regionu pomocniczego bez przerywania działania środowiska produkcyjnego. Podczas testowego przełączenia awaryjnego ASR tworzy kopie replikowanych maszyn wirtualnych w odizolowanej sieci wirtualnej w regionie pomocniczym. Produkcyjne maszyny wirtualne nadal działają normalnie w regionie podstawowym, więc użytkownicy korzystający ze środowiska produkcyjnego nie są narażeni na ryzyko.

Izolowana sieć VNet środowiska testowego nie może mieć połączenia z systemami produkcyjnymi. Zapobiega to przypadkowemu zapisywaniu przez testowe maszyny wirtualne danych w produkcyjnej bazie danych, wysyłaniu wiadomości e-mail do rzeczywistych klientów lub uruchamianiu transakcji płatniczych. Należy utworzyć dedykowaną sieć VNet na potrzeby testowego przełączenia awaryjnego, bez peeringu z produkcyjnymi sieciami VNet i bez dostępu do Internetu, a następnie używać jej wyłącznie do ćwiczeń DR.

Test DR powinien obejmować określony zestaw kryteriów:

• Czas uruchamiania — czy wszystkie maszyny wirtualne uruchamiają się w oczekiwanym przedziale czasu?
• Uruchamianie aplikacji — czy aplikacja inicjalizuje się prawidłowo po połączeniu z odzyskaną bazą danych?
• Integralność danych — czy dane w punkcie odzyskiwania są spójne i kompletne?
• Rzeczywisty RTO — należy zmierzyć całkowity czas, który upłynął od uruchomienia przełączenia awaryjnego do rozpoczęcia obsługi żądań przez aplikację
• Wykonanie elementów runbook — czy wszystkie skrypty automatyzacji zakończyły się pomyślnie?

Podczas testu należy uruchomić stoper w chwili wyzwolenia testowego przełączenia awaryjnego. Stoper należy zatrzymać po potwierdzeniu poprawnego działania aplikacji (sonda kondycji modułu równoważenia obciążenia zwraca kod 200 OK). Jest to rzeczywisty RTO. Należy porównać go z docelowym RTO. Jeśli rzeczywisty RTO przekracza wartość docelową, należy zidentyfikować wąskie gardła — powolne uruchamianie maszyn wirtualnych, długą inicjalizację bazy danych lub opóźnienie propagacji DNS — i usunąć ich przyczyny.

Po zakończeniu testowego przełączenia awaryjnego należy połączyć się z odzyskaną bazą danych i zweryfikować dane. Należy sprawdzić, czy transakcje zatwierdzone przed odcięciem replikacji są obecne oraz czy transakcje częściowo zatwierdzone są prawidłowo obsługiwane (wycofane lub dokończone). W przypadku baz danych obsługujących funkcję przywracania do punktu w czasie (PITR) należy przetestować przywracanie do określonego znacznika czasu i zweryfikować oczekiwany stan danych.

Po zakończeniu testu należy usunąć zasoby testowego przełączenia awaryjnego — testowe maszyny wirtualne, ich dyski i interfejsy sieciowe w regionie pomocniczym. Azure Site Recovery udostępnia w portalu akcję „Cleanup test failover”, która automatycznie usuwa wszystkie zasoby testowe. Zaniechanie czyszczenia powoduje niepotrzebne koszty i zaśmieca region pomocniczy nieaktualnymi zasobami.

Po każdym teście DR należy sporządzić raport z testu zawierający: datę i zakres testu, osiągnięte wartości rzeczywistego RTO i RPO, listę kontrolną elementów weryfikacji ze statusem powodzenia lub niepowodzenia, zaobserwowane luki lub błędy oraz zaplanowane działania naprawcze. Raport ten jest przydatny podczas audytów zgodności (ISO 27001, SOC 2, HIPAA) oraz do śledzenia wzrostu dojrzałości procesów DR w czasie.

Najlepsze praktyki branżowe i struktury zgodności zazwyczaj wymagają przeprowadzania testów DR co najmniej raz w roku, jednak wiele organizacji testuje obciążenia klasy Tier 1 co kwartał, a nawet co miesiąc. Częstsze testowanie pozwala wcześniej wykrywać rozbieżności w konfiguracji oraz budować pewność i doświadczenie zespołu. Należy w miarę możliwości zautomatyzować przygotowanie i weryfikację testu, aby ograniczyć nakład pracy związany z częstym testowaniem.

Azure Chaos Studio to zarządzana usługa chaos engineering, która umożliwia wprowadzanie kontrolowanych awarii do zasobów platformy Azure w celu testowania odporności aplikacji. Można wyłączać maszyny wirtualne, powodować awarie stref, ograniczać użycie procesora lub wprowadzać opóźnienia sieciowe, aby obserwować zachowanie aplikacji. W przeciwieństwie do standardowego ćwiczenia DR chaos engineering sprawdza, czy aplikacja łagodnie degraduje działanie w warunkach częściowej awarii.

Testowanie DR przynosi największą wartość jako element ciągłego cyklu doskonalenia: Zaplanuj → Wykonaj → Zmierz → Usuń problemy → Powtórz. Po każdym teście należy usunąć wykryte luki, zaktualizować elementy runbook i dokumentację, a następnie ponownie przeprowadzić test. Z czasem różnica między deklarowanymi wartościami docelowymi RTO/RPO a wartościami rzeczywiście osiąganymi powinna się zmniejszać, aż wszystkie testy będą konsekwentnie zaliczane w ramach przyjętej tolerancji.

W tej lekcji dowiedziałeś się, że testowe przełączenie awaryjne umożliwia zasymulowanie zdarzenia DR bez przerywania działania środowiska produkcyjnego przez utworzenie kopii maszyn wirtualnych w odizolowanej sieci VNet; podczas testu należy zmierzyć rzeczywisty RTO i zweryfikować integralność danych; a po każdym ćwiczeniu należy usunąć zasoby testowe i udokumentować wyniki. Następnie omówimy odzyskiwanie po awarii w usługach PaaS, takich jak Azure SQL Database.