前文再叙，书接上一回
4.卷管理器Volume Managers
对卷管理器的主要性能影响因素，是CLARiiON LUN使用了stripe的方式（我们所说的plaid或者stripe on stripe）。
我们要避免使用基于主机RAID而且使用校验（如Raid3，Raid5）的应用。这会消耗掉主机的资源来实现这一服务（校验保护），而这其实让存储系统来实现这个服务会更加好。
图三显示了在以下章节中讨论到的三种不同plaid技术
对于所有的情形，都会遵从以下规则：
A． Plaid 应该做的：
把主机管理器的stripe深度（stripe element）设成CLARiiON LUN的stripe size。你可以使用整数倍的，但最好还是把stripe element设定在512KB或者1MB。
简而言之，从基本的CLARiiON LUN上来考虑建立逐级管理器的stripe。
从分开的磁盘组来使用LUN；这个组应该有相同的参数（stripe size，disk count，RAID type，等等）。
B. Plaid 不应该做的：
千万不要在同一个RAID group里把多个LUN stripe（译者注：stripe和concatenate都是meteLUN的一种方式，下文中的英文部分的stripe都是特指这个）在一起。这是因为会造成大量的磁盘寻道。如果你从一个磁盘组需要捆绑多个LUN，使用concatenate来实现-千万不要使用striping的方式。
不要使主机的stripe element比CLARiiON的RAID stripe size小。
不要对那些具有不同RAID type和stripe size的RAID Group，或者根本不同磁盘组的LUN，使用plaid的方式在一起。结果并不一定是灾难性的，但很可能会出现未知的因素。
C. Plaid 为高带宽的设置：
plaid在以下几个原因使用在高带宽的应用里面：
plaid可以增加存储系统的协作（并行访问）。
plaid允许多于一个的主机HBA卡和CLARiiON的存储运算器（SP）共同为一个volume所用。
非常大的卷可以被分布到多于一个的CLARiiON系统之上。
增加协作
Plaid在应用是单线程（也就是说，读一个单一的大文件）的时候会比较有用。如果应用的I/O的大小正好跟卷管理器的条带大小一致，那么卷管理器可以访问那些可以包装成卷的并发的LUN。
从多个存储器分布式访问
跨越存储系统，正如在图三的配置B里面所演示那样，仅仅当文件系统的大小和带宽要求需要这样的一个设计的时候，才被建议使用。例如，一个30TB的地质信息系统数据库，要求的写的带宽超过了一个array所能达到的极限，将会是一个多系统plaid的候选者。必须注意的是，一个软件的更新或者任何存储系统的出错?-例如因为一个存储系统上的一个组件的出错而导致的写缓存的停用?-将会影响到整个文件系统。
D． Plaids and OLTP
OLTP应用是难以去分析，也难以去忍受一些热点。Plaids是一种有效的策略来使I/O从多个轴来分布式访问。一个可以让很多个磁盘处于忙碌状态的应用，将会从多个硬盘数中得益。
注意一些卷的管理建议小的主机stripe（16KB到64KB）。这对使用一种stripe的Raid type的CLARiiON来说并不正确。对于OLTP，卷管理器的stripe element应该跟CLARiiON的stripe size（典型来说是128KB到512KB）。Plaid对于OLTP主要的开销，在于大部分的用户以跨plaid的方式结束。
跨plaid
磁盘?-连同磁盘组?-会变得更大；因此，用户也常常会因为好几个主机卷被同一个CLARiiON的Raid groups所创立（一个跨plaid?看图三中的配置C）而结束。
这个设计的基本原理是在于以下的情况：对于任何一个卷组的随机行为的爆发，将会分布到多个磁盘上去。这个的不足之处在于测定卷之间的相互作用，是相当困难的。
但是，一个跨plaid也有可能是有效率的，当以下情况存在的时候:
. I/O sizes比较小（8KB或更小）和随机的访问
. 卷是受制于一天中不同时间的爆发，而不是同一时刻。
<未完待续>
