Procédures de sauvegarde et de restauration pour divers composants UltraM
Contenu
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 (VNF) de StarOS.
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 :
- IT automatique
- Déploiement automatique
- Ultra Automation Services (UAS)
- Gestionnaire d'éléments (EM)
- Contrôleur de services élastiques (ESC)
- Fonction de contrôle (CF)
- Fonction de session (SF)
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 qui connaît la plate-forme Cisco Ultra-M.
Abréviations
| VNF | Fonction de réseau virtuel |
| FC | Fonction de contrôle |
| SF | Fonction de service |
| É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 |
| EM | Gestionnaire d'éléments |
| UAS | Services d’automatisation ultra |
| UUID | Identificateur unique |
Procédures 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 Undercloud 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 afin de sauvegarder les données du noeud Undercloud 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 de déploiement automatique
1. Le déploiement automatique nécessite la sauvegarde de ces données :
- Déploiement automatique de la base de données de configuration de configuration (CDB)
- Configuration du déploiement automatique
- Journaux de déploiement automatique
- Configuration Syslog
2. Une sauvegarde des données CDB AutoDeploy Confd et de la configuration en cours est requise après chaque activation/désactivation et garantit que les données sont transférées à un serveur de sauvegarde.
3. AutoDeploy s'exécute en mode autonome et si ces données sont perdues, vous ne pourrez pas désactiver le déploiement de manière gracieuse. Par conséquent, il est obligatoire de prendre la sauvegarde de la configuration et des données CDB.
ubuntu@auto-deploy-iso-2007-uas-0:~$ sudo -i
root@auto-deploy-iso-2007-uas-0:~# service uas-confd stop
uas-confd stop/waiting
root@auto-deploy:/home/ubuntu# service autodeploy status
autodeploy start/running, process 1313
root@auto-deploy:/home/ubuntu# service autodeploy stop
autodeploy stop/waiting
root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar cvf autodeploy_cdb_backup.tar cdb/
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb
4. Copiez autoDeployment_cdb_backup.tar sur le serveur de sauvegarde.
5. Effectuez une sauvegarde de la configuration en cours dans l'AutoDeploy et transférez-la sur un serveur de sauvegarde.
root@auto-deploy:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy
auto-deploy#show running-config | save backup-config-$date.cfg à Replace the $date to appropriate date and POD reference
auto-deploy#
6.Démarrez le service de configuration AutoDeploy.
root@auto-deploy-iso-2007-uas-0:~# service uas-confd start
uas-confd start/running, process 13852
root@auto-deploy:/home/ubuntu# service autodeploy start
autodeploy start/running, process 8835
7. Accédez au répertoire des scripts et collectez les journaux à partir de la machine virtuelle AutoDeploy.
cd /opt/cisco/usp/uas/scripts
8. Lancez le script collect-uas-logs.sh afin de collecter les journaux.
sudo ./collect-uas-logs.sh
9. Prenez la sauvegarde d'image ISO à partir de l'AutoDeploy et transférez-la sur le serveur de sauvegarde.
root@POD1-5-1-7-2034-auto-deploy-uas-0:/home/ubuntu# /home/ubuntu/isos
root@POD1-5-1-7-2034-auto-deploy-uas-0:/home/ubuntu/isos# ll
total 4430888
drwxr-xr-x 2 root root 4096 Dec 20 01:17 ./
drwxr-xr-x 5 ubuntu ubuntu 4096 Dec 20 02:31 ../
-rwxr-xr-x 1 ubuntu ubuntu 4537214976 Oct 12 03:34 usp-5_1_7-2034.iso*
10. Collectez la configuration Syslog et enregistrez-la dans le serveur de sauvegarde.
ubuntu@auto-deploy-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autodeploy.conf
00-autodeploy.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
Sauvegarde AutoIT-VNF
AutoIT-VNF est une machine virtuelle sans état. Il n'y a donc aucune base de données (DB) à sauvegarder. AutoIT-VNF est responsable de la gestion des paquets avec le référentiel de gestion de configuration d'Ultra-M. Il est donc essentiel que ces sauvegardes soient effectuées.
1. Prenez la sauvegarde des configurations day-0 StarOS et transférez-les sur le serveur de sauvegarde.
root@auto-it-vnf-iso-5-8-uas-0:/home/ubuntu# cd /opt/cisco/usp/uploads/
root@auto-it-vnf-iso-5-8-uas-0:/opt/cisco/usp/uploads# ll
total 12
drwxrwxr-x 2 uspadmin usp-data 4096 Nov 8 23:28 ./
drwxr-xr-x 15 root root 4096 Nov 8 23:53 ../
-rw-rw-r-- 1 ubuntu ubuntu 985 Nov 8 23:28 system.cfg
2. Accédez au répertoire des scripts et collectez les journaux à partir de la machine virtuelle AutoIT.
cd /opt/cisco/usp/uas/scripts
3. Lancez le script collect-uas-logs.sh afin de collecter les journaux.
sudo ./collect-uas-logs.sh
4. Collectez la sauvegarde de configuration syslog et enregistrez-la dans le serveur de sauvegarde.
ubuntu@auto-it-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-it-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autoit-vnf.conf
00-autoit-vnf.conf
root@auto-it-vnf-iso-5-1-5-1196-uas-0:ls /etc/rsyslog.conf
rsyslog.conf
Sauvegarde AutoVNF
AutoVNF est responsable de l'affichage de VNFM et VNF individuels. AutoDeploy envoie la configuration requise pour instancier les deux VNFM. et VNF à AutoVNF et AutoVNF effectuent cette opération. Afin d'activer VNFM, AutoVNF communiquera directement à VIM/OpenStack et une fois le VNFM activé, AutoVNF utilise VNFM pour activer VNF.
AutoVNF dispose d'une redondance 1:N et dans une configuration Ultra-M, trois machines virtuelles AutoVNF sont en cours d'exécution. Une défaillance AutoVNF unique est prise en charge dans Ultra-M et la récupération est possible.
Détails de la sauvegarde AutoVNF :
- la configuration d'exécution
- Base de données CDB ConfD
- Journaux AutoVNF (à partir de chaque instance d'AutoVNF)
- Configuration Syslog
Il est recommandé de prendre des sauvegardes avant toute activation/désactivation sur le site donné et de les télécharger sur le serveur de sauvegarde.
1. Connectez-vous à Master AutoVNF et vérifiez qu'il s'agit de Cond-Master.
root@auto-testautovnf1-uas-1:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.57.11.101
INSTANCE IP STATE ROLE
-----------------------------------
172.57.12.6 alive CONFD-SLAVE
172.57.12.7 alive CONFD-MASTER
172.57.12.13 alive NA
auto-testautovnf1-uas-1#exit
root@auto-testautovnf1-uas-1:/home/ubuntu# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:c7:dc:89 brd ff:ff:ff:ff:ff:ff
inet 172.57.12.7/24 brd 172.57.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fec7:dc89/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:10:29:1b brd ff:ff:ff:ff:ff:ff
inet 172.57.11.101/24 brd 172.57.11.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe10:291b/64 scope link
valid_lft forever preferred_lft forever
2. Effectuez une sauvegarde de la configuration en cours et transférez le fichier sur le serveur de sauvegarde.
root@auto-testautovnf1-uas-1:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show running-config | save running-autovnf-12202017.cfg
auto-testautovnf1-uas-1#exit
root@auto-testautovnf1-uas-1:/home/ubuntu# ll running-autovnf-12202017.cfg
-rw-r--r-- 1 root root 18181 Dec 20 19:03 running-autovnf-12202017.cfg
3. Effectuez une sauvegarde de CDB et transférez le fichier sur le serveur de sauvegarde.
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar cvf autovnf_cdb_backup.tar cdb/
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/vpc.xml
cdb/A.cdb
cdb/gilan.xml
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd#
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/confd-6.3.1/var/confd# ll autovnf_cdb_backup.tar
-rw-r--r-- 1 root root 1198080 Dec 20 19:08 autovnf_cdb_backup.tar
4. Accédez au répertoire des scripts, collectez les journaux et transférez-les sur le serveur de sauvegarde.
cd /opt/cisco/usp/uas/scripts
sudo ./collect-uas-logs.sh
5. Connectez-vous à l'instance de secours d'AutoVNF et effectuez ces étapes afin de collecter les journaux et de les transférer au serveur de sauvegarde.
6. Sauvegardez la configuration Syslog sur les machines virtuelles AutoVNF maître et veille et transférez-les sur le serveur de sauvegarde.
ubuntu@auto-testautovnf1-uas-1:~$sudo su
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.d/00-autovnf.conf
00-autovnf.conf
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
Sauvegarde ESC
1. AutoVNF est responsable de l'activation de l'ESC dans une solution Ultra-M en interagissant directement avec VIM. AutoVNF/EM transmet la configuration spécifique VNF à l'ESC et l'ESC, à son tour, active 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 vous pouvez récupérer le système en cas de défaillance unique.
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 avoir suivi les activités dans le VNF/POD/Site donné.
4. Vérifiez que l'état de santé de l'ESC est correct avec l'utilisation 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 une 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 de sauvegarde
1. Réglez l'ESC sur le mode maintenance.
2. Connectez-vous à la machine virtuelle ESC et exécutez cette commande avant de prendre la sauvegarde.
[admin@auto-test-vnfm1-esc-0 admin]# sudo bash
[root@auto-test-vnfm1-esc-0 admin]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@auto-test-vnfm1-esc-0 admin]# 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@auto-test-vnfm1-esc-0 admin]# escadm op_mode set --mode=maintenance
3. Vérifiez le mode ESC et assurez-vous qu'il est en mode maintenance.
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode show
4. Sauvegarder la base de données à l'aide de l'outil de restauration de sauvegarde de la base de données disponible dans ESC.
[root@auto-test-vnfm1-esc-0 admin]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file scp://<username>:<password>@<backup_vm_ip>:<filename>
5. Redéfinissez l'ESC sur Mode de fonctionnement et confirmez le mode.
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode set --mode=operation
[root@auto-test-vnfm1-esc-0 admin]# escadm op_mode show
6. Accédez au répertoire des scripts et collectez les journaux.
[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/esc-scripts
sudo ./collect_esc_log.sh
7. 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.
8. Collectez la sauvegarde de configuration Syslog sur le serveur de sauvegarde ESC VMS et transférez-les sur 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 EM
1. Une fois VNFM/ESC activé, AutoVNF utilise l'ESC afin d'activer le cluster EM. Une fois le cluster EM activé, le module EM interagit avec l'ESC pour activer VNF (VPC/StarOS).
2. EM offre une redondance 1:N dans la solution Ultra-M. Il existe un cluster de trois machines virtuelles EM et Ultra-M prend en charge la récupération d'une défaillance de machine virtuelle unique.
Détails de la sauvegarde EM :
- La configuration d'exécution
- Base de données NCS
- Journaux EM (à partir des machines virtuelles NCS actives/en veille)
- Configuration Syslog
3. La fréquence de sauvegarde de la base de données EM est délicate et doit être manipulée avec soin lorsque l'ESC surveille et gère les différents ordinateurs d'état des différentes machines virtuelles VNF déployées. Il est recommandé d'effectuer ces sauvegardes après avoir suivi les activités dans un VNF/POD/Site donné.
4. Sauvegardez la configuration en cours d'EM et transférez le fichier sur le serveur de sauvegarde.
ubuntu@vnfd1deploymentem-0:~$ sudo -i
root@vnfd1deploymentem-0:~# ncs_cli -u admin -C
admin connected from 127.0.0.1 using console on vnfd1deploymentem-0
admin@scm# show running-config | save em-running-12202017.cfg
root@vnfd1deploymentem-0:~# ll em-running-12202017.cfg
-rw-r--r-- 1 root root 19957 Dec 20 23:01 em-running-12202017.cfg
5. Effectuez une sauvegarde de base de données NCS EM et transférez le fichier sur le serveur de sauvegarde.
ubuntu@vnfd1deploymentem-0:~$ sudo -i
root@vnfd1deploymentem-0:~# cd /opt/cisco/em/git/em-scm/ncs-cdb
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm/ncs-cdb# ll
total 472716
drwxrwxr-x 2 root root 4096 Dec 20 02:53 ./
drwxr-xr-x 9 root root 4096 Dec 20 19:22 ../
-rw-r--r-- 1 root root 770 Dec 20 02:48 aaa_users.xml
-rw-r--r-- 1 root root 70447 Dec 20 02:53 A.cdb
-rw-r--r-- 1 root root 483927031 Dec 20 02:48 C.cdb
-rw-rw-r-- 1 root root 47 Jul 27 05:53 .gitignore
-rw-rw-r-- 1 root root 332 Jul 27 05:53 global-settings.xml
-rw-rw-r-- 1 root root 621 Jul 27 05:53 jvm-defaults.xml
-rw-rw-r-- 1 root root 3392 Jul 27 05:53 nacm.xml
-rw-r--r-- 1 root root 6156 Dec 20 02:53 O.cdb
-rw-r--r-- 1 root root 13041 Dec 20 02:48 startup-vnfd.xml
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm/ncs-cdb#
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm# tar cvf em_cdb_backup.tar ncs-cdb
ncs-cdb/
ncs-cdb/O.cdb
ncs-cdb/C.cdb
ncs-cdb/nacm.xml
ncs-cdb/jvm-defaults.xml
ncs-cdb/A.cdb
ncs-cdb/aaa_users.xml
ncs-cdb/global-settings.xml
ncs-cdb/.gitignore
ncs-cdb/startup-vnfd.xml
root@vnfd1deploymentem-0:/opt/cisco/em/git/em-scm# ll em_cdb_backup.tar
-rw-r--r-- 1 root root 484034560 Dec 20 23:06 em_cdb_backup.tar
6. Accédez au répertoire des scripts, collectez les journaux et transférez-les sur le serveur de sauvegarde.
/opt/cisco/em-scripts
sudo ./collect-em-logs.sh
- Répétez la même procédure pour collecter le journal à partir de la machine virtuelle de secours NCS
- Sauvegarder la configuration Syslog sur toutes les machines virtuelles EM et les transférer sur le serveur de sauvegarde
root@vnfd1deploymentem-0:/etc/rsyslog.d# pwd
/etc/rsyslog.d
root@vnfd1deploymentem-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@vnfd1deploymentem-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf
Sauvegarde StarOS
Pour StarOS, ces informations doivent être sauvegardées.
- Les enregistrements de données de facturation (CDR) doivent être sauvegardés sur un serveur distant à intervalles réguliers
- Configuration Jour 0 appliquée au moment du déploiement du système
- Configuration du jour N
- SSD
- Configuration Syslog
Procédure de restauration
Récupération OSPD
La procédure de récupération OSPD est exécutée sur la base de ces hypothèses
- La sauvegarde OSPD est disponible à partir d'un ancien serveur OSPD
- 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 du déploiement automatique
1. La VM de déploiement automatique peut être récupérée lorsque la machine virtuelle est en état d'erreur ou d'arrêt, redémarrez la machine virtuelle affectée de manière définitive. Exécutez ces vérifications afin de voir si cela permet de récupérer AutoDeploy.
Checking AutoDeploy Processes
Verify that key processes are running on the AutoDeploy VM:
root@auto-deploy-iso-2007-uas-0:~# initctl status autodeploy
autodeploy start/running, process 1771
root@auto-deploy-iso-2007-uas-0:~# ps -ef | grep java
root 1788 1771 0 May24 ? 00:00:41 /usr/bin/java -jar /opt/cisco/usp/apps/autodeploy/autodeploy-1.0.jar com.cisco.usp.autodeploy.Application --autodeploy.transaction-log-store=/var/log/cisco-uas/autodeploy/transactions
Stopping/Restarting AutoDeploy Processes
#To start the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl start autodeploy
autodeploy start/running, process 11094
#To stop the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl stop autodeploy
autodeploy stop/waiting
#To restart the AutoDeploy process:
root@auto-deploy-iso-2007-uas-0:~# initctl restart autodeploy
autodeploy start/running, process 11049
#If the VM is in ERROR or shutdown state, hard-reboot the AutoDeploy VM
[stack@pod1-ospd ~]$ nova list |grep auto-deploy
| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.12, 10.84.123.39
[stack@pod1-ospd ~]$ nova reboot –hard 9b55270a-2dcd-4ac1-aba3-bf041733a0c9
2. Si le déploiement automatique est irrécupérable, suivez ces procédures afin de le restaurer à l'état dans lequel il était auparavant. Utilisez la sauvegarde effectuée précédemment.
[stack@pod1-ospd ~]$ nova list |grep auto-deploy
| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.12, 10.84.123.39 [stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.1.2 --delete
3. Après la suppression du déploiement automatique, créez-le à nouveau avec la même adresse flottante.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.1.2
2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.1.1.2:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.1.2' to IP '172.16.181.7'
2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.1.2]
4. Copiez le fichier Autodéploiement.cfg, ISO et le fichier cond_backup tar de votre serveur de sauvegarde vers la machine virtuelle AutoDeploy.
5. Restaurer les fichiers cdb confd à partir du fichier tar de sauvegarde.
ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i
ubuntu@auto-deploy-iso-2007-uas-0:# service uas-confd stop
uas-confd stop/waiting
root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb
root@auto-deploy-iso-2007-uas-0~# service uas-confd start
uas-confd start/running, process 2036
#Restart AutoDeploy process
root@auto-deploy-iso-2007-uas-0~# service autodeploy restart
autodeploy start/running, process 2144
#Check that confd was loaded properly by checking earlier transactions.
root@auto-deploy-iso-2007-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
auto-deploy-iso-2007-uas-0#show transaction
SERVICE SITE
DEPLOYMENT SITE TX AUTOVNF VNF AUTOVNF
TX ID TX TYPE ID DATE AND TIME STATUS ID ID ID ID TX ID
-------------------------------------------------------------------------------------------------------------------------------------
1512571978613 service-deployment tb5bxb 2017-12-06T14:52:59.412+00:00 deployment-success
6. Si la machine virtuelle a été 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.
ubuntu@auto-deploy-vnf-iso-5-1-5-1196-uas-0:~$sudo su
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autodeploy.conf
00-autodeploy.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
Récupération AutoIT-VNF
1. La machine virtuelle AutoIT-VNF peut être restaurée. Si la machine virtuelle est en état d'erreur ou d'arrêt, effectuez un redémarrage matériel afin d'activer la machine virtuelle affectée. Exécutez ces étapes afin de récupérer AutoIT-VNF.
Checking AutoIT-VNF Processes
Verify that key processes are running on the AutoIT-VNF VM:
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit status
AutoIT-VNF is running.
#Stopping/Restarting AutoIT-VNF Processes
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit stop
AutoIT-VNF API server stopped.
#To restart the AutoIT-VNF processes:
root@auto-it-vnf-iso-5-1-5-1196-uas-0:~# service autoit restart
AutoIT-VNF API server stopped.
Starting AutoIT-VNF
/opt/cisco/usp/apps/auto-it/vnf
AutoIT API server started.
#If the VM is in ERROR or shutdown state, hard-reboot the AutoDeploy VM
[stack@pod1-ospd ~]$ nova list |grep auto-it
| 1c45270a-2dcd-4ac1-aba3-bf041733d1a1 | auto-it-vnf-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.13, 10.84.123.40
[stack@pod1-ospd ~]$ nova reboot –hard 1c45270a-2dcd-4ac1-aba3-bf041733d1a1
2. Si AutoIT-VNF est irrécupérable, suivez ces procédures afin de le restaurer à l'état dans lequel il était auparavant. Utilisez le fichier de sauvegarde.
[stack@pod1-ospd ~]$ nova list |grep auto-it
| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0 | ACTIVE | - | running | mgmt=172.16.181.3, 10.84.123.42 [stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.1.3 --delete
3. Recréez Auto-IT en exécutant le script de transfert auto-it-vnf et assurez-vous d'utiliser la même adresse IP flottante que celle utilisée précédemment.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts
[stack@pod1-ospd scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.1.3
2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.1.1.3:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.1.3' to IP '172.16.181.9'
2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.1.3
4. Les images ISO utilisées dans le POD doivent être rechargées sur AutoIT-VNF.
[stack@pod1-ospd ~]$ cd images/5_1_7-2007/isos
[stack@pod1-ospd isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.1.3:5001/isos
{
"iso-id": "5.1.7-2007"
}
Note: 10.1.1.3 is AutoIT-VNF IP in the above command.
#Validate that ISO is correctly loaded.
[stack@pod1-ospd isos]$ curl http://10.1.1.3:5001/isos
{
"isos": [
{
"iso-id": "5.1.7-2007"
}
]
}
5. Copiez les fichiers system.cfg VNF du serveur distant vers la machine virtuelle AutoIT-VNF. Dans cet exemple, il est copié de Déploiement automatique vers la machine virtuelle AutoIT-VNF.
[stack@pod1-ospd autodeploy]$ scp system-vnf* ubuntu@10.1.1.3:.
ubuntu@10.1.1.3's password:
system-vnf1.cfg 100% 1197 1.2KB/s 00:00
system-vnf2.cfg 100% 1197 1.2KB/s 00:00
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd
/home/ubuntu
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls
system-vnf1.cfg system-vnf2.cfg
6. Copiez les fichiers à l'emplacement approprié sur AutoIT-VNF, comme indiqué dans la configuration AutoDeploy. Voir ici.
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ sudo -i
root@auto-it-vnf-iso-2007-uas-0:~$ cp –rp system-vnf1.cfg system-vnf2.cfg /opt/cisco/usp/uploads/
root@auto-it-vnf-iso-2007-uas-0:~$ls /opt/cisco/usp/uploads/
system-vnf1.cfg system-vnf2.cfg
7. Si la machine virtuelle est 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.
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:/home/ubuntu#ls /etc/rsyslog.d/00-autoit-vnf.conf
00-autoit-vnf.conf
root@auto-deploy-vnf-iso-5-1-5-1196-uas-0:ls /etc/rsyslog.conf
rsyslog.conf
Récupération AutoVNF
1. La machine virtuelle AutoVNF peut être restaurée si la machine virtuelle est en état d'erreur ou d'arrêt. Effectuez un redémarrage matériel afin d'activer la machine virtuelle affectée. Exécutez ces étapes afin de récupérer AutoVNF.
2. Identifiez la machine virtuelle en état d'erreur ou d'arrêt. Redémarrer la machine virtuelle AutoVNF.
Dans cet exemple, redémarrez auto-test autovnf1-uas-2.
[root@tb1-baremetal scripts]# nova list | grep "auto-testautovnf1-uas-[0-2]"
| 3834a3e4-96c5-49de-a067-68b3846fba6b | auto-testautovnf1-uas-0 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.6; auto-testautovnf1-uas-management=172.57.11.8 |
| 0fbfec0c-f4b0-4551-807b-50c5fe9d3ea7 | auto-testautovnf1-uas-1 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.7; auto-testautovnf1-uas-management=172.57.11.12 |
| 432e1a57-00e9-4e58-8bef-2a20652df5bf | auto-testautovnf1-uas-2 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.57.12.13; auto-testautovnf1-uas-management=172.57.11.4 |
[root@tb1-baremetal scripts]# nova reboot --hard 432e1a57-00e9-4e58-8bef-2a20652df5bf
Request to reboot server <Server: auto-testautovnf1-uas-2> has been accepted.
[root@tb1-baremetal scripts]#
3. Une fois la machine virtuelle réactivée, vérifiez qu'elle rejoint le cluster.
root@auto-testautovnf1-uas-1:/opt/cisco/usp/uas/scripts# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-testautovnf1-uas-1
auto-testautovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.57.11.101
INSTANCE IP STATE ROLE
-----------------------------------
172.57.12.6 alive CONFD-SLAVE
172.57.12.7 alive CONFD-MASTER
172.57.12.13 alive NA
4. Si la machine virtuelle AutoVNF ne peut pas être récupérée par la procédure mentionnée, vous devez la récupérer à l'aide de ces étapes.
[stack@pod1-ospd ~]$ nova list | grep vnf1-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | vnf1-UAS-uas-0 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.10; vnf1-UAS-uas-management=172.168.10.3
[stack@pod1-ospd ~]$ nova delete vnf1-UAS-uas-0
Request to delete server vnf1-UAS-uas-0 has been accepted.
5. Afin de récupérer la machine virtuelle autovnf-uas, exécutez le script uas-check pour vérifier l'état. Il doit signaler une erreur. Ensuite, exécutez à nouveau avec l'option —fix afin de recréer la machine virtuelle UAS manquante.
[stack@pod1-ospd ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@pod1-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors
[stack@tb3-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance vnf1-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance vnf1-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance vnf1-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance vnf1-UAS-uas-0' and attaching volume ‘vnf1-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘vnf1-UAS-uas-0'
[stack@tb3-ospd scripts]$ ./uas-check.py auto-vnf vnf1-UAS
2017-11-16 13:11:07,472 - INFO: Check of AutoVNF cluster started
2017-11-16 13:11:09,510 - INFO: Found 3 ACTIVE AutoVNF instances
2017-11-16 13:11:09,511 - INFO: Check completed, AutoVNF cluster is fine
6. Connectez-vous à la machine virtuelle AutoVNF maître. Quelques minutes après la récupération, l'instance nouvellement créée doit rejoindre le cluster et être à l'état actif.
tb3-bxb-vnf1-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP STATE ROLE
-----------------------------------
172.17.180.6 alive CONFD-SLAVE
172.17.180.7 alive CONFD-MASTER
172.17.180.9 alive NA
#if uas-check.py --fix fails, you may need to copy this file and execute again.
[stack@tb3-ospd]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
[stack@tb3-ospd]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/
7. Si la machine virtuelle est correctement restaurée et exécutée, 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 AutoVNF.
ubuntu@auto-testautovnf1-uas-1:~$sudo su
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.d/00-autovnf.conf
00-autovnf.conf
root@auto-testautovnf1-uas-1:/home/ubuntu#ls /etc/rsyslog.conf
rsyslog.conf
Récupération ESC
1. La VM ESC est récupérable si la VM est à l'état Erreur ou Arrêt. Effectuez un redémarrage matériel afin d'activer 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, auto-test-vnfm1-ESC-0 est redémarré.
[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, suivez cette séquence d'étapes.
[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. Dans AutoVNF-UAS, recherchez la transaction de déploiement ESC et dans le journal de la transaction, recherchez la ligne de commande boot_vm.py afin de créer l'instance ESC.
ubuntu@vnf1-uas-uas-0:~$ sudo -i
root@vnf1-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on vnf1-uas-uas-0
vnf1-uas-uas-0#show transaction
TX ID TX TYPE DEPLOYMENT ID TIMESTAMP STATUS
------------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b vnf-deployment vnf1-DEPLOYMENT 2017-11-29T02:01:27.750692-00:00 deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b vnfm-deployment vnf1-ESC 2017-11-29T01:56:02.133663-00:00 deployment-success
vnf1-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
<logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
<tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
<log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: vnf1-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'vnf1-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py vnf1-ESC-ESC-1 --flavor vnf1-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net vnf1-UAS-uas-management --gateway_ip 172.168.10.1 --net vnf1-UAS-uas-orchestration --os_auth_url http://10.1.1.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.1.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh]...
5. Enregistrez la ligne boot_vm.py dans un fichier de script shell (esc.sh) et mettez à jour toutes les lignes ***** et mot de passe ****** avec les informations correctes (généralement core/Cisco@123). Vous devez également supprimer l'option -encrypt_key. Pour user_pass et user_confd_pass, vous devez utiliser le format -user_passwd username:password (exemple - admin:Cisco@123).
Maintenant, trouvez l'URL de bootvm.py à partir de running-config et envoyez le fichier bootvm.py à la machine virtuelle autovnf-uas. 10.1.1.3 est l'auto-informatique dans ce cas.
root@vnf1-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on vnf1-uas-uas-0
vnf1-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
value http://10.1.1.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!
root@vnf1-uas-uas-0:~# wget http://10.1.1.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52-- http://10.1.1.3/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.1.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[======================================================================================================>] 127,771 --.-K/s in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771
Create a /tmp/esc_params.cfg file.
root@vnf1-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg
6. Exécutez le script shell qui exécute le script python bootvm.py avec des options.
root@vnf1-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py vnf1-ESC-ESC-1 --flavor vnf1-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net vnf1-UAS-uas-management --gateway_ip 172.168.10.1 --net vnf1-UAS-uas-orchestration --os_auth_url http://10.1.1.5:5000/v2.0 --os_tenant_name core --os_username core --os_password Cisco@123 --bs_os_auth_url http://10.1.1.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password Cisco@123 --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:Cisco@123 --user_confd_pass admin:Cisco@123 --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh
+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | mgmt |
| OS-EXT-SRV-ATTR:host | tb5-ultram-osd-compute-1.localdomain |
| OS-EXT-SRV-ATTR:hypervisor_hostname | tb5-ultram-osd-compute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-000001eb |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2017-12-02T13:28:32.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| addresses | {"vnf1-UAS-uas-orchestration": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:d7:c6:19", "version": 4, "addr": "172.168.11.14", "OS-EXT-IPS:type": "fixed"}], "vnf1-UAS-uas-management": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:31:ee:cd", "version": 4, "addr": "172.168.10.6", "OS-EXT-IPS:type": "fixed"}]}
| config_drive | True |
| created | 2017-12-02T13:27:49Z |
| flavor | {"id": "457623b6-05d5-403c-b2e4-aa3b6a0c9d32", "links": [{"href": "http://10.1.1.5:8774/flavors/457623b6-05d5-403c-b2e4-aa3b6a0c9d32", "rel": "bookmark"}]} |
| hostId | f5d2bbf0c5a7df34cf2e6f62ae0702ef120ff82f81c3f7664ffb35e9 |
| id | 2601b8ec-8ff8-4285-810a-e859f6642ab6 |
| image | {"id": "3fe6b197-961b-4651-af22-dfd910436689", "links": [{"href": "http://10.1.1.5:8774/images/3fe6b197-961b-4651-af22-dfd910436689", "rel": "bookmark"}]} |
| key_name | - |
| metadata | {} |
| name | vnf1-esc-esc-1 |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| security_groups | [{"name": "default"}, {"name": "default"}] |
| status | ACTIVE |
| tenant_id | fd4b15df46c6469cbacf5b80dcc98a5c |
| updated | 2017-12-02T13:28:32Z |
| user_id | d3b51d6f705f4826b22817f27505c6cd |
7. À partir d'OSPD, vérifiez que la nouvelle machine virtuelle ESC est ACTIVE/en cours d'exécution.
[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6 |
#Log in to new ESC and verify Backup state. You may execute health.sh on ESC Master too.
ubuntu@vnf1-uas-uas-0:~$ ssh admin@172.168.11.14
…
####################################################################
# ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
####################################################################
[admin@vnf1-esc-esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy
[admin@vnf1-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) =================
=======================================
ESC HEALTH PASSED
[admin@vnf1-esc-esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
8. 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.
9. Pour la restauration de la base de données ESC, assurez-vous 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
10. 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
11. Exécutez le script afin de 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 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>
12. Redémarrez le service ESC pour terminer la restauration de la base de données.
13. Pour l'exécution haute disponibilité dans les deux machines virtuelles, redémarrez le service conservé.
# service keepalived start
14. 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
Récupération EM
1. Si la VM EM est dans l'état Aucun/Erreur en raison d'une ou de plusieurs conditions, l'utilisateur peut suivre la séquence donnée afin de récupérer la VM EM affectée.
2. ESC/VNFM est le composant qui surveille les machines virtuelles EM de sorte que dans le cas où le module EM est à l'état Erreur, l'ESC tentera de récupérer automatiquement la machine virtuelle EM. Pour une raison quelconque, n si l'ESC ne parvient pas à terminer la récupération avec succès, l'ESC marque cette machine virtuelle en état d'erreur.
3. Dans de tels scénarios, l'utilisateur peut effectuer une récupération manuelle de la machine virtuelle EM une fois le problème d'infrastructure sous-jacent résolu. Il est important d'exécuter cette récupération manuelle uniquement après la résolution d'un problème sous-jacent.
4. Identifiez la machine virtuelle en état d'erreur.
[stack@pod1-ospd ~]$ source corerc
[stack@pod1-ospd ~]$ nova list --field name,host,status |grep -i err
| c794207b-a51e-455e-9a53-3b8ff3520bb9 | vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8 | None | ERROR |
5. Connectez-vous à ESC Master, exécutez recovery-vm-action pour chaque machine virtuelle EM et CF affectée. Sois patient ! L'ESC planifie l'action de récupération et cela pourrait ne pas se produire pendant quelques minutes.
ubuntu@vnf1-uas-uas-1:~$ ssh admin@172.168.10.3
…
[admin@vnf1-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[sudo] password for admin:
Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<ok/>
</rpc-reply>
6. Surveillez le répertoire /var/log/esc/yangesc.log jusqu'à ce que la commande se termine.
[admin@vnf1-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN Status Code: 200
14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [vnf1-DEPLOYMENT-_vnf1-D_0_a6843886-77b4-4f38-b941-74eb527113a8]
#Log in to new EM and verify EM state is up.
ubuntu@vnf1vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on vnf1vnfddeploymentem-1
admin@scm# show ems
EM VNFM
ID SLA SCM PROXY
---------------------
2 up up up
3 up up up
Lorsque l'ESC ne démarre pas la machine virtuelle
1. 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 afin de vérifier s'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.
2. Vous pouvez surveiller /var/log/esc/yangesc.log et /var/log/esc/escmanager.log. Si vous constatez que la machine virtuelle n'est pas récupérée après 5 à 7 minutes, l'utilisateur doit procéder à la récupération manuelle des machines virtuelles affectées.
3. 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.
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 StarOS
1. Dans le cas où l'une des machines virtuelles StarOS apparaît dans l'état Aucun/Erreur en raison de l'une ou l'autre des conditions, l'utilisateur peut suivre cette séquence afin de récupérer la machine virtuelle StarOS affectée.
2. ESC/VNFM est le composant qui surveille les machines virtuelles StarOS de sorte que, dans le cas où la machine virtuelle CF/SF est en état d'erreur, ESC tentera de récupérer automatiquement la machine virtuelle CF/SF. Pour une raison quelconque, si l'ESC ne parvient pas à terminer la récupération avec succès, l'ESC marque cette machine virtuelle dans l'état Erreur.
3. Dans de tels scénarios, l'utilisateur peut récupérer manuellement la machine virtuelle CF/SF une fois le problème d'infrastructure sous-jacent résolu. Il est important d'exécuter cette récupération manuelle uniquement après avoir résolu un problème sous-jacent.
4. Identifiez la machine virtuelle à l'état Erreur.
[stack@pod1-ospd ~]$ source corerc
[stack@pod1-ospd ~]$ nova list --field name,host,status |grep -i err
| c794207b-a51e-455e-9a53-3b8ff3520bb9 | vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3 | None | ERROR |
5. Connectez-vous à ESC Master, exécutez recovery-vm-action pour chaque EM et CF VM.Be affecté. L'ESC planifie l'action de récupération et cela pourrait ne pas se produire pendant quelques minutes.
ubuntu@vnf1-uas-uas-1:~$ ssh admin@172.168.10.3
…
[admin@vnf1-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3
[sudo] password for admin:
Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<ok/>
</rpc-reply>
##Monitor the /var/log/esc/yangesc.log until command completes.
[admin@vnf1-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN Status Code: 200
14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [vnf1-DEPLOYMENT-_s4_0_c2b19084-26b3-4c9c-8639-62428a4cb3a3]
6. Validez également la même chose en exécutant l'onglet show card sur StarOS. Si la machine virtuelle récupérée est SF, l'utilisateur peut avoir besoin de la rendre active si elle le souhaite. Apportez les modifications nécessaires à la configuration de StarOS.
[local]VNF1# show card tab
Saturday December 02 14:40:20 UTC 2017
Slot Card Type Oper State SPOF Attach
----------- -------------------------------------- ------------- ---- ------
1: CFC Control Function Virtual Card Active No
2: CFC Control Function Virtual Card Standby -
3: FC 4-Port Service Function Virtual Card Active No
4: FC 4-Port Service Function Virtual Card Active No
5: FC 4-Port Service Function Virtual Card Active No
6: FC 4-Port Service Function Virtual Card Standby -
7: FC 4-Port Service Function Virtual Card Active No
8: FC 4-Port Service Function Virtual Card Active No
9: FC 4-Port Service Function Virtual Card Active No
10: FC 4-Port Service Function Virtual Card Active No
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 afin de 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 que la machine virtuelle est récupérée après 5 à 7 minutes, vous devez procéder à la récupération manuelle des machines virtuelles affectées.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
29-Aug-2018 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)