Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Junos Node Slicing のアップグレード

Junosノードスライシングのアップグレードには、Juniper Device Manager(JDM)、ゲストネットワーク機能(GNF)、およびベースシステム(BSYS)のアップグレードが含まれます。

Junos Node Slicingのアップグレード

Junos Node Slicingは、3種類のソフトウェアコンポーネントで構成されています。

  • ジュニパーデバイスマネージャー(JDM)パッケージ

  • ゲストネットワーク機能(GNF)向けJunos OSイメージ

  • ベースシステム(BSYS)向けJunos OSパッケージ

これらの各コンポーネントは、ソフトウェアバージョンの許容範囲内であれば、個別にアップグレードできます(詳細については、 マルチバージョンソフトウェアの相互運用性の概要 を参照してください)。これらすべてをまとめてアップグレードすることもできます。

手記:
  • アップグレード プロセスを開始する前に、参照用に JDM、GNF VM、BSYS の設定を保存してください。

  • ラインカードでBIOSアップグレードを実行する場合、Junosノードスライシング設定を無効にして、ルーターがスタンドアロンモードになっていることを確認する必要があります。

外部サーバモデル用の JDM のアップグレード

  1. 両方のサーバーで以下のタスクを実行して、JDM をアップグレードします。

    1. 新しい JDM パッケージ(RPM または Ubuntu)をホスト上のディレクトリ( /var/tmp など)にコピーします。

    2. 次のコマンドを使用して JDM を停止します。

    3. upgrade コマンドを発行して、JDM パッケージをアップグレードします。

      JDM RHEL パッケージをアップグレードする場合は、次のコマンドを使用します。

      JDM Ubuntu パッケージをアップグレードする場合は、次のコマンドを使用します。

      手記:
      • JDM のアップグレードは、実行中の GNF には影響しません。

      • JDM をアップグレードする前に、両方の JDM デプロイメントが同期していることを確認してください。これはですね:

        • 特定の GNF で実行される Junos は、両方のサーバーで同じ SMBIOS バージョンをサポートする必要があります。

        • アップグレードする前に、すべての GNF が両方のサーバーに存在することを確認します。

      • 両方の JDM サーバーをアップグレードした後、新しい GNF を構成する前に commit synchronize を実行する必要があります。 commit synchronize を実行して、server1 で新しい GNF を作成しない場合、後で server0 から server1 に commit synchronize することはできません。

      • 両方の JDM をアップグレードする必要があります。

      関連項目:

ポッドマンベースのデプロイメントをサポートするためのJDMのアップグレード(23.2R1)

Junos OSリリース23.2R1以降、外部サーバーベースのJunosノードスライシングは、ポッドマネージャーツール(podman)を使用したジュニパーデバイスマネージャー(JDM)の導入をサポートします。Red Hat® Enterprise Linux® (RHEL) 9 以降のバージョンを実行しているサーバーのみが podman をサポートしています。

23.2R1 より前の Junos リリースでは、外部サーバーベースの Junos ノード スライシングは RHEL 7.3 をサポートしていました。RHEL 7.3 は、JDM を展開するための libvirt の lxc ドライバー(libvirt-lxc)を提供していました。

手記:

JDM のアップグレード中に JDM 設定をバックアップする必要がある場合は、まずデバイスに Junos バージョン 23.1R1 以降をインストールする必要があります。そのため、JDM設定(request system save state path および request system restore state path)をバックアップおよびリストアするコマンドは、Junosバージョン23.1R1以降でのみ使用可能です。

libvirt-lxc ベースの JDM を podman ベースのバージョンにアップグレードするには、両方のサーバーで以下の手順に従います。

  1. 両方のサーバーでJDMによって生成されたランダムなMACプレフィックスが同じかどうかを確認します。

  2. JDM 設定を /host/tmp/ フォルダにバックアップします。

    このステップでは、JDM 設定とランダム MAC プレフィックス値をバックアップします。MACプレフィックスは、ライセンス不要のゲストネットワーク機能(GNF)に関連付けられたMACアドレスの一部を形成します。

  3. 各サーバーで JDM をアンインストールします。詳細については、 Junos Node Slicingの管理を参照してください。

  4. ホスト OS を RHEL 9 にアップグレードします。

  5. ポッドマンベースの JDM をインストールします。これは通常のインストールプロセスです。JDM をインストールするには、 RHEL を実行する x86 サーバーへの JDM RPM パッケージのインストール (外部サーバーモデル)に記載されている手順を使用します。

  6. JDM バックアップをリストアします。

  7. 両方のサーバーで上記の手順を実行した後、両方のサーバーでJDMによって生成されたランダムなMACプレフィックスが同じかどうかを確認します。

手記:

JDM を libvirt-lxc ベースのバージョンからポッドマンベースのバージョンにアップグレードする前に、GNF をバックアップすることはできません。JDM をアップグレードした後、GNF を新たに設定する必要があります。

シャーシ内モデルの JDM のアップグレード

  1. 両方のルーティング・エンジンのBSYSインスタンスで以下のタスクを実行して、JDMをアップグレードします。

    1. 新しい JDM RPM パッケージをディレクトリ(/ var/tmp など)にコピーします。

    2. 次のコマンドを実行して、JDM を停止します。

    3. 次の例に示すコマンドを使用して、シャーシ内Junosノードスライス用のJDM RPMパッケージをインストールします。

      手記:

      JDM のアップグレードは、実行中の GNF には影響しません。

手記:

シャーシ内モデルのJDMをアップグレードする場合、既存のJDMソフトウェアをアンインストールする必要はありません。既存の JDM をアンインストールすると、ゲストネットワーク機能 (GNF) に影響を与える可能性があります。

GNF と BSYS のアップグレード

GNFおよびBSYSパッケージは、スタンドアロンMXシリーズルーターでJunos OSをアップグレードするのと同じ方法でアップグレードできます。

アップグレードの際には、すべての GNF がオンラインであることを確認してください。これは、GNF と BSYS の両方のアップグレード プロセスによってマルチバージョン チェックがトリガーされ (このガイドで後述)、マルチバージョン チェック フェーズ中にすべての GNF がオンラインである必要があり、失敗した場合はアップグレードが終了するためです。GNFがシャットダウンされたままの場合は、BSYS CLIから設定を非アクティブ化する必要があります。その場合、その特定のGNFのマルチバージョンチェックがスキップされます。

手記:

forceオプションも使用でき、JDM CLI コマンドrequest virtual-network-functions vnf-name add-image new-image-name forceを使用して、既存の GNF イメージを新しいイメージで上書きできます。これは、GNFイメージが起動しないまれな状況で役立ちます。また、force オプションを使用して、たとえば、進行中の以前のadd-imageを Ctrl-C を押して突然終了した場合にクリーンアップを実行することもできます (例: request virtual-network-functions vnf-name delete-image image-name force)。

WRL 9 ベースの VM ホストをサポートするための JDM のアップグレード - シャーシ内モデル

ルーティングエンジンでJunos OS 19.3R1以降を実行する場合は、JDMを19.3R1以降にアップグレードする必要があります。

手記:

19.3R1より前にリリースされたJunos OSバージョンでは、WRL6バージョンのVMホストソフトウェアを使用します。Junos OS 19.3R1では、WRL9バージョンのVMホストソフトウェアが導入されています。VM ホストのバージョンを確認するには、BSYS VM で Junos CLI コマンド show vmhost versionを使用します。

JDM をアップグレードするには、次の手順を使用します。

  1. 各GNFで、ルーティングエンジン1(re1)で実行されているバックアップGNFにプライマリロールを割り当てます。

  2. re0 では、まず JDM からの GNF を停止し、次に BSYS からの JDM 自体を停止します。

  3. re0 VM ホストのバージョンが Junos OS 19.3R1 以降であることを確認します。VM ホストのバージョンを確認するには、Junos CLI コマンド show vmhost versionを使用します。

    次のJunos CLIを使用して、VMホストソフトウェアをアップグレードできます。

    詳細については、「 VM ホストのインストール、アップグレード、バックアップ、および回復」を参照してください。

  4. 再起動後に re0 がバックアップされた場合は、新しい JDM RPM パッケージ(19.3R1 以降)をディレクトリ(/var/tmp など)にコピーします。

  5. re0 に新しい JDM RPM パッケージをインストールしてから、JDM を起動します。

    re0 の GNF は、このステップの後、自動的に開始されます。

  6. ルーティングエンジン1(r1)でステップ1から5を繰り返します。

  7. 両方のルーティングエンジンのJDMで request server authenticate-peer-server コマンドを実行します。

  8. set system commit synchronizeを設定し、re0 JDMにcommitを適用します。

手記:

JDMソフトウェアバージョン19.3R1は、Junos OSバージョン19.3R1および19.3R1より前のJunos OSバージョンで実行できます。

外部サーバーモデルへの JDM のダウングレード

手記:

単一サーバーベースのJunosノードスライシング設定にインストールされているJuniper Device Manager(JDM)をダウングレードすることはできません。

JDM をダウングレードするには、以下のステップを使用します。

  1. server1 で実行されているバックアップ GNF にプライマリ ロールを割り当てます。
  2. server0 で、すべての GNF を停止し、 commit synchronize 設定を削除します。
  3. server0 で、JDM を停止してアンインストールします。
    手記:

    Ubuntuを使用している場合は、コマンド dpkg --purge jns-jdm を使用してJDMをアンインストールします。

  4. server0 で、JDM のターゲット バージョンをインストールします。
  5. ルート認証またはインターフェイス、およびルーティングオプションを使用して JDM を設定します。
  6. server0 JDM で、JDM バージョンと互換性のある GNF イメージ・バージョンを追加します。

    GNF バージョンが JDM バージョンと互換性がない場合は、次のエラーメッセージが表示されます。

  7. GNFがサーバー0 JDMに現れるまで待ちます。
  8. プライマリ ルーティング エンジン(server1 で実行されている GNF)からコミット同期を実行します。
  9. server0 JDM で実行されている GNF にプライマリロールを割り当てます。
  10. サーバー 1 で、手順 2 から 5 を繰り返します。
  11. 両方のサーバーで request server authenticate-peer-server コマンドを実行します。
  12. show server connections all-serversを適用し、問題が見られないことを確認します。
  13. set system commit synchronizeを構成し、server0 JDM にcommitを適用します。
  14. コマンド show virtual-network-functions all-servers を使用して、GNFが立ち上がっているかどうかを確認します。

シャーシ内モデルへのJDMのダウングレード

手記:

単一のルーティングエンジンベースのJunosノードスライシングセットアップにインストールされているJuniper Device Manager(JDM)をダウングレードすることはできません。

JDM をダウングレードするには、以下のステップを使用します。

  1. ルーティング エンジン 1(re1)で実行されているバックアップ GNF にプライマリ ロールを割り当てます。
  2. re0 で、すべての GNF を停止し、 commit synchronize 設定を削除します。
  3. re0 で、(BSYS プライマリ上の) JDM をアンインストールします。
  4. re0 で、JDM のターゲット バージョン (例: 18.3R1) をインストールします。
  5. re0 で、server1 で実行されているのと同じバージョンの GNF を展開します。

    GNF バージョンが JDM バージョンと互換性がない場合は、次のエラーメッセージが表示されます。

    次のコマンドを使用して、GNFのバージョンを確認できます。

  6. re1 で、手順 1 から 5 を繰り返します。
  7. 両方のルーティング エンジンで request server authenticate-peer-server コマンドを実行します。
  8. プライマリ ルーティング エンジン(server1 で実行されている GNF)からコミット同期を実行します。
  9. set system commit synchronizeを設定し、re0 JDMにcommitを適用します。

現在、JDMはJunos OSバージョン18.3R1で稼働しています。

統合型ISSUサポート

Junos Node Slicingは、ISSU(統合型インサービスソフトウェアアップグレード)もサポートしているため、コントロールプレーンを中断することなく、トラフィックの中断を最小限に抑えながら、2つの異なるJunos OSバージョン間でアップグレードすることができます。統合型ISSUは、BSYSとGNFで別々に実行できます。また、他の GNF に影響を与えることなく、各 GNF で統合 ISSU を個別に実行できます。 統合 ISSU プロセスについても参照してください。

手記:
  • マルチバージョン ソフトウェア サポートの制限(バージョン逸脱制限など)は、統合 ISSU アップグレードにも適用されます。

  • Junos OS Release 21.4R1以降、SLC(サブラインカード)を搭載したMPC11Eは、ゼロパケット損失モードでISSUをサポートします。それ以前のJunos OSバージョンを実行している場合は、SLCを備えたJunosノードスライシング設定でISSUを実行しないでください。

マルチバージョンソフトウェアの相互運用性の管理

Junosノードスライシングは、マルチバージョンソフトウェアの相互運用性をサポートします。ただし、ソフトウェアのバージョン間に非互換性がある場合は、ソフトウェアのアップグレードプロセス中、またはGNFまたはFRUがオンラインになったときに警告メッセージが表示されます。軽微な非互換性が発生した場合は、それらを受け入れて続行することを選択できます。重大な非互換性がある場合は、プロセスを終了するか、 force オプションを使用して非互換性を受け入れて続行する必要があります。

手記:

vmhostソフトウェアのアップグレードの場合、 force オプションは使用できません。したがって、GNFがオフラインであるか、インストールするソフトウェアと互換性がなく、マルチバージョンチェックが終了する場合は、ソフトウェアのアップグレード中にそのGNFを非アクティブ化し、アップグレードの終了後に再アクティブ化する必要があります。

以下は、ソフトウェアのアップグレード中に非互換性が検出された場合に表示されるメッセージの例です。

Sample alert message indicating a minor incompatibility:

Sample alert message indicating a major incompatibility:

Sample output showing how to use the 'force' option to proceed with an upgrade:

ソフトウェア非互換性アラームの表示

GNF または BSYS のソフトウェア アップデート後、GNF と BSYS の間にソフトウェアの非互換性が存在する場合は、シャーシ アラームとして発生します。非互換性アラーム情報は、 show chassis alarms コマンドを使用して表示できます。非互換性の詳細をさらに表示するには、 show system anomalies コマンドを使用します。詳細については、 ソフトウェアバージョン間の非互換性の表示を参照してください。

アップグレードが BSYS で実行されている場合でも、アラームは GNF にのみ表示されます。次のタイプのアラームが発生する可能性があります。

  • BSYS とのシステムの非互換性:これは重大なアラームです。これは、BSYSソフトウェアバージョンとGNFソフトウェアバージョン間の非互換性が原因でGNFがオフラインになった場合に表示されます。

  • 機能 BSYS との非互換性:これは軽微なアラームです。これは、BSYS ソフトウェアと GNF ソフトウェア バージョン間の軽微な非互換性を示します。これによって GNF がオフラインになることはありません。

ソフトウェアバージョン間の非互換性の表示

BSYSからソフトウェアの非互換性を表示するには、次の例に示すようにCLIを使用します。

GNFからソフトウェアの非互換性を表示するには、次の例に示すようにCLIを使用します。

手記:
  • CLIに示すように、BSYSからの非互換性を確認しながら、GNF IDを指定することを忘れないでください。

  • 上記の例は、システム レベルの非互換性を示しています。 fru または config オプションを使用して、FRUまたは機能レベルの非互換性を表示します。

外部サーバーの再起動

ハードウェアやホストOSのアップグレード、障害の分離などのサーバーメンテナンス作業では、Junosノードスライスで使用される外部サーバーの再起動が必要になる場合があります。サーバーを再起動するには、次の手順を使用します。

  1. すべての GNF を停止します。

    両方のサーバを再起動する場合は、次の例に示すように、各 GNF を停止しながら [ all-servers ] オプションを選択します。

    特定のサーバーを再始動する場合は、以下の例に示すように、server-id を指定して、そのサーバー上の GNF を停止します。

  2. GNF が停止していることを確認します。
    手記:

    両方のサーバーの GNF のステータスを表示する場合は、[ all-servers ] オプションを選択します。例: show virtual-network-functions all-servers)。

  3. Linux ホスト・シェルから、以下のコマンドを使用して JDM を停止します。
  4. Linux ホスト・シェルから、JDM の状況が「停止」と表示されていることを確認します。
  5. 再起動後、JDM のステータスが実行中になっていることを確認します。

サーバーの再起動後、JDM と設定された GNF が自動的に実行を開始します。

サーバーを交換する場合は、オペレーティング・サーバーのペアが引き続き類似または同一のハードウェア構成であることを確認してください。交換中にサーバー ペアが一時的に異種になった場合(サーバーを順次交換する場合など)、この期間、GRES と NSR を無効にし、両方のサーバーが再び類似した場合にのみ再度有効にすることを推奨します。

外部サーバー上のホスト OS の更新

外部サーバー上のホスト OS を更新する前に、 外部サーバーの再起動の説明に従って、まずそのサーバー上の GNF と JDM を停止する必要があります。

ホスト OS の更新後、Intel X710 NIC を使用している場合は、「 x86 サーバー用のインテル X710 NIC ドライバーのアップデート 」の説明に従って、使用中の X710 NIC ドライバーのバージョンが引き続き最新バージョンであることを確認します。

ホストOSへのセキュリティ更新プログラムの適用

ホストOSでは、セキュリティアップデートが随時必要です。このセクションでは、Red Hat (RHEL) OS を使用してホストOSにセキュリティアップデートを適用する手順について説明します。

Junos ノード スライシングは RHEL 7.3 をサポートしています。

ホスト OS を更新する前に、Red Hat サブスクリプションマネージャーがバージョン 7.3 に設定されていること、および Red Hat サブスクリプションサービスに延長更新サポート (EUS) が含まれていることを確認してください。

コマンド subscription-manager release --show を使用して、リリースが 7.3 に設定されていることを確認できます。そうでない場合は、コマンド subscription-manager release --set=7.3 を使用してリリースを 7.3 に設定できます。

手記:

Red Hat サブスクリプションマネージャーがバージョン 7.3 に設定されていることを確認する必要があります。それ以外の場合、RHEL の更新は最新のマイナーリリースへのアップグレードを試みます。たとえば、RHEL 7.3 は一般的な yum 更新プログラムで RHEL 7.4 (またはそれ以降のバージョン) になる可能性があり、 yum セキュリティ更新プログラムは RHEL 7.3 を超える新しいカーネルをプルできます。

Red Hat の延長アップデートサポートにより、指定されたリリース内でパッチとセキュリティアップデートを適用できます。RHEL の延長更新サポートの使用許可は、RHEL サポート契約の機能であり、このセクションの範囲外です。RHEL サブスクリプションに拡張更新サポート (EUS) が含まれているかどうかを確認するには、コマンド subscription-manager repos --list | grep rhel-7-server-eus-rpmsを使用します。EUS サポートはデフォルトでは有効になっていません。EUS は、コマンド subscription-manager repos --enable rhel-7-server-eus-rpms を使用して有効にできます。

ホストOSのセキュリティ更新プログラムを適用する手順

ホスト OS にセキュリティ更新プログラムを適用すると、外部 x86 サーバーの再起動が必要になる可能性があります。 「外部サーバーでのホスト OS の更新 」トピックを参照してください。

ホストOSのセキュリティアップデートにより、新しいカーネルバージョンがもたらされる可能性もあります。ホストOSカーネルを更新すると、Intel i40eドライバーが上書きされ、i40eドライバーの最小バージョン要件を満たしていないバージョンが持ち込まれる可能性もあります。その場合は、最小要件を満たすようにi40eドライバーを更新する必要があります。詳細については、「 x86 サーバー用のインテル X710 NIC ドライバーのアップデート」を参照してください。

外部 x86 サーバーを再起動する前に、そのサーバー上のすべての GNF VM と JDM を停止する必要があります。2つの外部x86サーバーがあるため、ホストOSのセキュリティ更新は、一度に1つのサーバーを更新することで、GNF転送を中断することなく実行できます。影響を受けるサーバーからプライマリ ルーティング エンジンを移動するには、GRES/NSR プライマリ ルーティング エンジンの切り替えが必要です。

まず、各GNFのバックアップルーティングエンジンとしてのルーティングエンジン1(re1)のデフォルトの動作から始め、各GNFの re1 が外部x86サーバー1で実行されます1。

  1. すべての構成をバックアップします。

  2. ホスト OS のセキュリティ更新プログラムの前に、外部 x86 サーバー上のホスト OS カーネルとパッケージ バージョンのビューを収集します。また、i40eドライバーとIntel X710ファームウェアが最小要件を満たしていることを確認します(バージョン:2.4.10およびバージョン:18.5.17)。

  3. RedHat サブスクリプションマネージャーが RHEL 7.3 に設定され、EUS リポジトリが有効になっていることを確認します。

  4. すべてのGNFがserver0でプライマリREを使用していることを確認します。バックアップ ルーティング エンジンは server1re1されます。まず、バックアップ ルーティング エンジンを含むサーバーでホスト OS のセキュリティ更新を実行します。

    すべてのGNFでこのコマンドを実行し、すべてのGNFのプライマリ・ルーティング・エンジンがserver0にあることを確認します。

  5. server1 でのみリクエストstopを介して、JDM CLI 内のすべての GNF VM を停止します。server1、すべての GNF のバックアップ ルーティング エンジンが含まれています。all-servers オプションは使用しないでください。例:

  6. ホストOSから影響を受けるサーバー上のJDMを停止します。

  7. yumセキュリティ更新プログラムを実行し、サーバーを再起動します。

  8. i40e ドライバをリロードまたはコンパイルします。ドライバのアップデート手順については、 インテルのサポートページ を参照してください。

    この時点で、 server1 へのホストOSのセキュリティアップデートが完了しています。GNF VM はサーバーの再起動時に起動することに注意してください。

  9. セキュリティ更新が完了し、サーバーが再起動され、GNFがバックアップされたら、他のサーバーで繰り返します。

Ubuntuコンテナのセキュリティパッチの適用

Juniper Device Manager(JDM)のベースとなっているUbuntuコンテナには、セキュリティパッチを随時適用する必要があります。

手記:

JDM はインターネットに到達でき、 name-server 構成されている必要があります。次の JDM CLI 設定ステートメントを適用して、 name-serverを指定します。

root@jdm# set system name-server address

次の手順を使用して、JDM の Ubuntu コンテナー コンポーネントにセキュリティ更新プログラムを適用します。

  1. 外部サーバーモデルを使用している場合は、ホストOSからJDMコンソールを使用して、JDMをrootとして入力します。

    root@server# jdm console

    または、JDM CLI から、次のコマンドを使用して JDM シェルを入力します。

    root@jdm> start shell user root

    シャーシ内のJunosノードスライシングを使用している場合は、BSYS VMで次のコマンドを使用してJDMに入ります。

    root@router> request vmhost jdm login

  2. JDM シェルから、コマンド apt-get update を使用して、新規パッケージまたは現在インストールされているパッケージの最新バージョンに関する情報をダウンロードします。

    jdm-srv1:~# sudo apt-get update

  3. JDM シェルから、コマンド apt-get upgrade を使用します。

    jdm-srv1:~# sudo apt-get upgrade

    アップグレードの一覧が表示され、続行するように求められます。「はい」に Y 答えて 、Enter キーを押します。

  4. JDM シェルから、コマンド apt-get dist-upgrade を使用してアップグレードを実行します。

    jdm-srv1:~# sudo apt-get dist-upgrade

    続行を求められたら Y に応答し、アップグレードが完了するのを待ちます。

  5. 外部サーバーモデルを使用している場合は、ホストOSからJDMを再起動します。

    user@server# sudo jdm restart

    シャーシ内のJunosノードスライシングを使用している場合は、BSYS VMで次のコマンドを使用してJDMを再起動します。

    root@router> request vmhost jdm stop

    root@router> request vmhost jdm start