Contents

Introduction

背景信息

简称

Mop的工作流

单个HDD故障

在估计服务器的单个HDD故障

在控制器服务器的单个HDD故障

在OSD估计服务器的单个HDD故障

在OSPD服务器的单个HDD故障

Introduction

本文描述要求的步骤替换在服务器的有故障的硬盘驱动器(HDD)驱动在设置的ULTRAM主机StarOS虚拟网络作用(VNFs)。

背景信息

ULTRAM是设计的一个被预先包装的和被验证的虚拟化的便携信息包核心解决方案简化VNFs的配置。 OpenStack是虚拟化的基础设施管理器(精力) ULTRAM的并且包括这些节点类型：

- 估计

- 对象存储磁盘-估计(OSD -估计)

- 控制器

- OpenStack平台-导向器(OSPD)

ULTRAM高级体系结构和介入的组件在此镜像表示：

UltraM ArchitectureThis文件供熟悉Cisco ULTRAM平台的Cisco人员使用，并且选派要求的步骤被执行在OpenStack级别在OSPD服务器更换时。

Note:超M 5.1.x版本考虑为了定义在本文的程序。

简称

VNF

虚拟网络功能

CF

控制功能

SF

服务功能

ESC

有弹性服务控制器

MOP

程序方法

OSD

对象存储磁盘

HDD

硬盘驱动器

SSD

固体驱动

精力

虚拟基础设施管理器

VM

虚拟机

EM

网元管理

UAS

超自动化服务

UUID

通用唯一标识符

Mop的工作流

单个HDD故障

1. 每个Baremetal服务器将配置有两HDD驱动作为在袭击1配置的引导盘。在单个HDD故障的情况下，因为有RAID 1级别冗余，有故障的HDD驱动可以被热交换。

2. 替换在UCS C240 M4服务器的一个有故障的组件的程序可以参考从： 替换服务器组件。

3. 在单个HDD故障的情况下，仅有故障的HDD将被热交换并且BIOS升级程序没有在替换新的磁盘以后需要。

4. 在替换磁盘以后，请等待在磁盘之间的数据同步。它也许耗费几小时完成。

5. 在根据的OpenStack (ULTRAM)解决方案， UCS 240M4 baremetal服务器能占去这些角色之一：估计、OSD估计、控制器和OSPD。要求的步骤为了处理在这些服务器角色中的每一个的单个HDD故障是相同的，并且此部分描述在磁盘的紧迫交换前将执行的健康检查。

在估计服务器的单个HDD故障

1. 如果HDD驱动的故障在作为估计节点的UCS 240M4被观察，请执行这些健康检查，在您终于执行有故障的磁盘的紧迫交换前

2. 识别运行在此服务器的VMs并且验证功能的状况是好。

识别在估计节点主机的VMs ：

识别在估计服务器主机的VMs并且验证他们是活跃和运行。可以有两种可能性：

1. 估计服务器包含仅SF VM。

[stack@director ~]$ nova list --field name,host | grep compute-10

| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s8_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |

pod1-compute-10.localdomain    | ACTIVE|

2. 估计服务器包含VMs的CF/ESC/EM/UAS组合。

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

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     | ACTIVE |

Note:在显示的输出中这里，第一列对应于UUID，第二列是VM名字，并且第三列是主机名- VM存在的地方。

健康检查：

1. 登陆对StarOS VNF并且识别对应于SF或CF VM的卡。请使用SF的UUID或从部分识别的CF VM “识别在估计节点主机的VMs”，并且识别对应于UUID的卡。

[local]VNF2# show card hardware

Tuesday might 08 16:49:42 UTC 2018

<snip>

Card 8:

Card Type               : 4-Port Service Function Virtual Card

CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]

CPU Nodes               : 2

CPU Cores/Threads       : 26

Memory                  : 98304M (qvpc-di-large)

UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533

<snip>

[local]VNF2# show card hardware

Tuesday might 08 16:49:42 UTC 2018

<snip>

Card 2:

Card Type               : Control Function Virtual Card

CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]

CPU Nodes               : 1

CPU Cores/Threads       : 8

Memory                  : 16384M (qvpc-di-large)

UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2

<snip>

2. 验证卡的状态。

[local]VNF2# show card table

Tuesday might 08 16:52:53 UTC 2018

Slot         Card Type                               Oper State     SPOF  Attach

-----------  --------------------------------------  -------------  ----  ------

1: CFC      Control Function Virtual Card           Active         No

2: CFC      Control Function Virtual Card           Standby        -

3: FC       4-Port Service Function Virtual Card    Active         No

4: FC       4-Port Service Function Virtual Card    Active         No

5: FC       4-Port Service Function Virtual Card    Active         No

6: FC       4-Port Service Function Virtual Card    Active         No

7: FC       4-Port Service Function Virtual Card    Active         No

8: FC       4-Port Service Function Virtual Card    Active         No

9: FC       4-Port Service Function Virtual Card    Active         No

10: FC       4-Port Service Function Virtual Card    Standby        -

3. 登陆对在估计节点主机的ESC并且检查状态。

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status

0 ESC status=0 ESC Master Healthy

4. 登陆对在估计节点主机的EM并且检查状态。

ubuntu@vnfd2deploymentem-1:~$ ncs_cli -u admin -C

admin connected from 10.225.247.142 using ssh on vnfd2deploymentem-1

admin@scm# show ems

EM            VNFM

ID  SLA  SCM  PROXY

---------------------

3   up   up   up

6   up   up   up

5. 登陆对在估计节点主机的UAS并且检查状态。

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.

6. 如果健康检查优良是，请继续进行有故障的磁盘紧迫交换程序并且等待数据同步，需要几小时完成。参考替换服务器组件。

7. 重复这些健康检查程序为了确认恢复在估计节点主机的VMs的健康状态。

在控制器服务器的单个HDD故障

1. 如果HDD驱动的故障在作为控制器节点的UCS 240M4被观察，请跟随健康检查，在您执行有故障的磁盘的紧迫交换前。

2. 检查在控制器的心脏起搏器状态。

3. 登陆到其中一个激活控制器并且检查心脏起搏器状态。所有服务在发生故障的控制器一定运作在可用的控制器和终止。

[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. 检查在激活控制器的MariaDB状态。

[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

5. 验证这些线路为每个激活控制器是存在：

wsrep_local_state_comment: Synced

wsrep_cluster_size: 2

6. 检查在激活控制器的Rabbitmq状态。

[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',[]}]}]

7. 如果健康检查优良是，请继续进行有故障的磁盘紧迫交换程序并且等待数据同步，需要几小时完成。参考替换服务器组件。

8. 重复这些健康检查程序为了证实控制器的健康状态恢复。

在OSD估计服务器的单个HDD故障

如果HDD驱动的故障在作为锡OSD估计节点的UCS 240M4被观察，请执行这些健康检查，在您执行有故障的磁盘的紧迫交换前。

识别在OSD估计节点主机的VMs ：

识别在估计服务器主机的VMs。可以有两种可能性：

1. OSD估计服务器包含EM/UAS/Auto Deploy/Auto IT VMs的组合。

[stack@director ~]$ nova list --field name,host | grep osd-compute-0

| c6144778-9afd-4946-8453-78c817368f18 | AUTO-DEPLOY-VNF2-uas-0                                   | pod1-osd-compute-0.localdomain | ACTIVE |

| 2d051522-bce2-4809-8d63-0c0e17f251dc | AUTO-IT-VNF2-uas-0                                       | pod1-osd-compute-0.localdomain | ACTIVE |

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-osd-compute-0.localdomain | ACTIVE |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                           | pod1-osd-compute-0.localdomain | ACTIVE |

2. 估计服务器包含VMs的CF/ESC/EM/UAS组合。

[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:在显示的输出中这里，第一列对应于UUID，第二列是VM名字，并且第三列是主机名- VM存在的地方。

3. Ceph进程是活跃的在OSD估计服务器。

[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

4. 验证连接的映射OSD (HDD磁盘) (SSD)是好。

[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

5. 验证Ceph健康和OSD树映射是好。

[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

6. 如果健康检查优良是，请继续进行有故障的磁盘紧迫交换程序并且等待数据同步，需要几小时完成。参考替换服务器组件。

7. 重复这些健康检查程序为了证实在OSD估计节点主机的VMs的健康状态恢复。

在OSPD服务器的单个HDD故障

1. 如果HDD驱动的故障在作为OSPD节点的UCS 240M4被观察，请执行这些健康检查，在您起动有故障的磁盘的紧迫交换前。

2. 检查OpenStack堆栈和节点列表的状况。

[stack@director ~]$ source stackrc

[stack@director ~]$ openstack stack list --nested

[stack@director ~]$ ironic node-list

[stack@director ~]$ nova list

3. 是否请检查所有Undercloud服务在装载，活动和运行状态从OSP-D节点。

[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. 如果健康检查优良是，请继续进行有故障的磁盘紧迫交换程序并且等待数据同步，需要几小时完成。参考替换服务器组件。

5. 重复这些健康检查程序为了确认恢复OSPD节点的健康状态。