大话存储系列1——对存储的初步认识

  1. 云栖社区>
  2. 博客>
  3. 正文

大话存储系列1——对存储的初步认识

长烟慢慢 2013-03-02 19:48:44 浏览570
展开阅读全文
这篇文章转载自大牛Hellodba,连接如下:http://www.hellodb.net/2009/08/storage.html
那这篇文章开始我的存储之旅,我将会在近期整理出关于存储的更多细节。

IOPS
IOPS (Input/Output Operations Per Second),即每秒进行读写(I/O)操作的次数,多用于数据库等场合,衡量随机访问的性能。存储端的IOPS性能和主机端的IO是不同的,IOPS是指存储每秒可接受多少次主机发出的访问,主机的一次IO需要多次访问存储才可以完成。例如,主机写入一个最小的数据块,也要经过“发送写入请求、写入数据、收到写入确认”等三个步骤,也就是3个存储端访问。

决定IOPS的主要取决与阵列的算法,cache命中率,以及磁盘个数。阵列的算法因为不同的阵列不同而不同,如我们最近遇到在hds usp上面,可能因为ldev(lun)存在队列或者资源限制,而单个ldev的iops就上不去,所以,在使用这个存储之前,有必要了解这个存储的一些算法规则与限制。
硬盘的限制,每个物理硬盘能处理的IOPS是有限制的,如
同样,如果一个阵列有120块15K rpm的光纤硬盘,那么,它能撑的最大IOPS为120*150=18000,这个为硬件限制的理论值,如果超过这个值,硬盘的响应可能会变的非常缓慢而不能正常提供业务。
在raid5与raid10上,读iops没有差别,但是,相同的业务写iops,最终落在磁盘上的iops是有差别的,而我们评估的却正是磁盘的IOPS,如果达到了磁盘的限制,性能肯定是上不去了。

cache的命中率取决于数据的分布,cache size的大小,数据访问的规则,以及cache的算法,如果完整的讨论下来,这里将变得很复杂,可以有一天好讨论了。我这里只强调一个cache的命中率,如果一个阵列,读cache的命中率越高越好,一般表示它可以支持更多的IOPS,为什么这么说呢?这个就与我们下面要讨论的硬盘IOPS有关系了。
10 K rpm 15 K rpm ATA
——— ——— ———
100     150      50
那我们假定一个case,业务的iops是10000,读cache命中率是30%,读iops为60%,写iops为40%,磁盘个数为120,那么分别计算在raid5与raid10的情况下,每个磁盘的iops为多少。
raid5:
单块盘的iops = (10000*(1-0.3)*0.6 + 4 * (10000*0.4))/120
= (4200 + 16000)/120
= 168
这里的10000*(1-0.3)*0.6表示是读的iops,比例是0.6,除掉cache命中,实际只有4200个iops
而4 * (10000*0.4) 表示写的iops,因为每一个写,在raid5中,实际发生了4个io,所以写的iops为16000个
为了考虑raid5在写操作的时候,那2个读操作也可能发生命中,所以更精确的计算为:
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120
= (4200 + 5600 + 8000)/120
= 148
计算出来单个盘的iops为148个,基本达到磁盘极限
raid10
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4))/120
= (4200 + 8000)/120
= 102
可以看到,因为raid10对于一个写操作,只发生2次io,所以,同样的压力,同样的磁盘,每个盘的iops只有102个,还远远低于磁盘的极限iops。
在一个实际的case中,一个恢复压力很大的standby(这里主要是写,而且是小io的写),采用了raid5的方案,发现性能很差,通过分析,每个磁盘的iops在高峰时期,快达到200了,导致响应速度巨慢无比。后来改造成raid10,就避免了这个性能问题,每个磁盘的iops降到100左右。

磁盘 一个IO的访问,大致分为三个步骤,第一是磁头到指定的磁道(寻道),第二是等待需要读取的数据随盘片旋转到磁头(延迟),第三是读取数据。相比较前两个时间,读取数据的时间可以忽略不计,所以一个IO的响应时间等于寻道时间+延迟时间决定,寻道时间由于是机械的动作,所以很难得到大幅度提高,但是可以通过提高磁盘转速来提高延迟时间。所以转速越高的盘,可以承载更多的IOPS。磁盘的IOPS由磁盘的转速决定,比如15000RPM的磁盘,一般可以承受150个IOPS。 吞吐量,则由磁盘的转速和接口决定,转速决定了内部传输率,接口则决定了外部传输率,很明显前者肯定低于后者。常见的接口有ATA,SCCI,SATA,SAS,FC等等。FC接口一般在高端存储中比较常见,而SAS和SATA多在服务器或者中低端存储中常见。 存储 对于一个存储系统来说,IOPS主要决定于cache的算法,以及磁盘的数量。有时候我们往往会被厂商的数据给忽悠了,第一是cache命中率,厂商利用了某种手段,让cache命中率非常高,IOPS几乎可以随心所欲。另外一个因素就是磁盘的数量,厂家的数据是同型号1000块磁盘的测试结果,而我们实际的系统只有100块磁盘。 购买存储时,应该避免买高端的存储,而只配数量很少的磁盘,厂商非常喜欢你买一个高端的BOX,告诉你扩展性好,现在用不着可以少买点盘,以后可以扩容等等,这完全是忽悠。建议不要超前消费,如果确实对性能追求很高,可以选用容量小一些的磁盘,而磁盘的数量多一些。 磁盘的数量可以计算得出,我们的经验,一般OLTP应用的cache命中率在20%左右,剩下的IO还是要到磁盘上的,根据磁盘的转速和类型,就可以知道一块盘能够承载的IOPS,磁盘数量就可以估算出来了,为了得到比较好的响应时间,建议每块磁盘的IOPS不要超过100。 影响吞吐量的因素稍微复杂些,由磁盘的数量和存储的架构决定,当磁盘到达一定的数量后,吞吐量主要受限于存储的架构。比如某高端存储,吞吐量最大就是1.4GB,这是由它内部的架构所决定的。另外还要注意存储与主机的接口,比如HBA卡,有4Gb和2Gb(这里是bit,而不是Byte),一般主机和存储都配有多块HBA卡。 RAID RAID一般比较常见的就是RAID10和RAID5,对性能要求比较高的数据库应用一般都采用RAID10,RAID5也可以用,但是别把redo放在RAID5上,因为RAID5的对于redo这种小IO,性能非常差,很容易造成log file sync的等待。一个RAID group中的磁盘数量不宜过多,不要超过10块,原因是RAID group中磁盘数量越多,坏盘的概率就越大(概率问题)。一些高端存储对于RAID group中的磁盘数量都是固定的,这主要和存储的架构有关。使用存储的过程中,你会发现,越是高端的东西,就越是死板,而中低端存储则非常灵活,并不是说高端存储不好,而是说架构决定一切。 Stripe Stripe的作用就是尽可能的分散IO,它在有些存储上是可以调节的,但是很多存储是不可以调节的,一般在128K-512K之间。有一个错误的说法是,我在存储上做了stripe,数据库的一个IO,所有的磁盘都会响应这个IO。这个说法是错误的,对于Oracle来说,一个随机IO的大小是8K,一般条带的大小要比8K大得多,所以Oracle一个随机IO永远只会落在一块磁盘上。一块磁盘在同一个时刻只能响应一个IO,也就是说磁盘没有并发IO的概念,但是从整个系统来看,不同的磁盘响应不同的IO,宏观上IO还是分散的,所以我们看到一个数据库在运行时,所有的磁盘都在忙,实际上每块磁盘是为不同的IO服务。对于顺序IO,Oracle的默认设置是128K,最大值由OS决定,一般是1M,如果顺序IO的大小大于stripe,那么一个IO可能会有几块盘同时响应,但是很多存储的stripe都大于128K,这时一个IO还是只有一块磁盘响应,由于读是一个顺序的过程,所以要在数据库这个级别加上并发,才可以真正达到提高吞吐量的目的。 有人要问,stripe到底多大合适?如果我把stripe做得很小,这样不是很好吗?一个IO同时可以读很多块盘,大大提高了吞吐量。我们假设stripe为1K,Oracle一个IO要分布在8块不同的磁盘上,但是这时问题就出现了,一块磁盘是不具备并发IO能力的,如果每个IO都占用很多块盘,这样整个系统的并发IO能力就下降了,而且一个8K的IO如果在一块盘上读,和从8块盘上并行读,不会有很大的差别(也许在一块盘上读还要更快),所以stripe不能做的很小。stripe到底设多大,我的观点是大比小好,不要小于256K,数据仓库应用可以设置的更大一些。ASM对于数据文件的stripe默认是1M,我曾经觉得1M太大,将其改为128K,结果发现1M的性能更好,Oracle也推荐用1M。这说明对于数据库应用来说,stripe size要稍微大一点,而不是我们想的越细或者越分散越好。 存储划分 划分好的LUN输出到主机后,我们怎么用?这个就比较灵活多变,首先要看我们的用途,我们是追求IOPS还是吞吐量?我们用file system,raw devices,ASM?存储输出的LUN跨在多少块盘上?一般的存储没有虚拟化功能,则输出的LUN只跨在一个RAID group上,这时往往需要利用OS上的LVM来再次划分一次,看下面的示意图。 每个RAID goup有四块磁盘,建立两个LUN,输出到主机后,用蓝色的一组和红色的一组LUN分别创建两个VG,然后再创建LV(stripe),这下每个LV就完全跨在了所有的磁盘上。实际中考虑的问题要更多,有时候不仅仅要考虑磁盘,还要考虑将负载分配在不同的控制器,前端卡后端卡和多路径的问题,相当复杂。有些存储本身有虚拟化的功能,甚至可以输出一个LUN,比如3PAR就可以输出一个虚拟卷,这个卷已经跨在所有的磁盘上,我们直接使用就可以了(但实际工作中这么使用的比较少见)。 Oracle有了ASM,问题就更加复杂了,我的建议是如果可以的话,存储只做RAID1,stripe交给ASM去做。如果有些存储必须要做stripe,也没问题。存储划分是一个很有技术含量的工作,必须建立在对存储,主机和数据库深入了解的基础上,才有可能做出一个好的规划。 这里主要探讨了存储使用过程中的一些误区,随着SSD的逐步普及,我觉得将对整个存储市场格局带来很大的变化,下次我们再讨论一下SSD带给我们的机遇。 后记:存储是系统的最底层,因为非常重要,现在市场基本被几个大厂商所垄断,每个厂家都有一些忽悠人的名词或者商业上的炒作,所以我们要擦亮眼睛,谨防被忽悠。 –EOF– 更正:这篇文章中有一个错误的假设,认为Oracle scattered read是完全串行的过程,实际上在不同的multiblock read之间,存在一定程度的并行。Oracle每次同时向OS发送若干个multiblock read IO请求,然后把返回的结果合并排序。整个scattered read应该是局部并行,宏观串行的过程。 标签: 存储sequential和scattered的含义Oracle RAC廉价数据仓库解决方案 jametong 8 7th, 200923:27 回复 | 引用 | #1 对于数据仓库来讲, 可以使用大于1MB的ASM Stripe Size. tp 8 8th, 200917:46 回复 | 引用 | #2 追求IOPS还是吞吐量…盘越多iops也越大,throughoutput也一样, 这个按照SAME的观点是全部stripe. jacky 8 8th, 200918:26 回复 | 引用 | #3 Stripe And Mirror Everything,我们所有的存储,都是全部打散的。也就是每个数据文件,redo,temp,undo都是跨在跨在所有盘上。 tp 8 9th, 200911:34 回复 | 引用 | #4 是啊,那这样的话还是否需要去区分追求IOPS还是吞吐量呢? jacky 8 9th, 200921:24 回复 | 引用 | #5 如果仅仅是盘的堆砌,问题就简单了。事实上盘的数量对IOPS和吞吐量都有影响,但是有一个临界值,尤其是吞吐量而言,受制于存储的内部结构,这个瓶颈很容易达到。另外,对于存储的划分,stripe size,Oracle的一些设置都是针对IOPS还是吞吐量有差异的。所以当然要区分是IOPS还是吞吐量了。 jacky 8 9th, 200921:28 回复 | 引用 | #6 我恰恰认为一个系统从硬件选型开始,就需要明确是IOPS取向还是吞吐量取向了。这两个方向对于硬件,存储的要求有明显的不同。 bpmfhu 8 10th, 200915:16 回复 | 引用 | #7 “存储只做RAID1,stripe交给ASM去做” 你测试这个方案吗? jacky 8 10th, 200915:56 回复 | 引用 | #8 测试过的,不过用这种方案一般是低端存储或者是本地磁盘,ASM做stripe的性能要比磁盘柜做stripe的性能好。 mycolorcat 9 7th, 201012:55 回复 | 引用 | #9 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块就够了。 IOPS每块磁盘的限制我可以理解,但吞吐量每块磁盘的限制是多少呢?上面这个答案是我在一个专家那拷来的 http://blog.chinaunix.net/u3/106029/showart_2261192.html,他也是搞存储的,写的很不错,但这些数字 可以向你请教下是怎么算出来的吗?
jacky 9 29th, 201018:43 回复 | 引用 | #11 @mycolorcat  磁盘的吞吐量分为内部传输率和外部传输率(接口),不同的磁盘转速和接口类型对应不同的传输率,你可以google搜索一下,就是一个磁盘的技术指标而已。关于磁盘的接口类型和吞吐量,你可以详细看一下冬瓜头写的《大话存储》这本书,内容很详细。 如果还有问题,可以直接发邮件给我,我目前在度假,无法上网。 ruochen 10 13th, 201117:49 回复 | 引用 | #12 mysql的主机上,条带你们一般设置多大? mysql默认的page size你们修改过么? chusi 10 13th, 201118:59 回复 | 引用 | #13 请问OLTP 20%的cache命中率是怎么得出来的?这样的话内存加大到五倍不就可以把cache命中率提高到100%。当然只针对读,写的话还是要写到disk上去

网友评论

登录后评论
0/500
评论
长烟慢慢
+ 关注