EMC存储最佳实践

本资料由-大学生创业|创业|创业网http://www.chuangyw.com/提供资料 BestPractice From DOIT WIKI Jump to: navigation, search 版权声明：《EMC存储最佳实践》R22的版权归美国EMC公司所有，[感谢DOSTOR网友/Arthas的全力翻译]。EMC存储最佳实践R22中文译稿可以转载，转载时请务必以超链接形式标明文章原始出处DOSTOR存储在线和作者与译者信息及本声明。 目录 · [隐藏] · 1 一.关于性能的探讨 · 1.1 1.性能的定义 · 1.2 2.应用的设计 · 1.2.1 A. 为顺序或者随机I/O的优化 · 1.2.2 B. I/O 的大小 · 1.2.3 C. 暂时的模式和峰值的现（temporal patterns and peak activities） · 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 · 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 · 1.5 5. 主机HBA的影响 · 1.5.1 A. HBA卡的限制 · 1.5.2 B. Powerpath · 1.6 6. MetaLUNs · 1.6.1 A. 对比metaLUN和卷管理器 · 1.6.2 B. MetaLUN的使用说明和推荐 · 1.6.3 C. MetaLUN的扩充战略 · 1.7 7.存储控制器的影响 · 1.7.1 A． CLARiiON的存储控制器 · 1.7.2 B. 磁盘的级别和性能 · 1.8 8.RAID引擎的缓存 · 1.8.1 A. 缓存的大小和速度 · 1.8.2 B. 缓存的设定 · 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 二．为可用性和冗余做考虑 · 2.1 1. 高可用性的配属 · 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） · 2.3 3. 把RAID组通过总线和DAE绑定 · 2.3.1 A. 跨DAE来绑定硬盘 · 2.3.2 B. 跨后端总线绑定硬盘 · 2.3.3 C. 通过DPE磁盘绑定 · 2.3.4 D. 热备份的策略 · 2.4 4. 数据复制的持续性 [编辑] 一.关于性能的探讨 性能调优有多重要呢？在一个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.应用的设计 应用的设计对系统的表现影响很大。提升性能的最佳方法的第一步就是应用的优化。任何存储系统的调优都不可能建立一个非常差的应用设计上面。 [编辑] 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”中描述到。 [编辑] 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）的方式来达到数据的持续性。） 结合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", 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 block 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会将这个分区认为一个没有被格式化的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%的磁盘利用率（典型的OLT