Déployer Horizon sur la solution Azure VMware
- 09/29/2020
- 11 minutes de lecture
-
- s
- t
.
Note
Ce document se concentre sur le produit VMware Horizon, anciennement connu sous le nom d’Horizon 7. Horizon est une solution différente d’Horizon Cloud sur Azure, bien que certains composants soient partagés. Les principaux avantages de la solution VMware sur Azure comprennent à la fois une méthode de dimensionnement plus simple et l’intégration de la gestion de VMware Cloud Foundation dans le portail Azure.
VMware Horizon®, une plateforme de postes de travail et d’applications virtuels, s’exécute dans le centre de données et offre une gestion simple et centralisée. Il fournit des bureaux et des applications virtuels sur n’importe quel appareil, n’importe où. Horizon vous permet de créer et de courtier des connexions à des bureaux virtuels Windows et Linux, des applications hébergées par Remote Desktop Server (RDS), des bureaux et des machines physiques.
Ici, nous nous concentrons spécifiquement sur le déploiement d’Horizon sur Azure VMware Solution. Pour des informations générales sur VMware Horizon, consultez la documentation de production Horizon :
-
Qu’est-ce que VMware Horizon ?
-
En savoir plus sur VMware Horizon
-
Architecture de référence d’Horizon
Avec l’introduction d’Horizon sur Azure VMware Solution, il existe désormais deux solutions d’infrastructure de postes de travail virtuels (VDI) sur la plateforme Azure. Le schéma suivant résume les principales différences à un haut niveau.
Horizon 2006 et les versions ultérieures sur la ligne de sortie Horizon 8 prennent en charge à la fois le déploiement sur site et le déploiement sur Azure VMware Solution. Il y a quelques fonctionnalités Horizon qui sont prises en charge sur site mais pas sur Azure VMware Solution. D’autres produits de l’écosystème Horizon sont également pris en charge. Pour plus d’informations, voir la parité des fonctionnalités et l’interopérabilité.
Déployer Horizon dans un cloud hybride
Vous pouvez déployer Horizon dans un environnement de cloud hybride lorsque vous utilisez Horizon Cloud Pod Architecture (CPA) pour interconnecter les datacenters sur site et Azure. CPA met à l’échelle votre déploiement, construit un cloud hybride et fournit une redondance pour la continuité des activités et la reprise après sinistre. Pour plus d’informations, consultez la section Extension des environnements Horizon 7 existants.
Important
CPA n’est pas un déploiement étiré ; chaque pod Horizon est distinct et tous les serveurs de connexion qui appartiennent à chacun des pods individuels doivent être situés dans un seul emplacement et fonctionner sur le même domaine de diffusion du point de vue du réseau.
Comme les centres de données sur site ou privés, Horizon peut être déployé dans un cloud privé Azure VMware Solution. Nous aborderons les principales différences dans le déploiement d’Horizon sur site et sur Azure VMware Solution dans les sections suivantes.
Le cloud privé Azure est conceptuellement le même que le SDDC VMware, un terme généralement utilisé dans la documentation Horizon. Le reste de ce document utilise les termes nuage privé Azure et VMware SDDC de manière interchangeable.
Le connecteur Cloud Horizon est nécessaire pour Horizon sur Azure VMware Solution pour gérer les licences d’abonnement. Cloud Connector peut être déployé dans le réseau virtuel Azure aux côtés des serveurs de connexion Horizon.
Important
La prise en charge du plan de contrôle Horizon pour Horizon sur Azure VMware Solution n’est pas encore disponible. Veillez à télécharger la version VHD d’Horizon Cloud Connector.
Rôle vCenter Cloud Admin
Du fait qu’Azure VMware Solution est un service SDDC et qu’Azure gère le cycle de vie du SDDC sur Azure VMware Solution, le modèle de permission vCenter sur Azure VMware Solution est limité par conception.
Les clients doivent utiliser le rôle Cloud Admin, qui dispose d’un ensemble limité de permissions vCenter. Le produit Horizon a été modifié pour fonctionner avec le rôle Cloud Admin sur Azure VMware Solution, plus précisément :
-
Le provisionnement instantané des clones a été modifié pour fonctionner sur Azure VMware Solution.
-
Une politique vSAN spécifique (VMware_Horizon) a été créée sur Azure VMware Solution pour fonctionner avec Horizon, qui doit être disponible et utilisée dans les SDDC déployés pour Horizon.
-
vSphere Content-Based Read Cache (CBRC), également connu sous le nom de View Storage Accelerator, est désactivé lors de son exécution sur Azure VMware Solution.
Important
CBRC ne doit pas être réactivé.
Note
La solution VMware Azure configure automatiquement des paramètres Horizon spécifiques tant que vous déployez Horizon 2006 (alias Horizon 8) et plus sur la branche Horizon 8 et que vous sélectionnez l’option Azure dans le programme d’installation d’Horizon Connection Server.
Horizon sur Azure Architecture de déploiement de la solution VMware
Une conception typique de l’architecture Horizon utilise une stratégie de pods et de blocs. Un bloc est un vCenter unique, tandis que plusieurs blocs combinés constituent un pod. Un pod Horizon est une unité d’organisation déterminée par les limites d’évolutivité d’Horizon. Chaque pod Horizon possède un portail de gestion distinct, et donc une pratique de conception standard consiste à minimiser le nombre de pods.
Chaque cloud possède son propre schéma de connectivité réseau. Combinée à la mise en réseau VMware SDDC / NSX Edge, la connectivité réseau de la solution Azure VMware présente des exigences uniques pour le déploiement d’Horizon, différentes de celles sur site.
Chaque cloud privé et SDDC Azure peut gérer 4 000 sessions de bureau ou d’application, en supposant que :
-
Le trafic de la charge de travail s’aligne sur le profil de travailleur de tâches LoginVSI.
-
Seul le trafic de protocole est pris en compte, aucune donnée utilisateur.
-
NSX Edge est configuré pour être large.
Note
Votre profil de charge de travail et vos besoins peuvent être différents, et les résultats peuvent donc varier en fonction de votre cas d’utilisation. Les volumes de données utilisateur peuvent abaisser les limites d’échelle dans le contexte de votre charge de travail. Dimensionnez et planifiez votre déploiement en conséquence. Pour plus d’informations, consultez les directives de dimensionnement dans la section Dimensionnement des hôtes de la solution VMware Azure pour les déploiements Horizon.
Compte tenu de la limite maximale du cloud privé Azure et du SDDC, nous recommandons une architecture de déploiement dans laquelle les serveurs de connexion Horizon et les passerelles d’accès unifié VMware (UAG) sont exécutés à l’intérieur du réseau virtuel Azure. Cela transforme effectivement chaque nuage privé Azure et SDDC en un bloc. À son tour, il maximise l’évolutivité d’Horizon fonctionnant sur Azure VMware Solution.
La connexion du réseau virtuel Azure aux clouds privés Azure / SDDC doit être configurée avec ExpressRoute FastPath. Le diagramme suivant montre un déploiement de pods Horizon de base.
Connectivité réseau pour mettre à l’échelle Horizon sur Azure VMware Solution
Cette section présente l’architecture réseau à un niveau élevé avec quelques exemples de déploiement communs pour vous aider à mettre à l’échelle Horizon sur Azure VMware Solution. L’accent est mis spécifiquement sur les éléments de réseau critiques.
Pod Horizon unique sur Azure VMware Solution
Un pod Horizon unique est le scénario de déploiement le plus simple car vous déployez un seul pod Horizon dans la région Est des États-Unis. Étant donné que chaque cloud privé et SDDC est estimé pour gérer 4 000 sessions de bureau, vous déployez la taille maximale du pod Horizon. Vous pouvez planifier le déploiement de jusqu’à trois clouds privés/SDDC.
Avec les machines virtuelles (VM) de l’infrastructure Horizon déployées dans Azure Virtual Network, vous pouvez atteindre les 12 000 sessions par pod Horizon. La connexion entre chaque cloud privé et SDDC au réseau virtuel Azure est ExpressRoute Fast Path. Aucun trafic est-ouest entre les clouds privés n’est nécessaire.
Les hypothèses clés pour cet exemple de déploiement de base incluent que :
-
Vous n’avez pas de pod Horizon sur site que vous souhaitez connecter à ce nouveau pod à l’aide de l’architecture de pods de cloud (CPA).
-
Les utilisateurs finaux se connectent à leurs bureaux virtuels via Internet (vs. se connecter via un centre de données sur site).
Vous connectez votre contrôleur de domaine AD dans Azure Virtual Network avec votre AD sur site via un VPN ou un circuit ExpressRoute.
Une variation de l’exemple de base pourrait consister à prendre en charge la connectivité pour les ressources sur site. Par exemple, les utilisateurs accèdent aux bureaux et génèrent un trafic d’applications de bureau virtuel ou se connectent à un pod Horizon sur site à l’aide de CPA.
Le schéma montre comment prendre en charge la connectivité pour les ressources sur site. Pour connecter votre réseau d’entreprise au réseau virtuel Azure, vous aurez besoin d’un circuit ExpressRoute. Vous devrez également connecter votre réseau d’entreprise à chacun des clouds privés et des SDDC en utilisant ExpressRoute Global Reach. Cela permet la connectivité du SDDC au circuit ExpressRoute et aux ressources sur site.
Multiples pods Horizon sur Azure VMware Solution à travers plusieurs régions
Un autre scénario consiste à mettre à l’échelle Horizon à travers plusieurs pods. Dans ce scénario, vous déployez deux pods Horizon dans deux régions différentes et les fédérez à l’aide de CPA. C’est similaire à la configuration du réseau dans l’exemple précédent, mais avec quelques liens interrégionaux supplémentaires.
Vous allez connecter le réseau virtuel Azure dans chaque région aux clouds privés/SDDC de l’autre région. Cela permet aux serveurs de connexion Horizon faisant partie de la fédération CPA de se connecter à tous les postes de travail sous gestion. L’ajout de clouds privés/SDDC supplémentaires à cette configuration vous permettrait de passer à 24 000 sessions au total.
Les mêmes principes s’appliquent si vous déployez deux pods Horizon dans la même région. Veillez à déployer le deuxième pod Horizon dans un réseau virtuel Azure distinct. Tout comme l’exemple de pod unique, vous pouvez connecter votre réseau d’entreprise et votre pod sur site à cet exemple multi-pod/région en utilisant ExpressRoute et Global Reach.
Dimensionner les hôtes Azure VMware Solution pour les déploiements Horizon
La méthodologie de dimensionnement d’Horizon sur un hôte fonctionnant dans Azure VMware Solution est plus simple que Horizon sur site. C’est parce que l’hôte Azure VMware Solution est standardisé. Le dimensionnement exact de l’hôte permet de déterminer le nombre d’hôtes nécessaires pour répondre à vos besoins en matière de VDI. C’est un élément central pour déterminer le coût par poste de travail.
Tables de dimensionnement
Les besoins spécifiques en vCPU/vRAM pour les postes de travail virtuels Horizon dépendent du profil de charge de travail spécifique du client. Travaillez avec votre équipe commerciale MSFT et VMware pour vous aider à déterminer vos exigences en matière de vCPU/vRAM pour vos bureaux virtuels.
vCPU par VM | vRAM par VM (Go) | Instance | 100 VMs | 200 VMs | 300 VMs | 400 VMs | 500 VMs | 600 VMs | 700 VMs | 800 VMs | 900 VMs | 1000 VMs | 2000 VMs | 3000 VMs | 4000 VMs | 5000 VMs | 6000 VMs | 6400 VMs | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 | 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 |
Les entrées de dimensionnement de l’horizon
Voici ce que vous devrez rassembler pour votre charge de travail prévue :
-
Nombre de postes de travail simultanés
-
VCPU requise par poste de travail
-
VRAM requise par poste de travail
-
Stockage requis par poste de travail
En général, les déploiements VDI sont soit limités par le CPU, soit par la RAM, ce qui détermine la taille de l’hôte. Prenons l’exemple suivant pour une charge de travail de type LoginVSI Knowledge Worker, validée par des tests de performance :
-
Déploiement de 2 000 postes de travail simultanés
-
2vCPU par poste de travail.
-
4 Go de vRAM par poste de travail.
-
50 Go de stockage par bureau
Pour cet exemple, le nombre total d’hôtes s’élève à 18, ce qui donne une densité de VM par hôte de 111.
Important
Les charges de travail des clients varieront par rapport à cet exemple de travailleur du savoir LoginVSI. Dans le cadre de la planification de votre déploiement, travaillez avec vos SE VMware EUC pour vos besoins spécifiques en matière de dimensionnement et de performances. Assurez-vous d’exécuter vos propres tests de performance en utilisant la charge de travail réelle et planifiée avant de finaliser le dimensionnement de l’hôte et d’ajuster en conséquence.
Les licences d’Horizon sur Azure VMware Solution
Les coûts globaux d’exécution d’Horizon sur Azure VMware Solution comportent quatre composantes .
Coût de la capacité de la solution Azure VMware
Pour plus d’informations sur la tarification, consultez la page de tarification de la solution Azure VMware
Coût de la licence Horizon
Il existe deux licences disponibles pour une utilisation avec la solution Azure VMware, qui peuvent être soit un utilisateur simultané (CCU), soit un utilisateur nommé (NU) :
-
La licence d’abonnement Horizon
-
La licence d’abonnement universelle Horizon
Si vous ne déployez Horizon sur Azure VMware Solution que dans un avenir prévisible, alors utilisez la licence d’abonnement Horizon car elle est moins coûteuse.
Si vous déployez Horizon sur Azure VMware Solution et sur site, comme dans un cas d’utilisation de reprise après sinistre, choisissez la licence d’abonnement universelle Horizon. Elle inclut une licence vSphere pour le déploiement sur site, elle a donc un coût plus élevé.
Travaillez avec votre équipe commerciale VMware EUC pour déterminer le coût de la licence Horizon en fonction de vos besoins.
Types d’instance Azure
Pour comprendre les tailles de machine virtuelle Azure qui seront nécessaires pour l’infrastructure Horizon, veuillez vous référer aux directives de VMware qui peuvent être trouvées ici.