VMware虚拟化平台集体卡死排查实录：3家厂商6小时无果，一块告警一个月的10年老硬盘拖垮全院业务
目录
- 故障背景：所有设备正常，业务却在轮流"死机"
- 客户环境：12台ESXi主机+75台虚拟机+多品牌存储
- 凌晨1点的求助电话
- 3家厂商排查数小时无果
- 远程初判：问题在存储层
- 凌晨3点赶往现场
- VMware性能分析：Datastore延迟异常
- 锁定故障：一台10年老存储的坏道硬盘
- 技术解析：为什么一块盘能拖垮整个平台
- 故障排除：下线故障盘，5分钟恢复
- 故障后整改：淘汰超龄设备+建立监控体系
- 经验总结：最可怕的不是坏掉的设备，而是带病运行的设备
1. 故障背景：所有设备正常，业务却在轮流"死机"
对于医院来说，服务器宕机并不是最可怕的。真正可怕的是：所有服务器都正常，网络正常，存储正常，但整个业务系统却越来越慢，甚至轮流"死机"。
2024年4月，我就遇到过这样一次故障。凌晨1点，一家三甲医院的虚拟化平台几乎陷入瘫痪。驻场运维、集成商、存储厂家连续排查数小时都没有找到原因。最终故障根因，竟然是一块已经告警一个多月的老旧硬盘。
2. 客户环境：12台ESXi主机+75台虚拟机+多品牌存储
该医院为三甲等级，日门诊量约6000人次，开放床位1500张。核心业务系统包括HIS、LIS、PACS和集成平台，全部运行在VMware虚拟化环境上。
虚拟化平台规模：
- ESXi主机：12台
- 虚拟机：75台
- 虚拟化平台：VMware vSphere
存储架构方面，医院采用存储虚拟化网关统一管理后端存储资源，网关下挂载了多个品牌的存储设备：EMC、同友、浪潮、宏杉、信核、曙光、思科。其中部分设备已经运行超过10年。
3. 凌晨1点的求助电话
凌晨1点左右，电话突然响起。对方焦急地说：
"董工，这么晚打扰你了，现在整个虚拟化平台卡死了，业务系统轮流死机。"
进一步了解情况后得知：
- LIS访问缓慢
- 合理用药响应异常
- 集成平台频繁超时
- 多台物理主机无规律重启
4. 3家厂商排查数小时无果
医院已经组织了驻场运维工程师、集成商工程师和存储厂家工程师联合排查。检查范围覆盖了：
- 网络交换机
- FC交换机
- FC链路
- VMware主机
- 虚拟机状态
均未发现明显异常。几个小时过去了，问题还没找到。
5. 远程初判：问题在存储层
通过电话和远程协助，我让现场工程师重点查看Datastore性能、主机存储延迟和存储响应时间。
很快发现一个共同现象：所有业务都在等待存储返回数据。
我当时就判断：问题大概率不在应用层，也不在虚拟化层，而是在存储层。于是建议大家重点检查后端存储性能。
6. 凌晨3点赶往现场
原本以为已经找到了方向，没想到凌晨3点电话再次响起：
"董工，方向有了，但是问题还是没找到。"
于是我带着设备直接赶往医院。医院距离我大约15公里，凌晨3点出发，3点30分到达现场。
到现场后首先逐项确认基础环境：
- 网络正常
- FC交换机正常
- 光纤链路正常
- VMware主机正常
- CPU正常
- 内存正常
但业务依然很慢。于是开始重点分析VMware存储性能。
7. VMware性能分析：Datastore延迟异常
通过VMware性能监控发现：
- 多个Datastore延迟明显升高
- 大量虚拟机出现存储等待
- 部分虚拟机因长时间无法访问存储而出现异常重启
这说明问题一定还在后端存储。
8. 锁定故障：一台10年老存储的坏道硬盘
继续检查存储虚拟化网关后面的各套存储，终于发现异常——其中一台已经运行超过10年的老存储存在硬盘故障。
进一步检查发现：
- 其中一块硬盘已经出现严重坏道
- 更关键的是，这块硬盘其实一个多月前就已经开始告警
9. 技术解析：为什么一块盘能拖垮整个平台
很多人都问：既然硬盘早就告警了，为什么当天凌晨才把整个医院拖垮？
原因就在于存储虚拟化网关架构。医院所有存储资源都被统一整合到存储虚拟化网关中，对于VMware来说，后端所有存储都表现为一个统一资源池。
故障初期，虽然硬盘已经出现坏道，但存储控制器还能通过重试机制维持运行。随着坏道不断增加，硬盘响应越来越慢。
而当晚医院正好进行数据库备份、影像归档和批量数据处理，存储压力突然增大。故障盘开始出现大量I/O阻塞。由于存储虚拟化网关需要等待底层存储返回结果，最终导致整个存储池响应时间被拉高。
结果就是：一块故障硬盘拖慢了整个虚拟化平台，所有虚拟机同时受到影响。
这本质上是存储虚拟化网关架构的一个潜在风险——它实现了资源的统一管理，但同时也意味着底层任何一块存储的严重性能问题，都可能通过网关扩散到整个资源池。
10. 故障排除：下线故障盘，5分钟恢复
确认故障盘后，立即将故障硬盘下线。
不到5分钟：
- Datastore延迟明显下降
- 虚拟机陆续恢复正常
- 业务响应速度恢复
经过持续观察，到早上7点左右，LIS、合理用药、集成平台全部恢复正常，VMware平台恢复稳定。最终没有影响当天门诊业务。
11. 故障后整改：淘汰超龄设备+建立监控体系
故障结束后，医院决定从三个方面进行整改：
一、淘汰超龄存储设备
逐步下线运行超过8年的老旧设备，避免老旧设备继续承担核心业务。
二、建立存储生命周期管理机制
明确各类存储设备的使用年限和淘汰标准，从制度上杜绝"超期服役"。
三、开展全面健康巡检与持续监控
对ESXi主机、Datastore性能、FC链路和存储延迟进行全面评估，建立持续监控体系，提前发现坏盘、慢盘、延迟异常和容量风险，避免类似故障再次发生。
12. 经验总结：最可怕的不是坏掉的设备，而是带病运行的设备
这次故障让我印象特别深刻。因为现场所有人都在关注VMware、网络、FC交换机、存储网关，却忽略了一块已经告警一个多月的硬盘。
很多时候，真正危险的不是已经坏掉的设备，而是已经发出告警，却仍然带病运行的设备。
对于医院来说，故障并不可怕，可怕的是风险已经存在而没人发现。如果这次故障发生在上午门诊高峰期，后果将完全不同。
所以信息科真正需要关注的，不是故障发生后的抢修能力，而是故障发生前发现风险的能力。
本文为真实IT故障排查案例复盘。作者拥有20年企业IT基础架构实战经验，专注VMware虚拟化、vSAN超融合、Oracle数据库故障排查与性能优化、企业容灾备份及应急恢复，服务医疗、制造业、汽车集团等行业客户。
