目錄

簡介

必要條件

需求

採用元件

疑難排解

從SHUTOFF狀態開啟仲裁器的電源

從錯誤狀態中恢復任何例項

恢復仲裁人/仲裁人vip

驗證

簡介

本文檔介紹如何恢復在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），則運行以下步驟：

1. 在群集管理器上，運行以下命令，根據系統配置建立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

4. 如果使用仲裁程式vip，請藉助以下命令，檢查pcrfclient01上的任何pc資源是否需要清理：

pcs resource show | grep –v started

如果步驟4中的命令使用以下命令返回任何輸出，請針對尚未啟動的多個pc資源，為每個資源重複該命令：

pcs resource cleanup

驗證

驗證副本狀態的運行狀況：

Run diagnostics.sh on pcrfclient01

如果仲裁程式作為仲裁程式運行，而不是作為仲裁程式/pcrfclient，然後要驗證VM是否已完全恢復，可以執行以下步驟：

1. 在主仲裁器上，所有蒙戈進程都應運行，並且可以使用仲裁器上的以下命令對其進行驗證：

ps –aef | grep mongo

2. 驗證受監控的所有進程是否處於仲裁器的正常（運行/受監控）狀態。

monit summary