一、情况描述
十大靠谱网赌软件近期接到用户报修存储告警且业务应用受到影响,检查发现华为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、如果遇到此类故障,一定要分析故障发生的先后顺序、对业务的影响程度,掌握故障设备的业务使用情况。
如欲了解更多,请登录十大靠谱网赌软件官方网站:cr93.wakatter.com