震彻“云”霄：详谈Amazon“云事件”始末

Amazon网络服务的中断事件暴露了用户对在线服务的期望与云计算实际运行交付能力之间深深的鸿沟。

如果你的系统在本周的Amazon云计算中发生故障，那并不应该由Amazon公司来承担责任。

有一个戏剧性的场景值得我们思考，那简直就是上个世纪那场电信危机的一个缩影：Amazon公司的冗余弹性块存储（EBS）的服务中断事件不仅涉及诸如Reddit之类的热门网站，而且还殃及Heroku等没有备用资源的互联网服务供应商。

“问题在于我们没有可供托管数据库或其它任何资源使用的替代场所，”Architectural Overflow公司的CEO Lee Buescher说，Architectural Overflow是一家向全美各地建筑商和建筑公司销售建筑蓝图和提供建筑规划服务的公司。

Buescher在Heroku基础上构建他们的业务，Heroku为其提供了一个不需要Buescher运行或维护该公司本身拥有服务器的应用程序平台。他表示，直至上周发生事件之前，相关服务的所有便利性和成本效益都是物有所值的。

现在，他的信心已经开始了极大的动摇，Buescher表示他仍十分看好云计算，只不过是错误地对Heroku在实际运行能力方面产生了过于单一的依赖性。但是云计算开发平台却因为此次其供应商Amazon网络服务（AWS）所面临的危机而获益匪浅。

“我错误地认为他们知道他们正在做什么，”Buescher说，“我从未遇到过停机时间如此之长的服务中断事件。我曾使用过其他的应用托管服务，但从来没有这样的中断服务事件。”

他补充道，由于他本人拥有数据中心运营的背景，他对Heroku所遭遇的麻烦和AWS经营者不得不修复这些级联故障均表示了深深的同情。与此同时，还有一些尚不为人知的东西。

“我深知那些工作人员正通宵达旦地修复故障，因此我被他们感动，”他说，“但与此同时，由于我正为该服务支付费用，所以我希望它能正常运行。”

Buescher说，他正在积极地寻觅Heroku的替代者，包括托管他自己的服务器和一个针对他的应用的灾难恢复计划，但他目前主要是在等待Heroku宣布如何防止类似的服务中断事件再次发生。他目前最关心的是客户与供应商之间缺乏沟通的问题。

Buescher是众多在线服务的用户之一，例如ERP软件即服务（SaaS）NetSuite和协同服务37signals.com。但当事件发生时他们对用户们的考虑呈现了极为不同层次上的考虑。

“当他们发生中断事件时，他们会积极地进行沟通，即使他们的东西并不是客户的关键业务，”他说。

#p#

Amazon用户表达了对服务中断事件的愤怒

Buescher（和其他许多用户，从Amazon技术支持论坛和社交媒体网站的评论和反应来看）对Amazon公司在服务中断事件期间缺乏补偿而感到极大的不满。他说，每个人都会遇到中断事件——这就是我们所身处的现实世界——但是不确定感和缺乏沟通则是令人非常沮丧的。他补充说，他并没有真正理解为什么他从其他服务供应商得到的客户响应等级和他试图提供给他自己客户的响应等级并不适用于AWS。

这一不确定性导致了一些AWS客户采用某些怪异把戏来引起别人的注意和AWS对其的支持：一个用户发帖子说，此次服务中断事件是一次医疗紧急事故，有可能对数百名心脏急症病人造成潜在的生命威胁。

“对不起，我无法采用任何其他的方法来达到目的，”后续帖子中如是写道。该用户表示，他们在AWS上运行了三个实例来监控数以百计家居患者的ECG信号，但自从4月21日以来就无法再看到这些信号了。

这一令人震惊但漏洞百出的帖子却招致其他用户对AWS猛烈的口诛笔伐。医疗IT系统，特别是那些有可能涉及威胁生命的系统，都是采用了具有极高冗余性和可用性的标准；用户本可能对犯罪持无所谓态度。此后该用户退而宣称监控应用是至关重要的，或者患者可能已身处危险之中，但这一戏剧性的事件凸显了用户在服务中断事件期间由于缺乏来自于AWS的响应而感受到的绝望情绪。AWS的工作人员并未对用户最初的支持请求做出反应。

其他用户在Amazon的论坛上讨论可供替代的供应商和服务，如Rackspace和Azure等。大家达成的共识是，可行的方案可能都缺少对妥善业务处理支持的要素。

“比较明智的做法，Azure比较接近于AWS”在线协作服务NextSlide的CTO Stephane Legay说，“他们把排队、存储、CDN、关系型数据库作为一种服务，把分布式缓存作为一种服务，计算节点、EBS（Azure 驱动）和现在已解决的视频流，而通常来说微软对这些服务的支持相当好。”

在服务中断开始之后的几乎一周时间里，对于AWS如何处理该故障的困惑和失望仍旧是一个问题。Amazon在其状态页面（顺便说一句，该页面运行于Amazon.com上；零售巨头的网站不会在AWS的云计算上运行）公布了其详细的常规报告，但还未作出有关该问题的公开声明，在其12小时的运行高峰期间，有可能已导致数以千计的网站和业务无法正常运行。

云计算管理服务供应商RightScale的CTO和创始人Thorsten von Eicken在一篇博客中对这一状态更新的情况提出了批评。他说，在某种程度上，他们帮助RightScale对这一危机做出了次优的决策。

“事后回想起来，我们本应当在事件早期就有意识地使我们在‘可用性受影响区域’中运行的主数据库停机，”他说，“但是Amazon并没有提供足够的详细信息来帮助我们做出这一决定。”

#p#

Amazon云计算服务中断事件的详细信息

服务中断事件始于美国太平洋标准时间4月21日上午01：30分（上午8：30 GMT），这一事件造成了位于Virginia州Ashburn 的Amazon公司旗舰数据中心EBS服务无法正常使用。在大约12小时后，AWS表示，在除一个区域以外，所有可用区域的功能均已恢复并运行正常。至4月24日晚上7:00,AWS表示，该服务运行稳定，恢复过程仍在进行中，但是直至4月25日AWS才将美国东部地区的运行状态标为正常（虽然在关系型数据库中还存在着问题）。

与EBS相比，有相当大一部分关系型数据库服务的用户；那么，其重要性何在？除用户确实喜欢的Amazon主要计算服务和存储云以外，EBS是一个附加的功能，但是该功能却为AWS的云计算环境带来了一个潜在的致命弱点。

EBS甚至为用户提供了可在启动和停止虚拟机实例时保留的状态虚拟存储卷标。对于用户来说，这是一个比Amazon的简单存储服务（S3）有用得多的功能；至于操作系统方面，EBS就如同一个硬盘驱动器一样工作。用户启用一个虚拟机实例并将其与他们的非固定EBS卷标相连，就如同将他们插在一个外部硬盘驱动器上。实例可以与大量的本地存储资源同时启用，但是当实例消失时这些存储资源也一并消失，这就造成了众多类型应用程序的可扩展性问题。

因此，EBS已成为EC2用户作为存储区域网络（SAN）服务的一种替代品。但是，正如许多人所指出的，在设计和实践方面，云计算并不是一个传统的数据中心。复制诸如AWS某些原有的架构往往就意味着，潜在的弱点将暴露无遗。已经有众多基于Amazon的高手和供应商提出了相关的警示，但它显然不是一个简单的教训而已。

#p#

云计算实施应当三思而后行

“EBS并不是一个SAN，”IT解决方案供应商Atalanta系统公司的技术总监Stephen Nelson-Smith这样写道。他说，用户必须正确看待EBS:EBS是传统、高可用性光纤支持SAN的一个模型。它完全运行于网络之上；如果网络资源使用已经达到饱和，那么你的存储功能就将不可用。他补充说，像Reddit这样对EBS有着大规模、不适当有时甚至是危险的过分依赖性的网站受服务中断事件影响极大。其他诸如Heroku之类的受害者显然只是运气非常差，其实例运行于基础设施中受影响最大的那部分设施之上。

Nelson-Smith说，用户必须能够看到Amazon所提供可靠性服务的一切，并在突然想起某些服务时进行运行预估。 “总之，如果你的系统于本周在Amazon的云计算中发生了故障，那并不是Amazon的错，”云计算管理工具制造商EnStratus公司的CTO George Reese在一篇博客帖子中这样写到。“你要么认为这类性质的服务中断事件是一个可接受的风险，要么你的Amazon云计算模型设计就是失败的。”

Reese表示，AWS的正确使用要求你进行“为故障进行设计”，即期望并预测故障并采取相应的风险管理措施，同时千万不要指望AWS来帮助你解决任何问题。

有几个值得注意的服务中断的特例。许多Amazon云计算服务的大型客户——例如Priceline, Netflix, SmugMug 和Zynga等公司 –并没有遭遇任何严重的停机事件。他们可能已经注意到了一些小麻烦，一些警告的性能日志，但是都保持在整个功能中。

SmugMug的Don MacAskill曾撰写过一个为什么他们能够承受中断事件影响的高水平评论。首先，他说他的公司将他们的服务遍布于Amazon的可用区域；其次，他们要假定服务故障是必然会发生的；“再次，我们不使用EBS”。

那么，为什么对如何正确使用云计算的争论会引起这么多人的兴趣呢？其读者队伍不断壮大；据云计算追踪网站CloudSleuth估计，目前世界上所有网络流量的三分之一强都是通过或涉及由AWS所运营的资源的。但是，所有的一切都是由易受到中断事件影响的个人、自我服务AWS客户所管理的。

虽然之前发生的中断事件是一个不好的信号，但是这将丝毫不会减缓Amazon网络服务或云计算的发展速度。它仍然是一个值得注意的警示，用户需要了解云计算是一个非常不同的、非常新的、偶尔也是非常不确定的工作方式，而部署云计算实施必须牢记这一点。

迄今为止，AWS一直拒绝对此次事件发表评论，只是表示，他们正在准备一份详细的故障报告。Heroku则刚刚公布了它自己的故障报告，部分内容如下：“HEROKU对此次深深影响我们客户的停机事件承担100%的责任。”报告中还指出，该平台还将优先考虑在多个地区的备份和可用性部署，并减少对EBS的使用。

最新更新：AWS已发布了对本次服务中断事件的解释，并提出了一份在其可用区域之一中出现事件以天计故障时的解决时间表。在日常升级期间，对备份路由器进行不当配置；而当主路由器因升级而离线时，该操作引起了EBS系统的连锁性故障。

AWS表示，此次服务中断事件在短时间内就得到了解决，但恢复操作花费时间过长是由于其存储阵列的硬盘驱动器可用空间不足，且不再遵循重用现有能力的标准程序，直至确定数据不会丢失。小部分受影响的EBS卷标将无法恢复。希望同时增加灾难恢复所需的备用能力及其升级过程中的自动化程度，以避免同类问题的再次发生。

AWS还承诺为受影响的用户提供10天的服务并向他们致以歉意。