Noeud de calcul Stop and Start de la fonction de règles de stratégie et de facturation

Introduction

Ce document décrit les étapes nécessaires pour arrêter le démarrage d'un serveur de calcul défectueux dans une configuration Ultra-M qui héberge les fonctions de réseau virtuel (VNF) de Cisco Policy Suite (CPS).

Note: La version Ultra M 5.1.x est prise en compte afin de définir les procédures de ce document. Ce document est destiné au personnel Cisco qui connaît la plate-forme Cisco Ultra-M et décrit les étapes à suivre au niveau OpenStack et CPS VNF au moment du démarrage du serveur de calcul.

Conditions préalables

Sauvegarde

Avant de démarrer un noeud Compute, il est important de vérifier l'état actuel de votre environnement Red Hat OpenStack Platform. Il est recommandé de vérifier l'état actuel afin d'éviter les complications.

En cas de récupération, Cisco recommande d'effectuer une sauvegarde de la base de données OSPD à l'aide de ces étapes.

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

Ce processus garantit qu'un noeud peut être remplacé sans affecter la disponibilité d'instances. Il est également recommandé de sauvegarder la configuration CPS.

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz

Identifier les machines virtuelles hébergées dans le noeud de calcul

Identifiez les machines virtuelles hébergées sur le serveur de calcul.

[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

Note: Dans le résultat présenté ici, la première colonne correspond à l'identificateur unique universel (UUID), la deuxième colonne correspond au nom de la machine virtuelle et la troisième au nom d'hôte de la machine virtuelle. Les paramètres de cette sortie seront utilisés dans les sections suivantes.

Désactiver les services PCRF résidant sur la machine virtuelle à arrêter

1. Connectez-vous à l'adresse IP de gestion de la machine virtuelle.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all

2. Si la machine virtuelle est unSM, OAMorArbiter, en outre, arrêtez les services sessionmgr.

[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

3. Pour chaque fichier intitulé sessionmgr-xxxxx run service sessionmgr-xxxxx stop.

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

Mise hors tension gracieuse

Arrêt de la machine virtuelle de l'ESC

1. Connectez-vous au noeud ESC correspondant au VNF et vérifiez l'état de la machine virtuelle.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

2. Arrêtez la machine virtuelle à l'aide de son nom de machine virtuelle. (Nom de la machine virtuelle indiqué dans la section " Identifier les machines virtuelles hébergées dans le noeud de calcul ").

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

 3. Une fois arrêté, la machine virtuelle doit entrer l'état SHUTOFF.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip> 

Arrêt-Démarrage du noeud de calcul

Les étapes mentionnées dans cette section sont communes indépendamment des machines virtuelles hébergées dans le noeud de calcul.

Noeud de calcul Stop-Start de l'OSPD

1. Vérifiez l'état, puis arrêtez-démarrez le noeud.

[stack@director ~]$ nova list | grep compute-10 
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ nova stop pod1-stack-compute-10

2. Attendez que le calcul soit à l'état Shutoff, puis recommencez.

[stack@director ~]$ nova start pod1-stack-compute-10

3. Vérifiez que le nouveau noeud de calcul est à l'état Actif.

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ source pod1-stackrc-Core
[stack@director ~]$ openstack hypervisor list |grep compute-10
| 6 | pod1-compute-10.localdomain    |

Restaurer les machines virtuelles

Récupération VM de l'ESC

1. Idéalement, à partir d'OSPD si vous cochez la liste nova, les machines virtuelles doivent être à l'état Arrêt. Dans ce cas, vous devez démarrer les machines virtuelles à partir de l'ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

2. Ou, si la machine virtuelle est dans l'état d'erreur dans la liste nova, exécutez cette configuration.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

3. Maintenant, récupérez la machine virtuelle de l'ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[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>

4. Surveillez yangesc.log.

admin@VNF2-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 [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

Vérifier les services PCRF résidant sur la machine virtuelle

Note: Si la machine virtuelle est à l'état SHUTOFF, mettez-la sous tension à l'aide de esc_nc_cli à partir de l'ESC. Vérifiez le fichier diagnostics.sh de la machine virtuelle du gestionnaire de cluster et si vous rencontrez une erreur trouvée pour les machines virtuelles qui sont récupérées, alors.

1. Connectez-vous à la machine virtuelle correspondante.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all

2. Si la machine virtuelle est unSM, OAMorArbiter, en outre, démarrez les services sessionmgr qui se sont arrêtés plus tôt. Pour chaque fichier intitulé sessionmgr-xxxxx, exécutez service sessionmgr-xxxxx start.

[root@XXXSM03 init.d]# service sessionmgr-27717 start

 3. Si le diagnostic n'est toujours pas clair, exécutez build_all.sh à partir de la machine virtuelle du Gestionnaire de cluster et exécutez VM-init sur la machine virtuelle correspondante.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init