评论: 数据文件分布之争，孰是孰非？

作者: David.Guo

David.Guo — Mon, 07 May 2007 14:28:43 +0000

我会采用第2种方法,因为我亲眼在济南电力看到因为我们的应用烂,导致把整个磁盘的io能力拖慢了,结果营销hant了,唉,营销可是别人收钱的,差点没搞死人,所以我是绝对的支持每个应用单独分开,即便自己因为艾滋挂了,也不要传染给别人.

作者: piner

piner — Mon, 07 May 2007 14:38:22 +0000

如果几个应用都差不多忙呢？
关键你这里有一个很烂，可以把别人整死。

现在有一个问题，就是，如果同样的应用，两种方式谁会快一些？

作者: David.Guo

David.Guo — Mon, 07 May 2007 15:03:42 +0000

同样的应用,我还是要选第2种方法,因为我感觉,这玩意在速度上应该差不多的说,因为你应用多,应该是经过了光纤交换机的了,如果磁盘都是raid10,两种方法感觉io速度应该差不多了,当然,可能是第一种会更好点,但是,有了那次我们把别人整死,然后客户差点整死我们的经历,我现在看到裹到一起的玩意,直接就有心理阴影了,最好分开,方便出事以后秋后算帐.

作者: randylin

randylin — Tue, 08 May 2007 02:50:10 +0000

其实我比较赞同的建议是每2个DB共用8个raid组，分成2组。这样管理会较第1种方案方便，IO会较第2种方案有所提高！这2个方案的比较感觉像是raid0和raid5的性能比较！

作者: piner

piner — Tue, 08 May 2007 03:53:25 +0000

[quote]其实我比较赞同的建议是每2个DB共用8个raid组，分成2组。这样管理会较第1种方案方便，IO会较第2种方案有所提高！这2个方案的比较感觉像是raid0和raid5的性能比较！[/quote]
呵呵，那其实还是规则1，我这里是引申到4个，实际情况可能是2个，3个？这些库访问的流量还不一样。
但是，不管哪种，他们都能跑，就是性能谁好的问题。

作者: mustapha

mustapha — Tue, 08 May 2007 12:01:06 +0000

还是用第二种，互相干扰很恐怖的，而且分开的话能多一些顺序io，性能也好点

作者: 八神苍月

八神苍月 — Tue, 08 May 2007 12:22:54 +0000

规则1相当于是HDS,规则2是EMC DMX3,两个产品谁好谁坏,碰撞了之后才知道,哈哈,使用bonnie++测试后发现EMC 3个迈塔的strip卷的离散读取速度不是太高,EMC的工程师也建议使用strip宽度可以增大,这样IO请求可以均摊到更多的盘片,从维护的角度,方法2是首选,性能角度,不知道怎么说

作者: piner

piner — Tue, 08 May 2007 13:02:03 +0000

HDS其实是主张规则2的,EMC是主张规则1的。

其实，今天跟另外一个人讨论到这个问题，他说，这个不就是在主机上LV级别上“条带与不条带”的问题吗？我想了想，引申过来的确就是这样。。。。。。
好比，在规则2，一个主机有4个RAID组，你是在lv上strip还是不strip呢？？？

测试结果是显示条带要好的，个人认为，不要走极端，现在一般的高端存储不怕热点读，因为可以命中，他们反而是希望读集中，这样命中率好。但是，如果不条带不能避免热点写不出现，因为写是cache不了的。

所以，选择一个合理的适度的方式？

作者: snowfox-cai

snowfox-cai — Wed, 09 May 2007 13:18:31 +0000

同样的应用,我选第2种方法,在这种有几个RaidGroup的存储来说,一般磁盘是足够的,磁盘IO一般不会是瓶劲了,两种方法在低负载的时候io速度应该差不多了,但是如果是负载比较高的情况下,反而第二种IO会好,因为第一种四个IO在同一个队列,IO之间争用的情况严重,反而会使整个存储的速度隆下来,而且从维护的角度来讲,第二种方式比较清爽,一般的Raidgroup 逻辑上的一些问题不会影响到另外的组.而且现在有些存储比如NetApp都是可以动态扩展的,所以空间分配的灵活性也不会成为问题

作者: cc59

cc59 — Wed, 09 May 2007 14:31:50 +0000

为了不相互干扰，我会选择第一种．

作者: zhaolinjnu

zhaolinjnu — Fri, 11 May 2007 03:35:48 +0000

其实以上两种方式可以看成是两种极端，我们可以综合以上两种方式的优点，如果db1,db2的应用相同，那我们在存储上让db1,db2共用raid组1-8,db3,db4因为应用不同，为了避免相互影响，db3用raid组9-12,db4用raid组13-16.

作者: zhaolinjnu

zhaolinjnu — Fri, 11 May 2007 03:48:59 +0000

这样分的好处是，如果db1,db2的应用出问题，那么负载将平均分到8个raid组的磁盘上面，而在正常情况下，由于数据不是分布的太分散，将有利于提高存储的cache命中率；db3,db4单独使用自己的raid组,也实现应用在存储上的分离，避免了相互影响,而此时数据也相当的集中，也可以提高高端存储的cache命中率。

作者: piner

piner — Fri, 11 May 2007 04:27:56 +0000

[quote]这样分的好处是，如果db1,db2的应用出问题，那么负载将平均分到8个raid组的磁盘上面，而在正常情况下，由于数据不是分布的太分散，将有利于提高存储的cache命中率；db3,db4单独使用自己的raid组,也实现应用在存储上的分离，避免了相互影响,而此时数据也相当的集中，也可以提高高端存储的cache命中率。[/quote]

其实，你这样，还是等于没有结果。

作者: kamus

kamus — Sat, 12 May 2007 10:19:59 +0000

这不就是我上次碰到的那个问题？上次我100多块盘在lv上又做了stripe，导致性能下降很多。
单纯就性能上来说，个人感觉如果4个应用都已经没有明显的性能问题，那么共用16个raid组是好的。

作者: piner

piner — Sat, 12 May 2007 11:37:24 +0000

[quote]这不就是我上次碰到的那个问题？上次我100多块盘在lv上又做了stripe，导致性能下降很多。单纯就性能上来说，个人感觉如果4个应用都已经没有明显的性能问题，那么共用16个raid组是好的。[/quote]

你的问题好象是一个raid组，与这个还没有关系。这里是多个raid组，一个raid组是不适合再做lv strip的。
那你是支持规则1罗？

作者: kangbiao

kangbiao — Sun, 16 Sep 2007 01:03:12 +0000

在你假设都为理想状态的时候，我选择2，因为便于管理，分清责任，因为在理想状态上，1和2之间在性能上应该所是没有太大的区别了。

但是在实际工作中，这种理想状态可能性不大，肯定有好有坏的，我还是选择2，理由还是便于管理。

在生产上稳定是第一位的，我想为了这个我还是愿意牺牲一些性能的。

作者: justgo

justgo — Mon, 21 Apr 2008 09:07:13 +0000

貌似就是metalun的问题，EMC会有很多理由说这种方式好。方法1是全部的盘都参与了，方法2是1/4的盘参与，单纯性能上讲，大吞量情况个人认为方法1是比较好的。
至于相互影响，方法2会不会也存在呢？毕竟两种方法有一个交叉点就是控制器，不过影响大小了

作者: wwmb

wwmb — Wed, 17 Sep 2008 03:17:06 +0000

选择两种的哪一种，需要依赖性能数据说话（从性能角度上）：
1，第一种，必须计算应用共享所有raidgroup后，LUN叠加的IOPS是否超过硬盘处理能力。每个raidgroup是否均衡。
2，第二种：单独应用使用一个raidgroup的IOPS与第一种比较。