ceph 元数据保存方式
Ceph 对象数据的元数据信息放在哪里呢? 对象数据的元数据以 key-value 的形式存在，在RADOS 中有两种实现：
- xattrs
- omap
ceph 可选后端支持多种存储引擎
- filestore
- bluestore
- kvstore
- memstore
ceph 使用 bluestore 存储对象数据的元数据信息。
xattrs(扩展属性)
将元数据 保存在 对象对应文件 的扩展属性中 并保存到 系统磁盘上，这要求支持 对象存储 的 本地文件系统（一般是 XFS）支持扩展属性。
omap(object map 对象映射)
将元数据保存在本地文件系统之外的独立 key-value 存储系统中，
- 在使用 filestore 时是 leveldb（已经废弃掉了）
- 在使用 bluestore 时是 rocksdb 当前正在是痛的
由于 filestore存在功能问题(需要将磁盘格式化为 XFS 格式)及元数据高可用问题等问题，
因此在目前ceph主要使用 bluestore。
filestore & leveldb --已经弃用了
ceph 早期基于 filestore 使用 google 的 levelDB 保存对象的元数据，
LevelDb 是一个持久化存储的 KV 系统 和 Redis 这种内存型的 KV 系统不同，leveldb 不会像 Redis 一样将数据放在内存从而占用大量的内存空间
而是将大部分数据存储到磁盘上，但是需要把磁盘上的leveldb 空间格式化为文件系统(XFS)。
FileStore 将数据保存到与 Posix 兼容的文件系统(例如 Btrfs、XFS、Ext4)。
在 Ceph 后端使用传统的 Linux 文件系统尽管提供了一些好处，但也有代价，如性能、 对象属性与磁盘本地文件系统属性匹配存在限制等。
bluestore 与 rocksdb
RocksDB github.com/facebook/ro…
BlueStore是Ceph中的一种存储引擎，其最大的特点是可以直接管理裸磁盘设备，并将对象数据存储在该设备中。
这种设计使得OSD（对象存储设备）与磁盘的交互更加高效。
此外，BlueStore还对诸如SSD等新型存储设备做了许多优化工作，以提升性能并提高Ceph集群的整体效率。
RocksDB 的数据放在哪里呢？
放在内存怕丢失，放在本地磁盘但是解决不了高可用.
BlueStore还实现了一个轻量级的文件系统BlueFS供RocksDB读写数据
ceph 对象数据放在了每个 OSD 中，那么就在在当前 OSD 中划分出一部分空间，格式化为 BlueFS 文件系统用于保存 RocksDB 中的元数据信息(称为 BlueStore)
并实现元数据的高可用，BlueStore 最大的特点是构建在裸磁盘设备之上
BlueStore做了很多优化工作
- 对全 SSD 及全 NVMe SSD 闪存适配
- 绕过本地文件系统层，直接管理裸设备，缩短 IO 路径
- 严格分离元数据和数据，提高索引效率
- 使用 KV 索引，解决文件系统目录结构遍历效率低的问题
- 支持多种设备类型
- 解决日志“双写”问题
- BlueStore 的设计考虑了 FileStore 中存在的一些硬伤，抛弃了传统的文件系统直接管理裸设备，缩短了 IO 路径，同时采用 ROW 的方式，避免了日志双写的问题，在写入性能上有了极大的提高。
- 期望带来至少 2 倍的写性能提升和同等读性能
- 增加数据校验及数据压缩等功能
BlueStore vs Filestore性能对比
逻辑架构
Allocator
负责裸设备的空间管理分配。
RocksDB
rocksdb 是 facebook 基于 leveldb 开发的一款 kv 数据库，BlueStore 将元数据全部存放至 RocksDB 中，这些元数据包括存储预写式日志、数据对象元数据、Ceph 的 omap数据信息、以及分配器的元数据 。
BlueRocksEnv
这是 RocksDB 与 BlueFS 交互的接口；RocksDB 提供了文件操作的接口
EnvWrapper(Env 封 装 器 )
可 以 通过 继 承 实 现 该 接 口来 自 定 义 底 层 的 读写 操 作 ，
BlueRocksEnv
就是继承自 EnvWrapper 实现对 BlueFS 的读写。
BlueFS
BlueFS 是 BlueStore 针对 RocksDB 开发的轻量级文件系统，用于存放 RocksDB产生的.sst 和.log 等文件。
BlockDecive
BlueStore 抛弃了传统的 ext4、xfs 文件系统，使用直接管理裸盘的方式
Ceph CRUSH 算法简介
Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash算法
CRUSH 是一种分布式算法，类似于一致性 hash 算法，用于为 RADOS 存储集群控制数据的分配
- 动态分布 PG--->OSD
- 不同磁盘上的数据可以动态复制
- 例如OSD磁盘损坏时 可以计算出PG新的OSD组合
Ceph 使用 CURSH 算法来存放和管理数据，它是 Ceph 的智能数据分发机制。
Ceph 使用CRUSH 算法来准确计算数据应该被保存到哪里，以及应该从哪里读取
和保存元数据不同的是,CRUSH 按需计算出元数据，因此它就消除了对中心式的服务器／网关的需求
它使得Ceph 客户端能够计算出元数据，该过程也称为 CRUSH 查找，然后和 OSD 直接通信
1.如果是把对象直接映射到 OSD 之上会导致对象与 OSD 的对应关系过于紧密和耦合，当OSD 由于故障发生变更时将会对整个 ceph 集群产生影响。
2.于是 ceph 将一个对象映射到 RADOS 集群的时候分为两步走：
- 首先使用一致性 hash 算法将对象名称映射到 PG 2.7
- 然后将 PG ID 基于 CRUSH算法 映射到 OSD 即可查到对象
3.以上两个过程都是以”实时计算”的方式完成，而没有使用传统的查询数据与块设备的对应表的方式，
- 这样有效避免了组件的”中心化”问题，
- 也解决了查询性能和冗余问题。
使得 ceph集群扩展不再受查询的性能限制。
4.这个实时计算操作使用的就是 CRUSH 算法 Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash 算法。
