Proxmox VE: dwa hosty z QDevice czy klaster trójwęzłowy?

Dwa hosty z QDevice mogą wystarczyć do HA dla małego zestawu usług, ale w nowym środowisku produkcyjnym warto planować co najmniej trzy węzły. Sprawdź, kiedy wariant 2+1 jest uzasadniony i czego wymaga od storage'u, sieci i serwerów.

Czy dwa hosty Proxmox VE wystarczą do HA?

Dwa hosty Proxmox Virtual Environment (Proxmox VE) z niezależnym QDevice mogą automatycznie przejmować maszyny po awarii jednego z nich, jeśli mają dostęp do danych, działający fencing i dość zasobów na chronione usługi.

Dwa hosty bez trzeciego głosu tego nie zrobią. Po awarii jednego z nich zostaje 1 głos z 2, quorum znika i HA nie ma jak przejąć usług. Dlatego w nowym środowisku produkcyjnym warto planować co najmniej trzy pełne węzły, a układ 2+1 traktować jako kompromis kosztowy dla małego, zamkniętego zakresu usług.

Artykuł dotyczy Proxmox VE 9.2, stan dokumentacji na październik 2026 r. W innych wersjach wartości domyślne i opcje mogą się różnić. Proxmox wskazuje trzy węzły jako podstawę niezawodnego quorum, opisuje QDevice jako rozwiązanie dla dwóch węzłów i dopuszcza łączenie HA z lokalną replikacją ZFS. [1–3]

Kiedy wybrać 2+1, a kiedy kupić trzeci host

Układ 2+1 ma sens, gdy chronisz niewielki zestaw VM, masz niezależne miejsce dla QDevice i możesz utrzymać wszystkie te usługi na dowolnym z dwóch hostów. Dla danych sprawdzi się redundantny storage współdzielony albo lokalny ZFS z replikacją, jeżeli dopuszczasz utratę ostatnich zapisów. Przy ograniczonym budżecie lepiej objąć HA jasno wskazane aplikacje, niż obiecywać przejęcie całego środowiska, którego jeden serwer nie udźwignie.

Trzeci pełny host jest lepszym wyborem, gdy środowisko ma rosnąć, po awarii usługi mają się rozłożyć między pozostałe serwery albo prace serwisowe nie mogą sprowadzać całej produkcji do jednego hosta. Koszt porównuj dla konfiguracji zdolnych obsłużyć awarię: dwa mocno rozbudowane serwery, arbitrator i niezależny storage bywają mniej atrakcyjne niż trzy odpowiednio dobrane węzły.

Dla Ceph uruchomionego na hostach Proxmox potrzebne są co najmniej trzy pełne serwery. Gdy wymaganiem jest brak utraty zatwierdzonych zapisów przy awarii hosta, asynchroniczna replikacja ZFS odpada; rozważ storage z odpowiednią ochroną zapisu lub replikację na poziomie aplikacji. Aplikacja, która ma działać bez przerwy potrzebnej na restart VM, wymaga własnego mechanizmu wysokiej dostępności.

Trzy węzły też mają granicę: przy standardowym głosowaniu tolerują utratę jednego. Wyłączenie hosta na serwis i awaria kolejnego to już utrata dwóch. Jeśli ten scenariusz ma być obsłużony, potrzebny jest większy klaster, a quorum, dostępność kopii danych i wydajność pozostałych węzłów trzeba sprawdzić osobno.

Co QDevice rozstrzyga podczas awarii

W układzie 2+1 każdy host ma jeden głos, a QDevice zapewnia dodatkowy głos; quorum wymaga dwóch z trzech. Usługa corosync-qnetd działa poza parą hostów. Wybierz urządzenie lub VM w niezależnej infrastrukturze, ze sprawdzoną drogą sieciową i zasilaniem. Umieszczenie arbitratora na jednym z chronionych hostów wiąże jego dostępność z awarią, którą ma pomóc obsłużyć.

• Awaria jednego hosta, QDevice dostępny: pozostały host może zachować quorum i przejąć zasoby HA, jeżeli ma ich dane i spełnia reguły uruchomienia.
• Awaria samego QDevice, hosty komunikują się: pozostają dwa głosy i quorum. Napraw arbitrator przed wyłączeniem któregokolwiek hosta.
• Awaria QDevice oraz jednego hosta: pozostały host nie ma większości. Automatyczne przejęcie usług jest zablokowane, a aktywny mechanizm HA może doprowadzić do samoodgrodzenia tego hosta przez watchdog.
• Utrata komunikacji Corosync między hostami, oba widzą QDevice: głos otrzyma tylko jedna część klastra. Odizolowany węzeł z aktywnym HA musi zostać odgrodzony, zanim jego usługi zostaną przejęte.

QDevice rozstrzyga głosowanie Corosync. Nie przechowuje dysków VM i nie zastępuje monitorów ani kopii danych Ceph. Monitoruj także jego osiągalność: sprawny host i sprawne dyski nie wystarczą do przejęcia, jeśli zabraknie quorum. [1]

Storage: trzy warianty o różnych konsekwencjach

Wybór storage'u decyduje o tym, ile danych można stracić i ile serwerów trzeba kupić. Poniższe zestawienie pokazuje różnice, a sekcje pod nim opisują każdy wariant.

Współdzielony storage — gdy oba hosty mają korzystać z tych samych danych

Ten wariant pasuje, jeżeli firma ma już odpowiednią macierz lub zamawia ją razem z klastrem. Do oferty wpisz redundancję kontrolerów i zasilania oraz niezależne połączenia hostów ze storage'em. Sprawdź zachowanie całej drogi dostępu po awarii kontrolera, portu i przełącznika. Dla iSCSI/FC wymagaj poprawnie skonfigurowanych i przetestowanych ścieżek zgodnych z dokumentacją macierzy.

Pojedynczy NAS z jednym kontrolerem pozostaje wspólnym punktem awarii obu hostów. Taki zestaw można przyjąć, jeśli wymaganie obejmuje wyłącznie awarię serwera obliczeniowego. Jeśli ma obejmować także awarię storage'u, potrzebny jest redundantny system przechowywania danych. Przy wymaganiu RPO=0 ustal, kiedy urządzenie potwierdza zapis i jak chroni potwierdzone dane.

Lokalny ZFS z replikacją — gdy dopuszczasz utratę ostatnich zapisów

Wbudowana replikacja Proxmox obsługuje lokalny backend zfspool. Po pierwszej pełnej synchronizacji przesyła przyrosty ze snapshotów. Na węźle docelowym musi być dostępny storage o tym samym identyfikatorze i wystarczającej pojemności. W specyfikacji sprzętu dla ZFS zażądaj bezpośredniego dostępu do dysków, np. przez HBA; Proxmox odradza ZFS na sprzętowym RAID z własnym zarządzaniem cache. [3, 5]

• Harmonogram domyślny: co 15 minut. Najkrótszy obsługiwany interwał: 1 minuta; najdłuższy: raz w tygodniu.
• Po błędzie zadania zwykły harmonogram jest czasowo zawieszany, a próby ponawiane co 30 minut. Alarm musi obejmować wiek ostatniej udanej repliki, a nie tylko obecność zadania.
• Po migracji VM na węzeł będący celem replikacji kierunek synchronizacji odwraca się automatycznie.
• Domyślnie replikacja korzysta z sieci migracyjnej, a przy jej braku — zarządzającej. W 9.2 można wskazać osobną Replication Network w Datacenter → Options → Replication Settings. [3]

Interwał jest planem uruchamiania zadania. O możliwej utracie danych decyduje stan ostatniej poprawnie przesłanej kopii. Przy intensywnym zapisie, błędzie zadania lub zapełnieniu storage'u replika może być starsza, niż sugeruje harmonogram.

Replikację ZFS stosuj dla usług, których właściciel akceptuje cofnięcie danych do ostatniej udanej synchronizacji. Ustal RPO — maksymalną tolerowaną utratę danych wyrażoną czasem — i sprawdź je podczas awarii próbnej. Dla systemu wymagającego zachowania wszystkich zatwierdzonych transakcji ta architektura odpada, a skrócenie interwału do minuty nie zmienia jej asynchronicznego charakteru.

Zapisy z padniętego hosta po ostatniej synchronizacji nie trafiają na przejętą maszynę. Jeśli mają znaczenie, zabezpiecz dyski tego hosta, zanim ponownie włączysz go do klastra. Po failoverze sprawdź też ręcznie spójność danych aplikacji, szczególnie baz danych: replika zawiera stan dysków z ostatniej synchronizacji, więc aplikacja może wymagać weryfikacji lub odtworzenia po starcie.

Ceph — co najmniej trzy pełne węzły

Dla hiperkonwergentnego Proxmox z Ceph dokumentacja wymaga co najmniej trzech serwerów, najlepiej podobnych. Zaleca trzy monitory oraz co najmniej 12 OSD rozłożonych równomiernie między węzły. QDevice nie zastąpi trzeciego serwera przechowującego dane. [4]

Domyślne parametry puli replikowanej to size=3 i min_size=2. Ceph dąży do utrzymania trzech kopii obiektu, a operacje I/O wymagają co najmniej dwóch. Przy rozłożeniu kopii między trzy hosty utrata jednego pozostawia dwie kopie. Klaster pracuje z obniżoną redundancją, a kolejna awaria może zablokować I/O. Proxmox ostrzega przed min_size=1 — nie obniżaj go, żeby dopasować projekt do dwóch hostów.

W małym klastrze Ceph koszt obejmuje dyski, pamięć i CPU dla usług storage'u oraz sieć. Dla ruchu Ceph zalecane jest co najmniej 10 Gb/s, a dla szybkich NVMe odpowiednio więcej. Po awarii i podczas odbudowy kopii infrastruktura musi jednocześnie obsłużyć aplikacje i ruch odtwarzania redundancji. Jeśli budżet nie obejmuje tych elementów, lepsza będzie inna architektura storage'u.

Replikacja i backup rozwiązują różne problemy

Replika umożliwia uruchomienie VM z niedawnego stanu dysków na innym hoście. Błędne dane zapisane przez aplikację lub zaszyfrowane pliki mogą trafić do kolejnej synchronizacji. Potrzebujesz również wcześniejszych punktów odtworzenia przechowywanych zgodnie z polityką retencji.

Do tego służy backup. Proxmox zaleca Proxmox Backup Server (PBS) na oddzielnym hoście. System pozwala utrzymywać historię kopii oraz wykonywać zadania weryfikacji danych. Zaplanuj niezależne miejsce przechowywania kopii, uprawnienia ograniczające ich usunięcie i odtworzenie reprezentatywnej VM. Wynik weryfikacji backupu potwierdza integralność danych kopii; dopiero test uruchomienia pokazuje, czy odzyskana aplikacja nadaje się do pracy. [6–7]

PBS nie staje się automatycznie hostem zapasowym dla HA, a odtworzenie backupu jest osobną operacją. W budżecie na 2+1 zostaw więc osobną pozycję na backup i jego utrzymanie; druga kopia dysków na drugim hoście nie zastępuje PBS.

Fencing i watchdog: skąd bierze się przerwa

Przed uruchomieniem VM na innym hoście klaster musi mieć pewność, że poprzedni węzeł nie uruchamia już tej samej maszyny. Fencing odgradza uszkodzony węzeł, chroniąc dane przed równoczesnym zapisem. Proxmox realizuje samoodgrodzenie przez watchdog: gdy aktywny stos HA nie może go odświeżać, licznik wygasa i resetuje serwer.

Timeout watchdoga wynosi według dokumentacji 60 sekund. To czas do resetu po ustaniu odświeżania, a nie czas powrotu aplikacji. Proxmox podaje około dwóch minut jako typowy czas wykrycia błędu i failoveru HA. Do oceny przerwy potrzebny jest wynik aplikacji po restarcie systemu gościa i odzyskaniu połączeń z jej zależnościami. [2]

Do nowego zakupu wybieraj serwery ze sprzętowym watchdogiem i wymagaj jego skonfigurowania oraz testu. Bez dostępnego i skonfigurowanego urządzenia Proxmox korzysta z softdog w jądrze Linux; dokumentacja ocenia ten wariant jako mniej niezależny i mniej niezawodny niż watchdog sprzętowy.

Jeśli dopuszczalna przerwa jest krótsza niż restart VM wraz z aplikacją, sam HA hypervisora nie spełni wymagania. Potrzebne będą działające równolegle instancje usługi oraz mechanizm przełączenia właściwy dla aplikacji. Planowane przenoszenie maszyn omówiono w materiale „Migracja do Proxmox VE bez przestoju”; odbiór przejęcia po nagłej awarii powinien być osobnym testem.

Co wpisać do specyfikacji sieci i serwerów

Dla Corosync Proxmox wymaga stabilnej sieci z opóźnieniami poniżej 5 ms między węzłami. W małym klastrze dedykowane łącze 1 Gb/s zwykle wystarcza; ważne są opóźnienia pod obciążeniem. Zaplanuj drugi link Corosync na innej fizycznej sieci. Dwa VLAN-y przechodzące przez ten sam port i przełącznik nie usuwają ich wspólnej awarii. [1]

Ruch storage'u, replikacji i backupu może nasycić łącza. Dobierz ich przepustowość do rzeczywistego zapisu oraz czasu synchronizacji, a próbę sieci przeprowadź podczas tych operacji. Dla QDevice sprawdź niezależną trasę z obu hostów i dostęp TCP do portu 5403 qnetd. To połączenie działa niezależnie od komunikacji Corosync między węzłami.

W układzie 2+1 każdy host musi pomieścić wszystkie chronione VM oraz narzut systemu i ZFS. Do kalkulacji pamięci przyjmij: RAM chronionych maszyn + RAM hosta i storage'u + uzgodniony zapas. Zweryfikuj też CPU, opóźnienia dysków i czas odpowiedzi aplikacji po zebraniu całego obciążenia na jednym serwerze. Sprzętu nie dobiera się według średniego wykorzystania dwóch hostów w spokojnym okresie.

Na wszystkich dozwolonych celach przejęcia muszą istnieć wymagane sieci VM, bridge'e, VLAN-y, dyski i urządzenia. Karta PCI przekazana do VM może ograniczyć możliwość uruchomienia jej gdzie indziej. Reguły HA muszą odpowiadać rzeczywiście dostępnym zależnościom. Jeśli planujesz także migracje na żywo, sprawdź zgodność modelu CPU; Proxmox nie gwarantuje migracji na żywo między procesorami różnych producentów (Intel i AMD). [2, 9]

Checklista odbioru klastra

Przed odbiorem uzgodnij listę chronionych usług, RTO — maksymalną przerwę — oraz RPO. Próby zakłócające pracę wykonuj w uzgodnionym oknie, po sprawdzeniu kopii i procedury powrotu. Każdy wynik zapisz razem z wersjami pakietów, konfiguracją testu i czasem zdarzeń.

1. Quorum i QDevice. Na obu hostach uruchom pvecm status. W zdrowym 2+1 oczekuj Quorate: Yes, Expected votes: 3, Total votes: 3 i Quorum: 2. Sprawdź flagi QDevice: A oznacza osiągalny arbitrator, V — przyznany głos. Przywrócenie łączności ma odtworzyć prawidłowy stan bez ręcznego zmieniania liczby głosów. [1]
2. Zasoby i zależności HA. Porównaj wynik ha-manager status z listą chronionych VM i regułami ich rozmieszczenia. Na każdym dopuszczonym hoście sprawdź dostęp do wymaganych dysków, sieci i urządzeń. Kryterium odbioru: każda usługa ma wykonalny wariant uruchomienia po utracie dowolnego pojedynczego hosta objętego projektem.
3. Repliki ZFS. W panelu Replication oraz w wyniku pvesr status sprawdź LastSync, Duration, FailCount i State. Porównaj komplet dysków VM z zakresem replikacji. Podczas reprezentatywnego zapisu kopia musi nadążać za przyjętym RPO, a na celu ma pozostać miejsce na wzrost danych i snapshoty. Błąd zadania ma wywołać zauważalny alarm. [3, 8]
4. Rzeczywista utrata danych. W testowej aplikacji zapisuj znaczniki czasu i identyfikatory operacji potwierdzonych klientowi. Po wymuszonej awarii hosta odczytaj ostatni zachowany znacznik na przejętej VM. Z logiem klienta ustal, które potwierdzone operacje zniknęły i jaki przedział czasu obejmują. Ten wynik porównaj z RPO.
5. Fencing oraz RTO. Podczas odcięcia komunikacji klastra sprawdź, czy węzeł zostaje odgrodzony, zanim jego VM ruszy na drugim. Odczytaj journalctl -u pve-ha-lrm na węzłach oraz journalctl -u pve-ha-crm na węźle zarządzającym HA i porównaj zdarzenia z rejestrem resetu serwera. Z klienta poza klastrem mierz czas od pierwszej nieudanej operacji do ponownego poprawnego zapisu i odczytu w aplikacji; zapisz częstotliwość prób. Wynik musi mieścić się w RTO.
6. Watchdog. Zapisz, który watchdog jest aktywny na każdym hoście: moduł wskazany w /etc/default/pve-ha-manager (WATCHDOG_MODULE) i wpis o fencingu w wyniku ha-manager status. Przy sprzętowym watchdogu sprawdź, czy moduł jest załadowany i objęty testem fencingu z poprzedniego punktu. Jeśli host korzysta z softdog, odnotuj to w odbiorze jako świadomy kompromis i powtórz ten sam test, bo to on pokazuje, czy reset faktycznie następuje. [2]
7. Awaria arbitratora i awarie złożone. Osobno odłącz QDevice przy obu działających hostach, wyłącz jeden host przy działającym QDevice oraz odetnij Corosync między hostami przy dostępnym arbitratorze. Porównaj wynik ze scenariuszami opisanymi wyżej. Utratę hosta przy niedostępnym QDevice sprawdź w środowisku testowym jako przypadek utraty quorum, z przygotowaną procedurą przywrócenia łączności.
8. Sieć i storage pod obciążeniem. Podczas replikacji lub backupu wykonuj ping między adresami Corosync i sprawdzaj logi tej usługi. Wymagaj braku utraty pakietów i dotrzymania przyjętego limitu opóźnień również pod obciążeniem. Wyłączaj kolejno pojedyncze połączenia i przełączniki przewidziane jako redundantne. Dla macierzy sprawdź utratę ścieżki i kontrolera; dla Ceph — utratę hosta oraz odbudowę kopii. Kryterium: zachowanie dostępu do danych i dotrzymanie parametrów aplikacji.
9. Wydajność po przejęciu. Uruchom uzgodniony zestaw operacji przy całym chronionym obciążeniu na pozostałym hoście w 2+1. Zapisz wykorzystanie RAM i CPU, opóźnienia I/O oraz czas odpowiedzi aplikacji. Porównaj je z pomiarem przed awarią i limitami z projektu. Uruchomienie wszystkich VM to dopiero połowa sukcesu: firma musi też móc na nich pracować.
10. Backup i powrót do normalnej pracy. Odtwórz wybraną kopię z PBS do odizolowanej sieci i sprawdź działanie aplikacji. Następnie przywróć odłączony host, potwierdź quorum, zakończenie synchronizacji lub odbudowy danych i prawidłowe rozmieszczenie usług. Odbiór obejmuje również powrót do pełnej redundancji oraz usunięcie przyczyn alarmów.

Dokumentacja i źródła

[1] Cluster Manager — quorum, QDevice i sieć klastra.

[2] High Availability — wymagania, zależności zasobów, fencing i watchdog.

[3] Storage Replication — parametry, błędy i sieć replikacji.

[4] Ceph Server — wymagania sprzętowe, monitory i pule.

[5] ZFS on Linux — wymagania dotyczące dysków i kontrolerów.

[6] Backup and Restore — kopie i odtwarzanie w Proxmox VE.

[7] Proxmox Backup Server — retencja i weryfikacja.

[8] pvesr — polecenie status.

[9] QEMU/KVM Virtual Machines — typ CPU i migracja na żywo.