Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Sicherungsverfahren

OSPD-Sicherung

AutoDeploy Backup

AutoIT-VNF Backup

AutoVNF-Sicherung

ESC-Sicherung

EM-Backup

StarOS Backup

Wiederherstellungsverfahren

OSPD-Wiederherstellung

AutoDeploy Recovery

AutoIT-VNF-Wiederherstellung

Automatische VNF-Wiederherstellung

ESC-Wiederherstellung

EM-Wiederherstellung

StarOS-Wiederherstellung

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.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

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.

Hinweis: Wenn mehr als ein Fehler vorliegt, wird er nicht unterstützt und erfordert möglicherweise eine Neubereitstellung des Systems.

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.

Hinweis: Wenn mehr als ein Fehler vorliegt, wird er nicht unterstützt und erfordert möglicherweise eine Neubereitstellung des Systems.

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.

Hinweis: Wenn mehr als ein Fehler vorliegt, wird er nicht unterstützt und erfordert möglicherweise eine Neubereitstellung des Systems.

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.