Concevoir des clusters étendus vSAN

Dans cet article, découvrez comment concevoir un cluster étendu vSAN pour un cloud privé Azure VMware Solution.

Background

L’infrastructure globale d’Azure est divisée en régions. Chaque région prend en charge les services d’une zone géographique donnée. Dans chaque région, Azure crée des îles isolées et redondantes d’infrastructure appelées zones de disponibilité. Une zone de disponibilité agit comme une limite pour la gestion des ressources. Le calcul et d’autres ressources disponibles pour une zone de disponibilité sont limités et peuvent être épuisés par les demandes des clients. Une zone de disponibilité est conçue pour être résiliente de manière indépendante, ce qui signifie que les échecs dans une zone n’affectent pas d’autres zones.

Avec Azure VMware Solution, les hôtes ESXi déployés dans un cluster vSphere standard résident traditionnellement dans une seule zone de disponibilité Azure et sont protégés par la haute disponibilité vSphere. Toutefois, elle ne protège pas les charges de travail contre une défaillance de zone de disponibilité Azure. Pour se protéger contre une défaillance de zone de disponibilité, un seul cluster vSAN peut être activé pour couvrir deux zones de disponibilité distinctes, appelé cluster étendu vSAN.

Les clusters étendus permettent la configuration des domaines d’erreur vSAN sur deux zones de disponibilité pour avertir vCenter Server que les hôtes résident dans chaque zone de disponibilité. Chaque domaine d’erreur est nommé d’après la zone de disponibilité dans laquelle il réside pour gagner en clarté. Lorsque vous étendez un cluster vSAN sur deux zones de disponibilité au sein d’une région, si une zone de disponibilité s’arrête, elle est traitée comme un événement de haute disponibilité vSphere et la machine virtuelle est redémarrée dans l’autre zone de disponibilité.

Avantages des clusters étendus :

• Améliorent la disponibilité des applications.
• Fournissent une fonctionnalité d’objectif de point de récupération (RPO) zéro pour les applications d’entreprise sans avoir à les reconcevoir ni à déployer des solutions de reprise d’activité coûteuses.
• Un cloud privé avec des clusters étendus est conçu pour fournir une disponibilité de 99,99 % en raison de sa résilience aux défaillances de zone de disponibilité.
• Permettent aux clients de se concentrer sur les principales exigences et fonctionnalités des applications, au lieu de la disponibilité de l’infrastructure.

Pour vous protéger contre les scénarios Split-Brain et vous aider à mesurer l’intégrité du site, un témoin vSAN managé est créé dans une troisième zone de disponibilité. Avec une copie des données dans chaque zone de disponibilité, la haute disponibilité vSphere tente de récupérer suite à une défaillance avec un simple redémarrage de la machine virtuelle.

Le diagramme suivant décrit un cluster vSAN étendu sur deux zones de disponibilité.

En résumé, les clusters étendus simplifient les besoins de protection en fournissant les mêmes contrôles et fonctionnalités approuvés en plus de la mise à l’échelle et de la flexibilité de l’infrastructure Azure.

Il est important de comprendre que les clouds privés de clusters étendus offrent uniquement une couche supplémentaire de résilience et ne traitent pas tous les scénarios d’échec. Par exemple, les clouds privés de clusters étendus :

• Ne protègent pas contre les défaillances au niveau de la région dans les scénarios de perte de données ou Azure causés par des problèmes d’application ou des stratégies de stockage mal planifiées.
• Fournissent une protection contre un échec de zone unique, mais ne sont pas conçus pour assurer la protection contre les défaillances doubles ou progressives. Par exemple :

  • Malgré diverses couches de redondance intégrées à la structure, si une défaillance entre zones de disponibilité entraîne le partitionnement du site secondaire, la haute disponibilité vSphere démarre la mise hors tension des machines virtuelles de charge de travail sur le site secondaire.

    Le diagramme suivant montre le scénario de partitionnement de site secondaire.

    

  • Si le partitionnement du site secondaire a abouti à l’échec du site principal à la place ou a entraîné un partitionnement complet, la haute disponibilité vSphere tente de redémarrer les machines virtuelles de charge de travail sur le site secondaire. Si la haute disponibilité vSphere a tenté de redémarrer les machines virtuelles de charge de travail sur le site secondaire, elle a placé les machines virtuelles de charge de travail dans un état instable.

    Les diagrammes suivants montrent les scénarios d’échec de site préféré et de partitionnement réseau complet.

    

    

Il convient de noter que ces types de défaillances, bien que rares, dépassent l’étendue de la protection offerte par un cloud privé de cluster étendu. En raison de ces types d’échecs rares, une solution de cluster étendu doit être considérée comme une solution de haute disponibilité avec plusieurs zones de disponibilité dépendante de la haute disponibilité vSphere. Il est important de comprendre qu’une solution de cluster étendu n’est pas destinée à remplacer une stratégie complète de reprise d’activité multirégion qui peut être utilisée pour garantir la disponibilité des applications. Cela s’explique par le fait qu’une solution de reprise d’activité comporte généralement des plans de gestion et de contrôle distincts dans des régions Azure distinctes. Les clusters étendus Azure VMware Solution ont un plan de gestion et de contrôle unique étendu sur deux zones de disponibilité au sein de la même région Azure. Par exemple, un serveur vCenter, un cluster NSX Manager, une paire de machines virtuelles NSX Edge.

Disponibilité régionale des clusters étendus

Les clusters étendus Azure VMware Solution sont disponibles dans les régions suivantes :

• Royaume-Uni Sud (sur AV36 et AV36P)
• Europe Ouest (sur AV36 et AV36P)
• Allemagne Centre-Ouest (sur AV36 et AV36P)
• Australie Est (sur AV36P)
• USA Est (sur AV36P)

Stratégies de stockage prises en charge

Les stratégies SPBM suivantes sont prises en charge, avec un PFTT de « Mise en miroir de sites double » et un SFTT de « RAID 1 (mise en miroir) » activés comme stratégies par défaut pour le cluster :

• Paramètres de tolérance pour la reprise d’activité de site (PFTT) :
  • Mise en miroir de sites double
  • Aucun : conserver les données sur les machines préférées
  • Aucun : conserver les données sur les machines non préférées
• Échecs locaux à tolérer (SFTT) :
  • 1 échec – RAID 1 (mise en miroir)
  • 1 échec : RAID 5 (codage d’effacement), nécessite un minimum de 4 hôtes dans chaque zone de disponibilité
  • 2 échecs – RAID 1 (mise en miroir)
  • 2 échecs : RAID 6 (codage d’effacement), nécessite un minimum de 6 hôtes dans chaque zone de disponibilité
  • 3 échecs – RAID 1 (mise en miroir)

FAQ

D’autres régions sont-elles planifiées ?

Actuellement, il existe quatre régions prises en charge pour les clusters étendus.

Quel est le type de contrat SLA fourni par Azure VMware Solution avec les clusters étendus ?

Un cloud privé créé avec un cluster étendu vSAN est conçu pour offrir un engagement de disponibilité d’infrastructure de 99,99 % lorsque les conditions suivantes existent :

• Au moins six nœuds sont déployés dans le cluster (3 dans chaque zone de disponibilité).
• Lorsqu’une stratégie de stockage de machine virtuelle de PFTT de « Mise en miroir de sites double » et de SFTT de 1 est utilisée par les machines virtuelles de charge de travail.
• La conformité aux exigences supplémentaires capturées dans les détails du contrat SLA d’Azure VMware Solution est requise pour atteindre les objectifs de disponibilité.

Dois-je choisir la zone de disponibilité dans laquelle un cloud privé est déployé ?

Non. Un cluster étendu est créé entre deux zones de disponibilité, tandis que la troisième zone est utilisée pour déployer le nœud témoin. Étant donné que toutes les zones sont utilisées efficacement pour déployer un environnement de cluster étendu, aucun choix n’est proposé au client. Au lieu de cela, le client choisit de déployer des hôtes dans plusieurs zones de disponibilité au moment de la création du cloud privé.

Quelles sont les limitations à connaître ?

• Une fois qu’un cloud privé est créé avec un cluster étendu, il ne peut pas être changé en un cloud privé de cluster standard. De même, un cloud privé de cluster standard ne peut pas être changé en un cloud privé de cluster étendu après la création.
• Le scale-out et le scale-in des clusters étendus ne peuvent se produire que dans des paires. Un minimum de six nœuds et un maximum de 16 nœuds sont pris en charge dans un environnement de cluster étendu. Pour plus d’informations, consultez Abonnement Azure et limites, quotas et contraintes de service.
• Les machines virtuelles de charge de travail de client sont redémarrées avec une priorité de haute disponibilité vSphere moyenne. Les machines virtuelles de gestion ont la priorité de redémarrage la plus élevée.
• La solution s’appuie sur la haute disponibilité vSphere et vSAN pour les redémarrages et la réplication. L’objectif de délai de récupération (RTO) est déterminé par le temps nécessaire à la haute disponibilité vSphere pour redémarrer une machine virtuelle sur la zone de disponibilité restante après l’échec d’une seule zone de disponibilité.
• Actuellement non pris en charge dans un environnement de cluster étendu :
  • Fonctionnalités récemment publiées comme l’adresse IP publique jusqu’à NSX Edge et le stockage externe, comme les magasins de données ANF.
  • Compléments de récupération d’urgence tels que VMware SRM, Zerto et JetStream.
• Ouvrez un ticket de support à partir du portail Azure pour les scénarios suivants (veillez à sélectionner Clusters étendus en tant que type de problème) :
  • Connectez un cloud privé à un cloud privé de cluster étendu.
  • Connectez deux clouds privés de clusters étendus dans une seule région.

Quels types de latences dois-je attendre entre les zones de disponibilité ?

Les clusters étendus vSAN fonctionnent dans une durée aller-retour de 5 millisecondes et une bande passante de 10 Gbits/s ou plus entre les zones de disponibilité qui hébergent les machines virtuelles de charge de travail. Le déploiement de cluster étendu Azure VMware Solution suit ce principe directeur. Tenez compte de ces informations lors du déploiement d’applications (avec un SFTT de mise en miroir de sites double, qui utilise des écritures synchrones) qui ont des exigences de latence strictes.

Puis-je combiner des clusters étendus et standard dans mon cloud privé ?

Non. Une combinaison de clusters étendus et standard n’est pas prise en charge dans le même cloud privé. Un environnement de cluster étendu ou standard est sélectionné lorsque vous créez le cloud privé. Une fois qu’un cloud privé est créé avec un cluster étendu, l’hypothèse est que tous les clusters créés dans ce cloud privé sont étendus par nature.

Combien coûte la solution ?

Les clients sont facturés en fonction du nombre de nœuds déployés dans le cloud privé.

Suis-je facturé pour le nœud témoin et pour le trafic entre zones de disponibilité ?

Non. Les clients ne voient pas de frais pour le nœud témoin et le trafic entre zones de disponibilité. Le nœud témoin est entièrement géré par le service et Azure VMware Solution fournit la gestion de cycle de vie requise du nœud témoin. Étant donné que toute la solution est gérée par le service, le client doit uniquement identifier la stratégie SPBM appropriée à définir pour les machines virtuelles de charge de travail. Le reste est géré via Microsoft.