Storage Devices

存储集群中有几个 Ceph 守护进程：

Ceph OSDs（对象存储守护进程）存储了 Ceph 中大部分数据。通常每个 OSD 都由一个存储设备支持。这可以是一个传统硬盘 (HDD) 或固态硬盘 (SSD)。OSD 也可以由设备的组合支持：例如，用 HDD 存储大部分数据，用 SSD（或 SSD 的分区）存储一些元数据。集群中 OSD 的数量通常取决于要存储的数据量、每个存储设备的大小以及指定的冗余级别和类型（复制或纠删码）。
Ceph监控器守护进程管理关键集群状态。这包括集群成员资格和认证信息。小型集群只需要几 GB 的存储空间来存储监控数据库。然而，在大型集群中，监控数据库的大小可以达到几十 GB 到几百 GB。
Ceph管理器守护进程与监控守护进程一起运行，提供额外的监控并提供接口以连接外部监控和管理系统。

OSD 后端

OSD 管理它们存储的数据有两种方式。截至 Luminous 12.2.z 版本，默认（也是推荐）的后端是 bd3f32: BlueStore。在 Luminous 发布之前，默认（也是唯一）的后端是 c4d065: FilestoreBlueStore. Prior to the Luminous release, the default (and only) back end was Filestore.

BlueStore

BlueStore 是一个专门为管理 Ceph OSD 工作负载磁盘上的数据而设计的专用存储后端。BlueStore 的设计基于十年来支持和管理 Filestore OSD 的经验。

BlueStore 的主要特性包括：

直接管理存储设备。BlueStore 消耗原始块设备或分区。这避免了可能限制性能或增加复杂性的中间抽象层（例如本地文件系统如 XFS）。
使用 RocksDB 进行元数据管理。RocksDB 的键值数据库嵌入其中，以管理内部元数据，包括对象名称到磁盘上块位置的映射。
完整的数据和元数据校验和。默认情况下，写入 BlueStore 的所有数据和元数据都由一个或多个校验和保护。没有数据或元数据从磁盘读取或返回给用户，而没有经过验证。
内联压缩。数据可以在写入磁盘之前选择性地进行压缩。
多设备元数据分层。BlueStore 允许其内部日志（预写日志）写入到单独的高速设备（如 SSD、NVMe 或 NVDIMM）以提高性能。如果有很多更快的存储可用，内部元数据可以存储在更快的设备上。
高效的写时复制。RBD 和 CephFS 快照依赖于 BlueStore 中高效实现的写时复制机制。这为常规快照和纠删码池（它们依赖于克隆来高效实现两阶段提交）都带来了高效的 I/O。clone mechanism that is implemented efficiently in BlueStore. This results in efficient I/O both for regular snapshots and for erasure-coded pools (which rely on cloning to implement efficient two-phase commits).

更多信息，请参阅BlueStore Configuration Reference和BlueStore 迁移.

FileStore

警告

Filestore 在 Reef 发布中已被弃用，不再受支持。

FileStore 是 Ceph 中存储对象的传统方法。它依赖于标准文件系统（通常是 XFS）以及用于某些元数据的键值数据库（传统上是 LevelDB，现在改为 RocksDB）。

FileStore 经过充分测试并在生产中广泛使用。然而，由于其整体设计和依赖传统文件系统来存储对象数据，它在性能方面存在许多缺陷。

虽然 FileStore 能够在大多数 POSIX 兼容文件系统（包括 btrfs 和 ext4）上运行，但我们建议仅使用 XFS 文件系统与 Ceph 一起使用。btrfs 和 ext4 都存在已知错误和缺陷，使用它们可能导致数据丢失。默认情况下，所有 Ceph 基础设施工具都使用 XFS。

更多信息，请参阅Filestore 配置参考.

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.