Comment Azure VMware Solution fonctionne
Maintenant que vous connaissez Azure VMware Solution et ce qu’il peut faire, examinons comment il fonctionne sur Azure.
Support partagé
Les environnements VMware vSphere locaux exigent que le client prenne en charge tous les logiciels et le matériel pour exécuter la plateforme. Azure VMware Solution non. Microsoft maintient la plateforme pour le client. Examinons ce que le client gère et ce que Microsoft gère.
Dans le cas du tableau suivant :
Microsoft Managed = Bleu, Customer Managed = Gris

En partenariat avec VMware, Microsoft prend en charge la gestion du cycle de vie des logiciels VMware (ESXi, vCenter Server et vSAN). Microsoft travaille également avec VMware pour la gestion du cycle de vie de l’appliance NSX et l’amorçage de la configuration réseau. Cela inclut la création de la passerelle Tier‑0 et l’activation du routage nord/sud.
Le client est responsable de la configuration SDN de NSX :
- Segments réseau
- Règles du pare-feu distribué
- Passerelles de niveau 1
- Équilibreurs de charge
Surveillance et correction
Azure VMware Solution surveille en continu l’état de santé des composants sous-jacents et des composants de la solution VMware. Si Azure VMware Solution détecte une défaillance, il répare les composants défaillants. Lorsque Azure VMware Solution détecte une dégradation ou une défaillance sur un nœud Azure VMware Solution, il déclenche le processus de remédiation de l’hôte.
La remédiation des hôtes consiste à remplacer le nœud défaillant par un nouveau nœud sain dans le cluster. Ensuite, lorsque cela est possible, l’hôte défaillant est placé en mode maintenance VMware vSphere. VMware vMotion déplace les machines virtuelles de l’hôte défaillant vers d’autres serveurs disponibles dans le cluster, ce qui peut permettre une migration en direct des charges de travail sans interruption. Si l’hôte défaillant ne peut pas être placé en mode maintenance, l’hôte est retiré du cluster.
Azure VMware Solution surveille les conditions suivantes sur l’hôte :
- État du processeur
- État de la mémoire
- État de la connexion et de l’alimentation
- État des ventilateurs matériels
- Perte de connectivité réseau
- État de la carte système matérielle
- Erreurs survenues sur les disques d’un hôte vSAN
- Tension matérielle
- État de la température matérielle
- État de l’alimentation matérielle
- État du stockage
- Défaillance de connexion
Clouds privés, clusters et hôtes dans Azure
Azure VMware Solution fournit des clouds privés VCF sur du matériel dédié Azure.
Chaque cloud privé peut avoir plusieurs clusters gérés par le même vCenter Server et le même NSX Manager. Les clouds privés sont installés et gérés à partir d’un abonnement Azure. Le nombre de clouds privés dans un abonnement est évolutif.
Pour chaque cloud privé créé, il existe un cluster vSphere par défaut. Vous pouvez ajouter, supprimer et mettre à l’échelle des clusters en utilisant le portail Azure ou l’API. Microsoft propose des configurations de nœuds basées sur les besoins de base, de mémoire et de stockage. Choisissez le type de nœud approprié pour votre région ; le choix le plus courant est AV36P.
Les configurations minimales et maximales des nœuds sont les suivantes :
- Au moins trois nœuds dans un cluster
- Un maximum de 16 nœuds dans un cluster
- Maximum de 12 clusters dans un cloud privé Azure VMware Solution
- Maximum de 96 nœuds dans un cloud privé Azure VMware Solution
Le tableau suivant présente les spécifications du processeur, de la mémoire, du disque et du réseau pour les hôtes AVS disponibles :
| Type d’hôte | CPU (Unité centrale de traitement) | RAM | Niveau de cache vSAN | Capacité vSAN |
|---|---|---|---|---|
| AV36P | Deux processeurs Intel Xeon Gold 6240, 18 cœurs/processeur @ 2,6 GHz / 3,9 GHz Turbo. Total de 36 cœurs physiques. | 768 GB | 1,5 TB (Intel Cache) | 19,20 TB (NVMe) |
| AV48 | Deux processeurs Intel Xeon Gold 6442Y, 24 cœurs/processeur @ 2,6 GHz / 4,0 GHz Turbo. Total de 48 cœurs physiques. | 1 024 GB | N/D | 25,6 TB (NVMe) |
| AV52 | Deux processeurs Intel Xeon Platinum 8270, 26 cœurs par processeur à 2,7 GHz ; 4,0 GHz en mode Turbo. Total de 52 cœurs physiques. | 1 536 GB | 1,5 TB (Intel Cache) | 38,40 TB (NVMe) |
| AV64* | Deux processeurs Intel Xeon Platinum 8370C, 32 cœurs/processeur à 2,8 GHz / 3,5 GHz Turbo. Total de 64 cœurs physiques. | 1 024 GB | 3,84 TB (NVMe) | 15,36 TB (NVMe) |
Dans AVS Gen 1, un cloud privé Azure VMware Solution déployé avec AV36P, AV48 ou AV52 est requis avant d’ajouter des hôtes AV64.
Dans AVS Gen 2, AV64 peut être déployé seul.
Interconnexion dans Azure
L’environnement de cloud privé pour Azure VMware Solution peut être accessible à la fois depuis des ressources locales (on‑premises) et depuis des ressources basées sur Azure. Les services suivants fournissent l’interconnexion :
- Azure ExpressRoute
- Connexions VPN
- Azure Virtual WAN
- Passerelle Azure ExpressRoute
Le diagramme suivant illustre la méthode d’interconnexion ExpressRoute et ExpressRoute Global Reach pour Azure VMware Solution.

Ces services nécessitent l’activation de plages d’adresses réseau spécifiques et de ports de pare-feu.
Vous pouvez utiliser une passerelle ExpressRoute existante pour vous connecter à Azure VMware Solution si elle ne dépasse pas la limite de quatre circuits ExpressRoute par réseau virtuel (VNet). Pour accéder à Azure VMware Solution depuis un emplacement local via ExpressRoute, utilisez ExpressRoute Global Reach comme option privilégiée. S’il n’est pas disponible ou pas adapté en raison d’exigences réseau ou de sécurité spécifiques, envisagez d’autres options.
ExpressRoute Global Reach est utilisé pour connecter des clouds privés à votre environnement local (on‑premises). La connexion nécessite un réseau virtuel avec un circuit ExpressRoute vers l’environnement local dans votre abonnement. Il existe deux options d’interconnexion de cloud privé pour Azure VMware Solution :
- L’interconnexion Azure de base vous permet de gérer et d’utiliser votre cloud privé avec un seul réseau virtuel dans Azure. Cette mise en œuvre est idéale pour les évaluations Azure VMware Solution ou les implémentations qui n’ont pas besoin d’un accès depuis des environnements locaux.
- L’interconnexion complète entre un environnement local et un cloud privé étend la mise en œuvre Azure de base pour inclure l’interconnexion entre les environnements locaux et les clouds privés Azure VMware Solution.
Lors du déploiement d’un cloud privé, des réseaux privés pour la gestion, l’approvisionnement et vMotion sont créés. Ces réseaux privés sont utilisés pour accéder à vCenter Server et NSX‑T Manager, à la machine virtuelle vMotion, ou au déploiement de machines virtuelles.
Stockage du cloud privé
Azure VMware Solution utilise un stockage vSAN VMware entièrement Flash, entièrement configuré, et local au cluster. Tout le stockage local pour chaque hôte dans un cluster est utilisé dans un datastore VMware vSAN, et le chiffrement des données au repos est activé par défaut.
L’architecture de stockage vSAN d’origine utilise une unité de ressources appelée groupe de disques. Chaque groupe de disques se compose d’un niveau de cache et d’un niveau de capacité. Tous les groupes de disques utilisent un cache NVMe ou Intel, comme décrit dans le tableau suivant. La taille des niveaux cache et capacité varie selon le type d’hôte Azure VMware Solution. Deux groupes de disques sont créés sur chaque nœud dans le cluster vSphere. Chacun contient un disque de cache et trois disques de capacité. Tous les datastores sont créés dans le cadre d’un déploiement de cloud privé et sont immédiatement utilisables.
| Host Type | vSAN cache level (TB, raw) | vSAN Capacity Level (TB, Raw) |
|---|---|---|
| AV36P | 1.5 (Intel Cache) | 19.20 (NVMe) |
| AV48 | N/A | 25.60 (NVMe) |
| AV52 | 1.5 (Intel Cache) | 38.40 (NVMe) |
| AV64 | 3.84 (NVMe) | 15.36 (NVMe) |
Une stratégie est créée sur le cluster vSphere et appliquée au datastore vSAN. Elle détermine comment les objets de stockage des machines virtuelles sont provisionnés et alloués dans le datastore vSAN afin de garantir le niveau de service requis. Pour respecter le SLA, 25 % de la capacité libre doit être conservée sur le datastore vSAN. De plus, la stratégie FTT (failure to tolerate) applicable doit être appliquée afin de respecter l’accord de niveau de service pour Azure VMware Solution. Cela change en fonction de la taille du cluster.
Vous pouvez utiliser les services de stockage Azure dans les charges de travail qui s’exécutent dans votre cloud privé. Le diagramme suivant illustre certains des services de stockage disponibles que vous pouvez utiliser avec Azure VMware Solution.

Sécurité et conformité
Les clouds privés Azure VMware Solution utilisent le contrôle d’accès basé sur les rôles vSphere pour l’accès et la sécurité. Vous pouvez configurer des utilisateurs et des groupes dans Active Directory avec le rôle CloudAdmin en utilisant LDAP ou LDAPS.
Dans Azure VMware Solution, vCenter Server possède un utilisateur local intégré appelé cloudadmin affecté au rôle cloudAdmin. Le rôle cloudAdmin dispose d’autorisations vCenter Server qui diffèrent des autorisations administrateur dans d’autres solutions cloud VMware :
- L’utilisateur local CloudAdmin n’a pas l’autorisation d’ajouter une source d’identité, telle qu’un serveur LDAP (Lightweight Directory Access Protocol) local ou un serveur LDAP sécurisé (LDAPS) à vCenter Server. Des commandes d’exécution peuvent être utilisées pour ajouter une source d’identité et attribuer le rôle CloudAdmin aux utilisateurs et groupes.
- Dans un déploiement Azure VMware Solution, l’administrateur n’a pas accès au compte utilisateur administrator. L’administrateur peut attribuer des utilisateurs et groupes Active Directory au rôle CloudAdmin dans vCenter Server.
L’utilisateur du cloud privé n’a pas accès ni la possibilité de configurer certains composants de gestion qui sont pris en charge et gérés par Microsoft. Les clusters, les hôtes, les datastores et les commutateurs virtuels distribués en sont des exemples.
Azure VMware Solution fournit une sécurité pour les datastores de stockage vSAN en utilisant le chiffrement des données au repos et en l’activant par défaut. Le chiffrement est basé sur le Key Management Service (KMS) et prend en charge les opérations de gestion des clés dans vCenter Server. Les clés sont stockées, chiffrées et encapsulées par une clé maître Azure Key Vault. Lorsqu’un hôte est retiré d’un cluster, les données sur les SSD sont immédiatement invalidées. Le diagramme suivant illustre la relation des clés de chiffrement avec Azure VMware Solution.

Étapes pour déployer Azure VMware Solution
Le tableau suivant montre les étapes nécessaires pour qu’une organisation commence avec Azure VMware Solution.
| Jalons | Étapes |
|---|---|
| Planifier | Planifier le déploiement d’Azure VMware Solution : – Évaluer les charges de travail – Déterminer la taille – Identifier l’hôte – Demander un quota – Déterminer la mise en réseau et la connectivité |
| Déployer | Déployer et configurer Azure VMware Solution : – Enregistrer le fournisseur de ressources Microsoft.AVS – Créer un cloud privé Azure VMware Solution – Se connecter au réseau virtuel Azure avec ExpressRoute – Valider la connexion |
| Connexion locale | Créer une clé d’autorisation ExpressRoute dans le circuit ExpressRoute local : – Appairer le cloud privé local – Vérifier la connectivité réseau locale D’autres options de connectivité sont également disponibles. |
| Déployer et configurer VMware HCX | Déployer et configurer VMware HCX : – Activer l’add-on du service HCX – Télécharger le fichier OVA du VMware HCX Connector – Déployer localement le fichier OVA VMware HCX (connecteur VMware HCX) – Activer le connecteur VMware HCX – Associer votre connecteur VMware HCX local avec votre Azure Cloud Manager VMware Solution – Configurer l’interconnexion (profil réseau, profil de calcul et service mesh) – Compléter l’installation en vérifiant l’état de l’appliance et en confirmant que la migration est possible |