注意
本文档适用于 Ceph 的开发版本。
存储设备
存储集群中有几个 Ceph 守护进程
Ceph OSD（对象存储守护进程）存储 Ceph 中的大部分数据。通常每个 OSD 由一个存储设备提供支持。这可以是传统的硬盘驱动器（HDD）或固态驱动器（SSD）。OSD 也可以由设备的组合提供支持：例如，HDD 用于大部分数据，SSD（或 SSD 的分区）用于某些元数据。集群中 OSD 的数量通常是待存储数据量、每个存储设备的大小以及指定的冗余级别和类型（复制或纠删码）的函数。
Ceph Monitor守护进程管理关键的集群状态。这包括集群成员资格和身份验证信息。小型集群只需要几 GB 的存储空间来保存监视器数据库。然而，在大型集群中，监视器数据库的大小可以达到几十 GB 到几百 GB。
Ceph Manager守护进程与监视器守护进程一起运行，提供额外的监视以及与外部监视和管理系统的接口。
OSD 后端
OSD 有两种管理其存储数据的方式。从 Luminous 12.2.z 版本开始，默认（且推荐）的后端是 BlueStore。在 Luminous 版本之前，默认（且唯一）的后端是 Filestore。
BlueStore
BlueStore 是一种专用的存储后端，专门用于为 Ceph OSD 工作负载管理磁盘上的数据。BlueStore 的设计基于十年支持和管理 Filestore OSD 的经验。
BlueStore 的主要功能包括
直接管理存储设备。BlueStore 消耗原始块设备或分区。这避免了介入的抽象层（例如 XFS 等本地文件系统），这些抽象层可能会限制性能或增加复杂性。
使用 RocksDB 进行元数据管理。嵌入了 RocksDB 的键/值数据库，用于管理内部元数据，包括对象名称到磁盘上块位置的映射。
完整的数据和元数据校验和。默认情况下，写入 BlueStore 的所有数据和元数据都受到一个或多个校验和的保护。在未经验证的情况下，不会从磁盘读取数据或元数据并将其返回给用户。
内联压缩。数据可以选择在写入磁盘之前进行压缩。
多设备元数据分层。BlueStore 允许将其内部日志（预写日志）写入单独的高速设备（如 SSD、NVMe 或 NVDIMM），以提高性能。如果可用大量更快的存储空间，则内部元数据可以存储在更快的设备上。
高效的写时复制。RBD 和 CephFS 快照依赖于在 BlueStore 中高效实现的写时复制克隆机制。这使得常规快照和纠删码池（它们依赖克隆来实现高效的两阶段提交）的 I/O 都高效。
有关更多信息，请参阅 BlueStore 配置参考 和 BlueStore 迁移。
FileStore
警告
FileStore 已在 Reef 版本中弃用，不再受支持。
FileStore 是在 Ceph 中存储对象的传统方法。它依赖于标准文件系统（通常是 XFS）与键/值数据库（传统上是 LevelDB，现在是 RocksDB）的组合来实现某些元数据。
FileStore 经过充分测试，并在生产中广泛使用。然而，由于其整体设计以及对用于对象数据存储的传统文件系统的依赖，它存在许多性能缺陷。
尽管 FileStore 能够在大多数兼容 POSIX 的文件系统（包括 btrfs 和 ext4）上运行，但我们建议 Ceph 仅使用 XFS 文件系统。btrfs 和 ext4 都有已知的错误和缺陷，使用它们可能会导致数据丢失。默认情况下，所有 Ceph 配置工具都使用 XFS。
有关更多信息，请参阅 Filestore 配置参考。