Créer la grappe vSAN VMware étirée

Une fois toutes les configurations préalables terminées, vous pouvez maintenant créer la grappe étendue vSAN VMware. Cette étape formalise la connexion entre les hôtes d'OCI Dedicated Region A et OCI Dedicated Region B, ainsi que le noeud Témoin déployé dans une troisième région.

Vous pouvez utiliser l'Assistant Démarrage rapide ou naviguer directement jusqu'à : Grappe, Configuration, vSAN, domaines d'erreur et grappe étirée dans l'interface utilisateur VMware vCenter.

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

  • Affecter des hôtes dédiés à OCI Dedicated Region à Domaine d'erreur 1
  • Affecter des hôtes B pour la région dédiée OCI au domaine d'erreur 2
  • Spécifiez l'hôte témoin (ajouté précédemment) pour le quorum

Pour plus de détails, voir Exigences relatives aux grappes étirées et VMware vSAN Stretched Cluster Guide.

Une fois le cluster étiré créé :

  • Exécutez les vérifications d'état vSAN pour valider l'intégrité de la grappe.
  • Corriger toute erreur liée au réseau (par exemple, problème de non-concordance de MTU ou de routage).

Note :

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 : Comment supprimer des objets inaccessibles dans le magasin de données vSAN

Lorsque vous avez terminé, la grappe doit indiquer une note d'état vSAN dans la valeur 90s élevée, ce qui indique une configuration étendue réussie.

Configurer NSX

Avec la grappe vSAN VMware étirée, mettez à jour NSX VMware pour prendre en charge le réseau superposé entre sites. Cette étape garantit que les hôtes ESXi des deux régions peuvent communiquer sur des tunnels NSX à l'aide de leurs zones de transport respectives.

Cloner la configuration NSX TEP
  • Copiez le groupe d'adresses IP NSX TEP à partir du gestionnaire NSX B pour la région dédiée OCI vers le gestionnaire NSX pour la région dédiée OCI.
  • Pour éviter les conflits d'adresse IP avec l'hôte de gestion ESXi toujours présent dans la région dédiée OCI B, configurez le nouveau groupe d'adresses IP dans la région dédiée OCI A pour commencer à partir de .10.

    Exemple : Dans un gestionnaire NSX pour région dédiée OCI, créez un groupe TEP avec un intervalle de .10 à.20 pour les hôtes B pour région dédiée OCI afin de garantir qu'il n'y a pas de chevauchement avec les adresses IP existantes.

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

    Note : Dans certains scénarios, en particulier après un événement de basculement, il est possible que les interfaces de tunnel NSX ne s'affichent pas correctement. Pour ce faire :

    • Redémarrez l'hôte ESXi concerné ou
    • Exécutez le redémarrage services.sh au moyen de SSH sur l'hôte.

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

Créer des segments de superposition NSX
  • Créer quatre segments de superposition NSX.
  • Assurez-vous que ces segments sont visibles et synchronisés sur tous les hôtes ESXi des deux sites.
Configurer DHCP (facultatif)
  • Facultativement, configurez 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é superposée de bout en bout
  • Déployez quatre machines virtuelles, en plaçant une machine sur chaque hôte dans les deux régions.
  • Affectez à chaque machine virtuelle une adresse IP statique dans l'intervalle de segments correspondant.
  • Ping sur les passerelles de segment et entre les machines virtuelles pour valider la connectivité de superposition L3 dans l'environnement étendu.

Activer la connectivité externe pour les machines virtuelles superposées

Pour permettre aux machines virtuelles superposées NSX VMware d'accéder aux réseaux externes, configurez les règles NAT et le routage pour les réseaux VLAN pertinents.

Dans VCN-MGMT-Active et VCN-MGMT-Failover, mettez à jour la configuration NAT pour le réseau VLAN de la liaison montante 1 de périphérie de réseau NSX :

  • Utilisez les mêmes adresses IP d'accès externes dans les deux régions, correspondant à celles utilisées lors du déploiement d'une région OCI dédiée.
  • Vérifiez que l'adresse IP utilisée est l'adresse IP virtuelle hautement disponible pour les noeuds NSX Edge, visible dans le gestionnaire NSX.

Mettez également à jour les règles d'accès externe pour les réseaux 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 en nuage virtuels.

Prise en charge de la transmission DNS

Les machines virtuelles superposées utilisent généralement un transmetteur DNS (par exemple, 192.168.253.253) défini dans NSX-T. Pour acheminer ces interrogations DNS :

  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 MV superposés)
    • Cible : passerelle NAT
    • Adresse IP du transmetteur 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éaffecter les réseaux VLAN de l'hôte ESXi au VCN flottant

Dans la configuration courante, chaque hôte ESXi est provisionné avec deux cartes NIC physiques, chacune associée à un jeu de réseaux VLAN par défaut configuré au moyen d'attachements de carte VNIC à VCN-Primary (Région dédiée OCI A) et VCN-Secondary (Région dédiée OCI B). Ces cartes vNIC sont configurées à l'aide du bloc CIDR secondaire (172.45.0.0/16) attaché aux réseaux en nuage virtuels respectifs.

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

Migrer les cartes vNIC 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, allez à Service de calcul, ESXi Hôtes.
  2. Supprimer les attachements de carte VNIC existants : Pour chaque hôte, supprimer les cartes VNIC associées aux réseaux VLAN 201 et supérieurs de VCN-Principal ou VCN-Secondaire.

    Note :

    Cette étape est obligatoire, car une nouvelle carte VNIC ne peut pas être créée pour le même VLAN alors que l'ancienne existe.
  3. Recréez des cartes vNIC dans le VCN flottant :
    • Créez une nouvelle carte VNIC pour chaque VLAN du VCN flottant correspondant :
      • Utilisez VCN-MGMT-Active dans OCI Dedicated Region A
      • Utiliser VCN-MGMT-Failover dans la région dédiée OCI B
    • Sélectionnez le réseau VLAN avec le suffixe -NEW approprié pour le distinguer de l'initial.

    Répétez ce processus pour les deux cartes vNIC 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.

    Considérations spéciales pour les hôtes de site secondaire

    Après avoir migré les cartes vNIC pour les hôtes du site principal, répétez le processus pour tous les hôtes du site secondaire. Notez toutefois un détail clé :

    • Les composants de gestion vSphere du site secondaire ont été déployés initialement sur un réseau VLAN temporaire (par exemple, VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Ce réseau VLAN temporaire peut rester en place pendant la transition. Il n'a pas d'incidence 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 flux de travail de migration de la carte VNIC et du réseau.

    Incidence et récupération de la connectivité

    Lors des mises à jour des cartes VNIC, une perte temporaire de connectivité vers les hôtes vCenter, NSX Manager ou ESXi est attendue. Pour assurer la récupération :

    1. Vérifiez les attachements de passerelle DRG : Vérifiez que les réseaux en nuage virtuels de gestion appropriés (actifs et de basculement) sont attachés à leurs passerelles de routage dynamique (DRG) respectives.
    2. Mettre à jour les tables de routage :
      • Mettez à jour la table de routage principale dans chaque VCN de gestion pour pointer vers la passerelle DRG.
      • Mettez à jour les tables de routage du sous-réseau d'hôte bastion pour garantir que le trafic de gestion est acheminé correctement entre les réseaux en nuage 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 les règles de groupe de sécurité de réseau et la propagation des routes entre les réseaux en nuage virtuels.

    Nettoyage de la migration après la carte vNIC

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

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

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

    • Vous pouvez observer des indicateurs d'avertissement dans la page des ressources du SDDC de la console OCI, car le service Oracle Cloud VMware Solution ne fait plus le suivi des composants initialement déployés dans VCN-Primary.

    Mettre à jour le routage pour les nouveaux attachements de VCN

    1. Attachez VCN-MGMT-Active à la passerelle DRG dans la région OCI dédiée A.
    2. Mettre à jour les tables de routage :
      • Pour VCN-MGMT-Active : pointez la route par défaut (0.0.0.0/0) vers la passerelle DRG.
      • Pour le sous-réseau d'hôte bastion dans VCN-Primary : Mettez à jour sa table de routage pour qu'elle pointe vers la passerelle DRG afin de s'assurer qu'elle peut toujours accéder au gestionnaire NSX VMware vCenter et VMware.

    Une fois ces modifications effectuées, VMware vCenter et le gestionnaire NSX VMware dans la région dédiée OCI A doivent être accessibles à partir de l'hôte bastion, même si leurs interfaces sous-jacentes résident désormais dans un VCN différent.

Configurer les règles d'affinité DRS, la haute disponibilité et la politique de stockage vSAN VMware

Une fois que la grappe étendue est pleinement opérationnelle et que le réseau est stable sur les deux sites, configurez le programmateur de ressources réparties (DRS), la haute disponibilité et affectez une politique de stockage vSAN VMware sensible au site aux machines virtuelles de charge de travail et de gestion.

Ces configurations assurent le positionnement optimal des machines virtuelles entre les domaines d'erreur et permettent une récupération automatique lors des pannes de site.

Migrer des machines virtuelles vers la grappe étirée

Commencez par migrer toutes les machines virtuelles de gestion et toutes les machines virtuelles de charge de travail de test vers la grappe étirée nouvellement créée :

  • Utilisez vMotion pour déplacer les machines virtuelles de leurs grappes propres au site initial vers la grappe agrandie.
  • Si tout est configuré correctement (réseau, stockage, groupes de ports), la migration de la machine virtuelle doit se terminer sans problème.

Si des règles NSX DRS par défaut existent et sont réglées à DOIT, supprimez-les. Ceux-ci peuvent interférer avec les opérations de haute disponibilité et empêcher le basculement des noeuds NSX Edge et des machines virtuelles NSX Manager.

Créer une machine virtuelle et des groupes d'hôtes

Définissez les groupes d'affinité pour le positionnement de la charge globale :

  1. Créer des groupes d'hôtes :
    • Regrouper les hôtes appartenant au site principal.
    • Regrouper les 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 des hôtes dans chaque site (telles que vCenter, gestionnaires NSX, noeuds NSX Edge, gestionnaire HCX et autres, le cas échéant).
    • De même, regroupez toutes les machines virtuelles de charge de travail (dans notre cas, toutes les machines virtuelles de test).

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

Une fois les groupes définis :

  • Créez des règles d'affinité entre la machine virtuelle et l'hôte pour conserver les machines virtuelles situées sur les hôtes dans le site voulu.
  • Utilisez les règles Exécuter des machines virtuelles sur des hôtes pour permettre la flexibilité de la haute disponibilité dans les scénarios de basculement.
  • Créez de telles règles pour les groupes de machines virtuelles de gestion et de charge de travail.

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

Activer la haute disponibilité
  • Assurez-vous que l'option HA est activée au niveau de la grappe après la mise en place des règles d'affinité.
  • L'option par défaut de redémarrage des machines virtuelles lors d'un événement de défaillance de l'hôte garantit le redémarrage de la machine virtuelle en cas de défaillances inattendues, notamment de pannes complètes du site.

Créer et appliquer une politique de stockage vSAN étirée

Pour assurer la redondance des données entre les deux sites dans une configuration étendue, définissez une nouvelle politique SBPM (Stockage-Based Policy Management) vSAN. Cette politique contrôle la répartition des données de machine virtuelle entre les domaines d'erreur et le site de témoin.

Configurez les règles de placement suivantes dans la politique :

  • Type de stockage : vSAN
  • Tolérance aux sinistres de site : Mise en miroir de site - Grappe étendue
  • Échecs à tolérer : Aucune redondance de données
  • Nombre de segments de disque par objet : 1
  • Limite d'E/S par seconde pour l'objet : 0

Laissez toutes les autres options par défaut.

Une fois la politique créée :

  1. Appliquez la politique à toutes les machines virtuelles de test et de gestion dans la grappe étendue.
  2. Naviguez jusqu'à Surveiller, vSAN, Resynchroniser les objets pour observer et suivre le processus de resynchronisation.
  3. Une fois la resynchronisation terminée, vérifiez le positionnement d'objet pour confirmer que la politique 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 apparaîtront initialement comme non conformes. Sélectionnez chaque machine virtuelle ou un groupe de machines virtuelles et affectez manuellement la politique étendue nouvellement créée pour les mettre en conformité.

De plus, naviguez jusqu'à Surveiller, vSAN, Resynchroniser des objets et des 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 le site principal, le site secondaire et le noeud témoin, en validant la conformité totale avec la conception de grappe étendue.