Problemi affrontati
- Un singolo host rappresentava un punto di guasto unico: un problema hardware fermava tutte le macchine virtuali.
- Aggiornamenti e riavvii richiedevano di fermare l'intero ambiente, con finestre di manutenzione difficili da pianificare.
- Senza storage condiviso, i dischi virtuali non erano disponibili su un secondo nodo in caso di guasto.
- Senza quorum e fencing ben definiti, la perdita del collegamento tra i nodi poteva portare la stessa VM ad avviarsi in due punti (split-brain).
Soluzione implementata
Il cluster è composto da tre nodi Proxmox VE collegati da una rete dedicata ai servizi di cluster, separata dal traffico delle macchine virtuali. Ogni nodo usa un pool ZFS locale e le VM critiche sono replicate in modo asincrono verso gli altri nodi. L'HA manager sorveglia le risorse registrate e, se un nodo si guasta, le riavvia su un nodo superstite a partire dai dischi replicati. Quorum a maggioranza e fencing con watchdog impediscono che una VM sia attiva su due nodi contemporaneamente. La migrazione a caldo consente di svuotare un nodo prima della manutenzione.
Risultati
- Il guasto di un nodo non richiede più un intervento urgente: le VM protette ripartono in automatico su un altro nodo.
- Gli aggiornamenti dei nodi si eseguono a rotazione, spostando prima le VM con la migrazione a caldo e senza fermare i servizi.
- L'entità massima della perdita di dati dopo un failover è nota e governabile, perché dipende dall'intervallo di replica scelto per ogni VM.
- Le procedure di recupero dopo la perdita di un nodo o del quorum sono scritte e provate, non improvvisate.
Descrizione tecnica
Il progetto descrive il cluster di virtualizzazione a tre nodi del mio homelab, pensato per tollerare il guasto di un singolo server senza un intervento manuale immediato.
Architettura
Il cluster è composto da tre nodi Proxmox VE con hardware equivalente. Ogni nodo dispone di due reti distinte: una per gestione e traffico delle macchine virtuali, collegata allo switch gestito, e una dedicata ai servizi di cluster e alla replica. Con tre nodi il quorum a maggioranza resta valido anche quando uno si ferma: i due nodi rimasti continuano a governare il cluster.
Le configurazioni sono distribuite dal file system di cluster di Proxmox VE, mentre i dischi delle VM risiedono in pool ZFS locali. La replica asincrona copia a intervalli regolari i dischi delle macchine protette verso gli altri nodi.
Componenti e scelte
- Corosync gestisce appartenenza al cluster e quorum. È sensibile alla latenza: se la stessa rete trasporta anche replica e migrazioni, conviene aggiungere un secondo collegamento di riserva e limitare la banda della replica.
- ZFS con replica è stato preferito a uno storage condiviso o distribuito per contenere complessità e requisiti hardware. Il compromesso è che dopo un failover mancano i dati scritti dopo l'ultima replica.
- HA manager registra le risorse da proteggere e le riavvia su un nodo superstite. Il fencing basato su watchdog impedisce che la stessa VM resti attiva su un nodo isolato.
ha-manager add vm:100 --state started
pvesr create-local-job 100-0 nodo2 --schedule "*/15"Nota
La replica ZFS è asincrona: l'intervallo scelto per ogni VM determina quanti dati recenti possono andare persi dopo un failover. I carichi che non tollerano alcuna perdita richiedono uno storage condiviso o distribuito.
Verifiche e collaudo
Prima di considerare concluso il progetto sono state provate: lo spegnimento brusco di un nodo, con controllo del riavvio automatico delle VM protette; la perdita temporanea della rete di cluster; la migrazione a caldo per svuotare un nodo prima di un aggiornamento; il rientro del nodo e la ripresa della replica. Le procedure di recupero dopo la perdita del quorum sono scritte, insieme al salvataggio periodico delle configurazioni dei nodi.
Possibili evoluzioni
Tra gli sviluppi possibili: un voto esterno (QDevice) per ambienti a due nodi, uno storage distribuito come Ceph per eliminare la perdita di dati in failover, l'integrazione con Proxmox Backup Server e l'automazione della creazione delle VM. Il funzionamento del quorum è approfondito in Cluster Proxmox VE a tre nodi: creazione, quorum e prime verifiche.