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

存储 存储软件
Ceph是分布式和强一致性的软件定义存储产品,随着越来越多的企业和组织不断加入,Ceph存储系统稳定性、可靠性和易管理性得到了很大的提升,在版本演进和迭代中,Ceph存储的企业特性也得到了完善。

 Ceph是分布式和强一致性的软件定义存储产品,随着越来越多的企业和组织不断加入,Ceph存储系统稳定性、可靠性和易管理性得到了很大的提升,在版本演进和迭代中,Ceph存储的企业特性也得到了完善。如CephFS、iSCSI协议、InfiniBand网络等特性,但今天笔者将带领大家深入分析下Ceph***后端存储BlueStore的架构和ObjectStore历史技术演进,因为存储后端的架构在一定程度上决定Ceph存储系统的性能。SUSE也是在***Enterprise Storage 5版本中率先支持***的BlueStore后端存储技术。

[[240689]]

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

责任编辑:武晓燕 来源: 架构师技术联盟
相关推荐

2020-10-20 09:38:15

分布式存储Ceph

2015-04-03 10:43:49

2018-04-13 08:44:40

存储大型网站

2009-11-26 17:21:38

智能弹性架构技术

2021-09-02 16:10:57

系统数据存储

2018-12-05 06:59:20

SD-WAN网络架构软件定义网络

2021-07-07 10:00:03

深度学习系统机构

2022-08-28 09:05:34

分布式存储Ceph

2024-03-06 11:22:33

架构演进技巧

2018-10-29 12:42:23

Ceph分布式存储

2017-12-06 14:35:01

OpenStackCeph存储

2021-08-03 07:21:14

架构微服务开发

2022-03-04 12:01:06

架构师互联网业务

2018-05-22 08:37:02

Ceph存储存储系统

2023-06-08 05:58:28

数据库纠删码技术

2016-06-15 14:21:09

2018-08-31 17:37:52

intel云计算AI

2017-03-08 11:10:30

存储网络闪存

2018-03-27 10:06:26

对象存储演进

2018-09-21 11:00:58

Ceph存储系统
点赞
收藏

51CTO技术栈公众号