【Ceph RADOS】排障坐标系：slow ops、peering 卡死、满盘、恢复拖死前台与 checksum 错误
内容提要
本文介绍Ceph集群排障的五轴坐标系：慢操作、Peering卡死、满盘、恢复拖死前台、校验和错误。每轴按“症状→先查什么→不要先做什么”展开，强调先选轴再调参，避免乱调参数破坏因果链。提供核对路径、操作命令及串联案例，并附检查清单，帮助运维快速定位根因。
延伸解读
先选轴再调参，避免因果链污染
文章强调排障时先根据症状选择对应的轴，再针对性调整参数。例如，slow ops 可能源于磁盘、网络或 mClock 配置，若未定位根因就盲目调整 osd_op_num_threads，可能加剧问题。这种“一次否证一轴”的纪律，与 SPDK 排障思路一致，有助于快速定位根因，避免多参数同时调整导致因果链混乱。
区分前台延迟与后台恢复的相互影响
轴一（slow ops）与轴四（恢复拖死）常同时出现，但处理方向不同。若 slow op 卡在 waiting for subop，可能因 replica OSD 忙于 recovery；此时应限制恢复速率而非调整前台线程。文章建议先通过 dump_ops_in_flight 确认 op 阶段，再决定调优方向，避免同时调整两个轴的参数。
满盘阈值基于单盘，而非集群整体
nearfull/full 阈值按单个 OSD 使用率计算，即使集群整体容量充足，个别 OSD 也可能触发 full 导致写入拒绝。因此，监控时应关注 ceph osd df tree 的单盘 USE%，而非仅看 ceph df 集群均值。建议在 USE% 超过 75% 时即开始跟踪，避免告警滞后。
Checksum 错误处理前先确认磁盘状态
遇到 inconsistent PG 时，不应直接执行 pg repair。应先通过 OSD log 确认错误类型（如 read_error 或 data_digest_mismatch），并检查磁盘 SMART 状态。若磁盘存在静默损坏，repair 可能覆盖正确副本，导致数据再次损坏。正确流程是先更换故障磁盘，再执行 repair。
Q&A
Ceph集群出现slow requests时，应该先检查什么？
先使用ceph health detail定位涉及slow request的OSD，然后通过ceph tell osd.{id} dump_ops_in_flight查看操作卡在哪个阶段，再结合ceph osd perf和iostat判断是磁盘还是网络问题。
Ceph PG长时间处于peering状态，可能的原因有哪些？
常见原因是primary或replica OSD down，导致peering所需副本缺失。也可能是last_epoch_started不一致，某个OSD的PG log跨度不够。需通过ceph osd tree确认OSD状态，用ceph pg query查看blocked_by和LES。
Ceph OSD达到full阈值后，客户端写入会返回什么错误？
当OSD使用率达到osd_full_ratio（默认0.95）时，OSD会拒绝所有写入，客户端写入返回ENOSPC错误。
如何限制Ceph recovery/backfill对前台I/O的影响？
可以通过设置osd_recovery_max_active_hdd/ssd、osd_max_backfills和osd_recovery_sleep_hdd等参数限制并发和速率，或调整mClock profile为balanced或high_client_ops。
Ceph检测到checksum错误后，应该如何处理？
先通过ceph pg query查看scrub_errors类型，再检查OSD日志确认错误副本，并检查磁盘SMART状态。若磁盘损坏，先ceph osd out替换磁盘，再执行ceph pg repair。
Ceph排障时为什么强调先选轴再调参？
因为不同症状对应不同根因，乱调参数会破坏因果链。例如slow ops可能由磁盘、网络或mClock配置引起，若不先定位轴，直接调整osd_op_num_threads可能无效。
Ceph集群出现nearfull告警时，有哪些短期缓解措施？
可以降低满OSD的CRUSH weight（ceph osd reweight）触发数据迁移，或临时调高osd_full_ratio，同时删除不必要的数据。但根本解决需加盘扩容。
如何判断Ceph前台延迟升高是否由recovery/backfill引起？
比较ceph osd perf中recovering OSD与其他OSD的commit latency，若仅recovering OSD升高，且iostat显示磁盘%util高，则可能是recovery拖死前台。
