Rook/Ceph集群中MDS服务卡在replay状态的分析与解决

问题背景

在Rook/Ceph分布式存储系统中，当管理员对集群节点进行重启维护后，可能会出现文件系统持续处于"recovering"状态的问题。具体表现为所有PG（Placement Group）进入stale+active+clean状态，MDS（Metadata Server）服务长时间停留在up:replay阶段，无法完成恢复过程。

问题现象

典型的故障现象包括：

1. 文件系统显示为"degraded"状态
2. MDS服务日志不断显示"Updating MDS map"信息
3. 健康检查显示"MDSs behind on trimming"警告
4. 部分Ceph命令执行卡住或无响应
5. 新创建的PVC无法正常绑定

根本原因分析

经过深入排查，发现问题的核心在于MDS服务的日志回放机制。当集群节点重启后，MDS需要从日志中恢复元数据状态。在此过程中，存在两个关键指标：

1. journal_read_pos：当前读取的日志位置
2. journal_write_pos：需要恢复到的最终日志位置

当这两个值不一致时，MDS会持续进行日志回放操作。然而，由于默认配置下的内存限制，MDS服务在回放大量日志时会出现内存不足的情况，导致进程被OOM Killer终止。当MDS重新启动后，journal_read_pos又会从journal_expire_pos位置重新开始，形成恶性循环，使得恢复过程永远无法完成。

解决方案

临时解决方案

1. 检查MDS恢复状态：

ceph tell mds.<fs_name>:0 status | jq .replay_status

2. 增加MDS内存限制： 通过修改Rook的CephFilesystem CRD配置，增加MDS容器的内存资源限制，确保有足够内存完成日志回放。

永久解决方案

1. 优化MDS资源配置： 在集群规划阶段，应根据文件系统规模合理配置MDS资源，特别是对于元数据操作频繁的环境。

2. 定期维护： 在计划性维护前，建议先执行文件系统冻结操作，减少需要回放的日志量。

3. 监控设置： 建立对MDS内存使用和日志回放进度的监控，及时发现潜在问题。

经验总结

1. 对于生产环境，MDS服务的内存配置不应低于4GB，大型集群可能需要8GB或更多。

2. 节点重启操作应分批次进行，避免同时重启所有节点导致大量日志需要回放。

3. 定期检查文件系统的健康状态，特别是trimming进度，避免日志堆积。

4. 在问题排查时，journal_read_pos和journal_write_pos的差值可以直观反映恢复进度。

通过这次事件，我们认识到在分布式存储系统中，元数据服务的资源分配同样重要。只有保证MDS有足够的资源，才能确保文件系统在各种异常情况下都能正常恢复。