Dopo il primo server arriva spesso il secondo, e con lui la tentazione di unirli in un cluster. Proxmox VE lo permette con pochi clic: un'unica interfaccia per tutti i nodi, migrazione delle macchine virtuali da un host all'altro, configurazione condivisa. Il cluster, però, introduce un concetto che chi viene da un server singolo non conosce: il quorum. Capirlo evita la sorpresa più comune, cioè un nodo che smette di funzionare perché l'altro è spento.
Cosa condivide un cluster
In un cluster Proxmox i nodi condividono:
- la configurazione di macchine virtuali, storage e utenti, replicata da un file system di cluster;
- la comunicazione tramite Corosync, un sistema che tiene traccia di quali nodi sono presenti;
- la possibilità di migrare le macchine virtuali tra nodi.
Non condividono automaticamente i dischi. Se una VM vive sullo storage locale di un nodo, per spostarla bisogna copiarne il disco; con uno storage condiviso, come un NAS via NFS o Ceph, basta trasferire lo stato della memoria.
Il quorum, spiegato semplice
Ogni nodo ha un voto. Il cluster è operativo, si dice che è «quorato», solo se i nodi raggiungibili tra loro possiedono la maggioranza assoluta dei voti. Lo scopo è evitare lo split brain: due metà del cluster che, non vedendosi, credono entrambe di essere l'unica parte attiva e modificano la configurazione in modo divergente, o avviano la stessa macchina virtuale due volte.
Con tre nodi la maggioranza è due: se un nodo si spegne, gli altri due continuano. Con due nodi la maggioranza è ancora due: se uno si spegne, quello rimasto ha un voto su due, non ha il quorum e mette la configurazione in sola lettura. Le macchine già accese continuano a girare, ma non si possono avviare, modificare o creare altre VM.
| Nodi | Voti necessari | Guasti tollerati |
|---|---|---|
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
La tabella mostra perché i cluster si costruiscono con un numero dispari di voti: il quarto nodo non aggiunge tolleranza rispetto al terzo.
QDevice: il terzo voto senza il terzo server
Per un homelab con due server esiste una soluzione elegante: il QDevice. Si tratta di un piccolo servizio, corosync-qnetd, installato su una terza macchina qualunque, anche un single-board computer o una macchina virtuale su un dispositivo esterno al cluster. Non esegue macchine virtuali: fornisce solo un voto aggiuntivo.
Con due nodi e un QDevice i voti sono tre, e la perdita di un nodo lascia l'altro con la maggioranza. La configurazione richiede l'installazione del pacchetto sul dispositivo esterno e del client sui nodi, poi un comando di configurazione dal cluster.
Il QDevice non deve girare su uno dei due nodi: se quel nodo si spegne, si perdono due voti insieme.
La rete di Corosync
Corosync è sensibile alla latenza, non alla banda. Se i pacchetti arrivano in ritardo, perché una migrazione o un backup saturano la stessa rete, i nodi possono credersi a vicenda scomparsi. Buone pratiche:
- dedicare a Corosync una rete separata, anche solo una porta da 1 gigabit e un piccolo switch;
- configurare un secondo collegamento come riserva, che Corosync usa se il primo cade;
- non far passare traffico di storage o di migrazione sulla rete di Corosync.
Alta affidabilità: cosa promette davvero
Con il gestore HA attivo, Proxmox riavvia automaticamente su un altro nodo le macchine virtuali di un nodo che smette di rispondere. Per farlo in sicurezza, il nodo isolato deve prima fermarsi da solo: si chiama fencing e Proxmox lo realizza con un watchdog che riavvia il nodo che ha perso il quorum.
Condizioni perché funzioni:
- almeno tre voti, quindi tre nodi o due più un QDevice;
- dischi delle VM su storage condiviso o replicato; la replica ZFS tra nodi è una via praticabile in casa, ma in caso di guasto si perdono le modifiche successive all'ultima replica;
- accettare che la VM venga riavviata, non spostata a caldo: chi era collegato perde la sessione.
Nel mio lavoro consiglio di valutare se l'HA serve davvero. Per molti servizi domestici, un ripristino manuale da backup in pochi minuti è un compromesso migliore della complessità aggiuntiva.
Errori da evitare
- Rinominare un nodo dopo averlo aggiunto al cluster: è un'operazione delicata, meglio scegliere bene il nome prima.
- Aggiungere un nodo che ha già macchine virtuali: Proxmox lo sconsiglia, perché gli identificativi possono entrare in conflitto.
- Forzare il quorum con
pvecm expected 1senza capire perché si è perso: è uno strumento d'emergenza, non una soluzione permanente. - Separare un nodo dal cluster senza seguire la procedura documentata: lascia configurazioni incoerenti.
In sintesi
- Il cluster unisce gestione e migrazione, ma non condivide da solo i dischi.
- Il quorum richiede la maggioranza assoluta dei voti: con due nodi soli, un guasto blocca le modifiche.
- Un QDevice su una terza macchina esterna fornisce il voto mancante.
- Corosync vuole una rete a bassa latenza, separata dal traffico pesante.
- L'alta affidabilità riavvia le VM altrove e richiede storage condiviso o replicato: va valutata con realismo.
