Salta al contenuto

Cluster Proxmox: alta disponibilità e scalabilità per la tua infrastruttura

  • 700+ clienti attivi
  • H24 supporto in italiano
  • GDPR dati in Italia

Architettura di un cluster Proxmox

Un cluster Proxmox VE è un insieme di nodi fisici collegati tra loro e gestiti come un'unica entità tramite l'interfaccia web. L'architettura è di tipo multi-master: ogni nodo può gestire l'intero ambiente, senza un server di gestione centralizzato dedicato. Questo elimina un singolo punto di guasto ed è una delle differenze architetturali più rilevanti rispetto a piattaforme che richiedono un componente di management separato. Nella pratica, la causa più frequente di perdita di quorum non è il guasto hardware ma la manutenzione non coordinata: un aggiornamento firmware che richiede il reboot contemporaneo di due nodi su tre. La regola operativa è semplice: documentare sempre le finestre di manutenzione e non aggiornare mai più di un nodo alla volta. Per ambienti dove Ceph o una SAN non sono giustificati, Proxmox VE include un framework di replica asincrona integrato che mantiene una copia aggiornata dei dischi VM su un nodo secondario. È la soluzione più economica per ottenere HA con storage locale, e funziona bene per cluster a 2-3 nodi con workload non I/O-intensive. ------------------------------------------------------------------------

Corosync e quorum

La comunicazione tra i nodi è gestita da Corosync, il motore di cluster che si occupa della membership dei nodi e del quorum. Il quorum determina quanti nodi devono essere attivi affinché il cluster possa operare: serve la maggioranza (N/2 + 1). In un cluster a 3 nodi, il quorum si mantiene con 2 nodi attivi. Se il quorum viene perso, il cluster blocca le operazioni di scrittura e il failover automatico per prevenire scenari di split-brain.

pmxcfs: il file system del cluster

Proxmox VE utilizza pmxcfs, un file system basato su database che memorizza tutti i file di configurazione del cluster e li replica in tempo reale su tutti i nodi tramite Corosync. Ogni nodo ha sempre una copia aggiornata della configurazione dell'intero ambiente, senza bisogno di storage condiviso per i file di configurazione.

Storage: locale, condiviso e distribuito

Un cluster Proxmox supporta diverse tipologie di storage: locale (ZFS, LVM, LVMthin), condiviso (NFS, iSCSI, Fibre Channel) e distribuito (Ceph per architetture iperconvergenti). La scelta dipende dai requisiti di performance, disponibilità e budget. Per un approfondimento sulle architetture iperconvergenti con Ceph integrato, consulta la nostra guida dedicata a Proxmox HCI.

Alta disponibilità e failover automatico

Il sistema di high availability di Proxmox VE fornisce failover automatico per macchine virtuali KVM e container LXC. Quando un nodo diventa non raggiungibile e il cluster mantiene il quorum, le risorse configurate per l'HA vengono automaticamente riavviate su un altro nodo.

Fencing: isolare il nodo guasto

Prima di riavviare una VM su un altro nodo, il cluster deve avere la certezza che il nodo guasto non stia ancora accedendo ai dischi condivisi. Proxmox VE implementa il fencing tramite un meccanismo watchdog-based: ogni nodo esegue un timer hardware che deve essere resettato periodicamente dal software. Se il nodo smette di funzionare e il watchdog scade, il nodo viene automaticamente riavviato, garantendo l'isolamento. Senza fencing corretto, il rischio è la corruzione dei dati per accesso concorrente.

Il watchdog software di default funziona nella maggior parte dei casi. Per ambienti di produzione critici, è preferibile abilitare il watchdog hardware IPMI (se il server lo supporta): è più affidabile in scenari di kernel panic dove il watchdog software potrebbe non scattare. Un comando utile: wdctl per verificare che il watchdog attivo sia quello corretto.

Configurazione HA da interfaccia web

La configurazione dell'alta disponibilità avviene dalla web UI. Per ogni VM o container puoi definire: lo stato desiderato (started, stopped, disabled), il gruppo di nodi preferiti per il failover e la priorità di riavvio. Il sistema monitora continuamente lo stato dei servizi e interviene automaticamente.

Un punto operativo importante: non configurare tutte le VM come HA. Se un nodo con 30 VM va giù e tutte sono HA, i nodi rimanenti dovranno riavviarne 30 simultaneamente, con un picco di I/O e RAM che può saturare le risorse e causare un effetto domino. Configurare come HA solo le VM critiche per il business, impostando priorità di riavvio differenziate: i database prima, le applicazioni dopo.


Live migration: VM e storage senza interruzioni

------------------------------------------------------------------------

Migrazione delle VM tra nodi

La live migration consente di spostare una macchina virtuale in esecuzione da un nodo a un altro senza interruzione del servizio. La memoria della VM viene copiata iterativamente sul nodo di destinazione; quando la quantità residua è sufficientemente piccola, la VM viene brevemente sospesa (millisecondi), la memoria finale trasferita e la VM ripresa sul nuovo nodo. L'operazione è trasparente per le applicazioni e gli utenti connessi.

Migrazione dello storage

Proxmox VE supporta anche la storage live migration: spostamento dei dischi virtuali da uno storage a un altro con la VM in esecuzione. Utile per manutenzione storage, espansione della capacità o transizione verso un diverso tipo di storage.

Dalla nostra esperienza

La live migration richiede una rete cluster con banda sufficiente e latenza bassa. Con una rete a 1 GbE, la migrazione di una VM con 32 GB di RAM può richiedere diversi minuti e, se la VM scrive in memoria più velocemente di quanto la rete trasferisca, la migrazione non converge mai. Per ambienti di produzione consigliamo 10 GbE come minimo per la rete cluster, 25 GbE per cluster con molte VM ad alta occupazione di memoria.

Topologie cluster: come scegliere il numero di nodi

La scelta della topologia dipende dai requisiti di disponibilità, dal budget e dalla capacità di crescita prevista.

Cluster a 2 nodi

Configurazione minima per l'alta disponibilità. Richiede un QDevice esterno (un servizio leggero su un terzo server o VM) per mantenere il quorum quando uno dei due nodi è offline. La topologia più economica per ambienti che necessitano di failover automatico.

Cluster a 3 nodi

La topologia consigliata per ambienti di produzione. Tre nodi garantiscono il quorum nativo (2 su 3) senza QDevice. Con Ceph, tre nodi sono il minimo per una replica a 3 copie dei dati. È il punto di partenza per la maggior parte delle organizzazioni.

Cluster multinodo

Per requisiti di scalabilità e ridondanza elevati. Cinque o più nodi offrono tolleranza a guasti multipli, manutenzione su un nodo senza impatto e maggiore capacità. Con Proxmox Datacenter Manager, più cluster possono essere gestiti da un'unica console.

Dalla nostra esperienza

Il cluster a 2 nodi con QDevice è una soluzione efficace per il budget, ma con un limite operativo importante: durante la manutenzione di un nodo, il QDevice deve restare raggiungibile altrimenti il nodo rimanente perde il quorum e blocca l'HA. Per ambienti dove la manutenzione è frequente (aggiornamenti mensili, patching) il cluster a 3 nodi offre un margine operativo molto più confortevole.

Progettazione e consulenza cluster Proxmox

Progettare un cluster Proxmox VE che risponda alle esigenze specifiche della tua organizzazione richiede competenze certificate e un'esperienza consolidata su ambienti di produzione reali. Proxmox Gold Partner #1 in Italia. Rackone è il primo partner certificato Proxmox in Italia. Progettiamo cluster Proxmox VE da ambienti a 2 nodi per PMI fino a infrastrutture iperconvergenti multinodo per enti di ricerca e aziende enterprise. Il minimo per l'HA è un cluster a 2 nodi con QDevice esterno. La configurazione consigliata è 3 nodi (quorum nativo, replica Ceph a 3 copie se utilizzato). Cluster con 5+ nodi offrono maggiore ridondanza e margine di manutenzione. Se il cluster mantiene il quorum, il sistema HA rileva il guasto, isola il nodo tramite fencing e riavvia automaticamente le VM e i container HA su un altro nodo. L'ambiente VMware di origine non viene toccato. No. L'interruzione effettiva si riduce a pochi millisecondi durante lo switch finale, impercettibili per applicazioni e utenti. Richiede una rete cluster con banda adeguata (10 GbE minimo consigliato). Consigliamo di separare la rete cluster (Corosync + migrazione + eventuale Ceph) dalla rete VM. Per la rete cluster: 10 GbE minimo, 25 GbE consigliato. Per la rete VM: dipende dal traffico dei workload. I due segmenti dovrebbero viaggiare su interfacce fisiche separate. Analizziamo i tuoi requisiti e progettiamo l'architettura ottimale per la tua organizzazione: topologia, storage, rete e policy HA.

Chiama Parla con un esperto