Ceph 存储集群配置之存储设备
有两个 Ceph 守护进程在设备上存储数据:
-
Ceph OSD(或对象存储守护进程)是 Ceph 中大部分数据的存储位置。一般来说,每个 OSD 都由单个存储设备支持,例如传统硬盘 (HDD) 或固态硬盘 (SSD)。OSD 也可以由设备组合支持,例如用于大多数数据的 HDD 和用于某些元数据的 SSD(或 SSD 的分区)。集群中的 OSD 数量通常取决于将存储多少数据、每个存储设备有多大以及冗余级别和类型(复制或纠删码)。
-
Ceph Monitor守护进程管理关键的集群状态,如集群成员和身份验证信息。对于较小的集群,只需要几 GB 即可,但对于较大的集群,监控数据库可以达到数十甚至数百 GB。
OSD 后端
OSD 可以通过两种方式管理它们存储的数据。从 Luminous 12.2.z 版本开始,新的默认(推荐)后端是 BlueStore。在 Luminous 之前,默认(也是唯一的选项)是 Filestore。
BlueStore
BlueStore 是一个专用存储后端,专为管理 Ceph OSD 工作负载的磁盘数据而设计。它的灵感来自过去十年使用 FileStore 支持和管理 OSD 的经验。BlueStore 的主要功能包括:
-
直接管理存储设备。BlueStore 使用原始块设备或分区。这避免了可能限制性能或增加复杂性的任何中间抽象层(例如 XFS 等本地文件系统)。
-
使用 RocksDB 进行元数据管理。我们嵌入 RocksDB 的键/值数据库来管理内部元数据,例如从对象名称到磁盘上块位置的映射。
-
完整的数据和元数据校验和。默认情况下,写入 BlueStore 的所有数据和元数据都受一个或多个校验和保护。未经验证,不会从磁盘读取数据或元数据或将数据或元数据返回给用户。
-
内联压缩。写入的数据在写入磁盘之前可以选择压缩。
-
多设备元数据分层。BlueStore 允许将其内部日志(预写日志)写入单独的高速设备(如 SSD、NVMe 或 NVDIMM)以提高性能。如果有大量更快的存储可用,内部元数据也可以存储在更快的设备上。
-
高效的写时复制。RBD 和 CephFS 快照依赖于在 BlueStore 中高效实现的写时复制克隆机制。这为常规快照和纠删码池(依赖克隆来实现高效的两阶段提交)带来了高效的 IO。
有关详细信息,请参阅 BlueStore 配置参考和 BlueStore 迁移。
FileStore
FileStore 是在 Ceph 中存储对象的传统方法。它依赖于标准文件系统(通常是 XFS)和键/值数据库(传统上是 LevelDB,现在是 RocksDB)来获取一些元数据。
FileStore 经过良好测试并在生产中广泛使用,但由于其整体设计和依赖于传统文件系统来存储对象数据,因此存在许多性能缺陷。
尽管 FileStore 通常能够在大多数与 POSIX 兼容的文件系统(包括 btrfs 和 ext4)上运行,但我们只建议使用 XFS。btrfs 和 ext4 都有已知的错误和缺陷,使用它们可能会导致数据丢失。默认情况下,所有 Ceph 配置工具都将使用 XFS。
有关详细信息,请参阅文件存储配置参考。