你的位置： &&
【虚拟化实战】存储设计之五IOPS
【虚拟化实战】存储设计之五IOPS
在存储设计中最常用的一个性能衡量参数就是IOPS，但是不是仅IOPS就足以帮助我们作出设计决定呢？这方面有很多认识上的误区。绝大多数情况下仅仅单独考虑IOPS是没有意义的。本文以一个案例来带你了解全面考虑影响存储性能的方方面面。因为影响存储性能的因素太多了，而且不同存储产品的特性和处理方式也不同，为了简化的目的，本文暂不讨论Write/Read ratio，Sequential/random, &RAID Penalty，Cache，Dedupe，auto-Tiering，Partition Alignment等因素。衡量指标：Throughput单位时间内传输的数据量。往往以KBPS或MBPS来衡量。Latency (响应时间)指完成一个IO请求所需要的时间。往往以milliseconds来衡量。IOPSInput-Output Per Second。衡量在一秒内能完成多少读操作和写操作。Latency和IOPS的关系IOPS = 1000/(Seek Latency+ Rotational Latency)以上公式仅仅是在单个Disk的情况下的计算。这当然不能反映真实环境。但帮助我们大概了解二者的关系。下图的数据很老，仅仅说明不同类型Disk支持的IOPS是不同的。RPMIOPSSSD600015K17510K125720075540050以上是最简化的情况，没有考虑Write/Read ratio，RAID Penalty，Cache等因素。那么在使用商用存储阵列情况下，我们可不可以说IOPS越高，Latency就越低呢？不可以简单下这个结论。IOPS和Latency不是简单的线性关系，在IOPS小于一个数值（比如3000之内），IOPS越高可能Latency就越低。一旦超过该临界点，比如IOPS在4000的时候，Latency可能是IOPS在3000时的3倍！这个临界点取决于使用的阵列。在你看到某阵列支持Million &IOPS的数据时，别高兴的太早。也许该阵列处理那么多IOPS时Latency会高达30 ms！如果你的应用对Latency要求很高，比如信用卡系统的实时Transaction，大于4ms的Latency足以让该Transaction失败.Block Size，Throughput和IOPS的关系虚拟化架构师常考虑的一个问题是，前端接口卡（HBA，iSCSINIC）的带宽需要多大？后台存储能否有能力处理预计的IOPS？假设有一个桶，桶的容积是一定的。可以容下很多小球，可是只能容下几个大球。这里球的容积指的是一个操作的BlockSize。BLOCK SIZE:Block size是由具体应用程序来决定的，同一个应用在不同情况下Block Size也是不同的。比如Oracle在处理Online Transaction时Block Size 是2KB或者4KB ，而在decision support system中的BlockSize是8KB,16KB & 甚至16KB。EXCHANG2007使用8KB，SQL最小使用8KB，而SAP使用64KB下面的公式是描述Block Size，Throughput和IOPS的关系Throughput（MB perSecond）* 1024( Convert KB to MB)/Block Size (KB/IO) = IOPS情景一以某种备份应用程序为例，连续地写操作，Block Size是64KB，如果采用16Gb FC HBA, 那么Throughput是1700 MBps ，套用该公式得出：1700MBps * 1024 /64KB = 27,2000 &IOPS相对于8Gb FC而言, 16Gb FC的Throughput值更大，也就意味着能传输更高的IOPS。千万注意这只是考虑了前端的情况。后台的存储能否处理这么多的IOPS呢？那就要咨询你的存储提供商了，在保证支持该IOPS的同时，Latency也要满足你应用的要求。情景二刚才我们是在预先假定Throughput一定的情况下来推算从前端传输到后台存储的IOPS，我们也可以反过来应用那个公式。假设一个采用iSCSI共享存储的虚拟桌面环境，每台win7虚拟机20IOPS，一共有200台，那么对存储的要求是能处理20*200=4000 IOPS。通常window的I/O size是4KB，那么iSCSI NIC的速度需要多快呢？X * 1024 / 4 KB = 4000 X=15.625 MBps &or 0.12 Gbps.这意味着1Gbps的iSCSI完全能满足上述要求。通过我们上面的两个情景，一正一反两种方式应用了那个公式。本文出自 “坐看云起” 博客，请务必保留此出处http://frankfan./4831
最新热门tag当前位置： >>
评析存储未来发展的趋势
摘要：俗话说：“如果你问五个经济学家对于某事的观点，你将得到十四种不同的答案。”大概就是说任何的评论员都能容易地给你一些关于某个主题的解释，但是经济学家似乎比他们能解释得更好。我相信随着科技的急速发展，IT也一样。所以说存储更是这样，从技术到用户，再到应用，都在飞一般地变化着。
　　当几位专业人士聚到一起的时候，他们的话题总会转到存储的未来上。比如说我和HenryNewman在一起录制关于Linux文件系统这一系列的节目时，我们就会被问到，当我们领导着这一领域时，将会发展什么类型的文件系统或存储技术。
　　我决定写一些关于存储未来发展的趋势，尤其是存储设备和分层软件，因为我觉得这两个主题需要放在一起来说。
　　7200转与SSD欲分天下15000转或陷囧境？
　　我们发现，越来越多的应用的性能是由IOPS性能控制的。在高性能计算（HPC）中，检查应用I/O模式显示小的读写函数调用比之前预估的更为普遍。从典型的程序中可看出，读取GB级数据甚至TB级数据有大量的1k和4k的读写函数调用。所以，通过这些工作负载不难看出，占主导地位的IPOSI/O模式已深入到操作系统和文件系统中。
　　有些任务是去帮助操作系统处理以IOPS为主导的工作负载。其中一个方法是在存储中使用大量的缓冲区，允许系统将小的读写函数合并成为大的函数调用中去。因为这样能够减少IOPS的影响，可能会使得工作负载变得更有顺序。然而，这样有时会需要巨大的缓冲区来做这个事情。此外，这还会导致很大的延迟，因为每个被保留在缓冲区的具有I/O功能的数据试图合并到一个单一的请求中。在试着转换IOPS工作负载到连续的工作负载之间有一个分界线，它并没有升级到非常高的延迟。因此实际的结果很大一部分取决于那些特殊的应用以及工作负载。
　　我们还发现，有比我们预想更多的工作负载使用随机IOPS而不是连续IOPS。连续的IOPS是合适的工作负载，因为许多系统能够接受它们而且能将它们合并到单一的请求中，仅使用极小的缓冲区，因此只有很小的延迟。所以致使所需的IOPS比我们期待的要小。但是如果有足够临近的IOPS功能，你可以将请求转换到单一的更大的I/O请求中。然而，对随机的IOPS来说，没有太多你能够做的事情，除非在存储服务器中做个特别大的缓冲区。
　　使用这些趋势，应用到存储设备中，能够看出当应用正在运行中时，我们需要更大IOPS能力的设备。我以IOPS的能力来将存储设备按如下归类：
　　&7200转SATA/SAS驱动器：100-125IOPS性能
　　&15000转SATA/SAS驱动器：200-300IOPS性能
　　&SATA/SASSSD:IOPS性能
　　&PCIeSSD:0000IOPS性能
　　对第一项来说，这些数字是随机或连续的IOPS，尽管一些设备有很低的随机IOPS性能，你可以看出在旋转磁盘驱动器和固态硬盘之间的IOPS性能有很大的差异。在7200转的SATA硬盘和PCIeSSD的IOPS上有三到四个数量级的差异（从）。与此同时，每GB存储的价格的也有数量级的差异，在7200转的SATA硬盘和PCIeSSD之间大概差2-3个数量级。
　　最后，从7200转硬盘到PCISSD或SSD上具有2-20种不同容量的差别。我们知道目前已经有3TB容量的SATA/SAS硬盘了。虽然现在也有更大容量的SSD或PCIeSSD，但他们的价格都贵得出奇。因此，SSD或PCIeSSD的所谓&标准的&容量应该在200GB到1TB之间。大容量的7200转的硬盘具有非常高的性价比但IOPS性能非常的低。另外，虽然SSD的IOPS性能非常高，但性价比又非常低。
　　夹在中间进退两难的就是1.5万转的驱动器了。性价比高于SSD，低于7200转的驱动器。然而，当你把SSD也考虑进去做比较时，15000转的驱动器的IOPS性能并没比7200转的好多少。
　　我认为，1.5万转的驱动器已陷入了一个窘境。我估计它将在几年之内便会消失，只剩下7200转的驱动器和SSD驱动器。毕竟15000转的驱动器集成了旋转驱动器的缺点（低IOPS）和SSD的缺点（低容量与低性价比）。按逻辑想一下就会得知，企业将会在基于SSD的存储器上运行应用，然后将其储存在7200转的驱动器上（或存储在磁带机上）。
　　分层技术：目标已定如何实现？
　　然而，未来根本不是有保证的。为了实现这一目标，我们必须找个好的方法有效地将数据从7200转驱动器中迁移到SSD中。我不认为将固态存储放入旋转存储中作为额外的缓存是一个正确的方法。然而，还是有一些相当有趣的存储系统是使用SSD作为缓存的。
　　整合这两种类型存储（低成本，大容量的旋转驱动器和SSD）最显著的方法是使用分层技术。分层技术成功的关键就在于能够在两个存储层中快速的迁移数据。比如，你可以从一个应用中拦截open()调用程序一直到开始迁移不同层中的数据。如果结合一系列应用，而且这些应用在运行中使用高速的存储设备，你就可以得到全部效益却不需花费全部费用。为此，存储系统和分层必须识别当何时需要做数据迁移，然后快速地执行。
　　另外，在一个应用运行之前，数据或从低速存储器中被迁移到高速存储器中。这被称作为&数据迁移升级&（Stagingthedata）。这种方法能用于HPC中并产生良好的影响，因为应用使用排程器（Jobscheduler，也称为资源管理器)来运行程序,当用户指定一个事件时，它是如何运行的，需要多少处理器来工作，需要多大的内存，哪个文件被用作输入，哪个文件被用作输出。以上这些，用户都能够提交自己的排程器中。排程器能够决定用户指定要求的任务在何时何运行。排程器还能从低速存储器中复制输入文件到高速存储器中，以便为将要运行的应用做准备。当应用运行结束的时候，排程器可将文件从高速存储器中再迁移回低速存储器中来。
　　但是分层的方法比使用作业调度器更好，因为它们发生在用户不知道的背后。然而，现有的分层软件不见得有能力快速识别数据何时需要迁移到高速存储器并快速实现这一行动，所以它有极限值。大多数的分层软件需要存储了解文件中数据块的使用模式。过一段时间之后，可能会将它们迁移到基于测定的高速存储器中（也可能是预计的）。因此，现在真正需要的是更出色的分层软件，而不是目前这样不给力的软件。
　　现有磁盘不给力新老结合才王道
　　这只是一个预言&&我很容易错误的认为我是对的，但是我认为我们有必要思考未来存储的发展方向。我们目前着眼于工作负载，更多的是基于IOPS。但与此同时我们还需要更大的容量。可关键在于，当运行应用的时候，我们真的仅需要高IOPS性能，因此我们可以把一部分存储做成一个基于固态盘的小型系统，在合理价位上具有高IOPS性能，但同时只有较低的存储容量。然后，我们再建一个容量很大但是性能很低的存储池，使用大容量和低成本的7200转驱动器。因此，我认为15000转的驱动器将会于未来几年在市场上消失。
　　另外，成功的关键还在于将两个存储池通过中间件结合在一起，确保数据能够容易的在两方之间迁移。使用分层软件或许是最好的解决方案。但是现有的软件实在很糟糕。因因此，需要做的就是快速地确定数据在何时必须从低速存储器中迁移到高速存储器然后再迁移回来。由于数据迁移的原因，这不会具有太高的应用性能。
　　责任编辑：Randy
本文地址： 网友评论:
条 阅读次数：
版权声明：凡本站原创文章，未经授权，禁止转载，否则追究法律责任。
·····
《哈佛商业评论》前执行主编Nick
美国联邦储备局理事会在新的战略
Netflix最近开设了一项金额为10
宝马集团已引进印度最大外包和咨
9成的中小型企业更愿意把他们的
将近60%的企业放缓了其虚拟化计Amazon推弹性数据块存储 IOPS性能翻倍 - 推酷
Amazon推弹性数据块存储 IOPS性能翻倍
Amazon最近告知弹性数据块存储(EBS)的用户，现在每个EBS的IOPS可以达到2000，对比原来的1000 IOPS，翻了一番。
最近告知弹性
(EBS)的用户，现在每个EBS的IOPS可以达到2000，对比原来的1000 IOPS，翻了一番。
“对于高端15000RPM硬盘而言，此番IOPS性能的提升超出了用户的预计，”Amazon在其博客中如是说。“如果此前你一直是通过磁盘
技术来获取更高性能，现在或许可以用更少的阵列获得更高性能。”
Amazon称EBS将提供额外10%的性能，以保证卷的可用率达到99.9%。
为了实现更高的IOPS，客户可以将多个存储容积结合在一起制作一个EC2应用，使其更能满足I/O集中型的加载需求，如数据库存储或传输进程。据该公司透露，SAP提供了IOPS大于20000的环境。Amazon称客户还可以请求发布EBS 优化的EC2实例(数据传输率从500到1000Mbps不等)。
Amazon EBS支持的存储容量在1GB到1TB之间，可通过EC2实例来扩增。 EBS提供的IOPS的价格为每月每GB起始费用0.125美元，每月每IOPS需花费0.1美元。
责任编辑：存储 &&联系邮箱：chai_.cn
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见