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?