Cluster Proxmox VE a tre nodi: creazione, quorum e prime verifiche

Un cluster Proxmox VE riunisce più nodi sotto un'unica gestione: configurazione condivisa, migrazione delle macchine virtuali, replica e alta affidabilità. Alla base ci sono Corosync, che mantiene l'elenco dei nodi raggiungibili, e il quorum, che stabilisce quale parte del cluster può continuare a prendere decisioni. La procedura vale per Proxmox VE 8 (Debian 12) e 9 (Debian 13) e usa nomi generici e indirizzi riservati alla documentazione.

Prerequisiti#

Un cluster si corregge male dopo la creazione, quindi le basi vanno sistemate prima del primo comando.

• Rete dedicata a Corosync. Corosync è sensibile ai ritardi: la documentazione ufficiale indica latenze inferiori a 5 ms tra i nodi e raccomanda almeno una scheda fisica riservata al link principale. Se la rete è condivisa con backup, storage o traffico delle VM, un picco può far perdere il quorum. Tra i nodi devono passare UDP 5405-5412 e TCP 22.
• Orari sincronizzati. Su ogni nodo timedatectl deve indicare l'orologio come sincronizzato.
• Nomi e indirizzi stabili. Hostname e IP definitivi si impostano prima della creazione: la documentazione esclude di cambiarli dopo.
• Versioni allineate. Tutti i nodi dovrebbero eseguire la stessa versione di Proxmox VE.
• Nodi senza guest al momento dell'unione. Un nodo che entra non può contenere VM o container: gli ID potrebbero andare in conflitto e la configurazione in /etc/pve viene sostituita da quella del cluster. I guest da conservare si salvano con vzdump e si ripristinano dopo l'unione con un ID diverso.

Creazione del cluster#

Sul primo nodo#

Il nome del cluster è univoco e non si può cambiare in seguito. L'opzione --link0 indica l'indirizzo di nodo1 sulla rete Corosync.

pvecm create lab-cluster --link0 198.51.100.11

Sugli altri nodi#

Ogni nodo si unisce indicando l'indirizzo di un membro già presente e il proprio indirizzo sulla rete Corosync. Il comando chiede la password di root del nodo esistente e, alla prima connessione, la conferma dell'impronta del certificato. Conviene procedere un nodo alla volta, attendendo che il precedente compaia nel cluster.

pvecm add 192.0.2.11 --link0 198.51.100.12

pvecm add 192.0.2.11 --link0 198.51.100.13

Prime verifiche#

Su qualunque nodo pvecm status mostra lo stato del quorum e pvecm nodes l'elenco dei membri.

pvecm status
pvecm nodes

Cluster information
-------------------
Name:             lab-cluster
Config Version:   3
Transport:        knet
 
Votequorum information
----------------------
Expected votes:   3
Total votes:      3
Quorum:           2
Flags:            Quorate
 
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 198.51.100.11 (local)
0x00000002          1 198.51.100.12
0x00000003          1 198.51.100.13

Il cluster è in salute quando Total votes coincide con il numero dei nodi, Quorate compare tra i flag e tutti i membri sono elencati. Se non è così, journalctl -b -u corosync e systemctl status corosync indicano di solito un problema di rete o di orologio.

Il quorum: perché servono tre voti#

Ogni nodo ha un voto. Le operazioni che cambiano lo stato del cluster (avviare un guest, modificare la configurazione, migrare) sono consentite solo alla partizione che dispone della maggioranza, cioè più della metà dei voti. Con due nodi non si distingue un compagno guasto da un collegamento interrotto: se entrambi continuassero a lavorare, la configurazione divergerebbe (split-brain) e un guest su storage condiviso potrebbe partire due volte. La regola della maggioranza impedisce che due partizioni operino insieme.

Tre è dunque il minimo che tollera un guasto, e un quarto nodo non aumenta la tolleranza. Senza quorum /etc/pve diventa di sola lettura: i guest già attivi restano in esecuzione, ma non se ne possono avviare altri né modificare le configurazioni. Fanno eccezione le risorse gestite dall'alta affidabilità, dove il nodo isolato può essere riavviato dal watchdog (fencing).

QDevice per cluster a due nodi#

Con due nodi la perdita di uno blocca il cluster. Un QDevice aggiunge un voto esterno, fornito da corosync-qnetd su un host indipendente: con tre voti complessivi il cluster tollera il guasto di un nodo. La documentazione di Proxmox VE lo raccomanda per i cluster a due nodi e lo sconsiglia con un numero dispari di nodi, quindi nel cluster a tre di questa guida non serve.

apt install corosync-qnetd

apt install corosync-qdevice

pvecm qdevice setup 203.0.113.10

Servono l'accesso SSH come root all'host esterno (il setup vi copia la chiave del cluster; l'accesso con password può restare abilitato solo per la durata dell'operazione) e la porta TCP 5403 raggiungibile. L'host non deve dipendere dal cluster che arbitra: una VM ospitata sugli stessi nodi vanificherebbe lo scopo. Prima di aggiungere o rimuovere nodi il QDevice va tolto con pvecm qdevice remove; dopo il setup pvecm status mostra il flag Qdevice e tre voti totali.

Recupero d'emergenza con pvecm expected#

Se restano meno nodi del necessario, per esempio due su tre persi in modo permanente, il superstite perde il quorum e non permette più di gestire i guest. Il comando seguente porta a 1 i voti attesi e rende operativo il nodo locale.

pvecm expected 1

L'emergenza si chiude in uno di due modi: i nodi persi rientrano e il quorum si ricostituisce, oppure si rimuovono in modo definitivo con pvecm delnode nodo3, dopo aver verificato che siano spenti e non possano ricomparire in rete con la vecchia configurazione. Un nodo rimosso si reinstalla prima di riutilizzarlo.

Cosa non fare#

• Rinominare un nodo o cambiarne l'indirizzo dopo l'unione. Nome e IP compaiono nella configurazione di Corosync, nei certificati e nelle chiavi SSH, e la documentazione ufficiale esclude l'operazione. L'alternativa sicura è rimuovere il nodo, reinstallarlo con i dati corretti e unirlo di nuovo.
• Unire un nodo che ospita guest non salvati. La sua configurazione locale viene sovrascritta.
• Modificare /etc/pve/corosync.conf a mano. Se serve, si lavora su una copia, si incrementa config_version, si conserva un backup e si applica il file solo a modifica controllata.
• Fermare due nodi su tre per manutenzione. Il cluster perde il quorum.
• Usare pvecm expected come scorciatoia. È una procedura d'emergenza, non una funzione di manutenzione.

Prima di allargare o modificare il cluster conviene avere backup verificati, come descritto in Strategia di backup 3-2-1 con Proxmox Backup Server, e un monitoraggio che segnali la perdita del quorum, per esempio con Prometheus e Grafana in un container LXC.