前文我们创建了一个单节点的Ceph集群,并且创建了2个基于BlueStore的OSD。同时,为了便于学习,这两个OSD分别基于不同的布局,也就是一个OSD是基于3中不同的存储介质(这里是模拟的,并非真的不同介质),另外一个OSD所有内容放在一个裸设备上。
在老版本的Ceph当中FileStore是默认的对象存储引擎,但FileStore最大的问题是写放大的问题。同时由于需要经过操作系统通用文件系统层(例如Ext4和XFS等),因此整体性能欠佳。因此,开发一种新的对象存储引擎迫在眉睫,这个就是现在大家都在使用的BlueStore对象存储引擎。BlueStore最大的特点是构建在裸磁盘设备之上,并且对诸如SSD等新的存储设备做了很多优化工作。下图来自Ceph官方,该图是BlueStore的整体架构图。
性能提升确实是很明显,接下来我们就要具体学习一下BlueStore的技术细节了。从图1可以看出BlueStore最大的特点是OSD可以直接管理裸磁盘设备,并且将对象数据存储在该设备当中。另外,我们知道对象有很多KV属性信息,这些信息之前是存储在文件的扩展属性或者LevelDB当中的。而在BlueStore中,这些信息存储在RocksDB当中。RocksDB本身是需要运行在文件系统之上的,因此为了使用RocksDB存储这些元数据,需要开发一个简单的文件系统(BlueFS)。
通过上面的整体架构可以看出,如果想彻底的了解BlueStore,对对象数据的分配管理和BlueFS的实现原理的理解是基础。因此,我们这里先分析上述2部分的内容。RocksDB是对元数据进行管理的子系统,因此我们先从RocksDB相关的内容讲起。
从图1可以看出BlueFS是基础,RocksDB通过中间层BlueRocksDB访问文件系统的接口。这个文件系统与传统的Linux文件系统(例如Ext4和XFS)是不同的,它不是在VFS下面的通用文件系统,而是一个用户态的逻辑。BlueFS通过函数接口(API,非POSIX)的方式为BlueRocksDB提供类似文件系统的能力。
虽然BlueFS提供的接口方式不同,但起原理与通用文件系统是类似的。为了提高BlueFS文件系统的可靠性,BlueFS被设计成日志文件系统,也就是数据在写入之前会先写上日志中,这样可以保证出现掉电等异常情况下可以通过日志恢复数据。
虽然从官方配图上(图1)来看,BlueFS是基于裸设备的,实际上并非如此。BlueFS实际上基于BlueStore的磁盘空间分配器,也就是BlueFS使用的磁盘空间需要经过分配器来分配。BlueStore目前支持2种类型的磁盘空间分配器,分别是BitMapAllocator和StupidAllocator。
为了更加清晰的理解BlueFS的整体架构和原理,我们通过一个具体的实例介绍该文件系统是如何运行的。由于BlueFS只服务于RocksDB,因此创建文件的流程自然也是由RocksDB触发的。因此,整个流程的分析也是从RocksDB的环境类作为入口进行介绍。在介绍具体流程之前,我们先看一下更加详细的BlueFS类的类图,这里面比较重要的是其中的dir_map
和file_map
两个成员。这两个成员其实就是存储文件系统中的目录和文件的一个映射。
联系客服