Proxmox Cluster HA: Checklist Completa Installazione e Verifica (2026)

Quando un’organizzazione si affida a un’infrastruttura virtualizzata, la disponibilità è tutto. Immagina una situazione in cui un cluster Proxmox HA è stato installato in produzione, con test di failover eseguiti diligentemente in un ambiente di staging. Tutto sembra funzionare a dovere. Poi, un venerdì sera, un nodo fisico cede. Le VM dovrebbero migrare automaticamente, ma invece rimangono bloccate per 45 minuti. La causa? Un quorum configurato in modo errato, un dettaglio che, pur funzionando in un ambiente di test isolato, è diventato un collo di bottiglia critico in produzione. Questo scenario non è un’ipotesi, ma una lezione appresa sul campo, che sottolinea l’importanza di una checklist di installazione e verifica rigorosa per Proxmox Cluster HA. In questa guida, esploreremo i passaggi essenziali per costruire un cluster Proxmox ad alta disponibilità, assicurandoci che sia non solo funzionante, ma anche resiliente agli imprevisti. Un cluster HA ben configurato può ridurre i tempi di inattività del 90% rispetto a un singolo server (Fonte: Gartner, 2025).

Prerequisiti: Rete Dedicata e NTP Sincronizzato

Prima di iniziare la creazione del cluster Proxmox, è fondamentale predisporre l’ambiente correttamente. Due elementi sono assolutamente critici per la stabilità e l’affidabilità del tuo cluster HA: una rete dedicata per il traffico del cluster (Corosync) e una perfetta sincronizzazione temporale tramite NTP su tutti i nodi.

Rete dedicata per il traffico del cluster

Il traffico di Corosync, il cuore comunicativo del cluster Proxmox, è sensibile alla latenza e alle disconnessioni. Dedicare una scheda di rete fisica e, idealmente, una VLAN separata per questo traffico, è una best practice. Questo isola il heartbeat del cluster da altri carichi di rete, come il traffico delle VM o quello di gestione, prevenendo congestioni che potrebbero portare a split-brain o a decisioni errate sul quorum. Assicurati che i link siano gigabit o 10 gigabit per prestazioni ottimali.

NTP sincronizzato su tutti i nodi

La sincronizzazione precisa dell’ora tra tutti i nodi del cluster è vitale. Discrepanze anche minime possono confondere Corosync, portando a problemi di quorum e, potenzialmente, a split-brain, dove i nodi non riescono a concordare sullo stato del cluster. Configura i tuoi nodi Proxmox per utilizzare server NTP affidabili e verifica regolarmente la loro sincronizzazione. Puoi controllare lo stato di NTP con comandi come timedatectl status o ntpq -p.

Installazione del Cluster e Quorum Device

Con i prerequisiti soddisfatti, possiamo procedere con l’installazione del cluster Proxmox. Il processo è relativamente semplice, ma la configurazione del quorum, specialmente per cluster con un numero pari di nodi, richiede attenzione.

Creazione del cluster

Inizia creando il cluster sul primo nodo. Questo nodo diventerà il “master” iniziale. Dal terminale o dalla shell Proxmox, esegui:

pvecm create mycluster

Sostituisci mycluster con un nome significativo per il tuo cluster. Questo comando inizializza il cluster e genera le chiavi di autenticazione necessarie.

Aggiunta di nodi al cluster

Successivamente, aggiungi gli altri nodi al cluster. Su ciascun nodo che vuoi aggiungere, esegui:

pvecm add <IP_NODO_MASTER>

deve essere l’indirizzo IP del nodo su cui hai creato il cluster. Ti verrà chiesta la password di root del nodo master per l’autenticazione. Ripeti questo passaggio per tutti i nodi che desideri aggiungere.

Verifica dello stato del cluster

Dopo aver aggiunto tutti i nodi, verifica lo stato del cluster da qualsiasi nodo con:

pvecm status

Questo comando ti fornirà informazioni sui nodi attivi, lo stato del quorum e l’appartenenza al cluster.

Configurazione del Quorum Device (QDevice)

Per cluster con un numero pari di nodi (es. 2, 4, 6), è consigliabile configurare un QDevice. Il QDevice è un host esterno leggero (es. un Raspberry Pi o una VM su un’altra infrastruttura) che agisce come voto aggiuntivo, prevenendo lo split-brain in caso di fallimento di metà dei nodi. Senza un QDevice, un cluster con 2 nodi perderebbe il quorum se uno dei nodi fallisse, bloccando tutte le VM HA. L’aggiunta di un QDevice garantisce che il cluster possa mantenere il quorum anche con un singolo nodo operativo in un cluster a due nodi. Puoi installarlo con apt install qdevice e configurarlo tramite pvecm qdevice setup.

Controlla lo stato del quorum con:

corosync-quorumtool -s

Storage Condiviso: Ceph o NFS/iSCSI

Lo storage condiviso è un requisito fondamentale per l’alta disponibilità. Senza di esso, le VM non possono migrare tra i nodi in caso di failover. Proxmox supporta diverse soluzioni, ma Ceph e NFS/iSCSI sono le più comuni.

Ceph: Storage Distribuito e Resiliente

Ceph è una soluzione di storage software-defined, distribuito e ad alta resilienza, integrata nativamente in Proxmox. Offre un’ottima scalabilità e tolleranza ai guasti. L’installazione di Ceph richiede dischi dedicati su ciascun nodo.

Per inizializzare Ceph (sostituisci l’IP con la tua rete Ceph):

pveceph init --network 10.10.10.0/24

Crea i monitor (MON) e gli OSD (Object Storage Daemons) su ciascun nodo:

pveceph createmon
pveceph createosd /dev/sdb # Sostituisci /dev/sdb con il tuo disco dedicato

Infine, crea un pool per le tue VM:

pveceph createpool vm-storage

NFS/iSCSI: Soluzioni di Storage Esterne

Se disponi già di un NAS o SAN, puoi utilizzare NFS o iSCSI. Queste soluzioni sono più semplici da configurare rispetto a Ceph per cluster più piccoli, ma la loro disponibilità dipende dalla disponibilità del dispositivo di storage esterno. Assicurati che il collegamento di rete allo storage sia ridondato e ad alta velocità.

HA Groups e Policy di Failover

Una volta che il cluster è operativo e lo storage condiviso è configurato, puoi definire le politiche di alta disponibilità per le tue VM e container.

Configurazione degli HA Groups

Gli HA Groups permettono di raggruppare VM/Container e definire regole specifiche per il loro comportamento in caso di fallimento di un nodo. Puoi specificare quali nodi possono ospitare determinate VM, definire priorità e limitare il numero di migrazioni. Questo è cruciale per bilanciare il carico e prevenire che tutte le VM critiche finiscano su un singolo nodo superstite.

Policy di failover

All’interno degli HA Groups, puoi configurare policy come max_relocate (numero massimo di tentativi di ricollocazione), max_restart (numero massimo di riavvii) e restricted (per limitare le VM a un sottoinsieme di nodi). Queste policy sono fondamentali per gestire il comportamento del cluster durante un incidente, evitando cicli infiniti di riavvii o migrazioni indesiderate.

Controlla lo stato dei servizi HA con:

ha-manager status

Test di Failover e Verifica Funzionamento

Il passo più critico dopo l’installazione è testare il failover. Un cluster HA non testato è un cluster che non sai se funzionerà quando ne avrai più bisogno. Il 38% dei fallimenti di cluster HA sono dovuti a configurazioni non testate (Fonte: IDC, 2024).

Test di failover manuale

Per testare il failover, puoi simulare il fallimento di un nodo o migrare manualmente una VM. Per migrare una VM da un nodo all’altro:

ha-manager crm-command migrate <VMID> <NODO_DESTINAZIONE>

è l’ID della macchina virtuale e è il nome del nodo verso cui vuoi migrarla. Osserva il comportamento della VM e assicurati che riparta correttamente sul nuovo nodo.

Simulazione di un guasto

Il test più realistico è spegnere forzatamente un nodo (es. tirando il cavo di alimentazione, se l’ambiente lo permette, o usando shutdown -h now dal nodo stesso). Monitora attentamente il cluster per assicurarti che le VM HA migrino automaticamente e ripartano senza interventi manuali. Verifica i log del cluster (journalctl -u pve-ha-lrm e journalctl -u pve-ha-crm) per eventuali errori.

Monitoring del Cluster con Prometheus + Grafana

Un cluster Proxmox HA robusto richiede un monitoraggio proattivo. Integrare Prometheus e Grafana ti permette di avere visibilità in tempo reale sulle metriche chiave del cluster, come lo stato dei nodi, l’utilizzo delle risorse, la latenza dello storage e lo stato del quorum. Configura alert per soglie critiche (es. un nodo offline, quorum perso, problemi di latenza storage) in modo da essere avvisato prima che un problema diventi un disastro.

Errori Comuni e Troubleshooting

• Split-brain: Si verifica quando i nodi perdono il quorum e non riescono a decidere quale sia la versione corretta dello stato del cluster. Spesso causato da problemi di rete Corosync o NTP non sincronizzato. Il QDevice è la soluzione principale per prevenirlo.
• Problemi di rete Corosync: Latenza elevata o disconnessioni sulla rete dedicata di Corosync possono causare instabilità del cluster. Verifica i cavi, le schede di rete e la configurazione della VLAN.
• Storage non disponibile: Se lo storage condiviso non è accessibile da tutti i nodi, il failover non può avvenire. Verifica la connettività di rete allo storage e lo stato del servizio di storage (Ceph, NFS, iSCSI).
• Configurazione HA errata: VM non configurate per l’HA, o policy troppo restrittive, possono impedire il failover. Rivedi attentamente le configurazioni degli HA Groups e delle singole VM.

FAQ — Domande Frequenti

Qual è la differenza tra un cluster Proxmox e l’alta disponibilità?

Un cluster Proxmox permette di gestire più nodi da un’unica interfaccia e condividere risorse. L’alta disponibilità (HA) è una funzionalità aggiuntiva che, in caso di fallimento di un nodo, migra automaticamente le VM e i container critici su un nodo sano, minimizzando i tempi di inattività. Richiede storage condiviso e una corretta configurazione del quorum.

È necessario un QDevice per ogni cluster Proxmox HA?

Un QDevice è fortemente raccomandato per cluster con un numero pari di nodi (es. 2, 4). Aiuta a prevenire lo split-brain garantendo sempre una maggioranza di voti per il quorum, anche se metà dei nodi del cluster dovesse fallire. Per cluster con un numero dispari di nodi (es. 3, 5), non è strettamente necessario ma può comunque aumentare la robustezza.

Quale storage condiviso è il migliore per Proxmox HA?

La scelta dipende dalle esigenze. Ceph è eccellente per scalabilità, resilienza e integrazione nativa con Proxmox, ma richiede dischi dedicati e una curva di apprendimento. NFS o iSCSI sono più semplici da implementare se si ha già un NAS/SAN, ma dipendono dalla disponibilità e dalle prestazioni del dispositivo esterno. Ogni soluzione ha pro e contro in termini di complessità, costi e prestazioni.

Come posso testare il failover senza impattare la produzione?

Il modo più sicuro è replicare l’ambiente di produzione in un ambiente di test separato e lì eseguire test distruttivi. In produzione, si può iniziare con migrazioni manuali di VM non critiche. Per test più