内容

概要

トラブルシュート

「シャットオフ」状態からのクラスタマネージャの電源オン

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

スナップショットによるCPS Cluster Managerの再構築

スナップショットによるCPS Cluster Managerの再導入

確認

概要

このドキュメントでは、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の名前を取得します。

スニペットの例：

ステップ6:ESCからCluster Manager vmの削除をトリガーします。

警告：opdataからインスタンスを削除するコマンドは完全である必要があります。不完全なコマンドは展開全体を削除できます。ご注意ください。このコマンドには、常にすべてのパラメータ（テナント名、展開名、vm_group名）が含まれている必要があります。

/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>

<name>cm</name>

<image>CPS_Cluman_13.1.1</image>

ステップ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のヘルスステータスが影響を受けないようにします。