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 する必要があります。server1 で新しい GNF を実行して commit synchronize 作成しなければ、 commit synchronize 後で server0 から server1 に移動することはできません。

      • 両方の 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イメージが起動しないまれな状況で役立ちます。また、このオプションを使用して、 例えば、 Ctrl-C を押すことによって、進行中の以前のものをadd-image突然終了した場合にクリーンアップを実行することもできます force (例: 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. request server authenticate-peer-server両方のルーティングエンジンのJDMでコマンドを実行します。

  8. re0 set system commit synchronize 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. re0 set system commit synchronize 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または機能レベルの非互換性を表示するには、 fru または config オプションを使用します。

外部サーバーの再起動

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

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

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

    特定のサーバーを再始動する場合は、以下の例に示すように、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 9 をサポートしています。

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

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

メモ：

Red Hat サブスクリプションマネージャーがバージョン 9 に設定されていることを確認する必要があります。

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)のデフォルトの動作から始め、 re1 各GNFは外部x86サーバー1で動作します。

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

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

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

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

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

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

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

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

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

    この時点で、ホストOSのセキュリティアップデート server1 は完了です。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

関連ドキュメント