Contenu

Introduction

Informations générales

Abréviations

Procédures de sauvegarde

Sauvegarde OSPD

Sauvegarde de déploiement automatique

Sauvegarde AutoIT-VNF

Sauvegarde AutoVNF

Sauvegarde ESC

Sauvegarde EM

Sauvegarde StarOS

Procédure de restauration

Récupération OSPD

Récupération du déploiement automatique

Récupération AutoIT-VNF

Récupération AutoVNF

Récupération ESC

Récupération EM

Récupération StarOS

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.

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

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.

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

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

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