クラスタフェイルオーバーパラメータの設定
シャーシクラスター内のSRXシリーズデバイスは、ハートビート伝送を使用して制御リンクの「健全性」を判断します。ハートビートの欠落回数が構成されたしきい値に達した場合、システムは障害状態が存在するかどうかを評価します。詳細については、次のトピックを参照してください。
シャーシ クラスタ制御リンクのハートビート、障害、および回復について
シャーシ クラスタ制御リンク ハートビートについて
ハートビートしきい値とハートビート間隔は、 シャーシクラスターの設定時に指定します。
デフォルトでは、システムは制御リンクのステータスを監視します。
SRX5600回線とSRX5800回線でサポートされているデュアル制御リンクの場合、ジュニパーサービス冗長プロトコルプロセス(jsrpd)は、両方の制御リンクで制御ハートビートメッセージを送受信します。一方の制御リンクでハートビートを受信すると、Junos OSはもう一方のノードが稼働しているとみなします。
heartbeat-threshold オプションと heartbeat-interval オプションの積によって、フェイルオーバーがトリガーされるまでの待機時間が定義されます。これらのオプションのデフォルト値では、待機時間は 3 秒になります。heartbeat-threshold が 5 で、heartbeat-interval が 1000 ミリ秒の場合、待機時間は 5 秒になります。heartbeat-threshold を 4 に設定し、heartbeat-interval を 1250 ミリ秒に設定すると、待機時間は 5 秒になります。
シャーシ クラスタ環境で、1000を超える論理インターフェイスを使用する場合、クラスタ ハートビート タイマーをデフォルトの3秒から増やすことをお勧めします。SRX4600、SRX5400、SRX5600、または SRX5800 ファイアウォールの最大容量では、フェールオーバーまでに構成された時間を少なくとも 5 秒に増やすことをお勧めします。
シャーシ クラスタ制御リンクの障害と回復について
制御リンクに障害が発生すると、Junos OS はセカンダリ ノードの動作状態を 180 秒のカウントダウンの対象外に変更します。180秒間にファブリックリンクにも障害が発生した場合、Junos OSはセカンダリノードをプライマリに変更します。それ以外の場合、180 秒後にセカンダリ ノードの状態が無効に変わります。
制御リンクがダウンすると、システム ログ メッセージが生成されます。
制御リンク障害は、ファブリック リンクでハートビートが受信されている間に、制御リンクでハートビートを受信しないことと定義されます。
正当な制御リンクに障害が発生した場合、冗長グループ 0 は現在プライマリであるノード上でプライマリのままであり、プライマリ ノード上の非アクティブな冗長性グループ x がアクティブになり、セカンダリ ノードは無効状態になります。
セカンダリノードが無効になっている場合でも、管理ポートにログインして診断を実行できます。
正当な制御リンクの障害が発生したかどうかを判断するために、システムは、制御リンクとファブリック リンクの両方に送信される冗長なライブ性信号に依存します。
システムは、ファブリックリンクを介してプローブを定期的に送信し、制御リンクを介してハートビート信号を送信します。プローブとハートビート信号は、一意のタイムイベントにマッピングする共通のシーケンス番号を共有します。Junos OS は、次の 2 つの条件に該当する場合、正当な制御リンク障害を識別します。
ハートビートのしきい値が失われました。
欠落したハートビート信号のシーケンス番号に対応するシーケンス番号を持つプローブが少なくとも1つ、ファブリックリンクで受信されました。
制御リンクに障害が発生すると、180 秒のカウントダウンが開始し、セカンダリノードの状態は不適格となります。180 秒のカウントダウンが 0 に達する前にファブリック リンクに障害が発生した場合、両方のリンクの損失が他のノードが停止していることを示すとシステムが解釈するため、セカンダリ ノードがプライマリになります。制御リンクとファブリックリンクの両方が同時に失われると、ノードが状態を同期したり、優先順位を比較したりしなくなるため、両方のノードが一時的にプライマリになる可能性があり、安定した動作状態ではありません。ただし、いったん制御リンクが再確立されると、プライオリティ値の高いノードが自動的にプライマリになり、もう一方のノードはセカンダリになり、クラスタは通常の動作に戻ります。
正当な制御リンクの障害が発生した場合、以下の条件が適用されます。
冗長性グループ 0 は、現在プライマリとなっているノード上ではプライマリのままであり(したがって、そのルーティングエンジンはアクティブなまま)、ノード上のすべての冗長性グループ x がプライマリになります。
システムがどのルーティングエンジンがプライマリかを判別できない場合、冗長グループ0の優先度の値が高いノードがプライマリとなり、そのルーティングエンジンがアクティブになります。(各ノードの優先度は、冗長グループ0の
redundancy-groupステートメントを設定する際に設定します。)システムはセカンダリノードを無効にします。
デバイスを無効モードから回復するには、デバイスを再起動する必要があります。無効にしたノードを再起動すると、ノードはその動的状態をプライマリ ノードと同期します。
セカンダリ ノードが無効になっている間に設定を変更した場合は、commit コマンドを実行して、ノードの再起動後に設定を同期します。設定を変更しなかった場合、構成ファイルはプライマリ ノードの同期されたままになります。
冗長グループ0のプリエンプションを有効にすることはできません。冗長グループ0のプライマリノードを変更する場合は、手動フェイルオーバーを行う必要があります。
デュアルコントロールリンク(SRX5600およびSRX5800デバイスでサポート)を使用する場合は、以下の条件に注意してください。
ホストのインバウンドまたは送信トラフィックは、制御リンクの障害時に最大 3 秒間影響を受けることがあります。例えば、冗長グループ0がノード0上でプライマリであり、ノード1上でネットワークインターフェイスポートを介してルーティングエンジンへのTelnetセッションがある場合を考えます。現在アクティブな制御リンクに障害が発生した場合、この障害が検出されるまで、Telnet セッションは 3 秒間パケットを失います。
コミット プロセスが 2 つのノードで実行されている間に制御リンク障害が発生すると、コミット障害につながる可能性があります。この状況では、3 秒後に commit コマンドを再度実行してください。
SRX5600およびSRX5800デバイスの場合、デュアルコントロールリンクには 、シャーシクラスターの各ノードに2つ目のルーティングエンジンが必要です。
control-link-recovery ステートメントを設定することにより、制御リンクのリカバリーがシステムによって自動的に行われるように指定することができます。この場合、システムは制御リンクが正常であると判断すると、無効化されたノードで自動リブートを発行します。無効化されたノードが再起動すると、そのノードは再びクラスタに参加します。
例:シャーシ クラスタ制御リンク回復の設定
この例では、制御リンクの回復をイネーブルにする方法を示しています。これにより、制御リンクが障害から回復した後に、システムが自動的に引き継ぐことができます。
必要条件
開始する前に、以下を実行します。
シャーシ クラスタ制御リンクを理解します。 シャーシ クラスタ コントロール プレーンとコントロール リンクについてを参照してください。
シャーシクラスタのデュアルコントロールリンクを理解します。 シャーシ クラスタ デュアル コントロール リンクについてを参照してください。
シャーシクラスターでデュアルコントロールリンクを接続します。 シャーシ クラスタ内のSRXシリーズ ファイアウォール向けのデュアル コントロール リンク接続を参照してください。
概要
システムが制御リンクのリカバリーを自動的に実行できるようにすることができます。制御リンクが回復すると、システムは次のアクションを実行します。
制御リンクで少なくとも 3 つの連続したハートビートを受信しているか、デュアル コントロール リンク(SRX5600 および SRX5800 デバイスのみ)の場合はいずれかの制御リンクで受信しているかどうかを確認します。これは、制御リンクがフラッピングしておらず、正常であることを確認するためです。
制御リンクが正常であると判断されると、システムは、制御リンクに障害が発生したときのノードの状態(不適格または無効)に関係なく、自動リブートを発行します。ノードが再起動すると、クラスタに再参加できます。手動による介入は必要ありません。
この例では、シャーシ クラスタ制御リンクの回復を有効にします。
構成
プロシージャ
手順
chassis cluster control-link-recoveryを有効にするには:
制御リンクの回復を有効にします。
{primary:node0}[edit] user@host# set chassis cluster control-link-recoveryデバイスの設定が完了したら、設定をコミットします。
{primary:node0}[edit] user@host# commit