Nod padł w klastrze Proxmox – co się dzieje z HA i jak nie stracić danych

Jest 3:00 w nocy, jeden z nodów klastra Proxmox przestaje odpowiadać. Pytanie za wszystkie pieniądze: czy maszyny z tego noda wstaną same na pozostałych, czy cały klaster się zablokuje? Odpowiedź nie zależy od szczęścia – zależy od tego, jak skonfigurowane jest kworum, HA i fencing. Większość „niespodzianek" podczas awarii to skutek decyzji podjętych (albo pominiętych) na etapie budowy klastra.

Ten tekst tłumaczy, co naprawdę dzieje się pod maską, gdzie są najczęstsze pułapki i – co równie ważne – czego nie robić pod presją, żeby z awarii jednego noda nie zrobić utraty danych.

Kworum: dlaczego klaster liczy głosy

Proxmox używa corosync do utrzymania spójnego obrazu klastra. Każdy nod ma zwykle 1 głos, a klaster działa w pełni tylko wtedy, gdy widzi większość głosów (kworum). Dlatego zaleca się nieparzystą liczbę nodów (3, 5, 7) – zawsze da się rozstrzygnąć, która „połowa" jest tą właściwą.

Co się dzieje, gdy nod traci kworum? Warstwa konfiguracji klastra (`/etc/pve`, czyli pmxcfs) przechodzi w tryb tylko-do-odczytu. Nie uruchomisz nowej maszyny, nie zmienisz konfiguracji, HA nie podejmie działań. To celowe zabezpieczenie: lepiej „zamrozić" mniejszość niż pozwolić dwóm częściom klastra działać niezależnie i nadpisać sobie dane.

Szybka diagnostyka w takiej sytuacji to `pvecm status` – pokazuje liczbę głosów i to, czy klaster ma kworum.

Pułapka klastra dwu-nodowego

Najczęstszy błąd: klaster z dwóch nodów i włączone HA. Wygląda rozsądnie, dopóki jeden nod nie padnie – wtedy ocalały ma 1 z 2 głosów, czyli nie ma większości. Efekt paradoksalny: przeżył sprzęt, ale klaster wpadł w tryb read-only i HA nie uruchomi maszyn.

Rozwiązania są dwa:

• Trzeci pełny nod – najczystsze wyjście, daje realną większość 2 z 3.
• QDevice (corosync-qnet) – jeśli trzeci serwer jest zbędny, wystarczy mała maszyna (nawet lekki VPS czy Raspberry Pi klasy „always-on") pełniąca rolę rozjemcy. Dodaje głos rozstrzygający, więc przy awarii jednego z dwóch nodów ocalały zachowuje kworum. Konfiguracja: `pvecm qdevice setup <adres-qdevice>`.

Zasada praktyczna: klaster 2-nodowy z HA bez QDevice to konfiguracja, która zawiedzie dokładnie wtedy, kiedy jej potrzebujesz.

Fencing: skąd HA wie, że maszynę można bezpiecznie wznowić

Zanim HA uruchomi maszynę z padniętego noda na innym, musi mieć pewność, że stary nod jej już nie uruchamia – inaczej ta sama VM działałaby w dwóch miejscach naraz i zniszczyła własne dane na współdzielonym storage. Od tego jest fencing.

Proxmox stosuje samofencing przez watchdog. W skrócie: nod, który stracił kworum, po określonym czasie (rzędu ok. minuty) sam się restartuje dzięki układowi watchdog (sprzętowemu lub programowemu `softdog`). Dopiero gdy HA ma pewność, że stary nod się „ogrodził", wznawia jego maszyny na zdrowych nodach. Dlatego automatyczne odtworzenie VM przez HA nie jest natychmiastowe – realnie liczy się w 1–2 minuty. To nie błąd, to bezpieczeństwo: te sekundy kupują pewność, że nie dojdzie do podwójnego uruchomienia.

Split-brain i najgorszy odruch pod presją

Split-brain to sytuacja, w której dwie części klastra jednocześnie uznają, że to one są „tą właściwą", i obie modyfikują dane. Efekt bywa nieodwracalny. Kworum istnieje właśnie po to, żeby do tego nie dopuścić.

I tu najważniejsze ostrzeżenie tego artykułu. Gdy klaster wpada w read-only, w sieci łatwo znaleźć „szybką radę": `pvecm expected 1`. Ta komenda ręcznie obniża wymaganą liczbę głosów, żeby odblokować mniejszość. Na żywym klastrze, w którym drugi node albo jego maszyny wciąż mogą działać, to prosta droga do split-brain i uszkodzenia danych. Używaj tego wyłącznie świadomie, w kontrolowanym scenariuszu odzyskiwania (np. gdy masz absolutną pewność, że reszta klastra jest wyłączona) – nigdy jako pierwszego odruchu o 3 w nocy.

Storage i sieć: bez tego HA nie zadziała

Dwa fundamenty, o których łatwo zapomnieć:

• Współdzielony albo replikowany storage. HA może wznowić maszynę na innym nodzie tylko wtedy, gdy ten node ma dostęp do jej dysków. Oznacza to Ceph (współdzielony, bez utraty danych) albo replikację ZFS (asynchroniczną – wtedy akceptujesz utratę danych z okna między replikacjami, np. ostatnich kilku minut). Maszyna na storage wyłącznie lokalnym nie wstanie nigdzie indziej.
• Dedykowana, niskolatencyjna sieć dla corosync. Corosync jest bardzo wrażliwy na opóźnienia. Jeśli ruch klastra dzieli łącze z backupem albo storage, chwilowe obciążenie potrafi „wywrócić" kworum i wywołać niepotrzebne fencowanie zdrowych nodów. Corosync powinien mieć własną sieć, najlepiej redundantną (dwa pierścienie/łącza).

Co robić, gdy nod naprawdę padł

Krótka procedura na spokojnie:

Zrobić samemu czy zlecić?

Włączyć HA w GUI potrafi każdy – i tu jest problem, bo „włączony przełącznik" tworzy złudzenie bezpieczeństwa. Realna wysoka dostępność to projekt: właściwa liczba nodów albo QDevice, dobór storage (Ceph vs replikacja ZFS) pod wymóg utraty danych, dedykowana i redundantna sieć corosync, przemyślany fencing oraz – co kluczowe – przetestowany scenariusz awarii, zanim wydarzy się naprawdę.

Projektujemy i wdrażamy klastry HA na Proxmox po polsku: dobór architektury, konfigurację kworum i fencingu, storage, a także kontrolowane testy awarii noda, żebyś wiedział, jak klaster zachowa się o 3 w nocy – zanim to sprawdzi za Ciebie los.

FAQ

Ile nodów potrzeba do sensownego HA?

Minimum praktyczne to 3 nody (albo 2 nody + QDevice jako rozjemca). Chodzi o możliwość utrzymania kworum po utracie jednego noda. Liczby nieparzyste ułatwiają rozstrzyganie większości.

Czy przy awarii noda tracę dane maszyn?

Na współdzielonym storage (Ceph) – nie, maszyny wznawiają się z tego samego stanu. Przy replikacji ZFS akceptujesz utratę danych z okna między replikacjami (np. kilku minut). Na storage lokalnym maszyna nie wstanie na innym nodzie.

Ile trwa automatyczne wznowienie maszyn przez HA?

Zwykle 1–2 minuty. Ta zwłoka to czas potrzebny na bezpieczne „ogrodzenie" (fencing) padniętego noda przez watchdog, zanim HA uruchomi jego maszyny gdzie indziej.

Czy `pvecm expected 1` naprawi zablokowany klaster?

Może go odblokować, ale na żywym klastrze grozi split-brain i utratą danych. To narzędzie ostatniej szansy do kontrolowanego odzyskiwania, nie pierwszy krok. Jeśli nie masz pewności – nie używaj.

Podsumowanie

Zachowanie klastra w chwili awarii jest w 100% konsekwencją projektu: kworum (nieparzyste nody albo QDevice), fencing przez watchdog, storage umożliwiający wznowienie i dedykowana sieć corosync. Zbuduj to poprawnie, przetestuj awarię „na sucho" – i awaria noda o 3 w nocy będzie nudnym zdarzeniem, a nie kryzysem.

Planujesz klaster z wysoką dostępnością albo chcesz zweryfikować istniejący? Umów konsultację, policz subskrypcje w kalkulatorze, albo napisz na proxmox@polsoft.pl / zadzwoń 32 209 80 39 (pon.–pt. 8:00–16:00).