Amazon EC2大规模停机事件

　　2011年4月21日，Amazon的虚拟主机服务EC2发生大规模停机，时间超过两天，影响波及Reddit、Foursquare、Quora等众多网站。事后Amazon对此次事故作了详细分析。事故起因是Amazon对集群网络作日常维护升级时操作错误，网络流量被全部切换到备用网络，导致备用网络过载。自动故障恢复机制检测到网络不通，认为服务器大量宕机，马上开始数据复制以替换“宕机”的服务器上的数据副本，引发了“镜像风暴”(大量服务器同时尝试创建数据镜像)。而由此增加的数据流量更加剧了网络过载，从而使故障在集群中蔓延，进入恶性循环。最终采取了包括暂时关闭自动故障恢复系统和增加硬件在内的多种措施，服务于故障发生两天半以后恢复。

　　在此案例中，故障自动检测和恢复的策略是“在数据副本所在服务器失去联系时，复制数据”。这一策略对“一台服务器故障”这种小范围的常见问题很有效，然而在大范围故障如“网络过载”的场景下，可能会起反作用。在这个案例中，如果根本没有故障自动恢复机制，故障影响范围反而不会有那么大。

　　实际上，这一模式在过去的大规模分布式系统故障中反复出现：发生了未曾预料到的、中小范围的故障

　　故障自动恢复机制采取了错误的手段

　　故障恶化，进入恶性循环

　　Amazon S3存储服务2008年的故障就仅仅是由于故障自动检测机制的自身状态中一个bit出错，然而故障同样迅速蔓延到整个系统，导致服务在没有发生硬件故障的情况下不可用。

　　对此，我们的策略是限制故障自动恢复机制的作用范围：

　　正常情况下，任何时候集群中都有且仅有很小比例的服务器发生故障，此时自动恢复有效，即使无效也不会造成灾难;

　　如果发生(罕见的)大范围故障，明智的策略是尽量降低系统负载，因为此时实际上已不可能靠故障自动恢复来保持服务质量。万一此时故障自动恢复机制试图进行大量操作，并超出预设的限制，即暂时禁止掉这部分逻辑。

　　以前面提到的硬盘访问变慢为例：考虑到硬盘平均日故障率小于千分之一，我们给前述的疑似问题硬盘自动下线机制设置上限，例如，任何时候只能通过此机制下线总数1%的硬盘。此限制可以防止极端情况下，如大量硬盘出现问题，或者自动下线机制本身故障时，故障恢复机制本身不会引发灾难。

　　数据可靠性和实时性能优化

　　云环境中，由于分布式系统有硬件故障多发的特点，保证数据可靠性成为文件系统的一个挑战。

　　在飞天云计算平台的实际运营中发生故障最多的硬件是硬盘。硬盘故障占阿里云数据中心故障总数的80%。原因之一是硬盘是数量最多的部件，例如一个3000节点的集群就有30000多块硬盘，即使硬盘本身的平均无故障工作时间(MTBF)达到1,000,000小时，30000块硬盘也意味着平均每33小时就有一次硬盘故障发生。实际运营数据显示硬盘厂家标称的MTBF值并不可靠，生产环境的硬盘故障率可以几倍到几十倍于标称值。

　　硬盘故障最直接影响的就是盘古分布式文件系统。为了保证数据安全性，盘古文件系统对所有的数据均采用了多份拷贝。在创建文件时，用户可以指定文件数据的拷贝数目，文件系统会保证数据分布在不同的节点和不同的机架上，使得单个硬件故障不会造成数据无法访问。

　　多副本技术是业内广泛认可的有效防止数据丢失的技术，通常采用流水线方式传递写需求以减轻单个节点的负载。但这会导致数据写入的延迟增大，因为只有当所有副本都写成功后才能结束一个写操作。

　　由于磁盘读写特性，上述多副本写入磁盘的延迟通常在几十毫秒量级，有时可达100毫秒以上。云环境中的线上应用，有时会有更高的实时性要求。盘古通过内存日志文件(in-memory redo log)来解决此问题。

　　内存日志文件的基本思想基于以下事实：虽然服务器因为掉电或者宕机丢失内存数据的概率高于硬盘损坏的概率(所以在单机系统中我们会把日志文件写入磁盘以避免内存数据丢失)，但多台服务器同时故障的概率却可以低到能够满足数据可靠性的要求。对于实时性要求高的应用，盘古提供接口，使得数据文件进入指定数量服务器的内存即可认为是写成功;盘古的后台线程随后会把内存中的数据批量写入磁盘。

　　盘古在保证内存日志的可靠性和低延时上做了如下考虑。

　　保证redo log是多份拷贝的，避免单机故障造成数据损坏或丢失。

　　为降低写入延迟，确保redo log写入多个数据服务器内存buffer后即返回成功，由后台工作线程保证内存数据在很短时间内持久化到磁盘。

　　严格检测redo log数据的健康状态，并及时采取补救策略确保数据的可靠性。