System|分布式|Ceph & BlueStore

Ceph放弃了使用传统的文件系统作为分布式存储后端，因为它们有以下弊端:

• 难以零开销事务机制
• metadata的性能显著影响分布式性能
• 新型硬件支持不佳

转而使用BlueStore。BlueStore是Ceph最新的存储引擎，运行在用户态并且完全控制IO，取得了极大性能提升。

File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution SOSP 2019

Ceph

分布式文件系统需求

• 高效率的事务
• 快速的Metadata操作
• 支持新型异构的硬件

然而对于那些支持POSIX标准的底层文件系统而言，他们却往往缺少事务支持(因为overhead太大)，DFS必须在顶层加上WAL或者放大底层文件系统内部的事务机制。而如果它们支持的话，顶层就能简化事务设计。

而对于Metadata，大如在分布式文件系统上做目录枚举，小如在本地文件系统上查找，无论是中心化还是分布式设计都无法在两种情况下性能高效。

新型的存储设备，例如SMR(瓦式磁盘，通过磁道重叠提高存储密度，只能顺序写，一种解决方案是Ext4+LFS缓存metadata)，ZNS 固态硬盘等都是传统的基于block的文件系统无法处理的。

Ceph 架构

Reliable Autonomic Distributed Object Store(RADOS)是Ceph的核心，里面有多个Object Storage Devices（OSD），提供自我修复、自我管理、自我备份等机制。

在上层则通过librados库提供抽象，支持事务和各种原语。

object存在池子里,通过备份或者纠删码获得冗余，被划分到placement groups(PG)里。PG通过CRUSH伪随机数据分配算法分配给不同OSD，从而不需要metadata服务。通过这个间接层，Object能够进行迁移。

BlueStore

设计目标

• Fast metadata operations
• No consistency overhead for object writes
• Copy-on-write clone operation
• No journaling double-writes
• Optimized I/O patterns for HDD and SSD

BlueFS 和 RocksDB

Metadata

通过将metadata存在RocksDB里,提供了快速的metadata操作。

这点很有趣，因为这里的metadata同时是本地的，也是分布式的。

这点可以和GFS做个对比，GFS的metadata在本地是inode，在master则是trie

例如，以O开头的key代表object的metadata，B代表block，C代表collection

C12.e4-6表示pool12中hash值以e4的高6位开头的object集合。(111001）

O12e532(111001)属于此集合,O12.e832 则不属于(111010）

这样通过改变位数，很容易使得集合分裂，非常高效。

无一致性Overhead

RocksDB运行于BlueFS之上，作出两个改变

• 直接刷新缓存写入data
• 复用BlueFS的WAL，直接刷新缓存写入metadata

COW

BlueStore使用COW机制，也就是先在其他地方写，写完之后让metadata指向new data。COW的好处在于没有double-writes (journal data)。

• 对于大于最小分配size的写，当Data持久化后再把对应的MetaData插入RocksDB。
• 对于小于最小分配size的写，把Data和MetaData同时插入RocksDB，Data之后异步地写入磁盘。这样不仅可以Batch利用带宽，同时优化IO模式，例如<64kb的HDD overwrite是异步的，<16kb的SDD overwrite是inplace的。

空间分配

Freelist manager 基于bitmap，bit per block(那你叫freelist干嘛啊)，利用merge原子性反转多个位。

Allocator则是内存中的freelist拷贝，当分配完成后通知Freelist进行修改。为了节约空间，采用层次化的索引，1TB数据只需35MB

Cache

Blue Store与磁盘直接IO，因此无法利用page cache。

scan resistant 2Q 算法在内存中建立了write-through cache

cache通过OSD相同的CRUSH伪随机数据分配算法分配到指定核，因此核能准确找到2Q

Feature

checksum

每次写生成checksum，每次读验证checksum。

由于分布式系统大部分数据只读，可以通过IO hint控制checksum size。

例如只读的部分size可以更大，压缩的部分可以计算压缩后的checksum。

纠删码的覆写

仅支持RGW，因为纠删码只有在append/delete的情况下才能保证性能(不然修改的范围太大)

这里利用COW机制完成2PC，仅当所有备份OSD均正确overwrite时才会commit。

Transparent Compression

当压缩数据部分被修改时，新的数据只会COW在别的地方而不会覆写压缩数据本身。

只有当overwrite太多导致碎片化时，才会读取这些数据再进行覆写,一般来说通过hint仅压缩那些不容易被覆写的数据。

举个例子 1234 -> 1234|2' -> 1234|2'|3' ->12'3'4'

探索新接口

因为BlueFS自己控制IO，所以开源社区正在对新硬件提供支持

总结

Problem: 传统单机文件系统不支持分布式文件系统场景

Related work: 事务支持overhead大，性能不佳

Observation: 利用RocksDB存储Metadata，COW

Solution: COW提供事务支持，分布式的metadata就是本地的metadata

Evaluation: 性能提高，支持新硬件

Comments:需要特殊定制的数据库, 而且天生为Ceph服务，定制化程度高