日常运维与容量管理¶
日常巡检¶
ceph -s
ceph health detail
ceph df detail
ceph osd df tree
ceph osd tree
ceph pg stat
ceph orch host ls --detail
ceph orch ps
ceph versions
巡检不能只记录 HEALTH_OK。还应关注：
- 最满 OSD 与平均使用率的差距。
- PG 是否全部
active+clean，异常持续了多长时间。 - OSD、MON、MGR、MDS 和 RGW 实例是否达到预期数量。
- 客户端延迟、OSD Commit/Apply Latency 和慢请求。
- 恢复、Backfill、Scrub 是否长期占用资源。
- 磁盘 SMART、介质错误、网卡丢包和交换机端口错误。
- Pool、RBD Image、CephFS 和 RGW 的增长速度。
容量水位¶
Ceph 会根据 OSD 使用率触发 nearfull、backfillfull 和 full 等状态。达到 backfillfull 后，数据均衡可能无法向该 OSD 回填；达到 full 后，为保护一致性，集群可能阻止写入。
容量管理以最满 OSD 为重点。集群平均使用率不高，但某个 CRUSH 分支、设备类别或 OSD 已满，仍可能阻塞恢复和写入。
提高 Full Ratio 只能作为极短期应急手段，会压缩恢复空间并增加数据风险。正常处理方式是及时扩容、删除确认无用的数据，并修正导致分布不均的 CRUSH 权重或拓扑问题。
扩容流程¶
- 评估现有 Pool 使用的 CRUSH Rule、device class 和 failure domain。
- 新节点按现有标准完成网络、时间、磁盘和硬件检查。
- 将主机加入 cephadm，并核对主机名和地址。
- 按明确设备清单创建 OSD。
- 观察 PG Remap、Backfill、客户端延迟和最满 OSD。
- 恢复完成后核对容量分布、告警和故障域。
新增一台超大容量节点不一定能立即解决容量问题。CRUSH 会受主机数量、规则和数据移动速度限制，扩容期间还会产生额外网络和磁盘负载。
ceph orch host add <host> <ip>
ceph orch device ls --hostname <host> --wide
ceph orch daemon add osd <host>:/dev/<device>
watch ceph -s
OSD 维护与下线¶
计划维护主机或磁盘前，先确认当前集群无其他降级故障，并判断维护时长：
- 短期重启可在变更窗口内合理使用
noout，防止 OSD 很快被标记 Out 引发无谓迁移。 - 长期下线应让数据安全迁出，再按官方流程清除 OSD。
- 维护完成后必须清除临时 Flag，确认 OSD
up/in且 PG 恢复。
不要在整个集群已有 PG Degraded、容量接近满或恢复未完成时继续批量停盘。OSD 的 Destroy、Purge、Zap 会删除数据和设备元数据，执行前必须核对主机、OSD ID、设备序列号以及数据已完成迁移。
Scrub 与数据一致性¶
OSD 会通过 Scrub 检查对象元数据，通过 Deep Scrub 读取数据并验证更深层的一致性。Scrub 发现问题时可能出现 inconsistent PG。
Scrub 是发现潜在静默损坏的重要机制，但会消耗磁盘和 CPU。生产集群应根据业务低峰规划时间窗口，并监控是否因长期关闭 Scrub 或持续高负载导致检查逾期。
执行 PG Repair 前先确认故障介质、权威副本和备份状态。自动 Repair 并不能保证在所有情况下选择到业务期望的数据版本。
恢复与业务性能¶
磁盘或节点恢复后，Ceph 需要复制对象以恢复副本或 EC 分片。恢复速度越高，冗余恢复越快，但会占用客户端使用的磁盘、CPU 和网络。
处理原则：
- 先判断数据安全程度和当前可用副本数。
- 数据风险高时优先恢复，接受一定业务性能下降。
- 冗余尚可且业务高峰时，可按版本支持的参数适度限制恢复。
- 记录临时调整并在恢复后撤销，避免集群长期低速恢复。
参数名称和推荐范围随 Ceph 版本、磁盘类型及 mClock 调度器变化，不应直接复制旧版本的 recovery/backfill 调优参数。
监控与告警¶
MGR Prometheus 模块可向监控系统暴露 Ceph 指标。建议至少告警：
- 集群
HEALTH_WARN、HEALTH_ERR及持续时间。 - MON Quorum、MGR Active/Standby、OSD Up/In 数量。
- PG Inactive、Degraded、Undersized、Inconsistent。
- 最满 OSD、Pool 配额、容量增长趋势。
- 慢请求、客户端延迟、恢复与 Backfill 吞吐。
- MDS 状态、CephFS 客户端会话和元数据延迟。
- RGW 请求错误率、延迟和网关实例状态。
- 磁盘 SMART、主机网络错误和时钟偏移。
Ceph Dashboard 适合总览与管理，外部指标和日志平台更适合长期趋势、跨系统关联和告警闭环。
升级原则¶
- 阅读目标版本的升级说明、兼容矩阵和已知问题。
- 确认当前版本是否允许直接升级到目标版本。
- 升级前确保集群健康，备份配置、Keyring、CRUSH Map 和关键数据。
- 先在测试环境验证客户端、CSI、虚拟化平台和网关兼容性。
- 使用 cephadm Orchestrator 执行受控滚动升级，并持续观察 Health。
- 不在扩容、Backfill、硬件故障或容量告急时同时升级。
- 升级完成后核对所有 Daemon 版本及临时 Flag。
具体镜像标签和升级命令应以目标 Ceph 发行版文档为准，不使用未固定版本的 latest 镜像直接升级生产集群。
数据保护边界¶
Ceph 副本解决磁盘或节点故障，不解决误删、勒索加密、错误同步、应用逻辑损坏和整个站点故障。
- RBD 使用独立备份、快照导出或跨集群 RBD Mirroring。
- CephFS 使用快照、备份工具或文件级异地副本。
- RGW 使用版本控制、Object Lock（按版本能力）或 Multisite。
- 备份凭据、配置和 CRUSH Map，并定期执行恢复演练。
只有经过恢复验证的数据副本才能视为有效备份。