迟来的观后感——伪存储专家谈IOPS

本文主要是介绍迟来的观后感——伪存储专家谈IOPS，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

微信号 VMCloud

篇前语：

看到封面，相信参加过在北京举行的2014年亚太区域MVP Open Day的朋友一定不陌生，当时这篇名字为“Hyper-V的数学作业“的课程震撼了在场的每个人的心，包括笔者跟当时跟我一起前往的领导也深深被贾浩老师这篇既有实例又有数据的公开课所启发并在之后的项目中一直收益。当时听完贾老师的课之后，我甚至直接联系到贾老师本人跟他探讨IOPS之余，还要了课件继续做研究（由于保密协议要求，该课件不方便公开，抱歉抱歉，不过本篇解读将会“隐晦“地分享该课件的精华之处，虽远不及贾老师现场讲解的万分之一，但权当抛砖引玉），以下是当年跟贾老师的邮件：

笔者一直忙于应付考试、项目等事没时间整理总结这篇微文，众所周知，目前的虚拟化实际上已经发展到几乎人人皆知的地步，在做虚拟化的过程中，可能很多人或多或少会遇到虚拟机卡、应用莫名访问慢（除开应用本身问题）、数据库死锁多（除开架构优化问题）等情况，而且很多情况下CPU、内存、网络都非常好，甚至占用都不到10%，这到底是为什么？

（免责声明：以下内容由StatLee扮演的StatLee编写，与StatLee本人无关！）

正文部分：

首先，请问下存储相关的参数是什么？在1、2年前，很多非IT人士可能会回答容量、品牌，IT人士可能会回答容量、转速、读取、写入速度。Ok，容量、转速无可厚非，读取、写入速度这个怎么来衡量呢？很多人可能会回答：“可以看拷贝、复制文件的速度嘛，每秒多少兆多少兆嘛。“没问题，您这样回答OK的，那么我怎么凭借每秒速率来设计我的的底层架构？怎么考虑并发？是平均吗？

通过每秒速率然后平均分摊来设计架构，事实上就算是这样简单的算法都很少人这样做，这样做到底可不可以？据我目前了解，大部分设计者都是基于存储容量考虑，以下我列举一个在VMCloud群里曾经有人问过的问题，姑且称呼他为小明吧（小明躺枪）：

小明：“求助各位大神，我有10块300G的盘可不可以放60台虚拟机T T”

大蛇：“小伙子，没问题的，每个系统盘40G来算，你3T够的！：）“

小明：“好的，谢谢大神！：D”

第一反应我看到这样的问题，我很汗颜，第二反应，看到这样的回答，我更汗颜，当然回答者说的实际上也没有错，确实，40G，60台，差不多也是要2400G（约合2.4T）。

但是！这样的答案真的对吗？这位小伙子以后真的在10块300G盘上跑满40台虚拟机会不会有问题呢？

回答这个问题之前，我先来回答前面所提的按照速率平均分摊设计架构究竟可不可以。可以！人家只计算容量设计都没问题，您连速率都考虑进去了肯定比只考虑容量来得慎重啊！更准确的回答，其实您可以选择比速率更加专业的方式，就是今天所要谈的——IOPS。

IOPS由于最近几年存储的瓶颈越来越突出，越来越多的ITPro都明白这玩意儿的重要性，那么到底IOPS是什么鬼？如何决定存储的性能？

先上Wiki百科对IOPS的解释（传送门：http://en.wikipedia.org/wiki/IOPS）：

简而言之，IOPS是指存储每秒可接受多少次主机发出的访问，主机的一次IO需要多次访问存储才可以完成的一个“指标“。以下是IOPS的计算公式：

看起来蛮复杂的，我要怎么去计算呢？实际上很多时候我们都不需要用到这个公式（如果您真的想纠结下的话，也可以试试，我尝试过，误差不会很大），接下来，咱们来聊聊实战。

实战：

IOPS的加入，仅仅是为您的规划有一个更加精细，但是再精细的估算，也是估算，再上估算之后的存储环境也会受其他的性能参数（诸如网络、内存、处理器等限制），由于本篇只讨论存储，故不考虑其他性能条件（即默认都是满足要求的），所以请不要纠结于精不精准。废话不多说，那么先上一组数据（相信大家都比较熟悉了）：

常见SAS盘可提供的单盘IOPS（可能有不同版本有多多少少的误差，无所谓了）

常见系统的IOPS需求（可以看到最高的要求是50左右，我们按照内存比来计算，8G内存大概需要100+IOPS）：

常见Raid级别的IOPS比例与计算方式（可能就比较少人考虑了，并不是叠加计算），我们此篇为能够简单暴力的表达IOPS的规划，暂时不考虑应用的读写比例，就以物理的IOPS读写比例来进行计算：

再来个比较夸张的IOPS例子做对比（当然SharePoint、Exchange诸如此类都是吃IO大户，这里暂且以SQL为吃IO大户吧）：

Ok，现在我们可以来回答小明的问题了，到底10块300G的盘，能不能撑下60台虚拟机？鉴于小明提的问题实际上也不是特别明确，基于谨慎的原则，我们来设计两个场景：

10块1WRPM SAS 300G，无Raid，60个虚拟机均为常规系统，且内存、CPU均为4G，2 Cores
10块1WRPM SAS 300G，Raid 10，60个虚拟机80%为常规系统，内存为8G、2 Cores，20%为重型应用（以数据库的2313IOPS为例子），内存为16G、2 Cores

a场景到底IOPS满不满足需求呢？步骤如下：

供：计算无Raid级别的IOPS：10 * 140 = 1400

需：计算60个虚拟机的IOPS需求：50 * 60 = 3000

供 < 需，而且是远远小于，这里我们是以小明手上是10块1WRPM的SAS，如果连1WRPM都没有呢？明显的，当虚拟机数量达到小明说描述的要60台的时候，整个虚拟化平台基本也就瘫痪了。

来看看b场景，步骤如下：

供：计算Raid 10级别的IOPS（读写比2:1）：(10*140)*0.7 [即2/3]+2*(10*140)*0.3 [即1/3] = 1820

需：计算60个虚拟机的IOPS需求：50 * （60 * 0.8）+ 2313 *（60 * 0.2）= 2W+

不多说了。

这么说，小明的虚拟化平台是不是没救了？非也，实际上合理设计，是可以让10块1WRPM SAS盘顺畅跑60台虚拟机的，我们就说60台虚拟机全部跑常规系统吧：

首先考虑Raid级别，无Raid下仅有1400 IOPS提供明显不够，且生产环境也不能裸跑，让我们来考虑下如何做Raid，先整理需求：

IOPS需求： >= 3000（60*50）

容量需求： >= 2.4T（60*40G）

也就是说，我们需要选择这么一个存储方案：

if 存储方案IOPS >= 3000 then

print “可以继续考虑容量啦！“

if 存储容量>=2.4T then

print “就是这个方案啦！“

else

print “IOPS满足，但是容量不满足，弃选！“

end if

else

print “连IOPS都不满足，不用考虑容量啦！“

end if

如果有多个存储方案，我们就应该选择一个最具性价比的，Ok，有了需求，咱们来设计下几种Raid方案的所能提供的IOPS与容量：

Raid 0 ：生产环境不考虑 ×
Raid 10：可提供1820 IOPS ×
Riad 5：可提供 2100 IOPS ×
Raid 6：可提供 3500 IOPS √ 容量提供(n-2)*300=8*300=约2.4T √
到这里，大家应该明白，要如何考虑存储方案了吧？So，小明的问题答案就是：可以，但是需要做Raid 6才能支撑，且不能有类似SQL一样的重型应用，为保证容量冗余，建议加多两块盘。
下面再举个例子：
问：3块15K 1T 容量SAS是否满足 10台8G内存、2 Cores 虚拟机（搭载普通应用）？
答：首先，10台高性能虚拟机总共需要100*10+（100*10）*20%=1100 IOPS
而3块15K1T容量 SAS采用无Raid，最大只能540 IOPS，故需要采用Raid 6才足够满足该例中的需求（可提供1296 IOPS，当然需要加多一块盘才可以组成Raid 6）。故3块 15K1T容量的SAS满足10台高性能虚拟机。
那么究竟这样设计对不对呢？笔者不能说精准，但是误差并不会太大，下面是按照我们设计的方案做成的虚拟化平台设计测试的整体测试的结果：

（上图是前期测试，故未用专业工具测试）

（上图是根据业务60%、数据40%的比例，使用IOMeter测试出来的结果，比较精确）
再举个反例，某一天有位朋友问我，他们的虚拟机异常的卡，性能资源蛮充足的呀，不知道是什么原因：

嗯，后来我丢了个HDPro上去，测试结果：

再后来，这个问题我了解到他们平台有一台SQL数据库一直在读写，而他们的存储实际上并没有那么高的IOPS提供，故建议让他们停止或迁移SQL到别的存储上即可。
关于IOPS测试工具，除了要快速展现结果之外，我强烈建议用IOMeter，这个工具可以根据业务负载来进行测试，得到数据比较精确，必要时您还可以结合Loadruner进行测试哟：）

总结：
讲到这里，基本上对于存储设计这块基本也就讲完了，实际项目中，各位看官还是得根据项目实际来做规划，应当考虑上其他的性能条件，比如贾浩老师在Open Day提到过CPU线程的问题，并且以著名的阿姆达尔定律来做解释：

或许笔者讲得例子可能是错误的，在这篇文章中，笔者想表达的是一种思考存储的思路。 但在设计方案中，特别是虚拟化平台项目中，前期的规划特别重要，CPU、内存、网络固然重要，请千万别忘记存储设计，也不要仅仅对容量进行考虑，否则在日后客户使用过程中肯定也会给您带来麻烦，希望今天的这篇微文能给您以后带来一点点“抛砖引玉“的启发吧：）