Get the Hang of IOPS 翻译

原文地址http://www.symantec.com/connect/articles/getting-hang-iops-v13

引言 3

磁盘性能基本要素 3

硬盘速度-不仅仅是RPM（红帽软件包管理软件） 3

响应时间 5

磁盘传输率；又叫做“顺序读” 6

分区位录写 7

理解企业硬盘性能 9

磁盘每秒操作-IOPS 9

IOPS和数据 10

IOPS 和部分行程 11

我们需要多少的IOPS？ 13

IOPS，磁盘阵列&写惩罚 15

正规有效的IOPS 17

目标IOPS的最佳驱动数目 19

总结 20

进一步阅读 20

注释 21

 

理解IOPS

在当今的企业中, 逐渐地要求应用管理者成为不仅仅具有局限于应用层知识的IT全才。应用程序需要性能，当一个应用程序表现不佳时，我们逐渐注意到存储器是潜在的瓶颈。

  对于那些不具有存储背景的人来说，解释繁多的存储供应商指标的学习曲线是难的，而且这些信息严重过载。最难懂也是最经常误解的令人苦恼的指标就是存储IOPS（每秒进行读写（I/O）操作的次数）。通过将基本的存储概念整合在一个入门书中，这份白皮书目的在于减缓IOPS的学习曲线。一旦这些理解了，你就会明白为什么IOPS在你的磁盘子系统的性能中的作用是决定性的。

此白皮书覆盖了一下几个主题：

• 硬盘如何工作

• 驱动器的响应时间

• 解释驱动器的吞吐率

• 什么是IOPS以及为什么其如此重要

• IOPS计算磁盘阵列

• 应用程序读/写配置文件和有效的IOPS

    这份白皮书是基于Symantec connect1的同名文章。 尽管这份文档最初为Symantec's Altiris IT Management Suite企业管理者而写，但是是一份对任何应用管理者都有用的背景阅读资料。

引言

如果你是一个Altiris管理员，你可以相信我的话，IOPS对你很重要。赛门铁克IT管理套件支撑技术之一是微软SQL服务器，而且你需要确定你的SQL服务器可以胜任这一任务。有很多种方法能让你的SQL服务器表现的很好。

如下：

· 扩展服务器操作系统和SQL服务器应用程序到64位

· 确保你有足够的RAM芯片装载你的整个SQL数据库到内存中 

· 确保你机箱有足够的处理能力

· 确保文件子系统可以胜任这个任务 

· 实现数据库维护计划

· 性能监控器

上述列表中最难弄清楚的是确保磁盘子系统胜任这个任务。这很重要，你想要确保你考虑的这个硬件从一开始就适合你预期放置到服务器上的负载。

一旦你的硬件已经购置，你当然要调整你的SQL服务器如何利用已经给定的硬盘。举个例子，为了减少竞争，我们可以为操作系统，数据库，日志文件使用不同的主轴。你甚至可以为你的硬盘重新分区，以及格式化的时候调整卷块大小。

然而，规定磁盘子系统首先产生了很多棘手的问题。

1、这些磁盘真实有多快？

2、好的，现在我知道它们有多快了。那样好吗？

3、这个磁盘配置适合我的应用程序的工作负载吗？

在我们能回答这些问题之前，我们真的需要从头开始。.

磁盘性能基本要素

磁盘性能是个有趣的主题。我们中的大多数倾向于就每秒我们能从我们的存储器中得到多少MB的数据这个方面来考虑这个问题。我们日常的任务，像磁盘之间拷贝文件教会我们MB/s的数字确实是一个重要的基准。

然而，理解这些过程属于一个特定的我们称之为顺序的I/O类至关重要。举例说明，当我们在一个连续流中从头到尾读一个文件，我们实际上执行一个顺序读。同样的，当复制大型文件的时候，写入过程到新的驱动器被称为顺序写操作。

当我们谈到给一个磁盘子系统的性能打分的时候，顺序读写操作仅仅是故事的一半。为说明原因，让我们看看一个经典的机械硬盘的内部。

硬盘速度-不仅仅是RPM（红帽软件包管理软件）

一些驱动电子设备，一个旋转盘片，和一些在一个臂上在磁盘上可以旋转的读写磁头。要注意我的重点是驱动的机械方面，因为正是这些限制我们从驱动读写数据的速度。

图1：简易磁盘设计（左）和磁道中磁头的运动（右）

1、磁盘盘片

盘片是驱动器外壳里面的磁盘，上面记录了我们的信息。盘片是一种硬的材料（也就是不是软盘），通常不是铝的、玻璃的就是陶瓷的。外面涂上一层磁面，使之可以存储代表我们数据的磁位。盘片以非常高的速度绕着主轴旋转（最快的磁盘可达150mph）,其在磁头下有以很快的速度表示数据流的能力。

为了提供一种在磁盘上定位数据的方法，这些盘片被格式化为数以千计的同心圆，叫做磁道。每个磁道被划分成很多扇区，每个存储512字节的数据。因为每个供应商在盘片上记录磁信息的容量是有限制的，制造商经常不得不制造含有若干盘片的磁盘驱动，来满足其客户需要的存储能力。

2、驱动磁头

这是驱动起作用的一端。这个磁头从盘片上其下方的磁性区域读写数据。通常每张盘片有两个磁头，分别被放置在磁盘的两侧。

3、磁头驱动轴

这是一个装有磁头的集合，（通过驱动器）保证所有的头都被放置在正确的磁盘磁道上。

 

当我们考虑到磁盘性能，一个重要的对象是磁盘转速。驱动头从转速为1000RPM（转每分钟）的盘片中每秒读取的数据远远多于从转速为1转/分钟的的盘片上读取的数据。简言之，在给定的时间段中，驱动主轴转速越快，磁头能够读取的扇区块越多。

接下来，传动臂在磁道之间移动的速度也开始起作用。举例说明，考虑这个实例，这个磁头悬停在盘片的33号磁道上。然后得到一个500号磁道数据的IO请求。这个传动臂要移动磁头穿过467个磁道，从而到达请求数据的磁道。传动臂移动那些距离需要的时间将根本上限制了任意时间可以服务的随机请求的数目。为了基准测试的目的。这两个限制磁盘IO的机械速度在有时在厂家的规格说明页中会提供。

1、平均延迟时间

这是盘片经历半个磁盘旋转的时间。什么是一半？好吧，有时数据可以离磁头一整个磁盘旋转，或者幸运的话数据正好在磁头下面。因此半个旋转所花费的时间告诉我们盘片获取的数据的平均时间。

2、平均寻道时间

一般来说，当一个请求一个特定数据块的IO请求到来的时候，磁头可能不在磁盘上正确的磁道上。磁头驱动臂需要移动以便磁头可以移动到正确的磁道上面，这个磁头就等待盘片去展示磁头下面的目标数据。因为数据可能在磁盘上的任意位置，所以平均寻找时间就是磁头在磁盘上穿过一半所需要的时间。

所以当磁盘的每分钟转速非常重要（即上文中提到的平均延迟时间），这仅仅是故事的一半，寻道时间也扮演者一个很重要的角色。

响应时间

总体来讲，服务一次独立的随机的IO请求所花费的时间受到上面的延迟和寻道时间的总和的限制。举个例子，一个相当主流零售笔记本电脑的硬盘，希捷Momentus。希捷网站上它的规格是

 

转速（转/每分）	7200转
平均延迟	4.17ms
寻道时间（读）	11ms
寻道时间（写）	13ms
I/O数据传输速率	300MB/s

回到我们顺序读的特例中，我们可以看到定位到我们的数据开始的地方所花费的时间是平均延迟时间和平均寻道时间的总和。这是因为一旦磁头在磁盘上移动到正确的磁道（寻道时间），它仍然需要等待（平均）磁盘旋转一半来定位数据。定位和读取数据的总时间被称为驱动响应时间。

我听说人们因为这两个移动可以同时进行（盘片旋转的同时驱动臂也在磁盘上寻道）的原因怀疑这个公式。认为响应时间就是寻道时间和延迟时间中更大的那一个。然而，这个思考实验有一处缺陷；一旦驱动头到达正确的磁道，它不知道它下面是哪个扇区。仅仅当它到达目标磁道磁头开始读，然后运用扇区地址标记去定位自己（见下面图2）.一旦它获取了地址标记，它就知道地址标记在盘片上的位置，以及经过多少个扇区距离才能到达目标扇区。

图2 磁盘结构的图形化表示

 

结果是当磁头到达正确的磁道，我们仍然需要平均等待半个磁盘的旋转到正确的扇区。将寻道时间和延迟时间相加来提供驱动响应时间的公式因此是正确的。

响应时间=11ms+4.17ms=15.17ms

所以驱动的响应时间是稍大于15毫秒。好吧，这个听起来很小，但是这与其他驱动比较起来怎么样，还有在哪些情况下驱动的响应时间对我们来说很重要呢？为了了解驱动响应时间如何影响磁盘性能，首先来看这个是如何影响顺序读操作。

磁盘传输率；又叫做“顺序读”

大多数磁盘驱动制造商在驱动规格中提供响应时间以及传输速率峰值。传输率峰值通常是指最好的顺序读情景。

让我们假设操作系统已经指引磁盘执行一个大的顺序读操作。在定位数据的开始所花费的最初的15.17ms的平均开销后。驱动轴现在仅需要随着地盘旋转微小的移动来继续读（假设数据是连续的）。我们从磁盘上读数据的速率现在被盘片转速以及制造商能够装入每个磁道多少数据这两个因素限制。

好吧，我们知道了盘片的转速，但是盘片的数据密度是什么样的？为了这些，我们需要深入研究生产商更详细的规格表。

 

驱动规格	ST95005620AS		ST93205620AS		ST92505610AS
格式化GB（512字节/扇区）	500		320		250
有担保的扇区	976,773,168		625,142,448		448,397,168
每扇区字节数	512
物理读写磁头	4	3		2
磁盘	2			1
缓存（MB）	32
记录密度每英寸位数（位数/英寸 最大）	1490k
磁道密度 每英寸磁道数（磁道数/ 英寸 最大）	256k
面密度（Gb/英寸的平方）	394
转速（每分钟转数）	7200
平均延迟（ms）	4.17
内部传输率	152MB/s 最大
I/O 数据传输率	3.0GB/s 最大

 

这告诉我们磁道的每英寸的位数是1490,000.让我们用这个数据计算这个驱动器在这个顺序读中可能传送多少数据。

注意到这是个2.5英寸的驱动，最大的磁道长度将是驱动外面的圆周

周长 =pi*直径=3.14*2.5=7.87英寸

因为每英尺的数据密度为1490kb,这就意味着被填入一个磁道的数据的最大总和大概为 每个磁道的数据=7.87*1490kb=11,734kb=1.43MB

现在这个转速为7200RPMde 磁盘实际上转120次每秒。这意味着1秒内磁头下能够经过的数据总量最大为173MB（120*1.43MB）

考虑到磁道大概87%是数据，它给出了磁盘最大吞吐量为150MB/s。这出人意料的吻合了希捷自己的数据。（见上文希捷规格页的倒数第二行）

注意到这个计算是最好的情况-它假设数据是从磁盘最外层的磁道顺序读，而且磁头读取数据和操作系统请求之间没有其它延迟。当我们开始用数据填充驱动器，当我们进一步工作的时候磁道会越来越小（别着急-我们下面介绍分区位录写）。这意味当你向盘片中间工作的时候，这意味着磁道的数据越少了，因此在任何给定的时间框架磁头下经过更少的数据。

来看下顺序读速度能够多糟糕，让我们为直径为1英寸的磁道执行同样的计算。这给出了顺序读的最糟糕的情况为60MB/s!所以当你的用户报告他们的计算机随着时间变得越来越慢，他们可能没有想它。当磁盘越来越慢，从2.5英寸的驱动器的末端读取数据将比从开始读取数据慢2.5倍。对一个3.5英寸的台式机硬盘差距为3.5倍。

先不谈随着磁盘被填满出现的退化，本章节得出的结论是驱动响应时间不影响顺序读的性能。在这种情况下，驱动的数据密度和每分钟转速时要考虑的重要因素。

在我们进入下一个响应时间重要的场景中之前，让我们看看驱动如何成功在外侧磁道存储比内部磁道更多的数据。

分区位录写

像我在上个章节陈述过的，较长的外侧磁道比较短的内侧磁道存储更多的数据。这个似乎看起来很明显，但是并不是一直是这样。当硬盘第一次被引进市场，它们的磁盘控制器相当有限。这导致了磁道被分成扇区的方式是如下所示的非常简单几何的。特别地，每个磁道被分为固定数量的扇区，其上数据被记录。在这些盘上，盘片上每个磁道扇区的数量是一个常数。

随着控制器变得更先进，制造商意识到它们最终能够提高盘片表面的复杂性。尤其是，当磁道半径增大时，他们能够增加每个磁道的扇区数。

最优的情况是在每个磁道在其长度中记录尽可能多的扇区上，但是因为磁盘有上千个磁道，这又出现了一个问题-控制器不得不维护一个所有磁道扇区数量的表，以便能够当读取一个特定的扇区时确切知道将磁头移动到哪一个磁道。如果你继续尝试调整每个磁道的最大数目，还有一个收益递减规律在起作用。

一个折中情况出现了。盘片将被分为少量的区域。每个区域将是一个磁道的逻辑组，它包含一个详细的磁道扇区数。通过更高效地使用外侧磁道，这个有助于提高磁盘容量。重要的是这个是当它需要指出某一个特定的扇区的位置时，在没有在控制器中引进复杂的查询机制的情况下被实现。

 

图3：磁盘扇区结构  传统的扇区数固定磁道（左） 和 每个磁道不同的扇区数的分区位录入结构（右）。

上述图3展示了一个盘片表面被分成5个区域。尽管上图为了简化没有画出，每个区域的磁道包含大量的磁道（通常上千）。这个技术叫做分区位录写，简称ZBR.

在有些硬盘上，如果你用像HD Tune2的基准工具，你可以清楚地看到分区清单。这个工具从最外侧的磁道一直向内测试磁盘顺序读速度。在我的迈拓硬盘这个特例中，你可以清楚地看到从外侧磁道得到最快的磁盘传输速率。当工具向内移动，当读磁头通过拥有数量减少的扇区的磁道的区域，我们可以看到一系列阶梯。在这种情况下，我们可以看到盘片被分为16个区域。

 

分区位录写优雅的表现很难在现代驱动上发现-台阶通常被尖锐的混乱所代替。我的猜测是缓存和控制逻辑在玩把戏，导致如此多的数据突发掩盖了分区位录入的布局。

理解企业硬盘性能

既然我们已经了解了硬盘如何工作的基本要素，我们准备好了去更深入地了解企业硬盘的性能。正如我们将要看到的，这意味着从响应时间去考虑硬盘的性能而不是我们至今已经考虑过的持续的磁盘吞吐率。

磁盘每秒操作-IOPS

我们在预处理阶段看到的是磁盘的响应时间和硬盘的传输速率关系很小。传输速率事实上由驱动的转速和线性记录密度（每个磁道中扇区数目的最大值）控制。

这个回避了该问题：什么时候响应时间变得重要？

为了回答这个问题，让我们回到这篇文章开始的地方:SQL服务器。数据库的问题是数据库的I/O事实上不可能是顺序的。一次查询可能请求表顶部的数据，而下一次请求可能请求100,000行后的数据。事实上，连续的访问可能甚至在同一服务器上不同的数据库中。

当有这样的查询进行的时候，如果我们去看磁盘级别，我们会看到磁头疯了似的来回穿梭，当它试图响应传入的I / O请求来读取和写入数据时显然随机移动。

在数据库的情景下，每个小的I/O请求被服务的时间由磁盘磁头移动到目标位置的时间和读取数据的时间决定。那就是说，磁盘响应时间将决定我们的性能。当请求随机而且小的时候，响应时间反应了我们的存储设备服务一个IO请求的时间。如果我们把这个新基准放到磁头上，我们可以转化给出我们存储设备提供的每秒钟输入/输出操作。

因此，对于有15.17ms响应时间的希捷驱动器的特例，服务每个I/O平均花费15.17ms. 转化这个到我们的磁头给出了我们的IOPS产量（1/ 0.01517)）为66 IOPS。

在我们了解这个值是好是坏之前，我必须强调这个计算并没有考虑读写数据的时间。根据这些条件计算出来的IOPS值实际上是指零字节的文件传输。尽管可能看上去滑稽，它确实给出了一个好的起点，当响应时间确定，估计响应小的IO请求的时间的时候，你的存储器能够实现多少读写IOPS。

为了测量我的Seagate Momentus IOPS数据是好是坏，感受一下不同类型的存储器提供的IOPS值是很有用的。下面是基于Nick Anderson's3 的成果表格的一个增强，这里他将不同类型的驱动基于RPM分组，而且将他们的响应时间转化给出0字节读IOPS。

正如你能看到的，我的Seagate Momentus 事实上处于5400RPM的一类中，尽管它是7200RPM驱动。不用惊讶，因为它事实上是一个笔记本硬盘驱动，经常为了让移动设备更安静做出了妥协。简而言之，你的具体数据可能不同。

IOPS和数据

我们当前对于驱动IOPS的定义是基于磁盘驱动器获取0字节文件的时间。眼下担忧的是当我们开始考虑读写数据的时候我们的IOPS数据会发生什么。在这种情况下，我们可以看到响应时间和顺序传输率开始起作用。

为了评估IO请求时间，我们需要将响应时间和读写数据的时间相加（注意到写寻道正常比读寻道长几毫秒来给磁头更多的时间定位）。因此，下表图四中图表显示出当我们从Seagate Momentus 驱动中请求数据块的大小增加时，我期待IOPS将如何变化。

 

图4：随着数据块的大小增加时IOPS减少

因此我们SQL服务器情景中66 IOPS 的希捷驱动器（64KB块大小）实际上当读的时候仅仅给出了大于63的IOPS，当写的时候仅仅给出了56 的IOPS。

这里的重点是当我们谈论到IOPS（当然还有比较它们）时，确定测试的块大小和我们在谈论读还是写数据很重要。当在I/O操作被服务的总时间中传输时间开始扮演更重要的角色的时候，这些尤其重要。

因为当I/O块大小被考虑的时候,真实的IOPS值被不利地影响着（而且如果我们在写数据而不是读），厂商通常引用最好情况下的IOPS。这是从驱动中读最小数量的数据的时间得出的（512字节）。从而从驱动响应时间得出IOPS。

放置犬儒主义到一边，这种考虑IOPS的简单方法事实上大概上是好的。值得记住的是这些被引用的值总是相当乐观的。

IOPS 和部分行程

如果你记得，我们的500G的Seagate Momentus 拥有以下大概规格，

转速（转/每分）	7200转
平均延迟	4.17ms
寻道时间（读）	11ms
内部IO数据传输率	150MB/s
IOPS	66

在IOPS的范围内，我们已经决定这不是一个表现者。如果我们想将此驱动器用于SQL数据库我们将会很失望的。如果我们已经买了这块硬盘我们能做什么来提高它的性能？奇妙地，这里的答案是可以。通过在分区的小技巧，我们巧妙的可以欺骗统计数字。

来看看这是如何工作的，将 Momentus 磁盘驱动器分区，结果只有刚开始的100GB被格式化。剩下的驱动器的400GB的值，对于磁头来说是死亡区域因为它将永远不去那里。这将对驱动器的寻道时间产生很有趣的结论。现在磁头被限制在驱动表面的一小部分，意味着从已经格式化的驱动器的一段到另外一端的时间比原来磁头穿过整个磁盘的时间小得多。这个很好地反映在100GB表面驱动寻道时间，这对于驱动的IOPS产生了有趣的结果。

为了得到一些数据，我们假设大概4ms的时间用在磁头寻道时间的加速和减速（2ms加速，2ms减速）。剩下的磁盘寻道时间可以归结到其在盘片表面的移动时间。

通过将磁头必须移动的物理距离减少到磁盘表面的五分之一，我们可以期待传送时间也会同样地减小。这导致了一个新的寻道时间(11-4)/5 + 4 = 6.4ms。

事实上，由于分区位录写的原因，更多的数据被打包到外侧的磁道，这个可能是保守的估计。如果剩下的磁盘的4/5将永远不被使用，驱动数据将如下，

 

这个驱动可能的IOPS增加了50%。事实上，这现在可以与高端的7200RPM的驱动器相媲美。这个技巧被叫做部分行程，而且能够非常有效地保证慢转速的驱动器能在IOPS的方面像其高转速BPM兄弟一样表现。是的，你失去了容量，但是总的成本上却节约了。

为了看是否这个真的奏效，我用不同的分区大小和512的传输数据收集到了我的Seagate Momentus的若干的响应时间。

图5：部分行程对响应时间的影响

在图5中，我们能看到粗略的计算没那么坏；这里100GB驱动的平均IO响应时间到达11ms,快速计算的结果是10.5ms。然而，这个结果的吻合可能比判断更靠运气。我没有加上磁头稳定的时间，这个时间是驱动臂校准设置所需要的。然而这个省略很可能被我轻微的高估驱动臂加速和减速时间所忽略。

尽管这是个粗略的计算，我想这对大多数的驱动器都不会偏离太远。

你的具体数据当然会因为驱动器的模式而不同，但是举例，如果你希望为100GB的数据库获取很大的IOPS，我想一个有80 IOPS 的1TB 7200RPM希捷 Barracuda，通过出于此目的划分该磁盘，可以被转化成120IOPS的磁盘驱动器。这将改变该磁盘在IOPS方面大致相当于10k RPM的磁盘，而只用了100GB 10k RPM磁盘价格一半的成本。

从另一方面说，尽管你磁盘驱动在部分行程的情况下损失了90%的存储容量，但是从IOPS和容量的角度来说还是比升级更贵更高性能的硬盘片便宜的多。

然而请注意,部分行程不是一个来推动日常驱动器到企业磁盘阵列的机制。企业磁盘更贵是因为它们被测试和期待夜以继日地工作在更高的负载，温度和振动级。进一步地，它们拥有更长的错误（平均无故障时间间隔）和高数据完整性之间的间隔时间。

总体来说，部分划掉硬盘（部分行程）的技术，保证了一个磁盘驱动表面的大多数是磁盘磁头的死亡区域，可以将一个普通的工作台转变为一个它这一类的IOPS王。做这些的原因不是特别漂亮，或者证明了一个观点-具有大IOPS的磁盘驱动相当贵。

我们需要多少的IOPS？

当用磁盘部分划掉技术提高我们的IOPS是有趣的，我们现在考虑的是我们应该在关注这本IOPS导读中的哪部分来规定我们磁盘子系统基础设施的指标。

为了做这部分，你需要看一下真实世界中对你目标应用程序的要求。因为我从Altiris管理员的角度写这篇文章，我查看的是Symantec's ITSM 7.1 计划和实现导论。下表就是从该导论中再生产的，表现出一些一个两万节点设置的有趣的数字，这个设置中描述了高峰时期一个小时的SQL I/O。

 

 

结论是主要的SQL服务器配置管理数据库在该小时窗口中平均需要240个写IOPS。因为我们不想我们的磁盘子系统一直工作在峰值，我们可能定位我们的存储子系统能够有500个IOPS。

IOPS目标不是能够通过单独一个机械驱动器就能实现的，所以我们需要转换我们的想法到驱动阵列，希望通过聚集磁盘我们可以增加我们的IOPS。正如我们将看到的，这个时候，事情变得模糊了。

IOPS，磁盘阵列&写惩罚

迅速地看下大多数服务器引擎盖下面，可以看到众多的磁盘连接到一个特殊的磁盘控制器，叫做RAID控制器。如果你不熟悉RAID，网上有很多有用的好的关于这个主题的信息，维基百科RAID词条不是一个很糟糕的开始的地方。

总体来说，RAID代表的是独立冗余磁盘阵列。这项技术回答了保持企业数据完整性的需要，到底硬盘有预期寿命，可能有一天会坏掉。RAID控制器将底层的物理驱动器抽象成大量的逻辑磁盘驱动器。通过在数据物理分配的方式中加入容错，RAID阵列可以构造成能够在数据完整性受到危害前容忍一些磁盘驱动错误。

这些年，很多不同RAID体制被开发出用来保证数据以容错的方式被写入磁盘阵列。每个模式被分类定位到一个RAID等级。为了在有助于理解下文关于RAID性能的讨论，我们来复习一下一些最常用的RAID等级。

• RAID 0
  这个等级将被写的数据划分为很多块（通常64k）, 然后分配到阵列的所有驱动器中。所以当将一个640KB的文件写入有五块磁盘的RAID0控制器中，将首先把文件分成10*64KB的数据块。然后同时将前5块写到5个磁盘上，然后一旦写入成功，继续用同样地方式写入剩下的5块数据块。由于数据被分层写入到磁盘阵列，这个技术被叫做数据分条技术，上述的数据块大小指的是阵列的分条大小。如果RAID 0中的一个驱动器坏了，数据就丢失了，因为没有冗余。由于这里用到的分条概念是其他提供冗余的RAID等级的基本要素，所以很难从官方的RAID分类中省略RAID 0。

RAID 0 的最大的好处是其提供了一个大有改善的IO性能，因为在读写数据的时候所有的磁盘都是被同时利用的。

• RAID 1

这是最简单的RAID配置。在这个配置中，当将一个数据块写入到一个物理磁盘中，写进程也在另一块硬盘上重复同样地操作。因为这个原因，这些驱动器通常被称为镜像对。一旦发生驱动错误，阵列可以继续操作，而且没有数据损失。读的性能是降级的因为读操作是从一块磁盘中读的，而不是从两块磁盘中读取；因此阵列被称为在运转在降级状态。

• RAID 5

这是在RAID 0中加入容错的版本。在这个配置当中，每个分条层包含一个校验块。校验块的存储提供了RAID冗余，因为一旦一个硬盘出错，这个故障硬盘上的信息能被邻近的该分条层中剩余的数据块重组。这个冗余相当于使用损失了RAID 5 阵列中一个单独磁盘容量。

一旦一个磁盘驱动挂掉，一个单独的读操作可以请求读取整个分条，从而重组丢失磁盘的信息。在这个坏掉的磁盘被替换（还有重构）之前，一旦这个降级了的阵列中另外一个磁盘坏掉，这个磁盘阵列的完整性也就失去了。

• RAID 6

和上述RAID5一样，但是现在有两个驱动器存储校验信息，意味着在数据完整性被破坏之前两个驱动器可以被破坏。这个额外的冗余是用相当于RAID 6 阵列中两个硬盘容量的价值换来的（而在RAID 5中你失去相当于1个硬盘的容量）。

• RAID 10
  这就是我们提到的嵌套RAID配置-它是分条的镜像所以同样被叫做RAID 1+0（简称RAID 10）。在这个配置中你有和上述RAID 0一样的分条结构，但是现在每一个磁盘还拥有一个镜像搭档来提供冗余。因为两个磁盘的镜像同时损坏的可能性非常低，其对硬盘驱动错误的保护是不错的。你可能得失去这个磁盘阵列中相当于一半的驱动器（假设每个磁盘一个镜像的错误）。

通过RAID 10，你阵列的容量是存储容量的一半。下面图6中，我将图形化地展示RAID 5和RAID 10的磁盘配置的示例。这里每个数据块被指定一个字母加一个数字。字母表示分条层，数字表示该分条层内的数据索引。带p的数据块索引是校验块。

 

图6：图示现在两大主流的RAID配置-RAID 5(左) RAID 10(右)

正如上面所示，分条带来的最大的好处之一是性能。

让我们再次举包含5个磁盘的RAID 0阵列的例子。当写入一个文件的时候，所有的数据不能简单的写入到第一个磁盘中。然而，仅仅是第一个数据块写入到第一个磁盘中。控制器指示第二个数据块写入到第二个磁盘中，...直到所有的磁盘被写入。如果该文件还有要写入的，控制器从磁盘1的新的分层再次开始。运用这个策略，你可以同时从很多磁盘读写数据，提高了你的读写性能。

这可以很有利的提高我们的IOPS。为了了解每个RAID配置如何影响IOPS, 现在回过头来讨论RAID等级，想清楚对传入的读写请求发生了什么。

• RAID 0
  对于RAID控制器中既有读又有写的IOPS情况，在数据所在的那个物理磁盘中产生一个IOPS。
• RAID 1

对于读IOPS的情况，控制器将在镜像中的一个磁盘中执行一个读IOPS。对于控制器的写IOPS的情况，将会产生两个写IOPS-镜像中每个磁盘一个。

• RAID 5

在读IOPS的情况下，控制器无需读取校验块-它仅仅直接将读操作指引到包含有请求数据的磁盘上从而再次在后端产生一个IOPS。对于写入磁盘我们有一个问题-我们还需要更新目标分条层的校验信息。RAID控制器因此必须执行两个读IOPS(一个是读我们将要写入的块，另外一个是读取该分条中的校验信息）。我们然后需要计算新的校验信息，然后执行两个写IOPS(一个更新校验块，一个更新数据块)。一个写的IOPS导致后端4个IOPS。

• RAID 6

同上，一个向控制器的读IOPS将要导致后端的一个读IOPS.然而，一个写的IOPS将要导致后端6个IOPS来维护每个分条的校验块（3次读3次写）。

• RAID 10

一个发送到控制器的读IOPS将被导向正确的分条的镜像中的一个，所以引起仅仅后端一个读IOPS。一个发送到控制器写的IOPS然而会在后端产生两个IOPS，体现出镜像中的两个磁盘都需要更新。

当运用磁盘阵列时，我们需要理解如下的知识点：

1、对于磁盘读取，磁盘阵列的IOPS能力是阵列中磁盘的数量乘以单独一个磁盘的IOPS。这是因为一个传入的读IO在后端产生一个IO。

2、对于RAID磁盘的写入，后端执行的IOPS的数目通常不等于传入到控制器的IOPS数目

这导致阵列能够执行的有效的IOPS总数目通常比你简单的聚集磁盘的性能读出的数目小的多。

一个传入的写请求施加到后端的写请求的数目通常被称为RAID写惩罚。

每个RAID等级忍受着不同数目的上文提到的写请求，下表是一个有用的简单参考。

 

这非常有趣；发送随机IO请求的应用将会看到不同的IOPS, 取决于是读请求还是写请求。应用程序中IO的分配越偏向于写，对结果IOPS的影响就越大。因此，知道写操作和读操作占得比例在配置你的存储中很重要。应用程序供应商通常会为你提供从他们的生活环境分析得来的这些数据。

知道每一个RAID的写惩罚,用一下公式我们能够计算有效的IOPS。

 

n是磁盘阵列中磁盘的数目，Isingle是单独的一个驱动的IOPS, R是磁盘分析中读操作站的比例，W是写操作所占的比例，F是写惩罚（或者 RAID 因子）

这个公式是一个很重要的存储阵列设计工具。当建立存储阵列对随机I/O模式的基本响应时，它完全是你的首选。

正规有效的IOPS

正如提供商经常引用最大的阵列IOPS(磁盘的数量乘以单个磁盘的IOPS),你可以用另外的方式写出上面的公式。

 

 

给这个公式一点基础知识，它有助于映射到一个我们称作有效IOPS的测量。

 

这个用来从厂商声明的最大IOPS归纳出真实的IOPS数据的乘数因子非常有用。

图7中的表格展示出了不同RAID配置的正规化有效IOPS如何随着应用程序中读/写所占比例变化。这个允许你通过选择RAID等级和应用程序写设置抽象出阵列的有效IOPS。

图7：随着应用程序设定写的比例正则化有效IOPS的变化

一个具体的例子，假设一个存储解决方案由25个15K SAS 磁盘驱动构成。每个SAS磁盘驱动有200 IOPS，因此阵列被称为有最大5000IOPS。

让我们来考虑一个应用程序，被设定为100%的读，0%的写操作。当为0%的写的时候，所有的RAID类型转化给出值为1的正规化的IOPS值。没有看到写惩罚。最大引用阵列IOP也反映了你的应用程序被服务的真实情况，且独立于你选择的RAID级别。

然而，当我们考虑I/O设置中有写元素的时候，我们移动到图的右侧，沿着RAID曲线，我们的有效IOPS下降。为了证明，考虑一个读写操作各占50%的应用程序。看看RAID曲线和50%写操作的焦点证明了如下正规化和高效的IOPS值。

 

这是重要的。尽管这个阵列宣称有5000IOPS, 一旦我们实现有冗余的RAID,我们的应用程序就无法看到这个结果。

存储器的影响也值得我们花时间去考虑。镜像磁盘等级承受最小的IOPS损失，但是以可用的storage为代价。相反的，引入有校验的冗余，就磁盘容量来说更有效，但是导致了很大的IOPS损失。这是存储难题；可用容量和IOPS的权衡。

图7中，我标识出了三个区域来指出图中不同应用程序可能存在的地方。举例来说，红色区域为VDI（虚拟桌面基础架构）其读/写设置差别很大。接下来是微软交换SQL服务器的蓝色区域，这里随机的I/O模式预期大概在66%的读操作和33%的写操作。最后一个区域，绿色高亮显示是赛门铁克的ITMS SQL数据库，这里我们预期写操作占主导地位。

在应用程序要求100%的写IOPS的特殊例子中，我们看到提供商的最大IOPS严重地高估了真实世界的阵列性能。要看到底降级多少，因为看到减小的正规化有效IOPS，乘数因子当然很明确地取决于你要实现的RAID等级。

目标IOPS的最佳驱动数目

如果我们能够提前知道我们的存储阵列中需要的IOPS数目，我们可以重新整理有效IOPS等式来告诉我们满足所需要的IOPS要求的最小数目的驱动器。

 

回到Altiris ITMS的具体应用场景上，我们想起SQL服务器的要求是能有500IOPS。如果我们假设我们的存储解决方案为10K SAS 驱动，每个120IOPS，我们需要多少块磁盘来满足写IOPS请求。

下表总结了这些结果。

 

这里我们能看到的是所需驱动数量的不同取决于RAID的等级，它对你磁盘阵列的成本有直接的影响。这又一次强调了如果IOPS对你重要的话，选择RAID配置很重要。

关于RAID配置，提供商清楚地认识到写IOPS引起的性能下降，他们正在尝试如果可能的话缓存写操作。这个想法是通过投入缓存他们可以在一个更有利的窗口提交一个磁盘执行。结果是，真实场景下，控制器经常比你上面预期的数据表现得要好。然而，一旦这些阵列被高度利用，有利窗口的减少使得写缓存不太有效。这时候，阵列的表现返回到RAID配置和应用程序设置的预期值。

总结

这个白皮书的主要目的是让你更多的思考磁盘性能而不是磁盘容量，当规划你的应用程序存储需求的时候。尤其是，你需要从你的应用程序提供商那里获悉IOPS是不是可能成为你实现的瓶颈。

从这篇文章中得出的主要的要点是，

1 顺序I/O的重要指标是磁盘的吞吐率

2 随机I/O的重要测量指标是IOPS

3 当考虑你的IOPS性能的时候，选择存储的RAID等级是很重要的。

4 你应用程序看到的有效的IOPS高度依赖于你的应用程序对随机磁盘的读写的分配（读/写比 例）

5 当规划你的存储的时候，融入到你的服务器/存储器团队中。

因此，当设计你的存储器的时候，请考虑使用它的应用程序。你需要看一下他们的IOPS要求以及期望的阵列容量（允许二者同时增长）。

请记住这份白皮书仅仅是磁盘性能旅行中的一个起点。同样地，当测量和规定系统配置的时候这个文件不能被孤立地考虑。

 

 

 

 

 

 

转载于:https://www.cnblogs.com/zhaoxinyue/archive/2013/01/08/2850765.html