Cisco SDWAN Manager 3 Node - Ripristino di emergenza del cluster

Introduzione

Questo documento descrive la natura di conservazione dello stato di Cisco vManage e del relativo router designato primario/secondario (DR), che consente il failover manuale con la replica automatica dei dati.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei cluster vManage a 3 nodi.
Per procedere con il ripristino di emergenza, è necessario configurare e utilizzare due cluster vManage a 3 nodi separati. Nel cluster attivo è necessario che le convalide e i controller siano integrati. Nel caso in cui si disponga di validator e controller sul sito DR, è necessario che questi siano installati anche sul cluster attivo e non sul cluster DR vManage.

Cisco consiglia di soddisfare i seguenti requisiti prima di registrare il disaster recovery:

• Verificare che il nodo primario e il nodo secondario siano raggiungibili da HTTPS su una VPN di trasporto (VPN 0).
• Verificare che i Cisco vSmart Controller e i Cisco vBond Orchestrator sull'installazione secondaria siano collegati all'installazione primaria.
• Verificare che il nodo primario e il nodo secondario Cisco vManage eseguano la stessa versione di Cisco vManage.
• Interfaccia cluster fuori banda nella VPN 0:
  • Per ogni istanza vManage all'interno di un cluster, è necessaria una terza interfaccia (collegamento cluster) oltre alle interfacce utilizzate per VPN 0 (trasporto) e VPN 512 (gestione).
  • Questa interfaccia viene utilizzata per la comunicazione e la sincronizzazione tra i server vManage all'interno del cluster.
  • Questa interfaccia deve essere di almeno 1 Gbps e avere una latenza di 4 ms o inferiore. Si consiglia un'interfaccia di 10 Gbps.
  • Entrambi i nodi vManage devono essere in grado di raggiungere l'uno l'altro tramite questa interfaccia: che si tratti di un segmento di livello 2 o di un instradamento di livello 3.
  • In ogni vManage, questa interfaccia deve essere configurata nella GUI come interfaccia cluster(Amministrazione>Gestione cluster - indicare l'indirizzo IP, l'utente e la password dell'interfaccia cluster fuori banda).
  • Per consentire ai nodi Cisco vManage di comunicare tra loro nei data center, abilitare le porte TCP 8443 e 830 sui firewall del data center.
• Verificare che tutti i servizi (application-server, configuration-db, messaging server, coordination server e statistics-db) siano abilitati su entrambi i nodi Cisco vManage.
• Distribuire tutti i controller, inclusi i Cisco vBond Orchestrator, nei centri dati principali e secondari. Verificare che questi controller siano raggiungibili dai nodi Cisco vManage distribuiti nei centri dati. I controller si connettono solo al nodo Cisco vManage primario.
• Verificare che non siano in corso altre operazioni nel nodo Cisco vManage attivo (primario) e in standby (secondario). Verificare, ad esempio, che nessun server stia aggiornando o collegando modelli ai dispositivi.
• Disabilitare il server proxy HTTP/HTTPS Cisco vManage, se abilitato. Vedere Server proxy HTTP/HTTPS per la comunicazione Cisco vManage con server esterni. Se non si disabilita il server proxy, Cisco vManage tenta di stabilire la comunicazione per il ripristino di emergenza tramite l'indirizzo IP proxy, anche se gli indirizzi IP dei cluster fuori banda di Cisco vManage sono raggiungibili direttamente. È possibile riattivare il server proxy Cisco vManage HTTP/HTTPS al termine della registrazione del ripristino di emergenza.
• Prima di avviare il processo di registrazione del ripristino di emergenza, passare alla finestra Strumenti > Riconosci rete sul nodo Cisco vManage principale e individuare nuovamente i Cisco vBond Orchestrator.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software:

• Responsabile: 20.12.5
• Convalida: 20.12.5
• Controller: 20.12.5
• Bordo: 17.12.5

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Il disaster recovery fornisce un processo di failover avviato dall'amministratore. Quando viene registrato il ripristino di emergenza, i dati vengono replicati automaticamente tra i cluster Cisco vManage primario e secondario. Se necessario, è possibile eseguire manualmente un failover sul cluster secondario.

Configurazione

Esempio di rete

La figura mostra l'architettura di alto livello della soluzione di disaster recovery con un cluster a tre nodi.

Configurazioni

Per ulteriori informazioni su vManage Disaster Recovery, fare riferimento a questo collegamento.

I due cluster a 3 nodi separati sono già stati creati, presupponendo che ciascun gestore SD-WAN disponga della configurazione minima e che la parte di certificazione sia stata completata.

• Passare a Amministrazione > Gestione cluster in entrambi i cluster e verificare che tutti i nodi siano in stato Pronto.

DC vManage:

DR-vManage:

• Passare a Amministrazione>Disaster Recovery. Fare clic su Gestione ripristino di emergenza.

• Nella finestra popup, immettere i dettagli per vManage principale e secondario.

  Gli indirizzi IP da indicare sono gli indirizzi IP delle interfacce cluster fuori banda.

  Le credenziali devono essere quelle di un utente netadmin e non devono essere modificate una volta configurato il DR, a meno che non venga eliminato.

  
  

  Una volta completate le impostazioni, fare clic su Avanti.

  • Specificare i dettagli dei controller vBond.
    

  I controller vBond devono essere raggiungibili nell'indirizzo IP specificato tramite Netconf.

  

  Una volta completate le impostazioni, fare clic su Avanti.
  
  

  • In Modalità di ripristino, scegliere Manuale. La modalità di automazione è deprecata. Fare clic su Next (Avanti).

Impostare il valore e fare clic su Salva.

• La registrazione del ripristino di emergenza inizia ora. Fare clic sul pulsante Aggiorna per aggiornare manualmente lo stato e i registri di stato. Questo processo può richiedere fino a 20-30 minuti.
  

Verifica

• Passare a Amministrazione>Disaster Recovery per verificare lo stato del ripristino di emergenza e la data dell'ultima replica dei dati.
  
  
  

  Nota: In questo scenario, la replica ha richiesto solo 49 secondi perché l'ambiente lab dispone di un database di dimensioni ridotte. Tuttavia, la replica può richiedere diverse ore a seconda delle dimensioni del database. Inoltre, può richiedere alcuni cicli per ottenere una replica corretta.

Verificare il registro di disaster recovery in entrambi i cluster.

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

Come verificare il nodo principale della replica?

• Utilizzare l'API successiva per individuare il nodo della linea guida della replica in entrambi i cluster:

https://<vmanage-ip>/servizio dati/proprietà entità/albero.

Per il cluster di controller di dominio:
Il nodo di replica è cb87a08e-079e-4394-81c3-e63c36ac22c0 che è node1, verificare da show control local-properties.

Analogamente, per DR-vManage, il nodo di replica è d78832e5-e6d3-4b6b-bf61-f923cf3c7282.

Aggiornamento della password di Convalida (vBond) dopo la registrazione del ripristino di emergenza

Se si modifica la password vBond dopo la registrazione del ripristino di emergenza, lo switchover non riesce perché la password vBond non viene aggiornata nel cluster secondario, che conserva comunque la vecchia password 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:?]

Aggiorna password di convalida (vbond)

Assicurarsi di aggiornare la nuova password vBond sia nella pagina Disaster Recovery che in Gestione password:

Amministrazione > Disaster Recovery > Gestisci password > Aggiorna password vBond.

Verificare che la replica sia stata eseguita correttamente dopo l'aggiornamento della password. Tentare un failover solo dopo aver confermato la corretta replica.

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

Aggiunta di un nuovo validator (vBond) da sovrapporre dopo la registrazione del ripristino di emergenza

L'aggiunta di un nuovo validator alla sovrapposizione SD-WAN dopo la registrazione del disaster recovery non è supportata, in quanto la configurazione del disaster recovery non è a conoscenza di queste nuove informazioni di validator poiché non sono state aggiornate durante la registrazione.

Sebbene sia possibile aggiungere la convalida, il passaggio non riesce.

Se è necessario aggiungere un nuovo validator, attenersi alla seguente procedura:

1. Eliminare l'impostazione di ripristino di emergenza.

2. Aggiungere il nuovo validator alla sovrimpressione SD-WAN.

3. Riconfigurare il ripristino di emergenza.

Aggiornamento delle sovrapposizioni del ripristino di emergenza

• Usare il metodo CLI per aggiornare i manager Cisco SD-WAN attivi e in standby.

• Verificare che lo stato di replica nella pagina Amministrazione > Ripristino di emergenza sia stabile e non in uno stato transitorio, ad esempio Importazione in sospeso, Esportazione in sospeso, o Download in sospeso. Deve essere in stato Riuscito prima di sospendere il ripristino di emergenza.

• Sospendere il ripristino di emergenza utilizzandoSospendi ripristino di emergenza nella pagina Amministrazione > Ripristino di emergenza.

Processo di aggiornamento

In questo caso si sta aggiornando il cluster vManage dalla versione 20.12.5 alla 20.15.2. Utilizzare il metodo CLI per aggiornare il cluster.

Prima di eseguire l'aggiornamento, verificare la versione e lo stato della replica.

Sospendi ripristino di emergenza:

Dopo l'aggiornamento, verificare che tutti i servizi siano in esecuzione e che sia possibile accedere a tutti i nodi vManage (controller di dominio e ripristino di emergenza) utilizzando la GUI.

Riprendere il ripristino di emergenza; la replica viene avviata e lo stato della replica deve risultare corretto.

Informazioni correlate

• 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
• Supporto tecnico Cisco e download