人们谈 Ceph，常常先谈统一存储，说它能把 object、block 与 file 收进同一套系统里，而且规模可以很大。[1] 这句话当然成立，只是它仍旧停在结果层。真正需要抓住的设计动作更靠前一些。Ceph 最有分量的地方，在于它把故障处理改写成一套算术。它没有把对象位置藏进一个中心化元数据代理里，而是让 client 与 OSD 依据同一组 cluster map 和 CRUSH 规则去计算放置，再把恢复与重平衡落到比单个对象更粗、也更可管理的单位上。[1][4][6][7]

这也是本文想写清楚的架构笔记。Ceph 的难有非常清楚的轮廓：它把拓扑、放置策略与恢复成本推到运维人员真正能调、也必须调的地方。把 CRUSH、placement groups 与 BlueStore 放在一起看，Ceph 就不再像一个巨大的存储名词，它更像一台把“磁盘坏了、主机掉了、整排机架失联了”这些事件压进可计算边界里的机器。[1][2][3][4][5]

截至 2026-04-06T22:04:09Z UTC，GitHub API 显示 ceph/ceph 仓库有 16,422 stars、6,349 forks、1,168 个 open issues，最近一次 push 时间是 2026-04-06T20:43:13Z。[8] 这些数字并不能代替架构判断，却足以说明 Ceph 仍是一套持续演化中的活系统，而并非停留在论文里的静态方案。

配图说明：题图采用的是一张真实的服务器机柜照片，没有使用厂商式示意图。这个选择很贴切，因为 Ceph 的放置逻辑只有在你能看见主机、机架、电源与交换网络这些物理分层时才真正落地。CRUSH 之所以重要，正因为这些边界都是真实存在的。[4][9]

1. CRUSH 拿掉了最危险的中心查表路径

官方架构文档对旧式问题写得很直接。传统存储系统往往要求客户端先穿过一个中心化 gateway、broker 或 facade，这个中心入口同时会变成单点故障，也会变成扩展上限。[1] Ceph 的回答，是把这条放置查询路径拆掉。客户端先向 monitor 获取当前 cluster map，随后客户端与 OSD 都使用 CRUSH 算法自行计算数据应该落在哪里，而并非在每次读写时都去问一个中心放置表。[1][4]

这里才是 Ceph “故障算术”的核心。CRUSH map 不只是 OSD 清单，它还保存那些真正会让故障相关联的层级：host、rack、row、datacenter，以及 hdd、ssd、nvme 这类 device class。[4] 放置规则再去描述副本或纠删码碎片怎样跨这些层级分散。[4][7] 一旦运维者明确写出“副本要跨不同 host”或者“这些 shard 必须跨 rack”，放置逻辑就会保持在本地、算法式、去中心化的状态，而不会退回到一张越来越重的查找表里。[4][7]

这也是为什么拓扑并非装饰性元数据。它本身就是可用性设计的一部分。机架在这里承担的是一条关于共享供电、共享交换路径与共享坏运气的声明。[4]

2. placement groups 把移动成本压到可以看清的单位

若只有 CRUSH，Ceph 依旧不会轻松，因为系统仍会按单个对象去管理放置。data placement 文档把第二步写得很清楚：对象先被映射进 pool，再被映射进 placement group，最后才落到 OSD 集合上。[2][3] placement group 是逻辑 pool 的一个分片，而 Ceph 之所以在内部按 PG 粒度管理数据，是因为这比逐个 RADOS 对象处理更能扩展。[2][3]

这一层比听上去更重要。Ceph 的重平衡、peering 与恢复，真正运作的单位是 PG。某台主机掉线，或者新盘被加进集群时，系统不会按对象逐一重想一遍世界，它会围绕 PG 去搬动、对账、收敛。也正因此，文档始终把 PG 数量写成一条要在两种成本之间拿捏的边界：PG 太少，数据会压在过窄的一段集群上；PG 太多，系统又会在 peering 流量、元数据开销与内存上付出过高代价。[2][3][10]

当前指导数值也足够具体。placement groups 文档写明，mon_target_pg_per_osd 的默认值是 100，除极小部署外通常建议朝 200 靠拢，而高于 500 则有机会带来过多的 peering 流量与 RAM 占用。[3] 这类数字很重要，因为它们把 Ceph 的“可扩展”从口号重新拉回操作区间。它告诉运维者，规模对应的是一套有工作带宽、有代价曲线的工程安排。

新的 PG autoscaler 也让这一点更清楚，而并非更模糊。[3][10] 即使系统开始自动建议或自动应用 pg_num 变化，它做的仍旧是围绕 pool 大小、复制或纠删码放大率、CRUSH 子树与每个 OSD 的目标 PG 预算去算账。[3][10] 顺着这些文档看下去，可以得到一个很清楚的理解：Ceph 乐意替你自动化那部分算术，但它始终是一套受拓扑与移动成本支配的系统。

3. BlueStore 让每个 OSD 贴着必须恢复的设备去工作

第三层故事发生在每个 OSD 之内。架构页指出，BlueStore 已经是默认后端，并以一种更像单体数据库的方式存放对象。[1] BlueStore 配置文档则把这件事写得更细：BlueStore 直接对原始设备读写，而并非先创建、挂载一个传统文件系统，再把对象塞进去。[5]

这层设计之所以重要，是因为恢复行为本来就从 OSD 边界起步。一个 BlueStore OSD 有主 block 设备，还可以把 block.db 与 block.wal 分到更快的介质上。[5] 若快盘很少，文档建议先把它留给 WAL；若快盘更充裕，把它用作 block.db 更划算，因为 WAL 也会顺带跟着进来，同时元数据同样受益。[5] 对混合 HDD 与 SSD 的布局，文档给出的建议也很具体：把 block.db 放在更快设备上，容量通常约为 block 的 1% 到 4%，RGW 一类元数据负载更重的工作负载可以靠近 4%，RBD 则常见于 1% 到 2% 的范围。[5]

这一层关系到恢复预算。BlueStore 让 OSD 贴近原始设备现实，于是运维者可以决定元数据放在哪里，日志写入放在哪里，缓存压力落在哪里。文档还说明 BlueStore 的 cache autotuning 默认开启，会围绕 osd_memory_target 去控制 OSD 堆内存占用，并保留最小缓存与比例参数，以便默认预算不适合真实负载时再做调整。[5] 放在这个层面看，Ceph 并没有把所有磁盘都假装成同一种抽象物件，它反而留出了一条足够清楚的路径，让设备差异与负载差异能够进入设计。

4. 最适合它的边界

把这些资料放在一起，结论会比“Ceph 很能扩展”这类口号更窄，也更有用。Ceph 最适合的场景，是那些确实需要让存储放置跟随物理现实的环境：多台主机、清楚的故障域、混合设备类型，以及规模大到中心放置服务会变成负担的集群。[1][2][4][6][7] 在这类环境里，CRUSH 把放置从中心路径里拿开，PG 把移动成本收束起来，BlueStore 则给每个 OSD 一个可以调度、而并非只能猜测的存储引擎形状。[1][3][4][5]

反过来看，不匹配的边界也很清楚。若系统小到还不需要在意 rack-aware placement，团队又没有余力管理拓扑、pool 策略与设备布局，或者对存储系统的期待是“把所有调参都抹平”，Ceph 就会显得比它带来的收益更重。文档本身反复强调的，也正是这一点：pools、CRUSH rules、PG 预算、device classes、WAL 与 DB 的布局、cache target，这些都是真正会影响行为的边界。[2][3][4][5] Ceph 提供的是一种受控的复杂度，用来换取更可预期的故障表现。

因此，到了 2026，理解 Ceph 最合适的方式，仍旧是把它看成一套“故障算术”。它没有消灭艰难的存储问题，它只是选择了这些问题该住在哪里，并把关键边界公开出来，让运维者能把物理风险写成放置策略，而并非把它们留给口耳相传的经验。

来源

1. Ceph Documentation，《Architecture》：统一系统定位、monitor 与 OSD 的角色、cluster map、基于 Paxos 的 monitor 共识，以及架构层面的 CRUSH 解释。
2. Ceph Documentation，《Data Placement Overview》：pools、placement groups、CRUSH maps，以及 balancer 在分布中的位置。
3. Ceph Documentation，《Placement Groups》：PG 作为管理粒度、autoscaling 行为、mon_target_pg_per_osd，以及当前操作建议。
4. Ceph Documentation，《CRUSH Maps》：bucket 层级、failure domains、device classes，以及 governing replica placement 的策略规则。
5. Ceph Documentation，《BlueStore Configuration Reference》：原始设备写入模型、block / block.db / block.wal 布局、容量建议与 cache autotuning 行为。
6. Sage A. Weil 等，《RADOS: A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters》：Ceph 底层分布式对象存储设计论文。
7. Sage A. Weil 等，《CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data》：Ceph 去中心化放置算法的原始论文。
8. GitHub API 中 ceph/ceph 的仓库快照：stars、forks、open issues 与文章创建时的最近一次 push 时间。
9. 本文配图所用服务器机柜照片的 Wikimedia Commons 文件页。
10. Ceph Blog，《New in Nautilus: PG merging and autotuning》：PG 数量为何长期是运维难点，以及 autoscaling 如何重写这部分工作。