Junos 节点切片升级
Junos 节点切片升级涉及升级瞻博网络设备管理器 (JDM)、访客网络功能 (GNF) 和基本系统 (BSYS)。
升级 Junos 节点切片
Junos 节点切片包含三种类型的软件组件:
-
瞻博网络设备管理器 (JDM) 软件包
-
访客网络功能 (GNF) 的 Junos OS 映像
-
适用于基本系统 (BSYS) 的 Junos OS 软件包
您可以单独升级其中每个组件,只要它们在允许的软件版本范围内(有关详细信息,请参阅 多版本软件互操作性概述 )。您也可以一起升级所有这些。
-
在开始升级过程之前,请保存 JDM、GNF VM 和 BSYS 配置以供参考。
-
如果要在线卡上运行 BIOS 升级,则必须通过禁用 Junos 节点切片配置来确保路由器处于独立模式。
- 升级外部服务器模型的 JDM
- 升级 JDM 以支持基于 Podman 的部署 (23.2R1)
- 升级机箱内型号的 JDM
- 升级 GNF 和 BSYS
- 升级 JDM 以支持基于 WRL 9 的虚拟机主机 - 机箱内型号
升级外部服务器模型的 JDM
-
通过在两台服务器上执行以下任务来升级 JDM:
-
将新的 JDM 包(RPM 或 Ubuntu)复制到主机上的目录(例如 /var/tmp)。
-
使用以下命令停止 JDM:
root@Linux server0#
jdm stop
Stopping JDM -
发出升级命令以升级 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 服务器后,必须先运行,
commit synchronize
然后再配置任何新的 GNF。commit synchronize
如果不在服务器 1 上运行和创建新的 GNF,commit synchronize
则以后将无法从服务器 0 到服务器 1。 -
您必须升级这两个 JDM。
另请参阅:
-
-
升级 JDM 以支持基于 Podman 的部署 (23.2R1)
从 Junos OS 23.2R1 版开始,基于外部服务器的 Junos 节点切片支持使用 Pod Manager 工具 (podman) 部署瞻博网络设备管理器 (JDM)。只有运行红帽®企业 Linux® (RHEL) 9 或更高版本的服务器支持 podman。
在 23.2R1 之前的 Junos 版本中,基于外部服务器的 Junos 节点切片支持 RHEL 7.3,RHEL 7.3 提供了 libvirt 的 lxc 驱动程序 (libvirt-lxc) 来部署 JDM。
如果需要在 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 节点切片。
-
将主机操作系统升级到 RHEL 9。
-
安装基于 podman 的 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 的版本升级到基于 podman 的版本之前,您无法备份 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 映像无法启动的极少数情况下非常有用。例如,如果您突然终止了之前add-image
正在进行的清理,也可以使用该force
选项执行清理,方法是按 Ctrl-C(示例:request virtual-network-functions vnf-name delete-image image-name force
)。
升级 JDM 以支持基于 WRL 9 的虚拟机主机 - 机箱内型号
如果路由引擎要运行 Junos OS 19.3R1 或更高版本,则必须将 JDM 升级到 19.3R1 或更高版本。
19.3R1 之前发布的 Junos OS 版本使用 WRL6 版本的虚拟机主机软件。Junos OS 19.3R1 引入了 WRL9 版本的 VM Host 软件。要检查虚拟机主机版本,请在 BSYS 虚拟机上使用 Junos CLI 命令 show vmhost version
。
使用以下步骤升级 JDM。
-
在每个 GNF 上,为路由引擎 1 (re1) 上运行的备份 GNF 分配主要角色。
root@router>
request chassis routing-engine master switch no-confirm
-
在 re0 上,首先从 JDM 停止 GNF,然后从 BSY 停止 JDM 本身。
root@jdm>
request virtual-network-functions stop gnf-name
root@router>request vmhost jdm stop
-
确保 re0 虚拟机主机版本为 Junos OS 19.3R1 或更高版本。要检查虚拟机主机版本,请使用 Junos CLI 命令
show vmhost version
。您可以使用以下 Junos CLI 升级虚拟机主机软件:
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。
-
request server authenticate-peer-server
在两个路由引擎上的 JDM 上运行命令。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 以及 Junos OS 19.3R1 之前的版本中运行。
参见
降级外部服务器模型的 JDM
您无法降级安装在基于单服务器的 Junos 节点切片设置中的瞻博网络设备管理器 (JDM)。
使用以下步骤降级 JDM:
降级机箱内型号的 JDM
您无法降级安装在单个基于路由引擎的 Junos 节点切片设置中的瞻博网络设备管理器 (JDM)。
使用以下步骤降级 JDM:
现在,JDM 已搭载 Junos OS 版本 18.3R1。
统一 ISSU 支持
Junos 节点切片还支持统一不中断服务的软件升级 (ISSU),使您能够在两个不同的 Junos OS 版本之间进行升级,而不会中断控制平面,并将流量中断降至最低。您可以分别对 BSYS 和 GNF 执行统一的 ISSU。此外,您可以在每个 GNF 上独立运行统一的 ISSU,而不会影响其他 GNF。另 请参阅了解统一 ISSU 流程。
-
多版本软件支持限制(如版本偏差限制)也适用于统一 ISSU 升级。
- 从 Junos OS 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
的详细信息。有关更多详细信息,请参阅 查看软件版本之间的不兼容性。
警报仅显示在 GNF 上,即使在 BSY 上执行升级也是如此。可能会发生以下类型的警报:
系统与 BSY 不兼容 — 这是一个主要警报。当 BSYS 和 GNF 软件版本之间的任何不兼容性导致 GNF 脱机时,就会出现这种情况。
功能与 BSY 不兼容 - 这是一个次要警报。它表明 BSYS 和 GNF 软件版本之间存在轻微的不兼容。这不会导致 GNF 脱机。
查看软件版本之间的不兼容性
要从 BSYS 查看软件不兼容性,请使用 CLI,如以下示例所示:
user@router> show system anomalies gnf-id 4 system
要查看 GNF 中的软件不兼容性,请使用 CLI,如以下示例所示:
user@router> show system anomalies system
如 CLI 中所示,请记住在查看 BSY 中的不兼容性时指定 GNF ID。
前面的示例显示了系统级的不兼容性。使用 或
fru
config
选项可查看 FRU 或功能级别的不兼容性。
重新启动外部服务器
硬件或主机操作系统升级和故障隔离等服务器维护活动可能需要重新启动 Junos 节点切片中使用的外部服务器。请按下列步骤重新启动服务器:
服务器重新启动后,JDM 和配置的 GNF 将自动开始运行。
如果要更换服务器,请确保操作服务器对继续具有相似或相同的硬件配置。如果在更换期间服务器对暂时变得不同(按顺序更换服务器时可能出现这种情况),建议您在此期间禁用 GRES 和 NSR,并仅在两台服务器再次相似时才重新启用它们。
更新外部服务器上的主机操作系统
在更新外部服务器上的主机操作系统之前,必须先停止该服务器上的 GNF 和 JDM ,如重新启动外部服务器中所述。
主机操作系统更新后,如果您使用的是英特尔 X710 NIC,请确保正在使用的 X710 NIC 驱动程序的版本仍然是最新版本,如 更新 x86 服务器的英特尔 X710 NIC 驱动程序 中所述。
将安全更新应用于主机操作系统
主机操作系统需要不时进行安全更新。本节重点介绍使用红帽 (RHEL) 操作系统将安全更新应用于主机操作系统所涉及的步骤。
Junos 节点切片支持 RHEL 7.3。
在对主机操作系统进行任何更新之前,请确保红帽订阅管理器设置为版本 7.3,并且红帽订阅服务包括扩展更新支持 (EUS)。
您可以使用命令 subscription-manager release --show
确认版本设置为 7.3。如果不是,则可以使用命令 subscription-manager release --set=7.3
将版本设置为 7.3。
您必须确保将红帽订阅管理器设置为版本 7.3。否则,对 RHEL 的更新将尝试升级到最新的次要版本。例如,RHEL 7.3 可以通过常规 yum
更新变为 RHEL 7.4(或更高版本),或者 yum
安全更新可以引入 RHEL 7.3 之外的新内核。
红帽的扩展更新支持允许在指定版本中应用补丁和安全更新。允许使用 RHEL 的扩展更新支持是 RHEL 支持合同的一项功能,超出了本节的范围。您可以使用命令 subscription-manager repos --list | grep rhel-7-server-eus-rpms
检查您的 RHEL 订购是否包含扩展更新支持 (EUS)。默认情况下不启用 EUS 支持。可以使用命令 subscription-manager repos --enable rhel-7-server-eus-rpms
启用 EUS。
应用主机操作系统安全更新的步骤
将安全更新应用于主机操作系统可能需要重新启动外部 x86 服务器。请参阅 更新外部服务器上的主机操作系统 主题。
主机操作系统安全更新也可能引入新的内核版本。更新主机操作系统内核也可能覆盖英特尔 i40e 驱动程序,以引入不符合 i40e 驱动程序最低版本要求的版本。如果是这样,则必须更新 i40e 驱动程序以满足最低要求。有关更多详细信息,请参阅 更新 x86 服务器的英特尔 X710 NIC 驱动程序。
在重新启动外部 x86 服务器之前,必须停止该服务器上的所有 GNF 虚拟机和 JDM。由于我们有两台外部 x86 服务器,因此可以通过一次更新一台服务器来完成主机操作系统安全更新,而不会中断 GNF 转发。需要 GRES/NSR 主路由引擎切换才能将主路由引擎移离受影响的服务器。
我们从路由引擎 1 (re1
) 的默认行为开始,作为每个 GNF 的备份路由引擎, re1
其中每个 GNF 都在外部 x86 服务器上运行1。
备份所有配置。
在主机操作系统安全更新之前,收集外部 x86 服务器上主机操作系统内核和包版本的视图。还要确认 i40e 驱动程序和英特尔 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。备份路由引擎已re1
打开server1
。首先在包含备份路由引擎的服务器上执行主机操作系统安全更新。user@router>
show chassis routing-engine
在所有 GNF 上运行此命令,以确认所有 GNF 在 server0 上都有其主路由引擎。
仅通过打开请求
stop
server1
停止 JDM CLI 中的所有 GNF 虚拟机。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
从主机操作系统停止受影响服务器上的 JDM。
user@server#
jdm status
user@server#jdm stop
执行
yum
安全更新并重新启动服务器。user@server#
yum -y update -security
root@server#shutdown -r now
重新加载或编译 i40e 驱动程序。有关更新驱动程序的说明,请参阅 英特尔支持页面 。
此时,主机
server1
操作系统安全更新已完成。请注意,GNF 虚拟机在服务器重新启动时启动。安全更新完成后,服务器重新启动并备份 GNF,在另一台服务器上重复此操作。
为 Ubuntu 容器应用安全补丁
瞻博网络设备管理器 (JDM) 所基于的 Ubuntu 容器需要不时应用安全补丁。
JDM 必须能够访问互联网并且必须已 name-server
配置。应用以下 JDM CLI 配置语句以指定 name-server
:
root@jdm# set system name-server address
使用以下步骤将安全更新应用于 JDM 的 Ubuntu 容器组件: