Ceph存储原理详解：从FileStore到BlueStore
Ceph存储原理详解：从FileStore到BlueStore
Ceph是一种分布式存储系统，其存储原理可以从存储解读、案例解读和小结三个方面来学习。
1.1 存储解读
Ceph存储集群从Ceph客户端接收数据，无论是通过Ceph块设备、Ceph对象存储、Ceph文件系统还是使用librados创建的自定义实现，这些数据都会被存储为RADOS对象。每个对象都会存储在一个对象存储设备（Object Storage Device，OSD）上。
Ceph OSD守护进程负责处理存储驱动器上的读、写和复制操作。它主要基于两种文件方式实现：
- FileStore方式：每个RADOS对象都作为一个单独的文件存储在传统文件系统（通常是XFS）上。
- BlueStore方式：对象以类似整体数据库的方式存储，这是最新版本Ceph默认的存储方式。
需要注意的是，在Ceph中，每一个文件都会被拆分为多个独立的Object，然后按照上述逻辑进行持久化存储。
Ceph OSD守护进程将“数据”作为对象存储在平面命名空间中，该对象包括以下几个部分：
- 标识符：在内存中唯一查找的标识
- 二进制数据：每个对象的真实数据
- 属性数据：由一组名称/值对组成的元数据，语义完全取决于Ceph客户端
例如，CephFS使用元数据来存储文件属性，例如文件所有者、创建日期、上次修改日期等。对象ID在整个集群中是唯一的，而不仅仅是本地文件系统。
1.2 案例解读
1.2.1 存储示例
假设需要存储一个大小为16M的文件，存储时需要首先进行切割，假设每个对象（object）大小为4M，然后通过hash方式将object存储到对应的PG（Placement Group）上，最后通过CRUSH策略将对应的数据关联到不同的hosts上。
这个时候会遇到一个问题：OSD是一个磁盘设备，那么如何来进行存储数据？常见的处理措施主要有两种：
- 第一种：将OSD格式化为文件系统，然后挂载到对应目录，然后就可以使用了
- 第二种：OSD有自己的守护进程，那么直接在守护进程空间中实现数据的处理
1.2.2 方法1 - FileStore
在这种方式下，OSD就变成一个文件系统中的文件（目录）。因此，OSD需要维护object的对象属性信息，object的元数据保存到OSD（文件系统）的元数据区。但是文件系统的元数据区只能存放文件的属主、属组、权限、时间戳等信息。对于Ceph来说，object的元数据信息却包含很多相关信息，那么这些数据保存到哪里？
为了保存文件系统默认能够保存的数据之外的元数据（object对象的其他元数据信息），就需要将OSD做成一个XFS文件系统，在这个文件系统中，需要有一个单独的数据库（LevelDB），来维护Ceph的元数据信息。
由于这种方式是基于文件系统映射的方式来实现Ceph的属性存储，所以这种文件的存储方式称为：FileStore。其劣势在于，由于object本来已经称为对象了，而在FileStore中，需要将其转换为文件方式来进行数据属性的存储，所以效率有些慢。
附注：
- XFS是被开发用于高容量磁盘以及高性能文件系统之用的。主要规划为三个部分：
- 资料区（data section）：包括inode、block、superblock等数据
- 文件系统活动登录区（log section）：用来记录文件系统的变化
- 实时运作（realtime section）：数据真正存储的地方
1.2.3 方法2 - BlueStore
因为OSD对象是由一个ceph-osd守护进程来实现存储数据、处理数据复制、恢复、重新平衡等管理操作的。所以新版的Ceph的OSD进程中，维护了一个RocksDB用于存储objects的元数据属性信息。
RocksDB为了实现数据的存储还需要一个文件系统，所以Ceph就为它开发了一个文件系统BlueFS。
RocksDB + BlueFS共同实现了objects的元数据的存储，所以这种存储方式称为BlueStore。新版的Ceph的存储机制，默认采用的就是BlueStore机制。
1.3 小结
Ceph的存储原理主要涉及数据如何被存储为RADOS对象，以及两种主要的存储方式：FileStore和BlueStore。其中，BlueStore是最新版本Ceph默认的存储方式，它通过RocksDB和BlueFS来实现对象元数据的存储，具有更高的效率和性能。