Ceph OSD down 后的决策树：要不要 out？要不要 destroy？

OSD down 是 Ceph 运维最常见的事件。新手最容易犯的错是看到 down 就立刻 ceph osd out，结果触发数据迁移，等磁盘其实自己能恢复，白白搬一遍数据。本文是我团队内部用的决策树。

一图先行（文字版）

OSD down
  ├─ down 时长 < 10 分钟？
  │   └─ 是 → 等 mon_osd_down_out_interval 自动处理，先别动
  │
  ├─ 节点是否在线？(ping / ssh)
  │   ├─ 节点离线 → 是计划维护吗？
  │   │     ├─ 是 → noout + 维护，完事 unset noout
  │   │     └─ 否 → 排查节点
  │   └─ 节点在线 → 进入磁盘排查
  │
  ├─ 磁盘 SMART 是否正常？
  │   ├─ 异常 → destroy & 换盘
  │   └─ 正常 → 看 OSD 日志，可能是 OOM / 段错误 / 文件系统问题

几个关键参数搞清楚

• mon_osd_down_out_interval：OSD down 多久自动 out（默认 600s）
• noout：禁止 OSD 自动 out（维护必用）
• nobackfill / norecover：禁止回填/恢复
• noscrub / nodeep-scrub：禁止 scrub

维护场景三连：

ceph osd set noout
ceph osd set nobackfill
ceph osd set norecover
# 维护...
ceph osd unset norecover
ceph osd unset nobackfill
ceph osd unset noout

out vs destroy vs purge

实战决策：

• 短暂故障要恢复 → 啥都不做，等它自己 up
• 换盘但想复用 OSD ID（推荐，少一次 CRUSH 抖动）→ destroy → 换盘 → ceph-volume lvm create --osd-id X
• 彻底下线一块盘 → out → 等回填 → purge

一个真实踩坑

一台机器 4 块 OSD 全 down，我同事下意识 ceph osd out 了 4 个 ID。结果触发大量数据迁移，集群 IO 抖动 1 小时。其实那台机器只是网卡 down 了，5 分钟修好。

正确做法：发现整节点掉了，先 ceph osd set noout，去现场查节点，节点恢复后 OSD 自己 up 就行了，零迁移。

让运维少出事的几个习惯

1. 节点维护前永远 noout：写进 SOP，没商量
2. 批量换盘别同时换：一次只换一块，等回填完了再下一块
3. 集群配 mon_max_pg_per_osd_hard_limit：避免大规模迁移把单个 OSD 撑爆
4. 死磁盘 destroy 而不是 purge：保留 ID，重建后 CRUSH 拓扑不变，少一轮全盘扫描

教训一句话：OSD down 先别 out，10 分钟内的故障往往是网络或者 OSD 进程的事，不是磁盘的事。