Sicherungs- und Wiederherstellungsverfahren für verschiedene Ultra-M-Komponenten - CPS

Einleitung

In diesem Dokument werden die erforderlichen Schritte zum Sichern und Wiederherstellen einer virtuellen Maschine in einer Ultra-M-Konfiguration beschrieben, die CPS-Funktionen für virtuelle Netzwerke hostet.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte virtualisierte Mobile Packet Core-Lösung, die die Bereitstellung von Virtual Network Functions (VNFs) vereinfacht. Die Ultra-M-Lösung besteht aus den folgenden VM-Typen:

• Elastic Services Controller (ESC)
• Cisco Policy Suite (CPS)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind wie in diesem Bild dargestellt.

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
WSA	Elastischer Service-Controller
MOPP	Verfahrensweise
OSD	Objektspeicherplatten
Festplatte	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Manager für virtuelle Infrastruktur
VM	Virtuelles System
UUID	Universeller eindeutiger IDentifier

Backup-Verfahren

OSPD-Backup

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 vom OSP-D-Knoten, ob alle Undercloud-Services geladen, aktiv und ausgeführt werden. 

[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, for example, 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 ausreichend Speicherplatz zur Verfügung steht, bevor Sie den Sicherungsvorgang durchführen. Dieser Tarball wird voraussichtlich mindestens 3,5 GB groß sein.

[stack@director ~]$df -h

4. Führen Sie diese Befehle als Root-Benutzer aus, um die Daten aus dem Untercloud-Knoten in einer 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

ESC-Backup

1. ESC wiederum aktiviert Virtual Network Function (VNF) durch Interaktion mit VIM.

2. ESC bietet 1:1-Redundanz in Ultra-M-Lösung. Es sind 2 ESC VMs bereitgestellt, die einen einzelnen Fehler in Ultra-M unterstützen. Beispiel: Stellen Sie das System wieder her, wenn ein einzelner Fehler im System auftritt.

ESC-Sicherungsdetails:

• Ausführen der Konfiguration
• KonfD CDB DB
• ESC-Protokolle
• Syslog-Konfiguration

3. Die Häufigkeit der ESC DB-Backups ist kompliziert und muss sorgfältig behandelt werden, da ESC die verschiedenen Zustandssysteme für verschiedene bereitgestellte VNF VMs überwacht und wartet. Es wird empfohlen, diese Sicherungen nach diesen Aktivitäten in einem bestimmten VNF/POD/Standort durchzuführen.

4. Überprüfen Sie mithilfe des health.sh-Skripts, ob der Zustand von ESC einwandfrei ist.

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Primary 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 (Primary) 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 Sicherungsserver.

[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

 ESC-Datenbank sichern

1. Melden Sie sich bei ESC VM an, und führen Sie diesen Befehl aus, bevor Sie die Sicherung durchführen.

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# 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@esc esc-scripts]# escadm op_mode set --mode=maintenance

2. Überprüfen Sie den ESC-Modus, und stellen Sie sicher, dass er sich im Wartungsmodus befindet.

[root@esc esc-scripts]# escadm op_mode show

3. Backup-Datenbank mit Datenbank-Backup-Wiederherstellungstool verfügbar in ESC.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://<username>:<password>@<backup_vm_ip>:<filename>

4. Setzen Sie ESC wieder in den Betriebsmodus, und bestätigen Sie den Modus.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

5. Navigieren Sie zum Verzeichnis scripts und sammeln Sie die Protokolle.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

 6. Um eine Momentaufnahme des ESC zu erstellen, fahren Sie zuerst den ESC herunter.

shutdown -r now

7. Erstellen Sie aus OSPD einen Image-Snapshot.

nova image-create --poll esc1 esc_snapshot_27aug2018

8. Überprüfen Sie, ob der Snapshot erstellt wurde.

openstack image list | grep esc_snapshot_27aug2018

9. Starten Sie den ESC über OSPD.

nova start esc1 

10. Wiederholen Sie den gleichen Vorgang auf dem Standby-ESC-virtuellen System und übertragen Sie die Protokolle auf den Backup-Server.

11. Sammeln Sie das Backup der Syslog-Konfiguration auf dem ESC-VMS, und übertragen Sie es 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

  

CPS-Sicherung

Schritt 1: Erstellen Sie eine Sicherung des CPS Cluster-Managers.

Verwenden Sie diesen Befehl, um die nova-Instanzen anzuzeigen und den Namen der Cluster Manager VM-Instanz zu notieren:

nova list

Stoppen Sie den Cluman von ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP <vm-name>

Schritt 2: Überprüfen Sie, ob sich der Cluster Manager im SHUTOFF-Zustand befindet.

admin@esc1 ~]$ /opt/cisco/esc/confd/bin/confd_cli 

admin@esc1> show esc_datamodel opdata tenants tenant Core deployments * state_machine

Schritt 3: Erstellen Sie ein Nova-Snapshot-Image, wie in diesem Befehl dargestellt:

nova image-create --poll <cluman-vm-name> <snapshot-name>

.Important - Falls VM nach der Snapshot-Erstellung nicht mehr erreichbar ist, überprüfen Sie den Status der VM mithilfe des nova list-Befehls. Wenn sie sich im SHUTOFF-Zustand befindet, müssen Sie die VM manuell starten.

Schritt 4: Anzeigen der Bildliste mit dem folgenden Befehl: nova image-list

Abbildung 1: Beispielausgabe

Schritt 5: Wenn ein Snapshot erstellt wird, wird das Snapshot-Image in OpenStack Glance gespeichert. Um den Snapshot in einem Remote-Datenspeicher zu speichern, laden Sie den Snapshot herunter, und übertragen Sie die Datei in OSPD nach (/home/stack/CPS_BACKUP).

Um das Image herunterzuladen, verwenden Sie den folgenden Befehl in OpenStack:

glance image-download –-file For example: glance image-download –-file snapshot.raw 2bbfb51c-cd05-4b7c-ad77-8362d76578db

Schritt 6: Listen Sie die heruntergeladenen Images wie in diesem Befehl dargestellt auf:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

Schritt 7. Speichern Sie den Snapshot der Cluster Manager-VM, der später wiederhergestellt werden soll.

2. Sichern Sie die Konfiguration und die Datenbank.

1. config_br.py -a export --all /var/tmp/backup/ATP1_backup_all_$(date +\%Y-\%m-\%d).tar.gz OR
2. config_br.py -a export --mongo-all /var/tmp/backup/ATP1_backup_mongoall$(date +\%Y-\%m-\%d).tar.gz
3. config_br.py -a export --svn --etc --grafanadb --auth-htpasswd --haproxy /var/tmp/backup/ATP1_backup_svn_etc_grafanadb_haproxy_$(date +\%Y-\%m-\%d).tar.gz
4. mongodump - /var/qps/bin/support/env/env_export.sh --mongo /var/tmp/env_export_$date.tgz
5. patches - cat /etc/broadhop/repositories, check which patches are installed and copy those patches to the backup directory /home/stack/CPS_BACKUP on OSPD
6. backup the cronjobs by taking backup of the cron directory: /var/spool/cron/ from the Pcrfclient01/Cluman. Then move the file to CPS_BACKUP on the OSPD.

Überprüfen Sie anhand der crontab-l, ob ein anderes Backup erforderlich ist.

Übertragen Sie alle Sicherungen auf OSPD /home/stack/CPS_BACKUP.

3. Sichern Sie die yaml-Datei von ESC Primary.

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config.xml

Übertragen Sie die Datei in OSPD /home/stack/CPS_BACKUP.

4. Sichern Sie crontab -l-Einträge.

Erstellen Sie eine TXT-Datei mit crontab -l und ftp sie an einen Remote-Speicherort (in OSPD /home/stack/CPS_BACKUP).

5. Sichern Sie die Routendateien von LB und PCRF-Client.

Collect and scp the configurations from both LBs and Pcrfclients
route -n /etc/sysconfig/network-script/route-*

Wiederherstellungsverfahren

OSPD-Wiederherstellung

Das OSPD-Wiederherstellungsverfahren wird auf der Grundlage dieser Annahmen durchgeführt. 

1. Die OSPD-Sicherung ist vom alten OSPD-Server aus verfügbar.

2. OSPD Wiederherstellung kann auf dem neuen Server durchgeführt werden, der den Ersatz des alten OSPD-Server im System ist. .

ESC-Wiederherstellung

1. ESC VM ist wiederherstellbar, wenn die VM sich im Fehler- oder Abschaltzustand befindet. Führen Sie einen harten Neustart durch, um die betroffene VM hochzufahren. Führen Sie diese Schritte aus, um ESC wiederherzustellen.

2. Identifizieren Sie das virtuelle System, das sich im FEHLER- oder Herunterfahrzustand befindet, sobald ein Hard-Reboot des virtuellen Systems ESC erkannt wurde. In diesem Beispiel starten Sie auto-test-vnfm1-ESC-0 neu.                                   

[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.31.12.11; auto-testautovnf1-uas-management=172.31.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.31.12.15; auto-testautovnf1-uas-management=172.31.11.15                                                                                      |

[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 aufgerufen werden muss. Gehen Sie folgendermaßen vor.

[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.16.11.14; vnf1-UAS-uas-management=172.16.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.                                                 

4. Wenn die ESC VM nicht wiederherstellbar ist und eine Wiederherstellung der Datenbank erfordert, stellen Sie die Datenbank aus der zuvor durchgeführten Sicherung wieder her.

5. Bei der Wiederherstellung der ESC-Datenbank müssen Sie sicherstellen, dass der ESC-Dienst vor der Wiederherstellung der Datenbank angehalten wird. Bei ESC HA führen Sie zuerst die sekundäre VM und dann die primäre VM aus.

# service keepalived stop

6. Überprüfen Sie den ESC-Servicestatus, und stellen Sie sicher, dass in primären und sekundären VMs für die hohe Verfügbarkeit alles gestoppt wird.

# escadm status

7. Führen Sie das Skript aus, um die Datenbank wiederherzustellen. Im Rahmen der Wiederherstellung der DB auf die neu erstellte ESC-Instanz kann das Tool auch eine der Instanzen als primäre ESC heraufstufen, ihren DB-Ordner auf das drbd-Gerät mounten und die PostgreSQL-Datenbank starten.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>

8. Starten Sie den ESC-Dienst neu, um die Datenbankwiederherstellung abzuschließen. Starten Sie den Keepalived-Service neu, wenn die HA-Ausführung in beiden VMs erfolgen soll.

# service keepalived start

9. Nachdem die VM erfolgreich wiederhergestellt und ausgeführt wurde, stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus dem vorherigen erfolgreichen bekannten Backup wiederhergestellt wurden. Stellen Sie sicher, dass sie in allen ESC-VMs wiederhergestellt wurden.

[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

10. Wenn der ESC aus dem OSPD-Snapshot neu erstellt werden muss, verwenden Sie diesen Befehl unter Verwendung des Snapshots, der während des Backups erstellt wurde.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

11. Überprüfen Sie den Status des ESC, nachdem die Wiederherstellung abgeschlossen ist. 

nova list --fileds name,host,status,networks | grep esc

12. Überprüfen Sie mit diesem Befehl den ESC-Zustand.

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

Wenn ESC VM nicht startet

• In einigen Fällen kann ESC aufgrund eines unerwarteten Zustands das virtuelle System nicht starten. Eine Problemumgehung besteht darin, einen ESC-Switchover durchzuführen, indem der primäre ESC neu gestartet wird. Die ESC-Umschaltung kann etwa eine Minute dauern.  Führen Sie health.sh auf dem neuen primären ESC aus, um zu überprüfen, ob es aktiv ist. Wenn der ESC zur primären Schnittstelle wird, kann ESC den VM-Status korrigieren und die VM 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 sehen, dass die VM nach 5-7 Minuten NICHT wiederhergestellt wird, muss der Benutzer die manuelle Wiederherstellung der betroffenen VM(s) durchführen.

• Sobald die VM erfolgreich wiederhergestellt und ausgeführt wurde, stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus dem vorherigen erfolgreichen bekannten Backup wiederhergestellt wurden. Stellen Sie sicher, dass sie in allen ESC-VMs wiederhergestellt wird.

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

CPS-Wiederherstellung

Cluster Manager VM in OpenStack wiederherstellen

Schritt 1: Kopieren Sie den Snapshot des virtuellen Cluster-Managers auf den Controller-Blade, wie in diesem Befehl dargestellt:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

Schritt 2: Laden Sie das Snapshot-Image aus dem Datenspeicher in OpenStack hoch:

  

glance image-create --name --file --disk-format qcow2 --container-format bare

Schritt 3: Überprüfen Sie, ob der Snapshot mit einem Nova-Befehl hochgeladen wurde, wie in diesem Beispiel gezeigt:

nova image-list

Abbildung 2: Beispielausgabe

Schritt 4: Je nachdem, ob der Cluster-Manager VM vorhanden ist oder nicht, können Sie den Cluman erstellen oder den Cluman neu erstellen:

・ Wenn die Cluster Manager VM-Instanz nicht vorhanden ist, erstellen Sie die Cluman VM mit einem Heat- oder Nova-Befehl, wie in diesem Beispiel gezeigt:

Erstellen Sie die Cluman-VM mit ESC. 

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/<original_xml_filename>

Das PCRF-Cluster kann mithilfe des vorherigen Befehls gestartet werden. Anschließend können die Cluster-Manager-Konfigurationen aus den Backups wiederhergestellt werden, die mit der Wiederherstellung "config_br.py" durchgeführt wurden, und Mongorestore aus dem Backup-Dump.

delete - nova boot --config-drive true --image "" --flavor "" --nic net-id=",v4-fixed-ip=" --nic net-id="network_id,v4-fixed-ip=ip_address" --block-device-mapping "/dev/vdb=2edbac5e-55de-4d4c-a427-ab24ebe66181:::0" --availability-zone "az-2:megh-os2-compute2.cisco.com" --security-groups cps_secgrp "cluman" 

・ Wenn die Cluster Manager VM-Instanz vorhanden ist, verwenden Sie einen nova rebuild-Befehl, um die Cluman VM-Instanz mit dem hochgeladenen Snapshot wie folgt neu zu erstellen:

nova rebuild <instance_name> <snapshot_image_name>

Beispiele:

nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

Schritt 5: Listen Sie alle Instanzen wie dargestellt auf, und überprüfen Sie, ob die neue Cluster Manager-Instanz erstellt wurde und ausgeführt wird:

nova list

Bild 3. Beispielausgabe

Stellen Sie die neuesten Patches auf dem System wieder her.

1.       Copy the patch files to cluster manager which were backed up in OSPD /home/stack/CPS_BACKUP 
2.       Login to the Cluster Manager as a root user.
3.       Untar the patch by executing this command:  tar -xvzf [patch name].tar.gz
4.       Edit /etc/broadhop/repositories and add this entry:  file:///$path_to_the plugin/[component name]  
5.       Run build_all.sh script to create updated QPS packages:  /var/qps/install/current/scripts/build_all.sh
6.       Shutdown all software components on the target VMs:  runonall.sh sudo monit stop all
7.       Make sure all software components are shutdown on target VMs:  statusall.sh

Hinweis: Für alle Softwarekomponenten muss der aktuelle Status "Not Monitored" (Nicht überwacht) lauten.

8.       Update the qns VMs with the new software using reinit.sh script:  /var/qps/install/current/scripts/upgrade/reinit.sh
9.       Restart all software components on the target VMs:  runonall.sh sudo monit start all
10.     Verify that the component is updated, run:  about.sh

Stellen Sie die Cronjobs wieder her.

1. Verschieben Sie die gesicherte Datei von OSPD in Cluman/Pcrfclient01.

2. Führen Sie den Befehl aus, um den Cronjob aus dem Backup zu aktivieren.

       

#crontab Cron-backup

3. Überprüfen Sie, ob die Cronjobs durch diesen Befehl aktiviert wurden.

     

#crontab -l 

      

Stellen Sie einzelne VMs im Cluster wieder her.

So stellen Sie pcrfclient01 VM erneut bereit: 

Schritt 1: Melden Sie sich bei der Cluster Manager-VM als Root-Benutzer an.

Schritt 2: Speichern Sie die UUID des SVN-Repositorys mit dem folgenden Befehl:

svn info http://pcrfclient02/repos | grep UUID

Der Befehl kann die UUID des Repositorys ausgeben.

Beispiel: Repository-UUID: ea50bbd2-5726-46b8-b807-10f4a7424f0e

Schritt 3: Importieren Sie die Konfigurationsdaten des Backup-Policy-Builders in den Cluster Manager, wie in diesem Beispiel gezeigt:

config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz

Hinweis: Viele Bereitstellungen führen einen Cron-Job aus, der Konfigurationsdaten regelmäßig sichert. Weitere Informationen finden Sie unter Subversion Repository Backup.

Schritt 4: Führen Sie den folgenden Befehl aus, um die VM-Archivdateien im Cluster Manager mit den neuesten Konfigurationen zu generieren:

/var/qps/install/current/scripts/build/build_svn.sh

  

Schritt 5: Führen Sie einen der folgenden Schritte aus, um das virtuelle System pcrfclient01 bereitzustellen:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Nova-Befehl, um das virtuelle System neu zu erstellen. Weitere Informationen finden Sie im CPS-Installationshandbuch für OpenStack.

Schritt 6: Stellen Sie die primäre/sekundäre SVN-Synchronisierung zwischen pcrfclient01 und pcrfclient02 wieder her, wobei pcrfclient01 als primärer Parameter verwendet wird. Führen Sie dazu diese Befehlsserie aus.

Wenn SVN bereits synchronisiert ist, geben Sie diese Befehle nicht aus.

Führen Sie diesen Befehl von pcrfclient02 aus, um zu überprüfen, ob SVN synchronisiert ist.

Wenn ein Wert zurückgegeben wird, ist SVN bereits synchronisiert:

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

Führen Sie diese Befehle von pcrfclient01 aus:

/bin/rm -fr /var/www/svn/repos
 
/usr/bin/svnadmin create /var/www/svn/repos
 
/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync
 
/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"
 
/etc/init.d/vm-init-client /
 
var/qps/bin/support/recover_svn_sync.sh

Schritt 7. Wenn pcrfclient01 auch die Vermittlungs-VM ist, führen Sie die folgenden Schritte aus:

a) Erstellen Sie die mongodb Start/Stopp-Skripte basierend auf der Systemkonfiguration. Nicht für alle Bereitstellungen sind alle diese Datenbanken konfiguriert.

Hinweis: Unter /etc/broadhop/mongoConfig.cfg erfahren Sie, welche Datenbanken eingerichtet werden müssen.

cd /var/qps/bin/support/mongo
 
build_set.sh --session --create-scripts
build_set.sh --admin --create-scripts
build_set.sh --spr --create-scripts
build_set.sh --balance --create-scripts
build_set.sh --audit --create-scripts
build_set.sh --report --create-scripts

b) Starten Sie den Mongo-Prozess:

/usr/bin/systemctl start sessionmgr-XXXXX

c) Warten Sie, bis der Arbiter gestartet ist, und führen Sie dann diagnostics.sh —get_replica_status aus, um die Integrität des Replikatsatzes zu überprüfen.

So stellen Sie pcrfclient02 VM erneut bereit:

 Schritt 1: Melden Sie sich bei der Cluster Manager-VM als Root-Benutzer an.

Schritt 2: Führen Sie den folgenden Befehl aus, um die VM-Archivdateien im Cluster Manager mit den neuesten Konfigurationen zu generieren:

/var/qps/install/current/scripts/build/build_svn.sh

Schritt 3: Führen Sie einen der folgenden Schritte aus, um das virtuelle System pcrfclient02 bereitzustellen:
Verwenden Sie in OpenStack die HEAT-Vorlage oder den Nova-Befehl, um das virtuelle System neu zu erstellen. Weitere Informationen finden Sie im CPS-Installationshandbuch für OpenStack.

Schritt 4: Sichern Sie die Shell auf pcrfclient01:

ssh pcrfclient01

Schritt 5: Führen Sie dieses Skript aus, um die SVN-Repos von pcrfclient01 wiederherzustellen:

/var/qps/bin/support/recover_svn_sync.sh

So stellen Sie eine SessionManager-VM erneut bereit:

Schritt 1: Melden Sie sich bei der Cluster Manager-VM als Root-Benutzer an.

Schritt 2: Führen Sie einen der folgenden Schritte aus, um die VM sessionmgr bereitzustellen und die ausgefallene oder beschädigte VM zu ersetzen:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Nova-Befehl, um das virtuelle System neu zu erstellen. Weitere Informationen finden Sie im CPS-Installationshandbuch für OpenStack.

Schritt 3: Erstellen Sie die mongodb Start/Stopp-Skripte basierend auf der Systemkonfiguration.

Nicht für alle Bereitstellungen sind alle diese Datenbanken konfiguriert. Unter /etc/broadhop/mongoConfig.cfg erfahren Sie, welche Datenbanken eingerichtet werden müssen.

cd /var/qps/bin/support/mongo

build_set.sh --session --create-scripts
build_set.sh --admin --create-scripts
build_set.sh --spr --create-scripts
build_set.sh --balance --create-scripts
build_set.sh --audit --create-scripts
build_set.sh --report --create-scripts

Schritt 4: Sichern Sie die Shell auf dem sessionmgr VM und starten Sie den mongo-Prozess:

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

Schritt 5: Warten Sie, bis die Mitglieder gestartet sind und die sekundären Mitglieder synchronisiert sind, und führen Sie dann diagnostics.sh —get_replica_status aus, um den Zustand der Datenbank zu überprüfen.

Schritt 6: Um die Session Manager-Datenbank wiederherzustellen, verwenden Sie einen der folgenden Beispielbefehle, je nachdem, ob die Sicherung mit der Option —mongo-all oder —mongo durchgeführt wurde:

• config_br.py -a import --mongo-all --users /mnt/backup/Name of backup 

or

• config_br.py -a import --mongo --users /mnt/backup/Name of backup

So stellen Sie die VM von Policy Director (Load Balancer) erneut bereit:

 Schritt 1: Melden Sie sich bei der Cluster Manager-VM als Root-Benutzer an.

Schritt 2: Führen Sie den folgenden Befehl aus, um die Konfigurationsdaten des Backup Policy Builder in den Cluster Manager zu importieren:

config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz

Schritt 3: Führen Sie den folgenden Befehl aus, um die VM-Archivdateien im Cluster Manager mit den neuesten Konfigurationen zu generieren:

/var/qps/install/current/scripts/build/build_svn.sh

Schritt 4: Führen Sie einen der folgenden Schritte aus, um das virtuelle System lb01 bereitzustellen:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Nova-Befehl, um das virtuelle System neu zu erstellen. Weitere Informationen finden Sie im CPS-Installationshandbuch für OpenStack.

So stellen Sie den Policy Server (QNS) VM erneut bereit:

 Schritt 1: Melden Sie sich bei der Cluster Manager-VM als Root-Benutzer an.

Schritt 2: Importieren Sie die Konfigurationsdaten des Backup-Policy-Builders in den Cluster Manager, wie in diesem Beispiel gezeigt:

config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz

Schritt 3: Führen Sie den folgenden Befehl aus, um die VM-Archivdateien im Cluster Manager mit den neuesten Konfigurationen zu generieren:

/var/qps/install/current/scripts/build/build_svn.sh

Schritt 4: Führen Sie einen der folgenden Schritte aus, um das virtuelle QNS-System bereitzustellen:
Verwenden Sie in OpenStack die HEAT-Vorlage oder den Nova-Befehl, um das virtuelle System neu zu erstellen. Weitere Informationen finden Sie im CPS-Installationshandbuch für OpenStack. 

Allgemeines Verfahren für die Datenbankwiederherstellung.

Schritt 1: Führen Sie den folgenden Befehl aus, um die Datenbank wiederherzustellen:

config_br.py –a import --mongo-all /mnt/backup/backup_$date.tar.gz where $date is the timestamp when the export was made.

Beispiele,

config_br.py –a import --mongo-all /mnt/backup/backup_27092016.tgz

Schritt 2: Melden Sie sich bei der Datenbank an, und überprüfen Sie, ob diese ausgeführt wird und ob darauf zugegriffen werden kann:

1. Melden Sie sich beim Sitzungsmanager an:

mongo --host sessionmgr01 --port $port

wobei "$port" die Portnummer der zu überprüfenden Datenbank ist. Beispiel: 27718 ist der Standard-Balance-Port.

2. Zeigen Sie die Datenbank an, indem Sie den folgenden Befehl ausführen:

show dbs

3. Schalten Sie die Mongo-Shell in die Datenbank, indem Sie diesen Befehl ausführen:

use $db

wobei "$db" ein im vorherigen Befehl angezeigter Datenbankname ist.

Der Befehl use schaltet die Mongo-Shell auf diese Datenbank.

Beispiele,

use balance_mgmt

4. Führen Sie den folgenden Befehl aus, um die Sammlungen anzuzeigen:

show collections

5. Führen Sie den folgenden Befehl aus, um die Anzahl der Datensätze in der Auflistung anzuzeigen:

db.$collection.count()
 
For example, db.account.count()

Im vorherigen Beispiel kann die Anzahl der Datensätze im Erfassungskonto in der Balance-Datenbank (balance_mgmt) angezeigt werden.

Subversion Repository Wiederherstellen.

Führen Sie den folgenden Befehl aus, um die Policy Builder-Konfigurationsdaten aus einem Backup wiederherzustellen:

config_br.py –a import --svn /mnt/backup/backup_$date.tgz where, $date is the date when the cron created the backup file. 

Grafana Dashboard wiederherstellen

Sie können das Grafana-Dashboard mit diesem Befehl wiederherstellen:

config_br.py -a import --grafanadb /mnt/backup/

Überprüfen der Wiederherstellung

Überprüfen Sie nach dem Wiederherstellen der Daten das funktionierende System, indem Sie den folgenden Befehl ausführen:

/var/qps/bin/diag/diagnostics.sh