障害回復障害シナリオの理解

検出

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

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

影響

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

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

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

回復

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

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

検出

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

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

影響

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

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

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

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

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

回復

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

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

サイト 1 とサイト 2 の間の接続の問題を修正して、SCP を介した MySQL と PgSQL のレプリケーションとファイル転送を再開します。

検出

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

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

影響

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

回復

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

検出

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

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

影響

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

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

site2 には、site1 からリアルタイムでレプリケートされた最新の MySQL および PgSQL データが含まれるようになりました。site2 で入手できる最新バージョンの設定ファイルと RRD ファイルは、SCP を介した最新のファイル転送からのものです。

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

回復

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

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

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

検出

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

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

影響

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

サイト2はアービターデバイス(すべてまたはほとんど)に接続できないため、サイト2はスタンバイのままです。

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

回復

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

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

検出

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

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

影響

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

回復

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

検出

site1 のディザスタリカバリウォッチドッグの arbiterMonitor サービスは、到達可能なアービターデバイスの割合が設定された警告しきい値を下回っていることを検出します。この情報が記載された電子メールが管理者に送信されます。

影響

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

回復

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

検出

site2 のディザスタリカバリウォッチドッグの arbiterMonitor サービスは、到達可能なアービターデバイスの割合が設定された警告しきい値を下回っていることを検出します。この情報が記載された電子メールが管理者に送信されます。

影響

障害復旧ソリューションへの影響はありません。

回復

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

検出

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

影響

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

• アクティブ サイトとスタンバイ サイトの両方が、他のサイトの状態を判断できません。Site1 はアクティブなサイトとして開始します。サイト2はアクティブなままです。

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

• ネットワーク管理サービスは、サイトの 1 つがスタンバイ サイトになるまで、アクティブ サイトとスタンバイ サイトの両方で開始されます。

回復

監視デバイスへの接続が猶予期間内 (デフォルトでは 8 時間) に復元された場合、サイト 1 はアクティブになり、サイト 2 はスタンバイ サイトのままになります。

アクティブ・サイトとスタンバイ・サイトの両方がアクティブである場合は、site1 の VIP ノードでコマンドを実行して jmp-dr manualFailover -s 災害復旧を有効にします。

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