Chinaunix首页 | 论坛 | 博客
  • 博客访问: 578503
  • 博文数量: 113
  • 博客积分: 3322
  • 博客等级: 少校
  • 技术积分: 1565
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-04 11:38
文章分类

全部博文(113)

文章存档

2012年(21)

2010年(92)

分类:

2010-03-12 09:21:05

存储的基础构建正在发生根本性的转变,它就像20年前RAID刚出现时候一样具有颠覆性。这个革新性的发展通常被称为自主自愈存储,它给磁盘系统带来前所未有的高可靠性。

自主自愈存储这个词听起来不像一个根本性的变革,倒更像一个夸大其辞的概念。现在的RAIDRAINredundant array if independent nodes冗余节点阵列)、快照、连续数据保护(CDP)和镜像不都是吗?如果你将自愈定义为从损坏状况下恢复的能力,那确实是这样的。所有这些大家熟悉的技术都是设计来从损坏状况下恢复数据的。但是说得更精确的话,这些技术实际都是自愈数据,而不是自愈存储。他们在出现存储损坏的时候恢复数据并向应用掩盖存储的损坏——他们不会恢复那个损坏的硬件。

自愈存储的更准确定义是在出现损坏的时候透明地恢复数据和存储。这可能有点听起来像吹毛求疵,但其实这不是。这是治标和治本的区别。

磁盘失效的时候会发生什么

现代通常存储系统的标准公分母是硬盘。硬盘驱动器是整个存储系统中唯一的电磁设备,而且它具有最高的损坏率和最低的平均正常工作时间(MTBF mean time between failures)(参见:MTBF: 奇妙的失效)。大家公认的事实是,磁盘部件是存储系统的要害。

多数公司内空前的数据增长带来了存储系统和硬盘驱动器爆炸式的增加。统计表明随着磁盘数量的增加,磁盘损坏的数量也会随之增长,而这可能意味着数据丢失。对磁盘损坏的情形的分析显示出如下问题。

1.一个磁盘驱动器失效

2.磁盘必须被物理替换,或者通过手动替换或者通过在线的磁盘池。

3.针对不同的RAID组级别,磁盘的数据会在备用盘上重建。

     1.RAID 134561060都能依据数据校验和重建数据。

     2.RAID 0无法重建硬盘数据。

4.重建硬盘数据的时间随磁盘容量、速度和RAID类型而变化。

     1.一个使用RAID 51TB 7200SATA硬盘需要大约24-30小时来重建数据,前提是假设重建进程具有较高优先级。

     2.如果重建进程的优先级较低,并被指派为在空闲时段运行的后台进程,重建可能会需要8天。在重建的过程中,如果出现第二块盘失效和出现不可恢复的读错误,RAID组会有更高的的风险,这将导致数据丢失。这是因为校验数据需要从RAID组里所有盘里读出每个比特的数据才能重建数据。(除掉RAID6RAID60NEC美国公司的双校验RAID 3之外)。

     1.典型SATA驱动器的不可恢复读错误率为10^14:大约每100,000,000,000,000比特就会有1比特的数据出现读错误。这意味着一个71TB SATA盘的RAID 5磁盘组将有50%的可能性会重建失败并导致该磁盘组的数据丢失。

     2.企业级磁盘(光通道或者SAS)的不可恢复读错误率为10^15,也就是低于5%RAID 5磁盘组重建失败率。

     3.RAID 6避免了出现两块磁盘失败的时候丢失数据。为了安心你付出的代价是低于RAID 5的写性能,以及RAID组里一块额外的校验磁盘。

最后,磁盘驱动器会被送回厂家。根据《MTBF: 奇妙的失效》中的MTBF例子,这意味着每年会有越40次这种磁盘保修事件

多数的存储管理员知道磁盘被送回厂家之后会发生什么都会大吃一惊。经过厂家的一系列错误检测流程之后,结果是大多数的(在67%90%之间)失效磁盘驱动器都是未发现故障”——磁盘是好的。但是返修已经做了,而且RAID数据也必须要重建。对未发现故障来说,这就是白费气力。

未发现的数据损坏

磁盘的另一个很少被提及但却非常流行的问题是静默的数据损坏。静默的数据损坏是指存储系统中未被察觉也未被告知的错误,结果就是给应用的数据是损坏了的,而没有任何的告警、日志、错误信息、或者任何形式的通知。

多数的存储系统不会检测此类错误,而通常其发生频率是SATA硬盘为17个月内0.6%,企业级硬盘为0.06%(据存储栈中的数据损坏分析,” L.N. Bairavasundaram et al., 在加利福尼亚 San Jose FAST ’08大会上宣读)。在RAID没有发现例如错误或丢失写操作之类数据损坏错误的时候就会发生静默数据损坏。还有发生破碎的写数据的时候,最终的数据是新数据和旧数据的融合,而存储系统没有发觉或者没有尝试进行修复,这样也会发生静默数据损坏。

自主自愈系统

在这些新一代的系统中,有些使用了端到端的错误检测和纠正机制,能检测包括静默数据损坏在内的错误。另外的一些系统也使用相同的手段,但是加入了更加复杂的算法来尝试将失效的磁盘原地修复,从而避免进行RAID数据重建。最后一类系统则具备这些能力同时通过新的原地失效概念来增加筹码,也就是说当磁盘确实失效的时候(例如,无法继续使用),不需要对其进行替换操作就能进行RAID数据重建。

端到端错误检测和纠正

提供端到端错误检测和纠正的厂家和产品包括:DataDirect的带有OoSSATAssure Silicon Storage Architecture (硅存储架构S2A)EMC的带有Double Checksum双校验和的Symmetrix DMX-4;NECD系列支持美国标准组织新的企业级光通道或SAS硬盘T10 DIF (Data Integrity Field数据一致性域) 标准,以及他们自己的针对SATA硬盘的扩展DIF功能; Panasas 公司的ActiveStor带有SATA硬盘垂直校验功能; Sun 微系统公司基于 Zettabyte File System (ZFS)镜像卷的系统;以及Xiotech公司的 Emprise 5000 (又称Intelligent Storage Element只能存储单元),也是基于T10 DIF标准的 (参阅自愈系统产品”)

T10 DIF是一个较新的标准,只支持SCSI协议的硬盘(SAS或者光通道)(参见细看ANSI T10 DIF标准)。2009年和2010年计划发布的多款存储系统都计划支持这一标准。尽管如此,目前还没有针对SATA硬盘端到端错误检测和纠正的标准。这就是为什么EMCDataDirect网络和NEC都自己发展了各自的SATA端到端错误检测和纠正机制。

 EMC DMX-4使用的双校验技术和Oracle数据库里的经过实践检验能降低数据库损坏的双校验十分类似,DataDirect网络公司的S2A SATAssure技术在每次读操作的时候进行Reed-Solomon纠错计算,并将硬盘上的数据与校验和进行比较,来保证数据一致性。如果发现不一致,SATAssure会修复数据,然后将其发回给请求数据的应用程序并将其写回磁盘以避免更多的问题。所有这些都是实时完成的。

NECD系列EDIF基于ANSIT10 DIF标准。区别是EDIFSATA内置的IDE协议做了相应修改。

Panasas的垂直校验设计目的为保证单个磁盘的可靠性。垂直校验可以在RAID阵列察觉之前就在SATA磁盘上发现并修复磁盘磨损、丢失或者错位的写操作(通过使用水平RAID条带中的冗余信息)。

SunZFS现在使用于几种统一存储系统中(Sun 45007000系列,以及OnStor公司最新的Pantera LS 2100)。ZFS依靠自己的端到端错误检测算法来检测静默数据损坏,它需要镜像卷并通过从未损坏的镜像成员处拷贝数据来改正检测到的错误。

过去18个月间,来自用户的证据表明硬盘错误检测机制可以工作。对在关键业务中存储PB级数据的大型IT机构的寻访显示出很高的的满意度,这些机构包括政府实验室、高能粒子研究所、数字电影/视频制作与发行公司等,统计上来说,静默数据损坏很容易在这些地方出现。来自一位不愿透露姓名的IT经理的经典回答是:我再也不担心静默数据损坏了,它对我们已经不是个问题。

原位修复

传统的磁盘系统设计把出现坏磁道的磁盘标记为失效。而失效的磁盘会激发很耗时并影响性能的RAID数据重建。而且这种方式可能会很不经济,因为那块硬盘可能还有其利用价值。

原位修复系统通过一系列的自动修复流程来减少或者避免出现未发现磁盘错误一类的错误,以及随之而来的不必要而且消耗极大的RAID数据重建。

目前有五种系统提供原味修复功能:AtratoVelocity1000V1000),DataDirect网络的S2A系列,NECD系列,PanasasActiveStor,以及XiotechEmprise 5000。它们都提供经过检验的,albeit完全不同的原位修复技术。

Atrato把他们的 V1000使用的技术称为错误检测、隔离及恢复(FDIR)。FDIR持续监视部件和系统的健康状况,并辅以自诊断和自动修复。通过使用FDIRAtrato能够将SATA磁盘的表现和他们的通过对超过10万块SATA硬盘进行运行可靠性检测而得到的大量数据进行比对。FDIR使用基于那些海量运行可靠性检测历史数据、压力测试、以及失效分析而得到的判断方法来判断SATA硬盘的错误。然后它将使用Atrato虚拟化软件(AVS)来处理最新发现的磁道错误(暂时性或者永久性不可访问的不可修复的磁道)。AVS的自动后台磁盘修复通常能防止多数的类似错误。当其一旦出现时,AVS会以磁道为单位将其重映射到虚拟备用SATA硬盘上。这避免了出现坏道的SATA磁盘被强制进入永久性的完全失效状态,允许磁盘被恢复到完全正常的状态。

DataDirect网络的S2A的原位修复功能在移除失效硬盘之前会尝试多个级别的修复。首先它会保留对所有行为异常的硬盘的写操作记录,然后进行修复尝试。如果修复成功,只有一小部分的磁盘数据需要依靠写入记录进行重建。减少需要重建的数据能明显缩减重建时间,而且避免了返厂维修。

NECD系列Phoenix技术能检测磁道错误,并允许依靠RAID组内的其它磁盘继续提供服务。只要能分配替代扇区,硬盘就可以重新加入RAID组中继续工作,而不需要完全重建。Phoenix技术能保证检测和修复过程中的吞吐量性能。

PanasasActiveScan功能持续监视数据对象、RAID校验数据、磁盘介质和磁盘属性。当它检测到潜在的硬盘数据块问题的时候,数据会被转移到同一磁盘的备用数据块上。通过对硬盘SMART属性值的统计分析可以预测未来的磁盘失效,从而在产生失效之前对数据进行保护。当预测到磁盘失效的时候,用户可修改的策略机制能够先行将数据迁移到其它磁盘。这减少或消除了重构的必要性。

XiotechEmprise 5000(也叫ISE)架构能够主动或者被动提供存储的自主自愈。ISE的预防和修复性部件修复工作在它的封闭DataPac存储容量模块内部。它不需要手动抽出损坏的磁盘。ISE在需要的时候能提供自主数据迁移,重上电,工厂翻新和部件重调;相对于整个磁盘的重建,只有受到影响的磁头和已经分配的空间会通过快速的并行进程来进行重建。得到的结果等同于工厂翻新磁盘,只有无法修复的部件才会被退出服务。其它的部件都会被恢复到完全的功能和性能。

原位失效

原位失效是个比较新的概念,它的目的是解决存储系统中热拔插和热替换硬盘的一些问题。这些困难的副作用包括插入了错误的硬盘型号造成意外的数据丢失;替换失效硬盘不及时,造成重建被推迟而提高数据丢失的风险;或者使用了没有被测试过的备用磁盘,从而引起出现第二块磁盘失效。

原位失效的基本思路是将最小的现场更换部件(FRU)从硬盘重定义并扩大为存储组。一个存储组是一组协作的磁盘,他们有一部分的容量被预留做替换用途。失效磁盘通过分配的空间进行自动重建。

目前只有两个厂家提供原位失效存储系统:Atrato(他们的V1000)和Xiotech(他们的Emprise 5000ISE)。两套系统都支持端到端的错误检测和纠正,以及自主自愈。

两个厂家的产品架构都是基于将可用用户容量和机框作为单个现场更换部件的生命周期紧密联系的概念。机框的生命周期是指其内部的原始容量能提供给应用使用的时间段。机框的全部容量包括了其生命周期内预期需要的替换容量(Atrato三年而Xiotech5年)。

两种实现方式之间的区别则体现了他们不同的产品理念。通过他们的ORT,端到端错误检测和纠正,自主自愈,高密度机框,以及很巧妙的控制震动和热量的手段,Atrota2.5SATA驱动器变为企业级。他们通过在3U机框中集成160块磁盘来提高性能,单机框容量为80T,能提供12,500 IOPS1.5GBps吞吐量。

Xiotech则专注于用3.5寸和2.5寸企业级光通道和SAS磁盘提供更高的可靠性和性能。基本的现场替换部件DataPac3U空间中封闭了103.5寸或者202.5寸光通道或者SAS磁盘,提供最多16TB。每一个ISE有两个可替换DataPac,电源和散热部件,96个小时的备用电池以及主-主备份的RAID控制器。不像标准的存储子系统,ISE DataPac包括很多创新,包括一套复杂的降低震动和改善散热的方法;Xiotech充分开发了其所有部件内部结构来利用非常高级的磁盘和系统遥测技术。DataPac驱动器内置了特殊的固件,从而避免了其它存储系统中需要的设备兼容性问题。对DataPac内部tightly knit控制的结果就是得到了一个非常可靠的超级磁盘,其可靠性相对于典型的存储系统磁盘框有超过100倍的提高。(基于Xiotech208ISE及其内部的5900块磁盘历时15个月的测试,没有返修事件)

原位失效能工作吗?

AtratoXiotech已经证明原位失效是可以工作的。他们的产品测试和客户反馈表明这些技术能完全消除所有的更换磁盘的服务请求。这意味着更低的成本,更低的数据丢失风险和更少的应用中断。

自愈存储系统完美地解决了数据中心的实际运营问题。它减少了服务事件,成本,管理工作,数据丢失风险和应用中段。而更重要的是,它能工作。从现在起10年后,自愈系统将像现在的RAID一样被认为是最基本要求。

阅读(3055) | 评论(3) | 转发(0) |
给主人留下些什么吧!~~

ecloud2010-03-12 13:25:02

现在什么都智能了啊
CPu智能超频
磁盘只能修复

风之幻想2010-03-12 09:34:38

ziggler:

ziggler2010-03-12 09:22:12