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的高手和供应商提出了相关的警示，但它显然不是一个简单的教训而已。

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

　　“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天的服务并向他们致以歉意。