redundancja serwerów

Redundancja serwerów to utrzymywanie zapasowej infrastruktury przejmującej ruch w razie awarii głównej.

Redundancja serwerów jako zabezpieczenie ciągłości pracy

Redundancja serwerów oznacza zaprojektowanie infrastruktury tak, aby awaria pojedynczego elementu nie powodowała całkowitego zatrzymania usługi. Zapasowy serwer może przejąć obsługę ruchu po wykryciu niedostępności serwera podstawowego. W zależności od architektury redundancja obejmuje nie tylko same jednostki obliczeniowe, lecz także zasilacze, interfejsy sieciowe, przełączniki, macierze dyskowe, systemy przechowywania danych i łącza komunikacyjne. Jeżeli kilka serwerów korzysta z jednego niezabezpieczonego przełącznika albo wspólnego zasilacza, awaria tego elementu nadal może przerwać działanie całej usługi.

Najczęściej spotykany model aktywny–pasywny wykorzystuje jeden serwer wykonujący pracę oraz drugi, pozostający w gotowości do przejęcia usług. W modelu aktywny–aktywny oba serwery obsługują żądania jednocześnie, zwykle za pośrednictwem modułu równoważenia obciążenia. Taki układ może zwiększać wydajność i ułatwiać prace serwisowe, ale wymaga poprawnego synchronizowania stanu aplikacji oraz danych. Redundancja nie jest więc prostym powieleniem sprzętu. Musi obejmować mechanizmy wykrywania awarii, zmianę trasy ruchu i odtworzenie dostępu do aktualnych zasobów.

Modele przełączania ruchu i wykrywania awarii

Przełączenie na serwer zapasowy może być realizowane przez dedykowany load balancer, klaster wysokiej dostępności, rekordy DNS albo mechanizmy sieciowe wykorzystujące wirtualny adres IP. Load balancer może wykonywać cykliczne testy stanu, na przykład sprawdzać odpowiedź określonego portu TCP lub żądanie HTTP do ustalonego adresu. Samo otwarcie portu nie potwierdza jednak poprawnego działania aplikacji. Serwer może odpowiadać na poziomie sieci, a jednocześnie mieć zatrzymany proces aplikacyjny, niedostępną bazę danych albo pełny system plików. Z tego powodu test kontrolny powinien sprawdzać funkcję istotną dla danej usługi, o ile architektura na to pozwala.

W klastrze węzły wymieniają informacje o swoim stanie i podejmują decyzję, który z nich ma świadczyć usługę. Istotne są interwały kontroli, liczba nieudanych prób przed uznaniem węzła za niedostępny oraz czas potrzebny na uruchomienie zasobów na serwerze zapasowym. Zbyt agresywne parametry mogą wywoływać fałszywe przełączenia podczas chwilowych opóźnień sieci. Zbyt łagodne ustawienia wydłużają przerwę po rzeczywistej awarii. W instalacjach wielowęzłowych stosuje się również mechanizmy quorum, aby ograniczyć ryzyko split-brain, czyli sytuacji, w której odseparowane części klastra równocześnie uznają się za aktywne.

Synchronizacja danych, RTO i RPO

Serwer zapasowy musi mieć dostęp do danych potrzebnych do kontynuowania pracy. Synchronizacja może być wykonywana niemal równocześnie, okresowo albo przez odtwarzanie kopii zapasowych. Replikacja synchroniczna potwierdza zapis dopiero po zapisaniu danych w wymaganych lokalizacjach, dlatego ogranicza ryzyko utraty ostatnich zmian, ale zwiększa zależność od opóźnień sieci i wydajności systemu dyskowego. Replikacja asynchroniczna pozwala szybciej potwierdzać operacje, lecz w chwili awarii może pozostawić część najnowszych danych wyłącznie na serwerze podstawowym.

Przy projektowaniu redundancji określa się RTO i RPO. RTO, czyli docelowy czas odtworzenia działania, opisuje, jak długo usługa może pozostawać niedostępna. RPO określa akceptowalny zakres danych, który może zostać utracony wskutek awarii, wyrażany zwykle jako okres czasu. Przykładowo RPO wynoszące 15 minut oznacza konieczność ograniczenia potencjalnej utraty danych do zmian z najwyżej ostatnich 15 minut, ale nie gwarantuje automatycznie spełnienia tego celu. Rzeczywiste parametry zależą od sposobu replikacji, obciążenia, przepustowości łączy oraz procedury uruchamiania serwera zapasowego.

Regularne testy są konieczne, ponieważ sama obecność drugiego serwera nie dowodzi poprawności rozwiązania. Test powinien obejmować kontrolowane zatrzymanie węzła podstawowego, przejęcie adresów lub ruchu, dostęp aplikacji do danych, działanie zależności oraz późniejszy powrót do układu podstawowego. Należy także sprawdzać, czy po odzyskaniu serwer nie nadpisuje nowszych danych starszą kopią. Wyniki testów powinny zawierać zmierzony czas przerwy, zakres ewentualnej utraty danych i błędy wymagające korekty konfiguracji.

Ograniczenia redundancji w infrastrukturze serwerowej

Redundancja zmniejsza skutki awarii, ale nie usuwa wszystkich przyczyn niedostępności. Jednoczesne uszkodzenie kilku urządzeń, błąd konfiguracji wdrożony na wszystkich węzłach, awaria wspólnego systemu przechowywania danych albo przerwanie zasilania w całej lokalizacji może dotknąć zarówno serwer główny, jak i zapasowy. Z tego powodu rozwiązania o wymaganej wysokiej dostępności często rozdziela się między niezależne obwody zasilania, urządzenia sieciowe lub lokalizacje. Trzeba przy tym uwzględnić opóźnienia między lokalizacjami i sposób spójnego zapisu danych.

Podczas diagnostyki infrastruktury sprawdza się stan dysków, kontrolerów RAID, zasilaczy, wentylatorów, interfejsów sieciowych oraz komunikację między węzłami. Analizuje się również dzienniki przełączeń, błędy testów zdrowia, opóźnienia replikacji i różnice między konfiguracją serwera podstawowego a zapasowego. Jeżeli przełączenie nie następuje, przyczyną może być nie tylko awaria sprzętu, lecz także wygasły certyfikat, niedostępna usługa zależna, niezgodny identyfikator zasobu lub błędna reguła routingu. Wynik takiej kontroli powinien rozróżniać awarię pojedynczego komponentu od problemu w całym mechanizmie wysokiej dostępności.