在新虚拟机（VM-VM）上升级 Apstra（推荐） |Apstra 4.2 |瞻博网络

第 1 步：升级前验证

请参阅升级路径以确认您要升级到受支持的版本。（您可以通过在 Apstra GUI 中导航至平台> 关于，找到当前的 Apstra 版本。从 Apstra 4.2.1 版开始，Apstra 版本也会显示在 GUI 左侧导航菜单中的 Juniper Apstra 徽标下方。）
以管理员身份登录到 Apstra 服务器（例如，如果您的 Apstra 服务器 IP 地址为 10.28.105.3，则命令为 ssh admin@10.28.105.3）。

运行命令service aos status以检查服务器是否处于活动状态并且没有问题。

查看 Apstra 新版本发行说明，了解可能影响数据平面的配置渲染更改。
查看每个蓝图，确认所有服务配置都处于“成功”状态。如有必要，请从蓝图中取消部署并移除设备，以解决任何挂起或失败的服务配置。
查看每个蓝图以查找探针异常，并尽可能解决它们。记下任何剩余的异常情况。
请参阅 Apstra 用户指南（参考>设备>合格设备和 NOS 版本），验证设备型号和 NOS 版本是否适用于新的 Apstra 版本。根据需要升级或降级到受支持的某个版本。（从 Apstra 4.2.0 版开始，Apstra 弃用 EX4300。从 Apstra 4.2.1 版开始，如果活动蓝图中存在 EX4300，则升级将被阻止。）
如果您使用的是 Junos 设备并升级到 Apstra 4.2.1 版，则原始配置必须包含必要的mgmt_junosVRF。有关详细信息瞻博网络请参阅支持知识库文章KB77094。

注意：

如果原始配置不包含 mgmt_junos VRF，则部署将失败。
移除所有设备 AAA 配置。在设备升级期间，需要配置的设备代理凭据才能进行 SSH 访问。
移除用于配置防火墙的所有 Configlet。如果在设备上使用 FW 的路由引擎筛选器，则需要更新它们以包含新控制器和辅助角色 VM 的 IP 地址。
要升级设备系统代理，Apstra 必须能够使用创建代理时配置的凭据通过 SSH 连接到所有设备。要从 Apstra GUI 中检查此项，请导航到设备>托管设备，选中要检查的设备的复选框，然后单击代理菜单中的检查按钮。验证所有作业的状态是否为 SUCCESS。如果任何检查作业失败，请先解决问题，然后再继续升级 Apstra。
以 root 用户身份运行命令sudo aos_backup以备份 Apstra 服务器。
注意：

升级后的 Apstra 服务器不包含任何 Time Voyager 版本，因此如果您需要恢复到过去的状态，则需要进行此备份。由于与参考设计的紧密耦合，因此不包括之前的状态，并且在 Apstra 版本之间可能会发生变化。
将备份文件从 /var/lib/aos/snapshot/<shapshot_name> 外部位置复制。
确保新虚拟机具有 Apstra 服务器所需的服务器资源。

第 2 步：部署新的 Apstra 服务器

注意：

如果您在旧 Apstra 服务器中自定义 /etc/aos/aos.conf 了该文件（例如，如果将字段更新为 metadb 使用其他网络接口），则必须将更改重新应用到新 Apstra 服务器虚拟机中的同一文件。它不会自动迁移。

作为支持的注册用户，请从瞻博网络支持下载（for example, aos_server_4.1.2-269）下载 Apstra 虚拟机映像并将其传输到新的 Apstra 服务器。
使用新的 IP 地址安装并配置新的 Apstra 虚拟机映像（可使用相同 FQDN 或新的 FQDN）。
如果您使用的是 Apstra 群集（异机代理、IBA 探针），并且要重用工作虚拟机，请通过运行sudo bash aos_<aos_version>.run安装新软件。如果使用的是新的辅助角色 VM，请跳过此步骤。

注意：
更换所有虚拟机的示例：如果您有一个控制器和 2 个工作节点，并且希望将它们全部升级到新虚拟机，则需要使用新的 Apstra 版本创建 3 个虚拟机，并将其中一个指定为控制器。
验证新 Apstra 服务器是否具有对旧 Apstra 服务器的 SSH 访问权限。
验证新的 Apstra 服务器是否可以访问系统代理。（请参阅所需的通信端口。）
验证新的 Apstra 服务器是否可以访问适用的外部系统（如 NTP、DNS、vSphere 服务器、LDAP/TACACs+ 服务器等）。

第 3 步：导入状态

注意：

如果在开始导入新虚拟机后，对旧 Apstra 服务器执行任何 API/GUI 写入操作，则这些更改将不会复制到新 Apstra 服务器。

以用户 管理员身份登录到新的 Apstra 服务器。
运行命令sudo aos_import_state以从旧服务器导入 SysDB，应用必要的转换并导入配置。包括以下参数（如果适用）：
- --ip-address <old-apstra-server-ip>
- --username <admin-username>
- 对于具有新工作节点 IP 地址的 Apstra 群集，请包括以下内容： --cluster-node-address-mapping <old-node-ip> <new-node-ip>
- 要在不运行实际升级的情况下运行升级前置条件检查，请使用以下命令：--dry-run-connectivity-validation
- 要不检查连接验证，请包括以下内容： --skip-connectivity-validation
- 如果旧 Apstra 版本上的 SSH 凭据不如新 Apstra 版本的要求那么严格，则在将数据库导入新 Apstra 版本时，您需要将参数添加到 --override-cluster-node-credentials 命令中 aos_import_state 。否则，升级将失败。
示例命令：具有相同工作节点的单个虚拟机或 Apstra 群集
示例命令：具有新工作节点的 Apstra 群集
在上面的示例中， 10.28.105.4 是 10.28.105.7 旧工作节点 IP 地址; 10.28.105.6 10.28.105.8 是新工作节点 IP 地址。
导入数据库需要 Root，因此系统会要求您提供远程 Apstra 虚拟机的 SSH 密码和 root 密码。

注意：
升级 Apstra 群集时，旧控制器、旧 Worker 和新 Worker 的 SSH 密码必须相同，否则升级身份验证失败。在上面的示例中，您为“远程 AOS 虚拟机的 SSH 密码”输入的密码用于远程控制器、旧工作人员虚拟机和新工作人员虚拟机。（AOS-27351）

如果您在升级后更改了 Worker 虚拟机的 SSH 密码，则还需要在 Apstra GUI（Platform > Apstra Cluster > Nodes）中更新 Worker 的密码。

注意：
蓝图的大小和 Apstra 服务器虚拟机资源决定了完成导入所需的时间。如果数据库导入超过默认值，则操作可能会“超时”。（Apstra 4.1.2 的默认值为 40 分钟或 2400 秒）。如果发生这种情况，您可以使用命令增加超时值 AOS_UPGRADE_DOCKER_EXEC_TIMEOUT 。

例如，以下命令将超时前的时间增加到 2 小时（7200 秒）。
admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

升级脚本提供交换矩阵中将在升级期间接收配置更改的设备的摘要视图。从 Apstra 版本 4.1.2 开始，屏幕上会出现一条警告，建议您在继续操作之前阅读发行说明和升级路径文档。从 Apstra 4.1.2 版开始，发行说明包括 配置呈现更改类别。顶部会清楚地记录配置渲染更改，说明每次更改对网络的影响。
从 Apstra 4.0.1 版开始， Apstra 升级摘要 显示按设备角色（例如超级主干、主干、叶、叶对和接入交换机）分隔的信息。如果应用了增量配置而不是完整配置，则会显示有关更改的更多详细信息。
查看摘要后，进入q以退出摘要。此时将显示 AOS 升级：交互式菜单，您可以在其中查看每台设备上的确切配置更改。如果您使用的是 Configlet，请验证升级推送的新配置是否不会与任何现有 Configlet 冲突。
注意：

新 Apstra 版本中的 Apstra 参考设计可能已更改，导致 Configlet 无效。为避免意外结果，请验证您的 configlet 是否与新呈现的配置冲突。如果需要更新 configlet，请退出升级，更新 configlet，然后再次运行升级。
如果想要在查看挂起的更改后继续升级，请输入 c。
如果要停止升级，请输入以q中止该过程。如果您此时退出并稍后决定升级，则必须从头开始该过程。

注意：
如果 Apstra 升级失败（或出现其他故障），您可以正常关闭新 Apstra 服务器，然后重新启动旧 Apstra 服务器以继续操作。

步骤 4：保留旧虚拟机的 IP 地址（可选）

如果要保留旧虚拟机的 IP 地址，则必须先执行以下额外步骤，然后才能更改操作模式并升级设备的代理。

关闭旧 VM 或将其 IP 地址更改为其他地址以释放 IP 地址。这是避免任何重复 IP 地址问题所必需的。
从 CLI 转至新虚拟机的 Apstra 交互式菜单。
单击网络以更新 IP 地址并确认其他参数。
要使新 IP 地址生效，请在退出之前从同一菜单重新启动网络服务，或者在退出菜单后从 CLI 重新启动网络服务。

第 5 步：将操作模式更改为正常

启动 Apstra 服务器升级时，操作模式会自动从正常更改为维护。维护模式可防止任何异机代理过早联机。不会推送任何配置，也不会拉取任何遥测数据。此时，如果您决定继续使用之前的 Apstra 版本而不进行升级，则可以关闭新的 Apstra 服务器。如果您决定完成升级，请将模式更改回正常。

登录 Apstra GUI。
如果想要查看挂起的服务配置更改，请导航到蓝图的仪表板，然后单击挂起以查看受影响的设备。
从左侧导航菜单中，导航到 Platform > Apstra 群集>群集管理。
单击“更改操作模式”按钮，选择“正常”，然后单击“更新”。任何异机代理，无论是位于控制器虚拟机还是工作虚拟机上，都会自动联机并重新连接设备，并推送任何待处理的配置更改。片刻之后，仪表板上的临时异常将得到解决，服务配置部分显示操作已成功。

您还可以从任何页面的左下角访问 集群管理 页面。您还可以从这里获得基于颜色的持续平台运行状况可见性。

在左侧导航菜单的底部，单击其中一个点，然后单击操作模式以转到 集群管理。单击“ 更改操作模式 ”按钮，选择 “正常”，然后单击 “更新”。

第 6 步：升级自机代理

Apstra 服务器和自机代理必须运行相同的 Apstra 版本。如果版本不同，代理将不会连接到 Apstra 服务器。

如果您运行的是多状态蓝图，尤其是 5 阶段蓝图，我们建议您分阶段升级代理：首先升级超级主干，然后升级主干，然后升级分叶。出于路径搜索，建议按此顺序排列。路由可以暂时从一个主干向下向下到另一个叶，然后返回到另一个主干，而不是将所有内容路由到一个主干，或从一个主干路由到一个超级主干。为了尽量减少发生这种情况的机会，我们建议分阶段升级设备。

以用户 管理员身份登录到 Apstra GUI。
从左侧导航菜单中，导航到设备>托管设备，然后选中要升级的设备的复选框（一次最多 100 台设备）。您可以同时升级多个本机代理，但设备升级的顺序很重要。
- 首先升级超级主干的代理。
- 其次是升级主干代理
- 第三个是叶的升级代理。
当您选择一个或多个设备时， “设备 ”和“代理”菜单将显示在表格上方。
单击“安装”按钮以启动安装过程。

作业状态更改为 IN PROGRESS。如果代理使用的是 Apstra 软件的早期版本，则会自动升级到新版本。然后连接到服务器，并将任何挂起的配置更改推送到设备。遥测也将恢复，作业状态将变为 SUCCESS。
在蓝图仪表板的 Liveness 部分中，确认没有设备异常。

注意：
如果您在启动代理升级后需要回滚到以前的 Apstra 版本，则必须使用以前的 Apstra 版本构建新的虚拟机，并将配置还原到该虚拟机。如需帮助，请联系瞻博网络技术支持。

第 7 步：关闭旧的 Apstra 服务器

根据您的配置更新所有 DNS 条目，以使用新的 Apstra 服务器 IP/FQDN。
如果您为 Apstra 服务器使用代理，请确保它指向新的 Apstra 服务器。
正常关闭旧的 Apstra 服务器。从 Apstra 4.2.1 版开始，系统会询问您是否要关闭旧的 Apstra 服务器;如果您的回答为“是”，则会自动运行命令service aos stop以为您关闭旧的 Apstra 服务器。
如果您要升级 Apstra 群集，并用新的虚拟机替换了工作节点，请同时关闭旧的工作器虚拟机。

后续举措：

如果您的设备的 NOS 版本在新的 Apstra 版本上不合格，请将其升级到合格版本。（有关详细信息，请参阅 Juniper Apstra 用户指南。）

本页内容

在新虚拟机 （VM-VM） 上升级 Apstra（推荐）