Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Junos Node Slicingのアップグレード

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

Junos Node Slicingのアップグレード

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

  • Juniper Device Manager(JDM)パッケージ

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

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

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

メモ:

アップグレード プロセスを開始する前に、JDM、GNF VM、BSYS 設定を参照用に保存します。

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

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

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

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

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

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

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

      メモ:
      • JDM アップグレードは、実行中のどの GNF にも影響を与えません。

      • JDM をアップグレードする前に、両方の JDM 導入が同期していることを確認します。これはですね:

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

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

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

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

      詳細は、以下も参照してください。

シャーシ内モデルの 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 イメージで上書きできます。これは、GNF イメージが起動しないまれな状況で役立ちます。このオプションをforce使用してクリーンアップを実行することもできます。たとえば、実行中の以前add-imageのファイルを突然終了した場合は、Ctrl-C(例: request virtual-network-functions vnf-name delete-image image-name force)を押します。

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

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

メモ:

19.3R1 より前にリリースされた Junos OS バージョンでは、WRL6 バージョンの VM ホスト ソフトウェアが使用されています。Junos OS 19.3R1 には、WRL9 バージョンの VM ホスト ソフトウェアが組み込まれています。BSYS VM で 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 API を使用して VM ホスト ソフトウェアをアップグレードできます。

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

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

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

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

  6. ルーティング エンジン 1(r1)で手順 1~5 を繰り返します。

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

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

メモ:

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

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

メモ:

単一サーバーベースの Junos Node Slicing セットアップにインストールされている Juniper Device Manager(JDM)をダウングレードすることはできません。

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

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

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

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

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

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

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

メモ:

単一のルーティング エンジンベースの Junos Node Slicing 設定にインストールされている Juniper Device Manager(JDM)をダウングレードすることはできません。

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

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

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

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

  6. re1 では、ステップ 1 から 5 を繰り返します。
  7. 両方の request server authenticate-peer-server ルーティング エンジンでコマンドを実行します。
  8. プライマリ ルーティング エンジン(サーバー 1 で実行されている GNF)からコミット同期を実行します。
  9. re0 JDM を設定 set system commit synchronize して適用 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 以降、SPC(サブライン カード)を備えた MPC11E は、ISSU をゼロ パケット ロス モードでサポートしています。以前の Junos OS バージョンを実行している場合は、SPC を備えた 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 を指定することを忘れないでください。

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

外部サーバーの再起動

ハードウェアやホスト OS のアップグレードや障害分離などのサーバー保守作業では、Junos Node Slicing で使用されている外部サーバーの再起動が必要になる場合があります。サーバーを再起動するには、次の手順に従います。

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

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

    特定のサーバーを再起動する場合は、次の例に示すようにサーバー 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 サーバー用 Intel X710 NIC ドライバーの更新」で説明されているとおり、使用中の X710 NIC ドライバー のバージョンが最新バージョンであることを確認します。

ホスト OS へのセキュリティ更新の適用

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

Junos Node Slicing は 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 サポート 契約の機能です。コマンド subscription-manager repos --list | grep rhel-7-server-eus-rpmsを使用して、RHEL サブスクリプションに拡張更新サポート(EUS)が含まれているかどうかを確認できます。EUSサポートはデフォルトでは有効になっていません。EUS は、コマンド subscription-manager repos --enable rhel-7-server-eus-rpmsを使用して有効にできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

  8. 再読み込みまたは i40e ドライバーをコンパイルします。ドライバーの更新手順については、 Intel サポート ページ を参照してください。

    この時点で、ホスト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