Co to jest quorum w PVE
Podręcznik pvecm: kworum to minimum głosów, by rozproszona transakcja mogła się wykonać. Przy podziale sieci zmiany wymaga większość węzłów online. Bez kworum — tryb tylko do odczytu. Domyślnie jeden głos na węzeł (quorum_votes: 1). Status: pvecm status (Expected / Total votes, Quorate).
Dla HA podręcznik mówi wprost: niezawodne kworum to co najmniej trzy węzły, ta sama wersja. Przy dwóch węzłach QDevice daje trzeci głos.
Status pvecm status pokazuje Expected votes, Total votes i Quorate. Gdy Quorate: No, GUI nadal „żyje”, ale zapis konfiguracji klastra i HA stoją. To nie jest „lekki tryb serwisowy” — to ochrona przed rozjechaniem /etc/pve. Wracanie kworum bez diagnostyki sieci (bond, MTU, multicast/unicast Corosync) kończy się fencingiem „zdrowych” węzłów.
Ile węzłów: 2, 3, parzyste
| Węzły | Głosy (bez QDevice) | Przeżywa pad 1 węzła? |
|---|---|---|
| 1 | 1 | Nie ma klastra |
| 2 | 2 (trzeba 2) | Nie — 1 z 2 to nie większość |
| 2+QDevice | 3 | Tak (2 z 3) |
| 3 | 3 (trzeba 2) | Tak |
| 4 | 4 (trzeba 3) | Pad 1: tak; pad 2: nie |
| 5 | 5 (trzeba 3) | Pad 2: tak |
Wzór większości to ⌊n/2⌋+1 przy równych głosach. Przy utracie kworum na ostatnim węźle podręcznik dopuszcza obejście pvecm expected 1 — to narzędzie ratunkowe, nie architektura.
QDevice: kiedy tak, kiedy nie
QDevice Net to daemon na węzłach plus corosync-qnetd na osobnym hoście (Debian). Łączy się TCP/IP, nie musi być w LAN Corosync. Oficjalnie: wspierane dla parzystej liczby węzłów, rekomendowane dla 2. Dla nieparzystej liczby Proxmox zniechęca.
Dlaczego: parzysty klaster dostaje +1 głos. Nieparzysty dostaje N−1 głosów QDevice — wtedy pad samego QNet czyni klaster kruchym (przy 15 węzłach bez QDevice padnie 7; z QDevice, gdy QNet padnie, nie może paść żaden). Przy masowym failoverze HA jeden ocalały węzeł może nie unieść VM. Ceph i tak przestaje serwować, gdy zostanie ((N−1)/2) lub mniej OSD/MON.
Corosync, bondy i fencing
Bond jako jedyny link Corosync bywa groźny: tryby z load balancingiem przy „link up, ale cisza” dają niesymetryczną łączność i niestabilne kworum. HA może sfensować nawet zdrowe węzły. LACP: bond-lacp-rate fast po obu stronach — inaczej 3×30 s LACPDU = 90 s, a fencing HA idzie już po ok. minucie bez stabilnego kworum.
Przed usunięciem węzła z QDevice — najpierw zdjąć QDevice (FAQ pvecm). Dwa linki Corosync na rozłącznych ścieżkach są lepsze niż jeden „gruby” bond.
HA bez współdzielonego dysku
QDevice ratuje kworum, nie dysk. VM na local-ZFS nie wstanie na drugim węźle, bo wolumenu tam nie ma. HA wymaga storage widocznego na celu (RBD, NFS, iSCSI) albo replikacji ZFS zaplanowanej osobno. Live migration to inny artykuł: migracja na żywo.
Split-brain i dwa linki Corosync
Przy QDevice i podziale sieci daemon oddaje głos tylko jednej partycji — tej, którą widzi. Przy remisie (dwie równe partycje widzą QDevice) wybierany jest najniższy node id, chyba że zmienicie tie_breaker (man corosync-qdevice) i zrestartujecie usługę na wszystkich węzłach. To nie jest „HA samo zgadnie biznesowo ważniejszą szafę”.
Dwa linki Corosync na rozłącznych ścieżkach są lepsze niż jeden LACP. Sieć migracji i Ceph trzymamy osobno — saturacja linku klastra live migration’em w trakcie „niewinnego” vMotion to utrata kworum. Live migration: qm migrate --online.
Dodawanie węzłów przy QDevice
FAQ pvecm: przed dodaniem albo usunięciem węzła z klastra z QDevice — najpierw zdjąć QDevice, zmienić węzły, potem postawić QDevice ponownie, gdy liczba znów jest parzysta. Usuwanie węzła z Ceph to osobna sekwencja (OSD, MON, MGR, MDS, CRUSH), nie „pvecm delnode i po sprawie”. pvecm expected 1 zostaje narzędziem ratunkowym na ostatnim węźle, nie architekturą dwuwęzłową bez QDevice.
Konserwacja HA i kworum
Tryb konserwacji HA (osobny artykuł Tryb konserwacji HA) zdejmuje węzeł z failoveru. To nie jest to samo co utrata kworum. W konserwacji klaster nadal jest quorate i zapisuje konfigurację; bez kworum zapis stoi, nawet gdy GUI odpowiada. Mieszanie tych dwóch stanów w runbooku kończy się fencingiem w trakcie „planowanego okna”.
Przed patchowaniem: konserwacja HA, live migration gości na inne węzły (shared storage), dopiero wtedy reboot. Na local-ZFS bez replikacji nie ma dokąd zmigrować dysku — okno serwisowe to restart w miejscu albo zaplanowany cold move. QDevice na osobnym hoście (nie na jednym z dwóch hypervisorów) zostaje poza tym oknem.
Uwaga: pvecm expected 1 na ostatnim żywym węźle jest w podręczniku jako obejście. Zostawienie tej wartości po odzyskaniu węzłów rozjeżdża Expected votes. Po ratunku wracamy do liczby węzłów, nie do „na stałe expected 1”.
Zaprojektujemy kworum i HA
Trzy węzły albo dwa plus QDevice, osobne linki Corosync, storage pod failover — bez split-brain „na produkcji”.
⚡ Bezpłatna konsultacja → Reguły HA affinity