推广 热搜: APP  存储  设备  闪存  企业存储  交换机  华为  联想  思科  监控 

  • 匿名
点击 174回答 0 2015-08-01 00:00

小议RAID性能和安全性参数

待解决 悬赏分:0 - 离问题结束还有
小议RAID性能和安全性参数

随着 RAID 技术的不断推广,用户有时很难全面了解不同 RAID 级别具体表示什么意思。大多数人都知道 RAID 0 和 RAID 5 的含义,但了解诸如 RAID 60 和 RAID 5EE等其他 RAID 级别工作原理的人却寥寥无几。

>

不同的 RAID 级别对应于不同的性能、容量和可靠性,代表了这三种关键参数的不同平衡组合。

>

从最基本的角度来说,所有 RAID 级别均建立在 RAID 0、1、5 和 6 这几个基本 RAID 级别基础之上。一些 RAID 级别衍生出某些少见的变种,比如RAID 1E、5E 和 5EE,它们与 RAID 1、5 的特性相似,不过更丰富一些。

>

RAID级别可以相互组合或通过扩展,形成诸如 RAID 10、50和60 等 RAID 级别。人们往往对这种扩展的 RAID 级别不甚了解。不过,这些复杂的 RAID 级别添加了一些极其有趣的特性,比方说:

>

l R1E(2 个以上磁盘或奇数磁盘的镜像)

>

l R5E(与 R5 一样,但支持“热”备用磁盘容量)

>

l R5EE(与 R5E 一样,但每个条带都支持“热”备用磁盘)

>

需要进一步考虑的是 RAID 10、50 和 60 等复杂的 RAID 级别,它们提供了一些非常有趣的未知特性。它们基本上能提供相同级别、和尺寸的 RAID 卷组合,此外采用RAID 0 方式在他们之间分配条带化数据,以此平衡性能。

>

比方说,20个驱动器组成的RAID 50,可分成4个RAID 5阵列,每个阵列有5个磁盘,然后这四个RAID 5阵列之间采用RAID 0方式配置条带化数据。不过,问题在于,为什么要选择20个磁盘组成RAID 50这种复杂的RAID级别,而不用20个同样的磁盘组成简单的 RAID 5 呢?

>

主要原因在于,如果我们看看RAID 5的读取性能就会发现,在降级模式时其读取性能非常差。为了从坏块/死盘恢复数据,必须读取19个没问题的磁盘,并对每个磁盘进行18次XOR运算,而后才能返回数据。也就是说,这时的读取速度仅为正常读取速度的二十分之一,而且涉及的磁盘越多,读取性能就变得更糟。同样,重构也非常复杂。假设每个磁盘为1TB,如果重构的话,那么就需要移动20 TB的数据,XOR为19TB(这可能需要数周才能完成)。

>

不过,如果使用了RAID 50,丢失的数据可以由故障阵列重新生成。如果采用 5个磁盘阵列,那么只需要 4次读取和 3 次XOR运算就可返回数据,比RAID 5的效率提高了5倍。RAID 5只使用一个奇偶磁盘,而RAID 50每个扩展的磁盘阵列都使用一个奇偶磁盘,也就是每个扩展的磁盘阵列有 4个奇偶磁盘。由此可见,这时我们需要在容量和性能之间加以权衡。重构也一样,1TB数据的重构需要移动5TB数据,XOR为4TB,尽管这仍然需要很长的时间,但比 RAID 5还是缩短了4倍。

>

配置可能非常复杂,但只要我们大概了解到底需要解决哪些问题,就能针对不同应用确定采用哪种 RAID 级别最合适。说到底,肯定要在性能、容量和可靠性三者之间进行权衡取舍。

>

用户如何让RAID满足其特定需求呢?RAID是一种提供众多选项的复杂子系统。为了选择最佳选项,管理基础设施需要不断发展,帮助用户从以技术为主导的选择方式(也就是重点考虑 RAID 级别、条带大小、高速缓存模型等)向以解决问题为导向(也就是更多关心性能、安全性、读/写等)或专用解决方案(也就是针对 Microsoft Exchange或Oracle DB等具体应用的要求)方向转型。这样,用户就能集中精力思考解决方案本身,而不用为机械技术问题而苦恼。

>

随着数据的不断增长,RAID今后会为用户带来怎样的帮助?

>

考虑到RAID可管理大型卷,其使用肯定会不断扩展,RAID 使用户受益的领域包括:

>

l 可管理性(如上所述)

>

l 可靠性:对极大的磁盘来说,重构时间可能慢得让人无法忍受。上述新的 RAID 级别可最大限度地缩短重构时间。

>

l SSD 在存储器分层结构中支持全新设备类型,RAID 将由此受益。

>

来源:Watchstor.com

反对 0举报 0 收藏 0
网站首页  |  物流配送  |  关于我们  |  联系方式  |  使用协议  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  RSS订阅  |  违规举报  |  京ICP备14047533号-2
Processed in 0.019 second(s), 6 queries, Memory 1.2 M