Proxmox cluster

Proxmox VE: guida alla virtualizzazione 2/2

Scopri cos’è Proxmox VE, vantaggi e limiti, cluster Ceph, alta affidabilità, backup, disaster recovery per aziende private e pubblica amministrazione.

Indice

Proxmox cluster: come funziona il clustering

High availability: cosa succede se un cluster Proxmox si guasta

Proxmox e Ceph: costruire un’infrastruttura iperconvergente

Quanto è affidabile Proxmox in produzione?

Backup con Proxmox Backup Server

Disaster recovery con Proxmox, perchè non è la stessa cosa dell’HA

Proxmox nella Pubblica Amministrazione

Proxmox per aziende e settore privato

Quanto è difficile imparare e amministrare Proxmox?

Quando Proxmox è una buona scelta

Proxmox è adatto a un’infrastruttura business-critical?

Conclusioni

Proxmox Cluster: come funziona il clustering

Uno dei passaggi che trasforma Proxmox da semplice hypervisor a piattaforma data center è la possibilità di aggregare più server all’interno di un cluster.

I nodi Proxmox lavorano secondo una logica multi-master e utilizzano Corosync per la comunicazione del cluster. La configurazione è replicata attraverso pmxcfs e l’ambiente utilizza un sistema di quorum, cioè una maggioranza di voti, per stabilire quali nodi possono prendere decisioni sul cluster.

Proxmox raccomanda preferibilmente almeno tre voti per creare un cluster stabile. Nei piccoli cluster a due nodi è possibile utilizzare un QDevice, cioè un terzo voto esterno che aiuta a risolvere situazioni in cui i due nodi non riescono più a comunicare fra loro.

Il quorum è fondamentale perché previene una delle condizioni più pericolose nei sistemi distribuiti: due parti dello stesso cluster che ritengono entrambe di essere quella corretta e continuano a modificare le risorse.

Per questo motivo la rete Corosync deve essere particolarmente stabile e a bassa latenza. Proxmox suggerisce di evitare che traffico storage o backup possa saturare la stessa connessione utilizzata per la comunicazione del cluster.

La progettazione della rete è quindi importante quanto la scelta dei server.

High Availability: cosa succede se un server Proxmox si guasta

Proxmox mette a disposizione un HA Manager per proteggere le VM e i container considerati critici.

Se un nodo non è più disponibile, il cluster rileva il problema e, dopo aver verificato la situazione e protetto la consistenza del cluster tramite quorum e fencing, può riavviare i guest HA su altri nodi disponibili. Le risorse necessarie al guest devono naturalmente essere raggiungibili anche dal nodo di destinazione.

È importante comprendere la natura di questa funzionalità.

La high availability di Proxmox è normalmente una HA basata sul riavvio del workload. Non significa che la stessa macchina virtuale stia girando contemporaneamente e in perfetta sincronia su due server fisici.

Ci sarà quindi un intervallo durante il quale viene identificato il guasto, viene gestito il fencing e la VM viene avviata su un altro nodo.

Per molti servizi business questo modello è adeguato, soprattutto quando applicazioni e database dispongono a loro volta di meccanismi di resilienza.

Per altri workload con requisiti estremamente stringenti potrebbe invece essere necessario progettare l’alta disponibilità anche a livello applicativo.

Questa distinzione dovrebbe sempre essere affrontata durante la progettazione attraverso due indicatori: RTO, Recovery Time Objective, e RPO, Recovery Point Objective.

Proxmox e Ceph: costruire un’infrastruttura iperconvergente

Una delle combinazioni più interessanti è quella fra Proxmox VE e Ceph.

Ceph è una piattaforma open source per storage distribuito. Con Proxmox può essere installata direttamente sugli stessi nodi che eseguono le VM, ottenendo così una infrastruttura iperconvergente, o HCI, nella quale compute e storage fanno parte degli stessi server.

Proxmox integra la gestione di Ceph nella propria GUI e supporta sia RBD, utilizzato tipicamente per i dischi delle macchine virtuali, sia CephFS per storage file distribuito. Ceph distribuisce e replica i dati fra differenti dispositivi e nodi, offrendo caratteristiche di self-healing e riducendo la dipendenza da un singolo sistema storage centrale.

Un cluster Proxmox/Ceph può quindi sopportare la perdita di dischi o nodi, entro i limiti definiti dal livello di replica e dai failure domain configurati.

Questa architettura elimina la necessità di una SAN tradizionale in molti scenari e permette di aumentare progressivamente compute e storage aggiungendo server al cluster.

Ma Ceph non rende automaticamente affidabile qualsiasi infrastruttura.

La progettazione della rete diventa fondamentale.

Nei benchmark pubblicati da Proxmox, una rete 10 Gbit/s può diventare rapidamente il collo di bottiglia anche con pochi SSD molto veloci. Anche 25 Gbit/s può essere saturata in determinati workload, mentre i test a 100 Gbit/s spostano progressivamente il limite verso altri componenti dello stack.

Questo è un esempio importante di come l’affidabilità e le prestazioni non dipendano semplicemente dal software scelto.

Un buon cluster HCI deve essere progettato considerando numero e tipologia degli OSD, RAM disponibile, CPU, NVMe o SSD utilizzati, replica, failure domain, rete storage, rete Corosync, traffico delle VM e capacità necessaria durante le fasi di recovery.

Commodity hardware non significa hardware improvvisato.

Un’infrastruttura business-critical necessita comunque di componenti adeguati, alimentazioni ridondate, networking resiliente, monitoraggio e procedure di manutenzione.

Abbiamo raccontato qui come Proxmox + Ceph possano ospirare una soluzione come Nextcloud ad esempio.

Quanto è affidabile Proxmox in produzione?

La risposta breve è: Proxmox può essere utilizzato per infrastrutture enterprise e business-critical, ma l’affidabilità finale dipende dall’architettura molto più che dal nome dell’hypervisor.

Un cluster ben progettato può combinare ridondanza dei server, storage distribuito, live migration, high availability e backup indipendenti.

Un cluster progettato male può invece creare dipendenze difficili da diagnosticare.

Tra i punti più delicati vi sono la perdita del quorum, la congestione della rete Corosync, l’insufficiente capacità dello storage durante una ricostruzione Ceph, la mancanza di spazio libero, configurazioni di rete non ridondate e backup che non sono mai stati realmente testati.

La qualità operativa si misura quindi anche nella capacità di affrontare eventi anomali: rottura simultanea di più dischi, failure di uno switch, manutenzione di un nodo, aggiornamento dell’intero cluster o perdita di un sito.

Una delle caratteristiche delle infrastrutture realmente affidabili è che questi eventi vengono simulati prima che accadano.

Backup con Proxmox Backup Server

La presenza di un cluster ad alta disponibilità non elimina la necessità di backup.

High Availability e backup proteggono da problemi differenti.

La HA cerca di mantenere disponibile un servizio quando un server si guasta. Il backup protegge da cancellazioni accidentali, corruzione dei dati, errori amministrativi, ransomware e altri eventi che possono rendere inutilizzabili anche dati perfettamente replicati su tutti i nodi del cluster.

Proxmox VE dispone di funzionalità native di backup, ma per ambienti più strutturati la soluzione naturale è Proxmox Backup Server.

PBS utilizza backup incrementali e deduplica dei dati per ridurre l’impatto sul network e lo spazio occupato. Le copie possono essere cifrate e sottoposte a verifica dell’integrità; è inoltre possibile sincronizzare i backup verso sistemi remoti per realizzare copie off-site.

Con Proxmox Backup Server 4.2 sono state ampliate anche le possibilità di utilizzo di storage object S3-compatible come backend e le funzioni legate alla sincronizzazione e alla cifratura server-side.

Queste caratteristiche permettono di progettare strategie molto più solide rispetto a un semplice snapshot locale.

Uno snapshot, infatti, non è un backup se rimane nello stesso storage e nello stesso dominio di guasto dei dati originali.

Disaster Recovery con Proxmox: perché non è la stessa cosa dell’HA

Un altro errore frequente è considerare un cluster Proxmox automaticamente equivalente a un sistema di disaster recovery.

Non è così.

Un cluster HA protegge principalmente dal guasto di alcuni componenti dell’infrastruttura locale.

Se però l’intero data center viene reso indisponibile da incendio, allagamento, interruzione prolungata dell’alimentazione, errore operativo grave o attacco informatico, la presenza di tre o cinque nodi nello stesso edificio serve a poco.

Il Disaster Recovery richiede un secondo dominio di failure.

Questo può significare un secondo data center, una sede geografica separata o un’infrastruttura esterna dalla quale sia possibile ripristinare i workload.

Proxmox Backup Server può contribuire a questo modello attraverso la sincronizzazione dei backup verso sistemi remoti. In altri progetti può essere utilizzata anche la replica ZFS o possono essere costruite architetture multi-site più articolate.

Ma la tecnologia costituisce soltanto una parte del DR.

Occorrono una definizione chiara degli RPO e RTO, banda sufficiente per trasferire i dati, capacità di calcolo sul sito secondario, configurazioni di rete documentate, credenziali disponibili durante l’emergenza e soprattutto procedure di disaster recovery periodicamente testate.

Una strategia completa può essere sintetizzata in tre livelli distinti:

High Availability → mantenere operativo il servizio quando un componente si guasta.

Backup → poter tornare a una copia corretta dei dati.

Disaster Recovery → poter ripristinare l’intero servizio in un altro dominio di failure.

Abbiamo raccontato qualcosa in più su questo tema in questo articolo.

Proxmox nella Pubblica Amministrazione

L’adozione di tecnologie open source assume particolare interesse nella Pubblica Amministrazione.

L’articolo 68 del Codice dell’Amministrazione Digitale prevede che le amministrazioni effettuino una valutazione comparativa tecnica ed economica delle soluzioni disponibili tenendo conto di principi come economicità, efficienza, tutela degli investimenti, riuso e neutralità tecnologica.

Fra le tipologie da valutare sono esplicitamente incluse anche le soluzioni software libero o a codice sorgente aperto, accanto al software cloud e alle soluzioni proprietarie.

Questo non significa che una Pubblica Amministrazione debba automaticamente scegliere Proxmox perché open source.

Significa invece che una soluzione come Proxmox può entrare pienamente all’interno della valutazione comparativa.

Per un ente pubblico alcuni vantaggi possono essere particolarmente rilevanti.

L’accessibilità del codice sorgente permette una maggiore verificabilità della tecnologia. La possibilità di utilizzare differenti server, storage e partner riduce il rischio di dipendere integralmente da un singolo produttore. La portabilità dei workload e l’utilizzo di standard aperti possono inoltre facilitare la definizione di una exit strategy.

Dal punto di vista economico, l’assenza di edizioni che bloccano specifiche funzionalità consente anche di rendere più trasparente la relazione fra funzionalità tecnologiche e servizi di supporto.

Ma per un ente pubblico rimangono fondamentali altri elementi: SLA, cybersecurity, compliance, continuità operativa, competenze disponibili, responsabilità contrattuali, supporto professionale e capacità di aggiornare l’infrastruttura per tutto il suo ciclo di vita.

Open source non significa automaticamente sicurezza, sovranità o conformità. Questi risultati dipendono da come la tecnologia viene progettata, gestita e governata.

Proxmox per aziende e settore privato

Nel settore privato Proxmox può essere utilizzato in scenari molto differenti.

Una PMI può consolidare più server fisici in un piccolo cluster a tre nodi e centralizzare backup e ripristino.

Un’impresa manifatturiera può ospitare ERP, database, file server, servizi Active Directory, applicazioni di produzione e sistemi gestionali mantenendo l’infrastruttura all’interno del proprio stabilimento.

Una software house o un provider può utilizzare template, API e automazione per creare rapidamente nuovi ambienti.

Organizzazioni più grandi possono integrare Proxmox con SAN, NAS e networking enterprise esistenti oppure costruire cluster HCI basati su Ceph.

Un altro vantaggio riguarda la possibilità di mantenere workload Windows e Linux all’interno dello stesso ambiente.

Nel 2026 il supporto Arm64 apre inoltre la strada a nuove possibilità nell’edge computing, nei data center ad alta densità e nei workload AI, anche se la scelta dell’architettura hardware deve naturalmente essere valutata sulla base della compatibilità applicativa.

Il beneficio principale per l’impresa non dovrebbe però essere descritto semplicemente come “risparmio sulle licenze”.

È più corretto parlare di controllo del cosiddetto TCO (total cost of ownership), flessibilità architetturale e riduzione della dipendenza tecnologica.

Quanto è difficile imparare e amministrare Proxmox?

Uno dei punti di forza di Proxmox è che la prima esperienza può risultare sorprendentemente semplice.

L’installazione è guidata, la GUI è intuitiva e creare una prima macchina virtuale richiede poco tempo.

Questa semplicità iniziale può tuttavia generare un’impressione sbagliata.

Installare Proxmox è relativamente semplice. Gestire bene un’infrastruttura Proxmox enterprise è un altro mestiere.

Su un singolo server è sufficiente comprendere virtualizzazione, networking di base, storage e backup.

Passando a un ambiente produttivo diventano importanti Debian/Linux, ZFS o altri filesystem, VLAN, bonding, firewall, aggiornamenti, monitoraggio e troubleshooting.

In un cluster HA occorre capire Corosync, quorum, fencing, storage condiviso, replica e live migration.

Con Ceph bisogna aggiungere concetti come OSD, monitor, pool, placement group, CRUSH, failure domain, replica, recovery e gestione delle performance.

Un’infrastruttura multi-site aggiunge infine networking geografico, RPO, RTO, procedure di DR e test periodici.

La stessa offerta formativa ufficiale Proxmox distingue un corso dedicato al Deployment and Management da uno specifico per Clustering and Shared Storage. Il percorso completo richiede 28 ore e include Ceph, HA, Corosync, QDevice, networking, backup, API, failure scenario e troubleshooting.

Questo fornisce una buona indicazione della curva di apprendimento e anche noi proponiamo tramite dei nostri partner un’academy dedicata.

Un sistemista con esperienza Linux e virtualizzazione può diventare produttivo abbastanza rapidamente sulle attività quotidiane.

Diventare competente nella progettazione e diagnosi di cluster Proxmox/Ceph business-critical richiede invece esperienza specifica.

Per questo motivo le aziende dovrebbero valutare non soltanto quale tecnologia installare, ma anche chi la gestirà nei tre o cinque anni successivi.

Quando Proxmox è una buona scelta

Proxmox è particolarmente interessante quando un’organizzazione cerca una piattaforma di virtualizzazione aperta, vuole ridurre il lock-in, dispone o può acquisire competenze Linux e desidera mantenere flessibilità nella scelta di server, storage e networking.

È molto adatto anche alle aziende che vogliono costruire cluster iperconvergenti con Ceph oppure sostituire infrastrutture di virtualizzazione proprietarie con una piattaforma nella quale le funzionalità non dipendono dall’acquisto di specifiche edizioni software.

Può essere utilizzato sia per piccoli cluster sia come componente di infrastrutture più ampie.

Un’analisi seria deve considerare anche i casi contrari.

Una realtà completamente integrata con un ecosistema VMware complesso, con forte dipendenza da NSX, vSAN, automazioni proprietarie o specifiche certificazioni applicative potrebbe sostenere costi di migrazione superiori ai benefici immediati.

Analogamente, un ambiente profondamente Microsoft potrebbe trovare vantaggioso continuare a utilizzare Hyper-V e gli strumenti già conosciuti internamente.

In altri casi un’organizzazione potrebbe preferire un’appliance HCI come Nutanix per ridurre al minimo le responsabilità di integrazione tra hardware, storage e hypervisor.

Infine, un’azienda priva di competenze Linux che non intende formare il proprio personale o affidarsi a un partner specializzato potrebbe non sfruttare pienamente i vantaggi di Proxmox.

La libertà offerta da una piattaforma open source comporta anche una responsabilità maggiore nelle scelte architetturali.

Proxmox è adatto a un’infrastruttura business-critical?

Sì, a condizione che il progetto venga affrontato come un’infrastruttura enterprise e non come l’installazione di un semplice hypervisor.

Questo significa dimensionare correttamente hardware e network, costruire un cluster coerente con i failure domain, separare opportunamente i traffici critici, monitorare storage e quorum, implementare backup indipendenti, definire RPO e RTO e soprattutto testare le condizioni di guasto.

La tecnologia può fornire gli strumenti necessari.

Il livello reale di affidabilità dipende però dalla qualità del progetto e delle persone che lo gestiscono.

Ed è probabilmente questo il punto più importante da comprendere quando si valuta Proxmox.

Proxmox riduce molte barriere tecnologiche e commerciali della virtualizzazione enterprise, ma non elimina la necessità di competenza.

Conclusioni

Proxmox VE è passato da essere una soluzione conosciuta soprattutto all’interno della comunità Linux a diventare una piattaforma che può essere seriamente presa in considerazione nella progettazione di infrastrutture enterprise.

La combinazione di KVM, LXC, ZFS, Ceph, clustering, high availability e Proxmox Backup Server permette di costruire architetture che vanno dal singolo nodo fino a data center iperconvergenti e ambienti distribuiti.

I suoi vantaggi principali sono la flessibilità, l’apertura dello stack, il controllo sui costi e una minore dipendenza da un singolo vendor.

I suoi limiti emergono soprattutto quando si confonde la facilità della prima installazione con la semplicità della gestione enterprise.

Per utilizzare Proxmox in ambienti business-critical servono una corretta progettazione del cluster, storage adeguato, networking ridondato, una strategia di backup e disaster recovery e competenze capaci di intervenire quando il comportamento dell’infrastruttura non corrisponde allo scenario ideale.

Per questo motivo la domanda da porsi non dovrebbe essere soltanto:

“Proxmox è sufficientemente affidabile?”

ma piuttosto:

“La nostra infrastruttura Proxmox è stata progettata e viene gestita in modo sufficientemente affidabile?”

È su questa differenza che si misura il successo di un progetto di virtualizzazione.

Se stai valutando una nuova infrastruttura Proxmox, la migrazione da VMware o la realizzazione di un cluster Proxmox/Ceph, il primo passo dovrebbe essere un assessment dell’ambiente esistente: workload, storage, networking, backup, requisiti RPO/RTO e competenze necessarie alla gestione.

Richiedi un assessment della tua infrastruttura Proxmox.

[VEDI LA PRIMA PARTE DELL’ARTICOLO]

ITServicenet open source supportato

ISCRIVITI ALLA NEWSLETTER

Vuoi ricevere aggiornamenti da ItServiceNet