Sicherungs- und Wiederherstellungsverfahren für verschiedene Ultra-M-Komponenten
Inhalt
Einführung
In diesem Dokument werden die erforderlichen Schritte zum Sichern und Wiederherstellen eines virtuellen Systems (VM) in einer Ultra-M-Konfiguration beschrieben, die StarOS Virtual Network Functions (VNFs) hostet.
Hintergrundinformationen
Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. Die Ultra-M-Lösung besteht aus den folgenden VM-Typen:
- Auto-IT
- Automatische Bereitstellung
- Ultra Automation Services (UAS)
- Element Manager (EM)
- Elastic Services Controller (ESC)
- Kontrollfunktion (CF)
- Sitzungsfunktion (SF)
Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:
Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind.
Abkürzungen
| VNF | Virtuelle Netzwerkfunktion |
| CF | Kontrollfunktion |
| SF | Servicefunktion |
| WSA | Elastic Service Controller |
| MOP | Verfahrensweise |
| OSD | Objektspeicherdatenträger |
| HDD | Festplattenlaufwerk |
| SSD | Solid-State-Laufwerk |
| VIM | Virtueller Infrastrukturmanager |
| VM | Virtuelles System |
| EM | Element Manager |
| USA | Ultra-Automatisierungsservices |
| UUID | Universell eindeutige IDentifier |
Sicherungsverfahren
OSPD-Sicherung
1. Überprüfen Sie den Status des OpenStack-Stacks und der Knotenliste.
[stack@director ~]$ source stackrc
[stack@director ~]$ openstack stack list --nested
[stack@director ~]$ ironic node-list
[stack@director ~]$ nova list
2. Überprüfen Sie, ob alle Undercloud-Services über den OSP-D-Knoten den Status "geladen", "aktiv" und "aktiv" haben.
[stack@director ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"
UNIT LOAD ACTIVE SUB DESCRIPTION
neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent
neutron-openvswitch-agent.service loaded active running OpenStack Neutron Open vSwitch Agent
neutron-ovs-cleanup.service loaded active exited OpenStack Neutron Open vSwitch Cleanup Utility
neutron-server.service loaded active running OpenStack Neutron Server
openstack-aodh-evaluator.service loaded active running OpenStack Alarm evaluator service
openstack-aodh-listener.service loaded active running OpenStack Alarm listener service
openstack-aodh-notifier.service loaded active running OpenStack Alarm notifier service
openstack-ceilometer-central.service loaded active running OpenStack ceilometer central agent
openstack-ceilometer-collector.service loaded active running OpenStack ceilometer collection service
openstack-ceilometer-notification.service loaded active running OpenStack ceilometer notification agent
openstack-glance-api.service loaded active running OpenStack Image Service (code-named Glance) API server
openstack-glance-registry.service loaded active running OpenStack Image Service (code-named Glance) Registry server
openstack-heat-api-cfn.service loaded active running Openstack Heat CFN-compatible API Service
openstack-heat-api.service loaded active running OpenStack Heat API Service
openstack-heat-engine.service loaded active running Openstack Heat Engine Service
openstack-ironic-api.service loaded active running OpenStack Ironic API service
openstack-ironic-conductor.service loaded active running OpenStack Ironic Conductor service
openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector
openstack-ironic-inspector.service loaded active running Hardware introspection service for OpenStack Ironic
openstack-mistral-api.service loaded active running Mistral API Server
openstack-mistral-engine.service loaded active running Mistral Engine Server
openstack-mistral-executor.service loaded active running Mistral Executor Server
openstack-nova-api.service loaded active running OpenStack Nova API Server
openstack-nova-cert.service loaded active running OpenStack Nova Cert Server
openstack-nova-compute.service loaded active running OpenStack Nova Compute Server
openstack-nova-conductor.service loaded active running OpenStack Nova Conductor Server
openstack-nova-scheduler.service loaded active running OpenStack Nova Scheduler Server
openstack-swift-account-reaper.service loaded active running OpenStack Object Storage (swift) - Account Reaper
openstack-swift-account.service loaded active running OpenStack Object Storage (swift) - Account Server
openstack-swift-container-updater.service loaded active running OpenStack Object Storage (swift) - Container Updater
openstack-swift-container.service loaded active running OpenStack Object Storage (swift) - Container Server
openstack-swift-object-updater.service loaded active running OpenStack Object Storage (swift) - Object Updater
openstack-swift-object.service loaded active running OpenStack Object Storage (swift) - Object Server
openstack-swift-proxy.service loaded active running OpenStack Object Storage (swift) - Proxy Server
openstack-zaqar.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server
openstack-zaqar@1.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1
openvswitch.service loaded active exited Open vSwitch
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
3. Vergewissern Sie sich, dass genügend Speicherplatz verfügbar ist, bevor Sie den Sicherungsvorgang durchführen. Dieser Tarball soll mindestens 3,5 GB umfassen.
[stack@director ~]$df -h
4. Führen Sie diese Befehle als Root-Benutzer aus, um die Daten vom Undercloud-Knoten in eine Datei mit dem Namen undercloud-backup-[timestamp].tar.gz zu sichern und auf den Backup-Server zu übertragen.
[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names
AutoDeploy Backup
1. Bei AutoDeploy müssen diese Daten gesichert werden:
- AutoDeploy Confd Configuration Database (CDB)
- AutoDeploy-Konfiguration
- AutoDeploy-Protokolle
- Syslog-Konfiguration
2. Nach jeder Aktivierung/Deaktivierung ist eine Sicherung der CDB-Daten für die AutoDeploy Confd und eine laufende Konfiguration erforderlich, um sicherzustellen, dass die Daten auf einen Backup-Server übertragen werden.
3. AutoDeploy wird im Standalone-Modus ausgeführt. Wenn diese Daten verloren gehen, können Sie die Bereitstellung nicht ordnungsgemäß deaktivieren. Daher ist die Sicherung von Konfigurations- und CDB-Daten obligatorisch.
ubuntu@auto-deploy-iso-2007-uas-0:~$ sudo -i
root@auto-deploy-iso-2007-uas-0:~# service uas-confd stop
uas-confd stop/waiting
root@auto-deploy:/home/ubuntu# service autodeploy status
autodeploy start/running, process 1313
root@auto-deploy:/home/ubuntu# service autodeploy stop
autodeploy stop/waiting
root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar cvf autodeploy_cdb_backup.tar cdb/
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb
4. Kopieren Sie autodeploy_cdb_backup.tar auf den Sicherungsserver.
5. Sichern Sie die aktuelle Konfiguration in der automatischen Bereitstellung, und übertragen Sie sie auf einen Backup-Server.
root@auto-deploy:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy
auto-deploy#show running-config | save backup-config-$date.cfg à Replace the $date to appropriate date and POD reference
auto-deploy#
6. Starten Sie den AutoDeploy Confd-Dienst.
root@auto-deploy-iso-2007-uas-0:~# service uas-confd start
uas-confd start/running, process 13852
root@auto-deploy:/home/ubuntu# service autodeploy start
autodeploy start/running, process 8835
7. Navigieren Sie zum Skriptverzeichnis, und sammeln Sie die Protokolle von AutoDeploy VM.
cd /opt/cisco/usp/uas/scripts
8. Starten Sie das Skript collection-uas-logs.sh, um die Protokolle zu sammeln.
sudo ./collect-uas-logs.sh
9. Nehmen Sie die ISO-Image-Sicherung von der AutoDeploy-Funktion und übertragen Sie sie auf den Backup-Server.
root@POD1-5-1-7-2034-auto-deploy-uas-0:/home/ubuntu# /home/ubuntu/isos
root@POD1-5-1-7-2034-auto-deploy-uas-0:/home/ubuntu/isos# ll
total 4430888
drwxr-xr-x 2 root root 4096 Dec 20 01:17 ./
drwxr-xr-x 5 ubuntu ubuntu 4096 Dec 20 02:31 ../
-rwxr-xr-x 1 ubuntu ubuntu 4537214976 Oct 12 03:34 usp-5_1_7-2034.iso*
10. Erfassen Sie die Syslog-Konfiguration, und speichern Sie sie auf dem Backup-Server.
ubuntu@auto-deploy-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autodeploy.conf
00-autodeploy.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
AutoIT-VNF Backup
AutoIT-VNF ist eine Stateless VM, daher muss keine Datenbank (DB) gesichert werden. AutoIT-VNF übernimmt die Paketverwaltung zusammen mit dem Konfigurationsmanagement-Repository für Ultra-M. Daher ist es wichtig, dass diese Backups durchgeführt werden.
1. Sichern Sie Tag-0-StarOS-Konfigurationen, und übertragen Sie sie auf den Backup-Server.
root@auto-it-vnf-iso-5-8-uas-0:/home/ubuntu# cd /opt/cisco/usp/uploads/
root@auto-it-vnf-iso-5-8-uas-0:/opt/cisco/usp/uploads# ll
total 12
drwxrwxr-x 2 uspadmin usp-data 4096 Nov 8 23:28 ./
drwxr-xr-x 15 root root 4096 Nov 8 23:53 ../
-rw-rw-r-- 1 ubuntu ubuntu 985 Nov 8 23:28 system.cfg
2. Navigieren Sie zum Verzeichnis "Skripts", und sammeln Sie die Protokolle von AutoIT VM.
cd /opt/cisco/usp/uas/scripts
3. Starten Sie das Skript collection-uas-logs.sh, um die Protokolle zu sammeln.
sudo ./collect-uas-logs.sh
4. Sichern Sie die Syslog-Konfiguration, und speichern Sie sie auf dem Backup-Server.
ubuntu@auto-it-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-it-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autoit-vnf.conf
00-autoit-vnf.conf
root@auto-it-vnf-iso-5-1-5-1196-uas-0:ls /etc/rsyslog.conf
rsyslog.conf
AutoVNF-Sicherung
AutoVNF ist für die Aktivierung von VNFM und VNF verantwortlich. AutoDeploy sendet die Konfiguration, die zur Instanziierung beider VNFMs erforderlich ist. und VNF zu AutoVNF und AutoVNF führt diesen Vorgang aus. Zur Aktivierung von VNFM kommuniziert AutoVNF direkt mit VIM/OpenStack. Nach der Aktivierung des VNFM verwendet AutoVNF VNFM zur Aktivierung von VNF.
AutoVNF verfügt über eine 1:N-Redundanz, und in einer Ultra-M-Konfiguration werden drei AutoVNF-VMs ausgeführt. Ein einziger AutoVNF-Ausfall wird in Ultra-M unterstützt, und eine Wiederherstellung ist möglich.
AutoVNF-Sicherungsdetails:
- Konfiguration wird ausgeführt
- ConfD CDB DB
- AutoVNF-Protokolle (von jeder Instanz von AutoVNF)
- Syslog-Konfiguration
Es wird empfohlen, Sicherungen vor jeder Aktivierung/Deaktivierung auf der angegebenen Site zu erstellen und auf den Backup-Server hochzuladen.
1. Melden Sie sich bei Master AutoVNF an, und überprüfen Sie, ob es sich um config-master handelt.
root@auto-testautovnf1-uas-1:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.57.11.101
INSTANCE IP STATE ROLE
-----------------------------------
172.57.12.6 alive CONFD-SLAVE
172.57.12.7 alive CONFD-MASTER
172.57.12.13 alive NA
auto-testautovnf1-uas-1#exit
root@auto-testautovnf1-uas-1:/home/ubuntu# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:c7:dc:89 brd ff:ff:ff:ff:ff:ff
inet 172.57.12.7/24 brd 172.57.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fec7:dc89/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:10:29:1b brd ff:ff:ff:ff:ff:ff
inet 172.57.11.101/24 brd 172.57.11.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe10:291b/64 scope link
valid_lft forever preferred_lft forever
2. Sichern Sie die aktuelle Konfiguration, und übertragen Sie die Datei auf den Backup-Server.
root@auto-testautovnf1-uas-1:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show running-config | save running-autovnf-12202017.cfg
auto-testautovnf1-uas-1#exit
root@auto-testautovnf1-uas-1:/home/ubuntu# ll running-autovnf-12202017.cfg
-rw-r--r-- 1 root root 18181 Dec 20 19:03 running-autovnf-12202017.cfg
3. Sichern Sie die CDB, und übertragen Sie die Datei auf den Backup-Server.
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar cvf autovnf_cdb_backup.tar cdb/
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/vpc.xml
cdb/A.cdb
cdb/gilan.xml
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd#
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd# ll autovnf_cdb_backup.tar
-rw-r--r-- 1 root root 1198080 Dec 20 19:08 autovnf_cdb_backup.tar
4. Navigieren Sie zum Verzeichnis Scripts, erfassen Sie die Protokolle und übertragen Sie sie auf den Backup-Server.
cd /opt/cisco/usp/uas/scripts
sudo ./collect-uas-logs.sh
5. Melden Sie sich bei der Standby-Instanz von AutoVNF an, und führen Sie die folgenden Schritte aus, um die Protokolle zu sammeln und auf den Backup-Server zu übertragen.
6. Sichern Sie die Syslog-Konfiguration auf den Master- und Standby-AutoVNF-VMs, und übertragen Sie sie auf den Backup-Server.
ubuntu@auto-testautovnf1-uas-1:~$sudo su
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.d/00-autovnf.conf
00-autovnf.conf
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
ESC-Sicherung
1. AutoVNF ist dafür verantwortlich, ESC in einer Ultra-M-Lösung durch direkte Interaktion mit VIM zu aktivieren. AutoVNF/EM übergibt die VNF-spezifische Konfiguration an ESC und ESC wiederum rufen VNF durch Interaktion mit VIM auf.
2. ESC bietet 1:1-Redundanz in der Ultra-M-Lösung. Es werden zwei ESC VMs bereitgestellt, die einen Ausfall in Ultra-M unterstützen, d.h. Sie können das System wiederherstellen, wenn ein einzelner Systemfehler auftritt.
ESC-Sicherungsdetails:
- Konfiguration wird ausgeführt
- ConfD CDB DB
- ESC-Protokolle
- Syslog-Konfiguration
3. Die Häufigkeit der ESC DB-Backups ist schwierig und muss sorgfältig behandelt werden, da der ESC die verschiedenen Statuscomputer für verschiedene bereitgestellte VNF VMs überwacht und verwaltet. Es wird empfohlen, dass diese Sicherungen durchgeführt werden, nachdem Sie die Aktivitäten in der angegebenen VNF/POD/Site befolgt haben.
4. Stellen Sie sicher, dass der Zustand von ESC mit der Verwendung von health.sh-Skript gut ist.
[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy
[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running... [ OK ]
postgresql-9.4 (pid 2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION
/opt/cisco/esc/esc_database is a mountpoint
============== ESC HA (MASTER) with DRBD =================
DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0
=======================================
ESC HEALTH PASSED
5. Sichern Sie die aktuelle Konfiguration, und übertragen Sie die Datei auf den Backup-Server.
[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C
admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit
[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg
Sicherungsdatenbank
1. Stellen Sie ESC in den Wartungsmodus ein.
2. Melden Sie sich bei ESC VM an, und führen Sie diesen Befehl aus, bevor Sie die Sicherung durchführen.
[admin@auto-test-vnfm1-esc-0 admin]# sudo bash
[root@auto-test-vnfm1-esc-0 admin]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@auto-test-vnfm1-esc-0 admin]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py
#Set ESC to mainenance mode
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode set --mode=maintenance
3. Prüfen Sie den ESC-Modus, und vergewissern Sie sich, dass er sich im Wartungsmodus befindet.
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode show
4. Backup-DB mit dem in ESC verfügbaren Backup-Wiederherstellungs-Tool der DB.
[root@auto-test-vnfm1-esc-0 admin]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file scp://<username>:<password>@<backup_vm_ip>:<filename>
5. Stellen Sie ESC wieder auf den Betriebsmodus ein, und bestätigen Sie den Modus.
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode set --mode=operation
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode show
6. Navigieren Sie zum Skriptverzeichnis, und sammeln Sie die Protokolle.
[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/esc-scripts
sudo ./collect_esc_log.sh
7. Wiederholen Sie das gleiche Verfahren auf dem Standby-ESC-VM, und übertragen Sie die Protokolle auf den Backup-Server.
8. Sichern der Syslog-Konfiguration auf dem ESC VMS und Übertragen dieser Daten auf den Backup-Server.
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf
EM-Backup
1. Wenn VNFM/ESC aktiviert ist, verwendet AutoVNF ESC, um das EM-Cluster zu aktivieren. Sobald der EM-Cluster aktiv ist, interagiert EM mit ESC, um VNF (VPC/StarOS) aufzurufen.
2. EM bietet 1:N-Redundanz in der Ultra-M-Lösung. Es gibt ein Cluster von drei EM-VMs und Ultra-M, die die Wiederherstellung eines einzelnen VM-Ausfalls unterstützen.
EM-Sicherungsdetails:
- Konfiguration wird ausgeführt
- NCS DB
- EM-Protokolle (von beiden NCS-aktiven/Standby-VMs)
- Syslog-Konfiguration
3. Die Häufigkeit der EM DB-Backups ist schwierig und muss sorgfältig gehandhabt werden, da der ESC die verschiedenen Statusgeräte für verschiedene bereitgestellte VNF VMs überwacht und pflegt. Es wird empfohlen, dass diese Sicherungen durchgeführt werden, nachdem Sie die Aktivitäten in einem bestimmten VNF/POD/Standort befolgt haben.
4. Nehmen Sie EM mit der laufenden Konfiguration zurück, und übertragen Sie die Datei auf den Backup-Server.
ubuntu@vnfd1deploymentem-0:~$ sudo -i
root@vnfd1deploymentem-0:~# ncs_cli -u admin -C
admin connected from 127.0.0.1 using console on vnfd1deploymentem-0
admin@scm# show running-config | save em-running-12202017.cfg
root@vnfd1deploymentem-0:~# ll em-running-12202017.cfg
-rw-r--r-- 1 root root 19957 Dec 20 23:01 em-running-12202017.cfg
5. Nehmen Sie die EM NCS DB-Sicherung und übertragen Sie die Datei auf den Backup-Server.
ubuntu@vnfd1deploymentem-0:~$ sudo -i
root@vnfd1deploymentem-0:~# cd /opt/cisco/em/git/em-scm/ncs-cdb
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm/ncs-cdb# ll
total 472716
drwxrwxr-x 2 root root 4096 Dec 20 02:53 ./
drwxr-xr-x 9 root root 4096 Dec 20 19:22 ../
-rw-r--r-- 1 root root 770 Dec 20 02:48 aaa_users.xml
-rw-r--r-- 1 root root 70447 Dec 20 02:53 A.cdb
-rw-r--r-- 1 root root 483927031 Dec 20 02:48 C.cdb
-rw-rw-r-- 1 root root 47 Jul 27 05:53 .gitignore
-rw-rw-r-- 1 root root 332 Jul 27 05:53 global-settings.xml
-rw-rw-r-- 1 root root 621 Jul 27 05:53 jvm-defaults.xml
-rw-rw-r-- 1 root root 3392 Jul 27 05:53 nacm.xml
-rw-r--r-- 1 root root 6156 Dec 20 02:53 O.cdb
-rw-r--r-- 1 root root 13041 Dec 20 02:48 startup-vnfd.xml
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm/ncs-cdb#
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm# tar cvf em_cdb_backup.tar ncs-cdb
ncs-cdb/
ncs-cdb/O.cdb
ncs-cdb/C.cdb
ncs-cdb/nacm.xml
ncs-cdb/jvm-defaults.xml
ncs-cdb/A.cdb
ncs-cdb/aaa_users.xml
ncs-cdb/global-settings.xml
ncs-cdb/.gitignore
ncs-cdb/startup-vnfd.xml
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm# ll em_cdb_backup.tar
-rw-r--r-- 1 root root 484034560 Dec 20 23:06 em_cdb_backup.tar
6. Navigieren Sie zum Verzeichnis Scripts, erfassen Sie die Protokolle und übertragen Sie sie auf den Backup-Server.
/opt/cisco/em-scripts
sudo ./collect-em-logs.sh
- Wiederholen Sie das gleiche Verfahren, um das Protokoll von der NCS-Standby-VM zu sammeln.
- Sichern Sie die Syslog-Konfiguration auf allen EM VMs, und übertragen Sie sie auf den Backup-Server.
root@vnfd1deploymentem-0:/etc/rsyslog.d# pwd
/etc/rsyslog.d
root@vnfd1deploymentem-0:/etc/rsyslog.d# ll
total 28
drwxr-xr-x 2 root root 4096 Jun 7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun 6 20:33 ../
-rw-r--r-- 1 root root 319 Jun 7 18:36 00-vnmf-proxy.conf
-rw-r--r-- 1 root root 317 Jun 7 18:38 01-ncs-java.conf
-rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf
-rw-r--r-- 1 root root 252 Nov 23 2015 21-cloudinit.conf
-rw-r--r-- 1 root root 1655 Apr 18 2013 50-default.conf
root@vnfd1deploymentem-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf
StarOS Backup
Für StarOS müssen diese Informationen gesichert werden.
- Charging Data Records (CDRs) müssen in regelmäßigen Abständen auf einem Remote-Server gesichert werden.
- Day-0-Konfiguration zum Zeitpunkt der Systembereitstellung angewendet
- Day-N-Konfiguration
- SSDs
- Syslog-Konfiguration
Wiederherstellungsverfahren
OSPD-Wiederherstellung
Das OSPD-Wiederherstellungsverfahren wird auf der Grundlage dieser Annahmen durchgeführt.
- OSPD-Backup ist vom alten OSPD-Server verfügbar
- OSPD Recovery wird auf dem neuen Server durchgeführt, der den alten OSPD-Server im System ersetzt.
AutoDeploy Recovery
1. AutoDeploy VM kann wiederhergestellt werden, wenn sich die VM im Fehlermodus oder im heruntergefahrenen Zustand befindet. Führen Sie einen harten Neustart durch, um die betroffene VM aufzurufen. Führen Sie diese Prüfungen durch, um zu überprüfen, ob dies die Wiederherstellung von AutoDeploy unterstützt.
Checking AutoDeploy Processes
Verify that key processes are running on the AutoDeploy VM:
root@auto-deploy-iso-2007-uas-0:~# initctl status autodeploy
autodeploy start/running, process 1771
root@auto-deploy-iso-2007-uas-0:~# ps -ef | grep java
root 1788 1771 0 May24 ? 00:00:41 /usr/bin/java -jar /opt/cisco/usp/apps/autodeploy/autodeploy-1.0.jar com.cisco.usp.autodeploy.Application --autodeploy.transaction-log-store=/var/log/cisco-uas/autodeploy/transactions
Stopping/Restarting AutoDeploy Processes
#To start the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl start autodeploy
autodeploy start/running, process 11094
#To stop the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl stop autodeploy
autodeploy stop/waiting
#To restart the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl restart autodeploy
autodeploy start/running, process 11049
#If the VM is in ERROR or shutdown state, hard-reboot the AutoDeploy VM
[stack@pod1-ospd ~]$ nova list |grep auto-deploy
| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.12, 10.84.123.39
[stack@pod1-ospd ~]$ nova reboot –hard 9b55270a-2dcd-4ac1-aba3-bf041733a0c9
2. Wenn AutoDeploy nicht wiederhergestellt werden kann, gehen Sie folgendermaßen vor, um den ursprünglichen Zustand wiederherzustellen. Verwenden Sie die zuvor durchgeführte Sicherung.
[stack@pod1-ospd ~]$ nova list |grep auto-deploy
| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.12, 10.84.123.39 [stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.1.2 --delete
3. Nachdem AutoDeploy gelöscht wurde, erstellen Sie es erneut mit derselben floatingip-Adresse.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.1.2
2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.1.1.2:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.1.2' to IP '172.16.181.7'
2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.1.2]
4. Kopieren Sie die Datei AutoDeployment.cfg, ISO und die Datei cond_backup tar von Ihrem Backup-Server in das virtuelle System für die automatische Bereitstellung.
5. Stellen Sie die konfigurierten CD-Dateien aus der Sicherungstar-Datei wieder her.
ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i
ubuntu@auto-deploy-iso-2007-uas-0:# service uas-confd stop
uas-confd stop/waiting
root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb
root@auto-deploy-iso-2007-uas-0~# service uas-confd start
uas-confd start/running, process 2036
#Restart AutoDeploy process
root@auto-deploy-iso-2007-uas-0~# service autodeploy restart
autodeploy start/running, process 2144
#Check that confd was loaded properly by checking earlier transactions.
root@auto-deploy-iso-2007-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
auto-deploy-iso-2007-uas-0#show transaction
SERVICE SITE
DEPLOYMENT SITE TX AUTOVNF VNF AUTOVNF
TX ID TX TYPE ID DATE AND TIME STATUS ID ID ID ID TX ID
-------------------------------------------------------------------------------------------------------------------------------------
1512571978613 service-deployment tb5bxb 2017-12-06T14:52:59.412+00:00 deployment-success
6. Wenn VM erfolgreich wiederhergestellt und ausgeführt wurde Stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt werden.
ubuntu@auto-deploy-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autodeploy.conf
00-autodeploy.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
AutoIT-VNF-Wiederherstellung
1. Die AutoIT-VNF VM kann wiederhergestellt werden. Wenn sich die VM im Fehler- oder Herunterladezustand befindet, führen Sie einen harten Neustart durch, um die betroffene VM aufzurufen. Führen Sie diese Schritte aus, um AutoIT-VNF wiederherzustellen.
Checking AutoIT-VNF Processes
Verify that key processes are running on the AutoIT-VNF VM:
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit status
AutoIT-VNF is running.
#Stopping/Restarting AutoIT-VNF Processes
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit stop
AutoIT-VNF API server stopped.
#To restart the AutoIT-VNF processes:
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit restart
AutoIT-VNF API server stopped.
Starting AutoIT-VNF
/opt/cisco/usp/apps/auto-it/vnf
AutoIT API server started.
#If the VM is in ERROR or shutdown state, hard-reboot the AutoDeploy VM
[stack@pod1-ospd ~]$ nova list |grep auto-it
| 1c45270a-2dcd-4ac1-aba3-bf041733d1a1 | auto-it-vnf-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.13, 10.84.123.40
[stack@pod1-ospd ~]$ nova reboot –hard 1c45270a-2dcd-4ac1-aba3-bf041733d1a1
2. Wenn AutoIT-VNF nicht wiederhergestellt werden kann, gehen Sie folgendermaßen vor, um den ursprünglichen Zustand wiederherzustellen. Verwenden Sie die Sicherungsdatei.
[stack@pod1-ospd ~]$ nova list |grep auto-it
| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.3, 10.84.123.42 [stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.1.3 --delete
3. Erstellen Sie Auto-IT neu, indem Sie das Auto-it-VNF-Staging-Skript ausführen und stellen Sie sicher, dass dieselbe Floating-IP verwendet wird, die bereits verwendet wurde.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.1.3
2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.1.1.3:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.1.3' to IP '172.16.181.9'
2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.1.3
4. Im POD verwendete ISO-Images müssen auf AutoIT-VNF neu geladen werden.
[stack@pod1-ospd ~]$ cd images/5_1_7-2007/isos
[stack@pod1-ospd isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.1.3:5001/isos
{
"iso-id": "5.1.7-2007"
}
Note: 10.1.1.3 is AutoIT-VNF IP in the above command.
#Validate that ISO is correctly loaded.
[stack@pod1-ospd isos]$ curl http://10.1.1.3:5001/isos
{
"isos": [
{
"iso-id": "5.1.7-2007"
}
]
}
5. Kopieren Sie die VNF-system.cfg-Dateien vom Remote-Server in das virtuelle AutoIT-VNF-System. In diesem Beispiel wird es von AutoDeploy in AutoIT-VNF VM kopiert.
[stack@pod1-ospd autodeploy]$ scp system-vnf* ubuntu@10.1.1.3:.
ubuntu@10.1.1.3's password:
system-vnf1.cfg 100% 1197 1.2KB/s 00:00
system-vnf2.cfg 100% 1197 1.2KB/s 00:00
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd
/home/ubuntu
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls
system-vnf1.cfg system-vnf2.cfg
6. Kopieren Sie die Dateien an einem geeigneten Speicherort auf AutoIT-VNF, wie in der AutoDeploy-Konfiguration beschrieben. Siehe hier.
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ sudo -i
root@auto-it-vnf-iso-2007-uas-0:~$ cp –rp system-vnf1.cfg system-vnf2.cfg /opt/cisco/usp/uploads/
root@auto-it-vnf-iso-2007-uas-0:~$ls /opt/cisco/usp/uploads/
system-vnf1.cfg system-vnf2.cfg
7. Wenn die VM erfolgreich wiederhergestellt und ausgeführt wird, stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt wurden.
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autoit-vnf.conf
00-autoit-vnf.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:ls /etc/rsyslog.conf
rsyslog.conf
Automatische VNF-Wiederherstellung
1. AutoVNF VM kann wiederhergestellt werden, wenn sich die VM im Fehler- oder Herunterladezustand befindet. Führen Sie einen harten Neustart durch, um die betroffene VM aufzurufen. Führen Sie diese Schritte aus, um AutoVNF wiederherzustellen.
2. Identifizieren Sie die VM, die sich im Fehler- oder heruntergefahrenen Zustand befindet. Führen Sie einen Kaltstart der AutoVNF VM durch.
In diesem Beispiel starten Sie auto-testautovnf1-uas-2 neu.
[root@tb1-baremetal scripts]# nova list | grep "auto-testautovnf1-uas-[0-2]"
| 3834a3e4-96c5-49de-a067-68b3846fba6b | auto-testautovnf1-uas-0 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.6; auto-testautovnf1-uas-management=172.57.11.8 |
| 0fbfec0c-f4b0-4551-807b-50c5fe9d3ea7 | auto-testautovnf1-uas-1 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.7; auto-testautovnf1-uas-management=172.57.11.12 |
| 432e1a57-00e9-4e58-8bef-2a20652df5bf | auto-testautovnf1-uas-2 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.13; auto-testautovnf1-uas-management=172.57.11.4 |
[root@tb1-baremetal scripts]# nova reboot --hard 432e1a57-00e9-4e58-8bef-2a20652df5bf
Request to reboot server <Server: auto-testautovnf1-uas-2> has been accepted.
[root@tb1-baremetal scripts]#
3. Wenn die VM hochgefahren ist, überprüfen Sie, ob sie wieder dem Cluster beitritt.
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/scripts# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.57.11.101
INSTANCE IP STATE ROLE
-----------------------------------
172.57.12.6 alive CONFD-SLAVE
172.57.12.7 alive CONFD-MASTER
172.57.12.13 alive NA
4. Wenn die AutoVNF VM nach dem oben genannten Verfahren nicht wiederhergestellt werden kann, müssen Sie sie mithilfe dieser Schritte wiederherstellen.
[stack@pod1-ospd ~]$ nova list | grep vnf1-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | vnf1-UAS-uas-0 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.10; vnf1-UAS-uas-management=172.168.10.3
[stack@pod1-ospd ~]$ nova delete vnf1-UAS-uas-0
Request to delete server vnf1-UAS-uas-0 has been accepted.
5. Um die autovnf-uas VM wiederherzustellen, führen Sie uas-check-Skript aus, um den Status zu überprüfen. Sie muss einen Fehler melden. Führen Sie dann erneut mit —fix-Option aus, um die fehlende UAS VM wiederherzustellen.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@pod1-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors
[stack@tb3-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance vnf1-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance vnf1-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance vnf1-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance vnf1-UAS-uas-0' and attaching volume ‘vnf1-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘vnf1-UAS-uas-0'
[stack@tb3-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS
2017-11-16 13:11:07,472 - INFO: Check of AutoVNF cluster started
2017-11-16 13:11:09,510 - INFO: Found 3 ACTIVE AutoVNF instances
2017-11-16 13:11:09,511 - INFO: Check completed, AutoVNF cluster is fine
6. Melden Sie sich bei Master AutoVNF VM an. Innerhalb weniger Minuten nach der Wiederherstellung muss die neu erstellte Instanz dem Cluster beitreten und sich im aktiven Zustand befinden.
tb3-bxb-vnf1-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP STATE ROLE
-----------------------------------
172.17.180.6 alive CONFD-SLAVE
172.17.180.7 alive CONFD-MASTER
172.17.180.9 alive NA
#if uas-check.py --fix fails, you may need to copy this file and execute again.
[stack@tb3-ospd]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
[stack@tb3-ospd]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/
7. Wenn die VM erfolgreich wiederhergestellt und ausgeführt wird, stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt wurden. Stellen Sie sicher, dass das System in allen AutoVNF VMs wiederhergestellt ist.
ubuntu@auto-testautovnf1-uas-1:~$sudo su
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.d/00-autovnf.conf
00-autovnf.conf
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
ESC-Wiederherstellung
1. Wenn sich die VM im Fehler- oder Herunterladezustand befindet, kann eine ESC VM wiederhergestellt werden. Führen Sie einen harten Neustart durch, um die betroffene VM aufzurufen. Führen Sie diese Schritte aus, um ESC wiederherzustellen.
2. Identifizieren Sie die VM, die sich im Fehler- oder Herunterladezustand befindet, nachdem Sie einen harten Neustart der ESC VM identifiziert haben. In diesem Beispiel wird auto-test-vnfm1-ESC-0 neu gestartet.
[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-
| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3 |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5 |
[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.
[root@tb1-baremetal scripts]#
3. Wenn ESC VM gelöscht wird und erneut aktiviert werden muss, folgen Sie dieser Abfolge von Schritten.
[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4 |
[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.
4. Suchen Sie in AutoVNF-UAS die ESC-Bereitstellungstransaktion, und suchen Sie im Protokoll für die Transaktion die Befehlszeile boot_vm.py, um die ESC-Instanz zu erstellen.
ubuntu@vnf1-uas-uas-0:~$ sudo -i
root@vnf1-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on vnf1-uas-uas-0
vnf1-uas-uas-0#show transaction
TX ID TX TYPE DEPLOYMENT ID TIMESTAMP STATUS
------------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b vnf-deployment vnf1-DEPLOYMENT 2017-11-29T02:01:27.750692-00:00 deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b vnfm-deployment vnf1-ESC 2017-11-29T01:56:02.133663-00:00 deployment-success
vnf1-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
<logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
<tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
<log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: vnf1-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'vnf1-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py vnf1-ESC-ESC-1 --flavor vnf1-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net vnf1-UAS-uas-management --gateway_ip 172.168.10.1 --net vnf1-UAS-uas-orchestration --os_auth_url http://10.1.1.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.1.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh]...
5. Speichern Sie die Zeile boot_vm.py in einer Shell-Skriptdatei (esc.sh), und aktualisieren Sie alle Zeilen mit dem Benutzernamen ***** und dem Kennwort **** mit den richtigen Informationen (in der Regel Core/Cisco@123). Sie müssen auch die -encrypt_key-Option entfernen. Für user_pass und user_cond_pass müssen Sie das Format -user_passwd username:password (Beispiel - admin:Cisco@123) verwenden.
Suchen Sie jetzt die URL zu bootvm.py aus running-config, und rufen Sie die Datei bootvm.py auf die autovnf-uas VM. 10.1.1.3 ist in diesem Fall Auto-IT.
root@vnf1-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on vnf1-uas-uas-0
vnf1-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
value http://10.1.1.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!
root@vnf1-uas-uas-0:~# wget http://10.1.1.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52-- http://10.1.1.3/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.1.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[======================================================================================================>] 127,771 --.-K/s in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771
Create a /tmp/esc_params.cfg file.
root@vnf1-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg
6. Führen Sie das Shell-Skript aus, das bootvm.py python-Skript mit Optionen ausführt.
root@vnf1-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py vnf1-ESC-ESC-1 --flavor vnf1-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net vnf1-UAS-uas-management --gateway_ip 172.168.10.1 --net vnf1-UAS-uas-orchestration --os_auth_url http://10.1.1.5:5000/v2.0 --os_tenant_name core --os_username core --os_password Cisco@123 --bs_os_auth_url http://10.1.1.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password Cisco@123 --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:Cisco@123 --user_confd_pass admin:Cisco@123 --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh
+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | mgmt |
| OS-EXT-SRV-ATTR:host | tb5-ultram-osd-compute-1.localdomain |
| OS-EXT-SRV-ATTR:hypervisor_hostname | tb5-ultram-osd-compute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-000001eb |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2017-12-02T13:28:32.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| addresses | {"vnf1-UAS-uas-orchestration": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:d7:c6:19", "version": 4, "addr": "172.168.11.14", "OS-EXT-IPS:type": "fixed"}], "vnf1-UAS-uas-management": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:31:ee:cd", "version": 4, "addr": "172.168.10.6", "OS-EXT-IPS:type": "fixed"}]}
| config_drive | True |
| created | 2017-12-02T13:27:49Z |
| flavor | {"id": "457623b6-05d5-403c-b2e4-aa3b6a0c9d32", "links": [{"href": "http://10.1.1.5:8774/flavors/457623b6-05d5-403c-b2e4-aa3b6a0c9d32", "rel": "bookmark"}]} |
| hostId | f5d2bbf0c5a7df34cf2e6f62ae0702ef120ff82f81c3f7664ffb35e9 |
| id | 2601b8ec-8ff8-4285-810a-e859f6642ab6 |
| image | {"id": "3fe6b197-961b-4651-af22-dfd910436689", "links": [{"href": "http://10.1.1.5:8774/images/3fe6b197-961b-4651-af22-dfd910436689", "rel": "bookmark"}]} |
| key_name | - |
| metadata | {} |
| name | vnf1-esc-esc-1 |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| security_groups | [{"name": "default"}, {"name": "default"}] |
| status | ACTIVE |
| tenant_id | fd4b15df46c6469cbacf5b80dcc98a5c |
| updated | 2017-12-02T13:28:32Z |
| user_id | d3b51d6f705f4826b22817f27505c6cd |
7. Überprüfen Sie in OSPD, ob die neue ESC VM aktiv/aktiv ist.
[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6 |
#Log in to new ESC and verify Backup state. You may execute health.sh on ESC Master too.
ubuntu@vnf1-uas-uas-0:~$ ssh admin@172.168.11.14
…
####################################################################
# ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
####################################################################
[admin@vnf1-esc-esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy
[admin@vnf1-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) =================
=======================================
ESC HEALTH PASSED
[admin@vnf1-esc-esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
8. Wenn ESC VM nicht wiederherstellbar ist und die Wiederherstellung der Datenbank erfordert, stellen Sie die Datenbank aus der zuvor durchgeführten Sicherung wieder her.
9. Stellen Sie bei der Wiederherstellung der ESC-Datenbank sicher, dass der ESC-Dienst beendet wird, bevor Sie die Datenbank wiederherstellen. Führen Sie für ESC HA zunächst eine sekundäre VM und dann die primäre VM aus.
# service keepalived stop
10. Überprüfen Sie den ESC-Dienststatus, und stellen Sie sicher, dass in primären und sekundären VMs für HA alles gestoppt wird.
# escadm status
11. Führen Sie das Skript aus, um die Datenbank wiederherzustellen. Im Rahmen der Wiederherstellung der DB zur neu erstellten ESC-Instanz fördert das Tool auch eine der Instanzen als primären ESC, mountet ihren DB-Ordner auf dem DRBD-Gerät und startet die PostgreSQL-Datenbank.
# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>
12. Starten Sie den ESC-Dienst neu, um die Datenbankwiederherstellung abzuschließen.
13. Wenn HA in beiden VMs ausgeführt wird, starten Sie den Keepalived Service neu.
# service keepalived start
14. Sobald die VM erfolgreich wiederhergestellt und ausgeführt wurde, Stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt werden. Stellen Sie sicher, dass es in allen ESC VMs wiederhergestellt wird.
[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf
EM-Wiederherstellung
1. Wenn sich EM VM aufgrund einer oder anderer Umstände im Status Keine/Fehler befindet, kann der Benutzer die angegebene Sequenz befolgen, um die betroffene EM VM wiederherzustellen.
2. ESC/VNFM ist die Komponente, die die EM VMs überwacht. Falls sich EM im Fehlerstatus befindet, versucht ESC, das EM VM automatisch wiederherzustellen. Wenn ESC die Wiederherstellung nicht erfolgreich abschließen kann, markiert ESC aus irgendeinem Grund die VM im Fehlerstatus.
3. In solchen Szenarien kann der Benutzer das EM VM manuell wiederherstellen, sobald das zugrunde liegende Infrastrukturproblem behoben ist. Es ist wichtig, diese manuelle Wiederherstellung erst auszuführen, nachdem ein zugrunde liegendes Problem behoben wurde.
4. Identifizieren Sie die VM im fehlerhaften Zustand.
[stack@pod1-ospd ~]$ source corerc
[stack@pod1-ospd ~]$ nova list --field name,host,status |grep -i err
| c794207b-a51e-455e-9a53-3b8ff3520bb9 | vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8 | None | ERROR |
5. Melden Sie sich beim ESC Master an, führen Sie Recovery-vm-action für jedes betroffene EM und CF VM aus. Sei geduldig! Der ESC plant die Wiederherstellungsaktion, die möglicherweise nicht für einige Minuten erfolgt.
ubuntu@vnf1-uas-uas-1:~$ ssh admin@172.168.10.3
…
[admin@vnf1-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[sudo] password for admin:
Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<ok/>
</rpc-reply>
6. Überwachen Sie /var/log/esc/yangesc.log, bis der Befehl abgeschlossen ist.
[admin@vnf1-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN Status Code: 200
14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8]
#Log in to new EM and verify EM state is up.
ubuntu@vnf1vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on vnf1vnfddeploymentem-1
admin@scm# show ems
EM VNFM
ID SLA SCM PROXY
---------------------
2 up up up
3 up up up
Wenn ESC zum Starten von VM fehlschlägt
1. In einigen Fällen kann ESC aufgrund eines unerwarteten Zustands nicht die VM starten. Eine Problemumgehung besteht darin, einen ESC-Switchover durchzuführen, indem der Master-ESC neu gestartet wird. Der ESC-Switchover dauert etwa eine Minute. Führen Sie health.sh auf dem neuen Master-ESC aus, um zu überprüfen, ob er aktiviert ist. Wenn der ESC Master wird, kann ESC den VM-Status reparieren und das virtuelle System starten. Da dieser Vorgang geplant ist, müssen Sie 5-7 Minuten warten, bis er abgeschlossen ist.
2. Sie können /var/log/esc/yangesc.log und /var/log/esc/escmanager.log überwachen. Wenn Sie sehen, dass die VM nach 5-7 Minuten nicht wiederhergestellt wird, muss der Benutzer die manuelle Wiederherstellung der betroffenen VM(s) durchführen.
3. Sobald die VM erfolgreich wiederhergestellt und ausgeführt wurde, Stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt werden. Stellen Sie sicher, dass es in allen ESC VMs wiederhergestellt ist.
root@abautotestvnfm1em-0:/etc/rsyslog.d# pwd
/etc/rsyslog.d
root@abautotestvnfm1em-0:/etc/rsyslog.d# ll
total 28
drwxr-xr-x 2 root root 4096 Jun 7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun 6 20:33 ../]
-rw-r--r-- 1 root root 319 Jun 7 18:36 00-vnmf-proxy.conf
-rw-r--r-- 1 root root 317 Jun 7 18:38 01-ncs-java.conf
-rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf
-rw-r--r-- 1 root root 252 Nov 23 2015 21-cloudinit.conf
-rw-r--r-- 1 root root 1655 Apr 18 2013 50-default.conf
root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf
StarOS-Wiederherstellung
1. Wenn eine der StarOS VM aufgrund einer oder anderer Bedingungen im Status Keine/Fehler angezeigt wird, kann der Benutzer diese Sequenz befolgen, um die betroffene StarOS VM wiederherzustellen.
2. ESC/VNFM ist die Komponente, die die StarOS VMs überwacht. Falls sich die CF/SF VM im Fehlerzustand befindet, versucht ESC, die CF/SF VM automatisch wiederherzustellen. Wenn ESC die Wiederherstellung nicht erfolgreich abschließen kann, markiert ESC diese VM aus irgendeinem Grund im Fehlerstatus.
3. In solchen Szenarien kann der Benutzer das CF/SF VM manuell wiederherstellen, sobald das zugrunde liegende Infrastrukturproblem behoben ist. Es ist wichtig, diese manuelle Wiederherstellung erst auszuführen, nachdem Sie ein zugrunde liegendes Problem behoben haben.
4. Identifizieren Sie das virtuelle System im Fehlerstatus.
[stack@pod1-ospd ~]$ source corerc
[stack@pod1-ospd ~]$ nova list --field name,host,status |grep -i err
| c794207b-a51e-455e-9a53-3b8ff3520bb9 | vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3 | None | ERROR |
5. Melden Sie sich bei ESC Master an, führen Sie Recovery-vm-action für jeden betroffenen EM- und CF VM.Be-Patienten aus. Der ESC plant die Wiederherstellungsaktion, die möglicherweise nicht für einige Minuten erfolgt.
ubuntu@vnf1-uas-uas-1:~$ ssh admin@172.168.10.3
…
[admin@vnf1-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3
[sudo] password for admin:
Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<ok/>
</rpc-reply>
##Monitor the /var/log/esc/yangesc.log until command completes.
[admin@vnf1-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN Status Code: 200
14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3]
6. Validieren Sie dies auch, indem Sie die Registerkarte "Karte anzeigen" in StarOS ausführen. Wenn es sich bei der wiederhergestellten VM um SF handelt, muss der Benutzer diese ggf. aktivieren. Nehmen Sie die notwendigen Änderungen an der StarOS-Konfiguration vor.
[local]VNF1# show card tab
Saturday December 02 14:40:20 UTC 2017
Slot Card Type Oper State SPOF Attach
----------- -------------------------------------- ------------- ---- ------
1: CFC Control Function Virtual Card Active No
2: CFC Control Function Virtual Card Standby -
3: FC 4-Port Service Function Virtual Card Active No
4: FC 4-Port Service Function Virtual Card Active No
5: FC 4-Port Service Function Virtual Card Active No
6: FC 4-Port Service Function Virtual Card Standby -
7: FC 4-Port Service Function Virtual Card Active No
8: FC 4-Port Service Function Virtual Card Active No
9: FC 4-Port Service Function Virtual Card Active No
10: FC 4-Port Service Function Virtual Card Active No
Wenn ESC zum Starten von VM fehlschlägt
In einigen Fällen kann ESC aufgrund eines unerwarteten Zustands nicht die VM starten. Eine Problemumgehung besteht darin, einen ESC-Switchover durchzuführen, indem der Master-ESC neu gestartet wird. Der ESC-Switchover dauert etwa eine Minute. Führen Sie health.sh auf dem neuen Master-ESC aus, um zu überprüfen, ob dieser aktiviert ist. Wenn der ESC Master wird, kann ESC den VM-Status reparieren und das virtuelle System starten. Da dieser Vorgang geplant ist, müssen Sie 5-7 Minuten warten, bis er abgeschlossen ist. Sie können /var/log/esc/yangesc.log und /var/log/esc/escmanager.log überwachen. Wenn Sie nicht sehen, dass VM nach 5-7 Minuten wiederhergestellt wird, müssen Sie die manuelle Wiederherstellung der betroffenen VM(s) durchführen.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
29-Aug-2018 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)