Ceph 进阶系列（一）：一些基本概念(2 of 2，偏Server端OSD)

性能相关的概念和设计原则：

0. Ceph引入日志型存储系统？

BlueFS，引入日志的目的是为了进行写加速，WAL（Write Ahead Log）对于提升RocksDB的性能至关重要。

1. 为什么引入BlueStore?

ceph后端（OSD）支持多种存储引擎，以插件式的方式来进行管理使用，目前支持filestore，kvstore，memstore以及最新的bluestore.

因为FileStore需要通过操作系统自带的本地文件系统间接管理磁盘，所以所有针对RADOS层的对象操作，都需要预先转换为能够被本地文件系统识别、符合posix语义的文件操作，这个转换过程极其繁琐，效率低下。BlueStore选择绕过本地文件系统，由自身接管裸设备（例如磁盘），直接进行对象操作，不再进行对象和文件之间的转换，从而使得整个对象存储的I/O路径大大缩短，这是BlueStore能提升性能的根本原因。除此之外，考虑到元数据的索引效率对于性能有着致命的影响，BlueStore在设计中将元数据和用户数据分离，用高速固态存储设备NVMe SSD来存储数据，能起到性能加速的作用。

BlueStore整体架构分为四个部分：

• BlockDevice为最底层的块设备，BlueStore直接操作块设备，抛弃了XFS等本地文件系统。BlockDevice在用户态直接以linux系统实现的AIO直接操作块设备文件。
• BlueFS是一个小的文件系统，其文件系统的文件和目录的元数据全部被缓存在内存中，持久化保存在文件系统的日志文件中， 当文件系统重新mount时，重新replay该直接，就可以加载所有的元数据到内存中。其数据和日志文件都直接保存在依赖低层的BlockDevice中
• RocksDB 是Facebook在leveldb上开发并优化的KV存储系统。BlueFS的主要的目的，就是支持RocksDB
• BlueStore是最终基于RocksDB和BlockDevice实现的ceph的对象存储，其所有的元数据都保存在RocksDB这个KV存储系统中，包括collection，对象，omap，磁盘空间分配记录等都保存RocksDB里, 其对象的数据直接保存在BlockDeviceB

PG(placement group)?

BlueStore 里的元数据类型有几种？

Collection 和 Onode，其中Collection对应PG在BlueStore当中的内存管理结构（ceph推荐每个OSD承载100个PG）。

Onode其实就是管理对象的元数据: 在bluestore里，已经没有传统的文件系统，而是自己管理裸盘，因此需要有元数据来管理对象，对应的就是Onode，Onode是常驻内存的数据结构，持久化的时候会以kv的形式存到rocksdb里。

2. 为什么BlueStore 默认采用了RocksDB作为元数据存储引擎？

LevelDB => RocksDB

3. 什么是BlueFS？它有哪些特点？

BlueFS 是为RocksDB量身定制的一款本地用户态日志型文件系统，它在设计上支持将.sst(sort string table)和.log文件分开存储，以便将.log文件单独使用速度更快的固态存储设备（NVme SSD）存储。

4. 为什么Ceph有 QOS存储服务质量?

比如，Openstack生产环境中可能出现个别虚拟机侵占了整个集群的绝大部分I/O资源，大致其它虚拟机操作延时较大；此外，某些场景下需要为一些重要客户预留更多的I/O资源，以便提供更加优质的的服务。

5. 为什么会有 RGW？其框架图的拓扑结构

对象存储主要面向海量非结构化数据的存储，常用于静态数据、备份归档、流媒体等场景，通常情况下需要提供HTTP访问接口，非常方便数据通过互联网传输，因此，对象存储成为了云存储领域的一种常见的存储形态。Ceph为了支持通用的HTTP接口设计了RGW（RADOS GateWay即对象网关系统）系统。

6. Ceph 的 RBD 架构是怎么样的？

看了这张图，你可明白了rbd 在linux kernel里代码的地位