版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。
问题:
数据恢复既然是数据灾难的一种补救措施,那设计得绝对安全的RAID磁盘阵列系统也会出现数据灾难吗?为什么?在RAID数据恢复领域里常见的故障类型有哪些?
回答(北亚数据恢复中心张宇 http://www.datahf.net):
RAID设计的初衷大约有3个原因:解决容量问题、解决IO性能问题与解决存储安全(冗余)问题。从数据恢复的角度看,我们暂不讨论容量与IO性能方面,仅讨论存储安全。
RAID中可以起到存储安全的组织方案常见的为RAID1、RAID5及其变形,基本设计思路是相似的,都是能过一定的算法,用多块硬盘之间的算法维护来保证当部分数据异常时,可通过特定算法还原出来。拿RAID5的设计方式来看,举个简单的例子说明一下,如果我们要记录两个数字,那么可以通过再多记录他们的和来达到记录的冗余性,就像我们记录3和5,同时再记录一下8(为3+5的和),那么如果我们不记得到底是几和5,只需要用8-5就可以算出这个丢失的数字了,其余情况依此。在磁盘阵列里同样是以某种算法来达到保全数据的目的,当一组3块盘的RAID5正常工作时,所有写入RAID里的数据都正确地写到特定磁盘地址,同时再生成一个特定的计算值(通常称为校验和),这个时候的读写效率是最好的。但当其中一块盘出现故障时,存储在这块故障盘上的原有数据就要通过其他硬盘的数据恢复出来,当然这个过程中控制器(硬RAID为RAID卡,软RAID实际上是个驱动)会负责这个工作,同时为了保证不宕机,控制器也会保证存储的正常化,不会让操作系统认为硬盘系统出了问题。
从上面的原理来看,RAID提供的存储安全还有一些不太容易避免的漏洞,虽然可能性不大,但存储在RAID上的数据价值可能无法评估,出丝毫的故障都可能会导致一场大的信息灾难。
转入正题,RAID通常出现的故障可能性有:
1、处于降级状态时,未及时rebuild:RAID是通过多出来的部分存储空间来提供算法上的数据安全冗余的,但当某些盘出现故障下线后,RAID便不能再提供这种存储冗余,如果管理员不及时更换盘,REBUILD整个卷,这时候其余工作中的硬盘再出现故障,RAID卷便无法正常工作了。这类故障在RAID数据恢复中比例相当高,服务器维护管理跟不上很容易发生。
2、控制器故障:控制器是连接物理硬盘与操作系统之间的数据存储纽带,同时因RAID的组成方式并非自然约定(特定),硬盘容量的大小,硬盘数量的多少,RAID组成级别,逻辑磁盘分割方式,块大小,校验方式等因素组合成不同的RAID信息(RAID元数据),这些RAID信息有时候会写在阵列卡上,有时候会写在硬盘上,还有的时候两者皆有。如果控制器出现故障,很多情况下更换新的控制器并不能RAID信息还原,中低端的控制器出于成本考虑,这方面漏洞更会大得多。同时即使记得住原先的RAID结构,再次重建也都是错误的数据恢复方法(见相关文章)。
3、固件算法缺陷:RAID的创建、重建、降级、保护等工作在控制器的实现上是非常复杂的算法,当然这里面的复杂更多地是提供尽可能万无一失的无漏洞算法,尽管厂商不会轻易承认控制器的BUG,但毫无疑问,这些问题在任何一款控制器上都无法避免。因为固件算法上BUG,可能会产生很多无法解释的故障。比如在部分服务器数据恢复案例中,有一些早期生产的DELL 2950服务器,会有RAID一块盘OFFLINE后故障盘与报警灯不一致的情况,导致客户在更换故障盘REBUILD时拔错盘,整个RAID组崩溃。
4、IO通道受阻导致RAID掉盘:RAID控制器在设计时为了数据的绝对安全,会尽可能避免写数据到不稳定的存储介质上,这样,当控制器与物理硬盘进行IO时,如果时间超过某个阀值,或不满足校验关系,便会认为对应的存储设备已不具备持续工作的能力,但会让其强制下线,通知管理员尽快解决问题。这种设计的初衷很好,同时也是正确的设计方式,但对于如物理链接线路松动,或因硬盘机械工作时反应超时(可能硬盘还是完好的)等随机原因对控制器而言无法分辨设备是否具备和之前一样的稳定状态,所以很不在意的某些小环节,便会导致RAID卷出现故障,此类故障的发生概率极大,而且无法避免。这也是大多数RAID出现故障后,硬盘并未有故障的原因,我们好多数据恢复服务的客户会因此质疑服务器厂商,实际上是有苦难言的,一定程度上,越是设计安全的控制器,越会发生此类现象。
5、控制器的稳定性:RAID的控制器在ONLINE状态下(无离线盘)工作是最稳定的,相对而言,当部分硬盘损坏(可能是逻辑故障)后离线,控制器便会工作在一个比较吃力的状态,这也是好多中低端的RAID控制器在一块盘离线后读写性能急速下降的原因。控制器的负载太重便会极大地增加数据吞吐时出现IO滞留的可能性,从而导致如上面第4点提及的RAID离线。一个不具备高速硬件处理芯片,不具备高速缓冲的控制器发生这类故障的概率要高得多。为了避免出现故障后数据恢复带来的业务停顿与额外开销,还是尽量不要选择这类磁盘阵列控制器。
6、坏硬盘:这类情况很有趣,好多人会认为正常工作的RAID里不会有坏硬盘,因为只要硬盘一坏,RAID就会让他这块坏硬盘脱机,更换新硬盘后REBUILD就又是好硬盘了。但实际上,这类情况却是不可避免的,原因是:一组RAID卷在工作很长时间以后也很少会读到物理硬盘的所有磁盘空间,同一时间更是不可能。部分情况下,硬盘会在没有读到的区域或者以前读取是良好的区域产生坏道,这类坏道因为没有读写过,所以在控制器看来是好的。产生这种坏磁道的最直接危害是在REBUILD过程中。当一块物理硬盘离线后,通常所有的技术人员及官方资料都会写尽快做REBUILD,但如果其他硬盘存在这类平常不知的坏磁道,REBUILD又都是对全盘做全面同步,就一定会读写到那些坏道,这时候REBUILD没完成,新盘无法上线,因旧盘里又发现了坏道,便会导致RAID又多出一些下线的硬盘,这样就可能会导致RAID出现故障,无法自行进行数据恢复了。
7、人为误操作:涉及数据恢复的数据灾难有相当一部分也是可以避免的,但总会有这样的情况:无关人员误拔RAID里的硬盘、没准备备件盘、不及时换盘、给RAID除尘时忘了原来的顺序、不小心删除了原RAID配置等。
8、其他我暂时想不起来的原因。
这些灾难原因除人为原因外,大多数很难直接避免,只能通过结合备份,构建整体存储安全方案来解决。其他文章会提到原因,以及抛开数据恢复话题的安全建议。
2009年2月21日星期六
订阅:
博文评论 (Atom)
没有评论:
发表评论