簡介
本文檔介紹如何恢復在Ultra-M/Openstack部署上部署的Cisco Virtual Policy and Charging Rules Function(vPCRF)例項。
作者：Nitesh Bansal，思科高級服務。
必要條件
需求
思科建議您瞭解以下主題：
- Openstack
- CPS
- 部署了受影響例項的計算現在可用。
- 計算資源與受影響的例項位於同一個可用區中。
採用元件
本檔案中的資訊是根據CPS，適用於所有版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
疑難排解
從SHUTOFF狀態開啟仲裁器的電源
如果任何例項由於計畫關閉或其他原因而處於「關閉」狀態，請使用以下過程啟動該例項，並在Elastic Service Controller(ESC)中啟用其監視。
步驟1.通過OpenStack檢查例項狀態。
source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2 | SHUTOFF|
步驟2.檢查電腦是否可用並確保狀態為up。
source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state | up |
| status | enabled |
步驟3.以管理員使用者身份登入到ESC主裝置，並檢查opdata中例項的狀態。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
步驟4.從openstack開啟例項電源。
source /home/stack/destackovsrc-Pcrf
nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步驟5.等待五分鐘，讓例項啟動並進入活動狀態。
source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep cm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |
步驟6.在例項處於活動狀態後在ESC中啟用VM監視器。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
有關例項配置的進一步恢復，請參閱下面提供的特定於例項型別的過程。
從錯誤狀態中恢復任何例項
如果openstack中CPS例項的狀態為ERROR狀態，請使用以下過程啟動該例項：
步驟1.重置例項狀態以強制該例項返回活動狀態而不是錯誤狀態，一旦完成，請重新啟動您的例項。
source /home/stack/destackovsrc-Pcrf
nova reset-state –active r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
nova reboot –-hard r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步驟2.以管理員使用者身份登入到ESC主裝置，並檢查opdata中例項的狀態。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
步驟3.檢查電腦是否可用且運行正常。
source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state | up |
| status | enabled |
步驟4.檢查OpenStack中例項的狀態。
source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2 | ERROR|
步驟5.等待五分鐘，讓例項啟動並進入活動狀態。
source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |
步驟6.如果 重新啟動後，集群管理器將狀態更改為活動，在集群管理器例項處於活動狀態後，在ESC中啟用VM監視器。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步驟7.恢復到運行/活動狀態後，請參閱例項型別的特定過程，以從備份中恢復配置/資料。
恢復仲裁人/仲裁人vip
如果最近恢復了一個仲裁器例項/pcrfclient，並且仲裁器不在diagnostics.sh get_replica_status輸出中，請遵循此過程。
如果部署具有專用仲裁器VM使用步驟1到步驟3（對於仲裁者vip，請另外運行步驟4），則運行以下步驟：
- 在群集管理器上，運行以下命令，根據系統配置建立mongodb啟動/停止指令碼：
cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
2. 在PCRFCLIENTXX或（和）仲裁器上運行此命令以列出您需要啟動的所有進程。
cd etc/init.d/
ll | grep sessionmgr
3. 在PCRFCLIENTXX或（和）仲裁器上，為最後輸出中列出的每個檔案運行以下命令，用埠號替換xxxxx，例如27717下所示：
/etc/init.d/sessionmgr-xxxxx start
Example:
/etc/init.d/sessionmgr-27717 start
- 如果使用仲裁程式vip，請藉助以下命令，檢查pcrfclient01上的任何pc資源是否需要清理：
pcs resource show | grep –v started
如果步驟4中的命令使用以下命令返回任何輸出，請針對尚未啟動的多個pc資源，為每個資源重複該命令：
pcs resource cleanup
驗證
驗證副本狀態的運行狀況：
Run diagnostics.sh on pcrfclient01
如果仲裁程式作為仲裁程式運行，而不是作為仲裁程式/pcrfclient，然後要驗證VM是否已完全恢復，可以執行以下步驟：
- 在主仲裁器上，所有蒙戈進程都應運行，並且可以使用仲裁器上的以下命令對其進行驗證：
ps –aef | grep mongo
- 驗證受監控的所有進程是否處於仲裁器的正常（運行/受監控）狀態。
monit summary
意見