你需要知道的关于高 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 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/what-you-need-to-know-about-high-io-ec2/