Contenu

Introduction

Informations générales

Abréviations

Dépannage de RMA de composant - Noeud Compute/OSD-Compute

Étape 1. Arrêt gracieux

Identifier les machines virtuelles hébergées dans le noeud Compute/OSD-Compute

Pour l'arrêt gracieux de la machine virtuelle du Gestionnaire de cluster

Pour l'arrêt gracieux de la machine virtuelle PD/équilibreur de charge actif

Pour la mise hors tension gracieuse de la machine virtuelle PD/équilibreur de charge de secours

Pour l'arrêt gracieux de la machine virtuelle PS/QNS

Pour l'arrêt gracieux de la machine virtuelle OAM/pcrfclient

Pour la machine virtuelle arbitre

Étape 2. Sauvegarde de base de données ESC.

Étape 3. Migrer l'ESC en mode veille.

Étape 4. Remplacez le composant défectueux du noeud Compute/OSD-Compute.

Étape 5. Restaurer les machines virtuelles

Récupération VM de l'ESC

Récupération de la machine virtuelle ESC

Manipulation de l'échec de récupération ESC

Dépannage de la RMA de composant - Noeud contrôleur

Étape 1. Contrôleur - Précontrôles

Étape 2. Déplacer le cluster du contrôleur en mode Maintenance.

Étape 3. Remplacez le composant défectueux du noeud contrôleur.

Étape 4. Mettez le serveur sous tension.

Introduction

Ce document décrit les étapes requises pour remplacer les composants défectueux mentionnés ici dans un serveur Cisco Unified Computing System (UCS) dans une configuration Ultra-M qui héberge les fonctions de réseau virtuel (VNF) de Cisco Policy Suite (CPS).

- Module de mémoire DIMM (Dual In-line Memory Module) de remplacement

- Défaillance du contrôleur FlexFlash

- Défaillance du disque dur SSD (Solid State Drive)

- Défaillance du module de plateforme sécurisée (TPM)

- Échec du cache RAID

- Panne du contrôleur RAID/adaptateur HBA (Hot Bus Adapter)

- Panne de montage PCI

- Carte PCIe Intel X520 10G en panne

- Défaillance de la carte mère LAN-on modulaire (MLOM)

- Unité de ventilation RMA

- Défaillance du processeur

Contribué par Nitesh Bansal, Cisco Advance Services.

Informations générales

Ultra-M est une solution 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 comprend les types de noeuds suivants :

- Calcul

- Disque de stockage d'objets - Calcul (OSD - Calcul)

- Contrôleur

- Plate-forme OpenStack - Director (OSPD)

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

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

Avant de remplacer un composant défectueux, il est important de vérifier l'état actuel de l'environnement de plate-forme Red Hat Open Stack. Il est recommandé de vérifier l'état actuel afin d'éviter les complications lorsque le processus de remplacement est activé.

En cas de récupération, Cisco recommande de procéder à la sauvegarde de la base de données OSPD à l'aide des étapes suivantes :

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

Note: Si un serveur est un noeud contrôleur, passez à la section , sinon passez à la section suivante.

Abréviations

VNF

Fonction de réseau virtuel

PD

Policy Director (équilibreur de charge)

PS

Policy Server ( pcrfclient )

Échap

Contrôleur de service flexible

MOP

Méthode de procédure

OSD

Disques de stockage d'objets

HDD

Disque dur

SSD

Disque dur SSD

VIM

Gestionnaire d'infrastructure virtuelle

VM

Machine virtuelle

SM

Gestionnaire de session

QNS

Serveur de noms Quantum

UUID

Identificateur unique

Dépannage de RMA de composant - Noeud Compute/OSD-Compute

Étape 1. Arrêt gracieux

Identifier les machines virtuelles hébergées dans le noeud Compute/OSD-Compute

Le calcul/OSD-Compute peut héberger plusieurs types de VM. Identifiez toutes les étapes et poursuivez avec le noeud sans système d'exploitation particulier et pour les noms de machines virtuelles spécifiques hébergés sur ce calcul :

[stack@director ~]$ nova list --field name,host | grep compute-10

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634     |

pod1-compute-10.localdomain    |

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88     |

pod1-compute-10.localdomain    |

Pour l'arrêt gracieux de la machine virtuelle du Gestionnaire de cluster

Étape 1. Créez un snapshot et FTP du fichier vers un autre emplacement en dehors du serveur ou, si possible, en dehors du rack lui-même.

openstack image create --poll

Étape 2. Arrêter la machine virtuelle de l'ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>

Étape 3. Vérifiez si la machine virtuelle est arrêtée.

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634

VM_SHUTOFF_STATE

Pour l'arrêt gracieux de la machine virtuelle PD/équilibreur de charge actif

Étape 1. Connectez-vous à la bibliothèque active et arrêtez les services comme ci-dessous

- Basculer de actif en veille

service corosync restart

- arrêter les services sur l'adaptateur de secours

service monit stop

service qns stop

Étape 2. À partir du maître ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

Étape 3.  Vérifiez si la machine virtuelle est arrêtée.

admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour la mise hors tension gracieuse de la machine virtuelle PD/équilibreur de charge de secours

Étape 1. Connectez-vous à la bibliothèque de secours et arrêtez les services.

service monit stop

service qns stop

Étape 2. À partir du maître ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

Étape 3. Vérifiez si la machine virtuelle est arrêtée.

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour l'arrêt gracieux de la machine virtuelle PS/QNS

Étape 1. Arrêter le service :

service monit stop

service qns stop

Étape 2. À partir du maître ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

Étape 3.  Vérifiez si la machine virtuelle est arrêtée.

[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour la mise hors tension gracieuse de la machine virtuelle SM

Étape 1. Arrêtez tous les services de mongo présents dans sessionmgr.

[root@sessionmg01 ~]# cd /etc/init.d

[root@sessionmg01 init.d]# ls -l sessionmgr*

[root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [  OK  ]

Étape 2. À partir du maître ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

Étape 3. Vérifiez si la machine virtuelle est arrêtée.

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour l'arrêt gracieux de la machine virtuelle OAM/pcrfclient

Étape 1. Vérifiez si le SVN de stratégie est synchronisé à l'aide de ces commandes. Si une valeur est renvoyée, le SVN est déjà synchronisé et vous n'avez pas besoin de la synchroniser à partir de PCRFCLIENT02. Vous devez ignorer la récupération de la dernière sauvegarde peut toujours être utilisée si nécessaire.

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

Étape 2. Rétablir la synchronisation maître/esclave SVN entre pcrfclient01 et pcrfclient02 avec pcrfclient01 comme maître en exécutant la série de commandes sur PCRFCLIENT01.

/bin/rm -fr /var/www/svn/repos

/usr/bin/svnadmin create /var/www/svn/repos

/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0

http://pcrfclient02/repos-proxy-sync

/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"

/etc/init.d/vm-init-client

/var/qps/bin/support/recover_svn_sync.sh

Étape 3.  Effectuez une sauvegarde du SVN dans le gestionnaire de clusters.

config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz

Étape 4.  Arrêtez les services dans pcrfclient.

service monit stop

service qns stop

Étape 5.  Du maître ESC :

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

Étape 6.  Vérifiez si la machine virtuelle est arrêtée.

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour la machine virtuelle arbitre

Étape 1. Connectez-vous à l'arbitre et arrêtez les services.

[root@SVS1OAM02 init.d]# ls -lrt sessionmgr*

-rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721

-rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718

-rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719

-rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717

-rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720

service monit stop

service qns stop

/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.

Étape 2.À partir du maître ESC

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

Étape 3. Vérifiez si la machine virtuelle est arrêtée.

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Pour le contrôleur de services élastiques (ESC)

Étape 1. Les configurations de l'ESC-HA doivent être sauvegardées tous les mois, avant/après toute opération d'évolutivité ou de réduction avec le VNF et avant/après les modifications de configuration à l'ESC. Il convient de le renforcer afin d'assurer une reprise après sinistre de l'ESC de manière efficace

1. Connectez-vous à l'ESC à l'aide des informations d'identification et de connexion admin et exportez les données opdata au format XML.

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u

-p

--get-config > /home/admin/ESC_config.xml

2. Téléchargez ce fichier sur votre ordinateur local de ftp/sftp vers un serveur en dehors du cloud.

Étape 2. Sauvegarder la configuration du cloud PCRF Tous les scripts et fichiers de données utilisateur référencés dans les XML de déploiement.

1. Rechercher tous les fichiers de données utilisateur référencés dans les XML de déploiement de tous les VNF à partir des opdata exportés à l'étape précédente.Exemple de sortie.

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg

2. Recherchez tous les scripts de post-déploiement utilisés pour envoyer l'API d'orchestration CPS.

3. Exemples de scripts de post-déploiement dans esc opdata.

Exemple 1 :

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

----------

script_filename

/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py

script_timeout

3600

Exemple 2 :

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

CLUMAN_MGMT_ADDRESS

10.174.132.46

CLUMAN_YAML_FILE

/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml

script_filename

/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py

wait_max_timeout

3600

Si les opdata de l'ESC de déploiement (extraites à l'étape précédente) contiennent l'un des fichiers mis en surbrillance, effectuez la sauvegarde.

Exemple de commande de sauvegarde :

tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/

Téléchargez ce fichier sur votre ordinateur local de ftp/sftp vers un serveur en dehors du cloud.

Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.

Étape 2. Sauvegarde de base de données ESC.

Étape 1. Collectez les journaux des machines virtuelles ESC deux et sauvegardez-les.

$ collect_esc_log.sh

$ scp /tmp/

@

:

Étape 2. Sauvegarder la base de données à partir du noeud ECS maître.

Étape 3. Passez à l'utilisateur racine et vérifiez l'état de l'ESC principal et validez que la valeur de sortie est Master.

$ sudo bash

$ escadm status

Set ESC to maintenance mode & verify

$ sudo escadm op_mode set --mode=maintenance

$ escadm op_mode show

Étape 4. Utilisez une variable pour définir le nom du fichier, inclure les informations de date et appeler l'outil de sauvegarde et fournir la variable de nom de fichier de l'étape précédente.

fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S")

$ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar

Étape 5. Vérifiez le fichier de sauvegarde dans votre stockage de sauvegarde et assurez-vous qu'il est présent.

Étape 6. Remettez l'ESC Master en mode de fonctionnement normal.

$ sudo escadm op_mode set --mode=operation

Si l'utilitaire de sauvegarde dbtool échoue, appliquez la solution de contournement suivante une fois dans le noeud ESC. Répétez ensuite l'étape 6.

$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump,"

/opt/cisco/esc/esc-scripts/esc_dbtool.py

Étape 3. Migrer l'ESC en mode veille.

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

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status

0 ESC status=0 ESC Master Healthy

[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop Stopping keepalived:

[  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status

1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot

Broadcast message from admin@vnf1-esc-esc-0.novalocal

(/dev/pts/0) at 13:32 ...

The system is going down for reboot NOW!

Étape 2. Une fois que la machine virtuelle est en veille ESC, arrêtez la machine virtuelle à l'aide de la commande shutdown -r now

Note: Si le composant défectueux doit être remplacé sur le noeud OSD-Compute, mettez le CEPH dans Maintenance sur le serveur avant de procéder au remplacement du composant.

[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance

set norebalance

[admin@osd-compute-0 ~]$ sudo ceph osd set noout

set noout

[admin@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 {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2

osdmap e194: 12 osds: 12 up, 12 in

flags noout,norebalance,sortbitwise,require_jewel_osds

pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

Étape 4. Remplacez le composant défectueux du noeud Compute/OSD-Compute.

Mettez le serveur spécifié hors tension. Pour remplacer un composant défectueux sur le serveur UCS C240 M4, procédez comme suit :

Remplacement des composants du serveur

Reportez-vous à la procédure Connexion permanente ci-dessous et exécutez-la si nécessaire.

Étape 5. Restaurer les machines virtuelles

Récupération VM de l'ESC

1. La machine virtuelle serait dans l'état d'erreur dans la liste nova.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     |

2. Récupérez les machines virtuelles à partir de l'ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

[sudo] password for admin:

Recovery VM Action

/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW

3. Surveillez la yangesc.log

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log

…

14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE

14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS

14:59:50,112 07-Nov-2017 WARN  Status Code: 200

14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

4. Vérifiez tous les services des machines virtuelles en cours de démarrage.

Récupération de la machine virtuelle ESC

1. Connectez-vous à l'ESC via la console et vérifiez l'état.

2. Démarrer les processus si ce n'est déjà fait

[admin@esc ~]$ sudo service keepalived start

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

Manipulation de l'échec de récupération ESC

Dans les cas où l'ESC ne démarre pas la machine virtuelle en raison d'un état inattendu, Cisco recommande d'effectuer une commutation ESC en redémarrant l'ESC principal. Le passage à l'ESC prendrait environ une minute. Exécutez le script “ health.sh ” sur le nouvel ESC maître pour vérifier si l'état est actif. Master ESC pour démarrer la machine virtuelle et régler l'état de la machine virtuelle. Cette tâche de récupération prend jusqu'à 5 minutes.

Vous pouvez surveiller /var/log/esc/yangesc.log et /var/log/esc/escmanager.log. Si vous ne voyez PAS la récupération de la machine virtuelle après 5 à 7 minutes, l'utilisateur doit effectuer la récupération manuelle des machines virtuelles affectées.

Si la machine virtuelle ESC n'est pas restaurée, suivez la procédure de déploiement d'une nouvelle machine virtuelle ESC. Contactez l'assistance Cisco pour connaître la procédure.

Dépannage de la RMA de composant - Noeud contrôleur

Étape 1. Contrôleur - Précontrôles

À partir d'OSPD, connectez-vous au contrôleur et vérifiez que les ordinateurs sont dans un bon état : les trois contrôleurs en ligne et la galère affichant les trois contrôleurs en tant que maîtres.

Note: Un cluster sain nécessite 2 contrôleurs actifs, donc vérifiez que les deux autres contrôleurs sont en ligne et actifs.

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

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec  4 00:46:10 2017                        Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0

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

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Étape 2. Déplacer le cluster du contrôleur en mode Maintenance.

1. Mettre le cluster pc sur le contrôleur en cours de mise à jour en veille.

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

2. Vérifiez à nouveau l'état des ordinateurs et assurez-vous que le cluster des ordinateurs s'est arrêté sur ce noeud.

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

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec  4 00:48:24 2017                        Last change: Mon Dec  4 00:48:18 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Node pod1-controller-0: standby

Online: [ pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-1 pod1-controller-2 ]

Stopped: [ pod1-controller-0 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-1 pod1-controller-2 ]

Slaves: [ pod1-controller-0 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-1 ]

Stopped: [ pod1-controller-0 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

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

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

3. L'état des ordinateurs sur les 2 autres contrôleurs doit également afficher le noeud en veille.

Étape 3. Remplacez le composant défectueux du noeud contrôleur.

Mettez le serveur spécifié hors tension. Pour remplacer un composant défectueux sur le serveur UCS C240 M4, procédez comme suit :

Remplacement des composants du serveur

Étape 4. Mettez le serveur sous tension.

1. Mettez le serveur sous tension et vérifiez que le serveur est allumé.

[stack@tb5-ospd ~]$ source stackrc

[stack@tb5-ospd ~]$ nova list |grep pod1-controller-0

| 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |

2. Connectez-vous au contrôleur affecté, supprimez le mode veille en configurant unstandby. Vérifiez que le contrôleur est disponible en ligne avec le cluster et que la galère affiche les trois contrôleurs comme Master. Cela peut prendre quelques minutes.

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

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

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec  4 01:08:10 2017                        Last change: Mon Dec  4 01:04:21 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

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

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

3. Vous pouvez vérifier certains services de surveillance, tels que la céphalée, qu'ils sont en bonne santé.

[heat-admin@pod1-controller-0 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0}

election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2

osdmap e218: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects

2142 GB used, 11251 GB / 13393 GB avail

704 active+clean

client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr