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

阅读数:21 2019 年 11 月 11 日 08:00

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

作者:焦杨

故事背景

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

基本原理

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

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

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

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

那到了 AWS 上,又变成什么样了呢?

  • 云上的图

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

你可能看出来了:

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

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

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

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

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

列举分析

1. EC2 网络

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

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

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

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

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

2 存储网络

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

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

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

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

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

3 磁盘性能

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

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

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

  • 单卷 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 的所有潜能吧。

作者介绍:

你需要知道的关于高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/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布