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

ダウンロード オプション

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

偏向のない言語

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

翻訳について

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

    概要

    このドキュメントでは、Ultra-M/Openstackの導入に導入されたセッションマネージャリカバリ手順について説明します。

    トラブルシュート

    Session Managerのインスタンス回復手順

    シャットオフステートからのセッションマネージャの電源オン

    予定されたシャットダウンまたはその他の理由によりインスタンスがシャットオフ状態になっている場合は、この手順を使用してインスタンスを開始し、ESCで「™s monitoring」を有効にしてください。

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

      source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|
    2. コンピューティングが使用可能かどうかを確認し、状態がupであることを確認します。

      source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state                     | up                                       |
| status                    | enabled                                  |
    3. 管理者ユーザとしてElastic Services Controller(ESC)Masterにログインし、opdataのインスタンスの状態を確認します。 

      /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. openstackからインスタンスの電源をオンにします

      source /home/stack/destackovsrc-Pcrf
nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
      .
    5. インスタンスが起動してアクティブ状態になるまで5分待ちます。

      source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep sm-s1_0
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |
    6. インスタンスがアクティブ状態になった後、ESCでVMモニタを有効にします。
    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

    インスタンス設定の詳細な回復については、次のセクションで説明するインスタンスタイプ固有の手順を参照してください。

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

    この手順は、openstackのCPSインスタンスの状態がERRORの場合に使用できます。

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

      source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|
    2. コンピューティングが使用可能で、正常に動作しているかどうかを確認します。

      source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state                     | up                                       |
| status                    | enabled                                  |
    3. 管理者ユーザとしてESC Masterにログインし、opdataのインスタンスの状態を確認します。

      /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. インスタンスの状態をリセットして、エラー状態ではなくインスタンスを強制的にアクティブ状態に戻します。完了したら、インスタンスをリブートします。

      source /home/stack/destackovsrc-Pcrf

nova reset-state –active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
nova reboot –-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
    5. インスタンスが起動してアクティブ状態になるまで5分待ちます。

      source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep sm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | 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_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

    リカバリ後に実行/アクティブ状態に戻る場合は、インスタンスタイプ固有の手順を参照して、バックアップから構成/データをリカバリします。

    セッションマネージャ/MongoDBのリカバリ

    Session Managerは、このセクションのCluster Policy Suiteにデータベース層を提供します。最近リカバリしたセッションマネージャのインスタンスでのデータベースのリカバリについて説明します。

    オフライン状態のレプリカセットのメンバー

    レプリカ・セットのメンバーがオフライン状態の場合は、次の手順を使用します。

    1. Cluster Managerでこのコマンドを使用して、レプリカセットのステータスを確認します。
    diagnostics.sh --get_replica_status

      

    1. すべてのレプリカセットのすべてのオフライン・メンバーをリスト・ダウンします。

    2. Cluster Managerでコマンドを実行します。
    cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
    1. sessionmgr VMへのシェルを保護し、mongoプロセスを開始します。
    ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

    レプリカ・セットのメンバーがスタートアップ2でスタックしている/長時間の状態のリカバリ

    レプリカ・セットのメンバーがstartup2またはリカバリ状態に留まり、レプリカ・セットでプライマリとレプリカが使用可能な場合は、次の手順を使用します。

    1. Cluster Managerでこのコマンドを使用して、レプリカセットのステータスを確認します。
    diagnostics.sh --get_replica_status

      

    1. すべてのレプリカ・セットのすべてのメンバーをリスト・ダウンします。
    1. sessionmgr VMへのシェルを保護し、mongoプロセスの格納場所を取得します。例に示すように、dbpathは、ポート37717でsessionmgr01で実行されるmongoプロセスの/var/data/sessions.1/bです。
    ssh sessionmgr01
ps -ef | grep mongo | grep 37717
root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

       

    1. mongoプロセスを停止し、dbpathの内容をクリーンアップします。
    /etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*
    1. mongoプロセスを開始します。これにより、レプリカ・セット・メンバーは、oplogではなく、プライマリ・データベースからのすべてのデータを同期します。
    /etc/init.d/sessionmgr-xxxxx start

    ステップ5では、データベースのサイズによっては、プライマリからのすべてのデータの同期に時間がかかることがあります。

    レプリカセットの再構築

    一部の停止により、一部またはすべてのレプリカセットを再構築する必要が生じることがあります。ただし、一部またはすべてのレプリカセットの再構築を決定する前に、これらのレプリカセットのすべてのデータが失われる可能性があることに注意してください。バックアップの可用性は、次のデータベースについて相互検証する必要があります。

    • 管理者（一般に27721年）
    • バランス（一般にポート27718）
    • SPR（一般にポート27720）

    バックアップを相互検証し、データベース・レプリカ・セットの再作成を決定したら、次の手順を使用します。

    1. /etc/broadhop/mongoConfig.cfgの内容を確認します。LLDには、このファイルに存在する必要がある設定に関する情報が必要です。または、バックアップファイルを使用できます。
    1. build_set.sh —<db-name> —createコマンドは、再構築するデータベースに応じて、Cluster Managerで実行する必要があります。そのDBに関連するすべてのレプリカセットが作成されます。

    注：レプリカ・セット内のすべてのDBを作成するコマンドは、データベースをクリーンアップします。レプリカセットのすべての内容が失われます。

    1. 1つのデータベースに対して特定のレプリカ・セットを再構築する場合は、次のコマンドを使用します。
    build_set.sh --
     
     
       --create --setname

      

    1. すべてのデータベースのすべてのレプリカセットを再構築する場合は、次のコマンドを使用します。
    build_set.sh --all --create

    バックアップ後のレプリカ・セットからのデータベースのリストア

    レプリカ・セットのすべてのメンバーがオンラインで、いずれかのメンバーがプライマリになると、この手順でmongoDBをバックアップからリストアできます。

    1. バックアップからすべてのDBを復元するには、次のコマンドを使用します。
    config_br.py --action import --mongo-all  /mnt/backup/
    1. 特定のDBをバックアップからconfig_br.pyを通じて復元するには、次のオプションがあります。
    • SPR
    config_br.py --action import --mongo-all --spr /mnt/backup/

      

    • [管理（Admin）]
    config_br.py --action import  --mongo-all --admin  /mnt/backup/

      

    • バランス 
    config_br.py --action import  --mongo-all --balance  /mnt/backup/

      

    • レポート作成
    config_br.py --action import  --mongo-all --report  /mnt/backup/

    mongodumpをデータベースのバックアップに使用すると、mongo restoreでの使用が次のように表示されます。

    1. バックアップtar.gzファイルを抽出します。

      tar -zxf /mnt/backup/
    2. リカバリするデータベースのmongoダンプを含むフォルダを探し、ディレクトリを変更して入力します。

      ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump
    3. レプリカ・セットをバックアップからリストアします。

      mongorestore --host 
          
          
            --port
    4. オプションで、特定のコレクションまたはデータベースをリストアするには、次のコマンドを使用します。
    mongorestore --host 
        
        
          --port 
         
           --db 
          
            --
    TAC Authored

    シスコ エンジニア提供

    • Nitesh Bansal
      Cisco Advance Services

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

    Feedbackフィードバック

    シスコに問い合わせ

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