Contenu

Introduction

Informations générales

Abréviations

Procédure de sauvegarde

Sauvegarde OSPD

Sauvegarde ESC

Sauvegarde CPS

Procédure de restauration

Récupération OSPD

Récupération ESC

Récupération CPS

Introduction

Ce document décrit les étapes requises pour sauvegarder et restaurer une machine virtuelle (VM) dans une configuration Ultra-M qui héberge les fonctions de réseau virtuel CPS (VNF).

Informations générales

Ultra-M est une solution de coeur de réseau de paquets mobiles virtualisés prépackagée et validée conçue pour simplifier le déploiement des VNF. La solution Ultra-M se compose des types de machines virtuelles suivants :

- Contrôleur de services élastiques (ESC)

- Cisco Policy Suite (CPS)

L'architecture de haut niveau d'Ultra-M et les composants concernés sont illustrés dans cette image.

Note: La version Ultra M 5.1.x est prise en compte afin de définir les procédures de ce document. Ce document est destiné au personnel Cisco qui connaît la plate-forme Cisco Ultra-M.

Abréviations

VNF

Fonction de réseau virtuel

Échap

Contrôleur de service flexible

MOP

Méthode de procédure

OSD

Disques de stockage d'objets

HDD

Disque dur

SSD

Disque dur SSD

VIM

Gestionnaire d'infrastructure virtuelle

VM

Machine virtuelle

UUID

Identificateur unique

Procédure de sauvegarde

Sauvegarde OSPD

1. Vérifiez l'état de la pile OpenStack et la liste des noeuds.

[stack@director ~]$ source stackrc

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

[stack@director ~]$ ironic node-list

[stack@director ~]$ nova list

2. Vérifiez si tous les services sous-cloud sont en état de chargement, d'activité et d'exécution à partir du noeud OSP-D.

[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. Vérifiez que l'espace disque disponible est suffisant avant d'effectuer le processus de sauvegarde. Ce tarball devrait être d'au moins 3,5 Go.

[stack@director ~]$df -h

4. Exécutez ces commandes en tant qu'utilisateur racine pour sauvegarder les données du noeud de sous-cloud vers un fichier nommé undercloud-backup-[timestamp].tar.gz et transférez-le sur le serveur de sauvegarde.

[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

Sauvegarde ESC

1. L'ESC, à son tour, affiche Virtual Network Function (VNF) en interagissant avec VIM.

2. La redondance 1:1 est présente dans la solution Ultra-M. Deux machines virtuelles ESC sont déployées et prennent en charge une seule panne dans Ultra-M, c'est-à-dire récupérer le système en cas de panne unique dans le système.

Note: S'il y a plus d'une panne, elle n'est pas prise en charge et peut nécessiter un redéploiement du système.

Détails de la sauvegarde ESC :

- La configuration d'exécution

- Base de données CDB ConfD

- Journaux ESC

- Configuration Syslog

3. La fréquence de sauvegarde de la base de données ESC est délicate et doit être manipulée avec soin lorsque l'ESC surveille et gère les différents ordinateurs d'état pour les différentes machines virtuelles VNF déployées. Il est conseillé que ces sauvegardes soient effectuées après les activités suivantes dans un VNF/POD/Site donné

4. Vérifiez que l'état de l'ESC est correct à l'aide du script health.sh.

[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. Effectuez la sauvegarde de la configuration en cours et transférez le fichier sur le serveur de sauvegarde.

[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

Base de données ESC de sauvegarde

1. Connectez-vous à la machine virtuelle ESC et exécutez la commande suivante avant d'effectuer la sauvegarde.

[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. Vérifiez le mode ESC et assurez-vous qu'il est en mode maintenance.

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

3. Sauvegarder la base de données à l'aide de l'outil de restauration de sauvegarde de base de données disponible dans ESC.

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

4. Réglez l'ESC de nouveau sur Mode de fonctionnement et confirmez le mode.

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

[root@esc scripts]# escadm op_mode show

5. Accédez au répertoire des scripts et collectez les journaux.

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

sudo ./collect_esc_log.sh

6. Pour créer un instantané de l'ESC, arrêtez d'abord l'ESC.

shutdown -r now

7. À partir d'OSPD, créez un instantané d'image

nova image-create --poll esc1 esc_snapshot_27aug2018

8. Vérifier la création de l'instantané

openstack image list | grep esc_snapshot_27aug2018

9. Démarrer l'ESC à partir d'OSPD

nova start esc1

10. Répétez la même procédure sur la machine virtuelle ESC de secours et transférez les journaux sur le serveur de sauvegarde

11. Collecte de la sauvegarde de configuration Syslog sur les deux systèmes ESC VMS et transfert vers le serveur de sauvegarde

[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

Sauvegarde CPS

1. Créer une sauvegarde de CPS Cluster-Manager

Utilisez cette commande afin d'afficher les instances nova et notez le nom de l'instance de machine virtuelle du gestionnaire de cluster :

nova list

Arrêter le clone de l'ESC

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

Étape 2. Vérifiez le Gestionnaire de cluster dans l'état SHUTOFF.

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

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

Étape 3. Créez une image de capture instantanée nova comme indiqué dans la commande suivante :

nova image-create --poll

Note: Assurez-vous que vous disposez de suffisamment d'espace disque pour l'instantané.

Important : si la machine virtuelle devient inaccessible après la création d'un instantané, vérifiez l'état de la machine virtuelle à l'aide de la commande nova list. S'il est à l'état SHUTOFF, vous devez démarrer la machine virtuelle manuellement.

Étape 4. Affichez la liste des images à l'aide de la commande suivante : nouvelle image-liste Figure 1 : Exemple de rapport

Étape 5. Lorsqu'un instantané est créé, l'image du snapshot est stockée dans OpenStack Glance. Pour stocker l'instantané dans un magasin de données distant, téléchargez l'instantané et transférez le fichier dans OSPD vers ( /home/stack/CPS_BACKUP )

Pour télécharger l'image, utilisez la commande suivante dans OpenStack :

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

Étape 6. Répertoriez les images téléchargées comme indiqué dans la commande suivante :

ls —ltr *snapshot*

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

Étape 7. Stocker l'instantané de la machine virtuelle Cluster Manager à restaurer ultérieurement.

2. Sauvegarder la configuration et la base de données.

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.

Vérifiez à partir de crontab -l si une autre sauvegarde est nécessaire

Transférer toutes les sauvegardes vers OSPD /home/stack/CPS_BACKUP

3. Fichier de sauvegarde du journal à partir du maître ESC

/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

Transférer le fichier dans OSPD /home/stack/CPS_BACKUP

4. Sauvegarder les entrées crontab -l

Créez un fichier texte avec crontab -l et ftp vers un emplacement distant ( dans OSPD /home/stack/CPS_BACKUP )

5. Sauvegarde des fichiers de route à partir du client LB et PCRF

Collect and scp the below conifgurations from both LBs and Pcrfclients

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

Procédure de restauration

Récupération OSPD

La procédure de récupération OSPD est exécutée sur la base des hypothèses suivantes :

1. La sauvegarde OSPD est disponible à partir d'un ancien serveur OSPD.

2. La récupération OSPD sera effectuée sur le nouveau serveur qui remplace l'ancien serveur OSPD dans le système. .

Récupération ESC

1. La machine virtuelle ESC peut être restaurée si la machine virtuelle est en état d'erreur ou d'arrêt, redémarrez définitivement la machine virtuelle affectée. Exécutez ces étapes pour récupérer ESC.

2. Identifiez la machine virtuelle qui est en état d'ERREUR ou d'arrêt, une fois identifiée comme redémarrage matériel de la machine virtuelle ESC. Dans cet exemple, vous redémarrez auto-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. Si la VM ESC est supprimée et doit être réactivée. Suivre la séquence d'étapes ci-dessous

[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. Si la machine virtuelle ESC est irrécupérable et nécessite la restauration de la base de données, restaurez la base de données à partir de la sauvegarde précédemment prise.

5. Pour restaurer la base de données ESC, nous devons nous assurer que le service esc est arrêté avant de restaurer la base de données ; Pour la HA ESC, exécutez d'abord dans la VM secondaire, puis dans la VM principale.

# service keepalived stop

6. Vérifiez l'état du service ESC et assurez-vous que tout est arrêté dans les machines virtuelles principales et secondaires pour la haute disponibilité.

# escadm status

7. Exécutez le script pour restaurer la base de données. Dans le cadre de la restauration de la base de données vers l'instance ESC nouvellement créée, l'outil va également promouvoir une des instances pour être un ESC primaire, monter son dossier DB sur le périphérique drbd et va démarrer la base de données PostgreSQL.

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

8. Redémarrez le service ESC pour terminer la restauration de la base de données. Pour l'exécution haute disponibilité dans les deux machines virtuelles, redémarrez le service conservé.

# service keepalived start

9. Une fois la machine virtuelle restaurée et exécutée correctement ; assurez-vous que toute la configuration spécifique à syslog est restaurée à partir de la sauvegarde connue précédente. assurez-vous qu'il est restauré dans toutes les machines virtuelles ESC.

[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. Si l'ESC doit être reconstruit à partir de l'instantané OSPD, utilisez cette commande avec l'utilisation de l'instantané pris lors de la sauvegarde.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

11. Vérifiez l'état de l'ESC une fois la reconstruction terminée.

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

12. Vérifier l'intégrité ESC avec la commande ci-dessous

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

Lorsque l'ESC ne démarre pas la machine virtuelle

- Dans certains cas, l'ESC ne démarre pas la machine virtuelle en raison d'un état inattendu. Une solution de contournement consiste à effectuer un basculement ESC en redémarrant l'ESC principal. La commutation ESC prendra environ une minute.  Exécutez health.sh sur le nouvel ESC maître pour vérifier qu'il est actif. Lorsque l'ESC devient maître, l'ESC peut régler l'état de la machine virtuelle et démarrer la machine virtuelle. Comme cette opération est planifiée, vous devez attendre 5 à 7 minutes pour qu'elle se termine.

- Vous pouvez surveiller /var/log/esc/yangesc.log et /var/log/esc/escmanager.log. Si vous ne voyez PAS la récupération de la machine virtuelle après 5 à 7 minutes, l'utilisateur doit effectuer la récupération manuelle des machines virtuelles affectées.

- Une fois la machine virtuelle restaurée et exécutée correctement ; assurez-vous que toute la configuration spécifique à syslog est restaurée à partir de la sauvegarde connue précédente. S'assurer qu'il est restauré dans toutes les machines virtuelles ESC

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

Récupération CPS

Restaurer la machine virtuelle du gestionnaire de cluster dans OpenStack

Étape 1 Copiez l'instantané de la machine virtuelle du gestionnaire de cluster sur la lame du contrôleur, comme indiqué dans la commande suivante :

ls —ltr *snapshot*

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

Étape 2 - Téléchargez l'image de capture instantanée vers OpenStack à partir du data store :

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

Étape 3 Vérifiez si l'instantané est chargé à l'aide d'une commande Nova, comme indiqué dans l'exemple suivant :

nova image-list

Figure 2 : Exemple de rapport

Étape 4 En fonction de l'existence ou non de la machine virtuelle du gestionnaire de cluster, vous pouvez choisir de créer le cluman ou de reconstruire le cluman :

· Si l'instance de la machine virtuelle du Gestionnaire de cluster n'existe pas, créez la machine virtuelle de cluster avec une commande Heat ou Nova, comme indiqué dans l'exemple suivant :

Créer une machine virtuelle cloud avec 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>

Le cluster PCRF fraye avec l'aide de la commande ci-dessus, puis restaure les configurations du gestionnaire de cluster à partir des sauvegardes effectuées avec la restauration config_br.py, mongorestore à partir du vidage effectué dans la sauvegarde

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"

· Si l'instance de machine virtuelle du Gestionnaire de cluster existe, utilisez une commande de reconstruction de nouvelle génération pour reconstruire l'instance de machine virtuelle de Cluman avec l'instantané téléchargé, comme indiqué :

nova rebuild <instance_name> <snapshot_image_name>

Exemple :

nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

Étape 5 - Listez toutes les instances comme indiqué et vérifiez que la nouvelle instance du gestionnaire de cluster est créée et en cours d'exécution :

nova list

Figure 3. Exemple de rapport

Restaurer les derniers correctifs du système

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

Note: Les composants logiciels doivent tous afficher l'état Non surveillé.

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

Restaurer les travaux en rond

1. Déplacez le fichier sauvegardé d'OSPD vers Cluman/Pcrfclient01.

2. Exécutez la commande pour activer la tâche cronjob à partir de la sauvegarde.

#crontab Cron-backup

3. Vérifiez si les cronjobs ont été activés par la commande ci-dessous.

#crontab -l

Restaurer des machines virtuelles individuelles dans le cluster

Pour redéployer la machine virtuelle pcrfclient01 :

Étape 1 Connectez-vous à la machine virtuelle du Gestionnaire de cluster en tant qu'utilisateur racine.

Étape 2 Notez l'UUID du référentiel SVN à l'aide de la commande suivante :

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

La commande affiche l'UUID du référentiel.

Exemple : UUID du référentiel : ea50bd2-5726-46b8-b807-10f4a7424f0e

Étape 3 Importez les données de configuration de Policy Builder de sauvegarde sur Cluster Manager, comme indiqué dans l'exemple suivant :

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

Note: De nombreux déploiements exécutent une tâche cron qui sauvegarde régulièrement les données de configuration.Pour plus d'informations, reportez-vous à Sauvegarde du référentiel Subversion.

Étape 4 Pour générer les fichiers d'archivage des machines virtuelles sur le Gestionnaire de cluster à l'aide des dernières configurations, exécutez la commande suivante :

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

Étape 5 Pour déployer la machine virtuelle pcrfclient01, effectuez l'une des opérations suivantes :

Dans OpenStack, utilisez le modèle HEAT ou la commande Nova pour recréer la machine virtuelle. Pour plus d'informations, consultez le Guide d'installation de CPS pour OpenStack.

Étape 6 - Rétablissez la synchronisation maître/esclave SVN entre pcrfclient01 et pcrfclient02 avec pcrfclient01 comme maître en exécutant la série de commandes suivante.

Si SVN est déjà synchronisé, n'émettez pas ces commandes.

Pour vérifier si SVN est synchronisé, exécutez la commande suivante à partir de pcrfclient02.

Si une valeur est renvoyée, le SVN est déjà synchronisé :

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

Exécutez les commandes suivantes à partir de pcrfclient01 :

/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

Étape 7 Si pcrfclient01 est également la machine virtuelle arbitre, exécutez les étapes suivantes :

a) Créez les scripts de démarrage/d'arrêt mongodb en fonction de la configuration système. Toutes ces bases de données ne sont pas configurées pour tous les déploiements.

Note: Reportez-vous à /etc/broadhop/mongoConfig.cfg pour déterminer les bases de données à configurer.

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) Lancer le processus mongo :

/usr/bin/systemctl start sessionmgr-XXXXX

c) Attendez que l'arbitre démarre, puis exécutez diagnostics.sh —get_replica_status pour vérifier l'intégrité du jeu de réplicas.

Pour redéployer la machine virtuelle pcrfclient02 :

Étape 1 - Connectez-vous à la machine virtuelle Cluster Manager en tant qu'utilisateur racine

Étape 2 Pour générer les fichiers d'archivage des machines virtuelles sur le Gestionnaire de cluster à l'aide des dernières configurations, exécutez la commande suivante :

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

Étape 3 Pour déployer la machine virtuelle pcrfclient02, effectuez l'une des opérations suivantes :

Dans OpenStack, utilisez le modèle HEAT ou la commande Nova pour recréer la machine virtuelle. Pour plus d'informations, consultez le Guide d'installation de CPS pour OpenStack.

Étape 4 - Sécurisez le shell vers pcrfclient01 :

ssh pcrfclient01

Étape 5 Exécutez le script suivant pour récupérer les repos SVN de pcrfclient01 :

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

Pour redéployer une machine virtuelle sessionmgr :

Étape 1 - Connectez-vous à la machine virtuelle Cluster Manager en tant qu'utilisateur racine

Étape 2 Pour déployer la machine virtuelle sessionmgr et remplacer la machine virtuelle défaillante ou endommagée, effectuez l'une des opérations suivantes :

Dans OpenStack, utilisez le modèle HEAT ou la commande Nova pour recréer la machine virtuelle. Pour plus d'informations, consultez le Guide d'installation de CPS pour OpenStack

Étape 3 - Créez les scripts de démarrage/d'arrêt mongodb en fonction de la configuration système.

Toutes ces bases de données ne sont pas configurées pour tous les déploiements. Reportez-vous à /etc/broadhop/mongoConfig.cfg pour savoir quelles bases de données doivent être configurées

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

Étape 4 - Sécurisez le shell sur la machine virtuelle sessionmgr et lancez le processus mongo :

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

Étape 5 Attendez que les membres démarrent et que les membres secondaires se synchronisent, puis exécutez diagnostics.sh —get_replica_status pour vérifier l'intégrité de la base de données.

Étape 6 Pour restaurer la base de données de Session Manager, utilisez l'une des commandes suivantes selon que la sauvegarde a été effectuée avec l'option —mongo-all ou —mongo :

• 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

Pour redéployer la machine virtuelle Policy Director (Load Balancer) :

Étape 1 Connectez-vous à la machine virtuelle du Gestionnaire de cluster en tant qu'utilisateur racine.

Étape 2 Pour importer les données de configuration de Policy Builder de sauvegarde sur Cluster Manager, exécutez la commande suivante :

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

Étape 3 Pour générer les fichiers d'archivage des machines virtuelles sur le Gestionnaire de cluster à l'aide des dernières configurations, exécutez la commande suivante :

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

Étape 4 Pour déployer la machine virtuelle lb01, effectuez l'une des opérations suivantes :

Dans OpenStack, utilisez le modèle HEAT ou la commande Nova pour recréer la machine virtuelle. Pour plus d'informations, consultez le Guide d'installation de CPS pour OpenStack.

Pour redéployer la machine virtuelle QNS (Policy Server) :

Étape 1 Connectez-vous à la machine virtuelle du Gestionnaire de cluster en tant qu'utilisateur racine.

Étape 2 Importez les données de configuration de Policy Builder de sauvegarde sur Cluster Manager, comme indiqué dans l'exemple suivant :

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

Étape 3 Pour générer les fichiers d'archivage des machines virtuelles sur le Gestionnaire de cluster à l'aide des dernières configurations, exécutez la commande suivante :

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

Étape 4 Pour déployer la machine virtuelle qns, effectuez l'une des opérations suivantes :

Dans OpenStack, utilisez le modèle HEAT ou la commande Nova pour recréer la machine virtuelle. Pour plus d'informations, consultez le Guide d'installation de CPS pour OpenStack

Procédure générale de restauration de la base de données

Étape 1 Exécutez la commande suivante pour restaurer la base de données :

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

Exemple :

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

Étape 2 Connectez-vous à la base de données et vérifiez qu'elle est en cours d'exécution et accessible :

1. Connectez-vous au gestionnaire de sessions :

mongo --host sessionmgr01 --port $port

où $port est le numéro de port de la base de données à vérifier. Par exemple, 27718 est le port Balance par défaut.

2. Affichez la base de données en exécutant la commande suivante :

show dbs

3. Basculez le shell mongo dans la base de données en exécutant la commande suivante :

use $db

où $db est un nom de base de données affiché dans la commande précédente.

La commande 'use' bascule le shell mongo dans cette base de données.

Exemple :

use balance_mgmt

4. Pour afficher les collections, exécutez la commande suivante :

show collections

5. Pour afficher le nombre d'enregistrements de la collection, exécutez la commande suivante :

db.$collection.count()

For example, db.account.count()

L'exemple ci-dessus montre le nombre d'enregistrements dans le ” de compte “ collection de la base de données Balance (balance_mgmt).

Restauration du référentiel de sous-versions

Pour restaurer les données de configuration de Policy Builder à partir d'une sauvegarde, exécutez la commande suivante :

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

Restaurer le tableau de bord Grafana

Vous pouvez restaurer le tableau de bord Grafana à l'aide de la commande suivante :

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

Validation de la restauration

Après avoir restauré les données, vérifiez le système de travail en exécutant la commande suivante :

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