Dwa serwery z małym rozjemcą czy od razu trzy pełne węzły? To jedna z pierwszych decyzji przy budowie klastra Proxmox i jedna z tych, które najtrudniej później odkręcić. Wyjaśniamy, jak działa kworum, co realnie daje QDevice i kiedy trzeci węzeł jest wart swojej ceny.
Klaster Proxmox opiera się na corosync, który pilnuje jednej zasady: decyzje podejmuje tylko ta część klastra, która ma większość głosów (kworum). To zabezpieczenie przed split-brain, czyli sytuacją, w której dwie odcięte od siebie połowy klastra uznają się za "tę właściwą" i obie zaczynają uruchamiać te same maszyny wirtualne. Efektem split-brain jest równoległy zapis do tych samych danych i uszkodzenie dysków VM, czego zwykle nie da się posprzątać bez odtwarzania z backupu.
Przy dwóch węzłach matematyka jest bezlitosna: każdy węzeł ma 1 głos, więc układ to 50/50. Gdy jeden węzeł pada albo traci łączność, drugi zostaje z jednym głosem na dwa możliwe. To nie jest większość, więc corosync blokuje operacje: ocalały węzeł nie uruchomi maszyn z uszkodzonego węzła, a często nie pozwoli nawet na normalne zarządzanie własnymi. Klaster formalnie działa, ale automatycznego failovera nie ma. Da się to ręcznie obejść (wymuszenie kworum), ale to interwencja administratora w środku awarii, a nie wysoka dostępność.
Pułapka z praktyki. Spotykamy klastry 2-węzłowe, w których ktoś na stałe ustawił oczekiwaną liczbę głosów na 1, "żeby działało po awarii". To otwiera drogę do split-brain przy zwykłej przerwie w sieci między węzłami. Jeśli macie taką konfigurację na produkcji, to dobry powód, żeby zamówić przegląd klastra.
QDevice (a dokładnie corosync-qdevice z usługą qnetd) rozwiązuje problem 50/50 w najtańszy możliwy sposób. To mały proces działający na dowolnej maszynie poza klastrem: mini PC w serwerowni, kontener na innym hoście, maszyna wirtualna w drugiej lokalizacji albo u dostawcy chmury. Nie trzyma żadnych danych klastra, nie uruchamia VM, nie potrzebuje mocnego sprzętu. Robi jedną rzecz: oddaje głos w kworum.
Z QDevice klaster 2-węzłowy ma 3 głosy. Po awarii jednego węzła ocalały węzeł plus QDevice mają 2 z 3 głosów, czyli większość. Kworum jest zachowane, menedżer HA może automatycznie przejąć i uruchomić maszyny z padniętego węzła. To zamienia klaster 2-węzłowy z konstrukcji "na papierze" w konfigurację z prawdziwym failoverem.
Jedno zastrzeżenie projektowe: QDevice musi stać poza klastrem, który obsługuje. Umieszczenie go jako VM na jednym z dwóch węzłów niszczy cały sens rozwiązania, bo awaria tego węzła zabiera dwa głosy naraz. Dobrą praktyką jest też osobna ścieżka sieciowa, żeby awaria jednego switcha nie odcięła rozjemcy razem z węzłem.
Uczciwie po obu stronach. Konfiguracja 2+QDevice daje:
Czego ta konfiguracja nie daje:
Trzeci pełny węzeł kosztuje, ale kupuje kilka konkretnych rzeczy. Po pierwsze, kworum działa natywnie, bez QDevice i bez dodatkowej maszyny do utrzymywania: 3 głosy, awaria jednego węzła zostawia większość 2 z 3. Po drugie, pojawia się formalna możliwość startu z Ceph, choć tu od razu zastrzeżenie: przy 3 węzłach i awarii jednego Ceph nie ma gdzie odbudować trzeciej repliki danych i pracuje w stanie zdegradowanym do czasu naprawy. Dlatego w praktyce sensowny Ceph zaczyna się od 4 węzłów. Sami produkcyjnie utrzymujemy hosting IQHost na łącznie 8 węzłach z ponad 4 TB RAM. Więcej o doborze sprzętu piszemy na stronie Serwery i storage.
Po trzecie, zapas na failover. Przy 3 węzłach obciążenie padniętego węzła rozkłada się na dwa pozostałe, więc każdy węzeł może na co dzień pracować wyżej bez ryzyka, że awaria położy resztę. Po czwarte, prace serwisowe są po prostu wygodniejsze: wyłączenie jednego węzła do aktualizacji czy wymiany dysków nie sprowadza klastra do pojedynczej maszyny bez zapasu. To robi różnicę w środowiskach, w których aktualizacje robi się regularnie, a nie raz do roku.
| Kryterium | 2 węzły + QDevice | 3 węzły |
|---|---|---|
| Budżet na start | Najniższy: dwa serwery i tani rozjemca | Wyższy: trzeci pełny serwer z licencją na zasoby, prąd i miejsce w szafie |
| Akceptowalne RPO | Minuty (replikacja ZFS, stan z ostatniej synchronizacji) | Minuty przy ZFS; bliżej zera przy współdzielonym storage lub Ceph (realnie od 4 węzłów) |
| Skala środowiska | Kilkanaście VM, które w razie awarii uniesie jeden węzeł | Kilkadziesiąt VM i więcej, obciążenie po awarii dzieli się na dwa węzły |
| Plany rozwoju | Środowisko stabilne, bez planów na Ceph | Przewidywany wzrost, docelowo Ceph i rozbudowa o kolejne węzły |
| Rekomendacja | Ograniczony budżet, kilkanaście VM, RPO w minutach OK: uczciwy wybór | Krytyczne bazy, potrzeba zapasu i planów rozbudowy: zaczynajcie od 3 (a przy Ceph od 4) |
Wdrażamy oba warianty i żaden nie jest "gorszy", o ile pasuje do wymagań. Dla firm z 12-14 maszynami wirtualnymi i ograniczonym budżetem konfiguracja 2 węzły + QDevice z replikacją ZFS to uczciwy kompromis: prawdziwy automatyczny failover za ułamek kosztu trzeciego serwera. Warunkiem jest szczera rozmowa o RPO na etapie projektu, a nie po pierwszej awarii.
Tam, gdzie w środowisku jest produkcyjna baza danych, której utrata kilku minut transakcji boli, nie udajemy, że replikacja ZFS to załatwia. Dokładamy wtedy replikację na poziomie aplikacji, na przykład replikację SQL między dwiema maszynami bazodanowymi na różnych węzłach. Klaster odpowiada za dostępność infrastruktury, a warstwa aplikacyjna za spójność danych. Do tego zawsze niezależny backup: klaster HA nie zastępuje kopii zapasowych, o czym więcej w artykule o strategii backupu 3-2-1 z Proxmox Backup Server.
Jeśli dopiero liczycie budżet całego projektu, orientacyjne widełki zebraliśmy w tekście ile kosztuje wdrożenie Proxmox. Wdrożenia klastrów zaczynają się w pakiecie Start od 25 000 zł netto, a każdy projekt poprzedzamy Etapem 0 (inwentaryzacja techniczna, 5 000 zł netto, odliczane od wdrożenia).
Tak. QDevice to lekki proces (qnetd), który potrzebuje minimalnych zasobów i stabilnego połączenia sieciowego z oboma węzłami. Mini PC, Raspberry Pi, kontener LXC na osobnej maszynie albo mała maszyna wirtualna w innej lokalizacji: każda z tych opcji działa. Ważne, żeby QDevice nie działał jako VM wewnątrz klastra, któremu ma dawać głos, bo po awarii węzła z tą VM tracicie i węzeł, i rozjemcę.
Tak. Po awarii jednego węzła drugi wciąż ma większość głosów (własny plus głos QDevice), więc menedżer HA może automatycznie uruchomić maszyny na działającym węźle. Warunek: dane muszą być dostępne na drugim węźle, w praktyce przez replikację ZFS albo współdzielony storage. Przy replikacji ZFS trzeba pamiętać, że odtworzone VM startują ze stanu z ostatniej synchronizacji.
Formalnie tak, 3 węzły to minimum dla Ceph z trzema replikami. Praktycznie jest to konfiguracja bez zapasu: po awarii jednego węzła Ceph nie ma gdzie odbudować trzeciej repliki i klaster pracuje w stanie zdegradowanym aż do naprawy sprzętu. Dlatego przy planach na Ceph rekomendujemy myśleć o 4 węzłach albo świadomie zaakceptować to ograniczenie. Sami produkcyjnie utrzymujemy łącznie 8 węzłów.
Porozmawiajmy o waszych maszynach, wymaganym RPO i budżecie. Projektujemy i wdrażamy oba warianty klastra, a każdy projekt zaczynamy od inwentaryzacji technicznej, której koszt odliczamy od wdrożenia.
Umów rozmowę techniczną