4ノードおよび3ノードマルチノードの高可用性

4ノードMNHAの設定には、同じハードウェア構成を持つ4つの同一のSRXシリーズファイアウォールが含まれます。これらのデバイスは 2 つの MNHA ドメインに編成され、各ドメインには 2 つのファイアウォールが含まれています。

図1:4ノードマルチノードの高可用性

トポロジー内:

• ドメイン1は、ノード1.1(ドメイン1ノード1)とノード1.2(ドメイン1ノード2)の2つのファイアウォールで構成されています。
• ドメイン2は、ノード2.1(ドメイン2ノード1)とノード2.2(ドメイン2ノード2)の2つのファイアウォールで構成されています。

各ドメイン内では、2つのノードがシャーシ間リンク(ICL)を介して通信します。これは、高速で効率的な通信を可能にする直接接続です。2つのドメイン間で、ノードはドメイン間リンク(IDL)を介して通信します。ICLとIDLはどちらも論理リンクであり、専用インターフェイスまたは帯域内トラフィックインターフェイス上で動作できます。ICLとIDLの両方をルーティングし、IPsec暗号化を使用できます。

IDLは、異なるドメインのノード間の通信を可能にするレイヤー3のルーティング可能なリンクです。各IDLは、ノードのインターフェイス上で構成され、プライベートルーティングインスタンスの一部です。この設定により、ドメイン全体の MNHA ノード間の内部通信パケットのみがこれらのリンクを通過できるようになり、セキュリティと整合性が維持されます。

4つのノードはすべて、パブリックネットワークとプライベートネットワークの両方からのトラフィックを処理する外部レイヤー3ルーターに接続されています。この設定により、ファイアウォールはネットワークトラフィックを効率的に管理できます。

4ノードMNHAを設定するには、まずICL経由で2つのノードを接続して、各ドメイン内にMNHAペアを確立することをお勧めします。次に、これらのペアを(異なるドメインから)IDL経由で接続し、完全なMNHA構造を完成させます。

4ノードMNHAアーキテクチャは、2つのドメインに分かれており、それぞれが2つのノードで構成されています。この設定により、ドメイン内とドメイン間の2つのレベルで冗長性が可能になります。

• ドメイン内冗長性:

  • 各ドメインには、互いにバックアップする2つのピアノードがあります。ドメイン内の1つのノードに障害が発生したり、サービス停止になったりした場合は、もう一方のノードがその責任を引き継ぎます。
  • ドメイン内のノードは、次の2つのモードで動作できます。
    • アクティブバックアップモード:1つのノードはアクティブですべてのタスクを処理し、もう1つのノードはスタンバイ状態で、アクティブノードに障害が発生した場合に引き継ぐ準備ができています。
    • アクティブ/アクティブモード:両ノードがタスクを積極的に処理し、負荷を共有し、即時フェイルオーバー機能を提供します。

• ドメイン間の冗長性:

  • 1つのドメインのノードは、もう一方のドメインのノードによってバックアップされます。1つのドメインのすべてのノードに障害が発生した場合、もう一方のドメインのノードがサービスを引き継ぎます。
  • また、この冗長性は、ドメイン内冗長性と同様に、アクティブ/バックアップモードとアクティブ/アクティブモードの両方をサポートします。

• 通信と同期:

  • ICL: これは、同じドメイン内の2つのノード間の通信リンクです。これにより、彼らは自分の状態を同期し、自分のステータスについてお互いに最新の状態に保つことができます。
  • IDL: この新しく導入されたリンクにより、異なるドメイン間のノード間の通信が容易になり、状態の同期やステータス情報の共有が可能になります。

• 状態の同期:

  • 各ノードは、ICLを介して同じドメイン内のピアと状態を同期します。
  • また、ノードは、IDL を介して他のドメインのノードの 1 つと状態を同期します。
  • ノードがIDLを介して別のドメインから状態情報を受信すると、その情報をICLを介して同じドメイン内のピアノードに中継します。

    例:トポロジーに示されているセットアップには、ノード1.1、ノード1.2、ノード2.1、ノード2.2というラベルの付いた4つのノードが含まれています。

    • ノード 1.1 は、ローカル ドメイン内の ICL を介してノード 1.2 と状態を同期します。
    • また、ノード1.1はIDLを介してリモートドメインのノード2.1と同期します。
    • ノード2.1は、この状態を受け取ると、ICLを介して同じドメインのノード2.2に転送します。

4ノードMNHAのソフトウェアをアップグレードするには、以下の手順に従います

1. マルチノード高可用性の設定が正常で機能していること、およびシャーシ間リンク(ICL)が稼働していることを確認します。この手順は、同じドメイン内の別のノードが、アップグレードするノードの責任を引き継ぐ準備ができていることを確認するために必要です。

2. ドメイン間リンク(IDL)を切断してノードをネットワークの残りの部分から分離し、アップグレード中の中断の可能性を防ぎます。

3. ドメイン1のバックアップノード(ノード1.2)でソフトウェアアップグレードプロセスを開始し、 set chassis high-availability software-upgrade ステートメントを使用して設定をコミットします。
4. もう一方のデバイス(ノード1.1)がアクティブなロールであり、正常に機能していることを確認します。
5. ノード1.2にJunos OSソフトウェアをインストールし、再起動を実行して更新を適用します。
6. インストールが成功したら、 request system reboot または request vmhost reboot コマンド(プラットフォームによって異なります)を使用してデバイスを再起動します。
7. show version command.を使用して、再起動後にノードが正しいソフトウェアバージョンを実行していることを確認します。
8. デバイス上のマルチノード高可用性のステータスを確認します。
9. ノード1.2の software-upgrade ステートメントを削除し、設定をコミットします。この手順により、システムを通常の動作モードに戻すことができます。
10. ドメイン間リンクを再確立して、アップグレードしたノードをネットワークに再統合します。
11. 同じドメイン内の次のノード(ノード1.1)についても手順を繰り返し、各ノードが順次アップグレードされ、ネットワークの安定性が維持されるようにします。
12. 現在のドメインのアップグレードを完了したら、別のドメイン(ドメイン2)に移動し、同じ手順に従って、ネットワーク全体で一貫した整然としたアップグレードプロセスを確保します。

マルチノード高可用性(MNHA)ネットワーク設定では、シームレスなネットワーク運用とフェイルオーバー機能を維持するためには、複数のノード間でセッションの一貫性を維持することが重要です。以前は、MNHA設定内のすべてのノードが、特定のセッションに対して同じイングレスおよびエグレスインターフェイス名、ゾーン名、ポリシー名を使用する必要がありました。特に4ノードMNHA構成では、すべてのノードにわたって綿密な構成管理が必要となるため、この要件を満たすのは困難です。

4ノードMNHAは、これらの制限の一部を緩和します。具体的には、MNHAドメイン内のすべてのノードでイングレスインターフェイスとエグレスインターフェイスが同じ名前を持つ必要がなくなります。この変更により、以前は異なるノード上の同じセッションで同じ名前のインターフェイス(すべてのノードでge-0/0/0など)を使用する必要がありましたが、新しい設定により、これらのインターフェイスは各ノードで異なる名前を付けることができます。

例:ノード1.1のセッションには、イングレスインターフェイスge-0/0/0とエグレスインターフェイスge-0/0/1がありますが、ノード2.1で同じセッションがアクティブな場合、イングレスインターフェイスge-0/0/2とエグレスインターフェイスge-0/0/3を持つことができます。ただし、ge-0/0/0 と ge-0/0/2 は同じゾーンにある必要があり、同様に ge-0/0/1 と ge-0/0/3 は同じゾーンにある必要があります。

安全で信頼性の高いセッション処理を確保するには、次の要件を満たす必要があります

1. ゾーンの一貫性:異なるノード上の同じセッションに使用されるインターフェイスは、同じゾーンに属している必要があります(前のセクションで説明したとおり)。

2. ポリシーの一貫性: これらのゾーンに適用されるポリシーは、すべてのノードで一貫性を維持する必要があります。この設定により、物理インターフェイスが異なっていても、セキュリティとルーティングの動作が同じままになります。

3. ルーティングインスタンス/VRFの一貫性:同様に、一貫したルーティング動作を確保するには、VR名をノード間で同じに保つ必要があります。

以下の設定スニペットは、4ノードMNHAシステムを設定するために必要な大まかな手順の概要を示しています

1. ローカルドメインとノードIDの設定:

   • ローカルドメインIDとサイズを設定します。

     • domain-id:ローカルドメインの一意の識別子(1または2)。
     • size:ドメイン内のノードの数(1または2)。4ノードMNHAの場合、ドメインサイズは2です。

   • ローカル ノード ID を設定します。

     local-node-id:ドメイン内のローカルノードの一意の識別子(1から10)。

2. シャーシ間リンク(ICL)の設定:

   この設定は、ローカルノードを同じドメイン内のピアノードに接続するためのものです。

   • ローカルノードIPを設定します。

3. ピアノード設定:

4. ドメイン間リンク(IDL)設定:この設定は、異なるドメイン間でノードを接続するためのものです。
5. サービス冗長性グループ(SRG0)の設定:

   • 同じドメイン((1〜10)にピアノードを設定します。

   • 別のドメインにピアノードを設定します。

     注:以下の基準が満たされていることを確認します。

     • 各ドメインIDは一意である必要があり、IDは1または2のみです。
     • ノードIDは、同じドメイン内で一意です。
     • MNHAインフラストラクチャは、 peer-domain-id が設定されている場合にのみ、SRG0の4ノード構成をサポートします。これがない場合、セットアップは2ノード構成をサポートします。
     • ローカルドメインID、ローカルノードID、ピアドメインID、ピアノードID、ドメインサイズを設定したら、デバイスを再起動します。

     show chassis high-availability informationやshow chassis high-availability peer-infoなどのコマンドを使用して、設定が期待どおりに機能していることを確認します。

ドメイン間リンク(IDL)を備えた4ノードマルチノード高可用性(MNHA)は、データセンタードメイン全体に拡張することで高可用性を強化します。IDLは、異なるドメイン間のノード間の通信を容易にし、ノードが状態を同期し、ステータス情報を共有できるようにします。

IDLは論理IPリンクであり、ネットワーク内でルーティング可能なIPアドレスを使用して確立されます。

ドメイン全体のノードは、IDLを使用してコントロールプレーンとデータプレーンの状態を同期します。IDL 通信は共有ネットワークや信頼できないネットワークを経由する可能性があり、IDL を介して送信されたパケットは、必ずしも信頼されるとは限らないパスを通過する可能性があります。そのため、IPsec標準を使用してトラフィックを暗号化し、IDLを通過するパケットを保護する必要があります。

IPsecは、IDL用の暗号化トンネルを確立することでトラフィックを保護します。HAリンク暗号化を適用すると、HAトラフィックは、セキュアで暗号化されたトンネルを介してのみドメイン間のノード間をフローします。HAリンク暗号化を使用しないと、ノード間の通信が安全でない可能性があります。

IDLはIKEv2とカスタムMulti-SA実装をサポートしており、IPsec VPNを介してドメイン間で暗号化されたデータを安全に交換できます。このシステムは、堅牢なAES-GCM-256暗号化とPSKおよびPKIの両方の認証をサポートしており、セキュアなドメイン間通信を保証します。

3ノードMNHAの設定には、同じハードウェア設定を持つ3台の同一のSRXシリーズファイアウォールが含まれます。これらのデバイスは 2 つの MNHA ドメインに編成されており、1 つのドメインには 2 つのファイアウォールが含まれ、もう 1 つのドメインには 1 つのファイアウォールが含まれます。

図2:3ノードマルチノード高可用性

3ノードMNHA設定では、ノード1.1とノード1.2はドメイン1に属し、ノード2.1はドメイン2に属しています。4ノードMNHA構成の場合、各ノードには1つのクラスター間リンク(ICL)と1つのドメイン間リンク(IDL)が装備されています。3ノードMNHA構成では、ドメイン1の2つのノードがそれぞれ1つのICLと1つのIDLを持っていますが、ドメイン2のノードには2つのIDLがあり、ICLはありません。

状態の同期:

• ドメイン1では、ノード1.1はICLを介してその状態をピア(ノード1.2)と同期します。
• また、ノード1.1は、IDLを介して他のドメインのノード2.1と状態を同期します。
• ノード 2.1 は、IDL を介してノード 01.1 とノード 1.2 に状態を同期します。
• ノードがIDLを介して別のドメインから状態情報を受信しても、この情報をICLを介して同じドメイン内のピアノードに中継することはありません。このアプローチにより、ドメイン内でのデータ転送が不要に重複するのを防ぎます。

単一のIDL障害が発生した場合、特にノード1.1とノード2.1の間の直接リンクがダウンしている場合、ルーティングを使用して接続が維持されます。ノード 1.1 は、Nnode 1.2 を介した定義済みルートを使用してノード 2.1 と通信できます。このルーティングにより、ノード1.1とノード2.1の間のIDLが動作し続けるようになり、ホット同期プロセスでもコールド同期プロセスでも、IDLからICLピアにパケットを転送する必要がなくなります。