Ceph 分布式存储生产运维与故障恢复

Ceph 能同时提供块、对象和文件存储，但它不是“多放几块磁盘就自动安全”。生产稳定性取决于故障域、CRUSH 规则、PG 分布、容量水位、网络、恢复限速和日常巡检。本文以 cephadm 管理的现代集群为主，讲清架构、容量、扩容、磁盘更换、慢请求和灾难恢复。

Ceph 在降级状态下执行批量重启、错误的 OSD purge、CRUSH 调整或强制 PG 操作，可能造成永久数据丢失。任何修复前都应保存 ceph status、拓扑、配置和日志，并确认当前仍有多少完整副本。

一、先理解数据如何落盘

核心组件包括：

MON：维护集群地图和一致性状态，需要多数派；
MGR：提供管理模块、指标和编排能力；
OSD：管理磁盘数据、复制、恢复和回填；
MDS：CephFS 元数据服务；
RGW：S3/Swift 对象网关；
RBD：块设备接口；
CRUSH：按规则将对象映射到不同故障域的 OSD；
PG：对象到 OSD 之间的逻辑分组。

客户端通过 CRUSH 直接计算数据位置，不需要单一中心数据代理。性能和可靠性都依赖集群地图一致、网络可达和足够的健康 OSD。

二、故障域与副本策略

三副本并不自动等于能容忍任意两块盘故障。如果三份数据位于同一主机或同一机柜，主机或电源故障可能同时失去所有副本。

设计 CRUSH 层级时考虑：

root
└── room / row / rack
    └── host
        └── osd

常见副本池 size=3、min_size=2：正常写入三份副本，剩余两份时通常仍可 I/O；低于 min_size 后为保护数据会阻止写入。纠删码池通过数据块和校验块降低容量开销，但恢复、随机写和小对象行为更复杂。

不要在不理解风险时降低 min_size 强行恢复写入。那会把“服务不可写”转变为“最后副本损坏后永久丢失”。

三、建立健康基线

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

HEALTH_OK 只是起点。日常还应记录：

各池容量、对象数和增长率；
raw used 与 logical used；
每个 OSD 的使用率和 PG 数；
客户端读写吞吐、IOPS 和延迟；
慢请求、恢复、回填和 scrub；
MON 仲裁、时钟、MGR 活跃/备用；
磁盘 SMART、介质错误和网络丢包；
守护进程版本与配置差异。

四、容量规划与水位

Ceph 不能把磁盘使用到 100%。恢复和回填需要额外空间，单个 OSD 过满还会影响整个池。

ceph osd dump | grep -E 'nearfull|backfillfull|full_ratio'
ceph osd df
ceph df

容量模型至少包含：

原始容量；
副本或纠删码开销；
BlueStore 元数据与 RocksDB/WAL；
快照、克隆和对象版本；
恢复预留；
未来增长和采购周期；
故障后剩余节点能否承载全部数据。

不要只看集群平均使用率。若 OSD 分布不均，最满 OSD 会先到 nearfull/backfillfull/full。生产通常应在进入 nearfull 前就扩容，并以“失去一个故障域后仍可恢复”为容量目标。

五、PG状态如何解读

健康状态通常是 active+clean。常见异常：

PG状态	含义与方向
degraded	副本不足，检查 down/out OSD 和恢复进度
undersized	当前副本数少于池 size
inactive	无法提供 I/O，优先级最高
peering	正在确定权威日志和副本集合
backfill_wait	等待回填资源或目标空间
recovery_wait	等待恢复调度
remapped	临时映射到不同 OSD
inconsistent	scrub 发现副本不一致，需要谨慎定位
stale	主 OSD 未及时上报，检查网络和守护进程

ceph pg dump_stuck
ceph pg <pgid> query
ceph tell <pgid> query

不要看到 PG 异常就直接执行 repair。先确认哪个副本权威、磁盘是否持续报错、对象是否还能从其他副本读取。

六、慢请求排查

slow ops 可能来自磁盘、网络、CPU、恢复流量、锁竞争或客户端。按层定位：

ceph health detail
ceph tell osd.<id> dump_historic_ops
ceph tell osd.<id> perf dump
ceph daemon osd.<id> perf dump

同时检查主机：

iostat -xz 1
pidstat -dru 1
sar -n DEV 1
ethtool -S <interface>
smartctl -a /dev/<device>

判断原则：

是单个 OSD、单主机还是全局；
是读、写、提交还是应用阶段慢；
是否与 scrub、recovery、backfill 同时发生；
NVMe/SSD/HDD 类别和 DB/WAL 设备是否匹配；
网络是否丢包、重传、MTU 不一致；
客户端是否产生大队列或异常小 I/O。

七、磁盘与OSD故障处理

磁盘出现介质错误、守护进程反复崩溃或主机不可达时，不要立即 purge。先确认数据已在其他 OSD 上形成足够副本。

典型流程：

保存 OSD ID、主机、设备、序列号和 CRUSH 位置；
检查 ceph osd tree、PG 和健康详情；
判断是临时重启、网络故障还是介质永久失败；
必要时标记 out，让数据迁移；
等待集群恢复到安全状态；
使用 cephadm 的设备替换/移除流程；
新盘上线后验证 CRUSH 位置、设备类和性能；
观察回填、容量和慢请求。

主机短期维护可评估 noout，但必须设置明确解除时间。长期保留 noout 会让真正故障无法触发数据重建。

八、扩容与再平衡

扩容前检查网络、电源、机架、磁盘型号和故障域。一次加入大量 OSD 会触发明显数据迁移。

ceph orch device ls --refresh
ceph orch apply osd --all-available-devices --dry-run

生产扩容建议：

先 dry-run 核对设备；
分批加入并观察；
同一池尽量使用性能相近介质；
DB/WAL 设备容量和寿命匹配；
评估业务高峰和恢复限速；
检查自动均衡器模式与结果；
扩容后验证最满 OSD 是否下降。

恢复速度过高会拖慢业务，过低又延长降级窗口。应以客户端 P99 延迟和恢复完成时间共同调节，不能只追求最快回填。

九、Scrub与一致性

Scrub 检查对象元数据，deep-scrub 读取数据并校验。它是发现潜在损坏的重要机制，也会带来 I/O。

生产应：

设置合适时间窗口和并发；
告警 scrub 逾期；
观察 deep-scrub 对业务延迟影响；
出现 inconsistent 时先定位对象和副本；
对介质错误、内存错误、网络异常做关联分析；
repair 后复查，而不是只清掉健康告警。

十、MON、MGR与时间同步

MON 需要多数派。三个 MON 可容忍一个失效，五个可容忍两个，但更多 MON 会增加一致性开销，并非越多越好。

ceph quorum_status
ceph mon stat
ceph mgr stat
chronyc tracking
chronyc sources -v

MON 数据盘延迟、磁盘满、地址变更、证书或时钟异常都可能影响管理面。MON 不应与高延迟数据盘争用资源。

十一、网络设计

Ceph 流量包含客户端访问、复制、恢复和心跳。是否划分 public/cluster network 应根据规模和带宽设计，不能只依赖逻辑网段解决物理拥塞。

检查：

端到端 MTU 一致；
bond/LACP 哈希与交换机配置一致；
双网卡是否具备真正冗余路径；
丢包、CRC、pause frame 和重传；
恢复时是否打满上联；
防火墙端口和地址变更；
DNS 与主机名解析稳定。

十二、RBD、CephFS与RGW专项

RBD

关注客户端缓存、队列深度、镜像特性、快照数量、回收站和 rbd du 的实际占用。虚拟化场景要区分虚拟机文件系统延迟、宿主机 QEMU 队列和 Ceph 后端延迟。

CephFS

关注 MDS 内存、会话、cap、元数据热点和 standby-replay。大量小文件、深目录和异常客户端可能拖慢元数据服务。

RGW

关注 bucket index、分片、生命周期、版本化、失败 multipart、网关连接和对象存储后端延迟。多站点同步必须监控同步落后和冲突。

十三、配置变更与升级

ceph config dump
ceph versions
ceph orch upgrade check <target-version>

升级前：

阅读目标版本兼容和弃用说明；
集群必须先恢复健康；
备份 MON 数据、配置、密钥和 CRUSH map；
核对客户端兼容；
预留回滚或停止升级方案；
分阶段观察守护进程重启、PG、延迟和错误。

不要在降级、nearfull 或硬件不稳定时叠加大版本升级。

十四、灾难恢复资料

应独立备份：

ceph.conf 和 keyring；
CRUSH map、OSD map、MON map；
cephadm 清单和服务规格；
池、认证、配额和快照策略；
RGW realm/zone 配置；
RBD 镜像关系；
恢复 Runbook 与联系人。

Ceph 的副本解决硬件故障，不自动解决机房级灾难、误删除或凭据泄露。关键数据仍需异地备份、RBD mirror、RGW multisite 或应用层复制，并定期做恢复演练。

十五、巡检清单

[ ] MON 多数派、MGR 备用和时钟正常；
[ ] 所有 PG 状态、慢请求和 scrub 逾期可解释；
[ ] 最满 OSD 距离水位有足够余量；
[ ] OSD 使用率、PG 和设备类分布合理；
[ ] 磁盘 SMART、介质错误和网络错误受监控；
[ ] 恢复/回填不会压垮业务；
[ ] cephadm 编排、版本和配置无异常漂移；
[ ] RBD/CephFS/RGW 分别有业务级指标；
[ ] 关键配置、密钥和异地数据保护可恢复；
[ ] 磁盘、主机、网络和机房级故障已演练。

十六、结语

Ceph 运维的核心是始终知道数据还有几份、分布在哪些故障域、剩余空间是否足以恢复，以及当前后台任务会不会影响业务。先保护副本和证据，再处理性能与告警；任何“强制恢复正常”的动作都必须回答它是否会减少最后的数据安全边界。

参考资料

Ceph Documentation：https://docs.ceph.com/en/latest/
Ceph Troubleshooting：https://docs.ceph.com/en/latest/rados/troubleshooting/

Ceph分布式存储生产运维与故障恢复