ITPub博客

首页 > IT基础架构 > 服务器存储 > Ceph存储后端ObjectStore架构和技术演进

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

服务器存储 作者:HitTwice 时间:2018-08-17 20:45:18 0 删除 编辑

作者:晗狄 来源:微信公众号(架构师技术联盟)

原文链接: https://mp.weixin.qq.com/s/-sArdh5LUcjGDYxzUjfwaw

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存储系统性能。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31473948/viewspace-2200324/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2017-07-06

  • 博文量
    133
  • 访问量
    231617