Ceph 分布式存储运维实践：从集群规划到故障自愈
Ceph 把对象、块、文件三种存储统一在一套 RADOS 集群之上，是私有云与云原生环境里最常见的分布式存储底座。本页不重复安装向导，而是从极客运维的日常视角出发，围绕集群规划、CRUSH 布局、PG 状态、性能调优与故障自愈几个层面，整理一套可以长期稳定运行的 Ceph 运维方法。
3-in-1
对象 / 块 / 文件统一存储
CRUSH
去中心化数据分布算法
PG
数据分布与恢复的基本单位
关键运维要点
- ✔ 用
ceph -s与ceph osd tree建立每日巡检基线 - ✔ PG 数量按 OSD 规模计算，避免过度分裂拖慢恢复
- ✔ 区分
nearfull与backfillfull阈值，提前扩容而不是等告警 - ✔ 用 Prometheus + ceph_exporter 采集指标，把恢复速率纳入监控面板
- ✔ 替换磁盘前先
ceph osd out并等待数据回填完成 - ✔ 对 RBD 客户端设置合理的
rbd cache与队列深度
常见状态与处理思路
| 状态 | 含义 | 处理方向 |
|---|---|---|
| HEALTH_WARN | 存在告警但服务可用 | 逐条查看 ceph health detail |
| PG degraded | 副本不足，数据仍在恢复 | 确认 OSD 在线状态，观察恢复速率 |
| OSD down | 磁盘或进程异常 | 检查磁盘健康与日志，必要时替换 |
| nearfull | 集群容量接近阈值 | 扩容 OSD 或调整权重，避免写满 |
性能调优与容量治理
Ceph 的性能瓶颈往往不在 CPU，而在网络与磁盘队列。对全闪集群，优先关注 BlueStore 的 WAL/DB 设备分离与网络 MTU；对混闪集群，则要控制回填与恢复的并发，避免业务 IO 被后台任务拖垮。
容量治理上，建议把 mon_osd_nearfull_ratio 与扩容流程绑定，形成“告警—评估—扩容—回填”的闭环，而不是等集群写满再紧急处理。
常见问题
Q：PG 数量到底怎么定？
A：按 OSD 总数与副本数估算，单 OSD 承载 100 个左右 PG 是常见起点，再结合集群规模与恢复能力微调，避免频繁重分布。
Q：OSD 掉线后能直接换盘吗？
A：先确认 OSD 是否可恢复，若需换盘，应先将 OSD 标记 out 并等待数据回填完成，再执行销毁与重建，避免二次降级。
Q：Ceph 适合跑数据库吗？
A：RBD 可以提供块设备，但数据库对延迟敏感，建议使用本地 NVMe 或专用存储，Ceph 更适合对象、镜像与共享文件场景。