Contesto
L’ente aveva quattro cluster VMware vSphere con storage vSAN, estesi su due data center: server Windows, server Linux e due cluster per i desktop virtuali Omnissa Horizon. In tutto più di 450 VM server e i desktop di oltre mille utenti. L’aumento dei costi di licenza VMware ha reso necessario cambiare piattaforma, con due vincoli: nessun nuovo server da acquistare e nessuna interruzione dei servizi.
Ho scritto il documento di design, dai workshop con i team tecnici del cliente fino alla versione definitiva che guida installazione e migrazione. Il design di dettaglio di Horizon è dei servizi professionali Omnissa; io ho disegnato la piattaforma, i servizi file e le integrazioni tra Horizon e Nutanix.
La sfida
- Hardware fuori lista. I nodi erano vSAN Ready Node non presenti nella lista hardware Nutanix, con schede di rete e dischi cache non supportati. Servivano una qualificazione dedicata e interventi fisici su ogni nodo.
- Nessun nodo libero. Ogni nuovo cluster poteva nascere solo con i nodi liberati da un cluster VMware: l’ordine delle attività decideva capacità, rischio e tempi.
- RPO zero su due siti attivi. Il cliente chiedeva la replica sincrona per tutti i carichi, con entrambi i data center in produzione.
- Nessun accesso a Internet. Aggiornamenti, immagini e licenze dovevano entrare in un perimetro chiuso.
- Un parco VM eterogeneo. Circa una VM su nove aveva un sistema operativo fuori supporto, da Windows Server 2003 a RHEL 3, e più di cento erano in supporto esteso o non identificabili.
L’approccio: Eject, Build, Expand
Ho trasformato il vincolo in un metodo. Ogni nodo segue lo stesso ciclo: evacuazione dei carichi, rimozione dal cluster VMware, interventi hardware (schede Intel E810 a 25 GbE, rimozione dei dischi cache, impostazioni BIOS dedicate), reimaging con Foundation e infine creazione o espansione di un cluster AHV. Gli interventi fisici li esegue il personale del cliente, con le procedure e l’approvazione finale di Nutanix.
La sequenza parte da due cluster ponte, uno per sito, ricavati dai nodi VDI dopo aver concentrato i desktop su un solo cluster. Lì si spostano temporaneamente i server Windows; i nodi così liberati costruiscono i cluster Linux, poi quelli Windows, poi quelli VDI. Alla fine ogni nodo ha la sua collocazione definitiva, compresi due piccoli cluster di test per gli aggiornamenti applicativi e firmware.
Il piano a onde conta nove passi. Per ognuno è previsto un piano di capacità da validare prima di procedere, perché nelle fasi intermedie la riserva N+1 è il punto più fragile.
Decisioni chiave
- Un cluster per sito, mai esteso. Ogni gruppo ha due cluster gemelli che si proteggono a vicenda con Nutanix Disaster Recovery: replica asincrona o NearSync come base, sincrona con witness dove serve RPO zero.
- Quattro istanze di Prism Central. In scale-out, separate per server e desktop e per sito, accoppiate come availability zone. Il capacity provider di Horizon dipende da Prism Central: la sua resilienza è un requisito, non un’opzione.
- Compromessi dichiarati. RF2 al posto di RF3 per i limiti di capacità ed erasure coding sui container dei server sono due richieste del cliente. Il design le registra con impatti e accettazione del rischio, invece di nasconderle.
- Desktop active-active. Pool dimensionati al 100% su ciascun sito e replica sincrona solo per le immagini master. I profili restano sul NAS esistente nella prima fase e passano a Nutanix Files con Smart DR dopo una validazione funzionale.
- Microsegmentazione al posto di NSX. Flow Network Security isola i desktop tra loro: ognuno comunica solo con il gateway. Le policy partono in modalità monitor.
- Dark site. Repository LCM interno, immagini e licenze offline, Pulse disattivato e raccolta dei log da una postazione ponte controllata dal cliente.
- Un piano per le VM legacy. Prova su rete isolata e rollback per ogni VM. In alternativa, un cluster VMware di laboratorio con una data limite per ciascuna; Hyper-V annidato solo come ultima risorsa, con l’assenza di supporto accettata per iscritto.
Stato del progetto
Il design è stato consegnato a ottobre 2026 e fa da riferimento per installazione, migrazione con Nutanix Move e test di validazione. La dismissione dell’ambiente VMware e le policy di backup restano a cura del cliente.
01
Soluzione, livello per livello
Seleziona un livello coinvolto per leggere cosa è stato fatto.
L1 · Accesso sicuro
Gli Unified Access Gateway diventano appliance native AHV in DMZ, con regole di anti-affinità. Un ADC virtuale bilancia Connection Server, Unified Access Gateway e App Volumes Manager, con persistenza allineata al timeout delle sessioni Horizon.
L2 · Workspace digitale
Omnissa Horizon su AHV tramite capacity provider in Prism Central: template, categorie e compute profile con vTPM per Windows 11. Il blocco di gestione vive sui cluster server, separato dai desktop. App Volumes sta su Nutanix Files dalla prima fase; profili FSLogix e dati DEM ci arrivano dopo la validazione.
L3 · Piattaforma iperconvergente
Otto cluster AHV in quattro gruppi (server Windows, server Linux, desktop e test), un cluster per sito in ogni gruppo. RF2 con riserva N+1, compressione inline, quattro istanze di Prism Central in scale-out, Flow Network Security su tutti i cluster e Nutanix Files con Smart DR tra i siti.
M · Migrazioni di piattaforma
Sequenza Eject, Build, Expand in nove passi, con due cluster ponte temporanei. Nutanix Move per le VM server, nuovi deploy per appliance e gateway, nuovi pool per i desktop. Per ogni onda: regole di cut-over, finestre di freeze, rollback alla VM sorgente e criteri di accettazione.
02
Risultati
- 8
- cluster Nutanix AHV, quattro per sito
- 80+
- nodi riutilizzati dai cluster vSAN
- 450+
- VM server da migrare
- 1.000+
- utenti di desktop virtuali
03