目錄

簡介

背景資訊

縮寫

元件RMA故障排除 — 計算/OSD — 計算節點

步驟1.正常關機

確定在計算/OSD — 計算節點中託管的VM

對於群集管理器虛擬機器正常關閉

對於活動PD/負載平衡器VM正常關閉

對於備用PD/負載均衡器VM正常關閉

對於PS/QNS VM正常關閉

對於OAM/pcrfclient VM正常關閉

對於仲裁虛擬機器

步驟2. ESC資料庫備份。

步驟3.將ESC遷移至備用模式。

步驟4.從Compute/OSD-Compute節點替換故障元件。

步驟5.恢復虛擬機器。

從ESC恢復VM

恢復ESC虛擬機器

處理ESC恢復失敗

元件RMA故障排除 — 控制器節點

步驟1.控制器 — 預檢查

步驟2.將控制器群集移至維護模式。

步驟3.從控制器節點更換故障元件。

步驟4.開啟伺服器電源。

簡介

本文檔介紹在託管思科策略套件(CPS)虛擬網路功能(VNF)的Ultra-M設定中，替換此處提及的故障元件所需的步驟。

- 雙列直插式記憶體模組(DIMM)更換拖把

- FlexFlash控制器故障

- 固態驅動器(SSD)故障

- 可信平台模組(TPM)故障

- Raid快取故障

- Raid控制器/熱匯流排介面卡(HBA)故障

- PCI Riser卡故障

- PCIe介面卡Intel X520 10G故障

- 模組化主機板上區域網(MLOM)故障

- 風扇托架RMA

- CPU故障

作者：Nitesh Bansal，思科高級服務。

背景資訊

Ultra-M是一種預打包且經過驗證的虛擬化解決方案，旨在簡化VNF的部署。 OpenStack是適用於Ultra-M的虛擬化基礎架構管理器(VIM)，由以下節點型別組成：

- 計算

- 對象儲存磁碟 — 計算（OSD — 計算）

- 控制器

- OpenStack平台 — 導向器(OSPD)

- Ultra M 5.1.x版本用於定義本文檔中的過程。

- 本文檔面向熟悉Cisco Ultra-M平台的思科人員，詳細介紹在伺服器進行元件更換時，在OpenStack和CPS VNF級別需要執行的步驟。

更換有故障的元件之前，請務必檢查Red Hat Open Stack平台環境的當前狀態。建議您檢查當前狀態，以避免更換過程開啟時出現問題。

在進行恢復時，思科建議使用以下步驟來備份OSPD資料庫：

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql

/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack

tar: Removing leading `/' from member names

此過程可確保在不影響例項可用性的情況下更換節點。

附註：如果伺服器是控制器節點，請繼續執行部分，否則請繼續執行下一部分。

縮寫

VNF

虛擬網路功能

PD

策略導向器（負載平衡器）

PS

策略伺服器(pcrfclient)

ESC

彈性服務控制器

澳門幣

程式方法

OSD

對象儲存磁碟

硬碟

硬碟驅動器

固態硬碟

固態驅動器

VIM

虛擬基礎架構管理員

虛擬機器

虛擬機器

SM

作業階段管理員

QNS

Quantum名稱伺服器

UUID

通用唯一識別符號

元件RMA故障排除 — 計算/OSD — 計算節點

步驟1.正常關機

確定在計算/OSD — 計算節點中託管的VM

計算/OSD計算可以託管多種型別的VM。確定所有步驟，然後繼續執行各個步驟以及特定的裸機節點和託管在此電腦上的特定VM名稱：

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

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634     |

pod1-compute-10.localdomain    |

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88     |

pod1-compute-10.localdomain    |

對於群集管理器虛擬機器正常關閉

步驟1.建立快照並將檔案通過FTP傳送到伺服器以外的其他位置，或者可能位於機架之外。

openstack image create --poll

步驟2.從ESC停止VM。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>

步驟3.驗證VM是否已停止。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634

VM_SHUTOFF_STATE

對於活動PD/負載平衡器VM正常關閉

步驟1.登錄到Active lb並停止服務，如下所示

- 將lb從主用切換為備用

service corosync restart

- 停止standby lb上的服務

service monit stop

service qns stop

步驟2.從ESC主螢幕。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

步驟3.  驗證VM是否已停止。

admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於備用PD/負載均衡器VM正常關閉

步驟1.登入備用lb並停止服務。

service monit stop

service qns stop

步驟2.從ESC主螢幕。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

步驟3.驗證VM是否已停止。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於PS/QNS VM正常關閉

步驟1.停止服務：

service monit stop

service qns stop

步驟2.從ESC主螢幕。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

步驟3.  驗證VM是否已停止。

[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於SM VM正常關閉

步驟1.停止sessionmgr中存在的所有mongo服務。

[root@sessionmg01 ~]# cd /etc/init.d

[root@sessionmg01 init.d]# ls -l sessionmgr*

[root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [  OK  ]

步驟2.從ESC主螢幕。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

步驟3.驗證VM是否已停止。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於OAM/pcrfclient VM正常關閉

步驟1。檢查策略SVN是否通過這些命令處於同步狀態。如果返回值，則SVN已處於同步狀態，並且您不需要從PCRFCLIENT02進行同步。如果需要，您應該跳過從上次備份恢復仍可以使用這一過程。

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

步驟2.通過在PCRFCLIENT01上執行一系列命令，在pcrfclient01和pcrfclient02之間重新建立SVN主/從同步（以pcrfclient01為主機）。

/bin/rm -fr /var/www/svn/repos

/usr/bin/svnadmin create /var/www/svn/repos

/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0

http://pcrfclient02/repos-proxy-sync

/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"

/etc/init.d/vm-init-client

/var/qps/bin/support/recover_svn_sync.sh

步驟3.  在群集管理器中備份SVN。

config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz

步驟4.  關閉pcrfclient中的服務。

service monit stop

service qns stop

步驟5.  在ESC母版中：

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

步驟6.  驗證VM是否已停止。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於仲裁虛擬機器

步驟1.登入仲裁伺服器並關閉服務。

[root@SVS1OAM02 init.d]# ls -lrt sessionmgr*

-rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721

-rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718

-rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719

-rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717

-rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720

service monit stop

service qns stop

/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.

步驟2.從ESC主螢幕。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

步驟3.驗證VM是否已停止。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

對於彈性服務控制器(ESC)

步驟1. ESC-HA中的配置必須每月備份，在對VNF執行任何擴展或縮減操作之前/之後以及ESC中的配置更改之前/之後。必須進行備份才能有效執行ESC的災難恢復

1. 使用admin Credentials登入到ESC並將opdata匯出到XML。

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u

-p

--get-config > /home/admin/ESC_config.xml

2. 將此檔案下載到ftp/sftp本地電腦到雲外部的伺服器。

步驟2.備份PCRF雲配置部署XML中引用的所有指令碼和使用者資料檔案。

1. 從上一步匯出的opdata中查詢所有VNF的部署XML中引用的所有使用者資料檔案。示例輸出.

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg

2. 查詢用於傳送CPS協調API的所有部署後指令碼。

3. esc opdata中部署後指令碼的示例片段。

示例1:

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

----------

script_filename

/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py

script_timeout

3600

示例2:

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

CLUMAN_MGMT_ADDRESS

10.174.132.46

CLUMAN_YAML_FILE

/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml

script_filename

/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py

wait_max_timeout

3600

如果部署ESC開啟資料（在上一步中提取）包含任何突出顯示的檔案，則進行備份。

備份命令示例：

tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/

將此檔案下載到ftp/sftp本地電腦到雲外部的伺服器。

Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.

步驟2. ESC資料庫備份。

步驟1.從兩個ESC VM收集日誌並進行備份。

$ collect_esc_log.sh

$ scp /tmp/

@

:

步驟2.從主ECS節點備份資料庫。

步驟3.切換到根使用者，檢查主ESC的狀態並驗證輸出值為Master。

$ sudo bash

$ escadm status

Set ESC to maintenance mode & verify

$ sudo escadm op_mode set --mode=maintenance

$ escadm op_mode show

步驟4.使用變數設定檔名並包含日期資訊，然後呼叫備份工具並提供上一步的檔名變數。

fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S")

$ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar

步驟5.檢查備份儲存中的備份檔案並確保該檔案存在。

步驟6.使Master ESC重新進入正常操作模式。

$ sudo escadm op_mode set --mode=operation

如果dbtool備份實用程式失敗，請在ESC節點中應用下列解決方法一次。然後重複步驟6。

$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump,"

/opt/cisco/esc/esc-scripts/esc_dbtool.py

步驟3.將ESC遷移至備用模式。

步驟1.登入到節點中託管的ESC並檢查它是否處於主狀態。如果是，將ESC切換到備用模式。

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

步驟2.在VM成為ESC備用後，使用以下命令關閉VM: shutdown -r now

附註：如果要在OSD-Compute節點上替換故障元件，請在繼續元件替換之前將CEPH置於伺服器的維護中。

[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance

set norebalance

[admin@osd-compute-0 ~]$ sudo ceph osd set noout

set noout

[admin@osd-compute-0 ~]$ 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 {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-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

步驟4.從Compute/OSD-Compute節點替換故障元件。

關閉指定伺服器的電源。有關更換UCS C240 M4伺服器上故障元件的步驟，請參閱：

更換伺服器元件

請參閱以下過程中的永久日誌記錄並根據需要執行

步驟5.恢復虛擬機器。

從ESC恢復VM

1. VM在新星清單中處於錯誤狀態。

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

2. 從ESC恢復VM。

[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

3. 監控 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].

4. 驗證正在啟動的VM中的所有服務。

恢復ESC虛擬機器

1. 通過控制檯登入到ESC並驗證狀態。

2. 啟動進程（如果尚未啟動）

[admin@esc ~]$ sudo service keepalived start

[admin@esc ~]$ escadm status 0 ESC status=0 ESC Slave Healthy

處理ESC恢復失敗

如果ESC由於意外狀態而無法啟動VM，Cisco建議通過重新啟動主ESC執行ESC切換。ESC切換將需要大約一分鐘。在新的主ESC上運行指令碼「health.sh」以檢查狀態是否為up。主ESC啟動VM並修復VM狀態。完成此恢復任務最多需要5分鐘。

您可以監控/var/log/esc/yangesc.log和/var/log/esc/escmanager.log。如果您在5-7分鐘之後沒有看到虛擬機器被恢復，則使用者將需要手動恢復受影響的虛擬機器。

如果ESC VM未恢復，請按照過程部署新的ESC VM。如需相關程式，請聯絡思科支援。

元件RMA故障排除 — 控制器節點

步驟1.控制器 — 預檢查

在OSPD中，登入控制器並驗證pc是否處於正常狀態 — 所有三個控制器都處於聯機狀態，且所有三個控制器都顯示為主控制器。

附註：一個正常的群集需要2個活動控制器，因此請確認其餘兩個控制器處於聯機狀態且處於活動狀態。

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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-0

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

步驟2.將控制器群集移至維護模式。

1. 將正在更新的控制器上的pc群集置於備用狀態.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

2. 再次檢查pc狀態，並確保此節點上的pc群集已停止.

[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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

3. 另外，其他2個控制器上的pc狀態應將該節點顯示為備用。

步驟3.從控制器節點更換故障元件。

關閉指定伺服器的電源。可以從以下網址參閱更換UCS C240 M4伺服器上的故障元件的步驟：

更換伺服器元件

步驟4.開啟伺服器電源。

1. 開啟伺服器電源並驗證伺服器是否啟動。

[stack@tb5-ospd ~]$ source stackrc

[stack@tb5-ospd ~]$ nova list |grep pod1-controller-0

| 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |

2. 登入受影響的控制器，通過設定unstandby（非待機）來刪除備用模式。驗證控制器是否與群集聯機，並且galera將全部三個控制器顯示為主控制器。這可能需要幾分鐘.

[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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

3. 您可以檢查某些監控服務（例如ceph）是否處於正常狀態。

[heat-admin@pod1-controller-0 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

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 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2

osdmap e218: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects

2142 GB used, 11251 GB / 13393 GB avail

704 active+clean

client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr