美国东部地区的 Amazon Elastic Compute Cloud 目前正经受严重故障的考验。众多知名网站不可用或至少受到一定影响――其中包括 Reddit、Foursquare、Quora 、Hootsuite、 Heroku 、 Assembla 和 Codespaces。故障的原因是位于维吉尼亚的美国东部数据中心中多个可用性区域（Availablity Zone）的EBS（ Elastic Block Storage ，它还支撑着 Relational Database Services）容量不足。这很有可能是网络问题导致 EBS 控制器超载后弹性恢复 Schema 生效导致的。
8:54 AM PDT：早上早些时候的一次网络事件触发了 US-EAST-1 中的大量 EBS 卷重新镜像，造成 US-EAST-1 其中一个可用性区域的容量不足，这影响了新 EBS 卷的创建，以及重新镜像并恢复受影响 EBS 卷的速度。此外，我们内部的一个 EBS 控制层面（control planes）满了，这样一来创建新 EBS 卷和基于 EBS 的实例就很困难了。 ――摘自 Amazon AWS Dashboard
诸如 eWeek 、 InformationWeek 和 CNN 之类的新闻网站很快便报道了这一事件。 GigaOm 针对那些同样脆弱的依赖于 EC2 的 PaaS 提供商（Heroku、EngineYard 和 DotCloud）进行了一番讨论。
今天，4 月 21 日 1:41 AM PDT，Amazons 的 AWS 状态页上报告：“我们正在调查 EBS 卷的延迟和错误率，还有 US-EAST-1 区 EC2 实例的连通性问题。”直到现在为止（1:48 PM PDT），我们还没有彻底解决这个问题。
除了终结者电影中宣布的天网攻击时间恰好是 2011 年 4 月 21 日以及 Twitter 上给 Amazon 工程师的有用提示之外，关于本次意外故障还有一些精湛的回复。
@scottmcnealy ：我说过网络就是电脑，但我并没说它能 100% 正常运行。
@torrenegra ：今天是《终结者》中的审判日（2011 年 4 月 21 日），天网本该把我们全灭了，幸好它是跑在 Amazon EC2 上的。
@Nicolethebear ：亲爱的 Amazon EC2――有没有试试开了再关？
通常一个 EC2 区域中的不同可用性区域是互不干涉的，因为它们是物理上隔离开的数据中心，通过优化过的连接来保证低延时。 如此说来，跨过多个 AZ 来架构系统应该能提供足够的风险管理来补偿一个或多个AZ 的故障。因此，它们的可用性保证受到了多方质疑。 PCWorld 与 Gartner 分析师 Drue Reeves 和 Reuven Cohen（Enomaly 的创始人和 CTO）一起讨论了这个话题。竞争对手云提供商 DotCloud （同样依赖于 Amazon EC2）报道了他们在本次故障中的经历，指出了一些灾难恢复上的技术问题。
Hacker News 的报道中引用了 Netflix 工程师的话，跨多个可用性区域的系统在本次故障中几乎没什么问题（“Netflix 部署在三个可用性区域里，少了一个仍可继续运行。这比彻底不可用的代价要小多了。”）
来自 backdrift.org 的 Keith 就如何处理此类停机时间给出了一些简单有效的建议。举例来说，使用配置管理系统来做镜像设置与更新（例如 puppet ），同步那些基于云的数据并保护你的 DNS 配置。 Clay Loveless 的一篇文章就此做了详细说明。
想要提前获得 AWS 问题的状态更新， Eric Hammond （Alestic）建议关注 @ylastic ，Eric Hammond 描述了如何让受影响的服务器重新上线。
今天这个事件的后果就是会有很多人对基于云的应用程序的可靠性提出质疑，需要给出必需的架构方面的预防措施以及风险管理。不仅是Amazon，其他的云提供商也必须如此，比如 VMware 的 CloudFoundry 和 Google App Engine 。另一个话题将是云提供商给出的 SLA——Amazon EC2 针对多 AZ 部署的外部连通性 SLA 是 99.95%。EBS 和 RDS 都还没有 SLA。
查看英文原文： Major Outage on Amazons EC2 US-East Datacenter - Many sites affected
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论