EMC创新日:随机环境系统性能调优指南

作者:IT168李隽 整理
2008/12/5 0:00:00
本文关键字: 存储 分析

  11月27日至28日,EMC在其成立不久的上海研发中心举办了主题为“创新无极限”2008年度创新日大会。作为EMC一年一度展示最新技术与产品的主要平台,每年的创新日活动都有大量EMC核心重要的行业客户参与,走进其研发中心,了解存储业界引领最新趋势的技术研发项目和存储系统产品。

  本次的创新日主题围绕EMC 最新一代中端存储系统产品CLARiiON CX4,在为期两天的创新日日程中,我们不仅全面了解了EMC CLARiiON CX4各项增强功能和创新设计,还有幸近距离走入EMC研发试验室,观摩了许多还处于研发阶段的项目展示。这些目前还处于实验室阶段的技术都针对行业最为热点和前沿的存储应用,其中的一些研发项目非常有趣,不仅仅展示了EMC领先市场份额背后的强大技术实力,还体现了EMC研发中心创新与开放的思维个性。本次创新日之旅的精彩内容我们将在下面一一呈现给大家。

随机环境下存储系统性能调优

  存储的性能问题一直是系统管理员面临的最为实际的问题,也是一直以来困扰企业系统管理人员的一个有趣的话题。本次EMC创新日讲座上,EMC资深存储系统顾问黄劲峰先生针对存储应用的一些通用状况和部分典型应用,讲解了存储系统性能调优的一些基本原则和实战操作。本文分为上下两篇,本文侧重讲述随机环境下存储系统性能调优的一些经验和原则,下篇将侧重顺序环境下存储系统性能调优的一些实用技巧。

理解随机IO和顺序IO的特点

  对于随机应用来说,大部分是一些数据库的应用,此外,Oracle ASM也是属于随机应用,但每个IO段都比较大,所以导入起来时间比较长。除了随机应用,系统中通常还会有顺序读写的IO应用,一般来说在归档、视频等等的应用比较常见。它们对性能的要求是不太一样的,规模也是不一样的。针对这两种IO特点,我们通常由一些配置的原则,但不见得哪一种是贯穿的。

  随机应用要求是响应时间,我们每一个IO都希望在几毫秒内完成,然后才可以进行下一个IO操作。顺序读写要求带宽比较高,这种情况下,一个IO过来,很可能一读就占了几M或者十几M,这时候一个IO的操作就占用了整个阵列。其他IO就会被迫排在它的后面,顺序IO就占用了太多的资源,并占用了其他IO的资源。例如本来在1秒钟可以处理1000个IO,现在只能处理700个IO。所以我们就建议不要把顺序读写放在同一个磁盘上面,但是我们可以把它放在一排阵列上面没有问题,最好用不同的磁盘来分散IO压力。

性能调优的通用原则

  详细分析随机环境下的IO特点之前,我们会先给出一些存储系统调优最基本的原则。这些原则基本适用于大多数应用环境,无论是随机IO的环境还是顺序IO的环境。

读Cache设置:一般会认为读cache在阵列中是提高性能的非常有用的措施,对于一些应用来说,大部分时候读cache的确非常有效。但是一个原则是不要分配太多的读Cache给系统,一般日常的工作状态中,分配20%左右的读Cache就已经足够了。原因有两点,首先,在随机IO的应用状态下,我们不能保证所需要读取的IO能在缓存中命中。其次,在顺序IO的读取过程中,从磁盘中读取IO的速度并不慢,先读到缓存中对整体读取速度的提高没有太明显的影响。因此,通常的一个标准就是,读缓存设置20%左右就足够了。

选型配制时不仅需要考虑容量,还需要考虑性能:其次,当我们在进行存储选型或者配置的时候,我们不仅仅需要考虑存储系统的容量,我们还需要考虑性能的因素。举个例子来说,从容量的角度,我们可能4块磁盘就足够满足应用,另外一个方面四块磁盘不一定能够满足我们对IO性能的要求。举例来说,一块15K转硬盘在非常随机的IO状态下能提供180个IOPS,如果是4块盘,大概就只有720个IOPS,究竟是否能满足性能的需要?

系统盘中是否能够存放应用数据?此外,CLARiiON中有5块盘作为系统盘使用。应该说,系统盘中其实有一定的空间给我们使用,我们同样可以应用系统盘中间的空间进行编组,划分LUN。但这是在IO的压力并不是十分大的情况下,应用系统盘的空间对阵个系统的影响不大。当IO压力很大的时候,我们不建议把应用的LUN放到系统盘上面,会导致整体系统的响应速度变慢。

  而且有一种情况,在阵列中有一个HA VAULT选项,这个选项的作用就是当系统盘一旦出现故障以后,这个选项能够自动将cache里面的数据文本下载到系统盘上面去,如果这时候系统盘还有其他的应用在访问,这时候系统要同时把数据从cache里面DOWN到磁盘里面,两个应用都在系统磁盘上操作,这样速度也会变慢。当然这个选项可以取消它,但带来的负面因素就是,当系统出现故障的时候,无法自动的把数据从cache下载到磁盘里面,可靠性会降低。

选择合适的磁盘类型:当进行存储选型的时候,我们通常会有FC、SAS和SATA几种磁盘类型。FC盘和SAS盘等适用于关键实时应用, SATA盘性能比较低,我们通常用在归档的环境。但是如果你的访问是顺序的,基本上一个访问,你这时候你可以用SATA盘。

把不同的随机应用混在一起

  下面我们重点讨论一下随机IO的应用。对于一些用户来说,往往很疑惑,我有几个不同的随机IO的应用,对于这些不同的随机IO的应用,我们要不要分在不同的RAID组,或者不同的LUN中。其实对于存储系统来说,我们会发现,不同的随机IO即使混合在一起,也同样是随机的IO,对于这些不同的应用,我们即使划分在一个RAID组或者LUN里面,对单个应用的性能都不会有太多的影响。

  此外,随机IO应用的高峰期通常不会完全重合,当随机IO处于高峰期的时候相互之间的确会产生影响,因此对于用户来说,我们需要注意的就是,如果同时有两个随机IO的应用高峰期大致相同,且其中一个的应用对性能的要求很高,需要有一定的资源保证,在这种情况下,我们需要把这个应用独立出来划分LUN。如果这些随机IO的高峰期并不是非常一致,且没有需要保证高性能的应用的情况下,我们可以大胆的把这些应用混在一起,这样我们能够用更多的磁盘来担负多个应用的IO需求,不仅不会对性能造成影响,还能有效的消除热点。


不同的随机应用混合在一起还是随机应用

  我们关注一下数据库的应用,对于关系型数据库来说往往LOG是比较重要的,我们通常会单独划分空间来保存LOG,在需要很高性能的时候这样做的确是必须的而且是有效的。但是如果系统对性能要求并不十分苛刻的话,我们其实可以大胆的把LOG和数据放到一起,因为它占用性能的影响其实没有我们想象那么大。很多时候,LOG都是顺序的少量的写IO,通常IO写到Cache里面,读的话不会占用所有的cache。当我们把LOG和数据放到一起,我们能用更多的磁盘来完成LOG读写IO的操作,此外,LOG本身对性能的影响本身也并不十分明显。因此我们建议,在对性能没有苛刻要求的情况下,完全可以把非关系型数据库的LOG和数据放到一起。


两个不同数据库的LOG和数据交叉存放

个实用的技巧,是把两个不同的数据库的LOG和数据交叉存放,来保护数据或者错峰使用。

选择什么样的RAID级别?

  对于随机IO的分布来说我们还需要考虑我们到底选择什么样的RAID级别,不同的RAID级别对磁盘的要求是不同的,对于综合性能来说,RAID是最值得期待的。

  通常RAID5是一个综合成本和性能的很好的选择,但是我们什么情况下需要采用RAID0+1呢?实际上一般的应用来说,占绝大多数的都是读IO,其中写IO通常占到10%左右。但是,当我们分析写IO超过20%的时候,我们就应该考虑采用RAID0+1,这种情况下,如果不要求太高的性能,RAID5也是可以接受的。但是当写IO超过了40%左右,那么我们就必须考虑采用RAID0+1了。

  因为不同的RAID方式对磁盘产生的IO(Disk IO)是不同的。举例来说,一个四块磁盘的RAID5要做一个写操作时,所产生的磁盘IO实际上是4个,包括2个读IO和2个写IO。而同样一个写IO,在一个四块磁盘的RAID 0+1组中,所产生的磁盘IO实际上只有2个,实际上只需要同时写到两个磁盘中就可以了。因此,当一个应用中的写IO越高,那么对于RAID5和RAID0+1的性能影响就会体现的越明显。

  那什么时候使用RAID6呢,首先要求写操作的比率比较低,低于15%的时候可以考虑使用RAID6。读操作的时候RAID5和RAID6相差不多,但是它比RAID5对系统的影响更大,因为一个post IO通常会在后端产生6个磁盘IO。所以,首先RAID 6在写IO操作并不十分多的情况下应用会比较好,另外就是应用在数据完整性方面的要求的确非常高。

相同应用下不同的RAID级别的性能差别

  如图的这个案例,2100个IOPS,其中30%的写IO,在RAID0+1的情况下,磁盘利用率达到70%,响应时间13ms,而换到RAID5的情况下,磁盘利用率就达到了92%,响应时间变成了62ms,很多应用都不能接受62ms的响应时间。而对于RAID6来说,写操作完全没办法满足应用要求。

  RAID条带宽度对性能会带来什么影响呢?RAID条带宽度主要与RAID组的磁盘数据是有关系的。一般来说,一个磁盘片的宽度是64K,如果是3+1的RAID组就是64K*3,7+1的RAID组就是64K*7。在随机应用的环境中,带宽对整体性能并没有明显的影响。但是当一个RAID组中的磁盘数量过多的时候,在磁盘出现故障需要重建的时候,磁盘会当机。

矫正偏移量

  另外有一个很关键的问题就是偏移量(Alignment),偏移量基本上产生在WINDOWS平台,或者Wintel架构中。因为在WINDOWS平台里面,每个磁盘都留有一部分空间用来存放分区表,系统在启动的时候会有很多的信息在里面,一般为32K。由于我们知道一个盘片的基本容量在64K,那么这个盘片还有32K的可用空间。当一个大于32K的写IO过来的时候,这时候就需要2个磁盘或者更多的磁盘来完成这个IO操作,这就是偏移量。

  偏移量对系统的整体性能有非常大的影响,那么我们通过什么方式能够调整呢?对于wintel的架构,我们可以通过diskpar工具来设定偏移量,例如将数据块大小设为64K,这样写操作的时候,数据将自动从第二块磁盘去写入。在虚拟机的环境下,如果是RDM的LUN环境,我们可以在虚拟机层面使用diskpar工具工具设定偏移量,如果是VMFS的LUN环境,我们需要先在ESX上使用FDISK,然后在虚拟机层面使用diskpar工具工具设定偏移量。

  偏移量是个很重要的问题,但很多用户会很容易忽视它。我们举个例子来说明,在没有矫正偏移量的情况下,系统性能会损失多少。一般来说,最常用的数据块大小除以64,就是我们损失的性能比。如果常用数据块为8K,那么损失的性能为8/64=12.5%。

Oracle ASM环境下性能调优

  对于Oracle ASM的环境,一般来说是大数据块的随机写入。如果我们对系统进行优化,通常会自动的把数据拆分成小数据块,例如8K、16K,对于这些小数据块来说主要是顺序读写,尽管整个大的数据块保持了随机读写的特性。在这种环境下,我们需要注意:

  无论对于R26以前或者以后的版本,首先每一个RAID组设置1 或2 LUNs。
  对于R26以前版本
– RAID 1/0 条带化成256 blocks时性能最好(需要在命令行或工程模式下进行)
– 2+2, 4+4 的条带吻合I/O 块大小
– 对齐偏移量! 比小数据块的随机访问环境更关键
– 把数据LUN的读高速缓存关掉-- 基本用不上

  在Release 26及更高版本, CLARiiON支持‘multi-stripe read’
– RAID 1/0 2+2 的配置比较合适,可以让磁盘支持大的数据块读操作(高达512 KB).
– 使用条带化的MetaLUN, 8的倍数来获得更大的分区和分散热点数据
– 支持发送1MB的I/O到成员LUN上, 每个磁盘的处理I/O高达512 KB。

随机访问性能调优规则总结

  最后我们总结一下在随机访问的时候获得最高性能的一些规则。

  首先是缓存:

  把缓存页面设置成主导I/O的大小,在混合环境中建议使用8KB大小。但需要注意的是,改变缓存页面大小必须关闭高速缓存,须预先计划影响

  如果系统的写操作响应时间较长,把缓存水平线的阀值降低。这样做的好处包括:简单,无需中断;在高速缓存中预留更大的空间,以应付写操作的高峰。但需要注意的是,水平线的高值应该比低值高20%。

  此外我们可以关闭随机访问的LUN上的预读功能,因为一些文件系统对数据的存取导致大量的预读操作,但是并没有帮助,而且这样做简单,无需中断。

  对一些有随机特征的顺序操作(常见于媒体应用),应该增加预读的功能。中央视频监控是一种典型的例子,而且这样做同样简单并无需中断。

  此外,对磁盘数量大小的设定也对性能有明显的影响,一般来说,单个磁盘臂提供的IOPS决定随机存取的性能。在进行选型之前,我们需要计算计算所需IOPS的性能需求,包括主机产生的压力及RAID算法额外产生的I/O负荷。

  下面提供一些经验数据值,在70%使用率,非常随机的读取目标情况下:
15K rpm FC/SAS能够提供180 IOPS,10K rpm FC/SAS能够提供140 IOPS,7.2K rpm SATA能够提供80 IOPS。因此用户需要根据根据IOPS的需求决定支持的磁盘数,然后选择相应的阵列,很多用户会用到阵列所支持的最大磁盘数。

责编:
vsharing 微信扫一扫实时了解行业动态
portalart 微信扫一扫分享本文给好友
著作权声明:kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
最新专题
流动存储 为大数据而生

伴随信息技术的突飞猛进,更大量级的非结构化数据与结构化数据构成的大数据成为企业级存储所面临的最大挑战:一方..

磁盘阵列及虚拟化存储

利用数组方式来作磁盘组,配合数据分散排列的设计,提升数据的安全性。虚拟化存储,对存储硬件资源进行抽象化表现。

    畅享
    首页
    返回
    顶部
    ×
    畅享IT
      信息化规划
      IT总包
      供应商选型
      IT监理
      开发维护外包
      评估维权
    客服电话
    400-698-9918
    Baidu
    map