Cluster HA con Proxmox e 2 nodi: configurare correttamente Quorum, QDevice e Fencing

Un cluster HA con Proxmox e 2 nodi è nella pratica un caso particolare: si allestisce rapidamente, ma sui temi del Quorum (decisione a maggioranza nel cluster) e del Fencing (isolamento netto di un nodo difettoso per evitare la corruzione dei dati) è decisamente più esigente rispetto a un classico insieme a 3 nodi. Il motivo è semplice: con esattamente due voti non c’è maggioranza senza un terzo «metronomo». Non appena la comunicazione o lo storage vacillano, si rischiano situazioni di «Split Brain» — cioè due parti che ciascuna crede di essere l’istanza valida.

Questo articolo mostra in modo pratico come risolvere correttamente il Quorum con due nodi Proxmox (QDevice), come implementare e testare realisticamente il Fencing in Proxmox (incluso il Watchdog) e quali strategie di controllo e di fallback aiutano in esercizio. Il focus è sugli impatti su disponibilità, integrità dei dati e operatività — non sui dettagli dei framework.

Cluster HA con Proxmox e 2 nodi nella pratica

In Proxmox la comunicazione di cluster si basa su Corosync (messaggistica di cluster) e la configurazione del cluster risiede in pmxcfs (Proxmox Cluster File System, un filesystem di configurazione distribuito, dipendente dal quorum). Per le decisioni del cluster Corosync utilizza un Quorum: solo quando è raggiunta una maggioranza la vista del cluster è considerata «valida» e le azioni in scrittura sul cluster sono permesse.

Con tre nodi è robusto: due su tre costituiscono maggioranza. Con due nodi è fragile senza ausili: se un nodo o solo la connessione cade, rimane un voto — e quello non è una maggioranza. Il cluster si blocca allora (nel migliore dei casi). Nel peggiore i amministratori aggirano i meccanismi di protezione del quorum e rischiano lo Split Brain: entrambe le parti continuano a funzionare, scrivono sullo stesso storage o eseguono azioni HA contraddittorie.

Importante per la pianificazione: «HA» non è solo «la VM si avvia su un altro host». HA significa soprattutto decisioni coerenti in caso di guasto. Per questo servono o almeno tre voti o una «terza voce» esterna e controllata.

Principio di base: QDevice come terza voce per il Quorum di Proxmox

La soluzione pulita per due nodi Proxmox è un QDevice. Non si tratta di un altro host Proxmox, ma di un aiuto per il quorum: un servizio esterno (qnetd, Corosync Quorum Net Daemon) mette a disposizione tramite rete un voto aggiuntivo. I nodi del cluster si collegano come client (qdevice) a questo servizio. In questo modo, in caso di guasto o partizione, può di nuovo emergere una maggioranza: 1 nodo + QDevice = 2 voti (maggioranza di 3).

Perché funziona: QDevice non prende decisioni di HA, ma funge da testimone controllato che assegna a quale partizione viene data la voce aggiuntiva. Questo riduce nettamente il rischio di split‑brain, ma non sostituisce il Fencing. Perché anche con il quorum un nodo può essere „ancora in funzione“, ma già insicuro (p. es. lo storage si blocca, il kernel si blocca, timeout I/O). In questi casi serve un meccanismo che garantisca: Solo un host può continuare a scrivere sulle risorse condivise.

Requisiti e controllo del design prima dell’implementazione

Prima di configurare QDevice o Fencing, chiarite le condizioni quadro. Molte installazioni a 2 nodi non falliscono per Proxmox in sé, ma per assunzioni non espresse riguardo rete, storage o alimentazione.

1) Rete: almeno due percorsi, latenza definita, MTU coerente

Per Corosync non conta la «banda», ma la latenza stabile e basse perdite di pacchetti. Pianificate idealmente reti separate (o VLAN) per management/cluster (Corosync) e traffico VM. Se usate un’interfaccia Corosync dedicata, assicuratevi MTU identiche e una configurazione coerente degli switch. «Jumbo Frames solo da qualche parte» è un classico per partizioni sporadiche.

2) Storage: Shared Storage vs. Replicazione

In scenari HA con Proxmox ricorrono spesso due modelli:

• Shared Storage (p. es. iSCSI/NFS/SAN): Entrambi gli host vedono lo stesso datastore. Vantaggio: la VM può essere avviata rapidamente sull’altro host. Rischio: uno split‑brain può corrompere lo storage se entrambi gli host scrivono contemporaneamente.
• Storage replicato (p. es. replicazione ZFS): i dati sono sincronizzati/replicati periodicamente tra gli host. Vantaggio: meno scritture simultanee sullo stesso block device. Svantaggio: RPO/RTO dipendono dagli intervalli di replicazione e dal processo di failover.

Per entrambi vale: senza Fencing lo Shared Storage in un ambiente a 2 nodi è particolarmente rischioso. Anche con QDevice il Fencing dovrebbe essere previsto come «ultima istanza».

3) Out-of-Band-Management e Watchdog

Per un Fencing affidabile serve tipicamente un’interfaccia out-of-band come IPMI (gestione BMC) o una PDU commutabile. In alternativa esistono meccanismi basati sullo storage (p. es. SBD), che nelle ambienti Proxmox però spesso si trovano fuori dal percorso standard. Inoltre dovrebbe essere attivo un Watchdog: un timer hardware o del kernel che riavvia l’host quando il sistema «si blocca» e non lo «alimenta» più regolarmente (keepalive). Questo affronta i deadlock in cui un host ha ancora alimentazione ma non prende più decisioni sicure.

Implementazione: configurare QDevice (qnetd) per due nodi Proxmox

La raccomandazione dal punto di vista operativo: eseguite il servizio QDevice su un terzo sistema, indipendente dai due host Proxmox (altro circuito/UPS, idealmente altro rack/segmento di ubicazione). Può essere una piccola VM o un mini‑server. Ciò che conta meno è la performance e più la raggiungibilità e percorsi di rete puliti.

Passo 1: Installare QNetd sul QDevice‑Host

Esempio per un sistema Debian/Ubuntu come QDevice‑Host:

sudo apt update
sudo apt install -y corosync-qnetd
sudo systemctl enable --now corosync-qnetd
sudo systemctl status corosync-qnetd

Assicuratevi che il firewall permetta la porta di qnetd (per impostazione predefinita TCP 5403). In reti RESTrittive questo è spesso il primo ostacolo: Corosync comunica internamente tipicamente via UDP/Multicast o UDP/Unicast, mentre qnetd utilizza TCP.

Passo 2: Allineare l’ora e la risoluzione dei nomi

I componenti del cluster sono sensibili alla deriva dell’orologio. Attivate NTP/Chrony su tutti i sistemi. Inoltre la risoluzione dei nomi dovrebbe essere stabile (DNS o /etc/hosts), perché certificati e identità possono avere un ruolo con qdevice/qnetd.

Passo 3: Registrare QDevice nel Proxmox‑Cluster

Su un nodo Proxmox (tipicamente quello che ha inizializzato il cluster) integrate QDevice. Proxmox fornisce a questo scopo pvecm (Proxmox VE Cluster Manager).

# Status prüfen
pvecm status

# QDevice hinzufügen (Hostname oder IP des QNetd-Hosts)
pvecm qdevice setup <QNETD_HOSTNAME_ODER_IP>

Il processo di setup genera e distribuisce le chiavi/certificati necessari e riscrive di conseguenza la configurazione di Corosync. Successivamente verificate di nuovo lo stato del cluster:

pvecm status
pvecm qdevice status

Cosa aspettarsi in un cluster a 2 nodi: oltre ai due voti dei nodi, vedrete informazioni aggiuntive di quorum fornite da QDevice. Se QDevice non è raggiungibile, in caso di guasto il quorum tornerà al problematico modello a 2 voti.

Insidie tipiche con QDevice

• QDevice nello stesso segmento Layer‑2 dei due nodi, ma sulla stessa porta dello switch: se lo switch fallisce, anche QDevice cade. Il «terzo testimone» non è quindi indipendente.
• QDevice come VM sullo stesso cluster Proxmox: questo è un circolo vizioso. Se il cluster vacilla, vacilla anche la VM che dovrebbe stabilizzare il quorum.
• Regole firewall vaghe: qnetd richiede connettività TCP stabile. Perdita di pacchetti o TLS‑Inspection sul percorso possono causare disconnessioni sporadiche.
• Tentativi di tuning dei timeout di Corosync troppo aggressivi: in reti piccole timeout più brevi sembrano «più veloci», ma aumentano i falsi positivi in caso di brevi interruzioni. Prima misurare, poi modificare.

Fencing in Proxmox: Perché il quorum da solo non basta

Anche con QDevice vale: il quorum indica solo, chi ha il diritto di decidere. Non dice se un altro nodo è realmente fermo. È proprio qui che entra in gioco il Fencing (spesso chiamato anche STONITH: «Shoot The Other Node In The Head»). Obiettivo: se un host deve considerarsi guasto dal punto di vista del cluster, venga spento o resettato in modo affidabile prima che risorse (VM, Storage) vengano eseguite sull’altro host.

In Proxmox l’HA è gestita tramite il HA Manager integrato. Il HA Manager può gestire i servizi (VM/Container) e spostarli in caso di guasto. Attenzione: se entrambi i nodi credono simultaneamente di essere „attivi“, l’HA può eseguire azioni errate senza fencing. Con Shared Storage questo è particolarmente pericoloso, perché i blocchi di dati possono essere scritti in parallelo.

Opzioni di fencing realistiche in configurazione a 2 nodi

• IPMI/Redfish Power Off/Reboot: Il classico nell’ambito server. Presupposto: la BMC è raggiungibile, separatamente protetta e non tramite la stessa rete del segmento affetto dal problema.
• PDU commutabile / Smart Power: Funziona anche se la BMC è instabile. Deve però essere gestita in modo sicuro a livello organizzativo (diritti di accesso, logging).
• Watchdog + auto-fencing: Se l’host rileva internamente di essere in uno stato insicuro (p. es. perde quorum/cluster), può riavviarsi autonomamente. Non sostituisce il fencing esterno, ma aumenta la robustezza contro stati „appesi“.

Importante: uno „shutdown pulito“ non è fencing. Il fencing deve essere, in caso di dubbio, duro, perché proprio nel caso di guasto l’operazione „pulita“ spesso non funziona più in modo affidabile.

Attivare e verificare il watchdog in Proxmox (Best Practice)

Un watchdog è un meccanismo che resetta il sistema quando non risponde più. Sotto Linux è spesso disponibile /dev/watchdog tramite un modulo kernel (es. iTCO_wdt sulle piattaforme Intel). Proxmox può usare il watchdog per l’HA, per evitare di funzionare ‚mezzo morto‘ in situazioni di deadlock.

Passo 1: Verificare se è disponibile un dispositivo watchdog

ls -l /dev/watchdog* || true

# Kernelmeldungen zum Watchdog
dmesg | grep -i watchdog || true

# Geladene Module
lsmod | grep -i wdt || true

Se non compare alcun dispositivo, verificate le opzioni BIOS/UEFI (Watchdog/Server Management) e i moduli kernel appropriati. In ambienti virtualizzati il watchdog può essere fornito dalla piattaforma VM; su Bare Metal è tipicamente fornito dall’hardware/chipset.

Passo 2: Verificare la configurazione del watchdog in Proxmox

A seconda della versione di Proxmox e della configurazione, il watchdog viene abilitato tramite servizi di sistema/componenti HA. Come controllo rapido in esercizio:

systemctl status pve-ha-lrm pve-ha-crm || true
journalctl -u pve-ha-lrm -u pve-ha-crm --since "-2h" | tail -n 200

Interpretazione: non cercate servizi „verdi“, ma indicatori che i componenti HA siano attivi e che non si verifichino timeout ricorrenti o RESTart-loop. Se l’HA non è utilizzata, il watchdog RESTa comunque utile come rete di sicurezza — ma in questo caso i vostri processi operativi (Monitoring/Alerting) devono rilevare in modo affidabile gli host bloccati.

Checklist pratica: test da eseguire prima del primo failover HA

Prima che VM produttive girino come risorse HA, esegua test controllati. L’obiettivo non è „funziona una volta“, ma „capire quando non funziona e come reagire“.

1) Baseline dello stato del cluster e del quorum

pvecm nodes
pvecm status

# Corosync-Health grob prüfen
systemctl status corosync
journalctl -u corosync --since "-1h" | tail -n 200

Prestare attenzione alla perdita di pacchetti, ai token timeout e ai ricorrenti cambi di membership. Un cluster a 2 nodi deve funzionare in modo „noioso“: niente rejoin continui, nessun flapping.

2) Verificare lo stato del QDevice e le dipendenze

pvecm qdevice status

# QNetd vom Node aus erreichen
nc -vz <QNETD_HOSTNAME_ODER_IP> 5403

Se la connessione TCP fallisce sporadicamente, risolva il problema prima dell’attivazione dell’HA. Altrimenti, in caso di errore rimarrete senza voto di maggioranza.

3) Simulazione di caduta del link: isolare la rete Corosync

Isoli in modo controllato l’interfaccia Corosync (non quella di management, così da mantenere la possibilità di amministrare) e osservi cosa accade: una parte ottiene il quorum? L’altra rimane nettamente bloccata? È qui che si verifica se QDevice e il disegno di rete funzionano.

Osservazioni durante il test:

watch -n 2 'pvecm status; echo; pvecm qdevice status'

Se entrambe le parti continuano a sembrare „attive“ o le azioni HA risultano poco chiare, è un segnale d’allarme: dovrete ripianificare con cura fencing/isolamento e i percorsi di rete.

Quadri d’errore tipici e troubleshooting in esercizio

Quadro d’errore A: „Cluster hat kein Quorum“ nach kurzem Netzruckler

Cause: perdita di pacchetti sul percorso Corosync, problemi di buffer/queue degli switch, MTU mismatch, QoS/Policing, switch virtuali con drop. Nei setup a 2 nodi lo si nota immediatamente, perché non esiste una terza voce che stabilizzi la visione.

Procedura:

• Controllare i log di Corosync per token timeout.
• Misurare il percorso di rete: drops sulle NIC/porte switch, errori, CRC, duplex.
• Se possibile: configurare una seconda rete Corosync (ridondanza), invece di „affinare“ i timeout.

Quadro d’errore B: QDevice ist erreichbar, aber Quorum verhält sich „unerwartet“

Cause: QDevice non indipendente (condivide la causa del guasto), problemi di risoluzione dei nomi/certificati, sessione TCP instabile, routing asimmetrico. Verifichi che effettivamente entrambi i nodi parlino stabilmente con qnetd e che qnetd stesso sia in funzione senza interruzioni.

Controlli rapidi:

# Auf dem QDevice-Host
systemctl status corosync-qnetd
journalctl -u corosync-qnetd --since "-2h" | tail -n 200

Quadro d’errore C: VM läuft nach Failover, aber Storage ist inkonsistent oder „stuck“

Questo è il caso pericoloso: quorum/HA hanno reagito „in qualche modo“, ma senza fencing sicuro l’host precedente può ancora eseguire I/O o mantenere lock. A seconda dello storage (NFS, iSCSI, Cluster‑FS, Ceph) si manifesta come blocchi, errori del filesystem o dischi VM corrotti.

Misure:

• In caso di dubbio: spegnere forzatamente l’host interessato (Out-of-Band) prima di proseguire il debug.
• Controllare i log dello storage (lato Target/Controller). Molte cause non risiedono nell’hypervisor.
• Rilasciare le risorse HA solo quando è chiaro che non sono attivi „Doppelwriter“.

Raccomandazione di implementazione: design HA minimale e robusto a 2 nodi

Se per ragioni di budget o spazio dovete rimanere su due nodi, l’obiettivo è un design che reagisca in modo predicibile in caso di errore. Un pacchetto minimale e pragmatico è il seguente:

• 2 host Proxmox con percorsi di rete separati per Corosync/gestione/traffico VM (almeno logicamente via VLAN, preferibile fisicamente).
• 1 host QDevice indipendente (qnetd), non eseguito sui due host Proxmox.
• Fencing out-of-band (IPMI/Redfish o PDU) come processo di emergenza definito, incluse responsabilità e vie di accesso.
• Watchdog attivo e testato, per mitigare stati di blocco.
• Runbooks per blocchi di partizione/storage: chi spegne quale host e quando, come si risincronizza, come si valida la coerenza dei dati?

Questo è meno „glamourös“ rispetto alle liste di funzionalità, ma riduce guasti reali e soprattutto i rischi sui dati.

Strategia di fallback e recovery: cosa fare se Quorum/Fencing reagisce in modo errato?

In pratica bisogna assumere che almeno una volta si presenti uno stato ambiguo: partizione parziale, storage-freeze, BMC non raggiungibile, failover HA bloccato. È allora fondamentale avere una sequenza di recovery conservativa che protegga i dati.

Sequenza di recovery conservativa (collaudata in esercizio)

1. Fermare le scritture: se è coinvolto uno storage condiviso e sospettate scritture doppie, date priorità allo spegnimento forzato di un nodo (OOB Power Off) prima di tentare una riconfigurazione „gentile“.
2. Stabilizzare lo stato del cluster: soltanto quando è chiaro quale host debba essere „Master“, ripristinate Corosync/Quorum (percorso di rete, raggiungibilità di qnetd).
3. Validare lo storage: a seconda del backend: controlli del filesystem, log del controller di storage, sessioni iSCSI, lock NFS. Obiettivo: nessuna incoerenza silente.
4. Attivare i servizi HA in modo controllato: non mettere subito „tutto in autopilota“, ma gradualmente, con monitoraggio su latenza I/O, lock, errori del kernel.

Regola operativa: è preferibile impiegare 10 minuti in più per decidere correttamente che passare 10 ore a recuperare i dati. Due nodi non perdonano ambiguità.

Conclusione finale: 2 nodi sono possibili – ma solo con disciplina

Un cluster HA con Proxmox e 2 nodi può essere gestito in modo affidabile se compensate consapevolmente la debolezza sistemica (mancanza di maggioranza naturale). QDevice non è un „nice-to-have“, ma la base per raggiungere il Quorum in modo sensato in caso di guasto. Fencing e Watchdog sono le reti di sicurezza che impediscono corruzione dei dati e stati indefiniti quando la realtà (blocchi dello storage, flap di rete, host parzialmente degradati) colpisce.

Se state pianificando ora: considerate QDevice e Fencing fin dall’inizio, testate i guasti critici in modo controllato e documentate una procedura di recovery conservativa. Così un „piccolo“ cluster a 2 nodi diventa un setup che in esercizio non vive di speranze, ma di stati chiari.

Per questo tema sono importanti anche Proxmox Qdevice e Proxmox Fencing. L’articolo inquadra questi aspetti in modo comprensibile e mostra su cosa conta nella pratica.