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.
Hôtes, clusters et clouds privés
Les clusters Azure VMware Solution sont basés sur une infrastructure hyperconvergée. Le tableau suivant montre les spécifications processeur, mémoire, disque et réseau de l’hôte.
| Type d’hôte | PROCESSEUR (cœurs/GHz) | RAM (Go) | Niveau de cache vSAN (To, brut***) | Niveau de capacité vSAN (To, brut***) | Disponibilité régionale |
|---|---|---|---|---|---|
| AV36 | Deux processeurs Dual Intel Xeon Gold 6140 (micro-architecture Skylake) avec 18 cœurs de processeur @ 2,3 GHz, 36 cœurs physiques au total (72 cœurs logiques avec hyper-threading) | 576 | 3,2 (NVMe) | 15,20 (SSD) | Régions sélectionnées (*) |
| AV36P | Processeurs Dual Intel Xeon Gold 6240 (micro-architecture Cascade Lake) avec 18 cœurs/Processeur @ 2,6 GHz / 3,9 GHz Turbo, total de 36 cœurs physiques (72 cœurs logiques avec hyper-threading) | 768 | 1,5 (cache Intel) | 19,20 (NVMe) | Régions sélectionnées (*) |
| AV52 | Processeurs Dual Intel Xeon Platinum 8270 (micro-architecture Cascade Lake) avec 26 cœurs/Processeur @ 2,7 GHz / 4,0 GHz Turbo, total de 52 cœurs physiques (104 cœurs logiques avec hyper-threading) | 1 536 | 1,5 (cache Intel) | 38,40 (NVMe) | Régions sélectionnées (*) |
| AV64 | Processeurs Dual Intel Xeon Platinum 8370C (micro-architecture Cascade Lake) avec 32 cœurs/processeur @ 2,8 GHz/3,5 GHz Turbo, total de 64 cœurs physiques (128 cœurs logiques avec hyper-threading) | 1 024 | 3,84 (NVMe) | 15,36 (NVMe) | Régions sélectionnées (**) |
Un cluster Azure VMware Solution nécessite un nombre minimal de trois hôtes. Vous pouvez uniquement utiliser des hôtes du même type 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 ci-dessus ont un débit d’interface réseau de 100 Gbits/s.
(*) détails 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.
(***) Valeur brute basée sur le Système international d’unités (SI) et signalée par le fabricant de disque. Exemple : avec 1 To brut = 1000000000000 octets, l’espace calculé par un ordinateur en binaire (1 To binaire = 1099511627776 octets binaires) est égal à 931,3 gigaoctets convertis à partir du décimal brut.
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
L’AV64 est une nouvelle référence SKU d’hôte Azure VMware Solution, qui est disponible pour développer (et non créer) le cloud privé Azure VMware Solution généré avec la référence SKU AV36, AV36P ou AV52 existante. Utilisez la documentation Microsoft pour vérifier la disponibilité de la référence SKU AV64 dans la région.
Prérequis pour l’utilisation d’AV64
Consultez les conditions préalables suivantes pour le déploiement de cluster AV64.
Un cloud privé de solution Azure VMware est créé à l’aide d’AV36, AV36P 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 :
- 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.
- Utilisez un flux de travail de cluster de complément Azure VMware Solution existant avec des hôtes AV64 à développer.
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 de référence SKU AV36, AV36P ou AV52 avant de se développer à l’aide d’AV64. Pour ce scénario, procédez comme suit :
- Obtenez l’approbation du quota AV36, AV36P, AV52 et AV64 auprès de Microsoft avec au moins trois nœuds chacun.
- Créez un cloud privé Azure VMware Solution à l’aide de la référence SKU AV36, AV36P ou AV52.
- Utilisez un flux de travail de cluster de complément Azure VMware Solution existant avec des hôtes AV64 à développer.
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.
[!NOTE]
Tout le trafic d’un hôte AV64 vers un réseau client utilisera l’adresse IP de l’interface réseau VMKernel 1.
Conception et recommandations du domaine d’erreur (DE) vSAN du cluster AV64
Les clusters hôtes Azure VMware Solution traditionnels n’ont pas de configuration de DE vSAN explicite. 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 lorsque les utilisateurs effectuent un scale-up des hôtes dans un cluster en passant de trois nœuds à 16 nœuds. Certaines régions Azure prennent toujours en charge un maximum de cinq FD dans le cadre de la version initiale de la référence SKU AV64. Pour plus d’informations, reportez-vous au tableau de correspondance entre les zones de disponibilité (AZ) et les UGS 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 DE différent, si un DE échoue (par exemple, le haut du commutateur de 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 DE 1 avant de supprimer des hôtes d’autres DE.
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 prendre les deux hôtes des mêmes DE, sauf s’ils réduisent la taille du cluster à quatre ou moins.
Une suppression d’hôte sélectionnée implique moins de trois domaines d’erreur vSAN actifs. Ce scénario ne devrait pas se produire étant donné que toutes les régions AV64 ont cinq ou sept domaines d’erreur. 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 au tableau de correspondance entre les zones de disponibilité (AZ) et les UGS de la région Azure.
| Configuration RAID | Nombre de défaillances tolérées | Minimum d’hôtes requis |
|---|---|---|
| Raid-1 (Mise en miroir) Paramètre par défaut. | 1 | 3 |
| RAID-5 (Code d’effacement) | 1 | 4 |
| RAID-1 (Mise en miroir) | 2 | 5 |
| RAID-6 (Code d’effacement) | 2 | 6 |
| RAID-1 (Mise en miroir) | 3 | 7 |
Stockage
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.
Mise en réseau
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.
Notes
Pour les emplacements où ExpressRoute Global Reach n’est pas activé, par exemple en raison de réglementations locales, vous devez créer une solution de routage à l’aide de machines virtuelles Azure IaaS. Pour obtenir des exemples, consultez Azure Cloud Adoption Framework - Topologie réseau et connectivité pour Azure VMware Solution.
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 clients
Azure VMware Solution ne stocke pas les données client.
Versions des logiciels VMware
Les versions de la solution logicielle VMware utilisées dans les nouveaux déploiements de clouds privés Azure VMware Solution sont les suivantes :
| Logiciel | Version |
|---|---|
| VMware vCenter Server | 8.0 U2d |
| VMware ESXi | 8.0 U2b |
| VMware vSAN | 8.0 U2 |
| Format VMware vSAN sur disque | 19 |
| Architecture de stockage VMware vSAN | OSA |
| VMware NSX | 4.1.1 |
| VMware HCX | 4.9.1 |
| Gestionnaire de Site Recovery VMware | 8.8.0.3 |
| Réplication VMware vSphere | 8.8.0.3 |
La version actuelle du logiciel est appliquée aux nouveaux clusters qui sont ajoutés à un cloud privé existant, si la version de 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 :
- Collecter 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.
| Rôle | Tâche/détails |
|---|---|
| Microsoft - Azure VMware Solution | Infrastructure physique
(facultatif) Déploiement de HCX VMware avec un profil de calcul entièrement configuré côté cloud en tant que module complémentaire (facultatif) VMware SRM déploie, met à niveau et scale-up/down Prise en charge : Plateformes de cloud privé et VMware HCX |
| Client | Demande de devis à Microsoft pour des hôtes Azure VMware Solution Planifiez et créez une requête de clouds privés sur le Portail Azure avec :
Ajout ou suppression de demandes d’hôtes au cluster à partir du portail Déploiement/gestion du cycle de vie des solutions partenaires (tierces) |
| Écosystème de partenaires | Prise en charge de leur produit/solution. Pour référence, voici quelques exemples de solutions/produits partenaires Azure VMware Solution pris en charge :
|
Étapes suivantes
L’étape suivante consiste à apprendre les concepts clés de l’architecture d’un cloud privé.