bluestore

slhywll

已于 2023-04-13 10:49:39 修改

阅读量202

点赞数 1

分类专栏： ceph bluestore 文章标签： ceph

于 2023-04-13 10:47:59 首次发布

本文链接：https://blog.csdn.net/slhywll/article/details/130125074

版权

ceph 同时被 2 个专栏收录

9 篇文章 1 订阅

订阅专栏

bluestore

3 篇文章 0 订阅

订阅专栏

BlueStore

BlueStore 架构及原理分析

Ceph 底层存储引擎经过了数次变迁，目前最常用的是 BlueStore，在 Jewel 版本中引入，用来取代 FileStore。与 FileStore 相比，Bluesore 越过本地文件系统，直接操控裸盘设备，使得 I/O 路径大大缩短，提高了数据读写效率。并且，BlueStore 在设计之初就是针对固态存储，对目前主力的 SATA SSD 有着更好的支持（相比 FileStore），同时也支持 Nvme SSD 超高速固态。在数据的处理上，BlueStore 选择把元数据和对象数据分开存储，使用高速设备来保存元数据，能够起到性能优化作用。

原文链接：https://blog.csdn.net/DeamonXiao/article/details/120866790

BlueStore 架构图

在这里插入图片描述

BlueStore 把数据分成两条路径。一条是 data 直接通过 Allocator（磁盘空间分配器）分配磁盘空间，然后写入 BlockDevice。另一条是 metadata 先写入 RocksDB（内存数据库），通过 BlueFs（BlueStore 专用文件系统）来管理 RocksDB 数据，经过 Allocator 分配磁盘空间后落入 BlockDevice

BlueStore 把元数据和对象数据分开写，对象数据直接写入硬盘，而元数据则先写入超级高速的内存数据库，后续再写入稳定的硬盘设备，这个写入过程由 BlueFS 来控制。

RocksDB 架构

Rocksdb 是基于Google LevelDB研发的高性能kv持久化存储引擎，以库组件形式嵌入程序中，为大规模分布式应用在ssd上运行提供优化。RocksDB不提供高层级的操作，例如备份、负载均衡、快照等，而是选择提供工具支持将实现交给上层应用。正是这种高度可定制化能力，允许RocksDB对广泛的需求和工作负载场景进行定制。
RocksDB使用Log-Structured Merge（LSM）trees做为基本的数据存储结构。

RocksDB主要组成 & 读、写和压缩操作流程图解

BlueStore策略

BlockSize：磁盘IO操作的最小单元(原子操作)。HDD为512B，SSD为4K。即读写的数据就算少于 BlockSize，磁盘I/O的大小也是 BlockSize，是原子操作，要么写入成功，要么写入失败，即使掉电不会存在部分写入的情况。

RWM(Read-Modify-Write)：指当覆盖写发生时，如果本次改写的内容不足一个BlockSize，那么需要先将对应的块读上来，然后再内存中将原内容和待修改内容合并Merge，最后将新的块写到原来的位置。但是RMW也带来了两个问题：一是需要额外的读开销；二是RMW不是原子操作，如果磁盘中途掉电，会有数据损坏的风险。为此我们需要引入Journal，先将待更新数据写入Journal，然后再更新数据，最后再删除Journal对应的空间。

COW(Copy-On-Write)：指当覆盖写发生时，不是更新磁盘对应位置已有的内容，而是新分配一块空间，写入本次更新的内容，然后更新对应的地址指针，最后释放原有数据对应的磁盘空间。理论上COW可以解决RMW的两个问题，但是也带来了其他的问题：一是COW机制破坏了数据在磁盘分布的物理连续性。经过多次COW后，读数据的顺序读将会便会随机读。二是针对小于块大小的覆盖写采用COW会得不偿失。是因为：一是将新的内容写入新的块后，原有的块仍然保留部分有效内容，不能释放无效空间，而且再次读的时候需要将两个块读出来Merge操作，才能返回最终需要的数据，将大大影响读性能。二是存储系统一般元数据越多，功能越丰富，元数据越少，功能越简单。而且任何操作必然涉及元数据，所以元数据是系统中的热点数据。COW涉及空间重分配和地址重定向，将会引入更多的元数据，进而导致系统元数据无法全部缓存在内存里面，性能会大打折扣。

在这里插入图片描述

BlueStore的写策略综合运用了COW和RMW策略。

非覆盖写直接分配空间写入即可；

块大小对齐的覆盖写采用COW策略；

小于块大小的覆盖写采用RMW策略。

BlueFS

RocksDB是基于本地文件系统的，但是文件系统的许多功能对于RocksDB不是必须的，所以为了提升RocksDB的性能，需要对本地文件系统进行裁剪。最直接的办法便是为RocksDB量身定制一套本地文件系统，BlueFS便应运而生。

BlueFS是个简易的用户态日志型文件系统，恰到好处的实现了RocksDB::Env所有接口。根据设计理念这一章节，我们知道引入Journal是为了进行写加速，WAL对于提升RocksDB的性能至关重要，所以BlueFS在设计上支持把.log和.sst分开存储，.log使用速度更快的存储介质(NVME等)。

在引入BlueFS后，BlueStore将所有存储空间从逻辑上分了3个层次：
慢速空间(Block)：存储对象数据，可以使用HDD，由BlueStore管理。
高速空间(DB)：存储RocksDB的sst文件，可以使用SSD，由BlueFS管理。
超高速空间(WAL)：存储RocksDB的log文件，可以使用NVME，由BlueFS管理。