Awaria serwera nie musi oznaczać telefonu o trzeciej w nocy. Dobrze zaprojektowany klaster Proxmox sam restartuje maszyny na żywym węźle, a prace serwisowe robicie w dzień, bez przestoju. Projektujemy, wdrażamy i testujemy takie klastry, tę samą technologię mamy pod własnym hostingiem.
Klaster wysokiej dostępności zmienia sposób, w jaki wasza firma przeżywa awarie i planuje prace serwisowe. Zamiast jednego serwera, od którego zależy wszystko, macie grupę węzłów, które nawzajem się pilnują.
Co istotne, wszystko powyższe jest w darmowym Proxmox VE. Płatna subskrypcja to wsparcie producenta i stabilniejsze repozytorium aktualizacji, nie odblokowanie funkcji. Szczegóły opisaliśmy w artykule o subskrypcjach Proxmox.
HA to nie magia, tylko kilka współpracujących mechanizmów. Warto je rozumieć, bo od nich zależą decyzje projektowe.
Corosync i kworum. Węzły komunikują się przez corosync i głosują nad tym, kto żyje. Decyzje podejmuje większość: w klastrze 3-węzłowym potrzeba 2 głosów, w 5-węzłowym 3. Dzięki temu klaster nie rozpadnie się na dwie połowy, z których każda myśli, że jest tą właściwą (split-brain). Konsekwencja praktyczna: parzysta liczba węzłów bez dodatkowego głosu to zły pomysł.
Fencing przez watchdog. Zanim VM zostanie uruchomiona na innym węźle, klaster musi mieć pewność, że stara kopia już nie działa. Węzeł, który straci kworum, jest automatycznie resetowany przez sprzętowy lub programowy watchdog. Bez tego mechanizmu ta sama maszyna mogłaby zapisywać dane w dwóch miejscach naraz i uszkodzić system plików.
HA manager i grupy. Dla każdej VM ustalacie politykę: czy ma być restartowana automatycznie, na których węzłach może działać i z jakim priorytetem. Grupy HA pozwalają na przykład trzymać bazę danych na węzłach z szybkim NVMe, a po awarii wracać na preferowany węzeł.
Migracja pamięci na żywo. Przy live migration Proxmox kopiuje pamięć RAM działającej maszyny na drugi węzeł w kolejnych iteracjach, a na końcu zamraża VM na ułamek sekundy, przenosi ostatnie zmienione strony i wznawia ją po drugiej stronie. Warunkiem jest wspólny dostęp do dysków (storage współdzielony lub replikowany) i sensowna przepustowość sieci.
Nie ma jednej słusznej topologii. Dobieramy ją do budżetu, wymaganego RPO (ile danych możecie stracić) i planów rozwoju.
Dwa serwery plus QDevice, czyli lekki trzeci głos na maszynie poza klastrem, który zapewnia kworum po awarii węzła. Dyski lokalne na ZFS, replikacja migawek między węzłami co ustalony interwał, RPO od minuty. To świadomy kompromis: po awarii tracicie zmiany od ostatniej replikacji, ale koszt wejścia jest o cały serwer niższy. Dla wielu firm to najlepszy stosunek ochrony do ceny. Porównanie wariantów rozpisaliśmy w artykule klaster: 2 czy 3 węzły.
Trzy serwery głosują same za siebie, awaria dowolnego z nich nie zatrzymuje klastra. Storage nadal może być ZFS z replikacją, ale trzy węzły to też minimalny sensowny start dla Ceph, jeśli chcecie z czasem dojść do RPO zero. Ten wariant daje też zapas mocy: prace serwisowe na jednym węźle nie zostawiają was bez zabezpieczenia.
Ceph trzyma każdy blok danych w kilku kopiach na różnych węzłach, więc awaria serwera nie powoduje utraty ani sekundy danych, a klaster sam odbudowuje brakujące repliki na pozostałym sprzęcie. Wymagania są konkretne: sieć storage minimum 10G, a przy dyskach NVMe realnie 25G, inaczej sieć staje się wąskim gardłem i cała inwestycja w szybkie dyski idzie na marne. Kiedy Ceph, a kiedy ZFS: rozkładamy to na czynniki w tekście Ceph vs ZFS. Nasza własna produkcja to łącznie 8 węzłów i ponad 4 TB RAM, obsługujące hosting IQHost.
Większość problemów z klastrami, które trafiają do nas na audyt, zaczyna się w sieci, nie w Proxmoxie. Klaster jest tak dostępny, jak jego najsłabsze łącze.
Tak projektujemy sieć pod HA. Bonding interfejsów do dwóch niezależnych przełączników, żeby awaria switcha nie położyła klastra. Osobny, wydzielony pierścień corosync o niskich opóźnieniach, bo od niego zależy kworum. Sieć storage i replikacji oddzielona od ruchu VM, żeby backup w nocy nie dławił komunikacji klastra. Przy 2-3 węzłach opcjonalnie bezpośredni link między serwerami pod replikację, bez udziału przełącznika: szybciej i taniej niż drugi switch 25G.
Brak fencingu. HA włączone, watchdog nieskonfigurowany albo wyłączony "bo restartował serwer". Pierwsza poważna awaria kończy się dwiema instancjami tej samej VM i uszkodzonymi danymi.
Jeden przełącznik jako SPOF. Trzy porządne serwery spięte przez jeden switch. Awaria lub aktualizacja przełącznika zatrzymuje cały klaster, mimo redundancji na poziomie węzłów.
Corosync w tym samym VLAN co backup. Nocny backup zapycha łącze, corosync traci pakiety, węzły wypadają z kworum i watchdog je resetuje. Klaster "sam się restartuje w nocy", a przyczyną jest współdzielona sieć.
Brak testów failover po wdrożeniu. Klaster postawiony, HA zaznaczone, nikt nigdy nie wyciągnął wtyczki. Pierwszy prawdziwy test odbywa się podczas prawdziwej awarii, w najgorszym możliwym momencie.
Jeśli macie już klaster i któryś z tych punktów brzmi znajomo, zacznijcie od audytu Health Check: 2-3 dni, raport z rekomendacjami, od 2 500 zł netto.
Same 2 węzły nie, bo po awarii jednego z nich drugi nie ma większości głosów i klaster traci kworum. Rozwiązaniem jest QDevice: mały, trzeci głos na dowolnej maszynie poza klastrem (może być nawet niewielki VPS albo maszyna w innej serwerowni). Z QDevice dwa węzły dają działający HA z replikacją ZFS. To świadomy kompromis: RPO liczone w minutach zamiast zera, ale koszt o jeden serwer niższy.
Nie. HA, klaster, live migration, replikacja ZFS i Ceph są w pełni dostępne w darmowym Proxmox VE. Subskrypcja nie jest licencją: daje dostęp do enterprise repo (stabilniejszy kanał aktualizacji) i wsparcie producenta. Ceny za socket CPU rocznie netto: Community 120 EUR, Basic 370 EUR, Standard 550 EUR, Premium 1 100 EUR.
HA chroni przed awarią sprzętu: VM wstaje na innym węźle w ciągu minut. Nie chroni przed skasowaniem danych, ransomware ani błędem w aplikacji, bo replikacja powiela także uszkodzone dane. Od tego jest backup na osobnym urządzeniu, na przykład Proxmox Backup Server. Poważne środowisko potrzebuje obu warstw.
Tak, pojedynczy węzeł można dołączyć do klastra, a istniejące VM przenieść bez reinstalacji. Zwykle zaczynamy od audytu obecnej konfiguracji (sieć, storage, wersje), potem projektujemy docelową architekturę i dokładamy węzły etapami, z minimalnymi oknami serwisowymi.
Opowiedzcie nam, co ma przeżyć awarię i ile danych możecie stracić. Zaproponujemy architekturę, sprzęt i wycenę. Wdrożenia od 25 000 zł netto (pakiet Start), a Etap 0, czyli inwentaryzację techniczną za 5 000 zł netto, odliczamy od ceny wdrożenia.
Umów rozmowę techniczną