通过失败 简单讨论Amazon云计算响应 (dcluo)

通过失败 简单讨论Amazon云计算响应 (dcluo)

2011-05-09 21:58

帮朋友 dcluo 分享他写的 =w=~

----------------------------------------------------------------------------------------

前言

Amazon.com 是世界领先的IaaS （Infrastructure as a Service/基础设施即服务）提供者。

其IaaS 被称为 Amazon Elastic Compute Cloud （EC2）。

在其分布式云计算系统里，负责多线程存储的子集被称为 Amazon Elastic Block Store （EBS）。

在本文里，主要想讨论的的是，EBS系统引起的EC2系统的大面积崩溃。

EBS系统概述

EBS体系结构是一个分布式数据（自我）复制数据储备系统。

其主要功能就是最优化的处理多线程和最小延迟的EC2 读和写操作。

EBS服务包括两大部分：

1）机群在有效地带内来存储用户数据和请求传递来自EC2。

2）CPS（Control Plane Service）机群来协调在每一个有效地带的用户请求与EBS机群的和谐度。

一个EBS机群是由EBS节点组成。这些节点用来复制和保存 EBS数据卷信息以及读写请求。

EBS数据卷被复制到多个节点来保证数据的持久性和可用性。

每一个EBS节点利用P2P技术来迅速处理容错转移以及侵略性复制如果任何一个备份异步或者不可用。

在EBS机群里，每一个节点连接到两个网络：一级网络和二级网络。

一级网络是一个高带宽的网络，用来传递EBS，EC2和CPS节点间正常操作请求。

二级网络是一个低带宽网络。其主要作用就是提供可靠备份网络数据而不是来执行一级网络的数据操作。

正如大部分的云系统，当一个节点发现他正在侵略复制的主机掉线或者高延迟，

节点立即认为目标节点下线并马上在系统里找新的节点来保证数据持久性（再次镜像）。

再次镜像的步骤如下：EBS节点在EBS机群里寻找一个节点有足够的数据空间来建立连接并繁衍数据。

在一个正常的可执行EBS机群里，寻找一个节点的速度是以ms来计算的。

来更进一步的保护用户的数据，当数据被再次镜像时节点会一直保存数据，直到确认存储节点（目标）有完整的数据以及权限。

当然为了保证数据一致性，在这些步骤里存储数据的IO都是锁定的。

CPS的作用十分重要。CPS接受用户的请求并将请求指向正确的目标EBS机群。每一个EC2区域都有且只有一个CPS群组。

但是CPS的结构却是一个分布式节点分布在可用地带的每个角落来提高错误包容度。

CPS系统相当于EBS机群的控制者当节点选举出主数据存储者。

事件过程

在2011年4月11日凌晨12：47分，

Amazon的管理员在一个北美区域的可用地带网络里执行了一次正常的AWS （Amazon Web Service）一级网络扩容操作。

在扩容的过程中，其中一个常规步骤是把所有EBS节点的一级网络关闭并引导到一条备份一级网络上。

或许是周一凌晨的缘故，管理员无心地把网络流量引导到了一条低带宽的二级网络。

对于大部分的EBS机群，这是一个噩梦。他们没有一级网络（引导到二级网络），而且二级网络无法支持这么多的流量。

如同计算机世界里的任何队列，当lambda 增长，系统可用性会大幅度减少。

管理员的这个失误，迅速影响着可用地带的EBS节点。

这些被影响的节点的反应速度远远低于系统门槛（Threshold）被EBS机群孤立出来。

和普通网络的中断不一样，这个疏忽让系统里每一个节点孤立起来。分布式运算的机群变成了一堆独自消遣的计算机。

当这个连接问题发生后，根据EBS节点的机制，每个独立的计算机在循环尝试寻找EBS机群里的可用节点来备份数据。

当管理员纠正错误的时候，这些被影响节点迅速搜索EBS机群里的可用空间来镜像他们的数据。

由于这些都是大规模同时进行的，网络带宽以及数据计算和读写的利用率几乎是瞬间被消耗掉。

正常毫秒区间搜索的操作被延长为无限大。EBS机群里的可用存储空间也在短时间内被完全用光。

很大一部分没有找到备份的节点，陷进了这个循环寻找可用空间的消耗过程。

不要忘记我前面的介绍，在这个过程里，所有的数据读写都是被锁定的。

根据Amazon的人说，当时可用地带的系统里13%的主机都陷入在这种没有出路的循环中。

云系统里所有节点都是链接在一起的。事发后，这个EBS机群的失效迅速影响到了CPS。

当EBS机群大量吞噬可用地带的空间时，新的服务以及API请求将不会被建立。

直接影响CPS的用户请求全部长时间超时。这些缓慢的API请求被系统备份并引起了CPS的线程饥荒。

正如路由器一样，CPS群有一个线程池（也可以看作黑箱式的队列）来保证每一个用户请求。

当线程被用尽，CPS将不会继续执行任何API请求。

2：40 AM， Amazon为了阻止幂次递减的系统可用度和锁死，迅速成立了个应急小组阻止了新建的API请求。

大概过了10分钟，系统的延迟和APIs的出错率才略有下降。小组开启其他EBS机群的API。

这次事件中，两个因素引起了该EBS机群的崩溃：

1）一个节点在没有找到备份节点的情况下，没有停止搜索，而是循环地在机群里继续寻找可用空间。

2）节点寻找备份的竞争机制。在云计算里，竞争是经常发生的事情。

对于一个可用空间，每一个节点都去抢。其结果就是大量的连接流量被用来分配空间该给哪个节点而进一步延迟整个系统。

5：30凌晨，API请求的错误率和延迟再一次增长。

当一个数据册在执行再次镜像的过程中，EC2，EBS和CPS之间会进行三方会谈来保证整个云系统里只有一个数据的备份（确保数据一致性）。

会谈中，三方的作用分别是：EC2来确定数据的位置，EBS来存储，CPS来仲裁。

由于上一段讨论的竞争制度，没成功备份的EBS节点与CPS的通讯增加，

大幅度降低了CPS的可用率，减慢了API反应速度，再一次的引起了整个系统低（无）效率运行。

于8：20AM， 应急小组再一次的禁止了在可用地带受影响的EBS机群以及CPS的所有通讯。

再一次的组织了所有用户的API请求来尝试减缓系统中延迟以及错误率。

应急小组的首要目的是在不影响更多EBS机群的情况下来还原受影响的机群数据。

终于在11：30 AM， 小组开发了一个方法来阻止受影响EBS机群无意义的备份请求。

这个方法使Amazon的云系统没有进一步被恶化（当时18%的节点被影响）。

该机群的一些节点被慢慢还原为可用，并减少受影响到13%的可用地带。

这个事件从21日凌晨持续到中午，

用户的请求一直受到高错误率的影响直到应急小组启用了一个新的EC2系统可用地带来代替受影响系统。

起初过高的错误率开始慢慢下降，然后小组发现一些不严谨的警报系统并修正了CPS系统。

半个小时后，整个系统逐渐恢复正常。

受影响EBS机群的恢复

直到12：04PM，Amazon云处理的服务断供得到了控制并仅局限于一个可用地带。

受影响的EBS机群已经稳定了。APIs 在其余的机群已经恢复正常运行且没有增加的堵塞空间。

应急小组的新目标是如何还原这约占13%的受影响主机内的数据和其队列APIs 请求。

主要的方法其实很简单，引入多余的数据空间，让堵塞的节点找到空间并备份来解锁。

对于引入新空间，应急小组面对两个挑战：

首先，当往一个节点镜像失败，主机停止再向这个节点进行备份尝试直到该所有数据都被成功备份。

这是一个缜密的决定，因为这种机制可以让即使在服务器未预料的行为中，数据可以很好的恢复。

可是这却使应急小组需要引入大量的数据空间到网络来替换现有机群中的数据。

这是一个消耗时间的工作：

所有的数据需要重新分配到新加入的物理主机（别忘了，这些服务器不是在一起，而是散落在北美的各个地方）。

其次，由于每个节点的主机都停止了他们的P2P处理孤立起来。重新分配这些可用空间也是一个棘手的问题。

应急小组必须很仔细的更改节点之间的流向来引导到新安装的服务器，而不是旧的服务器。这两耗费了比预期更多的时间来解决。

直到4月22日2：00AM， 小组才成功开始引入了一定的数据空间来启动积压成山的数据请求。

直到22日的12：30PM， 系统里只有2.2%的主机还未从过多的请求中恢复。

这些主机需要时间重新接受EC2请求以及从新连接到CPS寻找新的可用空间。

当所有主机都有足够空间后，首要任务就是重组CPS的API请求让受影响的系统，逐渐执行这些API而不影响节点的备份操作。

起初，小组尝试新建一个CPS平台来稀释这些请求。可是在短时间内新建的CPS太粗糙。

分配任务的任务仍然不能保证系统在一个稳定的状态。

直到4月23日的上午，应急小组才把新的CPS优化到稳定程度。

11：30AM，这些受影响的系统终于开始执行队列里的API请求。

下午3：35PM，所有系统恢复为可操作状态，这些受影响的EBS机群重新开启与CPS的通讯链接。

直到 6：15PM， 新的API请求才允许访问这些EBS系统。

当重新开启APIs后，这些EBS主机逐渐恢复正常，可是剩余的2.2%必须要求管理员手动恢复。

小组给系统创建了一个S3快照，来测试和调试他们的代码。

此时已经是4月24日12：30PM，还有 1.04%的数据需要恢复。

于 3：00PM，最终0.07%的数据被判定为无法修复为稳定状态而被放弃。

对Amazon Relational Database Service（RDS）的影响

此次事件不仅影响了EBS系统，同时也对RDS系统造成了损失。

RDS是一个建立在EBS系统之上的数据库以及日志存储系统。

当EBS收到影响，寄存在云系统里的RDS也被影响，导致可用地带无法访问。

用户可以选择操作RDS系统在一个可用地带（single-AZ）或者多个可用地带(mult-AZ)。

Single-AZ数据库的所有操作局限在一个可用地带。

当一个地带受到21日类似的事件，该地带的所有Single-AZ也会被影响，如果其中的一个EBS机群被锁死。

而且由于RDS会同时访问多个 EBS机群，所以系统里一个EBS机群被锁死，RDS被锁定的几率也相对很高。

4月21日-22日，在Single-AZ机群里受影响的RDA达到 45%。

不过，当EBS数据被恢复的时候，RDS数据的回复也是几乎瞬间完成的。

对于无法恢复的EBS机群数据，RDS启用了自动备份，以及Point- in-time数据库恢复操作。

RDS在multi-AZ采取重复存储的策略并同步复制数据在不同的可用地带。

当两份数据其中一个坐落在受影响的空间里，RDS系统会自动将错误转移并备份到另一个空间。

这次事件对multi-AZ的影响相对较小，2.5%的RDS无法自动转移数据而锁定在 IO过程。

其主要原因是，备份期间目标节点的为响应使RDS也同样被孤立起来。这使对自动寻找错误转移的机制不稳定。

相对，这些系统需要手动的引导来解决此类问题。

预防此类事件再次发生

这个事件的主要因素是由网络的设置引起。

Amazon管理团队需要重新审核对云系统的修改步骤且增加自动化元素来预防人为操作失误。

为了防止集体性质的备份发生，预警机制需要改善。增加预留数据的空间以及重构节点之间的竞争机制。

对于云系统来说，没有先后顺序的集体行为是可怕的。想必Amazon已经深刻体会到了这一点。