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列了一张表，越看越有意思。

表格拉的很快，结论也拉出来了：9台VM分布在3台不同的ESXi宿主机上，操作系统和业务五花八门，唯一的交集是数据存储全部落在同一个vSAN数据存储上。这基本排除了“某台ESXi宿主机死机”和“某个业务进程互相影响”这两个方向。问题大概率出在vSAN数据存储本身或者承载vSAN流量的网络上。

2.2 顺手澄清一个高频疑问：虚拟机IP和宿主机IP一样吗

排查过程中，新来的网络同事提出一个想法：“会不会虚拟机配的IP和宿主机管理IP冲突了，导致整个二层广播乱掉？”这个问题乍一听很吓人，其实做虚拟化的都清楚，两者不在一个逻辑层面。

ESXi宿主机的管理IP或VMkernel IP，是宿主机用来做管理、vMotion、vSAN等底层流量的地址，跑在ESXi自己的网络栈里。而虚拟机里面的IP是guest OS自己配的业务地址，跑在虚拟交换机上，由ESXi负责转发。正常情况下完全独立，不存在“必须不一样”的关系。虚拟机配成和宿主机管理IP相同，只会让某台guest OS自身网络异常，不可能让9台机器共享一种失联模式。

真正需要检查的，是ESXi上用于vSAN流量的VMkernel网卡。vSAN数据流量本质上需要在宿主机之间高速互联，一旦这条链路抖动，虚拟机的磁盘IO就会开始等待，表现为guest OS卡死、网络探针失败。当时我们检查vSAN网络，看到esxi-01上vSAN的vmk网卡对应物理网卡vmnic3持续丢包，esxi-03也出现了类似问题——方向这才彻底反转过来。

3. vSAN链路抖动引发的大面积对象异常：故障传导全路径还原

3.1 一次光模块不稳，如何一步步拖垮9台业务

找到了vSAN网络异常这个初步方向，还要回答最核心的问题：为什么一条网络链路不稳，能拖垮9台看起来“分布在不同物理机”上的VM？

我按时间顺序把vSAN和vSphere的日志捋了一遍，整个传导过程大概是这样的：

1. 某台骨干交换机上连接esxi-01和esxi-03的物理端口光模块开始劣化，链路在短时间内频繁up/down。
2. esxi-01和esxi-03上的vSAN VMkernel接口反复丢包，vSAN集群内部的心跳和元数据通信出现间歇性中断。
3. vSAN网络其实是一种分布式存储网络，主机之间既要传输数据副本，也要维护组件元数据。当链路抖动持续一段时间，vSAN会把部分组件标记为“absent”或“degraded”，等待副本重新同步。
4. 在反复断开同步的过程中，数据存储整体进入高延迟状态，部分对象的读写IO开始排队。
5. 9台VM的磁盘文件部署在这些受影响的对象上，guest OS的存储IO等待时间超过应用阈值，越来越多进程卡在D状态，最终表现为服务无响应、ping不通。
6. 与此同时，vSphere HA发现部分宿主机的管理面心跳异常并尝试触发恢复动作，但在存储链路不稳定时，HA重启VM只会让VM在启动阶段反复读取不到磁盘数据，于是集体卡在启动早期。

这个链条其实非常有代表性。vSAN的本意是数据多副本、跨主机冗余，但“多地多副本”的前提是网络稳定。网络一旦抖动，分布式存储会把“单点故障”放大成“多点同步失败”——物理机上你只会坏一块盘，虚拟化平台上你却会失去一整片业务。

3.2 当时用的几个排查命令和日志特征

如果你也遇到类似的“VM集体失联”，我建议按下面的顺序在宿主机上做验证，而不是先去vCenter里反复开关VM。

登录到每台ESXi宿主机，先确认vSAN集群视角是否还正常：

bash复制esxcli vsan cluster get

这条命令会返回当前节点所在的vSAN集群UUID、角色、健康状态。如果返回超时或显示集群内其他节点不可达，说明vSAN控制面本身已经出问题了。

再检查物理网卡的链路状态和丢包情况：

bash复制esxcli network nic list
esxcli network nic stats get -n vmnic3

重点看Link Status是否反复up/down，以及rxerrors、txerrors有没有异常增长。如果物理网卡本身没问题，再用vmkping测试vSAN网络专用VMkernel接口的连通性：

bash复制vmkping -I vmk2 -d -s 1400 -c 10 10.0.20.12

这里-I指定vSAN所在的VMkernel网卡，-d是持续ping，-s 1400是为了模拟接近业务数据包的大小，-c 10是发10个包。如果丢包率不是0，或者延迟忽高忽低，说明这条链路就是最大嫌疑。

当时的日志里，vmkernel.log反复出现类似vSAN node reachability变化、heartbeat丢失的记录，vSAN健康检查页也有“网络分区”提示。这套组合拳打下来，问题源头基本锁定。

4. vSphere HA在故障时到底是帮手还是帮凶：配置思路复盘

4.1 看看你家的“主机隔离响应”是哪一种

很多集群默认会把vSphere HA的“主机隔离响应”设置成“重新启动VM”。这个设置在单台物理机彻底挂掉时非常有用——HA检测到主机失联，自动在集群内其他宿主机上把VM重新拉起来，业务中断时间可以压到几分钟以内。

但vSAN环境有个特殊点：分布式存储的数据面和管理面高度依赖宿主机之间的网络。如果网络没有彻底断，只是质量劣化，HA的“自动重启”反而会踩油门。我们这次就遇到了类似情况：一部分VM被HA判断为需要故障转移，VM在别的宿主机上尝试启动，但启动时需要读取的虚拟机磁盘对象还在vSAN上做组件重新同步，结果就是VM起一半卡死，vCenter里出现大量“不可访问”的中间状态。

我后来在复盘时给团队立了一条规矩：如果业务系统对“连续可用”的要求高于“快速拉起”，比如数据库、ERP这类有状态应用，建议把HA隔离响应调成“保持电源状态”。先让专家判断到底是主机死了还是网络分区，再决定是否手工处理。无状态Web前端可以保持“重新启动VM”，但要确保存储网络健康检查正常后再放HA去自动化。

4.2 DRS和vMotion在存储抖动中的副作用

故障那晚，我们还观察到DRS尝试把部分正常宿主机上的VM做负载迁移。DRS的本意是平衡，但在vSAN网络分区期间，vMotion同样需要通过存储网络传输内存页和磁盘状态。链路抖动让vMotion重复失败，虚拟化平台的整体管理负载反而升高。

这里要理解一个原则：vMotion并不是专治各种故障的“万能迁移”，它要求源主机和目标主机都能访问共享存储，还需要稳定的管理网络。vSAN数据存储虽然看起来是个共享存储，但它的“共享”是建立在所有ESXi主机都能互相通信的基础上的。网络分区意味着这个“共享”的前提没了，vMotion自然无法成功。

如果你的生产环境同时开了HA、DRS和vSAN，建议把这三者的关系画成一张“故障场景决策表”：什么情况下让DRS自动平衡，什么情况下让HA自动重启，什么情况下完全人工接管。不要等到告警风暴时再想，人在凌晨的应激反应很容易按错键。

5. 恢复9台虚拟服务器的正确顺序：先把虚拟化层恢复到可运行，再动虚拟机

5.1 恢复次序才是真正的胜负手

告警发生约40分钟后，网络同事确认是核心交换机到esxi-01、esxi-03的两条光纤链路对应的光模块故障，其中一块光模块已经进入劣化状态。把两条业务链路切换到备用光口后，vSAN网络丢包率归零。

但我仍然没有急着把9台VM全部开机。当时做的第一步是在vCenter里等vSAN健康检查状态从红色变黄再变绿。vSAN是一个需要“自愈”的分布式系统，网络恢复后，组件会重新同步，对象会重新变为可用。这个重同步过程视数据量大小可能需要几分钟到几小时。在重同步没有完成前强行开机，VM启动时会有大量的存储IO请求，反而拖慢整个vSAN对象的修复进度。

正确顺序应该是：

1. 恢复物理网络链路，确保所有vSAN成员主机的vmkping不再丢包。
2. 在vCenter中观察vSAN健康状态，确认没有“网络分区”之外的红色错误。
3. 等待组件重同步率达到健康线，至少不再有大面积对象不可访问。
4. 再逐个检查9台VM的磁盘文件是否已可见、可注册。
5. 按业务依赖顺序启动VM，而不是一次性全部开机。

5.2 遇到“注册冲突”和“磁盘锁”时的处理手法

网络恢复并不意味着9台VM能一键拉回。我们当时遇到两个典型问题：

第一个是部分VM在vCenter里处于“不可访问”，但直接右键启动是灰的。这是因为HA可能已经把VM的注册信息挪动过，或者vCenter里还残留着旧的占位记录。处理方法是在vCenter里把这台VM“从清单移除”，注意不是“从磁盘删除”，只是移除清单项。然后到对应的数据存储目录里，找到.vmx文件，右键“注册虚拟机”，重新加回来。这一步很多新手会手抖，如果选了“从磁盘删除”，那数据就真没了。

第二个问题是启动VM时报“虚拟磁盘已被锁定”或“无法打开磁盘”。原因通常是故障发生时，某台ESXi还持有vmdk的锁记录，但该宿主机的vpxa服务状态已经异常。遇到这种情况不要急着去数据存储里删.lck目录，很多锁文件删了会引发更严重的一致性风险。我当时的做法是：先在vCenter事件里查这个锁是哪个宿主机、哪个任务留下的，然后到对应的宿主机上把vpxa服务重启一下，或者等待HA自动释放失效锁。绝大多数情况下，重新注册后会由虚拟化平台自动接管锁，不需要手动干预。

5.3 那台麒麟V10上的vsftpd虚拟用户服务，恢复后要查什么

9台VM里有一台比较特殊，就是ftp-data-01。它跑的是麒麟高级服务器操作系统V10 SP3，上面部署了vsftpd，并通过虚拟用户方式隔离了一批合作方账号。虚拟用户的好处是账号和系统用户分离，每个合作方只能访问自己的目录，权限控制很清楚，也不用给真实系统账户。

这台VM被虚拟化到vSAN上后，它的虚拟系统盘和FTP数据目录都落在同一个数据存储。底层vSAN抖动时，vsftpd进程虽然没崩，但因为磁盘IO卡住，整个FTP服务的响应全部超时。恢复后，我没有只看服务起来了就宣告没事，而是做了三件事：

1. 查看vsftpd服务状态和系统日志，确认没有因为存储中断导致配置文件损坏。
2. 检查虚拟用户对应的数据目录是否完整，尤其关注vsftpd通过PAM模块加载的虚拟用户账号库文件能否正常读取。
3. 用测试账号实际做一次FTP登录和文件上传下载，验证通过后再通知业务方。

这次事件之后，我也建议他们把ftp-data-01的关键虚拟用户配置做一次定期备份。虚拟化平台的存储确实带来了便利，但“配置和业务都在同一个vSAN数据存储”意味着平台层的故障会同时影响“操作系统”和“应用账号库”，这个风险面比物理机时代更容易被忽视。

6. 惊魂之后我做了什么：vSAN网络、HA策略和故障预案三份硬配置

6.1 vSAN网络物理隔离不是口号，是底线

这次故障的根因是承载vSAN流量的物理链路出现了光模块劣化。如果vSAN流量和业务流量混跑在同一根链路上，业务高峰期的突发流量会加剧vSAN的延迟抖动，反过来又拖垮所有VM。所以虚拟化平台里，vSAN网络最好走独立物理链路，至少也要使用独立的交换机端口和独立的VLAN，不要让业务流量、管理流量、存储流量全挤在一块。

我当时梳理了一遍现有配置，整理成一张连接表，贴在运维手册里。这张表要能回答三个问题：每台ESXi的vSAN VMkernel接口对应哪块物理网卡、接到交换机的哪个端口、中间有没有经过其他网络设备。没有这张表，下次换光模块或重配交换机端口时，还是可能稀里糊涂把vSAN网络搞断。

6.2 按业务类型重新设置HA隔离响应和VM重启优先级

经过这次故障，我们调整了集群级的HA策略：

• 对有状态、启动慢、恢复流程复杂的VM，比如数据库和应用服务器，隔离响应保持“保持电源状态”。因为在存储网络抖动时，让它们继续运行并等待人工决策，比让HA盲目重启更安全。
• 对无状态、可快速重建的VM，比如CI Runner、日志接收端，允许HA在主机故障时自动重启。
• 设置VM重启优先级，关键业务“高”，普通业务“低”，尽量避免HA在恢复时把所有VM一起拉起造成存储IO瞬间打满。

你可以在vSphere的集群设置里，为不同虚拟机建立分组，再把分组和HA规则关联起来。这件事一定要在平时做，不要等到故障发生时才去vCenter里找配置入口。

6.3 故障预案里最值得写的三部分内容

经历过这次之后，我重新整理了排障手册，重点不是“操作步骤大全”，而是“分诊顺序”和“禁止动作”。

分诊顺序很简单：先看宿主机是否活着，再看vSAN健康检查是否正常，再看网络链路丢包情况，最后才看单台VM的系统和应用日志。顺序反了，你会浪费大量时间在业务日志里找根本不存在的代码Bug。

禁止动作清单也很重要：存储网络没有恢复前，禁止手动重启VM；vCenter里显示“不可访问”时，禁止从磁盘删除任何虚拟机文件；“虚拟磁盘被锁定”时，禁止盲目删除锁文件；vSAN重同步没有完成时，禁止一次性批量开机。

这份手册不需要写得多漂亮，但要把每个人在慌乱里最容易犯错的动作提前说死。我把这次9台VM集体失联的完整过程、命令输出截图、配置修改记录都附在后面，作为以后类似告警的标准参考。谁再遇到类似情况，至少能少走我那天凌晨那40分钟的弯路。