Cluster Proxmox HA: setup pratico
Un cluster Proxmox in alta disponibilità consente di mantenere operative le VM critiche anche in caso di guasto di un nodo. Il setup richiede attenzione a rete, storage condiviso e quorum, ma offre una resilienza enorme con un parco hardware accessibile.
Requisiti del cluster
Minimo 3 nodi (per quorum), rete dedicata a basso jitter (idealmente 10 GbE), storage condiviso o replicato: Ceph, NFS, iSCSI, ZFS con replica. I nodi devono avere hardware simile per evitare problemi di compatibilità CPU durante migrazione live; configura il CPU type più basso comune o usa kvm64. Per HA reale serve anche un meccanismo di fencing.
Creare il cluster
Sul primo nodo: pvecm create nomecluster. Sugli altri nodi: pvecm add IP-PRIMO-NODO. Verifica con pvecm status che il quorum sia raggiunto. La rete di corosync (cluster heartbeat) dovrebbe essere su una VLAN separata dal traffico VM per evitare split-brain.
Storage condiviso
L'HA richiede che il disco della VM sia accessibile da ogni nodo. Soluzioni comuni: Ceph integrato in Proxmox (Ceph RBD), NFS da NAS dedicato, iSCSI multipath. Per piccoli cluster ZFS con replica asincrona offre un compromesso (ma non e veramente HA, e DR con RPO non zero).
Procedura passo-passo
- Predisponi 3 nodi con Proxmox installato e rete dedicata.
- Imposta hostname, /etc/hosts e DNS coerenti tra i nodi.
- Crea il cluster e aggiungi i nodi.
- Configura storage condiviso (Ceph o NFS).
- Sposta o crea VM sul nuovo storage.
- Configura un gruppo HA con priorità per definire dove le VM devono girare di preferenza.
- Imposta fencing hardware (IPMI/iLO/iDRAC) per isolare nodi compromessi.
- Esegui test: spegnimento brusco di un nodo e verifica del failover entro 2-3 minuti.
- Documenta runbook di failover e recovery.
Fencing e quorum
Il fencing impedisce che due nodi credano di essere "primari" simultaneamente (split-brain). Proxmox supporta fencing via IPMI o watchdog hardware. Senza fencing, l'HA puo causare corruzione dati. Il quorum richiede maggioranza dei nodi attivi: con 3 nodi tollera 1 down, con 5 ne tollera 2.
Errori comuni e come risolverli
- Cluster a 2 nodi: non c e quorum reale; aggiungi un terzo (anche QDevice).
- Rete corosync sovraccarica: heartbeat persi causano isolamento; dedica una NIC.
- Mancanza di fencing: rischio split-brain e corruzione storage.
- Storage non condiviso: l'HA non funziona, le VM non possono migrare.
Domande frequenti
D: Quanto tempo dura il failover?
R: Tipicamente 1-3 minuti, includendo il riavvio della VM su altro nodo.
D: Ceph e affidabile?
R: Si, in produzione con almeno 3 OSD nodes e configurazione corretta.
D: Posso aggiungere nodi a caldo?
R: Si con pvecm add; pianifica capacita extra.
Approfondimento tecnico: corosync, QDevice e fencing
Il cuore della comunicazione cluster Proxmox e corosync: un demone basato su UDP multicast (o unicast in scenari problematici) che mantiene il quorum e propaga lo stato. La rete corosync deve essere dedicata, a bassa latenza (< 5 ms) e jitter minimo. Una rete sovraccarica o instabile causa flapping: nodi che si vedono come down quando in realta funzionano.
Il QDevice e un componente esterno (un piccolo Raspberry Pi, un VPS) che aggiunge un voto al quorum: utile per cluster a 2 nodi che altrimenti non avrebbero quorum reale. Il fencing e la garanzia che un nodo isolato venga forzatamente spento prima che le sue VM vengano riavviate altrove: senza fencing, una split-brain causa scritture concorrenti distruttive sul storage condiviso.
Scenari d'uso reali
Un provider WordPress usa cluster Proxmox a 3 nodi con Ceph per failover automatico: in caso di guasto hardware, le VM si riavviano su altro nodo in 2 minuti.
Una piccola azienda con 2 server usa cluster + QDevice + replica ZFS: HA limitata ma costi contenuti.
Un cluster a 5 nodi di una multinazionale gestisce 200 VM con bilanciamento automatico: workload distribuito ottimalmente.
Checklist operativa cluster HA
- Almeno 3 nodi o 2 nodi + QDevice.
- Rete corosync dedicata, bassa latenza.
- Storage condiviso (Ceph, NFS, iSCSI).
- Fencing configurato (IPMI/iLO).
- Test di failover trimestrale.
- Capacity per N-1 nodi (un guasto non deve saturare).
- Backup distinto dal cluster (Proxmox Backup Server).
Risorse e riferimenti
pve.proxmox.com/wiki/Cluster_Manager, Ceph documentation per storage distribuito. Linee guida su rete corosync: pve.proxmox.com/wiki/Separate_Cluster_Network. Per fencing avanzato, STONITH e i meccanismi di Red Hat HA Add-On condividono concetti applicabili.
Considerazioni economiche e organizzative
Implementare correttamente quanto descritto in questo articolo su cluster proxmox ha richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.
Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.
Glossario rapido dei termini chiave
RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).
Hai bisogno di aiuto?
Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.