Amazon云服务故障分析

上周四即6月14日，Amazon位于美国东部的数据中心出现故障，并影响了AWS多项云服务以及基于之上的Heroku、Quora等知名网站。16日，Amaozn公布了事故分析。事故是由公共电网故障引起，并引发了一系列连锁故障。：

事情的起因是电缆故障影响了高压配电系统。

6月14日20：44左右，一电缆发生故障，进而影响了高压配电系统。2个为可用区域提供电力的公用变电站出现故障，进而使得整个供应区供电不足。但这个情况是可以处理的，亚马逊启动了备用发电机，保证了所有的EC2实例和EBS存储成功转移。

然而，20：53，1个备用发电机因其风扇过热造成了超负荷运转而断电。所以采用备用发电机（由一个完全独立的配电电路完成额外发电能力）的方案也宣告失败。更不幸的是，在这套特定的后备电源分配电路中，一个断路器被错误配置为在低功率阈值时打开，这样，当负载转移到该电路时，错误发生了，该断路器断路了。

20：57，当该电路断路器断开时，实例和存储失去了主要备份电力或二次后备电源。受此影响客户的实例和卷是运行在多个可用区域的，只能在此环境中等到电力恢复才能正常运行。

15日10：19，发电机风扇被替换并安装好，发电机开始提供动力。电力逐步恢复后，受影响的实例和存储也开始恢复。

10：50，绝大多数实例已经恢复正常。但对于EBS存储（含启动块）而言，电力不足之时写入会有数据损失，也就是这些存储可能存在不一致的状况。这并非是潜在的不一致，因为即使是存储上I/O停顿，EBS也会在线直接反馈出受损状态。用户只能通过验证存储上的一致性来恢复它。

最后，16日1：05，超过99%受影响的存储才得以解决。

总的来看，EBS-related EC2 API的损失集中在20：57-22：40.具体来看，这段时间内，可变系统调用（如创建，删除）失败，进而直接影响到客户发布新的EBS-backed EC2实例。EC2和EBS APIs实施在多个可用复制数据存储区。EBS数据存储被用来存储元数据等资源的卷快照。一个主要的EBS数据存储因为这个时间失去了动力，使得系统无法将数据存储的副本放到另外一个可用区。一般来看，为了保护数据存储，系统会自动翻转为只读模式，直到电力恢复可以启动可用区，进而尽快恢复到一致状态，并返回到数据存储读写模式，使得启用可变EBS调用成功。但这个事件中，这一保护方案没有起到作用。

未来，为了保证数据存储实现快速切换，亚马逊将实施变革。高压配电系统以及所有运行实例和存储将采用全冗余电源。此外，亚马逊还完成了对所有备用配电的审计。在审计中，亚马逊还发现了另一个设置有问题的断路器。至此，亚马逊表示，已经确定所有断路器都是正确的配置了，并会进行定期的测试和审计。

最后，亚马逊对在这次事件中受到损失的企业表示了歉意。

CSDN观点：从亚马逊的解释来看，颇有“屋漏偏逢连夜雨”之慨，但也从另一层面看出对于数据中心的任何一次事故而言，所需要提供的应对方案应是复杂的，连续的，方案之外，定期测试也是必须的。在该事件之后，有很多有价值的分析与评论，特选择一些和大家共享。

ericabiz：（自2001-2007年一直经营一个专用服务器托管公司）

在托管实施设计中，电池要有足够的力量来支持发电机。但这也会带来一个巨大单点故障的可能性。一个更好的设计是通过飞轮产生足够的电力。不过，对于一般数据中心而言，一年左右的时间内总会遇到这些发电机故障。

亚马逊有着好的设置，但是没有进行有效的测试。

顺便说一下，这也是问你的数据中心供应商的一个好问题：是否拥有两个完全冗余电源并包含PDU和发电机器的系统？多长时间进行一次测试？如果一个电路单元/发电机失败，我如何设置服务器来保证应用不失去动力？

有一个正确的方法：多电源保证每一个服务器连接到2PDUs或连接到2个不同的发电机——但这是昂贵的，许多最低端的托管服务提供商是无法接受这个成本的。

rdl：

大型余热发电设备（比如利用蒸汽、建筑、供热设备产生的废热等）往往采用grid-backup模式。举个例子，麻省理工学院的热电厂（几大天然气涡轮机），也有很多大学利用蒸汽加热，很多工业遗址也证明了这些。它归结为成本和分区允许。显然比起运行一个24*7的发电机，其更容易获得许可证。而从实际价格上看，利用余热更能体现循环价值。

服务器租用/服务器托管中国五强！虚拟主机域名注册顶级提供商！15年品质保障！--亿恩科技[ENKJ.COM]