Cloudflare 机房断电故障复盘

零、背景

Cloudflare 是一家美国公司，提供内容交付网络服务、云网络安全、DDoS 缓解和 域名注册服务。

2023年11月2日 11:44 开始 Cloudflare 的控制平面和分析服务出现中断。
2023年11月4日 04:25 恢复，故障持续 40 小时左右。

我负责的系统正在升级改造异地容灾事项，所以有必要复盘一下 Cloudflare 的这次故障。

一、故障概述

2023年11月2日11:44，Cloudflare 的控制平面和分析服务出现故障不可用，原因是一个数据中心 (PDX-DC04) 发生电源故障。
主要影响 Cloudflare 的控制平面和分析服务受到影响，其中控制平面包括面向客户的接口和 API，分析服务包括日志记录和分析报告。
持续时间：故障持续 40 小时左右。

二、故障关键时间点

2023-11-2 08:50 PDX-04 机房服务提供商 Flexential 发生了一次计划外维护事件，在没有通知 Cloudflare 的情况下，关闭一个独立供电电源，启动了备用发电机。

2023-11-2 11:40 PDX-04 的 PGE 变压器发生接地故障，独立供电电源和发电机都被关闭。

2023-11-2 11:44 宣称支撑 10 分钟的备用 UPS 电池，仅 4 分钟就无法供电。

2023-11-2 11:44 Cloudflare 收到监控系统发出的数据中心出现问题的通知，故障开始。

2023-11-2 12:28 Cloudflare 收到机房服务商 Flexential 的故障通知。

2023-11-2 12:48 机房服务商 Flexential 成功重启了发电机，部分设施已恢复供电，遇到断路器出现故障。

2023-11-2 13:40 Cloudflare 决定将故障转移到位于欧洲的 Cloudflare 灾难恢复站点。

2023-11-2 13:43 Cloudflare 在灾难恢复站点上提供了第一批服务控制平面服务，但遇到惊群问题，随后开启频率控制降级服务。

2023-11-2 17:57 Cloudflare 的控制平面服务全部恢复，其他服务等待机房恢复。

2023-11-2 22:48 机房服务商 Flexential 更换了发生故障的断路器，恢复了公用设施供电。 Cloudflare 评估太晚了，决定第二天再恢复故障。

2023-11-3 开始恢复 PDX-04 的服务，遵循整个设施的完整引导，先启动网络设备，然后启动数千台服务器并恢复其服务

2023-11-4 04:25 所有服务完成启动与重建。

故障持续共计 40 小时左右。

三、影响范围

1）11-2 11:44 ~ 11-2 13:43 控制平面和分析服务整体不可用，影响所有用户。

2）11-2 13:43 ~ 11-2 17:57 控制平面陆续恢复，恢复期间部分用户偶尔会失败；分析服务所有用户都不可用。

3）11-2 17:57 ~ 11-4 04:25 控制平面所有用户全部恢复，分析服务所有用户都不可用。

四、故障响应

此小节为 【故障关键时间点】 的展开，即各个时间谁响应了这个问题、做了什么处理。

第一阶段：故障前

2023-11-2 08:50~11:44 PDX-04 机房发生故障到全部断电。

问题1：PGE 变压器接地故障导致电路跳闸，需要进行物理访问并手动重新启动。
但是 Flexential 的门禁系统没有备用电池供电，因此处于离线状态。

问题2：现场的夜间值班人员只有一名保安和上岗一周的新人。

问题3：11:44 至 12:01 之间，由于发电机未完全重启，UPS 电池耗尽，数据中心的所有客户都断电。在整个过程中，Flexential 从未告知 Cloudflare 该设施存在任何问题。

第二阶段：故障发现

2023-11-2 11:44 Cloudflare 团队收到告警后，尝试联系 Flexential 并派遣当地团队亲自前往该设施。

第三阶段：机房尝试回复故障

12:48，Flexential 成功重启了发电机，该设施的部分设施已恢复供电。

问题1：为了不使系统不堪重负，当数据中心恢复供电时，通常会通过一次重新打开一个电路的电源来逐步完成。
每个电路区域都由冗余断路器提供服务。
当 Flexential 尝试为 Cloudflare 的电路提供备用电源时，发现断路器出现故障。

PS：Cloudflare 不知道断路器是否由于接地故障或其他事故导致的失效，或者它们之前是否已经损坏，直到它们断电后才发现。

问题2：Flexential 开始更换故障断路器。
这要求他们采购新的断路器，因为坏断路器比他们设施中现有的断路器还要多。

第四阶段：主动迁移控制平面服务。

2023-11-2 13:40~17:57 Cloudflare 主动将故障转移到 Cloudflare 灾难恢复站点。

13:40 拨打电话，将故障转移到位于欧洲的 Cloudflare 灾难恢复站点。
Cloudflare 大部分服务支持多个数据中心的高可用性运行，只需要对整体控制平面的一小部分进行故障转移即可。

13:43 在灾难恢复站点上提供了第一批服务，恢复关键的控制平面服务。
当服务流量迁移后，遇到了惊群问题，所有服务的 API 都调用失败了。
之后 Cloudflare 实施了速率限制来控制请求量。
在此期间，大多数产品的客户在通过仪表板或 API 进行修改时都会遇到间歇性错误。
17时57分，已成功迁移至灾备站点的服务已稳定，大部分客户不再受到直接影响。

日志处理服务和定制 API 等尚不支持异地容灾，所以只能等待机房恢复。

第五阶段：机房恢复，恢复服务。

五、故障恢复

介绍故障恢复期间做的关键措施。

1）Cloudflare 将控制平面服务迁移到灾难恢复站点，恢复控制平面服务的功能，部分定制API不可使用。
2）机房服务商 Flexential 通过更换断路器，恢复了公用设施供电。
3）Cloudflare 按指引恢复机房的服务。

六、故障根因分析

机房的容灾设计与问题

PDX-04 机房施工时通过 Tier III 认证，来承诺高可用性 SLA，但是实际依旧断电了。

PDX-04 机房电源设计为2组独立供电电源，外加 10 台发电机，外加 UPS 电池。

由于通用电气进行一次计划外维护事件，影响了一个独立供电电源。
正常情况下，电力应该切换到另一个独立供电电源，但是 PDX-04 却启用了发电机。

未知原因（尚未得到 Flexential 或 PGE 的回复），PDX-04 的 PGE 变压器发生接地故障。
接地故障可能是由 PGE 执行的计划外维护而引起的，也可能是一个非常不幸的巧合。

高压（12,470 伏）电源线的接地故障非常严重。
电气系统旨在快速关闭，以防止发生损坏。
不幸的是，在这种情况下，保护措施也关​​闭了 PDX-04 的所有发电机。
这意味着该设施的两个发电来源——冗余公用线路和 10 台发电机——均已离线。

幸运的是，除了发电机之外，PDX-04 还包含一组 UPS 电池。这些电池据称足以为该设施供电约 10 分钟。
事实上，根据自己的设备故障中观察到的情况，仅 4 分钟后电池就开始出现故障。
而Flexential 花了 68 分钟才首次恢复发电机。

Cloudflare 的容灾设计与问题

Cloudflare 的控制平面和分析系统主要在三个数据中心的服务器上运行。
这三个数据中心相互独立，每个数据中心都有多个公用电源，并且每个数据中心都有多个冗余且独立的网络连接。
这些设施被有意选择为相距一定距离，以最大限度地减少自然灾害导致这三个设施受到影响的可能性，同时又足够接近，以便它们都可以运行主动-主动冗余数据集群。
这意味着他们正在三个设施之间持续同步数据。根据设计，如果任何设施离线，则其余设施能够继续运行。

Cloudflare 四年前开始实施多数据源中心系统容灾。
虽然 Cloudflare 的大多数关键控制平面系统已迁移到高可用性集群，但某些服务，尤其是一些较新的产品，尚未添加到高可用性集群中。

此外，Cloudflare 的日志系统故意不属于高可用性集群的一部分。
该决定的逻辑是，日志记录已经是一个分布式问题，日志在网络边缘排队，然后发送回的核心（或使用区域服务进行日志记录的客户的另一个区域设施）。
如果日志记录设施离线，那么分析日志将在网络边缘排队，直到它重新上线。
Cloudflare 确定延迟分析是可以接受的。

PDX-DC04 机房容纳了 Cloudflare 最大的分析集群以及超过三分之一的高可用性集群机器。
它也是尚未加入 Cloudflare 的高可用性集群的服务的默认位置。
Cloudflare 是该设施的相对较大客户，消耗了其总产能的约 10%。

虽然 PDX-04 的设计在施工前已通过 Tier III 认证，并有望提供高可用性 SLA，但 Cloudflare 计划了它可能离线的可能性。

即使运营良好的设施也可能遇到糟糕的日子， Cloudflare 为此做好了计划。

在这种情况下，Cloudflare 预计会发生的情况是，Cloudflare 的分析将处于离线状态，日志将在边缘排队并延迟，并且未集成到高可用性集群中的某些较低优先级服务将暂时离线，直到这些服务在另一个设施重新部署。

该地区运行的另外两个数据中心将接管高可用性集群的责任并保持关键服务在线。
一般来说，这按计划进行。

不幸的是，Cloudflare 发现本应位于高可用性集群上的服务子集依赖于专门在 PDX-04 中运行的服务。

特别是，处理日志并为分析提供支持的两个关键服务——Kafka 和 ClickHouse——仅在 PDX-04 中可用，但有依赖于它们的服务在高可用性集群中运行。

这些依赖关系不应该如此紧密，应该更优雅地失败，应该降级这些错误。

另外，Cloudflare 通过使其他两个数据中心设施中的每一个（以及全部）完全离线来对高可用性集群进行测试。
Cloudflare 还测试了 PDX-04 的高可用性部分离线。
然而，Cloudflare 从未对整个 PDX-04 设施进行全面离线测试。
因此，Cloudflare 忽略了数据平面上某些依赖项的重要性。

Cloudflare 对于新产品及其相关数据库与高可用性集群集成的要求也过于宽松。
Cloudflare 允许多个团队快速创新。
因此，产品通常会采取不同的路径来实现最初的阿尔法。

虽然随着时间的推移，Cloudflare 的做法是将这些服务的后端迁移到最佳实践，但在产品宣布普遍可用 (GA) 之前，并没有正式要求这样做。 这是一个错误，因为这意味着 Cloudflare 所采用的冗余保护根据产品的不同而工作不一致。

七、改进方案

Cloudflare 有许多问题需要 Flexential 的解答。
但 Cloudflare 也必须预料到整个数据中心可能会发生故障。

谷歌有一个流程，当发生重大事件或危机时，他们可以调用黄色代码或红色代码。
在这些情况下，大部分或全部工程资源都被转移到解决手头的问题。

Cloudflare 过去没有这样的流程，但今天很明显 Cloudflare 需要自己实现一个版本：Code Orange。
Cloudflare 正在将所有非关键工程功能转向专注于确保控制平面的高可靠性。

作为其中的一部分，预计会发生以下变化：

1）消除对核心数据中心的所有服务控制平面配置的依赖，并将它们转移到尽可能首先由分布式网络供电的地方。
2）确保即使有核心数据中心都离线，网络上运行的控制平面也能继续运行
3）要求所有指定为“普遍可用”的产品和功能必须依赖于高可用性集群，而不对特定设施有任何软件依赖。
4）要求所有指定为“普遍可用”的产品和功能都具有经过测试的可靠灾难恢复计划。
5）测试系统故障的影响范围并最大程度地减少受故障影响的服务数量
6）对所有数据中心功能实施更严格的混沌测试，包括完全拆除每个核心数据中心设施。
7）对所有核心数据中心进行彻底审核并制定重新审核计划以确保它们符合标准。
8）日志记录和分析灾难恢复计划，确保即使在所有核心设施发生故障的情况下也不会丢失日志

Cloudflare 拥有正确的系统和程序，能够承受在数据中心提供商处看到的级联故障，但需要更加严格地执行它们，并对其进行未知依赖项的测试。

在今年余下的时间里，这将引起我和团队大部分成员的全力关注。
过去几天的痛苦会让 Cloudflare 变得更好。

八、最后

看完 Cloudflare 这个复盘总结，可以发现三个问题，值得我们思考与借鉴。

第一：核心机房即使做了多重容灾，依旧可能全部断电。
第二：核心服务即使做了异地高可用容灾，依旧可能因为某个外部依赖导致服务不可用。
第三：高可用验证必须充分验证，即所有机房都需要验证，尤其是最重要的机房。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code