ディザスタリカバリの失敗シナリオについて

検出

site2 の災害復旧ウォッチドッグは、site1 への連続した ping 再試行に対する応答を受信しません。サイト2の障害復旧ウォッチドッグは、デバイスアービトレーションアルゴリズムを開始し、監視デバイス(すべてまたは大半)がサイト1によって管理されていないことを確認します。

この情報が記載された電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

site2 の MySQL データベースと PgSQL データベースには、サイト 1 がダウンする前にリアルタイムでレプリケートされた最新のデータが含まれるようになりました。これには、すべての管理対象デバイスの設定、インベントリ、アラーム関連データ、Junos SpaceプラットフォームおよびJunos Spaceアプリケーションによって維持されるデータが含まれます。site2 で利用可能な設定および RRD ファイルの最新バージョンは、SCP を介した最新のファイル転送からのものです。

Junos SpaceユーザーとNBIクライアントは、site2がアクティブになるまで待ち、site2のVIPアドレスを使用してすべてのネットワーク管理サービスにアクセスする必要があります。

回復

サイト2の災害復旧ウォッチドッグが、アクティブになるプロセスを開始します。完全なプロセスには約15〜20分かかる場合があります。これは、Junos Space 設定で管理されているデバイスの数によって異なります。

フェイルオーバーが完了すると、site2はすべてのデバイスとの接続を確立し、必要に応じて設定とインベントリデータを再同期します。Site2は、管理対象デバイスからアラームとパフォーマンス管理データの受信を開始します。

検出

両方のサイトの災害復旧ウォッチドッグは、連続したping再試行に対する応答を受信しません。両サイトのディザスタリカバリウォッチドッグが、デバイスアービトレーションアルゴリズムを開始します。

MySQLおよびPgSQLレプリケーションの失敗と、サイト間のSCPを介したファイル転送に関する電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

どちらのサイトも監視デバイス(すべてまたはほとんど)に接続できないため、どちらのサイトも他方のサイトのステータスを判別できません。サイト 1 はスタンバイ状態になり始め、サイト 2 はスプリット ブレインの状況を回避するためにスタンバイ状態のままになります。

2 つのサイト間の接続が回復しても、サイトは監視デバイスに接続できないため、両方のサイトはスタンバイ状態のままになります。

ネットワーク管理サービスは、サイトの 1 つがアクティブになるまで、両方のサイトで停止します。

猶予期間内(デフォルトでは8時間)に監視サーバデバイスへの接続が復元されない場合、自動フェイルオーバー機能は両方のサイトで無効になります。この情報が記載された電子メールが 1 時間ごとに管理者に送信されます。

回復

猶予期間内(デフォルトでは8時間)に監視デバイスへの接続が回復すると、site1は再びアクティブになります。サイト2はスタンバイのままです。

両方のサイトがスタンバイ状態の場合は、site1 の VIP ノードで jmp-dr manualFailover –a コマンドを実行して、ディザスタ リカバリを有効にします。サイトで自動フェイルオーバーを有効にするには、site1とsite2のVIPノードで jmp-dr toolkit watchdog status --enable-automatic-failover コマンドを実行します。

site1 と site2 の間の接続の問題を修正して、MySQL と PgSQL のレプリケーションと SCP 経由のファイル転送を再開します。

検出

両方のサイトの災害復旧ウォッチドッグは、連続したping再試行に対する応答を受信しません。両サイトの災害復旧ウォッチドッグは、デバイスアービトレーションアルゴリズムを開始し、監視デバイス(すべてまたは大半)がsite1によって管理されていることを検出します。

MySQLおよびPgSQLデータベースレプリケーションの失敗と、サイト間のSCPを介したファイル転送に関する電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

回復

Site1 はアクティブのままで、Site2 はスタンバイのままです。site1 と site2 の間の接続の問題を修正して、MySQL と PgSQL データベースのレプリケーションと SCP 経由のファイル転送を再開します。

検出

両方のサイトの災害復旧ウォッチドッグは、連続したping再試行に対する応答を受信しません。両サイトのディザスタリカバリウォッチドッグが、デバイスアービトレーションアルゴリズムを開始します。

MySQLおよびPgSQLデータベースレプリケーションの失敗と、サイト間のSCPを介したファイル転送に関する電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

site1 が監視デバイスに接続できないため、site1 はスタンバイ状態になります。監視デバイス(すべてまたは大半)がサイト1によって管理されていないことをsite2が検出したため、フェイルオーバーが開始されます。スタンバイ状態になる一環として、すべてのネットワーク管理サービスがサイト1で停止します。

site2 には、site1 からリアルタイムで複製された最新の MySQL および PgSQL データが含まれています。site2 で利用可能な設定および RRD ファイルの最新バージョンは、SCP を介した最新のファイル転送からのものです。

Junos SpaceユーザーとNBIクライアントは、site2がアクティブになるまで待ち、site2のVIPアドレスを使用してすべてのネットワーク管理サービスにアクセスする必要があります。

回復

サイト2の災害復旧ウォッチドッグが、アクティブになるプロセスを開始します。完全なプロセスには約15〜20分かかる場合があります。これは、Junos Space 設定で管理されているデバイスの数によって異なります。

フェイルオーバーが完了すると、site2はすべてのデバイスとの接続を確立し、必要に応じて設定とインベントリデータを再同期します。Site2は、管理対象デバイスからアラームとパフォーマンス管理データの受信を開始します。

site1 と site2 の間の接続の問題を修正して、MySQL と PgSQL データベースのレプリケーションと SCP 経由のファイル転送を再開します。

検出

両方のサイトの災害復旧ウォッチドッグは、連続したping再試行に対する応答を受信しません。サイト1の災害復旧ウォッチドッグは、デバイスアービトレーションアルゴリズムを開始し、監視デバイス(すべてまたはほとんど)がサイト1によって管理されていることを検出します。サイト2の災害復旧ウォッチドッグが、デバイス仲裁アルゴリズムを開始します。

MySQLおよびPgSQLレプリケーションの失敗と、サイト間のSCPを介したファイル転送に関する電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

site2 は監視デバイス(すべてまたはほとんど)に接続できないため、site2 はスタンバイ状態のままになります。

Site2は監視デバイスへの接続を再試行しますが、8時間以内に十分な数の監視デバイスに接続できても、再びアクティブになることはありません。この 8 時間の間に、site2 はリモート サイトのディザスタ リカバリ ランタイム情報を要求して、リモート サイトがアクティブであり、フェイルオーバーのプロセスに入っていないことを確認します。site2 が 8 時間以内に十分な監視デバイスに接続できない場合、自動フェイルオーバーを手動で有効にするまで、site2 は自動フェイルオーバーを永続的に無効にします。この情報が記載された電子メールが 1 時間ごとに管理者に送信されます。

回復

site1 と site2 の間の接続の問題を修正して、MySQL と PgSQL データベースのレプリケーションと SCP 経由のファイル転送を再開します。

スタンバイ サイトで自動フェールオーバーを有効にするには、site2 の VIP ノードで jmp-dr toolkit watchdog status --enable-automatic-failover コマンドを実行します。

検出

site1 の災害復旧ウォッチドッグは、site2 への連続した ping 再試行に対する応答を受信しません。サイト1の災害復旧ウォッチドッグは、デバイスアービトレーションアルゴリズムを開始し、監視デバイス(すべてまたはほとんど)がサイト1によって管理されていることを検出します。

MySQLおよびPgSQLレプリケーションの失敗と、サイト間のSCPを介したファイル転送に関する電子メールが管理者に送信されます。

インパクト

site2 への MySQL および PgSQL データベースのレプリケーションが停止します。ダウンタイム中にSCPを介したファイル転送を設定した場合、site2はそのバージョンの設定とRRDファイルを失う可能性があります。

回復

site1 はアクティブなままです。site2 の電源をオンにすると、site2 はスタンバイ状態になります。電源を切った場合、またはディザスタリカバリ設定がsite2から削除されていない場合、MySQLおよびPgSQLデータベースのレプリケーションとSCPを介したファイル転送が開始されます。

検出

site1 の災害復旧ウォッチドッグの監視監視サービスは、到達可能な監視デバイスの割合が構成された警告しきい値を下回っていることを検出します。この情報が記載された電子メールが管理者に送信されます。

インパクト

到達可能な監視デバイスの割合がフェイルオーバーしきい値を下回るまで、ディザスタリカバリソリューションへの影響はありません。

回復

ネットワーク管理サービスはサイト1から利用できるため、リカバリは必要ありません。

検出

サイト2の災害復旧ウォッチドッグの監視監視サービスは、到達可能な監視デバイスの割合が設定された警告しきい値を下回っていることを検出します。この情報が記載された電子メールが管理者に送信されます。

インパクト

ディザスタリカバリソリューションへの影響はありません。

回復

ネットワーク管理サービスはサイト1から利用できるため、リカバリは必要ありません。

検出

ディザスタリカバリウォッチドッグは、アクティブサイトとスタンバイサイトの両方で連続したpingに対する応答を受信し、自動ディザスタリカバリフェイルオーバーの回復後に再試行します。

インパクト

• アクティブサイトとスタンバイサイトの両方が、すべてまたはほとんどの監視デバイスに接続します。

• アクティブ サイトとスタンバイ サイトの両方が、他のサイトのステータスを判別できません。Site1 はアクティブ サイトとして開始されます。AS Site2はアクティブなままです。

• アクティブ サイトとスタンバイ サイト間の接続が回復しても、両方のサイトはアクティブなままです。

• ネットワーク管理サービスは、アクティブ サイトとスタンバイ サイトの両方から開始し、一方のサイトがスタンバイ サイトになるまで続きます。

回復

猶予期間内(デフォルトでは8時間)に監視サーバデバイスへの接続が回復すると、サイト1がアクティブになり、サイト2はスタンバイサイトとして残ります。

アクティブ サイトとスタンバイ サイトの両方がアクティブな場合は、site1 の VIP ノードで jmp-dr manualFailover -s コマンドを実行して、ディザスタ リカバリを有効にします。

サイトで自動フェールオーバーを有効にするには、site1 と site2 の VIP ノードで jmp-dr toolkit watchdog status --enable-automatic-failover コマンドを実行します。