174 KiB
基于 Ceph 官方文档整理 | 文档版本：Tentacle v20.2.4 | 抓取日期：2026-09-17 | 源文：ceph/ceph@v20.2.4
doc/architecture.rst官网页面：https://docs.ceph.com/en/tentacle/architecture/
第 01 册 · Ceph 架构篇
本册导读
本册是整个《Ceph Tentacle v20.2.4 中文学习手册》的骨架分册。它回答三个最根本的问题：Ceph 由什么组成、数据怎么放进去、为什么这样设计能撑到 EB 级。后续各册（部署运维、RBD、RGW、CephFS、故障排查等）都是在本册建立的概念坐标系上展开的。
本册覆盖页面
| 源文页面 | 本册对应章节 |
|---|---|
doc/architecture.rst（主源，约 76KB / 1713 行，已完整读完） |
第一 ~ 第十章 |
doc/glossary.rst（术语表，约 26KB） |
第十一章（术语表） |
doc/rados/operations/crush-map.rst（同版本本地源文，补充 CRUSH 结构） |
第四章 |
doc/dev/crush-msr.rst（同版本本地源文，补充 CRUSH rule 语法） |
第四章 |
doc/rados/operations/data-placement.rst、pg-concepts.rst、pg-states.rst |
第三、五、八章 |
doc/rados/configuration/mon-osd-interaction.rst |
第二、八章（心跳与故障检测） |
doc/mgr/index.rst、doc/mgr/administrator.rst |
第二章（MGR） |
💡 补充：第四章（CRUSH map 结构）与第八章（心跳数值、PG 状态机）在
architecture.rst中只有一句带过，本册从同版本（Tentacle v20.2.4）的其它官方源文补齐，并在对应小节另行标注来源；凡官方文档没有给出的机制（例如 CRUSH 内部哈希选择算法的具体实现），一律按写作规范标注为「文档未明确」，不做推测性编造。
建议阅读顺序
- 第一遍（建立骨架）：第一章 架构总览 → 第二章 四大守护进程 → 第三章 RADOS 对象/Pool/PG。读完这三章，你应该能画出「一个文件是怎么进 Ceph 的」的粗线条。
- 第二遍（理解核心机制）：第四章 CRUSH → 第五章 完整寻址链路。这是 Ceph 的心脏，也是面试/排障最常问的部分。第五章末尾的「端到端示例」建议自己在纸上推一遍。
- 第三遍（理解可靠性）：第六章 智能守护进程与集群映射传播 → 第七章 一致性与纠删码 → 第八章 高可用与故障恢复。
- 第四遍（按需要查）：第九章 扩展性与性能 → 第十章 协议与接口层 → 第十一章 术语表（当字典用）。
阅读约定
- 命令、参数名、配置项、默认值、算法术语（CRUSH、PG、OSD、MON、MGR、MDS、Paxos、bucket type、
acting set等）一律保留英文原文，只在必要处加中文注释。 - 原文中的 Sphinx 指令（
.. ditaa::、.. note::、.. image::、.. topic::）不原样输出，其中图形一律用 ASCII / 表格重画，并注明「原图为 XX 示意图」。 - 凡本册作者（而非官方文档）补充的分析，均以
> 💡 补充：开头标注。
一、Ceph 架构总览
1.1 Ceph 是什么
官方开篇对 Ceph 的定位是：Ceph 在一个统一的系统中同时提供 object（对象）、block（块）、file（文件）三种存储能力——这一点是 Ceph 区别于绝大多数存储系统的地方。
原文关键描述（逐条对应源文 architecture.rst 开头）：
- Ceph 高度可靠、易于管理，并且是免费的（free）。
- Ceph 提供非凡的可扩展性：数千个客户端并发访问 PB 到 EB 级数据（thousands of clients accessing petabytes to exabytes of data）。
- 一个 Ceph Node 利用商用硬件（commodity hardware）与智能守护进程（intelligent daemons）。
- 一个 Ceph Storage Cluster 容纳大量节点，节点之间互相通信，以**动态地复制（replicate）和再分布（redistribute）**数据。
三个关键词值得单独拎出来：
| 关键词 | 含义 | 为什么重要 |
|---|---|---|
| unified（统一） | 一套底层 RADOS 集群，同时对外提供对象、块、文件三种接口 | 不必为不同业务形态部署三套存储，运维面收敛 |
| commodity hardware（商用硬件） | 不依赖专有硬件，用普通服务器 + 普通硬盘 | 成本与供应链可控；但也意味着必须靠软件做可靠性，这正是 CRUSH / 副本 / scrub 存在的理由 |
| intelligent daemons（智能守护进程） | OSD 自身具备计算能力（会做 CRUSH 计算、心跳、peering、scrub、复制） | 消除中心化组件，把负载分摊到全集群 CPU/RAM |
1.2 RADOS：一切的底座
Ceph Storage Cluster 建立在 RADOS（Reliable Autonomic Distributed Object Store，可靠的、自治的、分布式对象存储）之上。官方对 RADOS 的定义是：
一个可靠的、分布式的存储服务，它利用每个节点自身的智能来保护它所存储的数据，并把数据提供给客户端。
拆解 RADOS 这个名字，它就是 Ceph 的设计宣言：
- Reliable（可靠）：数据靠副本/纠删码 + 心跳 + peering + scrub 保证，而不是靠 RAID 卡或高端盘阵。
- Autonomic（自治）：OSD 自己检测故障、自己协商状态、自己完成恢复与再平衡，不需要一个中心控制器指挥。
- Distributed（分布式）：没有中心查找表，位置由算法计算得出。
- Object Store（对象存储）：底层唯一的存储语义就是「对象」，块和文件都是在其上构造出来的。
💡 补充：RADOS 的 "Autonomic" 是理解 Ceph 与「传统集中式存储」差异的关键。传统阵列的控制器是大脑、磁盘是四肢；Ceph 里每一个 OSD 都既是四肢也是（部分的）大脑。因此 Ceph 集群规模越大，可用的"总脑力"（CPU/RAM）也越大——这是它能线性扩展的根本原因，也是它对 OSD 节点 CPU/内存配置比传统存储更敏感的原因。
官方在文中给出两篇延伸阅读（本册不展开，仅登记出处）：
- Sage Weil 的博客 The RADOS Object Store（初级介绍）
- 论文 RADOS - A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters（详尽说明）
1.3 Ceph 存储集群由哪些守护进程组成
Ceph Storage Cluster 由多种类型的守护进程组成，官方明确列出四类：
| 守护进程 | 英文/进程名 | 官方一句话职责 |
|---|---|---|
| Ceph Monitor | ceph-mon，常简称 MON / mon |
维护 cluster map 的主副本（master copy），并把它提供给 Ceph 客户端 |
| Ceph OSD Daemon | ceph-osd |
检查自身状态与其他 OSD 的状态，并回报给 Monitor |
| Ceph Manager | ceph-mgr，简称 MGR |
作为**监控（monitoring）、编排（orchestration）与插件模块（plug-in modules）**的端点 |
| Ceph Metadata Server | ceph-mds，简称 MDS |
当使用 CephFS 提供文件服务时，管理文件元数据 |
三句必须记住的补充事实（原文）：
- 多个 monitor 的存在保证了「某个 monitor 守护进程或其主机故障」时集群仍然可用。
- 存储集群客户端和 OSD 守护进程都用 CRUSH 算法计算数据位置；正因为用了 CRUSH，客户端和 OSD 不会被中心查找表（central lookup table）卡住脖子。
- Ceph 的高级特性包括：通过
librados提供的原生接口，以及构建在librados之上的一系列服务接口。
1.4 总体栈图（原图为 Ceph 存储栈示意图 images/stack.png）
architecture.rst 在开篇处用 .. image:: images/stack.png 引入了一张Ceph 存储栈示意图。本册用 ASCII 重画如下（内容取自源文后面的官方客户端分层图，见第十章）：
+------------+ +----------------+ +-------------+
| RBD | | RGW (对象) | | CephFS | <- 三种服务接口
| (块设备) | | S3 / Swift API | | (POSIX 文件) |
+------------+ +----------------+ +-------------+
| librbd | | librgw | | libcephfs | <- 服务层库
+------------+ +----------------+ +-------------+
+-------------------------------------------------+
| Ceph Storage Cluster Protocol (librados) | <- 原生协议/统一入口
+-------------------------------------------------+
+---------------+ +---------------+ +---------------+
| OSDs | | MDSs | | Monitors | <- 集群守护进程
+---------------+ +---------------+ +---------------+
| RADOS (Ceph Storage Cluster) | <- 底座
+-------------------------------------------------+
要点：
librados是唯一的原生入口；RBD / RGW / CephFS 都是"上层建筑"，不是并列的三套存储引擎。- 只有 CephFS 需要 MDS；RBD 与 RGW 不需要 MDS。
- MON 不在数据路径上（它只提供集群映射与认证），数据在客户端与 OSD 之间直接流动。
1.5 数据是怎么存进去的（一句话版本）
- Ceph Storage Cluster 从 Ceph Client 接收数据——来源可能是 Ceph Block Device、Ceph Object Storage、Ceph File System，或者是你用
librados自己写的实现。 - 收到的数据一律以 RADOS object 的形式存储。
- 每个 object 存放在一个 Object Storage Device（也就是 OSD）上。
- Ceph OSD 控制存储驱动器上的读、写与复制操作。
- 默认的 BlueStore 后端以「整体的、类数据库的方式」（monolithic, database-like fashion）存储对象。
💡 补充：第 5 点是理解 BlueStore 与旧 FileStore 差异的钥匙。BlueStore 直接管理裸块设备，不再经过一层本地文件系统，因此避免了「对象语义 → 文件语义」的双重映射（以及随之而来的双写放大与元数据开销）。代价是 BlueStore 自己必须实现空间分配、校验、压缩等原本由文件系统承担的职责。
1.6 可扩展性与高可用性：Ceph 到底消除了什么
官方用一个对比来立论：
传统架构：客户端要跟一个中心化组件通信——它可能是 gateway、broker、API 或 facade。这个中心化组件是通往复杂子系统的单一入口。依赖这种组件的架构存在：
- 单点故障（single point of failure）
- 性能与可扩展性的上限（limits to performance and scalability）
- 中心化组件一挂，整个系统不可用
Ceph 的做法：消除这个中心化组件。
- 客户端直接与 Ceph OSD 交互。
- Ceph OSD 在其他 Ceph Node 上创建对象副本，保证数据安全与高可用。
- Ceph 用一个 monitor 集群保证高可用。
- 为了消除中心化，Ceph 使用了名为 CRUSH（Controlled Replication Under Scalable Hashing）的算法。
💡 补充：注意官方用词是"消除中心化组件"，而不是"消除中心化管理"。Ceph 依然有 MON 集群做权威状态管理，但它不在数据路径上。这是"控制面中心化、数据面去中心化"的经典设计：控制面要强一致（所以 MON 用 Paxos），数据面要去中心（所以客户端和 OSD 都用 CRUSH 自己算位置）。很多 Ceph 排障思路都源于这个二分法——比如"集群能
ceph -s但业务 IO 卡住"，通常是数据面（OSD/PG）问题，而"业务 IO 正常但看不到状态"通常是控制面（MON/MGR）问题。
引自：Architecture
二、Ceph 存储集群组件
本章按 MON → MGR → OSD → MDS 的顺序展开。每个组件都按「是什么 / 为什么这么设计 / 内部原理 / 举例 / 注意事项 / 与其他概念的关系」六段式说明。
2.1 Ceph Monitor（MON，ceph-mon）
是什么
Ceph Monitor 维护 cluster map 的主副本（master copy），并将其提供给 Ceph 客户端。Ceph 用一个 monitor 集群（而非单个 monitor）来提升可靠性与容错能力。
为什么这么设计
- 客户端必须先拿到 cluster map 才能干活：一个 Ceph Client 必须联系 Ceph Monitor 并取得当前的 cluster map 副本，才能从集群读数据或向集群写数据。
- 单个 monitor 可以正常工作，但存在单点故障：一旦它挂了，客户端就无法读写。
- 多个 monitor 时，可能因为延迟或其他故障导致部分 monitor 落后（fall behind）。Ceph 的缓解办法是：要求多数 monitor 实例就集群状态达成一致。
内部原理：Paxos 与多数派
Ceph 使用 Paxos 算法与「多数派 monitor」在 monitor 之间建立关于集群状态的一致性（consensus）。官方给出的多数派数量表：
| monitor 总数 | 需要的多数派数量 |
|---|---|
| 1 | 1 |
| 3 | 2 |
| 5 | 3 |
| 6 | 4 |
| … | 依此类推（and so on） |
💡 补充：这张表揭示了一个重要的运维事实——偶数个 monitor 不会带来额外容错能力。3 个 MON 允许坏 1 个，4 个 MON 也只允许坏 1 个（需要 3 个存活，原文未列 4 个的情况，但按「多数派」规则即 3），却多消耗一台机器。因此生产环境普遍部署 3 或 5 个 MON。
术语表（Glossary）对 Quorum 的定义是：集群中多数 Monitor 处于 up 状态时所处的状态；集群中必须至少存在 3 个 Monitor，Quorum 才可能成立。
术语表对 Ceph Monitor 的补充：一个 Ceph 集群必须至少包含 3 个运行中的 monitor，才能同时具备冗余（redundant）与高可用（highly-available）。Monitor 及其所在节点常被称作 "mon"。
注意事项
- Monitor 不参与数据路径。它不在客户端与 OSD 之间转发数据。
- Monitor 尽量做轻量级进程：故障检测的主要工作由 OSD 互相之间完成（见 2.3 节与第八章）。
- Monitor 的持久化存储称为 Monitor Store，指 Monitor 使用的持久化存储，包括 Monitor 的 RocksDB 以及
/var/lib/ceph下的相关文件。
与其他概念的关系
- MON ← → Cluster Map：MON 持有主副本；客户端和 OSD 持有副本。
- MON ← → CephX：CephX 认证中，客户端与 MON 各持有一份客户端的密钥；每个 MON 都能独立认证用户并分发票据（见第六章）。
- MON ← → MDS：CephFS 中 active MDS 故障切换由
ceph-mon自动触发（见 2.4）。
2.2 Ceph Manager（MGR，ceph-mgr）
是什么
术语表定义：Ceph Manager 守护进程（ceph-mgr）与 monitor 守护进程并排运行（runs alongside），提供额外的监控能力，以及对接外部监控与管理系统的接口。它也常被描述为「把整个集群的全部状态收集到一处」的软件（MGR：collects all the state from the whole cluster in one place）。
architecture.rst 的定位更偏功能面：Ceph Manager 是 monitoring、orchestration 与 plug-in modules 的端点（endpoint）。
为什么这么设计
在 Luminous 之前，ceph -s 里的很多状态要靠 monitor 或外部脚本去聚合；随着集群规模增长，这类聚合逻辑越来越不适合塞进 Paxos 强一致状态的 MON 里。MGR 的引入把「读多写少、允许重建、允许扩展」的集群视图类工作从 MON 剥离出来，做成一个插件化的守护进程。
关键事实（官方）：
- 自 Luminous（12.x） 起，没有运行中的
ceph-mgr，Ceph 集群无法正常工作。在 11.x（Kraken）中它是可选组件。 - 默认情况下，manager 守护进程除了"确保它在运行"之外不需要额外配置。
- 如果没有 mgr 在跑：会看到一条健康警告；
ceph status输出中的部分信息会缺失或过期（stale）。 - 通常应在每个运行
ceph-mon的主机上部署一个ceph-mgr，以获得同等可用性；并不强制与 mon 同机，但「几乎总是明智的」（almost always sensible）。
内部原理：模块（module）机制
MGR 的能力几乎全部由模块提供。官方 mgr/index.rst 列出的模块（部分）：
| 模块 | 作用（按官方标题） |
|---|---|
dashboard |
内建的 Web 管理与监控应用 |
prometheus |
提供 Prometheus exporter，把 ceph-mgr 收集点的性能计数器传给 Prometheus |
alerts |
告警 |
diskprediction |
磁盘预测 |
localpool |
本地池 |
influx / telegraf |
对接时序数据库 |
hello |
示例模块 |
telemetry |
遥测 |
iostat |
I/O 统计 |
crash |
崩溃信息收集 |
insights |
洞察 |
orchestrator |
编排（如对接 cephadm / rook） |
rook |
Rook 集成 |
rgw |
RGW 管理 |
mds_autoscaler |
MDS 自动伸缩 |
nfs / smb |
NFS / SMB 网关管理 |
progress |
进度跟踪 |
cli_api |
CLI API 命令 |
MGR 的三种守护进程状态（官方 mgr/administrator.rst，在 ceph status 中可见）：
| 状态 | 含义 |
|---|---|
| active | 该 Manager 已完全初始化，可以接收并执行命令。同一时刻只有一个 Manager 处于此状态 |
| active (starting) | 已被选为 active 但尚未完成初始化。此时管理员仍可下发命令，命令会被暂存，待其变为 active 后执行。同一时刻只有一个 |
| standby | 当前不接收/执行命令，但随时可接管。可用 ceph mgr fail <mgr name> 手动把某个 standby 提升为 active。所有非 active / active (starting) 的 Manager 都处于此状态 |
MGR 的高可用机制（官方）：
- 默认情况下，最先启动的那个 ceph-mgr 实例会被 monitor 置为 active，其余为 standby。
- MGR 之间不需要 quorum。
- 如果 active 守护进程超过
mon_mgr_beacon_grace未向 monitor 发送 beacon，它将被一个 standby 取代。 - 可以显式执行
ceph mgr fail <mgr name>抢占式切换。 - 性能与可扩展性：所有 mgr 模块共享一个缓存，可用
ceph config set mgr mgr_ttl_cache_expire_seconds <seconds>开启。官方建议在 500+ OSD 或 10k+ PG 时启用 10 秒 TTL 的缓存（举例：1000 个 OSD 的 OSDMap 约 4MiB；在 3000 OSD 集群上有过 1.5 倍提升）。
Ceph Dashboard 是最常用的模块：它是内建的、基于 Web 的 Ceph 管理与监控应用，用于查看和管理集群内各类资源，实现为一个 ceph-mgr 模块。
举例
ceph status 输出中的相关行（官方示例）：
services:
mon: 3 daemons, quorum a,b,c (age 47m) [leader: a]
mgr: x(active, starting, since 3s)
mds: 1/1 daemons up, 2 standby
osd: 4 osds: 4 up (since 47m), 4 in (since 47m)
手工创建 mgr 的认证 key（官方）：
ceph auth get-or-create mgr.$name mon 'allow profile mgr' osd 'allow *' mds 'allow *'
注意事项
- MGR 挂了不会立刻导致数据不可用，但会丢监控视图与依赖 mgr 的功能（如 dashboard、
ceph -s中部分字段、部分 CLI），且会报健康警告。 - 老集群升级后，若客户端 CephX capabilities 没有
mgr allow *，调用某些集群命令会收到 EACCES 错误。
与其他概念的关系
- MGR ← → MON：MGR 由 monitor 决定谁是 active；MGR 通过 beacon 向 monitor 报活。
- MGR ← → CephX：MGR 是 CephX 中的一类服务（AUTH、MON、MGR、OSD、MDS 之一）。
- MGR ← → Prometheus / Dashboard：通过模块把集群状态导出给外部系统。
引自：Architecture、Glossary、Ceph Manager Daemon、ceph-mgr administrator's guide
2.3 Ceph OSD Daemon（ceph-osd）
OSD 是整个 Ceph 里工作量最重的守护进程。本节覆盖：对象存储、状态上报、心跳、peering、scrub、复制。
2.3.1 是什么
- Ceph OSD Daemon 检查自身状态以及其他 OSD 的状态，并回报给 monitor。
- Ceph OSD 控制存储驱动器上的 read / write / replication 操作。
- 每个 RADOS object 存放在一个 Object Storage Device（也叫做 "OSD"）上。
💡 术语坑：术语表专门解释了 "OSD" 的歧义。约 2013 年，"研究界与工业界"曾试图坚持 OSD 只表示 "Object Storage Device"（物理或逻辑存储单元，例如 LUN）；但 Ceph 社区始终用它表示 "Object Storage Daemon"。Sage Weil 本人在 2022 年 11 月确认 "Daemon is more accurate for how Ceph is built"。因此在本手册中，OSD 默认指 Ceph OSD Daemon（即
ceph-osd软件进程）；当指物理/逻辑磁盘时，官方用 Object Storage Device 全称。
2.3.2 数据以对象形式存储在扁平命名空间
Ceph OSD 守护进程把数据以对象形式存放在**扁平命名空间（flat namespace）**中。这意味着：对象不是按目录层级存放的。
一个对象的组成（原图为 RADOS 对象结构示意图 .. ditaa::）：
/------+------------------------------+----------------\
| ID | Binary Data | Metadata |
+------+------------------------------+----------------+
| 1234 | 0101010101010100110101010010 | name1 = value1 |
| | 0101100001010100110101010010 | name2 = value2 |
| | 0101100001010100110101010010 | nameN = valueN |
\------+------------------------------+----------------/
即：标识符（ID）+ 二进制数据（Binary Data）+ 由 name/value 对组成的元数据（Metadata）。
对象 ID 在整个集群范围内唯一，而不仅仅是在本地文件系统内唯一（原文 note）。
对象的语义由 Ceph Client 决定：例如 CephFS 用元数据来存储文件属性，如文件属主（file owner）、创建日期（created date）、最后修改日期（last modified date）。
对象与 OSD、驱动器的关系（原图为 object → OSD → drive 关系示意图 .. ditaa::）：
/------\ +-----+ +-----+
| obj |------>| {d} |------>| {s} |
\------/ +-----+ +-----+
Object OSD Drive
2.3.3 OSD 成员身份与状态（Membership and Status）
OSD 加入集群时会上报自己的状态。
- 最低层级的状态是
up或down，反映该 OSD 守护进程是否在运行、是否能够服务 Ceph Client 请求。 - 若一个 OSD 是
down且in集群，这个状态可能指示该 OSD 守护进程发生了故障。 - 若 OSD 因崩溃而未运行，它无法通知 Monitor 自己是
down。 - 因此 OSD 会周期性向 Monitor 发送消息：
- Luminous 之前：通过
MPGStats - 从 Luminous 起：通过
MOSDBeacon
- Luminous 之前：通过
- 如果 Monitor 在一段可配置的时间内没有收到这类消息，就把该 OSD 标记为
down。 - 但官方强调：这个机制是一种兜底（failsafe）。正常情况是：OSD 自己判断邻居 OSD 是否
down，并上报给 Monitor——这让 Monitor 保持为轻量级进程。
心跳数值（引自 mon-osd-interaction.rst，官方默认值）：
| 行为 | 官方数值 |
|---|---|
| OSD 检查其他 OSD 心跳的间隔 | 随机间隔，小于每 6 秒 |
| 邻居 OSD 未显示心跳的宽限期（grace period） | 20 秒；超过后可将邻居视为 down 并上报 Monitor |
| OSD 无法 peering 时向 Monitor 索取最新 cluster map 的间隔 | 每 30 秒（osd mon heartbeat interval） |
OSD 在可上报事件（故障、PG stats 变化、up_thru 变化、或启动时）后上报的时限 |
5 秒内 |
| 无论有无变化，OSD 向 Monitor 上报的周期 | 每 120 秒 |
Monitor 判定 OSD down 的超时 |
mon osd report timeout 超时后判定 |
2.3.4 数据清洗（Data Scrubbing）
为维持数据一致性，Ceph OSD 守护进程会 scrub RADOS 对象：
- OSD 把本地对象的元数据与存放在其他 OSD 上的副本的元数据做比较。
- Scrubbing 以 PG 为单位进行（per-Placement-Group basis）。
- 它能发现对象大小不匹配（mismatches in object size）与元数据不匹配（metadata mismatches）。
- 通常每天执行（usually performed daily）。
- 深度清洗（deeper scrubbing）：逐位比较对象数据与校验和，能发现轻度 scrub 检测不出的坏扇区（bad sectors）。
术语表对 scrubs 的补充定义：
| 类型 | 频率（官方） | 做什么 |
|---|---|---|
| light scrubbing（也称 shallow scrubbing） | 每天 | 仅确认对象存在、元数据正确 |
| deep scrubbing | 每周 | 读取数据并用 checksums 确保数据完整性 |
Scrub 的过程（术语表）：Ceph 先生成一个 PG 中所有对象的目录（catalog），然后把每个主对象与存放在其他 OSD 上的副本做比较，确保没有对象丢失或不匹配。任何被判定为「某副本与其它副本不同」或「整个缺失」的 PG 会被标记为 inconsistent。
2.3.5 复制（Replication）
数据复制是 Ceph Client 与 Ceph OSD Daemon 协作完成的：
- Ceph 客户端用 CRUSH 算法确定对象的存储位置 → 对象被映射到 pool 和 placement group → 客户端查阅 CRUSH map 找出该 PG 的 primary OSD。
- 客户端把对象写入该 PG 的 primary OSD。
- Primary OSD 查阅自己的 CRUSH map 副本，找出 secondary OSD。
- Primary OSD 把对象复制到这些 secondary OSD 上的 PG。
- Primary OSD 确认对象已成功存入 secondary OSD。
- Primary OSD 向客户端报告对象写入成功。
这些复制操作被称为 subops。
写入时序（原图为客户端写入复制时序示意图 .. ditaa::）：
+----------+
| Client |
+----------+
* ^
Write (1) | | Ack (6)
v *
+-------------+
| Primary OSD |
+-------------+
* ^ ^ *
Write (2) | | | | Write (3)
+------+ | | +------+
| +------+ +------+ |
| | Ack (4) Ack (5)| |
v * * v
+---------------+ +----------------+
| Secondary OSD | | Secondary OSD |
+---------------+ +----------------+
官方的总结：通过执行这种数据复制，Ceph OSD 守护进程把客户端（及其网卡）从复制数据的负担中解放了出来。
💡 补充：注意时序编号——客户端只发一次写（Write 1），剩下的复制由 primary OSD 承担。这与「客户端并行扇出写多副本」的设计形成对比：Ceph 的选择让客户端的上行带宽只消耗 1 份数据，代价是 primary OSD 承担了额外的一跳转发（这也是为什么 Ceph 集群网络与公共网络的规划很重要，见第十章网络相关分册）。
2.3.6 默认后端：BlueStore
- 默认后端是 BlueStore，它以「整体的、类数据库的方式」存储对象。
- 术语表 BlueStore：OSD 的存储后端，专为 Ceph 设计；Kraken 版本引入，Luminous 版本成为默认后端（取代 FileStore）；自 Reef 版本起，FileStore 不再可用作为存储后端。
- BlueStore 直接把对象存放在裸块设备或分区上，不与已挂载的文件系统交互。
- BlueStore 使用 RocksDB 的 key/value 数据库把对象名映射到磁盘上的块位置（block locations）。
2.3.7 下一代 OSD：Crimson（术语表）
Crimson 是下一代 OSD 架构，目标是降低跨核通信带来的延迟开销。通过重新设计 OSD，减少数据路径上 shard 之间的通信以降低锁竞争；并通过消除对线程池（thread pools）的依赖来提升 classic Ceph OSD 的性能。
2.3.8 注意事项与相关概念
| 注意事项 | 说明 |
|---|---|
| 一个对象 ≠ 一块盘 | 对象是逻辑单元，由 OSD 落盘；BlueStore 负责对象 → 块位置的映射 |
down 不等于 out |
down 是守护进程不服务；out 涉及 CRUSH 是否还把它算作放置目标（见第八章） |
| flapping OSD | 术语表：反复被迅速交替标记为 up 和 down 的 OSD |
| OSD id / fsid / uuid | OSD ID 是每个 OSD 唯一的整数，由 monitor 在 OSD 创建时生成；OSD FSID 是 OSD 的唯一标识符，存于 OSD 路径下的 osd_fsid 文件；FSID 与 UUID 两个术语可互换使用 |
| hybrid OSD | 术语表：同时拥有 HDD 和 SSD 驱动器的 OSD |
引自：Architecture、Glossary、Configuring Monitor/OSD Interaction
2.4 Ceph Metadata Server（MDS，ceph-mds）
是什么
architecture.rst：A Ceph Metadata Server (MDS) 在使用 CephFS 提供文件服务时管理文件元数据。- 术语表 MDS：MetaData Server 守护进程，也称
ceph-mds。任何运行 CephFS 文件系统的 Ceph 集群都必须运行 MDS。MDS 存储全部文件系统元数据。客户端与单个 MDS 或一组 MDS 协同维护 CephFS 所需的分布式元数据缓存。
为什么这么设计：把元数据从数据里分离出来
MDS 存在的原因是：像**列目录（ls）或切目录（cd）**这类简单的文件系统操作，会不必要地消耗 Ceph OSD 守护进程的资源。因此：把元数据与数据分离，意味着 Ceph File System 可以提供高性能服务，而不会拖累 Ceph Storage Cluster。
具体分工：
- MDS：存放全部文件系统元数据（目录、文件属主、访问模式等 directories, file ownership, access modes），元数据驻留在内存中（resides in memory）。
- Ceph Storage Cluster（OSD）：存放文件数据，一个文件被映射为一个或多个对象。
内部原理：单个 / 高可用 / 可扩展
ceph-mds 可以作为单个进程运行，也可以分布到多台物理机上——要么为了高可用，要么为了可扩展性。
| 模式 | 机制（官方原文） |
|---|---|
| High Availability | 额外的 ceph-mds 实例可以是 standby，随时接管任何失败的 active ceph-mds。这很容易做到，因为所有数据（包括 journal）都存放在 RADOS 上。切换由 ceph-mon 自动触发 |
| Scalability | 多个 ceph-mds 实例可以是 active，它们会把目录树切分成子树（subtrees）（以及对单个繁忙目录做分片 shards），从而在所有 active 服务器之间有效地均衡负载 |
standby 与 active 可以组合使用，例如：运行 3 个 active ceph-mds 实例做扩展，外加 1 个 standby 实例做高可用。
注意事项
- 只有 CephFS 需要 MDS。RBD 与 RGW 不需要 MDS——这是初学者最常见的误解之一。
- MDS 的元数据最终落在 RADOS 上（包括 journal），所以 MDS 本身是可重建的；这也是 standby 接管能"很容易"实现的原因。
ceph status中 MDS 行例如mds: 1/1 daemons up, 2 standby。
与其他概念的关系
- MDS ← → CephFS：CephFS 是构建在 RADOS 之上的 POSIX 兼容文件系统（见第十章）。
- MDS ← → MON：active/standby 切换由
ceph-mon触发。 - MDS ← → CephX：MDS 是 CephX 五类服务之一；官方举例"rotating service keys 会安全分发给每类服务，例如 CephFS 的 MDS"。
2.5 四大组件对照表
| 组件 | 是否必须在数据路径上 | 不在会怎样 | 状态一致性机制 | 是否可水平扩展 |
|---|---|---|---|---|
| MON | 否（只提供 cluster map + 认证） | 客户端无法取得/更新 cluster map，无法读写 | Paxos + 多数派（3 节点需 2、5 节点需 3、6 节点需 4） | 是（部署 3/5 个，但不扩吞吐） |
| MGR | 否（监控/编排/插件端点） | 健康警告；ceph -s 部分字段缺失或 stale；dashboard 等模块失效 |
无 quorum 要求；monitor 选主 + beacon（mon_mgr_beacon_grace） |
是（模块可扩展） |
| OSD | 是 | 数据不可读写 | peering（PG 内 OSD 协商）+ Monitor 持有的权威 OSDMap | 是（加 OSD 即扩容并触发 rebalance） |
| MDS | 是（仅 CephFS） | CephFS 不可用；RBD/RGW 不受影响 | active/standby，元数据与 journal 存于 RADOS；由 ceph-mon 触发切换 |
是（多 active 按目录子树分片） |
💡 补充：这张表最有用的一列是"是否必须在数据路径上"。排障时的快速判据：MON/MGR 异常 → 通常是"看得见但管不了/管得慢"；OSD 异常 → 直接是"读写卡/慢/报错"；MDS 异常 → 只有 CephFS 受影响，RBD/RGW 完全无感。
引自：Architecture
三、RADOS 对象存储层：object / pool / PG 的关系
3.1 三层抽象：object → pool → PG
RADOS object ──属于──> pool（逻辑分区） ──划分为──> PG（放置组） ──CRUSH──> OSD
官方的三个定义：
| 概念 | 官方定义 | 关键点 |
|---|---|---|
| Pool | 「用于存储对象的逻辑分区（logical partition）」 | 池是逻辑概念，不是物理设备划分 |
| Placement Group (PG) | 「每个逻辑 Ceph pool 的子集（subsets）」；PG 的功能是把对象（作为一个组）放置到 OSD 中 | Ceph 在内部以 PG 粒度管理数据 |
| RADOS object | 集群存储的唯一数据语义；有 ID + 二进制数据 + name/value 元数据 | ID 全集群唯一 |
3.2 为什么需要 PG 这一层：可扩展性的关键
官方给了两条理由：
- PG 粒度管理比逐对象管理扩展性更好。原文：Ceph 在内部以 placement-group 粒度管理数据，"这比管理一个个（因而数量多得多的）RADOS 对象扩展性更好"（this scales better than would managing individual (and therefore more numerous) RADOS objects）。
- PG 数量越多，均衡性越好。原文：一个拥有较多 PG（例如每 OSD 100 个）的集群，比其它条件相同但 PG 数更少的集群均衡得更好。
data-placement.rst 的补充：PG 减少了 Ceph 在 OSD 中存储数据所需的 per-object 元数据量（Placement groups reduce the amount of per-object metadata that is necessary for Ceph to store the data in OSDs）。并给出同样的经验值对比：每 OSD 100 个 PG 比每 OSD 50 个 PG 均衡得更好。
归属关系（必须记牢的两句原文）：
- Ceph 的内部 RADOS 对象每个都被映射到一个特定的 placement group。
- 每个 placement group 恰好属于一个 Ceph pool（each placement group belongs to exactly one Ceph pool）。
💡 补充：把 PG 理解为"对象的哈希桶 + 一致性单元"最贴切。它同时承担三种角色：
- 寻址中间层：把"数亿个对象"收敛成"数万个 PG"，让元数据（PG 的状态、日志、统计）可控；
- 复制单元：副本/EC 条带是以 PG 为单位组织到 OSD 的（acting set 是 PG 的属性，不是对象的属性）；
- 恢复与均衡单元：recovery、backfill、scrub、rebalance 全部以 PG 为调度粒度。 这也是为什么"PG 数量"是 Ceph 里最难改的参数之一——它同时决定了元数据开销与均衡粒度。
3.3 Pool：它到底设置了什么
architecture.rst「About Pools」给出的关键点：
- Ceph 客户端从 Monitor 取得 Cluster Map，然后把 RADOS 对象写入 pool。
- 数据如何放置在 pool 中由三样东西决定：
- pool 的
size（副本数量） - CRUSH rule
- pool 中的 PG 数量
- pool 的
- Pool 至少设置以下参数：
- Ownership/Access to Objects（对象的归属/访问）
- The Number of Placement Groups（PG 数量）
- The CRUSH Rule to Use（使用的 CRUSH 规则）
官方的 pool → CRUSH rule 关系图（原图为 pool 选择 CRUSH rule 示意图 .. ditaa::）：
+--------+ Retrieves +---------------+
| Client |------------>| Cluster Map |
+--------+ +---------------+
|
v Writes
/-----\
| obj |
\-----/
| To
v
+--------+ +---------------+
| Pool |---------->| CRUSH Rule |
+--------+ Selects +---------------+
data-placement.rst 对 pool 的补充定义：Ceph 把数据存放在 pool 内，pool 是用于存储对象的逻辑组；pool 管理 placement group 的数量、副本的数量、以及该 pool 的 CRUSH rule。要往 pool 里存数据，必须是对该 pool 有权限的已认证用户。Ceph 可以对 pool 做快照。
💡 补充：
architecture.rst里"pool 至少设置三个参数"是最少集合的说法；实际生产中 pool 还涉及pg_num/pgp_num、min_size、EC profile、target_size_ratio等。本册严格按架构页展开，这些运维参数的完整说明属于运维分册。
3.4 PG 数量：数量关系与经验公式
架构页本身给出的数量关系：
- 一个 pool 内有若干 PG。
- CRUSH 动态地把 PG 映射到 OSD。
- 客户端存对象时，CRUSH 把每个 RADOS 对象映射到一个 PG。
- 官方举例：一个每 OSD 100 个 PG 的集群比 PG 更少的同配置集群均衡得更好。
补充公式与数值（引自同版本 rados/operations/placement-groups.rst，非架构页内容，单独标注）：
- 参数
mon_target_pg_per_osd（默认值 100），可用ceph config set global mon_target_pg_per_osd 100调整。 - 官方建议：如果 OSD 超过 50 个，推荐每 OSD 大约 100–250 个 PG 副本。
- 计算公式：Total PGs = OSDs × 100 / pool size。
- 官方算例：200 × 100 / 3 = 6667，向上取整到最近的 2 的幂：8192。
- 另一条规则：默认情况下每个 pool 应有 50–100 个 PG（taking into account the replication）。
💡 补充：公式里的 "100" 来自
mon_target_pg_per_osd默认值，而"除以 pool size"是因为公式统计的是 **PG 副本数（PG replicas）**而非 PG 数——一个 3 副本的 pool，1 个 PG 会占用 3 个 OSD 上的各一份副本。混淆"PG 数"和"PG 副本数"是 PG 规划中最常见的错误。
3.5 object → PG → OSD 的间接层：为什么要加一层
官方的核心论述（「Mapping PGs to OSDs」）：
- 每个 pool 内有若干 PG，CRUSH 动态地把 PG 映射到 OSD。
- 把 RADOS 对象映射到 PG，在 Ceph OSD Daemon 与 Ceph Client 之间实现了一层抽象与间接（abstraction and indirection layer）。
- Ceph Storage Cluster 必须能够在内部拓扑变化时自适应地增长（或收缩）并重新分布数据。
- 如果客户端"知道"哪些 OSD 存了哪些对象，客户端与 OSD 之间就会存在紧耦合（tight coupling）。Ceph 避免了这种紧耦合：CRUSH 先把对象映射到 PG，再把 PG 映射到一个或多个 OSD。
- 这层间接让 Ceph 能够在新 OSD 及其底层设备上线时动态再平衡。
对象 → PG → OSD 映射（原图为 object/PG/OSD 映射关系示意图 .. ditaa::）：
/-----\ /-----\ /-----\ /-----\ /-----\
| obj | | obj | | obj | | obj | | obj |
\-----/ \-----/ \-----/ \-----/ \-----/
| | | | |
+--------+--------+ +---+----+
| |
v v
+-----------------------+ +-----------------------+
| Placement Group #1 | | Placement Group #2 |
+-----------------------+ +-----------------------+
| |
| +-----------------------+---+
+------+------+-------------+ |
| | | |
v v v v
/----------\ /----------\ /----------\ /----------\
| OSD #1 | | OSD #2 | | OSD #3 | | OSD #4 |
\----------/ \----------/ \----------/ \----------/
💡 补充：注意图里一个 PG 指向多个 OSD——这就是副本（或 EC 分片）。同一个 PG 的多个副本分散在不同 OSD 上，构成一个 acting set（见第五章与第八章）。而多个对象可以映射到同一个 PG，这正是"PG 是对象的哈希桶"的直观体现。
3.6 三层概念对照与数量关系速查
| 层级 | 数量级（典型） | 由谁决定 | 是否可变 | 变化后果 |
|---|---|---|---|---|
| object | 亿级 ~ 十亿级 | 客户端写入 | 随时增删改 | 无（最细粒度） |
| PG | 千级 ~ 万级（每 pool） | pool 的 pg_num / autoscaler |
可调整但有代价 | 触发 PG 分裂与数据迁移 |
| pool | 个级 ~ 十级 | 管理员创建 | 可增删 | 影响 CRUSH rule、配额、权限 |
| OSD | 十级 ~ 千级 | 硬件与部署 | 可扩缩 | 触发 rebalance |
四、CRUSH 算法
说明：
architecture.rst在本章范围内只给了「CRUSH Introduction」与 cluster map 中 CRUSH Map 的一句话定义。为了让本册把 CRUSH 讲透，本章从**同版本（Tentacle v20.2.4）**的rados/operations/crush-map.rst与dev/crush-msr.rst补充结构、bucket 类型、rule 语法与权重机制，并逐节标注来源。凡官方未给出的内部实现细节，标注「文档未明确」。
4.1 为什么需要 CRUSH
问题：中心查找表的三重罪
architecture.rst 的论证是：
- 传统上，客户端与 OSD 依赖**中心查找表（central lookup table）**来确定数据位置。
- 依赖中心查找表会让客户端与 OSD 被中心查找表卡住脖子（bottlenecked）。
- 而 CRUSH 让 Ceph Client 与 Ceph OSD Daemon 都通过算法计算对象位置信息，而不是查表。
crush-map.rst 的补充论证（三重收益）：
CRUSH 让 Ceph 客户端直接与 OSD 通信，而不是通过一个中心化的服务器或 broker。通过这种由算法决定的存取方法，Ceph 得以避免单点故障、性能瓶颈以及可扩展性的物理上限。
收益：把工作分摊到全集群
architecture.rst：CRUSH 提供了比旧方法更好的数据管理机制，并且通过把工作分发给集群中所有的 OSD 守护进程以及所有与它们通信的客户端，CRUSH 实现了大规模（massive scale）。
此外，CRUSH 使用智能的数据复制（intelligent data replication）来确保韧性（resiliency），这更适合超大规模存储（hyper-scale storage）。
4.2 CRUSH 与传统哈希表的对比
| 维度 | 传统中心查找表 / 朴素哈希 | CRUSH |
|---|---|---|
| 位置获取方式 | 查询中心表（一次网络往返） | 本地计算（无网络往返） |
| 单点故障 | 有（表所在的中心组件） | 无（每个客户端/OSD 都有 CRUSH map 副本） |
| 性能瓶颈 | 中心组件是所有请求的汇聚点 | 计算分摊到所有客户端与 OSD |
| 可扩展性上限 | 受中心组件容量限制 | 无物理上限（文档表述：avoids a physical limit to its scalability） |
| 故障域感知 | 需要额外机制 | 内建：CRUSH map 编码了物理拓扑与故障域 |
| 拓扑变化时的数据迁移 | 朴素哈希（hash mod N）会导致几乎全部数据重排 |
稳定：大量 PG 保持原位（见 4.7 重平衡） |
| 权重/容量异构 | 通常不支持 | 支持（weight，见 4.6） |
官方原文对"计算 vs 查询"的论述（「Calculating PG IDs」）：计算对象位置要比通过一次啰嗦的会话（chatty session）去查询对象位置快得多。
💡 补充：CRUSH 常被类比为一致性哈希的一种工程化、层次化实现，二者的共同目标是"节点变化时最小化数据搬迁"。但 CRUSH 比朴素一致性哈希多了三样东西：(1) 层次化的物理拓扑（bucket 树）、(2) 每节点权重（支持异构容量）、(3) 可声明的放置规则与故障域约束。这三点是它能在真实数据中心里落地的原因。此处的"一致性哈希"类比是笔者的解释性补充，官方文档本身只说 CRUSH 是 "Controlled Replication Under Scalable Hashing"，未使用一致性哈希的表述。
4.3 CRUSH map 的组成
crush-map.rst 的定义（原文）：CRUSH map 由 (1) 描述集群物理拓扑的层级结构（hierarchy）与 (2) 一组定义数据放置策略的规则（rules）组成。
architecture.rst 在 cluster map 中对 CRUSH Map 的定义：包含存储设备列表、故障域层级（failure domain hierarchy，例如 device、host、rack、row、room），以及在存储数据时遍历该层级的规则（rules）。
查看 CRUSH map 的官方命令（architecture.rst）：
ceph osd getcrushmap -o {filename}
crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename}
# 之后用文本编辑器或 cat 查看反编译后的 map
4.4 Devices（设备）
- Devices 是存放数据的单个 OSD（通常每个存储驱动器一个 device）。
- 由
id（非负整数）与name（通常是osd.N，其中N是该设备的id）标识。 - 自 Luminous 起，OSD 可以被赋予 device class（例如
hdd、ssd、nvme），从而被 CRUSH rule 定向选择。在同一 host 内混插不同设备类型时，device class 尤其有用。
4.5 Types and Buckets（类型与桶）
Bucket 的定义：在 CRUSH 语境中，"bucket" 是层级中任何内部节点的统称：hosts、racks、rows 等等。CRUSH map 定义了一系列 types 用于标识这些节点。
默认类型（官方列表，共 12 个）：
| # | type | 说明（本册注释） |
|---|---|---|
| 1 | osd（或 device） |
叶子节点 |
| 2 | host |
主机 |
| 3 | chassis |
机箱 |
| 4 | rack |
机柜 |
| 5 | row |
机列 |
| 6 | pdu |
电源分配单元 |
| 7 | pod |
交付单元/资源池单元 |
| 8 | room |
机房 |
| 9 | datacenter |
数据中心 |
| 10 | zone |
可用区 |
| 11 | region |
地域 |
| 12 | root |
根节点 |
官方说明：大多数集群只使用其中少数几个类型，其它类型可以按需定义。
层级结构：叶子是 device（通常 type 为 osd），内部节点是非 device 类型，根节点类型为 root。
CRUSH 层级示意（原图为 CRUSH 层级结构示意图 .. ditaa::，取自 crush-map.rst）：
+-----------------+
|{o}root default |
+--------+--------+
|
+---------------+---------------+
| |
+------+------+ +------+------+
|{o}host foo | |{o}host bar |
+------+------+ +------+------+
| |
+-------+-------+ +-------+-------+
| | | |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| osd.0 | | osd.1 | | osd.2 | | osd.3 |
+-----------+ +-----------+ +-----------+ +-----------+
OSD 如何进入层级（CRUSH Location）：
- OSD 部署时，会被自动加入 CRUSH map 中以该 OSD 所在节点命名的
hostbucket 之下。结合所配置的 CRUSH 故障域，这确保了副本或纠删码分片跨主机分布，并且单个主机故障（或其它类型故障）不会影响可用性。 - OSD 在 CRUSH map 层级中的位置称为其 CRUSH location，用一组 key-value 对描述。例如一个 OSD 位于某个 row、rack、chassis、host 中，并且属于
defaultCRUSH root（大多数集群如此），其 CRUSH location 可这样指定：
root=default row=a rack=a2 chassis=a2a host=a2a1
- 可在
ceph.conf中用crush_location选项设置。设置后，OSD 每次启动都会校验自己是否位于 CRUSH map 中的正确位置，若不在则自行移动。 - 若未显式设置
crush_location，OSD 使用默认值root=default host=HOSTNAME，其中 hostname 由hostname -s命令的输出决定。 - 可用 custom location hook 在启动时生成更完整的 CRUSH location（例如跨多个数据中心部署同一份配置时）。
4.6 故障域（Failure Domain）
为什么需要：CRUSH 通过反映部署环境的底层物理组织，可以建模（并因此应对）相关设备故障的可能性（correlated device failures）。与 CRUSH 层级相关的因素包括：chassis、racks、物理邻近性、共享电源、共享网络、以及故障域。
怎么做：把这些信息编码进 CRUSH map 后，CRUSH 放置策略就能在维持期望分布的同时，把对象副本分布到不同的故障域上。官方举的动机性例子：为应对并发故障，可能希望确保数据副本位于不同 shelves / racks / power supplies / controllers / physical locations。
故障域的选择：
- OSD 部署时自动归入
hostbucket + 所配置的故障域 → 保证副本/EC 分片跨主机分布。 - 官方提示：更大规模的集群，管理员必须仔细考虑故障域的选择。例如跨 rack 分布副本在中大型集群中是典型的做法。
💡 补充：故障域的选择本质是"容错能力 vs 资源效率 vs 放置成功率"的三方权衡：故障域越粗（
host→rack→datacenter），抗相关故障能力越强，但要求该层级下的域数量 ≥ 副本数，否则 CRUSH 选不出足够的独立目标，PG 会undersized/incomplete。例如size=3且故障域设为rack，集群至少需要 3 个 rack。
4.7 Rules（放置规则）
是什么
- CRUSH rules 定义策略，规定数据如何分布到层级中的设备上。
- 规则定义了 placement 以及 replication strategies / distribution policies，让你能精确指定 CRUSH 如何放置数据副本。
- 官方举的三种规则形态：
- 选择一对目标做双路镜像（two-way mirroring）
- 选择两个不同数据中心中的三个目标做三副本
- 跨六个存储设备做纠删码
怎么创建
- CRUSH 规则可以通过命令行创建，需指定：
- pool type（
replicated或erasure coded） - failure domain
- 可选地指定 device class
- pool type（
- 极少数情况下必须手工编辑 CRUSH map 来创建规则。
查看命令：
ceph osd crush rule ls # 列出集群中定义的规则
ceph osd crush rule dump # 查看规则内容
rule 语法（引自同版本 dev/crush-msr.rst，官方示例）
一个典型的三副本规则（跨 host）：
rule replicated_rule_1 {
...
step take default class hdd
step chooseleaf firstn 3 type host
step emit
}
拆成 choose + choose 的等价写法：
rule replicated_rule_1 {
...
step take default class hdd
step choose firstn 3 type host
step choose firstn 1 type osd
step emit
}
EC 场景（把 8+6 编码分摊到 4 个 host）：
rule ecpool-86 {
...
step take default class hdd
step choose indep 4 type host
step choose indep 4 type osd
step emit
}
| step 关键字 | 含义（据官方示例与说明） |
|---|---|
step take <root> [class <class>] |
从层级中取出一个子树作为选择起点（如 default，可加 class hdd 限定设备类） |
step chooseleaf firstn N type <type> |
选出 N 个 <type> 类型的 bucket，并在各自内部再下探到叶子（OSD） |
step choose firstn N type <type> |
只选出 N 个 <type> 类型的 bucket，不自动下探 |
step choose indep N type <type> |
indep 变体，用于 EC 等需要"位置稳定"的场景 |
step emit |
输出结果 |
step choosemsr N type <type> / type msr_indep |
CRUSH MSR（Multi-step Retry）规则专用，见下文 |
firstn 与 indep 的行为差异、chooseleaf 与 choose 的差异（官方说明）：
- 当 N 个 OSD 需要分布到 N 个故障域时，用
chooseleaf即可。 - 但如果某个 host 上的所有 OSD 都被标记
out，用choose firstn 3 type host+choose firstn 1 type osd的写法时，映射到该 OSD 的 PG 会被重映射到同一 host 上的其它 OSD，导致这些 OSD 相对其它 host 的 OSD 被过度使用；若一个 host 上所有 OSD 都 out，命中该 host 的映射会失败，导致 undersized PG。 - 而
chooseleaf firstn 3 type host在这种情况下会把映射重映射到其它 host（只要有足够的 host）。官方还给出定量描述：如果某 host 上 1/8 的 OSD 被标记 out，大约 1/8 映射到该 host 的 PG 会被重映射到别的 host，保持整体每 OSD 利用率均衡。 chooseleaf的局限：它不支持在指定 type 之下映射多于一个叶子（does not support mapping more than one leaf below the specified type），所以上面的 8+6 跨 4 host 场景不能用它。
CRUSH MSR（Multi-step Retry）
- 经典 CRUSH 的局限：包含多个
choosestep 的规则，在遇到outOSD 时无法回退重试前面的 step。 - MSR 规则用不同的下探算法解决这个问题：命中 out OSD 时重试所有 step。
- 经典 CRUSH 是广度优先（breadth first：对每一个 step，先把结果向量填满，再进入下一个 step）；MSR 规则是深度优先（depth first：对每一次选择，递归地走完所有 step，再进行下一次选择）。
- MSR 示例：
rule ecpool-86 {
type msr_indep
...
step take default class hdd
step choosemsr 4 type host
step choosemsr 4 type osd
step emit
}
💡 补充：
chooseleafvschoose的这段官方说明是 CRUSH 排障里非常实用的一条：当集群出现"OSD out 之后剩余 OSD 利用率不均"或"PG undersized"时，优先检查 CRUSH rule 是否用了choose ... choose ...的多段写法，而不是chooseleaf。
关于 ruleset：本册抓取的 Tentacle v20.2.4 源文（含
architecture.rst、crush-map.rst、crush-msr.rst等）中未出现ruleset这一术语；当前文档统一使用 CRUSH rule / rules 表述，并通过ceph osd crush rule ...命令族管理。因此本册不对ruleset给出定义——详见文末「文档未明确项」。
4.8 Device classes（设备类）
- 每个 device 可以可选地拥有一个 class。默认情况下，OSD 在启动时根据其底层设备类型自动设置为
hdd、ssd或nvme。 - 显式设置：
ceph osd crush set-device-class <class> <osd-name> [...] - 一旦设置了 device class，必须先 unset 旧 class 才能改成另一个 class；移除：
ceph osd crush rm-device-class <osd-name> [...] - 这条限制让管理员可以设置不会被 OSD 重启或脚本改掉的 device class。
- 创建面向特定 device class 的放置规则：
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class> - 应用到 pool：
ceph osd pool set <pool-name> crush_rule <rule-name> - 实现机制：device class 通过创建一个或多个 "shadow" CRUSH 层级实现——每种在用的 device class 都有一个只包含该类设备的 shadow 层级，CRUSH 规则随后在相应的 shadow 层级上分布数据。这种做法对老版本 Ceph 客户端完全向后兼容。
- 查看带 shadow 项的层级：
ceph osd crush tree --show-shadow - Luminous 之前创建的老集群可能依赖手工 CRUSH map 来维护按设备类型的层级，官方提供 reclassify 工具帮助它们迁移到 device class 而不触发不必要的数据迁移。
4.9 权重（Weight）与重平衡
权重的定义
- 层级中的每个节点（device 或 bucket）都有一个 weight，表示该设备或该子树应当存储的数据占全部数据的相对比例。
- 权重设置在叶子节点上，表示设备的大小。
- 这些权重自动沿"树上"方向求和：即
root节点的权重等于其下所有 device 权重之和。 - 权重通常以 tebibytes（TiB）为单位。
- 查看：
ceph osd tree
为什么有权重还不够：weight sets
crush-map.rst 的解释很直白：CRUSH 是一个概率性的伪随机放置过程，因此总会与理想分布存在一定偏差（就像掷骰子 60 次，很可能不会恰好得到 10 个 1 和 10 个 6）。Weight sets 允许集群基于你的集群具体情况（层级、pool 等）做数值优化，以达成均衡分布。
两种 weight set：
| 类型 | 特点（官方） |
|---|---|
| compat weight set | 为集群中每个 device 和每个 node 提供单一的一套替代权重。不能指望它纠正所有异常（例如不同 pool 的 PG 大小与负载可能不同，但 balancer 大多一视同仁）。主要优势是向后兼容——即使 weight set 是 Luminous v12.2.z 引入的，使用 compat weight set 时老客户端（例如 Firefly）仍能连上集群 |
| per-pool weight set | 更灵活：允许针对每个 data pool 优化放置；并且可以针对放置的每个位置（position）调整权重，使优化器能够纠正"数据向权重相对较小的设备倾斜"的细微偏差（这种效应通常只在超大规模集群中明显，但会导致均衡问题） |
使用 weight set 时，各节点权重会在 ceph osd tree 输出中的单独一列显示（列标签为 (compat) 或 pool 名称）。
重平衡（Rebalancing）
architecture.rst 的论述：
- 当你向集群添加一个 Ceph OSD Daemon 时，cluster map 会更新为包含这个新 OSD。
- 这改变了 cluster map，因而改变了对象放置，因为它改变了计算的一个输入。
- 关键性质：即使在重平衡时，CRUSH 也是稳定的（CRUSH is stable）。
- 许多 PG 保持原有配置不变；
- 每个 OSD 都获得一部分新增容量；
- 因此重平衡完成后新 OSD 上不会出现负载尖峰（no load spikes）。
- 官方也坦承下面这张图相当粗糙（albeit rather crudely），因为在大规模集群中影响要小得多。
重平衡前后（原图为 rebalancing 过程示意图 .. ditaa::）：
+--------+ +--------+
Before | OSD 1 | | OSD 2 |
+--------+ +--------+
| PG #1 | | PG #6 |
| PG #2 | | PG #7 |
| PG #3 | | PG #8 |
| PG #4 | | PG #9 |
| PG #5 | | PG #10 |
+--------+ +--------+
+--------+ +--------+ +--------+
After | OSD 1 | | OSD 2 | | OSD 3 |
+--------+ +--------+ +--------+
| PG #1 | | PG #7 | | PG #3 |
| PG #2 | | PG #8 | | PG #6 |
| PG #4 | | PG #10 | | PG #9 |
| PG #5 | | | | |
| | | | | |
+--------+ +--------+ +--------+
💡 补充：把两张图对照看，可以验证官方说的"CRUSH 是稳定的"：10 个 PG 中只有 PG #3、PG #6、PG #9 三个迁移到了新 OSD（约 30%），其余 7 个原地不动。这正是层次化 CRUSH 相对
hash mod N的核心优势——朴素取模在 N 从 2 变 3 时几乎会导致全部数据重排。也解释了为什么"扩 OSD 后集群会很长时间处于recovery/backfill状态但并不会把网络打满"。
4.10 CRUSH 查找过程（Descent）
官方文档给出的部分：
- 输入：CRUSH 需要 cluster map（CRUSH map）、pool 的 CRUSH rule、以及 PG 作为放置单位。
- 规则从
step take <root>（可带class）开始，确定选择起点。 - 按 step 依次下探：
chooseleaf firstn N type X（一步到位下探到叶子）或choose ... choose ...（分段下探）。 - 输出：
step emit，得到 N 个 OSD 组成的结果向量（对应 acting set 的目标）。 - 经典 CRUSH 是广度优先（逐步填满结果向量）；MSR 是深度优先并在遇到
outOSD 时重试所有 step。
文档未明确的部分（本册不推测）：
- CRUSH 在每一层如何从兄弟节点中选出一个（例如 straw / straw2 这类 bucket 选择算法的具体实现、随机种子
r的取值与递增规则、冲突/失败时的重试次数上限）——文档未明确。 - CRUSH 输入中除 PG 之外的其他参数（如副本序号
r）的完整取值规则——文档未明确。 firstn与indep在算法层面的精确差异（官方只给出用途与行为描述，未给出实现细节）——文档未明确。
💡 补充（概念性描述，非官方原文）：可以把它理解为"带约束的、确定性的伪随机下探"——给定 (PG id, 层级, 权重, 规则, 副本序号)，任何持有相同 CRUSH map 的一方（客户端或 OSD）都会算出完全相同的结果。这个"确定性"是 Ceph 去中心化的前提：客户端不需要问任何中心组件，只要大家手上的 CRUSH map 版本一致（或能够通过 epoch 对齐），就能独立算出一致的位置。
4.11 CRUSH 关键命令速查
| 目的 | 命令 |
|---|---|
| 导出 CRUSH map | ceph osd getcrushmap -o {filename} |
| 反编译 CRUSH map | crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename} |
| 查看层级与权重 | ceph osd tree |
| 查看（含 shadow 层级） | ceph osd crush tree --show-shadow |
| 列出规则 | ceph osd crush rule ls |
| 查看规则内容 | ceph osd crush rule dump |
| 创建副本规则（带 device class） | ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class> |
| 给 pool 应用规则 | ceph osd pool set <pool-name> crush_rule <rule-name> |
| 设置 device class | ceph osd crush set-device-class <class> <osd-name> [...] |
| 移除 device class | ceph osd crush rm-device-class <osd-name> [...] |
五、数据放置与寻址完整链路：file → object → pool → PG → OSD
本章把前面几章的零件组装成一条完整链路，并给出可手工验算的示例。
5.1 全链路总览
┌──────────────────────────────────────────────────────────────────────┐
│ 客户端侧（Ceph Client：RBD / RGW / CephFS / librados 自定义实现） │
└──────────────────────────────────────────────────────────────────────┘
│
│ ① 把用户数据切成对象（RBD/RGW/CephFS 各自负责条带化与命名）
v
┌──────────────┐
│ object │ name: "john" / "paul" / ... （ID 全集群唯一）
└──────────────┘
│
│ ② 选定 pool（客户端写到哪个 pool）
v
┌──────────────┐
│ pool │ name: "liverpool" → pool ID: 4
└──────────────┘
│
│ ③ 计算 PG ID：hash(object ID) mod pg_num → PG ID；再前置 pool ID
v
┌──────────────┐
│ PG │ PG ID: 4.58
└──────────────┘
│
│ ④ CRUSH（用 cluster map + pool 的 CRUSH rule）：PG → OSD 集合
v
┌──────────────────────────────────────────────┐
│ Acting Set: [Primary, Secondary, ...] │
│ 例：osd.25(Primary), osd.32, osd.61 │
└──────────────────────────────────────────────┘
│
│ ⑤ 客户端直连 Primary OSD 写入；Primary 通过 subops 复制到 Secondary
v
┌──────────────────────────────────────────────┐
│ OSD → BlueStore → Drive │
└──────────────────────────────────────────────┘
5.2 第 ① 步：file → object（客户端侧的数据表示转换）
官方说明（「Data Striping」）：Ceph 提供三类客户端（Ceph Block Device、Ceph File System、Ceph Object Storage）。Ceph 客户端把它提供给用户的数据表示格式（块设备镜像、RESTful 对象、CephFS 文件系统目录）转换成对象，以便存入 Ceph Storage Cluster。
各客户端的切分方式：
| 客户端 | 用户看到的形态 | 转换成 |
|---|---|---|
| RBD | 块设备镜像（block device image） | 镜像被条带化到多个对象上（详见第九章） |
| RGW | RESTful 对象（S3 / Swift object） | 映射到 Ceph 存储集群对象；S3/Swift 对象与集群对象不一定 1:1，一个 S3 或 Swift 对象可能映射到多个 Ceph 对象 |
| CephFS | 文件系统目录与文件 | CephFS 文件被映射为 Ceph 存放在存储集群中的对象 |
5.3 第 ② 步：选定 pool
- Ceph 把数据存放在命名（named）的 pool 中（例如
"liverpool"）。 - pool 是逻辑分区；pool 至少设置了 对象归属/访问、PG 数量、CRUSH rule。
- 客户端只写单个 pool，因此所有条带化出来的对象都会被映射到同一个 pool 中的 PG，从而使用同一个 CRUSH map 和相同的访问控制（原文 note）。
5.4 第 ③④ 步：计算 PG ID（官方五步法）
前提（极其重要，原文加粗强调）：
- 当 Ceph Client 绑定（binds）到一个 Ceph Monitor 时，它取得最新版本的 Cluster Map。
- 拿到 cluster map 副本后，客户端就知道了集群中所有的 monitor、OSD 和 metadata server。
- 但是，即便手握最新版 cluster map，客户端对对象位置一无所知（the client doesn't know anything about object locations）。
- 对象位置必须被计算出来（Object locations must be computed）。
- 客户端只需要对象 ID 和 pool 名，就能计算出对象位置。
官方五步（Calculating PG IDs）：
| 步骤 | 官方描述 | 官方示例 |
|---|---|---|
| 1 | 客户端输入 pool 名和对象 ID | pool = "liverpool"，object-id = "john" |
| 2 | Ceph 对对象 ID 做哈希（hashes the object ID） | — |
| 3 | Ceph 用哈希值对 PG 数量取模，得到 PG ID | 假设结果为 58 |
| 4 | Ceph 用 pool 名取出 pool ID | "liverpool" = 4 |
| 5 | Ceph 把 pool ID 前置到 PG ID 之前 | 4.58 |
原文在描述这一计算时还提到使用的要素是：object name、a hash code、pool 中 PG 的数量、以及 pool 名。
💡 补充：PG ID 写成
4.58这种「pool_id.pg_id」的形式，是你在ceph pg dump、ceph -s里看到的 PG 编号格式（如4.3f）。注意 PG ID 中的后半部分通常用十六进制显示，而上面步骤里的58是官方给出的十进制示例——两者是同一个数的不同表示。理解"PG 编号 = pool ID + 池内 PG 序号"这一点，对读懂ceph pg map 4.58之类的输出很关键。
5.5 第 ④ 步：PG → OSD（CRUSH 与 Acting Set / Up Set）
- CRUSH 动态地把 PG 映射到 OSD。
- 客户端使用自己的 cluster map 副本与 CRUSH 算法，精确计算出读写某个对象时要使用哪个 OSD。
- 客户端用 CRUSH 确定对象存储位置后，对象被映射到 pool 和 PG，然后客户端查阅 CRUSH map 找出该 PG 的 primary OSD。
Acting Set 与 Up Set（官方定义）：
| 概念 | 定义（原文） |
|---|---|
| Acting Set | 负责某个 placement group 的 OSD 集合。该术语既可以指当前负责该 PG 的 OSD，也可以指在某个 epoch 时曾负责该 PG 的 OSD |
| Up Set | Acting Set 中的 OSD 并不总是 up。当 Acting Set 中的某个 OSD 是 up 时，它就是 Up Set 的一部分。Up Set 是一个重要区分，因为当某个 OSD 失败时，Ceph 可以把 PG 重映射到其它 OSD |
| Primary | 按惯例是 Acting Set 中的第一个 OSD，负责为它作为 Primary 的每个 PG 编排 peering 过程。Primary 是给定 PG 中唯一接受客户端发起的写操作的 OSD |
官方的 Acting Set / Up Set 示例：假设某个 PG 的 Acting Set 包含 osd.25、osd.32、osd.61。第一个 OSD（osd.25）是 Primary。如果它失败，Secondary（osd.32）成为 Primary，而 osd.25 被移出 Up Set。
pg-concepts.rst 的补充定义（更精确）：
| 术语 | 定义 |
|---|---|
| Acting Set | 负责特定 PG 的 OSD 有序列表（或某个 epoch 时的列表） |
| Up Set | 按 CRUSH，特定 epoch 下负责特定 PG 的 OSD 有序列表。通常与 Acting Set 相同，除非 Acting Set 被 OSD Map 中的 pg_temp 显式覆盖 |
| Primary | Acting Set 的成员（按惯例是第一个），负责协调 peering，且是唯一接受客户端对该 PG 中对象发起写操作的 OSD |
| Replica | Acting Set 中的非 primary OSD（且已被 primary 认可并 activated） |
| Stray | 不是当前 Acting Set 成员，但尚未被告知可以删除其某个 PG 副本的 OSD |
| Current Interval / Past Interval | Acting Set 与 Up Set 不发生变化的一段连续 OSD map epoch 序列 |
| Epoch | （单调递增的）OSD map 版本号 |
5.6 第 ⑤ 步：写入 Primary 并复制（subops）
见 2.3.5 节的六步流程与时序图。补充两条原文要点：
- Ceph OSD Daemon 使用 CRUSH 算法确定对象副本的存储位置（即 primary 侧也是算出来的，不是查表）。
- 官方把这类复制操作称为
subops。
5.7 端到端示例（严格使用官方给定的数值）
场景：客户端要把一个名为 john 的对象写入名为 liverpool 的 pool。
输入：
pool name = "liverpool"
object id = "john"
pool 的 PG 数量（pg_num）= 假设值（官方未给出具体 pg_num，仅以结果示例）
① hash("john") -> 得到哈希值（官方未给出具体哈希函数与数值）
② hash % pg_num -> 58 （官方示例值）
③ pool name -> pool ID -> "liverpool" = 4 （官方示例值）
④ 拼接 -> PG ID = 4.58 （官方示例值）
⑤ CRUSH(4.58, CRUSH map, pool 的 CRUSH rule) -> Acting Set
例如 [osd.25, osd.32, osd.61]
⑥ Primary = Acting Set 的第一个 = osd.25
⑦ 客户端直连 osd.25 写入
⑧ osd.25 用自己的 CRUSH map 副本算出 secondary（osd.32、osd.61），
通过 subops 复制，收集 Ack(4)/Ack(5)
⑨ osd.25 返回 Ack(6) 给客户端
验证一遍"客户端为什么不需要问任何人"：
- 客户端从 MON 拿到 cluster map（含 CRUSH map、OSD map 中的 pool 列表与 pool ID、PG 数量等）→ 知道了
pool "liverpool" = 4与pg_num。 - 客户端本地 hash + 取模 → 得到
4.58。全程无网络交互。 - 客户端本地跑 CRUSH → 得到
osd.25。全程无网络交互。 - 客户端才第一次真正发起数据 I/O：直连
osd.25。
💡 补充：这就是为什么 Ceph 客户端的 CPU 开销里有一部分是 CRUSH 计算，也是为什么"客户端持有过期的 cluster map"会导致读到旧位置/写错 OSD——Ceph 的做法是让 OSD 在收到请求时比对 epoch，发现客户端 map 过旧就回送更新，客户端重算重试。这个"乐观计算 + 版本校验 + 重试"的模式，是去中心化寻址的标准解法。
5.8 寻址链路中的注意事项
| 注意事项 | 说明 |
|---|---|
| 计算优于查询 | 原文：计算对象位置比通过一次 chatty session 查询对象位置快得多 |
| 客户端的 cluster map 可能过期 | 客户端只持有副本；epoch 变化时需要更新（属 OSD map 传播，见第六章） |
| Primary 是唯一写入口 | Primary 是给定 PG 中唯一接受客户端发起写操作的 OSD |
| 一个 pool 一套 CRUSH rule | 客户端写单个 pool，条带出来的对象同属该 pool，使用同一 CRUSH map 与访问控制 |
| PG 数量变化会改变取模结果 | pg_num 是第 ③ 步的除数，改变它会重新分配对象到 PG（这正是 PG 扩容要谨慎的原因） |
六、智能守护进程与分布式集群管理
6.1 核心思想：OSD 与客户端都是"集群感知"的
官方论述（「Smart Daemons Enable Hyperscale」）：
- 很多存储集群的特征是有一个中心化接口（centralized interface），它记录客户端被允许访问哪些节点。这类中心化架构通过**双次分发（double dispatch）**向客户端提供服务。在 PB 到 EB 规模上，这种双次分发是重大瓶颈。
- Ceph 消除了这个瓶颈：Ceph 的 OSD Daemon 与 Ceph Client 都是集群感知的（cluster-aware）。
- 像客户端一样，每个 Ceph OSD Daemon 都知道集群中其他 Ceph OSD Daemon。这使得 OSD 能直接与其他 OSD 交互、直接与 Monitor 交互。
- 因为客户端、monitor、OSD 三者彼此直接交互，OSD 守护进程可以利用集群节点的聚合 CPU 与 RAM 资源。这意味着 Ceph 集群可以轻松完成带中心接口的集群难以完成的任务。
6.2 四大收益（官方列举）
| # | 收益 | 机制 |
|---|---|---|
| 1 | OSDs Service Clients Directly | 网络设备只能支持有限数量的并发连接。因为客户端无需先连接中心接口就直接联系 OSD，Ceph 相对包含中心接口的存储冗余策略拥有更好的性能与更大的系统容量。客户端只在需要时保持会话，而且只与特定的 OSD 保持会话，而不是与中心接口保持 |
| 2 | OSD Membership and Status | 见 2.3.3：OSD 上报状态；up/down；邻居判定 + Monitor 兜底；MOSDBeacon（Luminous+）/ MPGStats（Luminous 前） |
| 3 | Data Scrubbing | 见 2.3.4：以 PG 为单位比对元数据；每日；深度 scrub 逐位比对校验和 |
| 4 | Replication | 见 2.3.5：客户端算 PG/primary，primary 用 subops 复制到 secondary 并 ack |
6.3 Cluster Map：分布式管理的"共享真相"
五张 map（官方定义，逐条）
| map | 内容（官方原文） | 查看命令 |
|---|---|---|
| Monitor Map | 集群 fsid、每个 monitor 的 position、name、address 与 TCP port；monitor map 还规定了当前 epoch、monitor map 的创建时间、以及最后一次修改的时间 |
ceph mon dump |
| OSD Map | 集群 fsid、OSD map 的创建时间、最后修改时间、pool 列表、副本 size 列表、PG 数量列表、以及 OSD 及其状态（例如 up、in）的列表 |
ceph osd dump |
| PG Map | PG version、其 time stamp、最近的 OSD map epoch、full ratios，以及每个 placement group 的细节。细节包括：PG ID、Up Set、Acting Set、PG 的状态（例如 active + clean）、以及每个 pool 的数据使用统计 |
—（文档未给出专门命令） |
| CRUSH Map | 存储设备列表、故障域层级（例如 device、host、rack、row、room）、以及存储数据时遍历该层级的规则 |
ceph osd getcrushmap -o {filename} 然后 crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename} |
| MDS Map | 当前 MDS map epoch、map 创建时间、最后变更时间；还包括存放元数据的 pool、metadata server 列表、以及哪些 metadata server 是 up 和 in |
ceph fs dump |
关键性质
- 每一张 map 都维护其运行状态变更的历史（Each map maintains a history of changes to its operating state）。
- Ceph Monitor 维护 cluster map 的主副本（master copy）。这份主副本包括：集群成员、集群状态、集群变更、以及记录 Ceph Storage Cluster 整体健康情况的信息。
术语表对 Cluster Map 的定义
Cluster Map = 由 monitor map、OSD map、PG map、MDS map 和 CRUSH map 组成的集合，共同报告 Ceph 集群的状态。
💡 补充（文档内部差异，值得注意）：
architecture.rst的 "Ceph Monitor" 相关表述与术语表的 "Ceph Monitor" 条目在列举 monitor 维护的 map时并不完全一致——术语表的 Ceph Monitor 条目说 cluster state 包括 monitor map、manager map、OSD map 和 CRUSH map（把 manager map 列入，未列 PG map 与 MDS map）；而architecture.rst与术语表的 Cluster Map 条目都明确是五张 map（monitor / OSD / PG / MDS / CRUSH）。本册以architecture.rst的"五张 map"为准，此差异已登记在文末「文档未明确项」。
6.4 集群映射如何传播（Propagation）
官方给出的传播环节（散见各节，本册归纳）：
| 环节 | 官方描述 |
|---|---|
| 客户端首次获取 | 客户端绑定到一个 Ceph Monitor，取得最新版本的 Cluster Map；必须先取得当前 cluster map 副本才能读写数据 |
| 客户端持有什么 | 取得 cluster map 副本后，客户端知道集群中所有的 monitor、OSD 与 metadata server，但不知道对象位置 |
| OSD 侧 | OSD 周期性地向 Monitor 发送消息（Luminous 前 MPGStats，Luminous 起 MOSDBeacon） |
| OSD 拉取更新 | 若 OSD 无法与集群 map 中定义的任何 OSD 完成 peering，它会每 30 秒 ping 一次 Monitor 索取最新的 cluster map 副本（osd mon heartbeat interval） |
| MON 侧兜底 | 若 OSD 未上报，Monitor 在 mon osd report timeout 超时后将其判定为 down |
| 一致性保证 | Monitor 之间用 Paxos 就集群状态达成一致，并要求多数派 |
💡 补充：Ceph 的映射传播是惰性 + 按需的，不是广播推送。这个设计决定了两类常见现象：(1) 集群拓扑刚变化时，部分客户端/OSD 可能短暂持有旧 epoch，需要一次"被拒 → 更新 → 重试"才能收敛；(2) 集群规模越大，map 更新传播到全部参与者的尾部延迟越长。这也解释了为什么文档反复强调 Monitor 要"轻量"——它只服务于少量控制面请求，而非每个 I/O。
6.5 librados：智能客户端的载体
- Ceph 客户端使用原生协议（native protocol）与 Ceph Storage Cluster 交互。Ceph 把这一功能打包进
librados库，因此你可以创建自己的 Ceph Client。 - 术语表 librados：一个 API，可用于创建到 Ceph 存储集群的自定义接口；
librados使得与 Ceph Monitor 和 OSD 交互成为可能。 - 原生协议提供直接、并行的对象访问能力（direct, parallel access to objects throughout the cluster），并具备异步通信能力（asynchronous communication capability）。
💡 补充：
librados之所以能叫"智能客户端"，是因为它把本该由中心组件承担的 CRUSH 计算、连接池管理、故障重试、OSD 会话维护全部下沉到了客户端库里。代价是客户端升级要与集群能力对齐（虽然协议有版本协商），收益是数据路径上没有任何中心瓶颈。
6.6 高可用认证：CephX
是什么
- CephX 是 Ceph 的认证协议，用于认证用户与守护进程，并防范中间人攻击（man-in-the-middle attacks）。
- 同时，CephX 提供一种机制来授予客户端使用 Ceph 服务的授权（authorizations）。这些授权被编码为 CephX Capabilities，由相应服务解释其赋予了客户端什么权限。
- 授权的形式是有时限的票据（time-limited tickets），必须由 Ceph 客户端周期性刷新。
重要边界（官方 note）
CephX 协议不处理传输中的数据加密（例如 SSL/TLS）或静态数据加密（encryption at rest）。
内部原理
共享密钥：CephX 使用共享密钥（shared secret keys）进行认证。这意味着客户端与 Monitor 各保存一份客户端密钥的副本。
与 Kerberos 的相似性（原文列举）：
| 特征 | CephX（官方描述） |
|---|---|
| 总体类比 | CephX 协议的运行方式类似于 Kerberos |
| 无单点 | 像 Kerberos 一样，每个 Monitor 都能独立认证用户并向客户端分发票据。因此使用 CephX 时不存在单点故障，也不存在瓶颈 |
| 票据内容 | 票据里包含：客户端身份（entity name）、客户端的全局标识符或 incarnation、票据创建时间与过期时间、以及客户端拥有的所有 capabilities（授权） |
| 密钥分发 | CephX 使用 rotating service keys，它们被安全地分发给每一类服务（例如 CephFS 的 MDS） |
| 票据数量 | 对每一类 Ceph 服务（AUTH、MON、MGR、OSD、MDS），客户端可能为每一个 rotating service key 收到一张票据（通常为 3 个） |
| 过期 | 像 Kerberos 票据一样，CephX 票据会过期。攻击者不能使用已偷偷获得的过期票据或会话密钥 |
安全性论证（原文）：这种认证形式可以阻止能够接触通信介质的攻击者以他人身份伪造消息，也能阻止攻击者篡改他人的合法消息——前提是该用户的密钥在过期前未被泄露。
密钥轮转（2026+ 的预期）：官方明确写到——预计在 2026 年以后的 Ceph 安装中，服务守护进程的密钥（例如 mgr.x）可能在守护进程被迁移甚至重启时轮转，这将成为常规操作。同样的机制可用于任何实体类型（包括客户端）。最后，当密码套件（ciphers）升级以提升安全性时，该机制还能用于实施密钥类型升级。
建立用户（官方示例）
- 要使用 CephX，管理员必须提前建立每一个 user/credential。
- 新装 Ceph 时通常创建的第一个 credential 是
client.adminkey，可用于管理集群。 - 下图中，
client.admin用户可从命令行调用ceph auth get-or-create-key来生成新实体与密钥。Ceph 的auth子系统生成用户名与密钥，在所有 Monitor 上保存一份副本，并把新实体的密钥返回给管理员。 - 官方 note：
client.admin用户必须以安全的方式把 user ID 与密钥提供给使用者。
创建用户（原图为创建用户流程示意图 .. ditaa::）：
+---------+ +---------+
| Client | | Monitor |
+---------+ +---------+
| request to |
| create a user |
|-------------->|----------+ create user
| | | and
|<--------------|<---------+ store key
| transmit key |
| |
认证与票据获取（官方逐步描述）
第一步：认证，取得 auth session key
- 客户端以实体名
client.username进行认证，把用户名传给 Monitor。 - Monitor 生成一个 auth session key，并用与
client.username关联的密钥对其加密。 - Monitor 把加密后的
auth票据传给客户端。 - 客户端用其 principal 的密钥解密载荷。
- 新建立的 auth session key 现在就代表了该用户的身份，并将在其 incarnation 期间持续有效。
第二步：请求服务票据，取得 service session key
- 客户端请求服务票据时，Monitor 用所请求服务类型的最新 rotating service secret 生成新票据。
- 每张票据内含一个全新的、仅供该票据使用的 service session key。
- 这个 service session key 被加密了两次：
- 一次用 auth session key 加密；
- 第二次在加密的服务票据内部（该票据只能被服务守护进程解密）。
- 这个新的 service session key 因此让客户端与服务守护进程在建立会话时能够互相认证（mutually authenticate）。
两步流程（原图为认证与票据获取示意图 .. ditaa::）：
+---------+ +---------+
| Client | | Monitor |
+---------+ +---------+
| authenticate |
|-------------->|----------+ generate and
| | | encrypt
|<--------------|<---------+ session key
| transmit |
| encrypted |
| session key |
| |
|-----+ decrypt |
| | session |
|<----+ key |
| |
| req. ticket |
|-------------->|----------+ generate and
| | | encrypt
|<--------------|<---------+ ticket
| recv. ticket |
| |
|-----+ decrypt |
| | ticket |
|<----+ |
会话期间的持续保护
- CephX 协议认证客户端与 Ceph 守护进程之间正在进行的通信。
- 初始认证之后，客户端与守护进程之间发送的每条消息都用一个票据签名，该票据可被 Monitor、OSD 与 metadata daemon 验证。
- 验证使用客户端与守护进程之间共享的密钥。
全流程（原图为 CephX 端到端认证示意图 .. ditaa::）：
+---------+ +---------+ +-------+ +-------+
| Client | | Monitor | | MDS | | OSD |
+---------+ +---------+ +-------+ +-------+
| request to | | |
| create a user | | |
|-------------->| mon and | |
|<--------------| client share | |
| receive | a secret. | |
| shared secret | | |
| |<------------>| |
| |<-------------+------------>|
| | mon, mds, | |
| authenticate | and osd | |
|-------------->| share | |
|<--------------| a secret | |
| session key | | |
| | | |
| req. ticket | | |
|-------------->| | |
|<--------------| | |
| recv. ticket | | |
| | | |
| make request (CephFS only) | |
|----------------------------->| |
|<-----------------------------| |
| receive response (CephFS only) |
| |
| make request |
|------------------------------------------->|
|<-------------------------------------------|
receive response
重要限制（官方明确）
这种认证只保护 Ceph 客户端与 Ceph 守护进程之间的连接。认证不延伸到 Ceph 客户端之外。 如果用户从远程主机访问 Ceph 客户端，CephX 认证不会应用到用户主机与客户端主机之间的连接上。
为什么 CephX 是"高可用认证"
官方把 CephX 放在「High Availability Authentication」标题下，理由在文中很清楚：
- Ceph 在客户端与 Ceph 对象存储之间没有任何中心化接口（引用「Scalability and High Availability」一节）。
- 但正因如此，客户端必须直接与 OSD 交互，而客户端与 OSD 的直接交互需要已认证的连接。
- CephX 认证系统建立并维持这些已认证连接。
- 又因为每个 Monitor 都能独立认证与发票据，所以 CephX 既无单点故障也无瓶颈。
与其他概念的关系
- CephX ← → MON：MON 是票据颁发者，并保存客户端密钥副本。
- CephX ← → OSD / MDS / MGR：它们是票据的验证方（服务方）。
- CephX ← → Capabilities：授权（authorization）与认证（authentication）是两个不同的关注点；官方另有一份 A Detailed Description of the CephX Authentication Protocol 专门讲这两者的区分。
- CephX ← → 加密：不覆盖传输加密与静态加密。
七、数据一致性、Scrubbing、纠删码与副本对比
7.1 数据一致性：为什么需要 scrub
根本问题：architecture.rst 说得很直白——Ceph 依赖商用硬件，硬件会静默损坏（bit rot / bad sectors）。副本机制能保证"数据不丢"，但不能保证"副本之间内容一致"，也不能发现硬盘上的坏块。
Ceph 的对策（官方两条）：
| 机制 | 做什么 | 频率 |
|---|---|---|
| Scrubbing（light / shallow） | OSD 把本地对象的元数据与其他 OSD 上副本的元数据做比较；以 PG 为单位；发现对象大小不匹配与元数据不匹配；确认对象存在且元数据正确 | 每日（daily） |
| Deep scrubbing | 逐位（bit-for-bit）比较对象内的数据与其校验和（checksums）；能发现轻度 scrub 检测不出的坏块/坏扇区 | 每周（weekly，by default performed weekly） |
Scrub 的完整过程（术语表）：
- Ceph 生成一个 PG 中所有对象的目录（catalog）；
- 把每个主对象（primary object）与存放在其它 OSD 上的副本做比较；
- 确保没有对象缺失或不匹配；
- 任何 PG 若被发现某个副本与其他副本不同，或对象整个缺失，该 PG 被标记为
inconsistent。
官方对 scrub 价值的定位：scrubbing 能捕获 OSD bug 或文件系统错误（often as a result of hardware issues）；deep scrubbing 能发现驱动器上轻度 scrub 时未显现的坏块。
相关 PG 状态（pg-states.rst）：
| 状态 | 含义 |
|---|---|
scrubbing |
Ceph 正在检查该 PG 的元数据以寻找不一致 |
deep |
Ceph 正在对照存储的校验和检查该 PG 的数据 |
inconsistent |
Ceph 检测到该 PG 中一个或多个对象副本存在不一致（例如对象大小错误、recovery 结束后某副本仍缺对象等） |
repair |
Ceph 正在检查该 PG 并修复它能修复的不一致 |
💡 补充：注意
inconsistent与degraded的区别——degraded是"副本数不够"（可用性问题，通常能自愈），inconsistent是"副本内容不一致"（正确性问题，Ceph 不会自动判定谁对，需要人工介入ceph pg repair）。这是运维上非常关键的区分。
7.2 Peering：一致性的协商阶段
定义：peering 是让存放某个 PG 的所有 OSD 就该 PG 中所有 RADOS 对象（及其元数据）的状态达成一致的过程。
关键性质：
- OSD 守护进程互相检查心跳并向 Monitor 上报，此外它们还会 peer。
- Ceph OSD 守护进程会向 Monitor 上报 Peering Failure。
- Peering 问题通常会自行解决；但如果问题持续存在，需要参考官方的 Troubleshooting Peering Failure 节。
- 重要 note：对集群状态达成一致的 PG，并不必然已经拥有最新数据（PGs that agree on the state of the cluster do not necessarily have the current data yet）。
副本数量基线（原文，含警告）：
| 配置 | 官方说法 |
|---|---|
size = 2 |
Ceph Storage Cluster 被设计为至少存储对象的两份副本（即 size = 2），这是数据安全的最低要求 |
size = 3 且 min size = 2 |
为了高可用，集群应存储多于两份副本，这样它可以在维持数据安全的同时以 degraded 状态继续运行 |
| 警告（warning） | 虽然这里说 R2（两副本复制）是数据安全的最低要求，但推荐使用 R3（三副本）。在足够长的时间线上，采用 R2 策略存储的数据将会丢失 |
Peering 相关概念（pg-concepts.rst）：
| 术语 | 定义 |
|---|---|
| Peering | 让存放某 PG 的所有 OSD 就该 PG 中所有对象（及其元数据）的状态达成一致的过程。注意：对状态达成一致并不意味着它们都拥有最新内容 |
| PG Info | 关于 PG 的创建 epoch、最近一次写入该 PG 的 version、last epoch started、last epoch clean、以及 current interval 起点的基本元数据。任何 OSD 间关于 PG 的通信都包含 PG Info，因此任何知道某 PG 存在（或曾经存在）的 OSD 也都拥有 last epoch clean / last epoch started 的下界 |
| PG Log | 该 PG 中对象的最近更新列表。当 Acting Set 中所有 OSD 都已确认到某一点之后，这些日志可以被截断 |
| Missing Set | 每个 OSD 记录更新日志条目，若这些条目意味着对象内容有更新，就把该对象加入一个"待更新"列表，该列表称为该 <OSD,PG> 的 Missing Set |
| Authoritative History | 一个完整的、完全有序的操作集合，若执行这些操作，就能把某 OSD 的 PG 副本更新到最新 |
| Last Epoch Start | Acting Set 中所有节点就 Authoritative History 达成一致的最后一个 epoch。此时认为 Peering 成功 |
| Last Epoch Clean | Acting Set 中所有节点完全最新（PG 日志与对象内容均如此）的最后一个 Epoch。此时认为 recovery 完成 |
| up_thru | 在 Primary 能成功完成 peering 之前，它必须通过一个存活的 monitor 在 OSD map 中设置自己的 up_thru，告知 monitor 自己存活到当前 OSD map epoch。这有助于 peering 忽略那些 peering 从未完成的先前 Acting Set |
up_thru 要处理的故障序列（官方示例）：
- acting set = [A,B]
- acting set = [A]
- acting set = [] 极短时间之后（例如同时故障，但检测有先后）
- acting set = [B] （B 重启，A 没有）
💡 补充：
Last Epoch Start（peering 成功）与Last Epoch Clean（recovery 完成）的区分，解释了为什么一个 PG 可以先变成active（能服务 I/O）再进入recovering——只要 peering 完成、Primary 确定，就可以开始接受写；数据补齐在后台进行。这正是官方说的"Once Peering has been performed, the Primary can start accepting write operations, and Recovery can proceed in the background"。
7.3 纠删码（Erasure Coding）
基本概念
- 一个纠删码池（erasure coded pool）把每个对象存储为
K+M个 chunk。 - 它被划分为 **
K个数据 chunk（data chunks）**与M个编码 chunk（coding chunks）。 - 该 pool 的
size被配置为K+M，这样每个 chunk 存放在 acting set 中的一个 OSD 上。 - chunk 的 rank（序号）作为对象的一个属性（attribute）存储。
举例（官方）
- 可以创建一个使用**五个 OSD（
K+M = 5）并能承受其中两个丢失（M = 2）**的纠删码池。 - 在
(K+1)个 shard 恢复之前，数据可能不可用（Data may be unavailable until (K+1) shards are restored）。
写入：编码过程（官方 NYAN 例子）
对象 NYAN，内容为 ABCDEFGHI，写入一个 K=3, M=2 的池：
- 纠删编码函数把内容切成三个数据 chunk，方法是简单地三等分内容：第一个含
ABC，第二个DEF，最后一个GHI。 - 如果内容长度不是
K的倍数，内容会被填充（padded）。 - 该函数再创建两个编码 chunk：第四个是
YXY，第五个是QGC。 - 每个 chunk 存放在 acting set 中的一个 OSD 上。
- 这些 chunk 存放在名字相同的对象（都叫 NYAN）中，但位于不同的 OSD 上。
- chunk 被创建的顺序必须被保留，它**作为对象的一个属性（
shard_t）**存储，此外还有对象的名字。 - 具体落位（官方示例）：chunk 1 含
ABC，存放在 OSD5；chunk 4 含YXY，存放在 OSD3。
编码示意（原图为纠删码编码示意图 .. ditaa::）：
+-------------------+
name | NYAN |
+-------------------+
content | ABCDEFGHI |
+--------+----------+
|
v
+------+------+
+---------------+ encode(3,2) +-----------+
| +--+--+---+---+ |
| | | | |
| +-------+ | +-----+ |
| | | | |
+--v---+ +--v---+ +--v---+ +--v---+ +--v---+
name | NYAN | | NYAN | | NYAN | | NYAN | | NYAN |
+------+ +------+ +------+ +------+ +------+
shard | 1 | | 2 | | 3 | | 4 | | 5 |
+------+ +------+ +------+ +------+ +------+
content | ABC | | DEF | | GHI | | YXY | | QGC |
+--+---+ +--+---+ +--+---+ +--+---+ +--+---+
| | | | |
v v v v v
+------+ +------+ +------+ +------+ +------+
| OSD5 | | OSD2 | | OSD1 | | OSD3 | | OSD4 |
+------+ +------+ +------+ +------+ +------+
（上表落位按官方文字描述绘制：chunk1→OSD5、chunk2→OSD2、chunk3→OSD1、chunk4→OSD3、chunk5→OSD4；原文图示中 OSD 与 chunk 的连线以源文 ditaa 图为准。）
读取：解码过程（官方 NYAN 例子）
- 解码函数读取三个 chunk：chunk 1（含
ABC）、chunk 3（含GHI）、chunk 4（含YXY）。 - 然后重建出对象的原始内容
ABCDEFGHI。 - 解码函数被告知 chunk 2 和 chunk 5 缺失（它们被称为 'erasures'）。
- chunk 5 读不到，因为 OSD4 处于 out（不在）状态。
- 只要读到三个 chunk，解码函数就可以被调用：OSD2 是最慢的，它的 chunk 未被计入。
解码示意（原图为纠删码解码示意图 .. ditaa::）：
+-------------------+
name | NYAN |
+-------------------+
content | ABCDEFGHI |
+---------+---------+
^
|
+-------+-------+
| decode(3,2) |
+------------->+ | erasures 2,5 | <-+
| +-------+-------+ |
| ^ |
+--+---+ +------+ +---+--+ +---+--+
name | NYAN | | NYAN | | NYAN | | NYAN |
+------+ +------+ +------+ +------+
shard | 1 | | 2 | | 3 | | 4 |
+------+ +------+ +------+ +------+
content | ABC | | DEF | | GHI | | YXY |
+--+---+ +--+---+ +--+---+ +--+---+
^ . ^ ^
| TOO . | |
| SLOW . +--+---+ |
| ^ | OSD1 | |
| | +------+ |
| +-------| OSD2 | |
| +------+ |
| +------+ |
| | OSD3 |--------+
| +------+
| +------+
| | OSD4 | OUT
| +------+
| +------+
+----------------| OSD5 |
+------+
中断的全量写（Interrupted Full Writes）
这是 EC 最微妙的正确性场景，官方用了大篇幅说明。
初始状态：一个 EC PG，K = 2, M = 1，由三个 OSD 支撑（两个给 K，一个给 M）。Acting Set 为 OSD 1、OSD 2、OSD 3。一个对象编码后：D1v1（数据 chunk 1，版本 1）在 OSD 1，D2v1 在 OSD 2，C1v1（编码 chunk 1，版本 1）在 OSD 3。每个 OSD 上的 PG 日志完全相同（即 epoch 1、version 1，记为 1,1）。
Primary OSD
+-------------+
| OSD 1 | +-------------+
| log | Write Full | |
| +----+ |<------------+ Ceph Client |
| |D1v1| 1,1 | v1 | |
| +----+ | +-------------+
+------+------+
|
| +-------------+
| | OSD 2 |
| | log |
+--------->+ +----+ |
| | |D2v1| 1,1 |
| | +----+ |
| +-------------+
|
| +-------------+
| | OSD 3 |
| | log |
+--------->| +----+ |
| |C1v1| 1,1 |
| +----+ |
+-------------+
写入 v2（WRITE FULL）：
- OSD 1 是 primary，收到客户端的 WRITE FULL，意思是载荷要整体替换对象，而不是覆盖其中一部分。
- 创建**版本 2（v2）**来覆盖版本 1（v1）。
- OSD 1 把载荷编码成三个 chunk：
D1v2在 OSD 1、D2v2在 OSD 2、C1v2在 OSD 3。 - 每个 chunk 都被发送到目标 OSD，包括 primary OSD 自己——primary 除了处理写操作、维护 PG 日志的权威版本之外，也负责存储 chunk。
- 当 OSD 收到写 chunk 的指令时，它同时在 PG 日志中新建一条记录。例如 OSD 3 一存下
C1v2，就往日志里加入条目1,2（epoch 1、version 2）。 - 因为 OSD 是异步工作的，某些 chunk 可能仍在传输中（例如
D2v2），而其它 chunk 已被确认并持久化到存储驱动器。
Primary OSD
+-------------+
| OSD 1 |
| log |
| +----+ | +-------------+
| |D1v2| 1,2 | Write Full | |
| +----+ +<------------+ Ceph Client |
| | v2 | |
| +----+ | +-------------+
| |D1v1| 1,1 |
| +----+ |
+------+------+
|
| +------+------+
| | OSD 2 |
| +------+ | log |
+->| D2v2 | | +----+ | <- D2v2 仍在传输中
| +------+ | |D2v1| 1,1 |
| | +----+ |
| +-------------+
|
| +-------------+
| | OSD 3 |
| | log |
| | +----+ |
| | |C1v2| 1,2 | <- 已持久化
+---------->+ +----+ |
| |
| +----+ |
| |C1v1| 1,1 |
| +----+ |
+-------------+
顺利收尾：如果一切顺利，chunk 在 acting set 的每个 OSD 上都被确认，日志的 last_complete 指针可以从 1,1 移动到 1,2；然后存放上一版本 chunk 的文件可以被删除（OSD 1 上的 D1v1、OSD 2 上的 D2v1、OSD 3 上的 C1v1）。
Primary OSD
+-------------+
| OSD 4 |
| log |
| +----+ |
| |D1v1| 1,1 | <- 由 decode 在 scrubbing 期间重建
| +----+ |
+------+------+
^
| +-------------+
| | OSD 2 |
+----------+ +----+ |
| | |D2v1| 1,1 |
| +-------------+
|
| +-------------+
| | OSD 3 |
+----------| +----+ |
| |C1v1| 1,1 |
+-------------+
+-------------+
| OSD 1 |
| (down) |
| c333 |
+-------------+
事故场景：如果 D2v2 仍在传输中时 OSD 1 宕机，则对象的版本 2 被部分写入：
- OSD 3 有一个 chunk，但不足以恢复。它丢了两个 chunk：
D1v2和D2v2；而纠删码参数K = 2、M = 1要求至少有两个 chunk 可用才能重建第三个。 - OSD 4 成为新的 primary，它发现
last_complete日志条目（即：该条目之前的所有对象在先前的 acting set 中所有 OSD 上都已知可用）是1,1，于是1,1将成为新的权威日志的头。 - OSD 3 上的日志条目
1,2与 OSD 4 提供的新权威日志分歧（divergent）：它被丢弃，包含C1v2chunk 的文件被删除。 D1v1chunk 在 scrubbing 期间用纠删码库的decode函数重建，并存放在新的 primary OSD 4 上。
| 阶段 | OSD 1 (primary) | OSD 2 | OSD 3 | OSD 4 |
|---|---|---|---|---|
| 初始 v1 | D1v1 log 1,1 |
D2v1 log 1,1 |
C1v1 log 1,1 |
— |
| 写 v2 中 | D1v2 log 1,2（后 down） |
D2v2 在途 |
C1v2 log 1,2 |
— |
| OSD 1 down 后 | (down) | D2v1 log 1,1 |
C1v2 被判定分歧 → 删除；回退到 C1v1 |
新 primary；权威日志头 = 1,1 |
| scrub 后 | (down) | D2v1 |
C1v1 |
D1v1（decode 重建） |
💡 补充：这个例子揭示了 EC 池不支持"部分覆盖写"的原子性保证——一旦写入过程中 primary 挂掉且数据不足以重建，系统回退到上一个
last_complete版本，而不是"猜"一个结果。这正是为什么 EC 池对allow_ec_overwrites、对 RBD/RGW/CephFS 的使用方式有额外限制（详见纠删码分册）。同时注意原文的K=2, M=1只能容忍 1 个 chunk 丢失，而丢失 2 个就无法重建——这与前面"K+M=5、M=2 可承受 2 个丢失"的规则一致：可容忍丢失数 = M。
7.4 副本 vs 纠删码：对比
| 维度 | 副本（Replicated） | 纠删码（Erasure Coded） |
|---|---|---|
| 存储开销 | size 份完整数据（R3 = 3x） |
K+M 份分片，开销 (K+M)/K（3+2 = 1.67x） |
pool 的 size 语义 |
size = 副本数 |
size = K+M；官方特别说明：EC 池会"报告"一个等于 K+M 的 size，但该值不能被直接 set |
| 容忍丢失 | R3 可容忍 size-1 份丢失（仍可读）；可服务的最小副本由 min_size 控制 |
可容忍 M 个 chunk 丢失 |
| 读取路径 | 直接从 primary（或副本）读 | 需要至少 K 个 chunk；官方示例：读到 K 个即可解码，慢的那个（OSD2）不纳入考虑 |
| 写入路径 | primary 复制整对象到 secondary | primary 负责把载荷编码成 K+M 个 chunk 并发送给其它 OSD；primary 也存储 chunk、并维护 PG 日志的权威版本 |
| 部分写 / 覆盖写 | 天然支持 | 受限制；中断的全量写需要靠 last_complete 日志回退（见 7.3） |
| omap（object map） | 支持 | 术语表明确：纠删码池不能存储 RADOS omap 数据结构 |
| 恢复期可用性 | 剩 1 份完整副本即可读 | 官方：在 (K+1) 个 shard 恢复之前，数据可能不可用 |
| 恢复成本 | 拷贝整对象 | 需要 decode 重建（可能要读 K 个 chunk 才能重建 1 个） |
| 适用场景（官方未直接给出，💡 补充） | 热数据、小块随机写、需要 omap（如 RGW bucket index）、RBD | 冷/温数据、大对象顺序写、归档 |
💡 补充：术语表中那句"Erasure-coded pools cannot store RADOS omap data structures"是选型的硬约束——因为 RGW 的 bucket index 就是存成 omap 的，所以 RGW 的 index / 元数据池不能用 EC 池，只有 data 池可以用 EC。这是生产上最常见的 EC 落地形态（元数据池副本、数据池 EC）。
7.5 一致性机制小结
| 层次 | 机制 | 保证什么 |
|---|---|---|
| 写路径 | primary 串行化 + subops 复制到 secondary + ack |
副本被写入并被确认 |
| PG 内协商 | peering + PG Log + Authoritative History + up_thru |
各副本对"发生了哪些操作"达成一致 |
| 状态推进 | last_epoch_start（peering 成功）→ last_epoch_clean（recovery 完成） |
区分"可以开始服务"与"数据已完全补齐" |
| 数据完整性 | light scrub（每日） + deep scrub（每周） | 发现静默损坏、对象缺失、大小/元数据不一致 |
| 故障恢复 | recovery / backfill（见第八章） | 把副本补回期望份数 |
| 认证 | CephX | 防止伪造/篡改消息（但不提供加密） |
引自：Architecture、Glossary、Placement Group Concepts、Placement Group States
八、高可用与故障恢复
8.1 故障检测：三层机制
① OSD ↔ OSD 心跳（peer 检测，主力）
OSD 以 <6s 的随机间隔检查邻居心跳；20s 宽限期内无心跳 → 判定邻居 down
│
v
② OSD → MON 上报（down 报告 + 状态报告）
默认需要来自不同 host 的 2 个 OSD 报告，MON 才确认某 OSD down
│
v
③ MON 兜底（beacon 超时）
OSD 周期性发 MOSDBeacon；mon osd report timeout 超时 → MON 标记 OSD down
① OSD 检查心跳（OSDs Check Heartbeats）
- 每个 OSD 守护进程**以随机间隔（小于每 6 秒）**检查其他 OSD 的心跳。
- 如果邻居 OSD 在 20 秒宽限期内未显示心跳，该 OSD 可以认为邻居
down并上报给 Monitor，Monitor 随之更新 Cluster Map。 - 可用
osd heartbeat grace修改（[mon]与[osd]或[global]段，或运行时设置）。
② OSD 上报 down 的 OSD（OSDs Report Down OSDs）
- 默认情况下，必须有来自不同 host 的两个 OSD 向 Monitor 报告某个 OSD
down，Monitor 才会确认。 - 为什么需要两个：官方解释——有可能所有上报故障的 OSD 都位于一个带有故障交换机的 rack 中，该交换机与另一个 OSD 的连接有问题。为避免这类误报，我们把上报故障的 peer 视为整体集群中一个潜在"子集群（subcluster）"的代理，这个子集群同样滞后（laggy）。官方坦承"这显然并非在所有情况下都成立，但有时能帮助我们把这个宽限修正定位到系统中出问题的子集上"。
mon osd reporter subtree level用于按 peer 在 CRUSH map 中的共同祖先类型把它们分组为"subcluster"。- 默认情况下，只需要来自不同 subtree 的两份报告即可上报某个 OSD
down。 - 可用
mon osd min down reporters与mon osd reporter subtree level修改（[mon]段或运行时）。
③ OSD 上报自身状态（OSDs Report Their Status）
- 若 OSD 未向 Monitor 上报，Monitor 在
mon osd report timeout超时后会认为该 OSDdown。 - OSD 在可上报事件发生时会上报：例如故障、PG stats 变化、
up_thru变化、或启动时（5 秒内）。可用osd mon report interval修改。 - 无论是否有显著变化，OSD 每 120 秒上报一次。可用
osd mon report interval max修改。
④ Peering 失败时的 map 拉取
- 若 OSD 无法与配置/集群 map 中定义的任何 OSD 完成 peering，它会每 30 秒 ping Monitor 索取最新的集群 map 副本。可用
osd mon heartbeat interval修改（[osd]段）。
心跳数值速查表
| 项目 | 默认值 | 可调参数 |
|---|---|---|
| OSD 间心跳检查间隔 | < 6 秒（随机） | — |
| 邻居无心跳宽限期 | 20 秒 | osd heartbeat grace |
| 确认 OSD down 所需上报者 | 来自不同 host 的 2 个 OSD（默认只需来自不同 subtree 的 2 份报告） | mon osd min down reporters、mon osd reporter subtree level |
| peering 失败后拉取 map 间隔 | 30 秒 | osd mon heartbeat interval |
| 可上报事件后上报时限 | 5 秒 | osd mon report interval |
| 无条件上报周期 | 120 秒 | osd mon report interval max |
| MON 判定 OSD down | mon osd report timeout 超时 |
mon osd report timeout |
💡 补充：官方文档特意提醒——修改心跳设置时应把它们放在配置文件的
[global]段。这是因为心跳参数在 mon 与 osd 两侧都会被读取，放在单侧会导致行为不一致。
8.2 OSD 状态与集群可用性
| 状态组合 | 含义（官方） |
|---|---|
up |
OSD 守护进程正在运行且能够服务 Ceph Client 请求 |
down |
守护进程未运行/不能服务 |
down 且 in |
可能指示该 OSD 守护进程发生了故障 |
| flapping OSD | 被反复、快速地交替标记为 up 和 down 的 OSD（术语表） |
相关配置项（mon-osd-interaction.rst 的 Monitor Settings 列表）：mon_osd_min_up_ratio、mon_osd_min_in_ratio、mon_osd_laggy_halflife、mon_osd_laggy_weight、mon_osd_laggy_max_interval、mon_osd_adjust_heartbeat_grace、mon_osd_adjust_down_out_interval、mon_osd_auto_mark_in、mon_osd_auto_mark_auto_out_in、mon_osd_auto_mark_new_in、mon_osd_down_out_interval、mon_osd_down_out_subtree_limit。
💡 补充：架构页没有展开
down→out的转换（由mon_osd_down_out_interval控制，默认在其它分册给出）。本册只登记参数名，不给出默认值（架构页与本节引用的页面未给出具体默认秒数）。这是本册「不编造」原则的要求——具体数值请查阅运维/配置分册。
8.3 Recovery 与 Backfill
Recovery（pg-concepts.rst）：
确保某个 PG 中所有对象的副本都存在于 Acting Set 的所有 OSD 上。一旦 Peering 完成，Primary 就可以开始接受写操作，而 Recovery 可以在后台进行。
Backfill（pg-states.rst）：
Ceph 扫描并同步一个 PG 的全部内容**，而不是从最近操作的日志中推断需要同步哪些内容。Backfill 是 recovery 的一个特例（Backfill is a special case of recovery）。**
两者的对比（💡 补充归纳，基于上述官方定义）：
| 维度 | Recovery | Backfill |
|---|---|---|
| 依据 | PG Log / Missing Set（能推断出缺哪些对象） | 扫描 PG 的全部内容 |
| 触发 | 短暂离线后回到 acting set（日志还在） | 日志不足以推断（例如新加入的 OSD、PG 整体迁移） |
| 代价 | 只补缺失对象 | 全量比对，代价更高 |
| 关系 | — | 是 recovery 的特例 |
相关的 PG 状态（pg-states.rst）：
| 状态 | 含义 |
|---|---|
recovering |
Ceph 正在迁移/同步对象及其副本 |
forced_recovery |
用户强制该 PG 的高恢复优先级 |
recovery_wait |
该 PG 排队等待开始 recover |
recovery_toofull |
恢复操作等待中，因为目标 OSD 超过了它的 full ratio |
recovery_unfound |
由于 unfound objects，恢复停止 |
backfilling |
Ceph 正在扫描并同步一个 PG 的全部内容 |
forced_backfill |
用户强制该 PG 的高 backfill 优先级 |
backfill_wait |
该 PG 排队等待开始 backfill |
backfill_toofull |
backfill 等待中，因为目标 OSD 超过了 backfillfull ratio |
backfill_unfound |
由于 unfound objects，backfill 停止 |
8.4 PG 状态机（完整清单，引自 pg-states.rst）
官方说明：检查集群状态时，一个 PG 会有一个或多个状态；placement group map 中 PG 的最优状态是 active + clean。
| 状态 | 官方含义 |
|---|---|
creating |
Ceph 仍在创建该 PG |
activating |
该 PG 已 peered 但尚未 active |
active |
Ceph 会处理对该 PG 的请求 |
clean |
Ceph 已把该 PG 中所有对象按正确的份数完成复制 |
down |
一个持有必要数据的副本处于 down，因此该 PG 离线 |
laggy |
某个副本未及时确认来自 primary 的新 lease；IO 被临时暂停 |
wait |
该 PG 的 OSD 集合刚发生变化，IO 被临时暂停，直到前一 interval 的 lease 过期 |
scrubbing |
Ceph 正在检查该 PG 的元数据以寻找不一致 |
deep |
Ceph 正在对照存储的校验和检查该 PG 的数据 |
degraded |
Ceph 尚未把该 PG 中某些对象复制到正确份数 |
inconsistent |
Ceph 检测到该 PG 中一个或多个对象副本存在不一致（例如对象大小错误、recovery 结束后某副本仍缺对象等） |
peering |
该 PG 正在进行 peering 过程 |
repair |
Ceph 正在检查该 PG 并修复发现的（可能的）不一致 |
recovering |
Ceph 正在迁移/同步对象及其副本 |
forced_recovery |
用户强制高恢复优先级 |
recovery_wait |
排队等待开始 recover |
recovery_toofull |
恢复等待中，目标 OSD 超过 full ratio |
recovery_unfound |
因 unfound objects 恢复停止 |
backfilling |
扫描并同步整个 PG 内容（recovery 的特例） |
forced_backfill |
用户强制高 backfill 优先级 |
backfill_wait |
排队等待开始 backfill |
backfill_toofull |
目标 OSD 超过 backfillfull ratio |
backfill_unfound |
因 unfound objects backfill 停止 |
incomplete |
Ceph 检测到某 PG 缺失关于"可能已发生的写"的信息，或没有任何健康副本。若看到此状态，尝试启动任何可能含有所需信息的失败 OSD。在纠删码池的情况下，临时降低 min_size 可能允许恢复 |
stale |
该 PG 处于未知状态——自从该 PG 的映射发生变化后，monitor 一直没有收到关于它的更新 |
remapped |
该 PG 被临时映射到一组与 CRUSH 指定的不同的 OSD |
undersized |
该 PG 的副本数少于配置的 pool 复制级别 |
peered |
该 PG 已 peered，但由于副本数不足以达到 pool 配置的 min_size，无法服务客户端 IO。此状态下可能发生 recovery，PG 有可能最终恢复到 min_size |
snaptrim |
正在裁剪快照（Trimming snaps） |
snaptrim_wait |
排队等待裁剪快照 |
snaptrim_error |
裁剪快照出错而停止 |
unknown |
自 mgr 启动以来，ceph-mgr 尚未从任何 OSD 收到关于该 PG 状态的信息 |
💡 补充：
stale与incomplete是最容易混淆的两个状态，也是本册范围内最值得记住的两个：
stale= 不知道（信息过期）：monitor 在 PG 映射变化后没收到更新。常见诱因是所有持有该 PG 的 OSD 都不可达或 monitor 自身问题。它说的是"我（MON）没有最新消息"。incomplete= 知道了，但不完整：Ceph 明确知道"缺少可能已发生的写的信息"或"没有健康副本"。它说的是"数据可能已经不全了"，处理方式是先去救 OSD（而不是直接放弃）。 处理路径也因此不同：stale先排查 OSD 可达性 / monitor；incomplete先尝试拉起失败的 OSD，EC 池可考虑临时调低min_size（官方明确给出的建议）。
8.5 故障恢复的典型流程（综合官方描述）
OSD 故障
│
├─ 邻居 OSD 在 20s 宽限期内未收到心跳 → 判定 down
├─ 需来自不同 host/subtree 的 2 个 OSD 上报 → MON 确认 down
└─ （兜底）OSD beacon 超时（mon osd report timeout）→ MON 标记 down
│
v
MON 更新 OSD Map（epoch 递增）
│
v
PG 的 Acting Set 变化（原 primary 被移出 Up Set，secondary 成为 primary）
│ 例：Acting Set [osd.25, osd.32, osd.61] → osd.25 失败
│ → osd.32 成为 primary，osd.25 移出 Up Set
v
Peering（新 primary 编排；需 MON 设置 up_thru）
│ 成功 → last_epoch_start；PG 可进入 active
v
Recovery / Backfill（后台）
│ 依据 PG Log / Missing Set（recovery）或全量扫描（backfill）
v
last_epoch_clean → PG 回到 active + clean
│
v
（EC 池特例）若版本不完整：以 last_complete 为新权威日志，丢弃分歧日志，
缺失 chunk 在 scrubbing 期间用 decode 重建
8.6 高可用的其他支柱
| 支柱 | 机制 | 官方要点 |
|---|---|---|
| MON 高可用 | monitor 集群 + Paxos + 多数派 | 至少 3 个 monitor 才能既冗余又高可用；Quorum = 多数 monitor up |
| MGR 高可用 | active / standby + beacon | 最先启动者为 active，其余 standby；不需要 quorum；beacon 超时（mon_mgr_beacon_grace）则被 standby 取代；可用 ceph mgr fail 抢占切换 |
| MDS 高可用 | active / standby 实例 |
额外实例为 standby，可接管任何失败的 active；因为所有数据（含 journal）都在 RADOS 上，所以这很容易；切换由 ceph-mon 自动触发 |
| 数据高可用 | 副本 / EC + CRUSH 故障域 | 推荐 R3（size = 3、min size = 2）；R2 在足够长的时间线上必然丢数据 |
| 连接高可用 | CephX | 每个 MON 都能独立认证与发票据，无单点故障、无瓶颈 |
引自：Architecture、Configuring Monitor/OSD Interaction、Placement Group States、Placement Group Concepts、ceph-mgr administrator's guide
九、扩展性与性能特性
9.1 数据条带化（Data Striping）
为什么需要
存储设备存在吞吐限制，这会影响性能与可扩展性。 因此存储系统通常支持 striping——把顺序的信息片段存放到多个存储设备上——以提升吞吐与性能。最常见的条带化来自 RAID；与 Ceph 条带化最相似的 RAID 类型是 RAID 0（即 'striped volume'）。
官方对 Ceph 条带化的定位：Ceph 的条带化提供了 RAID 0 条带化的吞吐、n 路 RAID 镜像（mirroring）的可靠性，以及更快的恢复。
关键前提（官方 tip，非常重要）
Ceph 存放在 Ceph Storage Cluster 中的对象本身不是条带化的（are not striped）。 是 Ceph Object Storage、Ceph Block Device 和 Ceph File System 把它们的数据条带化到多个 Ceph Storage Cluster 对象上。而直接通过
librados写入存储集群的客户端，必须自己完成条带化（以及并行 I/O），才能获得这些收益。
最简单的条带化（stripe count = 1 object）
客户端把 stripe unit 写到一个对象中，直到该对象达到最大容量，然后创建另一个对象继续写入。官方说：这种简单形式对小型块设备镜像、S3 或 Swift 对象、以及 CephFS 文件可能已经足够。但它没有最大化利用 Ceph 把数据分布到多个 PG 的能力，因而对性能提升有限。
（原图为最简单的条带化示意图 .. ditaa::）
+---------------+
| Client Data |
| Format |
| cCCC |
+---------------+
|
+--------+-------+
| |
v v
/-----------\ /-----------\
| Begin cCCC| | Begin cCCC|
| Object 0 | | Object 1 |
+-----------+ +-----------+
| stripe | | stripe |
| unit 1 | | unit 5 |
+-----------+ +-----------+
| stripe | | stripe |
| unit 2 | | unit 6 |
+-----------+ +-----------+
| stripe | | stripe |
| unit 3 | | unit 7 |
+-----------+ +-----------+
| stripe | | stripe |
| unit 4 | | unit 8 |
+-----------+ +-----------+
| End cCCC | | End cCCC |
| Object 0 | | Object 1 |
\-----------/ \-----------/
跨对象集（object set）的条带化
适用场景：官方说，如果你预期会有很大的镜像、很大的 S3/Swift 对象（例如视频）、或很大的 CephFS 目录，把客户端数据条带化到一个 object set 中的多个对象上，可能会带来可观的读写性能提升。
为什么快（官方论证）：
- 当客户端把 stripe unit 并行写入各自对应的对象时，会出现显著的写性能提升。
- 因为对象被映射到不同的 PG，进而映射到不同的 OSD，每次写入都以最大写速度并行发生。
- 写入单个驱动器会受限于磁头移动（例如每次寻道 6ms）和该设备的带宽（例如 100MB/s）。
- 通过把写入分散到多个对象（它们映射到不同 PG 与 OSD），Ceph 可以减少每块驱动器的寻道次数，并合并多个驱动器的吞吐，从而实现快得多的写（或读）速度。
object set 的推进规则：客户端把 stripe unit 依次写入由 stripe count 决定的一系列对象，这一系列对象称为 object set。写到 object set 中最后一个对象之后，客户端回到该 object set 的第一个对象。若 object set 已满，则创建一个新的 object set。
（原图为跨 object set 的条带化示意图 .. ditaa::）
+---------------+
| Client Data |
| Format |
| cCCC |
+---------------+
|
+-----------------+--------+--------+-----------------+
v v v v
/-----------\ /-----------\ /-----------\ /-----------\
| Begin cCCC| | Begin cCCC| | Begin cCCC| | Begin cCCC|
| Object 0 | | Object 1 | | Object 2 | | Object 3 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 0 | | unit 1 | | unit 2 | | unit 3 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 4 | | unit 5 | | unit 6 | | unit 7 | Object
+-----------+ +-----------+ +-----------+ +-----------+ Set 1
| stripe | | stripe | | stripe | | stripe |
| unit 8 | | unit 9 | | unit 10 | | unit 11 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 12 | | unit 13 | | unit 14 | | unit 15 |
+-----------+ +-----------+ +-----------+ +-----------+
| End cCCC | | End cCCC | | End cCCC | | End cCCC |
| Object 0 | | Object 1 | | Object 2 | | Object 3 |
\-----------/ \-----------/ \-----------/ \-----------/
/-----------\ /-----------\ /-----------\ /-----------\
| Begin cCCC| | Begin cCCC| | Begin cCCC| | Begin cCCC|
| Object 4 | | Object 5 | | Object 6 | | Object 7 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 16 | | unit 17 | | unit 18 | | unit 19 |
+-----------+ +-----------+ +-----------+ +-----------+ Object
| stripe | | stripe | | stripe | | stripe | Set 2
| unit 20 | | unit 21 | | unit 22 | | unit 23 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 24 | | unit 25 | | unit 26 | | unit 27 |
+-----------+ +-----------+ +-----------+ +-----------+
| stripe | | stripe | | stripe | | stripe |
| unit 28 | | unit 29 | | unit 30 | | unit 31 |
+-----------+ +-----------+ +-----------+ +-----------+
| End cCCC | | End cCCC | | End cCCC | | End cCCC |
| Object 4 | | Object 5 | | Object 6 | | Object 7 |
\-----------/ \-----------/ \-----------/ \-----------/
三个决定条带化的变量（官方定义）
| 变量 | 官方定义 | 官方建议 |
|---|---|---|
| Object Size | Ceph Storage Cluster 中的对象有可配置的最大尺寸（例如 2MB、4MB 等） | 对象大小应足够大以容纳许多 stripe unit，并且应为 stripe unit 的倍数 |
| Stripe Width | stripe 有可配置的 unit 大小（例如 64kb）。客户端把要写入对象的数据划分成等大的 stripe unit，最后一个除外 | stripe width 应为 Object Size 的一个分数（fraction），这样一个对象可以包含许多 stripe unit |
| Stripe Count | 客户端把一串 stripe unit 写入由 stripe count 决定的一系列对象，这一系列对象称为 object set。写到最后一个对象后，回到第一个对象 | — |
注意事项（官方 important / note）
- 重要（important）：在把集群投入生产之前，先测试你的条带化配置的性能。一旦你把数据条带化并写入对象之后，就【不能】再更改这些条带化参数了。
- 注意（note）：条带化独立于对象副本。因为 CRUSH 会跨 OSD 复制对象，所以 stripe 会被自动复制。
- 注意（note）：因为客户端只写单个 pool，所以所有条带化出来的对象都被映射到同一个 pool 中的 PG，因此它们使用同一个 CRUSH map 与相同的访问控制。
💡 补充："条带化参数不可更改"这条限制的实际含义是：条带化参数（object size / stripe unit / stripe count）是"数据布局格式"的一部分，改了就等于改变了已有数据的解释方式。所以在 Ceph 里调整这些参数的正确做法是——新建一个不同参数的 pool/image，把数据迁移过去，而不是原地改。这与"PG 数量可以改但代价大"是不同量级的问题。
9.2 缓存分层（Cache Tiering）
官方状态（重要）
注意：Cache tiering 在 Reef 版本中已被弃用（deprecated）。 并且官方在末尾补充：Cache Tiers 可能很棘手（can be tricky），现在已不鼓励使用它们。
本册完整记录其设计，但读者应以"已弃用、不鼓励使用"为前提看待。
是什么
- 缓存层（cache tier）为 Ceph 客户端提供对"存放在后备存储层中的一部分数据"的更好 I/O 性能。
- 做法是：创建一个由相对快速/昂贵存储设备（例如固态硬盘）组成的 pool 作为 cache tier，以及一个后备 pool（可以是纠删码的，或由相对较慢/便宜的设备组成）作为经济的存储层。
- Ceph objecter 决定把对象放在哪里，分层代理（tiering agent）决定何时把对象从缓存刷（flush）到后备存储层。
- 因此，缓存层与后备存储层对 Ceph 客户端是完全透明的。
（原图为缓存分层示意图 .. ditaa::）
+-------------+
| Ceph Client |
+------+------+
^
Tiering is |
Transparent | Faster I/O
to Ceph | +---------------+
Client Ops | | |
| +----->+ Cache Tier |
| | | |
| | +-----+---+-----+
| | | ^
v v | | Active Data in Cache Tier
+------+----+--+ | |
| Objecter | | |
+-----------+--+ | |
^ | | Inactive Data in Storage Tier
| v |
| +-----+---+-----+
| | |
+----->| Storage Tier |
| |
+---------------+
Slower I/O
9.3 快照与写时复制克隆（Snapshots and Copy-on-write Cloning）
architecture.rst 在列出 librados 原生协议能力时，明确包含：
- Snapshots and Copy-on-write Cloning（快照与写时复制克隆）
以及在客户端章节对 RBD 的描述：Ceph Block Device 提供可调整大小（resizable）、精简置备（thin-provisioned）、可快照（snapshotted）与可克隆（cloned）的块设备。
PG 状态中也有快照相关状态（pg-states.rst）：
| 状态 | 含义 |
|---|---|
snaptrim |
正在裁剪快照 |
snaptrim_wait |
排队等待裁剪快照 |
snaptrim_error |
裁剪快照时出错停止 |
💡 补充：写时复制（copy-on-write）是 Ceph 快照的底层机制——创建快照时不复制数据，只记录"这些对象当前版本被这个快照引用"；此后对对象的写入产生新版本，旧版本由快照保留。这解释了两个运维现象：(1) 快照创建本身极快，但删除快照会触发
snaptrim（因为要清理不再被引用的旧版本）；(2) 长期保留大量快照会持续占用空间并放大写放大。
9.4 扩展 Ceph：Ceph Classes（对象类）
是什么
- 你可以通过创建共享对象类（shared object classes）——称为 'Ceph Classes'——来扩展 Ceph。
- Ceph 动态加载存放在
osd class dir目录中的.so类（默认为$libdir/rados-classes）。 - 实现一个类时，你可以创建新的对象方法，这些方法能够调用 Ceph Object Store 的原生方法，或你通过库引入、或自己创建的其它类方法。
读写两侧
| 方向 | 能力（官方） |
|---|---|
| 写（On writes） | Ceph Classes 可以调用原生或类方法，对入站数据执行任意一系列操作，并生成一个结果性的写事务（write transaction），由 Ceph 原子地应用（applied atomically） |
| 读（On reads） | Ceph Classes 可以调用原生或类方法，对出站数据执行任意一系列操作，并把数据返回给客户端 |
💡 补充："原子地应用"是 Ceph Classes 最有价值的一点——它把"读-改-写"这一整段逻辑下推到 OSD 侧并在单个事务内完成，从而避免了客户端侧的多次往返与并发竞争。本质上这是**存储端计算（computation near storage）**的一种实现。
官方示例（topic）
一个用于内容管理系统的 Ceph class，呈现特定尺寸与宽高比的图片：它可以接收一张入站位图，裁剪到特定宽高比，调整尺寸，并嵌入不可见的版权或水印以帮助保护知识产权；然后把结果位图保存到对象存储中。
参考实现
官方指向：src/objclass/objclass.h、src/fooclass.cc、src/barclass。
9.5 Object Watch/Notify（对象作为同步通道）
是什么
- 客户端可以对一个对象注册一个持久的兴趣（persistent interest），并保持与 primary OSD 的会话打开。
- 客户端可以向所有 watcher 发送一条通知消息（notification message）与载荷（payload），并在 watchers 收到通知时收到通知。
- 这使得客户端可以把任何对象当作同步/通信通道（synchronization/communication channel）。
交互流程
（原图为 Object Watch/Notify 交互示意图 .. ditaa::）
+----------+ +----------+ +----------+ +---------------+
| Client 1 | | Client 2 | | Client 3 | | OSD:Object ID |
+----------+ +----------+ +----------+ +---------------+
| | | |
| Watch Object | | |
|--------------------------------------------------->|
| Ack/Commit |
|<---------------------------------------------------|
| | Watch Object |
| |---------------------------------->|
| | Ack/Commit |
| |<----------------------------------|
| | | Watch Object |
| | |----------------->|
| | | Ack/Commit |
| |<-----------------------------------|
| Notify | | |
|--------------------------------------------------->|
| Notify | | |
|--------------------------------------------------->|
| | Notify | |
| |---------------------------------->|
| | | Notify |
| | |----------------->|
| Ack | | |
|--------------------------------------------------->|
| | Ack | |
| |---------------------------------->|
| | | Ack |
| | |----------------->|
|<---------------+----------------+------------------|
| Complete
💡 补充：Watch/Notify 是 Ceph 提供的轻量级分布式协调原语，常用于：多客户端之间的配置/锁同步（例如 RBD exclusive-lock 场景下的通知）、缓存失效广播、集群内事件通知。它的关键优势是复用已有的对象存储与 OSD 会话，不需要额外部署 ZooKeeper/etcd 之类的协调服务；局限是通知的可靠性语义由客户端协议保证（watcher 掉线后 watch 会随会话过期），不适合作为强一致的分布式锁的唯一依据。
9.6 扩展性特性的横向对比
| 特性 | 解决什么问题 | 作用位置 | 官方状态 |
|---|---|---|---|
| 条带化 | 单设备吞吐上限 | 客户端侧（RBD/RGW/CephFS），或 librados 用户自行实现 |
推荐（但参数不可改） |
| CRUSH 权重 / weight set | 数据分布不均 | CRUSH map | 推荐 |
| Balancer | 自动优化 PG 跨设备分布 | 集群（data-placement.rst 列出的四大概念之一） |
推荐 |
| 缓存分层 | 热数据 I/O 性能 | pool 之间（cache tier + storage tier） | Reef 起已弃用，不鼓励使用 |
| 快照 / COW 克隆 | 时间点副本与快速克隆 | librados 原生能力 |
支持 |
| Ceph Classes | 把计算下推到 OSD | OSD 侧 .so 插件 |
支持 |
| Watch/Notify | 客户端间同步/通信 | 对象 + primary OSD | 支持 |
| Crimson | 跨核通信延迟与锁竞争 | 下一代 OSD 架构 | 术语表登记 |
| 多 active MDS | CephFS 元数据扩展性 | MDS 目录子树分片 | 支持 |
💡 补充：关于 Balancer——
data-placement.rst把它列为数据放置规划的四大概念之一，官方定义是：自动优化 PG 在设备间的分布，以达成均衡的数据分布、最大化集群可存储的数据量、并在 OSD 之间均匀分摊工作负载。它是对"CRUSH 概率性分布必然有偏差"这一事实的运行时补偿，与 weight set（静态优化）形成互补。
引自：Architecture、Data Placement Overview、Placement Group States
十、Ceph 协议与接口层
10.1 Ceph Protocol 与 librados
定位
- Ceph 客户端使用原生协议（native protocol）与 Ceph Storage Cluster 交互。
- Ceph 把这一功能打包进
librados库，因此你可以创建自己的 Ceph Client。
（原图为 Ceph 协议基本架构示意图 .. ditaa::）
+---------------------------------+
| Ceph Storage Cluster Protocol |
| (librados) |
+---------------------------------+
+---------------+ +---------------+
| OSDs | | Monitors |
+---------------+ +---------------+
设计动机
官方原话：现代应用需要一个带有异步通信能力的简单对象存储接口。 Ceph Storage Cluster 提供的正是这样一个接口。该接口提供对整个集群中对象的直接、并行访问（direct, parallel access）。
librados 原生接口的能力清单（官方逐条）
| 能力 | 细分 |
|---|---|
| Pool Operations | 池操作 |
| Snapshots and Copy-on-write Cloning | 快照与写时复制克隆 |
| Read/Write Objects | Create or Remove；Entire Object or Byte Range（整对象或字节范围）；Append or Truncate |
| Create/Set/Get/Remove XATTRs | 扩展属性 |
| Create/Set/Get/Remove Key/Value Pairs | 键值对（omap 相关） |
| Compound operations and dual-ack semantics | 复合操作与 dual-ack 语义 |
| Object Classes | 对象类（见 9.4） |
💡 补充：这一清单里最容易被人忽略的是 Compound operations（复合操作） 与 dual-ack semantics（双确认语义）。前者允许把多个操作打包成一个事务提交（原子性）；后者区分"已提交到内存/日志"与"已持久化到磁盘"两种确认级别——这直接决定了性能与持久性的权衡，也是理解 Ceph 写延迟构成的关键。官方此处未给出两者的具体语义与参数，本册不展开（详见 librados / 运维分册）。
10.2 三类客户端的分层
Ceph 提供三类客户端：Ceph Block Device、Ceph File System、Ceph Object Storage。
（原图为 Ceph 客户端高层架构示意图 .. ditaa::）
+--------------+ +----------------+ +-------------+
| Block Device | | Object Storage | | CephFS |
+--------------+ +----------------+ +-------------+
+--------------+ +----------------+ +-------------+
| librbd | | librgw | | libcephfs |
+--------------+ +----------------+ +-------------+
+---------------------------------------------------+
| Ceph Storage Cluster Protocol (librados) |
+---------------------------------------------------+
+---------------+ +---------------+ +---------------+
| OSDs | | MDSs | | Monitors |
+---------------+ +---------------+ +---------------+
官方还说明：Ceph 可以运行额外的 OSD、MDS 与 monitor 实例，以实现可扩展性与高可用性。
10.3 各层定位速查
| 层 | 组件 | 定位（官方） | 是否需要 MDS |
|---|---|---|---|
| 原生层 | librados |
唯一原生协议；可用于创建自定义接口；可与 Ceph Monitor 与 OSD 交互 | 否 |
| 块 | Ceph Block Device / RBD（librbd） |
提供可调整大小、精简置备、可快照与克隆的块设备；Ceph 把块设备条带化到整个集群以获得高性能；同时支持内核对象（KO）与直接使用 librbd 的 QEMU hypervisor（避免虚拟化场景下的内核对象开销） |
否 |
| 对象 | Ceph Object Storage / RGW（librgw，守护进程 radosgw） |
提供 RESTful API，接口兼容 Amazon S3 与 OpenStack Swift | 否 |
| 文件 | Ceph File System / CephFS（libcephfs） |
提供 POSIX 兼容的文件系统，可以以 mount 方式或**用户态文件系统（FUSE）**方式使用 |
是 |
10.4 Ceph Object Storage（RGW）
是什么
- Ceph Object Storage 守护进程
radosgw是一个 FastCGI 服务，提供 RESTful HTTP API 来存储对象与元数据。 - 它层叠在 Ceph Storage Cluster 之上，带有自己的数据格式，并维护自己的用户数据库、认证与访问控制。
- RADOS Gateway 使用统一的命名空间（unified namespace），这意味着你既可以使用 OpenStack Swift 兼容 API，也可以使用 Amazon S3 兼容 API。例如：你可以用 S3 兼容 API 写入数据，然后用 Swift 兼容 API 读出数据。
S3/Swift 对象 ≠ Ceph 存储集群对象（官方 topic）
官方专门澄清这个易混点：
- Ceph 的 Object Storage 也用 object 这个词描述它存储的数据。
- S3 与 Swift 的对象，与 Ceph 写入 Ceph Storage Cluster 的对象不是同一回事。
- Ceph Object Storage 的对象被映射到 Ceph Storage Cluster 的对象。
- S3 与 Swift 对象与存储集群中的对象不一定 1:1 对应。
- 一个 S3 或 Swift 对象有可能映射到多个 Ceph 对象。
相关术语
- Ceph Object Gateway / RGW / RADOS Gateway：构建在
librados之上的对象存储接口，在应用与 Ceph 存储集群之间提供 RESTful 网关。 - Ceph Object Store：由 Ceph Storage Cluster + Ceph Object Gateway (RGW) 组成。
- Bucket（RGW 语境）：一组对象。用文件系统的类比：对象是文件，bucket 就是目录。可以对 bucket 设置 Multisite sync policies，以精细控制数据从一个 zone 到另一个 zone 的流动。bucket 概念取自 AWS S3；OpenStack Swift 把 RGW 与 AWS 称为 "buckets" 的东西称为 "containers"。
- Zone（RGW 语境）：由一个或多个 RGW 实例组成的逻辑组。一个 zone 的配置状态存放在 period 中。
- Period（RGW 语境）：Realm 的配置状态。period 存储多站点配置的配置状态。当 period 被更新时，就称 "epoch" 发生了变化。
- Realm（RGW 语境）：全局唯一的命名空间，由一个或多个 zonegroup 组成。
- S3 / OpenStack Swift：Ceph Object Store 支持的两套 API。
10.5 Ceph Block Device（RBD）
是什么
- Ceph Block Device 把一个块设备镜像条带化到 Ceph Storage Cluster 中的多个对象上；每个对象被映射到一个 PG 并被分布出去，而这些 PG 被分散到整个集群中彼此独立的
ceph-osd守护进程上。 - 官方 important：条带化使 RBD 块设备的性能优于单台服务器所能达到的性能！
部署形态
| 场景 | 官方说明 |
|---|---|
| QEMU/KVM 虚拟机 | 人们通常用 QEMU/KVM 中的 rbd 网络存储驱动部署 Ceph Block Device，宿主机使用 librbd 向 guest 提供块设备服务。许多云计算栈使用 libvirt 与 hypervisor 集成 |
| 云栈集成 | 可以把精简置备的 Ceph Block Device 与 QEMU 和 libvirt 一起使用，以支撑 OpenStack、OpenNebula、CloudStack 等方案 |
| 其它 hypervisor | 官方明确：目前我们不为其它的 hypervisor 提供 librbd 支持；但你也可以使用 Ceph Block Device 内核对象向客户端提供块设备。Xen 等其它虚拟化技术可以访问 Ceph Block Device 内核对象，这是通过命令行工具 rbd 完成的 |
相关术语
- Ceph Block Device：也称 "RADOS Block Device" 与 RBD。它把基于块的应用数据切分成 "chunks"，RADOS 把这些 chunk 存为对象，Ceph Block Device 编排这些对象在整个存储集群中的存放。
- Ceph Block Storage：Ceph 支持的三种存储之一（另两种是对象存储与文件存储）。它是块存储的"产品"形态，指与
librbd（提供类文件方式访问 RBD 镜像的 python 模块）+ hypervisor（如 QEMU 或 Xen） + hypervisor 抽象层（如libvirt） 配合使用时的块存储相关服务与能力。
10.6 Ceph File System（CephFS）
是什么
- CephFS 提供 POSIX 兼容的文件系统，作为层叠在基于对象的 Ceph Storage Cluster 之上的服务。
- CephFS 文件被映射为 Ceph 存放在 Ceph Storage Cluster 中的对象。
- Ceph 客户端把 CephFS 文件系统挂载为内核对象，或作为用户态文件系统（FUSE）使用。
（原图为 CephFS 架构示意图 .. ditaa::）
+-----------------------+ +------------------------+
| CephFS Kernel Object | | CephFS FUSE |
+-----------------------+ +------------------------+
+---------------------------------------------------+
| CephFS Library (libcephfs) |
+---------------------------------------------------+
+---------------------------------------------------+
| Ceph Storage Cluster Protocol (librados) |
+---------------------------------------------------+
+---------------+ +---------------+ +---------------+
| OSDs | | MDSs | | Monitors |
+---------------+ +---------------+ +---------------+
元数据与数据分离（架构动机）
见 2.4 节。核心两句原文：
- MDS 的目的是把全部文件系统元数据（目录、文件属主、访问模式等）存放在高可用的 Ceph Metadata Server 中，元数据驻留在内存里。
- MDS 存在的理由是：像
ls、cd这样简单的文件系统操作会不必要地消耗 Ceph OSD Daemon。所以把元数据与数据分离，意味着 Ceph File System 可以提供高性能服务而不拖累 Ceph Storage Cluster。
相关术语
- CephFS：Ceph File System，构建在 Ceph 的分布式对象存储 RADOS 之上的 POSIX 兼容文件系统。
- ceph-fuse：CephFS 的 FUSE（"Filesystem in USErspace"）客户端，把 Ceph FS 挂载到指定的挂载点。
- Ceph Kernel Modules：可用于与 Ceph Cluster 交互的内核模块集合（例如
ceph.ko、rbd.ko）。 - Ceph Client Libraries：可用于与 Ceph Cluster 各组件交互的库的集合。
10.7 协议栈总结（原图为 Ceph 协议栈示意图）
+------------------+ +------------------+ +------------------+
| RBD (块) | | RGW (对象) | | CephFS (文件) |
| 可调整大小/精简置备 | | S3 & Swift 兼容 | | POSIX 兼容 |
| 可快照/可克隆 | | 统一命名空间 | | mount 或 FUSE |
+------------------+ +------------------+ +------------------+
| librbd | | librgw | | libcephfs |
+------------------+ +------------------+ +------------------+
| | |
+----------------------+----------------------+
|
+---------------------------------------------------------------+
| librados（原生协议） |
| Pool Ops / Snapshots & COW Cloning / Read-Write Objects / |
| XATTRs / Key-Value Pairs / Compound Ops & dual-ack / |
| Object Classes / Watch-Notify |
+---------------------------------------------------------------+
|
+------------------+ +------------------+ +------------------+
| OSDs | | Monitors | | MDSs (CephFS) |
| 数据存储/复制/ | | cluster map 主副本 | | 文件元数据 |
| peering/scrub | | Paxos / CephX | | active/standby |
+------------------+ +------------------+ +------------------+
| RADOS |
+---------------------------------------------------------------+
十一、术语表
来源：
doc/glossary.rst（Ceph Glossary）。下表覆盖该页的全部条目（含Releases下的 5 个子条目），三列分别为：英文术语 | 中文解释 | 关联概念。少数条目在原文中是交叉引用（如 "See :term:CephFS"），本册在"中文解释"中给出指向，在"关联概念"中给出被指向的术语。
11.1 核心概念
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Ceph | 一个分布式网络存储与文件系统，具有分布式元数据管理与 POSIX 语义 | RADOS、CephFS |
| Ceph Platform | Ceph 的全部软件，包括托管在 https://github.com/ceph 上的任何代码 |
Ceph Project |
| Ceph Project | Ceph 的人员、软件、使命与基础设施的统称 | Ceph Platform、Ceph Stack |
| Ceph Stack | 两个或多个 Ceph 组件的集合 | Ceph Platform |
| Ceph Node | Ceph 集群中的一个单元，与其他节点通信以复制和再分布数据。所有节点合称 Ceph Storage Cluster。Ceph 节点包括 OSD、Ceph Monitor、Ceph Manager 与 MDS。文档中 "node" 通常等同于 "host"。可用 ceph node ls all 列出所有节点 |
Host、Ceph Storage Cluster |
| Host | Ceph 集群中的任何单台机器或服务器 | Ceph Node |
| Node | 见 Ceph Node | Ceph Node |
| Ceph Storage Cluster | 由 Ceph Monitor、Ceph Manager、Ceph Metadata Server 与 OSD 组成的集合，它们协同工作，为应用、Ceph 用户与 Ceph Client 存储和复制数据。Ceph Storage Cluster 从 Ceph Client 接收数据 | RADOS、Ceph Node |
| RADOS | Reliable Autonomic Distributed Object Store。为可变大小对象提供可扩展服务的对象存储，是 Ceph 集群的核心组件 | Ceph Storage Cluster、RADOS Cluster、librados |
| RADOS Cluster | Ceph Cluster 的一个真子集，由 OSD、Ceph Monitor 与 Ceph Manager 组成 | RADOS、Ceph Storage Cluster |
| Reliable Autonomic Distributed Object Store | 存储用户数据的核心存储软件集合（MON + OSD） | RADOS、MON、OSD |
| librados | 一个 API，可用于创建到 Ceph 存储集群的自定义接口。它使得与 Ceph Monitor 和 OSD 交互成为可能 | RADOS、Ceph Protocol |
| Ceph Client | 任何能够访问 Ceph Storage Cluster 的 Ceph 组件。包括 Ceph Object Gateway、Ceph Block Device、Ceph File System 及其对应库，也包括内核模块与 FUSE | Ceph Client Libraries、Application |
| Ceph Client Libraries | 可用于与 Ceph Cluster 各组件交互的库的集合 | Ceph Client、librados |
| Ceph Kernel Modules | 可用于与 Ceph Cluster 交互的内核模块集合（例如 ceph.ko、rbd.ko） |
Ceph Client |
| Application | 更确切地说是 client，指 Ceph 之外任何使用 Ceph Cluster 来存储和复制数据的程序 | Client、Ceph Client |
| Client | Ceph 之外任何使用 Ceph Cluster 来存储和复制数据的程序 | Application、Ceph Client |
| User | 使用 Ceph 客户端与 Ceph Storage Cluster 交互的个人或系统参与者（例如一个应用） | Ceph Client、CephX |
| Cloud Platforms / Cloud Stacks | 第三方云供应平台，例如 OpenStack、CloudStack、OpenNebula、Proxmox VE | Ceph Block Device、libvirt |
11.2 集群映射与守护进程
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Cluster Map | 由 monitor map、OSD map、PG map、MDS map 与 CRUSH map 组成的集合，共同报告 Ceph 集群的状态 | Monitor Map、OSD Map、PG Map、MDS Map、CRUSH Map |
| Ceph Cluster Map | 见 Cluster Map | Cluster Map |
| Ceph Monitor | 维护集群状态映射的守护进程。"cluster state" 包括 monitor map、manager map、OSD map 与 CRUSH map。一个 Ceph 集群必须至少包含 3 个运行中的 monitor，才能既冗余又高可用。monitor 及其所在节点常被称作 "mon" | Quorum、Paxos、Monitor Store、MON |
| MON | Ceph monitor 软件 | Ceph Monitor、Quorum |
| Monitor Store | Monitor 使用的持久化存储，包括 Monitor 的 RocksDB 以及 /var/lib/ceph 下的全部相关文件 |
Ceph Monitor |
| Quorum | 集群中多数 Monitor 处于 up 时存在的状态。集群中必须至少存在 3 个 Monitor，Quorum 才可能成立 |
Ceph Monitor、Paxos |
| Ceph Manager | ceph-mgr 守护进程，与 monitor 守护进程并排运行，提供额外的监控以及对接外部监控与管理系统的接口。自 Luminous（12.x）起，集群必须有运行中的 ceph-mgr 才能正常工作 |
MGR、Ceph Dashboard |
| MGR | Ceph manager 软件，把整个集群的全部状态收集到一处 | Ceph Manager、Dashboard |
| Ceph OSD | Object Storage Daemon。与逻辑磁盘（OSD）交互的 Ceph OSD 软件。约 2013 年有"研究界与工业界"试图坚持 OSD 只表示 "Object Storage Device"，但 Ceph 社区始终用它表示 "Object Storage Daemon"；Sage Weil 在 2022-11 确认 "Daemon 是更准确的说法" | OSD、Ceph OSD Daemon、Object Storage Device |
| Ceph OSD Daemon | 见 Ceph OSD | Ceph OSD、OSD |
| Ceph OSD Daemons | 见 Ceph OSD | Ceph OSD |
| OSD | 可能是 Ceph OSD，但不一定。有时（尤其是较旧的通信中，以及非专为 Ceph 写的文档中）"OSD" 表示 "Object Storage Device"，指物理或逻辑存储单元（例如 LUN）。Ceph 社区始终用 OSD 指 Ceph OSD Daemon，尽管 2010 年代中期业界曾推动把它限定为 "Object Storage Device"，因此必须分辨是哪一种含义 | Ceph OSD、Object Storage Device |
| Object Storage Device | 见 OSD | OSD、Ceph OSD |
| OSD ID | 每个 OSD 唯一的整数（每个 OSD 有唯一的 OSD ID）。每个 OSD id 由 monitor 在创建其关联 OSD 时生成 | OSD FSID、OSD UUID |
| OSD FSID | 用于标识 OSD 的唯一标识符，位于 OSD 路径下名为 osd_fsid 的文件中。FSID 与 UUID 两个术语可互换使用 |
OSD UUID、OSD ID |
| OSD UUID | OSD 的唯一标识符。该术语与 FSID 互换使用 | OSD FSID |
| Flapping OSD | 被反复、快速地交替标记为 up 和 down 的 OSD |
OSD, flapping |
| OSD, flapping | 见 Flapping OSD | Flapping OSD |
| Hybrid OSD | 同时拥有 HDD 和 SSD 驱动器的 OSD | device class |
| MDS | Ceph MetaData Server 守护进程，也称 ceph-mds。任何运行 CephFS 文件系统的 Ceph 集群都必须运行 MDS。MDS 存储全部文件系统元数据。客户端与单个 MDS 或一组 MDS 协同维护 CephFS 所需的分布式元数据缓存 |
Ceph Metadata Server、CephFS |
| Ceph Metadata Server | 见 MDS | MDS、CephFS |
| CephX | Ceph 的认证协议。认证用户与守护进程。运行方式类似 Kerberos，但没有单点故障，并允许对一类服务进行认证 | Client、User、secrets |
| secrets | 每当特权用户必须访问需要认证的系统时，用于执行数字认证的凭据。可以是密码、API key、token、SSH key、私有证书或加密密钥 | CephX |
11.3 存储组织与放置
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Pool | 用于存储对象的逻辑分区 | Pools、Placement Groups、CRUSH rule、pg_num |
| Pools | 见 pool | Pool |
| Placement Groups (PGs) | 每个逻辑 Ceph pool 的子集。PG 的功能是把对象（作为一个组）放置到 OSD 中。Ceph 在内部以 PG 粒度管理数据——这比管理一个个（数量多得多的）RADOS 对象扩展性更好。PG 数量较多的集群（例如每 OSD 100 个）比 PG 较少的同配置集群均衡得更好。Ceph 的内部 RADOS 对象每个都被映射到一个特定的 PG，而每个 PG 恰好属于一个 Ceph pool | Pool、OSD、CRUSH |
| CRUSH | Controlled Replication Under Scalable Hashing。Ceph 用来计算对象存储位置的算法 | CRUSH rule、Cluster Map、bucket |
| CRUSH rule | 应用于某个或某些特定 pool 的 CRUSH 数据放置规则 | CRUSH、Pool、failure domain |
| Primary Affinity | OSD 的一个属性，决定某个 OSD 被选为 acting set 中 primary OSD（或 "lead OSD"）的可能性。自 Firefly (v. 0.80) 引入 | OSD、Acting Set、Primary |
| Object Storage | Ceph 相关的三种存储之一（另两种是文件存储与块存储）。对象存储是 Ceph 最基础的存储类别 | RADOS、Ceph Object Storage |
| omap | "object map"。一个 key-value 存储（数据库），用于减少从 Ceph 集群读写数据所需的时间。RGW 的 bucket index 以 omap 形式存储。纠删码池不能存储 RADOS omap 数据结构。可用 ceph osd df 查看 omap |
RGW、Bucket、Erasure Coding |
| BlueStore | OSD 使用的存储后端，专为 Ceph 设计。Kraken 引入；Luminous 提升为默认 OSD 后端（取代 FileStore）；自 Reef 起，FileStore 不再可用。BlueStore 把对象直接存放在裸块设备或分区上，不与已挂载的文件系统交互；使用 RocksDB 的 key/value 数据库把对象名映射到磁盘上的块位置 | OSD、RocksDB |
| Crimson | 下一代 OSD 架构，目标是降低跨核通信带来的延迟开销。重新设计 OSD 以减少数据路径上 shard 之间的通信从而降低锁竞争；通过消除对线程池的依赖提升 classic Ceph OSD 的性能 | OSD |
| DAS | Direct-Attached Storage。直接连接到访问它的计算机、不经过网络的存储。与 NAS 和 SAN 相对 | SDS |
| SDS | Software-defined Storage（软件定义存储） | Ceph、DAS |
| scrubs | Ceph 用来确保数据完整性的过程。scrubbing 时，Ceph 生成一个 PG 中所有对象的目录，然后把每个主对象与存放在其他 OSD 上的副本做比较，确保没有对象缺失或不匹配。任何 PG 若被发现副本内容不同或对象整个缺失，就被标记为 inconsistent。有两种：light scrubbing（也称 shallow scrubbing，每天执行，仅确认对象存在且元数据正确）与 deep scrubbing（每周执行，读取数据并用 checksums 确保完整性） |
PG、deep scrubbing、inconsistent |
| LVM tags | Logical Volume Manager 标签。LVM 卷与卷组的可扩展元数据，用于存储 Ceph 关于设备及其与 OSD 关系的特定信息 | OSD、ceph-volume |
| PLP | Power Loss Protection。一种用电容延长把数据从 DRAM 缓存转移到 SSD 永久存储器的可用时间，从而保护固态硬盘数据的技术。消费级 SSD 很少配备 PLP | SSD、BlueStore |
11.4 对象/块/文件服务
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Ceph Block Device | 也称 "RADOS Block Device" 与 RBD。一个软件构件，用于编排基于块的数据在 Ceph 中的存储。Ceph Block Device 把基于块的应用数据切分成 "chunks"，RADOS 把这些 chunk 存为对象，Ceph Block Device 编排这些对象在整个存储集群中的存放 | RBD、Ceph Block Storage、librbd |
| RBD | RADOS Block Device。见 Ceph Block Device | Ceph Block Device、librbd |
| Ceph Block Storage | Ceph 支持的三种存储之一（另两种是对象存储与文件存储）。它是块存储"产品"，指与 (1) librbd（提供类文件方式访问 RBD 镜像的 python 模块）、(2) hypervisor（如 QEMU 或 Xen）、(3) hypervisor 抽象层（如 libvirt） 配合使用时的块存储相关服务与能力 |
Ceph Block Device、libvirt |
| Ceph Object Gateway | 构建在 librados 之上的对象存储接口。在应用与 Ceph 存储集群之间提供 RESTful 网关 |
RGW、Ceph Object Store、librados |
| RGW | RADOS Gateway。也称 "Ceph Object Gateway"。提供到 Amazon S3 RESTful API 与 OpenStack Swift API 的网关的 Ceph 组件 | Ceph Object Gateway、S3、Swift |
| RADOS Gateway | 见 RGW | RGW |
| Ceph Object Storage | 见 Ceph Object Store | Ceph Object Store、RGW |
| Ceph Object Store | 由 Ceph Storage Cluster + Ceph Object Gateway (RGW) 组成 | RGW、Ceph Storage Cluster |
| Bucket | 在 RGW 语境中，bucket 是一组对象。用文件系统的类比：对象对应文件，bucket 对应目录。可以对 bucket 设置 Multisite sync policies，以精细控制数据从一个 zone 流向另一个 zone。该概念取自 AWS S3；OpenStack Swift 把 RGW/AWS 称为 "buckets" 的东西称为 "containers" | RGW、Zone、Realm |
| CephFS | Ceph File System，构建在 Ceph 的分布式对象存储 RADOS 之上的 POSIX 兼容文件系统 | Ceph File System、MDS、libcephfs |
| Ceph File System | 见 CephFS | CephFS |
| ceph-fuse | CephFS 的 FUSE（"Filesystem in USErspace"）客户端。把 Ceph FS 挂载到指定的挂载点 | CephFS、Ceph Client |
| S3 | 在 Ceph 语境中，Ceph Object Store 支持的两套 API 之一（另一套是 OpenStack Swift） | RGW、Bucket |
| Swift / OpenStack Swift | 在 Ceph 语境中，OpenStack Swift 是 Ceph Object Store 支持的两套 API 之一（另一套是 S3）。它把 RGW/AWS 称为 "buckets" 的东西称为 "containers" | RGW、Bucket |
| Zone | 在 RGW 语境中，zone 是由一个或多个 RGW 实例组成的逻辑组。一个 zone 的配置状态存放在 period 中 | RGW、Period、Realm |
| Period | 在 RGW 语境中，period 是 Realm 的配置状态。period 存储多站点（multi-site）配置的配置状态。当 period 被更新时，就称 "epoch" 发生了变化 | RGW、Realm、Zone |
| Realm | 在 RADOS Gateway (RGW) 语境中，realm 是全局唯一的命名空间，由一个或多个 zonegroup 组成 | RGW、Zone、Period |
11.5 管理与运维相关
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Ceph Dashboard | 内建的、基于 Web 的 Ceph 管理与监控应用，通过它可以查看和管理集群内的各种资源。它实现为一个 ceph-mgr 模块 | Dashboard、Ceph Manager |
| Dashboard | 内建的、基于 Web 的 Ceph 管理与监控应用，用于管理集群的各个方面与对象。dashboard 实现为一个 Ceph Manager 模块 | Ceph Dashboard、Dashboard Module |
| Dashboard Module | Dashboard 的另一种叫法 | Dashboard |
| Dashboard Plugin | Mimic 时代的一个 Web 应用，用一个由 Ceph Manager 托管的 web server 可视化 Ceph 集群的信息与统计 | Dashboard、Ceph Manager |
| Ceph Manager Dashboard | 见 Ceph Dashboard | Ceph Dashboard |
| Prometheus | 一个开源的监控与告警工具包。Ceph 提供 "Prometheus module"，它提供一个 Prometheus exporter，把 ceph-mgr 中一个收集点的性能计数器传递给 Prometheus |
Ceph Manager、Dashboard |
| ceph-ansible | 一个 GitHub 仓库，从 Jewel 到 Quincy 版本受支持，用于简化 Ceph 集群的安装 | Cloud Platforms |
| Teuthology | 对 Ceph 执行脚本化测试的软件集合 | Ceph Platform |
| systemd oneshot | 一种 systemd type，其命令定义在 ExecStart 中，完成后即退出（它不打算 daemonize） |
— |
| FQDN | Fully Qualified Domain Name。应用于网络中某个节点、并指定该节点在 DNS 树状层级中确切位置的域名。在 Ceph 集群管理中，FQDN 常用于主机。文档中主要用 FQDN 来区分它与相对简单的 hostname（后者不指定主机在 DNS 树中的确切位置，只是给主机起个名字） | Host、Ceph Node |
| DC | Data Center（数据中心） | CRUSH bucket type datacenter |
11.6 Releases（发布类型，含 5 个子条目）
| 英文术语 | 中文解释 | 关联概念 |
|---|---|---|
| Releases | 发布类型的总条目，包含下列 5 个子条目 | Ceph Release |
| Ceph Release | Ceph 的任何不同的编号版本 | Ceph Point Release、Ceph Stable Release |
| Ceph Interim Release | 尚未经过质量保证（QA）测试的 Ceph 版本。可能包含新特性 | Ceph Stable Release |
| Ceph Release Candidate | 已经过初步质量保证测试、可供 beta 测试者使用的 Ceph 主版本 | Ceph Interim Release |
| Ceph Stable Release | 一个 Ceph 主版本，其中来自前面各 interim release 的全部特性都已成功通过质量保证测试 | Ceph Interim Release |
| Ceph Point Release | 任何只包含 bug 修复与安全修复的临时（ad hoc）发布 | Ceph Stable Release |
| Ceph Stable Release | 见上 | — |
引自：Glossary
文档未明确项
本册在撰写过程中，遇到以下官方文档未给出或文档内部表述不一致之处。按写作规范登记，不做推测性填充：
- CRUSH 内部选择算法：
architecture.rst与crush-map.rst均未给出 CRUSH 在每一层如何从兄弟节点中选出一个（bucket 选择算法、随机种子的取值与递增规则、冲突/失败时的重试次数上限）。本册已在 4.10 节标注。 firstn与indep的算法层面差异：官方仅给出用途与行为描述（见 4.7），未给出实现细节。ruleset术语：本册抓取的 Tentacle v20.2.4 全部源文中未出现ruleset字样；当前文档统一使用 CRUSH rule / rules。因此本册不定义ruleset，也不把它当作现行概念使用。- CRUSH 查找的完整输入参数：官方未列出 CRUSH 计算所需的全部输入（例如副本序号等参数的具体取值规则）。
- PG Map 的查看命令：
architecture.rst为 monitor / OSD / CRUSH / MDS 四张 map 都给出了查看命令，唯独 PG Map 没有给出专门命令。 - 默认
size的出处差异：architecture.rst只给出设计基线（size = 2为最低要求，推荐size = 3且min size = 2），未使用"默认值"这一措辞。本册因此不声称"默认 size = 3"来自架构页。 - Cluster Map 的组成存在文档内部差异：
architecture.rst与术语表 Cluster Map 条目均为五张 map（monitor / OSD / PG / MDS / CRUSH）；但术语表 Ceph Monitor 条目把 cluster state 列为 monitor map、manager map、OSD map、CRUSH map（未列 PG map 与 MDS map，却列入了 manager map）。本册以architecture.rst的五张 map 为准（见 6.3）。 mon_osd_down_out_interval等参数的默认数值：本册引用的mon-osd-interaction.rst只列出参数名，未在本册阅读范围内给出具体默认秒数，故本册只登记参数名。compound operations与dual-ack semantics的具体语义：architecture.rst在 librados 能力清单中列出二者，但未给出定义、参数或行为说明（见 10.1）。- 条带化参数（object size / stripe width / stripe count）的默认值：官方只给了示例值（object size 例如 2MB、4MB；stripe width 例如 64kb），未给出默认值。
- CephX rotating service keys 的具体数量规则：官方表述为"通常为 3 个"（usually 3），未说明其配置方式与取值规则。
- PG ID 中后半部分的进制：官方示例给出十进制
58，而实际ceph输出中 PG 编号后半部分通常显示为十六进制。官方未说明这一表示差异，第 5.4 节的说明为笔者的 💡 补充。
本册完 · 第 01 册《Ceph 架构篇》 主要引自：Architecture ｜ Glossary