Wysoka dostępność (High Availability, HA) to cecha systemu zaprojektowanego tak, by działał możliwie nieprzerwanie nawet wtedy, gdy padnie pojedynczy serwer, dysk czy łącze. W praktyce nie chodzi o to, żeby nic się nigdy nie zepsuło (zepsuje się — to tylko kwestia kiedy), lecz o to, żeby awaria jednego elementu nie zwaliła całej usługi. Osiąga się to przez redundancję (kilka instancji tego samego) i automatyczne mechanizmy przełączania ruchu na zdrowe komponenty.
Dostępność mierzymy w procentach czasu działania w skali roku, popularnie zwanych „dziewiątkami”. 99,9% (three nines) to około 8,7 godziny niedostępności rocznie, 99,99% (four nines) to już tylko ~52 minuty, a 99,999% (five nines) — niecałe 5,5 minuty rocznie. Każda kolejna dziewiątka kosztuje dramatycznie więcej, więc zanim obiecasz „pięć dziewiątek”, policz, czy biznes naprawdę tego potrzebuje, czy tylko ładnie brzmi w prezentacji.
Jak to działa
Fundament HA to brak single point of failure (SPOF) — czyli żadnego elementu, którego awaria zatrzymuje wszystko. Dokładasz więc nadmiarowe instancje, a przed nie stawiasz mechanizm, który wykrywa awarię (health check) i przekierowuje ruch. Najczęstsze wzorce to load balancing (ruch rozkładany na wiele aktywnych węzłów) oraz failover (gotowy węzeł zapasowy przejmuje rolę po awarii). W bazach danych dochodzi replikacja danych, żeby kopia była aktualna w momencie przełączenia.
Przykład z praktyki
Masz dwa serwery aplikacji za load balancerem (np. HAProxy albo nginx). Balancer co kilka sekund odpytuje endpoint zdrowia, np. GET /health. Gdy jeden serwer przestaje odpowiadać, balancer po prostu wycina go z puli i kieruje cały ruch na drugi — użytkownik nawet tego nie zauważy. W przypadku jednego adresu IP, który musi „przeskoczyć” między maszynami, używa się keepalived z protokołem VRRP i wirtualnym IP. Sprawdzenie stanu HAProxy podejrzysz np. tak:
echo "show stat" | socat stdio /run/haproxy/admin.sock
Częste błędy i mity
- HA to nie backup. Replikacja wiernie skopiuje też skasowaną tabelę albo zaszyfrowane przez ransomware pliki. Redundancja chroni przed awarią sprzętu, nie przed błędem człowieka.
- Split-brain. Gdy dwa węzły nawzajem uznają się za martwe i oba zaczynają działać jako master, robi się chaos w danych. Dlatego potrzebujesz quorum i fencingu.
- Nieprzetestowany failover. Przełączanie, którego nigdy nie odpaliłeś na produkcji, statystycznie nie działa wtedy, gdy jest naprawdę potrzebne.
Pojęcia powiązane: redundancja, failover, load balancing, replikacja, klaster (cluster), fault tolerance, disaster recovery, SLA, single point of failure, RTO i RPO.