你需要知道的关于高IO EC2的事儿

作者：焦杨

故事背景

笔者长期在AWS从事架构师工作，人送焦导的外号。经常遇到客户抱怨：“我选了比原来大的机器，比原来快的硬盘，可EC2的IO怎么就是上不去，到底卡在哪里了啊？你们架构师到底怎么干活的啊？”，好了，今天我也不想再背这个锅了，我们一起把这个事儿好好说道说道。

基本原理

一开始，我们先来看看磁盘上的数据是怎么到达外网的。

第一步操作系统接到IO命令，然后驱动磁盘，从磁盘上读入数据到内存处理，最后从网卡送出，通过交换机路由器送出到外部网络。要更好的IO性能，硬件层面上看无非三板斧

换个更块的硬盘
换个更快的网卡和交换机
更快的CPU、足够的内存、足够优化的

那到了AWS上，又变成什么样了呢？

云上的图

你可能看出来了：

物理机变成了EC2 instance。
磁盘为了更灵活和更可靠，把它从机器里拿出来变成了EBS。
外部的交换机/路由器由于VPC的存在，对用户变成透明的了。

稍微想想，发现实质完全没有变化。那是不是我们就可以用原有的三板斧解决性能问题了呢？

焦导的回答是：“完全没错，但是不足够”。

大家知道，公有云服务商为了保证服务质量，避免所谓的“吵闹的邻居”问题，也为了避免意外操作导致的超额费用，引入了大量的QoS特性。这里边既有我们熟悉的各个service的hard和soft的limit，也有对外暴露的各种配置选项。为了要实现高IO的目的，我们有必要对这些QoS特性有清晰的了解。

还是上边的那个图，把其中的关键部分标上号，下边一一说明

列举分析

1. EC2网络

AWS向客户提供SDN的VPC网络，屏蔽了交换机、路由器等网络基础设施。但是对单个EC2 实例的网络出口带宽是有明确的限制的。

你可能会说这不就是网卡限制吗？多加几个网卡不就行了。

请注意，增加多个网卡并不能增加单个EC2的总出口带宽。

更加详细的数据请查看这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html

2 存储网络

默认情况下，刚才提到的EC2总带宽，包含了进出EC2实例的所有流量。熟悉网络的同学应该知道，这里边包含了EC2间的计算流量、访问存储设备的存储流量等的各种流量。

要优化性能，拿出单独的网络来走存储流量就可以了。这也就是我们通常说的计算、存储流量分离技术。在AWS里，我们把这个叫做”EBS优化“。

当然了，对于一些早期机型（i2,c3等），在使用了万兆网络的情况下。因为这根管子已经足够粗，流量混在一起问题也不是很大。

EC2机型EBS优化的更多信息，可以在这里找到http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html

3 磁盘性能

要想获得高IO，选择合适的磁盘应该是最基本的了吧。是看重IOPS而选择SSD型，还是看重连续读写的磁盘吞吐而选择HDD，这是你要做出的关于磁盘的第一个决定。

这里要特别注意的几个点：

单卷IOPS的具体值和容量正相关，对于GP2而言，基准值为3IOPS/GB
对单卷有IOPS和吞吐量的限制，两个因素同时起作用
对连接了多个卷的实例，总体IOPS和吞吐量也分别有限制

另外需要注意的是，对于使用最多的GP2类型SSD，存在着读写突增特性（链接），无论多小的磁盘短时间内IOPS都可以到达3000，具体就不再展开说了。参考这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

4 存储队列

卷存储队列是指等待设备处理的 I/O 请求的队列，它的长度表明了有多少I/O请求还没有得到执行。队列过长，读写延迟加大，队列过短，读写任务不饱满。要让EBS全速工作起来，需要有足够的任务，也就是说要让EBS始终处于忙碌的状态。

基于这个认识，有必要根据工作负载的具体状况，实时观察存储队列长度的情况。对工作负载进行适当调整，以便发挥底层设备的最大能力。

这个指标可以通过Cloudwatch的VolumeQueueLength 来观察。 http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-io-characteristics.html

综合和特例

还有一些特殊的情况也值得拿出来说一下：如果我们特别在意存储网络的带宽的限制，完全可以使用带有instance-storage的实例类型，比如i系列和d系列。存储在本地，通过本地总线连接，就没有这个存储网络的限制啦。

某些情况下，追求极致的IOPS，也可以考虑使用条带化技术将多个卷合起来一起使用。

另外，如果我们的流量模型为从磁盘上一次读出，在计算节点上向多个client分发，简单的说就是具有fan-out效果的话，碰到瓶颈的地方大概率应该在EC2 intance的流出限制之上，而不是存储网络限制。

总结

总结一下，要获得期望的高IO。你需要准备

a. 合适的磁盘类型，磁盘个数，保证你需要达到IO在单卷和总卷限制范围以内。
b. 足够快的从磁盘到EC2的高速网络
c. 足够大的机型，以带来足够的inbound/outbound。
d. 适当的存储队列，保证磁盘够忙

好了，需要知道的所有关于EC2的IO性能的秘籍都在这儿了，马上动手，去榨干你购买的EC2的所有潜能吧。

作者介绍：

焦杨，AWS解决方案架构师，IT行业老兵，在Moto，NEC，路透，汉柏，AWS等国内外企业从业10余年。2011年之前，从事过web container, EJB container 和大型网站的后台研发工作，醉心于OO和设计模式。2011开始着手基于oVirt和Openstack的私有云平台研发工作，并亲密接触SDN，关注点随之转移到基础架构、分布式和高可用，自此自诩全栈工程师。 2015年加入AWS，担任解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计工作。

亚马逊AWS官方博客