3. 滚动升级与业务迁移的架构评估

滚动升级与业务迁移能否顺利落地，第一步不是动手改配置，而是把现有环境“看清楚”。架构评估的目标是回答四个问题：当前系统长什么样、哪些组件彼此依赖、业务能容忍多长的中断、一旦出问题影响面有多大。只有把这些问题量化，后续的升级批次、迁移顺序和回退策略才有依据。

一、现有拓扑：先画出真实的依赖关系

拓扑评估不能只看机柜图或资产清单，而要还原“业务请求从入口到落盘”的完整路径。以典型的 Lenovo ThinkSystem 三节点虚拟化集群为例，评估时应逐层记录：接入层（负载均衡/防火墙）、计算层（物理服务器型号、CPU 代际、内存、网卡）、虚拟化层（平台版本、集群规模、HA 策略）、存储层（SAN/NAS/分布式存储、LUN 与卷映射）、以及业务层（虚拟机与应用的对应关系）。

建议用一张“依赖矩阵”记录每个业务系统所依赖的物理主机、存储卷、网络 VLAN 和上游系统。例如某订单系统运行在 ESXi 集群的 VM-ORD-01 上，其数据库卷位于存储阵列的 LUN 12，通过 VLAN 210 与支付网关通信。这样的记录在升级时能直接回答“停掉这台主机，谁会受影响”。

二、虚拟化平台：版本兼容与集群约束

虚拟化平台是滚动升级的核心对象。评估时要确认三件事：平台版本是否支持目标升级路径、集群是否具备滚动维护的条件、以及 HA/DRS 策略是否会在维护模式下触发意外迁移。以 VMware vSphere 为例，若集群启用了 vSphere DRS 全自动模式，将主机置入维护模式时，DRS 会自动迁移虚拟机，这可能与业务迁移窗口冲突，因此评估阶段应明确是否临时切换为手动或半自动模式。

同时要核对硬件兼容性列表（HCL），确认服务器型号、网卡、HBA 卡在目标平台版本中仍受支持。若集群中存在不同代际的 CPU（如 Skylake 与 Cascade Lake 混用），还需确认 EVC 基线设置，避免迁移后虚拟机因 CPU 特性不匹配而无法启动。

三、存储与网络依赖：最容易被低估的风险点

存储依赖评估的重点是“多路径与卷映射”。滚动升级中，主机重启或 HBA 固件更新可能导致多路径短暂抖动，若存储未配置冗余路径，业务 I/O 会直接中断。评估时应确认：每台主机到存储阵列的路径数量、多路径软件状态、以及 LUN 的归属控制器。对于使用 Lenovo DE 系列存储的环境，还需确认固件版本与主机端驱动的兼容性。

网络依赖则要梳理 VLAN、链路聚合和上行链路冗余。升级交换机固件或调整端口配置时，若业务 VLAN 未做双上行，单链路中断即造成业务不可达。评估阶段应标记出所有单点链路，并确认其承载的业务是否允许中断。

四、业务 SLA 与风险等级划分

架构评估的最终产出是风险等级划分。建议按“业务中断容忍度”和“依赖复杂度”两个维度打分。中断容忍度可参考 SLA：RTO（恢复时间目标）小于 15 分钟的业务为高敏感，15 分钟至 2 小时为中敏感，2 小时以上为低敏感。依赖复杂度则看该业务是否跨多个主机、存储卷或网络区域。

将两个维度交叉后，可得到三级风险：高风险——单链路依赖且 RTO 极短，升级时必须安排业务停机窗口并准备回退；中风险——具备冗余但迁移过程需短暂切换，可安排在业务低峰期滚动执行；低风险——冗余完备、可在线迁移，适合作为首批升级对象以验证流程。

五、评估输出与后续衔接

完成上述评估后，应形成一份可执行的《架构评估与风险清单》，至少包含：拓扑依赖矩阵、平台版本与兼容性结论、存储/网络单点清单、业务 SLA 与风险等级、以及建议的升级批次顺序。这份清单将直接决定滚动升级的批次划分和业务迁移的先后顺序——低风险业务先行验证，高风险业务安排在最后并预留回退窗口。

需要强调的是，架构评估不是一次性动作。每次升级前都应重新核对固件版本、HCL 状态和业务分布，因为虚拟机的迁移、存储卷的调整或网络策略的变更都会改变原有的依赖关系。把评估做成可复用的清单和矩阵，才能让后续每一轮滚动升级都有据可依。