Ultra-M UCS 240M4 Single-HDD-Fehler - Hot-Swap-Verfahren - CPS

Einführung

Dieses Dokument beschreibt die erforderlichen Schritte, um die fehlerhafte Festplatte eines Servers in einer Ultra-M-Konfiguration zu ersetzen, die Cisco Policy Suite (CPS) Virtual Network Function (VNFs) hostet.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtualized Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:

• Computing
• Object Storage Disk - Computing (OSD - Computing)
• Controller
• OpenStack-Plattform - Director (OSPD)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

UltraM-Architektur

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt. Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die Schritte, die bei einem OSPD-Serveraustausch auf OpenStack-Ebene durchgeführt werden müssen.

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universell eindeutige IDentifier

Workflow des MoP

Ausfall einer Festplatte

1. Jeder Baremetal-Server wird mit zwei HDD-Laufwerken bereitgestellt, um als Boot Disk in der RAID 1-Konfiguration zu fungieren. Bei Ausfall einer Festplatte kann das fehlerhafte Festplattenlaufwerk durch Hot-Swap ausgetauscht werden, da die Raid 1-Ebene-Redundanz vorhanden ist.

2. Lesen Sie das Verfahren, um eine fehlerhafte Komponente des UCS C240 M4 Servers zu ersetzen: Ersetzen der Serverkomponenten.

3. Bei Ausfall einer einzelnen Festplatte wird nur die fehlerhafte Festplatte durch Hot-Swap ausgetauscht, sodass nach dem Austausch neuer Festplatten kein BIOS-Upgrade erforderlich ist.

4. Nachdem Sie die Datenträger ausgetauscht haben, warten Sie auf die Datensynchronisierung zwischen den Festplatten. Es kann ein paar Stunden dauern.

5. In einer OpenStack-basierten (Ultra-M) Lösung kann der UCS 240M4 Bare-Metal-Server eine der folgenden Rollen übernehmen: Computing, OSD-Computing, Controller und OSPD.

6. Die Schritte, die für die Handhabung des einzelnen Festplattenausfalls in jeder dieser Serverrollen erforderlich sind, sind identisch. In diesem Abschnitt werden die Zustandsüberprüfungen beschrieben, die vor dem Hot Swap der Festplatte durchzuführen sind.

Ausfall einer Festplatte auf einem Computing-Server

1. Wenn beim UCS 240M4, das als Compute-Knoten fungiert, ein Festplattenausfall festgestellt wird, führen Sie diese Statusprüfungen durch, bevor Sie den Hot-Swap-Vorgang für die fehlerhafte Festplatte starten.

2. Identifizieren Sie die VMs, die auf diesem Server ausgeführt werden, und überprüfen Sie, ob die Funktionen ordnungsgemäß funktionieren.

Identifizieren der im Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem Compute-Server gehostet werden, und überprüfen Sie, ob sie aktiv und aktiv sind. 

Der Compute-Server enthält eine Kombination aus virtuellen Systemen (VMs/Elastic Services Controller, ESC) mit CPS:

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

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem das virtuelle System vorhanden ist.

Health Checks

1. Melden Sie sich beim im Computing-Knoten gehosteten ESC an, und überprüfen Sie den Status.

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

  

2. Melden Sie sich bei den im Rechenknoten gehosteten UAS an, und überprüfen Sie den Status.

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. Wenn die Integritätsprüfungen in Ordnung sind, fahren Sie mit dem fehlerhaften Hot Swap-Vorgang für die Festplatte fort und warten Sie auf die Datensynchronisierung, da dieser Vorgang einige Stunden dauern kann. Siehe: Ersetzen der Serverkomponenten

4. Wiederholen Sie diese Integritätsprüfungsverfahren, um zu bestätigen, dass der Systemstatus der auf dem Computing-Knoten gehosteten VMs wiederhergestellt wird.

Ausfall einer Festplatte auf einem Controller-Server

1. Wenn in UCS 240M4, das als Controller-Knoten fungiert, der Ausfall der Festplatten festgestellt wird, führen Sie diese Statusprüfungen durch, bevor Sie den Hot-Swap-Vorgang für die fehlerhafte Festplatte starten.

2. Überprüfen Sie den Status des Schrittmachers auf den Controllern.

3. Melden Sie sich bei einem der aktiven Controller an, und überprüfen Sie den Status des Schrittmachers. Alle Dienste müssen auf den verfügbaren Controllern ausgeführt und auf dem ausgefallenen Controller gestoppt werden.

[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. Überprüfen Sie den MariaDB-Status in den aktiven Controllern.

[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

Überprüfen Sie, ob diese Leitungen für jeden aktiven Controller vorhanden sind:

wsrep_local_state_comment: Synced

wsrep_cluster_size: 2

 5. Überprüfen Sie den Rabbitmq-Status in den aktiven Controllern.

[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. Wenn die Integritätsprüfungen in Ordnung sind, fahren Sie mit dem fehlerhaften Hot Swap-Vorgang für die Festplatte fort und warten Sie, bis die Datensynchronisierung abgeschlossen ist, da dies einige Stunden dauern kann. Siehe: Ersetzen der Serverkomponenten

7. Wiederholen Sie diese Health Check-Verfahren, um zu bestätigen, dass der Gesundheitsstatus des Controllers wiederhergestellt wird.

Ein Festplattenfehler auf einem OSD-Computing-Server

Wenn beim UCS 240M4, der als OSD-Compute-Knoten fungiert, ein Ausfall der Festplattenlaufwerke festgestellt wird, führen Sie diese Statusprüfungen durch, bevor Sie den Hot-Swap-Vorgang für die fehlerhafte Festplatte starten.

Identifizieren der im OSD-Compute-Knoten gehosteten VMs

  

1. Der Compute-Server enthält ESC VM.

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

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte der (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem die VM vorhanden ist.

2. Ceph-Prozesse sind auf dem OSD-Compute-Server aktiv.

[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. Überprüfen Sie, ob die Zuordnung von OSD (HDD-Festplatte) zu Journal (SSD) funktioniert.

[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. Stellen Sie sicher, dass der Ceph-Zustand und die OSD-Baumstrukturzuordnung korrekt sind.

[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. Wenn die Integritätsprüfungen in Ordnung sind, fahren Sie mit dem fehlerhaften Hot Swap-Vorgang für die Festplatte fort und warten Sie auf die Datensynchronisierung, da dieser Vorgang einige Stunden dauern kann. Weitere Informationen finden Sie unter Ersetzen der Serverkomponenten.

6. Wiederholen Sie diese Health Check-Verfahren, um zu bestätigen, dass der Status der auf dem OSD-Compute-Knoten gehosteten VMs wiederhergestellt wird.

Single HDD Failure auf einem OSPD-Server

1. Wenn beim UCS 240M4, der als OSPD-Knoten fungiert, ein Ausfall der Festplattenlaufwerke festgestellt wird, sollten Sie diese Prüfungen durchführen, bevor Sie den Hot-Swap-Vorgang für die fehlerhafte Festplatte starten.

2. Überprüfen Sie den Status des OpenStack-Stacks und der Knotenliste.

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

3. Überprüfen Sie, ob alle unterCloud-Services über den OSPD-Knoten geladen, aktiv und aktiv sind. 

[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. Wenn die Integritätsprüfungen in Ordnung sind, fahren Sie mit dem fehlerhaften Hot Swap-Vorgang für die Festplatte fort und warten Sie, bis die Datensynchronisierung abgeschlossen ist, da dies einige Stunden dauern kann. Weitere Informationen finden Sie unter Ersetzen der Serverkomponenten.

5. Wiederholen Sie diese Health Check-Verfahren, um sicherzustellen, dass der Status des OSPD-Knotens wiederhergestellt wird.