Contenu

Introduction

Informations générales

Abréviations

Flux de travail du MoP

Remplacement de la carte mère dans la configuration UltraM

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

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

Mise hors tension gracieuse

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

Sauvegarde ESC

Base de données ESC de sauvegarde

Remplacer la carte mère

Restaurer les machines virtuelles

Le noeud de calcul héberge CPS, ESC

Restaurer les machines virtuelles CPS

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

Mettre CEPH en mode Maintenance

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

Mise hors tension gracieuse

Cas 1 . OSD-Computing Noeud Hôtes ESC

Remplacer la carte mère

Déplacer le CEPH hors du mode maintenance

Restaurer les machines virtuelles

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

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

Remplacer la carte mère

Restaurer l'état du cluster

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