高可用性フェイルオーバーのシナリオについて

アクティブな VIP ノードのクラッシュ

検出

スタンバイ VIP ノードで実行されているハートビート サービスは、ピアからハートビート メッセージを受信してから 10 秒以内にクラッシュを検出します。JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノード上の JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

スタンバイ ノードは、すぐに VIP アドレスを引き継ぎます。

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了にかかる時間は、移行するデバイス接続の数、残りのノードの負荷などによって異なります。通常、このプロセスは数分以内に完了します。

VIP アドレスがスタンバイ ノードに引き継がれると、スタンバイ ノードでネットワーク監視サービスが開始されます。ネットワーク監視サービスの初期化が完了するまでに、約 3 分から 5 分かかります。保守されている FM および PM データのサイズによっては、さらに時間がかかる場合があります。

インパクト

VIP アドレスは、スタンバイ ノードに引き継がれるまで、約 10 秒間使用できなくなります。この期間中のGUIまたはAPIクライアントアクセスで、一時的なエラーが発生します。さらに、この間隔中にデバイスから VIP アドレスに送信された SNMP トラップはすべて失われます。

障害が発生したノード上の JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンしています。

障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

スタンバイ ノードでネットワーク監視サービスが初期化されている間、ユーザーは約 3 分から 5 分間、ネットワーク監視機能の停止を経験します。

スタンバイ VIP ノードのクラッシュ

検出

JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノードの JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了時間は、移行するデバイス接続の数や、残りのノードの負荷などによって異なります。通常、このプロセスは数分以内に完了します。

インパクト

障害が発生したノード上の JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンしています。

障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

アクティブ VIP ノードの eth0 がダウンする

検出

スタンバイ VIP ノードで実行されているハートビート サービスは、ピアからハートビート メッセージを受信してから 10 秒以内にクラッシュを検出します。JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノード上の JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

スタンバイ ノードは、すぐに VIP アドレスを引き継ぎます。

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了にかかる時間は、移行するデバイス接続の数、残りのノードの負荷などによって異なります。通常、このプロセスは数分以内に完了します。

VIP アドレスがスタンバイ ノードに引き継がれると、スタンバイ ノードでネットワーク監視サービスが開始されます。ネットワーク監視サービスの初期化が完了するまでに、約 3 分から 5 分かかります。保守されている FM および PM データのサイズによっては、さらに時間がかかる場合があります。

インパクト

VIP アドレスは、スタンバイ ノードに引き継がれるまで、約 10 秒間使用できなくなります。この期間中のGUIまたはAPIクライアントアクセスで、一時的なエラーが発生します。さらに、この間隔中にデバイスから VIP アドレスに送信された SNMP トラップはすべて失われます。

障害が発生したノード上の JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンしています。

障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

スタンバイ ノードでネットワーク監視サービスが初期化されている間、ユーザーは約 3 分から 5 分間、ネットワーク監視機能の停止を経験します。

スタンバイ VIP ノードの eth0 がダウンする

検出

JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノードの JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了時間は、移行するデバイス接続の数や、残りのノードの負荷などによって異なります。通常、このプロセスは数分以内に完了します。

インパクト

障害が発生したノード上の JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンしています。

障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

非VIPノードがクラッシュする

検出

JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノードの JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了にかかる時間は、移行するデバイス接続の数、残りのノードの負荷などによって異なります。通常、このプロセスは数分で完了します。

インパクト

障害が発生したノード上の JBoss サーバーによって接続が提供されたデバイスのデバイス接続が数分間ダウンします。障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

非 VIP ノードの eth0 がダウンする

検出

JBoss クラスタリングメカニズムにより、他のノード上の JBoss サーバーは、障害が発生したノードの JBoss サーバーが応答していないことを約 52 秒で検出できます。

回復

障害が発生したノードによって提供されるデバイス接続は、クラスタ内の残りのノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 11 分後に開始されます。プロセスの完了時間は、移行するデバイス接続の数や、残りのノードの負荷などによって異なります。通常、このプロセスは数分で完了します。

インパクト

障害が発生したノード上の JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンしています。

障害が発生したノードで進行中のジョブは、失敗としてマークされ、理由が示されます。

非VIPノードのeth3がダウンする

検出

デバイスキープアライブモニターは、このノードが提供するすべてのデバイス接続が 15 分以内にダウンしたことを検出し、これらのデバイスの接続ステータスをダウンとしてマークします。

回復

Junos Space によって開始された接続の場合、Junos Space はこれらのデバイスとの再接続を試みます。各試行は、管理するデバイス数に関して最も負荷が低いと判断されたクラスタノードから行われます。クラスタ内の他のノードの負荷がこのノードよりも大幅に少ない場合、この負荷分散チェックに従って、それらのノードから再接続が試行され、成功します。この場合、これらのデバイスの接続は数分で回復します。このノードの負荷が最も低い場合、すべての再接続の試行はこのノードから行われ、eth3 がダウンしている限り、これらの試行は失敗し続けます。

デバイスによって開始される接続の場合、デバイスは約 15 分で接続障害を検出し、次の数秒でクラスター内の別のノードと再接続します。

インパクト

このノードが接続を提供していたデバイスのデバイス接続がダウンしています。接続は 15 分間 (最良のケース) またはeth3 が復旧するまで (最悪のケース) ダウンする可能性があります。さらに、停止時間は、そのデバイスに対して再接続を試みるために選択されたノードに応じて、デバイスごとに異なる場合があります。デバイスによって開始される接続の場合、停止は 15 分強続きます。

アクティブ VIP ノードの eth3 がダウンする

検出

デバイスキープアライブモニターは、このノードが提供するすべてのデバイス接続が 15 分以内にダウンしたことを検出し、これらのデバイスの接続ステータスをダウンとしてマークします。

回復

Junos Space によって開始された JConnection の場合、Junos Space はこれらのデバイスとの再接続を試みます。各試行は、管理するデバイス数に関して最も負荷が低いと判断されたクラスタノードから行われます。クラスタ内の他のノードの負荷がこのノードよりも大幅に少ない場合、この負荷分散チェックに従って、それらのノードから再接続が試行され、成功します。この場合、これらのデバイスの接続は数分で回復します。このノードの負荷が最も低い場合、すべての再接続の試行はこのノードから行われ、eth3 がダウンしている限り、これらの試行は失敗し続けます。

デバイスによって開始される接続の場合、デバイスは約 15 分で接続障害を検出し、次の数秒でクラスター内の別のノードに再接続します。

インパクト

このノードが接続を提供していたデバイスのデバイス接続がダウンしています。接続は 15 分間 (最良のケース) またはeth3 が復旧するまで (最悪のケース) ダウンする可能性があります。さらに、停止時間は、そのデバイスに対して再接続を試みるために選択されたノードに応じて、デバイスごとに異なる場合があります。デバイスによって開始される接続の場合、停止は 15 分強続きます。

ネットワーク監視サービスは VIP ノードでのみ実行されるため、このサービスも影響を受けます。すべてのデバイスはトラップの宛先として VIP ノードの eth3 IP アドレスで設定されているため、サービスは管理対象デバイスから SNMP トラップを受信しません。さらに、eth3 が復旧するまで、すべての管理対象デバイスのすべてのパフォーマンスと障害監視は失敗します。

ノード上の JBoss サーバーがダウンする

検出

ノード上のJBossサーバーがダウンすると、障害が発生したJBossサーバーへのTCP接続がオペレーティングシステムによって閉じられるため、JBossクラスター内の他のノードは約2秒で障害を検出します。

回復

障害が発生した JBoss サーバーによって提供されるデバイス接続は、クラスター内の他のノードに移行されます。このプロセスは、障害が発生したノード上の JBoss サーバーがダウンしていることを JBoss クラスターメンバーが検出してから約 1 分後に開始されます。プロセスの完了にかかる時間は、移行するデバイス接続の数、残りのノードの負荷などによって異なります。通常、このプロセスは数分以内に完了します。

ノード上で実行されているウォッチドッグサービス (jmp‐watchdog) は、JBoss サーバーがダウンしていることを検出し、自動的に再起動します。JBoss サーバーが復旧すると、他のクラスターメンバーによって自動的に検出され、クラスターに追加されます。次に、クラスター内の他のノードからキャッシュを同期します。JBoss の一般的な再起動時間は 2 分から 5 分です。ただし、インストールされているアプリケーションの数、管理対象のデバイスの数、インストールされているDMIスキーマのバージョンの数などによっては、時間がかかる場合があります。

インパクト

ダウンした JBoss サーバーによって接続が提供されていたデバイスのデバイス接続が数分間ダウンします。

クラッシュした JBoss サーバーで進行中のジョブは失敗としてマークされ、理由が示されます。

アクティブなVIPノード上のMySQLサーバーがダウンする

検出

ノード上の MySQL サーバーがダウンした場合、ウォッチドッグサービスは、約 1 秒から 2 秒でそのアクティブノード上のダウンした MySQL サーバーを検出します。

回復

ウォッチドッグサービスは、ノード上の MySQL サーバーをただちに再起動します。再起動すると、MySQLサーバーは約20〜60秒で起動します。

インパクト

VIP ノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべての要求を処理するアクティブなデータベースです。これは事実上、この期間 (20 秒から 60 秒) にすべてのノードで JBoss によって短時間のデータベース停止が発生する可能性があることを意味します。この期間中は、データベース・アクセスを必要とする要求はすべて失敗します。これにより、GUIまたはAPIクライアントの要求で障害が発生し、この期間中に内部的にデータベースアクセスが必要になります。これにより、この期間中にデータベース・アクセスを必要とするジョブも失敗します。

スタンバイVIPノード上のMySQLサーバーがダウンする

検出

ノード上の MySQL サーバーがダウンした場合、ウォッチドッグサービスは、約 1 秒から 2 秒でそのスタンバイノード上のダウンした MySQL サーバーを検出します。

回復

ウォッチドッグサービスは、ノード上の MySQL サーバーをただちに再起動します。再起動すると、MySQL サーバーが起動するまでに約 20 秒から 60 秒かかります。バックアップ後、このサーバーはバックグラウンドでプライマリ サーバーと再同期し、再同期時間は停止中に発生した変更の数によって異なります。

インパクト

スタンバイ VIP ノード上の MySQL サーバーは JBoss によってアクセスされないため、そのダウンタイムは、システムの他の部分やシステムのユーザーが気づくような悪影響を引き起こしません。

プライマリ・データベース・ノードのクラッシュ

検出

2 次データベース・ノードで実行されているハートビート・サービスは、1 次データベース・ノードからハートビート・メッセージを受信してから 10 秒以内にクラッシュを検出します。

回復

データベース VIP アドレスは、10 秒から 20 秒以内にセカンダリ データベース ノードに転送されます。他のノード上の JBoss サーバーは、データベース VIP アドレスがセカンダリデータベースノードに引き継がれた後、データベースにアクセスできます。

インパクト

データベース VIP アドレスは、セカンダリ データベース ノードに引き継がれるまで、約 10 秒から 20 秒間使用できなくなります。プライマリデータベースノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべてのリクエストを処理するアクティブなデータベースです。これは事実上、この期間 (20 秒から 60 秒) にすべてのノードで JBoss によって短時間のデータベース停止が発生する可能性があることを意味します。この期間中は、データベース・アクセスを必要とする要求はすべて失敗します。これにより、この期間中に内部的にデータベースアクセスを必要とする要求で、GUIおよびAPIクライアントによって障害が発生します。これにより、この期間中にデータベース・アクセスを必要とするジョブも失敗します。

セカンダリデータベースノードのクラッシュ

検出

プライマリデータベースノードで実行されているハートビートサービスは、セカンダリデータベースノードからハートビートメッセージを受信してから10秒以内にクラッシュを検出します。

回復

データベースの高可用性を維持するために、ノードを削除し、新しいノードをセカンダリ データベース ノードとして Junos Space クラスタに追加できます。

インパクト

セカンダリデータベースノード上の MySQL サーバーは JBoss によってアクセスされないため、そのダウンタイムは、システムの他の部分やシステムのユーザーが気づくような悪影響を引き起こしません。

プライマリデータベースノード上のMySQLサーバがダウンする

検出

ノード上の MySQL サーバーがダウンした場合、ウォッチドッグサービスは、約 1 秒から 2 秒でそのアクティブノード上のダウンした MySQL サーバーを検出します。

回復

ウォッチドッグサービスは、ノード上の MySQL サーバーをただちに再起動します。再起動すると、MySQLサーバーは約20〜60秒で起動します。

インパクト

プライマリデータベースノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべてのリクエストを処理するアクティブなデータベースです。これは事実上、この期間 (20 秒から 60 秒) にすべてのノードで JBoss によって短時間のデータベース停止が発生する可能性があることを意味します。この期間中は、データベース・アクセスを必要とする要求はすべて失敗します。これにより、この期間中に内部的にデータベースアクセスを必要とする要求で、GUIおよびAPIクライアントによって障害が発生します。これにより、この期間中にデータベース・アクセスを必要とするジョブも失敗します。

セカンダリデータベースノード上のMySQLサーバーがダウンする

検出

ノード上の MySQL サーバーがダウンした場合、ウォッチドッグサービスは、約 1 秒から 2 秒でそのスタンバイノード上のダウンした MySQL サーバーを検出します。

回復

ウォッチドッグサービスは、ノード上の MySQL サーバーをただちに再起動します。再起動すると、MySQL サーバーが起動するまでに約 20 秒から 60 秒かかります。バックアップ後、このサーバはバックグラウンドでプライマリデータベースノードと再同期します。再同期にかかる時間は、停止中に発生した変更の数によって異なります。

インパクト

セカンダリデータベースノード上の MySQL サーバーは JBoss によってアクセスされないため、そのダウンタイムは、システムの他の部分やシステムのユーザーが気づくような悪影響を引き起こしません。

アクティブなVIPノード上のApache HTTPサーバーがダウンする

検出

ノード上の Apache HTTP サーバーがダウンした場合、ウォッチドッグ サービスは、約 1 秒から 2 秒でそのノード上のダウンした HTTP サーバーを検出します。

回復

ウォッチドッグ サービスは、ノード上の Apache HTTP サーバーをただちに再起動し、1 秒でサービスの準備が整います。

インパクト

Apache HTTP サーバが再起動されるまで、GUI および NBI クライアントで短時間のサービス停止が発生する可能性があります。ただし、この停止は数秒 (通常は 2 秒) のみであり、クライアントが気付くことはほとんどありません。

スタンバイ VIP ノードの Apache HTTP サーバーがダウンする

検出

ノード上の Apache HTTP サーバーがダウンした場合、ウォッチドッグ サービスは、約 1 秒から 2 秒でそのノード上のダウンした HTTP サーバーを検出します。

回復

ウォッチドッグ サービスは、ノード上の Apache HTTP Server をただちに再起動し、1 秒でサービスの準備が整います。

インパクト

影響はありません。

専用 Cassandra ノードのクラッシュ

検出

Cassandra ノードがダウンした場合、ウォッチドッグ サービスは、そのノードで Cassandra サービスがダウンしていることを約 1 秒から 2 秒で検出します。

回復

ダウンしている Cassandra ノードをファブリックから削除する必要があります。

インパクト

停止しているノードがファブリックから削除されるまで、Cassandra データベースにファイルをアップロードしたり、Cassandra データベースからファイルを削除したりすることはできません。

JBoss ノード上の Cassandra サービスがダウンする

検出

JBoss ノード上の Cassandra サービスがダウンした場合、ウォッチドッグ サービスは、そのノードで Cassandra サービスがダウンしていることを約 1 秒から 2 秒で検出します。

回復

ノード上の Cassandra サービスを無効にする必要があります。

インパクト

ノードで Cassandra サービスを無効にするまで、Cassandra データベースにファイルをアップロードしたり、Cassandra データベースからファイルを削除したりすることはできません。