Sauvegarde et récupération - Récupération complète en cluster - CPS

Introduction

Ce document décrit les étapes requises pour récupérer un cluster CPS entier 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 impliqués sont représentés dans cette image :

Ce document est destiné au personnel Cisco familier avec la plate-forme Cisco Ultra-M.

Note: La version Ultra M 5.1.x est prise en compte pour définir les procédures de ce document.

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

Hypothèse

Pour cette procédure, il est supposé que seul le cluster CPS doit être récupéré et que tous les composants au niveau d'Openstack sont opérationnels, y compris l'ESC 

Procédure de restauration

   

Lorsque l'ESC ne démarre pas la VM :

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

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

Étape 1. Utilisez la commande suivante pour afficher les instances nova et noter le nom de l'instance de machine virtuelle du gestionnaire de cluster :

nova list

Arrêtez le cluman de l'ESC.

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

É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 nouvelle comme indiqué dans cette commande :

nova image-create --poll 
     
      
       
     

Remarque : 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. Sauvegarder le fichier jaune à partir de 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 
       
     

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. Effectuez une 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-*

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 cette commande :

ls —ltr *snapshot*

Exemple de rapport : -rw-r—r— 1 racine 10429595648 août 16 02:39 snapshot.raw

Étape 2. Télécharger 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 téléchargé à l'aide d'une commande Nova, comme indiqué dans cet exemple :

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

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 config_br.py restore, mongorestore à partir du dump pris 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 Cluster Manager existe, utilisez une commande nova rebuild pour reconstruire l'instance de machine virtuelle Cluman avec l'instantané téléchargé, comme indiqué :

nova rebuild 
     
      
       
     

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 :

liste de nova

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 Non surveillé comme état actuel) 8. Mettre à jour les machines virtuelles qns avec le nouveau logiciel à l'aide du script reinit.sh : /var/qps/install/current/scripts/upgrade/reinit.sh 9. Redémarrez tous les composants logiciels des machines virtuelles cibles : runonall.sh sudo monit démarre les 10. Vérifiez que le composant est mis à jour, exécutez : about.sh

Restaurer les travaux en rond

1. Déplacer le fichier sauvegardé d'OSPD vers Cluman/Pcrfclient01 
   
   
2. Exécutez la commande pour activer cronjob à partir de la sauvegarde
   #crontab Cron-backup
   
3. Vérifier si les tâches cronjobs ont été activées 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 la sauvegarde Policy Builder 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 de VM 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établir la synchronisation maître/esclave SVN entre pcrfclient01 et pcrfclient02 avec pcrfclient01 comme maître lors de l'exécution de ces commandes.

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

Pour vérifier si SVN est synchronisé, exécutez cette commande à 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 ces commandes à 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 :

1. 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.

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

2. Démarrez le processus de mongo :

/usr/bin/systemctl start sessionmgr-XXXXX

3. 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 du Gestionnaire de cluster en tant qu'utilisateur racine.

Étape 2. Pour générer les fichiers d'archivage de VM 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 ce script 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. Se connecter à la machine virtuelle du Gestionnaire de cluster 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 démarrez 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 la sauvegarde Policy Builder sur Cluster Manager, comme indiqué dans cet exemple :

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

Étape 3. Pour générer les fichiers d'archivage de VM 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 cette commande 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. Afin d'afficher le nombre d'enregistrements dans la collection, exécutez cette commande :

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/

Valider la restauration

Après avoir restauré les données, vérifiez le système de travail à l'aide de cette commande :

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

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 prend 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.
  
  
• Si le cluster est complètement indisponible et que seul l'ESC est accessible, la restauration doit être effectuée à partir des dernières sauvegardes prises à partir des sauvegardes planifiées effectuées via Cronjobs. La procédure de récupération reste la même que celle mentionnée dans la MOP.