Da VMware vSphere a una piattaforma aperta, senza fermare l'azienda.

Chi gestisce VMware vSphere da anni ha costruito intorno all'hypervisor un ecosistema di abitudini. vCenter come punto unico di gestione, vMotion per la manutenzione, HA e DRS per la continuità, datastore VMFS su una SAN, backup che si appoggiano alle API VADP, template e customization spec per creare macchine nuove.

Sulle piattaforme di destinazione quasi tutto ha un equivalente, ma raramente identico. Proxmox VE ha live migration e alta disponibilità ma ragiona per cluster, non per vCenter. Lo storage spesso passa da una SAN a Ceph o ZFS. I backup cambiano strumento. Le reti si descrivono con bridge Linux e VLAN invece che con vSwitch e port group.

Per questo una migrazione ben fatta comincia con una mappa delle corrispondenze: per ogni funzione che usi oggi, cosa la sostituirà domani e cosa va riprogettato. È il documento che evita le sorprese a metà progetto.

Ogni progetto parte da un assessment, cioè un inventario completo dell'ambiente VMware vSphere: host, macchine virtuali, consumi reali di CPU e memoria, datastore, crescita dello storage, reti, sistemi operativi ospiti, strumenti di backup e integrazioni esterne. I dati si raccolgono con strumenti in sola lettura, senza toccare la produzione.

L'inventario da solo non basta. Parliamo con chi gestisce l'ambiente per capire quali applicazioni sono critiche, quali finestre di fermo sono accettabili, quali macchine dipendono le une dalle altre e cosa non è scritto da nessuna parte. È in queste interviste che emergono il server dimenticato da cui dipende il gestionale o la licenza legata al MAC address di una scheda di rete.

L'assessment si chiude con un report: piattaforma consigliata e perché, dimensionamento del nuovo cluster, piano per ondate, rischi e confronto dei costi a tre-cinque anni con il rinnovo VMware.

Il nuovo ambiente si progetta sui consumi misurati, non su quelli teorici. Per la maggior parte delle aziende la destinazione è Proxmox VE: il confronto funzione per funzione è nella pagina Proxmox VE o VMware vSphere. Decidiamo numero e dimensione dei nodi, il tipo di storage, la rete con la separazione tra traffico delle macchine, dello storage e della migrazione, le politiche di backup e l'integrazione con il monitoraggio esistente.

Spesso la migrazione è l'occasione per semplificare. Uno storage iperconvergente come Ceph può sostituire una SAN a fine vita. Le macchine dimenticate si dismettono invece di trasferirle. I template si rifanno puliti.

Il pilota è una prima ondata di macchine non critiche migrate sul nuovo cluster e lasciate in esercizio per qualche giorno. Serve a verificare prestazioni, backup e ripristino, monitoraggio e procedure operative, prima di toccare qualcosa di importante.

Le ondate successive seguono le dipendenze applicative: si spostano insieme le macchine che lavorano insieme. Per ogni ondata definiamo finestra, responsabili, criteri di successo e piano di rientro. La macchina originale resta su VMware vSphere, spenta ma intatta, finché l'ondata non è collaudata.

Gli strumenti dipendono dalla destinazione. Proxmox VE ha un import wizard che legge le macchine direttamente dagli host ESXi. SUSE Virtualization ha un componente dedicato all'importazione da VMware, che lavora a macchina spenta. Per i casi più delicati si usano conversioni dei dischi e replica dei dati applicativi. Un dettaglio che fa perdere ore se non lo si prevede: le macchine Windows hanno bisogno dei driver VirtIO prima dello spostamento. Anche macchine su vSAN, dischi cifrati e vTPM richiedono passaggi in più: sono casi da individuare già nell'assessment.

Una migrazione si giudica nei mesi successivi. Consegniamo documentazione e runbook operativi, formiamo il team sulle differenze rispetto a VMware vSphere e restiamo disponibili con un contratto di supporto. Se il tuo team è piccolo o impegnato altrove, possiamo occuparci noi della gestione quotidiana: aggiornamenti, monitoraggio, gestione della capacità e test di ripristino periodici.