聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

解析Ceph: 存储引擎实现–KeyValueStore

2014-06-04 01:15 浏览: 2007844 次 我要评论(0 条) 字号:

KeyValueStore 是 Ceph 支持的另一个存储引擎(第一个是FileStore),它是在 Emporer 版本中Add LevelDB support to ceph cluster backend store Design Summit 上由本人提出并实现了原型系统,在 Firely 版本中实现了与 ObjectStore 的对接。目前已经合并到 Ceph 的 Master 上。

KeyValueStore 相对于 FileStore 是一个轻量级实现,目标是利用其不同 Backend 提供的能力来为 Ceph 的不同应用场景服务。如目前的默认 engine 是 LevelDB,期望来提供高性能的写性能。

在了解 KeyValueStore 之前可以先了解 ObjectStore 和 FileStore 解析Ceph: 存储引擎实现之一–FileStore

主要数据结构

Snip20140413_10

KeyValueStore 主要由三部分组成,一个是继承 ObjectStore 的 KeyValueStore 类,另一个是 GenericObjectMap(类似于 FileStore 的 DBObjectMap),最后一个是继承 GenericObjectMap 的 StripObjectMap。GenericObjectMap 是主要用来访问后端 Engine 的实现,它的作用有点类似 VFS,而 Engine 就是各种不同的 FileSystem,它抽象出一些基本的方法(read/write)和一些高级接口(rename/clone)等等,首先最初开始设计 GenericObjectMap的时候是打算直接利用已经存在的 FileStore 的 DBObjectMap,但是在一定的调查后发现 DBObjectMap 缺少一定的扩展性,很难在不破坏现有接口的前提下来实现,因此最后与 Sage 商定直接实现新的 ObjectMap。那么什么是 ObjectMap,正如在上篇 FileStore 文章中所述,ObjectMap 是利用 K/V 接口实现的一个多层次 Map,目的是让 OSD 最重要的 Object 具备一个独立和高效查找的 KV 空间,同时这个空间还能使用 no-copy 的 clone。

GenericObjectMap 在提供了一个面向 Object 的通用 KV 空间后,StripObjectMap 继承了 GenericObjectMap 实现了对 Object Data 的封装,ObjectStore 有三种类型的数据: Data, attr 和 Omap,后两者都是单一的 KV 实现,可以直接利用 GenericObjectMap 的原生接口实现,但是 Data 的接口是类似于 Posix 需要具备 Parity Write 的能力,因此简单的将一个 Object 的 Data 作为一个键值对是不合适的,需要做一个 Strip 的工作,将一个 Object 的 Data 根据一定宽度划分成多个键值对,这个工作就是由 StripObjectMap 来完成。

最后 KeyValueStore 类利用 StripObjectMap 来完成了对 ObjectStore 的方法实现。

主要 IO 路径

与 FileStore 的实现类似,KeyValueStore 也会产生一个消息队列,所有来自上层 PG 产生的 IO 请求都会先放入这个队列,然后会有多个 KeyValueStore 线程作为队列的消费者获取请求进行处理,因为 PG 天生的隔离性,目前 KeyValueStore 是利用 PG 作为一个隔离单元,同一时间只有一个线程处理同一个 PG 的请求。KeyValueStore 线程针对每一个请求会产生一个缓冲空间,因为一个请求作为一个事务会包含多个原子操作,为了保证事务的原子性和隔离性,每一个请求在中间阶段并不能写入到持久层,只能产生一些操作序列,而可能的副作用就需要被缓冲空间保存起来作为后续操作的上下文。最后 KeyValueStore 线程会提交这个请求来完成这次事务。

开发方向和适用场景

KeyValueStore 目前仍是 dev 状态,只适合用于测试和评估,它由于后端的一致性(FileStore实际上对接了多个后端)会更具备稳定性,相对于没有 clone 能力的文件系统(除了 Btrfs),KeyValueStore 提供了高效的 clone 操作,同时 KeyValueStore 的 GenericObjectMap 由于类似于 VFS 中 inode 的作用,但是由于其内置于应用端具备更好的灵活性,实际上提供更加高效的索引作用。目前在 rbd 应用场景中,最新的 KeyValueStore 在 LevelDB 后端下写性能已经超过 FileStore。

未来 KeyValueStore 会支持更多的后端如 Rocksdb 和 kinect API,适用场景将更加广阔。



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复