vSAN网络抖动致9台虚拟机集体失联：从告警到恢复的排障复盘

凌晨1点37分，监控屏幕像炸了锅似的连续弹告警。值班同事电话里的声音明显压着紧张：“那台跑文件分发、刚迁到vSAN的麒麟V10虚拟服务器连不上了，不止它一个，整个集群里有9台虚拟服务器同时失联。”我套上外套往机房赶的时候，脑子里已经把最坏的情况过了一遍。事后复盘，这件事最让我警醒的地方恰恰是标题里那句“服务器是虚拟的”——很多人觉得业务跑在虚拟化平台上，宿主机有冗余、存储有副本，出事的概率应该比物理机小得多。可真等vSAN网络抖动、HA策略被触发、磁盘锁互相牵制这些环节叠在一起，虚拟化平台反而会把故障放大成“一片”，而不是“一台”。这篇记录，我想把从告警到恢复的全过程写透，包括当时的判断、误操作、恢复次序，以及最终沉淀下来的配置清单。同行如果用vSphere/ESXi跑关键业务，或者正在评估虚拟化+分布式存储方案，这篇应该能帮你少走不少弯路。

1. 实测排障：当“重启VM”成为最先想做的事，你已经被故障带偏了

1.1 凌晨告警的现场还原：vCenter里到底看到了什么

我赶到值班室时，vCenter已经刷了满屏告警。那9台VM的清单状态不是常见的“已断电”或“正在迁移”，而是清一色的“不可访问”或“无法连接”。有的VM还显示为“已打开电源”，但网络探针全部超时，也就是说，操作系统层面已经彻底失去响应。

我习惯性地先做了三件事：

1. 看vCenter告警面板，确认告警对象所在的集群和数据存储。
2. 登录其中一台ESXi宿主机，直接ping网关和vCenter地址，确认宿主机本身是否还活着。
3. 打开vSAN的健康检查页，看有没有大范围的对象降级或分区提示。

前两步很快就有了结论：3台ESXi宿主机都能ping通，vCenter也能正常登录，物理机和虚拟化管理面没有集体瘫。但vSAN健康检查里不干净，有关于“vSAN网络分区”的警告。到这一步，我心里基本清楚：问题不在业务应用本身，而在虚拟化平台的数据平面。

1.2 为什么“先重启一台VM试试”在共享存储故障里是危险的

这里我要专门提一个值班同事的真实反应。他看到一台Windows业务机失联，第一反应是“vmotion迁移到另一台宿主机，或者直接重启VM”。我拦住了。

为什么不能急着动VM？因为这9台VM共享同一个vSAN分布式存储，失联最可能的原因是存储IO已经出现了大面积阻塞。在这种状态下强行重启VM，相当于在存储还没恢复时给磁盘锁和组件重新构建再加一把压力。更麻烦的是，如果vSAN网络仍处于分区状态，HA可能已经在后台尝试把这些VM“重新启动一次”了。你手动再去点一次“重启客户机操作系统”或“关闭电源后再开机”，往往会和HA的自动化动作打架，造成更深的锁冲突。

那次我的指挥口令很简单：“谁都不许点重启或迁移，先把物理链路和vSAN网络状态排查清楚。”事后看，正是这一条拦住了最危险的扩大化操作。

2. 排查方向的转折点：9台VM的共同点不在宿主机，而在数据存储

2.1 一起失联的9台VM，到底有哪些共性

排障最怕的就是一头扎进单台机器里看日志。如果同时有9台出问题，你的第一优先级不应该是“某台机器为什么挂了”，而应该是“它们之间有什么共同点”。我把9台VM列了一张表，越看越有意思。