Cisco SDWAN Manager 3 Node Cluster Disaster Recovery

Introduction

Ce document décrit la nature avec état de Cisco vManage et de son routeur désigné (DR) principal/secondaire, permettant un basculement manuel avec réplication automatique des données.

Conditions préalables

Exigences

Cisco recommande que vous ayez connaissance des clusters vManage 3 noeuds.
Deux clusters à 3 noeuds vManage distincts doivent être configurés et opérationnels pour poursuivre la reprise après sinistre. Sur le cluster actif, vous devez avoir des validateurs et des contrôleurs intégrés. Si vous avez des validateurs et des contrôleurs sur le site DR, ils doivent également être intégrés sur le cluster actif et non sur le cluster vManage DR.

Cisco recommande de respecter les conditions suivantes avant d'enregistrer une reprise après sinistre :

• Assurez-vous que le noeud principal et le noeud secondaire sont accessibles par HTTPS sur un VPN de transport (VPN 0).
• Assurez-vous que les contrôleurs Cisco vSmart et les orchestrateurs Cisco vBond de la configuration secondaire sont connectés à la configuration principale.
• Assurez-vous que le noeud principal et le noeud secondaire Cisco vManage exécutent la même version de Cisco vManage.
• Interface de cluster hors bande dans VPN 0 :
  • Pour chaque instance vManage d'un cluster, une troisième interface (liaison de cluster) est requise en plus des interfaces utilisées pour VPN 0 (transport) et VPN 512 (gestion).
  • Cette interface est utilisée pour la communication et la synchronisation entre les serveurs vManage du cluster.
  • Cette interface doit être d'au moins 1 Gbit/s et avoir une latence de 4 ms ou moins. Une interface 10 Gbit/s est recommandée.
  • Les deux noeuds vManage doivent être en mesure de se joindre via cette interface : qu’il s’agisse d’un segment de couche 2 ou du routage de couche 3.
  • Dans chaque vManage, cette interface doit être configurée dans l'interface utilisateur graphique comme interface de cluster(Administration>Gestion de cluster- indiquez votre propre adresse IP, votre propre utilisateur et votre propre mot de passe d'interface de cluster hors bande).
  • Afin de permettre aux noeuds Cisco vManage de communiquer entre eux à travers les data centers, activez les ports TCP 8443 et 830 sur les pare-feu de votre data center.
• Assurez-vous que tous les services (application-server, configuration-db, messaging server, coordination server et statistics-db) sont activés sur les deux noeuds Cisco vManage.
• Distribuez tous les contrôleurs, y compris les orchestrateurs Cisco vBond, dans les data centers principal et secondaire. Assurez-vous que ces contrôleurs sont accessibles par les noeuds Cisco vManage distribués dans ces data centers. Les contrôleurs se connectent uniquement au noeud Cisco vManage principal.
• Assurez-vous qu'aucune autre opération n'est en cours dans le noeud Cisco vManage actif (principal) et en veille (secondaire). Par exemple, assurez-vous qu'aucun serveur n'est en cours de mise à niveau ou d'association de modèles à des périphériques.
• Désactivez le serveur proxy HTTP/HTTPS Cisco vManage s'il est activé. Voir Serveur proxy HTTP/HTTPS pour Cisco vManage Communication with External Servers. Si vous ne désactivez pas le serveur proxy, Cisco vManage tente d'établir une communication de reprise après sinistre via l'adresse IP proxy, même si les adresses IP de cluster hors bande Cisco vManage sont directement accessibles. Vous pouvez réactiver le serveur proxy HTTP/HTTPS Cisco vManage une fois l'enregistrement de la reprise après sinistre terminé.
• Avant de commencer le processus d'enregistrement de reprise après sinistre, accédez à la fenêtre Outils > Redécouvrir le réseau sur le noeud principal Cisco vManage et retrouvez les orchestrateurs Cisco vBond.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

• Responsable : 20.12.5
• Validateur : 20.12.5
• Contrôleur : 20.12.5
• cEdge : 17.12.5

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

La reprise après sinistre fournit un processus de basculement déclenché par l'administrateur. Lorsque la reprise après sinistre est enregistrée, les données sont répliquées automatiquement entre les clusters Cisco vManage principal et secondaire. Vous effectuez manuellement un basculement vers le cluster secondaire si nécessaire.

Configurer

Diagramme du réseau

Cette figure illustre l'architecture de haut niveau de la solution de reprise après sinistre avec un cluster à trois noeuds.

Configurations

Pour plus d'informations sur vManage Disaster Recovery, consultez ce lien.

Les deux clusters à 3 noeuds distincts sont déjà créés, à condition que chaque gestionnaire SD-WAN dispose d'une configuration minimale et que la partie certification soit terminée.

• Accédez à Administration > Cluster Management sur les deux clusters et vérifiez que tous les noeuds sont à l'état Prêt.

DC vManage :

DR-vManage :

• Accédez à Administration>Reprise après sinistre. Cliquez sur Gérer la reprise après sinistre.

• Dans la fenêtre contextuelle, renseignez les détails de vManage principal et secondaire.

  Les adresses IP à indiquer sont les adresses IP des interfaces de cluster hors bande.

  Les informations d'identification doivent être celles d'un utilisateur netadmin et ne doivent pas être modifiées une fois que le DR est configuré, à moins qu'il ne soit supprimé.

  
  

  Une fois rempli, cliquez sur Next.

  • Renseignez les détails des contrôleurs vBond.
    

  Les contrôleurs vBond doivent être accessibles dans l'adresse IP spécifiée via Netconf.

  

  Une fois rempli, cliquez sur Next.
  
  

  • Dans le champ Recovery Mode, sélectionnez Manual. Le mode Automation est déconseillé. Cliquez sur Next (Suivant).

Définissez la valeur et cliquez sur Save.

• L'enregistrement du DR commence maintenant. Cliquez sur le bouton Actualiser pour actualiser manuellement l'état et les journaux de progression. Ce processus peut prendre de 20 à 30 minutes.
  

Vérification

• Accédez à Administration>Reprise après sinistre afin de voir l'état de reprise après sinistre et quand les données ont été répliquées la dernière fois.
  
  
  

  Remarque : Dans ce scénario, la réplication n'a pris que 49 secondes, car l'environnement des travaux pratiques comporte une petite base de données. Cependant, la réplication peut prendre plusieurs heures en fonction de la taille de la base de données. En outre, quelques cycles peuvent être nécessaires pour réussir la réplication.

Vérifiez le journal de reprise après sinistre dans les deux clusters.

DC-vmanage (9a15f979-d613-4d75-97bf-f7d4124bc687 is export ID)
vmanage1:/var/log/nms$ cat vmanage-disaster_recovery.log | grep 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:17:08,297 UTC INFO [] [] [DataReplicationManager] (pool-232-thread-1) || Export ID Generated: 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:17:58,431 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (pool-232-thread-1) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="EXPORT_DATA", message="Primary Successfully Exported", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="ec133314-7205-4afc-bee3-a4b080fc42f0", update_time=1751606278431, entry_time=1751606278431, values=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606278431} 
04-Jul-2025 05:17:58,722 UTC INFO [] [] [DataReplicationManager] (pool-232-thread-1) || Sending the import request to remote server 89.89.89.4 for exportID: 9a15f979-d613-4d75-97bf-f7d4124bc687.
04-Jul-2025 05:17:59,081 UTC INFO [a17a50ae-e6d3-401c-9d34-7c9423a5dd5a] [vmanage1] [DisasterRecoveryRestfulResource] (default task-32) |default| Received request from 89.89.89.1, for token: 9a15f979-d613-4d75-97bf-f7d4124bc687, and file: default_1751001428297.tar.gz 
04-Jul-2025 05:21:06,515 UTC INFO [a456da19-9868-42e1-b3e7-9cb7ef3bdb81] [vmanage1] [DisasterRecoveryRestfulResource] (default task-31) |default| Replication status for exportID: 9a15f979-d613-4d75-97bf-f7d4124bc687, is Success
vmanage1:/var/log/nms$

DR-Vmanage
DR-vmanage1:/var/log/nms$ cat vmanage-disaster_recovery.log | grep 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:15:23,296 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Payload received for data replication: {replicationDir="/opt/data/disaster_recovery/", filename="default_1751001428297.tar.gz", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687", deviceIP="89.89.89.1", exportTime="1751606278229", exportDuration="49 secs", exportSize="22.363 MB", SwitchOverHistoryNode={lastSwitch=0, reasonForSwitch=null, updatedPrimary="89.89.89.1"}, startTime="1751606228297", sha256sum="06363770a967beec4667f29e5b033de4a538523f34e36d9952ffc893fb0557db"}
04-Jul-2025 05:15:23,298 UTC INFO [] [] [DataReplicationManager] (Thread-366) || destinationURL dataservice/disasterrecovery/download/9a15f979-d613-4d75-97bf-f7d4124bc687/default_1751001428297.tar.gz Saved to File /opt/data/disaster_recovery/default_1751001428297.tar.gz
04-Jul-2025 05:15:24,040 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (Thread-366) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="DOWNLOAD_DATA", message="Replication payload successfully downloaded by secondary", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="94ab4c3a-26d9-4d99-b631-d380313d7f08", update_time=1751606124040, entry_time=1751606124040, values=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606124040} 
04-Jul-2025 05:15:24,170 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Downloaded replication file size 23449259 for token 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:15:24,171 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending rpc message to copyReplicationFile for token 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:15:24,216 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending message to destinations [Endpoint{ip='89.89.89.5', uuid='c3e303a2-53d0-4525-901b-d96e9ce92875'}, Endpoint{ip='89.89.89.6', uuid='bf45f345-ff2e-48ec-b8fd-0bb92427cc28'}] for token 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:15:24,245 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Waiting for copyReplicationFile to complete for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:18:19,545 UTC INFO [] [] [DataReplicationWorker] (Thread-366) || Successfully Deleted Imported Data Directory /opt/data/disaster_recovery/9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:18:19,643 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (Thread-366) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="IMPORT_DATA", message="Secondary Successfully Imported", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="1fc80500-f621-4d45-9395-4ed949ddda68", update_time=1751606299643, entry_time=1751606299643, values=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606299643} 
04-Jul-2025 05:18:19,707 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Successfully imported data from exportID 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:18:19,716 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending rpc message to deleteReplicationFile for token 9a15f979-d613-4d75-97bf-f7d4124bc687
04-Jul-2025 05:18:19,849 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending message to destinations [Endpoint{ip='89.89.89.5', uuid='c3e303a2-53d0-4525-901b-d96e9ce92875'}, Endpoint{ip='89.89.89.6', uuid='bf45f345-ff2e-48ec-b8fd-0bb92427cc28'}] for token 9a15f979-d613-4d75-97bf-f7d4124bc687

Comment vérifier le noeud principal de réplication ?

• Utilisez l'API suivante afin de trouver le noeud principal de réplication sur les deux clusters :

https://<vmanage-ip>/service de données/propriété d'entité/arborescence.

Pour le cluster CC :
Le noeud de réplication est cb87a08e-079e-4394-81c3-e63c36ac22c0 qui est node1, vérifiez-le à partir de show control local-properties.

De même pour DR-vManage, le noeud de réplication est d78832e5-e6d3-4b6b-bf61-f923cf3c7282.

Mise à jour du mot de passe Validator (vBond) après enregistrement de reprise après sinistre

Si vous modifiez le mot de passe vBond après l'enregistrement de la reprise après sinistre, une commutation échoue car le mot de passe vBond n'est pas mis à jour sur le cluster secondaire, qui conserve toujours l'ancien mot de passe vBond.

[04-July-2025 6:47:35 UTC] Unshut control tunnel on the standby vManage. 
[04-July-2025 6:47:36 UTC] Sleeping for 10 seconds to ensure control tunnel is fully up and functional on the vmanage. 
[04-July-2025 6:47:55 UTC] Failed to activate the cluster. Vbond is unreachable 

================ 

04-July-2025 06:47:55,206 UTC ERROR [89b008fa-2c1b-4f78-b093-ed1fa1f06b71] [vManage20-14-DR] [DisasterRecoveryManager] (dr_activate) |default| IP credentials are not reachable through given ip and authentication creds com.viptela.vmanage.server.device.common.NetConfClientException: java.io.IOException: Unable to authenticate for deviceIP 10.66.91.163. With session Nio2Session[local=/10.66.91.173:56704, remote=/10.66.91.163:830]! 
at com.viptela.vmanage.server.device.common.NetConfClient.connect(NetConfClient.java:255) ~[vmanage-server-1.0.0-SNAPSHOT.jar:?] 
at com.viptela.vmanage.server.device.common.NetConfClient.(NetConfClient.java:114) ~[vmanage-server-1.0.0-SNAPSHOT.jar:?]

Mettre à jour le mot de passe du validateur (vbond)

Assurez-vous de mettre à jour le nouveau mot de passe vBond à la fois sur la page Reprise après sinistre et sous Gérer le mot de passe :

Administration > Reprise après sinistre > Gérer le mot de passe > Mettre à jour le mot de passe vBond.

Assurez-vous que la réplication réussit après la mise à jour du mot de passe. Tentative de basculement uniquement après confirmation de la réplication réussie.

attention : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwn19224.

Ajout d'un nouveau validateur (vBond) à la superposition après l'enregistrement de reprise après sinistre

L'ajout d'un nouveau validateur à la superposition SD-WAN après l'enregistrement de la reprise après sinistre n'est pas pris en charge, car la configuration de la reprise après sinistre ne connaît pas ces nouvelles informations de validateur car elles n'ont pas été mises à jour pendant l'enregistrement.

Bien que vous puissiez ajouter le validateur, une commutation échoue.

Si vous devez ajouter un nouveau validateur, observez ces étapes :

1. Supprimez la configuration de reprise après sinistre.

2. Ajoutez le nouveau validateur à la superposition SD-WAN.

3. Reconfigurez la reprise après sinistre.

Mise à niveau des superpositions de reprise après sinistre

• Utilisez la méthode CLI pour mettre à niveau les gestionnaires SD-WAN Cisco actifs et en veille.

• Assurez-vous que l'état de réplication sur la page Administration > Récupération après sinistre est stable et qu'il n'est pas dans un état transitoire comme Importation en attente, Exportation en attente, ou Téléchargement en attente. Il doit être à l'état Success (Réussite) avant de suspendre la reprise après sinistre.

• Suspendez la reprise après sinistre en utilisantSuspendre la reprise après sinistre sous Administration > page Reprise après sinistre.

Processus de mise à niveau

Dans ce cas, vous mettez à niveau le cluster vManage de 20.12.5 vers 20.15.2. Utilisez la méthode CLI afin de mettre à niveau le cluster.

Avant de procéder à la mise à niveau, vérifiez la version et l'état de réplication.

Suspendre la reprise après sinistre :

Après la mise à niveau, assurez-vous que tous les services sont en cours d'exécution et que vous pouvez vous connecter à tous les noeuds vManage (DC et DR) à l'aide de l'interface utilisateur graphique.

Reprise après sinistre ; la réplication démarre et l'état de la réplication doit apparaître comme réussi.

Informations connexes

• https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/ha-scaling/ios-xe-17/high-availability-book-xe/m-disaster-recovery.html
• Assistance technique de Cisco et téléchargements