一、组网图

不涉及

二、问题描述

双活存储私有链路闪断后，vm平台上的数据库集群异常宕机，数据库使用的硬盘空间为VM平台从存储上切割出来的虚拟磁盘。

三、过程分析

1、分析存储日志，发现数据库对应时间段存储端出现私有链路闪断，且数据库所占用的磁盘空间对应的双活LUN对应此闪断私有链路：

2019-05-04:17:08:49:0x13700001:SP2:DEVICE_PAIR:Warning:Device pair's link state has changed from UP to DOWN,<remote device>: Storage-old, <link id>: 2.
2019-05-04:17:08:57:0x13800001:SP2:MIRROR:Warning:Mirror status becomes unsynchronized, <Local LUN>: LUN-SSD-8T.
2019-05-04:17:09:40:0x3700001:SP2:DEVICE_PAIR:Info:Device pair's link state has changed from DOWN to UP,<remote device>: Storage-old, <link id>: 2.
2019-05-04:17:09:45:0x3800001:SP2:MIRROR:Info:Automatically start synchronizing for mirror successfully, <primary LUN>: LUN-SSD-8T, <mirror LUN>: LUN-SSD-8T.
2019-05-04:17:09:45:0x3800001:SP2:MIRROR:Info:The status of mirror becomes synchronized, the data of mirror becomes consistency, <primary LUN>: LUN-SSD-8T, <mirror LUN>: LUN-SSD-8T.
2019-05-04:17:10:26:0x13800001:SP2:MIRROR:Warning:Mirror status becomes unsynchronized, <Local LUN>: LUN-SSD-8T.

2、分析数据库所在虚拟机日志，对应时间段虚拟机磁盘报错：

且报：hostbyte=DID_BAD_TARGET，初步判断scsi总线共享方式为“物理”

3、分析数据库日志，发现对应时间点1分钟后数据库报错

4、查看DB2群集共享磁盘方式，现场检查确认scsi总线共享方式为“物理”，该种共享模式下虚拟机对磁盘的延时响应较为敏感，对于DB2等数据库业务，磁盘响应时间稍长将导致双机故障，需要在linux虚拟机中将磁盘超时参数修改为：5：

5、综合判断为：现场对应时间段私有链路1、2存在异常，初步分析由于私有链路闪断导致磁盘响应时间较平常时间长，由于DB2双机scsi共享总线方式为“物理”，对磁盘延时较为敏感，进而导致DB2数据库宕机。

四、解决方法

1、在前端业务量较小时，排查定位并解决现场私有链路闪断问题。
2、调整DB2虚拟机中的磁盘超时参数：echo "5" > /sys/block/sdb/device/timeout。

五、风险提示

当前端存在在vm平台搭建集群时，如scsi共享总线方式为“物理”，必须调整对应虚拟机内的磁盘超时参数为5：echo "5" > /sys/block/sdb/device/timeout；否则存储端出现重启、接管、反转等情况时，对应虚拟机业务必断。

六、关键字

DID_BAD_TARGET，Vmware，宕机