什么是 BlueStore

https://baijiahao.baidu.com/s?id=1635414952916759127&wfr=spider&for=pc

https://zhuanlan.zhihu.com/p/45084771

什么是 BlueStore

在老版本的 Ceph 当中 FileStore 是默认的对象存储引擎,但 FileStore 最大的问题是写放大的问题。同时由于需要经过操作系统通用文件系统层(例如 Ext4 和 XFS 等),因此整体性能欠佳。因此,开发一种新的对象存储引擎迫在眉睫,这个就是现在大家都在使用的 BlueStore 对象存储引擎【在L版本之后作为默认的后端存储】。

BlueStore 最大的特点是构建在裸磁盘设备之上,并且对诸如 SSD 等新的存储设备做了很多优化工作。下图来自 Ceph 官方,该图是 BlueStore 的整体架构图。


图1 BlueStore 整体架构

也就是说 BlueStore 主要目的是对性能进行优化,以提升 Ceph 集群整体的性能。那么 BlueStore 对 Ceph 集群到底有多大的性能提升呢?

我们看看官方给出的性能测试数据。如下是 3 副本情况下的性能测试对比数据,从测试结果可以看出大多数场景下有了将近 1 倍的性能提升。


图2 3 副本性能测试对比

那对于纠删码场景下的性能提升情况又是怎么样的呢?看看下面的测试结果。


图3 纠删码性能对比

性能提升确实是很明显,接下来我们就要具体学习一下 BlueStore 的技术细节了。从图 1 可以看出 BlueStore 最大的特点是 OSD 可以直接管理裸磁盘设备,并且将对象数据存储在该设备当中。另外,我们知道对象有很多 KV 属性信息,这些信息之前是存储在文件的扩展属性或者 LevelDB 当中的。而在 BlueStore 中,这些信息存储在 RocksDB 当中。 RocksDB 本身是需要运行在文件系统之上的,因此为了使用 RocksDB 存储这些元数据,需要开发一个简单的文件系统( BlueFS )。

通过上面的整体架构可以看出,如果想彻底的了解 BlueStore ,对对象数据的分配管理和 BlueFS 的实现原理的理解是基础。因此,我们这里先分析上述 2 部分的内容。 RocksDB 是对元数据进行管理的子系统,因此我们先从 RocksDB 相关的内容讲起。

BlueFS 简析

从图 1 可以看出 BlueFS 是基础, RocksDB 通过中间层 BlueRocksDB 访问文件系统的接口。这个文件系统与传统的 Linux 文件系统(例如 Ext4 和 XFS )是不同的,它不是在 VFS 下面的通用文件系统,而是一个用户态的逻辑。 BlueFS 通过函数接口( API ,非 POSIX )的方式为 BlueRocksDB 提供类似文件系统的能力。

虽然 BlueFS 提供的接口方式不同,但起原理与通用文件系统是类似的。为了提高 BlueFS 文件系统的可靠性, BlueFS 被设计成日志文件系统,也就是数据在写入之前会先写上日志中,这样可以保证出现掉电等异常情况下可以通过日志恢复数据。

虽然从官方配图上(图 1 )来看, BlueFS 是基于裸设备的,实际上并非如此。 BlueFS 实际上基于 BlueStore 的磁盘空间分配器,也就是 BlueFS 使用的磁盘空间需要经过分配器来分配。 BlueStore 目前支持 2 种类型的磁盘空间分配器,分别是 BitMapAllocator 和 StupidAllocator 。


图4 BlueFS与分配器的关系

如图 4 是 BlueFS 文件系统与分配器之间的关系,其中分配器( Allocator )作为 BlueFS 的成员,当文件系统需要磁盘空间时通过分配器的接口分配空间。整个类的内容非常丰富,本文仅仅给出它们之间的简单关系,后续会详细介绍内部的实现。

关于上文所说的 BitMapAllocator 和 StupidAllocator 分配器继承自 Allocator 类,三者之间的关系如图 5 所示。关于分配器的具体实现细节还是比较复杂的,限于篇幅问题本文暂时不做介绍。


图 5 BlueFS 与分配器的关系

BlueFS 与传统文件系统不同另外一个地方是并没有设计单独存储 fnode 的存储空间,而是将其存储在 WAL ( Write Ahead Log )日志当中。当文件系统挂载的时候通过回放该日志实现内存数据结构的构建。这样,在内存中就可以查到磁盘中的目录和文件信息,从而可以实现对文件的读写。 BlueFS 本身就是一个功能阉割的,迷你文件系统。 BlueFS 可以这么实现得益于其只服务于 RocksDB ,其文件数量非常有限,使用场景也非常有限。

创建文件流程

为了更加清晰的理解 BlueFS 的整体架构和原理,我们通过一个具体的实例介绍该文件系统是如何运行的。由于 BlueFS 只服务于 RocksDB ,因此创建文件的流程自然也是由 RocksDB 触发的。因此,整个流程的分析也是从 RocksDB 的环境类作为入口进行介绍。在介绍具体流程之前,我们先看一下更加详细的 BlueFS 类的类图,这里面比较重要的是其中的 dir_map 和 file_map 两个成员。这两个成员其实就是存储文件系统中的目录和文件的一个映射。


图 6 文件系统类简图

创建文件的操作是由 RocksDB 触发的,比如创建一个新的 SSTable 文件。具体函数调用过程如图 7 左侧流程所示。最终调用的是 BlueFS 的事务接口,用于构建一个向日志文件写数据的事务。


图 7 创建文件流程

之后,上层会触发一个刷写数据的流程,具体如图 7 右侧所示,最终会将数据写到日志文件中。至此,一个新的文件就创建成功了。

今天我们非常粗略的介绍了一下 BlueStore 及 BlueFS 的整体架构和一些关键的数据结构,很多细节没有介绍,大家可能有一些迷糊。后续我们将深入细节介绍每个特性的具体实现。

posted @   飞飞6779  阅读(532)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· .NET10 - 预览版1新功能体验(一)
点击右上角即可分享
微信分享提示