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 のアップグレード
- ポッドマンベースのデプロイメントをサポートするためのJDMのアップグレード(23.2R1)
- シャーシ内モデルの JDM のアップグレード
- GNF と BSYS のアップグレード
- WRL 9 ベースの VM ホストをサポートするための JDM のアップグレード - シャーシ内モデル
外部サーバモデル用の JDM のアップグレード
-
両方のサーバーで以下のタスクを実行して、JDM をアップグレードします。
-
新しい JDM パッケージ(RPM または Ubuntu)をホスト上のディレクトリ( /var/tmp など)にコピーします。
-
次のコマンドを使用して JDM を停止します。
root@Linux server0#
jdm stop
Stopping JDM -
upgrade コマンドを発行して、JDM パッケージをアップグレードします。
JDM RHEL パッケージをアップグレードする場合は、次のコマンドを使用します。
root@Linux server0#
rpm -U package_name.rpm --force
JDM Ubuntu パッケージをアップグレードする場合は、次のコマンドを使用します。
root@Linux server0#
dpkg -i package.deb
手記:-
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 ベースのバージョンにアップグレードするには、両方のサーバーで以下の手順に従います。
-
両方のサーバーでJDMによって生成されたランダムなMACプレフィックスが同じかどうかを確認します。
user@jdm>
show system random-mac-prefix all-servers
-
JDM 設定を /host/tmp/ フォルダにバックアップします。
user@jdm>
request system save state path /host/tmp/jdm-backup.tgz
Backup Done at:[/host/tmp/jdm-backup.tgz]このステップでは、JDM 設定とランダム MAC プレフィックス値をバックアップします。MACプレフィックスは、ライセンス不要のゲストネットワーク機能(GNF)に関連付けられたMACアドレスの一部を形成します。
-
各サーバーで JDM をアンインストールします。詳細については、 Junos Node Slicingの管理を参照してください。
-
ホスト OS を RHEL 9 にアップグレードします。
-
ポッドマンベースの JDM をインストールします。これは通常のインストールプロセスです。JDM をインストールするには、 RHEL を実行する x86 サーバーへの JDM RPM パッケージのインストール (外部サーバーモデル)に記載されている手順を使用します。
-
JDM バックアップをリストアします。
user@jdm>
request system restore state path /host/tmp/jdm-backup.tgz
Backup Restored from:[/host/tmp/jdm-backup.tgz] -
両方のサーバーで上記の手順を実行した後、両方のサーバーでJDMによって生成されたランダムなMACプレフィックスが同じかどうかを確認します。
user@jdm>
show system random-mac-prefix all-servers
JDM を libvirt-lxc ベースのバージョンからポッドマンベースのバージョンにアップグレードする前に、GNF をバックアップすることはできません。JDM をアップグレードした後、GNF を新たに設定する必要があります。
シャーシ内モデルの JDM のアップグレード
-
両方のルーティング・エンジンのBSYSインスタンスで以下のタスクを実行して、JDMをアップグレードします。
-
新しい JDM RPM パッケージをディレクトリ(/ var/tmp など)にコピーします。
-
次のコマンドを実行して、JDM を停止します。
root@router>
request vmhost jdm stop
-
次の例に示すコマンドを使用して、シャーシ内Junosノードスライス用のJDM RPMパッケージをインストールします。
root@router>
request vmhost jdm add jns-jdm-vmhost-18.3-20180930.0.x86_64.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 をアップグレードするには、次の手順を使用します。
-
各GNFで、ルーティングエンジン1(re1)で実行されているバックアップGNFにプライマリロールを割り当てます。
root@router>
request chassis routing-engine master switch no-confirm
-
re0 では、まず JDM からの GNF を停止し、次に BSYS からの JDM 自体を停止します。
root@jdm>
request virtual-network-functions stop gnf-name
root@router>request vmhost jdm stop
-
re0 VM ホストのバージョンが Junos OS 19.3R1 以降であることを確認します。VM ホストのバージョンを確認するには、Junos CLI コマンド
show vmhost version
を使用します。次のJunos CLIを使用して、VMホストソフトウェアをアップグレードできます。
root@router>
request vmhost software add package-name
root@router>request vmhost reboot
詳細については、「 VM ホストのインストール、アップグレード、バックアップ、および回復」を参照してください。
-
再起動後に re0 がバックアップされた場合は、新しい JDM RPM パッケージ(19.3R1 以降)をディレクトリ(/var/tmp など)にコピーします。
-
re0 に新しい JDM RPM パッケージをインストールしてから、JDM を起動します。
root@router>
request vmhost jdm add package-name
root@router>request vmhost jdm start
re0 の GNF は、このステップの後、自動的に開始されます。
-
ルーティングエンジン1(r1)でステップ1から5を繰り返します。
-
両方のルーティングエンジンのJDMで
request server authenticate-peer-server
コマンドを実行します。user@jdm>
request server authenticate-peer-server
-
set system commit synchronize
を設定し、re0 JDMにcommit
を適用します。user@jdm#
set system commit synchronize
user@jdm#commit synchronize
JDMソフトウェアバージョン19.3R1は、Junos OSバージョン19.3R1および19.3R1より前のJunos OSバージョンで実行できます。
関連項目
外部サーバーモデルへの JDM のダウングレード
単一サーバーベースのJunosノードスライシング設定にインストールされているJuniper Device Manager(JDM)をダウングレードすることはできません。
JDM をダウングレードするには、以下のステップを使用します。
シャーシ内モデルへのJDMのダウングレード
単一のルーティングエンジンベースのJunosノードスライシングセットアップにインストールされているJuniper Device Manager(JDM)をダウングレードすることはできません。
JDM をダウングレードするには、以下のステップを使用します。
現在、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:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz
Starting Multiversion compatibility checks for package /var/tmp/junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz
Starting compatibility checks...
--------------------------------------------------------------------------------
System Anomalies:
--------------------------------------------------------------------------------
Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
100 WARN <sample system incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
103 WARN <sample system incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
--------------------------------------------------------------------------------
CFG Anomalies for: set snmp interface
--------------------------------------------------------------------------------
FRU-ID Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
NONE 102 WARN <sample config incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
NONE 105 WARN <sample config incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
--------------------------------------------------------------------------------
FRU Anomalies:
--------------------------------------------------------------------------------
FRU-ID Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
0xaa0b 100 WARN <sample FRU incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
0xbb0b 101 WARN <sample FRU incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
Compatibility Checks done... OK
NOTICE: Validating configuration against junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Verified junos-install-mx-x86-64-17.4-20170703_dev_common.0 signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Sample alert message indicating a major incompatibility:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Starting Multiversion compatibility checks for package /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Starting compatibility checks...
--------------------------------------------------------------------------------
System Anomalies:
--------------------------------------------------------------------------------
Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
1677721600 ABORT <sample system incompatibility 1>
error: Junos-Node-Slicing multi-version checks returned abort for package /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Sample output showing how to use the 'force' option to proceed with an upgrade:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz force
NOTICE: Validating configuration against junos-install-mx-x86-64-17.4I20170713_0718.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Verified junos-install-mx-x86-64-17.4I20170713_0718 signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Verified manifest signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Checking PIC combinations
Adding junos-x86-64-17.4I20170713_0718...
ソフトウェア非互換性アラームの表示
GNF または BSYS のソフトウェア アップデート後、GNF と BSYS の間にソフトウェアの非互換性が存在する場合は、シャーシ アラームとして発生します。非互換性アラーム情報は、 show chassis alarms
コマンドを使用して表示できます。非互換性の詳細をさらに表示するには、 show system anomalies
コマンドを使用します。詳細については、 ソフトウェアバージョン間の非互換性の表示を参照してください。
アップグレードが BSYS で実行されている場合でも、アラームは GNF にのみ表示されます。次のタイプのアラームが発生する可能性があります。
BSYS とのシステムの非互換性:これは重大なアラームです。これは、BSYSソフトウェアバージョンとGNFソフトウェアバージョン間の非互換性が原因でGNFがオフラインになった場合に表示されます。
機能 BSYS との非互換性:これは軽微なアラームです。これは、BSYS ソフトウェアと GNF ソフトウェア バージョン間の軽微な非互換性を示します。これによって GNF がオフラインになることはありません。
ソフトウェアバージョン間の非互換性の表示
BSYSからソフトウェアの非互換性を表示するには、次の例に示すようにCLIを使用します。
user@router> show system anomalies gnf-id 4 system
GNFからソフトウェアの非互換性を表示するには、次の例に示すようにCLIを使用します。
user@router> show system anomalies system
CLIに示すように、BSYSからの非互換性を確認しながら、GNF IDを指定することを忘れないでください。
上記の例は、システム レベルの非互換性を示しています。
fru
またはconfig
オプションを使用して、FRUまたは機能レベルの非互換性を表示します。
外部サーバーの再起動
ハードウェアやホストOSのアップグレード、障害の分離などのサーバーメンテナンス作業では、Junosノードスライスで使用される外部サーバーの再起動が必要になる場合があります。サーバーを再起動するには、次の手順を使用します。
サーバーの再起動後、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。
すべての構成をバックアップします。
ホスト OS のセキュリティ更新プログラムの前に、外部 x86 サーバー上のホスト OS カーネルとパッケージ バージョンのビューを収集します。また、i40eドライバーとIntel X710ファームウェアが最小要件を満たしていることを確認します(バージョン:2.4.10およびバージョン:18.5.17)。
user@server#
cat /etc/redhat-release
user@server#uname -r
user@server#uname -a
user@server#rpm -q kernel
user@server#ethtool -i p3p1
-
RedHat サブスクリプションマネージャーが RHEL 7.3 に設定され、EUS リポジトリが有効になっていることを確認します。
[user@server ~]#
subscription-manager version
[user@server ~]#subscription-manager repos --list | grep rhel-7-server-eus-rpms
すべてのGNFが
server0
でプライマリREを使用していることを確認します。バックアップ ルーティング エンジンはserver1
でre1
されます。まず、バックアップ ルーティング エンジンを含むサーバーでホスト OS のセキュリティ更新を実行します。user@router>
show chassis routing-engine
すべてのGNFでこのコマンドを実行し、すべてのGNFのプライマリ・ルーティング・エンジンがserver0にあることを確認します。
server1
でのみリクエストstop
を介して、JDM CLI 内のすべての GNF VM を停止します。server1
、すべての GNF のバックアップ ルーティング エンジンが含まれています。all-servers
オプションは使用しないでください。例:user@jdm>
request virtual-network-functions gnf-a stop server 1
user@jdm>request virtual-network-functions gnf-b stop server 1
ホストOSから影響を受けるサーバー上のJDMを停止します。
user@server#
jdm status
user@server#jdm stop
yum
セキュリティ更新プログラムを実行し、サーバーを再起動します。user@server#
yum -y update -security
root@server#shutdown -r now
i40e ドライバをリロードまたはコンパイルします。ドライバのアップデート手順については、 インテルのサポートページ を参照してください。
この時点で、
server1
へのホストOSのセキュリティアップデートが完了しています。GNF VM はサーバーの再起動時に起動することに注意してください。セキュリティ更新が完了し、サーバーが再起動され、GNFがバックアップされたら、他のサーバーで繰り返します。
Ubuntuコンテナのセキュリティパッチの適用
Juniper Device Manager(JDM)のベースとなっているUbuntuコンテナには、セキュリティパッチを随時適用する必要があります。
JDM はインターネットに到達でき、 name-server
構成されている必要があります。次の JDM CLI 設定ステートメントを適用して、 name-server
を指定します。
root@jdm# set system name-server address
次の手順を使用して、JDM の Ubuntu コンテナー コンポーネントにセキュリティ更新プログラムを適用します。