Failover planned

Failover planned to zaplanowane, kontrolowane przełączenie roli głównej instancji, wykonywane bez ryzyka utraty danych.

Na czym polega zaplanowany failover

Failover planned oznacza zaplanowane, kontrolowane przełączenie roli głównej instancji na przygotowaną instancję zapasową. Operację wykonuje się w określonym oknie serwisowym, zwykle przed planowaną konserwacją, aktualizacją oprogramowania, wymianą elementu infrastruktury albo testem procedury ciągłości działania. W odróżnieniu od przełączenia awaryjnego nie jest to reakcja na nagłą awarię. Administrator zna moment rozpoczęcia operacji, może sprawdzić stan środowiska i przeprowadzić kolejne etapy według ustalonego scenariusza.

Podczas planned failover instancja zapasowa przejmuje funkcję podstawową, a dotychczasowa instancja główna staje się zapasową albo zostaje czasowo wyłączona z obsługi. Zakres przełączenia zależy od konkretnego systemu wysokiej dostępności. Może obejmować zmianę właściciela zasobu, przełączenie adresu używanego przez klientów, zmianę wpisu w mechanizmie kierowania ruchu lub aktywowanie roli w klastrze. Samo określenie failover planned nie wskazuje jednego produktu ani jednej komendy, dlatego szczegóły wykonania zawsze wynikają z dokumentacji używanego systemu.

Warunki bezpiecznego przełączenia roli

Najważniejszym warunkiem kontrolowanego failover jest dostępność instancji zapasowej oraz aktualność jej danych. W systemach replikujących dane należy potwierdzić, że replika otrzymała i zatwierdziła wszystkie wymagane zmiany. Szczególne znaczenie ma rozróżnienie replikacji synchronicznej i asynchronicznej. Replikacja synchroniczna może pozwolić na przełączenie bez utraty zatwierdzonych danych, jeżeli mechanizm potwierdza zapis po stronie obu uczestników. W replikacji asynchronicznej między instancją główną a zapasową może pozostać opóźnienie, więc przełączenie może wymagać zatrzymania zapisów, dodatkowego uzgodnienia stanu albo zaakceptowania ryzyka utraty ostatnich zmian.

Przed operacją sprawdza się także stan połączeń, obciążenie, dostępność wymaganych usług zależnych, poprawność konfiguracji oraz możliwość przyjęcia ruchu przez instancję zapasową. Należy ustalić, które procesy mogą wykonywać zapis, czy klienci ponowią połączenia po zmianie roli oraz czy mechanizm rozpoznawania aktywnej instancji działa zgodnie z założeniami. Warto przygotować punkt powrotu, zapisać aktualny stan replikacji i określić warunek przerwania procedury. Planned failover nie powinien być rozpoczynany wyłącznie na podstawie faktu, że instancja zapasowa odpowiada na żądania. Odpowiedź sieciowa nie potwierdza jeszcze kompletności danych ani gotowości całej aplikacji.

Przebieg operacji i kontrola wyniku

Typowy przebieg obejmuje ogłoszenie okna serwisowego, ograniczenie lub zatrzymanie nowych zapisów, sprawdzenie synchronizacji, formalne przekazanie roli oraz skierowanie klientów do nowej instancji głównej. Następnie wykonywane są testy odczytu i zapisu, kontrola statusu replikacji oraz weryfikacja działania aplikacji korzystających z przełączonego zasobu. Jeżeli system używa warstwy pośredniej, nazwy logicznej albo usługi wykrywającej aktywnego właściciela, trzeba potwierdzić, że klienci nie pozostają przy starym adresie z powodu pamięci podręcznej, nieaktualnej konfiguracji lub długiego czasu życia wpisu.

Po przełączeniu monitoruje się błędy połączeń, czas odpowiedzi, opóźnienie replikacji, obciążenie procesora, pamięci i urządzeń pamięci masowej oraz kolejki operacji oczekujących. Weryfikacja powinna obejmować również transakcje rozpoczęte przed zmianą roli, zadania cykliczne, blokady i procesy, które mogły zostać przerwane. Jeżeli wyniki odbiegają od założeń, procedura powrotu musi być wykonana według wcześniej ustalonych kryteriów. Failback, czyli przywrócenie pierwotnej instancji do roli głównej, również powinien być zaplanowany. Przed jego wykonaniem należy ponownie zapewnić zgodność danych i sprawdzić, czy przyczyna wcześniejszego przełączenia została usunięta.

Różnica między planned failover a przełączeniem po awarii

Planned failover różni się od nieplanowanego failover przede wszystkim ilością dostępnych informacji i możliwością przygotowania środowiska. Przy kontrolowanym przełączeniu można wcześniej sprawdzić zależności, ograniczyć ruch, zsynchronizować dane i poinformować użytkowników o krótkiej niedostępności. Po awarii administrator często działa przy niepełnym obrazie sytuacji: instancja główna może być niedostępna, stan ostatnich zapisów może wymagać odtworzenia, a mechanizm automatycznego wyboru nowej instancji może zależeć od quorum, głosów uczestników lub reguł konkretnego klastra.

W środowisku laptopa lub komputera PC użytkownik zwykle nie spotyka się z terminem failover planned jako samodzielną funkcją systemu lokalnego. Hasło odnosi się przede wszystkim do zaplanowanych operacji w systemach wieloinstancyjnych i usługach wymagających wysokiej dostępności. Przy diagnostyce komputera można natomiast sprawdzić, czy problem zgłaszany jako „przełączenie” nie wynika w rzeczywistości z utraty połączenia, nieaktualnego adresu usługi, błędu aplikacji albo uszkodzenia nośnika. Rozpoznanie tych przyczyn wymaga oddzielenia awarii sprzętowej od problemu konfiguracji i mechanizmu przejmowania roli.