Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

マルチノードの高可用性におけるソフトウェアアップグレード

このトピックでは、マルチノード高可用性セットアップでファイアウォールのソフトウェアアップグレードを実行する方法について説明します。

概要

さまざまなプラットフォームやソフトウェアリリースでサポートされている機能のリストについては、「 機能エクスプローラー」を参照してください。

MNHA構成で展開されたJunosファイアウォールは、各デバイスを順次アップグレードすることで、最小限の中断でアップグレードできます。デバイスのアーキテクチャに応じて、次のCLIコマンドのいずれかを使用して、 request system software add または request vmhost software add のJunosアップグレードを開始します。

Junos OSリリースから Junos OSリリースへ ソフトウェアアップグレード方法を使用
20.4 20.4以降のすべてのリリース いいえ
22.3 Junos OSリリースの次期バージョン はい
  • リリース22.4R1以降は、通常のアップグレード中にセッションを同期するための以前のJunos OSリリースと互換性がありません。このような場合は、 分離ノードのアップグレード手順を使用します。

  • シャーシ間リンク(ICL)(HAリンク)暗号化にIPv6アドレスを使用するマルチノード高可用性(MNHA)導入環境では、以前のJunos OSリリースからIPv6ベースのICL暗号化をサポートするリリースにアップグレードするには、分離 ノードアップグレード手順 を使用して移行を成功させる必要があります。これは、サポート対象の最初のリリースに移行する際の 1 回限りの要件です。それ以降のアップグレードでは、分離ノードのアップグレード手順は必要ありません。

  • 22.3から次のリリースにアップグレードすると、トラフィックが短時間中断することがあります。

  • 21.4R1以降のアップグレード中に Peer Hardware Incompatible: SPU SLOT MISMATCH が表示される場合があります。

  • 23.4R2より以前のリリースでは、中間アップグレード段階では、NATセッションは同期されません。

  • 両方のノードを常に同じ Junos OS バージョンにアップグレードしてください。

Junos OSリリースのアップグレードおよびダウングレードサポートについては、リリースノートの「 Junos OSリリースおよび延長サポート終了リリースのアップグレードおよびダウングレードサポートポリシー 」を参照してください。

マルチノード高可用性のファイアウォールを Junos OS リリース 22.4R1 またはそれ以前の Junos OS リリースからそれ以上のリリースにアップグレードする場合、 分離ノードのアップグレード手順を使用できます。Junos OSリリース22.4R1以降のリリースは、通常のアップグレード中にセッションを同期するための以前のJunos OSリリースと互換性がありません。

始める前に

MNHA)設定でファイアウォールのアップグレードを実行する前に、制御された方法でトラフィックをデバイスから遠ざけることをお勧めします。これは、次のいずれかの方法を使用して実行できます。

  • 手動フェイルオーバー:手動フェイルオーバーをトリガーして、トラフィックをピアデバイスにシフトします。

  • ソフトウェアアップグレードモード — 次のコマンドでデバイスを一時的に設定します。

    このコマンドは、障害コード SU (ソフトウェア アップグレード) のデバイス障害を導入します。その結果、サービス冗長グループ(SRG)1以上は、アップグレード対象のデバイスで(アクティブまたはバックアップではなく)不適格状態に移行します。これにより、関連するトラフィックが他のMNHAクラスターメンバーに自動的にフェイルオーバーされます。

    注:MNHAクラスターがSRG0のみで構成され、 install-on-failure-routeオプションが含まれている場合でも、 set chassis high-availability software-upgrade構成を使用してトラフィックをデバイスから正常に移動させることで、トラフィックをリダイレクトできます。

ソフトウェアアップグレード

準備チェックリスト

ソフトウェアのアップグレードを計画する際には、次のベストプラクティスを考慮してください。

  • 両方のノードがオンラインであり、同じ Junos OS バージョンを実行していることを確認します。show versionコマンドを使用して、デバイス上の現在のJunos OSソフトウェアバージョンを確認します。
  • ストレージの可用性を確認します。 show system storage
  • ハードウェアのステータスを確認する:
    • show chassis fpc pic-status
    • show chassis alarms
  • コミットされていない変更がないことを確認します。
  • 設定キーとライセンスキーをバックアップします。
  • 両方のデバイスで、Junos OSイメージを/var/tmpにダウンロードします。
  • 高可用性の設定が正常で機能していること、およびシャーシ間リンク(ICL)が稼働していることを確認します。

    show chassis high-availability information

  • で入手可能なチェックリストを使用して、ファイアウォールをアップグレード用に準備します。
ヒント:メンテナンス期間中にソフトウェアのアップグレードを実行することをお勧めします。

デバイスのアップグレード準備の詳細については、 ソフトウェアのインストールとアップグレードの準備(Junos OS)を参照してください。

ソフトウェアのダウンロード

両方のファイアウォールの ジュニパーネットワークスサポート ページからJunos OSイメージをダウンロードし、 /var/tmp の場所に保存します。例:

アップグレード手順

この手順の手順に従って、マルチノード高可用性(MNHA)設定で設定されたファイアウォールをアップグレードします。この例では、クラスターは Firewall-01(現在アクティブ)と Firewall-02(現在バックアップ中)の 2 つのデバイスで構成されています。アップグレードプロセスは、バックアップノード(Firewall-02)から開始し、アクティブノード(Firewall-01)が続くため、サービスの中断が最小限に抑えられます。

  1. マルチノード高可用性の設定が正常で機能していること、およびシャーシ間リンク(ICL)が稼働していることを確認します。

    ファイアウォール-01デバイス上

    firewall-02デバイス上

  2. バックアップノード(ファイアウォール-02)でソフトウェアアップグレードプロセスを開始し、設定をコミットします

    このコマンドは、SRG0のローカルフェイルオーバーをトリガーし、SRG1(存在する場合)をINELIGIBLEとしてマークして、ピアノードがアクティブなロールを引き継ぐか、保持できるようにします

  3. マルチノード高可用性のステータスを確認します。出力には、ノードステータス:オフライン[SU]が表示され、ノードがソフトウェアアップグレードの準備ができていることを示します。SRG1のステータスがINELIGIBLEに変わっていることがわかります。
  4. もう一方のデバイス(ファイアウォール-01)がアクティブなロールであり、正常に機能していることを確認します。

    コマンド出力は、SRG1のステータスが ACTIVEであることを示しています。

    SRG1の Peer Information セクションでは、ステータスが INELIGIBLE であり、もう一方のノードが不適格な状態であることを示しています。

  5. Firewall-02デバイスにJunos OSソフトウェアをインストールします。
  6. インストールが成功したら、 request system reboot コマンドを使用してデバイスを再起動します。
  7. 再起動後にJunos OSのバージョンを確認してください。

    出力では、デバイスが正しい Junos OS バージョンにアップグレードされていることを確認します。

  8. デバイス上のマルチノード高可用性のステータスを確認します。

    出力では、ノードのステータスが OFFLINE [ SU ] 、SRG1のステータスが INELIGIBLEとして表示され続けます。

  9. software-upgradeステートメントを削除し、設定をコミットします。

    software-upgradeステートメントを削除すると、ノードフェイルオーバー状態とインストールされているルートがクリアされます。このステートメントが削除されるまで、ノードはオフラインのままで、すべてのSRGはINELIGIBLE 状態のままとなります。これにより、ピアが正常である限り、アップグレード中にノードがトラフィックの処理から効果的に分離されます。

  10. マルチノードの高可用性ステータスをもう一度確認して、デバイスがオンラインであり、全体的なステータスが正常で機能していることを確認します。

    出力には、 Node Status: ONLINE とSRG1のステータスが BACKUPとして表示されており、これはノードがオンラインに戻り、バックアップロールで正常に機能していることを示しています。

  11. インターフェイス、ルーティングプロトコル、アドバタイズされたルートなどをチェックして、セットアップが正常に動作していることを確認します。

  12. これで、同じ手順を使用して他のデバイス(ファイアウォール-01)のアップグレードに進むことができます。

注:

(オプション)問題が発生してアップグレードを完了できない場合は、デバイス上のソフトウェアをロールバックし、システムを再起動できます。request system software rollbackコマンドを使用して、以前にインストールしたソフトウェアバージョンを復元します。

install-on-failure-routeを使用したソフトウェアのアップグレード

SRG0のみを使用する(A/B状態サポートなし)セットアップの場合は、install-on-failure-routeを設定することをお勧めします。このルートをルートポリシーで参照し、ソフトウェアのアップグレードシナリオやノードの障害時に優先度の低いパスをアドバタイズすることができます。この方法では、ルートを変更することでトラフィックを迂回させることができます。ここでは、トラフィックは引き続きノードを通過でき、インターフェイスは稼働したままになります。

  1. アップグレード中にトラフィックを迂回させるために使用するルート専用のカスタム仮想ルーターを作成します。

  2. SRG0の install-on-failure-route ステートメントを設定します。ここでは、ノードに障害が発生した場合にインストールするルートとして、IP アドレス 10.39.1.3 のルートを設定しました。

    ルーティングテーブルは、ノードに障害が発生した場合、ステートメントで説明されているルートをインストールします。

  3. マッチングするルーティングポリシーを設定し、ルートの存在に基づいてポリシー条件を定義します。ここでは、 if-route-existsのルート一致条件としてルート 10.39.1.3 を含めます。
  4. 一致する用語の1つとして条件を参照するポリシーステートメントを作成します。

  5. 前の手順(ソフトウェアアップグレード)で説明したように、ソフトウェアソフトウェアアップグレードを開始します。

非推奨の方法(障害時にシャットダウンインターフェイス)

Junos OS Release 24.3R1以降、 shutdown-on-failure 機能は、すぐには削除されませんが、非推奨と、後方互換性と、新しい設定に適合させる機会を提供します。この変更の一環として、[set chassis high-availability services-冗長性-group 0 shutdown-on-failure interface-name] 設定ステートメントは非推奨になりました。

以前は、インターフェイスをシャットダウンしてトラフィックを手動で迂回させる必要がありました。これで、software-upgradeコマンドを使用して、アップグレード期間中、ノードをオフライン状態に維持し、すべてのSRGをINELIGIBLE 状態に保つことができます。これにより、ノードがトラフィックの処理から効果的に分離されます。

Junos OS 22.4以前を使用している場合は、アップグレード中に従来の方法を使用してトラフィックを迂回させることをお勧めします。