Omnissa Horizon su Nutanix: le ottimizzazioni da applicare, su AHV e su vSphere

Con Horizon 8 2512 il supporto a Nutanix AHV è diventato generalmente disponibile, e “Horizon su Nutanix” non vuol dire più soltanto vSphere su hardware Nutanix. Nutanix e Omnissa hanno pubblicato parecchia documentazione su come integrare i due mondi: tech note, un Validated Design, best practice guide e la guida di architettura di Horizon 8. In questo articolo raccolgo le ottimizzazioni che i due vendor raccomandano, livello per livello, con il mio punto di vista da architetto Nutanix ed EUC.

Due modi di far girare Horizon su Nutanix

Horizon può girare su Nutanix con due hypervisor. Su vSphere l’integrazione è quella classica con vCenter, e Nutanix ha una best practice guide dedicata. Su AHV, dalla 2512, Horizon si integra con Prism Central, che fa da capacity provider: crea, clona, elimina e accende le VM al posto di vCenter. Su AHV sono supportati i pool automatici, sia di desktop sia di farm RDSH, e i pool manuali; girano su AHV anche i componenti di gestione: Connection Server, Unified Access Gateway, App Volumes, Dynamic Environment Manager, Horizon Recording e Horizon Edge Gateway.

Alcuni concetti cambiano, e conviene averli chiari prima di progettare:

Su vSphere	Su AHV
Integrazione con vCenter	Prism Central come capacity provider
Snapshot della golden image	Template di Prism Central, basato su recovery point senza catene di snapshot
Datastore VMFS o NFS	Container di storage Nutanix
Personalizzazione con ClonePrep o Sysprep e le guest customization	Personalizzazione con ClonePrep o Sysprep e i custom profile
App Volumes con VMDK collegati tramite vCenter	App Volumes con VHD in-guest su share SMB, per esempio Nutanix Files
Unified Access Gateway distribuito da OVA	Unified Access Gateway distribuito con gli script PowerShell di Omnissa verso Prism Central

Sulle versioni, la documentazione Omnissa della 2512 indica come minimi Prism Central 2024.3, AOS 7.0 e AHV 10.0; prima di partire verificate comunque la combinazione nella Interoperability Matrix di Omnissa. Due note pratiche: su AHV è supportata solo l’attivazione automatica delle licenze Horizon Universal subscription, e dalla 2512.1 Connection Server e Horizon Agent vanno aggiornati insieme, perché è cambiato il meccanismo di pairing tra i due (KB 6001315).

Architettura: pod, blocchi e Prism Central

L’architettura pod-and-block di Horizon non cambia. Su AHV ogni resource block è fatto di uno o più cluster AHV, e Omnissa raccomanda di dare a ogni blocco una istanza di Prism Central dedicata: i domini di guasto restano separati e un problema di Prism Central rimane confinato a un blocco.

Prism Central

Dimensionamento. Un’istanza arriva a 25.000 VM, ma per la VDI la raccomandazione è di non superare le 5.000 VM per istanza, in taglia Large; X-Large se il monitoraggio mostra che serve.
Disponibilità. Prism Central non è nel percorso delle sessioni: se si ferma, gli utenti connessi e le nuove connessioni a desktop già pronti continuano a funzionare. Si fermano invece provisioning, refresh dopo il logoff e operazioni di accensione e spegnimento. Si protegge con l’HA delle VM AHV o con il deployment scale-out a tre VM; il Validated Design di Nutanix usa una Prism Central scale-out in ogni datacenter, con il capacity provider puntato al suo indirizzo virtuale.
Picchi di provisioning. Se i logoff e la ricreazione dei desktop si concentrano in certe ore, Prism Central può diventare il collo di bottiglia. Nutanix consiglia di creare le VM dei pool automatici con All Machines Up-Front anziché Machines on Demand, e di ridurle fuori orario con un’automazione che modifichi il numero massimo di VM e di spare del pool.
Account di servizio. Usate un account dedicato in Prism Central, locale o di Active Directory, con il ruolo Super Admin richiesto dall’integrazione.

Cluster AHV e densità

Non progettate sui massimi. AHV arriva a 32 nodi per cluster, 200 VM VDI accese per nodo e 4.096 VM per cluster, ma per la VDI Nutanix raccomanda al massimo 16 nodi per cluster, con almeno n+1: 15 nodi utili.
VM per nodo. La stima di massima di Nutanix, riportata anche da Omnissa, è di circa 150 VM VDI per nodo, cioè fino a 2.250 VM per cluster. Il Validated Design di Nutanix, con Windows 11 e il profilo Knowledge Worker di Login Enterprise, ha qualificato 100 VM per nodo e 1.500 per cluster da 16 nodi, restando sotto l’85% di CPU e il 5% di CPU ready. Windows 11 pesa più di Windows 10: usate questi numeri come riferimento e validateli con i vostri carichi.
Cluster più piccoli, guasti più piccoli. Meno nodi per cluster vuol dire meno utenti coinvolti in un guasto e finestre di manutenzione più corte: il Validated Design stima 16 ore per aggiornare con LCM un cluster da 16 nodi, e con blocchi da 8 nodi il tempo si dimezza.

Server di gestione

Connection Server. Almeno tre per pod, così il pod resta ridondato anche durante la manutenzione; il Validated Design ne usa quattro quando le connessioni passano dagli UAG. Ogni Connection Server regge fino a 4.000 sessioni, 2.000 se arrivano dagli UAG; Nutanix consiglia di non superare le 2.000 e di partire dal minimo Omnissa di 4 vCPU e 10 GB di RAM.
HA e anti-affinità. Attivate l’HA delle VM AHV e create regole di anti-affinità, perché i server con lo stesso ruolo non finiscano sullo stesso host.
Gestione e desktop. Se condividono il cluster, date priorità alle risorse dei componenti di gestione e tenetene conto nel dimensionamento; il Validated Design li separa in un cluster di management dedicato.
Bilanciatori. Davanti a Connection Server, UAG e Horizon Recording serve un load balancer con persistenza delle sessioni: quello integrato in Prism Central non la offre.

Storage: container, data reduction e CVM

Sul container dei desktop la guida per vSphere e il Validated Design per AHV vanno nella stessa direzione:

Impostazione	Raccomandazione
Compressione	Inline attiva, con ritardo zero
Deduplica	Spenta per i desktop non persistenti; da valutare solo per full clone e volumi scrivibili
Erasure coding	Spento: non è adatto alla VDI
Replication factor	RF2 con fault tolerance 1; RF3 solo per SLA più stringenti
Container	Uno per caso d’uso: se avete full clone e cloni non persistenti, usatene due

Per la resilienza il Validated Design preferisce più cluster in RF2 a cluster in RF3, e attiva l’opzione di HA che riserva la capacità di failover. La memoria dei CVM va dimensionata con le tabelle della sezione CVM Memory Configuration della guida di Prism Element: lo raccomandano sia Nutanix sia Omnissa, perché sono i CVM a servire tutto l’I/O dei desktop.

Il dettaglio che fa la differenza: niente BitLocker nell’immagine

Omnissa spiega un comportamento di AHV da conoscere. Quando fate un push image, i vecchi cloni e i loro recovery point vengono cancellati, ma restano su disco fino al ciclo di recupero dello spazio, che gira ogni ora: per un po’ l’occupazione sale. Grazie al redirect-on-write ogni nuovo clone occupa poco spazio, e il picco resta contenuto. Con BitLocker attivo, invece, ogni VM occupa l’intero disco allocato, e il picco diventa importante.

Nella golden image disattivate quindi la crittografia del dispositivo e impedite a BitLocker di riattivarla. C’è anche un secondo motivo: in genere i dati cifrati nel guest non si comprimono. Se vi serve la cifratura a riposo, usate quella di Nutanix: il Validated Design cifra l’intero cluster.

Rete e sicurezza

Rete fisica. Ogni scrittura viene replicata su un altro CVM, quindi la latenza tra i nodi si somma a quella dello storage. Il Validated Design usa una topologia leaf-spine a 25 GbE, con MLAG o vPC invece dello stacking, VLAN di CVM e hypervisor non taggata sulle porte dei server e VLAN taggate per i carichi.
DHCP e DNS. Su AHV potete usare l’IPAM di Nutanix, che ha già l’alta affidabilità. Tenete corti i lease dello scope VDI e allineateli allo scavenging DNS; con un DHCP Windows, Nutanix suggerisce di passare dagli 8 giorni di default a un’ora.
Active Directory. La rete scelta per il pool deve essere associata a un sito Active Directory, che è un requisito Omnissa, e ogni sito deve avere domain controller, global catalog e DNS locali.
Microsegmentazione. Flow Network Security protegge le VM con policy basate sulle categorie di Prism Central. Le categorie guidano anche storage policy, disaster recovery e RBAC: quelle applicate al template le ereditano tutti i desktop, quindi sceglietele con attenzione.
Blast. Configurate la QoS per il traffico Blast, porte di accesso degli utenti ad almeno 1 GbE e banda adeguata per chi si collega da WAN o VPN.

Le VM: dimensionamento, immagini e template

Dimensionamento

vCPU. Almeno 2 per Windows 10, 3 per Windows 11 e 6 per gli RDSH su Windows Server 2019 e 2022. Il Validated Design ha qualificato Windows 11 con 4 vCPU e 6 GB.
Meglio scalare in orizzontale. Lo scheduler dell’hypervisor lavora meglio di Windows: più VM piccole rendono più di poche VM grandi. Su AHV non c’è differenza tra un socket con più core e più socket, e Nutanix suggerisce un socket solo. Se le VM crescono, tenete d’occhio i confini NUMA.
Overcommit. Al massimo 8:1 per Windows client e 2:1 per Windows Server, controllando il CPU ready: più vCPU per VM possono farlo salire.
Memoria. Mai in overcommit. Come riferimento, 4 GB per Windows 10, 6 GB per Windows 11 e almeno 32 GB per gli RDSH, da adattare alle applicazioni.
Hardware virtuale. Controller SCSI e disco e scheda di rete di default, cioè VirtIO-SCSI e VirtIO-Net. Per Windows 11 servono vTPM e Secure Boot.

Golden image e template

Immagine nuova, quando potete. Nutanix raccomanda di costruire un’immagine nuova per AHV anziché convertire quella di vSphere. Se la convertite con Move, dopo la conversione togliete Nutanix Guest Tools e VMware Tools, lasciando i driver VirtIO.
VirtIO sì, NGT no. Installate sempre i VirtIO più recenti nell’immagine, ma non installate NGT nelle immagini dei pool automatici. Per le macchine dedicate, installatelo dopo il deploy.
vTPM. Si definisce nel compute profile di Horizon e non si clona: Horizon lo sostituisce su ogni VM che distribuisce.
Ottimizzazione. Applicate le ottimizzazioni Omnissa con l’OS Optimization Tool, insieme alla guida Manually creating optimized Windows images for Horizon VMs, e ripetetele dopo ogni aggiornamento del sistema operativo o delle applicazioni.
Agenti. Seguite l’ordine di installazione indicato da Omnissa per Horizon Agent, Dynamic Environment Manager e App Volumes. L’agent si registra al Connection Server già all’installazione: per disinstallarlo o cambiarne i componenti, eliminate prima la VM dalla console Horizon.
Un template per pod. L’agent resta legato al pod in cui si è registrato, quindi in un’architettura multi-pod serve un’immagine per pod: conviene costruirle con l’automazione, per esempio Packer, Ansible o MDT.
Niente versioning dei template. Horizon non supporta il versioning dei template di Prism Central: aggiornate l’immagine e create un nuovo template.
Personalizzazione. Per i pool non persistenti il Validated Design usa ClonePrep; Sysprep resta disponibile quando serve.

GPU

Usate driver aggiornati e una coppia di driver host e guest supportata, e installate il driver nel template prima del provisioning. Se aggiungete la GPU al template dopo, dovete ridistribuire le macchine o aggiungerla a mano.
Tenete libera la capacità GPU necessaria per accendere il template durante gli aggiornamenti.
Una VM con GPU riserva tutta la sua memoria, NVIDIA vGPU non supporta la virtualization-based security, e AHV assegna le GPU sempre con lo scheduling depth-first.

Antivirus e aggiornamenti

Configurate le esclusioni raccomandate per tutti i componenti e ripetete l’esercizio a ogni nuova applicazione.
Programmate le scansioni fuori orario e a scaglioni, e fate una scansione completa prima di sigillare l’immagine.
Distribuite le patch a ondate successive, misurandone l’impatto.

App Volumes, DEM e profili su Nutanix Files

Su AHV App Volumes usa il modello VHD in-guest su share SMB, e Nutanix Files diventa la scelta naturale, anche per Dynamic Environment Manager e Horizon Recording. Nutanix indica il tipo di share per ogni componente:

Componente	Tipo di share	Continuous availability
App Volumes, pacchetti	Standard	Sì
App Volumes, Writable Volumes	Standard, su più share bilanciate con uno storage group	Sì
DEM, configurazione	Standard, preferita	No
DEM, profile archive	Distribuita, una cartella di primo livello per utente	No, salvo le configurazioni Flex
Horizon Recording	Distribuita, una cartella di primo livello per server	Sì

Accesso. Attivate l’access-based enumeration sulle share del profile archive; la cifratura SMB è opzionale.
Replica tra siti. I pacchetti si replicano con l’Application Synchronization di App Volumes, la configurazione di DEM con Smart DR e il profile archive con VDI Sync. Per i Writable Volumes si usa Smart DR nelle architetture active-passive o active-active pinned; nell’active-active roaming serve un prodotto di replica di terze parti.
Dimensionamento di Files. Usate i casi d’uso della sizing guide di Nutanix Files: Home Directories for VDI, Container-Based per i Writable Volumes, Performance-Sensitive Application Shares: Random per i pacchetti e Home Directories for VDI, File-Based per DEM.
Packaging. Per ogni pacchetto distribuite una VM nuova da un template Nutanix.
Alternative. Al posto di DEM potete usare FSLogix Profile Container, sempre su Files.

Se restate su vSphere

Per chi usa Horizon su Nutanix con vSphere, la best practice guide di Nutanix aggiunge alcune regole specifiche:

Container. Un unico container e datastore per desktop e RDSH, un container separato per i pacchetti di App Volumes, due container se avete sia full clone sia instant clone.
Shadow clone e View Storage Accelerator. Gli instant clone leggono tutti dal disco di replica, e gli shadow clone di Nutanix lo mettono in cache su ogni nodo, così le letture restano locali. Per questo Nutanix consiglia di disattivare View Storage Accelerator (CBRC) e di ignorare l’avviso che Horizon mostra alla creazione del pool.
vCenter. Anche se un vCenter gestisce fino a 8.000 instant clone, Nutanix consiglia di non superare i 2.000 desktop per vCenter.
Manutenzione con LCM. In genere ogni host ha una VM primaria per pool che LCM non può spegnere: deselezionate lo spegnimento automatico, perché vCenter elimina le primarie quando l’host entra in manutenzione e le ricrea dopo. Per evitare che il pool vada in errore perché la replica è spenta su un host in manutenzione, disabilitate il provisioning durante i lavori, oppure aggiornate prima un host senza repliche e spostatele lì.
VM base. Controller PVSCSI o LSI Logic SAS, scheda VMXNET3, disco thin, niente floppy, porte LPT e COM disabilitate e hot plug disattivato.

Multisito e disaster recovery

Su Nutanix ogni sito ha il suo cluster e la sua Prism Central, configurata come capacity provider separato: non c’è un unico punto di integrazione come il vCenter di un vSAN stretched. La continuità si costruisce con la Cloud Pod Architecture: un global entitlement che raggruppa pool su capacity provider diversi distribuisce le sessioni tra i siti, in active-active o in active-passive. Nell’esempio di Nutanix ogni sito ha il 100% della capacità e serve il 50% degli utenti. Ricordate che i template sono legati al pod tramite l’agent, e che i pool manuali sono i più adatti al failover tra pod.

La mia checklist

Versioni verificate nella Interoperability Matrix, con Connection Server e agent aggiornati insieme.
Una Prism Central per blocco, Large, al massimo 5.000 VM, protetta con HA o scale-out.
Cluster VDI da 16 nodi al massimo, con n+1, e densità validata con un test di carico.
Container con compressione inline, senza deduplica né erasure coding, in RF2.
Memoria dei CVM dimensionata secondo le tabelle di Prism Element.
Golden image nuova, VirtIO aggiornati, niente NGT, niente BitLocker, ottimizzata con OSOT.
Pool automatici con All Machines Up-Front e ClonePrep per i non persistenti.
HA e anti-affinità per i server di gestione, e bilanciatori con persistenza delle sessioni.
App Volumes, DEM e Recording su Nutanix Files con il tipo di share giusto per ciascuno.
Microsegmentazione con Flow e categorie del template scelte con attenzione.

Horizon su AHV è un’integrazione giovane, ma la documentazione dei due vendor è già solida e, soprattutto, coerente: segue gli stessi principi che valgono per qualsiasi VDI su Nutanix. Il mio consiglio è di partire dal Validated Design, adattarlo ai propri numeri e misurare prima di andare in produzione.

Riferimenti

Omnissa Horizon on Nutanix AHV (Nutanix, TN-2162)
Omnissa Horizon on AHV Design (Nutanix Validated Design, NVD-2173)
Omnissa Horizon on Nutanix Using vSphere Best Practices (Nutanix, BP-2060)
Migrating Omnissa Horizon Workloads from VMware ESXi to Nutanix AHV (Nutanix, TN-2139)
Horizon 8 architecture: Nutanix AHV deployments (Omnissa Tech Zone)
Omnissa Horizon 8 on Nutanix AHV design guidance (Omnissa technical blog)
Manually creating optimized Windows images for Horizon VMs (Omnissa Tech Zone)
Omnissa Horizon 8 2512 Release Notes (Omnissa)