在需要高带宽的应用里面，应该要小心谨慎的去分布那些涉及到跨越后端loop 的LUN，以便让所有后端的loop都能被用到。这有时可能会导致使用多个硬盘柜来组合。例如，一个系统需要在一个拥有8条后端loop的阵列（CX3-80或者CX700）上使用80个硬盘，那么我们应该需要把磁盘分布在8个磁盘柜以便让所有的后端的loop都能充分的使用到。
另外的，要用两个SP来实现负载均衡。要来达到这个目的，分配好SP的工作：对每一个LUN的默认的归属是专有的，这样确保了LUN能正常地访问一个SP。
当对一个ATA硬盘的RAID组分区的时候，让所有来自每一个RAID组的所有的LUN被一个单一的SP所拥有。
当作MetaLUN的计划的时候，注意所有的组成那个metaLUN的所有LUN的归属权，都会转交给那个对拥有base LUN的SP；他们原先默认的归属权将会被取代。因而，当作metaLUN的计划的时候，计划好SP A和SP B的LUN的资源池，以确保在SP间，所有的LUN的访问都是负载均衡的。 [编辑]
C． 系统和启动硬盘的影响
在CX系统系统里面，在第一个硬盘柜里的前5块硬盘，是被作为几种内部的工作的。
作为缓存的系统硬盘
0-4块硬盘是作为缓存的系统硬盘。缓存的系统硬盘在以下情况下会有重大的I/O的改变：
当系统关闭了写缓存的时候（把缓存里面的数据倒入到系统盘里）
? 当系统正在从一个停电中恢复过来（在此期
间没有主机的访问） ? 当系统盘正在rebuild（发生在系统盘的故障
后：硬盘0-4）
?
所有的这些情形都会在一个存储器故障的时候适用。
在主机访问时发生故障的主要的影响是写缓存被关闭了。如果写缓存被关闭了，整体性能会受到影响，主机的写操作会有一个更加长的相应时间（尤其对
RAID5）。而对系统硬盘的访问（包括读和写）速度，都会在把数据倒入系统盘的时候变得缓慢，而且这个dump的过程需要一段时间来完成。
31
因而，一个正在Rebulid的RAID组会非常的繁忙。（如果把Navisphere里的HA Vault的选项清除掉，那么影响会降少。在那种情况下，缓存在系统硬盘rebuild的时候仍然保持开启，代价是失去了对缓存中的数据的一小部分的保护。“The HA vault option and write cache behavior”章节会有更多的细节。）系统硬盘的重建比其他RAID组里的硬盘的重建更加重要，因为系统硬盘是一个校验保护的区域，所以所有系统硬盘在重建的时候都会非常的繁忙。同时，另外一些到FLARE数据库和PSM的系统访问仍可以继续。（看以下说明） 根据这些实际情况，我们推荐用户最好不要使用系统硬盘作为响应时间非常重要的数据，包括以下应用：
微软的Exchange 数据卷 ? 主机启动卷
? 群集的共享磁盘的卷
? 有较重负载的RDBMS目录表
?
如果系统是小的（30个硬盘或者更小），而用户也要求使用这些硬盘来作为中等程度到高负载的环境下的话（60 I/O每个硬盘或者更大），那么HA Vault这个选项应该被清除掉。
任何在系统硬盘里的数据LUN，在系统硬盘故障之后的写缓存的重新开启需要更多时间，这是因为数据的重建。这就意味着在阵列里所有的LUN都会在一个很长的时间里，忍受着非常糟糕的响应时间。 OS的启动硬盘
这前四个硬盘也被用作（存储控制器的）操作系统的引导和系统的配置。一旦系统开始启动，FLARE操作系统在引导分区很少有操作。所以，使用这些硬盘作为启动的设备，并不会影响主机的I/O。 FLARE 数据库硬盘和PSM
前三个硬盘也包含了FLARE的配置数据库系统和持久存储管理器（PSM），这是一个对配置数据的三镜像的保存。这些硬盘为性能方面做了一些考虑。
Navisphere使用PSM把那些在软件升级过程中被用到的数据装载入缓存之中。在软件升级过程中的繁重的主机I/O，可能会造成升级过程的中止联结，所以我们推荐在开始进行软件升级之前，主机的负载必须减少到每个硬盘100 IO/s。 因而，在这个三个硬盘里有非常繁重的主机I/O的情况下，会导致Navisphere命令的响应时间。因此，对于基于性能计划的考虑，建议把这些硬盘当作已经有一个LUN指定给他们。主机的I/O性能并不会受系统访问的影响，但如果这些硬盘已经有很重的负载的时候，可以通过分布数据的访问来确保Navisphere能得到好的响应时间。 [编辑]
32
D． 使用LUN和RAID组的编号方式
这个建议并不会帮助提高性能，但会帮助你管理好一个设计得很合理的系统。根据你的习惯使用RAID组的编号方式和LUN的编号方式。
例如，对LUN进行编号，因而可以让所有SP A拥有的LUN的编号都是奇数的，而所有SP B拥有的LUN的编号都是偶数的。
一种更加有效的方式是使用可预计的RAID组的编号方式，通过在RAID组号码后面增加数字来编号LUN的号码。这会更加容易的为metaLUN选择LUN。RAID组的号码包含在LUN里面，会让你可以从多个RAID组里面来选择LUN。（Table 3）
例如，如果要选用扩展成FLARE LUN 101编号的LUN绑定给一个metaLUN，选择编号201和301的LUN因为所有这三个LUN都属于同一个SP（metaLUN的所有组件都会转移到同跟Base LUN同属的一个SP上）。同样，新的metaLUN 101上的所有I/O，都会分布在三个RAID组里面。
在Table 3里面SP的分配计划被称之为AB的归属权，因为在每一个RAID组里，LUN交替地分配到SP A和SP B。 AB 归属权对FC和LCFC的硬盘有充分理由的，因为他们都是真正的拥有双端口；但这却非常不适于ATA硬盘，因为性能会受到ATA硬盘的单端口（多路复用）访问的严重影响，尤其是在高度带宽要求的应用。（这是一个原则性的原因：在Navisphere管理器里对RAID组的默认归属权的交替，是基于绑定时间，而不是基于LUN的交替，这也是过去所遵行的情形。）在一个RAID组里的AB归属权，并不能保证SP的利用率会得到平衡，尤其是当LUN分配到主机的操作已经完成特别是没有考虑预期的工作负载的时候。 [编辑]
E．最小化硬盘的竞争
33
因为硬盘的大小持续的增长，对RAID组分区也变得更加寻常，同时也让优化硬盘的性能变得更加困难。CLARiiON的设计是非常灵活的，而且可以提供非常好的性能，甚至是在硬盘个数有限的情况下。但是，对于高性能要求的环境，以下的指导方针是必须遵循的。 在生产过程中备份
跟生产并发的，要求顺序的读操作（在线备份）的环境，会从RAID 1/0的设置里得到非常好的性能，因为读操作可以分布在非常多的轴里面。在中度的负载如消息应用下，RAID 5也可以提供非常好的读的吞吐量。这些安排应该在部署之前作测试。当备份的时候，保持写操作充分的利用写缓存—如果缓存的flushes的优先级提高了，那么会降低读的访问速度。 保留的LUN资源池和clone的LUN
把保留的LUN资源池和将要作snap的源LUN放在同样的硬盘上，并不明智。写操作会导致非常高的寻道时间和非常差的性能。
同样的事情也会发生在clone LUN上面：把clone LUN和他们要clone的LUN放在不同的硬盘组里面。
一般来说，ATA硬盘并不推荐用作保留的LUN资源池和clone的RAID组。当他们工作在一些情形下，他们更差的性能会使他们成为瓶颈，尤其是当源LUN是绑定在光线通道的RAID组里面而且主机的写操作处在一个非常高的速度上。 [编辑]
F．Stripe和Stripe element的大小
stripe element的大小是128block或者64KB。没有任何的理由来改变它。 [编辑]
G. CLARiiON RAID 5的stripe优化
有时EMC的员工会推荐只使用4+1或者8+1的RAID 5。这通常是不必要的，而且通常是基于对CLARiiON RAID技术的不完全的理解。对大部分情形，用来绑定一个要求的硬盘的RAID组的大小，应该是基于要素，而不是基于性能。4+1/8+1神奇的主要根据是他们有stripe-write（带宽）的优化。
当整个stripe都被放置到SP的内存，而且校验是在fly里面计算的时候，校验的RAID的类型达到了他们最好的性能。这是被称为Full Stripe Write和常常在应用RAID5时被提及的Modified RAID 3（MR3）。要RAID5实现MR3优化的要求，有时候被误解了。许多EMC的员工相信CLARiiON RAID的优化只在4+1或者8+1模式下有效，而这是错误的----MR3可以跟任何大小的RAID5硬盘组下使用。
34
当一个I/O正好填充了一个RAID的stripe，MR3就发生了，无论是因为I/O很大而且和stipe对齐，还是顺序I/O一直在缓存里面直到他填充了这个tripe。但是，这个步骤仍然有以下的要求：
缓存的页面大小是4KB，或者，对于512KB或者更大的stripe，8KB或者16KB。
? stripe的element大小是64KB（128 block）
或者更小而且是8的倍数。
?
例如，对于12+1的RAID 5组和一个64KB的stripe element，stripe的大小是12*64 KB=768KB。对于MR3，必须使用一个8 KB或者更大的缓存页面大小，这是因为4KB的页面太小了。 [编辑]
H. 每一个RAID组的硬盘的个数
大于10个硬盘的RAID组会导致以下问题：
更长的rebuild时间（校验RAID）
? 更长的同步时间，因为处理器等待多个设备
来完成一个I/O
?
对于高带宽，避免使用非常大的硬盘组（大于10个）因为会有额外的寻道的延迟，因为所有的硬盘必须为同一个特定的I/O对齐。如果非常多的硬盘需要用来满足一个LUN的性能要求，最好使用更小硬盘组的metaLUN来实现。 大的轴的数量
跨越许多个硬盘的数据分布，对那些随机访问的，而且主机能产生足够多的并发的I/O来让硬盘保持满载的工作负载，是非常有效的。当应用有并发的处理或者线程，或者处理采用同步的I/O，那么高的并发访问是可以达到。
一个大的硬盘的数量可以允许并发的要求来达到独立性。对于随机的和爆发性的工作负载，stipe类型的metaLUN是一个理想的方法。由多个RAID组构成的MetaLUN在不同的时间里，都能理想的应对峰值。例如，如果几个RDBMS服务器共享RAID组，导致checkpoint的行为是不能设置成交迭的。 [编辑]
I．在一个存储系统里应该使用多少个硬盘
增加硬盘并不能线形地扩展工作负载，这就使性能会像上升后的一个平坦的曲线。这些都会在“sizing the storage requirement”里面谈及，但以下是严谨的最大化性能一些大体的方针。列在Table 4里面的硬盘的个数，是在不变的和从中等变为高负载的情形下，为并发的活跃的硬盘而设置的。
35