EMC存储最佳实践培训手册(共43页).doc

《EMC存储最佳实践培训手册(共43页).doc》由会员分享，可在线阅读，更多相关《EMC存储最佳实践培训手册(共43页).doc（43页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上BestPracticeFrom DOIT WIKIJump to: , 版权声明：EMC存储最佳实践R22的版权归美国EMC公司所有，。EMC存储最佳实践R22中文译稿可以转载，转载时请务必以超链接形式标明文章原始出处DOSTOR存储在线和作者与译者信息及本声明。 目录 o o o o o o o o o o o o o 一.关于性能的探讨性能调优有多重要呢？在一个Raid 5的阵列组中使用5-9块硬盘和使用默认的设置，CLARiiON光纤储系统能发挥极好的性能-这是EMC在性能测试实验室里测试自己的CLARiiON系统得出来的。 CLARiiON存储系统默认的设置

2、是为实际环境中遇到的大部分工作情形所设计的。但是，有一些工作情景还是需要调优来实现存储系统的最佳配置。 为什么在阵列组里用5到9块硬盘？这个设置并没有任何神奇的地方，也不是因为这个配置有什么特殊的优化。然而，Raid 5使用这个数量的硬盘确实是最有效的利用了校验，同时也能在合理的时间能重建数据。更小的阵列组会有更高的校验开销，而大的阵列组则会花更长的时间来重建数据。 这份白皮书探讨了在设计优化系统方面的时设计到的许多要素。请注意这里提供的信息是非常有帮助的，尤其当你充分理解了你的阵列的工作情形。因此，EMC推荐你使用Navisphere Analyzer来分析你的阵列的工作情形，并且要定期的复

3、习和回顾相关文档的基础知识。同时，请记住在配置一个阵列的时候很少有显而易见的选择，所以在有疑问的时候最好是按照默认的配置和保守的评估。 1.性能的定义以下的名词在整个白皮书当中都会用到。如果你对他们不熟悉，请回顾一下 EMC CLARiiON Fibre Channel Storage Fundamentals 带宽 校验 读取 随机 响应时间 要求数据大小 Request size 顺序 条带 条带元素 Stripe element 吞吐量 Write-aside 2.应用的设计应用的设计对系统的表现影响很大。提升性能的最佳方法的第一步就是应用的优化。任何存储系统的调优都不可能建立一个非常差

4、的应用设计上面。 A. 为顺序或者随机I/O的优化非常典型的一个例子是，提升带宽在顺序访问的调优方面会起显著作用，因为存储系统在顺序I/O方面会更加有效率-尤其是在RAID5的时候。而为随机访问的调优则要改善吞吐量和更快的响应时间，因为这样会改善处理顾客响应所花的时间。 读和写的对比写比读更加耗费存储系统的资源，这是基于CLARiiON对数据保护的机制的应用。写到write cache是镜像到两个存储控制器的（SP）。写到带校验的Raid Group会碰到校验运算的要求，而这也要求把冗余的信息写到磁盘里面。写到镜像的Raid Group会需要两份数据的拷贝的写入。 读的开销相对会小一些，这是因

5、为，从CLARiiON系统的读的吞吐量会比写的吞吐量要大一些。但是，对大部分工作情形来看，数据往往是写入write cache，这样会有更短的响应时间。读，在另一方面来说，可能命中cache，也可能不命中cache；而对大部分随机的工作情形来说，读比写会有更高的相应时间，因为数据还是需要从磁盘里面抓取。如果要达到高的随机读取吞吐量，需要更好的协作（concurrency）。 B. I/O 的大小每一个的I/O都有一个固定的开销和一个变量的开销，后者决定于其他的一些事情，例如I/O的大小。 大的I/O能提供更少的固定开销因为有着更大的数据。因而，对CLARiiON而言大的I/O比小块的I/O能提

6、供更大的带宽。如果有足够的硬盘，在执行大的I/O的时候后段总线的速度将会成为系统的性能瓶颈。小块的随机访问应用（例如OLTP）的瓶颈在于磁盘（的个数），而且很少达到后端总线速率。 当设计OLTP的时候，必须要使用基于磁盘（的个数）的IOP来衡量，而不是使用基于总线的带宽来衡量。 然而，在一个CLARiiON存储系统里面，当I/O到了某一个特定的大小的时候，包括write caching和prfetching都会被bypass掉。是决定用一个大的I/O请求还是把他分成几个顺序的请求，取决于应用程序和它跟cache之间的相互作用。这些相互作用在 “The Raid engine Cache”里会探

7、讨到。 文件系统也可以影响到I/O的大小，这也在稍后的“Host file-system impact”中描述到。 C. 暂时的模式和峰值的表现（temporal patterns and peak activities）应用的操作设计-如何去使用，什么时候去使用，什么时候需要去备份-都会影响到存储系统的负载。例如，用作随机访问的应用的存储系统，在备份和批量处理的时候，需要好的顺序性能。 一般来说，对OLTP和消息应用（任何跟大量随机访问I/O有关的），更高的并发处理能力（concurrency）会更好。当有更高的并发处理能力的时候，存储系统将会获得更高的吞吐量。使用异步I/O是一种获得更高的

8、并发处理能力的通常的手法。对带宽而言，单线程的应用几乎不能有效地利用四块硬盘以上带来的好处，除非request size是非常大的（比2MB大）或者使用到volume manager.当最佳的顺序性能达到的时候，而此时如果顺序处理到磁盘的路径是唯一的时候，用户还是可以从有适度并发随机访问的光纤硬盘（每个硬盘的I/O在100以下）的设置中获得一个可接受顺序性能。 3主机文件系统影响在主机层次，通过指定最小最大的I/O request size，文件系统也影响了应用I/O的特性。 A.文件系统的缓冲和组合（coalesce）跟在存储系统上的cache相似的是，缓冲是文件系统提高性能的一种主要方式。

9、 缓冲 在大部分的情况下，文件系统的缓冲应该最大化，因为这能减少存储系统的负载。然而，还是会有一些意外。 一般来说，应用自己来调配缓冲，能避免文件系统的缓冲或者在文件系统的缓冲之外工作。这是基于应用能更加有效的分配缓冲的假设之上。而且，通过避免文件系统的coalesce，应用更能控制I/O的响应时间。但是，正如在64位的服务器里RAM的容量将会提升到32GB或者更多，这也就有可能把这个文件系统都放在缓冲里面。这就能使读操作在缓冲下，性能会有非常显著的提升。（写操作应该使用写透（write-through）的方式来达到数据的持续性。） 结合Coalescing 文件系统的coalesce能帮助我

10、们从存储系统里获得更高的带宽。在大部分顺序访问的操作里面，用最大邻近和最大物理的文件系统设置来最大化文件系统的结合Coalescing.例如，这种处理方式可以和备份程序一起把64KB的写操作结合（coalesce）成一个完全stripe的写操作，这样在 write cache被bypass的情况下，对于带校验的Raid会更加有效果。 B.最小化I/O的大小：文件系统的request size文件系统通常都被配置成一个最小的范围大小，例如4KB，8KB或者64KB，这是提供给阵列的最小的不可分割的请求。应用使用的I/O在比这个范围大小要小的时候，会导致很多不必要的数据迁移和/或read-modi

11、fy-write的情形出现。这也是考虑应用和文件系统文件的最佳设置的最好办法。（it is best to consult application and file system documentation for the optimal settings）而request size没有被文件系统限制的Raw partitions，则没有受到这个约束。 C.最大化的I/O大小如果想要快速的移动大量的数据，那么一个大的I/O（64KB或更大）会更加有帮助。在整合（coalescing）顺序的写操作成Raid Group整个的stripe的时候，阵列将会更加有效率，正如预读取大的顺序读操作一样。大

12、的I/O对从基于主机的stipe获得更好的带宽而言也是很重要的，因为他们将会被基于srtipe的toplogy打散成更小的大小。 D.文件系统的fragmentation避免fragmentation和defragementation在一起，这是一个基础的原则。注意NTFS文件系统可能被分区成任何形式除了默认的范围大小，他们不能被大部分的工具所defragement：这个API（程序的接口）并不能允许这样做。执行一个文件级别的拷贝 （到另一个LUN或者执行一个文件系统的备份和恢复）是defragement的一个有效的实现。 跨越磁盘的小I/O在一些主机的类型里显得更加重要，而我们接下来将会探讨

13、为什么会导致这种状况。 当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响： a)有大比例的block size大于16KB的随机I/O b)Navisphere Analyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候（例如Exchange和Oracle），工作负载将会从对齐中获得一些优势。但因为I/O当中，小于6%（对于4KB）或者12%（对于8KB）的I/O都会造成跨盘操作（碰巧的是他们可能会以并行的方式来完成）。这种额外的收益可能很难在实践中注意到。但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移（offset）被注明，EM

14、C推荐使用操作系统的磁盘管理来调整分区。Navisphere LUN的绑定位移（offset）工具应该要小心的使用，因为它可能反而会影响分层的应用同步速度。 在Intel架构系统中的文件对齐 Intel架构的系统，包括windows2000/windows2003，都会受到在LUN上元数据的位置的影响，这也会导致磁盘分区的不对齐。这是因为遗留的BIOS的代码问题，BIOS里面用的是磁柱，磁头和扇区地址来取代LBA地址。（这个问题一样影响了使用intel架构的linux操作系统，正如windowsNT，2000，和2003。这个问题也一样影响了运行在intel硬件上的VMWare系统） fdis

15、k 命令，正如windows的Disk Manager，把MBR（Master Boot Record）放在每一个SCDI设备上。MBA将会占用设备上的63个扇区。其余可访问的地址是紧接着这63个隐藏分区。这将会后续的数据结构跟CLARiiONRAID的stripe变得不对齐。 在linux系统上，这个隐藏扇区的多少取决于boot loader和/或磁盘管理软件，但63个扇区是一个最常遇到的情况。对于VMware，位移（offset）是63。 在任何情况下，这个结果都为确定的比例的I/O而导致不对齐。大的I/O是最受影响的。例如，假设使用CLARiiON默认的stripe element 64

16、KB，所有的64KB的I/O都会导致跨盘操作。对于那些比这个stripe element的小的I/O，会导致跨盘操作的I/O的比例，我们可以通过以下公式来计算： Percentage of data crossing=(I/O size)/(stripe element size) 这个结果会给你一个大致的概念，在不对齐的时候的开销状况。当cache慢慢被填充的时候，这种开销会变得更大。aa F.校正对齐问题你可以选择以下的方法之一来修正对齐的问题。记住，必须只是两种方法之一： a.Navisphere LUN的对齐位移（offset） b.使用分区工具 对任何特定的LUN，只要使用其中一种，

17、不是两个。这个是我们经常要强调的。 同时，当设定一个metaLUN，只有那个base component需要分条的对齐（就是那个被其他LUN 挂靠上去的LUN）。如果使用LUN的对齐位移，当metaLUN建立的时候，metaLUN的对齐位移也被设置了。当扩展一个metaLUN，不需要再调整了。如果用了分区工具的方法，这个调整只需要在用户第一次对LUN分区的时候来做。 用什么方式来做 当没有基于主机的程序在使用的时候，我们可以使用LUN对齐位移的方式。LUN对齐位移方法对一些复制的软件操作，如clone sync I/O， SnapView Copy On Write opertions， Mi

18、rrowView sync I/O, SAN Copy I/O等，造成磁盘和strip跨盘的问题。 如果可以，使用基于主机的分区工具方式。 避免使用LUN对齐位移方法，假如你在这个LUN上使用了SnapView，SAN copy, MirrorView。相反， 应该使用基于主机的分区工具方式。 LUN的位移 LUN的位移方法使用把LUN偏移，来达到对齐stripe分界的分区。LUN从第一个RAID的stripe的末端开始。换一句话说，将LUN的位移设置成RAID stripe的大小，会让（紧接着MBR开始的）文件系统对齐了，如下图2所示。 LUN对齐位移的不足之处是它可能会造成任何要对Raw

19、LUN进行操作的软件的I/O请求的不对齐。CLARiiON 的复制会对raw LUN操作，如果LUN被位移了，这也会产生跨磁盘的操作。 Navisphere中，当LUN被bound的时候和block大小被设置成512byte的时候，位移会被设置成特定的。例如，在一个windows2003系统，将会把63个block设置为位移量。FLARE 会调整stripe，因此用户的数据就会从stripe的开头来开始。 图2： Intel MBR with partition and LUN offset correction 磁盘分区的对齐 基于主机的分区程序使用增加可设定地址的区域的起始部分，来校正对齐

20、的问题；因此，可设定地址的空间在RAID strip element的起始部分开始算起，或者在整个strip的起始部分。因为LUN从正常的地方算起，在RAID strip 的起始部分，复制软件操作也是对齐的。事实上，对于镜像操作，当secondary被写入的时候，primary的对齐是被保护了的，因为增加了的分区目录被写入了源LUN。 磁盘分区对齐和windows的系统 在Windows NT，2000，2003系统中，分区软件diskpar.exe，作为WRK（Windows Resource Kit）的一部分，可以用来设定分区位移的开始。你必须要在数据写入LUN之前做这件事，因为diskp

21、ar 会重新写分区表：所有在LUN上出现的数据都会丢失掉。 对于随机访问操作或者是metaLUN，在diskpart中设定起始位移的大小，跟对被用来Bind LUN的stripe element size的大小一致（一般128blocks）。对于高带宽要求的应用，设定起始位移的大小跟LUN stripe size的大小一致。 开始，用Disk Manager来获得磁盘的数目。在命令行中，使用diskpar加上-i的选项：diskpar -i x (新的大小是磁盘个数)来检查已经存在的位移： C:diskpar -i 0 Drive 0 Geometry Information - Drive

22、Partition 0 Information - StatringOffset = 32256 PartitionLength = HiddenSectors = 63 。 注意 HiddenSectors的值。这就是分区的位移的数值 1. 假如磁盘X有数据你不想丢失，那么备份那个数据 2. 假如磁盘X是一个Raw Drive，跳到第四部。 3. 删掉在磁盘X上所有的分区，使之成为一个Raw Disk。 4. 在命令行中使用diskpar -s X (X是磁盘个数) 5. 输入新的起始位移(单位sectors)和分区长度(单位MB)。这一步骤写入为那个磁盘写入新的MBR 和创建新的分区。在你

23、输入起始位移和分区大小，MBR就被修改了，而新的分区信息出现了。6. 在command prompt输入diskpar -i x (x为磁盘个数)来复查新近创立的分区上的信息。 64位windows系统 在64位的windows系统里面，如果按照默认创建，MBR类型的磁盘是对齐的；GPT分区也是按默认对齐，尽管他们有一个小的保留区域（32MB）是没有对齐的。 在linux系统中的磁盘分区调整 在linux中，在数据写入LUN之前对齐分区表(table)，因为分区影射(map)会被重写，所有在LUN上的数据都会毁坏。在接下来的例子里，LUN被影射到/dev/emcpowerah，而且LUN st

24、ripe element size 是128block。fdisk软件工具的使用方式如下所示： fdisk /dev/emcpowerah x # expert mode b # adjust starting block number 1 # choose partition 1 128 # set it to 128, our stripe element size w # write the new partition 对于那些会使用snapshot，clone，MirrowView的镜像构成的LUN来说，这个方法比 LUN对齐位移方法更加适用。这对SAN Copy中的sources和t

25、argets是一样适用的 对于VMWare的磁盘分区调整 VMware会更加复杂，因为会有两种情况存在。 当对齐raw disk或者Raw Device Mapping(RDM)卷，实在虚拟主机(VM)层次上来实现对齐的。例如，在 windows的虚拟主机上使用diskpar来实现对齐。 对于VMFS卷，会在ESX Server的层次上使用fdisk来实现对齐，正如diskpar在VM层次。这是因为不管是 ESX Server还是客户端都会把MBR放到LUN上面去。ESX必须对齐VMFS卷，而客户系统必需对其他们的虚拟磁盘。 对齐ESX Server： On service console,

26、execute fdisk /dev/sd, where sd is the device on which you would like to create the VMFS Type n to create a new partition Type p to create a primary partition Type n to create partition #1 Select the defaults to use the complete disk Type x to get into expert mode Type b to specify the starting bloc

27、k for partitions Type 1 to select partition #1 Type 128 to make partition #1 to align on 64KB boundary Type r to return to main menu Type t to change partition type Type fb to set type to fb (VMFS volume) Type w to write label and the partition information to disk 通过把分区类型声明为fb，ESX Server会将这个分区认为一个没有

28、被格式化的VMFS卷。你应该能够使用MUI或者vmkfstools，把一个VMFS文件系统放上去。对于Linux的虚拟主机，按照上面列出的程序步骤来做。对于windows的虚拟主机，也是按照上面的程序步骤来做。 G.Linux的I/O fragementing对于linux来说，避免对一个LUN上的多个大文件的并发访问是很重要的。否则，这回造成来自不同的线程的许多个访问，使用不同的虚假设备来访问同一个潜在的设备。这种冲突减少了写操作的coalescing。最好还是使用很多个小的LUN，每一个有一个单一的大的文件。 动态LUN的融合和偏移 如果你使用一个基于主机的分区工具来对齐数据，在你融合几个

29、LUN的时候，这个对齐也会被保留。这是假设所有LUN的LUN stripe size是一致的。假如Navisphere Bind Offset被融合的源LUN所使用，那么目标LUN，在bound用来调整stripe对齐的时候，必须要使用Bind Offset。 4.卷管理器Volume Managers对卷管理器的主要性能影响因素，是CLARiiON LUN使用了stripe的方式（我们所说的plaid或者stripe on stripe）。 我们要避免使用基于主机RAID而且使用校验（如Raid3，Raid5）的应用。这会消耗掉主机的资源来实现这一服务（校验保护），而这其实让存储系统来实现这

30、个服务会更加好。 图三显示了在以下章节中讨论到的三种不同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

31、 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

32、. Plaid 为高带宽的设置plaid在以下几个原因使用在高带宽的应用里面： plaid可以增加存储系统的协作（并行访问）。 plaid允许多于一个的主机HBA卡和CLARiiON的存储运算器（SP）共同为一个volume所用。非常大的卷可以被分布到多于一个的CLARiiON系统之上。 增加协作 Plaid在应用是单线程（也就是说，读一个单一的大文件）的时候会比较有用。如果应用的I/O的大小正好跟卷管理器的条带大小一致，那么卷管理器可以访问那些可以包装成卷的并发的LUN。 从多个存储器分布式访问 跨越存储系统，正如在图三的配置B里面所演示那样，仅仅当文件系统的大小和带宽要求需要这样的一个设计

33、的时候，才被建议使用。例如，一个30TB的地质信息系统数据库，要求的写的带宽超过了一个array所能达到的极限，将会是一个多系统plaid的候选者。必须注意的是，一个软件的更新或者任何存储系统的出错-例如因为一个存储系统上的一个组件的出错而导致的写缓存的停用-将会影响到整个文件系统。 D Plaids and OLTPOLTP应用是难以去分析，也难以去忍受一些热点。Plaids是一种有效的策略来使I/O从多个轴来分布式访问。一个可以让很多个磁盘处于忙碌状态的应用，将会从多个硬盘数中得益。 注意一些卷的管理建议小的主机stripe（16KB到64KB）。这对使用一种stripe的Raid typ

34、e的CLARiiON来说并不正确。对于OLTP，卷管理器的stripe element应该跟CLARiiON的stripe size（典型来说是128KB到512KB）。Plaid对于OLTP主要的开销，在于大部分的用户以跨plaid的方式结束。 跨plaid 磁盘-连同磁盘组-会变得更大；因此，用户也常常会因为好几个主机卷被同一个CLARiiON的Raid groups所创立（一个跨plaid看图三中的配置C）而结束。 这个设计的基本原理是在于以下的情况：对于任何一个卷组的随机行为的爆发，将会分布到多个磁盘上去。这个的不足之处在于测定卷之间的相互作用，是相当困难的。 但是，一个跨plaid也

35、有可能是有效率的，当以下情况存在的时候: . I/O sizes比较小（8KB或更小）和随机的访问 . 卷是受制于一天中不同时间的爆发，而不是同一时刻。 5. 主机HBA的影响用来实现主机附加的拓扑，取决于系统的目标。高可用性要求双HBA卡和到存储器的双路径。双路径对性能的影响，主要看管理者如何去从系统资源里得到负载均衡的能力。 在对存储系统调优的时候，必须牢记HBA卡和驱动的作用。EMC的E-Lab提供了设置磁盘和固件的建议，而我们必须要按这些建议来操作。 A. HBA卡的限制HBA卡的固件，HBA卡使用的驱动的版本，和主机的操作系统，都可以影响到在存储阵列中的最大量的I/O size和并发

36、访问的程度。 B. Powerpath如果操作系统可以使用，Powerpath这个软件应该总是要使用的-不管是对于一个单一连接到一个交换机的系统（允许主机继续访问，当软件升级的时候）还是在一个完全冗余的系统。 除了基本的failover之外，Powerpath还允许主机通过多个存储处理器（SP）的端口来连接到一个LUN上面-一种我们通常称之为多路径的技术。Powerpath通过负载均衡算，来优化多路径访问LUN。Powerpath提供了几种负载均衡的算法，默认的那种-ClarOpt-是我们所推荐的。ClarOpt可以调整传输byte的数量，正如队列的深度一样。 连接到所有目前的CLARiiON

37、的型号的主机，都可以从多路径中获益。直接连接的多路径需要至少两张HBA卡；实际的SAN多路径需要两张HBA卡，其中的每一个都会被分配到多于一个SP端口的区域。多路径的好处在于： 在同一个SP中，可以从一个端口failover到另一个端口，修复一个事件的系统工作。 在SP的端口和主机HBA卡中的负载均衡 从主机到存储系统中获得更高的带宽（假设主机里，路径能使用足够多的HBA卡） 当Powerpath提供了所有可行路径的负载均衡，这会带来一些附加的开销： 一些主机的CPU资源会被一般的操作所使用，正如会被failover的时候使用。 在一些情形下，活跃的路径会增加一些时间来failover。（Po

38、werpath在尝试几条路径之后，才会trespass一个LUN从一个SP到另一个SP） 因为这些事实，活跃的路径应该受到限制，通过zoning，到两个存储系统的端口对应一个HBA卡来影射到一个被主机绑定的存储系统。一个例外是，在从其它共享存储系统端口的主机所爆发的环境，是不可预知和严峻的。在这个情形下，四个存储系统的端口都有一个各自的HBA卡，这是可以实现的。 6. MetaLUNsMetaLUN是一个所有CLARiiON系列存储系统都特有的功能。我们从好几个方面来讨论什么时候和怎么用metaLUN。 A. 对比metaLUN和卷管理器在一个CLARiiON存储系统，metaLUN被当作一个

39、在RAID引擎之上的层，在功能上来说相似于主机上的一个卷管理器。但是，在metaLUN和卷管理器之间还是有很多重要的明显的区别。 单一的SCSI目标 对比 很多的SCSI目标 要创建一个卷管理器的stripe，所有构成的LUN必须设定成可以访问到主机的。MetaLUN要求只有一个单一的SCSI LUN被影射到主机；这个主机并不能看到组成这个metaLUN的多个LUN。这会让管理员在以下几个情形下得益： 对于因为OS限制而有受限制的LUN可用的主机 对于那些增加LUN导致SCSI设备重编号的主机；经常一个内核需要重建，用来清除设备的条目。 在这些情形下，使用metaLUN而不是卷管理器会简化在主

40、机上的管理。 没有卷管理器 不是所有的操作系统都有卷管理器的支持。MS的Server Win2000/2003 集群使用Microsoft Cluster Services（MSCS）并不能使用动态磁盘。MetaLUN是一个可以为这些系统提供可扩展的，stripe和concatenated（连接的）卷的解决方案 。 卷的复制 如果卷是要被使用SnapView，MirrorView或者SAN Copy的存储系统所复制的话，一个可用的镜像会要求持续的处理分离的能力。采用metaLUN会简化复制。 卷访问共享的介质 当一个使用了stripe或者concatenate的卷必须要允许在主机间共享访问，一

41、个卷管理器不能许可共享访问，而metaLUN可以使用并实现这个功能。MetaLUN可以在两个的主机存储组之间应用。 存储处理器（SP）的带宽 卷管理器的卷和metaLUN之间的一个重要的显著区别是，metaLUN是可以被一个CLARiiON存储系统上的一个存储处理器完全的访问。如果一个单一的卷需要非常高的带宽，一个卷管理器仍然是最好的方式，因为卷可以从不同的SP上的LUN上来建立。一个卷管理器允许用户访问存储器，通过很多个SP的集合起来的带宽。 卷管理器和并发访问 正如在“Plaids： 为高带宽设置”章节里指出的那样，基于主机的stripe的卷的使用，对于有多线程的大的request（那些有

42、多于一个卷stripe segment组成的request），会有比较高的效果。这会增加存储器的并发访问能力。使用metaLUN不会带来多线程上好的效果，因为component LUN上的多路复用是由存储系统来实现的。 B. MetaLUN的使用说明和推荐MetaLUN包含了以下三种类型：条带的(stripe)，结和的(concatenate)，和混合的(hybrid)。这个章节会做出几个通常的推荐。对那些想要更多细节的人来说，接下来的章节中将会定位建立metaLUN和相关每种类型的优点的策略和方法。 什么时候使用metaLUN 通过前面的卷管理器的讨论，应该在以下情形下使用metaLUN：

43、当大量的存储整合变得有必要的时候（每一个卷都需要非常多的很多磁盘） 当要求LUN的扩展的时候 当你建立一个metaLUN的时候，你可以控制以下的要素：component LUN的类型，metaLUN的类型，和stirpe multiplier（增加的）。 Component LUN 的类型 用来绑定在一个metaLUN上的LUN的类型应该能反映metaLUN上要求的I/O的形式。例如，使用在这份白皮书里面建议的各种不同的Raid 的类型（“Raid的类型和性能”提供了更多的信息），来匹配I/O的形式。 当绑定component LUN的时候，使用以下规则： 当为metaLUN绑定LUN的时候，

44、总是使用默认的stripe element size(128 block) 总是激活读缓存和写缓存 确保为component LUN设置的write-aside的大小为2048。（write-aside在“RAID引擎缓存”里面会被提到） 避免在RAID 5的磁盘组里使用少于4块的硬盘（或者说，至少是要3+1模式） 使用RAID 1/0 磁盘组的时候，至少使用4块硬盘（新的1+1并不是对metaLUN的一个好的选择） 不要使用component LUN位移来校正stripe的对齐。MetaLUN有他们自己的位移值。 MetaLUN的类型 一般来说，尽可能的使用stripe方式的metaLUN，

45、因为他们能体现出我们能预知的更好的性能。Concatenat一个单独的LUN给一个metaLUN，会更加方便；这可能在扩展一个对性能并不敏感的卷会更加合适。 Hybrid metaLUN使用stripe的方式捆绑concatenate的LUN。这个方式被用来克服stipe扩展的成本（这样会比较低）。一个采用stripe方式的metaLUN可以通过concatenate另一个stripe component的方式来扩展。这样保持了stripe component可预计的性能，也允许用户用来扩展一个stripe的metaLUN而不用队已经出线的数据的重组（性能将会受到影响，当重新条带化操作进行的时

46、候）。图四展示了这一点。 图四 hybrid-striped metaLUN 在理想的情况下，在扩展stripe设置的LUN将会分布在同样RAID类型的不同的RAID组里面，也会表现得更原始的stripe component一致。大部分最直接的方式是使用同一个RAID组作为基础的component。这个RAID组是被最先扩展的，以便使空间变的可用。这个方式在“metaLUN 扩展方法”里会演示。 RAID组的扩展是更加有效率的，对比metaLUN restripe（把这个重分条过程设置成中等优先级别），也会对主机性能有更小的影响。 MetaLUN stripe multiplier stripe multiplier决定了metaLUN的stripe element size: Stripe multiplier * base LUN stripe size = metaLUN stripe segment size MetaLUN stripe segment size是任何component LUN能收到的最大的I/O。 所有的高带宽性能和随机分布都要求metaLUN stripe element 的大小为1MB左右。而且，在下面的RAID组还可能被扩充。我们需要确保metaLUN stripe element是足够大，大到跟写的完全的stripe