Ceph 存储核心概念：RADOS、PG、OSD、MON、MGR、MDS、RGW 组件详解
Ceph 是一个高度可扩展、无单点故障的分布式存储系统，其核心设计哲学是将数据智能地分布在整个集群中。理解其核心组件与抽象层是掌握 Ceph 架构的基础。本章将深入剖析构成 Ceph 存储基石的关键概念：RADOS、PG、OSD、MON、MGR、MDS 和 RGW。
1. 核心抽象层：RADOS
RADOS (Reliable Autonomic Distributed Object Store) 是 Ceph 的基石，一个可靠、自治、分布式对象存储系统。所有 Ceph 的存储能力（块、文件、对象）最终都构建在 RADOS 之上。它负责处理数据分布、复制、故障检测与恢复、数据迁移等复杂任务，对外提供统一的、高可用的对象存储接口。
2. 核心数据单元：PG (Placement Group)
PG (Placement Group) 是 Ceph 中用于数据管理和分布的逻辑容器。它是一个抽象层，位于对象和 OSD 之间。每个 PG 包含一组对象，Ceph 通过 CRUSH 算法将 PG 映射到一组 OSD 上。PG 的数量是集群性能调优的关键参数。
- 作用： 简化数据管理，将海量对象聚合为可管理的组。
- 状态：
active+clean为健康状态；degraded表示有副本丢失；peering表示正在同步。 - 数量规划： 通常建议每个 OSD 承载 50-100 个 PG，总 PG 数 = (OSD 总数 * 100) / 副本数。
3. 核心存储引擎：OSD (Object Storage Daemon)
OSD (Object Storage Daemon) 是 Ceph 中实际存储数据的守护进程。每个 OSD 通常对应一个物理磁盘或一个分区。它负责处理数据的读写、复制、恢复、再均衡以及心跳检查。OSD 是 Ceph 集群中数量最多的组件，也是性能瓶颈的主要来源。
| 属性 | 说明 |
|---|---|
| 功能 | 存储数据、处理复制、恢复、再均衡、心跳 |
| 数量 | 集群中数量最多的组件，通常与磁盘数量一致 |
| 故障影响 | 单个 OSD 故障影响较小，CRUSH 自动迁移数据 |
| 性能关键 | 磁盘 I/O、网络带宽、CPU 处理能力 |
4. 集群大脑：MON (Monitor)
MON (Monitor) 是 Ceph 集群的“大脑”，负责维护集群的全局状态图，包括 OSD 状态、PG 映射、CRUSH 映射、认证信息等。MON 使用 Paxos 算法保证一致性，通常部署奇数个（如 3 个）以实现高可用。客户端和 OSD 在操作前都需要向 MON 获取最新的集群映射。
5. 集群管理助手：MGR (Manager)
MGR (Manager) 是 Ceph 的集群管理守护进程，负责收集和聚合集群的运行时指标，如 OSD 性能、磁盘使用率、客户端 I/O 等。MGR 提供了 RESTful API 和命令行接口，用于监控和配置集群。从 Luminous 版本开始，MGR 成为必选组件。
- 主要功能： 指标收集、仪表盘（Dashboard）、模块扩展（如 Prometheus 插件）。
- 高可用： 通常部署 2 个 MGR，一个活跃，一个备用。
6. 文件系统元数据服务：MDS (Metadata Server)
MDS (Metadata Server) 是 Ceph 文件系统（CephFS）的元数据管理组件。它负责管理文件系统的命名空间、目录结构、文件权限等元数据。MDS 本身不存储数据，只管理元数据，实际文件数据直接通过 RADOS 存储。MDS 支持动态子树分区以实现高并发。
7. 对象存储网关：RGW (RADOS Gateway)
RGW (RADOS Gateway) 是 Ceph 的对象存储网关，提供兼容 Amazon S3 和 OpenStack Swift 的 RESTful API。RGW 将 HTTP 请求转换为 RADOS 操作，使客户端可以通过标准对象存储协议访问 Ceph 集群。RGW 支持多租户、桶策略、生命周期管理等高级特性。
| 协议 | 端口 | 用途 |
|---|---|---|
| S3 | 443 (HTTPS) | 兼容 AWS S3 API |
| Swift | 443 (HTTPS) | 兼容 OpenStack Swift API |
8. 组件关系与数据流
下图展示了 Ceph 核心组件之间的逻辑关系以及数据写入的简化流程：
9. 组件对比总结
| 组件 | 全称 | 核心职责 | 是否必需 | 高可用方式 |
|---|---|---|---|---|
| MON | Monitor | 维护集群状态图、认证 | 是 | Paxos 算法，奇数个节点 |
| MGR | Manager | 指标收集、仪表盘、扩展模块 | 是 (Luminous+) | 主备模式 |
| OSD | Object Storage Daemon | 数据存储、复制、恢复 | 是 | CRUSH 自动分布，副本机制 |
| MDS | Metadata Server | CephFS 元数据管理 | 仅 CephFS | 动态子树分区，主备 |
| RGW | RADOS Gateway | S3/Swift 对象存储网关 | 仅对象存储 | 负载均衡器 + 多实例 |
10. 实践要点与避坑指南
- PG 数量规划： PG 数量过少会导致数据分布不均，过多会消耗大量 CPU 和内存。建议使用公式
总 PG 数 = (OSD 数 * 100) / 副本数进行估算，并向上取整到 2 的幂次。 - OSD 故障域： 在 CRUSH Map 中合理设置故障域（如主机、机架、数据中心），确保副本分布在不同的故障域中，避免单点故障导致数据丢失。
- MON 部署： 避免将 MON 部署在同一台物理机或同一机架，使用独立的 SSD 磁盘存储 MON 数据库以提高性能。
- MGR 模块： 启用
prometheus模块可以集成 Prometheus 监控，启用dashboard模块可以获得 Web 管理界面。 - RGW 性能： 对于高并发对象存储场景，建议部署多个 RGW 实例，并使用负载均衡器（如 HAProxy、Nginx）分发流量。