Recovery von eigenständigem vManage durch Disaster Recovery

Einleitung

In diesem Dokument werden die Schritte zur Wiederherstellung von vManage unter Verwendung eines Konfigurations-DB-Backups beschrieben.

Hintergrundinformationen

In diesem Dokument wird davon ausgegangen, dass regelmäßig ein Backup der Konfigurationsdatenbank durchgeführt wurde. Aus irgendeinem Grund ist der Standalone-vManager nicht wiederherstellbar und muss auf die Software zurückgesetzt oder neu installiert werden.

Dieses Dokument unterstützt Sie bei der Wiederherstellung aller Richtlinien, Vorlagen, Konfigurationen und Edge-Gerätezertifikate.

Sicherungskonfiguration - db

vManage_rcdn01# request nms configuration-db backup path 05_08_20_configdb
Starting backup of configuration-db
config-db backup logs are available in /var/log/nm/neo4j-backup.log file
Successfully saved database to /opt/data/backup/05_08_20_configdb.tar.gz

scp zu einem externen Server.

vManage_rcdn01# vshell
vManage_rcdn01:~$ scp /opt/data/backup/05_08_20_configdb.tar.gz user@10.2.3.1://home/ftpuser/ftp/amaugust/
amaugust@10.2.3.1's password:
05_08_20_configdb.tar.gz                                                     100%  484KB  76.6MB/s   00:00

vManage wiederherstellen

Simulieren Sie einen Notfall durch Zurücksetzen von vManage mithilfe des folgenden Befehls:

vManage_rcdn01# request software reset

Da Sie nun über einen neuen vManager verfügen, der dem gezeigten ähnelt, ist es ratsam, den Wiederherstellungsprozess in der richtigen Reihenfolge einzuhalten, bevor Sie die Sicherung wiederherstellen.

Schritt 1: Mindestkonfiguration auf vManage

system
 host-name             vManage_rcdn01
 system-ip             xx.xx.xx.xx
 site-id               100
 organization-name     ****.cisco
 vbond vbond.list
 !
!
vpn 0
 host vbond.list ip 10.2.3.4 10.2.3.5
 interface eth0
  ip address 10.1.3.8/24
  tunnel-interface 
  no shutdown
 !
 ip route 0.0.0.0/0 10.1.3.1
!
vpn 512
 interface eth1
  ip address 10.11.3.8/24
  no shutdown
 !
 ip route 0.0.0.0/0 10.1.3.1
!

Schritt 2: Kopieren der Sicherungskonfiguration und des Stammzertifikats

vManage_rcdn01:~$ scp am****@xx.xx.xx.xx://home/ftpuser/ftp/am****/05_08_20_configdb.tar.gz  .
am****@xx.xx.xx.xx's password:
05_08_20_configdb.tar.gz                                                    100%  484KB  76.6MB/s   00:00

Verify
vManage_rcdn01:~$ ls -lh
total 492K
-rw-r--r-- 1 admin admin  394 May  8 15:20 archive_id_rsa.pub
-rwxr-xr-x 1 admin admin 485K May  8 15:3905_08_20_configdb.tar.gz

Copy root certificate from other controller:
vManage_rcdn01:~$ scp admin@vbond://home/admin/root.crt .
viptela 18.4.4
admin@vbond's password:
root.crt                                                                   100% 1380     2.8MB/s   00:00

Schritt 3: Stammzertifikat installieren

vManage_rcdn01# request root-cert-chain install /home/admin/root.crt
Uploading root-ca-cert-chain via VPN 0
Copying ... /home/admin/root.crt via VPN 0
Updating the root certificate chain..
Successfully installed the root certificate chain

Schritt 4: Grundlegende Informationen aktualisieren

Navigieren Sie zu  Administration > Settings und konfigurieren Sie die grundlegenden Informationen für vBond IP, Organisationsname und Zertifikat.

Schritt 5: vManage-Zertifikat installieren

Verwenden Sie root.crt die in Schritt 2 installiert wird.

Schritt 6: Datenbank wiederherstellen

vManage_rcdn01# request nms configuration-db restore path /home/admin/05_08_20_configdb.tar.gz
Configuration database is running in a standalone mode
0 [main] INFO com.viptela.vmanage.server.deployment.cluster.ClusterConfigurationFileHandler  - Trying to update existing working copy of server_configs.json file
4 [main] INFO com.viptela.vmanage.server.deployment.cluster.ClusterConfigurationFileHandler  - Working copy of server_configs.json NOT updated due to unmodified configs
Successfully saved cluster configuration for localhost
Starting DB backup from: localhost
Creating directory: local
cmd to backup db: sh /usr/bin/vconfd_script_nms_neo4jwrapper.sh backup localhost /opt/data/backup/local 8g
Finished DB backup from: localhost
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Restoring from DB backup: /opt/data/backup/staging/graph.db-backup
cmd to restore db: sh /usr/bin/vconfd_script_nms_neo4jwrapper.sh  restore /opt/data/backup/staging/graph.db-backup
Successfully restored DB backup: /opt/data/backup/staging/graph.db-backup
Starting NMS configuration database on localhost
Waiting for 10s before starting other instances...
Polling neo4j at: localhost
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Starting NMS application-server on localhost
Waiting for 120s for the instance to start...
Removed old database directory: /opt/data/backup/local/graph.db-backup
Successfully restored database

Dieser Schritt nimmt mehr Zeit in Anspruch und hängt von der Sicherung ab.

Sie können den Prozess überprüfen durch  tailing  die Protokolle auf vShell.

vManage_rcdn01:~$ tail -fq /var/log/nms/vmanage-server.log /var/log/nms/neo4j-out.log

Schritt 7. Services überprüfen

vManage_rcdn01# request nms all status

Schritt 8: Controller erneut authentifizieren

Derzeit können Sie beobachten, dass alle Richtlinien, Vorlagen und Konfigurationen in vManage geladen wurden, aber alle Controller ausgefallen sind.

Sie müssen alle Controller erneut authentifizieren.

Navigieren Sie zu  Configuration > Devices. Bearbeiten Sie jeden Controller, und geben Sie den Benutzernamen und das Kennwort für die Management-IP-Adresse ein (die Management-IP-Adresse finden Sie in der lokalen Konfiguration).

Schritt 9. Senden von Updates an Controller

Nun sehen Sie, dass alle Geräte von vManage verwaltet werden können.