Échec d'un disque dur unique Ultra-M UCS 240M4 - Procédure de remplacement à chaud - CPS

Introduction

Ce document décrit les étapes requises pour remplacer le lecteur de disque dur défectueux dans un serveur dans une configuration Ultra-M qui héberge les VNF (Virtual Network Function) de Cisco Policy Suite (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 concernés sont illustrés dans cette image :

Architecture UltraM

Note: La version Ultra M 5.1.x est prise en compte afin de définir les procédures de ce document. Ce document est destiné au personnel Cisco qui connaît la plate-forme Cisco Ultra-M et décrit les étapes à suivre au niveau OpenStack au moment du remplacement du serveur OSPD.

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

Panne de disque dur unique

1. Chaque serveur sans système d'exploitation sera provisionné avec deux disques durs afin d'agir en tant que disque de démarrage dans la configuration Raid 1. En cas de défaillance d'un seul disque dur, étant donné qu'il existe une redondance de niveau 1, le disque dur défectueux peut être remplaçable à chaud.

2. Référez-vous à la procédure pour remplacer un composant défectueux sur le serveur UCS C240 M4 ici : Remplacement des composants serveur

3. En cas de défaillance d'un seul disque dur, seul le disque dur défectueux sera remplacé à chaud et, par conséquent, aucune procédure de mise à niveau du BIOS n'est requise après le remplacement des nouveaux disques.

4. Après avoir remplacé les disques, attendez la synchronisation des données entre les disques. Cela peut prendre quelques heures.

5. Dans une solution OpenStack (Ultra-M), le serveur sans système d'exploitation UCS 240M4 peut assumer l'un des rôles suivants : Compute, OSD-Compute, Controller et OSPD.

6. Les étapes requises pour gérer la défaillance d'un seul disque dur dans chacun de ces rôles de serveur sont identiques et cette section décrit les contrôles d'intégrité à effectuer avant le remplacement à chaud du disque.

Panne de disque dur unique sur un serveur de calcul

1. Si la défaillance des disques durs est observée dans l'UCS 240M4, qui agit en tant que noeud de calcul, effectuez ces contrôles d'intégrité avant d'entamer la procédure d'échange à chaud du disque défectueux.

2. Identifiez les machines virtuelles exécutées sur ce serveur et vérifiez que l'état des fonctions est correct.

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

Identifiez les machines virtuelles hébergées sur le serveur de calcul et vérifiez qu'elles sont actives et en cours d'exécution. 

Le serveur de calcul contient une combinaison de machines virtuelles CPS/ESC (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     | ACTIVE |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c2_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     | ACTIVE | 
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     | ACTIVE |

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.

Contrôles de santé

1. Connectez-vous à l'ESC hébergé dans le noeud de calcul et vérifiez l'état.

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy

  

2. Connectez-vous à l'UAS hébergé dans le noeud de calcul et vérifiez l'état.

ubuntu@autovnf2-uas-1:~$ sudo su
root@autovnf2-uas-1:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on autovnf2-uas-1
autovnf2-uas-1#show uas ha
uas ha-vip 172.18.181.101
autovnf2-uas-1#
autovnf2-uas-1#
autovnf2-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.18.181.101
INSTANCE IP   STATE  ROLE          
-----------------------------------
172.18.180.4  alive  CONFD-SLAVE            
172.18.180.5  alive  CONFD-MASTER  
172.18.180.8  alive  NA            

autovnf2-uas-1#show errors 
% No entries found.

3. Si les contrôles d'intégrité sont corrects, poursuivez la procédure d'échange à chaud sur disque défectueux et attendez la synchronisation des données car cela peut prendre quelques heures. Reportez-vous à : Remplacement des composants du serveur

4. Répétez ces procédures de contrôle d'intégrité afin de confirmer que l'état d'intégrité des machines virtuelles hébergées sur le noeud de calcul est restauré.

Défaillance d'un seul disque dur sur un serveur contrôleur

1. Si la défaillance des disques durs est observée dans l'UCS 240M4, qui agit en tant que noeud contrôleur, effectuez ces contrôles d'intégrité avant d'initialiser la procédure d'échange à chaud du disque défectueux.

2. Vérifiez l'état de Pacemaker sur les contrôleurs.

3. Connectez-vous à l'un des contrôleurs actifs et vérifiez l'état de Pacemaker. Tous les services doivent être exécutés sur les contrôleurs disponibles et arrêtés sur le contrôleur défaillant.

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-0 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Thu Jun 28 07:53:06 2018          Last change: Wed Jan 17 11:38:00 2018 by root via cibadmin on pod1-controller-0

3 nodes and 22 resources conimaged

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

Full list of resources:

 ip-10.2.2.2      (ocf::heartbeat:IPaddr2):       Started pod1-controller-0
 ip-11.120.0.42 (ocf::heartbeat:IPaddr2):       Started pod1-controller-1
 ip-11.119.0.42 (ocf::heartbeat:IPaddr2):       Started pod1-controller-2
 ip-11.120.0.50 (ocf::heartbeat:IPaddr2):       Started pod1-controller-0
 ip-11.118.0.48 (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 ]
 Clone Set: rabbitmq-clone [rabbitmq]
     Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
     Masters: [ pod1-controller-0 ]
     Slaves: [ pod1-controller-1 pod1-controller-2 ]
 openstack-cinder-volume        (systemd:openstack-cinder-volume):      Started pod1-controller-0
 my-ipmilan-for-controller-0    (stonith:fence_ipmilan):        Started pod1-controller-1
 my-ipmilan-for-controller-1    (stonith:fence_ipmilan):        Started pod1-controller-2
 my-ipmilan-for-controller-2    (stonith:fence_ipmilan):        Started pod1-controller-0

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

4. Vérifiez l'état MariaDB dans les contrôleurs actifs.

[stack@director] nova list | grep control
| 4361358a-922f-49b5-89d4-247a50722f6d | pod1-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.102 |
| d0f57f27-93a8-414f-b4d8-957de0d785fc | pod1-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.110 |

[stack@director ~]$ for i in 192.200.0.102 192.200.0.110 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done
*** 192.200.0.152 ***
Variable_name     Value
wsrep_local_state_comment  Synced
Variable_name     Value
wsrep_cluster_size         2
*** 192.200.0.154 ***
Variable_name     Value
wsrep_local_state_comment  Synced
Variable_name     Value
wsrep_cluster_size         2

Vérifiez que ces lignes sont présentes pour chaque contrôleur actif :

wsrep_local_state_comment: Synced

wsrep_cluster_size: 2

 5. Vérifiez l'état Rabbitmq dans les contrôleurs actifs.

[heat-admin@pod1-controller-0 ~]$ sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@pod1-controller-0' ...
[{nodes,[{disc,['rabbit@pod1-controller-0','rabbit@pod1-controller-1',
                'rabbit@pod1-controller-2']}]},
 {running_nodes,['rabbit@pod1-controller-2',
                 'rabbit@pod1-controller-1',
                 'rabbit@pod1-controller-0']},
 {cluster_name,<<"rabbit@pod1-controller-0.localdomain">>},
 {partitions,[]},
 {alarms,[{'rabbit@pod1-controller-2',[]},
          {'rabbit@pod1-controller-1',[]},
          {'rabbit@pod1-controller-0',[]}]}]

6. Si les contrôles d'intégrité sont corrects, exécutez la procédure d'échange à chaud sur disque défectueux et attendez la synchronisation des données car cela peut prendre quelques heures. Reportez-vous à : Remplacement des composants du serveur

7. Répétez ces procédures de contrôle d'intégrité afin de confirmer que l'état d'intégrité du contrôleur est restauré.

Défaillance d'un seul disque dur sur un serveur OSD-Computing

Si la défaillance des disques durs est observée dans l'UCS 240M4 qui agit comme un noeud OSD-Compute, effectuez ces vérifications d'intégrité avant d'initialiser la procédure d'échange à chaud du disque défectueux.

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

  

1. Le serveur de calcul contient la machine virtuelle ESC.

[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     | ACTIVE |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     | ACTIVE |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     | ACTIVE |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     | ACTIVE |

Note: Dans le résultat présenté ici, la première colonne correspond à (UUID), la deuxième colonne correspond au nom de la machine virtuelle et la troisième colonne au nom d'hôte où la machine virtuelle est présente.

2. Les processus Ceph sont actifs sur le serveur OSD-Compute.

[root@pod1-osd-compute-1 ~]# systemctl list-units *ceph*

UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

ceph-osd@11.service               loaded active running Ceph object storage daemon

ceph-osd@2.service                loaded active running Ceph object storage daemon

ceph-osd@5.service                loaded active running Ceph object storage daemon

ceph-osd@8.service                loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice         loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice          loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                   loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                   loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target               loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                       loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once            

3. Vérifiez que le mappage de l'OSD (disque HDD) au Journal (SSD) est correct.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph-disk list
/dev/sda :
 /dev/sda1 other, iso9660
 /dev/sda2 other, xfs, mounted on /
/dev/sdb :
 /dev/sdb1 ceph journal, for /dev/sdc1
 /dev/sdb3 ceph journal, for /dev/sdd1
 /dev/sdb2 ceph journal, for /dev/sde1
 /dev/sdb4 ceph journal, for /dev/sdf1
/dev/sdc :
 /dev/sdc1 ceph data, active, cluster ceph, osd.1, journal /dev/sdb1
/dev/sdd :
 /dev/sdd1 ceph data, active, cluster ceph, osd.7, journal /dev/sdb3
/dev/sde :
 /dev/sde1 ceph data, active, cluster ceph, osd.4, journal /dev/sdb2
/dev/sdf :
 /dev/sdf1 ceph data, active, cluster ceph, osd.10, journal /dev/sdb4

4. Vérifiez que l'état Ceph et le mappage de l'arborescence OSD sont corrects.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s
    cluster eb2bb192-b1c9-11e6-9205-525400330666
     health HEALTH_OK
            1 mons down, quorum 0,1 pod1-controller-0,pod1-controller-1
     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 28, quorum 0,1 pod1-controller-0,pod1-controller-1
     osdmap e709: 12 osds: 12 up, 12 in
            flags sortbitwise,require_jewel_osds
      pgmap v941813: 704 pgs, 6 pools, 490 GB data, 163 kobjects
            1470 GB used, 11922 GB / 13393 GB avail
                 704 active+clean
  client io 58580 B/s wr, 0 op/s rd, 7 op/s wr

[heat-admin@pod1-osd-compute-3 ~]$ 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                                  
-4  4.35999     host pod1-osd-compute-2                                   
 2  1.09000         osd.2                    up  1.00000          1.00000 
 5  1.09000         osd.5                    up  1.00000          1.00000 
 8  1.09000         osd.8                    up  1.00000          1.00000 
11  1.09000         osd.11                   up  1.00000          1.00000 
-5  4.35999     host pod1-osd-compute-3                                   
 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 

5. Si les contrôles d'intégrité sont corrects, poursuivez la procédure d'échange à chaud sur disque défectueux et attendez la synchronisation des données car cela peut prendre quelques heures. Reportez-vous à Remplacement des composants du serveur

6. Répétez ces procédures de contrôle d'intégrité afin de confirmer que l'état d'intégrité des machines virtuelles hébergées sur le noeud OSD-Compute est restauré.

Défaillance d'un seul disque dur sur un serveur OSPD

1. Si la défaillance des disques durs est observée dans l'UCS 240M4, qui agit comme un noeud OSPD, il est recommandé d'effectuer ces vérifications avant de lancer la procédure d'échange à chaud du disque défectueux.

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

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

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

[stack@director ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"

UNIT                                       LOAD   ACTIVE SUB     DESCRIPTION

neutron-dhcp-agent.service                 loaded active running OpenStack Neutron DHCP Agent
neutron-openvswitch-agent.service          loaded active running OpenStack Neutron Open vSwitch Agent
neutron-ovs-cleanup.service                loaded active exited  OpenStack Neutron Open vSwitch Cleanup Utility
neutron-server.service                     loaded active running OpenStack Neutron Server
openstack-aodh-evaluator.service           loaded active running OpenStack Alarm evaluator service
openstack-aodh-listener.service            loaded active running OpenStack Alarm listener service
openstack-aodh-notifier.service            loaded active running OpenStack Alarm notifier service
openstack-ceilometer-central.service       loaded active running OpenStack ceilometer central agent
openstack-ceilometer-collector.service     loaded active running OpenStack ceilometer collection service
openstack-ceilometer-notification.service  loaded active running OpenStack ceilometer notification agent
openstack-glance-api.service               loaded active running OpenStack Image Service (code-named Glance) API server
openstack-glance-registry.service          loaded active running OpenStack Image Service (code-named Glance) Registry server
openstack-heat-api-cfn.service             loaded active running Openstack Heat CFN-compatible API Service
openstack-heat-api.service                 loaded active running OpenStack Heat API Service
openstack-heat-engine.service              loaded active running Openstack Heat Engine Service
openstack-ironic-api.service               loaded active running OpenStack Ironic API service
openstack-ironic-conductor.service         loaded active running OpenStack Ironic Conductor service
openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector
openstack-ironic-inspector.service         loaded active running Hardware introspection service for OpenStack Ironic
openstack-mistral-api.service              loaded active running Mistral API Server
openstack-mistral-engine.service           loaded active running Mistral Engine Server
openstack-mistral-executor.service         loaded active running Mistral Executor Server
openstack-nova-api.service                 loaded active running OpenStack Nova API Server
openstack-nova-cert.service                loaded active running OpenStack Nova Cert Server
openstack-nova-compute.service             loaded active running OpenStack Nova Compute Server
openstack-nova-conductor.service           loaded active running OpenStack Nova Conductor Server
openstack-nova-scheduler.service           loaded active running OpenStack Nova Scheduler Server
openstack-swift-account-reaper.service     loaded active running OpenStack Object Storage (swift) - Account Reaper
openstack-swift-account.service            loaded active running OpenStack Object Storage (swift) - Account Server
openstack-swift-container-updater.service  loaded active running OpenStack Object Storage (swift) - Container Updater
openstack-swift-container.service          loaded active running OpenStack Object Storage (swift) - Container Server
openstack-swift-object-updater.service     loaded active running OpenStack Object Storage (swift) - Object Updater
openstack-swift-object.service             loaded active running OpenStack Object Storage (swift) - Object Server
openstack-swift-proxy.service              loaded active running OpenStack Object Storage (swift) - Proxy Server
openstack-zaqar.service                    loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server
openstack-zaqar@1.service                  loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1
openvswitch.service                        loaded active exited  Open vSwitch

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

4. Si les contrôles d'intégrité sont corrects, exécutez la procédure d'échange à chaud sur disque défectueux et attendez la synchronisation des données car cela peut prendre quelques heures. Reportez-vous à Remplacement des composants du serveur

5. Répétez ces procédures de contrôle d'intégrité afin de confirmer que l'état d'intégrité du noeud OSPD est restauré.