EMC存储最佳实践培训手册

BestPractice

From DOIT WIKI

Jump to: navigation, search

版权声明：《EMC存储最佳实践》R22的版权归美国EMC公司所有，[感谢DOSTOR网友/Arthas的全力翻译]。EMC存储最佳实践R22中文译稿可以转载，转载时请务必以超链接形式标明文章原始出处DOSTOR存储在线和作者与译者信息及本声明。

目录

[隐藏]

?

1 一.关于性能的探讨

o 1.1 1.性能的定义 o 1.2 2.应用的设计

? 1.2.1 A. 为顺序或者随机I/O的优化 ? 1.2.2 B. I/O 的大小

? 1.2.3 C. 暂时的模式和峰值的表现（temporal patterns and peak activities）

o 1.3 3．主机文件系统影响

? 1.3.1 A.文件系统的缓冲和组合（coalesce）

? 1.3.2 B.最小化I/O的大小：文件系统的request size ? 1.3.3 C.最大化的I/O大小

? 1.3.4 D.文件系统的fragmentation ? 1.3.5 F.校正对齐问题

? 1.3.6 G.Linux的I/O fragementing

o 1.4 4.卷管理器Volume Managers

? 1.4.1 A． Plaid 应该做的 ? 1.4.2 B. Plaid 不应该做的

? 1.4.3 C. Plaid 为高带宽的设置 ? 1.4.4 D． Plaids and OLTP

o 1.5 5. 主机HBA的影响

? 1.5.1 A. HBA卡的限制 ? 1.5.2 B. Powerpath

o 1.6 6. MetaLUNs

? 1.6.1 A. 对比metaLUN和卷管理器

1

1.6.2 B. MetaLUN的使用说明和推荐 ? 1.6.3 C. MetaLUN的扩充战略

o 1.7 7.存储控制器的影响

? 1.7.1 A． CLARiiON的存储控制器 ? 1.7.2 B. 磁盘的级别和性能

o 1.8 8.RAID引擎的缓存

? 1.8.1 A. 缓存的大小和速度 ? 1.8.2 B. 缓存的设定

o 1.9 9.后端设备（磁盘的子系统）

? 1.9.1 B. LUN的分布

? 1.9.2 C． 系统和启动硬盘的影响

? 1.9.3 D． 使用LUN和RAID组的编号方式 ? 1.9.4 E．最小化硬盘的竞争

? 1.9.5 F．Stripe和Stripe element的大小 ? 1.9.6 G. CLARiiON RAID 5的stripe优化 ? 1.9.7 H. 每一个RAID组的硬盘的个数

? 1.9.8 I．在一个存储系统里应该使用多少个硬盘 ? 1.9.9 J. 硬盘的类型和大小

? 2 二．为可用性和冗余做考虑

o 2.1 1. 高可用性的配属 o 2.2 2. RAID-level的考虑

? 2.2.1 A. RAID 5 ? 2.2.2 B. RAID 1/0 ? 2.2.3 C. RAID 3

? 2.2.4 D. 热备份（Hot spares）

o 2.3 3. 把RAID组通过总线和DAE绑定

? 2.3.1 A. 跨DAE来绑定硬盘 ? 2.3.2 B. 跨后端总线绑定硬盘 ? 2.3.3 C. 通过DPE磁盘绑定 ? 2.3.4 D. 热备份的策略

o 2.4 4. 数据复制的持续性

?

[编辑]

2

一.关于性能的探讨

性能调优有多重要呢？在一个Raid 5的阵列组中使用5-9块硬盘和使用默认的设置，CLARiiON光纤储系统能发挥极好的性能----这是EMC在性能测试实验室里测试自己的CLARiiON系统得出来的。

CLARiiON存储系统默认的设置是为实际环境中遇到的大部分工作情形所设计的。但是，有一些工作情景还是需要调优来实现存储系统的最佳配置。 为什么在阵列组里用5到9块硬盘？这个设置并没有任何神奇的地方，也不是因为这个配置有什么特殊的优化。然而，Raid 5使用这个数量的硬盘确实是最有效的利用了校验，同时也能在合理的时间能重建数据。更小的阵列组会有更高的校验开销，而大的阵列组则会花更长的时间来重建数据。

这份白皮书探讨了在设计优化系统方面的时设计到的许多要素。请注意这里提供的信息是非常有帮助的，尤其当你充分理解了你的阵列的工作情形。因此，EMC推荐你使用Navisphere Analyzer来分析你的阵列的工作情形，并且要定期的复习和回顾相关文档的基础知识。同时，请记住在配置一个阵列的时候很少有显而易见的选择，所以在有疑问的时候最好是按照默认的配置和保守的评估。 [编辑]

1.性能的定义

以下的名词在整个白皮书当中都会用到。如果你对他们不熟悉，请回顾一下 EMC CLARiiON Fibre Channel Storage Fundamentals

? ? ? ? ? ? ? ? ? ? ?

带宽 校验 读取 随机 响应时间

要求数据大小 Request size 顺序 条带

条带元素 Stripe element 吞吐量

Write-aside

[编辑]

2.应用的设计

3

应用的设计对系统的表现影响很大。提升性能的最佳方法的第一步就是应用的优化。任何存储系统的调优都不可能建立一个非常差的应用设计上面。 [编辑]

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”里会探讨到。

4

文件系统也可以影响到I/O的大小，这也在稍后的“Host file-system impact”中描述到。 [编辑]

C. 暂时的模式和峰值的表现（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）的方式来达到数据的持续性。）

5

跨越磁盘的小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

7

的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所示。

8

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上出现的数据都会丢失掉。

9

对于随机访问操作或者是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

10

对于那些会使用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 \sd is the device on which you would like to create the VMFS Type \to create a new partition Type \to create a primary partition Type \to create partition #1 Select the defaults to use the complete disk Type \partitions Type \#1 to align on 64KB boundary Type \change partition type Type \to write label and the partition information to disk

通过把分区类型声明为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。 [编辑]

11

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都是特指

12

这个）在一起。这是因为会造成大量的磁盘寻道。如果你从一个磁盘组需要捆绑多个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的方式结束。

13

跨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提供了几种负

14

载均衡的算法，默认的那种----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目标

15

要创建一个卷管理器的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上的多路复用是由存储系统来实现的。

16

[编辑]

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的类型

17

一般来说，尽可能的使用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组。

18

为磁盘组的大小来测定选择有效的磁盘个数。例如，六个磁盘的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

19

扩展的类型被设置成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的例子

20

Figure5. metaLUN里面的存储的初始化分布

注意到在图5，每一个metaLUN由一个对应一个RAID组的LUN组成。因此，每一个LUN的负载是分布在所有在那个set里的RAID组。但是，这些metaLUN是和对其他RAID组的set的数据访问是分隔开的。

为什么要使用RAID组的set？如果我们不允许一个metaLUN来扩展到自己的set以外，我们可以做出一定级别的隔离，将这种影响控制在磁盘的级别。例如，一个RAID组的set可能为一大群文件服务器所设立，而另一个RAID组的set是为RDBMS的数据目录----这时一对普通的RAID1组可能被使用作为RDBMS的日志设备。图6展示了这一点。

21

图6：用RAID组的set和metaLUN来做数据分隔的例子

在图6里面显示的例子，通过访问到NFS的共享metaLUN，并不会干涉到Oracle服务器访问他们自己的数据目录或者日志。 扩展模式的的扩展程序

下一步是建立扩展的策略。扩展的目标：

维持扩越很多磁盘的分布 ? 更有效的利用容量

?

达致这个目标的途径

当容量对metaLUN来说是可以预计的，把磁盘增加到set已经出现的RAID组里面。 ? 对metaLUN里的set里面的RAID组进行扩展 ? 对metaLUN里增加扩展的LUN作为一个新的

stripe的component

?

MetaLUN的扩展例子

这个例子里使用的途径，和metaLUN配置的原始的目标是紧密结合的----I/O分布在所有的磁盘上。

22

第一步，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的类型和容量：

23

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存储器家族的参数特点如下：

24

针对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）的数据

库（计算销售记录的统计分析）

?

25

任何记录大小大于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模式则无法做到这一点。

26

[编辑]

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，可以从关闭读缓存（或者关闭预

27

读取）来避免数据传输的“颠簸”。当同步的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，所以要尽可能的让写缓存保持在开启的状态。因而，用户可以自己选择。

为什么这作为一个选择呢？清除这个选项，会导致顾客有可能遭遇到数据丢失的三种情形：假如一个系统硬盘坏掉了，那么数据将不会倒入。假如另一个系统硬盘在第一个坏的硬盘被更换之前坏掉，和系统遭遇了一个电力系统的故障，缓存里面的内容就会丢失。相类似的是，如果在初始化的系统硬盘坏掉了之后，又遭遇电力的中断，然后第二个硬盘在数据倒入期间或者在随后出现故障，数据也会丢失。

用户需要在性能的提升和风险之间作一个决定。 预读取的设定

28

预读取（变量，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的折衷如下：

?

数据像这样的写入，在缓存里为一个并发的

读来说，并不是可用的。

29

?

这样的写操作的响应时间比用缓存的写操作的响应时间要长。

必须要注意的是完全的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组里。

30

在需要高带宽的应用里面，应该要小心谨慎的去分布那些涉及到跨越后端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

[编辑]

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的光纤硬盘几乎一样。但是，因为性能跟轴的数量有关，用户选择硬盘的时候，必须要计算他自己的性能要求，就像他要考虑容量需求一样。

36

转速

对于同样的硬盘技术，更高的转速会带来更好的性能。更高的转速会让硬盘的寻道时间线形的减少。此外，更高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”提供了更多的细节。

37

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）

38

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

39

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绑定

40

本文来源：https://www.bwwdw.com/article/bdl3.html