分布式存储Ceph存储引擎简介-天翼云开发者社区

一、分布式存储Ceph简介

Ceph是一个高性能、高可用、高扩展性的分布式存储系统，支持文件系统存储、块存储、对象存储三种不同类型的存储，满足多样存储的需求。Ceph整体架构包含最上层的存储接口层，用来提供客户端访问存储后端服务的各种接口，支持块存储、文件存储和对象存储，其中间层是librados，它用来提供各种访问底层RADOS集群存储系统的各种库函数。RADOS层是Ceph的重要组成部分，它提供给用户一个完整的存储系统，其主要组成部分是Monitors、OSDs、MDS，其中Monitor主要功能是用来监视Ceph集群的健康状态，并保存各种map（节点健康状况、逻辑和物理关系映射等）信息，OSDs是运行在存储设备上的主要用于存储数据的守护进程，它以PG为单位进行数据的存储、迁移、和恢复，MDS是文件系统的元数据管理服务进程，主要针对CephFS中的元数据信息进行管理。在librados的基础之上又根据具体的上层应用需求抽象出了块设备的库librbd、对象存储的库librgw和文件系统库libcephfs。

分布式存储系统ceph有如下特点：

◆高性能
a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。

◆高可用性
a. 副本数可以灵活控制。
b. 支持故障域分隔，数据强一致性。
c. 多种故障场景自动进行修复自愈。
d. 没有单点故障，自动管理。

◆高可扩展性
a. 去中心化。
b. 扩展灵活。
c. 随着节点增加而线性增长。

◆特性丰富
a. 支持三种存储接口：块存储、文件存储、对象存储。
b. 支持自定义接口，支持多种语言驱动。

二、Ceph存储引擎介绍

概述

Ceph提供存储功能的核心组件是RADOS集群，其本质是一个提供了大量接口的分布式对象存储集群，最终都是以对象存储的形式对外提供服务。但在底层的内部实现中，Ceph的后端存储引擎在近十年来经历了许多变化。现如今的Ceph系统中比较场景的后端存储引擎主要有FileStore和BlueStore。

FileStore

FileStore是利用文件系统的POSIX接口实现ObjectStore API。每个Object在FileStore层会被看成是一个文件，Object的属性会利用文件的xattr属性存取，因为有些文件系统(如Ext4)对xattr的长度有限制，因此超出长度的元数据会被存储在DBObjectMap或omap中。Filestore逻辑结构图如下图1：

图1 filestore逻辑结构图

Ceph原本的FileStore需要兼容Linux下的各种文件系统，如EXT4、BtrFS、XFS。理论上每种文件系统都实现了POSIX协议，但事实上，每个文件系统都有一点“不那么标准”的地方。Ceph的实现非常注重可靠性，因而需要为每种文件系统引入不同的Walkaround或者Hack；例如Rename不幂等性，等等。这些工作为Ceph的不断开发带来了很大负担。其次，FileStore构建与Linux文件系统之上。POSIX提供了非常强大的功能，但大部分并不是Ceph真正需要的；这些功能成了性能的累赘。其次文件系统的某些功能实现对Ceph并不友好，例如对目录遍历顺序的要求，等等。另一方面，是Ceph日志的双写问题。为了保证覆写中途断电能够恢复，以及为了实现单OSD内的事物支持，在FileStore的写路径中，Ceph首先把数据和元数据修改写入日志，日志完后后，再把数据写入实际落盘位置。这种日志方法（WAL）是数据库和文件系统标准的保证ACID的方法。但用在Ceph这里，带来了问题，数据被写入两遍，即日志双写问题，这意味着Ceph牺牲了一半的磁盘吞吐量：

1、Ceph的FileStore做了一遍日志，而Linux文件系统自身也有日志机制，实际上日志被多做了一遍。

2、对于新型的LSM-Tree类存储，如RocksDB、LevelDB，由于数据本身就按照日志形式组织，实际上没有再另加一个单独的WAL的必要。

3、更好地发挥SSD/NVM存储介质的性能。与磁盘不同，基于Flash的存储有更高的并行能力，需要加以利用。CPU处理速度逐渐更不上存储，因而需要更好地利用多核并行。存储中大量使用的队列等，容易引发并发竞争耗时，也需要优化。另一方面，RocksDB对SSD等有良好支持，它为BlueStore所采用。

另外，社区曾经为了FileStore的问题，提出用LevelDB作存储后端；对象存储转换为KeyValue存储，而不是转换问文件。后来，LevelDB存储没有被推广开，主流还是使用FileStore。但KeyValue的思路被沿用下来，BlueStore就是使用RocksDB来存储元数据的。

Bluestore

bluestore 的诞生是为了解决 filestore 自身维护一套journal 并同时还需要基于文件系统的写放大问题，并且 filestore 本身没有对 SSD 进行优化，因此 bluestore 相比于 filestore 主要做了两方面的核心工作：

1、去掉 journal ，直接管理裸设备

2、针对 SSD 进行单独优化

Bluestore逻辑结构图如下：

图2 bluestore逻辑结构图

Bluestore中通过Allocator（分配器）实现对裸设备的管理，直接将数据保存到设备上；同时针对 metadata 使用 RocksDB 进行保存，底层自行封装了一个BlueFS用来对接RocksDB 与裸设备。

在之前的存储引擎filestore里，对象的表现形式是对应到文件系统里的文件，默认4MB大小的文件，但是在bluestore里，已经没有传统的文件系统，而是自己管理裸盘，因此需要有元数据来管理对象，对应的就是Onode，Onode是常驻内存的数据结构，持久化的时候会以kv的形式存到rocksdb里。

BlueStore 存储的最常用写路径应该尽量的短，尽量的简单，这样才能有最好的性能，尽快另外的异常处理路径可能是非常复杂的。

Ceph 并不需要POSIX 文件系统。抛弃它，实现一个尽量简单的文件系统，专门给 RocksDB 使用。这个文件系统叫做 BlueFS，元数据存储在RocksDB中，用KeyValue的方式正合适。而数据不需要文件系统，直接存储在裸块设备上即可。我们在块设备上需要的，其实是一个空间分配器（Allocator）。还有一点，BlueStore 中不同组件可以使用不同的设备。例如给 RocksDB 的 WAL 文件配置 NVRAM，给SST文件配备 SSD，给数据文件配备HDD，方案是灵活的。

Filestore和Bluestore业务支持

Ceph存储在数据的容错方式上支持多副本和纠删码两种方式，以便分布式系统需要在硬件失效等故障发生后仍然能继续提供服务。与副本相比，纠删码的优点在于节省存储空间，缺点在于有计算开销而且修复需要一定时间，而副本损失只要复制出来损失的数据，未损失的数据可以继续提供服务。

多副本是通过将相同的数据在不同的节点上存储多份来实现数据保护的一种技术，支持三副本和两副本，推荐三副本。三副本的空间利用率为33.3%，两副本的空间利用率50%。

关于纠删码，Ceph的默认纠删码库是Jerasure，即Jerasure库；除此之外还有 Clay, ISA-L, LRC, Shec。当管理员创建一个erasure-coded后端时，可以指定数据块和代码块参数。Jerasure库是第三方提供的中间件。Ceph环境安装时，已经默认安装了Jerasure库。

在filestore下，块存储、文件存储、对象存储均支持多副本的数据容错方式，但是只有对象存储支持纠删码的数据容错方式。在bluestore下，块存储、文件存储、对象存储均支持多副本和纠删码的数据容错方式。

Filestore和Bluestore性能对比

Bluestore主要的目的是对性能进行优化，以提升ceph集群整体的性能。从Ceph官方给出的性能测试数据中可以看出3副本场景下，大多数业务场景下bluestore相比filestore场景下有将近1倍的性能提升。如下图所示：

图3 三副本下filestore和bluestore性能对比

对于纠删码场景下的性能对比，如下图所示：

图4 纠删码下filestore和bluestore性能对比

三、总结

Ceph的后端存储引擎随着技术革新需求的变化不断地向前发展，但发展的大体脉络也基本揭示了分布式存储系统的变革规律。从一开始选择使用功能稳定、机制成熟、且代码久经考验的文件系统作为存储后端，更多的是出于功能稳定性上的考虑，但随着场景的复杂化，数据规模的不断增大，不同的IO类型的出现，以及实际生产环境中对性能的极致要求，以Ceph为代表的分布式存储系统的经验表明文件系统不再适用于如今的分布式存储场景，其性能的低下和开销的巨大使得开发者们不得不在文件系统的基础上进行优化。但随着近年来新型存储器件技术的发展，使得存储设备对外提供的接口多样化，不再局限于传统的块接口，而基于传统的块设备设计的文件系统无法对新型存储器件进行较好的适配。在对性能的极致要求和新型存储器件提出的挑战的共同作用下，Ceph开始了新型存储后端引擎的研究，打破了文件系统作为存储后端的垄断格局，并结合其他后端存储引擎的优势如KV存储等，设计了一种新的基于裸设备的管理方案，并定制化小型文件系统来对传统的依赖POSIX接口应用进行适配，充分利用存储器件的性能，尽可能地降低软件的开销，将存储引擎的职责单一化专门化，从而更好地为分布式存储系统提供相应的服务和功能。