免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: oncb
打印 上一主题 下一主题

[RAID与磁盘阵列] 44块盘做成raid6有什么风险? [复制链接]

论坛徽章:
0
71 [报告]
发表于 2009-07-27 17:22 |只看该作者
原帖由 spook 于 2009-7-27 13:49 发表
赞同1、2的计算方法。

单盘失效 同数据量的话,明显44块盘的Raid组重建时间要长很多,因为是Raid5 ,校验平均分布的方式。
==== ...


这里有个问题,难道4块1T校验就可以不平均分布吗?那如果我坏的不是校验盘呢?因此这个问题不是校验平不平均分布问题。

问题是,如果我坏了一块73G的盘,我只丢了1/42数据,最多只需要从已知数据中计算恢复73G的数据。而如果坏一块1T的盘,我损失了1/3数据,需要计算恢复1T数据。73G VS 1T,为什么前者要长很多?

重建的速度难道不是和涉及的数据量相关,而是和磁盘块数相关吗?

另外11块300G的答案和44块73G的答案是一样的吗?如果您是测过,能否翻翻笔记,给咱们一个量化的答案?

**其他人等能否消停一下,这个线索才真正回答LZ的问题。

论坛徽章:
1
天秤座
日期:2014-04-27 07:42:20
72 [报告]
发表于 2009-07-27 22:59 |只看该作者
原帖由 Cocal 于 2009-7-27 17:22 发表


这里有个问题,难道4块1T校验就可以不平均分布吗?那如果我坏的不是校验盘呢?因此这个问题不是校验平不平均分布问题。

问题是,如果我坏了一块73G的盘,我只丢了1/42数据,最多只需要从已知数据中计算恢 ...


raid5和raid6的校验数据是平均分布的,无论你用几个盘,恢复数据都要把其他盘上的数据读出来才能计算校验数据或者源数据的1/N.N越大,计算量也就越大,所以在超过一定数量后,单个raid盘越多,写入就越慢.恢复数据也同样.

论坛徽章:
0
73 [报告]
发表于 2009-07-28 07:01 |只看该作者
原帖由 A.com 于 2009-7-27 22:59 发表


raid5和raid6的校验数据是平均分布的,无论你用几个盘,恢复数据都要把其他盘上的数据读出来才能计算校验数据或者源数据的1/N.N越大,计算量也就越大,所以在超过一定数量后,单个raid盘越多,写入就越慢.恢复数据 ...


部分赞同.

重申一下方案:
方案1:43块73G的RAID5,按3T总容量计算;
方案2:4块1T的RAID5,3T总容量

分析如下:
1.重建计算量差异,对于方案1,需要读取2927G,XOR计算出73G,写入73G;方案2,读取2000G,XOR计算出1000G,写入1000G。从这里看,方案1重建的原始数据量为方案2的150%,方案1的计算结果为方案2的7%。重建过程中关注的数据输入量,每个输入的单位数据参与一次XOR计算,因此方案1的计算量为方案2的150%。
*"N越大,计算量也就越大"是不对的,计算量只和输入数据量有关,每单位输入数据,只需要参与1次XOR计算,至于输出多少,只和抽取计算结果的频率有关。
2.重建I/O差异,方案一和方案二的IO总量是一样的。并且写的速度要比读慢,考虑到方案1写入量实际为方案2的7%,方案1比方案2快。
3."单个raid盘越多,写入就越慢",这个观点缺乏依据,写入相同容量数据,计算量一样大,但方案1写入校验数据量为方案2的7%,因此性能上方案1要更高。

综上所述,是否能得出如下结论:
1.方案1性能比方案2有限度提高,磁盘利用率有较大幅提高。(73G/3T vs 1T/3T,但就如有朋友说的,现在容量这么便宜,要省这0.9T吗?呵呵)
2.方案1可靠性比方案2有较大幅降低,方案1的MTBF为方案2的9%左右。(此因素应该是导致方案1不被接受的主要原因)
3.方案1重建的确比方案2长,但方案1重建时间不应超过方案2的150%。(这个结论是否太保守?如果重建过程中计算和IO各占50%时间的话,这个幅度应该在130%甚至更低才对,是不是?)

主要考虑结论2,次要考虑1、3,方案1不是合理方案。

[ 本帖最后由 Cocal 于 2009-7-28 07:07 编辑 ]

论坛徽章:
1
操作系统版块每日发帖之星
日期:2016-02-18 06:20:00
74 [报告]
发表于 2009-07-28 10:09 |只看该作者
原帖由 Cocal 于 2009-7-28 07:01 发表


部分赞同.

重申一下方案:
方案1:43块73G的RAID5,按3T总容量计算;
方案2:4块1T的RAID5,3T总容量

分析如下:
1.重建计算量差异,对于方案1,需要读取2927G,XOR计算出73G,写入73G;方案2,读 ...

阵列数据块是很小的,而且不是连续分布的,校验块则相对较大,读写时候磁头移动很夸张,一组数据放在43块盘上,要读完42块盘的数据才能完成一个校验,只要一个没读出来,就都得等……

理想是美好的,现实是残酷的,你是干啥的?

论坛徽章:
9
技术图书徽章
日期:2014-10-14 15:48:13数据库技术版块每日发帖之星
日期:2015-06-04 22:20:00数据库技术版块每日发帖之星
日期:2015-06-10 22:20:00数据库技术版块每日发帖之星
日期:2015-06-11 22:20:00数据库技术版块每日发帖之星
日期:2015-06-13 22:20:00IT运维版块每日发帖之星
日期:2015-09-22 06:20:00IT运维版块每日发帖之星
日期:2015-12-08 06:20:00综合交流区版块每日发帖之星
日期:2016-02-02 06:20:00IT运维版块每日发帖之星
日期:2016-07-25 06:20:00
75 [报告]
发表于 2009-07-28 11:17 |只看该作者
原帖由 Cocal 于 2009-7-28 07:01 发表


部分赞同.

重申一下方案:
方案1:43块73G的RAID5,按3T总容量计算;
方案2:4块1T的RAID5,3T总容量

分析如下:
1.重建计算量差异,对于方案1,需要读取2927G,XOR计算出73G,写入73G;方案2,读 ...


计算量可以忽略不计,盘阵中磁盘数量过多,会导致盘阵内部总线带宽拥塞,降低阵列效能。
另外,盘阵中磁盘数量过多,容易崩溃,43块盘和4块盘相比,可靠性降低近两个数量级。

论坛徽章:
9
技术图书徽章
日期:2014-10-14 15:48:13数据库技术版块每日发帖之星
日期:2015-06-04 22:20:00数据库技术版块每日发帖之星
日期:2015-06-10 22:20:00数据库技术版块每日发帖之星
日期:2015-06-11 22:20:00数据库技术版块每日发帖之星
日期:2015-06-13 22:20:00IT运维版块每日发帖之星
日期:2015-09-22 06:20:00IT运维版块每日发帖之星
日期:2015-12-08 06:20:00综合交流区版块每日发帖之星
日期:2016-02-02 06:20:00IT运维版块每日发帖之星
日期:2016-07-25 06:20:00
76 [报告]
发表于 2009-07-28 11:19 |只看该作者
原帖由 spook 于 2009-7-28 10:09 发表

阵列数据块是很小的,而且不是连续分布的,校验块则相对较大


有这样的事么?

论坛徽章:
0
77 [报告]
发表于 2009-07-28 13:58 |只看该作者
持续关注中,学习中。
Johnny.He 该用户已被删除
78 [报告]
发表于 2009-07-28 14:30 |只看该作者
提示: 作者被禁止或删除 内容自动屏蔽

论坛徽章:
0
79 [报告]
发表于 2009-07-28 17:34 |只看该作者
原帖由 spook 于 2009-7-28 10:09 发表

阵列数据块是很小的,而且不是连续分布的,校验块则相对较大,读写时候磁头移动很夸张,一组数据放在43块盘上,要读完42块盘的数据才能完成一个校验,只要一个没读出来,就都得等……

理想是美好的,现实是 ...


我是一个无聊的人,看到有趣的事情插一嘴。

“阵列数据块是很小的,而且不是连续分布的,校验块则相对较大”,这是怎么说的?。
“读写时候磁头移动很夸张,一组数据放在43块盘上,要读完42块盘的数据才能完成一个校验,只要一个没读出来,就都得等……”,如果这样的话,42块盘性能一定没有4块的高,有违之前的结论,呵呵。

我也觉得现实很残酷,残酷到41楼网友说“看什么卡我这里promise的卡15块盘 30个小时 acer的24块 10多个小时”,不知道他的硬盘容量是多大的。

大家都说RAID高,到头来高多少,高的条件是什么,高的约束是什么,高的代价是什么?
只能经验来经验去,结果一锅粥似的。你看bbj老兄说运算量差异可以忽略不计,把我的结论推翻了,那么真相到底是什么?大家做技术的不能这么不讲究吧?

论坛徽章:
0
80 [报告]
发表于 2009-07-28 17:45 |只看该作者
说句不客气的话,有些人就是喜欢去搅和那啥,所有人都知道是那啥了你去跟它搅和什么。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP