Implementare Horizon nella soluzione Azure VMware
Nota
Questo documento è incentrato sul prodotto VMware Horizon, noto in precedenza come Horizon 7. Horizon è una soluzione differente rispetto a Horizon Cloud in Azure, anche se sono presenti alcuni componenti condivisi. I vantaggi principali della soluzione Azure VMware includono sia un metodo di ridimensionamento più semplice che l'integrazione della gestione del cloud privato software-defined data center (SDDC) nel portale di Azure.
VMware Horizon®, una piattaforma desktop virtuale e applicazioni, viene eseguita nel data center e offre una gestione semplice e centralizzata. Offre desktop virtuali e applicazioni in qualsiasi dispositivo, ovunque. Horizon consente di creare connessioni e di broker a desktop virtuali Windows e Linux, applicazioni ospitate di Desktop remoto (RDS), desktop e computer fisici.
In questo caso, ci concentriamo specificamente sulla distribuzione di Horizon nella soluzione Azure VMware. Per informazioni generali su VMware Horizon, vedere la documentazione di produzione di Horizon:
Con l'introduzione di Horizon nella soluzione Azure VMware, nella piattaforma Azure sono ora disponibili due soluzioni VDI (Virtual Desktop Infrastructure):
Soluzione VMware Horizon in Azure VMware
VMware Horizon Cloud (modello desktop-as-a-Service)
Horizon 2006 e versioni successive nella riga di versione Horizon 8 supporta sia la distribuzione locale che la distribuzione della soluzione Azure VMware. Esistono alcune funzionalità di Horizon supportate in locale, ma non nella soluzione Azure VMware. Sono supportati anche altri prodotti nell'ecosistema Horizon. Per altre informazioni, vedere Parità delle funzionalità e interoperabilità.
Distribuire Horizon in un cloud ibrido
È possibile distribuire Horizon in un ambiente cloud ibrido usando Horizon Cloud Pod Architecture (CPA) per interconnettere i data center locali e di Azure. CPA aumenta la distribuzione, crea un cloud ibrido e offre ridondanza per continuità aziendale e ripristino di emergenza. Per altre informazioni, vedere Espansione degli ambienti Horizon 7 esistenti.
Importante
CPA non è una distribuzione estesa; ogni pod Horizon è distinto e tutti i server di connessione che appartengono a ognuno dei singoli pod devono trovarsi in un'unica posizione ed essere eseguiti nello stesso dominio di trasmissione dal punto di vista della rete.
Analogamente ai data center locali o privati, è possibile distribuire Horizon in un cloud privato della soluzione Azure VMware. Nelle sezioni seguenti vengono illustrate le differenze principali nella distribuzione di Horizon in locale e nella soluzione Azure VMware.
Il cloud privato di Azure è concettualmente identico a quello di VMware SDDC, un termine in genere usato nella documentazione di Horizon. Il resto di questo documento usa entrambi i termini in modo intercambiabile.
Horizon Cloud Connector è necessario per la soluzione Horizon in Azure VMware per gestire le licenze di sottoscrizione. È possibile distribuire Cloud Connector in Rete virtuale di Azure insieme ai server di connessione Horizon.
Importante
Il supporto del piano di controllo Horizon per la soluzione Azure VMware non è ancora disponibile. Assicurarsi di scaricare la versione VHD di Horizon Cloud Connector.
Ruolo di amministratore cloud del server vCenter
Poiché la soluzione Azure VMware è un servizio SDDC e Azure gestisce il ciclo di vita della soluzione SDDC nella soluzione Azure VMware, il modello di autorizzazione del server vCenter nella soluzione Azure VMware è limitato dalla progettazione.
I clienti devono usare il ruolo di amministratore cloud, che dispone di un set limitato di autorizzazioni del server vCenter. Il prodotto Horizon è stato modificato per lavorare con il ruolo di amministratore cloud nella soluzione Azure VMware, in particolare:
Il provisioning di cloni istantanei è stato modificato per l'esecuzione nella soluzione Azure VMware.
È stato creato un criterio vSAN specifico (VMware_Horizon) nella soluzione Azure VMware per l'uso con Horizon, che deve essere disponibile e usato negli SDDC distribuiti per Horizon.
VSphere Content-Based Read Cache (CBRC), noto anche come Acceleratore di archiviazione di visualizzazione, è disabilitato durante l'esecuzione nella soluzione Azure VMware.
Importante
CBRC non deve essere riattivato.
Nota
La soluzione Azure VMware configura automaticamente impostazioni di Horizon specifiche, purché si distribuisca Horizon 2006 (Horizon 8) e versioni successive nel ramo Horizon 8 e si selezioni l'opzione Azure nel programma di installazione del server di connessione Horizon.
Architettura di distribuzione della soluzione Azure VMware in Horizon
Una progettazione tipica dell'architettura Horizon usa una strategia pod e block. Un blocco è un singolo server vCenter, mentre più blocchi combinati rendono un pod. Un pod Horizon è un'unità di organizzazione determinata dai limiti di scalabilità di Horizon. Ogni pod Horizon ha un portale di gestione separato per cui una procedura di progettazione standard consiste nel ridurre al minimo il numero di pod.
Ogni cloud ha un proprio schema di connettività di rete. Combinare questa soluzione con VMware NSX, la connettività di rete della soluzione Azure VMware presenta requisiti univoci per la distribuzione di Horizon differente dall'ambiente locale.
Ogni cloud privato della soluzione Azure VMware e SDDC può gestire 4.000 sessioni desktop o applicazioni, presupponendo che:
Il traffico del carico di lavoro è allineato al profilo di lavoro dell'attività LoginVSI.
Viene considerato solo il traffico del protocollo, senza dati utente.
NSX Edge è configurato per essere di grandi dimensioni.
Nota
Il profilo del carico di lavoro e le esigenze possono essere differenti e pertanto i risultati possono variare in base al caso d'uso. I volumi di dati utente possono ridurre i limiti di scalabilità nel contesto del carico di lavoro. Ridimensionare e pianificare la distribuzione di conseguenza. Per altre informazioni, vedere le linee guida per il ridimensionamento nella sezione Dimensioni degli host della soluzione Azure VMware per le distribuzioni Horizon.
Dato il limite massimo di cloud privato di Azure e SDDC, è consigliabile un'architettura di distribuzione in cui i server di connessione Horizon e i gateway di accesso unificato VMware (UAG) vengono eseguiti all'interno della rete virtuale di Azure. Trasforma in modo efficace ogni cloud privato di Azure e SDDC in un blocco. A sua volta, ottimizzando la scalabilità di Horizon in esecuzione nella soluzione Azure VMware.
La connessione dalla rete virtuale di Azure ai cloud privati/SDDC di Azure deve essere configurata con Connessioni ExpressRoute (abilitata per FastPath). Il diagramma seguente illustra una distribuzione di base dei pod Horizon.
Connettività di rete per ridimensionare Horizon nella soluzione Azure VMware
Questa sezione descrive l'architettura di rete a livello generale con alcuni esempi di distribuzione comuni che consentono di ridimensionare Horizon nella soluzione Azure VMware. L'attenzione è specificamente sugli elementi di rete critici.
Pod Single Horizon nella soluzione Azure VMware
Un singolo pod Horizon è lo scenario di distribuzione più semplice perché si distribuisce un solo pod Horizon nell'area Stati Uniti orientali. Poiché ogni cloud privato e SDDC sono stimati per gestire 4.000 sessioni desktop, si distribuiscono le dimensioni massime dei pod Horizon. È possibile pianificare la distribuzione di un massimo di tre cloud privati/SDDC.
Con le VM dell'infrastruttura Horizon distribuite nella rete virtuale di Azure, è possibile raggiungere 12.000 sessioni per ogni pod Horizon. La connessione tra ogni cloud privato e SDDC alla rete virtuale di Azure è una connessione ExpressRoute (abilitata per FastPath). Non è necessario alcun traffico est-ovest tra cloud privati.
I presupposti chiave per questo esempio di distribuzione di base includono:
Non si dispone di un pod Horizon locale che si desidera connettere a questo nuovo pod usando Cloud Pod Architecture (CPA).
Gli utenti finali si connettono ai propri desktop virtuali tramite Internet (rispetto alla connessione tramite un data center locale).
È possibile connettere il controller di dominio AD nella rete virtuale di Azure con l'istanza locale di AD tramite VPN o circuito ExpressRoute.
Una variante dell'esempio di base potrebbe essere quella di supportare la connettività per le risorse locali. Ad esempio, gli utenti accedono ai desktop e generano traffico dell'applicazione desktop virtuale o si connettono a un pod Horizon locale tramite CPA.
Il diagramma mostra come supportare la connettività per le risorse locali. Per connettersi alla rete aziendale alla rete virtuale di Azure, è necessario un circuito ExpressRoute. È necessario connettere la rete aziendale a ognuno dei cloud privati e degli SDDC usando Copertura globale di ExpressRoute. Consente la connettività da SDDC al circuito ExpressRoute e alle risorse locali.
Più pod Horizon nella soluzione Azure VMware in più aree
Un altro scenario è il ridimensionamento di Horizon tra più pod. In questo scenario si distribuiscono due pod Horizon in due aree diverse e si esegue la federazione usando CPA. È simile alla configurazione di rete nell'esempio precedente, ma con più link tra aree.
Connettere la rete virtuale di Azure in ogni area ai cloud privati/SDDC nell'altra area. Consente ai server di connessione Horizon che fanno parte della federazione CPA di connettersi a tutti i desktop gestiti. L'aggiunta di altri cloud privati/SDDC a questa configurazione consente di ridimensionare fino a 24.000 sessioni complessive.
Gli stessi principi si applicano se si distribuiscono due pod Horizon nella stessa area. Assicurarsi di distribuire il secondo pod Horizon in un rete virtuale di Azure separata. Analogamente all'esempio di singolo pod, è possibile connettere la rete aziendale e il pod locale a questo esempio multi-pod/area usando ExpressRoute e Copertura globale.
Ridimensionare gli host della soluzione Azure VMware per le distribuzioni Horizon
La metodologia di dimensionamento di Horizon in un host in esecuzione nella soluzione Azure VMware è più semplice rispetto a Horizon locale. È più semplice perché l'host della soluzione Azure VMware è standardizzato. Il dimensionamento esatto dell'host consente di determinare il numero di host necessari per supportare i requisiti VDI. È fondamentale determinare il costo per desktop.
Ridimensionamento delle tabelle
I requisiti vCPU/vRAM specifici per i desktop virtuali Horizon dipendono dal profilo del carico di lavoro specifico del cliente. Collaborare con il team di vendita MSFT e VMware per determinare i requisiti vCPU/vRAM per i desktop virtuali.
| vCPU per VM | vRAM per VM (GB) | Istanza | 100 VM | 200 VM | 300 VM | 400 VM | 500 VM | 600 VM | 700 VM | 800 VM | 900 VM | 1000 VM | 2000 VM | 3000 VM | 4000 VM | 5000 VM | 6000 VM | 6400 VM |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 3.5 | Soluzione Azure VMware | 3 | 3 | 4 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 17 | 25 | 33 | 41 | 49 | 53 |
| 2 | 4 | Soluzione Azure VMware | 3 | 3 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 9 | 18 | 26 | 34 | 42 | 51 | 54 |
| 2 | 6 | Soluzione Azure VMware | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 2 | 8 | Soluzione Azure VMware | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 2 | 12 | Soluzione Azure VMware | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 2 | 16 | Soluzione Azure VMware | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 4 | 3.5 | Soluzione Azure VMware | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 4 | Soluzione Azure VMware | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 6 | Soluzione Azure VMware | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 4 | 8 | Soluzione Azure VMware | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 4 | 12 | Soluzione Azure VMware | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 4 | 16 | Soluzione Azure VMware | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 6 | 3.5 | Soluzione Azure VMware | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 4 | Soluzione Azure VMware | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 6 | Soluzione Azure VMware | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 8 | Soluzione Azure VMware | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 6 | 12 | Soluzione Azure VMware | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 6 | 16 | Soluzione Azure VMware | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 8 | 3.5 | Soluzione Azure VMware | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 4 | Soluzione Azure VMware | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 6 | Soluzione Azure VMware | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 8 | Soluzione Azure VMware | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 8 | 12 | Soluzione Azure VMware | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 8 | 16 | Soluzione Azure VMware | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
Input di ridimensionamento dell'orizzonte
Ecco cosa è necessario raccogliere per il carico di lavoro pianificato:
Numero di desktop simultanei
VCPU obbligatorio per desktop
VRAM obbligatorio per desktop
Archiviazione necessaria per desktop
In generale, le distribuzioni VDI sono vincolate dalla CPU o dalla RAM, che determina le dimensioni dell'host. Di seguito è riportato l'esempio seguente per un tipo di knowledge worker LoginVSI di carico di lavoro, convalidato con test delle prestazioni:
Distribuzione simultanea di 2.000 desktop
2vCPU per desktop.
VRAM da 4 GB per desktop.
50 GB di spazio di archiviazione per desktop
Per questo esempio, il numero totale di host raggiunge 18, producendo una densità VM per host pari a 111.
Importante
I carichi di lavoro dei clienti variano da questo esempio di un knowledge worker LoginVSI. Come parte della pianificazione della distribuzione, collaborare con le SES VMware EUC per le specifiche esigenze di dimensionamento e prestazioni. Assicurarsi di eseguire test delle prestazioni personalizzati usando il carico di lavoro pianificato effettivo prima di finalizzare il dimensionamento dell'host e regolare di conseguenza.
Licenze della soluzione Horizon in Azure VMware
Esistono quattro componenti per i costi complessivi dell'esecuzione di Horizon nella soluzione Azure VMware.
Costo della capacità della soluzione Azure VMware
Per informazioni sui prezzi, vedere la pagina dei prezzi della soluzione Azure VMware
Costo licenze Horizon
Sono disponibili due licenze per l'uso con la soluzione Azure VMware, che può essere Utente simultaneo (CCU) o Utente denominato (NU):
Licenza di sottoscrizione di Horizon
Licenza di sottoscrizione universale di Horizon
Se solo la distribuzione di Horizon nella soluzione Azure VMware per il prossimo futuro, usare la licenza di sottoscrizione Horizon perché è un costo inferiore.
Se distribuito nella soluzione Azure VMware e in locale, scegliere la licenza di sottoscrizione universale Horizon come caso d'uso per il ripristino di emergenza. Tuttavia, include una licenza vSphere per la distribuzione locale, quindi ha un costo più elevato.
Collaborare con il team di vendita di VMware EUC per determinare il costo delle licenze Horizon in base alle esigenze.
Tipi di istanza di Azure
Per informazioni sulle dimensioni delle VM di Azure necessarie per l'infrastruttura Horizon, vedere Installazione di Horizon nella soluzione Azure VMware.
Riferimenti
Requisiti di sistema per Horizon Agent per Linux
Passaggi successivi
Per altre informazioni su VMware Horizon nella soluzione Azure VMware, vedere Domande frequenti su VMware Horizon.