Automatic failover

Automatic failover to automatyczne przełączenie roli głównej instancji na serwer zapasowy w przypadku wykrycia awarii.

Na czym polega automatyczne przełączenie roli

Automatic failover, czyli automatyczne przełączenie awaryjne, oznacza zmianę roli instancji głównej na inną instancję przygotowaną do przejęcia obsługi ruchu. Instancja główna realizuje operacje odczytu i zapisu albo udostępnia określoną usługę, natomiast instancja zapasowa pozostaje gotowa do pracy w trybie czuwania lub utrzymuje aktualną kopię stanu systemu. Gdy mechanizm zarządzający wykryje niedostępność głównego elementu, podejmuje decyzję o zmianie właściciela usługi.

Wykrycie awarii nie powinno opierać się wyłącznie na pojedynczym nieudanym zapytaniu. Stosuje się sondy kontrolne, komunikaty heartbeat oraz testy obejmujące proces aplikacji, dostęp do dysku, interfejs sieciowy i możliwość wykonania operacji wymaganej przez usługę. Dzięki temu można odróżnić chwilowe opóźnienie od rzeczywistej awarii. Po potwierdzeniu problemu system może odłączyć dotychczasową instancję, nadać rolę główną serwerowi zapasowemu i skierować do niego nowe połączenia.

Detekcja awarii, quorum i ochrona przed split-brain

Najtrudniejszą częścią automatic failover jest nie samo uruchomienie serwera zapasowego, lecz bezpieczne ustalenie, który element ma prawo pełnić funkcję główną. Jeżeli obie instancje utracą ze sobą łączność, ale każda nadal będzie widziała własne zasoby, może dojść do tak zwanego split-brain. W takim stanie dwa węzły uznają się za aktywne i równocześnie przyjmują zapisy. Skutkiem może być rozbieżność danych, konflikt blokad albo późniejsza konieczność żmudnego scalania zmian.

Do ograniczania tego ryzyka wykorzystuje się quorum, czyli regułę wymagającą uzyskania odpowiedniej liczby głosów lub potwierdzeń przed przyznaniem roli głównej. W zależności od rozwiązania uczestniczyć może w tym dodatkowy niezależny głos, arbiter albo usługa koordynująca. Ważne jest także fencing, nazywany odcinaniem lub izolowaniem wadliwego węzła. Polega on na odebraniu starej instancji dostępu do współdzielonego zasobu albo na jej kontrolowanym zatrzymaniu, zanim zapasowy węzeł zacznie wykonywać operacje zapisu.

Parametry detekcji wpływają na zachowanie całego systemu. Zbyt krótki czas oczekiwania może powodować niepotrzebne przełączenia podczas chwilowych przeciążeń lub utraty pakietów. Zbyt długi czas opóźnia reakcję na rzeczywistą awarię. Dlatego konfigurację progów, liczby kolejnych nieudanych sond oraz czasu stabilizacji dobiera się do charakteru usługi i jakości połączeń między instancjami.

Replikacja danych a ciągłość obsługi po awarii

Automatyczne przełączenie nie gwarantuje samo w sobie zachowania wszystkich danych. Zapasowa instancja musi otrzymywać zmiany z instancji głównej albo korzystać z mechanizmu wspólnego stanu. Przy replikacji synchronicznej potwierdzenie zapisu może być uzależnione od zapisania danych także po stronie zapasowej. Ogranicza to ryzyko utraty ostatnich zmian, ale zwiększa zależność od opóźnień sieciowych. Przy replikacji asynchronicznej główna instancja może działać szybciej, jednak w chwili awarii część niedawno wykonanych zapisów może jeszcze nie znajdować się na zapasowym węźle.

Przy ocenie rozwiązania rozróżnia się RTO i RPO. RTO, czyli Recovery Time Objective, określa akceptowalny czas przywrócenia obsługi. RPO, czyli Recovery Point Objective, określa maksymalny zakres danych, który może zostać utracony wskutek awarii. Automatic failover może skrócić przerwę w działaniu, ale nie zastępuje kopii zapasowych. Nie chroni również przed błędnym poleceniem wykonanym na instancji głównej, usunięciem danych przez aplikację ani uszkodzeniem, które zostanie wiernie powielone na instancję zapasową.

Po przełączeniu trzeba jeszcze zapewnić prawidłowe kierowanie połączeń. Wykorzystuje się do tego między innymi wirtualny adres usługi, rekord DNS, moduł równoważenia ruchu albo warstwę pośrednią znającą aktualnego właściciela zasobu. Istniejące sesje klientów mogą zostać przerwane, ponieważ połączenie TCP lub stan transakcji nie zawsze może być przeniesiony na inny węzeł. Aplikacja powinna więc obsługiwać ponowne połączenie, bezpieczne powtórzenie operacji oraz sytuację, w której transakcja została przerwana w trakcie zapisu.

Weryfikacja konfiguracji i kontrolowany test przełączenia

Ocena automatic failover wymaga sprawdzenia nie tylko tego, czy zapasowy serwer się uruchamia, lecz także czy po przełączeniu działa cały łańcuch zależności. Należy zweryfikować dostępność usługi, możliwość logowania, odczyt danych, zapis nowych danych, poprawność nazwy używanej przez klientów oraz zachowanie połączeń już otwartych. Istotne jest również potwierdzenie, że stara instancja nie przyjmuje zapisów po utracie roli głównej.

Test powinien mieć ustalony scenariusz, kryterium sukcesu i sposób powrotu do poprzedniego układu. Można osobno sprawdzić awarię procesu, odłączenie interfejsu sieciowego, niedostępność zasobu danych oraz utratę komunikacji między węzłami. Po każdym teście analizuje się dzienniki zdarzeń, czas wykrycia awarii, czas przejęcia roli, liczbę błędnych żądań i ewentualną utratę niezatwierdzonych zmian. Testowanie w warunkach kontrolowanych jest ważne, ponieważ konfiguracja może wyglądać poprawnie, a mimo to zawodzić przy konkretnym rodzaju awarii.

W środowisku laptopa lub komputera PC pojęcie automatic failover najczęściej odnosi się do infrastruktury serwerowej, a nie do standardowej funkcji pojedynczego urządzenia. Podczas diagnostyki komputera można jednak sprawdzić objawy związane z niedostępnością usługi sieciowej, błędami sterowników, utratą połączenia lub nieprawidłowym rozwiązywaniem nazw. Taka analiza pozwala ustalić, czy problem leży po stronie stacji roboczej, sieci, mechanizmu kierowania ruchu czy samej usługi działającej na zapasowym węźle.