Dans ce scénario, le site 1 principal est arrêté en raison d'une maintenance planifiée ou d'une panne de courant imprévue. Toutes les charges de travail sont exécutées sur le site 2 secondaire (site principal promu) et le trafic est acheminé via l'UDLR et les dispositifs NSX Edge sur le site 2. Désormais, le site 1 principal d'origine est de nouveau actif et l'administrateur de NSX souhaite récupérer les composants de NSX et restaurer toutes les charges de travail sur le site 1 principal d'origine.

L'administrateur NSX souhaite atteindre les objectifs clé suivants :
  • Réaliser un retour arrière complet de toutes les charges de travail du site 2 vers le site 1 principal d'origine avec une interruption de service minimale.
  • Conserver les adresses IP d'application après le retour arrière vers le site 1.
  • Récupérer automatiquement tous les paramètres de l'interface Edge et les paramètres de configuration de protocole BGP sur le site 1.
Note :
  • L'administrateur peut effectuer les tâches de retour arrière manuellement en utilisant vSphere Web Client ou en exécutant les REST API NSX. De plus, l'administrateur peut automatiser certaines tâches de retour arrière en exécutant un fichier de script qui contient les API à exécuter pendant le retour arrière. Ce scénario explique les étapes de retour arrière manuel à l'aide de vSphere Web Client. Toutefois, si une étape nécessite l'utilisation de l'interface de ligne de commande ou des REST API NSX, des instructions adéquates sont fournies.
  • Dans ce scénario, le workflow de récupération d'urgence est spécifique à la topologie expliquée précédemment, qui a une instance principale de NSX Manager et une instance secondaire de NSX Manager unique. Le workflow avec plusieurs instances secondaires de NSX Manager n'est pas concerné par ce scénario.

Conditions préalables

  • NSX Data Center 6.4.5 ou version ultérieure est installé sur les sites 1 et 2.
  • Les serveurs vCenter Server sur les sites 1 et 2 sont déployés avec Enhanced Linked Mode.
  • Sur les sites 1 et 2, les conditions suivantes sont réunies :
    • Aucune stratégie de sécurité spécifique à l'application n'est configurée sur un pare-feu non-NSX, le cas échéant.
    • Aucune règle de pare-feu spécifique à l'application n'est configurée sur un pare-feu non-NSX, le cas échéant.
    • Le pare-feu est désactivé sur les deux passerelles ESG, car ECMP est activé sur les UDLR et pour vous assurer que tout le trafic est autorisé.
  • Sur le site 2 (promu principal), aucune modification n'est apportée aux composants logiques universels avant le lancement du processus de retour arrière.

Procédure

  1. Lorsque le site 1 principal est de nouveau actif, vérifiez que l'instance de NSX Manager et les nœuds de cluster de contrôleurs sont sous tension et en cours d'exécution.
    1. Accédez à Mise en réseau et sécurité (Networking & Security) > Tableau de bord (Dashboard) > Présentation (Overview).
    2. Sélectionnez l'instance principale de NSX Manager dans le menu déroulant.
    3. Dans le volet Présentation du système, vérifiez l'état de l'instance de NSX Manager et des nœuds de cluster de contrôleurs.
      Un point vert plein en regard de l'instance de NSX Manager et des nœuds de contrôleur signifie que les deux composants de NSX sont sous tension et en cours d'exécution.
  2. Avant de lancer le processus de retour arrière, vérifiez ce qui suit :
    1. Sur la page Installation et mise à niveau, accédez à Gestion (Management) > NSX Managers et voyez que les deux instances de NSX Manager sur les deux sites ont un rôle principal.
    2. Sur la page Nœuds de NSX Controller, vérifiez que les nœuds de cluster de contrôleurs universels (UCC) existent sur les deux sites.
  3. Arrêtez les trois nœuds UCC associés au site 2 (promu principal).
  4. Sur la page Nœuds de NSX Controller, supprimez les trois nœuds UCC associés au site 2 (promu principal).
    Info-bulle : Vous pouvez utiliser les REST API de NSX pour supprimer un nœud de contrôleur à la fois en exécutant l'appel API suivant : https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID}. Toutefois, forcez la suppression du dernier nœud de contrôleur en exécutant l'appel API suivant : https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID}?forceRemoval=true.
  5. Assurez-vous qu'il n'y a aucune modification dans les composants universels sur le site 2 (promu principal) avant de passer à l'étape suivante.
  6. Supprimez le rôle principal sur l'instance de NSX Manager sur le site 2 (promu principal).
    1. Sur la page Installation et mise à niveau, accédez à Gestion (Management) > NSX Managers.
    2. Sélectionnez l'instance de NSX Manager sur le site 2, puis cliquez sur Actions > Supprimer un rôle principal (Remove Primary Role).
      Un message vous invite à vérifier que les contrôleurs détenus par l'instance de NSX Manager sur le site 2 sont supprimés avant de supprimer le rôle principal.
    3. Cliquez sur Oui (Yes).
      L'instance de NSX Manager sur le site 2 reçoit le rôle Transit.
  7. Sur l'instance principale de NSX Manager sur le site 1, supprimez l'instance secondaire de NSX Manager associée.
    1. Sur la page NSX Managers, sélectionnez l'instance de NSX Manager associée au site 1.
    2. Cliquez sur Actions > Supprimer un gestionnaire secondaire (Remove Secondary Manager).
    3. Cochez la case Effectuer l'opération même si NSX Manager est inaccessible (Perform Operation even if NSX Manager is inaccessible).
    4. Cliquez sur Supprimer (Remove).
  8. Enregistrez l'instance de NSX Manager sur le site 2, qui est en Transit, comme l'instance secondaire de l'instance principale de NSX Manager sur le site 1.
    Attention : Comme la sortie locale est désactivée sur la VM de contrôle de l'UDLR (VM du dispositif Edge), la VM de contrôle est automatiquement supprimée. Par conséquent, avant l'enregistrement de l'instance de NSX Manager sur le site 2 (actuellement avec le rôle Transit) avec un rôle secondaire, vérifiez que les nœuds de cluster de contrôleurs sur le site 2 sont supprimés. Si les nœuds de cluster de contrôleurs ne sont pas supprimés, une interruption de trafic réseau peut se produire.
    1. Sur la page Installation et mise à niveau, accédez à Gestion (Management) > NSX Managers.
    2. Sélectionnez l'instance de NSX Manager associée au site 1.
    3. Cliquez sur Actions > Ajouter un gestionnaire secondaire (Add Secondary Manager).
    4. Sélectionnez l'instance de NSX Manager associée au site 2.
    5. Entrez le nom d'utilisateur et le mot de passe de l'instance de NSX Manager sur le site 2, puis acceptez le certificat de sécurité.
    6. Cliquez sur Ajouter (Add).
    Après avoir terminé toutes ces sous-étapes, observez les résultats suivants :
    • L'instance de NSX Manager sur le site 1 a un rôle principal et l'instance de NSX Manager sur le site 2 a un rôle secondaire.
    • Sur l'instance de NSX Manager sur le site 2, trois nœuds de contrôleur cachés s'affichent avec l'état Déconnecté. Le message suivant s'affiche : Les propriétés du cluster de contrôleurs peuvent être lues ou mises à jour uniquement sur un gestionnaire principal ou autonome.

      Ce message signifie que l'instance secondaire de NSX Manager sur le site 2 ne peut pas établir la connectivité avec les nœuds de cluster de contrôleurs universels sur l'instance principale de NSX Manager sur le site 1. Toutefois, après quelques secondes, la connexion est rétablie, et l'état passe sur Connecté.

  9. Mettez sous tension la VM de contrôle (VM du dispositif Edge) sur l'UDLR et les dispositifs NSX Edge sur le site 1.
    1. Accédez à Mise en réseau (Networking) > VM (VMs) > Machines virtuelles (Virtual Machines).
    2. Cliquez avec le bouton droit sur le nom de VM (ID de la VM) de la VM de contrôle de l'UDLR et cliquez sur Mise sous tension (Power on).
    3. Répétez l'étape (b) pour les VM du dispositif Edge que vous souhaitez mettre sous tension.
    4. Attendez que la VM de contrôle de l'UDLR et les VM du dispositif Edge soient opérationnelles avant de passer à l'étape suivante.
  10. Vérifiez que la VM de contrôle de l'UDLR (VM du dispositif Edge) associée à l'instance secondaire de NSX Manager sur le site 2 est automatiquement supprimée.
    1. Accédez à Mise en réseau et sécurité (Networking & Security) > Dispositifs NSX Edge (NSX Edges).
    2. Sélectionnez l'instance secondaire de NSX Manager et cliquez sur un UDLR.
    3. Sur la page État, vous voyez qu'aucune VM de dispositif Edge n'est déployée sur l'UDLR.
  11. Mettez à jour l'état de NSX Controller sur le site 1 principal afin que les services du contrôleur soient synchronisés avec le site 2 secondaire.
    1. Sur la page Installation et mise à niveau, cliquez sur NSX Managers.
    2. Sélectionnez l'instance principale de NSX Manager sur le site 1.
    3. Cliquez sur Actions > Mettre à jour l'état du contrôleur (Update Controller State).
  12. Migrez les VM de charge de travail du site 2 vers le site 1.
    Note : Les VM de charge de travail existent toujours sur le site 2. Par conséquent, vous devez migrer manuellement les VM de charge de travail vers le site 1.

Résultats

Le retour arrière manuel de tous les composants et charges de travail de NSX du site secondaire (site 2) vers le site principal (site 1) est terminé.

Que faire ensuite

Vérifiez que le retour arrière vers le site 1 principal est terminé à 100 % en procédant comme suit sur le site 1 :
  1. Vérifiez que l'instance de NSX Manager a le rôle principal.
  2. Vérifiez si la VM de contrôle (VM du dispositif Edge) est déployée sur l'UDLR.
  3. Vérifiez que l'état de tous les nœuds de cluster de contrôleurs est Connecté.
  4. Effectuez un contrôle de santé de communication sur chaque cluster d'hôtes préparé pour NSX.
    1. Accédez à Installation et mise à niveau (Installation and Upgrade) > Préparation de l'hôte (Host Preparation).
    2. Sélectionnez l'instance de NSX Manager sur le site 1.
    3. Sélectionnez un cluster à la fois, puis vérifiez si l'état de santé du canal de communication du cluster est actif.
    4. Pour chaque hôte du cluster, vérifiez que l'état de santé du canal de communication de l'hôte est actif.
    5. Vérifiez que l'état de préparation de l'hôte est Vert.
  5. Connectez-vous à la console CLI de la VM de contrôle de l'UDLR (VM du dispositif Edge) et procédez comme suit :
    1. Vérifiez que tous les voisins BGP sont établis et que l'état est actif en exécutant la commande show ip bgp neighbors .
    2. Vérifiez que tous les itinéraires BGP sont en cours d'apprentissage par tous les voisins BGP en exécutant la commande show ip route bgp.

Après un retour arrière complet vers le site 1, toutes les charges de travail s'exécutent sur le site 1 principal et le trafic est acheminé via l'UDLR et les instances de NSX Edge sur le site 1.