2025年3月11日 CEPH 故障事件报告

2025年3月11日 CEPH 故障事件报告

2025年3月10日,我们提供的服务发生了大约两小时的中断,影响了虚拟机和其他服务,原因是存储访问间歇性出现问题。以下是对此次事件的详细分析、其成因,以及我们为防止未来再次发生此类事件而采取的措施。

首先,我们要为3月9日至3月11日期间因块存储不可用和IO性能下降给所有客户带来的不便致歉。

以下故障报告旨在清晰、透明地说明我们所采取的措施,这些措施促使我们不得不在3月10日UTC时间17:41至19:44进行一次不可避免的紧急维护。

采取的措施

新的主版本升级将延迟至当前版本 EOL(生命周期结束)后6个月进行,因为期间会有问题修复被积极回移(backport)到旧版本。存储容量的预留水平将比以往大幅提高,以便在出现严重问题时为我们争取更多时间。我们现已接入 Croit 的工单系统,并将与其保持联系,以便在身边有一个能够处理严重 CEPH 问题的合作伙伴。

专业术语:
CEPH = 开源企业级存储集群解决方案
OSD = Object Storage Daemon,在 CEPH 中为数据池提供存储空间
CEPHADM = 用于简化部署和维护 CEPH 集群的解决方案
PG = Placement Group(归置组),负责组织 CEPH 中数据池向 OSD 的数据分配

事件经过

2月11日

我们对通用预发布(staging)环境进行了例行维护工作,并决定将 CEPH 组件从 CEPH Reef 升级到 Squid,因为距离上一次 CEPH 升级已经过去一年。截至今天(3月11日),预发布环境在 CEPH Squid 上仍然完全正常运行。

2月19日

我们借助 CEPHADM 在生产环境中启动了从 CEPH Reef 到 Squid 的升级。该升级由 CEPHADM 全自动完成,升级期间及升级后均未出现任何问题。

3月5日

UTC 20:06

由于客户对存储容量的需求不断增长,我们在主机 A 上为集群新增了一个 OSD。

3月6日

UTC 14:13

在我们的监控系统提示新增的 OSD 出现异常抖动(flapping)后,我们进行了例行检查,以评估相关主机的功能状态,同时也检查了集群状态——此时集群仍处于可运行状态。由于没有找到该 OSD 存在问题的具体证据,且集群整体运行状态尚可接受,我们重新部署了这个抖动的 OSD,希望问题能够随之消失。

UTC 14:41

由于该 OSD 似乎反复崩溃,我们开始对其进行调试并检查日志。我们注意到一些提示性信息,指向 OSD 达到其最大存储目标,或者 Bluestore 组件因达到 Bluefs 分配大小限制、分配器(allocator)本身以及启动日志相关限制而发生段错误(segfault)的问题。这些信息提示我们应调整相关设置,因此我们在持续排查过程中应用了这些调整。

UTC 16:26

该 OSD 反复崩溃,最终我们决定将该 OSD 从主机 A 迁移到主机 B,因为我们怀疑连接到主机背板的 Oculink 布线可能是导致这些问题的原因之一。Ceph 工具 ceph-bluestore-tool 报告 bluestore 文件系统中存在无法修复的错误。

UTC 19:39

OSD 已完成迁移,针对未完全复制的 PG 的恢复过程随即启动。

UTC 23:40

该 OSD 在主机 B 上再次崩溃,此时我们怀疑是 15.36 TB NVMe pm9a3 的固件问题所致,因为另一位用户也在 reddit 上报告过类似情况: https://www.reddit.com/r/ceph/comments/1j07rwr/got_4_new_disks_all_4_have_the_same_issue/ 随后安装了更新的 NVMe 固件,并重新启用了该 OSD。由于存储需求持续增长,加之怀疑固件是问题根源,我们又向 Solidigm 订购了一块 15.36 TB 的 NVMe。

3月7日

6:34 UTC

集群成功恢复了所有未完全复制的分片(shard),以3副本实现了完整的双重容错,但仍在处理数据迁移(rebalance),以达到各 OSD 之间的最佳填充水平。

10:55 UTC

我们在订购后的第一天早上就通过 transoflex express 收到了 Solidigm NVMe,并决定将其加入集群,以满足客户仍在持续增长的存储需求。

17:14 UTC

Solidigm NVMe OSD 意外崩溃,使我们进入警戒状态,因为这更像是指向 Ceph 本身的一个缺陷。因此我们开始清理环境中的各种波动因素,例如存储性能优化项以及其他在6年运营过程中陆续添加的特定配置。我们还提高了调试日志级别,这导致 CPU 占用上升、IO 性能下降。

19:04 UTC

Solidigm OSD 再次崩溃,我们再次开始排查 Bluestore 组件的日志。我们发现某些 RBD 实例数据导致了崩溃,因为它们的数据块被放置在与其他数据块内容重叠的扇区上。我们决定将这些 RBD 镜像从相应的存储池中移除,并迁移到另一个存储源。

3月8日

07:28 UTC

新添加的 pm9a3 OSD 再次崩溃,使集群进入了风险较高的运行状态,因为我们认为该情况已不再具备足够的确定性/可控性,无法维持正常的日常运行。因此,我们将纠删码(Erasure Coded)存储池中可用分片的最小数量从5降低到4。我们立即开始联系更多熟悉 CEPH 风险的相关人员,与他们分享了我们的发现,并得到建议:应通过 NVMe 部署这两个 OSD,因为新添加的 OSD(15.36TB)容量是旧 OSD(7.68TB)的两倍。

14:50 UTC

其中一块 NVMe 上的两个 OSD 之一再次崩溃,我们立即以深度模式(deep mode)运行 ceph-bluestore-tool,以检查数据状态。尽管我们已经付出了很多努力,仍然发现了更多相互覆盖的 RBD 实例数据块(blob)。

16:12 UTC

在完成对最近一次崩溃的全部排查后,我们向 CEPH Slack 和 SCS Matrix 服务器请求了进一步的帮助。遗憾的是,CEPH 问题跟踪系统(Issue Tracker)上没有找到匹配的错误报告。

19:47 UTC

由于我们联系了很多人,有人告诉我们,我们的情况与 hostup.se 的情况相当类似。他们的 OSD 也出现了崩溃,而在运行 ceph-bluestore-tool fsck 时,只有 EC 存储池的数据块被报告为无法修复的错误。我们立即暂停了所有进一步的 PG 相关操作,以确保不再发生崩溃。出于谨慎,我们开始将所有核心服务从 EC 存储池迁移到一个副本(replicated)存储池。

22:31 UTC

完成迁移后,我们开始评估所有可以将数据迁出 CEPH 集群的方案。

22:56 UTC

尽管所有 PG 相关操作均已停止,仍然发生了另一次 OSD 崩溃,我们立即决定将问题升级至 croit GmbH 的紧急支持团队。

3月9日

02:11 UTC

我们结束了与 croit 的第一次电话沟通,得出结论:必须等待 croit 方面的 ceph 开发人员有空。从此刻起,我们以轮班方式全天候监控集群状态,以便在数据迁移到更安全/更稳定的存储后端的解决方案还在推进的同时,尽快让每一个崩溃的 OSD 重新恢复运行。

6:40 UTC

在联系了许多同行之后,我们开始将客户数据迁移到 synlinq、informaten 和 dataforest 提供的临时存储解决方案上,同时也在努力维持存储后端的可用性和数据完整性。

11:20 UTC

在向其他后端的迁移以相对受限的速度继续进行的同时,我们开始在虚拟化主机(Hypervisor)上添加本地软 RAID(Softraid),以便能够将客户迁移到本地存储后端。

12:30 UTC

我们部分停用了面向客户的备份管理功能,并开始为所有仍位于 EC 存储池中且没有可用备份的虚拟机创建备份。在接下来的一段时间里,情况维持如此,我们努力将影响降到最低。

3月10日

7:20 UTC

Croit 的开发人员开始着手处理我们的问题,并已经能够追溯到我们 CEPH 环境中出现的问题根源。

10:23 UTC

Croit 的支持团队表示,摆脱我们新添加的那些 OSD 非常重要,因为只有它们表现异常。多亏了向我们提供大量存储空间的同事们,我们得以采用这一方案。但后来这一方案遗憾地不再奏效,因为其中一个 OSD 崩溃了,我们再次停止了 PG 相关操作,以避免造成更多影响。

15:23 UTC

由于又有一个 OSD 崩溃,使数据冗余状况进一步恶化,我们停止了继续寻找无影响迁移方案的尝试,转而请 croit 提供进一步的解决方案。避免数据丢失和更大规模故障的最后一个现实可行的方案,是在集群暂停期间将 PG 从受影响的 OSD 上迁移出去。我们宣布了一个从 UTC 17:30 开始、为期2小时的紧急维护窗口。

19:41 UTC

紧急维护由 croit 在我们的陪同与协助下顺利完成。历经近两天的不确定状态后,集群终于恢复到了稳定状态。

3月11日

4:17 UTC

所有分片和副本都成功恢复了各自缺失的副本,Ceph 集群因此重新恢复健康。

7:13 UTC

我们重新添加了其中一个 OSD,并使用了一项特殊配置,目的是禁用 CEPH Squid 中一项会导致 Bluestore 以错误方式写入数据、并最终引发 OSD 崩溃的新功能。

16:34 UTC

截至目前,该 OSD 已连续稳定运行超过9小时,未再报告此前出现过的任何可疑错误或警告。几乎所有数据都已迁回我们的 CEPH 集群。我们将继续观察情况,并在确保不会再出现其他问题后,逐步添加新的 OSD。

实际的错误报告(Bugreport): https://tracker.ceph.com/issues/70390