内容

概要

前提条件

要件

使用するコンポーネント

トラブルシュート

SHUOFF状態からのアービタの電源オン

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

アービター/アービターvipの回復

確認

概要

このドキュメントでは、Ultra-M/Openstackの導入に導入されたCisco Virtual Policy and Charging Rules Function(vPCRF)インスタンスを回復する方法について説明します。

著者：Cisco Advance Services、Nitesh Bansal

前提条件

要件

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

- Openstack

- CPS

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

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

使用するコンポーネント

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

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

トラブルシュート

SHUOFF状態からのアービタの電源オン

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

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：インスタンスが起動してアクティブ状態になるまで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：インスタンスが起動してアクティブ状態になるまで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: 再起動後にCluster Managerの状態がACTIVEに変わり、Cluster Managerインスタンスがアクティブ状態になった後、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の回復

arbiterインスタンス/pcrfclientが最近回復し、arbiterがdiagnostics.sh get_replica_status出力にない場合は、次の手順を実行します。

専用のアービターVMが導入されている場合は、手順1 ～ 3を使用します。この場合、arbitervipでは手順4を追加して実行し、次の手順を実行します。

1. クラスタマネージャで、次のコマンドを実行して、システム設定に基づいてmongodbの開始/停止スクリプトを作成します。

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

2.  PCRFCLIENTXXまたは（および）アービタでこのコマンドを実行し、開始する必要があるすべてのプロセスをリストします。

cd etc/init.d/

ll | grep sessionmgr

を選択します。  最後の出力にリストされている各ファイルの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のコマンドで何らかの出力が返された場合、次のコマンドを使用してpcsリソースをクリーンアップします。起動していない複数のpcリソースに対して、各リソースに対してコマンドを繰り返します。

pcs resource cleanup

確認

レプリカの状態の状態を確認します。

Run diagnostics.sh on pcrfclient01

アービタがアービタ/pcrfclientではなくアービタとして実行されている場合は、完全に回復されているかどうかをVMを確認するために、次の手順を実行できます。

1. プライマリアービタでは、すべてのmongoプロセスが実行され、アービタで次のコマンドを使用して確認できます。

ps –aef | grep mongo

2. 監視の下のすべてのプロセスがアービターの正常（実行中/監視対象）状態であることを確認します。

monit summary