微软Azure澳洲数据中心宕机超24小时！因值班工程师不足，无奈关服务器

人生(杂谈)  /  管理员 发布于 1年前   504

近日，位于澳大利亚悉尼的微软 Azure 服务突发中断，导致用户在超过 24 小时内无法访问 Azure、Microsoft 365 和 Power Platform 服务。而后微软针对此次事故发布了一份初步分析报告，引发众人关注。

这份报告将原因归咎于“电力骤降导致一个可用区内的一个数据中心的部分冷却装置处于脱机状态”。由于冷却装置无法正常工作，温度升高迫使数据中心自动关闭。

与此同时，微软也诚实地指出，冷却装置本来是可以手动启动，但由于偌大的数据中心配备值班工程师不足，所以想要手动开启受阻。据外媒 itnews 披露，当时只有 3 位值班工程师。

这一事件发生后，不仅为许多拥有数据中心的云服务公司敲响了警钟，也让人产生了「一个数据中心应配备多少位 IT 工程师才足够」的疑问。

数据中心的冷水机组故障，只有 3 个人的团队不足以应对手动重启

回顾整体事件的来龙去脉，要从 8 月 30 日发生在澳大利亚悉尼一场严重的雷暴天气谈起。

据澳洲天气预报机构 WeatherZone 称，那天，在短短三个小时内，该市就记录了约 22,000 次雷击，约 30,000 人因暴风雨受到停电的困扰。

根据微软的复盘报告显示，从 2023 年 8 月 30 日 8:41 UTC（协调世界时）开始，澳大利亚东部地区的电力下降导致一个可用区内的一个数据中心的部分冷却装置脱机。

微软表示，两个受影响数据中心的冷却系统由 7 台冷水机组成，其中 5 台冷水机在运行，两台冷水机在电压骤降事件之前处于备用状态（N+2）。

当电压骤降事件发生时，运行中的 5 台冷水机组全部出现故障。

此外，只有一台备用机组在工作。

距离断电一个小时之后，现场工程师抵达屋顶制冷机区域，随后立即执行了记录在案的应急运行程序 (EOP)，尝试让冷水机重新启动，但未能成功。

未能成功的原因或是因为现场人员不足导致，微软表示，“由于数据中心园区的规模，夜间团队的人员配备不足以及时重启冷水机组”，那时园区的现场人员只有 3 个人。

关闭服务器，实现降温

当然除了现场配备人员不足这个因素之外，冷水机组本身也存在一定的故障。

初步调查显示，当时运行中的 5 台冷水机故障之后并未自动重启，原因是相应的水泵没有收到冷水机组的运行信号。

「这一点很重要，因为它是冷水机组成功重启的关键」，微软在报告中写道，“我们正在与我们的 OEM 供应商合作，调查为什么冷水机组没有命令各自的泵启动。”

正因此，出现故障的冷水机组无法手动重启，导致冷冻水回路温度已超过阈值。

这样的状态持续到了当天的 11:34，受影响的数据中心的组件开始发出基础设施过热警告，跳出关闭选定的计算、网络和存储基础设施的提示。因为按照原始内部设计，关闭这些功能可以保护数据持久性和基础设施运行状况。

别无选择之下，微软当晚值班的工程师只能关闭两个受影响的服务器。

恢复之路困难重重

好在关闭服务器来降低热负荷的做法行之有效，“这成功地使冷冻水回路温度降至所需阈值以下，并恢复了冷却能力”，微软在报告中写道。

尽管如此，并非一切都顺利恢复。

根据初步复盘报告显示，当日 15:10 时，所有硬件恢复供电，后来存储基础设施开始恢复上线。然而，随着底层计算和存储规模单元上线，依赖的 Azure 服务也开始恢复，但有些服务在重新上线时遇到问题。

从存储角度来看，七个租户受到了影响，其中包括五个标准存储租户和两个高级存储租户。虽然所有存储数据都在跨多个存储服务器进行了备份，但在某些情况下，由于多个受影响的存储服务器出现故障与延迟，所有备份均不可用。

导致存储基础设施恢复全部功能延迟主要有三个因素：

其一，
一些存储硬件因此前数据中心温度升高而损坏，故需要进行大量故障排除。
由于存储节点本身未在线，诊断无法识别故障，因此在现场数据中心团队需要手动删除组件，
并逐个重新安装它们，来确定哪些特定组件阻止了每个节点的启动。

其二，
需要更换多个组件才能成功恢复数据，并恢复受影响的节点。
为了完全恢复数据，需要在各个服务器上临时重新安装一些原始/故障组件。

其三，
系统的代码自动化也失败了。
它错误地批准了过时的请求，并将一些健康的节点标记为不健康，这减慢了存储恢复工作。

另外，从 SQL 角度来看，一旦受影响的数据中心完全恢复供电，整个服务会受到依赖服务恢复进度的影响。所谓依赖服务主要是指 Azure 标准存储产品。在这些高级 Azure 存储服务恢复之前，许多通用数据库仍然不可用。

与此同时，微软表示，其托管超过 250000 个 SQL 数据库的租户环具有多种故障模式，有些数据库可能完全不可用，有些数据库可能会遇到间歇性连接问题，有些数据库可能完全可用。

这导致他们很难总结哪些客户仍然受到影响。所以，现场工程师进一步尝试将数据库迁出受影响的环时，又发现 SQL 没有经过充分测试的工具。

种种挑战之下，也让宕机的时间越来越长。根据初步分析报告显示，8 月 30 日发生的中断事件最终到 9 月 1 日的 06:40 才成功恢复所有标准存储租户。

如何避免此类事件发行的可能性或影响？

这份报告是微软在事件发生的三天内立即进行的事后调查给出的分析，其预计还会在 14 天内发布完整的服务中断报告。

根据此次初步分析，微软表示已经从数据中心电源/冷却的角度得到了以下一些经验与教训：

由于数据中心园区的规模，夜间团队的人员配备不足，无法时重新启动冷却器。

在更好地了解根本问题并采取适当的缓解措施之前，其暂时增加了团队人数。

（此前外媒报道是从 3 人增至 7 人团队）

对于影响如此之大的事件而言，重新启动冷水机的 EOP 执行缓慢。

基于此，微软正在探索改进现有自动化的方法，以提高对各种电压骤降事件类型的适应能力。

展望未来，微软也正在评估如何确保对不同冷水机子集的负载情况进行优先排序，以便首先对最高负载情况执行冷水机组重启。

在工作负载故障切换和设备停机的排序中使用操作手册，可以通过更好的洞察力来确定不同的优先次序。微软正在努力改进冷冻水温度报告，以便根据阈值更及时地决定故障切换/关闭。

一个数据中心应该配备多少运维？

在上述事件发生之后，虽然微软表示会增加团队人数，但在不少网友看来，实则并不是人的问题。

@dijit 网友表示：

我想，人们真的忘了如何运营数据中心了。

很多人认为运营是一件非常困难的事情，需要成千上万的员工。

我知道 AWS/GCP/Azure 喜欢向我们收费，好像我们要雇佣一支系统管理员大军，但事实上，日常的 DC 运维并不需要这么多人。

硬件故障比你想象的要少得多，而且你可以在不惊慌的情况下解决它们。

也有用户直言，“或许管理层的想法只是「招聘更多的人，花钱买个安心」。

只是这种寻求内心平静的时刻永远不会到来，因为云每年变得越来越复杂，而且很难跟上。”