Klaster HA w Proxmox — kiedy ma sens dla firmy

Wysoka dostępność, czyli HA, to mechanizm, który przy awarii jednego hosta uruchamia jego maszyny wirtualne na innym hostie w klastrze. Bez udziału człowieka i bez nocnego telefonu do administratora.

Warto nazwać, czego HA nie pilnuje. Nie chroni przed utratą danych, bo nie jest backupem. Nie chroni przed błędem w aplikacji, błędną aktualizacją ani przed usunięciem danych przez użytkownika — te zdarzenia przenoszą się na drugi host razem z maszyną. HA skraca przerwę w dostępie do systemu przy awarii sprzętu lub hosta jako całości. To wąski, ale konkretny scenariusz. Sama platforma, na której budujemy klaster, opisana jest na stronie wirtualizacji serwerów.

Klaster zwraca się tam, gdzie przestój ma policzalny koszt i jest dłuższy niż czas potrzebny na ręczne uruchomienie maszyny na innym serwerze.

Typowe przypadki: system, z którego pracuje kilkadziesiąt osób jednocześnie, produkcja pracująca w zmianach, obiekt przyjmujący klientów w godzinach, w których nie ma kto reagować, albo system obsługujący zamówienia, gdzie godzina przerwy oznacza opóźnione dostawy. Wspólny mianownik to sytuacja, w której nikt nie siedzi obok serwera, a przerwa natychmiast przenosi się na klientów.

Jeśli awaria oznacza „zadzwonię rano i ktoś to uruchomi”, a firma przez kilka godzin pracuje na papierze, wydawanie budżetu na klaster to nieostrożność, nie nowoczesność.

Na dwóch hostach nie buduje się pełnego klastra HA, bo nie ma kworum: gdy jeden host padnie, drugi nie ma z kim ustalić, kto ma rację. Da się to obejść dodatkowym elementem rozstrzygającym, ale wtedy pojawia się kolejny punkt, który trzeba utrzymywać.

Realny zysk z dwóch hostów jest inny: replikacja maszyn między nimi i szybkie, ręczne albo półautomatyczne uruchomienie po awarii. Przestój spada z godzin do minut, choć nie znika. Dla wielu firm to dokładnie tyle, ile potrzebują — i kosztuje znacznie mniej niż pełny klaster.

Od trzech hostów klaster pracuje tak, jak się to zwykle opisuje: hosty ustalają między sobą zgodę, a po awarii jednego z nich maszyny są uruchamiane automatycznie na pozostałych. Przy trzech hostach można stracić jeden i nadal mieć kworum.

Trzy hosty to też minimum, od którego sensownie działa storage rozproszony. Każdy kolejny host zwiększa odporność i wydajność, ale też koszt: więcej sprzętu, więcej prądu, więcej miejsca i więcej pracy przy aktualizacjach. Nie planuje się tego „na zapas” — planuje pod konkretny scenariusz awarii, który firma chce przetrwać.

Klaster wymaga, żeby maszyna mogła wystartować na innym hoście i mieć dostęp do tych samych danych. Są na to trzy drogi.

• ZFS na każdym hoście z replikacją — dane kopiują się między hostami w zaplanowanych odstępach. Proste i tanie, ale po awarii maszyna startuje ze stanu sprzed ostatniej replikacji.
• Ceph — storage rozproszony, dane rozłożone na wszystkich hostach. Migracja na żywo i automatyczne uruchomienie działają bez utraty ostatnich zapisów. Wymaga minimum trzech hostów i porządnej sieci.
• Zewnętrzna macierz albo serwer plików — dane poza klastrem. Rozwiązanie sprawdzone, ale wprowadza urządzenie, którego awaria zatrzymuje wszystko.

Wybór wynika z tego, jak dużo danych firma może stracić przy przełączeniu i jaką sieć ma między hostami. Bez sieci o odpowiedniej przepustowości nawet najlepszy storage nie zadziała — dlatego przy klastrach projekt sieci robimy razem z platformą, a opisujemy go na stronie sieci i serwerów.

Bywają środowiska, w których klaster HA kosztuje więcej niż problem, który rozwiązuje. Pierwszy przypadek: firma ma jeden krytyczny system i dwie maszyny, a przestój zdarza się raz na dwa lata. Drugi: sprzęt jest tak stary, że inwestycja w klaster oznacza zakup trzech nowych hostów — wtedy taniej wychodzi wymiana jednego serwera i uporządkowany backup.

Trzeci przypadek jest najczęstszy: firma chce mieć HA, ale nie ma przetestowanego backupu. Kolejność powinna być odwrotna. Klaster chroni przed awarią sprzętu, a backup przed utratą danych — i to druga sytuacja zdarza się znacznie częściej. Zanim ktoś zacznie liczyć hosty, warto przeczytać, jak wygląda test odtwarzania.

Migracja na żywo pozwala przenieść działającą maszynę z jednego hosta na drugi bez wyłączania jej — użytkownik w najgorszym razie odczuje krótkie zatrzymanie, a nie przerwę w pracy. Dzięki temu aktualizacje hostów, wymiana dysku czy prace w serwerowni przestają wymagać nocnych okien serwisowych.

To praktyczna, codzienna korzyść z klastra, której nie widać w opisach skupionych na awariach. W firmach, które pracują w zmianach, możliwość zaplanowania serwisu w godzinach pracy bywa ważniejsza niż sama odporność na awarię.

Widzimy cztery powtarzające się przyczyny. Sieć bez zapasu: jeden switch, jedna ścieżka, i awaria sieci zatrzymuje wszystkie hosty naraz, choć każdy z osobna działa. Brak aktualizacji klastra: wersje rozjeżdżają się między hostami i pierwsza próba migracji kończy się błędem. Storage pojedynczy: dane na jednym urządzeniu, więc chroniona jest tylko warstwa, która i tak rzadko zawodzi. I brak testu: nikt nie sprawdził, czy przełączenie naprawdę działa, więc wersja „działająca” istnieje tylko na papierze.

Przed budową klastra warto odpowiedzieć na trzy pytania: jaki dokładnie scenariusz awarii chcemy przetrwać, ile minut przerwy jest akceptowalne i kto to utrzyma. Koszty wdrożenia i utrzymania rozkładamy w artykule o koszcie wdrożenia Proxmox, a jeśli chcesz ocenić swój przypadek, napisz do nas.