Remplacement de la carte mère dans le serveur Ultra-M UCS 240M4 - CPAR

Introduction

Ce document décrit les étapes requises pour remplacer la carte mère défectueuse d'un serveur dans une configuration Ultra-M.

Cette procédure s'applique à un environnement Openstack utilisant la version NEWTON où ESC ne gère pas 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 mobile virtualisée préemballé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 se compose des types de noeuds suivants :

• Calculer
• Disque de stockage d'objets - Calcul (OSD - Calcul)
• Contrôleur
• Plate-forme OpenStack - Director (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 Cisco qui connaît bien la plate-forme Cisco Ultra-M et détaille les étapes à suivre sur OpenStack et Redhat OS.

---

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

Abréviations

SERPILLIÈRE	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
SAMU	Services d’automatisation ultra
UUID	Identificateur Universally Unique

Flux de travail de la musique d'attente

Remplacement de la carte mère dans la configuration Ultra-M

Dans une configuration Ultra-M, il peut arriver qu'un remplacement de carte mère soit nécessaire dans les types de serveurs suivants : Calcul, OSD-Calcul et contrôleur.

---

Remarque : Les disques de démarrage avec l'installation openstack sont remplacés après le remplacement de la carte mère. Par conséquent, il n'est pas nécessaire de rajouter le noeud au surcloud. Une fois que le serveur est mis sous tension après l'activité de remplacement, il s'inscrit à nouveau dans la pile de cloud.

---

Conditions préalables

Avant de remplacer un noeud Compute, il est important de vérifier l'état actuel de votre environnement Red Hat OpenStack Platform. Il est recommandé de vérifier l'état actuel afin d'éviter des complications lorsque le processus de remplacement Compute est activé. Il peut être réalisé par ce flux de remplacement.

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

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Ce processus garantit qu'un noeud peut être remplacé sans affecter la disponibilité des instances. 

Remarque : Assurez-vous de disposer du snapshot de l'instance afin de pouvoir restaurer la VM en cas de besoin. Suivez cette procédure pour prendre un instantané de la machine virtuelle.

Remplacement de la carte mère dans le noeud de calcul

Avant l'exercice, les machines virtuelles hébergées dans le noeud Calcul sont fermées progressivement. Une fois la carte mère remplacée, les machines virtuelles sont restaurées.

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

[stack@al03-pod2-ospd ~]$ nova list --field name,host

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

| ID                                   | Name                      | Host                             |

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | pod2-stack-compute-3.localdomain |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | pod2-stack-compute-3.localdomain |

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

  

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

Sauvegarde : Processus de snapshot

Étape 1. Arrêt de l’application CPAR

Étape 1. Ouvrez un client ssh connecté au réseau et connectez-vous à l’instance CPAR.

 Il est important de ne pas arrêter les 4 instances AAA au sein d'un site en même temps, et ce de manière individuelle.

Étape 2.Arrêtez l'application CPAR avec cette commande :

/opt/CSCOar/bin/arserver stop

A Message stating “Cisco Prime Access Registrar Server Agent shutdown complete.” Should show up

 Si un utilisateur a laissé une session CLI ouverte, la commande arserver stop ne fonctionne pas et le message suivant s'affiche :

ERROR:    You can not shut down Cisco Prime Access Registrar while the

          CLI is being used.   Current list of running

          CLI with process id is:

 2903 /opt/CSCOar/bin/aregcmd –s

Dans cet exemple, l'ID de processus mis en évidence 2903 doit être arrêté avant que le CPAR puisse être arrêté. Si c'est le cas, veuillez terminer ce processus avec cette commande :

kill -9 *process_id*

Répétez ensuite l'étape 1.

  

Étape 3.Vérifiez que l'application CPAR a bien été arrêtée en exécutant la commande suivante :

/opt/CSCOar/bin/arstatus

Ces messages doivent s'afficher :

  

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tâche de snapshot de VM

Étape 1.Accédez au site Web Horizon GUI correspondant au site (ville) en cours de traitement.

Lorsque vous accédez à Horizon, cet écran s'affiche :

Étape 2.Accédez à Project > Instances, comme indiqué dans l'image.

Si l'utilisateur utilisé était CPAR, seules les 4 instances AAA apparaissent dans ce menu.

Étape 3.Arrêtez une seule instance à la fois, veuillez répéter tout le processus dans ce document.

Afin d'arrêter la VM, accédez à Actions > Shut Off Instance et confirmez votre sélection.

Étape 4.Vérifiez que l'instance a bien été arrêtée en vérifiant l'état = Arrêt et l'état d'alimentation = Arrêt.

Cette étape met fin au processus d'arrêt du CPAR.

Snapshot VM

Une fois les machines virtuelles CPAR désactivées, les instantanés peuvent être pris en parallèle, car ils appartiennent à des ordinateurs indépendants.

Les quatre fichiers QCOW2 seront créés en parallèle.

Prendre un instantané de chaque instance AAA (25 minutes -1 heure) (25 minutes pour les instances qui ont utilisé une image qcow comme source et 1 heure pour les instances qui utilisent une image brute comme source)

Étape 1. Connexion à l'horizon d'Openstack de PODIUG.
    

Étape 2. Une fois connecté, accédez à la section Project > Compute > Instances du menu supérieur et recherchez les instances AAA.

Étape 3. Cliquez sur le bouton Create Snapshot pour poursuivre la création du snapshot (cette opération doit être exécutée sur l'instance AAA correspondante).

Étape 4. Une fois le cliché exécuté, accédez au menu IMAGES et vérifiez que tous les fichiers se terminent et qu'aucun problème n'est signalé.

Étape 5. L’étape suivante consiste à télécharger le cliché au format QCOW2 et à le transférer à une entité distante au cas où le protocole OSPD serait perdu au cours de ce processus. Pour ce faire, identifiez le snapshot avec cette commande glance image-list au niveau OSPD.

[root@elospd01 stack]# glance image-list

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

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

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

Étape 6. Une fois identifié le cliché à télécharger (dans ce cas, il s’agira de celui marqué en vert ci-dessus), téléchargez-le au format QCOW2 à l’aide de la commande glance image-download comme indiqué ici.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• Le « & » envoie le processus en arrière-plan. Cette action prendra un certain temps. Une fois terminée, l'image peut être localisée dans le répertoire /tmp.
• Lors de l'envoi du processus en arrière-plan, si la connectivité est perdue, le processus est également arrêté. 
• Exécutez la commande « disown -h » afin qu'en cas de perte de connexion SSH, le processus continue à s'exécuter et se termine sur l'OSPD.

Étape 7. Une fois le processus de téléchargement terminé, un processus de compression doit être exécuté car ce snapshot peut être rempli de ZÉROS en raison des processus, des tâches et des fichiers temporaires traités par le système d'exploitation. La commande à utiliser pour la compression de fichiers est virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Ce processus prend un certain temps (environ 10-15 minutes). Une fois terminé, le fichier résultant est celui qui doit être transféré à une entité externe comme spécifié à l'étape suivante.

La vérification de l'intégrité du fichier est nécessaire. Pour ce faire, exécutez la commande suivante et recherchez l'attribut « corrompu » à la fin de sa sortie.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

 Afin d'éviter un problème de perte de l'OSPD, l'instantané récemment créé sur le format QCOW2 doit être transféré à une entité externe. Avant de commencer le transfert de fichiers, nous devons vérifier si la destination a suffisamment d'espace disque disponible, utilisez la commande «df -kh» afin de vérifier l'espace mémoire. Nous vous conseillons de le transférer temporairement vers le protocole OSPD d'un autre site à l'aide du protocole SFTP « sftproot@x.x.x.x », où x.x.x.x est l'adresse IP d'un protocole OSPD distant. Afin d'accélérer le transfert, la destination peut être envoyée à plusieurs OSPD. De la même manière, nous pouvons utiliser la commande suivante scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (où x.x.x.x est l'adresse IP d'un OSPD distant) pour transférer le fichier vers un autre OSPD.

Mise hors tension progressive

Mettre le noeud hors tension

1. Pour mettre l'instance hors tension : nova stop <NOM_INSTANCE>
2. Vous voyez maintenant le nom de l'instance avec l'état shutdown.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

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

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

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

Remplacer la carte mère

Les étapes de remplacement de la carte mère dans un serveur UCS C240 M4 peuvent être consultées dans le Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

1. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.
   
   
2. Procédez à la mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée utilisé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

Restaurer les machines virtuelles

Récupérer une instance via un snapshot

Processus de récupération

Il est possible de redéployer l'instance précédente à l'aide de l'instantané pris lors des étapes précédentes.

Étape 1 [FACULTATIF].S'il n'y a pas de VMsnapshot précédent disponible, connectez-vous au noeud OSPD où la sauvegarde a été envoyée et remettez la sauvegarde à son noeud OSPD d'origine. En utilisant «sftproot@x.x.x.x» où x.x.x.x est l'IP de l'OSPD d'origine. Enregistrez le fichier d'instantané dans le répertoire /tmp.

Étape 2.Connectez-vous au noeud OSPD où l'instance est redéployée.

Utilisez la commande suivante pour créer la source des variables d'environnement :

              

# source /home/stack/pod1-stackrc-Core-CPAR

Étape 3.L'utilisation de l'instantané en tant qu'image est nécessaire pour le télécharger vers l'horizon en tant que tel. Pour ce faire, utilisez la commande suivante.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

Le processus se profile à l'horizon.

Étape 4.Dans Horizon, accédez à Project > Instances et cliquez sur Launch Instance.

Étape 5.Indiquez le nom de l'instance et sélectionnez la zone de disponibilité.

Étape 6.Dans l'onglet Source, choisissez l'image pour créer l'instance. Dans le menu Sélectionner la source de démarrage, sélectionnez image, une liste d'images s'affiche ici, choisissez celle qui a été précédemment téléchargée lorsque vous cliquez sur le signe +.

Étape 7.Dans l'onglet Saveur, choisissez la saveur AAA lorsque vous cliquez sur + signe.

  

Étape 8.Enfin, accédez à l'onglet Réseau et sélectionnez les réseaux dont l'instance a besoin lorsque vous cliquez sur le signe +. Dans ce cas, sélectionnez diameter-soutable1, radius-routable1 et tb1-mgmt.

  

Étape 9. Enfin, cliquez sur Launch instance pour le créer. La progression peut être suivie dans Horizon :

Après quelques minutes, l'instance est entièrement déployée et prête à l'emploi.

Créer et attribuer une adresse IP flottante

Une adresse IP flottante est une adresse routable, ce qui signifie qu'elle est accessible depuis l'extérieur de l'architecture Ultra M/Openstack et qu'elle peut communiquer avec d'autres noeuds à partir du réseau.

Étape 1.Dans le menu supérieur d’Horizon, accédez à Admin > Floating IPs.

Étape 2. Cliquez sur le boutonAllouerIP au projet.

Étape 3. Dans la fenêtre Allocate Floating IP, sélectionnez le pool auquel appartient la nouvelle adresse IP flottante, le projet auquel elle va être attribuée et la nouvelle adresse IP flottante elle-même.

Exemple :

                                                                

Étape 4.Cliquez surAllocateFloating IPbutton.

Étape 5. Dans le menu supérieur Horizon, accédez à Projet > Instances.

Étape 6.Dans la colonne Action, cliquez sur la flèche pointant vers le bas du bouton Créer un instantané pour afficher un menu. SélectionnezAssocier une option IP flottante.

Étape 7. Sélectionnez l’adresse IP flottante correspondante à utiliser dans le champ Adresse IP et choisissez l’interface de gestion correspondante (eth0) dans la nouvelle instance où cette adresse IP flottante va être attribuée dans le port à associer. Reportez-vous à l'image suivante comme exemple de cette procédure.

Étape 8. Enfin, cliquez sur le bouton Associer.

Activation de SSH

Étape 1.Dans le menu supérieur Horizon, accédez à Projet > Instances.

Étape 2.Cliquez sur le nom de l'instance/VM créée dans la sectionLancer une nouvelle instance.

Étape 3. Cliquez surOnglet Console. L'interface de ligne de commande de la machine virtuelle s'affiche.

Étape 4.Une fois l'interface de ligne de commande affichée, saisissez les informations de connexion appropriées :

           Nom d'utilisateur:racine

           Mot de passe : cisco123

Étape 5.Dans l'interface de ligne de commande, entrez la commande vi /etc/ssh/sshd_config pour modifier la configuration ssh.

Étape 6. Une fois le fichier de configuration ssh ouvert, appuyez sur Ipour le modifier. Recherchez ensuite la section ci-dessous et modifiez la première ligne de PasswordAuthentication en PasswordAuthentication yes.

Étape 7.Appuyez sur Échap et entrez :wq! pour enregistrer les modifications apportées au fichier sshd_config.

Étape 8. Exécutez la commande service sshd restart.

                                  

Étape 9.Afin de tester que les modifications de configuration SSH ont été correctement appliquées, ouvrez tout client SSH et essayez d'établir une connexion sécurisée à distance à l'aide de l'IP flottante attribuée à l'instance (c'est-à-dire 10.145.0.249) et à la racine utilisateur.

Établir une session SSH

Ouvrez une session SSH en utilisant l'adresse IP de la machine virtuelle/du serveur correspondant où l'application est installée.

Début de l'instance CPAR

Veuillez suivre les étapes ci-dessous, une fois que l'activité est terminée et que les services CPAR peuvent être rétablis dans le site qui a été fermé.

1. Pour vous reconnecter à Horizon, accédez à Project > Instance > Start Instance.
   
   
2. Vérifiez que l'état de l'instance est actif et que l'état d'alimentation est en cours d'exécution :

Contrôle d'intégrité post-activité

Étape 1 : exécution de la commande /opt/CSCOar/bin/arstatus au niveau du système d’exploitation

[root@aaa04 ~]# /opt/CSCOar/bin/arstatus
Cisco Prime AR RADIUS server running       (pid: 24834)
Cisco Prime AR Server Agent running        (pid: 24821)
Cisco Prime AR MCD lock manager running    (pid: 24824)
Cisco Prime AR MCD server running          (pid: 24833)
Cisco Prime AR GUI running                 (pid: 24836)
SNMP Master Agent running                (pid: 24835)
[root@wscaaa04 ~]#

Étape 2.Exécutez la commande /opt/CSCOar/bin/aregcmd au niveau du système d’exploitation et entrez les informations d’identification de l’administrateur. Vérifiez que CPAR Health est 10 sur 10 et quittez CPAR CLI.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]

    LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

                  PAR-ADD-TPS 7.2(2000TPS:)

                  PAR-RDDR-TRX 7.2()

                  PAR-HSS 7.2()

    Radius/

    Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit

Étape 3.Exécutez la commande netstat | grep diameter et vérifiez que toutes les connexions DRA sont établies.

Le résultat mentionné ci-dessous concerne un environnement dans lequel des liaisons de diamètre sont attendues. Si moins de liens sont affichés, cela représente une déconnexion du DRA qui doit être analysée.

[root@aa02 logs]# netstat | grep diameter
tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

Étape 4. Vérifiez que le journal TPS indique les demandes en cours de traitement par CPAR. Les valeurs mises en évidence représentent le TPS et ce sont celles auxquelles nous devons prêter attention.

La valeur de TPS ne doit pas dépasser 1500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv
11-21-2017,23:57:35,263,0
11-21-2017,23:57:50,237,0
11-21-2017,23:58:05,237,0
11-21-2017,23:58:20,257,0
11-21-2017,23:58:35,254,0
11-21-2017,23:58:50,248,0
11-21-2017,23:59:05,272,0
11-21-2017,23:59:20,243,0
11-21-2017,23:59:35,244,0
11-21-2017,23:59:50,233,0

 

Étape 5.Recherchez les messages d'erreur ou d'alarme dans name_radius_1_log

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Étape 6.Vérifiez la quantité de mémoire utilisée par le processus CPAR en exécutant la commande suivante :

peigné | rayon grep

[root@sfraaa02 ~]# top | grep radius
27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Cette valeur mise en surbrillance doit être inférieure à : 7 Go, soit le maximum autorisé au niveau de l'application.

Remplacement de la carte mère dans le noeud de calcul OSD

Avant l'exercice, les machines virtuelles hébergées dans le noeud Calcul sont fermées progressivement et le CEPH est mis en mode maintenance. Une fois la carte mère remplacée, les machines virtuelles sont restaurées et le CEPH quitte le mode maintenance.

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

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

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Sauvegarde : Processus de snapshot

Arrêt de l'application CPAR

Étape 1. Ouvrez un client ssh connecté au réseau et connectez-vous à l’instance CPAR.

 Il est important de ne pas arrêter les 4 instances AAA au sein d'un site en même temps, et ce de manière individuelle.

Étape 2.Arrêtez l'application CPAR avec cette commande :

/opt/CSCOar/bin/arserver stop

A Message stating “Cisco Prime Access Registrar Server Agent shutdown complete.” Should show up

Remarque : Si un utilisateur a laissé une session CLI ouverte, la commande arserver stop ne fonctionnera pas et le message suivant s'affichera :

ERROR:    You can not shut down Cisco Prime Access Registrar while the

          CLI is being used.   Current list of running

          CLI with process id is:

 2903 /opt/CSCOar/bin/aregcmd –s

Dans cet exemple, l'ID de processus mis en évidence 2903 doit être arrêté avant que le CPAR puisse être arrêté. Si c'est le cas, veuillez terminer ce processus avec cette commande :

kill -9 *process_id*

Répétez ensuite l'étape 1.

  

Étape 3.Vérifiez que l'application CPAR a bien été arrêtée avec cette commande :

/opt/CSCOar/bin/arstatus

Ces messages apparaissent :

  

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tâche de snapshot de VM

Étape 1.Accédez au site Web Horizon GUI correspondant au site (ville) en cours de traitement.

Lors de l'accès à Horizon, l'image affichée est observée :

Étape 2. Accédez à Project > Instances, comme indiqué dans l'image.

Si l'utilisateur utilisé était CPAR, seules les 4 instances AAA apparaissent dans ce menu.

Étape 3.Arrêtez une seule instance à la fois, veuillez répéter tout le processus dans ce document.

Afin d'arrêter la VM, accédez à Actions > Shut Off Instance et confirmez votre sélection.

Étape 4.Vérifiez que l'instance a bien été arrêtée en vérifiant l'état = Arrêt et l'état d'alimentation = Arrêt.

Cette étape met fin au processus d'arrêt du CPAR.

Snapshot VM

Une fois les machines virtuelles CPAR désactivées, les instantanés peuvent être pris en parallèle, car ils appartiennent à des ordinateurs indépendants.

Les quatre fichiers QCOW2 sont créés en parallèle.

Prenez un instantané de chaque instance AAA (25 minutes -1 heure) (25 minutes pour les instances qui ont utilisé une image qcow comme source et 1 heure pour les instances qui utilisent une image brute comme source)

Étape 1 : connexion à l'interface utilisateur graphique Horizon d'Openstack de POD

Étape 2. Une fois connecté, accédez à la section Project > Compute > Instances du menu supérieur et recherchez les instances AAA.

Étape 3. Cliquez sur le bouton Create Snapshot pour poursuivre la création du snapshot (cette opération doit être exécutée sur l'instance AAA correspondante).

Étape 4. Une fois le cliché exécuté, accédez au menu IMAGES et vérifiez que tous les fichiers se terminent et qu'aucun problème n'est signalé.

Étape 5. L’étape suivante consiste à télécharger le cliché au format QCOW2 et à le transférer à une entité distante au cas où le protocole OSPD serait perdu au cours de ce processus. Pour ce faire, identifiez le snapshot avec cette commande glance image-list au niveau OSPD.

[root@elospd01 stack]# glance image-list

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

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

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

Étape 6. Une fois identifié, le cliché doit être téléchargé (dans ce cas, il s’agira de celui marqué en vert ci-dessus). Téléchargez-le maintenant au format QCOW2 à l’aide de la commande glance image-download, comme indiqué ici.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• Le « & » envoie le processus en arrière-plan. Cette action prendra un certain temps. Une fois terminée, l'image peut être localisée dans le répertoire /tmp.
• Lors de l'envoi du processus en arrière-plan, si la connectivité est perdue, le processus est également arrêté. 
• Exécutez la commande « disown -h » afin qu'en cas de perte de connexion SSH, le processus continue à s'exécuter et se termine sur l'OSPD.

7. Une fois le processus de téléchargement terminé, un processus de compression doit être exécuté car ce cliché peut être rempli de ZÉROS en raison des processus, des tâches et des fichiers temporaires traités par le système d'exploitation. La commande à utiliser pour la compression de fichiers est virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Ce processus prend un certain temps (environ 10-15 minutes). Une fois terminé, le fichier résultant est celui qui doit être transféré à une entité externe comme spécifié à l'étape suivante.

La vérification de l'intégrité du fichier est nécessaire. Pour ce faire, exécutez la commande suivante et recherchez l'attribut « corrompu » à la fin de son résultat.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

 Afin d'éviter un problème de perte de l'OSPD, l'instantané récemment créé sur le format QCOW2 doit être transféré à une entité externe. Avant de commencer le transfert de fichiers, nous devons vérifier si la destination a suffisamment d'espace disque disponible, utilisez la commande «df -kh» afin de vérifier l'espace mémoire. Nous vous conseillons de le transférer temporairement vers le protocole OSPD d'un autre site à l'aide du protocole SFTP « sftproot@x.x.x.x », où x.x.x.x est l'adresse IP d'un protocole OSPD distant. Afin d'accélérer le transfert, la destination peut être envoyée à plusieurs OSPD. De la même manière, nous pouvons utiliser la commande suivante scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (où x.x.x.x est l'adresse IP d'un OSPD distant) pour transférer le fichier vers un autre OSPD.

Mettre CEPH en mode maintenance

Étape 1 : vérification de l’état de l’arborescence ceph osd sur le serveur

[heat-admin@pod2-stack-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 pod2-stack-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 pod2-stack-osd-compute-1 
 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 pod2-stack-osd-compute-2 
 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 2. Connectez-vous au noeud de calcul OSD et mettez CEPH en mode maintenance.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set norebalance
[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_WARN
 noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
 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 e79: 12 osds: 12 up, 12 in
 flags noout,norebalance,sortbitwise,require_jewel_osds
 pgmap v22844323: 704 pgs, 6 pools, 804 GB data, 423 kobjects
 2404 GB used, 10989 GB / 13393 GB avail
 704 active+clean
 client io 3858 kB/s wr, 0 op/s rd, 546 op/s wr

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

Mise hors tension progressive

Mettre le noeud hors tension

1. Pour mettre l'instance hors tension : nova stop <NOM_INSTANCE>
   
   
2. Vous voyez le nom de l'instance avec l'état shutdown.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

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

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

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

Remplacer la carte mère

Les étapes de remplacement de la carte mère dans un serveur UCS C240 M4 peuvent être consultées dans le Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

1. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.
   
   
2. Procédez à la mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée utilisé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

Déplacer le CEPH hors du mode Maintenance

 Connectez-vous au noeud de calcul OSD et sortez CEPH du mode de maintenance.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset norebalance
[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset noout

[root@pod2-stack-osd-compute-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 v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects
 2404 GB used, 10989 GB / 13393 GB avail
 704 active+clean
 client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr

Restaurer les machines virtuelles

Récupérer une instance via un snapshot

Processus de récupération :

Il est possible de redéployer l'instance précédente à l'aide de l'instantané pris lors des étapes précédentes.

Étape 1 [FACULTATIF].S'il n'y a pas de VMsnapshot précédent disponible, connectez-vous au noeud OSPD où la sauvegarde a été envoyée et remettez la sauvegarde à son noeud OSPD d'origine. En utilisant «sftproot@x.x.x.x» où x.x.x.x est l'IP de l'OSPD d'origine. Enregistrez le fichier d'instantané dans le répertoire /tmp.

Étape 2.Connectez-vous au noeud OSPD où l'instance est redéployée.

Utilisez la commande suivante pour créer la source des variables d'environnement :

             

# source /home/stack/pod1-stackrc-Core-CPAR

Étape 3.L'utilisation de l'instantané en tant qu'image est nécessaire pour le télécharger vers l'horizon en tant que tel. Pour ce faire, utilisez la commande suivante.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot 

Le processus se profile à l'horizon.

Étape 4.Dans Horizon, accédez à Project > Instances et cliquez sur Launch Instance.

 Étape 5.Indiquez le nom de l'instance et sélectionnez la zone de disponibilité.

Étape 6.Dans l'onglet Source, choisissez l'image à créer. Dans le menu Sélectionner la source de démarrage, sélectionnez image, une liste d'images s'affiche ici, choisissez celle qui a été précédemment téléchargée lorsque vous cliquez sur le signe +.

Étape 7.Dans l'onglet Saveur, choisissez la saveur AAA lorsque vous cliquez sur le + signe.

  

Étape 8.Enfin, accédez à l'onglet Réseau et sélectionnez les réseaux dont l'instance a besoin lorsque vous cliquez sur le signe +. Dans ce cas, sélectionnez diameter-soutable1, radius-routable1 et tb1-mgmt.

  

Étape 9. Enfin, cliquez sur Launch instance pour le créer. La progression peut être suivie dans Horizon :

Après quelques minutes, l'instance est entièrement déployée et prête à l'emploi.

Créer et attribuer une adresse IP flottante

Une adresse IP flottante est une adresse routable, ce qui signifie qu'elle est accessible depuis l'extérieur de l'architecture Ultra M/Openstack et qu'elle peut communiquer avec d'autres noeuds à partir du réseau.

Étape 1.Dans le menu supérieur d’Horizon, accédez à Admin > Floating IPs.

Étape 2.Cliquez sur le boutonAllouerIP au projet.

Étape 3. Dans la fenêtre Allocate Floating IP, sélectionnez le pool auquel appartient la nouvelle adresse IP flottante, le projet auquel elle va être attribuée et la nouvelle adresse IP flottante elle-même.

Exemple :

Étape 4.Cliquez surAllocateFloating IPbutton.

Étape 5. Dans le menu supérieur Horizon, accédez à Projet > Instances.

Étape 6. Dans la colonne Action, cliquez sur la flèche pointant vers le bas du bouton Créer un instantané pour afficher un menu. SélectionnezAssocier une option IP flottante.

Étape 7. Sélectionnez l’adresse IP flottante correspondante à utiliser dans le champ Adresse IP et choisissez l’interface de gestion correspondante (eth0) dans la nouvelle instance où cette adresse IP flottante va être attribuée dans le port à associer. Reportez-vous à l'image suivante comme exemple de cette procédure.

                                  

Étape 8.Enfin, cliquez sur le bouton Associer.

Activation de SSH

Étape 1.Dans le menu supérieur Horizon, accédez à Projet > Instances.

Étape 2.Cliquez sur le nom de l'instance/VM créée dans la sectionLancer une nouvelle instance.

Étape 3.Cliquez surOnglet Console. L'interface de ligne de commande de la VM s'affiche.

Étape 4. Une fois l’interface de ligne de commande affichée, saisissez les informations de connexion appropriées :

           Nom d'utilisateur:racine

           Mot de passe : cisco123

                                          

Étape 5.Dans l'interface de ligne de commande, entrez la commande vi /etc/ssh/sshd_config pour modifier la configuration ssh.

Étape 6. Une fois le fichier de configuration ssh ouvert, appuyez sur Ipour le modifier. Recherchez ensuite la section affichée ici et modifiez la première ligne de PasswordAuthentication en PasswordAuthentication yes.

Étape 7.Appuyez sur Échap et entrez :wq! pour enregistrer les modifications apportées au fichier sshd_config.

Étape 8. Exécutez la commande service sshd restart.

                                      

Étape 9.Afin de tester que les modifications de configuration SSH ont été correctement appliquées, ouvrez tout client SSH et essayez d'établir une connexion sécurisée à distance à l'aide de l'IP flottante attribuée à l'instance (c'est-à-dire 10.145.0.249) et à la racine utilisateur.

Établir une session SSH

Ouvrez une session SSH en utilisant l'adresse IP de la machine virtuelle/du serveur correspondant où l'application est installée.

Début de l'instance CPAR

Veuillez suivre ces étapes, une fois l'activité terminée et les services CPAR peuvent être rétablis dans le site qui a été fermé.

1. Reconnectez-vous à Horizon, accédez à Project > Instance > Start Instance.
   
   
2. Vérifiez que l'état de l'instance est actif et que l'état d'alimentation est en cours d'exécution :

Contrôle d'intégrité post-activité

Étape 1 : exécutez la commande /opt/CSCOar/bin/arstatus au niveau du système d’exploitation.

[root@aaa04 ~]# /opt/CSCOar/bin/arstatus
Cisco Prime AR RADIUS server running       (pid: 24834)
Cisco Prime AR Server Agent running        (pid: 24821)
Cisco Prime AR MCD lock manager running    (pid: 24824)
Cisco Prime AR MCD server running          (pid: 24833)
Cisco Prime AR GUI running                 (pid: 24836)
SNMP Master Agent running                (pid: 24835)
[root@wscaaa04 ~]#

Étape 2 : exécutez la commande /opt/CSCOar/bin/aregcmd au niveau du système d’exploitation et saisissez les informations d’identification de l’administrateur. Vérifiez que CPAR Health est 10 sur 10 et quittez CPAR CLI.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]

    LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

                  PAR-ADD-TPS 7.2(2000TPS:)

                  PAR-RDDR-TRX 7.2()

                  PAR-HSS 7.2()

    Radius/

    Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit

Étape 3.Exécutez la commande netstat | grep diameter et vérifiez que toutes les connexions DRA sont établies.

Le résultat mentionné ici est pour un environnement où des liaisons de diamètre sont attendues. Si moins de liens sont affichés, cela représente une déconnexion du DRA qui doit être analysée.

[root@aa02 logs]# netstat | grep diameter
tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

Étape 4. Vérifiez que le journal TPS indique les demandes en cours de traitement par CPAR. Les valeurs mises en évidence représentent le TPS et ce sont celles auxquelles nous devons prêter attention.

La valeur de TPS ne doit pas dépasser 1500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv
11-21-2017,23:57:35,263,0
11-21-2017,23:57:50,237,0
11-21-2017,23:58:05,237,0
11-21-2017,23:58:20,257,0
11-21-2017,23:58:35,254,0
11-21-2017,23:58:50,248,0
11-21-2017,23:59:05,272,0
11-21-2017,23:59:20,243,0
11-21-2017,23:59:35,244,0
11-21-2017,23:59:50,233,0

 

Étape 5.Recherchez les messages d'erreur ou d'alarme dans name_radius_1_log

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Étape 6.Vérifiez la quantité de mémoire utilisée par le processus CPAR avec cette commande :

peigné | rayon grep

[root@sfraaa02 ~]# top | grep radius
27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Cette valeur mise en surbrillance doit être inférieure à : 7 Go, soit le maximum autorisé au niveau de l'application.

Remplacement de la carte mère dans le noeud contrôleur

Vérifier l'état du contrôleur et mettre le cluster en mode de maintenance

À partir de l'OSPD, connectez-vous au contrôleur et vérifiez que les ordinateurs sont en bon état : les trois contrôleurs en ligne et galera affichent les trois contrôleurs comme maîtres. 

[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: Fri Jul 6 09:02:52 2018Last change: Mon Jul 2 12:49:52 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

Mettre le cluster en mode maintenance

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster standby

[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: Fri Jul 6 09:03:10 2018Last change: Fri Jul 6 09:03:06 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Node pod2-stack-controller-0: standby
Online: [ 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-1 pod2-stack-controller-2 ]
 Stopped: [ pod2-stack-controller-0 ]
 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-1 ]
 Stopped: [ pod2-stack-controller-0 ]
 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

Remplacer la carte mère

La procédure de remplacement de la carte mère dans un serveur UCS C240 M4 est disponible dans le Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

1. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.
   
   
2. Procédez à la mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée utilisée précédemment. Les étapes de la mise à niveau du BIOS sont indiquées ici :

      Guide de mise à niveau du BIOS du serveur rack Cisco UCS série C

Restaurer l'état du cluster

Connectez-vous au contrôleur concerné, supprimez le mode standby en définissant unstandby.  Vérifiez que le contrôleur est disponible en ligne avec le cluster et que galera affiche les trois contrôleurs comme maître.  Cette opération peut prendre quelques minutes.

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster unstandby

[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: Fri Jul 6 09:03:37 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-1 pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 ]
 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-1 pod2-stack-controller-2 ]
 Stopped: [ pod2-stack-controller-0 ]
 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