Remplacement PCRF du serveur de calcul UCS C240 M4

Introduction

Ce document décrit les étapes requises pour remplacer 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).

Informations générales

Ce document est destiné au personnel Cisco familier avec la plate-forme Cisco Ultra-M et décrit les étapes à suivre au niveau OpenStack et CPS VNF au moment du remplacement du serveur de calcul.

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

Contrôle médical

Avant de remplacer 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 lorsque le processus de remplacement de calcul est activé.

Étape 1. À partir d'OpenStack Deployment (OSPD). 

[root@director ~]$ su - stack
[stack@director ~]$ cd ansible
[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml  -e platform=pcrf

Étape 2. Vérifiez l'état du système à partir du rapport d'état ultram-health généré toutes les quinze minutes.

[stack@director ~]# cd /var/log/cisco/ultram-health

Étape 3. Vérifiez le fichier ultram_health_os.report.Les seuls services doivent apparaître car l'état XXX sont neutron-sriov-nic-agent.service.

Étape 4. Pour vérifier si le protocole rabbitmq s'exécute pour tous les contrôleurs à partir d'OSPD.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done

Étape 5. Vérifier que la colonne est activée

[stack@director ~]# sudo pcs property show stonith-enabled

Étape 6. Pour tous les contrôleurs, vérifiez l'état du PCS.

• Tous les noeuds de contrôleur sont démarrés sous haproxy-clone.
• Tous les noeuds de contrôleur sont actifs sous la galère.
• Tous les noeuds de contrôleur sont démarrés sous Rabbitmq.
• 1 noeud contrôleur est actif et 2 veille sous rouge.

 Étape 7. À partir d'OSPD.

[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done 

Étape 8. Vérifiez que tous les services openstack sont actifs, à partir d'OSPD exécutez cette commande.

[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

Étape 9. Vérifiez que l'état CEPH est HEALTH_OK pour les contrôleurs.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done

Étape 10. Vérifiez les journaux des composants OpenStack. Rechercher une erreur :

Neutron:
[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log

Cinder:
[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log

Glance:
[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log

Étape 11. À partir d'OSPD, exécutez ces vérifications pour l'API.

[stack@director ~]$ source 
     
     

[stack@director ~]$ nova list

[stack@director ~]$ glance image-list

[stack@director ~]$ cinder list

[stack@director ~]$ neutron net-list

Étape 12. Vérifiez l'état des services.

Every service status should be “up”:
[stack@director ~]$ nova service-list

Every service status should be “ :-)”:
[stack@director ~]$ neutron agent-list

Every service status should be “up”:
[stack@director ~]$ cinder service-list

Sauvegarde

En cas de récupération, Cisco recommande d'effectuer une sauvegarde de la base de données OSPD en procédant comme suit :

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

Afin de sauvegarder des machines virtuelles CPS, à partir de la machine virtuelle du Gestionnaire de cluster :

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz

or

[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).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'UUID (Universally Unique Identifier), la deuxième colonne correspond au nom de la machine virtuelle et la troisième au nom d'hôte où la machine virtuelle est présente. Les paramètres de cette sortie sont utilisés dans les sections suivantes.

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

Étape 1. Connexion à l'adresse IP de gestion de la machine virtuelle :

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

Étape 2. Si la machine virtuelle est un SM, un OAM ou un arbitre, 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

Étape 3. Pour chaque fichier intitulé sessionmgr-xxxxx, exécutez service sessionmgr-xxxxx stop :

  

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

  

Supprimer le noeud de calcul de la liste d'agrégats Nova

Étape 1. Énumérez les agrégats nova et identifiez l'agrégat qui correspond au serveur de calcul en fonction du VNF hébergé par celui-ci. Généralement, il s’agit du format <VNFNAME>-SERVICE<X> :

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

   Dans ce cas, le serveur de calcul à remplacer appartient à VNF2. Par conséquent, la liste agrégée correspondante est VNF2-SERVICE2.

Étape 2. Supprimer le noeud de calcul de l'agrégat identifié (supprimer par nom d'hôte noté dans la section Identifier les machines virtuelles hébergées dans le noeud de calcul 😞

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain

Étape 3. Vérifiez si le noeud de calcul est supprimé des agrégats. Maintenant, l'hôte ne doit pas être répertorié sous l'agrégat :

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

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

Supprimer du nuage

Étape 1. Créez un fichier de script nommé delete_node.sh avec le contenu comme indiqué ici. Assurez-vous que les modèles mentionnés sont identiques à ceux utilisés dans le script Deployment.sh utilisé pour le déploiement de la pile.

 delete_node.sh

 openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack 
     
      
       
     

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

Étape 2. Attendez que l'opération de pile OpenStack passe à l'état COMPLETE.

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Supprimer le noeud de calcul de la liste de services

Supprimer le service de calcul de la liste de services :

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep compute-8
| 404 | nova-compute     | pod1-compute-8.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete 
     
     
[stack@director ~]$ openstack compute service delete 404

Supprimer les agents neutres

Supprimez l'ancien agent neutron associé et l'agent vswitch ouvert pour le serveur de calcul :

[stack@director ~]$ openstack network agent list | grep compute-8
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete 
     
     

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

Supprimer de la base de données ironique

Supprimez un noeud de la base de données ironique et vérifiez-le.

[stack@director ~]$ source stackrc

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete 
     
     

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a 
[stack@director ~]$ ironic node-list (node delete must not be listed now) 

Installer le nouveau noeud de calcul

Les étapes permettant d'installer un nouveau serveur UCS C240 M4 et les étapes de configuration initiale peuvent être référencées à l'adresse suivante : Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

Étape 1. Après l'installation du serveur, insérez les disques durs dans les logements respectifs en tant qu'ancien serveur.

Étape 2. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.

Étape 3. Effectuez une mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée précédemment utilisée. Les étapes de mise à niveau du BIOS sont indiquées ici : Guide de mise à niveau du BIOS du serveur rack Cisco UCS série C

Étape 4. Afin de vérifier l'état des lecteurs physiques, accédez à Stockage > Contrôleur RAID modulaire SAS (SLOT-HBA) Cisco 12G > Informations sur le lecteur physique. Il doit être non configuré

Le stockage présenté ici peut être un disque SSD.

Étape 5. Afin de créer un lecteur virtuel à partir des disques physiques avec RAID de niveau 1, accédez à Stockage > Contrôleur RAID modulaire SAS (SLOT-HBA) Cisco 12G > Informations sur le contrôleur > Créer un lecteur virtuel à partir de disques physiques non utilisés

Étape 6. Sélectionnez la VD et configurez Set as Boot Drive, comme indiqué dans l'image.

Étape 7. Afin d'activer IPMI sur LAN, accédez à Admin > Communication Services > Communication Services, comme illustré dans l'image.

Étape 8. Afin de désactiver l'hyperthreading, comme illustré dans l'image, naviguez jusqu'à Compute > BIOS > Configure BIOS > Advanced > Processor Configuration.

Note: L'image ci-dessous et les étapes de configuration mentionnées dans cette section font référence à la version 3.0(3e) du micrologiciel et il peut y avoir de légères variations si vous travaillez sur d'autres versions

Ajouter le nouveau noeud de calcul au nuage

Les étapes mentionnées dans cette section sont communes indépendamment de la machine virtuelle hébergée par le noeud de calcul.

Étape 1. Ajouter un serveur de calcul avec un index différent.

Créez un fichier add_node.json avec uniquement les détails du nouveau serveur de calcul à ajouter. Assurez-vous que le numéro d'index du nouveau serveur de calcul n'est pas utilisé auparavant. Généralement, incrémentez la valeur de calcul la plus élevée suivante.

Exemple : Le plus haut précédent a donc été calcul-17, créé calcul-18 dans le cas d'un système 2-vnf. 

Note: Tenez compte du format json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "
     
     
       " 
     
            ],
            "capabilities": "node:compute-18,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

Étape 2. Importer le fichier json.

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

  

Étape 3. Exécutez l'introspection de noeud avec l'utilisation de l'UUID noté à l'étape précédente.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

Étape 4. Ajoutez des adresses IP à custom-templates/layout.yml sous ComputeIPs. Vous ajoutez cette adresse à la fin de la liste pour chaque type, le calcul 0 présenté ici comme exemple.

ComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take compute-0 .43 and add here

    tenant:

    - 11.117.0.43

    - 11.117.0.44

    - 11.117.0.45

    - 11.117.0.43   << and here

    storage:

    - 11.118.0.43

    - 11.118.0.44

    - 11.118.0.45

    - 11.118.0.43   << and here

Étape 5. Exécutez le script Deployment.sh précédemment utilisé pour déployer la pile, afin d'ajouter le nouveau noeud de calcul à la pile surnuage.

[stack@director ~]$ ./deploy.sh
++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
…
Starting new HTTP connection (1): 192.200.0.1
"POST /v2/action_executions HTTP/1.1" 201 1695
HTTP POST http://192.200.0.1:8989/v2/action_executions 201
Overcloud Endpoint: http://10.1.2.5:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud: 
END return value: 0

real   38m38.971s
user   0m3.605s
sys    0m0.466s

Étape 6. Attendez que l'état d'openstack soit Terminé.

[stack@director ~]$ openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

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

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-18
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-compute-18    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep compute-18
| 63 | pod1-compute-18.localdomain    |

Restaurer les machines virtuelles

Ajout à la liste d'agrégats Nova

Ajoutez le noeud de calcul à l'hôte agrégé et vérifiez si l'hôte est ajouté.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

Récupération VM à partir du contrôleur de services élastiques (ESC)

Étape 1. La machine virtuelle est en état d'erreur dans la liste nova.

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

Étape 2. Récupérez la machine virtuelle à partir 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

     
     

     
     
  
     
     

Étape 3. 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 Cisco Policy and Charging Rules Function (PCRF) qui résident sur la machine virtuelle

Note: Si la machine virtuelle est en état d'arrêt, 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 une erreur est détectée pour les machines virtuelles récupérées, puis

Étape 1. Connectez-vous à la machine virtuelle correspondante.

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

Étape 2. Si la machine virtuelle est un SM, OAM ou arbitre, en plus de lui, démarrez les services sessionmgr qui se sont arrêtés précédemment :

Pour chaque fichier intitulé sessionmgr-xxxxx, exécutez service sessionmgr-xxxxx start :

  

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

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

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

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

Supprimer et redéployer une ou plusieurs machines virtuelles en cas d'échec de récupération ESC

Si la commande de récupération ESC (ci-dessus) ne fonctionne pas (VM_RECOVERY_FAILED), supprimez et lisez les machines virtuelles individuelles.

Obtenir le dernier modèle ESC pour le site

À partir du portail ESC :

Étape 1. Placez votre curseur sur le bouton Action bleu, une fenêtre contextuelle s'ouvre, cliquez maintenant sur Exporter le modèle, comme l'illustre l'image.

Étape 2. Une option permettant de télécharger le modèle sur l'ordinateur local est présentée, cochez la case Enregistrer le fichier, comme indiqué dans l'image. 

Étape 3. Comme l'illustre l'image, sélectionnez un emplacement et enregistrez le fichier pour une utilisation ultérieure.

Étape 4. Connectez-vous à l'ESC actif pour que le site soit supprimé et copiez le fichier enregistré ci-dessus dans l'ESC de ce répertoire.

/opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Étape 5. Remplacer le répertoire par /opt/cisco/esc/cisco-cps/config/gr/tmo/gen :

cd /opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Procédure de modification du fichier

Étape 1. Modifiez le fichier de modèle d'exportation.

Au cours de cette étape, vous modifiez le fichier de modèle d'exportation pour supprimer le ou les groupes de machines virtuelles associés aux machines virtuelles qui doivent être restaurées.

Le fichier de modèle d'exportation concerne un cluster spécifique.

Au sein de ce cluster, il y a plusieurs groupes vm_groups.  Il existe un ou plusieurs groupes_vm pour chaque type de machine virtuelle (PD, PS, SM, OM).

Note: Certains groupes_vm ont plusieurs machines virtuelles.  Toutes les machines virtuelles de ce groupe seront supprimées et réajoutées.

Dans ce déploiement, vous devez marquer un ou plusieurs groupes vm_groups pour suppression.

Exemple :

               <groupe_vm>

                  <nom>cm</nom>

Maintenant, remplacez <vm_group>par <vm_group nc : opération="delete"> et enregistrez les modifications.

Étape 2. Exécutez le fichier modèle d'exportation modifié.

À partir de l'exécution ESC :

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

À partir du portail ESC, vous devriez pouvoir voir une ou plusieurs machines virtuelles qui passent à l'état de non-déploiement puis disparaissent complètement.

Les progrès peuvent être suivis dans le document /var/log/esc/yangesc.log

Exemple :

09:09:12,608 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUEST RECEIVED(UNDER TENANT) =====
09:09:12,608 29-Jan-2018 INFO  Tenant name: Pcrf
09:09:12,609 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:09:29,794 29-Jan-2018 INFO 
09:09:29,794 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:10:19,459 29-Jan-2018 INFO 
09:10:19,459 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:19,459 29-Jan-2018 INFO  Type: VM_UNDEPLOYED
09:10:19,459 29-Jan-2018 INFO  Status: SUCCESS
09:10:19,459 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:10:22,292 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:22,292 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:10:22,292 29-Jan-2018 INFO  Status: SUCCESS
09:10:22,292 29-Jan-2018 INFO  Status Code: 200

Étape 3. Modifiez le fichier de modèle d'exportation pour ajouter les machines virtuelles.

Au cours de cette étape, vous modifiez le fichier de modèle d'exportation pour réajouter le ou les groupes de machines virtuelles associés aux machines virtuelles en cours de récupération.

Le fichier de modèle d'exportation est divisé en deux déploiements (cluster1 / cluster2).

Au sein de chaque cluster se trouve un groupe_vm. Il existe un ou plusieurs groupes_vm pour chaque type de machine virtuelle (PD, PS, SM, OM).

Note: Certains groupes_vm ont plusieurs machines virtuelles.  Toutes les machines virtuelles de ce groupe seront réajoutées.

Exemple :

               <vm_group nc : opération=« delete »>

                  <nom>cm</nom>

Remplacez le <vm_group nc : opération=« delete »> par juste <vm_group>.

Note: Si les machines virtuelles doivent être reconstruites car l'hôte a été remplacé, le nom d'hôte de l'hôte peut avoir changé.  Si le nom d'hôte de l'hôte a changé, le nom d'hôte dans la section de placement du groupe_vm devra être mis à jour.

<placement>

                      <type>hôte_zone</type>

                     <application>stricte</application>

                      <host>wsstackovs-computing -4.localdomain</host>

</placement>

Mettez à jour le nom de l'hôte indiqué dans la section précédente vers le nouveau nom d'hôte fourni par l'équipe Ultra-M avant l'exécution de ce MOP. Après l'installation du nouvel hôte, enregistrez les modifications.

Étape 4. Exécutez le fichier modèle d'exportation modifié.

À partir de l'exécution ESC :

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

À partir du portail ESC, vous devriez voir réapparaître une ou plusieurs machines virtuelles, puis dans l'état Actif.

Les progrès peuvent être suivis dans le document /var/log/esc/yangesc.log

Exemple :

09:14:00,906 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUESTRECEIVED (UNDER TENANT) =====
09:14:00,906 29-Jan-2018 INFO  Tenant name: Pcrf
09:14:00,906 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:14:01,542 29-Jan-2018 INFO 
09:14:01,542 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:16:33,947 29-Jan-2018 INFO 
09:16:33,947 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:16:33,947 29-Jan-2018 INFO  Type: VM_DEPLOYED
09:16:33,947 29-Jan-2018 INFO  Status: SUCCESS
09:16:33,947 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,148 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,148 29-Jan-2018 INFO  Type: VM_ALIVE
09:19:00,148 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,148 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,275 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,275 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:19:00,275 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,275 29-Jan-2018 INFO  Status Code: 200

Étape 5. Vérifiez les services PCRF qui résident sur la machine virtuelle.

Vérifiez si les services PCRF sont arrêtés et démarrez-les.

[stack@XX-ospd ~]$ ssh root@
     
     
[root@XXXSM03 ~]# monsum
[root@XXXSM03 ~]# monit start all

Si la machine virtuelle est un SM, OAM ou arbitre, démarrez en outre les services sessionmgr qui se sont arrêtés précédemment :

Pour chaque fichier intitulé sessionmgr-xxxxx run service sessionmgr-xxxxx start :

  

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

 Si le diagnostic n'est toujours pas clair, exécutez build_all.sh à partir de la machine virtuelle du Gestionnaire de cluster, puis 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

Étape 6. Exécutez les Diagnostics pour vérifier l'état du système.

[root@XXXSM03 init.d]# diagnostics.sh

Informations connexes

• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
  
• Support et documentation techniques - Cisco Systems