内容

概要

前提条件

要件

使用するコンポーネント

バックアップ手順

ステップ 1：  Elastic Services Controller（ESC）

ステップ2:Cisco Policy Suiteのバックアップ

トラブルシュート

概要

このドキュメントでは、Ultra-M/OpenStack環境に配備された仮想Ciscoポリシーおよび課金ルール機能(vPCRF)インスタンスを回復する手順について説明します。

前提条件

要件

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

- OpenStack

- Cisco Policy Suite(CPS)

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

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

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

バックアップ手順

ステップ 1：  Elastic Services Controller（ESC）

ESC-HAの設定は、VNFを使用したスケールアップまたはスケールダウン操作の前/後、およびESCでの設定変更の前/後に、毎月バックアップする必要があります。ESCのディザスタリカバリを効果的に行うには、バックアップする必要があります。

ESCがXMLとしてデータを開く

ESC opdataをXMLとしてエクスポートするには、次の手順を実行します。

1.管理者クレデンシャルを使用してESCにログインします。

2. opdataをXMLにエクスポートします。

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config.xml

3.このファイルを、クラウド外のサーバーにftp/sftpのローカルコンピュータにダウンロードします。

4.展開XMLで参照されるすべてのスクリプトおよびユーザーデータファイル。前の手順でエクスポートしたopdataから、すべてのVNFの配備XMLで参照されているすべてのユーザデータファイルを検索します。

grep "file://" /home/admin/ESC_config.xml | sort | uniq

出力例：

<file>file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg</file>

<file>file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg</file>

<file>file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg</file>

<file>file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg</file>

<file>file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg</file>

5. CPSオーケストレーションAPIの送信に使用されるすべての導入後スクリプトを検索します。

6. ESCopdataのpost_deployスクリプトのサンプルスペニットです

出力例：

<policies>

<policy>

<name>PCRF_POST_DEPLOYMENT</name>

<conditions>

<condition>

<name>LCS::POST_DEPLOY_ALIVE</name>

</condition>

</conditions>

<actions>

<action>

<name>FINISH_PCRF_INSTALLATION</name>

<type>SCRIPT</type>

<properties>

----------

<property>

<name>script_filename</name>

<value>/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py</value>

</property>

<property>

<name>script_timeout</name>

<value>3600</value>

</property>

</properties>

</action>

</actions>

</policy>

</policies>

設定例 2：

<policy>

<name>PCRF_POST_DEPLOYMENT</name>

<conditions>

<condition>

<name>LCS::POST_DEPLOY_ALIVE</name>

</condition>

</conditions>

<actions>

<action>

<name>FINISH_PCRF_INSTALLATION</name>

<type>SCRIPT</type>

<properties>

<property>

<name>CLUMAN_MGMT_ADDRESS</name>

<value>10.174.132.46</value>

</property>

<property>

<name>CLUMAN_YAML_FILE</name>

<value>/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml</value>

</property>

<property>

<name>script_filename</name>

<value>/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py</value>

</property>

<property>

<name>wait_max_timeout</name>

<value>3600</value>

</property>

</properties>

</action>

</actions>

</policy>

ESC opdata (前のステップで抽出)にハイライトされたファイルが含まれている場合は、このコマンドを使用してバックアップします。

tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/

このファイルは、クラウド外のサーバにftp/sftpのローカルコンピュータにダウンロードします。

注：opdataはESCプライマリとスタンバイの間で同期されますが、ユーザデータ、XML、および導入後のスクリプトを含むディレクトリは両方のインスタンス間で同期されません。SCPまたはSFTPを使用して、これらのファイルを含むディレクトリの内容をプッシュすることを推奨します。展開時にプライマリだったESC VMが使用できない場合に展開を回復するには、これらのファイルをESC-PrimaryおよびESC-Standbyでします。

ESCでの推奨バックアップスケジュール

ESC PrimaryおよびESC Standbyにルートユーザを追加するためのcrontabエントリを次に示します。ただし、ネットワークの要件と変更頻度に応じて、時間/日/月を変更できます。

30 01 * * * tar –zcf /home/admin/esc_files_backup_$(date +"\%Y-\%m-\%d").tgz /opt/cisco/esc/cisco-cps/config/

00 02 * * * /opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config_$(date +"\%Y-\%m-\%d").xml

ステップ2:Cisco Policy Suiteのバックアップ

クラスタマネージャは、1つのCPSクラスタのパペットプライマリとして機能します。したがって、このインスタンスのスナップショットを作成する必要があります。また、シスコが提供するバックアップおよび復元ユーティリティを使用して、mongoDB、ポリシー設定、grafana DB、ユーザ、ネットワーク、およびその他のpcrf設定ファイルのバックアップを収集できます。これらのファイルは、CPSバックアップユーティリティを使用して頻繁にバックアップし、Ultra-Mクラウド外の場所に保存する必要があります。

Cluster Manager VMのスナップショット

Cluster Managerインスタンスのスナップショットは、設定の変更、パッチの更新、アップグレードの前後に毎月バックアップする必要があります。正常なアクティビティの後に古いスナップショットを削除して、ディスク領域を節約できます。この手順では、クラスタマネージャインスタンスをスナップショットとしてバックアップする手順を説明します。

1.次のコマンドを使用して、novaインスタンスを表示し、クラスタマネージャVMインスタンスの名前をメモします。

nova list

2.次に示すように、novaスナップショットイメージを作成します。

nova image-create --poll <cluman_instance_name> <cluman_snapshot_name>

出力例：

Server snapshotting... 100% complete

Finished

注：スナップショットに十分なディスク領域があることを確認します。スナップショットの作成時にCluster Managerが到達不能になり、スナップショットの作成後にCluster Managerが再開されることがあります。スナップショットプロセスが終了してもインスタンスが到達不能のままである場合は、nova listコマンドを使用してVMのステータスを確認します。SHUTOFF状態の場合は、nova startコマンドを使用して、VMを手動で起動する必要があります。

3.このコマンドでスナップショットイメージが作成されていることを確認します。

glance image-list

出力例：

+--------------------------------------+-------------------------------------+

| ID                                   | Name                                |

+--------------------------------------+-------------------------------------+

| 1683d05f-2a9f-46d8-877d-10982ee819e1 | cluman_backup_image                 |

| 30f2ece1-6438-4ef7-b4cf-44a0e7de183e | CPS_13.1.1.release.iso              |

| d38321a1-27c1-4c47-bc0f-24aedab5867a | CPS_13.1.1_Base                     |

+--------------------------------------+-------------------------------------+

4. Cephが影響を受ける可能性のあるプラットフォームの変更を実行する場合は、Cluster ManagerのスナップショットをQCOWファイルに変換し、リモートの場所に保存することを常に推奨します。

glance image-download --file /var/Pcrf/cluman_snapshot.raw <image-id of the snapshot>

5.このファイルを、クラウド外のサーバーにftp/sftpのローカルコンピュータにダウンロードします。

CPS設定およびデータベースのバックアップ

1. CPSの設定とデータベースの内容をバックアップするために、config_br.pyユーティリティがCPSプラットフォームに組み込まれています。config_br.pyユーティリティの使用に関する詳細は、『CPSバックアップと復元ガイド』を参照してください。これは、すべての設定とデータベースを毎日0100時間でバックアップするクラスタマネージャのcrontabの例です。

00 01 * * * /var/platform/modules/config_br.py -a export -–all /mnt/backup/backup_$(date +\%Y-\%m-\%d).tar

2. MongoDBは、代わりにmongodumpを使用してバックアップすることができます。

30 01 * * * mongodump --host sessionmgr01 –port 27721 --out /mnt/backup/mongo_admin_27721_$(date +\%Y-\%m-\%d)/

30 01 * * * mongodump --host sessionmgr01 –port 27720 --out /mnt/backup/mongo_spr_27720_$(date +\%Y-\%m-\%d)/

30 01 * * * mongodump --host sessionmgr01 –port 27718 --out /mnt/backup/mongo_bal_27718_$(date +\%Y-\%m-\%d)/

30 01 * * * mongodump --host sessionmgr01 –port 27719 --out /mnt/backup/mongo_report_27721_$(date +\%Y-\%m-\%d)/

3.バックアップオーケストレーションYAML。

curl -i -X GET http://<Cluster Manager IP>:8458/api/system/config -H "Content-Type: application/yaml" > /mnt/backup/CPS_orc_$(date +\%Y-\%m-\%d).yaml

CPSオーケストレーションAPIを使用してシステムを設定する場合は、この設定もバックアップすることをお勧めします。

注：すべてのバックアップは、CPS VNFの外部およびCPSが導入されているクラウドの外部に保存/転送する必要があります。

トラブルシュート

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

「シャットオフ状態」(SHUOFF State)のインスタンスの電源をオンにします。

予定されたシャットダウンまたはその他の理由により、いずれかのインスタンスがSHUTOFF状態になっている場合は、次の手順を使用してインスタンスを開始し、ESCでのモニタリングを有効にします。

1. OpenStackでインスタンスの状態を確認します。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | cm_0_170d9c14-0221-4609-87e3-d752e636f57f| destackovs-compute-2  | SHUTOFF|

2. [Compute]が使用可能かどうかを確認し、状態がupであることを確認します。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | cm_0_170d9c14-0221-4609-87e3-d752e636f57f| destackovs-compute-2  | SHUTOFF|

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 cm

cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE

4. OpenStackからインスタンスの電源をオンにします。

source /home/stack/destackovsrc-Pcrf

nova start cm_0_170d9c14-0221-4609-87e3-d752e636f57f

5.インスタンスが起動してACTIVE状態になるまで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 |

6.インスタンスがACTIVE状態になった後、ESCでVMモニタを有効にします。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR cm_0_170d9c14-0221-4609-87e3-d752e636f57f

インスタンス構成の詳細な回復については、ここに示すインスタンスタイプ固有の手順を参照してください。

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

OpenStackのCPSインスタンスの状態がERRORの場合、次の手順を使用できます。

1. OpenStackのインスタンスの状態を確認します。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | cm_0_170d9c14-0221-4609-87e3-d752e636f57f| destackovs-compute-2Â  | ERROR|

2.コンピューティングが使用可能で、正常に動作しているかどうかを確認します。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | cm_0_170d9c14-0221-4609-87e3-d752e636f57f| destackovs-compute-2  | ERROR|

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 cm

cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE

4.インスタンスの状態をリセットして、エラー状態ではなくインスタンスを強制的にACTIVE状態に戻します。完了したら、インスタンスをリブートします。

source /home/stack/destackovsrc-Pcrf

nova reset-state –active cm_0_170d9c14-0221-4609-87e3-d752e636f57f

nova reboot –-hard  cm_0_170d9c14-0221-4609-87e3-d752e636f57f

5.インスタンスが起動してACTIVE状態になるまで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 |

6.再起動後にCluster Managerの状態がACTIVEに変更する場合は、ESCでVMモニタを有効にします。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR

cm_0_170d9c14-0221-4609-87e3-d752e636f57f

7. RUNNING/ACTIVE状態への回復後、バックアップから構成/データを回復するには、インスタンスタイプ固有の手順を参照してください。