高可用性フェイルオーバーシナリオを理解する

アクティブな 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 サーバーがダウンしたことを検出した後、約 1 分後に開始されます。プロセスの完了時間は、移行するデバイス接続数、残りのノードの負荷などによって異なります。通常、このプロセスは数分で完了します。

影響

障害が発生したノードで 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 サーバーがダウンした場合、ウォッチドッグ・サービスはそのアクティブ・ノード上のダウンした MySQL サーバーを約 1~2 秒で検出します。

回復

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

影響

VIP ノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべての要求をサービスするアクティブなデータベースです。つまり、すべてのノードで JBoss がこの期間(20~60 秒)、簡単なデータベース障害を発生させる可能性があることを意味します。この期間中に、データベースへのアクセスを必要とする要求はすべて失敗します。その結果、GUIまたはAPIクライアントが要求に対して失敗し、その間に内部的にデータベースへのアクセスが必要になります。その結果、この期間中にデータベースへのアクセスが必要なジョブが失敗します。

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

検出

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

回復

ウォッチドッグ・サービスは、直ちにノード上の MySQL サーバーを再始動します。再起動すると、MySQL サーバーが起動するのに約 20~60 秒かかります。バックアップ後、このサーバーはバックグラウンドでプライマリ サーバーと再同期し、再同期時間は障害発生時に発生した変更数に依存します。

影響

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

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

検出

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

回復

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

影響

データベース VIP アドレスは、セカンダリ データベース ノードによって引き継がれるまで、約 10~20 秒間使用できなくなります。1 次データベース・ノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべての要求をサービスするアクティブ・データベースです。つまり、すべてのノードで JBoss がこの期間(20~60 秒)、簡単なデータベース障害を発生させる可能性があることを意味します。この期間中に、データベースへのアクセスを必要とする要求はすべて失敗します。その結果、この期間中に内部的にデータベースへのアクセスを必要とする要求に対して、GUIおよびAPIクライアントが発生した障害が発生します。その結果、この期間中にデータベースへのアクセスが必要なジョブが失敗します。

セカンダリ データベース ノードがクラッシュしている

検出

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

回復

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

影響

セカンダリデータベースノード上の MySQL サーバーは JBoss からアクセスされないため、ダウンタイムによってシステムの残りの部分またはシステムのユーザーが気づくような悪影響は発生しません。

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

検出

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

回復

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

影響

1 次データベース・ノード上の MySQL サーバーは、クラスター内のすべての JBoss サーバーからのすべての要求をサービスするアクティブ・データベースです。つまり、すべてのノードで JBoss がこの期間(20~60 秒)、簡単なデータベース障害を発生させる可能性があることを意味します。この期間中に、データベースへのアクセスを必要とする要求はすべて失敗します。その結果、この期間中に内部的にデータベースへのアクセスを必要とする要求に対して、GUIおよびAPIクライアントが発生した障害が発生します。その結果、この期間中にデータベースへのアクセスが必要なジョブが失敗します。

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

検出

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

回復

ウォッチドッグ・サービスは、直ちにノード上の MySQL サーバーを再始動します。再起動すると、MySQL サーバーが起動するのに約 20~60 秒かかります。バックアップ後、このサーバーはバックグラウンドで 1 次データベース・ノードと再同期します。再同期時間は、障害発生時に発生した変更の数に依存します。

影響

セカンダリデータベースノード上の MySQL サーバーは JBoss からアクセスされないため、ダウンタイムによってシステムの残りの部分またはシステムのユーザーが気づくような悪影響は発生しません。

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

検出

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

回復

ウォッチドッグ・サービスは直ちにノード上のApache HTTPサーバーを再起動し、1秒でサービスを受けられる状態になります。

影響

Apache HTTPサーバーが再起動されるまで、GUIとNBIクライアントによるサービス停止が簡単に発生する可能性があります。ただし、この障害はほんの数秒(通常は 2 秒)しかなく、クライアントからはほとんど気づきにくいのです。

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

検出

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

回復

ウォッチドッグ・サービスは直ちにノード上のApache HTTP Serverを再起動し、1秒でサービスを受けられる状態になります。

影響

影響なし。

専用の Cassandra Node がクラッシュする

検出

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

回復

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

影響

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

JBoss Node の Cassandra サービスがダウン

検出

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

回復

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

影響

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