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

Introduction

Ce document décrit les étapes requises pour remplacer une carte mère défectueuse d'un serveur dans une configuration Ultra-M qui héberge des fonctions de réseau virtuel (VNF) CPS.

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
• 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 de Cisco qui connaît la plate-forme Cisco Ultra-M et détaille les étapes à suivre au niveau OpenStack et StarOS VNF au moment du remplacement de la carte mère sur un serveur.

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

Abréviations

VNF	Fonction de réseau virtuel
É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
EM	Gestionnaire d'éléments
UAS	Services d’automatisation ultra
UUID	Identificateur unique

Flux de travail du MoP

Remplacement de la carte mère dans la configuration UltraM

Dans une configuration Ultra-M, il peut y avoir des scénarios où un remplacement de carte mère est nécessaire dans les types de serveurs suivants : Compute, OSD-Compute et Controller.

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

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 correctement désactivées. 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

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

Le serveur de calcul contient des machines virtuelles CPS ou Échap (Elastic Services Controller) :

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

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

Mise hors tension gracieuse

Le noeud de calcul héberge les machines virtuelles CPS/ESC

Étape 1. Connectez-vous au noeud ESC correspondant au VNF et vérifiez l'état des machines virtuelles.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

Étape 2. Arrêtez les machines virtuelles CPS une par une à l'aide de son nom de machine virtuelle. (Nom de la machine virtuelle indiqué dans la section Identifier les machines virtuelles hébergées dans le noeud de calcul).

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

Étape 3. Après son arrêt, les machines virtuelles doivent entrer l'état SHUTOFF.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
     
     
       VM_SHUTOFF_STATE 
     
<snip>

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

[admin@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!

Sauvegarde ESC

Étape 1. La redondance 1:1 est présente dans la solution UltraM. 2 machines virtuelles ESC sont déployées et prennent en charge une seule panne dans UltraM. c'est-à-dire que le système est récupéré en cas de défaillance unique.

Note: En cas de panne, elle n'est pas prise en charge et peut nécessiter un redéploiement du système.

Détails de la sauvegarde ESC :

• La configuration d'exécution
• Base de données CDB ConfD
• Journaux ESC
• Configuration Syslog

Étape 2. La fréquence de sauvegarde de la base de données ESC est délicate et doit être manipulée avec soin lorsque l'ESC surveille et gère les différents ordinateurs d'état pour les différentes machines virtuelles VNF déployées. Il est conseillé que ces sauvegardes soient effectuées après les activités suivantes dans un VNF/POD/Site donné.

Étape 3. Vérifiez que l'état de l'ESC est correct pour l'utilisation du script health.sh.

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running...                           [  OK  ]
postgresql-9.4 (pid  2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0

=======================================

ESC HEALTH PASSED

Étape 4. Effectuez une sauvegarde de la configuration en cours et transférez le fichier sur le serveur de sauvegarde.

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

Base de données ESC de sauvegarde

Étape 1. Connectez-vous à la machine virtuelle ESC et exécutez cette commande avant de prendre la sauvegarde.

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

Étape 2. Vérifiez le mode ESC et assurez-vous qu'il est en mode maintenance.

[root@esc esc-scripts]# escadm op_mode show

Étape 3. Sauvegarder la base de données à l'aide de l'outil de restauration de sauvegarde de base de données disponible dans ESC.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

Étape 4. Réglez l'ESC de nouveau sur Mode de fonctionnement et confirmez le mode.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

Étape 5. Accédez au répertoire des scripts et collectez les journaux.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

Étape 6. Pour créer un instantané de l'ESC, arrêtez d'abord l'ESC.

shutdown -r now

Étape 7. À partir d'OSPD, créez un instantané d'image.

•  nova image-create --poll esc1 esc_snapshot_27aug2018 

Étape 8. Vérifier la création de l'instantané 

openstack image list | grep esc_snapshot_27aug2018

Étape 9. Démarrer l'ESC à partir d'OSPD 

nova start esc1 

Étape 10. Répétez la même procédure sur la machine virtuelle ESC de secours et transférez les journaux sur le serveur de sauvegarde.

Étape 11. Collectez la sauvegarde de configuration Syslog sur le serveur de sauvegarde ESC VMS et transférez-les sur le serveur de sauvegarde.

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

Remplacer la carte mère

Étape 1. Pour remplacer la carte mère dans un serveur UCS C240 M4, procédez comme suit :

Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

Étape 2. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.

Étape 3. Effectuez une mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée précédemment 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

Restaurer les machines virtuelles

Le noeud de calcul héberge CPS, ESC

Récupération de la machine virtuelle ESC

Étape 1. La machine virtuelle ESC peut être restaurée si la machine virtuelle est en état d'erreur ou d'arrêt, redémarrez définitivement la machine virtuelle affectée. Exécutez ces étapes pour récupérer ESC.

Étape 2. Identifiez la machine virtuelle qui est en état d'ERREUR ou d'arrêt, une fois identifiée comme redémarrage matériel de la machine virtuelle ESC. Dans cet exemple, redémarrez auto-test-vnfm1-ESC-0.

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

Étape 3. Si la VM ESC est supprimée et doit être réactivée. 

[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.

Étape 4. À partir d'OSPD, vérifiez que la nouvelle machine virtuelle ESC est ACTIVE/en cours d'exécution :

[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3                                                                                                 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6                                                                                                 |

#Log in to new ESC and verify Backup state.  You may execute health.sh on ESC Master too.

…
   ####################################################################
   #   ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

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

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

ESC HEALTH PASSED
[admin@esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Étape 5. Si la machine virtuelle ESC est irrécupérable et nécessite la restauration de la base de données, restaurez la base de données à partir de la sauvegarde précédemment prise.

Étape 6. Pour restaurer la base de données ESC, nous devons nous assurer que le service esc est arrêté avant de restaurer la base de données ; Pour la HA ESC, exécutez d'abord dans la VM secondaire, puis dans la VM principale.

# service keepalived stop

Étape 7. Vérifier l'état du service ESC et s'assurer que tout est arrêté dans les machines virtuelles principales et secondaires pour la haute disponibilité

# escadm status

Étape 8. Exécutez le script pour restaurer la base de données. Dans le cadre de la restauration de la base de données vers l'instance ESC nouvellement créée, l'outil va également promouvoir une des instances pour être un ESC primaire, monter son dossier DB sur le périphérique drbd et va démarrer la base de données PostgreSQL.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

Étape 9. Redémarrez le service ESC pour terminer la restauration de la base de données.

Pour l'exécution de HA dans les deux machines virtuelles, redémarrez le service conservé

# service keepalived start

Étape 10. Une fois la machine virtuelle restaurée et exécutée correctement ; assurez-vous que toute la configuration spécifique à syslog est restaurée à partir de la sauvegarde connue précédente. S'assurer qu'il est restauré dans toutes les machines virtuelles ESC

[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

Étape 11. Si l'ESC doit être reconstruit à partir d'un instantané OSPD, utilisez la commande ci-dessous en utilisant un instantané pris lors de la sauvegarde.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

Étape 12. Vérifiez l'état de l'ESC une fois la reconstruction terminée.

nova list --fileds name,host,status,networks | grep esc

Étape 13. Vérifiez l'état ESC à l'aide de la commande ci-dessous.

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

Restaurer les machines virtuelles CPS

La machine virtuelle CPS 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     | 

Récupérer la machine virtuelle CPS à 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
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

Surveillez 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].

Lorsque l'ESC ne démarre pas la machine virtuelle

Étape 1. Dans certains cas, l'ESC ne démarre pas la machine virtuelle en raison d'un état inattendu. Une solution de contournement consiste à effectuer un basculement ESC en redémarrant l'ESC principal. La commutation ESC prendra environ une minute.  Exécutez health.sh sur le nouvel ESC maître pour vérifier qu'il est actif. Lorsque l'ESC devient maître, l'ESC peut régler l'état de la machine virtuelle et démarrer la machine virtuelle. Comme cette opération est planifiée, vous devez attendre 5 à 7 minutes pour qu'elle se termine.

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

Étape 3. Une fois la machine virtuelle restaurée et exécutée correctement ; assurez-vous que toute la configuration spécifique à syslog est restaurée à partir de la sauvegarde connue précédente. Assurez-vous qu'il est restauré dans toutes les machines virtuelles ESC.

root@autotestvnfm1esc2:/etc/rsyslog.d# pwd
/etc/rsyslog.d

root@autotestvnfm1esc2:/etc/rsyslog.d# ll

total 28
drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]
-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf
-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf
-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf
-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf
-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf

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 correctement désactivées et le CEPH est mis en mode maintenance. Une fois la carte mère remplacée, les machines virtuelles sont restaurées et CEPH est déplacé hors du mode maintenance.

Mettre CEPH en mode Maintenance

Étape 1. Vérifier que l'état de l'arborescence osd ceph est actif sur le serveur

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

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2  4.35999     host pod1-osd-compute-0
 0  1.09000         osd.0                          up  1.00000          1.00000
 3  1.09000         osd.3                          up 1.00000          1.00000
 6  1.09000         osd.6                          up  1.00000          1.00000
 9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod1-osd-compute-2
 1  1.09000        osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000 

Étape 2. Connectez-vous au noeud de calcul OSD et mettez CEPH en mode maintenance.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# 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 {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap 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

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

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

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

Le serveur de calcul contient des machines virtuelles ESC (Elastic Services Controller) ou CPS

[stack@director ~]$ nova list --field name,host | grep osd-compute-1
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

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

Mise hors tension gracieuse

Cas 1 . OSD-Computing Noeud Hôtes ESC

La procédure permettant de mettre gracieusement sous tension les machines virtuelles ESC ou CPS est identique, que les machines virtuelles soient hébergées dans Compute ou dans le noeud OSD-Compute.

Suivez les étapes de « Remplacement de la carte mère dans le noeud de calcul » pour éteindre les machines virtuelles avec grâce.

Remplacer la carte mère

Étape 1. Pour remplacer la carte mère dans un serveur UCS C240 M4, procédez comme suit :

Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

Étape 2. Connectez-vous au serveur à l’aide de l’adresse IP CIMC

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

Déplacer le CEPH hors du mode maintenance

Connectez-vous au noeud de calcul OSD et déplacez CEPH hors du mode de maintenance.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e196: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

Restaurer les machines virtuelles

Cas 1 . Noeud OSD-Compute hébergeant des machines virtuelles ESC ou CPS

La procédure de restauration des machines virtuelles CF/ESC/EM/UAS est identique, que les machines virtuelles soient hébergées dans Compute ou dans le noeud OSD-Compute.

Suivez les étapes de « Case 2. Compute Node héberge CF/ESC/EM/UAS pour restaurer les machines virtuelles.

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

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

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

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

Mettez le cluster en mode maintenance.

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Remplacer la carte mère

Étape 1. Pour remplacer la carte mère dans un serveur UCS C240 M4, procédez comme suit :

Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

Étape 2. Connectez-vous au serveur à l'aide de l'adresse IP CIMC.

Étape 3. Effectuez une mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée précédemment 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

Restaurer l'état du cluster

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 pourrait 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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

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