Jak zaprojektować środowisko wysokiej dostępności?

Co znaczy High Availability w praktyce

HA nie oznacza "nigdy nie pada". Oznacza "wraca wystarczająco szybko, żeby użytkownicy nie zauważyli awarii lub żeby wpływ był akceptowalny". To różnica, która ma konsekwencje projektowe — bo RTO (Recovery Time Objective, czas odtworzenia) i RPO (Recovery Point Objective, maksymalna utrata danych) to parametry biznesowe, nie techniczne. Najpierw musisz wiedzieć co jest akceptowalne, potem dobrać technologię.

Środowisko HA to zawsze zestaw kompromisów między kosztem a odpornością. Pełna redundancja na każdym poziomie jest możliwa, ale kosztuje 2-3× więcej niż środowisko bez redundancji. W praktyce priorytetyzuje się: co musi działać zawsze, co może mieć przestój mierzony w minutach, co może mieć przestój mierzony w godzinach. Projektuj od wymagań biznesowych, nie od dostępnych technologii.

Warstwy HA — gdzie może paść

HA to nie jedna decyzja, to kilka niezależnych warstw: sprzęt (zasilacze, dyski, karty sieciowe), sieć (łącza, switche, routery), zasilanie (UPS, agregat, sieci energetyczne), oprogramowanie (hypervisor, system operacyjny, aplikacja), datacenter (jako całość — pożar, zalanie, utrata zasilania miejskiego). Każda warstwa ma własne mechanizmy redundancji i własne punkty awarii.

Częsty błąd to zabezpieczenie jednej warstwy przy ignorowaniu pozostałych. Klaster HA Proxmoxa z shared storage nie pomoże gdy pada switch uplink łączący węzły klastra. Redundantne zasilacze w serwerze nie pomogą gdy UPS ma jedną ścieżkę zasilania i ta ścieżka pada. Rysuj architekturę i szukaj miejsc gdzie jest tylko jeden element bez alternatywy.

HA na poziomie hardware

Redundantne zasilacze to standard — serwery produkcyjne powinny mieć minimum 2 PSU podłączone do niezależnych obwodów (PDU A i PDU B). RAID dla dysków systemowych — minimum RAID 1 na dyskach systemowych, storage aplikacji w zależności od wymagań (RAID 10 dla wydajności, RAID 6 dla pojemności). Hot-spare dyski przyspieszają recovery po awarii dysku.

Spare server — gotowy serwer który można uruchomić w miejsce awaryjnego — jest często pomijany bo "jest drogi". Ale jeśli główny serwer pada i nie ma spare'a, czekasz na dostawę lub naprawę sprzętu. Przy krytycznych systemach czas oczekiwania na sprzęt (NBD — Next Business Day) oznacza co najmniej 24h przestoju, a często więcej. Cold spare jest akceptowalny, hot spare (uruchomiony i gotowy) to luksus dla naprawdę krytycznych systemów.

HA na poziomie wirtualizacji

Proxmox VE w konfiguracji klastrowej (minimum 3 węzły dla kworum) obsługuje HA Manager — automatyczne wykrycie awarii węzła i uruchomienie VM na innym. Wymaga shared storage (Ceph, NFS, iSCSI) — lokalne dyski nie działają z HA managerem. Fencing (STONITH — Shoot The Other Node In The Head) jest wymagany żeby uniknąć split-brain, gdzie dwa węzły myślą że są masterem i oba próbują pisać do storage.

Live migration działa gdy węzeł jest zdrowy i trzeba go odstawić do serwisu. HA Manager działa gdy węzeł pada nieprzewidzianie. To dwa różne scenariusze z różnymi wymaganiami. Dla live migration potrzebujesz shared storage i szybkiej sieci między węzłami. Dla HA Manager potrzebujesz dodatkowo skonfigurowanego fencingu i przetestowanych procedur — bo HA Manager który nie był testowany może nie zadziałać przy prawdziwej awarii.

HA na poziomie aplikacji

Load balancer przed aplikacją (HAProxy, nginx, lub L4 z keepalived) rozdziela ruch między instancje i wykrywa niesprawne backendy. Replika bazy danych (PostgreSQL streaming replication, MySQL Group Replication) zapewnia że dane są dostępne nawet gdy primary pada — ale wymaga mechanizmu automatycznego lub ręcznego failovera. Automatyczny failover bazy (np. Patroni dla PostgreSQL) zmniejsza RTO, ale wymaga starannej konfiguracji żeby uniknąć split-brain.

Session persistence to osobna kwestia — jeśli aplikacja trzyma stan sesji w pamięci jednej instancji, utrata tej instancji oznacza utratę sesji użytkowników. Rozwiązania: zewnętrzny store sesji (Redis, Memcached), sticky sessions na load balancerze (akceptowalne ale nieidealne), lub aplikacja bezstanowa. Każde z tych rozwiązań ma swoje implikacje dla architektury.

HA na poziomie sieci

Dwa łącza upstream od niezależnych operatorów (multihoming BGP) to HA na poziomie dostępu do internetu. Na poziomie wewnętrznym: bonding/LACP między serwerem a switchem daje redundancję przy awarii portu lub kabla, ale nie przy awarii całego switcha. Dwa fizyczne switche w konfiguracji MLAG (Multi-chassis LAG) lub podobnej dają redundancję przy awarii całego urządzenia.

Routing wewnętrzny: jeśli masz kilka VLAN-ów i potrzebujesz routingu między nimi, router lub firewall może stać się single point of failure. Active-passive firewall (np. dwa Fortigate z FGCP) lub active-active (zależnie od producenta) eliminuje ten punkt. Pamiętaj też o DNS — jeśli DNS resolver jest jeden i pada, pada całe środowisko nawet jeśli wszystko inne działa.

Backup jako uzupełnienie HA

HA i backup to dwie różne rzeczy, które się uzupełniają, nie zastępują. HA chroni przed niedostępnością — jeśli węzeł padnie, VM zostaje uruchomiona na innym. Backup chroni przed utratą danych — jeśli dane zostaną skasowane, zaszyfrowane przez ransomware lub uszkodzone przez błąd aplikacji, HA nie pomoże. Replikacja Ceph skopiuje uszkodzone dane na trzy węzły równie sprawnie jak prawidłowe.

Reguła 3-2-1 nadal obowiązuje niezależnie od poziomu HA: 3 kopie danych, na 2 różnych mediach, 1 poza główną lokalizacją. Środowisko HA w jednym datacenter nie chroni przed pożarem, zalaniem ani masową awarią sprzętu w tej lokalizacji. Backup off-site (własne drugie datacenter lub backup u zewnętrznego dostawcy) jest wymaganiem dla naprawdę krytycznych danych.

Koszt HA — od czego zacząć

Nie trzeba budować pełnej redundancji na wszystkich poziomach od pierwszego dnia. Zacznij od zidentyfikowania najpoważniejszych single points of failure w aktualnym środowisku i eliminuj je w kolejności wpływu na biznes. Typowa kolejność priorytetów: zasilanie (UPS + agregat), storage (RAID + backup), sieć (dwa łącza), wirtualizacja (klaster zamiast jednego hosta), aplikacja (load balancer + replika bazy).

Każdy krok ma realny koszt — sprzętowy, licencyjny i operacyjny (utrzymanie klastra jest droższe niż jednego serwera). Przelicz RTO i RPO na pieniądze: ile kosztuje godzina przestoju, ile kosztuje utrata danych za ostatni dzień. Porównaj to z kosztem kolejnego poziomu redundancji. To jest rozmowa którą warto przeprowadzić z działem biznesowym, nie decyzja techniczna podejmowana w próżni.