1. Ceph 存储基础：核心组件介绍与架构原理

Ceph 是一个统一、分布式存储系统，设计目标为高性能、高可靠性与可扩展性。其核心设计哲学是无单点故障与自愈自管理。理解 Ceph 的五大核心组件——MON、OSD、MGR、MDS、RGW——是掌握 Rook 编排与网关优化的前提。

1.1 核心组件总览

下表从功能、集群角色、关键特性三个维度对比五大组件：

1.2 组件架构关系图

下图展示了 Ceph 集群中五大组件的逻辑分层与数据流关系：

1.3 各组件深度解析

1.3.1 MON（Monitor）——集群大脑

• 职责：维护 Cluster Map（包括 MON Map、OSD Map、PG Map、MGR Map、CRUSH Map），保证所有节点看到一致的集群视图。
• 一致性协议：基于 Paxos 变体，要求奇数个 MON（通常 3 或 5 个）以容忍少数派故障。
• 性能特征：轻量级，不参与数据路径；写操作极少，读操作频繁。
• 高可用：MON 之间自动选举 Leader，Leader 故障时秒级切换。

1.3.2 OSD（Object Storage Daemon）——数据基石

• 职责：每个 OSD 管理一块独立磁盘（HDD/SSD/NVMe），负责数据对象的存储、读取、复制、恢复与再平衡。
• 数据分布：通过 CRUSH 算法计算数据放置位置，无需元数据查询，实现 O(1) 寻址。
• 副本与纠删码：支持多副本（默认 3 副本）与纠删码（Erasure Code）两种数据冗余策略。
• 自愈能力：OSD 故障后，集群自动将 PG 迁移至其他健康 OSD，触发数据恢复。

1.3.3 MGR（Manager）——集群管家

• 职责：收集集群统计信息（IOPS、吞吐量、容量、延迟），提供 RESTful API 与 Dashboard。
• 扩展模块：支持插件式模块，如 Balancer（自动调整 PG 分布）、Zabbix/Prometheus 集成、Telemetry 上报。
• 高可用：通常部署 2 个 MGR，一个 Active，一个 Standby，故障自动切换。

1.3.4 MDS（Metadata Server）——CephFS 元数据引擎

• 职责：管理 CephFS 文件系统的目录树、文件属性、权限等元数据。
• 动态子树分区：MDS 将元数据负载按目录子树动态分片，支持多 MDS 并行服务。
• 缓存与持久化：元数据缓存在 MDS 内存中，定期刷入 RADOS 中的元数据池。
• 适用场景：共享文件系统（NFS 替代、HPC、CI/CD 缓存）。

1.3.5 RGW（RADOS Gateway）——对象存储网关

• 职责：提供兼容 Amazon S3 与 OpenStack Swift 的 RESTful 对象存储接口。
• 无状态设计：RGW 本身不存储状态，所有数据与元数据均存储在 RADOS 中，支持水平扩展。
• 多站点同步：支持跨地域的 Active-Active 或 Active-Passive 数据同步。
• 性能优化点：Bucket 索引分片、Lua 脚本、缓存层（Redis/Memcached）、TLS 卸载。

1.4 数据读写流程（以 RGW 为例）

下图展示客户端通过 RGW 写入一个对象的完整数据流：

1.5 关键架构原则

1. 无单点故障：所有组件均可冗余部署，MON 使用 Paxos 选举，MGR 主备切换，OSD 自动恢复。
2. 数据自管理：CRUSH 算法决定数据分布，无需中心化元数据查询；PG 自动分裂、合并与迁移。
3. 统一存储：同一套 RADOS 集群同时提供块存储（RBD）、文件存储（CephFS）、对象存储（RGW）。
4. 水平扩展：增加 OSD 即可线性提升容量与性能；RGW 与 MDS 可随负载增加实例数。