一块HBA卡引发的血案

6.18那几天，应该是我干IT12年来，经历过的最惊心动魄、压力最大、最考验人的一次经历。

（以下为全VMware虚拟化环境）

现场状况描述：
1．从DB2数据库日志判断从16日15:20左右开始，数据库开始报错（事后判断此时应该是HBA卡性能开始劣化）

2．由于数据库对存储性能尤其敏感，到6.16 17:30左右，数据库故障，可以看到表，但无法查询表

3．此时紧急切换备机，但不是强制切换，主机显示切换成功，备机输入切换命令后么有回显，长时间等待；强制切换回主机，无法连接数据库

4．重启数据库，仍然无法连接

开始寻求外援：
1．IBM数据库工程师尝试修复主数据库服务器没有成功，修改备机为标准服务器对外提供服务

2．17日中午开始备份数据库，准备进行HADR（DB2服务器的高可用）的重建工作

3．此前IBM工程师发现之前打算用于修复主服务器的数据库备份有错误，他提示可能与FTP上传下载方式有关

4．到15:40左右完成备份，通过FTP下载到运维服务器，两个副本的MD5校验相同

5．将运维服务器上的副本FTP上传到主服务器，MD5校验不同（很有可能是HBA卡故障造成数据不一致）

6．尝试通过SCP将备份从原备库服务器发送到原主服务器，发送一半后，中断，但无法终止

严重的问题还在后面：
1．此时，客服反应其他业务系统卡顿中断，研发人员发现重启业务是提示文件系统为只读

2．排查发现相关服务器和原主库服务器在同一台物理服务器上；此时VC都连不上了，刚巧vc也在这台服务器上

3．直接ESXi，想命令行下重启关闭虚拟机都没有成功，系统完全卡死了 （这个时候我真的是压力山大，接近崩溃了，毕竟还有6个小时就要开始大促（6.18 零点）。。。这个时候宕机，公司就等着赔偿，关门，失业）

4．查了下网上，有人说Linux的虚拟机在存储连接失败的时候会文件系统保护，此时只能硬重启该物理服务器，这台服务器上居然还有VC，好在当前主数据库已经切换，不在这台服务器上。这个时候我已经不敢操作了，只能我下判断指挥同事操作，中间给媳妇打了个电话，都快哭出来了。。。

5．重启中发现服务器没有识别HBA卡，进系统后仍然没有识别，无法挂载后端存储

6．同时，该服务器上的虚拟机在其他物理服务器上重启（启用了HA高可用）

7．业务陆续恢复正常

8．故障服务器指定为维护模式，不再使用

从以上种种分析，可能由于16日开发人员大规模的删除数据库历史记录（也可能之前HBA卡性能就开始劣化），触发了虚拟机所在服务器的HBA卡性能持续劣化--故障，直至系统无法识别。由于持续劣化的过程中，存储的读写延迟持续上升，最终造成Linux类虚拟机的自动保护，表现为提示文件系统为只读，符合当时客服人员发硬系统卡顿中断的反应

教训：
所有的硬件、系统、软件都要冗余，服务器、存储、网络，包括各个配件

数据库、应用系统的双机应该错开放置，分布到不同的服务器和存储卷上

完整的监控，包括存储性能，光交接口丢帧、错误等等

在允许的条件下，尽量多的备份数据，这次这么大的事故，居然没有丢数据，真的是万幸

对于虚拟化技术的掌握，例如高可用的配置，DRS的配置（我一般是手动）

必要的故障预案要做好

遇事沉着冷静，天塌下来也不能慌，准确判断，小心操作

随时准备好多个备用方案，例如你连不上VC的时候

热点数据或虚拟机单独放到物理服务器和单独的raid存储卷，避免影响其他业务

一定要配置远程管理卡，最后关头可以远程硬重启服务器（当时同事已经准备好开车去机房了）

大业务期间一定要安排好相关人员和技术支持专家