ceph后端存储引擎

现在是2020年4月，ceph的发展已经到了BlueStore替代FileStore。在此记录一下对ceph后端存储引擎的发展经过，BlueStore的研发原因，即FileStore的缺陷，BlueStore当前的架构，优势，劣势以及当前BlueStore的痛点，即可以发力优化的方向。

首先，为什么会孕育BlueStore，这要说到FileStore的架构设计上的痛点。重点关注点为ceph OSD对来自客户端的I/O请求。OSD内部提供抽象接口ObjectStore。这个ObjectStore是ceph osd最最重要的概念之一，它封装了所有对底层存储的IO操作。它提供读写的事务API。

ObjectStore主要接口有三部分：1.Object读写操作（相当于POSIX）；2.Object的属性读写操作；3.关联Object的kv操作（omap）

ceph后端存储引擎的发展 

最初实现：EBOFS（Extent and B-Tree-based Object File System），就是一个文件系统，但缺少事务（ACID）和校验和（保证数据的完整性和准确性）。

Btrfs作为FileStore的存储后端：提供了事务，校验，数据去重功能。但是该文件系统存在碎片化现象严重的问题。

XFS作为FileStore的存储后端：仍然有元数据碎片化问题，无法充分利用硬件设备性能。同时缺少事务支持，需要额外实现WAL机制提供事务功能。

NewStore：将对象的元数据和对象数据进行分离，引入kv数据库优化了元数据管理。但文件系统层面仍然存在写放大问题。

总的来说，FileStore中，元数据管理和写放大问题成为限制ceph性能的原因。

BlueStore

BlueStore将数据直接保存在存储设备中，而元数据先保存在RocksDB中，在通过一个给RocksDB定制的轻量级文件系统BlueFS将数据持久化至存储设备中。这样设计，可以使元数据只存在于RocksDB，无需视图保证kv store与文件系统中元数据一致，可以更高效地支持事务。（事务的特征是ACID，即原子性，一致性，隔离性，持久性。要实现事务，可以有两种方案，一种是使用文件系统内部的事务机制，涉及到内核操作，不现实；还有一种方案是在用户态实现WAL，即Write-Ahead-Log，先写日志再持久化到磁盘，但是这会导致频繁调用fsync以持久WAL和数据，使用kv Store可以缓解开销，但是保证kv Store与文件系统中的元数据一致性又会引入新的开销。在BlueStore的涉及中，元数据只放在kv Store中，也就不需要做kv Store与文件系统的一致性，从而提高事务的效率）

再者，BlueStore中通过元数据的键值前缀将其组织成不同的Namespace，这样，可以将元数据键值前K位相同的文件定义成属于统一文件夹，这样，通过改变K的值可以快速实现文件夹分裂。（因为在ceph中常常要对特定目录下的文件进行遍历，这一操作会随着目录文件数量的增长而下降，同时只返回无序结果。利用传统文件系统解决这个问题，需要文件尽量均匀分布在各个目录，当文件数量超过阈值，对目录进行分裂操作，inode数量增多，即目录数量增加，不仅会则更加dentry cache的效率，即目录项高速缓存效率降低，也增加小型I/O操作的次数，甚至使得数据分布更加零散，降低了空间局部性。空间局部性是指一旦一个指令一个存储单元被访问，那么它附近的单元也将很快被访问。空间局部性降低，势必会影响访问效率）

还有一点，由于BlueStore拥有对I/O栈的完全控制，可以自由决定使用哪种硬件接口，同时由于COW的更新方式，BlueStore可以很好的兼容Zoned Interface。

BlueStore目前存在的问题

1.BlueStore需要自己实现页缓存动态调整大小的机制，面对拥有超高存储性能的NVMe SSD，缓存需要更加高效才能减小SSD的写负载。

2.引入RocksDB带来的问题：压缩机制和写放大问题成为了主要性能限制。（为什么会成为瓶颈？）

3.RocksDB有自己的线程模型，限制了自定义分片的能力。

4.跨越内核的存储后端控制几乎所有的内存，内存的优化和隔离机制需要手动实现。