Fiabilité dans Azure VMware Solution

Azure VMware Solution fournit des clouds privés qui contiennent des clusters VMware vSphere créés à partir d’une infrastructure Azure nue dédiée. Vous pouvez migrer des charges de travail à partir de vos environnements locaux, déployer de nouvelles machines virtuelles et utiliser des services Azure à partir de vos clouds privés. Vous pouvez utiliser une combinaison de fonctionnalités VMware et Azure natives pour activer la haute disponibilité et la résilience de vos charges de travail.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure VMware Solution résilient aux pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Azure VMware Solution (SLA).

Recommandations concernant le déploiement de production

Les déploiements d’Azure VMware Solution nécessitent une planification minutieuse sur une gamme de domaines et nécessitent souvent plusieurs services Azure. Pour obtenir des instructions détaillées, consultez les charges de travail Azure VMware Solution dans le Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Azure VMware Solution utilise une infrastructure hyperconvergée avec des clusters VMware vSphere.

Lorsque vous déployez Azure VMware Solution, vous déployez un cloud privé, qui a un ou plusieurs clusters. Chaque cluster contient des hôtes ESXi qui fournissent le calcul, le stockage via vSAN et la mise en réseau via VMware NSX. Il existe deux générations d’Azure VMware Solution :

Gen 1 utilise du matériel nu spécialisé pour les nœuds et utilise des approches réseau dédiées. Pour plus d’informations sur les concepts clés, consultez les concepts de cloud privé et de cluster Azure VMware Solution.
Gen 2 utilise des types de machines virtuelles Azure standard et des réseaux virtuels Azure. Cette architecture simplifie l’architecture réseau, améliore les vitesses de transfert de données, réduit la latence des charges de travail et améliore les performances lors de l’accès à d’autres services Azure.

Tolérance de panne

Azure VMware Solution fournit plusieurs mécanismes pour gérer les erreurs au niveau de l’infrastructure et de l’application :

Haute disponibilité vSphere (HAUTE DISPONIBILITÉ) : la haute disponibilité vSphere surveille les hôtes ESXi et les machines virtuelles. En cas d’échec d’un hôte, il redémarre automatiquement les machines virtuelles affectées sur des hôtes sains. La fonctionnalité vSphere HA est activée par défaut et réserve la capacité de calcul et de mémoire en cas de défaillance d’un seul nœud.
Tolérance de panne vSAN : les stratégies de stockage vSAN protègent contre les erreurs temporaires au niveau du stockage en conservant plusieurs copies de données entre les hôtes. Si un chemin de stockage ou un disque rencontre des problèmes temporaires, vSAN gère automatiquement le basculement vers des chemins de stockage sains.
Redondance du réseau : Azure VMware Solution fournit des chemins réseau redondants et plusieurs cartes réseau VMkernel pour gérer les erreurs temporaires au niveau du réseau.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Pour les applications s’exécutant sur des machines virtuelles Azure VMware Solution, implémentez des pratiques de gestion des erreurs temporaires standard :

Configurer des stratégies de nouvelle tentative appropriées avec un repli exponentiel.
Utiliser des modèles de coupe-circuit pour les appels de services externes
Surveiller l’intégrité de l’application et implémenter une dégradation maîtrisée
Concevoir des applications sans état si possible pour réduire l’impact des redémarrages de machines virtuelles

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure VMware Solution Gen 1 prend en charge les zones de disponibilité via des clusters étendus, qui distribuent les hôtes ESXi entre deux zones de disponibilité dans une région. Microsoft sélectionne les zones à utiliser. Votre cluster s’exécute dans une configuration active-active sur les deux zones, et vSAN s’étend également sur plusieurs zones. Vous pouvez indiquer si chaque charge de travail est déployée dans une ou deux zones.

Un nœud témoin est automatiquement déployé dans une troisième zone de disponibilité pour fournir un quorum pour les scénarios fractionnés de cerveau. Microsoft gère automatiquement le nœud témoin.

Un cluster standard est un cluster qui n’est pas étendu entre les zones. Dans un cluster standard, le cluster et tous ses hôtes ESXi sont considérés comme nonzonaux ou régionaux. Les clusters nonzonaux peuvent être placés dans n’importe quelle zone de disponibilité dans la région et Microsoft sélectionne la zone. Si une zone de disponibilité dans la région subit une panne, les clusters et les hôtes nonzonaux peuvent se trouver dans la zone affectée et peuvent rencontrer des temps d’arrêt.

Azure VMware Solution Gen 2 prend en charge les déploiements zonaux de clouds privés. Lorsque vous configurez un cloud privé zonal, chacun de ses clusters et tous ses hôtes ESXi sont déployés dans une seule zone de disponibilité que vous sélectionnez.

Un cloud privé zonal ne protège pas contre les défaillances de zone de disponibilité. Vous pouvez déployer plusieurs clouds privés dans des zones de disponibilité distinctes pour une résilience plus élevée, mais vous êtes responsable du déploiement et de la configuration de chaque cloud privé indépendamment.

Si vous ne sélectionnez pas de zone de disponibilité, votre cloud privé, ses clusters et tous leurs hôtes ESXi sont considérés comme nonzonaux ou régionaux. Les clusters nonzonaux peuvent être placés dans n’importe quelle zone de disponibilité dans la région et Microsoft sélectionne la zone. Si une zone de disponibilité dans la région subit une panne, les clusters nonzonaux peuvent se trouver dans la zone affectée et peuvent rencontrer des temps d’arrêt.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres générations, sélectionnez la génération appropriée au début de cette page.

Spécifications

Prise en charge de la région : Les clusters étendus sont disponibles dans certaines régions Azure qui prennent en charge la configuration de cluster étendu. Vérifiez la table des zones de disponibilité des régions Azure pour voir le support des régions actuelles de la correspondance des types d'hôte.
Hôtes minimum : Déployez un minimum de six hôtes sur deux zones de disponibilité (trois hôtes par zone) pour activer la configuration de cluster étendu. Lorsque vous effectuez un scale-in ou un scale-out, vous devez effectuer une mise à l’échelle à deux à la fois afin que le nombre d’hôtes soit égal dans chaque zone.
SKU d’hôte : Les clusters étendus sont pris en charge avec les types d’hôtes AV36, AV36P et AV52. La référence SKU AV64 n’est pas prise en charge avec des clusters étendus.

Prise en charge de la région : Vous pouvez déployer des clouds privés zonaux dans des régions qui prennent en charge Azure VMware Solution Gen 2 et prennent également en charge les zones de disponibilité.

Considérations

Chaque zone de disponibilité d’une région peut prendre en charge des types d’hôtes spécifiques. Pour obtenir la liste détaillée des types d’hôtes disponibles dans chaque zone, consultez la zone de disponibilité de la région Azure pour la table de mappage de type hôte.

Coûts

Vous entraînez des coûts pour chaque nœud du cluster, quelle que soit la configuration de la zone de disponibilité du cluster. Pour obtenir des informations détaillées sur la tarification, consultez la tarification d’Azure VMware Solution.

Configurez la prise en charge des zones de disponibilité

Déployez un nouveau cluster : Lorsque vous créez un cloud privé Azure VMware Solution dans une région prise en charge, vous pouvez le configurer en tant que cluster étendu pendant le déploiement. Cette configuration répartit automatiquement les hôtes entre deux zones de disponibilité. Pour plus d’informations, consultez Déployer des clusters étendus vSAN.
Clusters existants : Vous ne pouvez pas convertir un cluster standard en cluster étendu, ni convertir un cluster étendu en cluster standard. Au lieu de cela, vous devez déployer un nouveau cluster et migrer vos charges de travail.

Déployez un nouveau cluster : Lorsque vous créez un cloud privé Azure VMware Solution dans une région prise en charge, vous pouvez sélectionner sa zone de disponibilité.
Clusters existants : Vous ne pouvez pas modifier la configuration de la zone de disponibilité d’un cluster existant. Au lieu de cela, vous devez déployer un nouveau cluster et migrer vos charges de travail.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque votre cluster est étendu et que toutes les zones de disponibilité sont opérationnelles.

Opération interrégion : Les machines virtuelles peuvent s’exécuter sur des hôtes dans l’une ou l’autre zone de disponibilité. Le positionnement des machines virtuelles peut être contrôlé à l’aide des règles d’affinité drS vSphere et anti-affinité pour optimiser les performances ou les exigences de disponibilité.
Réplication des données interrégions : vSAN réplique les données de manière synchrone entre les zones de disponibilité. Chaque opération d’écriture est confirmée par les deux zones avant l’achèvement, ce qui garantit l’intégrité cohérente des données.

Cette section décrit ce qu’il faut attendre lorsque votre cluster est déployé dans un cloud privé zonal et que toutes les zones de disponibilité sont opérationnelles.

Opération interrégion : Les machines virtuelles s’exécutent sur des hôtes dans la zone de disponibilité du cluster.
Réplication des données interrégions : Aucune donnée n’est répliquée vers une autre zone.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque votre cluster est étendu et qu’une panne de zone de disponibilité se produit.

Détection et réponse : Azure VMware Solution gère la réponse au niveau de l’infrastructure aux défaillances de zone. La haute disponibilité vSphere (HA) détecte automatiquement les défaillances de zone et lance les procédures de redémarrage de VM si nécessaire.

Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

Demandes actives : Toutes les machines virtuelles exécutées dans la zone de disponibilité ayant échoué sont redémarrées sur les hôtes de la zone de disponibilité survivante. Les requêtes et connexions actives aux machines virtuelles affectées sont arrêtées, et les clients sont responsables de leur nouvelle tentative.
Temps d’arrêt attendu : Le temps de redémarrage des machines virtuelles ayant échoué dans la zone saine est généralement de quelques minutes, en fonction de la configuration de la machine virtuelle et des procédures de démarrage. Le cluster étendu reste opérationnel avec une capacité réduite.

Si la zone de disponibilité ayant échoué contient le nœud témoin, le témoin devient inaccessible. Tant que les réplicas de données suffisants restent disponibles, les hôtes de données et les charges de travail en cours d’exécution continuent de fonctionner sans perte de données immédiate. Toutefois, vSAN perd la connaissance du quorum dans cet état, ce qui l’empêche de prendre en toute sécurité des décisions de placement et de récupération et provoque le blocage de certaines opérations, telles que la mise sous tension de la machine virtuelle après les défaillances, le rééquilibrage et les réparations.
Perte de données attendue : Étant donné que vSAN utilise la réplication synchrone entre les zones, aucune perte de données n’est attendue lors d’une défaillance de zone.
Redistribution : vSphere DRS redistribue automatiquement les charges de travail de machine virtuelle dans la zone de disponibilité survivante. Le routage du trafic réseau via VMware NSX s’adapte automatiquement au nouveau placement de machine virtuelle.

Cette section décrit ce qu’il faut attendre lorsque votre cluster est déployé dans un cloud privé zonal et qu’une panne de zone de disponibilité se produit.

Détection et réponse : Vous devez détecter la perte d’une zone de disponibilité. Si nécessaire, vous pouvez lancer un basculement vers un cluster secondaire que vous avez préalablement créé dans une autre zone de disponibilité.

Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

Demandes actives : Les requêtes et connexions actives aux machines virtuelles affectées sont arrêtées, et les clients sont responsables de leur nouvelle tentative.
Temps d’arrêt attendu : Lorsqu’une zone n’est pas disponible, votre cluster et ses charges de travail ne sont pas disponibles tant que la zone de disponibilité n’est pas récupérée.
Perte de données attendue : Les données de la zone affectée ne sont pas disponibles tant que la zone n’est pas récupérée.
Redistribution: Vous êtes responsable du basculement du trafic vers d’autres clusters dans des zones saines, si nécessaire.

Récupération de la zone

Lorsque la zone de disponibilité récupère, vSphere DRS peut éventuellement redistribuer des machines virtuelles à la zone récupérée en fonction de vos règles de configuration et d’affinité drS. Vous pouvez également contrôler manuellement le positionnement des machines virtuelles à l’aide d’opérations vMotion.

Lorsque la zone de disponibilité récupère, les clusters et les hôtes de la zone sont à nouveau disponibles. Vous êtes responsable des procédures de récupération de zone et de la synchronisation des données dont vos charges de travail ont besoin.

Tester les pannes de zone

Vous pouvez simuler des défaillances de zone en :

Utilisation de vSphere pour placer les hôtes en mode maintenance pour simuler des défaillances au niveau de la zone.
Valider que les systèmes de sauvegarde et de surveillance continuent à fonctionner pendant des défaillances simulées.

Test de la résilience des applications aux redémarrages de machines virtuelles et des modifications de chemin d’accès réseau, en particulier lorsque vous avez étendu des clusters ou déployez des applications entre des clusters distincts dans différentes zones.

Étant donné qu’Azure VMware Solution gère la réponse de l’infrastructure aux défaillances de zone, vous devez principalement tester la réponse de votre application aux redémarrages de machine virtuelle.

Vous êtes responsable de toute réponse d’infrastructure aux défaillances de zone, telles que le basculement vers un autre cluster dans une autre zone ou région. Veillez à tester soigneusement vos processus de réponse.

Résilience aux défaillances à l’échelle de la région

Chaque cluster Azure VMware Solution est déployé dans une seule région Azure. Si la région devient indisponible, votre cloud privé et toutes les ressources qu’elle contient deviennent indisponibles.

Toutefois, vous pouvez également concevoir des solutions multirégions personnalisées qui combinent différentes approches ou s’intègrent à votre infrastructure existante pour répondre à vos besoins métier et objectifs de récupération spécifiques.

Solutions multirégions personnalisées pour la résilience

Pour obtenir une résilience multirégion avec Azure VMware Solution, vous devez déployer des clouds privés distincts dans plusieurs régions et implémenter le basculement et d’autres solutions de récupération d’urgence.

Il existe une gamme d’options qui prennent en charge différentes exigences. Pour plus d’informations, consultez les solutions de sauvegarde et de récupération d’urgence tierces pour Azure VMware : Limitations, compatibilité et problèmes connus.

Sauvegarde et restauration

Azure VMware Solution sauvegarde automatiquement les composants de gestion (vCenter Server, NSX Manager et HCX Manager si activé). Pour effectuer une restauration à partir de ces sauvegardes de gestion, créez une demande de support Azure.

Pour vos charges de travail de machine virtuelle, Azure VMware Solution prend en charge plusieurs approches de sauvegarde. Pour plus d’informations, consultez les solutions de sauvegarde pour les machines virtuelles Azure VMware Solution.

Résilience à la maintenance du service

Azure effectue la maintenance automatique de la plateforme pour appliquer des mises à jour de sécurité, déployer de nouvelles fonctionnalités et améliorer la fiabilité du service.

Pour en savoir plus sur l’effet que la maintenance peut avoir sur les composants d’Azure VMware Solution et pour comprendre les composants que vous êtes responsable de la maintenance et de ceux que Microsoft gère, consultez les meilleures pratiques de maintenance du cloud privé Azure VMware Solution.

Vous pouvez configurer les fenêtres de maintenance de votre cluster pour réduire la probabilité de maintenance affectant vos charges de travail de production. Pour plus d’informations, consultez Planifier la maintenance en libre-service pour Azure VMware Solution (préversion publique).

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Azure VMware Solution fournit différentes contrats SLA de disponibilité pour l’infrastructure de charge de travail et pour les opérations de gestion.

Les clusters configurés en tant que clusters étendus ont un contrat SLA de disponibilité d’infrastructure de charge de travail plus élevé.

Toutefois, pour pouvoir bénéficier des contrats SLA de disponibilité, vous devez configurer votre cluster de manière spécifique. Reportez-vous au texte SLA pour des informations détaillées.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-02-19