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。
有关详细信息，请参阅文件存储配置参考。
标签：存储,BlueStore,FileStore,Ceph,集群,存储设备,数据,OSD 来源： https://www.cnblogs.com/varden/p/15967467.html