东京地区(ap-northeast-1)的单个可用区(AZ)中发生了一定比例的EC2服务器过热。

注意:EC2服务器不是EC2实例,而是运行EC2的主机服务器。因此,会发生可用区域中EC2实例和EBS卷的性能下降。过热是由于受影响的可用区中的某些冗余空调管理系统出现故障,一些EC2实例和EBS卷在受功率损耗和过热影响的硬件主机上运行。恢复这些实例和卷需要时间,其中一些需要由于底层硬件去处理。

本次事故发生该如何处理 

监视



早期的合理规划很重要,EC2、RDS绝对要监视,利用好ELB的健康检查,尽可能跨多个AZ部署和备份。重点提下「Service Health Dashboard」的RSS URL监视(URL:https://status.aws.amazon.com/)之前一直忽略这个监控点,看到别人的总结使用Slack监视URL,值得参考借鉴。对于使用的服务尽可能做到全部监视。

恢复与备份

定期AMI备份,AWS Backup服务器的灵活运用,RDS Multi-AZ不差钱的可以考虑,费用是双倍。

————-以下是官方处理公告————-

2019年8月25日(日本時間)初版:发布说明  https://aws.amazon.com/jp/message/56489/

2019 年 8 月 28 日 (中国标准时间) 更新:

在我们一开始的总结中提到,这次事件影响了东京区中一个可用区(“AZ”)里的一小部分。被影响到的有Amazon EC2及EBS资源,一些使用到受损EC2资源作为底层硬件的其它服务(比如RDS,Redshift, ElastiCache 以及 Workspaces)亦受到了影响。在我们进一步和客户调查这个事件的时候,我们也看到了一些少数的例子,客户在用多个可用区的时候也受到了一定的影响(比如一些客户在同时使用Application Load Balancer,以及AWS Web Application Firewall或者粘性会话时,遇到了比预期比例還高的内部服务器错误)。我们会直接和被这些少数问题影响的客户直接分享更多详细的信息。

关于 Amazon EC2 以及 Amazon EBS 在东京区域 (AP-NORTHEAST-1) 的服务事件的说明 <–(官方说明链接)

针对在东京区域 (AP-NORTHEAST-1) 的服务中断事件,我们在这里提供更多信息。从 2019 年 8 月 23 日 11:36 AM CST (中国标准时间)开始,一小部分的 EC2 服务器在东京 (AP-NORTHEAST-1) 区域中单一可用区 (Availability Zone) 由于服务器过热造成停机。这导致在该可用区中受到影响的 EC2 实例与 EBS 卷效能降低。造成服务器过热的原因是控制系统故障,造成受影响的可用区的部分冷却系统失效。受到影响的冷却系统已经在 2:21 PM CST (中国标准时间)修复,服务器温度也恢复到正常状态。在温度恢复正常后,EC2 实例的电源供应也已恢复。在 5:30 PM CST (中国标准时间) ,大部分受影响的 EC2 实例与 EBS 卷都恢复正常工作,但仍有一小部分的实例与卷因为过热与断电暂时无法修复,因为底层硬件的故障,其中有些实例与卷需要更多的时间进行修复。

除了 EC2 实例与 EBS 卷受到影响外,在 12:21 PM CST (中国标准时间) EC2 RunInstances API 也受到了影响。在受影响的可用区中,尝试启动新的 EC2 实例和和尝试使用 RunInstances API 的 “idempotency token” 功能 (一个允许用户启动新的实例时重试而不会产生多余的实例的功能)时,也有发生错误。其他没有调用 “idempotency token”的 API 则可正常运作。这个事件也导致透过 “idempotency token” 使用 Auto Scaling 时,无法启动新实例。后台团队已经于 1:51 PM CST (中国标准时间) 修复了 “idempotency token” 与 Auto Scaling 相关的问题。并且于 3:05 PM CST(中国标准时间)在受影响的可用区中,修复了EC2 控制面板的子系统,开启新实例的功能已经可以正常工作。但在本事件中受到影响的卷所建立的新快照 (Snapshot) 依旧有一定的错误率。
本次事件是由于数据中心负责控制和优化冷却的控制系统故障所造成,这个控制系统在多个主机都有部署以实现高可用性,本控制系统中包含了允许与风扇、冷却器和温度传感器等硬件组件相互传递信号的第三方的程序,该程序可以直接或透过 Programmable Logic Controllers (PLC) 来与实际的硬件组件沟通。在这事件发生前,数据中心的控制系统正在为了其中一台失效的控制主机进行备份处理,在备份处理中,控制系统要彼此互相交换信号 (例如:冷却装置与温度传感器交换信号)以保持最新的信息。由于该第三方程序中的一个错误,导致控制系统与组件过度的进行信息交换而造成控制系统无法回应。我们的数据中心被设计成一旦控制系统发生错误,冷却系统就会自动进入最冷的模式,直到控制系统恢复正常为止,这样的设计对于我们大部分的数据中心都是有效的,但有一小部分的数据中心,由于冷却系统无法正确进入安全降温模式,而造成系统关机。我们的数据中心加入了安全防护设计,在控制系统故障时,可以略过控制系统,直接进入净空模式将数据中心中的热空气迅速排出,但控制中心的团队在启动净空模式时发生了故障,所以数据中心的温度才会持续攀升,而服务器在到达温度上限后也开始自动关机了。由于数据中心的控制系统故障,维运团队无法得知数据中心冷却系统的即时信息,在进行故障排除时,团队必须要对所有组件进行逐一的人工检查,才能让控制系统进入最冷模式,在这故障排除的过程中,发现控制空调组件的 PLC 控制器无法回应,控制器需要进行重置,是 PLC 控制器的错误造成了预设的冷却模式与净空模式无法正确动作,在 PLC 控制器被重置之后,该可用区数据中心的冷却系统就可以正常工作了,而数据中心的过高的温度也开始慢慢降低。

我们仍在与第三方供应商合作以了解导致控制系统和受影响的 PLC 无响应的错误和后续交互。 在此期间,我们已禁用在我们的控制系统上触发此错误的故障转移模式,以确保我们不会再次出现此问题。 我们还培训了我们的本地运营团队,以便在发生这种情况时快速识别和修复这种情况,并且我们相信,如果再次发生类似情况,无论什么原因,我们可以在客户受影响之前重置系统。 最后,我们正在努力修改我们控制受影响的空气处理单元的方式,以确保“清除模式”能够完全绕过PLC控制器。 这是我们在最新的数据中心设计中开始使用的一种方法,即使 PLC 无响应,我们也会更加确信“清除模式”将起作用。

在这次事件中,EC2 实例以及 EBS 储存在同一区域的其它的可用区没有受到影响。同时在多个可用区上充分执行他们的应用程序的客户,在这次的事件中依然可以维持服务可用。对于需要绝对高可用的客户,我们持续建议您使用高可用性的架构设计。任何与应用程序相关的元件都应该采用这种容错设计。

针对这次事件造成的不便,我们感到十分抱歉。我们理解对于我们的用户的业务来说,稳定的服务有多么至关重要。我们也从未满足於我们所提供的响应速度以及服务品质。对于这次事件,我们将会尽一切所能从此次事件中学习并且继续不断改善我们的服务。

 


发表评论

电子邮件地址不会被公开。