【Ceph RADOS】BlueStore 架构：BlockDevice、BlueFS、RocksDB 与 Allocator
内容提要
本文介绍Ceph BlueStore架构，替代FileStore解决双写与目录元数据问题。核心组件包括BlockDevice（裸盘I/O）、BlueFS（RocksDB专用文件系统）、RocksDB（对象元数据存储）和Allocator（空闲空间管理）。BlueStore将数据直写裸盘，元数据存KV，支持校验和与压缩，但面临compaction带宽竞争和挂载延迟等挑战。
延伸解读
BlueStore 的组件划分与设计动机
BlueStore 将数据面（BlockDevice + Allocator）与元数据面（RocksDB + BlueFS）分离，避免通用文件系统的语义阻抗失配。BlockDevice 只处理裸盘 I/O，不理解对象语义；元数据全部存入 RocksDB，由 BlueFS 提供最小文件系统支持。这种设计消除了 FileStore 的双写和目录元数据问题，但也引入了新的运维挑战，如 compaction 带宽竞争和挂载延迟。
Allocator 重建延迟与挂载时间
OSD 启动时需从 RocksDB 的 PREFIX_ALLOC 重建内存 Allocator，在数亿小对象场景下可能耗时数分钟，期间 OSD 不可服务，影响 PG peering。allocator image 功能可缓解，但默认开启条件需按 Squid 文档核对。运维中可通过 OSD 日志的 store open latency 观察此问题。
RocksDB compaction 与前台 I/O 的竞争
RocksDB compaction 不受 OSD mClock 调度器控制，高并发写时可能抢占带宽，导致客户端写延迟毛刺。即使 WAL 独立于 NVMe，SST 合并仍可能打满 DB 盘或与数据盘争带宽。可通过 ceph tell osd.N perf dump 观察 rocksdb compaction 计数与 op 延迟的相关性。
Q&A
Ceph BlueStore 相比 FileStore 解决了哪些核心问题？
BlueStore 解决了 FileStore 的双写问题（数据先写 Journal 再写文件系统，导致磁盘带宽减半）、目录元数据问题（百万级文件导致 readdir 慢和 directory splitting 性能暴跌），以及新硬件接口（如 SMR、ZNS）适配问题。它通过数据直写裸盘、元数据存入 RocksDB 来消除语义阻抗失配。
BlueStore 的四个核心组件分别负责什么？
BlockDevice 封装裸块设备的异步 I/O，不理解对象语义；BlueFS 为 RocksDB 提供最小文件系统，只存 WAL 和 SSTable；RocksDB 管理对象元数据（onode、blob、extent map）和延迟写 WAL；Allocator 在内存中维护裸盘空闲区间，负责分配和持久化。
BlueFS 和通用文件系统（如 XFS）有什么区别？
BlueFS 是专为 RocksDB 设计的用户态文件系统，只提供 RocksDB 所需的接口子集，元数据保存在 journal 中，mount 时装入内存，不维护独立 freelist。通用文件系统面向任意 POSIX 应用，有完整 VFS 和持久化 inode/目录，崩溃恢复语义复杂。BlueFS 避免了通用文件系统的一致性税，让 RocksDB 的 WAL/SST 落在受控裸盘路径上。
BlueStore 中对象元数据是如何存储在 RocksDB 中的？
每个 RADOS 对象对应一个 onode，存储在 PREFIX_OBJ 前缀下，包含 size、attrs、extent_map 等。extent_map 将逻辑区间映射到 blob，blob 再指向物理 extent。校验和也随 blob 元数据存入 RocksDB。此外还有 PREFIX_SUPER、PREFIX_STAT、PREFIX_COLL、PREFIX_OMAP、PREFIX_DEFERRED、PREFIX_ALLOC、PREFIX_SHARED_BLOB 等前缀分别存储不同元数据。
BlueStore 的 Allocator 有哪些实现？默认是什么？
BlueStore 提供 BitmapAllocator（bitmap）、StupidAllocator（stupid）、AvlAllocator（avl）、HybridAllocator（hybrid）等实现。Squid v19.2.5 的默认值需通过 `ceph config get osd bluestore_allocator` 查询，社区在 Quincy/Reef/Squid 周期内多次调整默认值。
BlueStore 挂载延迟（Mount Latency）问题是什么？如何缓解？
OSD 启动时需从 RocksDB 的 PREFIX_ALLOC 重建内存 Allocator，当管理数亿小对象时，重建可能耗时数分钟，期间 OSD 不可服务，影响 PG peering。缓解措施是 allocator image 功能，将 Allocator 状态快照写入裸盘固定区域，重启时直接加载，但该功能默认开启条件需以 Squid 官方文档为准。
RocksDB compaction 对 BlueStore 性能有什么影响？
RocksDB compaction 会与 OSD 写 I/O 竞争带宽，即使 WAL 在独立 NVMe 上，SST 合并也可能打满 DB 盘或与共置数据争带宽，导致客户端写延迟毛刺。mClock 调度器不直接控制 compaction 的触发时机和 I/O 速率，因此高并发写场景下问题更明显。
BlueStore 支持哪些块设备实现？SPDK 路径有什么优缺点？
BlueStore 支持 KernelDevice（默认，使用 Linux AIO）、HMSMRDevice（面向 Host-Managed SMR 磁盘）、NVMEDevice（可选，通过 SPDK 用户态驱动）。SPDK 路径理论上消除内核块层延迟，但需要独占 CPU core 轮询，且与 iostat、nvme-cli 等工具链脱节，运维代价高，生产采用率有限。
