EMC存储最佳实践培训手册.doc
《EMC存储最佳实践培训手册.doc》由会员分享，可在线阅读，更多相关《EMC存储最佳实践培训手册.doc（43页珍藏版）》请在冰豆网上搜索。
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在
升级会员 