Test przełączenia awaryjnego: czy drugi serwer naprawdę przejmie ruch?

Drugi serwer, replikacja bazy danych i adres IP, który w razie awarii przeskakuje na węzeł zapasowy — na schemacie architektura wysokiej dostępności wygląda przekonująco. Problem w tym, że schemat nie mówi nic o tym, czy przełączenie zadziała dzisiaj. Konfiguracja żyje: ktoś aktualizuje system, dopisuje regułę zapory, odnawia certyfikat, zmienia hasło do bazy. Jeśli te zmiany trafiły tylko na serwer główny, rezerwa przestaje być rezerwą, a firma dowiaduje się o tym w najgorszym możliwym momencie.

Dlatego test przełączenia awaryjnego (failover test) jest dla klastra tym, czym test odtwarzania jest dla backupu. O tym, jak sprawdzać kopie zapasowe, pisaliśmy we wpisie Kiedy ostatnio odtwarzałeś dane z kopii zapasowej?. Dziś zajmiemy się drugą połową tej samej układanki.

Co psuje się w rezerwie, której nikt nie sprawdza

Węzeł zapasowy przez większość czasu nic nie robi, więc jego usterki są niewidoczne. Najczęściej spotykane problemy wyglądają tak:

• Zatrzymana lub opóźniona replikacja. Baza na serwerze zapasowym przestała nadążać, ale nikt nie monitorował opóźnienia. Po przełączeniu aplikacja startuje na danych sprzed wielu godzin.
• Rozjechana konfiguracja. Nowa wersja aplikacji, zmienna środowiskowa albo reguła zapory została wdrożona tylko na węźle głównym.
• Wygasłe certyfikaty i hasła. Certyfikat odnowiono na serwerze, który obsługuje ruch, a na zapasowym leży stary.
• Zależności poza klastrem. Zapasowy serwer nie ma dostępu do zewnętrznego API, bo partner dopuszcza ruch tylko z jednego adresu IP.
• Mechanizm przełączenia, który nigdy nie zadziałał. Wirtualny adres IP, rekord DNS z długim TTL albo arbiter (quorum), który w praktyce nie podejmuje decyzji.

Każdą z tych usterek łatwo naprawić, gdy się o niej wie. Test służy właśnie temu, żeby się dowiedzieć.

Jak przygotować pierwszy test

Pierwszy test warto potraktować jak małe wdrożenie, a nie jak eksperyment.

1. Spisz oczekiwania. Ile czasu może trwać przełączenie i ile danych firma może stracić — czyli docelowe RTO i RPO. Bez tego nie ocenisz, czy test się udał. Teoretyczne podstawy tych pojęć opisaliśmy we wpisie o architekturze high availability na dwóch serwerach dedykowanych.
2. Wybierz okno serwisowe. Pierwszy test rzadko przebiega bezbłędnie, więc zaplanuj go poza godzinami szczytu i uprzedź użytkowników. Jak ustalić takie okno, opisaliśmy w tekście o oknach serwisowych.
3. Zrób świeżą kopię zapasową obu węzłów. Test ma sprawdzać przełączenie, a nie odwagę zespołu.
4. Przygotuj plan wycofania. Zapisz, kto i w jaki sposób przywraca stan wyjściowy, jeśli coś pójdzie źle.
5. Ustal, kto obserwuje co. Jedna osoba wywołuje awarię, druga patrzy na monitoring, trzecia sprawdza aplikację z perspektywy użytkownika.

Jak przeprowadzić test

Zacznij od scenariusza najbardziej kontrolowanego, a dopiero w kolejnych testach przechodź do trudniejszych:

• Przełączenie planowe — ręczne przeniesienie roli głównej na drugi węzeł poleceniem klastra. Sprawdza, czy węzeł zapasowy w ogóle potrafi obsłużyć ruch.
• Zatrzymanie usługi — wyłączenie bazy lub serwera aplikacji na węźle głównym. Sprawdza, czy monitoring klastra wykrywa awarię sam.
• Odcięcie sieci lub zasilania węzła — najbliższe prawdziwej awarii. W serwerze dedykowanym można to zrobić przez zdalną konsolę IPMI, bez fizycznej obecności w serwerowni.

Podczas testu mierz trzy rzeczy: czas od awarii do przywrócenia usługi, ilość utraconych lub niezsynchronizowanych danych oraz to, czy aplikacja faktycznie działa — logowanie, zapis transakcji, wysyłka powiadomień. Odpowiedź serwera na pingi to jeszcze nie działający system.

Powrót na serwer główny to osobny test

Wiele zespołów kończy test w chwili, gdy ruch przeszedł na węzeł zapasowy. Tymczasem powrót (failback) bywa trudniejszy: dane zapisane na serwerze zapasowym muszą wrócić na główny, a replikacja musi ruszyć w przeciwnym kierunku. Jeśli tego nie przećwiczysz, po prawdziwej awarii możesz utknąć na rezerwie na długie tygodnie, bez żadnego zabezpieczenia.

Co zapisać po teście

Krótki protokół z testu ma wartość nie tylko techniczną. Zawiera datę, scenariusz, zmierzony czas przełączenia, wykryte usterki i termin ich usunięcia. Taki dokument przydaje się podczas audytu bezpieczeństwa, w rozmowie z zarządem i przy przeglądzie planu ciągłości działania. Kolejny test warto zaplanować od razu — szczególnie po większych zmianach w architekturze lub aplikacji.

Gdzie kończy się rola data center

Data center odpowiada za to, co dzieje się pod Twoimi serwerami. W Sprint Data Center kolokacja serwerów obejmuje dwutorowe zasilanie, UPS z agregatem prądotwórczym, redundantną klimatyzację i łącza dostępowe od różnych operatorów. To jednak warstwa infrastruktury. Czy Twoja aplikacja przejdzie na drugi węzeł, zależy od konfiguracji klastra — i to właśnie sprawdza test przełączenia awaryjnego.

Podsumowanie

Rezerwa, której nikt nie przetestował, jest założeniem, a nie zabezpieczeniem. Zaplanuj test w oknie serwisowym, zmierz czas przełączenia i utratę danych, przećwicz powrót na serwer główny i zapisz wyniki. Jeśli budujesz klaster, serwery dedykowane SDC mają wbudowaną konsolę zdalnego zarządzania IPMI, która ułatwia kontrolowane wyłączanie węzłów podczas testów. Jeżeli wolisz oddać administrację specjalistom, sprawdź pakiety administracyjne, które obejmują między innymi monitoring usług i politykę kopii zapasowych. Masz pytania o architekturę rezerwy? Skontaktuj się z nami.

FAQ – najczęściej zadawane pytania o test przełączenia awaryjnego

Jak często przeprowadzać test przełączenia awaryjnego?

Nie ma jednej reguły, ale test powinien odbywać się regularnie, według ustalonego harmonogramu, oraz zawsze po większych zmianach w architekturze, systemie operacyjnym lub aplikacji. Częstotliwość warto dopasować do tego, jak krytyczna jest usługa i jak często zmienia się jej konfiguracja.

Czy test przełączenia awaryjnego może spowodować przestój?

Tak, zwłaszcza pierwszy. Dlatego test planuje się w oknie serwisowym, po wykonaniu świeżej kopii zapasowej i z przygotowanym planem wycofania. Krótki, zaplanowany przestój jest znacznie tańszy niż odkrycie usterki podczas prawdziwej awarii.

Czym różni się failover od failback?

Failover to przejęcie ruchu przez węzeł zapasowy po awarii głównego. Failback to powrót na serwer główny po jego naprawie, połączony z synchronizacją danych zapisanych w międzyczasie. Oba procesy trzeba przetestować osobno, bo failback często okazuje się trudniejszy.

Czy redundantna infrastruktura data center zastępuje drugi serwer?

Nie. Dwutorowe zasilanie i łącza od różnych operatorów chronią przed awariami po stronie data center, ale nie przed usterką samego serwera, systemu lub aplikacji. Przed nimi chroni dopiero drugi węzeł, na przykład drugi serwer dedykowany, oraz regularnie sprawdzane przełączenie.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.