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

? ? ? ? ? ? ? ? Ceph后端ObjectStore存储引擎实现和发展 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ceph作为一个高可用和强一致性的软件定义存储产品,目前在各行各业得到普遍应用，关于Ceph架构分析请参阅文章Ceph存储架构深度分析。今天我们主要Ceph后端存储引擎ObjectStore的实现方式和发展历程。Ceph后端支持多种存储引擎，以插件式的方式来进行管理，目前支持Filestore，Keyvalue Store，Memstore，NewStore以及最新的Bluestore，目前默认使用的Filestore。 ? ? ? ObjectStore层封装了下层存储引擎的所有IO操作，向上层提供对象(object)、事务(Transaction)语义的接口。MemStore为基于内存的实现；KeyValue Store主要基于KV数据库(如leveldb, RocksDB等)实现接口功能。 ? ? ? FileStore是Ceph目前默认的存储引擎(也是目前使用最多的存储引擎)，其事务实现基于Journal机制；除了支持事务特性(consistency、atomic等)外，Journal还可将多个小IO写合并为顺序写Journal来提升性能。 ? ? ? ? ObjectStore接口分主要为三部分，第一部分是Object的读写操作，类似于POSIX的部分接口，第二部分是Object的属性(xattr)读写操作，这类操作的特征是KV对并且与某一个Object关联。第三部分是关联Object的KV操作(在Ceph中称为omap)。 ? ObjectStore后端存储引擎之FileStore ? ? ? 目前ObjectStore的主要实现是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，系统性能差等。 ObjectStore后端存储引擎之NewStore ? ? ? 为了解决上述问题，Ceph引入新的存储引擎NewStore(又被称为Key File 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，用户可用实现