内容

概要

トラブルシュート

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

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

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

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

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

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

レプリカセットの再構築

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

概要

このドキュメントでは、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

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

3. Cluster Managerでコマンドを実行します。

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. sessionmgr VMへのシェルを保護し、mongoプロセスを開始します。

ssh sessionmgrXX

/etc/init.d/sessionmgr-XXXXX start

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

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

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

diagnostics.sh --get_replica_status

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

3. 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

4. mongoプロセスを停止し、dbpathの内容をクリーンアップします。

/etc/init.d/sessionmgr-xxxxx stop

rm -rf /var/data/sessions.1/b/*

5. mongoプロセスを開始します。これにより、レプリカ・セット・メンバーは、oplogではなく、プライマリ・データベースからのすべてのデータを同期します。

/etc/init.d/sessionmgr-xxxxx start

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

レプリカセットの再構築

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

- 管理者（一般に27721年）

- バランス（一般にポート27718）

- SPR（一般にポート27720）

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

1. /etc/broadhop/mongoConfig.cfgの内容を確認します。LLDには、このファイルに存在する必要がある設定に関する情報が必要です。または、バックアップファイルを使用できます。

2. build_set.sh —<db-name> —createコマンドは、再構築するデータベースに応じて、Cluster Managerで実行する必要があります。そのDBに関連するすべてのレプリカセットが作成されます。

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

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

build_set.sh --

--create --setname

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

build_set.sh --all --create

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

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

1. バックアップからすべてのDBを復元するには、次のコマンドを使用します。

config_br.py --action import --mongo-all  /mnt/backup/

2. 特定の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

--