★ FEATURED ARTICLE 如果你管着的 vSphere 集群要扩容新服务器到货、ESXi 也已经装好了你是不是觉得只要把主机“添加到集群”就算完事我见过太多次在这个环节翻车的案例点完“添加到集群”vMotion 迁移不过去HA 功能缺失vSAN 后台持续告警运气差一点的虚拟机直接无法从旧节点迁到新节点。问题的根源几乎都一样——加入集群之前没做系统性的兼容性评估。这篇文章就把我做兼容性评估时重点看的维度、实际操作的步骤、以及这些年踩过的坑整理出来。不管你是刚接手虚拟化环境的运维新人还是管着几百台虚拟机、正打算扩容的老手只要碰到“往 vSphere 集群里加主机”这个动作都建议花十分钟把思路过一遍。1. 先搞清楚为什么要做兼容性评估1.1 一个真实扩容翻车场景说个我有实际经验的例子。某公司的机房里有三个节点的 vSphere 集群跑了几年版本是 6.7 U3节点用的还是上一代处理器平台。后来业务部门要扩容公司采购了两台当前主流平台的新服务器硬件厂商预装了同样版本的 ESXi。新主机加入集群这个动作本身很顺利但做 vMotion 验证的时候从旧节点往新节点迁移虚拟机直接报错提示主机 CPU 不兼容。现场同事一开始还以为是网络或者存储的配置问题查了半天日志最后才发现是两代 CPU 的特性集合差异太大集群又没开 EVC。最后只能申请停机窗口把虚拟机全部关机做冷迁移才勉强完成扩容。原本半小时的扩容操作硬生生拖了一天还搭上一个业务停机窗口。这种场景在我接触过的环境里并不少见。很多人把“主机能加进集群”等同于“兼容没问题”其实加入集群只是第一步后面能不能正常使用高级特性、能不能稳定运行完全取决于你加主机之前有没有把兼容性这关过好。1.2 不评估的话哪些风险会找上门兼容性评估防的不是“加不进去”而是加进去之后的一连串隐性故障。我把常见风险理了一下vMotion 迁移失败新旧主机 CPU 特性集合不一致虚拟机在开机状态下无法热迁移。HA 功能失效或降级节点之间的 agent 通信、心跳网络如果因驱动或网络配置差异出问题HA 就会变成摆设。DRS 自动迁移导致性能异常DRS 把虚拟机从新主机迁到旧主机或反过来如果 CPU 特性、NUMA 拓扑差异太大虚拟机性能会忽高忽低。vSAN 健康检查飘红新主机控制器驱动、磁盘固件不在 vSAN 支持列表里数据重平衡异常甚至数据访问报错。存储不可见或链路不稳定新主机的 HBA 没有做存储映射和分区加入集群后虚拟机根本无法启动。网络中断分布式交换机vDS的物理网卡映射不对、MTU 不一致主机加完直接“失联”。证书、时间同步告警这些看着是小问题但会严重影响后续运维和排障效率。这些风险有个共同特点它们在“加入集群”这个动作之后才暴露而且越晚发现处理成本越高。所以兼容性评估这件事不是可做可不做的加分项而是扩容前必须做的常规动作。2. 评估的核心维度硬件到软件逐项对齐2.1 CPU 型号与 EVC 模式最容易踩雷的一项CPU 兼容性是整个评估里优先级最高的一项。vMotion 之所以能热迁移虚拟机靠的是把虚拟机状态在主机之间传递而目标主机必须能够“理解”虚拟机当前运行所需的 CPU 指令集。如果两台主机的 CPU 特性集合不一致迁移就会被拒绝。解决这个问题的标准方案是开启 EVCEnhanced vMotion Compatibility增强型 vMotion 兼容性。EVC 的原理简单说就是给集群内的虚拟机套一个“特性罩子”把超出公共基线的 CPU 特性屏蔽掉让所有主机看起来像同一代 CPU。以 Intel 为例基线从老的 Penryn、Nehalem、Westmere到 Sandy Bridge、Ivy Bridge、Haswell、Broadwell、Skylake再到更新的平台一代一代往上加。选哪个基线取决于集群里最老的那台 CPU 支持到什么程度。这里有一条核心规则你一定要记住新加入的主机其 CPU 必须至少支持集群当前配置的 EVC 基线。如果新主机 CPU 太老达不到基线要求它加入集群后要么跑不了要么被迫把整个集群的 EVC 基线往下降——但降基线影响的是现有虚拟机的运行特性通常需要维护窗口操作成本非常高。所以我在评估时一定会确认两件事第一集群是否已开启 EVC第二新主机 CPU 支持的最高 EVC 基线是什么。如果集群还没开 EVC先别急着扩容把 EVC 基线的问题处理完再说。另外如果新旧主机不是同一代 CPU即使能迁移NUMA 拓扑和超线程配置也可能不同虚拟机迁移后的性能表现需要单独观察。2.2 内存、BIOS 与固件容易被忽略的基础一致性内存这块很多人只看容量够不够其实有几个细节必须注意。新主机的内存类型是否与旧主机一致RDIMM 和 LRDIMM 不能混用不同频率的内存混插会导致整机内存降频运行甚至无法开机。最好在采购时就要求内存条品牌、型号、规格与现网一致省得扩容后性能缩水还不容易排查。BIOS 设置的一致性也很重要。虚拟化相关的开关必须确认开启比如 VT-x、VT-d 这类硬件虚拟化特性。电源管理策略如果是新旧主机两种模式一台设成高性能、一台设成节能虚拟机会被 DRS 迁到不同主机上表现出的性能差异会让业务部门误以为虚拟机出问题了。更麻烦的是这种差异在日志里很难直接看出来排查成本很高。我在实践中会把所有主机的基础设置整理成一张基线表每次扩容前逐项核对省得以后踩坑。固件版本同样不能漏。服务器管理卡固件、RAID 阵列卡固件、NVMe 盘固件这些都需要对照厂商和 VMware 的兼容性列表确认。有些主机加进集群的时候没问题跑一段时间后 vSAN 健康检查报“控制器固件不在支持列表”或者高负载下磁盘控制器报错就是因为固件版本和驱动组合没有提前对齐。2.3 存储与 vSAN看不见的数据风险如果集群用的是传统共享存储SAN 或 NAS评估重点是新主机的 HBA 是否已经做好了存储映射。很多扩容事故其实不是兼容性问题而是存储工程师忘了把新主机 WWPN 加入存储阵列的映射组导致新主机加入集群后看不到任何 LUN虚拟机自然一个都起不来。多路径策略也要对齐。旧主机用的可能是轮询Round Robin策略新主机如果默认是固定路径Fixed或其他策略会导致新旧节点之间的存储负载不均衡甚至高 I/O 场景下出现路径切换报错。统一多路径策略之后再做一次大文件拷贝或者数据库备份任务来验证稳定性这一步别省。如果集群用的是 vSAN评估内容更多。新主机的磁盘控制器必须工作在直通模式passthrough或 RAID 0 模式控制器驱动和磁盘固件要在 vSAN 的兼容性列表内。加入 vSAN 集群前一定要用 vSphere Client 里的“vSAN 健康检查”功能做预检专门看“控制器驱动版本”和“磁盘固件版本”这两项。vSAN 支持混合版本滚动升级但新旧节点的 vSAN 版本差异不能太大否则数据重平衡和故障重建会出现各种奇怪问题。2.4 网络与物理交换机链路匹配是硬门槛网络是扩容时暴露问题最多的地方之一。首先要确认新主机网卡的品牌型号和驱动版本是否被当前 ESXi 版本支持。最典型的情况是新服务器配了新网卡但 ESXi 版本比较旧镜像里没有这个网卡的驱动装完系统可能连管理 IP 都配不上。遇到这种情况要么给 ESXi 打好离线补丁包offline bundle要么换兼容的新版本 ESXi 镜像千万别硬来。其次要检查的是物理交换机侧的配置。VLAN、MTU、链路聚合LACP这些参数新主机接入的物理交换机端口必须和旧主机的配置保持一致。如果集群开了巨型帧MTU 9000新主机网卡还留在默认的 1500vMotion 网络表现就会极其诡异迁移数据吞吐上不去偶尔还报超时。对于使用分布式交换机vDS的环境最关键的步骤是把新主机的物理网卡正确映射到 dvUplink 上。如果新主机物理网卡数量和旧主机不一致比如旧主机是 4 个 10G 口新主机只有 2 个 10G 口网卡绑定teaming的行为就不一样带宽和故障切换能力会有明显差异。这个问题在下面的实操章节会详细说。2.5 ESXi、vCenter 与证书版本基线要对齐新主机的 ESXi 版本和构建号必须落在 vCenter 版本支持的范围内。vCenter 版本太老管不了新版本的 ESXiESXi 版本太老vCenter 又不一定能下发新特性。所以扩容前第一件事就是把新主机的 ESXi 构建号和 vCenter 的兼容矩阵对一遍。版本一致性之外还有两个容易忽略的细节。一个是 License新增主机后集群总物理 CPU 数可能超过当前 License 允许的上限加完主机会出现 License 告警某些功能被锁定。另一个是证书如果 vCenter 使用私有 CA 签发的证书新主机的证书没有被 vCenter 信任添加主机时就会报证书验证失败。这些看着都是小问题但不提前处理往往就是卡住你的最后一根稻草。3. 照着做的评估流程四步走3.1 第一步用官方兼容列表圈定硬件边界评估的第一步不是跑命令而是查文档。把新服务器的型号和部件信息整理出来去 VMware 官方兼容性列表VCG/HCL里逐一核对服务器型号、CPU、内存、磁盘控制器、网卡、驱动版本、固件版本。同时还要看服务器厂商自己的支持矩阵以及存储厂商的互操作指南三方对上了才算稳。这一步看起来很基础但我强烈建议在采购阶段就让硬件厂商书面确认“该型号服务器及所选部件支持目标 vSphere 版本和 vSAN 版本”。我见过不少案例货到了现场才发现某个部件不在支持列表里临时换货等了两三周。书面确认虽然不能完全避免问题但至少让厂商有责任帮你把好第一关。如果硬件已经到货也没关系按型号去查列表查完把不满足的部件记下来能升级固件驱动的升级升级不了的考虑退货或者换型号。这个环节说白了就是把“隐藏的地雷”提前排掉。3.2 第二步用工具批量盘点现网主机配置确认完硬件边界下一步是盘点现网环境。如果你只管几台主机直接登录 vSphere Client 一台台看也行但如果集群节点多一定要用工具批量采集。我这里最常用的工具是 RVTools免费、稳定跑完能导出 vCenter 里几乎所有对象的配置信息包括主机版本、构建号、CPU 型号、内存、网卡、HBA、存储适配器等。用 PowerCLI 也可以一个简单脚本就能把几台核心主机的版本、CPU、内存信息导出成 CSV$cred Get-Credential Connect-VIServer -Server vcenter.example.local -Credential $cred Get-VMHost | Select-Object Name, Version, Build, ProcessorType, {NCores;E{$_.NumCpu}}, {NMemGB;E{[math]::Round($_.MemoryTotalGB,2)}} | Export-Csv -Path host.csv -NoTypeInformation拿到现网主机清单后和准备加入的新主机做逐项对比重点标记版本差异大的驱动和固件。现场单台主机排查时用下面这几条命令很顺手# 查看硬件平台信息 esxcli hardware platform get # 查看已安装的 VIB 驱动列表 esxcli software vib list # 查看物理网卡信息 esxcli network nic list # 查看存储设备和控制器信息 esxcli storage core device list对比之后把存在差异但不会导致问题的项比如驱动版本小版本号不同和必须修正的项比如关键控制器驱动不在列表内分开记录形成一张评估清单。3.3 第三步主机先以独立方式加入 vCenter 做预检很多人的习惯是把新主机直接拖进集群其实更稳妥的做法是先让新主机以独立主机standalone的身份加入 vCenter不到集群里。这一步的目的是让 vCenter 能管理新主机同时你又可以对它做各种预检而不会影响到现有集群。独立主机状态下要完成这几项预检配置好管理网络、DNS、NTP确认时间同步正常。如果使用共享存储确认新主机的 HBA 已经能看到所有需要的 LUN多路径策略和旧主机一致。如果是 vSAN 集群运行 vSAN 健康检查的预配置检查确认控制器驱动和磁盘固件都在支持列表里。查看主机事件和告警确认没有硬件健康问题。完成这些预检后建议让新主机以独立身份运行 24 小时再真正加入集群。这个观察期能帮你提前发现很多隐蔽问题比如驱动在负载下的异常日志、网卡的间歇性丢包、固件触发的硬件告警等。宁可多等一天也别在集群里折腾。3.4 第四步EVC 调整与迁移预演接下来确认集群的 EVC 状态。如果集群还没开启 EVC就需要在维护窗口内做一次 EVC 基线评估原则是选一个“最老主机 CPU 支持、新主机也支持”的基线。开启和调整 EVC 时有几个细节要特别注意集群里如果存在带快照的虚拟机EVC 变更可能会被卡住所以操作前先把关键虚拟机的快照清理掉或者做好备份。EVC 调整完成后必须做迁移预演。找一个不影响业务的测试虚拟机在旧主机和新主机之间做一次双向的开机状态 vMotion。如果热迁移成功再做一次关机状态的冷迁移验证。热迁移验证的是 CPU 兼容性和 vMotion 网络冷迁移验证的则是存储可见性和主机基础配置。这两项都过了才敢说兼容性评估基本合格。我还建议把预演的结果记录下来包括迁移耗时、网络吞吐、有无报错后续如果出问题这份记录就是你排查的重要参照。4. 扩容现场最容易踩的坑与排查实录4.1 新主机加进来之后 vMotion 一直失败这是我遇到频率最高的问题。现象很典型新主机已经在集群里虚拟机也能正常跑但只要从旧主机往新主机做热迁移任务就报错提示 CPU 特性不兼容。原因基本就是集群没开 EVC而且新旧主机 CPU 代差明显。排查思路是先看 vCenter 任务栏的具体报错信息再到新主机上翻日志确认细节# 查看 vmkernel 日志中的迁移相关记录 grep -i migrate /var/log/vmkernel.log | tail -100如果确认是 CPU 不兼容处理方式就一条在维护窗口内开启合适的 EVC 基线。如果集群现在的 EVC 基线已经很高而新主机的 CPU 反而达不到那问题更大得评估是不是要降低基线影响现有虚拟机或者干脆不把这台新主机纳入热迁移范围。另外提醒一句有些虚拟机在配置里手动设置了 CPU 兼容掩码CPU Compatibility Mask这也会导致迁移失败。这类情况不常见但遇到“迁移报错但主机看起来完全兼容”时记得去虚拟机的高级参数里看一眼。4.2 vSAN 扩容后健康检查飘红、数据重平衡异常vSAN 集群扩容新主机加进去之后最常见的问题是健康检查报控制器不兼容或者磁盘固件版本过旧。这时候 vSphere Client 的 vSAN 健康检查页面会直接亮红告诉你哪一项不满足。别硬扛先把新主机的控制器驱动和磁盘固件升级到 vSAN 支持列表里的版本再重新跑健康检查全部通过后再继续。还有一个容易忽视的点是数据重平衡的时间窗口。新节点加入 vSAN 集群后系统会自动触发数据重平衡把一部分组件从旧节点迁移到新节点。如果新旧节点磁盘容量差异很大比如旧节点是 2TB 盘、新节点是 8TB 盘重平衡的 IO 压力可能会持续很久。建议在业务低峰期加入新节点并且别急着把新节点所有磁盘一次性塞满分阶段添加更容易控制风险。这类问题日志层面通常会反映在 vSAN 的专用日志里配合 vSAN Health Service 的检查结果基本能定位。如果重平衡过程中出现分区告警优先排查节点间的 vSAN 网络连通性别一上来就怀疑磁盘。4.3 分布式交换机端口组不匹配导致主机“失联”这个问题也很经典。新主机加入 vDS 的时候如果物理网卡映射得不正确或者新旧主机的物理网卡数量不一致、链路聚合配置不同最直接的后果是主机加完直接断网vCenter 都连不上去。我处理这类问题的经验是加入 vDS 之前先在新主机上保留一套临时标准交换机vSwitch作为管理网络的兜底。这样就算 vDS 配置错了主机也不至于彻底失联。然后在 vCenter 里通过“添加并管理主机”的向导把新主机加入 vDS手动指定正确的物理网卡vmnic到对应的 dvUplink保证和旧主机的故障切换顺序一致。如果新主机网卡数量比旧主机少还需要重新评估网卡绑定策略和带宽冗余。别想着“少两个口没事”在集群发生物理链路故障时少的口就是少一条逃生通道。物理链路、VLAN、MTU、LACP 这四项必须逐项核对到一致。4.4 证书、时间同步与告警风暴最后说说不那么致命但非常折磨人的几件事。添加新主机时vCenter 会提示证书不匹配或不受信任。如果环境里用的私有 CA最规范的做法是把 CA 根证书导入 vCenter 的信任库然后给每台新主机签发包含正确主机名和 IP 的证书而不是在界面上“接受风险”草草了事。图省事一时爽后续主机换 IP、换证书的时候就会后悔。时间同步也是老生常谈。NTP 配置不一致的主机加入集群后HA 的 agent 通信会间歇性报错vSAN 网络分区的判断也会受影响。统一 NTP 服务器后确认每台主机的时间差在几百毫秒以内再继续后续操作。新主机加入集群后刚开始往往会有大量告警什么“电源状态未知”“风扇转速异常”“温度传感器未响应”之类的一股脑冒出来。碰到这种告警风暴压住心别一条条点确认。先处理影响 HA 和 vSAN 的高优先级告警其余硬件类告警等主机稳定运行后根据厂商带外管理工具的读数去核对多数是传感器兼容性的误报。下面这张速查表是我的经验浓缩遇到问题可以先对照它定位方向异常现象常见原因优先排查方向热迁移报 CPU 不兼容未开 EVC 或基线过高集群 EVC 配置、主机 CPU 代次主机加进 vSAN 后健康检查红驱动/固件不在 vSAN 列表vSAN Health Service、驱动固件升级加完主机后断网失联dvUplink 映射或 MTU 错误vDS 配置、临时 vSwitch 兜底vCenter 报证书不受信任证书链不一致CA 证书导入、主机证书重签HA 告警、agent 不稳定NTP 不同步统一 NTP、对比各主机时间新主机看不到存储 LUNHBA 未映射、分区未做存储端映射、多路径策略5. 几点实操心得5.1 采购阶段就把兼容性确认做掉省下最多时间这些年做扩容评估我最深刻的体会是兼容性问题的黄金解决时间是在采购阶段而不是在到货阶段。服务器还没下单的时候就把目标 vSphere 版本和 vSAN 版本发给厂商要求书面确认所有部件在支持列表内比到货后发现问题再扯皮要高效得多。这个动作不花什么成本但能帮你避开 80% 的硬件兼容性坑。5.2 扩容也要走变更流程备份永远不嫌多有人觉得加一台主机而已没必要搞变更流程。但正是这种“小操作”出问题的概率一点也不低。我的习惯是任何扩容操作都按变更来处理提前申请维护窗口导出 vCenter 配置备份保存当前主机配置文件准备好回滚方案。整个操作步骤写下来照着做做完记录结果。这套流程看着繁琐但只要救过一次场你就会觉得值。5.3 主机加入集群前给它 24 小时观察期最后再分享一个小技巧。我一直坚持让新主机以独立主机身份在 vCenter 里“晾”上 24 小时再加集群。这段时间里除了让它自己跑着你可以翻翻它的 vmkernel 日志看看有没有驱动报错、网卡丢包、存储超时之类的早期症状。很多问题其实就是在这个观察期里暴露出来的提前处理掉远比加进集群以后一边跑业务一边排查舒服。扩容这件事慢就是快。
阅读完成 · 觉得有帮助？
