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

作者: wwmb

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

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

作者: justgo

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

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

作者: kangbiao

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

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

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

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

作者: piner

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

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

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

作者: kamus

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

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

作者: piner

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

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

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

作者: zhaolinjnu

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

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

作者: 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.

作者: cc59

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

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

作者: snowfox-cai

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

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