Remplacement PCRF de l'OSD-Compute UCS 240M4

Introduction

Ce document décrit les étapes requises pour remplacer un serveur de calcul automatique de code 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 OSD-Compute.

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

À partir de OSPD

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

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

   Vérifiez le fichier ultram_health_os.report.

   Les seuls services doivent apparaître comme état XXX sont neutron-sriov-nic-agent.service.

Étape 2. Vérifiez si rabbitmq s'exécute pour tous les contrôleurs, qui à leur tour s'exécute à 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 3. Vérifier que le stonith est activé.

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

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 Master sous galère
• Tous les noeuds de contrôleur sont démarrés sous Rabbitmq
• 1 noeud contrôleur est Master et 2 Esclaves sous redis

À partir de 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 4. 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 5. 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 6. 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 7. À 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 8. 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 à l'aide de ces étapes.

Étape 1. Prenez Mysql dump.

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

Étape 2. Pour sauvegarder des machines virtuelles CPS à partir de la machine virtuelle Cluster Manager :

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

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

Étape 1. Le serveur de calcul contient le contrôleur de services élastiques (ESC).

[stack@director ~]$ nova list --field name,host,networks | grep osd-compute-1
| 50fd1094-9c0a-4269-b27b-cab74708e40c | esc | pod1-osd-compute-0.localdomain 
| tb1-orch=172.16.180.6; tb1-mgmt=172.16.181.3  

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 seront utilisés dans les sections suivantes.

Note: Si le noeud de calcul OSD à remplacer est complètement désactivé et inaccessible, passez à la section “ Supprimer le noeud de calcul Osd de la ” de liste d'agrégats Nova. Sinon, passez à la section suivante.

Étape 2. Vérifiez que CEPH a la capacité disponible pour permettre la suppression d'un seul serveur OSD.

[root@pod1-osd-compute-0 ~]# sudo ceph df

GLOBAL:

    SIZE       AVAIL      RAW USED     %RAW USED

    13393G     11804G        1589G         11.87

POOLS:

    NAME        ID    USED      %USED     MAX AVAIL     OBJECTS

    rbd         0          0         0         3876G           0

    metrics     1     4157M      0.10         3876G      215385

    images      2     6731M      0.17         3876G         897

    backups     3         0         0         3876G           0

    volumes     4      399G      9.34         3876G      102373

    vms         5      122G      3.06         3876G       31863


    
    

Étape 3. Vérifiez que l'état de l'arborescence osd ceph est actif sur le serveur osd-computing.

[heat-admin@pod1-osd-compute-0 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2  4.35999     host pod1-osd-compute-0

 0  1.09000         osd.0                          up  1.00000          1.00000

 3  1.09000         osd.3                          up 1.00000          1.00000

 6  1.09000         osd.6                          up  1.00000          1.00000

 9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod1-osd-compute-2

 1  1.09000        osd.1                          up  1.00000          1.00000

 4  1.09000         osd.4                          up  1.00000          1.00000

 7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

 2  1.09000         osd.2                          up  1.00000          1.00000

 5  1.09000         osd.5                          up  1.00000          1.00000

 8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

Étape 4. Les processus CEPH sont actifs sur le serveur osd-computing.

[root@pod1-osd-compute-0 ~]# systemctl list-units *ceph*

UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

ceph-osd@11.service               loaded active running Ceph object storage daemon

ceph-osd@2.service                loaded active running Ceph object storage daemon

ceph-osd@5.service                loaded active running Ceph object storage daemon

ceph-osd@8.service                loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice         loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice          loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                   loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                   loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target               loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                       loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once            

Étape 5. Désactivez et arrêtez chaque instance ceph, supprimez chaque instance de osd et démontez le répertoire. Répétez l'opération pour chaque instance de césure.

[root@pod1-osd-compute-0 ~]# systemctl disable ceph-osd@11



[root@pod1-osd-compute-0 ~]# systemctl stop ceph-osd@11



[root@pod1-osd-compute-0 ~]# ceph osd out 11

marked out osd.11.



[root@pod1-osd-compute-0 ~]# ceph osd crush remove osd.11

removed item id 11 name 'osd.11' from crush map



[root@pod1-osd-compute-0 ~]# ceph auth del osd.11

updated



[root@pod1-osd-compute-0 ~]# ceph osd rm 11

removed osd.11



[root@pod1-osd-compute-0 ~]# umount /var/lib/ceph/osd/ceph-11



[root@pod1-osd-compute-0 ~]# rm -rf /var/lib/ceph/osd/ceph-11

   (ou)

Étape 6. Le script Clean.sh peut être utilisé pour effectuer la tâche ci-dessus en même temps.

[heat-admin@pod1-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-11 ceph-3 ceph-6 ceph-8

[heat-admin@pod1-osd-compute-0 ~]$ /bin/sh clean.sh



[heat-admin@pod1-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

   i=`echo $c |cut -d'-' -f2`

   sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

done

sudo ceph osd tree 

Une fois que tous les processus OSD ont été migrés/supprimés, le noeud peut être supprimé du nuage.

Note: Lorsque CEPH est supprimé, le RAID HD VNF passe à l'état Dégradé, mais le disque dur doit toujours être accessible.

Mise hors tension gracieuse

Migration de l'ESC en mode veille

Étape 1. Connectez-vous à l'ESC hébergé dans le noeud de calcul et vérifiez qu'il est à l'état maître. Si oui, passez en mode veille.

[admin@esc esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy


[admin@esc ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@esc ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@esc ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

Étape 2. Supprimez le noeud Osd-Compute de la liste d'agrégats Nova.

• É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 doit être au format <VNFNAME>-EM-MGMT<X> et <VNFNAME>-CF-MGMT<X>

[stack@director ~]$ nova aggregate-list
+----+------+-------------------+
| Id | Name | Availability Zone |
+----+------+-------------------+
| 3 | esc1 | AZ-esc1 |
| 6 | esc2 | AZ-esc2 |
| 9 | aaa | AZ-aaa |
+----+------+-------------------+

Dans notre cas, le serveur osd-computing appartient à esc1. Donc, les agrégats qui correspondent seraient esc1

Étape 3. Supprimez le noeud osd-computing de l'agrégat identifié.

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host esc1 pod1-osd-compute-0.localdomain 

Étape 4. Vérifiez si le noeud osd-computing a été supprimé des agrégats. Maintenant, assurez-vous que l'hôte n'est pas répertorié sous les agrégats.

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show esc1
[stack@director ~]$

Suppression De Noeud Osd-Compute

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é. 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 Osd-Compute de la liste de services

Supprimez le service de calcul de la liste de services.

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep osd-compute-0
| 404 | nova-compute     | pod1-osd-compute-0.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 ouvrez l'agent vswitch pour le serveur de calcul.

[stack@director ~]$ openstack network agent list | grep osd-compute-0
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-osd-compute-0.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 Nova and Ironic

Supprimez un noeud de la liste nova avec la base de données ironique, puis vérifiez-le.

[stack@director ~]$ source stackrc

[stack@al01-pod1-ospd ~]$ nova list | grep osd-compute-0
| c2cfa4d6-9c88-4ba0-9970-857d1a18d02c | pod1-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.114 |

[stack@al01-pod1-ospd ~]$ nova delete c2cfa4d6-9c88-4ba0-9970-857d1a18d02c

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-osd-compute-0 | 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 de l'installation d'un nouveau serveur UCS C240 M4 et les étapes de configuration initiale peuvent être référencées à partir du 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. 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. Vérifiez l'état des lecteurs physiques. Il doit être Non Conçu Bon.

Étape 5. Créez un lecteur virtuel à partir des lecteurs physiques avec RAID Niveau 1.

Étape 6. Accédez à la section Stockage et sélectionnez le contrôleur de raid modulaire Cisco 12G Sas et vérifiez l'état et l'état du contrôleur de raid, comme illustré dans l'image.

Note: L'image ci-dessus n'est utilisée qu'à titre d'illustration. Dans le CIMC OSD-Compute réel, sept disques physiques sont présents dans les logements [1,2,3,7,8,9,10] à l'état Bon non configuré, car aucun disque virtuel n'est créé à partir de ces logements.

Étape 7. Maintenant, créez un lecteur virtuel à partir d'un lecteur physique inutilisé à partir des informations du contrôleur, sous le contrôleur RAID modulaire SAS 12G de Cisco.

Étape 8. Sélectionnez VD et configurez le jeu comme lecteur de démarrage.

Étape 9. Activez IPMI sur LAN à partir des services de communication sous l'onglet Admin.

Étape 10. Désactivez Hyper-Threading à partir de la configuration du BIOS avancé sous le noeud Calcul, comme illustré dans l'image.

Étape 11. Similaire à BOOTOS VD créé avec les lecteurs physiques 1 et 2 , créez quatre lecteurs virtuels supplémentaires comme 

JOURNAL - À partir du lecteur physique numéro 3

OSD1 - À partir du lecteur physique numéro 7

OSD2 - À partir du lecteur physique numéro 8

OSD3 - À partir du lecteur physique numéro 9

OSD4 - À partir du lecteur physique numéro 10

Étape 7. En fin de compte, les disques physiques et virtuels doivent être similaires.

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

Ajouter le nouveau noeud OSD-Compute au nuage Overcloud

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 osd-computing n'a pas été utilisé auparavant. Généralement, incrémentez la valeur de calcul la plus élevée suivante.

Exemple : Le plus élevé précédent était osd-compute-0 ainsi créé osd-computing-3 dans le cas d'un système 2-vnf. 

Note: Tenez compte du format json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:osd-compute-3,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 OsdComputeIPs. Dans ce cas, lorsque vous remplacez osd-computing-0, vous ajoutez cette adresse à la fin de la liste pour chaque type.

OsdComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take osd-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

    storage_mgmt:

    - 11.119.0.43

    - 11.119.0.44

    - 11.119.0.45

    - 11.119.0.43   << and here

Étape 5. Exécutez le script déploiement.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 | pod1       | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Étape 7. Vérifiez que le nouveau noeud osd-computing est à l'état Actif.

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

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

Étape 8. Connectez-vous au nouveau serveur osd-computing et vérifiez les processus ceph. Initialement, l'état est dans HEALTH_WARN au fur et à mesure de la récupération de la céphalée.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666

     health HEALTH_WARN

            223 pgs backfill_wait

            4 pgs backfilling

            41 pgs degraded

            227 pgs stuck unclean

            41 pgs undersized

            recovery 45229/1300136 objects degraded (3.479%)

            recovery 525016/1300136 objects misplaced (40.382%)

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

     osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs

            flags sortbitwise,require_jewel_osds

      pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1553 GB used, 11840 GB / 13393 GB avail

            45229/1300136 objects degraded (3.479%)

            525016/1300136 objects misplaced (40.382%)

                 477 active+clean

                 186 active+remapped+wait_backfill

                  37 active+undersized+degraded+remapped+wait_backfill

                   4 active+undersized+degraded+remapped+backfilling

Étape 9. Cependant, après une courte période (20 minutes), CEPH revient à l'état HEALTH_OK.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666

     health HEALTH_OK

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

     osdmap e1398: 12 osds: 12 up, 12 in

            flags sortbitwise,require_jewel_osds

      pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1599 GB used, 11793 GB / 13393 GB avail

                 704 active+clean

  client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr



[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-3  4.35999     host pod1-osd-compute-2

 1  1.09000         osd.1                          up  1.00000          1.00000

 4  1.09000         osd.4                          up  1.00000          1.00000

 7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

 2  1.09000         osd.2                          up  1.00000          1.00000

 5  1.09000         osd.5                          up  1.00000          1.00000

 8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

-5  4.35999     host pod1-osd-compute-3

 0  1.09000         osd.0                          up  1.00000          1.00000

 3  1.09000         osd.3                          up  1.00000          1.00000

 6  1.09000         osd.6                          up  1.00000          1.00000

 9  1.09000         osd.9                          up  1.00000          1.00000

Restaurer les machines virtuelles

  

Ajout à la liste d'agrégats Nova

Ajoutez le noeud osd-computing aux agrégats-hosts et vérifiez si l'hôte est ajouté.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host esc1 pod1-osd-compute-3.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show esc1
+----+------+-------------------+----------------------------------------+------------------------------------------+
| Id | Name | Availability Zone | Hosts | Metadata |
+----+------+-------------------+----------------------------------------+------------------------------------------+
| 3 | esc1 | AZ-esc1 | 'pod1-osd-compute-3.localdomain' | 'availability_zone=AZ-esc1', 'esc1=true' |
+----+------+-------------------+----------------------------------------+------------------------------------------+

Récupération de la machine virtuelle ESC

Étape 1. Vérifiez l'état de la machine virtuelle ESC dans la liste nova et supprimez-la.

stack@director scripts]$ nova list |grep esc
| c566efbf-1274-4588-a2d8-0682e17b0d41 | esc                                                | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete esc
Request to delete server esc has been accepted.

If can not delete esc then use command: nova force-delete esc

Étape 2. Dans OSPD, accédez au répertoire ECS-Image et vérifiez que les fichiers bootvm.py et qcow2 pour la version ESC sont présents, si ce n'est pour le déplacer vers un répertoire.

[stack@atospd ESC-Image-157]$ ll

total 30720136

-rw-r--r--. 1 root  root       127724 Jan 23 12:51 bootvm-2_3_2_157a.py

-rw-r--r--. 1 root  root           55 Jan 23 13:00 bootvm-2_3_2_157a.py.md5sum

-rw-rw-r--. 1 stack stack 31457280000 Jan 24 11:35 esc-2.3.2.157.qcow2

Étape 3. Créez l'image.

[stack@director ESC-image-157]$  glance image-create --name ESC-2_3_2_157 --disk-format "qcow2" --container "bare" --file /home/stack/ECS-Image-157/ESC-2_3_2_157.qcow2

Étape 4. Vérifiez que l'image ESC existe.

stack@director ~]$ glance image-list
+--------------------------------------+--------------------------------------+
| ID                                   | Name                                 |
+--------------------------------------+--------------------------------------+
| 8f50acbe-b391-4433-aa21-98ac36011533 | ESC-2_3_2_157|
| 2f67f8e0-5473-467c-832b-e07760e8d1fa | tmobile-pcrf-13.1.1.iso              |
| c5485c30-45db-43df-831d-61046c5cfd01 | tmobile-pcrf-13.1.1.qcow2            |
| 2f84b9ec-61fa-46a3-a4e6-45f14c93d9a9 | tmobile-pcrf-13.1.1_cco_20170825.iso |
| 25113ecf-8e63-4b81-a73f-63606781ef94 | wscaaa01-sept072017                  |
| 595673e8-c99c-40c2-82b1-7338325024a9 | wscaaa02-sept072017                  |
| 8bce3a60-b3b0-4386-9e9d-d99590dc9033 | wscaaa03-sept072017                  |
| e5c835ad-654b-45b0-8d36-557e6c5fd6e9 | wscaaa04-sept072017                  |
| 879dfcde-d25c-4314-8da0-32e4e73ffc9f | WSP1_cluman_12_07_2017               |
| 7747dd59-c479-4c8a-9136-c90ec894569a | WSP2_cluman_12_07_2017               |
+--------------------------------------+--------------------------------------+

[stack@ ~]$ openstack flavor list
+--------------------------------------+------------+--------+------+-----------+-------+-----------+
| ID                                   | Name       |    RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+------------+--------+------+-----------+-------+-----------+
| 1e4596d5-46f0-46ba-9534-cfdea788f734 | pcrf-smb   | 100352 |  100 |         0 |     8 | True      |
| 251225f3-64c9-4b19-a2fc-032a72bfe969 | pcrf-oam   |  65536 |  100 |         0 |    10 | True      |
| 4215d4c3-5b2a-419e-b69e-7941e2abe3bc | pcrf-pd    |  16384 |  100 |         0 |    12 | True      |
| 4c64a80a-4d19-4d52-b818-e904a13156ca | pcrf-qns   |  14336 |  100 |         0 |    10 | True      |
| 8b4cbba7-40fd-49b9-ab21-93818c80a2e6 | esc-flavor |   4096 |    0 |         0 |     4 | True      |
| 9c290b80-f80a-4850-b72f-d2d70d3d38ea | pcrf-sm    | 100352 |  100 |         0 |    10 | True      |
| e993fc2c-f3b2-4f4f-9cd9-3afc058b7ed1 | pcrf-arb   |  16384 |  100 |         0 |     4 | True      |
| f2b3b925-1bf8-4022-9f17-433d6d2c47b5 | pcrf-cm    |  14336 |  100 |         0 |     6 | True      |
+--------------------------------------+------------+--------+------+-----------+-------+-----------+

Étape 5. Créez ce fichier sous le répertoire image et lancez l'instance ESC.

[root@director ESC-IMAGE]# cat esc_params.conf 
openstack.endpoint = publicURL

[root@director ESC-IMAGE]./bootvm-2_3_2_157a.py esc --flavor esc-flavor --image ESC-2_3_2_157 --net tb1-mgmt --gateway_ip 172.16.181.1 --net tb1-orch --enable-http-rest --avail_zone AZ-esc1 --user_pass "admin:Cisco123" --user_confd_pass "admin:Cisco123" --bs_os_auth_url http://10.250.246.137:5000/v2.0 --kad_vif eth0 --kad_vip 172.16.181.5 --ipaddr 172.16.181.4 dhcp --ha_node_list 172.16.181.3 172.16.181.4 --esc_params_file esc_params.conf

Note: Une fois la machine virtuelle ESC problématique redéployée avec exactement la même commande bootvm.py que l'installation initiale, ESC HA effectue la synchronisation automatiquement sans aucune procédure manuelle. Assurez-vous que le maître ESC est actif et fonctionne.

Étape 6. Connectez-vous au nouvel ESC et vérifiez l'état de sauvegarde.

[admin@esc ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) ===================================================
ESC HEALTH PASSED