Déployer des clusters étendus vSAN

Dans cet article, apprenez à implémenter un cluster étendu vSAN pour un cloud privé Azure VMware Solution.

Prérequis

Suivez le processus Demander un quota d’hôte pour obtenir le quota réservé pour le nombre requis de nœuds. Fournissez les détails suivants pour faciliter le processus :

• Nom de la société
• Point de contact : e-mail
• ID d’abonnement : un nouvel abonnement distinct est requis
• Type de cloud privé : « cluster étendu »
• Région demandée : USA Est, Royaume-Uni Sud, Europe Ouest, Allemagne Centre-Ouest ou Australie Est
• Nombre de nœuds dans le premier cluster étendu : minimum 6, maximum 16 – par multiples de deux
• Plan d’expansion estimé

Déployer un cloud privé de cluster étendu

Lorsque les détails de la demande de support sont reçus, le quota est réservé à un environnement de cluster étendu dans la région demandée. L’abonnement est activé pour déployer un SDDC de cluster étendu via le portail Azure. Un e-mail de confirmation est envoyé au point de contact désigné dans les deux jours ouvrables pendant lesquels vous devriez pouvoir déployer automatiquement un cloud privé de cluster étendu via le portail Azure. Veillez à sélectionner Hôtes dans deux zones de disponibilité pour vous assurer qu’un cluster étendu est déployé dans la région de votre choix.

Une fois le cloud privé créé, vous pouvez appairer les deux zones de disponibilité à votre circuit ExpressRoute local avec Global Reach qui permet de connecter votre centre de données local au cloud privé. Le peering des deux zones de disponibilité garantit qu’une défaillance de zone de disponibilité n’entraîne pas de perte de connectivité à votre cloud privé. Étant donné qu’une clé d’autorisation ExpressRoute est valide pour une seule connexion, répétez le processus Créer une clé d’autorisation ExpressRoute dans le circuit ExpressRoute local pour générer une autre autorisation.

Répétez ensuite le processus pour appairer avec ExpressRoute Global Reach deux zones de disponibilité au circuit ExpressRoute local.

Stratégies de stockage prises en charge

Les stratégies SPBM suivantes sont prises en charge, avec un PFTT (niveau primaire de tolérance aux défaillances) de « Mise en miroir double de site » et un SFTT (niveau secondaire de tolérance aux défaillances) de « RAID 1 (Mise en miroir) » activés comme les stratégies par défaut du 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)