存储阵列的瓶颈分析
2008-10-08 00:37
260 查看
存储阵列的瓶颈分析 author:skate time: 2008/10/07 参考:http://www.ixdba.com/html/y2007/m04/70-storage-bottle-neck.html 今天闲暇时间拜读了piner的boke,发现一篇关于关于存储阵列瓶颈分析文章很不错,在此记录下来,以备查询。 一直以来,看到关于raid5与raid10的性能之争还是非常多的,甚至很多人那拿出了测试数据,但是,到底谁是谁非。这里,我就这两种raid的内部运行原理来分析一下,我们在什么情况下应当适合选哪一种raid方式。 为了方便对比,我这里拿同样多驱动器的磁盘来做对比,raid5选择3D+1P的raid方案,raid10选择2D+2D的Raid方案,分别如图: 那么,我们分析如下三个过程:读,连续写,随机写,但是,在介绍这三个过程之前,我需要介绍一个特别重要的概念:cache。 cache技术最近几年,在磁盘存储技术上,发展的非常迅速,作为高端存储,cache已经是整个存储的核心所在,就是中低端存储,也有很大的cache存在,包括最简单的raid卡,一般都包含有几十,甚至几百兆的raid cache。 cache的主要作用是什么呢?体现在读与写两个不同的方面,如果作为写,一般存储阵列只要求写到cache就算完成了写操作,所以,阵列的写是非常快速的,在写cache的数据积累到一定程度,阵列才把数据刷到磁盘,可以实现批量的写入,至于cache数据的保护,一般都依赖于镜相与电池(或者是UPS)。 cache的读一样不可忽视,因为如果读能在cache中命中的话,将减少磁盘的寻道,因为磁盘从寻道开始到找到数据,一般都在6ms以上,而这个时间,对于那些密集型io的应用可能不是太理想。但是,如果cache能命中,一般响应时间则可以在1ms以内。 不要迷信存储厂商的iops(每秒的io数)数据,他们可能全部在cache命中的基础上做到的,但是实际上,你的cache命中率可能只有10%。 介绍完cache,我们就可以解释raid5与raid10在不同的模式下,工作效率问题了,那么我们来分别分析以上三个问题。 1、读操作 因为raid5与raid10的磁盘都可以提供服务,所以,在读上面他们基本是没有差别的,除非是读的数据能影响cache命中率,导致命中率不一样。 2、连续写 连续写的过程,一般表示写入连续的大批量的数据,如媒体数据流,很大的文件等等,这个写操作过程,如果有写cache存在,并且算法没有问题的话,raid5比raid10甚至会更好一些(这里要假定存储有一定大小足够的写cache,而且计算校验的cpu不会出现瓶颈)。因为这个时候的校验是在cache中完成,如4块盘的raid5,可以先在内存中计算好校验,同时写入3个数据+1个校验。而raid10只能同时写入2个数据+2个镜相。 如,4块盘的raid5可以在同时间写入1、2、3到cache,并且在cache计算好校验之后,我这里假定是6(实际的校验计算并不是这样的,我这里仅仅是假设),同时把三个数据写到磁盘。而4块盘的raid10不管cache是否存在,写的时候,都是同时写2个数据与2个镜相。 但是,我前面也说过了,写cache是可以缓存写操作的,等到一定时期再写到磁盘,但是,写操作不比读操作,这个写是迟早也要发生的,也就是说,最后落到磁盘上的写还是避免不了的,不过,如果不是连续性的强连续写,只要不达到磁盘的写极限,差别都不是太大。 3、离散写 这里可能是最难理解,但是,也是最重要的部分,数据库,如oracle 数据库大部分操作就是离散写,如每次写一个数据块的数据,如8K;联机日志虽然看起来是连续写,但是因为每次写的量不多,不保证能添满raid5的一个条带(保证每张盘都能写入),所以很多时候也是离散写入。 我们再接上图,假定要把一个数字2变成数字4,那么对于raid5,实际发生了4次io, 先读出2与校验6,可能发生读命中 然后在cache中计算新的校验 写入新的数字4与新的校验8 对于raid10,我们可以看到,同样的单个操作,最终raid10只需要2个io,而raid5需要4个io。 但是,这里我忽略了raid5在那两个读操作的时候,还可能会发生读命中操作,也就是说,如果需要读取的数据已经在cache中,可能是不需要4个io的,也证明了cache对raid5 的重要性,不仅仅是计算校验需要,而且对性能的提升由为重要。曾经测试过,在raid5的阵列中,如果关闭写cache,raid5的性能将差很多倍。 这里,并不是说cache对raid10就不重要了,因为写缓冲,读命中等,都是提高速度的关键所在,不过的是,raid10对cache的依赖性没有raid5那么明显而已。 到这里,大家应当也大致明白了raid5与raid10的原理与差别了,一般来说,象小io的数据库类型操作,建议采用raid10,而大型文件存储,数据仓库,则从空间利用的角度,可以采用raid5。 上面我们分析了raid5与raid10的内部运行细节,这里我们主要分析一下存储阵列的瓶颈,因为瓶颈的出现,与raid方式是有很大差别的,所以我们需要先分析raid5与raid10的具体差别。 阵列的瓶颈主要体现在2个方面,吞吐量与IOPS。 1、吞吐量 吞吐量主要取决于阵列的构架,光纤通道的大小(现在阵列一般都是光纤阵列,至于SCSI这样的SSA阵列,我们不讨论)以及硬盘的个数。阵列的构架与每个阵列不同而不同,他们也都存在内部带宽(类似于pc的系统总线),不过一般情况下,内部带宽都设计的很充足,不是瓶颈的所在。 光纤通道的影响还是比较大的,如数据仓库环境中,对数据的流量要求很大,而一块2Gb的光纤卡,所能支撑的最大流量应当是2Gb/8(小B)=250MB/s(大B)的实际流量,当4块光纤卡才能达到1GB/s的实际流量,所以数据仓库环境可以考虑换4Gb的光纤卡。 最后说一下硬盘的限制,这里是最重要的,当前面的瓶颈不再存在的时候,就要看硬盘的个数了,我下面列一下不同的硬盘所能支撑的流量大小: 10 K rpm 15 K rpm ATA ——— ——— ——— 10M/s 13M/s 8M/s 那么,假定一个阵列有120块15K rpm的光纤硬盘,那么硬盘上最大的可以支撑的流量为120*13=1560MB/s,如果是2Gb的光纤卡,可能需要6块才能够,而4Gb的光纤卡,3-4块就够了。 2、IOPS 决定IOPS的主要取决与阵列的算法,cache命中率,以及磁盘个数。阵列的算法因为不同的阵列不同而不同,如我们最近遇到在hds usp上面,可能因为ldev(lun)存在队列或者资源限制,而单个ldev的iops就上不去,所以,在使用这个存储之前,有必要了解这个存储的一些算法规则与限制。 cache的命中率取决于数据的分布,cache size的大小,数据访问的规则,以及cache的算法,如果完整的讨论下来,这里将变得很复杂,可以有一天好讨论了。我这里只强调一个cache的命中率,如果一个阵列,读cache的命中率越高越好,一般表示它可以支持更多的IOPS,为什么这么说呢?这个就与我们下面要讨论的硬盘IOPS有关系了。 硬盘的限制,每个物理硬盘能处理的IOPS是有限制的,如 10 K rpm 15 K rpm ATA ——— ——— ——— 100 150 50 同样,如果一个阵列有120块15K rpm的光纤硬盘,那么,它能撑的最大IOPS为120*150=18000,这个为硬件限制的理论值,如果超过这个值,硬盘的响应可能会变的非常缓慢而不能正常提供业务。 另外,我们上一篇也讨论了,在raid5与raid10上,读iops没有差别,但是,相同的业务写iops,最终落在磁盘上的iops是有差别的,而我们评估的却正是磁盘的IOPS,如果达到了磁盘的限制,性能肯定是上不去了。 那我们假定一个case,业务的iops是10000,读cache命中率是30%,读iops为60%,写iops为40%,磁盘个数为120,那么分别计算在raid5与raid10的情况下,每个磁盘的iops为多少。 raid5:
而4 * (10000*0.4) 表示写的iops,因为每一个写,在raid5中,实际发生了4个io,所以写的iops为16000个 为了考虑raid5在写操作的时候,那2个读操作也可能发生命中,所以更精确的计算为:
raid10
在一个实际的case中,一个恢复压力很大的standby(这里主要是写,而且是小io的写),采用了raid5的方案,发现性能很差,通过分析,每个磁盘的iops在高峰时期,快达到200了,导致响应速度巨慢无比。后来改造成raid10,就避免了这个性能问题,每个磁盘的iops降到100左右。 |
相关文章推荐
- 磁盘阵列吞吐量与IOPS两大瓶颈分析
- 阵列存储RAID分析
- 磁盘阵列两大瓶颈分析:吞吐量和IOPS
- 存储阵列及其应用
- 存储管理分析
- 常见存储过程分页PK赛——简单测试分析常见存储过程分页速度
- 识别和分析服务端的性能瓶颈
- Java提高篇——通过分析 JDK 源代码研究 Hash 存储机制
- nodejs(log4js)服务中应用splunk进行Log存储、搜索、分析、监控、警告
- mogileFS体系结构分析-Mogstored存储节点在做什么
- 寄存器使用过多成为CUDA程序瓶颈的情况分析
- MySQL数据库InnoDB存储引擎多版本控制(MVCC)实现原理分析[转]
- 大话存储-学习总结-4-磁盘阵列以及存储系统(DAS、SAN和NAS)
- 关于大型网站技术演进的思考(五):存储的瓶颈
- 识别和分析服务端的性能瓶颈
- Java提高篇——通过分析 JDK 源代码研究 Hash 存储机制
- 利用Windows性能计数器分析软件产品的性能瓶颈
- 线程内部存储---TheadLocal从使用到源码分析
- MySQL数据库InnoDB存储引擎多版本控制(MVCC)实现原理分析