BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Amazon Web Service服务稳定状况受到质疑,9月13日美国东一区服务宕机

| 作者 Chris Swan 关注 567 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2013年9月24日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

在9月13日周五早晨,Amazon Web Service(AWS)在美国东一区的服务再次出现宕机,由于这一地区是整个Amazon最大、时间最长久并且业务最繁忙的地区,这次宕机使包括Heroku、Github和CMSWire在内的一大批主流应用服务中断,还影响到了其它许多Amazon的客户。

就在最近这次宕机事件发生数日前,关注云端服务的评论者Ben Kepes还撰文写道:“每次AWS的宕机事件,看起来都是由于东区导致了服务故障。”Kepes还引用了分析师René Büst的一段文字,其中将美国东一区的服务描述为“陈旧、廉价并且脆弱的”。

Amazon目前还没有提供详细的故障报告,但上周五的问题已经基本可以归结为网络故障。在2011年4月的一次故障也是与网络问题相关,但在2012年12月2012年10月发生的最近两次故障都是由弹性负载均衡(Elastic Load Balancer – ELB)和弹性块存储(Elastic Block Storage - EBS)服务出现问题而导致的。网络与EBS的故障危害性尤其巨大,因为它们会导致多个可用性区域(Availability Zone)(本应作为故障边界)产生故障,或者使提供容错能力的更高级别服务(例如ELB)中断。

一般来说,应用程序的提供者只会使用传统的架构方式,而不会为了云端服务以及它固有的不稳定性进行针对性的设计,许多应用程序都不会考虑在一个或多个地区(region)中使用多个可用性区域。但即使针对这些故障进行专门设计,也不见得一定能避免问题的发生。Netflex使用的那套被戏称为“猿猴军团”和“混沌猴子”的工具一直被遵为云端设计的典范。他们有意持续不断地为自己的平台产生各种错误,并以此证明整个平台良好的自我修复能力,但有些时候(如平安夜宕机事件)这个平台还是不能提供能够承受来自四面八方的负载的能力,使得某些客户所使用到的服务质量下降。

东一区连续不断的宕机,以及那些本应力挽狂澜的服务(例如ELB)的无所作为,为Amazon在“基础架构即服务”(Infrastructure as a service)这一市场上的竞争对手带来了机会。Google近期就为Google计算引擎发布了它自己的负载均衡服务,并且提供了一份关于设计健壮的系统的良好提议

查看英文原文:Amazon Web Services Stability and the September 13th US East 1 Outage

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT