Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

Junosノードスライシングアップグレード

Junos Node Slicingのアップグレードには、ジュニパーデバイスマネージャー(JDM)、ゲストネットワーク機能(GNF)、ベースシステム(BSYS)のアップグレードが含まれます。

Junos Node Slicingのアップグレード

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

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

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

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

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

注:

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

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

外部サーバーモデル用の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 を実行しず、サーバー 1 で新しい GNF を作成すると、後でサーバー 0 からサーバー 1 に commit synchronize を行うことはできません。

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

      参照:

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

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

23.2R1 以前の Junos リリースでは、外部サーバーベースの Junos Node Slicing は 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設定とrandom-mac-prefix値をバックアップします。MACプレフィックスは、ライセンス不要のゲストネットワーク機能(GNF)に関連付けられたMACアドレスの一部を形成します。

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

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

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

  6. JDMバックアップを復元します。

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

注:

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

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

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

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

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

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

      注:

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

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

GNF と BSYS のアップグレード

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

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

注:

JDM CLIコマンドrequest virtual-network-functions vnf-name add-image new-image-name forceを使用して、既存のGNFイメージを新しいGNFイメージで上書きできるforceオプションも使用できます。これは、GNF イメージが起動しないというまれな状況で役立ちます。また、forceオプションを使用して、たとえば、Ctrl-Cを押して進行中の以前のadd-imageを突然終了した場合にクリーンアップを実行することもできます(例: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. 新しいJDM RPMパッケージをre0にインストールしてから、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 Node Slicingセットアップにインストールされているジュニパーデバイスマネージャー(JDM)はダウングレードできません。

JDMをダウングレードするには、次の手順を使用します。

  1. サーバー1で実行されているバックアップ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がserver0 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を設定し、サーバー0 JDMにcommitを適用します。
  14. コマンド show virtual-network-functions all-servers を使用して、GNFが立ち上がるかどうかを確認します。

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

注:

単一のルーティングエンジンベースのJunos Node Slicingセットアップにインストールされているジュニパーデバイスマネージャー(JDM)をダウングレードすることはできません。

JDMをダウングレードするには、次の手順を使用します。

  1. ルーティングエンジン1(re1)で実行されているバックアップGNFにプライマリロールを割り当てます。
  2. re0で、すべてのGNFを停止し、 commit synchronize 設定を削除します。
  3. re0で、JDMをアンインストールします(BSYSプライマリ上)。
  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バージョン間でアップグレードできます。BSYSとGNFで統一ISSUを別々に実行できます。また、他のGNFに影響を与えることなく、各GNFで独立して統合型ISSUを実行することもできます。 統合型ISSUについても参照してください。

注:

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

  • Junos OSリリース21.4R1以降、SLC(サブラインカード)を搭載したMPC11Eは、ゼロパケットロスモードでISSUをサポートします。それより前のバージョンのJunos OSを実行している場合は、SLCを備えたJunos Node SlicingセットアップでISSUを実行しようとしないでください。

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

Junos Node Slicingは、マルチバージョンのソフトウェアの相互運用性をサポートします。ただし、ソフトウェアバージョン間に非互換性がある場合は、ソフトウェアアップグレードプロセス中、または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 Node Slicingで使用する外部サーバーの再起動が必要になる場合があります。サーバーを再起動するには、次の手順に従います。

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

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

    特定のサーバーを再起動する場合は、次の例に示すように、サーバー ID を指定してそのサーバーの GNF を停止します。

  2. GNF が停止したことを確認します。
    注:

    両方のサーバー上のGNFのステータスを表示するには、[ all-servers ]オプションを選択します。例: show virtual-network-functions all-servers)。
  3. Linuxホストシェルから、次のコマンドを使用してJDMを停止します。
  4. Linuxホストシェルから、JDMステータスが「stopped」と表示されていることを確認します。
  5. 再起動後、JDMのステータスが「実行中」と表示されていることを確認します。

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

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

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

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

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

ホストOSへのセキュリティアップデートの適用

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

Junos Node Slicingは、RHEL 7.3をサポートしています。

ホスト OS の更新を実行する前に、Red Hat Subscription Manager がバージョン 7.3 に設定されていること、および Red Hat Subscription Service に Extended Update Support (EUS) が含まれていることを確認してください。

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

注:

Red Hat Subscription Manager がバージョン 7.3 に設定されていることを確認する必要があります。それ以外の場合、RHEL のアップデートは最新のマイナーリリースへのアップグレードを試みます。たとえば、RHEL 7.3 は一般的な yum アップデートで RHEL 7.4 (またはそれ以降のバージョン) になったり、 yum セキュリティアップデートで RHEL 7.3 以降の新しいカーネルを取り込んだりする可能性があります。

Red Hat の拡張アップデートサポートにより、指定されたリリース内でパッチとセキュリティアップデートを適用できます。RHEL の延長更新サポートの使用が許可されているかどうかは、RHEL サポートコントラクトの機能であり、このセクションの範囲を超えています。RHEL サブスクリプションに Extended Update Support (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を停止する必要があります。外部x86サーバーが2台あるため、ホストOSのセキュリティアップデートは、一度に1台ずつアップデートすることで、GNF転送を中断することなく実行できます。プライマリルーティングエンジンを影響を受けるサーバーから移動させるには、GRES/NSRプライマリルーティングエンジンの切り替えが必要です。

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

  1. すべての設定をバックアップします。

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

  3. RedHat Subscription Manager が RHEL 7.3 に設定され、EUS リポジトリーが有効になっていることを確認します。

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

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

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

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

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

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

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

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

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

ジュニパーデバイスマネージャー(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 Node Slicing を使用している場合は、BSYS VM で次のコマンドを使用して JDM を入力します。

    root@ルーター> 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 Node Slicing を使用している場合は、BSYS VM で以下のコマンドを使用して JDM を再起動します。

    root@ルーター> request vmhost jdm stop

    root@ルーター> request vmhost jdm start

関連ドキュメント