Klaster Proxmox i HA krok po kroku — od trzech hostów do automatycznego failoveru

26 października 2026 · 4 min czytania · Paweł Burzyński

ProxmoxKlasterHACorosync

Pojedynczy host Proxmoksa to pojedynczy punkt awarii. Klaster daje jedno okno zarządzania, migrację na żywo i, po włączeniu HA, automatyczne uruchomienie maszyn na innym węźle, gdy jeden padnie. Pokażę minimalną, ale poprawną konfigurację: trzy węzły, osobna sieć klastrowa, współdzielony storage i HA z testem awarii.

Wymagania, których nie warto omijać

Trzy węzły (lub dwa + QDevice). Klaster z dwóch hostów bez arbitra traci kworum przy każdej awarii i HA nie zadziała.
Ta sama wersja Proxmox VE na wszystkich hostach (pveversion).
Osobna sieć dla corosync z opóźnieniem poniżej 5 ms. Corosync jest wrażliwy na latencję, nie wrzucaj go na ten sam link co backupy i storage.
Zsynchronizowany czas (chronyc tracking) i unikalne nazwy hostów wpisane w /etc/hosts każdego węzła.
Dołączany węzeł musi być pusty. pvecm add odmówi, jeśli na hoście są już VM lub kontenery.

Przykładowe adresy: sieć zarządzania 192.168.10.0/24, sieć corosync 10.10.10.0/24 (pve1 = .1, pve2 = .2, pve3 = .3).

Krok 1: utworzenie klastra

Na pierwszym węźle:

pvecm create klaster1 --link0 10.10.10.1
pvecm status

Na pozostałych hostach, każdy z własnym adresem w sieci corosync:

# na pve2
pvecm add 10.10.10.1 --link0 10.10.10.2
# na pve3
pvecm add 10.10.10.1 --link0 10.10.10.3

Polecenie pyta o hasło roota pierwszego węzła i odcisk certyfikatu. Po chwili sprawdź:

pvecm nodes
pvecm status | grep -E "Quorate|Expected votes|Total votes"

Quorate: Yes i trzy głosy to stan docelowy. Jeśli masz drugą kartę sieciową, dodaj redundantny link przy tworzeniu (--link1 192.168.10.1), corosync przełączy się na niego sam przy awarii pierwszego.

Krok 2: współdzielony storage

HA przenosi konfigurację VM na inny węzeł, ale dysk musi być tam widoczny. Masz trzy drogi:

NFS / iSCSI / Ceph — prawdziwy shared storage, zero utraty danych przy failoverze.
Replikacja ZFS — storage lokalny z kopią na innym węźle; po awarii tracisz zmiany od ostatniej replikacji (minimum 1 minuta).
Lokalny LVM bez replikacji — HA nie ma sensu, maszyna nie wstanie gdzie indziej.

Najprostszy start to NFS z istniejącego NAS-a, dodany raz dla całego klastra:

pvesm add nfs nas-vm --server 192.168.10.50 --export /volume1/pve \
  --content images,rootdir --options vers=4.1
pvesm status

Storage pojawia się na wszystkich węzłach automatycznie, bo konfiguracja /etc/pve/storage.cfg jest replikowana przez pmxcfs.

Krok 3: polityka wyłączania hosta

Domyślnie planowany restart węzła zatrzymuje maszyny HA zamiast je przenieść. Zmień to raz, w konfiguracji datacenter:

echo "ha: shutdown_policy=migrate" >> /etc/pve/datacenter.cfg
cat /etc/pve/datacenter.cfg

Od teraz reboot na węźle najpierw migruje jego zasoby HA na inne hosty, a po powrocie ściąga je z powrotem.

Krok 4: włączenie HA dla maszyny

Dodaj VM 100 do HA, określając, co ma się dziać po awarii:

ha-manager add vm:100 --state started --max_restart 2 --max_relocate 1
ha-manager status

max_restart to liczba prób restartu na tym samym węźle, max_relocate — ile razy maszyna może zostać przeniesiona, zanim HA uzna ją za błędną (error). Stan error kasujesz ręcznie przez ha-manager set vm:100 --state started po usunięciu przyczyny.

Preferowane węzły ustawiasz przez reguły afiniczności (Proxmox VE 9) albo grupy HA (Proxmox VE 8):

# PVE 9: VM 100 ma siedzieć na pve1, zapasowo pve2; pve3 tylko w ostateczności
ha-manager rules add node-affinity prod-pve1 --resources vm:100 \
  --nodes "pve1:2,pve2:1,pve3" --strict 0

# PVE 8: to samo przez grupę
ha-manager groupadd prod --nodes "pve1:2,pve2:1,pve3"
ha-manager set vm:100 --group prod

Liczba po dwukropku to priorytet. --strict 0 oznacza, że przy braku węzłów z listy maszyna może wstać gdziekolwiek, co w małym klastrze jest zwykle tym, czego chcesz.

Krok 5: fencing, czyli dlaczego failover trwa dwie minuty

Węzeł, który stracił kworum, musi zostać odcięty, zanim ktokolwiek uruchomi jego maszyny. Proxmox robi to watchdogiem: domyślnie programowym softdog, który resetuje host po około 60 sekundach bez kontaktu z klastrem. Dopiero potem (łącznie zwykle 2–3 minuty) pozostałe węzły startują VM.

systemctl status watchdog-mux pve-ha-lrm pve-ha-crm
journalctl -u pve-ha-crm -n 30

Jeśli płyta ma watchdog sprzętowy (IPMI, iTCO), wpisz jego moduł w /etc/default/pve-ha-manager jako WATCHDOG_MODULE. Nigdy nie wyłączaj fencingu, nawet „na chwilę", bo ryzykujesz dwie kopie tej samej VM piszące na jeden dysk.

Krok 6: test, zanim zrobi to życie

Najpierw migracja kontrolowana:

ha-manager migrate vm:100 pve2
watch -n2 ha-manager status

Potem prawdziwa awaria. Nie shutdown, bo zadziała polityka migracji z kroku 3. Odetnij zasilanie węzła z VM 100 (IPMI power off albo fizycznie) i obserwuj z innego hosta:

watch -n5 'pvecm status | grep Quorate; ha-manager status'

Oczekiwana sekwencja: węzeł znika z listy, po ~60 s jego zasoby przechodzą w fence, po kolejnej minucie VM 100 jest started na pve2. Zapisz czas, bo to twój realny RTO.

Dwa węzły: QDevice zamiast trzeciego serwera

Gdy trzeciego hosta nie ma, głos rozstrzygający może dać dowolna maszyna z Debianem, nawet mały VPS:

# na arbitrze
apt install corosync-qnetd
# na każdym węźle klastra
apt install corosync-qdevice
# raz, z dowolnego węzła
pvecm qdevice setup 192.168.10.60
pvecm status | grep -A3 Qdevice

Usuwanie węzła

Węzeł wyłącz na stałe przed usunięciem i nigdy nie uruchamiaj go ponownie z tą samą tożsamością w tej sieci:

pvecm delnode pve3
rm -rf /etc/pve/nodes/pve3   # dopiero gdy nie ma na nim VM

Jeśli klaster utknął bez kworum (np. padły dwa z trzech węzłów), pvecm expected 1 przywróci sterowanie na ostatnim żywym hoście. To narzędzie awaryjne: po naprawie wróć do normalnego stanu, zanim włączysz cokolwiek w HA.