如何才算真正意义上的条带化？

主机RS6000 存储为FastT700
首先对FastT7000的14块盘做成RAID0+1,分成4个LUN.对应到主机上是hdisk2-hdisk5.
然后为数据库ORACLE创建裸设备，使用以下命令。
mklv -y 'systemdbs'    -t 'raw' -a 'c' -e 'x'  datavg 32 hdisk2
最近从TOPAS上观测到waits很高，磁盘hdisk2-hdisk5都是100％busy。但KBPS却不大，4块盘加起来20M以内。

今天ORACLE的工程师说存储上可能没有真正实现条带化，查询了以下存储和AIX方面的文档，发现FAST在创建LUN的时候有个参数：segment size,默认是4K.
在操作系统上创建LV是有个选项stripe size,默认是no stripe。

我的问题是如果在创建LV是没有指定strip size，那是否意味着没有实现真正意义上的条带化？

不会把,你做RAID 0+1就是硬件条带,操作系统不用做stripe 了把

stripe有很多不好的地方，我近来还头痛着如何转回去。:L

os层stripe---把数据平均写到多个LUN上。
存储层---把数据平均分配到多个物理disk上。
os层做不做，看应用特性。

[quote]原帖由 [i]炸鸡[/i] 于 2006-3-21 14:20 发表
stripe有很多不好的地方，我近来还头痛着如何转回去。:L [/quote]

举例说明一下：）

除了维护上比较麻烦外，在性能是否有比较大的提升？

[quote]原帖由 [i]balefired[/i] 于 2006-3-21 15:19 发表


举例说明一下：）

除了维护上比较麻烦外，在性能是否有比较大的提升？ [/quote]
条带的读和写的性能都是对多块盘分块操作，比读写都在一块盘的性能肯定会提高

如果硬盘已经是做了raid5的逻辑盘，做stripe我觉得没意思，性能有降低的可能。这个我无法测试。

不过，维护上真的很麻烦。要扩大，一起扩，万一这盘上有其它的lv，大家的剩余空间不同，就 会浪费很多空间。我的环境是12块盘做stripe。好，当12块盘都满了的时候呢，你要继续这种方式的话，就要一下子加12块盘。有时想做migratepv，又会因为没有1个pp的空间而失败。当其中一块盘有问题的时候，相当于12块盘都有问题。上次有两个pv missing，结果要重新建立上面100多个lv。

的确,os上做stripe ,性能有提高也有限,维护太麻烦

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-21 15:18 发表
os层stripe---把数据平均写到多个LUN上。
存储层---把数据平均分配到多个物理disk上。
os层做不做，看应用特性。 [/quote]

如果只有一个阵列的话：
从控制器角度考虑，可以建2个以上的LUN，IO也可以分散在2条控制器路径上，但是当LUN多过2个的时候，这种分散就没有实际性能的意义了吧，就算IO分散到多个LUN上又有什么意义？反正是同一个阵列，两条路径，IO最后还是落回到控制器-硬盘上，绕了一圈还是同样的目的，写的时候多一次“切片”，读的时候多一次“组装”，费事。

如果有多个阵列的话：
这个问题就变了，在每个阵列的raid基础上，再在不同的阵列之间做os的stripe，把IO分散在不同的阵列上/控制器上，性能应该有不少改善，不过这就又引出了另一个问题，raid的方式、raid中磁盘数量、阵列控制器效率等等，这些都是厂家玩花样，但是我们无法测试的地方。

所以我觉得在阵列RAID基础上，再os做strip没有实际的性能意义，反而给维护带来巨大的工作量，实在是不值得，一家之见，欢迎板砖

刚见一实施方案，几个raid group，分了100多个lun，os上用的时候，讲什么分布，我都想拿刀砍人了。

當年的 人 已經走了,現在想砍人也沒對象.:'(

这个问题，要分很多方面来看，目前简单想到的是以下几个方面：
1、系统层的划分
2、存储架构（双控、交换架构）
3、应用对数据的访问形式
4、文件系统的构建方式

近期本来是对存储有测试计划的，但目前被别的事情耽误了，争取下周搞了之后再写点东西。
估计会有很多老大来仍宝石，填充精华，哈。。。

急需在服务器工程师中普及层次概念

软件工程师早已经有这个概念，太基本了
网络工程师要是层次概念不清，早就精神分裂了
只有服务器工程师层次概念不清还可以胡吃海混

[[i] 本帖最后由 larryh 于 2006-3-22 10:20 编辑 [/i]]

larryh老大教训的好，好多时候对这些东西就是层次不清，需要大家多讨论，才能提高呀。
半路出家，基础不好，就是缺陷。:L

楼上两位说的"层次“，属于同一个范畴吗

未知。惶恐中。
哈。
还好空调好，没有汗流浃背。

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-22 10:42 发表
未知。惶恐中。
哈。
还好空调好，没有汗流浃背。 [/quote]

也在流汗。。。。

等larryh老大赐教

:$好像是我理解错了

忍不住，偷偷先回一个，错了，大家就赶紧指正，哈。

假设os层分配了10个LUN，不考虑RAID级别，不做条带化，数据的读写方式如下：
数据写的时候先往第一个hdisk上写，写满之后再写第二个hdisk。

条带化后，数据的读写方式如下：
数据平均写到10块hdisk上。

以上两种情况下，往磁盘写的IO数目应该一致的,但条带化后的IOPS值高，写入耗费的时间低。（单个LUN性能有限）
当后端存储性能足够好的时候，性能可能差别不大（周末可以测试得到结果），但条带化后写入速度应该比非条带化快。

赐教不敢。只是个人感触。

昨天我回过一贴，怎么今天看不到了？给删掉了？

既撚做了raid 就不需要 os strip，那楼主的问题是出在哪儿呢？是segment size 4k太小了吗？ 或是系统本身就没调好？

没想到这个帖子会这么热闹。

关于这个问题，曾咨询了很多工程师，真是众说纷纭。

难道真如larry所说的“只有服务器工程师层次概念不清还可以胡吃海混”
:D:D

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-22 11:51 发表
以上两种情况下，往磁盘写的IO数目应该一致的,但条带化后的IOPS值高，写入耗费的时间低。（单个LUN性能有限）
[/quote]

条带化提高IOPS承受能力是讲物理硬盘的条带化的，跟LUN上LV条带化应该没什么关系吧。

我认为，LUN的LV级别条带化对如下条件同时达成时有用：
1、LUN平均分配在两个控制器上，可以充分利用控制器处理能力，避免控制器瓶颈
2、LUN的属性（主机端）设置不合理，比如命令队列太短，多个LUN分散负载可以提高整体效能

因为控制器是有大量缓存的，对在LUN上产生的IOPS的消化能力主要看控制器，除非访问过于随机，控制器Cache不能充分发挥整合多个LUN级IO到少数物理硬盘级IO的作用。如果那样，LUN上产生的IOPS直接就受限于物理硬盘条带化后的IOPS处理能力。

就是说：
如果不考虑OS在LUN级别处理上的问题（比如前面说的命令队列问题、控制器分配问题）：
[b]1、[/b]大量顺序操作的时候，[u]多个LUN忙（LV条带化）[/u]，控制器可以做碎IO（但数据区域其实是连续的）的整合，以充分利用物理硬盘层IOPS处理能力，看起来好像LUN级IOPS很高，但这是控制器做整合的功劳；[u]如果不用LV条带化[/u]，IOPS看起来少了，但每个IO数据量可以大了，控制器无需做整合工作，只需切割大IO，简单很多，并且让物理硬盘平均地忙，总体吞吐量（平均IO数据量×IOPS）甚至应该略有提高。
[b]2、[/b]大量随机操作的时候，控制器将没有多少整合碎IO的机会，这时候不管做不做LV条带化，总的LUN级IOPS应该接近物理硬盘IOPS的总和，每个IO的数据量受限于上层应用给出的，是个定数，不受LV条带化与否影响，因为没有或很少整合的机会（数据不连续）。所以我也看不到做LV条带化的必要性。

当然，以上看法基于LV条带化的segment size小于存储做物理硬盘条带化的segment size的情况（因为对AIX+FASTT来说，很多应该是这种情况）。如果是大于，那么对于顺序处理，总体表现应该像上述（1、）中的第二部分，随机处理跟（2、）类似。

[[i] 本帖最后由 larryh 于 2006-3-22 17:50 编辑 [/i]]