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

? ? ? ? ? ? ? ? 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技术，数据对象可以无需任何文件系统的接口