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

栏目: 服务器 · 发布时间: 6年前

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

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

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

BlueStore是Ceph存储后端ObjectStore的最新实现。在Ceph系统中,数据首先通过Hash算法分布到每个节点OSD上,最终由ObjectStore写到磁盘上实现数据保存和持久化。那么,首先来看看ObjectStore架构。

Ceph存储后端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),其关键结构如下图所示:

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

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整体架构如下。

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

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


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

计算几何

计算几何

周培德 / 清华大学出版社 / 2011-9 / 82.00元

《计算几何--算法设计与分析(第4版)》(作者周培德)系统地介绍了计算几何中的基本概念、求解诸多问题的算法及复杂性分析,概括了求解几何问题所特有的许多思想方法、几何结构与数据结构。全书共分10章,包括:预备知识,几何查找(检索),多边形,凸壳及其应用,Voronoi图、三角剖分及其应用,交与并及其应用,多边形的获取及相关问题,几何体的划分与等分,路径与回路,几何拓扑网络设计等。 《计......一起来看看 《计算几何》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

MD5 加密
MD5 加密

MD5 加密工具