因服务器过热,AWS日本区1小一部分EC2停机

因服务器过热,AWS日本区1小一部分EC2停机 AWS近日公布了有关《Amazon EC2 和 Amazon EBS 在东京地区 (AP-NORTHEAST⑴) 的服务恶性事件》的表明,下列为公布的原文,供各位参照。

AWS近日公布了有关《Amazon EC2 和 Amazon EBS 在东京地区 (AP-NORTHEAST⑴) 的服务恶性事件》的表明,下列为公布的原文,供各位参照。

对于在东京地区 (AP-NORTHEAST⑴) 的服务终断恶性事件,大家在这里出示更多信息内容。从 2019 年 8 月 23 日 11:36 AM CST (我国规范時间)刚开始,1小一部分的 EC2 服务器在东京 (AP-NORTHEAST⑴) 地区中单1能用区 (Availability Zone) 因为服务器过热导致停机。这致使在该能用区中遭受危害的 EC2 案例与 EBS 卷效率减少。导致服务器过热的缘故是操纵系统软件常见故障,导致受危害的能用区的一部分冷却系统软件无效。

遭受危害的冷却系统软件早已在 2:21 PM CST (我国规范時间)修补,服务器温度也修复到一切正常情况。在温度修复一切正常后,EC2 案例的开关电源供货也已修复。

在 5:30 PM CST (我国规范時间) ,绝大多数受危害的 EC2 案例与 EBS 卷都修复一切正常工作中,但仍有1小一部分的案例与卷由于过热与断电临时没法修补,由于最底层硬件配置的常见故障,在其中一些案例与卷必须更多的時间开展修补。

除 EC2 案例与 EBS 卷遭受危害外,在 12:21 PM CST (我国规范時间) EC2 RunInstances API 也遭受了危害。在受危害的能用区中,尝试起动新的 EC2 案例和和尝试应用 RunInstances API 的 "idempotency token" 作用 (1个容许客户起动新的案例时重试而不容易造成过剩的案例的作用)时,也是有产生不正确。别的沒有启用 "idempotency token"的 API 则可一切正常运行。

这个恶性事件也致使透过 "idempotency token" 应用 Auto Scaling 时,没法起动新案例。

后台管理精英团队早已于 1:51 PM CST (我国规范時间) 修补了 idempotency token 与 Auto Scaling 有关的难题。而且于 3:05 PM CST(我国规范時间)在受危害的能用区中,修补了EC2 操纵面板的子系统软件,打开新案例的作用早已能够一切正常工作中。但在本领件中遭受危害的卷所创建的新快照 (Snapshot) 依然有1定的不正确率。

本次恶性事件是因为负责操纵和提升冷却的操纵系统软件常见故障所导致,这个操纵系统软件在好几个主机都有布署以完成高能用性,本操纵系统软件中包括了容许与散热风扇、冷却器和温度感应器等硬件配置组件互相传送数据信号的第3方的程序流程,该程序流程能够立即或透过 Programmable Logic Controllers (PLC) 来与具体的硬件配置组件沟通交流。

在这恶性事件产生前,数据信息管理中心的操纵系统软件正在以便在其中1台无效的操纵主机开展备份数据解决,在备份数据解决中,操纵系统软件要相互相互之间互换数据信号 (比如:冷却设备与温度感应器互换数据信号)以维持全新的信息内容。因为该第3方程序流程中的1个不正确,致使操纵系统软件与组件过多的开展信息内容互换而导致操纵系统软件没法答复。

大家的数据信息管理中心被设计方案成1旦操纵系统软件产生不正确,冷却系统软件就会全自动进到最冷的方式,直至操纵系统软件修复一切正常为止,这样的设计方案针对大家绝大多数的数据信息管理中心全是合理的,但有1小一部分的数据信息管理中心,因为冷却系统软件没法正确进到安全性降温方式,而导致系统软件关机。大家的数据信息管理中心添加了安全性安全防护设计方案,在操纵系统软件常见故障时,能够略过操纵系统软件,立即进到净空方式将数据信息管理中心中的热空气快速排出,但操纵管理中心的精英团队在起动净空方式时产生了常见故障,因此数据信息管理中心的温度才会不断爬升,而服务器在抵达温度上限后也刚开始全自动关机了。因为数据信息管理中心的操纵系统软件常见故障,维运精英团队没法获知数据信息管理中心冷却系统软件的及时信息内容,在开展常见故障清除时,精英团队务必要对全部组件开展逐1的人力查验,才可以让操纵系统软件进到最冷方式,在这常见故障清除的全过程中,发现操纵空调组件的 PLC 操纵器没法答复,操纵器必须开展重设,是 PLC 操纵器的不正确导致了预设的冷却方式与净空方式没法正确姿势,在 PLC 操纵器被重设以后,该能用区数据信息管理中心的冷却系统软件便可以一切正常工作中了,而数据信息管理中心的太高的温度也刚开始渐渐地减少。

大家仍在与第3方供货商协作以掌握致使操纵系统软件和受危害的 PLC 无回应的不正确和后续互动。 在此期内,大家已禁用在大家的操纵系统软件上开启此不正确的常见故障迁移方式,以保证大家不容易再度出現此难题。 大家还学习培训了大家的当地经营精英团队,便于在产生这类状况时迅速鉴别和修补这类状况,而且大家坚信,假如再度产生相近状况,不管甚么缘故,大家能够在顾客受危害以前重设系统软件。 最终,大家正在勤奋改动大家操纵受危害的空气解决模块的方法,以保证 消除方式 可以彻底绕开PLC操纵器。 这是大家在全新的数据信息管理中心设计方案中刚开始应用的1种方式,即便 PLC 无回应,大家也会更为相信 消除方式 将起功效。

在这次恶性事件中,EC2 案例和 EBS 存储在同1地区的其它的能用区沒有遭受危害。另外在好几个能用区上充足实行她们的运用程序流程的顾客,在这次的恶性事件中仍然能够保持服务能用。针对必须肯定高能用的顾客,大家不断提议您应用高能用性的构架设计方案。任何与运用程序流程有关的元件都应当选用这类容错机制设计方案。

有关阅读文章:

相关阅读