PCRF Cluster Manager VMリカバリのトラブルシューティング – Openstack
内容
概要
このドキュメントでは、Ultra-M/Openstackの導入に導入されたCisco Virtual Policy and Charging Rules Function(vPCRF)インスタンスを回復する手順について説明します。
トラブルシュート
「シャットオフ」状態からのクラスタマネージャの電源オン
予定されたシャットダウンまたはその他の理由によりインスタンスがシャットオフ状態になっている場合は、この手順を使用してインスタンスを開始し、Elastic Services Controller(ESC)でモニタリングを有効にしてください。
ステップ1:OpenStackでインスタンスの状態を確認します。
source /home/stack/destackovsrc-Pcrf nova list --fields name,host,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | 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 cm_0 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_ERROR_STATE
ステップ4:openstackからインスタンスの電源をオンにします。
source /home/stack/destackovsrc-Pcrf nova start SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
ステップ5：インスタンスが起動してアクティブ状態になるまで5分待ちます。
source /home/stack/destackovsrc-Pcrf nova list –fields name,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | ACTIVE
ステップ6. Eインスタンスがアクティブ状態になった後、ESCでVMモニタを有効にします。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
インスタンス設定の詳細な回復については、ここに示すインスタンスタイプ固有の手順を参照してください。
エラー状態からインスタンスを回復する
この手順は、openstackのCPSインスタンスの状態がERRORの場合に使用できます。
ステップ1: OpenStackのインスタンスの状態を確認します。
source /home/stack/destackovsrc-Pcrf nova list --fields name,host,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | destackovs-compute-2 | ERROR|
ステップ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 cm_0 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_ERROR_STATE
ステップ4：インスタンスの状態をリセットして、エラー状態ではなく強制的にインスタンスをアクティブ状態に戻します。完了したら、インスタンスをリブートします。
source /home/stack/destackovsrc-Pcrf nova reset-state –active SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 nova reboot –-hard SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
ステップ5：インスタンスが起動してアクティブ状態になるまで5分待ちます。
source /home/stack/destackovsrc-Pcrf nova list –fields name,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | 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_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
リカバリ後に実行/アクティブ状態に戻る場合は、インスタンスタイプ固有の手順を参照して、バックアップから構成/データをリカバリします。
スナップショットによるCPS Cluster Managerの再構築
Cisco Policy Suite(CPS)がERROR状態のままになり、すでに説明されている手順で電源をオンにできない場合、インスタンスはopenstackで使用できます。スナップショットイメージを使用してインスタンスを再構築することを推奨します。
ステップ1：最後に正常な設定のスナップショットがQCOWファイルとして存在することを確認します。バックアップ中に以前に生成したファイルを使用し、scp/sftpしてOpenStack Platform-Director(OSPD)コンピューティングに戻します。次の手順を使用して、イメージを一目でわかるように変換します。
source /home/stack/destackovsrc-Pcrf glance image-create --name CPS_Cluman_13.1.1 --disk-format "qcow2" --container "bare" --file /var/Pcrf/cluman_snapshot.raw Alternatively, glance image-create --name rebuild_cluman --file /home/stack/cluman_snapshot.raw --disk-format qcow2 --container-format bare
ステップ2:OSPDでnova rebuildコマンドを使用して、アップロードされたスナップショットを使用してCluman VMインスタンスを再構築します（次の図を参照）。
nova rebuild
ステップ3：インスタンスが起動してアクティブ状態になるまで5分待ちます。
source /home/stack/destackovsrc-Pcrf nova list –fields name,status | grep cm | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 |cm_0_170d9c14-0221-4609-87e3-d752e636f57f| ACTIVE |
手順4：再構築後にCluster Managerの状態がACTIVEに変わる場合は、ESCのインスタンスの状態を確認し、必要に応じてESCのVMモニタを有効にします。
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR cm_0_170d9c14-0221-4609-87e3-d752e636f57f
ステップ5:Cluster Managerの元のISOイメージに関連付けられているCinderボリュームが、再配置後の現在の時刻で更新されていることを確認します。
cinder list | grep tmobile-pcrf-13.1.1-1.iso | 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | in-use | tmobile-pcrf-13.1.1-1.iso | 3 | - | true | a3f3bc62-0195-483a-bbc0-692bccd37307 | cinder show 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | grep updated_at | updated_at | 2018-06-18T08:54:59.000000 updated_at | 2018-06-18T08:54:59.000000
ステップ6：前のステップで自動接続されていない場合は、Cluster Managerインスタンスに以前に接続されていたバックアップディスクまたはその他のシンダボリュームを接続します。
source /home/stack/destackovsrc-Pcrf
cinder list
+--------------------------------------+-----------+---------------------------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+---------------------------+------+-------------+----------+--------------------------------------+
| 0e7ec662-b59e-4e3a-91a9-35c4ed3f51d7 | available | pcrf-atp1-mongo02 | 3 | - | false | |
| 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | in-use | tmobile-pcrf-13.1.1-1.iso | 3 | - | true | a3f3bc62-0195-483a-bbc0-692bccd37307 |
| 4c553948-df75-4f0b-bf7b-0e64127dfda3 | available | pcrf-atp1-svn01 | 3 | - | false | |
| 594c052e-aaa3-4c82-867d-3b36162244b3 | available | tmobile-pcrf-13.1.1-2.iso | 3 | - | true | |
| 64953713-de86-40d5-a0e5-07db22d692f2 | in-use | tmobile-pcrf-13.1.1.iso | 3 | - | true | 80a93e90-59e2-43bd-b67e-5d766d0a2f11 |
openstack server add volume
--device
ステップ7：カラムのスナップショットが古く、スナップショットが作成された後の日付に対してconfig_br.pyのバックアップが可能な場合。バックアップから構成をインポートし、インポートしない場合は、この手順をスキップします。
ssh
config_br.py –a import --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/
ステップ8：クラスタマネージャのconfig_br.pyを使用して、バックアップからすべてのVMイメージを再ビルドします。
/var/qps/install/current/scripts/build/build_all.sh
スナップショットによるCPS Cluster Managerの再導入
CPS Cluster Manager VMが失われた（回復できない）場合、および再構築プロセス（2.3で説明）も失敗した場合は、ESCを使用してインスタンスを再配置する必要があります。この手順では、同じ手順について説明します。
ステップ1：最後に正常な設定のスナップショットがQCOWファイルとして存在することを確認します。バックアップ中に以前に生成されたこのファイルを使用し、scp/sftpしてOSPD計算に戻します。
ls –ltr /var/Pcrf/cluman_snapshot.qcow -rw-r--r--. 1 root root 328514100 May 18 16:59 cluman_snapshot.qcow
ステップ2：次の手順を使用して、イメージを一目でわかるように変換します。
source /home/stack/destackovsrc-Pcrf glance image-create --name CPS_Cluman_13.1.1 --disk-format "qcow2" --container "bare" --file /var/Pcrf/cluman_snapshot.qcow
ステップ3：イメージが使用可能になったら、ESCにログインし、ESCopdataのCluster Managerインスタンスの状態を確認します。
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE
ステップ4:2.1.1でバックアップした/home/admin/PCRF_config.xmlファイルが存在することを確認します
ステップ5：リカバリするクラスタマネージャの導入、テナント、およびvm_groupの名前を取得します。
スニペットの例：
Pcrf
---------------- Name of the tenant
false
DEP1
---------------- Name of the Deployment ----- ----- -----
cm
--------------- Name of the vm_group
![]()
pcrf-13.1.1.qcow2 ------------- Name of the Image used
pcrf-cm
600
30
ステップ6:ESCからCluster Manager vmの削除をトリガーします。
/opt/cisco/esc/confd/bin/confd_cli -u admin –C esc-ha-01# config esc-ha-01(config)# no esc_datamodel tenants tenant Pcrf deployments deployment DEP1 vm_group cm esc-ha-01(config)# commit esc-ha-01(config)# exit
上記の手順では、ESC opdataと同様に、openstackからインスタンスを削除する必要があります。つまり、Cluster Managerは導入の一部ではありません。
ステップ7：クラスタマネージャインスタンスがyangesc.log、escmanager.logから、ESCにescmanager.logを、OSPDノードにnovaリストを削除することを確認します。
ステップ 8： ステップ2.1.1でバックアップしたPCRF_config.xmlファイルを変更し、クラスタマネージャイメージの名前を、上記の手順でスナップショットから新しく作成したイメージに変更します。
| 変更前 | 変更後 |
| <vm_group> <name>cm</name> <image>pcrf-13.1.1.qcow2</image |
<vm_group> |
ステップ9:PCRF_config.xmlを変更し、Cluster Manager vmグループのクラウドユーザデータファイルを削除します。削除するxmlスニペットの例を次に示します。
--user-data
file:///opt/cisco/esc/cisco-cps/config/pcrf-cm_cloud.cfg
CLUSTER_ID
P1
CM_IP_ADDR_PVT
192.168.1.107
PREFIX
vpc
SEQ
01
SITE_ID
DE
ステップ10：ファイルPCRF_config.xmlを/opt/cisco/esc/cisco-cps/config/フォルダにコピーします。フォルダには他のすべての設定ファイルがあります。
ステップ11：新しい設定ファイルをロードしてESCopdataにマージします。
/opt/cisco/esc/confd/bin/confd_cli -u admin –C esc-ha-01# config esc-ha-01(config)# load merge /opt/cisco/esc/cisco-cps/config/PCRF_config.xml esc-ha-01(config)# commit esc-ha-01(config)# exit
ステップ12:yanesc.log、escmanager.log、ESC上のnovaリストを監視し、Cluster Managerの配備を確認します。
source /home/stack/destackovsrc-Pcrf nova list --fields name,status| grep cm | 96a5647e-9970-4e61-ab5c-5e7285543a09 | cm_0_a11a9068-df37-4974-9bd8-566f825d5e39 | ACTIVE
ステップ13：再構築後にCluster Managerの状態がACTIVEに変わる場合は、ESCのインスタンスの状態を確認し、必要に応じてESCのVMモニタを有効にします。
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR cm_0_170d9c14-0221-4609-87e3-d752e636f57f
ステップ14：バックアップディスクまたは他のCinderボリュームをCluster Managerインスタンスに以前に接続し、前のステップでEscによって自動接続しない。
source /home/stack/destackovsrc-Pcrf
cinder list
+--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+
| ID | Status | Name | Size | Volume Type| Bootable| Attached to |
+--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+
| 4c478cce-c746-455a-93f1-3f360acb87ce | in-use | CPS_14.0.0.release.iso | 3 | - | true | 96a5647e-9970-4e61-ab5c-5e7285543a09 |
| 7e5573d9-29bc-4ea0-b046-c666bb1f7e06 | in-use | PCRF_backup | 1024 | - | false | |
| d5ab1991-3e09-41f2-89f5-dd1cf8a9e172 | in-use | svn01 | 2 | - | false | 09f4bafa-dfb6-457f-9af5-69196eb31b13 |
| d74988a7-1f59-4241-9777-fc4f2d4f3e78 | in-use | svn02 | 2 | - | false | 86ea448d-09bc-4d2f-81a3-de05884f1e05 |
+--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+
openstack server add volume
--device
ステップ 15： 列のスナップショットが古く、スナップショットの取得後にconfig_br.pyバックアップを使用できる場合。バックアップから構成をインポートします。インポートされていない場合は、この手順を省略します。
ssh
config_br.py –a import --svn --etc --grafanadb --users --auth-htpasswd --haproxy /mnt/backup/
ステップ16：クラスタマネージャのconfig_br.pyを使用して、バックアップからすべてのVMイメージを再構築します。
/var/qps/install/current/scripts/build/build_all.sh
確認
- クラスタマネージャのIPに対してpingを実行し、接続が確立されていることを確認します。
- クラスタマネージャにSSH接続して、アクセス可能性を確認します。
- Cluster Managerの診断を確認して、CPSの他のVMのヘルスステータスが影響を受けないようにします。
フィードバック