Recuperação de desastres de cluster de 3 nós do Cisco SDWAN Manager

Introdução

Este documento descreve a natureza stateful do Cisco vManage e seu roteador designado (DR) principal/secundário, permitindo failover manual com replicação automática de dados.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento dos clusters de 3 nós do vManage.
Dois clusters de três nós do vManage separados devem ser configurados e estar operacionais para prosseguir com a recuperação de desastres. No cluster ativo, você deve ter validadores e controladores integrados. Caso você tenha o validador e os controladores no local do DR, eles também devem ser integrados no cluster ativo e não no cluster do DR vManage.

A Cisco recomenda que, antes de registrar a recuperação de desastres, estes requisitos devem ser atendidos:

• Certifique-se de que o nó primário e o secundário estejam acessíveis por HTTPS em uma VPN de transporte (VPN 0).
• Certifique-se de que os Cisco vSmart Controllers e Cisco vBond Orchestrators na configuração secundária estejam conectados à configuração principal.
• Verifique se o nó primário e o nó secundário do Cisco vManage estão executando a mesma versão do Cisco vManage.
• Interface de cluster fora de banda na VPN 0:
  • Para cada instância do vManage em um cluster, é necessária uma terceira interface (link de cluster) além das interfaces usadas para VPN 0 (transporte) e VPN 512 (gerenciamento).
  • Essa interface é usada para comunicação e sincronização entre os servidores vManage no cluster.
  • Essa interface deve ter pelo menos 1 Gbps e uma latência de 4 ms ou menos. Recomenda-se uma interface de 10 Gbps.
  • Ambos os nós do vManage devem ser capazes de alcançar um ao outro por meio dessa interface: seja um segmento da camada 2 ou através do roteamento da camada 3.
  • Em cada vManage, essa interface deve ser configurada na GUI como uma interface de cluster(Administração>Gerenciamento de cluster- indique o próprio endereço IP, usuário e senha da interface de cluster fora da banda).
  • Para permitir que os nós do Cisco vManage se comuniquem entre si em data centers, ative as portas TCP 8443 e 830 em seus firewalls de data center.
• Verifique se todos os serviços (servidor de aplicativos, configuração-db, servidor de mensagens, servidor de coordenação e estatística-db) estão habilitados em ambos os nós do Cisco vManage.
• Distribua todos os controladores, incluindo os Cisco vBond Orchestrators, em data centers primários e secundários. Verifique se esses controladores podem ser acessados pelos nós do Cisco vManage que estão distribuídos nesses data centers. Os controladores se conectam apenas ao nó principal do Cisco vManage.
• Certifique-se de que nenhuma outra operação esteja em andamento no nó ativo (principal) e no nó standby (secundário) do Cisco vManage. Por exemplo, certifique-se de que nenhum servidor esteja no processo de atualização ou anexação de modelos aos dispositivos.
• Desative o servidor proxy HTTP/HTTPS do Cisco vManage se ele estiver ativado. Consulte Servidor Proxy HTTP/HTTPS para Comunicação do Cisco vManage com Servidores Externos. Se você não desativar o servidor proxy, o Cisco vManage tentará estabelecer comunicação de recuperação de desastres por meio do endereço IP do proxy, mesmo que os endereços IP do cluster fora de banda do Cisco vManage sejam diretamente acessíveis. Você pode reativar o servidor proxy HTTP/HTTPS do Cisco vManage após a conclusão do registro de recuperação de desastres.
• Antes de iniciar o processo de registro de recuperação de desastres, navegue até a janela Tools > Rediscover Network no nó principal do Cisco vManage e redescubra os Cisco vBond Orchestrators.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

• Gerenciador: 20.12.5
• Validador: 20.12.5
• Controlador: 20.12.5
• Borda: 17.12.5

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A recuperação de desastres fornece um processo de failover acionado pelo administrador. Quando a recuperação de desastres é registrada, os dados são replicados automaticamente entre os clusters Cisco vManage primário e secundário. Você executa manualmente um failover para o cluster secundário, se necessário.

Configurar

Diagrama de Rede

Esta figura ilustra a arquitetura avançada da solução de recuperação de desastres com um cluster de três nós.

Configurações

Para obter mais informações sobre o vManage Disaster Recovery, consulte este link.

Os dois clusters de 3 nós separados já foram criados, supondo que cada gerenciador de SD-WAN tenha uma configuração mínima e que a parte de certificação esteja concluída.

• Navegue para Administração > Gerenciamento de cluster em ambos os clusters e verifique se todos os nós estão no estado pronto.

DC vManage

DR-vManage:

• Navegue até Administração>Recuperação de desastres. Clique em Manage Disaster Recovery.

• Na janela pop-up, preencha os detalhes do vManage principal e secundário.

  Os endereços IP a serem indicados são os endereços IP das interfaces de cluster fora da banda.

  As credenciais devem ser as de um usuário netadmin e não devem ser alteradas após a configuração do DR, a menos que ele seja excluído.

  
  

  Depois de preenchido, clique em Avançar.

  • Preencha os detalhes dos controladores vBond.
    

  Os controladores vBond devem estar acessíveis no endereço IP especificado via Netconf.

  

  Depois de preenchido, clique em Avançar.
  
  

  • No Modo de recuperação, escolha Manual. O modo de Automação foi preterido. Clique em Next.

Defina o valor e clique em Salvar.

• O registro do DR começa agora. Clique no botão atualizar para atualizar manualmente o estado e os logs de andamento. Esse processo pode levar de 20 a 30 minutos.
  

Verificação

• Navegue até Administração>Recuperação de desastres para ver o status da recuperação de desastres e quando os dados foram replicados pela última vez.
  
  
  

  Note: Neste cenário, a replicação levou apenas 49 segundos, pois o ambiente de laboratório tem um pequeno banco de dados. No entanto, a replicação pode levar várias horas, dependendo do tamanho do banco de dados. Além disso, pode exigir alguns ciclos para obter uma replicação bem-sucedida.

Verifique o log de recuperação de desastres em ambos os 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

Como verificar o nó líder de replicação?

• Use a próxima API para descobrir o nó líder de replicação em ambos os clusters:

https://<vmanage-ip>/data service/entity ownership/tree.

Para cluster DC:
O nó de replicação é cb87a08e-079e-4394-81c3-e63c36ac22c0, que é o nó 1, verifique-o em show control local-properties.

Da mesma forma para o DR-vManage, o nó de replicação é d78832e5-e6d3-4b6b-bf61-f923cf3c7282.

Atualização da senha do Validator (vBond) após o registro da recuperação de desastres

Se você alterar a senha do vBond depois que o registro de recuperação de desastre estiver concluído, um switchover falha porque a senha do vBond não é atualizada no cluster secundário, que ainda mantém a senha antiga do 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:?]

Atualizar Senha do Validador (vbond)

Certifique-se de atualizar a nova senha do vBond na página Recuperação de desastres e em Gerenciar senha:

Administração > Recuperação de desastres > Gerenciar senha > Atualizar senha do vBond.

Verifique se a replicação foi bem-sucedida após a atualização da senha. Tente um failover somente depois de confirmar a replicação bem-sucedida.

advertência: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwn19224.

Adicionando novo validador (vBond) à sobreposição após o registro de recuperação de desastres

Não há suporte para a adição de um novo validador à sobreposição de SD-WAN após o registro de recuperação de desastre, pois a configuração de recuperação de desastre não está ciente dessas novas informações do validador, pois elas não foram atualizadas durante o registro.

Embora você possa adicionar o validador, um switchover falha.

Se precisar adicionar um novo validador, siga estas etapas:

1. Exclua a configuração de recuperação de desastre.

2. Adicione o novo validador à sobreposição de SD-WAN.

3. Reconfigure a recuperação de desastres.

Atualizar sobreposições de recuperação de desastres

• Use o método CLI para atualizar os gerenciadores ativo e standbyCisco SD-WAN.

• Certifique-se de que o status da replicação na página Administração > Recuperação de desastres seja estável e não esteja em um estado transitório, como Importação pendente,Exportação pendente, ouDownload pendente. Ele deve estar no estado Success antes de pausar a recuperação de desastres.

• Pause a recuperação de desastres usandoPausar recuperação de desastres em Administração > página Recuperação de desastres.

Processo de atualização

Nesse caso, você está atualizando o cluster vManage de 20.12.5 para 20.15.2. Use o método CLI para atualizar o cluster.

Antes de atualizar, verifique a versão e o status da replicação.

Pausar recuperação de desastres:

Após a atualização, certifique-se de que todos os serviços estejam em execução e que você possa fazer login em todos os nós do vManage (DC e DR) usando a GUI.

Retomar a recuperação de desastres; a replicação é iniciada, e o status da replicação deve ser exibido como sucesso.

Informações Relacionadas

• 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
• Suporte técnico e downloads da Cisco