Junos 节点切片升级
Junos 节点切片升级涉及升级瞻博网络设备管理器 (JDM)、访客网络功能 (GNF) 和基本系统 (BSYS)。
升级 Junos 节点切片
Junos 节点切片由三种类型的软件组件组成:
-
瞻博网络设备管理器 (JDM) 包
-
用于访客网络功能 (GNF) 的 Junos OS 映像
-
适用于基本系统 (BSYS) 的 Junos OS 软件包
您可以单独升级其中每个组件,只要它们在允许的软件版本范围内即可(有关更多详细信息,请参阅 多版本软件互操作性概述 )。您也可以将它们一起升级。
-
开始升级流程之前,请保存 JDM、GNF VM 和 BSYS 配置以供参考。
-
如果要在线卡上运行 BIOS 升级,则必须禁用 Junos 节点切片配置,从而确保路由器处于独立模式。
- 升级 JDM for External Server 模型
- 升级 JDM 以支持基于 Podman 的部署 (23.2R1)
- 升级机箱内模型的 JDM
- 升级 GNF 和 BSYS
- 升级 JDM 以支持基于 WRL 9 的虚拟机主机 - 机箱内模型
升级 JDM for External Server 模型
-
通过在两台服务器上执行以下任务来升级 JDM:
-
将新的 JDM 包(RPM 或 Ubuntu)复制到主机上的目录(例如 /var/tmp)。
-
使用以下命令停止 JDM:
root@Linux server0#
jdm stopStopping 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。如果不在 server1 上运行commit synchronize和创建新的 GNF,则以后将无法从 server0 到 server1 执行此操作commit synchronize。 -
您必须同时升级两个 JDM。
另请参阅:
-
-
升级 JDM 以支持基于 Podman 的部署 (23.2R1)
从 Junos OS 23.2R1 版开始,基于外部服务器的 Junos 节点切片支持使用 Pod 管理器工具 (podman) 部署瞻博网络设备管理器 (JDM)。只有运行 Red Hat® Enterprise Linux® (RHEL) 9 或更高版本的服务器支持 podman。
在 23.2R1 之前的 Junos 版本中,基于外部服务器的 Junos 节点切片支持 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.tgzBackup Done at:[/host/tmp/jdm-backup.tgz]此步骤将备份 JDM 配置和 random-mac-prefix 值。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.tgzBackup 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 映像无法启动的极少数情况下非常有用。例如,如果按 Ctrl-C 突然终止正在进行的较早add-image操作,也可以使用该force选项执行清理(示例: 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 版本的虚拟机主机软件。要检查虚拟机主机版本,请在 BSYS 虚拟机上使用 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-nameroot@router>request vmhost jdm stop -
确保 re0 虚拟机主机版本为 Junos OS 19.3R1 或更高版本。要检查虚拟机主机版本,请使用 Junos CLI 命令
show vmhost version。您可以使用以下 Junos CLI 升级虚拟机主机软件:
root@router>
request vmhost software add package-nameroot@router>request vmhost reboot有关详细信息,请参阅 VM 主机的安装、升级、备份和恢复。
-
重新启动后备份 re0 时,将新的 JDM RPM 软件包(19.3R1 或更高版本)复制到目录(例如 /var/tmp)。
-
在 re0 上安装新的 JDM RPM 包,然后启动 JDM。
root@router>
request vmhost jdm add package-nameroot@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 synchronizeuser@jdm#commit synchronize
JDM 软件版本 19.3R1 可在 Junos OS 版本 19.3R1 以及低于 19.3R1 的 Junos OS 版本上运行。
也可以看看
将 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 上,即使在 BSYS 上执行也是如此。可能会出现以下类型的告警:
系统与 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。
上述示例显示了系统级不兼容性。使用或
config选项fru查看 FRU 或特征级不兼容性。
重新启动外部服务器
硬件或主机操作系统升级和故障隔离等服务器维护活动可能需要您重新启动 Junos 节点切片中使用的外部服务器。使用以下过程重新启动服务器:
服务器重新启动后,JDM 和配置的 GNF 将自动开始运行。
如果要更换服务器,请确保操作服务器对继续具有类似或相同的硬件配置。如果服务器对在更换期间暂时变得不相似(按顺序更换服务器时可能出现这种情况),建议在此期间禁用 GRES 和 NSR,仅当两台服务器再次相似时才重新启用它们。
更新外部服务器上的主机操作系统
在更新外部服务器上的主机操作系统之前,必须先停止该服务器上的 GNF 和 JDM,如 重新启动外部服务器中所述。
主机操作系统更新后,如果您使用的是英特尔 X710 NIC,请确保正在使用的 X710 NIC 驱动程序版本仍然是最新版本,如 更新适用于 x86 服务器的英特尔 X710 NIC 驱动程序 中所述。
将安全性更新应用到主机操作系统
主机操作系统需要不时进行安全更新。本节重点介绍使用 Red Hat (RHEL) OS 将安全性更新应用到主机操作系统所涉及的步骤。
Junos 节点切片支持 RHEL 7.3。
在对主机操作系统进行任何更新之前,请确保 Red Hat 订阅管理器设置为版本 7.3,并且 Red Hat 订阅服务包括扩展更新支持 (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 支持合同的一项功能,超出了本节的范围。您可以使用命令 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-releaseuser@server#uname -ruser@server#uname -auser@server#rpm -q kerneluser@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 都在 上使用主 RE
server0。备份路由引擎已re1打开server1。首先在包含备份路由引擎的服务器上执行主机操作系统安全更新。user@router>
show chassis routing-engine在所有 GNF 上运行此命令,以确认所有 GNF 在 server0 上都有其主路由引擎。
仅通过请求
stop在server1JDM CLI 中停止所有 GNF 虚拟机。server1包含所有 GNF 的备份路由引擎。请勿使用该all-servers选项。示例:user@jdm>
request virtual-network-functions gnf-a stop server 1user@jdm>request virtual-network-functions gnf-b stop server 1从主机操作系统停止受影响服务器上的 JDM。
user@server#
jdm statususer@server#jdm stop进行
yum安全更新并重新启动服务器。user@server#
yum -y update -securityroot@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 容器组件: