一键登录 更安全快捷
获取验证码
密码登录
验证码登录
登录
登录/注册
0
收藏
很多运维环境配置了VCHA（vCenter High Availability）三节点高可用集群，在完成VCSA8.0 U版本补丁升级后，Web界面弹出告警“vCenter HA status unhealthy”，VCHA整体状态不健康。此时虽然vCenter业务可以正常访问，但是高可用故障切换功能失效，如果主节点故障无法自动切换至备用节点，存在业务中断风险。 VCHA对复制链路网络质量非常敏感，节点之间网络延迟要求低于5ms，升级过程也有可能中断同步复制进程。本文讲解完整排查流程，查看复制状态、检测网络延迟、修复同步异常，恢复VCHA健康状态。
有VMware全系列产品官方资源和定制版资源需求的可以移步：
VCSA升级/打补丁完成后，vCenter网页告警：vCenter HA status unhealthy；
vCenter核心业务、登录、虚拟机管理功能正常可用；
VCHA高可用切换功能失效，不支持手动故障转移；
部分场景下Active、Standby、Witness三个节点角色识别混乱；
SSH查看复制服务，数据库复制进度停滞，复制链路断开。
某企业VCSA8.0 U2 VCHA三节点集群，在线升级到U3版本，升级流程执行完毕无报错。登录vCenter后立刻弹出VCHA status unhealthy告警。业务访问全部正常，但是无法执行vCenter HA手动切换。 登录Active节点SSH检查，发现VCHA复制链路延迟达到12ms，远超VCHA要求的5ms阈值，升级过程短暂网络抖动进一步打断复制同步。优化底层网络，修复复制会话，同步完成之后VCHA恢复healthy健康状态。
VCHA底层依靠数据库持续复制实现主备数据同步，VMware官方硬性要求三个节点之间复制网络往返延迟必须小于5ms。升级过程大量数据读写，如果网络延迟过高，复制会话断开，直接判定VCHA状态不健康。如果复制网络跨交换机、跨网段，容易出现延迟超标。
VCSA版本升级、补丁更新会重启VCSA内部多项服务，会中断正在运行的复制会话。部分环境升级结束后复制服务无法自动重建会话，复制停滞，状态标记为unhealthy。
三节点之间复制网络端口被防火墙拦截；
Witness见证节点磁盘空间不足；
节点之间DNS解析异常，主机名互相解析失败；
升级后主备节点版本短暂不一致，复制校验失败。
必须登录当前Active角色的VCSA节点执行查看命令，root账号登录。
#查看VCHA整体状态 vcsa-deploy vcha status
该命令会输出三个节点角色、复制状态、同步进度，重点观察Replication State复制状态字段。
VCHA强制要求复制网络RTT <5ms，超过阈值会直接导致复制不稳定、状态不健康。
#分别ping standby节点、witness节点复制IP，查看往返延迟 ping standby-repl-ip ping witness-repl-ip
如果持续平均延迟大于5ms，需要排查交换机、链路负载，尽量把VCHA复制网络规划到独立二层网络，避免跨路由转发。
#查看数据库复制会话 cat /var/log/vmware-vcha/vcha.log | grep -i replication
日志关键词：session broken代表复制会话断开；lag代表复制延迟过高。
VCHA强依赖DNS，每个节点必须可以正向、反向解析另外两个节点主机名。
nslookup standby-hostname nslookup witness-hostname
升级后经常出现DNS缓存问题，解析错误直接破坏VCHA集群状态。
情况一：网络已经修复，复制会话中断，执行重新同步。
#执行VCHA重新同步，会把Active数据重新同步到Standby节点 vcsa-deploy vcha resync
resync同步时间取决于VCSA数据库大小，大型环境同步需要数十分钟，不要中断会话。
情况二：resync无法修复，极端场景，取消VCHA配置，重新搭建VCHA集群。 > 注意：该操作为高危操作，业务窗口执行，先对VCSA做完整备份。
vcsa-deploy vcha unconfigure #之后重新配置vCenter HA
| 故障现象 | 核心根因 | 标准化解决方案 |
|---|---|---|
| VCSA升级后告警vCenter HA status unhealthy，业务正常 | 升级中断复制会话，节点间网络RTT大于5ms | 优化复制网络保证延迟<5ms，执行vcsa‑deploy vcha resync重新同步 |
| ping延迟达标，resync仍然失败 | 三节点DNS正向/反向解析异常 | 修复DNS，保证每个节点都可以解析另外两个节点主机名 |
| VCHA日志报session broken复制会话反复断开 | 防火墙拦截VCHA复制端口，网络偶发丢包 | 放开VCHA复制端口，排查物理网络丢包，优先二层隔离复制网络 |
| Witness见证节点磁盘占用高，VCHA状态异常 | Witness磁盘空间耗尽 | 清理见证节点磁盘，扩容存储，保证磁盘有充足空闲空间 |
| resync重新同步长时间卡住不动 | VCSA数据库庞大，存储IO性能不足 | 不要中断任务，监控存储性能，等待同步任务执行完成 |
1. 误区：vCenter网页业务访问正常，VCHA告警可以忽略纠正：业务正常仅代表主节点工作正常，VCHA unhealthy状态下故障切换完全失效，主节点宕机vCenter直接不可用。
2. 误区：VCHA复制网络可以随意跨广域网、跨机房部署纠正：官方硬性要求复制网络往返延迟小于5ms，不支持跨机房长距离部署VCHA。
3. 误区：VCSA升级不需要停机，升级完不用检查VCHA状态纠正：VCSA补丁、版本升级会重启大量内部服务，极易打断VCHA复制，升级完成必须核查VCHA status。
4. 误区：直接重启VCSA节点就可以修复VCHA告警纠正：单纯重启节点不会重建数据库复制会话，需要执行resync重同步命令。
VCSA执行升级、打补丁之前，对VCSA做完整备份，备份完成再执行升级操作；
VCHA复制网络独立规划二层网络，保障三节点之间网络往返延迟稳定小于5ms，杜绝跨路由跨广域网；
升级全部完成之后，必须执行vcsa‑deploy vcha status，确认VCHA状态healthy，才算升级全部完成；
集群DNS严格维护，保证三节点正向、反向解析全部正确，禁止修改VCHA节点主机名；
日常运维监控VCHA状态告警，一旦出现unhealthy告警第一时间处理，不要等到故障发生；
resync重同步操作安排业务低峰，数据库量大同步耗时久，禁止中途断开SSH会话。
VCSA8.0升级之后出现vCenter HA status unhealthy告警，业务可用但高可用切换功能失效。优先核查VCHA复制状态，重点保证三节点之间复制网络往返延迟低于5ms；升级常常打断复制会话，使用vcsa‑deploy vcha resync执行重新同步。 同步前确认DNS解析正常，网络无丢包；resync不能修复再考虑取消并重新配置VCHA。VCSA版本升级完成务必校验VCHA集群健康状态，避免高可用形同虚设。
