问题描述

Ceph 的数据被写了两次。第一次是将数据写入日志系统，第二次是将数据从日志系统写入文件系统进而落盘。这样就有了写放大，势必会影响性能。这也是 FileStore 的一个致命缺陷；

FileStore 对 SSD 的设计存在局限，尽管做了许多改进来提高 SSD 和 NVMe 存储支持性能，但仍然存在其他限制。例如，增加的 PG 要耗费巨大的计算和数据迁移成本，并且仍然存在双重写入损失；

FileStore 与块设备上的文件系统进行交互，具有性能损失；

解决方案

为了提高写性能，Ceph 解决 FileStore 写放大的问题，Ceph 开发 BlueStore 作为新的对象存储方案；

BlueStore 是 Ceph 的下一代存储实现。现有的存储设备包括固态驱动器 PCI Express 或 NVMe SSD；

BlueStore 的诞生是为了解决 FileStore 同时维护一套日志系统和基于文件系统写放大的问题，实现 FileStore 本身没有的对 SSD 的最优支持；

BlueStore 相比于 FileStore 主要做了两方面工作：（1）而 BlueStore 消除了文件系统层，直接使用原始块设备进行对象存储，操作裸设备，优化日志系统。（2）针对 SSD/NVMe 进行专门优化设计；

原理简述

RocksDB

存储 WAL、对象元数据、OMAP 数据以及分配器的元数据。RocksDB 是一种嵌入式高性能 K/V 存储，在闪存存储方面表现出色；

BlueFS

Bluestore 直接操作块设备（没有文件系统），而 RocksDB 无法直接写入原始磁盘设备，需要文件系统来持久化数据。所以设计 BlueFS 这个简化的文件系统，解决元数据、文件及磁盘的空间分配和管理问题，存储 RocksDB 日志和 sst 文件，主要作用是支持 RocksDB；

Ceph 对象的所有元数据的修改都记录在 BlueFS 的日志中。对于 BlueFS 而言，元数据持久保存在日志中。Ceph 挂载文件系统时，只需回放日志，就可将所有的元数据都加载到内存中。这就保证了内存文件系统数据持久化；

BlueStore 自己管理裸盘，因此需要有元数据来管理对象，对应的是 Onode。Onode 是常驻内存的数据结构，以 K/V 形式存储到 RocksDB 中，进而通过 BlueFS 的日志功能持久化数据；

HDD/SSD

物理块设备，存储实际的数据；

特征特征

数据完整

在使用 BlueStore 的 Ceph 集群中，Ceph 可以通过对 Write 操作进行循环冗余校验来确保数据完整，然后将 CRC 值存储在块数据库 RocksDB 中。在读取操作中，Ceph 可以从块数据库 RocksDB 中检索 CRC 值，并将其与检索到的数据生成的 CRC 值进行比较，以确保数据完整；