模組化元件RMA-PCRF
下載選項
已更新: 2018 年 9 月 5 日
文件 ID:213630
無偏見用語
本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
關於此翻譯
思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。
目錄
簡介
本文檔介紹在託管思科策略套件(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的災難恢復
- 使用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 - 將此檔案下載到ftp/sftp本地電腦到雲外部的伺服器。
步驟2.備份PCRF雲配置部署XML中引用的所有指令碼和使用者資料檔案。
- 從上一步匯出的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 - 查詢用於傳送CPS協調API的所有部署後指令碼。
- 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
- 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 |
- 從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 - 監控 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].
- 驗證正在啟動的VM中的所有服務。
恢復ESC虛擬機器
- 通過控制檯登入到ESC並驗證狀態。
- 啟動進程（如果尚未啟動）
[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.將控制器群集移至維護模式。
- 將正在更新的控制器上的pc群集置於備用狀態.
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
- 再次檢查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
- 另外，其他2個控制器上的pc狀態應將該節點顯示為備用。
步驟3.從控制器節點更換故障元件。
關閉指定伺服器的電源。可以從以下網址參閱更換UCS C240 M4伺服器上的故障元件的步驟：
步驟4.開啟伺服器電源。
- 開啟伺服器電源並驗證伺服器是否啟動。
[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 |
- 登入受影響的控制器，通過設定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
- 您可以檢查某些監控服務（例如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
由思科工程師貢獻
- Nitesh Bansal思科高級服務
意見