3. Ceph 存储核心概念：RADOS、PG、OSD、MON、MGR、RBD、CephFS、RGW
Ceph 是一个统一、分布式存储系统，其核心设计围绕 RADOS（Reliable Autonomic Distributed Object Store）展开。理解 Ceph 的组件与数据流，是运维 Rook 集群和规划 Velero 备份路径的前提。本节将逐一拆解 Ceph 的八大核心概念，并建立它们之间的拓扑关系。
3.1 核心组件总览
下表从功能角色、集群位置、故障影响三个维度，快速对齐各组件定位：
| 组件 | 全称 / 角色 | 集群位置 | 故障影响等级 |
|---|---|---|---|
| RADOS | 底层对象存储基石 | 所有节点 | 集群不可用 |
| OSD | Object Storage Daemon | 存储节点 | 数据迁移 / 降级 |
| MON | Monitor 集群监控 | 控制节点 | 集群脑裂 / 不可写 |
| MGR | Manager 集群管理 | 控制节点 | 指标丢失 / 均衡暂停 |
| PG | Placement Group | 逻辑分片 | 数据分布不均 |
| RBD | 块设备接口 | 客户端 / 内核 | Pod 挂载失败 |
| CephFS | 文件系统接口 | 客户端 / MDS | 共享卷不可用 |
| RGW | 对象存储网关 | 网关节点 | S3 接口不可用 |
运维提示：在 Rook 部署中，MON 和 MGR 通常以 Deployment 形式运行在 Kubernetes 控制面节点；OSD 以 DaemonSet 或 StatefulSet 运行在存储节点；RGW 和 MDS 按需启用。Velero 备份 RBD 卷时，依赖 RBD 快照接口与 RADOS 层的 snapshot 机制。
3.2 RADOS：一切存储的基石
RADOS 是 Ceph 的自我修复、自管理的对象存储层。所有数据最终都以对象（Object）形式存储在 OSD 上，RADOS 负责对象的分布、复制、故障检测和恢复。
- 对象：默认 4MB 大小的数据块，每个对象有唯一的 OID（Object ID）。
- CRUSH 算法：无需元数据服务器，直接计算对象到 OSD 的映射。
- 多副本：默认 3 副本，副本分布在不同的故障域（主机/机架/数据中心）。
3.3 PG：数据分布的原子单元
Placement Group（PG）是 RADOS 内部用于管理对象分布的逻辑容器。每个 PG 包含一组对象，PG 再映射到一组 OSD。
# 查看集群 PG 数量与状态
ceph pg stat
# 输出示例
# 1024 pgs: 1024 active+clean; 12 GiB data, 36 GiB used, 964 GiB / 1000 GiB availPG 数量直接影响数据均衡速度和集群恢复时间。计算公式：
PG总数 = (OSD总数 * 100) / 副本数
# 向上取整到最近的 2 的幂次
避坑：PG 数量过少会导致单个 OSD 承载过多 PG，数据分布不均；PG 数量过多会消耗 MON 内存和 OSD 的 CPU。Rook 默认自动计算 PG 数量，不建议手动修改。
3.4 OSD：数据存储的物理载体
OSD 是 Ceph 中真正存储数据的守护进程。每个 OSD 通常对应一块物理磁盘或一个逻辑卷。OSD 负责：
- 响应客户端的读写请求
- 执行数据复制、回填、恢复
- 向 MON 上报自身状态（up/down/in/out）
| OSD 状态 | 含义 | 运维动作 |
|---|---|---|
| up & in | 正常运行，参与数据分布 | 无 |
| down & in | 进程异常，数据仍属于该 OSD | 排查磁盘/网络，尝试重启 |
| down & out | OSD 被标记为移除，数据正在回填 | 等待回填完成，替换磁盘 |
3.5 MON 与 MGR：集群的大脑
MON（Monitor） 维护集群的全局状态图（Cluster Map），包括 OSD Map、PG Map、CRUSH Map 等。MON 使用 Paxos 协议保证一致性，奇数个 MON（通常 3 或 5）防止脑裂。
MGR（Manager） 提供额外的监控、指标收集和均衡功能。MGR 负责：
- 收集 OSD 的 perf 指标
- 提供 RESTful API（用于 Prometheus 集成）
- 执行 PG 自动均衡（balancer）
3.6 上层接口：RBD、CephFS、RGW
这三者是 Ceph 对外暴露的存储协议，分别对应块存储、文件存储、对象存储。
| 接口 | 协议 | 典型使用场景 | Kubernetes 集成方式 |
|---|---|---|---|
| RBD | 块设备 (librbd) | PVC 持久化卷、数据库存储 | RBD CSI Driver |
| CephFS | POSIX 文件系统 | 共享文件卷、多 Pod 读写 | CephFS CSI Driver |
| RGW | S3 / Swift 兼容 | 对象存储、Velero 备份后端 | RGW Service + Ingress |
Velero 集成要点：Velero 可以直接使用 RGW 作为备份存储后端（S3 兼容），也可以使用 RBD 快照实现 CSI 卷快照备份。两种方式分别对应对象存储备份和块存储备份，在后续章节会详细对比。
3.7 组件拓扑关系图
下图展示了 Ceph 核心组件之间的数据流与控制流关系：
3.8 数据写入流程示例
以 Kubernetes Pod 通过 RBD 写入数据为例，完整路径如下：
- 客户端请求：Pod 通过 RBD CSI Driver 发起写请求。
- CRUSH 计算：客户端根据对象名和 PG ID，通过 CRUSH 算法计算出目标 OSD 集合。
- 主 OSD 写入：数据发送到 PG 的主 OSD（Primary OSD）。
- 副本复制：主 OSD 将数据同步到从 OSD（Replica OSD）。
- 确认返回：所有副本写入成功后，主 OSD 返回确认给客户端。
关键指标：在 Velero 备份场景中，RBD 快照的创建速度取决于 PG 数量和 OSD 负载。建议在备份窗口前通过
ceph osd perf 检查 OSD 延迟，确保快照操作不会影响生产 IO。