一、情况描述

安图特近期接到用户报修存储告警且业务应用受到影响，检查发现华为S2600（版本号V100R005C02）一个RAID组中两块盘于半小时内先后发生故障，RAID5离线。现场情况如下：

17:48 位置4.1的硬盘故障，RAID5降级；

18:17 位置4.3的硬盘故障（存储时间慢一个小时）,编号为6的RAID5离线。

二、处理过程

据用户描述，该RAID组为虚拟化项目使用。工程师发现，该RAID组之前遵循的是一个RAID组中的LUN对应一个数据存储的规则，受影响的是其中一个2TB的数据存储。数据存储中存放有5台虚拟机，均为前端应用，目前无法正常运行，重新部署应用要花费较长时间。为防止数据丢失，工程师对存储告警内容及事件日志进行分析后，计划先拉起后故障的位置为4.3的坏盘，将RAID5恢复到降级状态，尝试拷出数据。

1、Revive 4.3坏盘

因为4.1和4.3先后发生故障，4.3后发生故障，所以先revive 4.3：

Ssh 登录S2600控制器，进入CLI模式；

Debug进入调试模式；

Mml进入mml模式；

Revive disk 4.3；

Revive raidlun 6；

经过以上操作，ID为6的RAID组状态变为degraed,LUN状态为可用，但spare盘并未开始顶替4.1。登录Vcenter发现，此时虚拟机系统已经挂死，但仍可对其进行操作。强制关闭虚拟机操作系统后，对涉及的5台虚拟机逐台进行迁移， 其中两台迁移成功且恢复正常使用，另外3台在迁移时发生了报错；

客户反映报错的3台虚拟机中有1台业务已下线，可暂时不作处理，另外两台的AD主服务器重要性较高。但在迁移报错的同时，存储上出现介质错误的紧急告警。

2、Revive 4.1坏盘

此时用户着手重新部署尚未恢复的两台虚拟机应用，工程师计划将另外1块坏盘也拉起来，Revive 4.1坏盘；

进入debug ，mml模式，revive disk 4.1，随后系统开始自动spare盘顶替4.3。热备盘顶替完成后，尝试迁移两台故障虚拟机操作再次失败，虽然RAID组状态已恢复正常，但介质错误的告警仍然存在。进入debug模式，使用“disktool –f A | grep Current_Pending_Sector”检查并未发现有磁盘坏道存在。

3、清理受影响LUN的BST标记

RAID组状态恢复正常，但介质错误的告警，应该是对应LUN的介质错误导致数据不可用，故着手解决LUN介质错误问题；

进入debug，MML模式，使用bst showbst可以发现如下图中0.10、 0.11（即为顶替后的热备盘位置）上有几个位置一样的逻辑记录，同时，RAID组中4.4的硬盘有一个不能清除的物理记录；

使用bst delbst 磁盘ID lba len 逐条清理lba标记，清理完0.10上的逻辑错误后，0.11上同样位置的逻辑错误同时消失。清理完成后，存储上介质错误的紧急告警已经消除，仅剩两条坏盘的重要告警。再次克隆虚拟机也成功完成，受损RAID组数据全部得到恢复；

为保证设备稳定运行，首先卸载对应的数据存储（虚拟机已迁走），然后删除该RAID组的映射、删除LUN和RAID组，最后更换该RAID组中的硬盘、重建RAID组并进行重新映射。

三、经验总结

1、华为OceanStor S2600为第一代OceanStor存储（目前华为已经停止支持该型号存储），设备短时间内多块盘故障的情况是较少见的，但一旦发生会对业务造成很大影响，为尽可能减少损失，应做好日常监测和应急预案；

2、日常维护时应定期收集存储上的硬盘的smart数据，使用相关软件对硬盘健康情况进行监测，并对状况不良的硬盘提前进行预更换；

3、华为目前的存储都支持RAID6类型，且新上线的存储，一般都规划为RAID6类型，而且可靠性提高很多；

4、此次事件处理中可见RAID组和虚拟化数据存储逐一对应的规划卓有成效，没有扩大受影响的数据量；同理如果是文件系统或者数据库，也可以遵循这一原则；

5、如果遇到此类故障，一定要分析故障发生的先后顺序、对业务的影响程度，掌握故障设备的业务使用情况。

如欲了解更多，请登录安图特官方网站:www.antute.com.cn