近来在 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?
评论