2. vSphere版本与发布模型
在vSphere运维中，最容易引发误判的问题之一，是把“版本号变化”直接等同于“需要大升级”，或者把“打了补丁”误认为“版本已经升级”。要治理生命周期，先要建立一套稳定的版本语言：哪些数字代表主版本，哪些代表补丁，哪些只是构建号；Update和Upgrade在变更对象、风险、回退路径上有什么本质区别；以及Broadcom/VMware的发布节奏与支持周期如何影响升级窗口。
一、vSphere各组件的版本号规则
vSphere不是单一产品，而是一组组件的集合：ESXi、vCenter Server、vSphere Client、vSAN、NSX、Aria Operations等。它们各自有独立版本号，但通过兼容性矩阵绑定在一起。以ESXi为例，常见版本形态如 8.0 Update 3b、7.0 Update 3o、6.7 EP 25。这里需要拆开看：
- 主版本（Major）：如6.7、7.0、8.0，代表一代平台，通常伴随架构、API、驱动模型或硬件支持的重大变化。
- Update（更新包）：如Update 1、Update 2、Update 3，是同一主版本内的功能与修复集合，可能包含新特性、驱动更新和安全修复。
- Express Patch / Patch（补丁）：如EP 25、Patch 05，通常只做缺陷修复和安全修补，不引入新功能。
- Build号：如
21930508，是唯一标识某个具体构建的数字，用于精确比对补丁级别。
因此，判断“是否同一版本”，不能只看8.0，而要看 8.0 Update 3b Build 21930508 这样的完整标识。vCenter的版本号规则类似，但它的Update往往与ESXi的Update并不同步发布，例如vCenter 8.0 Update 2可能早于ESXi 8.0 Update 2可用。运维中必须分别记录各组件版本，并以兼容性矩阵为准，而不是“统一升到8.0”就认为一致。
二、Update与Upgrade的本质区别
Update和Upgrade在中文里都常被翻译为“升级”，但在vSphere语境中，它们对应完全不同的变更类型：
| 维度 | Update / Patch | Upgrade |
|---|---|---|
| 版本跨度 | 同一主版本内，如8.0 U2 → 8.0 U3 | 跨主版本，如7.0 U3 → 8.0 U3 |
| 典型工具 | vSphere Lifecycle Manager、ESXCLI、离线包 | vCenter Upgrade、ESXi升级向导、VLM升级基线 |
| 是否可回退 | 通常可通过快照或回滚补丁回退 | 回退复杂，需备份与回滚方案，部分场景不可逆 |
| 风险等级 | 中低，影响单主机或单组件 | 高，涉及兼容性、驱动、插件、证书、网络 |
| 停机影响 | 可滚动维护，配合vMotion可接近零停机 | vCenter需停机窗口，ESXi需逐台维护 |
实际判断时，可以抓住一个核心问题：变更后主版本号是否改变。如果从7.0变为8.0，就是Upgrade；如果仍是8.0，只是从U2到U3，就是Update。这个判断直接决定变更审批级别、回退方案和停机窗口。
三、发布节奏与支持周期
vSphere的发布节奏通常遵循“主版本约每2～3年一次，Update约每6～12个月一次，Patch/EP按需发布”的规律。以7.0和8.0为例，7.0于2020年发布，8.0于2022年发布，中间经历了多个Update。每个主版本有明确的支持阶段：
- General Support（常规支持）：通常为主版本发布后约5年，期间提供补丁、安全修复和部分功能更新。
- Technical Guidance（技术指导）：常规支持结束后进入，通常再延续约2年，不再提供常规补丁，仅提供有限指导。
- End of General Support（EOGS）：常规支持终止日期，之后不再发布安全补丁。
- End of Technical Guidance（EOTG）：技术指导终止，产品进入EOL，不再获得任何官方支持。
例如，vSphere 7.0的EOGS为2025年4月2日，EOTG为2027年4月2日；vSphere 8.0的EOGS为2027年10月11日，EOTG为2029年10月11日。这些日期是规划升级窗口的硬约束：一旦接近EOGS，继续运行将面临无安全补丁、硬件兼容性下降、第三方插件不再认证等风险。
四、EOL策略与升级窗口规划
EOL（End of Life）不是某一天突然发生的，而是一个渐进过程。以7.0为例，2025年4月2日EOGS之后，虽然系统仍能运行，但会出现三个实际后果：第一，新的安全漏洞不再有官方补丁，CVE修复需自行承担；第二，新硬件（如新一代CPU、网卡、存储控制器）不再被认证，可能导致无法采购或无法识别；第三，第三方备份、监控、安全插件可能在新版本中不再支持7.0，形成生态断裂。
因此，升级窗口应至少提前12～18个月规划。一个可参考的决策逻辑是：
- 确认当前各组件版本与Build号，对照兼容性矩阵。
- 查询目标版本的EOGS/EOTG日期，计算剩余支持时间。
- 若剩余常规支持不足12个月，启动Upgrade项目；若仅需补丁，则安排Update窗口。
- 评估硬件兼容性列表（HCL），确认服务器、存储、网卡是否支持目标版本。
- 在测试环境验证vCenter升级、ESXi升级、插件兼容性和备份恢复。
- 制定回退方案：vCenter快照、ESXi镜像回滚、备份还原点。
五、版本治理的日常动作
版本治理不是一次性项目，而是持续动作。建议每季度执行一次版本审计：导出所有ESXi主机的 esxcli system version get 输出，记录 Version、Update、Build；导出vCenter的版本与Build；对照Broadcom兼容性矩阵和生命周期表，标记出“已过EOGS”“6个月内将过EOGS”“当前推荐版本”三类状态。对于已过EOGS的主机，应列入优先升级清单；对于仍在常规支持期的主机，按Update节奏滚动补丁。
最后要强调：Update和Upgrade不是二选一，而是两条并行的治理线。Update保证同一主版本内的安全与稳定，Upgrade保证平台不落后于支持周期。只有把版本号规则、发布节奏、支持周期和EOL策略放在同一张时间轴上管理，vSphere生命周期治理才真正可执行。