Fallo de unidad de disco duro único Ultra-M UCS 240M4 - Procedimiento de intercambio en caliente - CPS

Introducción

Este documento describe los pasos necesarios para reemplazar la unidad HDD defectuosa en un servidor en una configuración Ultra-M que aloja Cisco Policy Suite (CPS) Virtual Network Function (VNF).

Antecedentes

Ultra-M es una solución de núcleo de paquetes móviles virtualizada validada y empaquetada previamente diseñada para simplificar la implementación de VNF. OpenStack es el Virtualized Infrastructure Manager (VIM) para Ultra-M y consta de estos tipos de nodos:

• Informática
• Disco de almacenamiento de objetos - Compute (OSD - Compute)
• Controlador
• Plataforma OpenStack: Director (OSPD)

La arquitectura de alto nivel de Ultra-M y los componentes involucrados son como se muestra en esta imagen:

Arquitectura UltraM

Nota: Se considera la versión Ultra M 5.1.x para definir los procedimientos en este documento. Este documento está dirigido al personal de Cisco que está familiarizado con la plataforma Cisco Ultra-M y detalla los pasos necesarios para llevarse a cabo a nivel de OpenStack en el momento de la sustitución del servidor OSPD.

Abreviaturas

VNF	Función de red virtual
ESC	Controlador de servicio elástico
MOP	Método de procedimiento
OSD	Discos de almacenamiento de objetos
HDD	Unidad de disco duro
SSD	Unidad de estado sólido
VIM	Administrador de infraestructura virtual
VM	Máquina virtual
EM	Administrador de elementos
UAS	Servicios de ultra automatización
UUID	Identificador único universal

Flujo de trabajo del MoP

Fallo único del disco duro

1. Cada servidor Baremetal se aprovisionará con dos unidades HDD para actuar como disco de arranque en la configuración Raid 1. En caso de fallo único del disco duro, ya que hay redundancia de nivel Raid 1, la unidad de disco duro defectuosa puede intercambiarse en caliente.

2. Consulte el procedimiento para sustituir un componente defectuoso en el servidor UCS C240 M4 aquí: Sustitución de los Componentes del Servidor

3. En caso de fallo único del disco duro, sólo el disco duro defectuoso se intercambiará en caliente y, por lo tanto, no se requiere ningún procedimiento de actualización del BIOS después de sustituir los discos nuevos.

4. Después de reemplazar los discos, espere a que se sincronicen los datos entre los discos. Podría tardar un par de horas en completarse.

5. En una solución basada en OpenStack (Ultra-M), el servidor de estructura básica UCS 240M4 puede asumir una de estas funciones: Compute, OSD-Compute, Controller y OSPD.

6. Los pasos requeridos para manejar la falla de un disco duro en cada una de estas funciones de servidor son los mismos y esta sección describe las verificaciones de estado que deben realizarse antes del intercambio en caliente del disco.

Fallo de disco duro único en un servidor informático

1. Si se observa la falla de las unidades HDD en UCS 240M4, que actúa como nodo Informático, realice estas comprobaciones de estado antes de iniciar el procedimiento Hot Swap del disco defectuoso.

2. Identifique las VM que se ejecutan en este servidor y verifique el estado de las funciones que son correctas.

Identificación de las VM alojadas en el nodo de informática

Identifique las VM alojadas en el servidor informático y verifique que estén activas y en ejecución. 

El servidor informático contiene la combinación de VM CPS/Elastic Services Controller (ESC) de VM:

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

Nota: En el resultado que se muestra aquí, la primera columna corresponde al identificador único universal (UUID), la segunda columna es el nombre de la máquina virtual y la tercera es el nombre de host donde está presente la máquina virtual.

Comprobaciones de estado

1. Inicie sesión en el ESC alojado en el nodo de cálculo y verifique el estado.

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

  

2. Inicie sesión en el UAS alojado en el nodo informático y verifique el estado.

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 las comprobaciones de estado son correctas, continúe con el procedimiento de intercambio en funcionamiento del disco defectuoso y espere a que se sincronice la información, ya que puede tardar un par de horas en completarse. Consulte: Reemplazo de los Componentes del Servidor

4. Repita estos procedimientos de comprobación de estado para confirmar que se ha restaurado el estado de las VM alojadas en el nodo informático.

Fallo de disco duro único en un servidor controlador

1. Si se observa la falla de las unidades HDD en UCS 240M4, que actúa como nodo Controlador, realice estas comprobaciones de estado antes de iniciar el procedimiento Hot Swap del disco defectuoso.

2. Verifique el estado del marcapasos en los controladores.

3. Inicie sesión en uno de los controladores activos y verifique el estado del marcapasos. Todos los servicios deben estar ejecutándose en los controladores disponibles y se deben detener en el controlador con fallas.

[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. Verifique el estado de MariaDB en los controladores activos.

[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

Verifique que estas líneas estén presentes para cada controlador activo:

wsrep_local_state_comment: Synced

wsrep_cluster_size: 2

 5. Verifique el estado Rabbitmq en los controladores activos.

[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 las comprobaciones de estado están bien, continúe con el procedimiento de intercambio en caliente del disco defectuoso y espere a que se sincronice la información, ya que puede tardar un par de horas en completarse. Consulte: Reemplazo de los Componentes del Servidor

7. Repita estos procedimientos de verificación de estado para confirmar que el estado de salud en el controlador se restablece.

Fallo de disco duro único en un servidor informático OSD

Si se observa la falla de las unidades HDD en UCS 240M4, que actúa como nodo OSD-Compute, realice estas comprobaciones de estado antes de iniciar el procedimiento Hot Swap del disco defectuoso.

Identificación de las VM alojadas en el nodo de informática OSD

  

1. El servidor de cómputo contiene la VM 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 |

Nota: En el resultado que se muestra aquí, la primera columna corresponde al (UUID), la segunda columna es el nombre de la máquina virtual y la tercera columna es el nombre de host donde está presente la máquina virtual.

2. Los procesos Ceph están activos en el servidor 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. Compruebe que la asignación de OSD (disco duro) al Diario (SSD) es correcta.

[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. Verifique que el estado de Ceph y el mapeo del árbol OSD sean buenos.

[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 las comprobaciones de estado son correctas, continúe con el procedimiento de intercambio en funcionamiento del disco defectuoso y espere a que se sincronice la información, ya que puede tardar un par de horas en completarse. Consulte Sustitución de los Componentes del Servidor

6. Repita estos procedimientos de comprobación de estado para confirmar que se ha restaurado el estado de las VM alojadas en el nodo OSD-Compute.

Fallo de disco duro único en un servidor OSPD

1. Si se observa la falla de las unidades HDD en UCS 240M4, que actúa como nodo OSPD, se recomienda realizar estas comprobaciones antes de iniciar el procedimiento de intercambio en caliente del disco defectuoso.

2. Compruebe el estado de la pila OpenStack y la lista de nodos.

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

3. Verifique si todos los servicios de la nube inferior están en estado cargado, activo y en ejecución desde el nodo 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 las comprobaciones de estado están bien, continúe con el procedimiento de intercambio en caliente del disco defectuoso y espere a que se sincronice la información, ya que puede tardar un par de horas en completarse. Consulte Sustitución de los Componentes del Servidor

5. Repita estos procedimientos de verificación de estado para confirmar que se restaura el estado de estado del nodo OSPD.