Création du cluster VMware vSAN étendu

Toutes les configurations prérequises étant terminées, vous pouvez maintenant créer le cluster étendu vSAN VMware. Cette étape formalise la connexion entre les hôtes de la région dédiée OCI A et de la région dédiée OCI B, ainsi que le noeud témoin déployé dans une troisième région.

Vous pouvez utiliser l'assistant de démarrage rapide ou accéder directement à : Cluster, Configurer, vSAN, Domaines de pannes et Cluster étendu dans l'interface utilisateur VMware vCenter.

Configurez les éléments suivants au cours de ce processus :

  • Affectation d'OCI Dedicated Region à des hôtes au domaine de pannes 1
  • Affectation d'hôtes B de région dédiée OCI au domaine de pannes 2
  • Spécification de l'hôte témoin (précédemment ajouté) pour le quorum

Pour plus d'informations, reportez-vous aux sections Stretched Cluster Requirements et VMware vSAN Stretched Cluster Guide.

Une fois le cluster étendu créé :

  • Exécutez la commande vSAN Health Checks pour valider l'intégrité du cluster.
  • Traiter les erreurs liées à la mise en réseau (par exemple, non-concordance de MTU ou problèmes de routage).

Remarques :

Vous pouvez rencontrer des objets vSAN obsolètes sur certains hôtes à partir de leurs clusters d'origine. Reportez-vous à ce guide pour les supprimer : Suppression d'objets inaccessibles dans la banque de données vSAN

Une fois terminé, le cluster doit indiquer un score d'intégrité vSAN dans le 90s élevé, indiquant une configuration étendue réussie.

Configurer NSX

Avec le cluster vSAN VMware étendu, mettez à jour VMware NSX pour prendre en charge la mise en réseau de superposition intersite. Cette étape permet de s'assurer que les hôtes ESXi des deux régions peuvent communiquer sur les tunnels NSX à l'aide de leurs zones de transport respectives.

Cloner la configuration NSX TEP
  • Copiez le pool d'adresses IP NSX TEP de la région dédiée OCI B NSX Manager vers la région dédiée OCI A NSX Manager.
  • Pour éviter les conflits d'adresses IP avec l'hôte de gestion ESXi toujours présent dans OCI Dedicated Region B, configurez le nouveau pool d'adresses IP dans OCI Dedicated Region A pour qu'il démarre à partir de .10.

    Exemple : dans OCI Dedicated Region, dans un gestionnaire NSX, créez un pool TEP avec une plage de .10–.20 pour les hôtes B OCI Dedicated Region afin de ne pas chevaucher les adresses IP existantes.

Création d'un profil de liaison montante B OCI Dedicated Region dans OCI Dedicated Region A
  • Dans OCI Dedicated Region, gestionnaire NSX, définissez un nouveau profil de liaison montante spécifiquement pour les hôtes B OCI Dedicated Region.
  • Utilisez l'ID de VLAN correct et assurez-vous que l'ordre des liaisons montantes correspond à la configuration B de la région dédiée OCI.
Préparation des hôtes pour NSX
  • Utilisez les zones de transport OVERLAY-TZ et VLAN-TZ.
  • Lors de la préparation de l'hôte, affectez le profil de liaison montante approprié selon que l'hôte provient d'OCI Dedicated Region A ou d'OCI Dedicated Region B.

    Remarque : dans certains scénarios, en particulier après un événement de basculement, les interfaces de tunnel NSX peuvent ne pas s'afficher correctement. Pour résoudre ce problème, procédez comme suit :

    • Réinitialisez l'hôte ESXi affecté ou
    • Exécutez le redémarrage de services.sh via SSH sur l'hôte.

    Cela garantit que tous les services NSX démarrent dans le bon ordre et restaurent la stabilité du tunnel.

Créer des segments de superposition NSX
  • Créez quatre segments de superposition NSX.
  • Assurez-vous que ces segments sont visibles et synchronisés sur tous les hôtes ESXi des deux sites.
Configuration de DHCP (facultatif)
  • Vous pouvez éventuellement configurer les paramètres DHCP pour les nouveaux segments de superposition.
  • Les paramètres DNS ont déjà été configurés précédemment dans ce guide et n'ont pas besoin d'être répétés ici.
Valider la connectivité de superposition de bout en bout
  • Déployez quatre machines virtuelles, en plaçant une sur chaque hôte dans les deux régions.
  • Affectez à chaque machine virtuelle une adresse IP statique comprise dans la plage de segments correspondante.
  • Effectuer une commande ping sur les passerelles de segment et entre les machines virtuelles pour valider la connectivité de surcouche L3 dans l'environnement étendu.

Activer la connectivité externe pour les machines virtuelles de surcouche

Pour autoriser les machines virtuelles de surcouche NSX VMware à accéder aux réseaux externes, configurez les règles NAT et le routage pour les VLAN appropriés.

Dans VCN-MGMT-Active et VCN-MGMT-Failover, mettez à jour la configuration NAT pour le VLAN de liaison montante Edge NSX 1 :

  • Utilisez les mêmes adresses IP d'accès externe dans les deux régions, correspondant à celles utilisées lors du déploiement OCI Dedicated Region A.
  • Vérifiez que l'adresse IP utilisée est l'adresse IP virtuelle HA des noeuds d'axe NSX, visible dans NSX Manager.

Mettez également à jour les règles d'accès externe pour les VLAN vSphere :

  • Configurez les règles NAT pour vcenter-vip, nsxt-manager-vip et HCX-manager-vip (si HCX est utilisé) dans les deux réseaux cloud virtuels.

Prise en charge du transfert DNS

Les machines virtuelles de surcouche utilisent généralement un redirecteur DNS (par exemple, 192.168.253.253) défini dans NSX-T. Pour acheminer les requêtes DNS suivantes :

  1. Créez une table de routage dédiée pour la passerelle NAT.
  2. Définissez une route statique :
    • Destination : 10.x.x.x (sous-réseaux de machines virtuelles de surcouche)
    • Cible : passerelle NAT
    • Adresse IP du transitaire DNS : 192.168.253.253

Cette configuration doit être répliquée dans les deux sites. Associez la nouvelle table de routage à la passerelle NAT pour un comportement cohérent.

Réaffectation de VLAN d'hôte ESXi au VCN flottant

Dans la configuration en cours, chaque hôte ESXi est provisionné avec deux cartes d'interface réseau physiques, chacune étant associée à un ensemble par défaut de VLAN configurés via des attachements de carte d'interface réseau virtuelle vers VCN-Primary (OCI Dedicated Region A) et VCN-Secondary (OCI Dedicated Region B). Ces cartes d'interface réseau virtuelles sont configurées à l'aide du bloc CIDR secondaire (172.45.0.0/16) attaché aux réseaux cloud virtuels respectifs.

Pour terminer la transition vers une configuration étendue, tous les VLAN avec des balises 200 et supérieures (par exemple, pour vSphere, HCX, NSX Edge, etc.) doivent être migrés vers les réseaux cloud virtuels flottants :
  • VCN-MGMT-Active dans OCI Dedicated Region A
  • VCN-MGMT-Failover dans OCI Dedicated Region B

Migrer les cartes d'interface réseau virtuelles vers le VCN flottant

Suivez les étapes suivantes pour chaque hôte ESXi dans les deux SDDC :
  1. Accédez aux détails de l'hôte ESXi : dans la console OCI, accédez à Compute, hôtes ESXi.
  2. Supprimer les attachements de carte d'interface réseau virtuelle existants : pour chaque hôte, supprimez les cartes d'interface réseau virtuelles associées aux VLAN 201 et supérieurs de VCN-Principal ou VCN-Secondaire.

    Remarques :

    Cette étape est obligatoire car une nouvelle carte d'interface réseau virtuelle ne peut pas être créée pour le même VLAN tant que l'ancien existe.
  3. Recréez des cartes VNIC dans le VCN flottant :
    • Créez une carte d'interface réseau virtuelle pour chaque VLAN dans le VCN flottant correspondant :
      • Utilisation de VCN-MGMT-Active dans la région dédiée OCI A
      • Utilisation de VCN-MGMT-Failover dans la région dédiée OCI B
    • Sélectionnez le VLAN balisé avec le suffixe -NEW approprié pour le distinguer de l'original.

    Répétez ce processus pour les deux cartes d'interface réseau virtuelles par hôte. Nous recommandons une approche systématique : commencez par vnic0 et vnic1 pour le VLAN 201, terminez les remplacements, puis passez au VLAN suivant.

    Remarques spéciales concernant les hôtes de site secondaires

    Après avoir migré les cartes d'interface réseau virtuelles pour les hôtes du site principal, répétez le processus pour tous les hôtes du site secondaire. Cependant, notez un détail clé :

    • Les composants de gestion vSphere du site secondaire ont été initialement déployés sur un VLAN temporaire (par exemple, VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Ce VLAN temporaire peut rester en place pendant la transition. Elle n'a pas d'impact sur la fonctionnalité vSAN étendue et offre un accès de secours aux composants vCenter et NSX si nécessaire.

    La conservation de ce VLAN temporaire garantit un accès de gestion ininterrompu pendant le workflow de migration de la carte d'interface réseau virtuelle et du réseau.

    Impact de la connectivité et récupération

    Lors des mises à jour de carte d'interface réseau virtuelle, une perte temporaire de connectivité aux hôtes vCenter, NSX Manager ou ESXi est attendue. Pour garantir la récupération :

    1. Vérifier les pièces jointes DRG : confirmez que les réseaux cloud virtuels de gestion appropriés (actifs et de basculement) sont attachés à leurs passerelles de routage dynamique respectives.
    2. Mettre à jour les tables de routage:
      • Mettez à jour la table de routage principale dans chaque VCN de gestion pour qu'elle pointe vers le DRG.
      • Mettez à jour les tables de routage de sous-réseau Bastion pour vous assurer que le trafic de gestion est acheminé correctement entre les réseaux cloud virtuels et entre les régions.
    3. Valider l'accès :
      • Après la mise à jour des routes, l'accès à toutes les interfaces de gestion à partir de l'hôte Bastion doit être restauré.
      • Si des ressources restent inaccessibles, vérifiez à nouveau les règles de groupe de sécurité réseau et la propagation de routage entre les réseaux cloud virtuels.

    Nettoyage après migration de vNIC

    Une fois la migration de la carte VNIC terminée :

    • Supprimez tous les VLAN inutilisés de VCN-Primary et VCN-Secondary qui appartiennent au bloc CIDR 172.45.0.0/16.
    • Détachez le CIDR secondaire (172.45.0.0/16) de VCN-Primary car il n'est plus utilisé.

    OCI autorise le détachement CIDR uniquement lorsqu'aucune ressource active (VNIC, sous-réseaux ou VLAN) ne l'utilise.

    • Vous pouvez observer des indicateurs d'avertissement sur la page de ressource du SDDC dans la console OCI, ce qui est attendu, car le service Oracle Cloud VMware Solution ne suit plus les composants initialement déployés dans VCN-Primary.

    Mettre à jour le routage pour les nouveaux documents joints VCN

    1. Attachez VCN-MGMT-Active au DRG dans OCI Dedicated Region A.
    2. Mettre à jour les tables de routage:
      • Pour VCN-MGMT-Active : pointez le routage par défaut (0.0.0.0/0) vers le DRG.
      • Pour le sous-réseau Bastion dans VCN-Primary : mettez à jour sa table de routage pour qu'elle pointe vers le DRG afin de s'assurer qu'elle peut toujours accéder à VMware vCenter et à VMware NSX Manager.

    Une fois ces modifications effectuées, VMware vCenter et VMware NSX Manager dans OCI Dedicated Region A doivent devenir accessibles à partir de l'hôte Bastion, même si leurs interfaces sous-jacentes résident désormais dans un autre VCN.

Configuration des règles d'affinité DRS, de la haute disponibilité et de la stratégie de stockage vSAN VMware

Une fois que le cluster étendu est entièrement opérationnel et que la mise en réseau est stable sur les deux sites, configurez Distributed Resource Scheduler (DRS), High Availability (HA) et affectez une stratégie de stockage vSAN VMware tenant compte des sites aux machines virtuelles de charge globale et de gestion.

Ces configurations assurent un placement optimal des machines virtuelles dans les domaines de pannes et permettent une récupération automatique en cas de panne du site.

Migrer des machines virtuelles vers le cluster étendu

Commencez par migrer toutes les machines virtuelles de gestion et toutes les machines virtuelles de test de charge globale vers le cluster extrait que vous venez de créer :

  • Utilisez vMotion pour déplacer les machines virtuelles de leurs clusters propres au site d'origine vers le cluster étendu.
  • Si tout est configuré correctement (réseau, stockage, groupes de ports), la migration des machines virtuelles doit se terminer sans problème.

Si des règles de jeu de règles de déploiement NSX par défaut existent et sont définies sur DOIT, supprimez-les. Elles peuvent interférer avec les opérations de haute disponibilité et empêcher le basculement des noeuds en périphérie NSX et des machines virtuelles NSX Manager.

Création de machines virtuelles et de groupes d'hôtes

Définissez des groupes d'affinité pour le placement de la charge globale :

  1. Créer des groupes d'hôtes :
    • Groupez les hôtes appartenant au site principal.
    • Groupe d'hôtes appartenant au site secondaire.
  2. Créer des groupes de machines virtuelles :
    • Machines virtuelles de gestion de groupe qui doivent résider sur les hôtes de chaque site (par exemple, vCenter, gestionnaires NSX, noeuds d'axe NSX, gestionnaire HCX et autres, le cas échéant).
    • De même, regroupez toutes les machines virtuelles de charge globale (dans notre cas, toutes les machines virtuelles de test).

Définir des règles d'affinité de machine virtuelle/d'hôte

Une fois les groupes définis :

  • Créez des règles d'affinité de machine virtuelle à hôte pour conserver les machines virtuelles situées sur des hôtes sur le site prévu.
  • Utilisez les règles d'exécution des machines virtuelles sur les hôtes pour permettre une flexibilité de haute disponibilité dans les scénarios de basculement.
  • Créez ces règles pour les groupes de machines virtuelles de gestion et de charge globale.

Cette configuration garantit que, pendant le fonctionnement normal, chaque site héberge les charges de travail prévues, mais autorise la récupération automatique en cas de défaillance d'un hôte ou d'un site.

Activer la haute disponibilité (HA)
  • Assurez-vous que la HA est activée au niveau du cluster une fois les règles d'affinité en place.
  • L'option par défaut Redémarrer les machines virtuelles en cas d'échec de l'hôte garantit le redémarrage de la machine virtuelle en cas d'échec inattendu, y compris les pannes de site complètes.

Créer et appliquer une stratégie de stockage vSAN étendue

Pour assurer la redondance des données sur les deux sites dans une configuration étendue, définissez une nouvelle stratégie de gestion des stratégies basées sur le stockage (SBPM) vSAN. Cette stratégie contrôle la façon dont les données de machine virtuelle sont distribuées entre les domaines de pannes et le site témoin.

Configurez les règles de placement suivantes dans la stratégie :

  • Type de stockage : vSAN
  • Tolérance en cas de catastrophe du site : mise en miroir du site – cluster étendu
  • Echecs de tolérance : aucune redondance de données
  • Nombre de stripes de disque par objet : 1
  • Limite d'IOPS pour l'objet : 0

Conservez les valeurs par défaut de toutes les autres options.

Une fois la stratégie créée :

  1. Appliquez la stratégie à toutes les machines virtuelles de test et de gestion du cluster étendu.
  2. Accédez à Surveiller, vSAN, resynchroniser les objets pour observer et suivre le processus de resynchronisation.
  3. Une fois la resynchronisation terminée, vérifiez le placement d'objet pour vérifier que la stratégie fonctionne comme prévu :
    • Un objet de réplique se trouve sur le site principal
    • Un deuxième objet de réplique se trouve sur le site secondaire
    • Le composant témoin réside dans la région Témoin distant

Toutes les machines virtuelles apparaissent initialement comme non conformes. Sélectionnez chaque machine virtuelle ou groupe de machines virtuelles et affectez manuellement la stratégie étendue que vous venez de créer pour la mettre en conformité.

En outre, accédez à Surveiller, vSAN, resynchroniser les objets et les objets virtuels. Une fois le processus de resynchronisation terminé, vous devez observer que les objets virtuels de chaque machine virtuelle sont distribués correctement sur les noeuds Site principal, Site secondaire et Témoin, ce qui confirme la conformité totale avec la conception du cluster étendu.