Amazon EC2因订购过多而导致内部网络延迟？

近来在Amazon EC2用户社区中，有各种各样的报道，说他们的实例遭遇到性能很差的情况，而这是由很高的内部网络延时所导致的。这导致有人推测对Amazon的云的订购可能超过限度了。

aw2.0公司的Alan Williamson撰写了一篇报道，主要是关于他在Amazon EC2上的体验的，他抱怨说，Amazon是公司唯一使用的云提供商，看起来它在开始时能够适应得很好，但是有一个临界点：

在开始的日子里Amazon的表现非常棒。实例在几分钟内启动，几乎没有遇到任何问题，即便是他们的 小实例（SMALL INSTANCE）也很健壮，足以支持适当使用的MySQL数据库。在20个月内，Amazon云系统一切运转良好，不需要任何的关心和抱怨。

……

然而，在最后的八个月左右，他们“盔甲”内的漏洞开始呈现出来了。第一个弱点前兆是，新加入的Amazon SMALL实例的性能出现了问题。根据我们的监控，在服务器场中新添加的机器，与原先的那些相比性能有所下降。开始我们认为这是自然出现的怪现象，只是碰巧发生在“吵闹的邻居”（Noisy Neighbors）旁边。根据随机法则，一次快速的停机和重新启动经常就会让我们回到“安静的邻居”旁边，那样我们可以达到目的。

……

然而，在最后的一两个月中，我们发现，甚至是这些“使用高级CPU的中等实例”也遭受了与小实例相同的命运，其中，新的实例不管处于什么位置，看起来似乎都表现得一样。经过调查，我们还发现了一个新问题，它已经悄悄渗透到到Amazon的世界中，那就是内部网络延迟。

类似地，cloudkick也报告了实例的高网络延时：

几周之前，我们发现在Cloudkick上的ping操作的延时图看起来非常奇怪。

……

我们在EC2上的监控节点会对位于Slicihost上的四个不同的服务器进行ping操作。结果到处都是平均ping延时。

……

结论是什么？ Alan Williamson关于EC2被过多订购的帖子看起来非常合理。支持EC2的网络看起来遭遇了不定期发生的延时问题。

甚至在AWS论坛上也有来自于EC2客户的帖子，他们也遭遇了网络问题:

今天上午9：15，我们有个实例开始变得没有 任何响应。有时你能够登录上去，有时登录不了。这种情况还没有自动解决，另一个实例（假定在那个实例上有硬件问题）出现了同样的问题。我认为可能存在网络的问题。

我可以登录一两次，有时会变得一切正常，然后又变得没有响应了。有谁知道什么原因？

实例的ID是i-c4921fad 和i-a0e3d7c8。当试图从位于另一个EC2区域的计算机连接我们的计算机的时候，我也发现了同样的网络问题。

Alan报告说，在出现紧急情况的时候，他试图通过快速部署新实例来解决，但是没起作用：

在特别的“救火模式”中，我们花费了至少一个小时来启动新的实例，然后停止它们，直到找到对我们的网络流量确实有反应的节点。

在虚拟化的环境中，特别是在“吵闹的邻居”的情况下，你恰好位于一个节点，它相邻的实例的计算量都非常大，这看起来不是好事儿，因为有这样的趋势，EC2会为相同的一组计算机分配新的实例（PDF）。

你可以找到关于云计算和Amazon EC2更多的信息，就在InfoQ中文站。

查看英文原文：Is Amazon EC2 Oversubscribed and Suffering from Internal Network Latency?