Inhoud

Inleiding

Achtergrondinformatie

Afkortingen

Back-upprocedure

OSPF-back-up

ESC-back-up

CPS-back-up

Procedure terugzetten

OSPF-herstel

ESC-herstel

CPS-herstel

Inleiding

In dit document worden de stappen beschreven die vereist zijn voor het maken van back-ups en het herstellen van een virtuele machine (VM) in een Ultra-M-instelling waarbij CPS Virtual Network Functions (VPN’s) wordt opgeroepen.

Achtergrondinformatie

Ultra-M is een vooraf verpakte en gevalideerde gevirtualiseerde mobiele pakketoplossing die is ontworpen om de implementatie van VNFs te vereenvoudigen. Ultra-M oplossing bestaat uit deze typen virtuele machines (VM):

- Elastic Services Controller (ESC)

- Cisco Policy Suite (CPS)

De hoge architectuur van Ultra-M en de betrokken onderdelen zijn zoals in deze afbeelding te zien.

Opmerking: De Ultra M 5.1.x release wordt overwogen om de procedures in dit document te definiëren. Dit document is bedoeld voor het Cisco-personeel dat bekend is met Cisco Ultra-M platform.

Afkortingen

VNF

Virtuele netwerkfunctie

ESC

Elastic Service Controller

MOP

Procedure

OSD

Objectopslaglocaties

HDD

Station vaste schijf

SSD

Solid State Drive

VIM

Virtual-infrastructuurbeheer

VM

Virtuele machine

UUID

Universele unieke ID-versterker

Back-upprocedure

OSPF-back-up

1. Controleer de status van OpenStack en de lijst met knooppunten.

[stack@director ~]$ source stackrc

[stack@director ~]$ openstack stack list --nested

[stack@director ~]$ ironic node-list

[stack@director ~]$ nova list

2. Controleer of alle undercloud-services zich in geladen, actieve en actieve status bevinden vanuit het OSP-D-knooppunt.

[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. Controleer of u voldoende schijfruimte hebt voordat u het back-upproces uitvoert. Deze tarball zal naar verwachting ten minste 3,5 GB bedragen.

[stack@director ~]$df -h

4. Voer deze opdrachten uit als de basisgebruiker om back-ups te maken van de gegevens van de ondercloud-knooppunt naar een bestand dat undercloud-back-up heet-[timestamp].tar.gz en breng deze over naar de reserveserver.

[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-back-up

1. ESC zorgt op zijn beurt voor VPN-netwerkfunctie (Virtual Network Function, VPN) door in te spelen op VIM.

2. ESC heeft 1:1 redundantie in Ultra-M oplossing. Er zijn 2 ESC-VM's ingezet en ondersteunen één storing in Ultra-M, d.w.z. herstel van het systeem als er één storing in het systeem optreedt.

Opmerking: Als er meer dan één storing is, wordt deze niet ondersteund en kan er een hergebruik van het systeem nodig zijn.

Back-uplijn van het ESC:

- Configuratie uitvoeren

- ConfD CDB DB

- ESC-vastlegging

- Syslog-configuratie

3. De frequentie van ESC DB-back-up is lastig en moet zorgvuldig worden behandeld als ESC de verschillende staatsmachines controleert en onderhoudt voor de verschillende VPN-VM's die worden ingezet. Het wordt aanbevolen deze back-ups te maken na volgende activiteiten in gegeven VNF/POD/Site

4. Controleer of ESC goed is met behulp van health.sh script.

[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. Neem de back-up van de configuratie uitvoeren en breng het bestand over naar de reserveserver.

[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

Reserve ESC-database

1. Meld u aan bij ESC VM en voer de volgende opdracht uit voordat u de back-up neemt.

[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. Controleer de ESC-modus en controleer of deze in de onderhoudsmodus staat.

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

3. Back-up database met back-up van gegevensbestanden die beschikbaar is in ESC.

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

4. Stel ESC weer in op de bewerkingsmodus en bevestig de modus.

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

[root@esc scripts]# escadm op_mode show

5. Navigeer naar de map scripts en verzamel de logbestanden.

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

sudo ./collect_esc_log.sh

6. Om een momentopname van het ESC te creëren, moet eerst het ESC worden gesloten.

shutdown -r now

7. Vanaf het ruimteschip wordt een foto-snapshot gemaakt

nova image-create --poll esc1 esc_snapshot_27aug2018

8. Controleer of de momentopname is gemaakt

openstack image list | grep esc_snapshot_27aug2018

9. START ESC vanaf OSPD

nova start esc1

10. Herhaal dezelfde procedure op de stand-by ESC VM en breng de logbestanden over naar de reserveserver

11. Verzamel back-up van de configuratie van het systeem op zowel het ESC VMS als breng deze over naar de reserveserver

[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-back-up

1. Maak een back-up van CPS Cluster Manager

Gebruik deze opdracht om de nova-gevallen te bekijken en de naam van de VM-instantie van de clustermanager op te merken:

nova list

Stop de Cluman met ESC

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

Stap 2. Controleer Cluster Manager in de SHUTOFF-staat.

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

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

Stap 3. Maak een nieuwe snapshot-afbeelding zoals in de volgende opdracht:

nova image-create --poll

Opmerking: Zorg ervoor dat u voldoende schijfruimte hebt voor de snapshot.

Belangrijk - Indien VM na het creëren van een snapshot onbereikbaar wordt, controleert u de status van VM met de opdracht nova list. Als de VM in de "SHUTOFF"-status staat, moet u de VM handmatig starten.

Stap 4. Bekijk de afbeeldingslijst met de volgende opdracht: Nieuwe lijst van afbeeldingen Afbeelding 1: Uitvoer van voorbeelden

Stap 5. Wanneer een snapshot is gemaakt, wordt de snapshot-afbeelding opgeslagen in OpenStack Glance. Om de snapshot in een externe gegevenswinkel op te slaan, kunt u de snapshot downloaden en het bestand in OSPF naar ( /home/stack/CPS_BACKUP) overbrengen

U kunt de afbeelding downloaden met de volgende opdracht in OpenStack:

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

Stap 6. Lijst van de gedownload afbeeldingen in de volgende opdracht:

ls —ltr *snapshot*

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

Stap 7. Bewaar de momentopname van de Cluster Manager VM om in de toekomst te herstellen.

2. back-up van de configuratie en de database.

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.

Controleer vanaf het tabblad Crontab -l als er een andere back-up nodig is

Alle back-ups overbrengen naar het OSPD-adres/startpunt/stack/CPS_BACKUP

3. Back-upbestand van ESC Master

/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

Overschakelen van het bestand in OSPF-home/stack/CPS_BACKUP

4. Back-up van de tabbladen -l

Maak een tekstbestand met crontab -l en vervang het op externe locatie (in OSPF/home/stack/CPS_BACKUP)

5. Maak een back-up van de routebestanden van de LB- en PCRF-client

Collect and scp the below conifgurations from both LBs and Pcrfclients

route -n /etc/sysconfig/network-script/route-*

Procedure terugzetten

OSPF-herstel

De OPDD-herstelprocedure wordt uitgevoerd op basis van de volgende veronderstellingen

1. Een OSPF-back-up is beschikbaar op een oude OSPD-server.

2. Het OSPD-herstel zal worden uitgevoerd op de nieuwe server, die de vervanging is van de oude OSPD-server in het systeem. .

ESC-herstel

1. ESC VM kan worden hersteld indien de VM in een fout verkeert of wanneer de stilstand hard wordt heropgestart om de geïmpacte VM op te halen. Uitvoeren van deze stappen om ESC te herstellen.

2. Identificeer de VM die zich in de staat FOUT of shutdown bevindt, zodra de ESC VM herstart. In dit voorbeeld herstart u de automatische test-vnfm1-ESC-0.

[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. Indien ESC VM wordt verwijderd en opnieuw moet worden opgevoed. Volg onderstaande opeenvolging van stappen

[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. Als ESC VM niet kan worden hersteld en de database moet worden hersteld, moet u de database van de eerder opgenomen back-up herstellen.

5. Voor het herstellen van de ESC-databank moeten we ervoor zorgen dat de ESC-dienst wordt stopgezet voordat de databank wordt hersteld; Voor ESC HA, eerst uitvoeren in secundaire VM en daarna de primaire VM.

# service keepalived stop

6. Controleer ESC-servicestatus en zorg ervoor dat alles wordt gestopt in zowel primaire als secundaire VM's voor HA.

# escadm status

7. Voer het script uit om de database te herstellen. Als onderdeel van het herstel van de DB naar de nieuwe ESC-instantie, zal het gereedschap ook een van de gevallen promoten die een primaire ESC zijn, de DB-map op het drbd-apparaat zetten en de PostgreSQL-database starten.

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

8. Start ESC-service opnieuw om de database te herstellen. Voor HA-uitvoering in beide VM's moet de onderhoudsservice opnieuw worden gestart.

# service keepalived start

9. Zodra de VM met succes is hersteld en operationeel is; ervoor zorgen dat alle syslogspecifieke configuratie wordt hersteld van de vorige succesvolle bekende back-up. ervoor te zorgen dat het in alle ESC-VM's wordt hersteld.

[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. Indien het ESC moet worden herbouwd vanaf een Ospd-snapshot, gebruik deze opdracht met behulp van een momentopname die tijdens de back-up is gemaakt.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

11. Controleer de status van het ESC na voltooiing van de wederopbouw

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

12. Controleer ESC-status met onderstaande opdracht

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

Als ESC er niet in slaagt om VM te starten

- In sommige gevallen zal ESC er niet in slagen de VM te starten vanwege een onverwachte toestand. Een omschakelingsmechanisme is het uitvoeren van een ESC - omschakeling door herstart van het ESC. De ESC-omschakeling zal ongeveer een minuut duren.  Execute health.sh op de nieuwe Master ESC om te controleren of het in orde is. Wanneer het ESC Meester wordt, kan ESC de VM-status vastleggen en de VM starten. Aangezien deze bewerking is gepland, moet u 5-7 minuten wachten voordat deze is voltooid.

- U kunt /var/log/esc/yangesc.log en /var/log/esc/escmanager.log controleren. Indien VM na 5-7 minuten niet wordt teruggewonnen, moet de gebruiker de geïmpliceerde VM(en) handmatig gaan herstellen.

- zodra de VM met succes is hersteld en actief is; ervoor zorgen dat alle syslogspecifieke configuratie wordt hersteld van de vorige succesvolle bekende back-up. Zorg ervoor dat deze in alle ESC-VM's wordt hersteld

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-herstel

Cluster Manager VM in OpenStack herstellen

Stap 1 Kopieer de VM-snapshot van de clustermanager naar de controller-blade zoals in de volgende opdracht wordt getoond:

ls —ltr *snapshot*

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

Stap 2 Upload de snapshot-afbeelding naar OpenStack vanaf Datastore:

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

Stap 3 Controleer of de snapshot met een Nova opdracht is geüpload zoals in het volgende voorbeeld:

nova image-list

Afbeelding 2: Uitvoer van voorbeelden

Stap 4 Afhankelijk van de vraag of de clustermanager VM al dan niet bestaat, kunt u ervoor kiezen de kolom te maken of de groep te herbouwen:

・ Indien de Cluster Manager VM-instantie niet bestaat, creëer dan de Cluman-VM met een verwarmingsopdracht of een opdracht Nova zoals in het volgende voorbeeld wordt getoond:

Maak de Cluman VM met 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>

Het PCRF-cluster zal met de hulp van boven commando worden voortgebracht, en dan de clustermanager configuraties herstellen van de back-ups die worden genomen met het terugzetten van configuratie_br.py, mongorestore van dumpen in back-up

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"

・ Als de Cluster Manager VM-instantie bestaat, gebruikt u een nova-herbouwopdracht om de Cluman VM-instantie te herbouwen met de geüploade snapshot zoals wordt getoond:

nova rebuild <instance_name> <snapshot_image_name>

Bijvoorbeeld:

nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

Stap 5 Lijst alle instanties zoals getoond en controleer of de nieuwe instantie van de clustermanager is gemaakt en actief is:

nova list

Afbeelding 3. Uitvoer van voorbeeld

De laatste patches op het systeem herstellen

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

Opmerking: De softwarecomponenten moeten alle tonen Niet Gemonitord als de huidige status.

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

De tegenhangers herstellen

1. Verplaats het back-upbestand van OSPD naar Cluman/Pcrfclient01.

2. Start de opdracht om de taak te activeren vanaf de back-up.

#crontab Cron-backup

3. Controleer of de klompjes met de onderstaande opdracht zijn geactiveerd.

#crontab -l

Individuele VM's in het cluster herstellen

Om de pc-client01 VM opnieuw in te zetten:

Stap 1 Meld u aan bij de Cluster Manager VM als de basisgebruiker.

Stap 2 Let op de UID van de SVN-opslagplaats met de volgende opdracht:

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

De opdracht voert de UUID uit van de opslagplaats.

Bijvoorbeeld: UID als bewaarder: e50bbd2-5726-46b8-b807-10f4a7424f0e

Stap 3 Importeer de configuratiegegevens van de backup-beleidsbouwer in Cluster Manager, zoals in het volgende voorbeeld:

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

Opmerking: Vele implementaties voeren een kroontaak uit die regelmatig een back-up maakt van configuratiegegevens.Zie Subversie Repository Backup, voor meer informatie.

Stap 4 Om de VM-archiefbestanden op de Cluster Manager te genereren met behulp van de nieuwste configuraties, voert u de volgende opdracht uit:

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

Stap 5 Voer een van de volgende handelingen uit om de pc-client01 VM te implementeren:

Gebruik in OpenStack de HEAT-sjabloon of de Nova-opdracht om de VM opnieuw te maken. Zie de installatiehandleiding van CPS voor OpenStack voor meer informatie.

Stap 6 Herstel de synchrone/synchrone van SVN tussen de PCclient01 en PPP02 met de pc01 als de master door de volgende reeks opdrachten uit te voeren.

Als SVN reeds gesynchroniseerd is, geef deze opdrachten niet uit.

Om te controleren of SVN in sync is, voert u de volgende opdracht uit van client02.

Als een waarde wordt teruggegeven, is SVN al in sync:

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

Voer de volgende opdrachten uit vanaf een pc-client01:

/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

Stap 7 Indien cliënt01 ook de scheidsrechter VM is, dan de volgende stappen uitvoeren:

a) Maak de mongodb start/stop scripts op basis van de systeemconfiguratie. Niet alle implementaties hebben al deze databases geconfigureerd.

Opmerking: Raadpleeg /etc/broadhop/mongoConfig.cfg om te bepalen welke databases moeten worden ingesteld.

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) Start het mongoproces:

/usr/bin/systemctl start sessionmgr-XXXXX

c) Wacht tot de arbiter start, en voer vervolgens diagnostiek.sh —get_replica_status uit om de gezondheid van de replica set te controleren.

Om de pc02 VM opnieuw in te zetten:

Stap 1 Meld u aan bij de Cluster Manager VM als basisgebruiker

Stap 2 Om de VM-archiefbestanden op de Cluster Manager te genereren met behulp van de nieuwste configuraties, voert u de volgende opdracht uit:

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

Stap 3 Voer een van de volgende handelingen uit om de pc-client02 VM te implementeren:

Gebruik in OpenStack de HEAT-sjabloon of de Nova-opdracht om de VM opnieuw te maken. Zie de installatiehandleiding van CPS voor OpenStack voor meer informatie.

Stap 4 Secure shell aan de opdrachtgever01:

ssh pcrfclient01

Stap 5 Start het volgende script om de SVN repos van PC01 te herstellen:

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

Om een sessionhouder van VM te herschikken:

Stap 1 Meld u aan bij de Cluster Manager VM als basisgebruiker

Stap 2 Voer een van de volgende handelingen uit om de sessionhouder VM in te zetten en de mislukte of corrupte VM te vervangen:

Gebruik in OpenStack de HEAT-sjabloon of de Nova-opdracht om de VM opnieuw te maken. Zie CPS Installatie-gids voor OpenStack voor meer informatie

Stap 3 Maak de begin/stop scripts van de mongodb op basis van de systeemconfiguratie.

Niet alle implementaties hebben al deze databases geconfigureerd. Raadpleeg /etc/broadhop/mongoConfig.cfg om te bepalen welke databases moeten worden opgezet

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

Stap 4 Bevestig de schelp aan de sessionhouder VM en start het mongoproces:

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

Stap 5 Wacht tot de leden beginnen en voor de secundaire leden synchroniseren, en voer dan diagnostiek.sh —get_replica_status uit om de gezondheid van de database te controleren.

Stap 6 Om de Session Manager-database te herstellen, gebruikt u een van de volgende voorbeeldopdrachten, afhankelijk van of de back-up is uitgevoerd met —mongo-all of —mongo-optie:

• 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

U herstelt de Policy Director (taakverdeling) VM:

Stap 1 Meld u aan bij de Cluster Manager VM als de basisgebruiker.

Stap 2 Om de configuratiegegevens van de backup-beleidsbouwer in de Cluster Manager in te voeren, voert u de volgende opdracht uit:

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

Stap 3 Voor het genereren van de VM-archiefbestanden in de Cluster Manager met behulp van de nieuwste configuraties, voert u de volgende opdracht uit:

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

Stap 4 Voer een van de volgende handelingen uit om lb01 VM te implementeren:

Gebruik in OpenStack de HEAT-sjabloon of de Nova-opdracht om de VM opnieuw te maken. Zie de installatiehandleiding van CPS voor OpenStack voor meer informatie.

Zo herstelt u de Policy Server (QNS) VM:

Stap 1 Meld u aan bij de Cluster Manager VM als de basisgebruiker.

Stap 2 Importeer de configuratiegegevens van de backup-beleidsbouwer in Cluster Manager, zoals in het volgende voorbeeld:

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

Stap 3 Voor het genereren van de VM-archiefbestanden in de Cluster Manager met behulp van de nieuwste configuraties, voert u de volgende opdracht uit:

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

Stap 4 Voer een van de volgende handelingen uit om de qns VM te implementeren:

Gebruik in OpenStack de HEAT-sjabloon of de Nova-opdracht om de VM opnieuw te maken. Zie CPS Installatie-gids voor OpenStack voor meer informatie

Algemene procedure voor terugzetten van databases

Stap 1 Voer de volgende opdracht uit om de database te herstellen:

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

Bijvoorbeeld:

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

Stap 2 Meld u aan bij de database en controleer of deze actief is en toegankelijk is:

1. Inloggen op sessiemanager:

mongo --host sessionmgr01 --port $port

waar $port het poortnummer van de te controleren database is. Bijvoorbeeld, 27718 is de standaardbalanspoort.

2. Geef de database weer door de volgende opdracht uit te voeren:

show dbs

3. Schakel de mongoshell in de database door de volgende opdracht uit te voeren:

use $db

waar $db een database naam is die in de vorige opdracht wordt weergegeven.

De opdracht "gebruik" verandert de mongoshell in die database.

Bijvoorbeeld:

use balance_mgmt

4. Om de collecties weer te geven, voert u de volgende opdracht uit:

show collections

5. Om het aantal records in de verzameling weer te geven, voert u de volgende opdracht uit:

db.$collection.count()

For example, db.account.count()

Bovenstaand voorbeeld toont het aantal records in de "verzamelrekening" in de balansdatabase (balance_mgmt).

Terugzetten van omgekeerde pad

Als u de Gegevens van de Configuratie van de Leider van een steun wilt herstellen, voert u de volgende opdracht uit:

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 herstellen

U kunt het Grafana-dashboard herstellen met de volgende opdracht:

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

De terugzetten valideren

Controleer het werksysteem na het herstellen van de gegevens door de volgende opdracht uit te voeren:

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