概念区分：OSD vs. Ceph OSD

ceph-osd（Ceph OSD，Object Storage Daemon）
OSD，Object Storage Device

Ceph OSD 与 OSD 是两个不同的术语：
2）OSD 表示 Object Storage Device，是物理或逻辑存储单元；
1）Ceph OSD 表示 Ceph Object Storage Daemon；

Ceph OSD 与 OSD 为 1:1 关系，所以在描述中通常将 OSD 与 Ceph OSD 合并称为”OSD“。在叙述时，我们也将使用该说法，除非特殊说明；

功能作用

数据存储

Ceph 如何将对象写入具体的 OSD 呢？这就是 Ceph 的对象存储做的事情。对象存储为 OSD 的原子块设备提供了一个底层接口。当 Client 读写数据时，Client 与对象存储接口进行交互。保存在集群中的对象具有唯一的标识符、对象数据、元数据。对象存储接口通过确保 Ceph 对象语义正确来保证对象一致性。对象存储接口是存储介质的底层接口，提供了性能统计信息；

Ceph OSD 是 Ceph 的对象存储守护进程，负责数据存储（读写）、复制、恢复、平衡。每个存储服务器（存储节点）运行一个或多个 Ceph OSD 进程，通常每个磁盘存储设备对应一个 Ceph OSD 进程。在 Ceph Cluster 中，当启动所有的 Ceph OSD 管理相应的磁盘时，都是在宿主机操作系统中启动一个进程；

任何读写操作请求，当 Client 从 Ceph Mon 获取 Cluster Map 后，Client 将直接与 Ceph OSD 进行 I/O 操作的交互，而不再需要 Ceph Mon 干预。这使得数据读写过程更为迅速（因为这些操作过程不像其他存储系统，它没有其他额外的层级数据处理）；

数据存储方式：
1）早期使用 Filestore（其依赖于节点的文件系统，Ext4、XFS、Btrfs），即数据存储在文件系统中；
2）后面改用 Bluestore（直接接管块设备，以提高性能），即数据直接存储在块设备中；
3）其他数据存储方式，诸如 MemStore、K/V Store 等等，较少在生产中使用，所以这里暂不做讨论；

Ceph 使用存储介质有两种方法：OSD 日志盘；OSD 数据盘；

状态汇报

Ceph Mon 是个轻量级进程：
1）当 Ceph OSD 加入集群后，需要周期向 Ceph Mon 报告其状态。如果 Ceph Mon 定期主动检测 OSD 状态，当 Ceph 集群中存在很多 OSD 进程时，将使得 Ceph Mon 负载较高；
2）在 Ceph 的心跳设计中，Ceph OSD 还要检查其他守护进程是否有故障，判断相邻的 OSD 状态是否已经为 down，进而更新 Cluster Map，并向 Ceph Mon、Ceph Mgr 汇报结果，以提供一些监控信息；

在最低级别上，OSD 状态为 up 或 down，反映 Ceph OSD 是否正在运行并能够为 Ceph Client 请求提供服务。如果 OSD 状态为 in 和 down，表示 OSD 可能发生故障。例如，如果 OSD 进程未运行，则无法通知 Ceph Mon 它处于 down 状态。这时，Ceph Mon 可以定期 ping Ceph OSD 守护进程，以确保其正在运行；

数据清查（Scrub）

Scrub 是 Ceph 集群对 PG 进行数据清洗（扫描）的操作，以确保通过 PG 及其副本间的数据完整，确保数据一致性；

Scrub 类似于对象存储层上的 fsck 命令：
1）Light Scrubing：只对元数据进行扫描，速度比较快；每天检查对象的大小和属性；
2）Deep Scrubing：不仅要对元数据进行扫描，还要对数据进行扫描，速度比较慢。每周读取数据并使用校验和确保数据完整性；

Scrub 操作对于保持数据完整很重要，但是会降低性能。可以调整 Scrub 操作的频率来兼顾数据完整与性能；
对于每个 Placement Group，Ceph 都会为所有对象生成目录，并比较每个主要对象及其副本，以确保没有对象丢失或不匹配；

数据回填（Backfill）

当将 OSD 添加到集群或从集群中删除时，CRUSH 算法通过将 PG 移入或移出 OSD 来重新平衡集群数据分布，以达到数据均匀分布。PG 及其包含的对象的迁移可能会大大降低集群的运行性能；

为了保持集群性能，Ceph 通过回填（Backfill）方式来执行迁移。简单来说，我们可以通过修改配置，以降低 Backfill 操作的优先级，使得其比读取或写入数据的请求的优先级还低，以保证集群的读写性能。然后，在集群读写请求优先级较低的时候，完成数据再平衡；

数据同步（Peering）

当集群节点启动（或 Ceph OSD 崩溃并重新上线）时，Ceph OSD 将根据掉线的时间，判断 Ceph OSD 的对象和 PG 是否已过时。通常它与其他 Ceph OSD 数据不同步，掉线又重新恢复的 Ceph OSD 中的对象版本较老旧，而其他 Ceph OSD 在 PG 中包含的对象版本最新；

所以，当发生这种情况时，在可能发生读写操作前，该 Ceph OSD 开始与其余 Ceph OSD 进行配对检查。此时 Ceph OSD 进入恢复模式，寻求获取数据的最新副本并将其映射恢复到最新状态；

这些 Ceph OSD 相互对等或互相检查，以确保 PG 的每个副本的状态一致，该相互检查以确保数据一致的过程就是 Peering，该过程是自动的（无需人为干预处理）；

同样，如果某个故障域发生故障（例如机架故障），则可能同时有多个 Ceph OSD 上线，这会使恢复过程既耗时又耗资源。为了保障性能，Ceph 会限制恢复请求的数量。通过控制线程数和对象块大小，可以让 Ceph 在 Degraded 状态下表现出良好的性能；

数据平衡（Balance）

当 Ceph OSD 添加到 Ceph Cluster 时，Ceph 将更新 Cluster Map，随着 Cluster Map 变更，PG 的位置也会发生变化。CRUSH 会均匀地放置数据，但会伪随机放置。所以，当管理员添加新的 OSD 时，会有少量数据移动。

（移动的数据量）=（新 OSD 的数量）/（集群中的数据总量）。例如，在有 50 个 OSD 的集群中，添加一个 OSD 可能会移动集群数据的 1/50；

数据再平衡过程，其中一些 PG 从现有 OSD1 和 OSD2 迁移到新 OSD3。即使在再平衡过程中，许多 PG 仍保持其原始配置，并且每个 OSD 都有一些新数据写入，因此在集群再平衡后，新 OSD 上不会出现负载高峰；

高可用性

Ceph 的核心功能特性包括高可靠、自动平衡、自动恢复和一致性。对于 Ceph OSD 而言，基于副本数的配置，Ceph 通过在多 OSD 节点创建的数据副本来实现高可用性以及容错性。在 OSD 中的每个对象都有一个主副本，若干个从副本，这些副本默认情况下是分布在不同 OSD 节点上；

Ceph 集群一般情况都包含多个 OSD 实例，集群中不管是设置 3 副本还是采用 2:1 的纠删码方式，都至少需要 3 个 OSD 才能实现冗余和高可用；

每个 OSD 都可能作为某些对象的 Primary OSD，与此同时，它也可能作为某些对象的 Secondry OSD，Secondry OSD 受到 Primary OSD 的控制，

在某些情况下，Secondry OSD 也可能成为 Primary OSD。在磁盘故障时，Ceph OSD Deamon 的智能对等机制将协同其他 OSD 执行恢复操作。在此期间，存储对象副本的 Secondry OSD 将被提升为 Primary OSD，与此同时，新的从副本将重新生成，这样就保证 Ceph 的可靠和一致；

Primary OSD, Secondary OSD, …

当 Ceph 在一个有效的 OSD 集中存储一个 PG 时，OSD 按顺序命名，称为 Primary OSD、Secondary OSD 等等，以此类推；

Primary OSD，指的是在 Acting Set 中的第一个 OSD，其存储 PG 第一个副本，并负责每个 PG 与 Secondary OSD 直接的 Peering 操作；

Primary OSD 还负责响应客户端的写操作请求，是唯一接受客户端向给定 PG 发起对象写入的 Ceph OSD。当 Client 读取数据时，默认从 Primary OSD 读取（通过配置亲和性，能够改变这种行为）；

Acting Set vs. Up Set

Acting Set，指的是负责某个 PG 的一组 OSD 的集合。注意，这其中部分 Ceph OSD 的状态不一定是 up 状态。处于 UP 状态的 OSD 保留在 Acting Set 中，并不会从 Acting Set 中移除；

Up Set，指的是 负责某个 PG 的 并 处于 up 状态的 一组 OSD 的集合；

当 Primary OSD 变为 down 状态时，首先将其从 Uping Set 中移除，然后把 Secondary OSD 提升为 Primary OSD，同时 Ceph 将确定新的 OSD 集合来负责该 PG

该组 Up Set 将从 Acting Set 同步数据，当数据同步完成后，Acting Set 将与 Up Set 一致；

# rados put -p rbd hosts /etc/hosts

# rados ls -p rbd

# ceph osd map rbd hosts
osdmap e670 pool 'rbd' (2) object 'hosts' -> pg 2.ea1b298e (2.e) -> up ([5,3], p5) acting ([5,3], p5)

// up set 为 OSD.5 OSD.3
// acting set 为 OSD.5 OSD.3

状态变迁

当 OSD 是 Down (服务已停止) 状态，然而它仍然被标记为 IN 状态。只要它的状态还是 IN，Ceph Cluster 就不会为它触发数据恢复；

默认情况下，Ceph Cluster 需要 5min 时间来将一个 DOWN 状态的磁盘标记为 OUT 状态，然后开始数据恢复。设置该时长是为了在发生短期的服务中断时避免不必要的数据移动，比如，当系统重启时；

我们可以根据需要去增加或者减少该超时时长；

网络端口

OSD 绑定到某节点中从端口 6800 开始的第一个可用端口上。

针对在该节点上运行的每个 OSD 进程，确保至少打开 4 个从端口 6800 开始的端口；
1）一个端口用于与上的客户端和 Monitor 节点对话；
2）一个端口用于将数据发送到的其他 OSD 节点上；
3）两个端口用于在私网上发送心跳包；

每个端口都是和它所在节点关联的。如果当前进程重新启动且绑定的端口未释放，这时候可能需要打开比在该 Ceph 节点上运行的守护进程所需的端口更多，即需要打开一些其他端口，以便在守护进程出现故障并不释放端口的情况下有端口可用。

所以，我们可以考虑在每个 OSD 节点上打开 6800:7300 范围内的端口；