Remplacement du serveur OSPD UCS 240M4 - CPAR

Introduction

Ce document décrit les étapes requises pour remplacer un serveur défectueux qui héberge le logiciel OpenStack Platform Director (OSPD) dans une configuration Ultra-M. Cette procédure s'applique à un environnement OpenStack avec l'utilisation de la version NEWTON où ESC ne gère pas Cisco Prime Access Registrar (CPAR) et CPAR est installé directement sur la machine virtuelle déployée sur OpenStack.

Informations générales

Ultra-M est une solution de coeur de réseau de paquets mobiles virtualisés prépackagée et validée conçue pour simplifier le déploiement des VNF. OpenStack est le gestionnaire d'infrastructure virtualisée (VIM) pour Ultra-M et comprend les types de noeuds suivants :

• Calcul
• Disque de stockage d'objets - Calcul (OSD - Calcul)
• Contrôleur
• OSPD

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

Ce document s'adresse au personnel de Cisco qui connaît la plate-forme Cisco Ultra-M et décrit en détail les étapes à suivre dans les systèmes d'exploitation OpenStack et Redhat. 

---

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

---

Abréviations

MOP	Méthode de procédure
OSD	Disques de stockage d'objets
OSPD	OpenStack Platform Director
HDD	Disque dur
SSD	Disque dur SSD
VIM	Gestionnaire d'infrastructure virtuelle
VM	Machine virtuelle
EM	Gestionnaire d'éléments
UAS	Services d’automatisation ultra
UUID	Identificateur unique

Flux de travail du MoP

Workflow de haut niveau de la procédure de remplacement

Conditions préalables

Vérification du statut

Avant de remplacer un serveur OSPD, il est important de vérifier l'état actuel de l'environnement Red Hat OpenStack Platform et de s'assurer qu'il est sain afin d'éviter des complications lorsque le processus de remplacement est activé. 

1. Vérifiez l'état de la pile OpenStack et la liste des noeuds :

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

2. Vérifiez si tous les services sous-cloud sont en état de chargement, d'activité et d'exécution à partir du noeud OSP-D :

[stack@al03-pod2-ospd ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"
 UNIT LOAD ACTIVE SUB DESCRIPTION
 neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent
 neutron-metadata-agent.service loaded active running OpenStack Neutron Metadata Agent
 neutron-openvswitch-agent.service loaded active running OpenStack Neutron Open vSwitch Agent
 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.
lines 1-43 
lines 2-44 37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END)

Sauvegarde

1. Vérifiez que l'espace disque disponible est suffisant avant d'effectuer le processus de sauvegarde. Ce tarball devrait être d'au moins 3,5 Go.

[stack@director ~]$ df -h

2. Exécutez ces commandes en tant qu'utilisateur racine afin de sauvegarder les données du noeud sous-cloud vers un fichier nommé undercloud-backup-[timestamp].tar.gz.

[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

Installer le nouveau noeud OSPD

Installation du serveur UCS

1. Les étapes permettant d'installer un nouveau serveur UCS C240 M4 et les étapes de configuration initiale peuvent être référencées dans le Guide d'installation et de maintenance du serveur Cisco UCS C240 M4.

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

3. Connectez-vous au serveur à l'aide de l'adresse IP du contrôleur de gestion intégré Cisco (CIMC).

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

5. Vérifiez l'état des disques physiques. Il doit être Non configuré. Accédez à Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info comme indiqué dans l'image.

6. Créez un lecteur virtuel à partir des lecteurs physiques avec RAID Niveau 1. Accédez à Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives comme illustré dans l'image.

7. Sélectionnez le VD et configurez Set as Boot Drive comme indiqué dans l'image.

8. Activez IPMI sur LAN. Accédez à Admin > Communication Services > Communication Services comme illustré dans l'image.

  

9. Désactivez l'hyperthreading. Accédez à Compute > BIOS > Configure BIOS > Advanced > Processor Configuration comme indiqué dans l'image.

---

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.

---

Installation de Redhat

Monter l'image ISO Red Hat

1. Connectez-vous au serveur OSP-D.

2. Lancez la console KVM.

3. Accéder à Virtual Media > Activation des périphériques virtuels. Acceptez la session et activez l'option Souvenir de votre paramètre pour les connexions futures.

4. Accéder à Virtual Media > Carte CD/DVDet mapper l'image ISO de Red Hat.

5. Accéder à Alimentation > Réinitialiser le système (démarrage à chaud) dans l'ordre pour redémarrer le système.

6. Au redémarrage, appuyez sur F6et sélectionnezvDVD1.22 Cisco vKVM mappéet appuyez sur Entrée.

Installer RHEL

Préparation de l'installation sous-cloud à partir de la sauvegarde

Une fois l'ordinateur installé avec RHEL 7.3 et en état de propreté, réactivez tous les abonnements/référentiels nécessaires à l'installation et à l'exécution de Director.

1. Configuration du nom d'hôte.

[root@director ~]$sudo hostnamectl set-hostname <FQDN_hostname> 
[root@director ~]$sudo hostnamectl set-hostname --transient <FQDN_hostname>

2. Modifier le fichier /etc/hosts.

[root@director ~]$ vi /etc/hosts
<ospd_external_address>  <server_hostname>  <FQDN_hostname>
192.168.247.142  pod2-stack-ospd pod2-stack-ospd.cisco.com

3. Validez le nom d'hôte.

[root@director ~]$ cat /etc/hostname
pod2-stack-ospd.cisco.com

4. Validez la configuration DNS.

[root@director ~]$ cat /etc/resolv.conf

#Generated by NetworkManager
nameserver <DNS_IP>

5. Modifiez l'interface de carte réseau de provisionnement.

[root@director ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE=eno1
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br-ctlplane
BOOTPROTO=none
MTU=1500

Terminer l'enregistrement Redhat

  

1. Téléchargez ce paquet afin de configurer le gestionnaire d'abonnements pour utiliser rh-satellite.

[root@director ~]$ rpm -Uvh http://
     
     
       /pub/katello-ca-consumer-latest.noarch.rpm 
     
[root@director ~]$ subscription-manager config

2. Inscrivez-vous au rh-satellite en utilisant cette clé d'activation pour RHEL 7.3. 

[root@director ~]$subscription-manager register --org="<ORG>" --activationkey="<KEY>"

3. Pour voir l'abonnement.

[root@director ~]$ subscription-manager list –consumed

4. Activez les référentiels comme les repos OSPD anciens.

[root@director ~]$ sudo subscription-manager repos --disable=*
[root@director ~]$ subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rh
el-7-server-openstack-10-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpm

5. Effectuez une mise à jour sur votre système pour vous assurer que vous disposez des derniers packages système de base et redémarrez le système.

[root@director ~]$sudo yum update -y
[root@director ~]$sudo reboot

Restauration sous-cloud

Après avoir activé l'abonnement, importez le fichier tar de sous-cloud sauvegardé “ undercloud-backup-`date +%F`.tar.gz ” vers le nouveau répertoire racine du serveur OSP-D /root

1. Installez le serveur mariadb.

[root@director ~]$ yum install -y mariadb-server

2. Extraire le fichier de configuration MariaDB et la sauvegarde de la base de données. Effectuez cette opération en tant qu'utilisateur racine.

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/my.cnf.d/server.cnf
[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz root/undercloud-all-databases.sql

3. Modifiez /etc/my.cnf.d/server.cnf et commentez l'entrée d'adresse de liaison si elle est présente.

[root@tb3-ospd ~]# vi /etc/my.cnf.d/server.cnf

4. Démarrez le service MariaDB et mettez temporairement à jour le paramètre max_allowed_packet.

[root@director ~]$ systemctl start mariadb
[root@director ~]$ mysql -uroot -e"set global max_allowed_packet = 16777216;"

5. Nettoyez certaines autorisations (à recréer ultérieurement).

[root@director ~]$ for i in ceilometer glance heat ironic keystone neutron nova;do mysql -e "drop user $i";done
[root@director ~]$ mysql -e 'flush privileges'

---

Remarque : si le service de ceilomètre a été précédemment désactivé dans la configuration, exécutez la commande ci-dessus en supprimant « ceilometer ».

---

6. Créez le compte d'utilisateur empilé.

[root@director ~]$ sudo useradd stack
[root@director ~]$ sudo passwd stack << specify a password
[root@director ~]$ echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
[root@director ~]$ sudo chmod 0440 /etc/sudoers.d/stack 

7. Restaurer le répertoire d'accueil des utilisateurs de la pile.

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz home/stack

8. Installez les paquets de base rapide et rapide, puis restaurez leurs données.

[root@director ~]$ yum install -y openstack-glance openstack-swift
[root@director ~]$ tar --xattrs -xzC / -f undercloud-backup-$DATE.tar.gz srv/node var/lib/glance/images

9. Vérifiez que les données appartiennent à l'utilisateur approprié.

[root@director ~]$ chown -R swift: /srv/node
[root@director ~]$ chown -R glance: /var/lib/glance/images

10. Restaurer les certificats SSL sous-cloud (facultatif - à effectuer uniquement si l'installation utilise des certificats SSL).

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/pki/instack-certs/undercloud.pem
[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/pki/ca-trust/source/anchors/ca.crt.pem

11. Réexécutez l'installation sous-cloud en tant qu'utilisateur de pile, en veillant à l'exécuter dans le répertoire d'accueil de l'utilisateur de la pile :

[root@director ~]$ su - stack
[stack@director ~]$ sudo yum install -y python-tripleoclient

12. Vérifiez que le nom d'hôte est correctement défini dans /etc/hosts.

13. Réinstallez le sous-cloud.

[stack@director ~]$ openstack undercloud install

<snip>
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and must be
secured.

#############################################################################

Reconnectez le sous-nuage restauré au surnuage

Après avoir suivi les étapes ci-dessus, on peut s'attendre à ce que le nuage de base restaure automatiquement sa connexion au nuage de base. Les noeuds continueront à interroger l'orchestration (chaleur) pour les tâches en attente, en utilisant une simple requête HTTP émise toutes les quelques secondes.

Valider la restauration terminée

Utilisez ces commandes pour effectuer un contrôle de santé de votre environnement récemment restauré.

[root@director ~]$ su - stack
Last Log in: Tue Nov 28 21:27:50 EST 2017 from 192.182.255.20 on pts/0

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod2-stack-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.106 |
| 1f725ce3-948d-49e9-aed9-b99e73d82644 | pod2-stack-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.107 |
| fbc13c78-dc06-4ac9-a3c5-595ccc147adc | pod2-stack-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.119 |
| 3b94e0b1-47dc-4960-b3eb-d02ffe9ae693 | pod2-stack-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.112 |
| 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4 | ACTIVE | - | Running | ctlplane=192.200.0.116 |
| b896c73f-d2c8-439c-bc02-7b0a2526dd70 | pod2-stack-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.113 |
| 2519ce67-d836-4e5f-a672-1a915df75c7c | pod2-stack-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.105 |
| e19b9625-5635-4a52-a369-44310f3e6a21 | pod2-stack-controller-2 | ACTIVE | - | Running | ctlplane=192.200.0.120 |
| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.109 |
| 26d3f7b1-ba97-431f-aa6e-ba91661db45d | pod2-stack-osd-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.117 |
| 6e4a8aa9-4870-465a-a7e2-0932ff55e34b | pod2-stack-osd-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.103 |
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
<snip>

[stack@director ~]$ ssh heat-admin@192.200.0.113
Last login: Fri Jul 6 09:02:41 2018 from 192.200.0.1 
[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Tue Jul 10 10:04:15 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

 ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Master/Slave Set: redis-master [redis]
 Masters: [ pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]
 ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

[heat-admin@pod2-stack-controller-0 ~]$ sudo ceph status
 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}
 election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2
 osdmap e81: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v23094282: 704 pgs, 6 pools, 809 GB data, 424 kobjects
 2418 GB used, 10974 GB / 13393 GB avail
 704 active+clean
 client io 1841 kB/s wr, 0 op/s rd, 220 op/s wr
[heat-admin@pod2-stack-controller-0 ~]$ exit
logout
Connection to 192.200.0.113 closed.

Opération Check Identity Service (Keystone)

Cette étape valide les opérations du service d'identité en recherchant une liste d'utilisateurs.

[stack@director ~]$ source stackerc
[stack@director~]$ openstack user list
+----------------------------------+------------------+
| ID | Name |
+----------------------------------+------------------+
| 4d93cc08ed314b87b4c6dce95c19558f | admin |
| c499bd1a65d94029804350e3bca19888 | aodh |
| d9b59136b2794ec1b9c18c4f7b95c674 | ceilometer |
| 4650cdca79b44f2b9d2426b7a9df9495 | glance |
| 4a6724a623f4463c971658462b505c8a | heat |
| e18ae9a5b7f14aefb9e93931dcec476e | ironic |
| 9831160669c44c10b04d6f78b7517a55 | ironic-inspector |
| 6a5d6f02b9a74dfb9f679eecfebb28e0 | mistral |
| 462c8ec91fb0485fbc7dfec6d4ecf480 | neutron |
| f3a66d84e39c47a0bdcd14d24bd72816 | nova |
| 1f16ea9035ab424a88d5f34681d3f893 | swift |
| ab4a1e5f62be4609b290c32dc93bfbce | zaqar |
| fac68a166f5f442284f7d06355369c53 | zaqar-websocket |
+----------------------------------+------------------+

[stack@director ~]$ source <overcloudrc>
[stack@director ~]$ openstack user list
+----------------------------------+------------+
| ID | Name |
+----------------------------------+------------+
| 7285a65e0c8c4447b10875d0e9c9da69 | admin |
| c7c78ac31ec24926b3eed79e7f5bd59e | neutron |
| 191c2a293beb48edb4d2c1160c9a0523 | heat |
| 1445a6ef2ae94b6f9365ffbc6b56a231 | gnocchi |
| fb8b006129554c6b8465310fcfc0ba8c | aodh |
| 5afcb816f93b4f20998c9edaf3b143a0 | nova |
| 37444af1295344809eca6058a782f871 | glance |
| e74d2d9e59f34ddfb4408a8beb88db7b | ceilometer |
| 9baab90178c141478ce7c0084e930f40 | cinder |
| 5a964c651c11402284eecb0e8f40ee33 | heat-cfn |
| 6d49ebae55da432580943d6080efcf90 | swift |
| 41a666fe64c64df593d73b4f467885be | core |
| ab004ba966bf4ddc92783fbb6045e48b | cpar |
| fce5b5c5dc7647ccbc2170b56a64db33 | cpardemo |
| 28ead2dab0ef486ba449b441715a3e04 | pcrf |
| 0aac4107e3d443dc93ca62c3928a1998 | pcrfdemo |
+----------------------------------+------------+

Téléchargement d'images pour l'introduction au futur noeud

1. Validez /httpboot tous ces fichiers “ inspecteur.ipxe, agent.kernel, agent.ramdisk ”, si vous ne suivez pas les étapes suivantes pour effectuer la mise à jour dans l'image.

[stack@director ~]$ ls /httpboot
inspector.ipxe
[stack@director ~]$ source stackrc 
[stack@director ~]$ cd images/
[stack@director images]$ openstack overcloud image upload --image-path /home/stack/images
Image "overcloud-full-vmlinuz" is up-to-date, skipping.
Image "overcloud-full-initrd" is up-to-date, skipping.
Image "overcloud-full" is up-to-date, skipping.
Image "bm-deploy-kernel" is up-to-date, skipping.
Image "bm-deploy-ramdisk" is up-to-date, skipping.
[stack@director images]$ ls /httpboot
agent.kernel agent.ramdisk inspector.ipxe
[stack@director images]$ 

Redémarrage de la clôture

Les clôtures seraient en état d'arrêt après la récupération OSPD, la procédure ci-dessous permettrait d'activer les clôtures. 

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs property set stonith-enabled=true
[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
[heat-admin@pod2-stack-controller-0 ~]$sudo pcs stonith show 

Informations connexes

• Sauvegarder et restaurer Director Undercloud

• Clôture des noeuds de contrôleur

• Support et documentation techniques - Cisco Systems