目錄

簡介

必要條件

需求

採用元件

背景資訊

CPS VNF例項恢復過程

疑難排解

從SHUTOFF狀態開啟任何例項的電源

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

CPS應用程式恢復過程

PCRFCLIENT01恢復

PCRFCLIENT02恢復

驗證

簡介

本文檔介紹如何對策略伺服器(PS)恢復進行故障排除。

必要條件

需求

思科建議您瞭解以下主題：

- 思科原則套件(CPS)

- Openstack

- 部署了受影響例項的計算，現在可用。

- 計算資源與受影響的例項位於同一個可用區中。

- 本文檔中提到的備份過程會定期遵循/計畫。

採用元件

本檔案中的資訊是根據CPS，適用於所有版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

CPS VNF例項恢復過程

本節中的說明如下：

- 從SHUTOFF狀態恢復任何例項。

- 從ERROR狀態恢復任何例項。

疑難排解

從SHUTOFF狀態開啟任何例項的電源

如果任何例項由於計畫關閉或其他原因而處於「關閉」狀態，請使用此過程啟動該例項並在「彈性服務控制器」(ESC)中啟用它的監視。

步驟1.通過OpenStack檢查例項狀態。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep oam-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed  | SHUTOFF|

步驟2.檢查電腦是否可用並確保狀態為up。

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

步驟3.以管理員使用者身份登入到ESC Master，並檢查opdata中例項的狀態。

echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep qns-s2

SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed VM_ERROR_STATE

步驟4.從openstack開啟例項電源。

source /home/stack/destackovsrc-Pcrf

nova start SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed

步驟5.等待五分鐘，讓例項啟動並進入活動狀態。

source /home/stack/destackovsrc-Pcrf

nova list –fields name,status | grep oam-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 |SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed  | ACTIVE |

步驟6.在例項處於活動狀態後在ESC中啟用VM監視器。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed

有關例項配置的進一步恢復，請參閱提供的特定於例項型別的過程。

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

如果openstack中CPS例項的狀態為ERROR:

步驟1.檢查OpenStack中例項的狀態。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep oam-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed  | ERROR|

步驟2.檢查電腦是否可用且運行正常。

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

步驟3.以管理員使用者身份登入到ESC主裝置，並檢查opdata中例項的狀態。

echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin -C | grep oam-s1

SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed VM_ERROR_STATE

步驟4.重置例項狀態以強制該例項返回活動狀態而不是錯誤狀態，一旦完成，請重新啟動您的例項。

source /home/stack/destackovsrc-Pcrf

nova reset-state –active oam-s1_0_170d9c14-0221-4609-87e3-d752e636f57f

nova reboot --hard  oam-s1_0_170d9c14-0221-4609-87e3-d752e636f57f

步驟5.等待五分鐘，讓例項啟動並進入活動狀態。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,status | grep oam-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 |SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed | ACTIVE |

步驟6.如果重新啟動後Cluster Manager將狀態更改為ACTIVE，則在Cluster Manager例項處於活動狀態後，在ESC中啟用VM監視器。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed

步驟7.恢復到運行/活動狀態後，請參閱例項型別的特定過程，以從備份中恢復配置/資料。

CPS應用程式恢復過程

PCRFCLIENT01恢復

策略SVN恢復：

主要是為了將策略SVN儲存在不同的灰渣卷中，並裝載在PCRFCLIENTXX/var/www/svn/repos/上，這樣即使例項丟失，丟失策略svn的變化也會減少。如果部署中沒有策略svn的其他cinder卷，或者儲存策略svn的cinder也丟失，請按照以下過程在PCRFCLIENT01上恢復策略SVN。

步驟1.以根使用者身份登入到Cluster Manager VM。

步驟2.通過以下命令注意SVN儲存庫的UUID:

svn info http://pcrfclient02/repos | grep UUID

命令為輸出提供儲存庫的UUID:

For Example Repository UUID: ea50bbd2-5726-46b8-b807-10f4a7424f0e

步驟3.檢查策略SVN在使用提供的命令時是否同步。如果返回值，則SVN已處於同步狀態。您無需從PCRFCLIENT02進行同步，應跳過步驟4。從上次備份恢復仍然可以使用，如本節稍後所述。

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

步驟4.通過在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

步驟5.如果PCRFCLIENT01上的策略SVN與PCRFCLEINT02同步，但最新的svn未反映在策略生成器中，則可以使用群集管理器虛擬機器上的命令通過上次備份匯入該策略SVN。

config_br.py –a import --svn /mnt/backup/

PCRFCLIENT02恢復

主要是為了將策略SVN儲存在不同的灰渣卷中，並裝載在PCRFCLIENTXX/var/www/svn/repos/上，這樣即使例項丟失，丟失策略svn的變化也會減少。如果您的部署中沒有策略svn的其他cinder卷，或者儲存策略svn的cinder也丟失，請按照以下過程在PCRFCLIENT02上恢復策略SVN。

步驟1.將shell保護到pcrfclient01

ssh pcrfclient01

步驟2.運行指令碼以將SVN重發從pcrfclient01同步到pcrfclient02

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

驗證

驗證pcrfclient的運行狀況：

run diagnostics.sh from pcrfrclient

確保PB、控制中心和Grafana GUI可訪問且工作正常。

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

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