SStorpath
闯关预计 40 分钟

闯关：集群完全不可用，MON 出了什么事

ceph 命令直接卡住不返回。这一关练的是「管理面挂了怎么办」。

学完这节你能做到

  • 在 ceph 命令不可用时仍能定位问题
  • 判断 MON 是进程问题、时间问题还是磁盘问题
  • 按正确顺序恢复 quorum 而不损坏集群状态

场景

凌晨 03:47，你被电话叫醒：

所有虚拟机都读写不了了，存储好像整个没了。

你登上 ceph-node1 敲 ceph -s，命令卡在那里，什么都不返回。

这一关和上一关不同：上一关你至少还能用 ceph 命令。这一关连管理入口都没了。

!ceph 命令卡住意味着什么

ceph 命令的第一步是连 MON 拉取集群 map。它卡住不返回，只有三种可能：

  1. MON 失去 quorum —— 没有 MON 能给你一个权威答案
  2. 网络不通 —— 连不上任何一个 MON
  3. 本地配置/keyring 问题 —— 连错了地方

先别慌着重启任何东西。MON 是集群状态的唯一权威，处理不当会让情况变得更糟。

root@ceph-node1
目标 0/4
  1. 1.确认本机 MON 进程的状态
  2. 2.确认 mon_data 所在分区是否写满
  3. 3.找出把空间吃光的具体目录
  4. 4.确认其它 MON 是不是也是同样的问题
模拟终端：ceph -s 已经卡住十分钟了。
注意：这一关里 ceph 系列命令大多不可用，你需要用系统层的工具排查。
输入 goals 看目标，hint 要提示。
[root@ceph-node1 ~]#
help 查看用法 · goals 看目标 · hint 要提示 · ↑↓ 翻历史

复盘

结论：ceph-node1 与 ceph-node2 的 /var/lib/ceph 分区被 MON 的 RocksDB（store.db）写满，两个 MON 进程反复崩溃退出，3 个 MON 只剩 1 个，quorum（需要 2 个）无法维持，整个集群管理面与数据面均不可用。

根因链：

osd.14 坏盘（8 月 11 日）
  → 集群持续 HEALTH_WARN 且未被处理
    → MON 在集群不健康时不压缩 store.db（要保留恢复所需的历史 map）
      → store.db 从几百 MB 涨到 468G
        → /var/lib/ceph 写满
          → MON 无法写入，进程崩溃
            → quorum 丢失，集群完全不可用

处置顺序（顺序错了会更糟）：

# 1. 先腾出空间：删日志、临时挪走非关键数据，绝不能删 store.db 里的文件
journalctl --vacuum-size=200M
# 如有额外分区，把不相关的大文件临时挪走

# 2. 空间腾出后启动一个 MON，恢复 quorum
systemctl start ceph-mon@ceph-node1
ceph -s        # 此时应该能返回了

# 3. 有 quorum 之后再压缩 store.db
ceph tell mon.ceph-node1 compact
ceph tell mon.ceph-node3 compact

# 4. 把另一个 MON 也拉起来
systemctl start ceph-mon@ceph-node2

# 5. 最后处理最初的根因 —— 那块坏盘
ceph health detail
×三个绝对不能做的操作
  1. 不要删 store.db 里的文件 —— 那是集群状态的唯一副本，删了这个 MON 就废了
  2. 不要用 mon remove 删掉挂掉的 MON 试图"凑齐" quorum —— quorum 的分母会跟着变，可能把情况变得更复杂，且删除操作本身也需要 quorum
  3. 不要同时重装多个 MON —— 先救活一个恢复 quorum，是所有后续操作的前提

MON 相关的操作里，"少动、按顺序动"永远比"快速尝试"更安全。

!这一关真正的教训

故障发生在 03:47，但根因是三天前那块没被处理的坏盘。

集群长期处于 HEALTH_WARN 会带来一系列连锁反应，MON 的 store.db 不压缩只是其中之一。 "HEALTH_WARN 又不影响业务，先放着吧"——这个念头是很多重大事故的起点。

检查点单选

ceph -s 卡住不返回，最不该做的是？

检查点单选

MON 的 store.db 涨到几百 GB，最可能的原因是？

检查点单选

两个 MON 因磁盘满崩溃，第三个正常。正确的处置顺序是？

这一关的落点

  • ceph 命令卡住 = MON quorum 有问题，立刻切换到系统层工具排查
  • MON 在集群不健康时不压缩 store.db，长期 HEALTH_WARN 会把 mon_data 撑爆
  • 恢复顺序：腾空间 → 起一个 MON 恢复 quorum → compact → 起其余 MON → 治根因
  • 绝不能删 store.db、绝不能靠 mon remove 凑 quorum
  • 给 /var/lib/ceph 单独分区并做容量监控，是这类事故的预防手段

延伸资料

  • ·k8s-in-actionstorage/cephadm/7-faq.md
下一课：闯关：CephFS 突然卡住，客户端全在等 →