EMC存储最佳实践.docx
《EMC存储最佳实践.docx》由会员分享，可在线阅读，更多相关《EMC存储最佳实践.docx（37页珍藏版）》请在冰豆网上搜索。
EMC存储最佳实践
BestPractice
FromDOITWIKI
Jumpto:
navigation,search
版权声明：
《EMC存储最佳实践》R22的版权归美国EMC公司所有，[感谢DOSTOR网友/Arthas的全力翻译]。
EMC存储最佳实践R22中文译稿可以转载，转载时请务必以超链接形式标明文章原始出处DOSTOR存储在线和作者与译者信息及本声明。
目录
[隐藏]
∙1一.关于性能的探讨
o1.11.性能的定义
o1.22.应用的设计
▪1.2.1A.为顺序或者随机I/O的优化
▪1.2.2B.I/O的大小
▪1.2.3C.暂时的模式和峰值的表现（temporalpatternsandpeakactivities）
o1.33．主机文件系统影响
▪1.3.1A.文件系统的缓冲和组合（coalesce）
▪1.3.2B.最小化I/O的大小：
文件系统的requestsize
▪1.3.3C.最大化的I/O大小
▪1.3.4D.文件系统的fragmentation
▪1.3.5F.校正对齐问题
▪1.3.6G.Linux的I/Ofragementing
o1.44.卷管理器VolumeManagers
▪1.4.1A．Plaid应该做的
▪1.4.2B.Plaid不应该做的
▪1.4.3C.Plaid为高带宽的设置
▪1.4.4D．PlaidsandOLTP
o1.55.主机HBA的影响
▪1.5.1A.HBA卡的限制
▪1.5.2B.Powerpath
o1.66.MetaLUNs
▪1.6.1A.对比metaLUN和卷管理器
▪1.6.2B.MetaLUN的使用说明和推荐
▪1.6.3C.MetaLUN的扩充战略
o1.77.存储控制器的影响
▪1.7.1A．CLARiiON的存储控制器
▪1.7.2B.磁盘的级别和性能
o1.88.RAID引擎的缓存
▪1.8.1A.缓存的大小和速度
▪1.8.2B.缓存的设定
o1.99.后端设备（磁盘的子系统）
▪1.9.1B.LUN的分布
▪1.9.2C．系统和启动硬盘的影响
▪1.9.3D．使用LUN和RAID组的编号方式
▪1.9.4E．最小化硬盘的竞争
▪1.9.5F．Stripe和Stripeelement的大小
▪1.9.6G.CLARiiONRAID5的stripe优化
▪1.9.7H.每一个RAID组的硬盘的个数
▪1.9.8I．在一个存储系统里应该使用多少个硬盘
▪1.9.9J.硬盘的类型和大小
∙2二．为可用性和冗余做考虑
o2.11.高可用性的配属
o2.22.RAID-level的考虑
▪2.2.1A.RAID5
▪2.2.2B.RAID1/0
▪2.2.3C.RAID3
▪2.2.4D.热备份（Hotspares）
o2.33.把RAID组通过总线和DAE绑定
▪2.3.1A.跨DAE来绑定硬盘
▪2.3.2B.跨后端总线绑定硬盘
▪2.3.3C.通过DPE磁盘绑定
▪2.3.4D.热备份的策略
o2.44.数据复制的持续性
[编辑]
一.关于性能的探讨
性能调优有多重要呢？
在一个Raid5的阵列组中使用5-9块硬盘和使用默认的设置，CLARiiON光纤储系统能发挥极好的性能----这是EMC在性能测试实验室里测试自己的CLARiiON系统得出来的。
CLARiiON存储系统默认的设置是为实际环境中遇到的大部分工作情形所设计的。
但是，有一些工作情景还是需要调优来实现存储系统的最佳配置。
为什么在阵列组里用5到9块硬盘？
这个设置并没有任何神奇的地方，也不是因为这个配置有什么特殊的优化。
然而，Raid5使用这个数量的硬盘确实是最有效的利用了校验，同时也能在合理的时间能重建数据。
更小的阵列组会有更高的校验开销，而大的阵列组则会花更长的时间来重建数据。
这份白皮书探讨了在设计优化系统方面的时设计到的许多要素。
请注意这里提供的信息是非常有帮助的，尤其当你充分理解了你的阵列的工作情形。
因此，EMC推荐你使用NavisphereAnalyzer来分析你的阵列的工作情形，并且要定期的复习和回顾相关文档的基础知识。
同时，请记住在配置一个阵列的时候很少有显而易见的选择，所以在有疑问的时候最好是按照默认的配置和保守的评估。
[编辑]
1.性能的定义
以下的名词在整个白皮书当中都会用到。
如果你对他们不熟悉，请回顾一下EMCCLARiiONFibreChannelStorageFundamentals
∙带宽
∙校验
∙读取
∙随机
∙响应时间
∙要求数据大小Requestsize
∙顺序
∙条带
∙条带元素Stripeelement
∙吞吐量
∙Write-aside
[编辑]
2.应用的设计
应用的设计对系统的表现影响很大。
提升性能的最佳方法的第一步就是应用的优化。
任何存储系统的调优都不可能建立一个非常差的应用设计上面。
[编辑]
A.为顺序或者随机I/O的优化
非常典型的一个例子是，提升带宽在顺序访问的调优方面会起显著作用，因为存储系统在顺序I/O方面会更加有效率--尤其是在RAID5的时候。
而为随机访问的调优则要改善吞吐量和更快的响应时间，因为这样会改善处理顾客响应所花的时间。
读和写的对比写比读更加耗费存储系统的资源，这是基于CLARiiON对数据保护的机制的应用。
写到writecache是镜像到两个存储控制器的（SP）。
写到带校验的RaidGroup会碰到校验运算的要求，而这也要求把冗余的信息写到磁盘里面。
写到镜像的RaidGroup会需要两份数据的拷贝的写入。
读的开销相对会小一些，这是因为，从CLARiiON系统的读的吞吐量会比写的吞吐量要大一些。
但是，对大部分工作情形来看，数据往往是写入writecache，这样会有更短的响应时间。
读，在另一方面来说，可能命中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到了某一个特定的大小的时候，包括writecaching和prfetching都会被bypass掉。
是决定用一个大的I/O请求还是把他分成几个顺序的请求，取决于应用程序和它跟cache之间的相互作用。
这些相互作用在“TheRaidengineCache”里会探讨到。
文件系统也可以影响到I/O的大小，这也在稍后的“Hostfile-systemimpact”中描述到。
[编辑]
C.暂时的模式和峰值的表现（temporalpatternsandpeakactivities）
应用的操作设计--如何去使用，什么时候去使用，什么时候需要去备份--都会影响到存储系统的负载。
例如，用作随机访问的应用的存储系统，在备份和批量处理的时候，需要好的顺序性能。
一般来说，对OLTP和消息应用（任何跟大量随机访问I/O有关的），更高的并发处理能力（concurrency）会更好。
当有更高的并发处理能力的时候，存储系统将会获得更高的吞吐量。
使用异步I/O是一种获得更高的并发处理能力的通常的手法。
对带宽而言，单线程的应用几乎不能有效地利用四块硬盘以上带来的好处，除非requestsize是非常大的（比2MB大）或者使用到volumemanager.当最佳的顺序性能达到的时候，而此时如果顺序处理到磁盘的路径是唯一的时候，用户还是可以从有适度并发随机访问的光纤硬盘（每个硬盘的I/O在100以下）的设置中获得一个可接受顺序性能。
[编辑]
3．主机文件系统影响
在主机层次，通过指定最小最大的I/Orequestsize，文件系统也影响了应用I/O的特性。
[编辑]
A.文件系统的缓冲和组合（coalesce）
跟在存储系统上的cache相似的是，缓冲是文件系统提高性能的一种主要方式。
缓冲
在大部分的情况下，文件系统的缓冲应该最大化，因为这能减少存储系统的负载。
然而，还是会有一些意外。
一般来说，应用自己来调配缓冲，能避免文件系统的缓冲或者在文件系统的缓冲之外工作。
这是基于应用能更加有效的分配缓冲的假设之上。
而且，通过避免文件系统的coalesce，应用更能控制I/O的响应时间。
但是，正如在64位的服务器里RAM的容量将会提升到32GB或者更多，这也就有可能把这个文件系统都放在缓冲里面。
这就能使读操作在缓冲下，性能会有非常显著的提升。
（写操作应该使用写透（write-through）的方式来达到数据的持续性。
）
结合Coalescing
文件系统的coalesce能帮助我们从存储系统里获得更高的带宽。
在大部分顺序访问的操作里面，用最大邻近和最大物理的文件系统设置来最大化文件系统的结合Coalescing.例如，这种处理方式可以和备份程序一起把64KB的写操作结合（coalesce）成一个完全stripe的写操作，这样在writecache被bypass的情况下，对于带校验的Raid会更加有效果。
[编辑]
B.最小化I/O的大小：
文件系统的requestsize
文件系统通常都被配置成一个最小的范围大小，例如4KB，8KB或者64KB，这是提供给阵列的最小的不可分割的请求。
应用使用的I/O在比这个范围大小要小的时候，会导致很多不必要的数据迁移和/或read-modify-write的情形出现。
这也是考虑应用和文件系统文件的最佳设置的最好办法。
（itisbesttoconsultapplicationandfilesystemdocumentationfortheoptimalsettings）而requestsize没有被文件系统限制的Rawpartitions，则没有受到这个约束。
[编辑]
C.最大化的I/O大小
如果想要快速的移动大量的数据，那么一个大的I/O（64KB或更大）会更加有帮助。
在整合（coalescing）顺序的写操作成RaidGroup整个的stripe的时候，阵列将会更加有效率，正如预读取大的顺序读操作一样。
大的I/O对从基于主机的stipe获得更好的带宽而言也是很重要的，因为他们将会被基于srtipe的toplogy打散成更小的大小。
[编辑]
D.文件系统的fragmentation
避免fragmentation和defragementation在一起，这是一个基础的原则。
注意NTFS文件系统可能被分区成任何形式除了默认的范围大小，他们不能被大部分的工具所defragement：
这个API（程序的接口）并不能允许这样做。
执行一个文件级别的拷贝（到另一个LUN或者执行一个文件系统的备份和恢复）是defragement的一个有效的实现。
跨越磁盘的小I/O在一些主机的类型里显得更加重要，而我们接下来将会探讨为什么会导致这种状况。
当以下情况发生的时候，跨越磁盘将会对响应时间有一个显而易见的影响：
a）有大比例的blocksize大于16KB的随机I/O
b）NavisphereAnalyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候（例如Exchange和Oracle），工作负载将会从对齐中获得一些优势。
但因为I/O当中，小于6%（对于4KB）或者12%（对于8KB）的I/O都会造成跨盘操作（碰巧的是他们可能会以并行的方式来完成）。
这种额外的收益可能很难在实践中注意到。
但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移（offset）被注明，EMC推荐使用操作系统的磁盘管理来调整分区。
NavisphereLUN的绑定位移（offset）工具应该要小心的使用，因为它可能反而会影响分层的应用同步速度。
在Intel架构系统中的文件对齐
Intel架构的系统，包括windows2000/windows2003，都会受到在LUN上元数据的位置的影响，这也会导致磁盘分区的不对齐。
这是因为遗留的BIOS的代码问题，BIOS里面用的是磁柱，磁头和扇区地址来取代LBA地址。
（这个问题一样影响了使用intel架构的linux操作系统，正如windowsNT，2000，和2003。
这个问题也一样影响了运行在intel硬件上的VMWare系统）
fdisk命令，正如windows的DiskManager，把MBR（MasterBootRecord）放在每一个SCDI设备上。
MBA将会占用设备上的63个扇区。
其余可访问的地址是紧接着这63个隐藏分区。
这将会后续的数据结构跟CLARiiONRAID的stripe变得不对齐。
在linux系统上，这个隐藏扇区的多少取决于bootloader和/或磁盘管理软件，但63个扇区是一个最常遇到的情况。
对于VMware，位移（offset）是63。
在任何情况下，这个结果都为确定的比例的I/O而导致不对齐。
大的I/O是最受影响的。
例如，假设使用CLARiiON默认的stripeelement64KB，所有的64KB的I/O都会导致跨盘操作。
对于那些比这个stripeelement的小的I/O，会导致跨盘操作的I/O的比例，我们可以通过以下公式来计算：
Percentageofdatacrossing=（I/Osize）/（stripeelementsize）
这个结果会给你一个大致的概念，在不对齐的时候的开销状况。
当cache慢慢被填充的时候，这种开销会变得更大。
aa
[编辑]
F.校正对齐问题
你可以选择以下的方法之一来修正对齐的问题。
记住，必须只是两种方法之一：
a.NavisphereLUN的对齐位移（offset）b.使用分区工具
对任何特定的LUN，只要使用其中一种，不是两个。
这个是我们经常要强调的。
同时，当设定一个metaLUN，只有那个basecomponent需要分条的对齐（就是那个被其他LUN挂靠上去的LUN）。
如果使用LUN的对齐位移，当metaLUN建立的时候，metaLUN的对齐位移也被设置了。
当扩展一个metaLUN，不需要再调整了。
如果用了分区工具的方法，这个调整只需要在用户第一次对LUN分区的时候来做。
用什么方式来做
当没有基于主机的程序在使用的时候，我们可以使用LUN对齐位移的方式。
LUN对齐位移方法对一些复制的软件操作，如clonesyncI/O，SnapViewCopyOnWriteopertions，MirrowViewsyncI/O,SANCopyI/O等，造成磁盘和strip跨盘的问题。
如果可以，使用基于主机的分区工具方式。
避免使用LUN对齐位移方法，假如你在这个LUN上使用了SnapView，SANcopy,MirrorView。
相反，
应该使用基于主机的分区工具方式。
LUN的位移
LUN的位移方法使用把LUN偏移，来达到对齐stripe分界的分区。
LUN从第一个RAID的stripe的末端开始。
换一句话说，将LUN的位移设置成RAIDstripe的大小，会让（紧接着MBR开始的）文件系统对齐了，如下图2所示。
LUN对齐位移的不足之处是它可能会造成任何要对RawLUN进行操作的软件的I/O请求的不对齐。
CLARiiON的复制会对rawLUN操作，如果LUN被位移了，这也会产生跨磁盘的操作。
Navisphere中，当LUN被bound的时候和block大小被设置成512byte的时候，位移会被设置成特定的。
例如，在一个windows2003系统，将会把63个block设置为位移量。
FLARE会调整stripe，因此用户的数据就会从stripe的开头来开始。
图2：
IntelMBRwithpartitionandLUNoffsetcorrection
磁盘分区的对齐
基于主机的分区程序使用增加可设定地址的区域的起始部分，来校正对齐的问题；因此，可设定地址的空间在RAIDstripelement的起始部分开始算起，或者在整个strip的起始部分。
因为LUN从正常的地方算起，在RAIDstrip的起始部分，复制软件操作也是对齐的。
事实上，对于镜像操作，当secondary被写入的时候，primary的对齐是被保护了的，因为增加了的分区目录被写入了源LUN。
磁盘分区对齐和windows的系统
在WindowsNT，2000，2003系统中，分区软件diskpar.exe，作为WRK（WindowsResourceKit）的一部分，可以用来设定分区位移的开始。
你必须要在数据写入LUN之前做这件事，因为diskpar会重新写分区表：
所有在LUN上出现的数据都会丢失掉。
对于随机访问操作或者是metaLUN，在diskpart中设定起始位移的大小，跟对被用来BindLUN的stripeelementsize的大小一致（一般128blocks）。
对于高带宽要求的应用，设定起始位移的大小跟LUNstripesize的大小一致。
开始，用DiskManager来获得磁盘的数目。
在命令行中，使用diskpar加上-i的选项：
diskpar-ix（新的大小是磁盘个数）来检查已经存在的位移：
C:
\>diskpar-i0
Drive0GeometryInformation----
DrivePartition0Information----
StatringOffset=32256PartitionLength=40007729664HiddenSectors=63。
。
。
注意HiddenSectors的值。
这就是分区的位移的数值
1.假如磁盘X有数据你不想丢失，那么备份那个数据2.假如磁盘X是一个RawDrive，跳到第四部。
3.删掉在磁盘X上所有的分区，使之成为一个RawDisk。
4.在命令行中使用diskpar-sX（X是磁盘个数）5.输入新的起始位移（单位sectors）和分区长度（单位MB）。
这一步骤写入为那个磁盘写入新的MBR
和创建新的分区。
在你输入起始位移和分区大小，MBR就被修改了，而新的分区信息出现了。
6.在commandprompt输入diskpar-ix（x为磁盘个数）来复查新近创立的分区上的信息。
64位windows系统在64位的windows系统里面，如果按照默认创建，MBR类型的磁盘是对齐的；GPT分区也是按默认对齐，尽管他们有一个小的保留区域（32MB）是没有对齐的。
在linux系统中的磁盘分区调整在linux中，在数据写入LUN之前对齐分区表（table），因为分区影射（map）会被重写，所有在LUN上的数据都会毁坏。
在接下来的例子里，LUN被影射到/dev/emcpowerah，而且LUNstripeelementsize是128block。
fdisk软件工具的使用方式如下所示：
fdisk/dev/emcpowerahx#expertmodeb#adjuststartingblocknumber1#choosepartition1128#setitto128,ourstripeelementsizew#writethenewpartition
对于那些会使用snapshot，clone，MirrowView的镜像构成的LUN来说，这个方法比LUN对齐位移方法更加适用。
这对SANCopy中的sources和targets是一样适用的
对于VMWare的磁盘分区调整VMware会更加复杂，因为会有两种情况存在。
当对齐rawdisk或者RawDeviceMapping（RDM）卷，实在虚拟主机（VM）层次上来实现对齐的。
例如，在windows的虚拟主机上使用diskpar来实现对齐。
对于VMFS卷，会在ESXServer的层次上使用fdisk来实现对齐，正如diskpar在VM层次。
这是因为不管是ESXServer还是客户端都会把MBR放到LUN上面去。
ESX必须对齐VMFS卷，而客户系统必需对其他们的虚拟磁盘。
对齐ESXServer：
Onserviceconsole,execute"fdisk/dev/sd",wheresdisthedeviceonwhichyouwouldliketocreatetheVMFSType"n"tocreateanewpartitionType"p"tocreateaprimarypartitionType"n"tocreatepartition#1SelectthedefaultstousethecompletediskType"x"togetintoexpertmodeType"b"tospecifythestartingblockforpartitionsType"1"toselectpartition#1Type"128"tomakepartition#1toalignon64KBboundaryType"r"toreturntomainmenuType"t"tochangepartitiontypeType"fb"tosettypetofb（VMFSvolume）Type"w"towritelabelandthepartitioninformationtodisk
通过把分区类型声明为fb，ESXServer会将这个分区认为一个没有被格式化的VMFS卷。
你应该能够使用MUI或者vmkfstools，把一个VMFS文件系统放上去。
对于Linux的虚拟主机，按照上面列出的程序步骤来做。
对于windows的虚拟主机，也是按照上面的程序步骤来做。
[编辑]
G.Linux的I/Ofragementing
对
升级会员 