Présentation d’Azure VMware Solution

Azure VMware Solution fournit des clouds privés qui contiennent des clusters VMware vSphere créés à partir d’une infrastructure Azure complète dédiée. Azure VMware Solution est disponible dans Azure Commercial et Azure Government. Le déploiement initial minimum est de trois hôtes, avec la possibilité d'ajouter d'autres hôtes, jusqu'à un maximum de 16 hôtes par cluster. Tous les clouds privés approvisionnés comportent VMware vCenter Server, VMware vSAN, VMware vSphere et VMware NSX. Ainsi, vous pouvez effectuer la migration de charges de travail à partir de vos environnements locaux, déployer de nouvelles machines virtuelles et consommer des services Azure à partir de vos clouds privés. Pour plus d’informations sur le contrat SLA, consultez la page Contrats de niveau de service Azure.

Azure VMware Solution est une solution validée par VMware, qui teste et valide constamment les améliorations et les mises à niveau. Microsoft gère et maintient l'infrastructure et les logiciels du cloud privé, vous permettant de vous concentrer sur le développement et l'exécution de charges de travail dans vos cloud privés pour générer de la valeur commerciale.

Le diagramme illustre la contiguïté entre les clouds privés et les réseaux virtuels dans Azure, les services Azure et les environnements locaux. L’accès réseau des clouds privés vers les services Azure ou les réseaux virtuels fournit une intégration pilotée par SLA des points de terminaison de service Azure. ExpressRoute Global Reach connecte votre environnement local à votre cloud privé Azure VMware Solution.

Types de cloud privé Azure VMware Solution

Azure VMware Solution fournit deux générations de cloud privé différentes :

1. Azure VMware Solution Generation 1 fournit des clusters VMware vSphere créés à partir d’hôtes nus dédiés déployés dans les installations du centre de données Azure. Les circuits ExpressRoute gérés par Microsoft fournissent une connectivité entre les hôtes VMware vSphere et les ressources Azure natives déployées dans des réseaux virtuels.

2. Azure VMware Solution Generation 2 (préversion publique) fournit des clusters VMware vSphere créés à partir d’hôtes nus Azure dédiés. Azure VMware Solution Generation 2 propose une architecture réseau mise à jour dans laquelle les hôtes VMware vSphere sont directement attachés aux réseaux virtuels Azure. Cette offre est prise en charge uniquement sur la référence SKU AV64.

Hôtes, clusters et clouds privés

Les clusters Azure VMware Solution sont basés sur une infrastructure hyperconvergée. Le tableau suivant présente les spécifications du processeur, de la mémoire, du disque et du réseau de l’hôte.

Un cluster Azure VMware Solution nécessite un nombre minimal de trois hôtes. Vous pouvez utiliser des hôtes du même type uniquement dans un seul cloud privé Azure VMware Solution. Les hôtes utilisés pour créer ou mettre à l’échelle des clusters proviennent d’un pool isolé d’hôtes. Ces hôtes ont passé des tests matériels et toutes leurs données ont été soigneusement supprimées avant qu’ils ne soient ajoutés au cluster.

Tous les types d’hôtes précédents ont un débit d’interface réseau de 100 Gbits/s.

*Les détails sont disponibles via la calculatrice de prix Azure.

**Prérequis AV64 : un cloud privé Azure VMware Solution déployé avec AV36, AV36P ou AV52 est requis avant d’ajouter AV64.

Raw est basé sur la norme internationale d’unités (SI) signalée par les fabricants de disques. Exemple : 1 To brut = 1 000 000 000 000 octets. L’espace calculé par un ordinateur en binaire (1 To en binaire = 1099511627776 octets en binaire) est égal à 931,3 gigaoctets convertis depuis la valeur décimale brute.

Vous pouvez déployer de nouveaux clouds privés ou les mettre à l’échelle via le portail Azure ou Azure CLI.

Extension de cloud privé Azure VMware Solution avec taille de nœud AV64

AV64 est une référence SKU hôte Azure VMware Solution, qui est disponible pour développer le cloud privé Azure VMware Solution créé avec la référence SKU AV36, AV36P ou AV52 existante. Si vous souhaitez déployer AV64 directement, reportez-vous à Azure VMware Solution dans un réseau virtuel Azure. Utilisez la documentation Microsoft pour vérifier la disponibilité de la référence SKU AV64 dans la région.

Prérequis pour l’extension AV64 sur AV36, AV36P et AV52

Consultez les conditions préalables suivantes pour le déploiement de cluster AV64.

• Un cloud privé de la solution Azure VMware est créé à l’aide d’AV36, AV36P, AV48 ou AV52 dans la région/AZ prise en charge par AV64.

• Vous avez besoin d’un bloc d’adresses /23 ou trois (contigus ou non contigus) /25 pour la gestion des clusters AV64.

Prise en charge des scénarios client

Client avec un cloud privé Azure VMware Solution existant : lorsqu’un client a déployé un cloud privé Azure VMware Solution, il peut mettre à l’échelle le cloud privé en ajoutant un cluster de nœuds AV64 vCenter distinct à ce cloud privé. Dans ce scénario, les clients doivent utiliser les étapes suivantes :

1. Obtenez une approbation de quota AV64 auprès de Microsoft avec le minimum de trois nœuds. Ajoutez d’autres détails sur le cloud privé Azure VMware Solution que vous envisagez d’étendre à l’aide d’AV64.
2. Utilisez un flux de travail d'ajout de cluster Azure VMware Solution existant avec des hôtes AV64 pour agrandir.

Le client prévoit de créer un nouveau cloud privé Azure VMware Solution : quand un client souhaite un nouveau cloud privé Azure VMware Solution qui peut utiliser la référence SKU AV64, mais uniquement pour l’expansion. Dans ce cas, le client remplit les conditions requises pour disposer d’un cloud privé Azure VMware Solution généré avec une référence SKU AV36, AV36P ou AV52. Le client doit acheter au minimum trois nœuds des SKUs AV36, AV36P ou AV52 avant de pouvoir étendre son système avec AV64. Pour ce scénario, procédez comme suit :

1. Obtenez l’approbation du quota AV36, AV36P, AV52 et AV64 auprès de Microsoft avec au moins trois nœuds chacun.
2. Créez un cloud privé Azure VMware Solution à l’aide de la référence SKU AV36, AV36P ou AV52.
3. Utilisez un flux de travail d'ajout de cluster Azure VMware Solution existant avec des hôtes AV64 pour agrandir.

Cloud privé de clusters étendus Azure VMware Solution : la référence SKU AV64 n’est pas prise en charge avec le cloud privé de clusters étendus Azure VMware Solution. Cela signifie qu’une extension basée sur AV64 n’est pas possible pour un cloud privé de clusters étendus Azure VMware Solution.

Compatibilité vMotion améliorée (EVC) avec l’extension AV64

L’ajout de nœuds AV64 à un cloud privé Azure VMware Solution crée un environnement hétérogène, ce qui entraîne des problèmes de compatibilité vMotion améliorée (EVC) entre les clusters AV64 et les clusters de référence SKU de base à l’aide des références SKU AV36, AV36P ou AV52. Les clusters AV64 utilisent le mode Icelake EVC en raison de leurs processeurs Intel Icelake, tandis que les clusters AV36, AV36P et AV52, basés sur des processeurs Intel plus anciens, n’ont pas de mode EVC explicite activé. Vous trouverez ci-dessus des détails sur les générations de CPU pour chaque SKU.

L’hétérogénéité des modes EVC entre clusters présente des défis pour les opérations live vMotion, comme défini par Broadcom, en fonction du scénario et de la direction spécifiques de la migration. La section suivante fournit un résumé de l’expérience utilisateur lors de l’exécution de live vMotion entre AV64 et les clusters de base.

• Déplacement vMotion vers le cluster AV64 depuis le cluster de référence SKU De base : cela fonctionne bien, car la machine virtuelle est déplacée par vMotion d’un cluster en mode EVC inférieur vers un cluster en mode EVC supérieur.

• Déplacement vMotion vers le cluster de référence SKU De base depuis le cluster AV64 : deux scénarios

  • Si la machine virtuelle a été précédemment déplacée depuis le cluster De base et qu’elle n’a pas fait l’objet d’un cycle d’alimentation, le déplacement vMotion en direct réussit.

  • Si la machine virtuelle a été créée sur un cluster AV64 ou fait l’objet d’un cycle d’alimentation, même si elle a été précédemment déplacée par vMotion depuis le cluster de référence SKU De base, le déplacement vMotion en direct échoue avec une erreur de compatibilité EVC.

Les clients peuvent éviter les problèmes de déplacement vMotion en direct entre le cluster de référence SKU De base et le cluster AV64 en définissant le mode EVC au niveau de la machine virtuelle afin qu’il corresponde à un EVC de cluster De base inférieur ou en éteignant la machine virtuelle et en effectuant un déplacement vMotion à froid.

Conception et recommandations du domaine d’erreur (DE) vSAN du cluster AV64

Les clusters d'hôtes traditionnels de Azure VMware Solution ne possèdent pas de configuration explicite de FD vSAN. Le raisonnement repose sur le fait que la logique d’attribution d’hôtes garantit, au sein des clusters, que deux hôtes ne résident pas dans le même domaine d’erreur physique au sein d’une région Azure. Cette fonctionnalité apporte intrinsèquement de la résilience et de la haute disponibilité pour le stockage, ce que la configuration du DE vSAN est censée apporter. Pour plus d’informations sur le DE vSAN, consultez la documentation VMware.

Les clusters hôtes Azure VMware Solution AV64 ont une configuration de domaine d’erreur (DE) vSAN explicite. Le plan de contrôle Azure VMware Solution configure sept domaines d’erreur vSAN pour les clusters AV64. Les hôtes sont équilibrés uniformément entre les sept domaines d’erreur (FD) lorsque les utilisateurs effectuent un scale-up des hôtes dans un cluster en passant de 3 nœuds à 16 nœuds. Certaines régions Azure prennent toujours en charge un maximum de cinq domaines d’erreur dans le cadre de la version initiale de la référence SKU AV64. Pour plus d’informations, reportez-vous à la table de correspondance des types d'hébergement aux zones de disponibilité de la région Azure.

Recommandation de taille de cluster

La taille minimale du cluster de nœuds vSphere d’Azure VMware Solution prise en charge est de trois. La redondance des données vSAN est gérée en garantissant que la taille minimale du cluster de trois hôtes se trouve dans des DE vSAN différents. Dans un cluster vSAN avec trois hôtes, chacun dans un domaine d’erreur différent, si un domaine d’erreur échoue (par exemple, le commutateur en haut du rack échoue), les données vSAN sont protégées. Les opérations telles que la création d’objets (nouvelle machine virtuelle, VMDK et autres) échouent. Il en va de même pour toutes les activités de maintenance où un hôte ESXi est placé en mode maintenance et/ou redémarré. Afin d’éviter des scénarios tels que ceux-ci, il est recommandé de déployer des clusters vSAN avec un minimum de quatre hôtes ESXi.

Flux de travail de suppression d’hôte AV64 et meilleures pratiques

En raison de la configuration du domaine d’erreur (DE) vSAN du cluster AV64 et du besoin d’hôtes équilibrés sur tous les DE, la suppression de l’hôte du cluster AV64 diffère des clusters hôtes Azure VMware Solution traditionnels avec d’autres références SKU.

Actuellement, un utilisateur peut sélectionner un ou plusieurs hôtes à supprimer du cluster à l’aide du portail ou de l’API. L’une des conditions est qu’un cluster doit avoir un minimum de trois hôtes. Toutefois, un cluster AV64 se comporte différemment dans certains scénarios quand AV64 utilise des DE vSAN. Toute demande de suppression d’hôte est vérifiée par rapport au déséquilibre potentiel du DE vSAN. Si une demande de suppression d’hôte crée un déséquilibre, la requête est rejetée avec la réponse http 409-Conflict. Le code d’état de la réponse http 409-Conflict indique un conflit de requête avec l’état actuel de la ressource cible (hôtes).

Les trois scénarios suivants illustrent des exemples d’instances qui entraînent normalement une erreur et illustrent différentes méthodes qui peuvent être utilisées pour supprimer des hôtes sans créer de déséquilibre entre les domaines d’erreur vSAN.

• La suppression d’un hôte crée un déséquilibre entre les domaines d’erreur vSAN avec une différence d’hôtes entre le domaine d’erreur le plus peuplé et le domaine d’erreur le moins peuplé supérieure à un. Dans l’exemple d’utilisateur suivant, vous devez supprimer l’un des hôtes du domaine d’erreur 1 avant de supprimer des hôtes d’autres domaines d’erreur.

  

• Plusieurs demandes de suppression d’hôte sont effectuées en même temps et certaines suppressions d’hôtes créent un déséquilibre. Dans ce scénario, le plan de contrôle Azure VMware Solution supprime uniquement les hôtes, qui ne créent pas de déséquilibre. Dans l’exemple suivant, les utilisateurs ne peuvent pas utiliser les deux hôtes dans les mêmes DF, sauf s’ils réduisent la taille du cluster à quatre ou moins.

  

• Une suppression d’hôte sélectionnée implique moins de 3 domaines d’erreur vSAN actifs. Ce scénario n'est pas censé se produire étant donné que toutes les régions AV64 ont cinq ou sept FD. Lors de l’ajout d’hôtes, le plan de contrôle Azure VMware Solution se charge d’ajouter des hôtes des sept domaines d’erreur uniformément. Dans l’exemple suivant, les utilisateurs peuvent supprimer l’un des hôtes du domaine d’erreur 1, mais pas des domaines d’erreur 2 ou 3.

  

Comment identifier l’hôte qui peut être supprimé sans provoquer de déséquilibre du DE vSAN : un utilisateur peut accéder à l’interface client vSphere pour obtenir l’état actuel des DE vSAN et des hôtes associés à chacun d’entre eux. Cela permet d’identifier les hôtes (basés sur les exemples précédents) qui peuvent être supprimés sans affecter l’équilibre du DE vSAN et éviter toute erreur dans l’opération de suppression.

Configuration RAID prise en charge par AV64

Ce tableau fournit la liste des exigences de configuration RAID prises en charge et de l’hôte dans les clusters AV64. Les stratégies RAID-6 FTT2 et RAID-1 FTT3 sont prises en charge avec la référence SKU AV64 dans certaines régions. Dans les régions d’Azure qui sont actuellement limitées à cinq FD, Microsoft permet aux clients d’utiliser la stratégie de stockage vSAN RAID-5 FTT1 pour les clusters AV64 avec six nœuds ou plus pour répondre au contrat de niveau de service (SLA). Pour plus d’informations, reportez-vous à la table de correspondance des types d'hébergement aux zones de disponibilité de la région Azure.

Storage

Azure VMware Solution prend en charge l’expansion de la capacité du magasin de données au-delà de ce qui est inclus dans vSAN à l’aide des services de stockage Azure, ce qui vous permet d’étendre la capacité du magasin de données sans mettre à l’échelle les clusters. Pour plus d’informations, consultez Options d’expansion de la capacité du magasin de données.

Networking

Azure VMware Solution offre un environnement de cloud privé, qui est accessible à partir de sites et de ressources locaux et Azure. Des services tels qu’Azure ExpressRoute, Azure Virtual WAN ou les connexions VPN fournissent la connectivité nécessaire. Toutefois, ces services nécessitent des plages d’adresses réseau et des ports de pare-feu spécifiques pour leur activation.

Quand vous déployez un cloud privé, des réseaux privés pour la gestion, le provisionnement et vMotion sont créés. Ces réseaux privés vous permettent d’accéder à VMware vCenter Server et à VMware NSX Manager, ainsi qu’au vMotion ou au déploiement de la machine virtuelle.

ExpressRoute Global Reach permet de connecter des clouds privés à des environnements locaux. Il connecte les circuits directement au niveau de Microsoft Edge. La connexion demande un réseau virtuel (vNet) avec un circuit ExpressRoute local dans votre abonnement. En effet, les passerelles VNet (passerelles ExpressRoute) ne peuvent pas faire transiter le trafic, ce qui signifie que vous pouvez attacher deux circuits à la même passerelle mais que cela n’entraîne pas l’envoi du trafic d’un circuit à l’autre.

Chaque environnement Azure VMware Solution est sa propre région ExpressRoute (son propre appareil MSEE virtuel), qui vous permet de connecter Global Reach à l’emplacement d’appairage « local ». Il vous permet de connecter plusieurs instances Azure VMware Solution d’une région au même emplacement d’appairage.

Les machines virtuelles déployées sur le cloud privé sont accessibles à Internet via la fonctionnalité d’adresse IP publique d’Azure Virtual WAN. Pour les nouveaux clouds privés, l’accès à Internet est désactivé par défaut.

Pour plus d’informations, consultez Architecture de mise en réseau.

Accès et sécurité

Pour une sécurité renforcée, les clouds privés Azure VMware Solution utilisent le contrôle d’accès en fonction du rôle vSphere. Vous pouvez intégrer les fonctionnalités LDAP SSO vSphere à Microsoft Entra ID. Pour plus d’informations, voir la page Architecture d’accès et d’identité.

Par défaut, le chiffrement des données au repos vSAN est activé et il est utilisé pour garantir la sécurité du magasin de données vSAN. Pour plus d’informations, consultez Architecture du stockage.

Résidence des données et données client

Azure VMware Solution ne stocke pas les données client.

Versions des logiciels VMware

Le tableau suivant répertorie les versions logicielles utilisées dans les nouveaux déploiements de clouds privés Azure VMware Solution.

Si le numéro de build répertorié ne correspond pas au numéro de build répertorié dans les notes de publication, c’est parce qu’un correctif personnalisé a été appliqué aux fournisseurs de cloud.

La version actuelle du logiciel en cours d’exécution est appliquée aux nouveaux clusters ajoutés à un cloud privé existant, si la version vCenter Server la prend en charge.

Maintenance du cycle de vie des hôtes et des logiciels

Les mises à niveau régulières du cloud privé Azure VMware Solution et des logiciels VMware garantissent la sécurité, la stabilité et l’exécution des ensembles de fonctionnalités les plus récents dans vos clouds privés. Pour plus d’informations, consultez Maintenance de l’hôte et gestion du cycle de vie.

Supervision de votre cloud privé

Après le déploiement d’Azure VMware Solution dans votre abonnement, les journaux Azure Monitor sont générés automatiquement.

Dans votre cloud privé, vous pouvez :

• Collectez les journaux sur chacune de vos machines virtuelles.
• Télécharger et installer l’agent MMA sur les machines virtuelles Linux et Windows
• Activer l’extension de diagnostic Azure
• Créer et exécuter de nouvelles requêtes
• Exécuter les mêmes requêtes que celles que vous exécutez habituellement sur vos machines virtuelles

Dans Azure VMware Solution, les modèles de supervision sont similaires à ceux des machines virtuelles Azure sur la plateforme IaaS. Pour obtenir des informations supplémentaires et des procédures, consultez Supervision de machines virtuelles Azure avec Azure Monitor.

Communication du client

Vous pouvez trouver les notifications relatives aux problèmes de service, à la maintenance planifiée, aux avis d’intégrité et aux avis de sécurité via Service Health dans le portail Azure. Vous pouvez prendre des mesures opportunes lorsque vous configurez des alertes de journal d’activité pour ces notifications. Pour plus d’informations, consultez Créer des alertes Service Health à l’aide du portail Azure.

Matrice de responsabilité de Azure VMware Solution – Microsoft vs client

Azure VMware Solution implémente un modèle de responsabilité partagée qui définit les rôles et responsabilités distincts des deux parties impliquées dans l'offre : le client et Microsoft. Les responsabilités partagées des rôles sont illustrées plus en détail dans les deux tableaux suivants.

Le tableau matriciel de responsabilité partagée décrit les principales tâches que les clients et Microsoft effectuent chacun dans le déploiement et la gestion du cloud privé et des charges de travail des applications client.

Le tableau suivant présente une liste détaillée des rôles et responsabilités partagés entre le client et Microsoft, qui englobe les tâches et définitions les plus fréquentes. Si vous avez d’autres questions, n’hésitez pas à contacter Microsoft.

Étapes suivantes

L’étape suivante consiste à apprendre les concepts clés de l’architecture d’un cloud privé.