Remplacement du serveur UCS C240 M4 de contrôleur - vEPC

Introduction

Ce document décrit l'étape nécessaire pour remplacer un serveur défectueux de contrôleur dans un Ultra-M installé qui héberge des fonctions réseau virtuelles de StarOS (VNFs).

Informations générales

Ultra-M est une solution mobile virtualisée préemballée et validée de noyau de paquet qui est conçue afin de simplifier le déploiement de VNFs. OpenStack est le gestionnaire virtualisé d'infrastructure (SCORE) pour Ultra-M et se compose de ces types de noeud :

• Calcul
• Disque de mémoire d'objet - Calcul (OSD - Calcul)
• Contrôleur
• Plate-forme d'OpenStack - Directeur (OSPD)

L'architecture de haut niveau d'Ultra-M et les composants impliqués sont dépeints dans cette image :

Architecture d'UltraM

Ce document est destiné pour le personnel de Cisco qui sont au courant de la plate-forme de Cisco Ultra-M et elle détaille les étapes qui sont exigées pour être effectuées au niveau d'OpenStack et de StarOS VNF au moment du remplacement de serveur de contrôleur.

Remarque: Ultra la release M 5.1.x est considérée comme afin de définire les procédures dans ce document.

Abréviations

Processus du balai

Processus de haut niveau de la procédure de remplacement

Conditions préalables

Sauvegarde

En cas de reprise, Cisco recommande de prendre une sauvegarde de la base de données OSPD (DB) avec l'utilisation 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

Contrôle préliminaire d'état

Il est important de vérifier l'état actuel de l'environnement et des services d'OpenStack et de s'assurer qu'il est sain avant que vous poursuiviez la procédure de remplacement. Il peut aider à éviter des complications au moment du processus de remplacement de contrôleur.

• Vérifiez le statut d'OpenStack et de la liste de noeud :

[stack@director ~]$ source stackrc 
[stack@director ~]$ openstack stack list --nested
[stack@director ~]$ ironic node-list
[stack@director ~]$ nova list

• Vérifiez l'état de stimulateur sur des contrôleurs :

Ouvrez une session à un des contrôleurs actifs et vérifiez l'état de stimulateur. Tous les services devraient s'exécuter sur les contrôleurs disponibles et arrêté sur le contrôleur défectueux.

[stack@pod1-controller-0 ~]# pcs status

<snip>
Online: [ pod1-controller-0 pod1-controller-1 ]
OFFLINE: [ pod1-controller-2 ]
Full list of resources:
 ip-11.120.0.109 (ocf::heartbeat:IPaddr2): Started pod1-controller-0
 ip-172.25.22.109 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.107 (ocf::heartbeat:IPaddr2): Started pod1-controller-0

 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-0 pod1-controller-1 ]
 Stopped: [ pod1-controller-2 ]

 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-0 pod1-controller-1 ]
 Stopped: [ pod1-controller-2 ]
 ip-11.120.0.110 (ocf::heartbeat:IPaddr2): Started pod1-controller-0
 ip-11.119.0.110 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 ]
 Stopped: [ pod1-controller-2 ]

 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-0 ]
 Slaves: [ pod1-controller-1 ]
 Stopped: [ pod1-controller-2 ]

 ip-11.118.0.104 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-0

 my-ipmilan-for-controller-6 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-4 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-7 (stonith:fence_ipmilan): Started pod1-controller-0

Failed Actions:
Daemon Status:

 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Dans cet exemple, Controller-2 est hors ligne. Il sera donc remplacé. Controller-0 et Controller-1 sont opérationnels et exécutent les services de batterie. 

• État de MariaDB de contrôle dans les contrôleurs actifs :

[stack@director] nova list | grep control
| 4361358a-922f-49b5-89d4-247a50722f6d | pod1-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.102 |
| d0f57f27-93a8-414f-b4d8-957de0d785fc | pod1-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.110 |

[stack@director ~]$ for i in 192.200.0.102 192.200.0.110 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done
*** 192.200.0.152 ***
Variable_name     Value
wsrep_local_state_comment  Synced
Variable_name     Value
wsrep_cluster_size         2
*** 192.200.0.154 ***
Variable_name     Value
wsrep_local_state_comment  Synced
Variable_name     Value
wsrep_cluster_size         2

Vérifiez que ces lignes sont présentes pour chaque contrôleur actif :

wsrep_local_state_comment : Synced

wsrep_cluster_size : 2

•  État de Rabbitmq de contrôle dans les contrôleurs actifs. Le contrôleur défectueux ne devrait pas apparaître dans la liste des Noeuds courants.

[heat-admin@pod1-controller-0 ~] sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@pod1-controller-0' ...
[{nodes,[{disc,['rabbit@pod1-controller-0','rabbit@pod1-controller-1',
                'rabbit@pod1-controller-2']}]},
{running_nodes,['rabbit@pod1-controller-1',
                 'rabbit@pod1-controller-0']},
 {cluster_name,<<"rabbit@pod1-controller-2.localdomain">>},
 {partitions,[]},
 {alarms,[{'rabbit@pod1-controller-1',[]},
          {'rabbit@pod1-controller-0',[]}]}]


[heat-admin@pod1-controller-1 ~] sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@pod1-controller-1' ...
[{nodes,[{disc,['rabbit@pod1-controller-0','rabbit@pod1-controller-1',
                'rabbit@pod1-controller-2']}]},
 {running_nodes,['rabbit@pod1-controller-0',
                 'rabbit@pod1-controller-1']},
 {cluster_name,<<"rabbit@pod1-controller-2.localdomain">>},
 {partitions,[]},
 {alarms,[{'rabbit@pod1-controller-0',[]},
          {'rabbit@pod1-controller-1',[]}]}]

• Vérifiez si tous les services d'undercloud sont dans chargé, active et état courant 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'.

Débronchement clôturant la batterie de contrôleur

[root@pod1-controller-0 ~]# sudo pcs property set stonith-enabled=false
[root@pod1-controller-0 ~]# pcs property show

Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: tripleo_cluster
 dc-version: 1.1.15-11.el7_3.4-e174ec8
 have-watchdog: false
 last-lrm-refresh: 1510809585
 maintenance-mode: false
 redis_REPL_INFO: pod1-controller-0
stonith-enabled: false

Node Attributes:
 pod1-controller-0: rmq-node-attr-last-known-rabbitmq=rabbit@pod1-controller-0
 pod1-controller-1: rmq-node-attr-last-known-rabbitmq=rabbit@pod1-controller-1
 pod1-controller-2: rmq-node-attr-last-known-rabbitmq=rabbit@pod1-controller-2

Installez le nouveau noeud de contrôleur

• Les étapes afin d'installer un nouveau serveur UCS C240 M4 et les étapes de première installation peuvent être référées de :

Installation de serveur du Cisco UCS C240 M4 et guide de service

• Ouvrez une session au serveur avec l'utilisation de l'IP CIMC

• Exécutez la mise à jour du BIOS si le micrologiciel n'est pas selon la version recommandée utilisée précédemment. Des étapes pour la mise à jour du BIOS sont indiquées ici :

Guide de mise à jour du BIOS de Serveur rack Cisco UCS série C

Mémoire > contrôleur modulaire d'incursion de Cisco 12G SAS (SLOT-HBA) > les informations physiques d'entraînement

• Créez une unité de disques virtuelle des lecteurs physiques avec le niveau 1 RAID :

La mémoire > le contrôleur modulaire d'incursion de Cisco 12G SAS (SLOT-HBA) > les informations de contrôleur > créent l'unité de disques virtuelle des lecteurs physiques inutilisés

• Sélectionnez le VD et configurez le positionnement comme lecteur de démarrage :

• Enable IPMI au-dessus de RÉSEAU LOCAL :

Admin > services de communication > services de communication

• Débronchement hyperthreading :

Le calcul > le BIOS > configurent BIOS > ont avancé > configuration de processeur

Remarque: L'image affichée ici et les étapes de configuration mentionnées dans cette section sont concernant la version 3.0(3e) de micrologiciels et il pourrait y avoir de légères variations si vous travaillez sur d'autres versions.

Le remplacement de noeud de contrôleur se couvrent dedans

Cette section couvre les étapes qui sont exigées afin de remplacer le contrôleur défectueux par le neuf dans le couvrir. Pour ceci, le script de deploy.sh qui a été utilisé pour apporter la pile serait réutilisé. Au moment du déploiement, pendant la phase de ControllerNodesPostDeployment, la mise à jour échouerait en raison de quelques limites dans les modules de marionnette. L'intervention manuelle est exigée avant que vous redémarriez le script de déploiement.

Préparez pour retirer le noeud défectueux de contrôleur

• Identifiez l'index du contrôleur défectueux. L'index est le suffixe numérique sur le nom de contrôleur dans la sortie de liste de serveur d'OpenStack. Dans cet exemple, l'index est 2 :

[stack@director ~]$ nova list | grep controller
| 5813a47e-af27-4fb9-8560-75decd3347b4 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.152 |
| 457f023f-d077-45c9-bbea-dd32017d9708 | pod1-controller-1  | ACTIVE | -          | Running     | ctlplane=192.200.0.154 |
| d13bb207-473a-4e42-a1e7-05316935ed65 | pod1-controller-2  | ACTIVE | -          | Running     | ctlplane=192.200.0.151 |

• Créez un fichier ~templates/remove-controller.yaml de Yaml qui définirait le noeud pour supprimer. Utilisez l'index trouvé dans l'étape précédente pour l'entrée dans la liste de ressource :

[stack@director ~]$ cat templates/remove-controller.yaml

parameters:
  ControllerRemovalPolicies:
    [{'resource_list': [‘2’]}]  

parameter_defaults:
  CorosyncSettleTries: 5

• Tirez une copie du script de déployer qui est utilisé afin d'installer le couvrir et insérer une ligne afin d'inclure le fichier créé remove-controller.yaml précédemment :

[stack@director ~]$ cp deploy.sh deploy-removeController.sh
[stack@director ~]$ cat deploy-removeController.sh
time openstack overcloud deploy --templates \
-r ~/custom-templates/custom-roles.yaml \
-e /home/stack/templates/remove-controller.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 ~/custom-templates/network.yaml \
-e ~/custom-templates/ceph.yaml \
-e ~/custom-templates/compute.yaml \
-e ~/custom-templates/layout-removeController.yaml \
-e ~/custom-templates/rabbitmq.yaml \
--stack pod1 \
--debug \
--log-file overcloudDeploy_$(date +%m_%d_%y__%H_%M_%S).log \
--neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 \
--neutron-network-vlan-ranges datacentre:101:200 \ 
--neutron-disable-tunneling \ 
--verbose --timeout 180

• Identifiez l'ID du contrôleur à remplacer, par l'utilisation des commandes mentionnées ici et déplacez-le au mode maintenance :

[stack@director ~]$ nova list | grep controller

| 5813a47e-af27-4fb9-8560-75decd3347b4 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.152 |

| 457f023f-d077-45c9-bbea-dd32017d9708 | pod1-controller-1  | ACTIVE | -          | Running     | ctlplane=192.200.0.154 |

| d13bb207-473a-4e42-a1e7-05316935ed65 | pod1-controller-2  | ACTIVE | -          | Running     | ctlplane=192.200.0.151 |


[stack@director ~]$ openstack baremetal node list | grep d13bb207-473a-4e42-a1e7-05316935ed65

| e7c32170-c7d1-4023-b356-e98564a9b85b | None | d13bb207-473a-4e42-a1e7-05316935ed65 | power off   | active             | False       |


[stack@b10-ospd ~]$ openstack baremetal node maintenance set e7c32170-c7d1-4023-b356-e98564a9b85b


[stack@director~]$ openstack baremetal node list | grep True

| e7c32170-c7d1-4023-b356-e98564a9b85b | None | d13bb207-473a-4e42-a1e7-05316935ed65 | power off   | active             | True        |

• Afin de s'assurer que le DB fonctionne au moment de la procédure de remplacement, retirez Galera du contrôle de stimulateur et exécutez cette commande sur un des contrôleurs actifs :

[root@pod1-controller-0 ~]# sudo pcs resource unmanage galera
[root@pod1-controller-0 ~]# sudo pcs status

Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-0 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Thu Nov 16 16:51:18 2017                   Last change: Thu Nov 16 16:51:12 2017 by root via crm_resource on pod1-controller-0
3 nodes and 22 resources configured
Online: [ pod1-controller-0 pod1-controller-1 ]
OFFLINE: [ pod1-controller-2 ]

Full list of resources:

 ip-11.120.0.109          (ocf::heartbeat:IPaddr2):        Started pod1-controller-0
 ip-172.25.22.109        (ocf::heartbeat:IPaddr2):        Started pod1-controller-1
 ip-192.200.0.107        (ocf::heartbeat:IPaddr2):        Started pod1-controller-0

 Clone Set: haproxy-clone [haproxy]
     Started: [ pod1-controller-0 pod1-controller-1 ]
     Stopped: [ pod1-controller-2 ]

Master/Slave Set: galera-master [galera] (unmanaged)
     galera         (ocf::heartbeat:galera):          Master pod1-controller-0 (unmanaged)
     galera         (ocf::heartbeat:galera):          Master pod1-controller-1 (unmanaged)

     Stopped: [ pod1-controller-2 ]
 ip-11.120.0.110          (ocf::heartbeat:IPaddr2):        Started pod1-controller-0
 ip-11.119.0.110          (ocf::heartbeat:IPaddr2):        Started pod1-controller-1

<snip>

Préparez pour ajouter le nouveau noeud de contrôleur

• Créez un fichier controllerRMA.json avec seulement les nouveaux détails de contrôleur. Assurez-vous que l'index sur le nouveau contrôleur n'a pas été utilisé avant.  Typiquement, incrément au prochain nombre de contrôleur le plus élevé.

Exemple : Antérieur le plus élevé était Controller-2, ainsi créez Controller-3. 

Remarque: Soyez conscient du format de json.

[stack@director ~]$ cat controllerRMA.json
{
    "nodes": [
        {
            "mac": [
                <MAC_ADDRESS>
            ],
            "capabilities": "node:controller-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": "<CIMC_IP>"
        }
    ]
}

• Importez le nouveau noeud avec l'utilisation du fichier créé de json dans l'étape précédente :

[stack@director ~]$ openstack baremetal import --json controllerRMA.json

Started Mistral Workflow. Execution ID: 67989c8b-1225-48fe-ba52-3a45f366e7a0

Successfully registered node UUID 048ccb59-89df-4f40-82f5-3d90d37ac7dd

Started Mistral Workflow. Execution ID: c6711b5f-fa97-4c86-8de5-b6bc7013b398

Successfully set all nodes to available.

[stack@director ~]$ openstack baremetal node list | grep available

| 048ccb59-89df-4f40-82f5-3d90d37ac7dd | None | None                                 | power off   | available          | False

•  Placez le noeud pour gérer l'état :

[stack@director ~]$ openstack baremetal node manage 048ccb59-89df-4f40-82f5-3d90d37ac7dd 
[stack@director ~]$ openstack baremetal node list | grep off 
| 048ccb59-89df-4f40-82f5-3d90d37ac7dd | None | None | power off | manageable | False | 

• Exécutez l'introspection :

[stack@director ~]$ openstack overcloud node introspect 048ccb59-89df-4f40-82f5-3d90d37ac7dd --provide
Started Mistral Workflow. Execution ID: f73fb275-c90e-45cc-952b-bfc25b9b5727
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: a892b456-eb15-4c06-b37e-5bc3f6c37c65
Successfully set all nodes to available

[stack@director ~]$ openstack baremetal node list | grep available
| 048ccb59-89df-4f40-82f5-3d90d37ac7dd | None | None                                 | power off   | available          | False       | 

• Marquez le noeud disponible avec les nouvelles propriétés de contrôleur. Assurez pour utiliser l'ID de contrôleur indiqué pour le nouveau contrôleur, comme utilisé dans le fichier controllerRMA.json :

[stack@director ~]$ openstack baremetal node set --property capabilities='node:controller-3,profile:control,boot_option:local' 048ccb59-89df-4f40-82f5-3d90d37ac7dd  

• Dans le script de déployer, il y a un modèle personnalisé appelé le layout.yaml qui notamment, spécifie quelles adresses IP sont assignées aux contrôleurs pour les diverses interfaces. Sur une nouvelle pile, il y a 3 adresses définies pour Controller-0, Controller-1, et Controller-2. Quand vous ajoutez un nouveau contrôleur, assurez-vous que vous ajoutez une prochaine adresse IP dans l'ordre pour chaque sous-réseau :

ControllerIPs:
 internal_api:
 - 11.120.0.10
 - 11.120.0.11
 - 11.120.0.12
 - 11.120.0.13
 tenant:
 - 11.117.0.10
 - 11.117.0.11
 - 11.117.0.12
 - 11.117.0.13
 storage:
 - 11.118.0.10 
 - 11.118.0.11
 - 11.118.0.12
 - 11.118.0.13
 storage_mgmt:
 - 11.119.0.10 
 - 11.119.0.11
 - 11.119.0.12
 - 11.119.0.13

• Exécutez maintenant deploy-removecontroller.sh qui a été précédemment créé, afin de retirer le vieux noeud et ajouter le nouveau noeud.
  
  

Remarque: On s'attend à ce que cette étape échoue dans ControllerNodesDeployment_Step1. À ce moment là, l'intervention manuelle est exigée.

[stack@b10-ospd ~]$ ./deploy-addController.sh
START with options: [u'overcloud', u'deploy', u'--templates', u'-r', u'/home/stack/custom-templates/custom-roles.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml', u'-e', u'/home/stack/custom-templates/network.yaml', u'-e', u'/home/stack/custom-templates/ceph.yaml', u'-e', u'/home/stack/custom-templates/compute.yaml', u'-e', u'/home/stack/custom-templates/layout-removeController.yaml', u'-e', u'/home/stack/custom-templates/rabbitmq.yaml', u'--stack', u'newtonoc', u'--debug', u'--log-file', u'overcloudDeploy_11_15_17__07_46_35.log', u'--neutron-flat-networks', u'phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1', u'--neutron-network-vlan-ranges', u'datacentre:101:200', u'--neutron-disable-tunneling', u'--verbose', u'--timeout', u'180']
  :
DeploymentError: Heat Stack update failed
END return value: 1

real     42m1.525s
user     0m3.043s
sys      0m0.614s

La progression/statut du déploiement peut être surveillée avec ces commandes :

[stack@director~]$ openstack stack list --nested | grep -iv complete

+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------------+----------------------+--------------------------------------+

| ID                                   | Stack Name                                                                                                                                                              | Stack Status    | Creation Time        | Updated Time         | Parent                               |

+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------------+----------------------+--------------------------------------+

| c1e338f2-877e-4817-93b4-9a3f0c0b3d37 | pod1-AllNodesDeploySteps-5psegydpwxij-ComputeDeployment_Step1-swnuzjixac43                                                                                          | UPDATE_FAILED   | 2017-10-08T14:06:07Z | 2017-11-16T18:09:43Z | e90f00ef-2499-4ec3-90b4-d7def6e97c47 |

| 1db4fef4-45d3-4125-bd96-2cc3297a69ff | pod1-AllNodesDeploySteps-5psegydpwxij-ControllerDeployment_Step1-hmn3hpruubcn                                                                                       | UPDATE_FAILED   | 2017-10-08T14:03:05Z | 2017-11-16T18:12:12Z | e90f00ef-2499-4ec3-90b4-d7def6e97c47 |

| e90f00ef-2499-4ec3-90b4-d7def6e97c47 | pod1-AllNodesDeploySteps-5psegydpwxij                                                                                                                               | UPDATE_FAILED   | 2017-10-08T13:59:25Z | 2017-11-16T18:09:25Z | 6c4b604a-55a4-4a19-9141-28c844816c0d |

| 6c4b604a-55a4-4a19-9141-28c844816c0d | pod1                                                                                                                                                              | UPDATE_FAILED   | 2017-10-08T12:37:11Z | 2017-11-16T17:35:35Z | None                                 |

+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------------+----------------------+--------------------------------------+

Intervention manuelle 

• Sur le serveur OSP-D, exécutez la commande de liste de serveur d'OpenStack afin de répertorier les contrôleurs disponibles. Le contrôleur nouvellement ajouté devrait apparaître dans la liste :

[stack@director ~]$ openstack server list | grep controller
| 3e6c3db8-ba24-48d9-b0e8-1e8a2eb8b5ff | pod1-controller-3  | ACTIVE | ctlplane=192.200.0.103 | overcloud-full |
| 457f023f-d077-45c9-bbea-dd32017d9708 | pod1-controller-1  | ACTIVE | ctlplane=192.200.0.154 | overcloud-full |
| 5813a47e-af27-4fb9-8560-75decd3347b4 | pod1-controller-0  | ACTIVE | ctlplane=192.200.0.152 | overcloud-full |

• Connectez à un des contrôleurs actifs (pas le contrôleur nouvellement ajouté) et regardez le fichier /etc/corosync/corosycn.conf. Trouvez le nodelist qui assigne un nodeid à chaque contrôleur. Trouvez l'entrée pour le noeud défectueux et notez son nodeid :

[root@pod1-controller-0 ~]# cat /etc/corosync/corosync.conf
totem {
    version: 2
    secauth: off
    cluster_name: tripleo_cluster
    transport: udpu
    token: 10000
}

nodelist {
    node {
        ring0_addr: pod1-controller-0
        nodeid: 5
    }
    node {
        ring0_addr: pod1-controller-1
        nodeid: 7
    }
    node {
        ring0_addr: pod1-controller-2
        nodeid: 8
    }
} 

• Procédure de connexion à chacun des contrôleurs actifs. Retirez le noeud défectueux et redémarrez le service. Dans ce cas, retirez pod1-controller-2. N'exécutez pas cette action sur le contrôleur nouvellement ajouté :

[root@pod1-controller-0 ~]# sudo pcs cluster localnode remove pod1-controller-2
pod1-controller-2: successfully removed!
[root@pod1-controller-0 ~]# sudo pcs cluster reload corosync
Corosync reloaded

[root@pod1-controller-1 ~]# sudo pcs cluster localnode remove pod1-controller-2
pod1-controller-2: successfully removed!
[root@pod1-controller-1 ~]# sudo pcs cluster reload corosync
Corosync reloaded

• Exécutez cette commande d'un des contrôleurs actifs afin de supprimer le noeud défectueux de la batterie :
  
  

[root@pod1-controller-0 ~]# sudo crm_node -R pod1-controller-2 --force

• Exécutez cette commande d'un des contrôleurs actifs afin de supprimer le noeud défectueux de la batterie de rabbitmq :
  
  

[root@pod1-controller-0 ~]# sudo rabbitmqctl forget_cluster_node rabbit@pod1-controller-2
Removing node 'rabbit@newtonoc-controller-2' from cluster ...

• Supprimez le noeud défectueux du MongoDB. Afin de faire ceci, vous devez trouver le noeud actif de Mongo. Employez le netstat pour trouver l'adresse IP de l'hôte :

[root@pod1-controller-0 ~]# sudo netstat -tulnp | grep 27017
tcp        0      0 11.120.0.10:27017       0.0.0.0:*               LISTEN      219577/mongod     

• Procédure de connexion au noeud et au contrôle afin de voir si c'est le maître avec l'utilisation de l'adresse IP et du numéro de port de la commande précédente :

[heat-admin@pod1-controller-0 ~]$ echo "db.isMaster()" | mongo --host 11.120.0.10:27017
MongoDB shell version: 2.6.11
connecting to: 11.120.0.10:27017/test
{
         "setName" : "tripleo",
         "setVersion" : 9,
         "ismaster" : true,
         "secondary" : false,
         "hosts" : [
                  "11.120.0.10:27017",
                  "11.120.0.12:27017",
                  "11.120.0.11:27017"
         ],
         "primary" : "11.120.0.10:27017",
         "me" : "11.120.0.10:27017",
         "electionId" : ObjectId("5a0d2661218cb0238b582fb1"),
         "maxBsonObjectSize" : 16777216,
         "maxMessageSizeBytes" : 48000000,
         "maxWriteBatchSize" : 1000,
         "localTime" : ISODate("2017-11-16T18:36:34.473Z"),
         "maxWireVersion" : 2,
         "minWireVersion" : 0,
         "ok" : 1
}

Si le noeud n'est pas le maître, ouvrez une session à l'autre contrôleur actif et exécutez la même étape.

• Du maître, répertoriez les Noeuds disponibles avec l'utilisation de la commande rs.status (). Trouvez vieux/insensible noeud et identifiez le nom du noeud de mongo.

[root@pod1-controller-0 ~]# mongo --host 11.120.0.10
MongoDB shell version: 2.6.11
connecting to: 11.120.0.10:27017/test
<snip>
tripleo:PRIMARY> rs.status()
{
         "set" : "tripleo",
         "date" : ISODate("2017-11-14T13:27:14Z"),
         "myState" : 1,
         "members" : [
                  {
                           "_id" : 0,
                           "name" : "11.120.0.10:27017",
                           "health" : 1,
                           "state" : 1,
                           "stateStr" : "PRIMARY",
                           "uptime" : 418347,
                           "optime" : Timestamp(1510666033, 1),
                           "optimeDate" : ISODate("2017-11-14T13:27:13Z"),
                           "electionTime" : Timestamp(1510247693, 1),
                           "electionDate" : ISODate("2017-11-09T17:14:53Z"),
                           "self" : true
                  },
                  {
                           "_id" : 2,
                           "name" : "11.120.0.12:27017",
                           "health" : 1,
                           "state" : 2,
                           "stateStr" : "SECONDARY",
                           "uptime" : 418347,
                           "optime" : Timestamp(1510666033, 1),
                           "optimeDate" : ISODate("2017-11-14T13:27:13Z"),
                           "lastHeartbeat" : ISODate("2017-11-14T13:27:13Z"),
                           "lastHeartbeatRecv" : ISODate("2017-11-14T13:27:13Z"),
                           "pingMs" : 0,
                           "syncingTo" : "11.120.0.10:27017"
                  },
                  {
                           "_id" : 3,
                           "name" : "11.120.0.11:27017
                           "health" : 0,
                           "state" : 8,
                           "stateStr" : "(not reachable/healthy)",
                           "uptime" : 0,
                           "optime" : Timestamp(1510610580, 1),
                           "optimeDate" : ISODate("2017-11-13T22:03:00Z"),
                           "lastHeartbeat" : ISODate("2017-11-14T13:27:10Z"),
                           "lastHeartbeatRecv" : ISODate("2017-11-13T22:03:01Z"),
                           "pingMs" : 0,
                           "syncingTo" : "11.120.0.10:27017"               
                  }
         ],
         "ok" : 1
}

• Du maître, supprimez le noeud défectueux avec l'utilisation de la commande rs.remove. Quelques erreurs seront vues quand vous exécutez cette commande, mais vérifient l'état une fois de plus pour constater que le noeud a été retiré :

[root@pod1-controller-0 ~]$ mongo --host 11.120.0.10
<snip>
tripleo:PRIMARY> rs.remove('11.120.0.12:27017')
2017-11-16T18:41:04.999+0000 DBClientCursor::init call() failed
2017-11-16T18:41:05.000+0000 Error: error doing query: failed at src/mongo/shell/query.js:81
2017-11-16T18:41:05.001+0000 trying reconnect to 11.120.0.10:27017 (11.120.0.10) failed
2017-11-16T18:41:05.003+0000 reconnect 11.120.0.10:27017 (11.120.0.10) ok

tripleo:PRIMARY> rs.status()
{
         "set" : "tripleo",
         "date" : ISODate("2017-11-16T18:44:11Z"),
         "myState" : 1,
         "members" : [
                  {
                           "_id" : 3,
                           "name" : "11.120.0.11:27017",
                           "health" : 1,
                           "state" : 2,
                           "stateStr" : "SECONDARY",
                           "uptime" : 187,
                           "optime" : Timestamp(1510857848, 3),
                           "optimeDate" : ISODate("2017-11-16T18:44:08Z"),
                           "lastHeartbeat" : ISODate("2017-11-16T18:44:11Z"),
                           "lastHeartbeatRecv" : ISODate("2017-11-16T18:44:09Z"),
                           "pingMs" : 0,
                           "syncingTo" : "11.120.0.10:27017"
                  },
                  {
                           "_id" : 4,
                           "name" : "11.120.0.10:27017",
                           "health" : 1,
                           "state" : 1,
                           "stateStr" : "PRIMARY",
                           "uptime" : 89820,
                           "optime" : Timestamp(1510857848, 3),
                           "optimeDate" : ISODate("2017-11-16T18:44:08Z"),
                           "electionTime" : Timestamp(1510811232, 1),
                           "electionDate" : ISODate("2017-11-16T05:47:12Z"),
                           "self" : true
                  }
         ],
         "ok" : 1
}
tripleo:PRIMARY> exit
bye

•  Exécutez cette commande afin de mettre à jour la liste de Noeuds actifs de contrôleur. Incluez le nouveau noeud de contrôleur dans cette liste :

[root@pod1-controller-0 ~]# sudo pcs resource update galera wsrep_cluster_address=gcomm://pod1-controller-0,pod1-controller-1,pod1-controller-2

• Copiez ces fichiers d'un contrôleur qui existe déjà au nouveau contrôleur :

      /etc/sysconfig/clustercheck

      /root/.my.cnf

On existing controller:

[root@pod1-controller-0 ~]# scp /etc/sysconfig/clustercheck stack@192.200.0.1:/tmp/.
[root@pod1-controller-0 ~]# scp /root/.my.cnf stack@192.200.0.1:/tmp/my.cnf

On new controller:

[root@pod1-controller-3 ~]# cd /etc/sysconfig

[root@pod1-controller-3 sysconfig]# scp stack@192.200.0.1:/tmp/clustercheck .

[root@pod1-controller-3 sysconfig]# cd /root

[root@pod1-controller-3 ~]# scp stack@192.200.0.1:/tmp/my.cnf .my.cnf

• Exécutez le noeud de batterie ajoutent la commande d'un des contrôleurs qui existe déjà :

[root@pod1-controller-1 ~]# sudo pcs cluster node add pod1-controller-3

Disabling SBD service...
pod1-controller-3: sbd disabled
pod1-controller-0: Corosync updated
pod1-controller-1: Corosync updated

Setting up corosync...
pod1-controller-3: Succeeded
Synchronizing pcsd certificates on nodes pod1-controller-3...
pod1-controller-3: Success

Restarting pcsd on the nodes in order to reload the certificates...
pod1-controller-3: Success

• Ouvrez une session à chaque contrôleur et visualisez le fichier /etc/corosync/corosync.conf. Assurez-vous que le nouveau contrôleur est répertorié et que l'id de noeud assigné à ce contrôleur est le prochain nombre dans l'ordre qui n'a pas été précédemment utilisé. Assurez-vous que cette modification est faite sur chacun des 3 contrôleurs :

[root@pod1-controller-1 ~]# cat /etc/corosync/corosync.conf
totem {
    version: 2
    secauth: off
    cluster_name: tripleo_cluster
    transport: udpu
    token: 10000
}
nodelist {
    node {
        ring0_addr: pod1-controller-0
        nodeid: 5
    }
    node {
        ring0_addr: pod1-controller-1
        nodeid: 7
    }
    node {
        ring0_addr: pod1-controller-3
        nodeid: 6
    }
}
quorum {
    provider: corosync_votequorum
}
logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
}

Par exemple /etc/corosync/corosync.conf après modification :

totem { 
    version: 2 
    secauth: off 
    cluster_name: tripleo_cluster 
    transport: udpu 
    token: 10000 
}
nodelist {
    node {
        ring0_addr: pod1-controller-0
        nodeid: 5
    }
    node {
        ring0_addr: pod1-controller-1
        nodeid: 7
    }
    node {
        ring0_addr: pod1-controller-3
        nodeid: 9
    }
}
quorum {
    provider: corosync_votequorum
}
logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
}

• Corosync de reprise sur les contrôleurs actifs. Ne commencez pas le corosync sur le nouveau contrôleur :

[root@pod1-controller-0 ~]# sudo pcs cluster reload corosync
[root@pod1-controller-1 ~]# sudo pcs cluster reload corosync

• Commencez le nouveau noeud de contrôleur à partir d'un des contrôleurs temporaires :

[root@pod1-controller-1 ~]# sudo pcs cluster start pod1-controller-3  

• Redémarrez Galera d'un des contrôleurs temporaires :

[root@pod1-controller-1 ~]#  sudo pcs cluster start pod1-controller-3

pod1-controller-0: Starting Cluster...

[root@pod1-controller-1 ~]# sudo pcs resource cleanup galera
Cleaning up galera:0 on pod1-controller-0, removing fail-count-galera
Cleaning up galera:0 on pod1-controller-1, removing fail-count-galera
Cleaning up galera:0 on pod1-controller-3, removing fail-count-galera
  * The configuration prevents the cluster from stopping or starting 'galera-master' (unmanaged)

Waiting for 3 replies from the CRMd... OK

[root@pod1-controller-1 ~]#
[root@pod1-controller-1 ~]# sudo pcs resource manage galera

• La batterie est dans le mode maintenance. Désactivez le mode maintenance afin d'obtenir les services pour commencer :

[root@pod1-controller-2 ~]# sudo pcs property set maintenance-mode=false --wait

• Vérifiez l'état PC pour Galera jusqu'à ce que chacun des 3 contrôleurs soit répertorié comme maîtres à Galera :
  
  

Remarque: Pour de grandes installations, il peut prendre un certain temps au sync DBs.

[root@pod1-controller-1 ~]# sudo pcs status | grep galera -A1 

Master/Slave Set: galera-master [galera]
      Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-3 ] 

• Commutez la batterie au mode maintenance :

[root@pod1-controller-1~]# sudo pcs property set maintenance-mode=true --wait

[root@pod1-controller-1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: pod1-controller-0 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
 Last updated: Thu Nov 16 19:17:01 2017                  Last change: Thu Nov 16 19:16:48 2017 by root via cibadmin on pod1-controller-1
               *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services

PCSD Status:
  pod1-controller-3: Online
  pod1-controller-0: Online
  pod1-controller-1: Online

• Réexécutez le script de déployer que vous avez exécuté précédemment. Cette fois il devrait réussir.

[stack@director ~]$ ./deploy-addController.sh
START with options: [u'overcloud', u'deploy', u'--templates', u'-r', u'/home/stack/custom-templates/custom-roles.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml', u'-e', u'/usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml', u'-e', u'/home/stack/custom-templates/network.yaml', u'-e', u'/home/stack/custom-templates/ceph.yaml', u'-e', u'/home/stack/custom-templates/compute.yaml', u'-e', u'/home/stack/custom-templates/layout-removeController.yaml', u'--stack', u'newtonoc', u'--debug', u'--log-file', u'overcloudDeploy_11_14_17__13_53_12.log', u'--neutron-flat-networks', u'phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1', u'--neutron-network-vlan-ranges', u'datacentre:101:200', u'--neutron-disable-tunneling', u'--verbose', u'--timeout', u'180']
options: Namespace(access_key='', access_secret='***', access_token='***', access_token_endpoint='', access_token_type='', aodh_endpoint='', auth_type='', auth_url='https://192.200.0.2:13000/v2.0', authorization_code='', cacert=None, cert='', client_id='', client_secret='***', cloud='', consumer_key='', consumer_secret='***', debug=True, default_domain='default', default_domain_id='', default_domain_name='', deferred_help=False, discovery_endpoint='', domain_id='', domain_name='', endpoint='', identity_provider='', identity_provider_url='', insecure=None, inspector_api_version='1', inspector_url=None, interface='', key='', log_file=u'overcloudDeploy_11_14_17__13_53_12.log', murano_url='', old_profile=None, openid_scope='', os_alarming_api_version='2', os_application_catalog_api_version='1', os_baremetal_api_version='1.15', os_beta_command=False, os_compute_api_version='', os_container_infra_api_version='1', os_data_processing_api_version='1.1', os_data_processing_url='', os_dns_api_version='2', os_identity_api_version='', os_image_api_version='1', os_key_manager_api_version='1', os_metrics_api_version='1', os_network_api_version='', os_object_api_version='', os_orchestration_api_version='1', os_project_id=None, os_project_name=None, os_queues_api_version='2', os_tripleoclient_api_version='1', os_volume_api_version='', os_workflow_api_version='2', passcode='', password='***', profile=None, project_domain_id='', project_domain_name='', project_id='', project_name='admin', protocol='', redirect_uri='', region_name='', roles='', timing=False, token='***', trust_id='', url='', user='', user_domain_id='', user_domain_name='', user_id='', username='admin', verbose_level=3, verify=None)
Auth plugin password selected

Starting new HTTPS connection (1): 192.200.0.2
"POST /v2/action_executions HTTP/1.1" 201 1696
HTTP POST https://192.200.0.2:13989/v2/action_executions 201
Overcloud Endpoint: http://172.25.22.109:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud:
END return value: 0

real     54m17.197s
user     0m3.421s
sys       0m0.670s

Vérifiez se couvrent des services dans le contrôleur

• Assurez à cela tous les services gérés dirigés correctement sur les Noeuds de contrôleur.

[heat-admin@pod1-controller-2 ~]$ sudo pcs status

Menez les Routeurs à bonne fin de l'agent L3

Vérifiez les Routeurs afin de s'assurer que les agents L3 sont correctement hébergés. Assurez à la source le fichier d'overcloudrc quand vous exécutez ce contrôle.

• Trouvez le nom de routeur :

[stack@director~]$ source corerc
[stack@director ~]$ neutron router-list

+--------------------------------------+------+-------------------------------------------------------------------+-------------+------+

| id                                   | name | external_gateway_info                                             | distributed | ha   |

+--------------------------------------+------+-------------------------------------------------------------------+-------------+------+

| d814dc9d-2b2f-496f-8c25-24911e464d02 | main | {"network_id": "18c4250c-e402-428c-87d6-a955157d50b5",            | False       | True |

Dans cet exemple, le nom du routeur est principal.

• Répertoriez tous les agents L3 afin de trouver UUID de noeud défectueux et du nouveau noeud :

[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"

| 70242f5c-43ab-4355-abd6-9277f92e4ce6 | L3 agent           | pod1-controller-0.localdomain  | nova              | :-)   | True           | neutron-l3-agent          |
| 8d2ffbcb-b6ff-42cd-b5b8-da31d8da8a40 | L3 agent           | pod1-controller-2.localdomain  | nova              | xxx   | True           | neutron-l3-agent          |
| a410a491-e271-4938-8a43-458084ffe15d | L3 agent           | pod1-controller-3.localdomain  | nova              | :-)   | True           | neutron-l3-agent          |
| cb4bc1ad-ac50-42e9-ae69-8a256d375136 | L3 agent           | pod1-controller-1.localdomain  | nova              | :-)   | True           | neutron-l3-agent          |

• Dans cet exemple, l'agent L3 qui correspond à pod1-controller-2.localdomain devrait être retiré du routeur et de celui qui correspondent à pod1-controller-3.localdomain devrait être ajouté au routeur :

[stack@director ~]$ neutron l3-agent-router-remove 8d2ffbcb-b6ff-42cd-b5b8-da31d8da8a40  main

Removed router main from L3 agent

[stack@director ~]$ neutron l3-agent-router-add a410a491-e271-4938-8a43-458084ffe15d main

Added router main to L3 agent

•  Liste à jour par contrôle de L3-agents :

[stack@director ~]$ neutron l3-agent-list-hosting-router main

+--------------------------------------+-----------------------------------+----------------+-------+----------+
| id                                   | host                              | admin_state_up | alive | ha_state |
+--------------------------------------+-----------------------------------+----------------+-------+----------+

| 70242f5c-43ab-4355-abd6-9277f92e4ce6 | pod1-controller-0.localdomain | True           | :-)   | standby  |
| a410a491-e271-4938-8a43-458084ffe15d | pod1-controller-3.localdomain | True           | :-)   | standby  |
| cb4bc1ad-ac50-42e9-ae69-8a256d375136 | pod1-controller-1.localdomain | True           | :-)   | active   |
+--------------------------------------+-----------------------------------+----------------+-------+----------+ 

• Répertoriez tous les services qui dirigent du noeud retiré de contrôleur et les retirent :

[stack@director ~]$ neutron  agent-list | grep controller-2

| 877314c2-3c8d-4666-a6ec-69513e83042d | Metadata agent     | pod1-controller-2.localdomain  |                   | xxx   | True           | neutron-metadata-agent    |
| 8d2ffbcb-b6ff-42cd-b5b8-da31d8da8a40 | L3 agent           | pod1-controller-2.localdomain  | nova              | xxx   | True           | neutron-l3-agent          |
| 911c43a5-df3a-49ec-99ed-1d722821ec20 | DHCP agent         | pod1-controller-2.localdomain  | nova              | xxx   | True           | neutron-dhcp-agent        |
| a58a3dd3-4cdc-48d4-ab34-612a6cd72768 | Open vSwitch agent | pod1-controller-2.localdomain  |                   | xxx   | True           | neutron-openvswitch-agent |

[stack@director ~]$ neutron agent-delete 877314c2-3c8d-4666-a6ec-69513e83042d 
Deleted agent(s): 877314c2-3c8d-4666-a6ec-69513e83042d 
[stack@director ~]$ neutron agent-delete 8d2ffbcb-b6ff-42cd-b5b8-da31d8da8a40
Deleted agent(s): 8d2ffbcb-b6ff-42cd-b5b8-da31d8da8a40 
[stack@director ~]$ neutron agent-delete 911c43a5-df3a-49ec-99ed-1d722821ec20
Deleted agent(s): 911c43a5-df3a-49ec-99ed-1d722821ec20 
[stack@director ~]$ neutron agent-delete a58a3dd3-4cdc-48d4-ab34-612a6cd72768 
Deleted agent(s): a58a3dd3-4cdc-48d4-ab34-612a6cd72768 

[stack@director ~]$ neutron agent-list | grep controller-2 
[stack@director ~]$

Menez les services à bonne fin de calcul

• Vérifiez les éléments de service-liste de nova laissés du noeud retiré et supprimez-les :

[stack@director ~]$ nova service-list | grep controller-2

| 615 | nova-consoleauth | pod1-controller-2.localdomain  | internal          | enabled | down  | 2017-11-16T16:08:14.000000 | -               |
| 618 | nova-scheduler   | pod1-controller-2.localdomain  | internal          | enabled | down  | 2017-11-16T16:08:13.000000 | -               |
| 621 | nova-conductor   | pod1-controller-2.localdomain  | internal          | enabled | down  | 2017-11-16T16:08:14.000000 | -            

[stack@director ~]$ nova service-delete 615
[stack@director ~]$ nova service-delete 618
[stack@director ~]$ nova service-delete 621

stack@director ~]$ nova service-list | grep controller-2

• Assurez-vous que le processus de consoleauth fonctionne sur tous les contrôleurs ou redémarrez-le avec l'utilisation de cette commande : openstack-nova-consoleauth de reprise de ressource en PCs :

[stack@director ~]$ nova service-list | grep consoleauth

| 601 | nova-consoleauth | pod1-controller-0.localdomain  | internal          | enabled | up    | 2017-11-16T21:00:10.000000 | -               |
| 608 | nova-consoleauth | pod1-controller-1.localdomain  | internal          | enabled | up    | 2017-11-16T21:00:13.000000 | -               |
| 622 | nova-consoleauth | pod1-controller-3.localdomain  | internal          | enabled | up    | 2017-11-16T21:00:13.000000 | -

Reprise clôturant sur les Noeuds de contrôleur

• Vérifiez tous les contrôleurs pour l'artère IP à l'undercloud 192.0.0.0/8 :

[root@pod1-controller-3 ~]# ip route
default via 172.25.22.1 dev vlan101
11.117.0.0/24 dev vlan17  proto kernel  scope link  src 11.117.0.12
11.118.0.0/24 dev vlan18  proto kernel  scope link  src 11.118.0.12
11.119.0.0/24 dev vlan19  proto kernel  scope link  src 11.119.0.12
11.120.0.0/24 dev vlan20  proto kernel  scope link  src 11.120.0.12
169.254.169.254 via 192.200.0.1 dev eno1
172.25.22.0/24 dev vlan101  proto kernel  scope link  src 172.25.22.102
192.0.0.0/8 dev eno1  proto kernel  scope link  src 192.200.0.103

• Vérifiez la configuration en cours de stonith. Supprimez n'importe quelle référence au vieux noeud de contrôleur :

[root@pod1-controller-3 ~]# sudo pcs stonith show --full
 Resource: my-ipmilan-for-controller-6 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=pod1-controller-1 ipaddr=192.100.0.1 login=admin passwd=Csco@123Starent lanplus=1
  Operations: monitor interval=60s (my-ipmilan-for-controller-6-monitor-interval-60s)
 Resource: my-ipmilan-for-controller-4 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=pod1-controller-0 ipaddr=192.100.0.14 login=admin passwd=Csco@123Starent lanplus=1
  Operations: monitor interval=60s (my-ipmilan-for-controller-4-monitor-interval-60s)
Resource: my-ipmilan-for-controller-7 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=pod1-controller-2 ipaddr=192.100.0.15 login=admin passwd=Csco@123Starent lanplus=1
  Operations: monitor interval=60s (my-ipmilan-for-controller-7-monitor-interval-60s)

[root@pod1-controller-3 ~]# pcs stonith delete my-ipmilan-for-controller-7
Attempting to stop: my-ipmilan-for-controller-7...Stopped

• Ajoutez la configuration de stonith pour le nouveau contrôleur :

[root@pod1-controller-3 ~]sudo pcs stonith create my-ipmilan-for-controller-8 fence_ipmilan pcmk_host_list=pod1-controller-3 ipaddr=<CIMC_IP> login=admin passwd=<PASSWORD> lanplus=1 op monitor interval=60s 

• Redémarrez la clôture de n'importe quel contrôleur et vérifiez l'état :

[root@pod1-controller-1 ~]# sudo pcs property set stonith-enabled=true 
[root@pod1-controller-3 ~]# pcs status

<snip>
my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-3 
my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-3 
my-ipmilan-for-controller-3 (stonith:fence_ipmilan): Started pod1-controller-3 

Configurations de rechange de serveur de courrier

Veuillez se référer au lien ci-dessous pour appliquer les configurations qui étaient précédemment présentes dans le vieux serveur :