Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 e gestire l’intermediazione delle connessioni a desktop virtuali Windows e Linux, applicazioni ospitate su Desktop remoto Server (RDS), desktop e computer fisici.
Questo articolo illustra come distribuire Horizon in soluzione Azure VMware. Per informazioni generali su VMware Horizon, vedere la documentazione di produzione di Horizon seguente:
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 le versioni successive della linea di rilascio Horizon 8 supportano sia le distribuzioni on-premises sia le distribuzioni in 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à.
Implementare 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 consente di scalare la tua implementazione, creare un cloud ibrido e garantire ridondanza per la continuità operativa e il ripristino d’emergenza. Per altre informazioni, vedere Espansione degli ambienti Horizon 7 esistenti.
Importante
CPA non è un'implementazione estesa. Ogni pod Horizon è distinto. Tutti i server di connessione che appartengono ai singoli pod devono trovarsi in un'unica posizione ed essere eseguiti nello stesso dominio broadcast 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 di Horizon Control Plane per Horizon su soluzione Azure VMware non è ancora disponibile. Assicurarsi di scaricare la versione VHD (Virtual Hard Disk) 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 essere eseguito su 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 di Horizon su soluzione Azure VMware
Una tipica progettazione dell'architettura Horizon utilizza una strategia basata su pod e blocchi. 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 funzionalità con VMware NSX, la connettività di rete soluzione Azure VMware presenta requisiti univoci per la distribuzione di Horizon diversa da quella 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 del task worker di 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 variare. 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. Dimensiona e pianifica di conseguenza la distribuzione. 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é si stima che ogni cloud privato e ogni SDDC possano gestire 4.000 sessioni desktop, si distribuisce un pod Horizon della dimensione massima. È 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 alcun pod Horizon locale che si desidera connettere a questo nuovo pod tramite Cloud Pod Architecture (CPA).
Gli utenti finali si connettono ai propri desktop virtuali tramite Internet (rispetto alla connessione tramite un data center locale).
Si connette il controller di dominio AD nella rete virtuale di Azure all'AD locale tramite VPN o connessione 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 è scalare Horizon su 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.
Tabelle delle dimensioni
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 macchina virtuale | vRAM per macchina virtuale (GB) | Istanza | 100 VM | 200 VM | 300 VM | 400 VM | 500 VM | 600 VM | 700 VM | 800 VM | 900 VM | 1000 VM | 2000 macchine virtuali | 3000 VM | 4000 VM | 5000 VM | 6000 VM | 6400 VM |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 3.5 | AVS | 3 | 3 | 4 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 17 | 25 | 33 | 41 | 49 | 53 |
| 2 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 9 | 18 | 26 | 34 | 42 | 51 | 54 |
| 2 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 2 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 2 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 2 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 4 | 3.5 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 4 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 4 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 4 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 6 | 3.5 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 4 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 6 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 6 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 8 | 3.5 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 4 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 6 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 8 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 8 | 16 | AVS | 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 richieste per ciascun desktop
VRAM obbligatorio per desktop
Spazio di archiviazione richiesto 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 si prevede di distribuire Horizon solo su soluzione Azure VMware nel prossimo futuro, utilizzare la licenza in abbonamento Horizon, poiché ha 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 l'agente Horizon per LinuxHorizon 8 nell'architettura soluzione Azure VMware