VMware vSphere → Proxmox VECaso anonimizzato
Un ente su due sedi passa da VMware vSphere a un cluster Proxmox VE distribuito
Due sale server in edifici diversi, requisiti di continuità operativa da rispettare e un contratto VMware in scadenza. La sfida è garantire che i servizi restino attivi anche se un'intera sede si ferma.
- Da
- VMware vSphere su 2 sedi
- Verso
- Proxmox VE stretch cluster + Ceph
- Dimensione
- 2 sedi, ~120 VM
- Durata
- 4 mesi + acquisto
- Tipo
- Progetto reale, anonimizzato
Il contesto
Un ente pubblico con due sedi nella stessa città gestisce circa centoventi macchine virtuali su VMware vSphere, distribuite su due sale server collegate in fibra. I servizi interni, come protocollo, contabilità e posta, e quelli rivolti ai cittadini, come portale e sportelli online, devono restare disponibili anche in caso di guasto di un'intera sede. Oggi questo requisito è coperto da una replica tra le due sale e da procedure manuali di ripartenza.
Il contratto VMware è in scadenza e l'ente, con un processo di acquisto lungo e un budget definito, non può sostenere il rinnovo alle nuove condizioni.
I vincoli
- Continuità operativa: i servizi critici devono ripartire automaticamente se una sede si ferma.
- Scadenza non negoziabile: la migrazione deve chiudersi prima della fine del contratto VMware.
- Documentazione: ogni scelta deve essere documentata per i controlli interni e per gli audit.
- Dati in sede: nessun servizio può essere spostato su cloud pubblico.
L'architettura scelta
L'assessment misura latenza e banda tra le due sedi: la latenza resta sotto i 5 ms e i collegamenti in fibra sono due, su percorsi diversi. La raccomandazione è un unico stretch cluster Proxmox VE, con tre nodi in ciascuna sede e storage Ceph che tiene due copie dei dati in ogni sede, quattro in totale. Così ogni sede conserva da sola una copia completa e ridondata, anche se nel frattempo si guasta un nodo. Per evitare che un'interruzione del collegamento faccia credere a entrambe le sedi di essere rimaste sole, situazione chiamata split-brain, un nodo di spareggio in un terzo edificio, raggiungibile da entrambe le sedi, porta il voto decisivo per il cluster e un monitor Ceph.
Le macchine virtuali sono classificate per criticità. Quelle critiche hanno alta disponibilità con regole che le fanno ripartire nell'altra sede. Le meno critiche ripartono manualmente secondo un runbook. I backup vanno su Proxmox Backup Server con replica incrociata tra le sedi.
Come è andata
Prima del progetto, acquisto. Sul capitolato tecnico preparato nell'assessment l'ente acquista i server con la propria procedura. Questa fase non rientra nei quattro mesi.
Mese 1, design. Classificazione dei servizi, misure di rete, design del cluster e del quorum. Il design viene presentato e approvato prima di procedere.
Mese 2, deploy e test di guasto. Installazione dei nodi nelle due sedi e del nodo di spareggio. Il collaudo comprende lo spegnimento simulato di un'intera sede: le macchine di test ripartono nell'altra sede senza intervento manuale e Ceph continua a servire i dati.
Mesi 2-4, migrazione per ondate. Prima i servizi interni meno critici, poi posta e contabilità, infine i servizi rivolti ai cittadini, migrati in orari notturni e annunciati sul portale. Ogni ondata si chiude con un test di ripristino da backup.
Fine del mese 4, chiusura. VMware vSphere viene dismesso prima della scadenza del contratto. La documentazione finale comprende architettura, runbook di emergenza e verbali dei test di guasto.
Gli imprevisti
Durante il primo test di guasto alcune macchine critiche ripartono nell'altra sede senza un ordine garantito: i servizi applicativi partono prima del database e vanno in errore. L'alta disponibilità di Proxmox VE fa ripartire le VM ma non prevede sequenze di avvio tra loro, quindi le applicazioni vengono rese tolleranti: dentro le VM i servizi attendono che il database risponda e si riconnettono da soli, e il runbook prevede una verifica finale. Il test si ripete fino a una ripartenza pulita.
Uno dei collegamenti tra le sedi si rivela instabile sotto carico durante la sincronizzazione iniziale di Ceph. Il gestore della fibra individua e sostituisce un componente difettoso. Il problema esisteva già prima, ma la vecchia replica non lo metteva sotto stress.
Il risultato
L'ente ottiene un'infrastruttura aperta che regge la perdita di una sede senza intervento manuale per i servizi critici, verificata con test di guasto documentati. La migrazione si chiude prima della scadenza del contratto VMware, e il costo ricorrente si limita a subscription Proxmox VE e Proxmox Backup Server e supporto. I verbali dei test e i runbook diventano parte della documentazione per gli audit annuali.
Basata su progetti reali seguiti dal nostro team: nomi, numeri e dettagli che renderebbero riconoscibile il cliente sono stati modificati per riservatezza.
La tua situazione è simile?
Raccontaci il tuo ambiente: ti diciamo come lo affronteremmo.