Ceph 发展十年的教训：文件系统不适合作为分布式存储后端

导读：Ceph 是一个 Linux 的 PB 级分布式文件系统，与 POSIX 兼容，使用 Ceph 存储集群来存储数据。 Ceph 文件系统与 Ceph 块设备、同时提供 S3 和 Swift API 的 Ceph 对象存储、或者原生库（ librados ）一样，都使用着相同的 Ceph 存储集群系统。Ceph 最初是一项关于存储系统的博士生研究项目，由 Sage Weil 在圣塔克鲁兹加利福尼亚大学（University of California, Santa Cruz，UCSC）实施。但是，在今年的操作系统原理会议（Symposium on Operating Systems Principles，SOSP）上，收录了一篇论文，称经过十年的评估，作者认为文件系统并不适合作为分布式存储后端（File Systems Unfit as Distributed Storage Backends）。作为系统领域的最高学术会议，作者抛出这一观点，一时间，引起了轩然大波。这究竟是怎么回事呢？专注于分布式系统的 Murat Demirbas 教授为我们解读了这篇论文。

本文最初发表在 Murat Demirbas 个人博客上，经原作者授权，InfoQ 中文站翻译并分享。

正文：

本文系论文 File systems unfit as distributed storage backends: lessons from 10 years of Ceph evolution （《Ceph 发展十年的教训：文件系统不适合作为分布式存储后端》）的解读。该论文的作者是 Abutalib Aghayev、Sage Weil、Michael Kuchnik、Mark Nelson、Gregory R. Ganger。

Ceph 最初是 2004 年在圣塔克鲁兹加利福尼亚大学（University of California, Santa Cruz，UCSC）的一个研究项目。Ceph 的核心是一个名为 RADOS 的分布式对象存储。存储后端是在已经成熟的文件系统上实现的。文件系统有助于块分配、元数据管理和崩溃恢复。Ceph 团队在现有的文件系统上构建了存储后端，因为他们并不希望从头开始编写存储层。因为完整的文件系统需要耗费大量的时间（十年）来开发、稳定、优化和成熟。

但是，在存储路径中如果使用文件系统的话，会带来很多开销。这给高效事务的实现带来了问题。它为元数据操作带来了瓶颈。例如，分页等也会带来问题。为了避免这些问题，Ceph 团队尝试通过在用户空间中实现 WAL 来连接到文件系统内部，并使用 NewStore 数据库来执行事务。但是，文件系统还是很难处理。自 2010 年以来，他们修补问题已经有七年了。Abutalib 将此比作悲伤的阶段：否认、愤怒、讨价还价……和接受！

最后，Ceph 团队被迫放弃了文件系统方法，开始编写自己的存储系统 BlueStore，它不使用文件系统。他们在短短两年内，就能够完成并达到了成熟的存储级别！这是因为小型定制后端比 POSIX 文件系统成熟得更快。

与早期版本相比，新的存储层 BlueStore 实现了非常高的性能。通过避免数据日志记录，BlueStore 能够实现比 FileStore/XFS 更高的吞吐量。

当使用文件系统时，脏元数据 / 数据的回写（write-back）会干扰 WAL 的写操作，并导致较高的尾延迟（tail latency）。相反，通过控制写操作和使用写通（write-through）策略，BlueStore 确保没有后台写操作干扰前台写操作。这样，BlueStore 就避免了写操作的尾延迟。

最后，对 I/O 堆栈的完全控制加速了新硬件的采用。例如，虽然文件系统很难适应叠瓦式磁记录（shingled magnetic recording）存储器，但作者能够为它们添加对 BlueStore 的元数据存储支持，数据存储正在进行中。

综上所述，我们得到的经验教训是，对于分布式存储而言，与为实现这一目的而硬塞文件系统相比，实现定制后端可以做到又快又好。

上图是存储后端 BlueStore 的架构图。所有元数据都在 RocksDB 中维护，RocksDB 位于 BlueFS 之上，而 BlueFS 是最小的用户空间文件系统。

作者介绍：

Murat Demirbas，纽约州立大学布法罗分校（SUNY Buffalo）计算机科学与工程教授，研究方向为分布式系统、分布式共识和云计算。

原文链接：

SOSP19 File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution