Ceph--存储引擎BlueStore

Ceph–存储引擎BlueStore

1.设计理念

相较于使用操作系统本身提供的文件管理系统，Ceph以及数据库等等都倾向于自己实现一套自己的文件管理系统。使用操作系统的文件管理系统所需要的工作量小，缺点就是缺少定制化，无法对一些策略或者规则进行更改，使得性能不高。

BlueStore是一个事务性的本地日志文件系统（实际存储的是对象），在保证数据可靠性和一致性的前提下，尽量减少由于日志系统存在而引入的双写问题所带来的负面影响。（双写指在进行写操作时需要先写日志，即可返回写入成功，后通过一个线程异步将数据写入）。

BlueStore提供的读写接口都是基于PG粒度的，通过其提供的接口来操作PG下的某个对象，首先需要找到BlueStore中对应PG上下文和对象上下文，这两类上下文保存了关键的PG和对象的元数据信息，而且BlueStore通过KVDB固化这两类上下文至磁盘，接下来我们需要谅解这两类上下文的磁盘数据结构。

2.磁盘数据结构

2.1 PG

为了便于管理，Ceph引入了资源池pool的虚拟概念，表示一组约束条件，例如可以针对不同的pool设计一组CRUSH规则。一个pool包含多个PG，一个PG中包含多个对象object，object为其最小存储单元通常为4K,并且会有一个全局唯一的object ID表示该object(文件名+序号)，然后通过一定的规则映射到PG ID中，PG ID又通过CRUSH规则选出要存放的OSD。

PG ID = pool ID + 序号

从object id映射到PG ID公式如下：首先会选择一个pool（如何选取暂时还不太清楚，应该也是根据权重这些选择的），之后通过pool ID + hash(object id) & mask = PG ID。

当然mask的取值也很有讲究，其和pool里面的PG数量有关，一般为 mask = $2^n$ 同时n满足 $2^n$ >= pg_num,但这就会引入一个问题，比如只有12个PG，所以n为4，但是根据公式计算出来可能会出现编号为13根本就不存在的PG ID，所以改为：

​ if ((hash & ($2^n$ -1)) < pg_num)

​ return (hash & ($2^n$ -1))

​ else

​ return (hash & ($2^{n-1}$ -1))

由于pool中的PG数量不是一成不变的，所以也要有扩容问题。

假设旧pool pg_num=16,新pool pg_num=64，假设老pool中某个PG ID为$X_4{X}_3{X}_2{X}_1$

根据object id映射原则，只有第一种才能映射到老PG中，所以需要创建3个新PG，同时转移老PG中的一些对象到新PG中。又因为产生了新PG，需要存储到OSD中，因为原先老PG存放到OSD中时已经做了负载均衡，新PG的数据又是从老PG迁移过来的，所以新PG存放的OSD就和老PG相同，以减少数据的跨OSD迁移造成性能的损耗。同时数据的存储就类似文件存储，目录名就是PG ID，只需要在PG ID下再开几个目录就行。

2.2 对象object

每个object对象存储类似于文件，是基于逻辑段(extent)进行的，其由（offset， length， data）组成，offset为对象内逻辑偏移，从0开始，length为逻辑段长度，data为逻辑段包含的数据，可以是分片的有多段，每一段能够索引到磁盘上的数据。

数据校验、数据压缩和数据共享都是基于extent进行的。以下为磁盘数据结构：

当然一个对象可以由多个extent组成，所以可以将同一个对象下的所有extent组成一个extent map，，可以直接索引该对象下的所有内容，但因为磁盘碎片化严重等问题，导致extent map变得十分臃肿。影响访问效率，所以可以将其分片，独立出来单独保存。

上面讲的是磁盘的数据结构，还需要将上层对象存储到磁盘中，即对象的磁盘数据结构onode（存储在物理磁盘上）。上层对象就是逻辑上将文件分片的对象，其还有个全局唯一的object id，但由于后面的快照这些的引入会使全局唯一性丧失，所以需要将一些额外的信息考虑到上层对象至onode的映射中。具体结构在Ceph设计原理于实现66页。

2.3 缓存管理

2.3.1 缓存算法

LRU：淘汰最长时间未使用页面（时间局部性）

LFU：淘汰使用频率最低页面（空间局部性）

ARC：使用了MFU和MRU队列，其队列长度是可变的，在呈现明显时间局部性时MFU队列长度变为0，变成LRU算法，缺点是复杂度高执行率较低。

2Q：针对数据库算法，数据库经常存在多个事务操作同一块热点数据的场景（事务相关性），所以一共有Ain Aout Am三个队列，页面命中放入Ain，继续命中认为是相关的，不提升热度，淘汰后进入Aout队列，继续命中，热度提升放入Am头部，在Am中命中也放入到其头部。

2.3.2 BlueStore中的缓存管理

出于减少锁碰撞的目的，BlueStore会实例化多个缓存（主要是因为不同PG之间的客户请求可以并发访问，所以为了提升处理性能，每个OSD相应会设置多个PG工作队列，Bluestore中缓存实例数与之对应）

其主要分为Cache基类，以及由Cache派生的TwoQCache和LRUCache类

BlueStore中大的元数据主要有两种：Collection和Onode，其中Collection对应PG在BlueStore中存储结构，因为PG的数量较少，所以其常驻内存不淘汰，而Onode数量较多所以需要有淘汰机制。

Onode使用LRU队列管理，理论上可以将所有Onode在Cache中使用单个LRU队列管理，但每个Onode唯一归属于一个Collection，所以引入中间结构，来建立Onode来建立和Collection的联系，便于Collection级别的操作。名称为OnodeSpace：

因为Onode中Extent是管理用户数据的基本单元，Blob（即前面提到的data）负责真正执行用户数据到磁盘空间的映射，所以基于Blob引入一个中间结构—BufferSapce，负责建立每个Blob中用户数据到混村之间的二级索引：

方法介绍略，再书上72页，最终Onode和Buffer都需要加入Cache，Onode采用LRU，Buffer采用2Q，但两种数据所占的缓存是共享的。

2.4 磁盘空间管理

2.4.1 常见磁盘管理方式

这部分内容应该和操作系统中的内容相类似，有位图和段管理方式(offset和length)。

空间分配策略：首次拟合法、最佳拟合法和最差拟合法。 需要综合考虑请求空间大小的分布规律和效率来决定。

BlueStore默认使用位图来管理（也支持端），其由FreelistManager组件负责管理空闲空间列表，Allocator组件负责管理已分配空间列表。下面介绍BitmapFreelistManaget和BitmapAllocator。

2.4.2 BitmapFreelistManager

其以块为粒度，将连续、数量固定的多个块进一步组成一个段，从而将整个磁盘空间划分为若干连续的段进行管理。每个段可以由offset和length表示，并且固化到kvDB中，其中使用一个长度固定的比特流来表示段中每个块的状态（已分配或者空闲）。与1异或可以快速翻转状态。公共接口看书上76页。

2.4.3 BitmapAllocator

无需使用kvDB存盘，采用非扁平化方式组织提升作用效率：

BitmapEntry是BitmapAllocator中最小可操作单位，假设其由64位，则可以记录64个物理上相邻块的状态，同时多个Entry组成AreaZone，AreaZone由独立的锁逻辑，因此可以在不同AreaZone之间进行并发操作。为了增加索引效率，还可以进一步引入一些中间逻辑结构。

需要注意的是，因为 BlueStore 将不同类型的数据严格分开并且允许使用不同的设备存储，所以一个BlueStore实例中可能存在多个BitmapAllocator 实例。

这两个类都能都提供分配和释放空间的接口函数。Allocator可以快速的查找快的使用情况。一般只需要初始化一个类就行。

2.5 BlueFS

2.5.1 RocksDB与BlueFS

引入BlueFS日志型文件系统后，BlueStore将所有存储空间从逻辑上分成了三个层次：

• (1)慢速(Slow)空间

  这类空间主要用于存储对象数据，可由普通大容量机械磁盘提供，由 BlueStore 自行管理。

• (2)高速(DB)空间

  这类空间主要用于存储 BlueStore 内部产生的元数据(例如onode)可由普通SSD提供，容量需求比(1)小。因为 BlueStore 的元数据都交由 RocksDB 管理，而 RocksDB 最终通过 BlueFS将数据存盘，所以这类空间由 BlueFS 直接管理

• (3)超高速(WAL)空间

  这类空间主要用于存储 RocksDB 内部产生的og 文件，可由NVMe SSD或NVRAM等时延相较普通SSD 更小的设备充当，容量需求和(2)相当(实际上还取决于RocksDB相关参数设置)。超高速空间也由 BlueFS 直接管理

上述三种类型空间是不固定的，由BlueFS和BlueStore自身进行协调。

2.5.2 BlueFS磁盘数据结构

BlueFS的磁盘数据只要包括文件、目录和日志三种类型。

Blue只用于存储单个BlueStore（对应一块磁盘）的元数据，所存储的文件规格比较统一（绝大多数为SSTable）并且数量十分有限，所以可以直接采用扁平结构进行组织。

BlueFS 定位某个具体文件一共需要经过两次查找:第一次通过 dir_map 找到文件所在的最底层文件夹;第二次通过该文件夹下的file_map 到对应的文件需要注意的是:因为是扁平组织，所以dir_map 中每个条目描述的都是文件的绝对路径即条目之间没有隶属关系。每个文件也采用一个类似inode 的结构进行管理，BlueFS称为bluefs fnode t(简称fnode，下同)。因此，file_map 建立的实际上是文件名和fnode之间的映射关系，fnode相应的磁盘数据结构如表 2-23 所示。

其中extents与前面几节介绍的不同，这边还需要加入磁盘所用的块设备（slow。。。。），其所有修改操作都是基于日志，为了减少刷盘日志量提升效率，采用增量日志模式。同时为了避免日志占用过多，也会增加checkpoint，定期将dir_map和file_map落盘已减少日志量。

在引入RocksDB + BlueFS后，BlueStore至多可以管理三种类型的存储空间——Slow、DB和WAL。

2.6 实现原理

2.6.1 mkfs

mkfs主要是固化一些用户指定的配置项到磁盘。比如FresslistManager实现的方式是位图还是段。

2.6.2 mount

mount操作完成正常上电前的检查和准备工作。

2.6.3 read

2.6.4 write

写抑制是为了防止过载。同时还有包括前面的对其写，COW，RMW（Read Modify Write ）。

使用 BlueStore，每个 OSD 的主设备还要在部署时再次划分为容量一大一小两个分区，其中较小的分区使用本地文件系统格式化，用于保存 OSD启动时的引导数据；较大的分区则以裸设备的形式由 BlueStore 直接接管，充当 Slow 设备 。