分布式存储 Ceph 的演进经验 · SOSP 2019 转载于：真没什么逻辑本文要

转载于：真没什么逻辑
本文要介绍的是 2019 年 SOSP 期刊中的论文 —— File Systems Unfit as Distributed Storage Backends: Lesson Effis from 10 Years of Ceph Evolution[^1] ，该论文介绍了分布式存储系统 Ceph 在过去 10 多年演进过程中遇到的一些问题，我们作为文件系统的使用者也能从中可以借鉴到很多经验与教训，在遇到相似问题时避免犯相同的错误。
文章插图
图 1 - Ceph
从 2004 年到今天， Ceph 的存储后端一直都在演变，从最开始基于 B 树的 EBOFS 演变到今天的 BlueStore ，存储后端已经变得非常成熟，新的存储系统不仅能够提供良好的性能，还有着优异的兼容性。我们在这篇文章中将要简单介绍分布式存储 Ceph 的架构以及演进过程中遇到的挑战。
Ceph 架构分布式文件系统能够聚合多个物理机上的存储空间并对外提供具有大带宽、并行 I/O、水平扩展、容错以及强一致性的数据存储系统。不同的分布式系统可能在设计上稍有不同并且使用不同的术语描述物理机上用于管理存储资源的模块，但是存储后端（Storage backend）一般都被定义为直接管理物理机上存储设备的软件模块；而在 Ceph 中这一模块就是对象存储设备（Object Storage Devices、OSDs）：
文章插图
图 2 - Ceph 架构
Ceph 使用如上图所示的架构，它的核心是可靠自主分布式对象存储（Reliable Autonomic Distributed Object Store、RADOS），该模块可以水平扩展出成千上万个 OSDs 提供自愈、自管理并且强一致的副本对象存储服务。
我们可以使用 Ceph 提供的 librados 操作 RADOS 中存储的对象和对象集合，该库提供了易于操作的事务接口，在该接口之上我们可以构建出：

RADOS 网关（RGW）：类似于 Amazon S3 的对象存储；
RADOS 块设备（RBD）：类似于 Amazon EBS 的虚拟块设备；
CephFS：提供 POSIX 语义的分布式文件系统；

RADOS 中的对象会被存储在逻辑分区中，也就是池（Pool）；对象会在池中分片，每个分片单位被称作放置组（Placement Groups、PGs），放置组中的数据会根据配置好的副本数同步到多个 OSD 上，这样可以在单个 OSD 宕机时保证数据的正确性。
RADOS 集群中的每个节点都会为每个本地存储设备运行独立的 OSD 守护进程，这些进程会处理来自 librados 的请求并配合其他 OSD 节点完成数据的拷贝、迁移以及错误恢复等操作，所有的数据都会通过内部的了ObjectStore 接口持久化到本地，我们可以为硬件设备实现不同的接口以满足兼容性的需求。
演进挑战与其他的分布式文件系统不同，今天 Ceph 的存储后端 BlueStore 绕过了本地的文件系统，直接管理本地的裸设备，这是因为 Ceph 团队的经验说明在本地的文件系统上构建存储后端是一件非常麻烦的事情：

文章插图
图 3 - 存储后端的挑战

在本地文件系统上直接构建无额外开销的事务机制是非常复杂的；
本地文件系统的元数据性能对分布式文件系统的性能有很严重的影响；
成熟的文件系统有着非常严格的接口，适配新的存储硬件很困难；

高效事务事务可以通过将一系列操作封装到独立的原子单元来简化应用程序的开发，这一系列操作要么全部执行、要么全部执行，对数据库稍有了解的工程师应该都很了解事务的四个特性，也就是原子性、一致性、隔离性和持久性，我们这里就不展开讨论了。
虽然事务能够极大地简化应用程序开发者的工作并减轻负担，但是想要在本地的文件系统之上支持高效地事务机制是非常有挑战的任务，这篇论文给出了三种实现事务的方法：

文章插图
图 4 - 三种实现事务的方式

基于文件系统内部的事务机制 — 很多文件系统都在内部实现了事务，这样能够原子地执行一些内部的复合操作，然而因为这些事务机制仅用于内部，所以功能非常受限、甚至不可用，所以也就很难利用文件系统的内部事务；
在用户空间实现逻辑预写式日志（Write-Ahead Log、WAL）— 虽然这种实现方式可以工作，但是它却会遇到三个比较严重的问题；

读-修改-写操作缓慢（Slow Read-Modify-Write）— 基于 WAL 的日志机制会为每个事务执行如下所示的步骤：序列化事务并写入日志、调用 fsync 提交事务、事务操作提交到文件系统，因为每个事务在执行前都需要读取前一个事务执行的结果，即等待三个步骤执行完成，所以这种实现比较低效；