Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

障害シナリオを理解する

以下のセクションでは、障害が発生してアクティブサイトとスタンバイサイト(自動フェイルオーバーが有効になっているサイト)がダウンし、サイト間の接続が失われる、監視デバイスとの接続が失われるなどの障害シナリオについて説明します。デバイスアービトレーションアルゴリズムは、障害検知に使用されます。

シナリオでは、アクティブ サイトがサイト 1 で、スタンバイ サイトがサイト 2 であると仮定します。

障害によりアクティブサイト(サイト1)がダウンするか、電源を切断

検出

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

この情報を含む電子メールが管理者に送信されます。

影響

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

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

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

回復

site2のディザスターリカバリーウォッチドッグは、アクティブになるプロセスを開始します。プロセスの完了には約 15~20 分かかる場合があります。これは、Junos Space 設定で管理されるデバイスの数によって異なります。

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

メモ:

サイト 1 の再構築または電源投入時に、ディザスター リカバリー構成が削除された場合、サイト間で障害回復を再設定する必要があります。

アクティブサイトとスタンバイサイトの間に接続がなく、両サイトがアービターデバイスとの接続を失う

検出

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

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

影響

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

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

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

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

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

回復

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

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

サイト1とサイト2間の接続問題を修正して、MySQLとPgSQLの複製を再開し、SCPを介してファイル転送を行います。

アクティブサイトとスタンバイサイト間の接続なし

検出

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

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

影響

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

回復

サイト1はアクティブなままで、サイト2はスタンバイのままです。サイト1とサイト2間の接続問題を修正して、MySQLとPgSQLデータベースの複製とSCPを介したファイル転送を再開します。

アクティブサイトとスタンバイサイトとアクティブサイト(サイト1)の間に接続が切断され、アービターデバイスとの接続が失われる

検出

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

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

影響

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

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

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

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

回復

site2のディザスターリカバリーウォッチドッグは、アクティブになるプロセスを開始します。プロセスの完了には約 15~20 分かかる場合があります。これは、Junos Space 設定で管理されるデバイスの数によって異なります。

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

サイト1とサイト2間の接続問題を修正して、MySQLとPgSQLデータベースの複製とSCPを介したファイル転送を再開します。

アクティブサイトとスタンバイサイトとスタンバイサイト(サイト2)の間に接続が切断され、アービターデバイスとの接続が失われる

検出

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

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

影響

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

site2 はアービター デバイス(すべてまたは大部分)に接続できないため、site2 はスタンバイのままになります。

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

回復

サイト1とサイト2間の接続問題を修正して、MySQLとPgSQLデータベースの複製とSCPを介したファイル転送を再開します。

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

障害によりスタンバイ サイト(site2)がダウンするか、電源を切断

検出

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

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

影響

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

回復

サイト1はアクティブなままです。サイト2の電源を入れると、サイト2はスタンバイになります。電源を入れた場合、または障害回復設定がサイト2から削除されない場合、MySQLおよびPgSQLデータベースの複製とSCPによるファイル転送が開始されます。

メモ:

サイト 2 で再構築または電源投入する場合、ディザスター リカバリー構成が削除された場合、両方のサイト間で障害回復を再設定する必要があります。

アクティブ サイト(サイト 1)とアービター デバイス間の接続なし

検出

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

影響

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

回復

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

スタンバイ サイト(site2)とアービター デバイス間の接続なし

検出

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

影響

障害回復ソリューションに影響はありません。

回復

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

アクティブサイトとスタンバイサイトの両方がアクティブであり、監視デバイスとの接続を失うことはありません。

検出

障害回復ウォッチドッグは、アクティブサイトとスタンバイサイトの両方で連続するpingに返信し、自動障害回復フェイルオーバーの復旧後に再試行します。

影響

  • アクティブサイトとスタンバイサイトの両方が、ほとんどの監視デバイスに接続します。
  • アクティブサイトとスタンバイサイトの両方が、他のサイトのステータスを決定することができません。サイト 1 はアクティブ サイトとして開始されます。サイト2がアクティブな状態です

  • アクティブ・サイトとスタンバイ・サイト間の接続が復元されても、両方のサイトはアクティブなままになります。

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

回復

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

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

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