Dans ce scénario, une catastrophe naturelle touche le site 1 principal à Palo Alto et le site 1 s'arrête complètement. L'administrateur NSX effectue un basculement manuel vers le site 2 secondaire à Austin.

Comme le site principal s'est arrêté en raison de circonstances imprévues, l'administrateur ne peut effectuer aucune préparation de basculement avant la panne réelle.

L'administrateur NSX souhaite atteindre les objectifs clé suivants :
  • Réaliser un basculement de site complet sur le site 2 avec une interruption de service minimale.
  • Conserver les adresses IP d'application du site 1 sur le site 2 après le basculement.
  • Récupérer automatiquement tous les paramètres de l'interface Edge et les paramètres de configuration de protocole BGP sur le site 2.
Note :
  • L'administrateur peut effectuer les tâches de basculement manuellement en utilisant vSphere Web Client ou en exécutant les REST API NSX. De plus, l'administrateur peut automatiser certaines tâches de basculement en exécutant un fichier de script qui contient les API à exécuter pendant le basculement. Ce scénario explique les étapes de basculement 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.
Important : Si le site 1 principal est mis sous tension alors que le basculement vers le site 2 secondaire est en cours, commencez par vous assurer que le processus de basculement est effectué à l'aide de la procédure dans ce scénario. Seulement après la réalisation d'un basculement propre vers le site 2 secondaire, effectuez la restauration ou le retour arrière de toutes les charges de travail vers le site 1 principal d'origine. Pour obtenir des instructions détaillées sur le processus de retour arrière, reportez-vous à la section Scénario 3 : retour arrière complet sur le site principal.

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, les conditions suivantes sont réunies avant le basculement :
    • Des interfaces de liaison descendante similaires sont configurées manuellement sur les passerelles ESG comme elles sont configurées sur le site 1.
    • Une configuration BGP est effectuée manuellement sur les passerelles ESG qui est similaire à la configuration sur le site 1.
    • Des passerelles ESG sont hors tension lorsque le site 1 principal est actif ou en cours d'exécution.

Procédure

  1. Vérifiez que l'instance principale de NSX Manager sur le site 1 est arrêtée.
    1. Sur la page Installation et mise à niveau, accédez à Gestion (Management) > NSX Managers.
      • Si vous actualisez la page NSX Managers dans la session de navigateur actuelle, le rôle de l'instance principale de NSX Manager devient Inconnu.
      • Si vous vous déconnectez de vSphere Web Client et vous reconnectez ou si vous démarrez une nouvelle session de navigateur vSphere Web Client, l'instance principale de NSX Manager ne s'affiche plus sur la page NSX Managers.
    2. Accédez à Mise en réseau et sécurité (Networking & Security) > Tableau de bord (Dashboard) > Présentation (Overview).
      • Si vous actualisez la page Tableau de bord dans la session de navigateur actuelle, le message d'erreur suivant s'affiche : Impossible d'établir la connexion avec NSX Manager. Contactez l'administrateur.. Cette erreur signifie que l'instance principale de NSX Manager n'est plus accessible.
      • Si vous vous déconnectez de vSphere Web Client et vous reconnectez ou si vous démarrez une nouvelle session de navigateur vSphere Web Client, l'instance principale de NSX Manager n'est plus disponible dans le menu déroulant NSX Manager.
  2. Donnez à l'instance secondaire de NSX Manager un rôle principal.
    1. Sur la page Installation et mise à niveau, accédez à Gestion (Management) > NSX Managers.
    2. Sélectionnez l'instance secondaire de NSX Manager.
    3. Cliquez sur Actions > Se déconnecter de l'instance principale de NSX Manager (Disconnect from Primary NSX Manager). Lorsque vous êtes invité à passer à l'opération de déconnexion, cliquez sur Oui (Yes).
      L'instance secondaire de NSX Manager est déconnectée de l'instance principale de NSX Manager et reçoit le rôle Transit.
    4. Cliquez sur Actions > Attribuer un rôle principal (Assign Primary Role).
      L'instance secondaire de NSX Manager sur le site 2 obtient un rôle principal.
    Attention : Étant donné que la sortie locale est désactivée sur l'UDLR, la VM de contrôle de l'UDLR (VM du dispositif Edge) est déployée uniquement sur le site principal d'origine (site 1). Avant l'échec du site 1, la VM de contrôle de l'UDLR n'est pas disponible sur le site secondaire (site 2), qui a maintenant un rôle principal. Par conséquent, redéployez la VM de contrôle de l'UDLR sur le site principal promu (site 2) avant de redéployer le cluster NSX Controller.

    Si les nœuds de contrôleur sont déployés avant la VM de contrôle de l'UDLR, les tables de transfert sur l'UDLR sont vidées. Cela entraîne une interruption de service juste après le déploiement du premier nœud de contrôleur sur le site 2. Cette situation peut entraîner des interruptions de communication. Pour éviter cette situation, déployez la VM de contrôle de l'UDLR avant les nœuds NSX Controller.

  3. Mettez sous tension les instances de NSX Edge qui sont hors tension et déployez la VM de contrôle de l'UDLR (VM du dispositif Edge) sur le site 2 secondaire (promu principal).
    Pour obtenir des instructions sur le déploiement de la VM de contrôle d'UDLR, consultez le Guide d'installation de cross-vCenter NSX.
    Lors du déploiement de la VM de contrôle d'UDLR, configurez les paramètres de ressources suivants :
    • Sélectionnez le centre de données site 2.
    • Sélectionnez le cluster/pool de ressources.
    • Sélectionnez la banque de données.
    Note : Après le déploiement de la VM de contrôle de l'UDLR, les paramètres de configuration suivants sont automatiquement récupérés sur le site 2 :
    • Configuration du routage du protocole BGP
    • Configuration du mot de passe BGP
    • Paramètres de la liaison montante et de l'interface interne
  4. Déployez les trois nœuds de cluster NSX Controller sur le site 2 (promu principal).
    Pour obtenir des instructions détaillées sur le déploiement des instances de NSX Controller, consultez le Guide d'installation de cross-vCenter NSX.
  5. Mettez à jour l'état du cluster NSX Controller.
    1. Sur la page Installation et mise à niveau, cliquez sur NSX Managers.
    2. Sélectionnez l'instance principale de NSX Manager promue.
    3. Cliquez sur Actions > Mettre à jour l'état du contrôleur (Update Controller State).
  6. Forcez le service de routage de synchronisation sur chaque cluster sur le site 2.
    1. Sur la page Installation et mise à niveau, cliquez sur Préparation de l'hôte (Host Preparation).
    2. Sélectionnez l'instance principale de NSX Manager promue.
    3. Sélectionnez un cluster à la fois, puis cliquez sur Actions > Forcer les services de synchronisation (Force Sync Services).
    4. Sélectionnez Routage (Routing) et cliquez sur OK.
  7. Migrez les VM de charge de travail du site 1 vers le site 2.
    Note : Les VM de charge de travail existent toujours sur le site 1. Par conséquent, vous devez migrer manuellement les VM de charge de travail vers le site 2.

Résultats

La récupération manuelle des composants de NSX et le basculement du site principal (site 1) vers le site secondaire (site 2) est terminée.

Que faire ensuite

Vérifiez que le basculement vers le site 2 est terminé à 100 % en procédant comme suit sur le site 2 (site principal promu) :
  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. 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 basculement complet vers le site 2, toutes les charges de travail s'exécutent sur le site secondaire (promu principal) et le trafic est acheminé via l'UDLR et les instances de NSX Edge sur le site 2.