Ceph存储后端ObjectStore架构和技术演进

Ceph是分布式和强一致性的软件定义存储产品，随着越来越多的企业和组织不断加入，Ceph存储系统稳定性、可靠性和易管理性得到了很大的提升，在版本演进和迭代中，Ceph存储的企业特性也得到了完善。如CephFS、iSCSI协议、InfiniBand网络等特性，但今天笔者将带领大家深入分析下Ceph最新后端存储BlueStore的架构和ObjectStore历史技术演进，因为存储后端的架构在一定程度上决定Ceph存储系统的性能。SUSE也是在最新Enterprise Storage 5版本中率先支持最新的BlueStore后端存储技术。

BlueStore是Ceph存储后端ObjectStore的最新实现。在Ceph系统中，数据首先通过Hash算法分布到每个节点OSD上，最终由ObjectStore写到磁盘上实现数据保存和持久化。那么，首先来看看ObjectStore架构。

ObjectStore架构介绍

Ceph后端支持多种存储引擎，这些存储后端模块是以插件式的方式被管理，目前支持的实现方式包括Filestore(默认存储后端)，KeyValue Store、Memstore、NewStore和最新的Bluestore。

从架构上来看，ObjectStore封装了下层存储引擎的所有IO操作，并向上层提供对象(Object)、事务(Transaction)语义接口。在这里，MemStore是基于内存的实现存储接口功能;KeyValue Store主要基于KV数据库(如LevelDB，RocksDB等)实现接口功能。

一直以来，FileStore是Ceph目前默认的ObjectStore后端存储引擎(仍然是其他Ceph存储的默认后端)，FileStore基于Journal机制实现了事务处理能力，除了支持事务特性(consistency、atomic等)以外，Journal还可将多个小IO写合并为顺序写Journal来提升系统性能。

ObjectStore接口主要包括三个部分，第一部分是Object的读写操作，类似于POSIX的部分接口;第二部分是Object的属性(xattr)读写操作，这类操作是KV操作，它与某一个Object关联;第三部分是关联Object的KV操作(在Ceph中称为omap)。

ObjectStore后端存储引擎之FileStore

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

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

ObjectStore后端存储引擎之NewStore

为了解决上述FileStore的问题，Ceph引入了新的存储引擎NewStore(又被称为KeyFile Store)，其关键结构如下图所示：

NewStore解耦Object与本地物理文件间的一一对应关系，通过索引结构(上图中ONode)在Object和本地物理文件建立映射关系，并使用KV数据库存储索引数据;在保证事务特性的同时，对于Object的操作无需Journal支持;在KV数据库上层建立Onode数据cache以加速读取操作;单个Object可以有多个fragement文件，多个Object也可共存于一个fragement文件，更加灵活。

ObjectStore后端存储引擎之BlueStore

NewStore使用RocksDB存储Ceph日志，同时Ceph的真正数据对象存储在文件系统中。如今有了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可以共享裸设备，也可以分别指定不同的设备。

当BlueFS和BlueStore共享设备时，裸设备通常被分为两部分:

设备的一部分为BlueFS的小分区，它实现了RocksDB所需的类似文件系统的功能。

设备的其余部分通常是占据设备其余部分的大分区。它由BlueStore直接管理，包含所有实际数据。

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

总结一下，从SUSE Enterprise storage 5存储版本开始，BlueStore成为Ceph的一个新的存储后端，它的性能优于FileStore，并提供完整的数据检验和和内置压缩能力。

FileStore将数据保存到与Posix兼容的文件系统(例如Btrfs、XFS、Ext4)。在Ceph后端使用传统的Linux文件系统尽管提供了一些好处，但也有代价，如性能、 对象属性与磁盘本地文件系统属性匹配存在限制等。

然而，NewStore存储后端技术 解耦Object与本地物理文件间的对应关系，通过KV数据库、索引技术优化日志操作。

B lueStore可使 数据对象无需任何文件系统的接口，就可以直接存储在物理块设备上，所以，B lueStore可以 极大的提升Ceph存储系统性能。