Ceph 故障排查

总体方法

Ceph 告警往往是结果而不是根因。例如 PG Degraded 可能由 OSD Down、主机断网、容量过高或守护进程崩溃引起。排障应先判断数据风险和影响范围，再逐层定位。

业务现象
  ↓
Cluster Health 与 PG 状态
  ↓
Daemon：MON / MGR / OSD / MDS / RGW
  ↓
主机资源、磁盘、网络、时间同步
  ↓
最近变更、容量趋势和硬件告警

第一组命令

ceph -s
ceph health detail
ceph df detail
ceph osd tree
ceph osd df tree
ceph pg stat
ceph orch ps

记录执行时间、FSID、异常 PG/OSD、最近变更以及业务症状。不要一看到 HEALTH_WARN 就重启所有服务或设置多个全局 Flag。

MON Quorum 异常

现象包括 MON Down、Quorum 成员不足、CLI 超时或无法取得最新 Cluster Map。

检查方向：

1. MON 进程和所在主机是否存活。
2. MON 节点间网络、端口、防火墙和 MTU。
3. 时钟同步是否异常。
4. MON 数据目录和系统盘是否满、只读或延迟过高。
5. 当前是否仍有多数派，避免错误地同时重建多个 MON。

ceph quorum_status
ceph mon stat
ceph orch ps --daemon-type mon
cephadm logs --name mon.<id>

MON 数据量通常不等于业务数据量，但其状态对集群一致性至关重要。没有明确恢复方案时，不应删除 MON Store 或强制创建新 Monmap。

OSD Down 或 Out

down 表示 OSD 进程当前不可达，out 表示 CRUSH 不再把数据正常放置到它。两者含义不同，可以出现 down/in 或 up/out。

ceph osd tree
ceph osd find <OSD_ID>
ceph orch daemon status osd.<OSD_ID>
cephadm logs --name osd.<OSD_ID>

依次检查：

• 主机是否断电、重启或网络隔离。
• OSD 容器/服务是否反复崩溃。
• 数据设备、BlueStore DB/WAL 设备是否存在和可读。
• Kernel、SMART、NVMe、SCSI 是否报告 IO Error 或 Reset。
• 数据盘是否满，系统盘或容器目录是否满。
• OSD Heartbeat 网络是否丢包或延迟异常。

坏盘更换前确认该 OSD 的剩余副本状态。若同一 PG 已缺少多个副本，贸然 Zap 故障盘可能删除唯一可恢复的数据。

PG Degraded、Undersized 或 Peering

ceph pg dump_stuck
ceph pg <PG_ID> query
ceph osd map <pool> <object>

• degraded：对象副本不完整，通常等待恢复。
• undersized：Acting Set 数量小于池的 size。
• peering：相关 OSD 正在确定 PG 历史和权威日志。
• inactive：PG 无法服务 IO，应优先处理。

重点查找这些 PG 共同依赖的 OSD、Host 或 CRUSH 分支。大量 PG 同时异常通常指向一个节点、网络或容量问题，而不是每个 PG 独立损坏。

Nearfull、Backfillfull 与 Full

ceph df
ceph osd df tree
ceph osd dump | grep full_ratio
ceph osd pool ls detail

处理顺序：

1. 找到最满 OSD、Pool 和对应 CRUSH 分支。
2. 确认是否有异常大对象、测试数据、快照、克隆依赖或 RGW 未清理数据。
3. 判断数据是否因权重、设备类别、规则或节点容量差异分布不均。
4. 尽快增加符合当前 CRUSH Rule 的容量，或删除经业务确认的数据。
5. 观察 Backfill 是否能够继续，以及客户端延迟是否可接受。

直接调高 Full Ratio 会降低安全余量，只能作为经过风险评估的短时应急操作。

Slow Ops 与延迟升高

Slow Ops 表示请求在队列或处理链路中等待时间过长，常见原因包括：

• 单块磁盘介质故障、超时或固件问题。
• BlueStore DB/WAL 设备延迟或故障。
• OSD 所在主机 CPU、内存或系统盘压力过高。
• 网络丢包、拥塞、MTU 不一致或交换机错误。
• Recovery、Backfill、Scrub 与业务 IO 竞争。
• 热点 RBD、热点 PG 或容量严重不均。

ceph health detail
ceph daemon osd.<ID> ops
ceph daemon osd.<ID> dump_historic_ops
ceph osd perf

同时使用 iostat -x、sar -n DEV、SMART/NVMe 日志和交换机计数器定位底层瓶颈。不能只根据 OSD 日志中的最后一条慢请求判断根因。

CephFS 故障

ceph fs status
ceph mds stat
ceph health detail
ceph orch ps --daemon-type mds

检查 Active MDS、Standby 数量、Metadata Pool 健康、MDS 缓存压力、客户端会话和目录热点。MDS 异常主要影响元数据操作；底层 Data Pool 或 OSD 故障也会同时影响文件数据访问。

RGW 故障

先区分网关入口问题与底层 RADOS 问题：

• DNS、TLS、负载均衡和 RGW 监听端口是否正常。
• 单个 RGW 实例还是所有实例失败。
• 用户、Key、Bucket Policy 和配额是否正确。
• RGW 相关 Pool 与 PG 是否健康。
• 请求失败是 4xx 权限/请求错误，还是 5xx 服务端错误。
• 多站点场景检查 Realm、Zonegroup、Zone 和同步状态。

不应作为常规修复的操作

• 未确认数据副本前 Purge OSD 或 Zap 磁盘。
• 长期设置 noout、norecover、nobackfill、noscrub。
• 为消除告警直接调高容量阈值。
• 未分析权威副本就对 Inconsistent PG 执行 Repair。
• 删除 /var/lib/ceph、MON Store 或 OSD 数据目录。
• 在集群不健康时同时升级、扩容和调整 CRUSH Map。

故障记录模板

时间：
业务影响：
Ceph 版本与 FSID：
ceph -s 摘要：
异常 PG / OSD / Host：
容量与最满 OSD：
最近变更：
磁盘与网络告警：
已执行操作：
恢复结果：
根因与预防措施：

官方参考：Health Checks、Troubleshooting OSDs、Troubleshooting PGs。