导读: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)上,收录了一篇论文,称经过十年的评估,作者认为 Ceph 的并不适合作为分布式存储后端(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
领取专属 10元无门槛券
私享最新 技术干货