Cumulus Linux 升级怎么做：配置备份、兼容检查与回滚

Cumulus Linux 升级不只是替换一个系统镜像。交换机硬件、端口模式、模块、配置模型、路由、自动化、监控和相邻设备都可能受版本变化影响；没有可验证回滚的升级，不适合直接在整套 AI 网络展开。

维护前应明确升级目标和要解决的问题。只因为存在新版本就安排生产升级，会增加变量却没有可衡量收益，版本选择应依据硬件支持、安全、缺陷和功能需求。

建立硬件与软件兼容清单

列出交换机型号、ASIC、引导组件、当前与目标版本、端口模式、模块/DAC/AOC 和管理工具，核对目标版本支持。高端口速率和分拆功能需重点确认。

自动化脚本、API、NetQ 或第三方监控也要检查版本。交换机可启动不代表周边工具仍能正常管理。

备份配置还要备份运行状态

保存受控配置、接口与端口模式、路由邻居、路由表、MLAG/EVPN 状态、ACL、AAA、NTP、日志和模块信息。只有配置文件无法证明升级后运行状态一致。

备份要能够在隔离设备上恢复，确认权限与密钥获取路径。临时保存在交换机本地的备份不能覆盖设备启动失败。

先升级可隔离的代表设备

选择业务影响可控、同时覆盖目标硬件和功能的交换机，排空或迁移流量后升级。Leaf 与 Spine 的版本共存范围按官方资料和实验验证确定。

一次只改变系统版本，避免同时调整 BGP、ECMP、PFC/ECN 和线缆。否则异常时无法区分原因。

回归从物理端口到业务

检查端口与模块、FEC/错误、路由邻居、ECMP、MTU、QoS、PFC/ECN、遥测和管理访问，再运行 RDMA、NCCL 或代表性业务。

与升级前基线比较最低节点、尾部表现和错误趋势，不只看控制面邻居恢复。长稳观察覆盖目标负载和温度。

预先定义回滚触发条件

明确端口异常、路由不稳定、自动化失败、业务性能下降或安全问题达到什么程度立即回滚，谁有决策权限。不要在维护窗口临近结束时临时讨论。

回滚后重新验证配置和业务，确认失败升级没有留下端口或数据库状态。保留日志与时间线，修正验证项后再安排下一次。

分批升级防止版本漂移

升级周期跨多个维护窗口时，资产系统标记已升级、待升级和回滚设备，自动化根据状态使用对应模板。临时跳过的设备要有原因和下一次窗口。

混合版本期间持续验证邻接、端口与管理兼容，并设置最长共存时间。长期漂移会让故障处理和配置审查同时维护多套假设。