PCRF OAM VMリカバリのトラブルシューティング – Openstack

ダウンロード オプション

  • PDF     (180.6 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (82.2 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (71.1 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2018 年 8 月 31 日
Document ID:213613

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    概要

    このドキュメントでは、ポリシーサーバ(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にアクセスでき、正常に動作していることを確認します。

    TAC Authored

    シスコ エンジニア提供

    • Nitesh Bansal
      Cisco Advance Services

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ

    このドキュメントは次の製品に対応しています