Backup und Recovery - vollständige Cluster-Wiederherstellung - CPS

Einführung

Dieses Dokument beschreibt die erforderlichen Schritte zur Wiederherstellung eines gesamten CPS-Clusters in einer Ultra-M-Konfiguration, die CPS 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:

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

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 in Betracht gezogen.

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
UUID	Universell eindeutige IDentifier

Annahme

Bei diesem Verfahren wird davon ausgegangen, dass nur das CPS-Cluster wiederhergestellt werden soll und alle Komponenten auf der OpenStack-Ebene, einschließlich des ESC, betriebsbereit sind 

Wiederherstellungsverfahren

   

Wenn ESC nicht zum Starten von VM führt:

• In einigen Fällen kann ESC die VM aufgrund eines unerwarteten Zustands nicht 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. 

• 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, 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 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

CPS-Wiederherstellung

1. Erstellen einer Sicherung des CPS Cluster Manager

Schritt 1: Verwenden Sie den folgenden Befehl, um die nova-Instanzen anzuzeigen und den Namen der Cluster Manager VM-Instanz zu beachten:

nova list

Stoppen Sie den Cluman aus dem ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP 
       
       

Schritt 2: Überprüfen Sie Cluster Manager im SHUTOFF-Status.

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 gezeigt:

nova image-create --poll 
       
        
         
       

Hinweis:Stellen Sie sicher, dass Sie über genügend Speicherplatz für den Snapshot verfügen.

Wichtig - Falls VM nach der Snapshot-Erstellung nicht erreichbar ist, überprüfen Sie den Status von VM mithilfe des nova-Listenbefehls. Wenn der Status "SHUTOFF" lautet, müssen Sie das virtuelle System manuell starten.

Schritt 4: Zeigen Sie die Bildliste mit dem folgenden Befehl an: nova-Bildliste 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 an ( /home/stack/CPS_BACKUP )

Um das Bild 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: Führen Sie die heruntergeladenen Bilder wie im folgenden Befehl gezeigt 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 des 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 auf der Crontab -l, ob eine andere Sicherung erforderlich ist.

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

3. Sicherungsdatei von ESC Master.

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

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

4. Sichern von Crontab-l-Einträgen

Erstellen Sie eine TXT-Datei mit crontab -l und ftp it to remote location ( in OSPD /home/stack/CPS_BACKUP ).

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

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

Stellen Sie Cluster Manager VM in OpenStack wieder her

Schritt 1: Kopieren Sie den Snapshot des Cluster Manager VM auf den Controller-Blade, wie in folgendem Befehl gezeigt:

ls —ltr *snapshot*

Beispielausgabe: -rw-r—r— 1 Root Root 10429595648 Aug 16 02:39 Snapshot.raw

Schritt 2: Laden Sie das Snapshot-Image in OpenStack aus dem Datenspeicher 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 wird, wie in diesem Beispiel gezeigt:

nova image-list

Abbildung 2: Beispielausgabe

Schritt 4: Je nachdem, ob die 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 dem Befehl Heat oder Nova, wie im folgenden Beispiel gezeigt:

Erstellen einer 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/
       
       

Das PCRF-Cluster wird mithilfe des obigen Befehls ausgelöst und stellt dann die Cluster-Manager-Konfigurationen aus den Backups wieder her, die mit config_br.py-Wiederherstellung durchgeführt wurden. Die Mongorestore aus dem in der Sicherung übernommenen Dump erfolgen mongorestore.

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 Instanz der Cluster Manager VM vorhanden ist, verwenden Sie einen nova rebuild-Befehl, um die Cluman VM-Instanz mit dem hochgeladenen Snapshot wie folgt neu zu erstellen:

nova rebuild 
       
        
         
       

Beispiel: nova rebuild cps-cluman-5f3tujqvbi67 cluman_Snapshot

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

Nova-Liste

Abbildung 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 the following command:  tar -xvzf [patch name].tar.gz
4.       Edit /etc/broadhop/repositories and add the following 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: Die Softwarekomponenten müssen als aktuellen Status "Nicht überwacht" anzeigen (8). Aktualisieren Sie die qns VMs mit der neuen Software mithilfe des Skripts reinit.sh: /var/qps/install/current/scripts/upgrade/reinit.sh 9. Starten Sie alle Softwarekomponenten auf den Ziel-VMs neu: runonall.sh sudo monit start all 10. Überprüfen Sie, ob die Komponente aktualisiert ist, führen Sie Folgendes aus: about.sh

Wiederherstellen von Cronjobs

1. Übertragen der gesicherten Datei vom OSPD auf den Cluman/Crfclient01 
   
   
2. Führen Sie den Befehl aus, um den Cronjob von der Sicherung aus zu aktivieren
   #Crontab CronBackup
   
3. Mit dem folgenden Befehl überprüfen, ob die Cronjobs aktiviert wurden
           #crontab -l       

Wiederherstellen einzelner VMs im Cluster

So stellen Sie die VM pcrfclient01 erneut bereit

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

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

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

Der Befehl gibt die UUID des Repositorys aus.

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

Schritt 3: Importieren Sie die Backup Policy Builder-Konfigurationsdaten auf dem Cluster Manager, wie im folgenden 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-Auftrag aus, der Konfigurationsdaten regelmäßig sichert.Weitere Einzelheiten finden Sie unter Subversion Repository Backup. 

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

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

Schritt 5: Um die VM pcrfclient01 bereitzustellen, führen Sie einen der folgenden Schritte aus:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Befehl Nova, um die VM neu zu erstellen. Weitere Informationen finden Sie in der CPS-Installationsanleitung für OpenStack.

Schritt 6: Stellen Sie die SVN-Master-/Slave-Synchronisierung zwischen dem pcrfclient01 und pcrfclient02 wieder her, wobei pcrfclient01 als Master diese Befehle ausführt.

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

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

Wenn ein Wert zurückgegeben wird, ist das 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 beliebige VM ist, führen Sie die folgenden Schritte aus:

1. Erstellen Sie die mongodb start/stop Skripts auf Basis der Systemkonfiguration. Nicht in allen Bereitstellungen sind alle Datenbanken konfiguriert.

Hinweis: Unter /etc/broadhop/mongoConfig.cfg können Sie ermitteln, 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

2. Starten des Mongo-Prozesses:

/usr/bin/systemctl start sessionmgr-XXXXX

3. Warten Sie, bis der Schiedsrichter startet, und führen Sie dann diagnostics.sh —get_replica_status aus, um den Zustand des Replikationssatzes zu überprüfen.

So stellen Sie die VM pcrfclient02 erneut bereit

Schritt 1: Melden Sie sich beim 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 erstellen:

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

Schritt 3 Führen Sie einen der folgenden Schritte aus, um die VM pcrfclient02 bereitzustellen: 

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Befehl Nova, um die VM neu zu erstellen. Weitere Informationen finden Sie in der CPS-Installationsanleitung für OpenStack.

Schritt 4 Sichern Sie die Shell zum 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 sitzungsbasierte VM wieder bereit

Schritt 1: Melden Sie sich beim Cluster Manager VM als Stammbenutzer an.

Schritt 2: So stellen Sie die sessionmgr VM bereit und ersetzen die ausgefallene oder beschädigte VM:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Befehl Nova, um die VM neu zu erstellen. Weitere Informationen finden Sie in der CPS-Installationsanleitung für OpenStack.

Schritt 3: Erstellen Sie die mongodb start/stop Skripts auf Basis der Systemkonfiguration.

Nicht in allen Bereitstellungen sind alle Datenbanken konfiguriert. Unter /etc/broadhop/mongoConfig.cfg können Sie ermitteln, 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 die sessionmgr VM, und starten Sie den Mongo-Prozess:

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

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

Schritt 6: Verwenden Sie zum Wiederherstellen der Session Manager-Datenbank 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 den Policy Director (Load Balancer) VM neu bereit

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

Schritt 2: Führen Sie den folgenden Befehl aus, um die Konfigurationsdaten für den Backup Policy Builder im 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 erstellen:

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

Schritt 4: Führen Sie zum Bereitstellen des lb01 VM eine der folgenden Aktionen aus:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Befehl Nova, um die VM neu zu erstellen. Weitere Informationen finden Sie in der CPS-Installationsanleitung für OpenStack.

So stellen Sie die Policy Server (QNS) VM wieder bereit

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

Schritt 2: Importieren Sie die Backup Policy Builder-Konfigurationsdaten auf dem 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 erstellen:

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

Schritt 4 Führen Sie zum Bereitstellen der qns VM einen der folgenden Schritte aus:

Verwenden Sie in OpenStack die HEAT-Vorlage oder den Befehl Nova, um die VM neu zu erstellen. Weitere Informationen finden Sie in der CPS-Installationsanleitung für OpenStack. 

Allgemeine Vorgehensweise für die Datenbankwiederherstellung

Schritt 1: Führen Sie diesen 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.

Beispiel:

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 verfügbar ist:

1. Melden Sie sich beim Sitzungsmanager an:

mongo --host sessionmgr01 --port $port

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

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

show dbs

3. Wechseln Sie die Mongo-Shell zur Datenbank, indem Sie den folgenden Befehl ausführen:

use $db

wobei $db ein im vorherigen Befehl angezeigter Datenbankname ist.

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

Beispiel:

use balance_mgmt

4. Um die Auflistungen anzuzeigen, führen Sie den folgenden Befehl aus:

show collections

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

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

Im obigen Beispiel wird die Anzahl der Datensätze in der Sammelanschlussdatenbank (balance_mgmt) angezeigt.

Subsystemwiederherstellung

Führen Sie den folgenden Befehl aus, um die Policy Builder-Konfigurationsdaten aus einer Sicherung 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 dem folgenden Befehl wiederherstellen:

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

Überprüfen der Wiederherstellung

Nachdem Sie die Daten wiederhergestellt haben, überprüfen Sie das funktionierende System mithilfe des folgenden Befehls:

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

Wenn ESC zum Starten von VM fehlschlägt

• In einigen Fällen kann ESC die VM aufgrund eines unerwarteten Zustands nicht 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.  

• 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, muss der Benutzer die manuelle Wiederherstellung der betroffenen VM(s) durchführen.
  
  
• Wenn der Cluster vollständig nicht verfügbar ist und nur ESC erreichbar ist, muss die Wiederherstellung aus den letzten Sicherungen durchgeführt werden, die aus den geplanten Backups durch Cronjobs entnommen werden. Das Verfahren für die Beitreibung bleibt das gleiche wie in der Pariser Vereinbarung.