简单解析Ceph底层存储引擎Bluestore与Filestore

最近在群里看到群友们聊到了ceph的底层存储引擎Bluestore。不由得眼前一亮，之前没有过多了解过底层的存储引擎，所以就通过百度及官网文档简单了解了一下异同点。

FileStore是Ceph目前默认的存储引擎(也是目前使用最多的存储引擎)，其事务实现基于Journal机制；除了支持事务特性(consistency、atomic等)外，Journal还可将多个小IO写合并为顺序写Journal来提升性能。

底层存储引擎接口分主要为三部分，第一部分是Object的读写操作，类似于POSIX的部分接口，第二部分是Object的属性(xattr)读写操作，这类操作的特征是KV对并且与某一个Object关联。第三部分是关联Object的KV操作(在Ceph中称为omap)。

Filestore：

架构图：

FileStore，利用文件系统的POSIX接口实现ObjectStore API。每个Object在FileStore层会被看成是一个文件，Object的属性(xattr)会利用文件的xattr属性存取，因为有些文件系统(如Ext4)对xattr的长度有限制，因此超出长度的Metadata会被存储在DBObjectMap里。而Object的KV关系则直接利用DBObjectMap实现。

但是FileStore存在一些问题，例如Journal机制使一次写请求在OSD端变为两次写操作(同步写Journal，异步写入Object)；通过SSD用作Journal以解耦Journal和object写操作的相互影响；写入的每个Object都一一对应OSD本地文件系统的一个物理文件，对于大量小Object存储场景，OSD端无法缓存本地所有文件的元数据，使读写操作可能需要多次本地IO，系统性能差等。

Bluestore：

架构图：

BlueStore技术，数据对象可以无需任何文件系统的接口而直接存储在物理块设备上。

BlueStore初衷就是为了减少写放大，并针对SSD做优化，而且直接管理裸盘，从理论上进一步规避文件系统如ext4、xfs等部分的开销，BlueStore是一个全新的 OSD存储后端,采用块设备提示存储性能；Bluestore整体架构如下。

BlueStore直接管理裸设备，抛弃了本地文件系统，BlockDevice实现在用户态下直接对裸设备进行I/O操作。既然是直接管理裸设备就必然需要进行裸设备的空间管理，对应的就是Allocator，目前支持Stupid Allocator和Bitmap Allocator两种分配器。

相关的元数据以KV的形式保存到KV数据库里，默认使用的是RocksDB，RocksDB本身虽然是基于文件系统，不能直接操作裸设备，但是RocksDB可将系统相关的处理抽象成Env，用户可用实现相应的接口来操作。RocksDB默认的Env是PosixEnv，直接对接本地文件系统。为此Bluestore实现了一个BlueRocksEnv来为RocksDB提供底层系统的封装，实现了一个小的文件系统BlueFS对接BlueRocksEnv，在系统启动挂载这个文件系统的时候将所有的元数据都加载到内存中，BluesFS的数据和日志文件都通过BlockDevice保存到裸设备上，BlueFS和BlueStore可以共享裸设备，也可以分别指定不同的设备。

在之前的存储引擎Filestore里，对象的表现形式是对应到文件系统里的文件，默认4MB大小的文件，但是在目前最新的ObjectStore实现——Bluestore里，已经没有传统的文件系统，而是自己管理裸盘，需要管理对象Onode常驻内存的数据结构，持久化的时候会以KV的形式存到RocksDB里。

总结：

简单总结一下，FileStore是目前默认的存储引擎，基于POSIX接口实现ObjectStore API，对象跟文件对应，对象属性与磁盘本地文件系统属性匹配存在限制；NewStore解耦Object与本地物理文件间的对应关系，通过KV数据库、索引技术优化日志操作。BlueStore可以使数据对象可以无需任何文件系统的接口而直接存储在物理块设备上，极大的提升Ceph系统性能。

（文章存在引用他人资料，网址找不到了，如有侵权，请与我联系，我会备注原作者）