Ceph后端ObjectStore存储引擎实现和发展

Ceph作为一个高可用和强一致性的软件定义存储产品,目前在各行各业得到普遍应用，关于Ceph架构分析请参阅文章Ceph存储架构深度分析。今天我们主要Ceph后端存储引擎ObjectStore的实现方式和发展历程。Ceph后端支持多种存储引擎，以插件式的方式来进行管理，目前支持Filestore，Keyvalue Store，Memstore，NewStore以及最新的Bluestore，目前默认使用的Filestore。

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

ObjectStore后端存储引擎之NewStore

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

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里。

相关阅读

• 解析Ceph和9000分布式存储

• Ceph特性更新或再让OpenStack爱不释手

• Ceph存储架构深度分析

• 再谈Ceph这朵开源存储金花