EMC CLARiiON 光纤通道存储
最佳实践
CLARiiON Firmware Release 13 Update (non-Confidential)
目录
一.关于性能的探讨 ................................................................................................................. 3
1.性能的定义 ................................................................................................................... 3 2.应用的设计 ................................................................................................................... 3 3．主机文件系统影响 ..................................................................................................... 5 4.卷管理器Volume Managers ...................................................................................... 14 5. 主机HBA的影响 ....................................................................................................... 17 6. MetaLUNs ................................................................................................................... 18 7.存储控制器的影响 ..................................................................................................... 28 8.RAID引擎的缓存 ........................................................................................................ 31 9.后端设备（磁盘的子系统） ..................................................................................... 36 二．为可用性和冗余做考虑 ................................................................................................. 47
1. 高可用性的配属 ....................................................................................................... 47 2. RAID-level的考虑 .................................................................................................. 48 3. 把RAID组通过总线和DAE绑定 ............................................................................. 49 4. 数据复制的持续性 ................................................................................................... 51 三. 评估存储的需求的大小 ................................................................................................. 52
1. 容量的计划 ............................................................................................................... 52 2. 性能计划 ................................................................................................................... 53 3. sizing例子 .............................................................................................................. 56 四. 结论 ................................................................................................................................. 57
一.关于性能的探讨
性能调优有多重要呢？在一个Raid 5的阵列组中使用5-9块硬盘和使用默认的设置，CLARiiON光纤储系统能发挥极好的性能----这是EMC在性能测试实验室里测试自己的CLARiiON系统得出来的。
CLARiiON存储系统默认的设置是为实际环境中遇到的大部分工作情形所设计的。但是，有一些工作情景还是需要调优来实现存储系统的最佳配置。
为什么在阵列组里用5到9块硬盘？这个设置并没有任何神奇的地方，也不是因为这个配置有什么特殊的优化。然而，Raid 5使用这个数量的硬盘确实是最有效的利用了校验，同时也能在合理的时间能重建数据。更小的阵列组会有更高的校验开销，而大的阵列组则会花更长的时间来重建数据。
这份白皮书探讨了在设计优化系统方面的时设计到的许多要素。请注意这里提供的信息是非常有帮助的，尤其当你充分理解了你的阵列的工作情形。因此，EMC推荐你使用Navisphere Analyzer来分析你的阵列的工作情形，并且要定期的复习和回顾相关文档的基础知识。同时，请记住在配置一个阵列的时候很少有显而易见的选择，所以在有疑问的时候最好是按照默认的配置和保守的评估。
1.性能的定义
以下的名词在整个白皮书当中都会用到。如果你对他们不熟悉，请回顾一下 EMC CLARiiON Fibre Channel Storage Fundamentals
带宽 校验 读取 随机
2.应用的设计
应用的设计对系统的表现影响很大。提升性能的最佳方法的第一步就是应用的优化。任何存储系统的调优都不可能建立一个非常差的应用设计上面。
A. 为顺序或者随机I/O的优化
非常典型的一个例子是，提升带宽在顺序访问的调优方面会起显著作用，因为存储系统在顺序I/O方面会更加有效率--尤其是在RAID5的时候。而为随机访问的调优则要改善吞吐量和更快的响应时间，因为这样会改善处理顾客响应所花的时间。
读和写的对比写比读更加耗费存储系统的资源，这是基于CLARiiON对数据保护的机制的应用。写到write cache是镜像到两个存储控制器的（SP）。写到带校验的Raid Group会碰到校验运算的要求，而这也要求把冗余的信息写到磁盘里面。写到镜像的Raid Group会需要两份数据的拷贝的写入。
读的开销相对会小一些，这是因为，从CLARiiON系统的读的吞吐量会比写的吞吐量要大一些。但是，对大部分工作情形来看，数据往往是写入write cache，这样会有更短的响应时间。读，在另一方面来说，可能命中cache，也可能不命中cache；而对大部分随机的工作情形来说，读比写会有更高 的响应时间，因为数据还是需要从磁盘里面抓取。如果要达到高的随机读取吞吐量，需要更好的协作（concurrency）。
B. I/O 的大小
每一个的I/O都有一个固定的开销和一个变量的开销，后者决定于其他的一些事情，例如I/O的大小。
大的I/O能提供更少的固定开销因为有着更大的数据。因而，对CLARiiON而言大的I/O比小块的I/O能提供更大的带宽。如果有足够的硬盘，在执行 大的I/O的时候后段总线的速度将会成为系统的性能瓶颈。小块的随机访问应用（例如OLTP）的瓶颈在于磁盘（的个数），而且很少达到后端总线速率。
当设计OLTP的时候，必须要使用基于磁盘（的个数）的IOP来衡量，而不是使用基于总线的带宽来衡量。
然而，在一个CLARiiON存储系统里面，当I/O到了某一个特定的大小的时候，包括write caching和prfetching都会被bypass掉。是决定用一个大的I/O请求还是把他分成几个顺序的请求，取决于应用程序和它跟cache之间的相互作用。这些相互作用在 “The Raid engine Cache”里会探讨到。
文件系统也可以影响到I/O的大小，这也在稍后的“Host file-system impact”中描述到。
式和峰值的表现（temporal patterns and peak activities）==== 应用的操作设计--如何去使用，什么时候去使用，什么时候需要去备份--都会影响到存储系统的负载。例如，用作随机访问的应用的存储系统，在备份和批量处理的时候，需要好的顺序性能。
一般来说，对OLTP和消息应用（任何跟大量随机访问I/O有关的），更高的并发处理能力（concurrency）会更好。当有更高的并发处理能力的时 候，存储系统将会获得更高的吞吐量。使用异步I/O是一种获得更高的并发处理能力的通常的手法。对带宽而言，单线程的应用几乎不能有效地利用四块硬盘以上 带来的好处，除非request size是非常大的（比2MB大）或者使用到volume manager.当最佳的顺序性能达到的时候，而此时如果顺序处理到磁盘的路径是唯一的时候，用户还是可以从有适度并发随机访问的光纤硬盘（每个硬盘的 I/O在100以下）的设置中获得一个可接受顺序性能。
3．主机文件系统影响
在主机层次，通过指定最小最大的I/O request size，文件系统也影响了应用I/O的特性。
A.文件系统的缓冲和组合（coalesce）
跟在存储系统上的cache相似的是，缓冲是文件系统提高性能的一种主要方式。
缓冲
在大部分的情况下，文件系统的缓冲应该最大化，因为这能减少存储系统的负载。然而，还是会有一些意外。
一般来说，应用自己来调配缓冲，能避免文件系统的缓冲或者在文件系统的缓冲之外工作。这是基于应用能更加有效的分配缓冲的假设之上。而且，通过避免文件系 统的coalesce，应用更能控制I/O的响应时间。但是，正如在64位的服务器里RAM的容量将会提升到32GB或者更多，这也就有可能把这个文件系 统都放在缓冲里面。这就能使读操作在缓冲下，性能会有非常显著的提升。（写操作应该使用写透（write-through）的方式来达到数据的持续性。）
结合Coalescing
文件系统的coalesce能帮助我们从存储系统里获得更高的带宽。在大部分顺序访问的操作里面，用最大邻近和最大物理的文件系统设置来最大化文件系统的 结合Coalescing.例如，这种处理方式可以和备份程序一起把64KB的写操作结合（coalesce）成一个完全stripe的写操作，这样在 write cache被bypass的情况下，对于带校验的Raid会更加有效果。
B.最小化I/O的大小：文件系统的request size
文件系统通常都被配置成一个最小的范围大小，例如4KB，8KB或者64KB，这是提供给阵列的最小的不可分割的请求。应用使用的I/O在比这个范围大小 要小的时候，会导致很多不必要的数据迁移和/或read-modify-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的时候，阵列将会更加有效率，正如预读取大的顺序读操作一样。大的I/O对从基于主机的stipe获得更好的带宽而言也是很重要的，因为他们将会被基于srtipe的toplogy打散成更小的大小。
D.文件系统的fragmentation
避免fragmentation和defragementation在一起，这是一个基础的原则。注意NTFS文件系统可能被分区成任何形式除了默认的范 围大小，他们不能被大部分的工具所defragement：这个API（程序的接口）并不能允许这样做。执行一个文件级别的拷贝（到另一个LUN或者执行 一个文件系统的备份和恢复）是defragement的一个有效的实现。
跨越磁盘的小I/O在一些主机的类型里显得更加重要，而我们接下来将会探讨为什么会导致这种状况。
当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响： a)有大比例的block size大于16KB的随机I/O
b)Navisphere Analyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候（例如Exchange和Oracle），工作负载将会从对齐 中获得一些优势。但因为I/O当中，小于6%（对于4KB）或者12%（对于8KB）的
I/O都会造成跨盘操作（碰巧的是他们可能会以并行的方式来完 成）。这种额外的收益可能很难在实践中注意到。但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移（offset）被注明，EMC推荐 使用操作系统的磁盘管理来调整分区。Navisphere LUN的绑定位移（offset）工具应该要小心的使用，因为它可能反而会影响分层的应用同步速度。
在Intel架构系统中的文件对齐
Intel架构的系统，包括windows2000/windows2003，都会受到在LUN上元数据的位置的影响，这也会导致磁盘分区的不对齐。这是 因为遗留的BIOS的代码问题，BIOS里面用的是磁柱，磁头和扇区地址来取代LBA地址。（这个问题一样影响了使用intel架构的linux操作系 统，正如windowsNT，2000，和2003。这个问题也一样影响了运行在intel硬件上的VMWare系统）
fdisk 命令，正如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 64KB，所有的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，只要使用其中一种，不是两个。这个是我们经常要强调的。
同时，当设定一个metaLUN，只有那个base component需要分条的对齐（就是那个被其他LUN 挂靠上去的LUN）。如果使用LUN的对齐位移，当metaLUN建立的时候，metaLUN的对齐位移也被设置了。当扩展一个metaLUN，不需要再调整了。如果用了分区工具的方法，这个调整只需要在用户第一次对LUN分区的时候来做。
用什么方式来做
当没有基于主机的程序在使用的时候，我们可以使用LUN对齐位移的方式。LUN对齐位移方法对一些复制的软件操作，如clone sync I/O， SnapView Copy On Write opertions， MirrowView 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 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 磁盘分区的对齐
基于主机的分区程序使用增加可设定地址的区域的起始部分，来校正对齐的问题；因此，可设定地址的空间在RAID strip element的起始部分开始算起，或者在整个strip的起始部分。因为LUN从正常的地方算起，在RAID strip 的起始部分，复制软件操作也是对齐的。事实上，对于镜像操作，当secondary被写入的时候，primary的对齐是被保护了的，因为增加了的分区目录被写入了源LUN。
磁盘分区对齐和windows的系统
在Windows NT，2000，2003系统中，分区软件diskpar.exe，作为WRK（Windows Resource Kit）的一部分，可以用来设定分区位移的开始。你必须要在数据写入LUN之前做这件事，因为diskpar 会重新写分区表：所有在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 Partition 0 Information ---- StatringOffset = 32256 PartitionLength = 40007729664 HiddenSectors = 63 。。。 注意 HiddenSectors的值。这就是分区的位移的数值 1. 假如磁盘X有数据你不想丢失，那么备份那个数据 2. 假如磁盘X是一个Raw Drive，跳到第四部。 3. 删掉在磁盘X上所有的分区，使之成为一个Raw Disk。 4. 在命令行中使用diskpar -s X (X是磁盘个数) 5. 输入新的起始位移(单位sectors)和分区长度(单位MB)。这一步骤写入为那个磁盘写入新的MBR 和创建新的分区。在你输入起始位移和分区大小，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 stripe 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和targets是一样适用的 对于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, execute \"fdisk /dev/sd 通过把分区类型声明为fb，ESX Server会将这个分区认为一个没有被格式化的VMFS卷。你应该能够使用MUI或者vmkfstools，把一个VMFS文件系统放上去。对于Linux的虚拟主机，按照上面列出的程序步骤来做。对于windows的虚拟主机，也是按照上面的程序步骤来做。 G.Linux的I/O fragementing 对于linux来说，避免对一个LUN上的多个大文件的并发访问是很重要的。否则，这回造成来自不同的线程的许多个访问，使用不同的虚假设备来访问同一个 潜在的设备。这种冲突减少了写操作的coalescing。最好还是使用很多个小的LUN，每一个有一个单一的大的文件。 动态LUN的融合和偏移 如果你使用一个基于主机的分区工具来对齐数据，在你融合几个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）的应用。这会消耗掉主机的资源来实现这一服务（校验保护），而这其实让存储系统来实现这个服务会更加好。 图三显示了在以下章节中讨论到的三种不同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或更小）和随机的访问 . 卷是受制于一天中不同时间的爆发，而不是同一时刻。 5. 主机HBA的影响 用来实现主机附加的拓扑，取决于系统的目标。高可用性要求双HBA卡和到存储器的双路径。双路径对性能的影响，主要看管理者如何去从系统资源里得到负载均衡的能力。 在对存储系统调优的时候，必须牢记HBA卡和驱动的作用。EMC的E-Lab提供了设置磁盘和固件的建议，而我们必须要按这些建议来操作。 A. HBA卡的限制 HBA卡的固件，HBA卡使用的驱动的版本，和主机的操作系统，都可以影响到在存储阵列中的最大量的I/O size和并发访问的程度。 B. Powerpath 如果操作系统可以使用，Powerpath这个软件应该总是要使用的—-不管是对于一个单一连接到一个交换机的系统（允许主机继续访问，当软件升级的时候）还是在一个完全冗余的系统。 除了基本的failover之外，Powerpath还允许主机通过多个存储处理器（SP）的端口来连接到一个LUN上面—--一种我们通常称之为多路径 的技术。Powerpath通过负载均衡算，来优化多路径访问LUN。Powerpath提供了几种负载均衡的算法，默认的那种 ----ClarOpt----是我们所推荐的。ClarOpt可以调整传输byte的数量，正如队列的深度一样。 连接到所有目前的CLARiiON的型号的主机，都可以从多路径中获益。直接连接的多路径需要至少两张HBA卡；实际的SAN多路径需要两张HBA卡，其中的每一个都会被分配到多于一个SP端口的区域。多路径的好处在于： 在同一个SP中，可以从一个端口failover到另一个端口，修复 一个事件的系统工作。 在SP的端口和主机HBA卡中的负载均衡 从主机到存储系统中获得更高的带宽（假设主机里，路径能使用 足够多的HBA卡） 当Powerpath提供了所有可行路径的负载均衡，这会带来一些附加的开销： 一些主机的CPU资源会被一般的操作所使用，正如会被failover 的时候使用。 在一些情形下，活跃的路径会增加一些时间来failover。 （Powerpath在尝试几条路径之后，才会trespass一个LUN从一个SP到另一个SP） 因为这些事实，活跃的路径应该受到限制，通过zoning，到两个存储系统的端口对应一个HBA卡来影射到一个被主机绑定的存储系统。一个例外是，在从其 它共享存储系统端口的主机所爆发的环境，是不可预知和严峻的。在这个情形下，四个存储系统的端口都有一个各自的HBA卡，这是可以实现的。 6. MetaLUNs MetaLUN是一个所有CLARiiON系列存储系统都特有的功能。我们从好几个方面来讨论什么时候和怎么用metaLUN。 A. 对比metaLUN和卷管理器 在一个CLARiiON存储系统，metaLUN被当作一个在RAID引擎之上的层，在功能上来说相似于主机上的一个卷管理器。但是，在metaLUN和卷管理器之间还是有很多重要的明显的区别。 单一的SCSI目标 对比 很多的SCSI目标 要创建一个卷管理器的stripe，所有构成的LUN必须设定成可以访问到主机的。MetaLUN要求只有一个单一的SCSI LUN被影射到主机；这个主机并不能看到组成这个metaLUN的多个LUN。这会让管理员在以下几个情形下得益： 对于因为OS限制而有受限制的LUN可用的主机 对于那些增加LUN导致SCSI设备重编号的主机；经常一个内核 需要重建，用来清除设备的条目。 在这些情形下，使用metaLUN而不是卷管理器会简化在主机上的管理。 没有卷管理器 不是所有的操作系统都有卷管理器的支持。MS的Server Win2000/2003 集群使用Microsoft Cluster Services（MSCS）并不能使用动态磁盘。MetaLUN是一个可以为这些系统提供可扩展的，stripe和concatenated（连接的）卷的解决方案 。 卷的复制 如果卷是要被使用SnapView，MirrorView或者SAN Copy的存储系统所复制的话，一个可用的镜像会要求持续的处理分离的能力。采用metaLUN会简化复制。 卷访问共享的介质 当一个使用了stripe或者concatenate的卷必须要允许在主机间共享访问，一个卷管理器不能许可共享访问，而metaLUN可以使用并实现这个功能。MetaLUN可以在两个的主机存储组之间应用。 存储处理器（SP）的带宽 卷管理器的卷和metaLUN之间的一个重要的显著区别是，metaLUN是可以被一个CLARiiON存储系统上的一个存储处理器完全的访问。如果一个 单一的卷需要非常高的带宽，一个卷管理器仍然是最好的方式，因为卷可以从不同的SP上的LUN上来建立。一个卷管理器允许用户访问存储器，通过很多个SP 的集合起来的带宽。 卷管理器和并发访问 正如在“Plaids： 为高带宽设置”章节里指出的那样，基于主机的stripe的卷的使用，对于有多线程的大的request（那些有多于一个卷stripe segment组成的request），会有比较高的效果。这会增加存储器的并发访问能力。使用metaLUN不会带来多线程上好的效果，因为component LUN上的多路复用是由存储系统来实现的。 B. MetaLUN的使用说明和推荐 MetaLUN包含了以下三种类型：条带的(stripe)，结和的(concatenate)，和混合的(hybrid)。这个章节会做出几个通常的推荐。对那些想要更多细节的人来说，接下来的章节中将会定位建立metaLUN和相关每种类型的优点的策略和方法。 什么时候使用metaLUN 通过前面的卷管理器的讨论，应该在以下情形下使用metaLUN： 当大量的存储整合变得有必要的时候（每一个卷都需要非常多的 很多磁盘） 当要求LUN的扩展的时候 当你建立一个metaLUN的时候，你可以控制以下的要素：component LUN的类型，metaLUN的类型，和stirpe multiplier（增加的）。 Component LUN 的类型 用来绑定在一个metaLUN上的LUN的类型应该能反映metaLUN上要求的I/O的形式。例如，使用在这份白皮书里面建议的各种不同的Raid 的类型（“Raid的类型和性能”提供了更多的信息），来匹配I/O的形式。 当绑定component LUN的时候，使用以下规则： 当为metaLUN绑定LUN的时候，总是使用默认的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，因为他们能体现出我们能预知的更好的性能。Concatenat一个单独的LUN给一个metaLUN，会更加方便；这可能在扩展一个对性能并不敏感的卷会更加合适。 Hybrid metaLUN使用stripe的方式捆绑concatenate的LUN。这个方式被用来克服stipe扩展的成本（这样会比较低）。一个采用stripe方式的metaLUN可以通过concatenate另一个stripe component的方式来扩展。这样保持了stripe component可预计的性能，也允许用户用来扩展一个stripe的metaLUN而不用队已经出线的数据的重组（性能将会受到影响，当重新条带化操作进行的时候）。图四展示了这一点。 图四 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一样，用来扩展component LUN（图表1）。 使用以下规则来设置stripe multiplier： 除非使用RAID 0，使用最少四个磁盘的磁盘组，来组成作为 component LUN主机的RAID组。 为磁盘组的大小来测定选择有效的磁盘个数。例如，六个磁盘的 RAID 1/0是3（3+3）。五个磁盘的RAID5是4（4+1） 通过图表1，为有效磁盘的个数而选择multiplier 如果有疑问，使用4作为metaLUN的stripe multiplier。对大部分情形来说，这是一个默认的，也是一个好的选择。 MetaLUN对齐的位移 如果你计划通过metaLUN来使用SnapView或者MirrorView，把metaLUN对齐位移值设为0。使用磁盘分区工具来调整分区的位移。 MetaLUN和ATA磁盘 在这个时候，ATA并不适合繁忙的随机I/O访问的方案。这个章节集中在使用ATA磁盘作为高带宽的应用。 保持RAID组的足够小，是metaLUN策略的一部分。这会使ATA硬盘更加合理，因为小的磁盘组比大的会有更小的重组时间。但是，必须意识到的 时，metaLUN会被一个单一的磁盘组的rebuild所影响，而ATA磁盘的rebulid时间是冗长的。基于数据可用性的考量，在非常多的环境里， 我们最好避免使用ATA硬盘来做metaLUN除非动态扩展或者需要非常大的一个容量。 CLI例子：建立一个metaLUN 在接下来的例子的代码，我们建立一个stripe方式的使用base LUN30的metaLUN。没有建立metaLUN的命令；你需要扩展一个已经出现的FLARE LUN来建立一个metaLUN。在命令中设计而成的LUN，都是相同RAID的类型和容量的FLARE LUN。LUN 30会变成基本的—新的metaLUN会把30作为他的identifier。 Matalun –expand –base 30 –lus 31 32 33 –name P1H00 –elszm 4 –type S 扩展的类型被设置成S，作为stripe方式，而选择element size（4）是因为LUN是建立在5块硬盘的RAID5组里面。 C. MetaLUN的扩充战略 对于有长期扩展计划的用户来说，有好几种使用策略。使用一种策略，你必须要确认你的目标。在接下来的章节会出现的一些可能的目标如下： 把本地的爆发的随机数据分布到多个磁盘上去 好的顺序/带宽的性能 有效的利用容量 灵活的扩展设备 这些都是使用metaLUN的用户的主要的目的。 扩展模式的初始化配置初始化安装的规则在图5中阐明。这些规则是： 为初始化容量部署，来部署所需要的磁盘 建立合适大小的磁盘阵列组： a. 对于RAID 1/0，使用4或6个硬盘 b. 对于RAID5或者RAID3，使用5个硬盘 把磁盘组按照每一个set有4-8个RAID组的方法来组织。（如 果要求高的随机I/O，那么需要更多的磁盘组） 对于每一个metaLUN，根据归属来确定Raid组的set。 对每一个计划要做的metaLUN，通过用RAID组在自己的RAID组 set里面的数目来分metaLUN的大小，来确定component LUN的大小。 从每一个在自己set里的RAID组里，为每一个metaLUN建立一 个component。 建立metaLUN的时候，请让组成这个metaLUN的LUN，跨越所有 的的RAID组set里的RAID组。 图5是一个set的metaLUN和他们的RAID组set的例子 Figure5. metaLUN里面的存储的初始化分布 注意到在图5，每一个metaLUN由一个对应一个RAID组的LUN组成。因此，每一个LUN的负载是分布在所有在那个set里的RAID组。但是，这些metaLUN是和对其他RAID组的set的数据访问是分隔开的。 为什么要使用RAID组的set？如果我们不允许一个metaLUN来扩展到自己的set以外，我们可以做出一定级别的隔离，将这种影响控制在磁盘的级 别。例如，一个RAID组的set可能为一大群文件服务器所设立，而另一个RAID组的set是为RDBMS的数据目录----这时一对普通的RAID1 组可能被使用作为RDBMS的日志设备。图6展示了这一点。 图6：用RAID组的set和metaLUN来做数据分隔的例子 在图6里面显示的例子，通过访问到NFS的共享metaLUN，并不会干涉到Oracle服务器访问他们自己的数据目录或者日志。 扩展模式的的扩展程序 下一步是建立扩展的策略。扩展的目标： 维持扩越很多磁盘的分布 更有效的利用容量 达致这个目标的途径 当容量对metaLUN来说是可以预计的，把磁盘增加到set已经出 现的RAID组里面。 对metaLUN里的set里面的RAID组进行扩展 对metaLUN里增加扩展的LUN作为一个新的stripe的component MetaLUN的扩展例子 这个例子里使用的途径，和metaLUN配置的原始的目标是紧密结合的----I/O分布在所有的磁盘上。 第一步，IS部门确定Meta A的容量使用率超过了他的警戒线—85%--同时也会告知用户要注意这个metaLUN。在周末的时候，IS接受一个外加160GB请求。这个系统的操作员增加2个磁盘，到metaLUN A 所在的set里的每一个RAID组。RAID组的扩展被设置成中等优先级别，这对性能影响会非常小。每一个组的存储增加了一个磁盘的容量（66GB），如图7所示。 图7. 对metaLUN的扩展：第一步 下一步是对metaLUN set的每一个RAID组绑定一个LUN。他们必须要扩展的总的容量是160GB，而我们在这个metaLUN set里面有四个RAID组，所以160/4=40。一个40GB的LUN必须限定在set里的每一个RAID组。 最后一部是使用 4个建立的LUN，来扩展metaLUN。操作员指派要被增加的LUN并且把扩展设置为concatenate的方式。因为扩展的LUN都是一样的大小，所以navisphere concatenate一个新的stripe的component到metaLUN，来组成这些LUN。（图8） 图8：MetaLUN的扩展：第二步 接下来的是一个CLI方式（命令行）的命令的例子：通过concatenate一个新的stripe component来扩展metaLUN。这个metaLUN的identifier是30。FLARE LUN 34，35，36，37都有一样的RAID的类型和容量： metalun –expand –base 30 –lus 34 35 36 37 –type c 扩展的类型被设置成C，代表concatenate的方式。Navishpere会以stripe方式把LUN捆绑成一个新的component，然后加到已经出现的metaLUN，metaLUN 30上面去。 基于LUN堆叠的metaLun 正如前面的例子那样，当从一个set的RAID组里建立多个metaLUN，掉转你为每一个metaLUN定位的base LUN里的RAID组。这可以把磁盘组里的数据库，文件系统，甚至是一个备份的过程里的hot edge分布开去，如图9所示。每一中颜色的stripe表示不同的metaLUN；每一个meta的base LUN在不同的RAID组里面。 图9：基于LUN堆叠的metaLUN 7.存储控制器的影响 这个章节指导用户怎样使用CLARiiON的硬件来匹配相对应的性能要求。 A． CLARiiON的存储控制器 EMC的CX系列阵列的存储控制器跟以前的型号不同的地方，是他们支持了连接到前端主机和后段磁盘的4Gb/s和2Gb/s的速度；事实上，在同一个存储 系 统，两种速度都可以实现。相对低端的产品，CX3-20和CX3-40，当使用了4Gb的硬盘的时候，在带宽方面的性能跟我们老的CX500和 CX700相对应。如果配置成2Gb的硬盘，会导致只有一半的可用的带宽，因而工作的负载应该在只升级SP的时候仔细的调研。基于磁盘的OLTP应用受到 后段的loop speed的影响很小，所以我们应该把大部分注意力放在备份和DSS的带宽状况尚。 CX3存储器家族的参数特点如下： 针对Rlease22的新的架构和调整，相当地改进了rebuild的时间。在（4+1）Raid5的测试中，如果没有负载的情况下，对hot spare的4Gb 15k 73G硬盘的rebuild大概需要30分钟，比CX700少了50%。如果持续的8KB随机负载（Read/Write=2 :1）占用了70%的磁盘利用率（典型的OLTP负载），则这个过程需要55分钟。吞吐量下降了大概50%。High，Medium和Low三种设置相对应的rebuild时间是6，12和18小时，这对主机的负载很小。 B. 磁盘的级别和性能 CLARiiON存储系统通常使用RAID5来做数据保护和性能的应用。当适当的时候，也会使用RAID1/0，但使用RAID1/0往往不是基于性能方面的考虑。我们可以通过CLARiiON Block Storage Fundamentals 白皮书来了解为什么RAID5会有更好的性能。 什么时候使用RAID5 消息，数据挖掘，中等性能的流媒体服务，和在DBA使用read-ahead和write-behind策略的RDBMS应用，使用RAID5是能获得比较好的性能的。如果主机的OS和HBA可以支持大于64KB的transfer的时候，RAID5是不二的选择。 以下的应用类型，使用RAID5是比较理想的： 有适度的IO/s-per-gigabyte要求的随机的工作负载 当写操作只占用了30%或者更少的工作负载时的高性能随机I/O 一个顺序访问的决策支持系统（DSS）的数据库（计算销售记录 的统计分析） 任何记录大小大于64KB和随机访问的RDBMS的目录空间（个人 的二元内容的纪录，例如照片） RDBMS的日志行为 消息应用 图像/流媒体 什么时候使用RAID1/0 在使用非常小的，随机的，和write-intensive 的I/O（其中30%的负载都是用来执行写操作）时，RAID 1/0在负载方面会比RAID 5更具有优势。一些随机的，小I/O的工作负载的例子： 繁忙的事务性的OLTP 大的消息的安装 实时的数据/业务记录 包含了经常更新的小的记录的RDBMS数据目录（账目平衡） 对一些特定的降级模式—--也就是，当写缓存被关闭或者在RAID组里面一个磁盘出现问题的时候，RAID 1/0也会有更好的表现。 什么时候使用RAID3 新的RAID 5的设计使每八个stripe后写入校验的磁盘，这样使RAID5也能像RAID3那样在顺序的工作负载中得到好处。RAID 5实质上可以达到RAID 3一样的带宽。 对于顺序写的工作负载，当以下三个要求达到的时候，RAID 3在配置里可以实现更高的读带宽： 1)磁盘个数决定了带宽（后段磁盘loop只有很少个数的磁盘） 2)文件很大（大于2MB） 3)文件没有打碎。 必须了解的是：对于许多的顺序的应用，从阵列得到的带宽，通常是取决于component的容量，而不是取决于像ATA的盘柜的BBC卡和/或后段loop的硬盘个数。在这些情形下（在任何有随机的工作负载的情形），最好还是使用RAID5来取代RAID3，因为RAID 3固定的校验盘会变成非顺序的工作负载中的component的瓶颈。 什么时候使用RAID 1 在R16里介绍了1+1 RAID 1/0的好处，我们没有任何好的理由来使用RAID 1。RAID 1/0 1+1模式是可以扩展的，而RAID 1模式则无法做到这一点。 8.RAID引擎的缓存 这个章节讨论了使用合适的缓存页面，如何使用预读取缓存的大小，在哪里设置警戒线，和其他的一些如SP的负载均衡等方面的技巧。 A. 缓存的大小和速度 在EMC CLARiiON Fibre Channel Storage Fundamentals 白皮书里面，对于cache大小对性能的影响，我们有全面的信息。 对于那些有1GB或者更少的可用cache 内存的存储器，使用其中的20%作为读缓存，把其余作为写缓存。对于其他所有的系统，使用最多的可允许的数值作为写缓存，而其他的作为读缓存。 Cache设置的脚本 在很多环境里，产品的工作负载对于一天的不同时间来说，变化是非常多的。例如，从8：00am到5：00pm工作负载可能会是OLTP居多；而从5 :00PM 到8：00PM，工作负载可能变成作为报告的多线程的顺序访问DSS；而从8：00PM之后，备份系统工作开始。如果需要为不同类型的工作负载调优，可用 Navisphere CLI的脚本来调整cache的参数。一些参数，例如SP的读缓存的开启/关闭，SP的读缓存的大小，LUN的读和写的缓存的开启/关闭，LUN预读取设 置，和警戒线的设置，都可以被不间断存储器工作的情况下被改变。另外，如SP的写缓存的大小和页面大小的调整，会要求SP写缓存被关闭，这个时间段会严重 影响写操作的响应时间，因而操作要尽快完成。 B. 缓存的设定 在CLARiiON存储系统里面，以下列出的缓存参数，都有适用于大部分用户的默认的设置。 缓存的开启/关闭 大部分工作负载都会从读缓存和写缓存里面得到好处；两者默认的设置是开启。 用来节省一个非常短的服务时间（当读操作到来时，检查缓存有无命中的毫秒级别），关闭LUN上的读的缓存并不会使系统性能受益。例如，有非常多随机读操作 的环境（没有顺序访问）的LUN，并不会从读缓存里受益。同样的，有很多同时的顺序访问的数据流（通常是DSS）的LUN，可以从关闭读缓存（或者关闭预 读取）来避免数据传输的“颠簸”。当同步的clone进行时，一些用户会关闭缓存来得到一个“中间”的带宽，即在尽快的模式和最小的SP利用率之 间取得平 衡。当准备为备份设置时，使用Navisphere CLI脚本来开启LUN的读缓存。写缓存是很有效的，除了最极端的写环境里面。写缓存的钝化最好是使用每一个LUN的write-aside的设置。（可 参考“write-aside的大小”）。 页面大小 在I/O的大小是非常稳定的情形下，你可以通过设置cache的页面大小跟存储系统所见的要求的大小（文件系统的block的小，或者在使用裸分区使用时的应用的block大小）一致，来获得性能。在有大量I/O大小的环境，8KB的页面大小是最佳的。 大量使用SnapView，MirrorView/A，或者增量SAN copy的系统，会从16KB的缓存页面大小设置中得益，因为内部的页面调度是使用64KB大小的block。如果应用的工作负载是由小block所支配的，警戒线应该设置到60/40。 当使用2KB的缓存页面大小设置的时候，要注意。使用多于5个的硬盘的，到校验RAID组的顺序写操作，可能会受到影响。“CLARiiON RAID 5 strip optimizations”里有更多的相关信息。 HA vault的选项和写缓存的行为 我们可以在存储系统的属性对话框里的Cache标号上找到HA Cache Vault选项，上面默认的设置是开启的。在EMC CLARiiON Fibre Channel Storage Fundamentals 白皮书上有关于这个默认设置方面的描述。 几种故障（在那个白皮书里有说明）会导致写缓存的关闭和把缓存上的内容导到系统硬盘里面（vault）。其中一种故障是系统硬盘里的一个磁盘。如果用户清除了HA Cache Vault选项，那么一个系统磁硬盘的故障就不会导致写缓存的关闭。因为关闭写缓存会显而易见地影响主机的I/O，所以要尽可能的让写缓存保持在开启的状态。因而，用户可以自己选择。 为什么这作为一个选择呢？清除这个选项，会导致顾客有可能遭遇到数据丢失的三种情形：假如一个系统硬盘坏掉了，那么数据将不会倒入。假如另一个系 统硬盘在 第一个坏的硬盘被更换之前坏掉，和系统遭遇了一个电力系统的故障，缓存里面的内容就会丢失。相类似的是，如果在初始化的系统硬盘坏掉了之后，又遭遇电力的 中断，然后第二个硬盘在数据倒入期间或者在随后出现故障，数据也会丢失。 用户需要在性能的提升和风险之间作一个决定。 预读取的设定 预读取（变量，segment和倍数都设置为4）的默认设置对大部分工作负载来说，都能有效地利用缓存。改变倍数会导致无法预计的结果；当顺序性能需要调优的时候，最好和CLARiiON SPEED专家一起使用。 高和低的水位线和flushing CLARiiON的设计有两种称之为水位线（watermark）全局的设置—--高和低----用来管理flushing。细节方面的内容，在storage fundamentals白皮书有叙述。对于大部分的工作负载来说，默认的设置（80%作为高水位线，60%作为低水位线）可以提供最好的性能。 如果写操作的爆发导致了足够多的flush，影响了主机的写的工作负载，那么需要降低水位线。降低水位线会导致更加剧烈的flush，这会让更多的空闲的 缓存页面来存放爆发的数据，这样的代价是从写缓存里读命中会更加的少。对于小一些的CX系统，降低水位线到60/40可以帮助降低flush的条件。 当改变的时候，高和低的水位线一般来说增加或减少同样的数量。 Write-aside的大小 write-aside的大小跟每一个LUN的设置有关。这个设置会指定会被载入缓存的最大的写请求。谢操作大于这个大小的，会不经过写缓存。 Write-aside使大的I/O不会占用了写缓存镜像的带宽，也让系统有可能得到超越了写缓存镜像的最大带宽。这个代价就是被旁路的那些I/O会比载入缓存的I/O有更长的主机相应时间。 要像得到超越写缓存最大带宽，则必须要有足够多的磁盘来承担这些负载。更进一步说，如果使用了带校验的RAID（RAID5或者RAID3），必须保证以下条件： I/O跟LUN的stipe大小一致或者是倍数 主机能生成足够的并发，来保证LUN保持在繁忙中 I/O对起stripe 达到Full Stripe Writes的要求（请参看“CLARiiON RAID5 stipe optimizations”） 这些条件对于带校验的RAID来说，是至关紧要的，而且是不能被轻易改变的。使I/O对齐来实现有效的write-aside并不容易。如果有疑问，还是使用写缓存。 使用write-aside的折衷如下： 数据像这样的写入，在缓存里为一个并发的读来说，并不是可用 的。 这样的写操作的响应时间比用缓存的写操作的响应时间要长。 必须要注意的是完全的SAN Copy是使用512KB的传输大小。默认的write-aside的值是2048 block或者1MB。因而，完全SAN Copy的写默认来说都是有缓存的。多个完全SAN Copy的操作可能会加重目标阵列的写缓存；在这个情况下，write-aside的值可以固定在1023block（511.5KB）或者关闭目标LUN的写缓存。注意，只有2+1，4+1，和8+1 RAID 5或者4+1和8+1 RAID 3的拓扑能在这种情况下得到完全stripe写的好处，提供没有LUN绑定的位移。 Navishpere CLI getlun 命令可以显示一个LUN的write-aside的大小。要改变write-aside的大小，使用Navisphere CLI chglun command。 在两个SP（存储控制器之间）取得负载平衡 我们把LUN分布在两个SP上，以便让两个SP上的工作能取得负载均衡；这避免以下这一情景的出现：当一个SP有很多的空余的能力的时候，而另外一个SP却成为瓶颈。Navisphere Analyzer可以用来监测负载的不均衡。 9.后端设备（磁盘的子系统） B. LUN的分布 使用LUN的分布的主要目的在于： 后端总线涉及到一对所有CLARiiON存储系统都用来访问硬盘的 冗余的光纤loop（一个对应一个SP）。（一些CLARiiON存储系统有一对后端总线----总共4条光纤的loop，有些有4条后端的总线） 一个RAID组会分成多个LUN，或者说，一个来自于这样的一个 RAID组的LUN，会被分别称之为分了区的RAID组或者分了区的LUN。 一个只有一个LUN的RAID组被称之为专有RAID组或者专有LUN。 如果要更有效的把I/O分布在光纤硬盘上，把LUN分布在多个RAID组上面。当作LUN的分布的计划的时候，把LUN的容量列个账目。计算经常要访问的存储的容量，并把容量适当的分布在RAID组里。 在需要高带宽的应用里面，应该要小心谨慎的去分布那些涉及到跨越后端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的过程需要一段时间来完成。 因而，一个正在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能得到好的响应时间。 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．最小化硬盘的竞争 因为硬盘的大小持续的增长，对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硬盘组下使用。 当一个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里面的硬盘的个数，是在不变的和从中等变为高负载的情形下，为并发的活跃的硬盘而设置的。 J. 硬盘的类型和大小 目前来说，CLARiiON系统可以使用以下的硬盘类型和大小： 10000rpm的光纤通道硬盘（73，146，300GB） 15000rpm的光纤通道硬盘（73，146GB） 5400rpm的ATA硬盘（320GB） 7200rpm的SATA硬盘（250，500GB） 7200rpm的低成本光纤硬盘（500GB） 硬盘大小的影响 尽管硬盘生产厂商都宣称更新的，更高容量的硬盘可以获得更高的传输率，但在硬盘和主机之间的协议层次，还是会使硬盘内部的传输速率和主机访问速率隔绝开来。简而言之，这个影响是非常小的。 一个对性能有着深刻影响的是，硬盘的大小影响了在指定的容量里的轴的数目。每gigabyte更少的轴等于更低的性能潜力。就硬盘而言，硬盘的转速和技术比硬盘的容量更加重要。 例如，用300GB容量的硬盘，CLARiiON的速度（performance guru）会被经常问道：300GB硬盘的性能怎样？回答：跟其他10K rpm的光纤硬盘几乎一样。但是，因为性能跟轴的数量有关，用户选择硬盘的时候，必须要计算他自己的性能要求，就像他要考虑容量需求一样。 转速 对于同样的硬盘技术，更高的转速会带来更好的性能。更高的转速会让硬盘的寻道时间线形的减少。此外，更高rpm的硬盘也包括了横向的寻道速度的提升。传输率跟着rpm提高，尽管硬盘的缓冲和光纤硬盘协议限制了这些硬盘实际的传输率。 光纤通道硬盘 光纤通道硬盘是企业级的设备。他们拥有在硬盘上的固件，可以对队列的重新排列，缓冲，和高级的寻道优化。许多巧妙的设置能让他们处在一个桌面级别硬盘标准达不到的层次。转速对光纤通道硬盘的速度由非常大的影响，因为这些硬盘可以非常有效的提升轴的速度。 对于随机的读的性能，一个更快的转速意味着更小的延迟，因为缓存不能缓冲随机的读操作。对于随机的写操作，他们首先会写入SP的写缓存里面，更高转速的影 响是更快的cache的刷新。拥有更快的刷新的缓存可以让存储系统有更高的I/O传输率，避免了达到水位线，而且强迫刷新可以让服务时间增加。 结果是，当系统的随机负载达到了最高负荷的时候，15K rpm的硬盘提供了大概20%-30%的真实世界里的性能提升。顺序的操作系统业可以得到一些提升，但影响会相对较小。 在DAE里使用不同的硬盘种类 ATA硬盘和光纤硬盘是不可以混插在同一个硬盘柜里。 在一个硬盘柜里可能会混插不同速度的硬盘。如何摆放成了一个计划的大问题。如果一个系统系统使用不同容量和/或者不同速度的硬盘（例如，146GB和73GB，或者10K和15K）在同一个硬盘柜里，那么EMC推荐你们把他们摆放在一个逻辑的顺序，如以下所说： 把容量高的硬盘放在最先（最左边的）的槽里面，然后再放更低 容量的硬盘。 必须注意的是，在一些对带宽敏感的应用里，把2Gb/s的接口硬 盘放到一个都是4Gb/s硬盘的总线上的时候，会把整体的总线速度降低到2Gb/s,这肯定会影响到性能。 ATA硬盘和RAID的层次 ATA硬盘在使用RAID3的时候，对于带宽敏感的应用表现良好。对于随机的I/O和不同步的光纤LUN的clone，要使用RAID 1/0。RAID 5并不推荐来做这些应用，因为随机写操作需要更高的硬盘负载。“ATA drivers as mirror targets and clones”提供了更多的细节。 RAID组的分区和ATA硬盘 当对ATA硬盘的RAID组分区的时候，最好把那个RAID组里的所有LUN都分配到同一个SP上。这会让这些硬盘得到最高的带宽。（而这对光纤硬盘并不是一种要求。） ATA硬盘作为镜像的目标和Clone ATA硬盘并不适合作为clone和MirroView的目标。当显示工作负载已经可以被ATA性能要求所满足的时候，他们在一些情形下可以被使用。数据恢复存储站点的性能，应该跟primary 站点的一致，因而ATA硬盘只有在primary站点使用ATA存储的时候，才可使用。小心的计划一个数据恢复站点，包括足够的性能表现和长期的业务。 当作为clone或者mirror的目标的时候，ATA硬盘的性能影响必须详细地考虑和注意一些细节。当使用同步模式的时候，ATA会收到主站点的所有的 写操作，但对他们的刷新会比较慢，所以这回造成写缓存上的更多的负载。当同步的时候，他们会有并发的写的负载加上同步的负载，这会进一步对缓存造成压力。 因此，任何针对在同步的ATA硬盘读操作，都会造成竞争，而且会导致更低的顺序读的速度和更慢的缓存刷新。周期性的更新，例如 MirrorView/Asynchronous，会在更新的时间内装载到缓存里面。 在一个并没有受到很大压力的系统（例如，写缓存并没有达到刷新水位线），使用ATA硬盘作为目标，比光纤硬盘对比，会有一个适度影响的性能表现。保持对ATA硬盘的I/O负载，在低于Table 6所给定的描述下。应该要对系统作一个监控，来确保使用ATA的目标，不会使缓存的利用率持续的处在高水位线。 在一个已经有非常重的缓存的负载的系统里，建立在ATA硬盘上的一个同步的应用或者一个clone的建立，都可能造成写缓存被填满。这会造成对其他正在写入的LUN的强迫性地刷新—--会对系统里的其他LUN造成负面的影响。如果Navisphere Analyzer显示长期的处在100% dirty page，ATA的工作负载应该是首要怀疑对象。独立的ATA LUN上的写缓存可以被关闭，这是作为一种在二选一环境（更多的硬盘，不同的RAID的类型，或者迁移到光纤硬盘）下的一种控制手段。 类似的，使用ATA硬盘作为对光纤通道primary的镜像目标，在目标的缓存会比源的缓存，更加慢地被刷新（这是因为使用了更慢的硬盘）。目标系统的缓存必须被监控，因为强迫刷新，会导致对镜像写做操作的响应时间的增加。同步 的MirroView和增量的SAN Copy也会对目标有随机的I/O写入，所以在做这些任务的时候，也要仔细的考虑使用ATA硬盘。 请参考以下白皮书，以了解复制技术的细节。 Rlease 19：updates for CLARiiON Replication Software 低成本的光纤硬盘（LCFC） LCFC硬盘在容量，寻道时间和转速上面，跟ATA硬盘类似。LCFC有光纤通道的接口，所以他们可以和其他光纤硬盘放在DAE里面。LCFC开启了命令 队列和寻道优化，所以他们的性能介于FC和ATA之间。LCFC适用于相对较低的工作负载需求，包括适度的数据库，文件共享，归档，和备份。当工作负载有 比较高的并发的时候，他们可以提供非常好的吞吐量，就像其他光纤硬盘；但他们更长的访问时间，在队列变得大的时候，会导致更长响应时间。因为LCFC硬盘 能提供命令队列的能力，所以他们会比ATA更使用于snap，clone，mirror和增量SAN Copy的目标，但仍然不如FC硬盘，后者还是一种可选的硬盘。此外，LCFC对于随机的吞吐量也在ATA和FC硬盘中间。 必须注意的是，LCFC硬盘可以绑定到FC硬盘里的RAID组里面。EMC建议RAID组只能绑定同样大小和类型的硬盘。 二．为可用性和冗余做考虑 一个可靠的和冗余的存储网络以SAN的设计开始，这已经超越了这个白皮书的范围。但是，一些存储系统设计方面的问题----例如硬盘和RAID组的选择—--是存储系统理所当然的课题。 请记住一点，动态的LUN的迁移，使在初始化应用后再改变RAID和硬盘的类型变得可能。 1. 高可用性的配属 高度的可用性的配属方法，是定义对应用CLARiiON存储系统的最佳实践。The EMC CLARiiON Open Systems Configuration Guide 概述了配属方法和支持的设备。 2. RAID-level的考虑 大部分CLARiiON存储都使用RAID 1/0或者RAID 5组，因为冗余的striped的RAID类型能提供最好的性能和冗余性。RAID 3 提供了和RAID 5一样的的冗余性（一个单一校验硬盘）。 A. RAID 5 RAID 5最好应用在4-9个硬盘的RAID组里面。更小的组会招致在校验开销上的更高成本。而更大硬盘数的组的主要缺点是在rebuild的时候的数据量的影 响。更大的RAID组的rebuild时间会更加长，尽管把大的RAID5组跨越了两个后端的总线上能减小这种影响。Table 5给了对rebuild时间的详细说明。此外，一个更小的组会提供更高层次的可用性，因为显然对比5块硬盘坏2块，10块硬盘坏2块的概率会大得多。 对于那些不能接受可能会因为硬盘故障而导致速度减慢的系统，或者数据的完全性是非常重要的，使用RAID 1/0 B. RAID 1/0 在可用性和冗余性是极为重要的时候，适用RAID 1/0。镜像的RAID比校验配置的冗余性肯定会更加强。此外，一个RAID 1/0只需要两个DAE—--一个对应一个后端总线----这样能让数据的可用性提升到最高可能性级别。“Binding across DAEs”里有更多的信息。最后，Table 5图解了在rebuild情况下Raid 1/0对比Raid 5的优势。 C. RAID 3 RAID 3的硬盘组可以用5块或者9块硬盘建立。冗余性跟RAID 5一致。但是，rebuild会更快一些，因为rebuild的代码会从RAID3使用的大的后端request size中得益。 D. 热备份（Hot spares） 更换的算法如下：最小的热备份硬盘，要跟目标里面选的故障的硬盘的大小一致。第二，把所有的热备份硬盘放在同一个loop里面，因为最好用大小相近的硬盘 来代替故障的硬盘。任何不在BCC控制下的硬盘（如2Gb的ATA，必须要有他们自己的热备份硬盘）可以为正常的DAE作为热备份硬盘，所以谨慎地规划 LCFC/FC混插的环境，来实现最少为每一种类型的硬盘都安排一个热备份。LCFC可以用来热备FC硬盘，但会有明显的速度的降低。对特定硬盘类型的每 两个DAE使用一个热备份的原因是凭经验来做的。他们可以放在除系统硬盘外的任何地方。 3. 把RAID组通过总线和DAE绑定 有对老的基于SCSI的系统的工作经验的工程师，会认为需要在校验RAID组里绑定每一个不同硬盘柜里面的硬盘。当每一个盘柜使用的是一条单独的SCSI 总线的时候，就会应用这个方法。为可用性考虑是因为SCSI的故障不再适用于光纤。但是，在绑定硬盘的时候，还是有好几个方面需要我们考虑。 A. 跨DAE来绑定硬盘 当绑定的硬盘跨DAE的时候，在现场的一些科目可能会导致很多的顾虑和疑惑。会有性能方面的提升吗？会有冗余方面的提升吗？在两种情形下，这都取决于RAID的配置；而在不同的情形下，这种区别是轻微的。 校验的硬盘组（RAID3，RAID5） 绑定校验RAID组，把每一个硬盘放在不同的DAE并不能提升性能。但是，这个方式可以轻微地提升数据的可用性。但是，这是非常的笨拙的方式；如果真的要求非常高的可能性，那么使用RAID1/0。请参考“binding across back-end buses”，这里面会提到。 RAID 1/0硬盘组 显然把一个RAID 1/0硬盘组绑定在多于两个DAE的时候，性能并不会得到提升，但这也不会有什么负面的影响。 B. 跨后端总线绑定硬盘 目前所有的CLARiiON系统除了CX3-20和CX300之外，都有多于绑定在DAE一组的双后端光纤总线。一个硬盘组里的硬盘可以来自一条，两条或者多条总线。标准的联接DAE的方式是把总线交替地跨越他们，像DPE和第一个DAE使用bus 0，下一个DAE使用bus 1，等等。 校验的硬盘组（RAID3，RAID5） 10个或者更多的校验的硬盘组可以从跨两个总线绑定当中得到更多的好处，因为这帮助减少了rebuild的时间。例如，绑定一个10个硬盘的RAID5，把5个硬盘放在一个DAE，另5个方在下一个DAE。 镜像的硬盘组（RAID1，RAID1/0） 跨两条总线绑定镜像的RAID组，可以增加可用性，也会减少rebuild的时间。这个方法确保了在两种（很少出现）情形下的双故障数据下数据的可用性： 一个DAE或者冗余后端的总线（双端口故障）。绑定这些硬盘以便让每一个镜像组的primary的硬盘在第一个后端总线，而secondary（镜像）硬 盘在第二个后端总线。跨总线的绑定也会有很小但是积极的性能影响。 当建立一个RAID组的时候（或者在绑定命令的时候定义一个特定的LUN），使用Navisphere CLI来跨总线绑定。当指派这些硬盘时，Navisphere CLI使用硬盘的排序，以createrg 或者 bind 命令来创建 Primary0，Mirror0，Primary1，Mirror1，等等，命令要按这个顺序。硬盘被指派为Bus_Enclosure_Disk型式。以下是一个例子：绑定来自每一个总线的各自硬盘柜里的前两个硬盘： Navicli –h C. 通过DPE磁盘绑定 在一个完全停电的情景下，SPS（standby power supply）提供了电池后备电源给SP和系统硬盘。这允许存储系统把写缓存上的内容写入硬盘。 然而，电力到没有系统盘的存储系统的硬盘柜是无法持续的。当存储系统重启的时候，有着显著I/O的LUN将会被检查，使用后台校验流程，来核实又没有任何在进行中的写只完成了部分。后台的校验是一个相当的慢的过程。 但是，如果一个LUN里面的一些硬盘是在系统硬盘（DPE或者第一个DAE，视哪种型号而定）的盘柜和一些硬盘在系统硬盘柜外面的硬盘柜，那么可能会要求rebuild，这是一个对硬盘影响更大的过程。如果影响性能达到一定程度会重启。 为了避免在启动后就rebuild，使用在系统硬盘柜内面或者外面的硬盘，建立硬盘组。如果硬盘组被分开了，遵循以下的方针： 1. 不要把RAID 1的硬盘组分布在系统硬盘柜和其他的DAE。 2. 对于校验的RAID（RAID5，RAID3），确保至少两个硬盘在系统硬盘柜之外。 3. 对于RAID 1/0，确保至少一个镜像（primary和secondary硬盘作为一对）是在系统硬盘柜之外。 D. 热备份的策略 FLARE的驱动会为最低数字（LUN的编号）热备份硬盘来扫描故障硬盘所在的总线。如果那个热备份的硬盘有足够的空间来rebuild故障硬盘的空间， 他就会被选中。如果不行，FLARE会继续扫描在那个总线上的硬盘列表，然后再到其他总线，最后另一个SP的所有列表中的热备份硬盘，直到找到一个合适的 硬盘。 4. 数据复制的持续性 SnapView，MirrorView和SAN Copy的使用，已经超出了这个白皮书的范围，但持续性这个概念跟可用性是非常相近的，所以还是有理由在这里强调一下。（参考EMC关于这些其他产品的白皮书） 当使用任何类型（包括备份）的涉及到多个LUN的数据的镜像或者复制时，工程师必须把持续性考虑在内。涉及多个LUN的数据是指那些跨越了多于一个LUN和相互关联的LUN。我们有以下例子： 关系型数据库的组件：数据目录，日志，TEMP，和RBS 在主机卷集里的卷（VERITAS，PowerVolume） 消息数据库的组件 共享的文件系统 多个LUN的持续性取决于存储系统中的特定行为。例如，到一个跨越多个LUN组成的数据库的写操作，必须让这些LUN都要保证持续性。三个在存储设计中必须要达到这个要求的情形是：clone fractures,snapshot starts, 和mirroring。 MirrorView/A 提供了阵列内持续性组，这可以保证有关联的LUN能跟着一致的split而更新。MirrorView/S有一致的fracture。SnapView提供了一致的Clone的split和一致的Snapshot Session的开始。 三. 评估存储的需求的大小 存储系统的评估包括了为容量计算正确的硬盘数，为性能计算正确的硬盘个数和正确的存储系统。 1. 容量的计划 现在是确定RAID类型和硬盘组大小的时候了（这会影响校验RAID类型的容量）。如果这个能了解，那么我们就可以做性能方面的计算。EMC员工有工具来 确定给定系统的确切的要求容量。这些工具会计算多方面对最终容量有影响的要素，例如把数据的每一个sector都存在一个CLARiiON存储系统来达到 更好的数据冗余性。 A. Vault硬盘 在CX系列的存储系统的前5个硬盘包含了Vault。Vault的硬盘跟其他系统里的任何硬盘一样，都可以被使用。但是，Vault硬盘会有更小的使用容 量（大概少6.3GB）。当Vault硬盘跟其他非Vault硬盘一起绑定，所有在这个组里面的硬盘会减少容量来匹配Vault硬盘的容量。从容量的利用 率上面来看，只绑定Vault硬盘作为一个组（或者几个组）是最有效率的。 B. 真实的硬盘容量 硬盘的容量是要比额定的容量低一些的。这主要是因为生产厂商把1 gigabyte 当成1，000，000，000 byte（基于10 gigabyte）。一台使用基于2进制的时候，1个2进制的gigabyte是1，073，741，824byte。很多客户都会惊奇的发现一个36GB的硬盘只有33GB的容量。 同时，CLARiiON会在每512byte的sector里，使用额外的8个byte作为存储冗余的信息。这些小的偏差会减少使用的容量。 C. 校验或者镜像的保护 使用校验或者镜像来保护数据不受硬盘故障的影响，这样也会减少存储的使用空间。镜像总是需要50%的校验RAID的空间，overhead取决于在组里面的硬盘个数。 2. 性能计划 性能计划或者评估是一门值得考虑的科学。这里描述的步骤只是大体上的的评估。 A. 单凭经验的的方法途径 开始性能的评估的时候，一种单凭经验的方法是使用每一个硬盘的IO/s和MB/s来计算（看table 6）。这是保守的和有意的相对单纯的方法。这必须要注意的是：这是一个精确的性能评估的开始；基于经验的评估可以作为一个快速的设计评估。EMC的员工会有更多精确评估的方法。 Table 6里面的表格假设： IO/s描述了假设2KB到8KB的随机请求 MB/s（带宽）描述了假设128KB和更大的随机请求 *ATA硬盘在这种数据下，并不推荐作为持续性的随机工作负载，因为他们的工作时间会受到他们特定的MTBF的限制。 快速评估的方法： 1. 确定主机I/O或者带宽负载 2. 计算硬盘I/O或者带宽负载 3. 计算硬盘I/O或者带宽负载需要的硬盘的个数 4. 计算存储系统的个数和类型 记住这些都是按照经验的方法。一个单一的线程应用（例如，一个一次只有对硬盘一个突出的I/O的请求，对一个10K rpm的硬盘的所有可寻址空间，做了一个8KB的随机读操作）可以达到大概120 IO/s @ 8ms per I/O。同样的硬盘使用12个模拟8KB的线程可以达到215 IO/s @ 50ms per I/O。注意在这个图表中，单凭经验的方法得出的是每个硬盘能达到140 IO/s；大部分安装都会有多于一个的线程存在，但仍想要把响应时间保持在20ms以下。对于8KB或者更大的块大小的响应时间敏感的应用，可能会使用 120（甚至100）IO/s作为一个更加保守的估计。在很少的例外情形里，非常的随机块大小（比256KB大），可能会造成比几个I/O还少的情况。在 很好的运行的顺序访问的情形下，这个速率可能会大于300IO/s，甚至比大I/O还要大。 确定主机的负载 这通常是评估最难确定的部分。很多客户都不知道自己目前的负载，不管被提议的系统的负载。然而对客户来说，最重要的是他们的预计应当尽可能的精确。必须要去做一些评估。 评估必须不仅包括整体的IO/s，还要包括其中多少比例的负载是属于读操作和写操作。加之，主要的I/O大小也是必须要确定下来的。 确定硬盘的负载 必须主要的是Table6里 IO/s的值是硬盘的IO/s。要确定主机I/O负载需要的硬盘IO/s的数目，根据是校验还是镜像的操作来调整： Parity RAID: Disk IO/s=Read IO/s + 4* Write IO/s Mirrored RAID: Disk IO/s=Read IO/s + 2* Write IO/s 对于带宽计算，当你期待大和/或者顺序I/O来填充LUN的stripe时，使用以下的方法，写的负载会通过RAID的multiplier而增加 Parity RAID: RAID multiplier is 1+(1/RAID组的硬盘个数)Disk MB/s=Read MB/s + Write MB/s *(1+(1/(组里的硬盘个数))) Mirrored RAID: multiplier is 2 Disk MB/s=Read MB/s + Write MB/s *2 举个例子，如果一个校验的组的大小是 4 + 1(组里有5个硬盘)而且读的负载是100MB/s而写的负载是40MB/s： Disk MB/s=100MB/s + 40MB/s * (1 + (1/5)) =148MB/s 计算需要的硬盘个数 把整体的IO/s或者带宽分摊到Table 6里的每一个硬盘的IO/s或者带宽。这只是一个近似的硬盘个数你需要用来为预计的I/O负载服务的。如果是使用大于8KB的I/O占主导作用的随机I/O，那么增加10%-20%的硬盘的个数。 计算存储系统的数目和类型 当评估完硬盘的个数之后，必须根据这个结果来选择相应的存储系统或者系统的集合来提供相应的性能，容量和价值给客户。 对于那些对性能很敏感的部署，参考Table 4来选择那些有高效率/高性能的硬盘个数最能满足客户需求的存储系统。 通过高效能/高性能硬盘总个数，再根据存储系统自身能提供的相应服务的硬盘个数，来确定使用多少个存储系统。 对于性能不那么重要的部署，使用硬盘柜能达到的最大的硬盘个数。通过硬盘柜最大的支持硬盘数来确定存储系统的个数。 B. 解决性能和容量的需要 系统里面硬盘的个数是由性能和容量的需要来决定的。我们可以使用这种方法来描述：高于确定要达到性能要求的最小的硬盘个数。对于不同的硬盘大小，通过需要达到容量要求来计算硬盘的个数。使用硬盘的个数，不仅要满足性能要求，也至少要满足容量的要求。 3. sizing例子 接下来的例子使用了刚才所描述的程序。 步骤1：确定要求的I/O负载 Client X有一个需求：要为一个对象的数据库安排10TB的存储。这个应用被设计为执行非常多的随机的8KB的I/O。大致的要求是： . 70%的随机读操作 . 30%的随机写操作 . 主要的I/O的大小是8KB . 总共的主机IO/s是20，000。这个客户对价格非常敏感，所以使用9个硬盘的RAID5是一个很自然的选择。但是，由于写操作的百分比（30%）比较高，所以RAID 1/0也是可能被考虑的 步骤2：计算硬盘的负载 我们计划使用一个校验的RAID，所以硬盘的负载是： 0.7 * 20,000 + 4 * 0.3 * 20,000 = 38,000 disk IO/s 但是，使用RAID 1/0的硬盘会比较小一些： 0.7 * 20,000 + 2 * 0.3 * 20,000 = 28,000 disk IO/s 步骤3：计算需要的硬盘的个数 对于要达成38,000 IO/s的RAID5的负载，我们需要38,000/180 =212 个硬盘。 如果考虑RAID 1/0，我们只需要28,000/1180=156 个硬盘。对于性价比的想法来看，RAID 1/0在这个情形下是一个更好的选择。 212个硬盘做RAID 5的可使用的容量是[8/9 * 212 * 66GB]，大概12TB。 156个硬盘做RAID 1的可使用的容量是[1/2 * 156 * 66GB]，大概是 5TB。 一个合理的RAID5的解决方案会是215个硬盘作为数据，一个有15个ATA或者LCFC硬盘的硬盘柜作为备份，5个热备份的，还有5个作为Vault（和归档空间），这样总共是240个硬盘。 因为RAID 1/0的解决方案会要求使用多于300个硬盘来到到容量的需求而且可以承受更多的I/O，一个好一些的解决方案会是使用 156个146GB 4-Gb 15K rpm的硬盘。增加一个ATA/LCFC的硬盘柜，Vault的硬盘和热备份的硬盘，这样会达到181个硬盘。（所以我们可能要减少一个热备份硬盘以避免一个硬盘柜里面只有一个硬盘的情况出现） 另外一种RAID 1/0的替代的做法是使用更便宜的 146GB 10K rpm 2Gb 的硬盘，此时IO/s要减少到每个硬盘140 IO/s。在这个情形下，必须要仔细考虑DSS和备份操作的带宽，因为后端的loop的速度只有4Gb的一半（loop的速度并不会影响到随机的小block IO/s，但会对带宽有明显的影响）。ATA硬盘加上热备份硬盘和Vault硬盘会使总共的硬盘数达到225个。 步骤4：计算存储系统的个数和类型 在每一个情形下，一个CX3-40会是一个好的选择。注意RAID 5的解决方案和2Gb RAID 1/0的解决方案，如果要对目前的硬盘数量上再做clone，snap，或者镜像的话，可能就要转换为CX3-80了。4Gb RAID 1/0方案还能增加四个硬盘柜作为分层的应用（或其他的）。最后的选择会取决于怎么在容量，性能，可用性，增长性还有成本等多方面的均衡考量。 四. 结论 性能，可靠性，冗余性和容量是在选择存储的时候得主要考虑方面。 使用一个CLARiiON的光纤通道存储系统，得到非常好的性能—--这也是很大一部分顾客所需要的—--是相当地简单。要榨干存储系统的最后一点性能， 操作员必须能了解到基于主机的影响和RAID配置的geomery（译者注：geometry应该翻译为几何数据,其实就是指的 CHS(Cylinder、Head、Sector/Track)）。应用的分析和主机内存的配置必须在对存储系统调优之前完成。 可靠性是建立在存储系统里的----拥有着比99.99还要高的可用性。冗余性是很容易实现，但成本会比没有高度可用性的配置高很多。CLARiiON存 储系统得大部分冗余性是建立在----双SP，热插拔硬盘，冗余RAID和热备份硬盘。在实际操作中我们还可以选择一些特定的方法和选择RAID的类型。 对于成本有考虑的用户，必须对他们解释在配置里面不建立冗余性的成本。RAID 1/0是一个冗余的最佳办法。 确定容量可以通过EMC的工具来直接实现。使用性能白皮书作为一个指引，对给定的I/O的整体轮廓和负载来确定应该要部署的存储系统的数目和类型。 因篇幅问题不能全部显示，请点此查看更多更全内容