ceph fileStore与 blueStore逻辑架构对比

ceph 消息处理逻辑架构图

ceph后端支持多种存储引擎，以插件化的形式来进行管理使用，目前支持filestore，kvstore，memstore以及bluestore，目前默认使用的是filestore，但是目前bluestore也可以上生产。

1）Firestore存在的问题是：

• 在写数据前需要先写journal，会有一倍的写放大；
• 若是另外配备SSD盘给journal使用又增加额外的成本；
• filestore一开始只是对于SATA/SAS这一类机械盘进行设计的，没有专门针对SSD这一类的Flash介质盘做考虑。

2）而Bluestore的优势在于：

• 减少写放大；
• 针对FLASH介质盘做优化；
• 直接管理裸盘，进一步减少文件系统部分的开销。

但是在机械盘场景Bluestore与firestore在性能上并没有太大的优势，bluestore的优势在于flash介质盘。

为什么需要BlueStore？
Ceph作为软件定义存储(SDS)解决方案，其首要目标是保障存储数据的安全。为了达到数据安全的目的，Ceph使用了WAL的方式（Write-Ahead-Log)，这就是我们日常最熟悉的journal.

但是写前记录日志这种技术有一个主要缺陷就是它把你的硬盘性能降低到原来的二分之一（仅当日志和OSD数据共享同一个硬盘时），因为filestore在写数据前需要先写journal，所以有一倍的写放大。

filestore设计初衷就是就是为了充分发挥普通机械盘的性能，没有对SSD进行优化考虑。但随着SSD全面普及(主要性价比越来越实惠，也是新技术不断推陈出新的结果）,Ceph应用在SSD之上案例越来越多，对于性能的需求是更加迫切。基于以上现实，社区推出了Bluestore的存储引擎，剔除journal方案，缩减写放大，优化SSD写入，同时数据直写裸盘。

FileStore逻辑架构

1）首先，为了提高写事务的性能，FileStore增加了fileJournal功能，所有的写事务在被FileJournal处理以后都会立即callback(上图中的第2步)。日志是按append only的方式处理的，每次都是被append到journal文件末尾，同时该事务会被塞到FileStore op queue；

2）接着，FileStore采用多个thread的方式从op queue 这个 thread pool里获取op，然后真正apply事务数据到disk（文件系统pagecache）。当FileStore将事务落到disk上之后，后续的读请求才会继续(上图中的第5步)。

3）当FileStore完成一个op后，对应的Journal才可以丢弃这部分Journal。对于每一个副本都有这两步操作，先写journal，再写到disk，如果是3副本，就涉及到6次写操作，因此性能上体现不是很好。

Bluestore逻辑架构

1）Bluestore实现了直接管理裸设备的方式，抛弃了本地文件系统，BlockDevice实现在用户态下使用linux aio直接对裸设备进行I/O操作，去除了本地文件系统的消耗，减少系统复杂度，更有利于Flash介质盘发挥性能优势；

2）为了惯例裸设备就需要一个磁盘的空间管理系统，Bluestore采用Allocator进行裸设备的空间管理，目前支持StupidAllocator和BitmapAllocator两种方式；

3）Bluestore的元数据是以KEY-VALUE的形式保存到RockDB里的，而RockDB又不能直接操作裸盘，为此，bluestore实现了一个BlueRocksEnv，继承自EnvWrapper，来为RocksDB提供底层文件系统的抽象接口支持；

4）为了对接BlueRocksEnv，Bluestore自己实现了一个简洁的文件系统BlueFS，只实现RocksDB Env所需要的接口，在系统启动挂在这个文件系统的时候将所有的元数据都加载到内存中，BluesFS的数据和日志文件都通过BlockDevice保存到底层的裸设备上；

5）BlueFS和BlueStore可以共享裸设备，也可以分别指定不同的设备，比如为了获得更好的性能Bluestore可以采用 SATA SSD 盘，BlueFS采用 NVMe SSD 盘。

内部组件

• RocksDB:
  存储预写式日志、数据对象元数据、Ceph的omap数据信息、以及分配器的元数据（分配器负责决定真正的数据应在什么地方存储）
• BlueRocksEnv: 与RocksDB交互的接口
• BlueFS:
  迷你的文件系统（相对于xfs，ext2/3/4系列而言)，解决元数据、文件空间及磁盘空间的分配和管理。因为rocksdb一般是直接存储在POSIX兼容的文件系统（如ext3/xfs等）之上，但BlueStore引擎是直接面向裸盘管理，没有直接兼容POSIX的文件接口。但幸运的是，rocksdb的开发者充分考虑了适配性，只要实现了rocksdb::Env
  接口，就能持久化rocksdb的数据存储(包含RocksDB日志和sst文件)。BlueStore就是为此而设计开发的，它只包含了最小的功能，用来承接rocksdb。在osd启动的时候，它会被"mount"起来，并完全载入内存
• Allocator: 用来从空闲空间分配block（block是可分配的最小单位)

说明：
1.对象数据存储部分即osd指定的data设备(可以是裸盘分区，或者lvm卷，下同)
2.RocksDB日志即osd指定的wal设备
3.RocksDB数据部分即osd指定的db设备
4.以上设备可以共用同一物理盘设备，也可以分开在不同的物理设备,这充分体现了ceph的灵活性

参考文章：
http://www.yuncunchu.org/portal.php?mod=view&aid=74
https://mp.weixin.qq.com/s/vTgVOlRV2yb3x94FafusuQ