1. Ceph 架构：RADOS 与三大服务

本章目标

说出 MON / OSD / MDS / MGR 各自的角色与推荐数量
理解 CRUSH：为什么 Ceph 不需要"查元数据表"也能定位数据
理解副本与 EC 的取舍，会算给定配置下的净可用容量

1.1 RADOS：一切的地基

Ceph 只有一个存储引擎：RADOS（Reliable Autonomic Distributed Object Store）—— 一个自管理的分布式对象存储集群，管理千万级小对象，自带副本/EC、故障检测、数据再均衡。

三大接口都是 RADOS 的"翻译官"：

text

        ┌────────── RADOS（一切的地基）──────────┐
        │   MON( monitor )  MDS( metadata )  OSD │
        └──────┬───────────────┬────────────┬────┘
               ▼               ▼            ▼
             RBD            CephFS         RGW
      块设备语义        POSIX 文件语义    S3 对象语义
     (虚拟机云盘)      (共享目录/家目录)  (备份/数据湖)

RBD 把"块"翻译成对象（每 4MiB 一个）；RGW 把"bucket/key"翻译成对象+索引；CephFS 把文件数据切成对象、把目录树放进元数据池。学 Ceph = 学 RADOS + 三个翻译层。

1.2 五类守护进程

守护进程	职责	数量与说明
MON	集群成员表（monmap）、PG 分布图（osdmap）；Paxos 仲裁	≥3 且为奇数；只存元数据，不负载数据流量
OSD	存数据（通常一盘一 OSD，BlueStore 直接管裸盘）	数量 = 数据盘数；互相心跳，秒级故障发现
MDS	仅 CephFS：目录树/inode 元数据	≥2（active/standby）；RBD/RGW 不需要
MGR	管理、指标聚合、dashboard	≥2（active/standby）；不工作不影响数据面
RGW	S3/Swift 网关	无状态，按需水平扩展

关键区分：MON 管集群的"地图"，MDS 管文件系统的"目录"，OSD 管"数据本身"。面试常考：RGW 挂了对象数据丢了吗？—— 不丢，RGW 是无状态网关，数据都在 RADOS。

1.3 CRUSH：不查表的数据定位

传统分布式的写路径要问元数据服务器"我该写哪"；Ceph 用纯计算替代查表：

text

对象名 myobj.123
   │  hash(objname) % pg_num
   ▼
PG 1.4c (归置组，~100 个对象一批)
   │  CRUSH(pg, osdmap, crush_rule)
   ▼
[OSD.3(主), OSD.17(从), OSD.42(从)]   ← 按 host/rack 故障域打散

三个直接收益：

无元数据热点：客户端自己算出位置，直接与主 OSD 通信（要写信给 MON 拿一次最新 osdmap，之后缓存）
拓扑感知：crush rule 定义"副本必须跨 host/rack"—— 机架断电不打死任何 PG
增量重平衡：增删 OSD 只需重算受影响 PG，全集群数据不必重洗（对比一致性哈希的虚节点迁移）

PG 是"对象的班组"：默认每个 PG 约 100 个对象，PG 数量决定分布均匀度与再平衡粒度（第 7 章的 pg_autoscaler 会讲怎么定 PG 数）。

1.4 副本 vs 纠删码（EC）

	3 副本	EC 4+2
净容量利用率	1/3（33%）	4/6（67%）
写放大	3×	1×（但需计算校验，小 IO 要读改写）
读放大	1×（任一副本）	1×（读 k 个分片之一即可）
故障容忍	2 个 OSD	2 个 OSD
延迟特征	低（并行写）	小块写高（RMW）
适用	热数据、性能池	冷数据、大对象（RGW 默认）、容量池

生产经典布局（对照 rook 指南里的 CephFS 配置）：

CephFS：metadataPool 用 ssd + 3 副本；dataPools 用 EC 4+2 提升得盘率
RBD：性能池 3 副本（nvme/ssd）；若开 Fast EC（osd_pool_default_flag_ec_optimizations，Ceph ≥20.2）也能把 EC 用在性能场景

1.5 一次写的完整路径

text

client: 算出 PG → 查 osdmap 缓存 → 得到主 OSD [3, 17, 42]
   │ write(obj, data)
   ▼
OSD.3 (主): 接收 → 写入（BlueStore, 落盘确认）
   │ 并行转发
   ├──▶ OSD.17 (从): 落盘确认 ──┐
   └──▶ OSD.42 (从): 落盘确认 ──┤
   ▼                            │
OSD.3 收齐 2/2 从确认 ◀─────────┘
   │
   ▼
client 收到 ack —— 共 1 次 client↔主 + 2 次主↔从 网络往返 + 各自 fsync

把第一篇的网络账带进来：min_size=2 表示主+至少 1 从确认即可应答（2/3 写入模式），这是延迟与安全的调节旋钮。若 min_size 不满足，PG 进入 degraded/backfill 状态 —— 第 6 章运维的主战场。

本章小结

一个 RADOS、三个翻译官：RBD/CephFS/RGW 共享同一套底座
MON=地图、MDS=目录、OSD=数据、MGR=仪表盘、RGW=网关
CRUSH 用计算换掉了查表：拓扑感知 + 增量重平衡
副本买性能、EC 买容量；metadata 池永远用副本 + ssd

自测

Quiz一个 Ceph 集群 pool 大小 = 3（3 副本），OSD 总裸容量 300TiB，该 pool 理论最大净可用容量约为？

多选关于 CRUSH 与 PG，下列说法正确的是？(多选)

QuizRGW 网关进程全部宕机 10 分钟，期间对象数据的状态是？

🧪Lab · 读架构，画三张图入门

⏱ 60 分钟🖥 纸笔或画图工具

1. 画一次 RBD 写入的数据流（client → PG → 3×OSD → ack），标出每个箭头上的网络往返。 2. 画 CephFS 读文件时 MDS 与 OSD 的分工（谁回答"文件在哪"，谁给数据）。 3. 画出你自己规划中的实验集群拓扑：节点、public/cluster 网络、每块盘的角色（对应[第 2 章部署](/ceph/02-deploy-cephadm)）。 4. **验收标准**：三张图能不看资料复现，并能回答"每个箭头为什么存在"。

📎 参考手册 ↗

下一章：2. cephadm 部署实战 →

1. Ceph 架构：RADOS 与三大服务 ​

1.1 RADOS：一切的地基 ​

1.2 五类守护进程 ​

1.3 CRUSH：不查表的数据定位 ​

1.4 副本 vs 纠删码（EC） ​

1.5 一次写的完整路径 ​

本章小结 ​

自测 ​

1. Ceph 架构：RADOS 与三大服务

1.1 RADOS：一切的地基

1.2 五类守护进程

1.3 CRUSH：不查表的数据定位

1.4 副本 vs 纠删码（EC）

1.5 一次写的完整路径

本章小结

自测