Un'azienda manifatturiera passa da VMware vSphere a Proxmox VE con Ceph

Il contesto

Un'azienda manifatturiera con circa duecento dipendenti gestisce la propria infrastruttura su tre host VMware vSphere 7 collegati a una SAN Fibre Channel. Sopra girano una settantina di macchine virtuali: ERP, MES di reparto, file server, controller di dominio, posta interna, sistemi di supervisione delle linee e diverse macchine di cui nessuno ricorda più la funzione.

Le scadenze si sommano. VMware vSphere 7 è fuori dal supporto generale dal 2 ottobre 2025, quindi senza più patch di sicurezza. La SAN esce dal supporto del produttore. Il rinnovo VMware, che servirebbe anche solo per passare a VMware vSphere 8, con il nuovo modello a core costa diverse volte il contratto precedente. Il responsabile IT, che lavora con un solo collega, deve decidere se rinnovare entrambi o cambiare strada.

I vincoli

• Produzione continua: le linee lavorano su tre turni. Il MES e la supervisione non possono fermarsi durante la settimana.
• Finestre limitate: fermi accettabili solo nel fine settimana e per poche ore.
• Team piccolo: due persone, esperte di VMware vSphere, senza esperienza su Linux in profondità.
• Budget: l'investimento non deve superare il costo di SAN nuova più rinnovo VMware.

L'architettura scelta

L'assessment mostra un carico modesto in CPU ma importante in I/O nelle ore di chiusura della produzione, quando l'ERP elabora i dati di giornata. La raccomandazione è Proxmox VE su quattro nodi con Ceph su dischi NVMe: lo storage iperconvergente sostituisce la SAN a fine vita, e il quarto nodo garantisce che il cluster resti pienamente ridondato anche durante la manutenzione di un server.

La rete prevede collegamenti separati e ridondati per il traffico delle macchine, per Ceph e per la gestione. I backup passano a Proxmox Backup Server su un server dedicato in un altro locale, con replica notturna verso un secondo sito. Il confronto dei costi a cinque anni, tra hardware, subscription Proxmox VE e Proxmox Backup Server e supporto da una parte, e SAN nuova più rinnovo VMware dall'altra, è risultato chiaramente favorevole alla migrazione.

Come è andata

Settimane 1-2, assessment e design. Inventario, misura dei carichi, interviste con IT e responsabili di reparto. Emerge che otto macchine non sono più usate da anni: vengono archiviate e non migrate. Chiuso il design, l'azienda ordina i quattro nodi. Le settimane di attesa della consegna non rientrano nel conteggio: servono a preparare rete, piano delle ondate e runbook.

Settimane 3-4, deploy. All'arrivo dei server, i quattro nodi vengono installati, collaudati con test di guasto di un nodo e di un disco, e collegati al monitoraggio esistente.

Settimana 5, pilota. Migriamo con l'import wizard di Proxmox VE una quindicina di macchine non critiche, tra cui strumenti interni, ambienti di test e stampa, e le lasciamo in esercizio una settimana. Verifichiamo backup e ripristino di una macchina intera e di singoli file.

Settimane 6-9, ondate. Quattro fine settimana, uno per ogni gruppo di macchine dipendenti: servizi di infrastruttura, file server e posta, ERP con il suo database, infine MES e supervisione. Per l'ERP una sincronizzazione preliminare dei dischi riduce il fermo a meno di due ore.

Settimana 10, chiusura. Gli host VMware vSphere vengono spenti, la SAN dismessa, la documentazione consegnata.

Gli imprevisti

Un software di supervisione delle linee aveva la licenza legata all'indirizzo MAC della scheda di rete virtuale. Emerso nelle interviste dell'assessment, il caso si risolve mantenendo lo stesso indirizzo MAC sulla nuova macchina. Senza quella verifica la linea sarebbe ripartita il lunedì senza supervisione.

Il secondo problema è emerso nel pilota: le prestazioni di Ceph su una macchina di test erano inferiori al previsto. La causa era una configurazione errata della rete di storage su uno dei nodi, corretta prima di migrare le macchine di produzione. È esattamente il motivo per cui il pilota esiste.

Il risultato

L'azienda lascia VMware vSphere e la SAN in dieci settimane di lavoro, con quattro fermi programmati nel fine settimana e nessun fermo imprevisto della produzione. Il cluster ha più capacità di prima, alta disponibilità su quattro nodi e backup verificati ogni settimana con un ripristino di prova. I due sistemisti, dopo due giornate di formazione sul cluster reale, lo gestiscono in autonomia. Un contratto di supporto copre aggiornamenti maggiori ed emergenze.