声明:本文都是从AWS以及其他网上获取的知识整理笔记,不敢臆测Amazon内部的机制= =

Amazon位于N.Virginia的云计算数据中心于太平洋时间4月21日凌晨1点左右宕机,Service Health dashboard上写的是系统的连通性、延迟以及错误率等较高。其宕机影响了包括Quora、Foursquare、Reddit等众多的Web2.0明星应用,报道详情猛击这里,此外这篇评论也很有阅读价值(可能要翻墙,话说现在什么乱七八糟的网站都开始被墙了)。

报道中提到了Amazon没有解释为什么自己没有绕开出问题的AZ将服务转移,特意去关注了下AWS提供的服务在Failure Tolerance方面提供的一些特性。

Regions & Availablity Zones

Amazon EC2由Regions和Availablity Zones组成,按照其文档上的说明,Region由Availability Zones组成并分布在不同的地域甚至国家,AZs是Regions内部的可用区域,不同的AZ之间以工程设计的方式隔开以保证一个AZ的失效不会影响到其他AZ,同一个Region内部的不同AZ之间提供了inexpensive和low latency的通信。将自己的instance运行在多个独立的AZs中能避免自己的应用程序单点失效。Amazon目前有5个Region,分别位于N.Virginia、N.California、Ireland、Singapore以及Tokyo。

EC2的SLA协议中提到每个Region的可用性达到99.95%,EC2通过备份instance的快速启用以及预测启用提供高可靠的运行环境,These “availability zones” are supposed to ensure redundancy, but failed in this case。

Amazon Simple Storage(S3)

按照官方的说明,S3提供了高达99.999999999%的可用性,设计上可以容忍分布两个设备上数据同时丢失或者不可访问。同时利用数据版本策略对数据提供进一步的保护,用户可以保留、恢复不同的数据版本,读取中通过指定版本号可以读取较旧的数据进行恢复。此外,S3还提供了一种Reduced Redundancy Storage(RRS)的策略,RRS也会存储数据的多个副本,但副本个数会少于标准的S3服务,RRS主要用于一些敏感性不高、可再生的数据,提供的可用性为99.99%,话说这差距对一般个人使用估计也没啥吧,相对就便宜一点,支持单个设备上的数据丢失的情况。Amazon S3号称提供了一个高可靠、可扩展的安全策略用于数据的备份和隐私的归档,利用Amazon Import/Export进行大数据的导入导出,以使得从灾难中快速恢复。看了半天也就是S3说自己会对数据冗余复制在多个Facilites中,按照理解这个Facilities应该是不同的AZ。

Elastic Storage Block(EBS)

Amazon EBS是一个用于持久保存运行在instance上数据的存储块,可以创建类似未格式化的文件卷Volumn,并attach到位于同一Availability Zone的instance上,EBS本身的冗余复制到各个EBS Server都是位于同一个AZ内部的,因此并不能明显的提高可靠性。但EBS Volumn提供快照功能,可以创建数据的snapshot并存放在S3中,而S3的冗余备份会跨越多个AZ。

Elastic Load Balancing

按照AWS文档的描述,可以部署多个EC2 instance,将instances放置到Elastic Load Balancer后面,由Balancer自动的根据instance以及AZ的traffic info将请求转发到健康的instance来提高应用程序的Failure Tolerance。Elastic Load Balancer背后的多个EC2 instance既可以部署在同一个AZ中也可以跨越AZ部署,跨越AZ的instance会提供更好的可靠性。

Auto Scaling

Auto Scaling可以使得应用程序根据发展的需要动态的增加以及减少instance,因此也可以使用Auto Scaling来提高应用程序的可靠性,例如在Auto Scaling中设置条件,保证系统中健康的instance个数不会低于两个或者应用程序中任何一个EC2 instance的latency在一段时间内不能超过5秒。一旦这些条件被触发,系统就会自动的增加instance的个数从而提高服务的可用性。

从上面的一些Failure Tolerance的策略中可以看出,AWS一般提供跨Availability Zone的可靠性,数据会在AZ之间冗余,如果一个AZ中的服务不可用,会转移到另外一个AZ上继续提供服务,而N.Virginia的Region包含4个Availability Zone,这也是国外媒体质疑的地方,莫非Dashboard上写的connectivity影响到了整个Region。

AWS的EC2以及提供的EBS、Load balancing、Auto Scaling等特性确实很棒,特别适合start-up的公司,不需要投入大量资金和人力到硬件部署和升级上,报道硅谷最近的公司员工入职都是直接一台机器,上AWS编程,RoR应用很多,开发效率各种高,不过光看这次宕机影响的网站也就知道硅谷目前对于AWS的依赖程度了。不知道国内啥时候能开始接触和适应这种模式,阿里云到现在也没见到个影子啊。

之前看过一篇报道,当我们都在关注Google的技术、Apple的创造力、Facebook的影响速度时,是不是忽略了Amazon,甚至沃尔玛这样的公司对IT的影响力。

—————————————————————————————————————————–

Amazon在修复了事故之后给出了详细的报道,详情http://aws.amazon.com/message/65648/,看E文的就不用往下看了。

EBS由两个组件构成,EBS Clusters用来存储用户的数据,每一个Cluster运行在一个单独的AZ中,由多个Nodes 组成,每个Node有一个对应的备份node,当主节点感知备份node失效后,会向Cluster重新请求一个可用的Server做备份节点,进行re-mirroing过程,过程中数据访问被block;EBS Control panel则将用户请求发送到合适的EBS Cluster中,Control panel services分布在各个Region的各个AZ中。

同时EBS Cluster中的nodes通过两条网络链接。primary network具备较高的带宽,提供节点间的正常通信服务。而secondary network带宽较低,主要用于备份通信以及数据复制过程中额外的带宽,未被设计用于正常的网络服务。

N.Virginia的宕机是由于在升级过程中,网络切换错误导致产生的,本来应将primary network切换至另外一个router的primary network,结果切换到了一个secondary network上。由于secondary network低带宽无法承载系统的服务,造成了对应AZ的大量node无法连接到自己的back-up,认为back-up失效后请求cluster重新寻求备份,从而产生了re-mirroing strom。

re-mirroing storm耗尽对应的Cluster的可用空间,使得通过EBS Control panel的API进行volumn create的操作无法进行,而API的延迟设置相对较高,进而耗尽了EBS Control panel的thread pool,使得其他的API请求也无法进行,影响了其他AZ的服务。

转载请注明来源:Leoncom-《Amazon AWS的宕机事件与容错》
,
Trackback

no comment untill now

Add your comment now