内容

概要

前提条件

要件

使用するコンポーネント

背景説明

CPS VNFインスタンス回復手順

トラブルシュート

「シャットオフ」状態からの任意のインスタンスの電源オン

エラー状態からインスタンスを回復する

CPSアプリケーションの回復手順

PCRFCLIENT01のリカバリ

PCRFCLIENT02のリカバリ

確認

概要

このドキュメントでは、ポリシーサーバ(PS)のリカバリをトラブルシューティングする方法について説明します。

前提条件

要件

次の項目に関する知識が推奨されます。

- Cisco Policy Suite(CPS)

- Openstack

- 影響を受けるインスタンスが展開されたコンピューティングが利用可能になりました。

- コンピューティングリソースは、影響を受けるインスタンスと同じアベイラビリティゾーンで使用できます。

- このドキュメントで説明されているバックアップ手順は、定期的に実行またはスケジュールされます。

使用するコンポーネント

このドキュメントの情報はCPSに基づいており、すべてのバージョンに適用されます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

CPS VNFインスタンス回復手順

このセクションでは、次のように説明します。

- 「シャットオフ」(SHUTOFF)状態からインスタンスを復元します。

- インスタンスをERROR状態から復元します。

トラブルシュート

「シャットオフ」状態からの任意のインスタンスの電源オン

予定されたシャットダウンまたはその他の理由によりインスタンスがシャットオフ状態になっている場合は、この手順を使用してインスタンスを開始し、Elastic Service Controller(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：コンピューティングが使用可能かどうかを確認し、状態がアップであることを確認します。

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 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：インスタンスが起動してアクティブ状態になるまで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：インスタンスが起動してアクティブ状態になるまで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の回復：

主には、Policy SVNを別のシンダーボリュームに保持するため、/var/www/svn/repos/でPCRFCLIENTXXにマウントします。したがって、インスタンスが失われても、ポリシー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とpcrfclient02の間のSVNマスター/スレーブ同期を再確立します

/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のPolicy SVNがPCRFCLEINT02と同期しているが、最新のSVNがPolicy Builderに反映されない場合は、Cluster Manager VMのコマンドを使用して最後のバックアップからインポートできます。

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

PCRFCLIENT02のリカバリ

主には、Policy SVNを別のシンダーボリュームに保持するため、/var/www/svn/repos/でPCRFCLIENTXXにマウントします。したがって、インスタンスが失われても、ポリシーsvnの損失の変更は少なくなります。ポリシーsvn用に異なるcinderボリュームがない場合、またはポリシーsvnが保存されたcinderも失われた場合は、次の手順に従ってPCRFCLIENT02のポリシーSVNを回復してください。

ステップ1:pcrfclient01へのシェルを保護します

ssh pcrfclient01

ステップ2：スクリプトを実行して、pcrfclient01からpcrfclient02へのSVN応答を同期します

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

確認

pcrfclientのヘルスステータスを確認します。

run diagnostics.sh from pcrfrclient

PB、Control Center、およびGrafana GUIにアクセスでき、正常に動作していることを確認します。

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

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