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

阅读数:2362 2019 年 12 月 10 日 17:34

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 发展十年的教训:文件系统不适合作为分布式存储后端

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

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

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

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

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

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

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

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

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

作者介绍:

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

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

评论

发布
用户头像
小编你看,说明很多人在这么用啊,咋肥四
2019 年 12 月 12 日 11:46
回复
用户头像
翻译正文没问题,”导读“有问题,”作者认为 Ceph 的并不适合作为分布式存储后端(File Systems Unfit as Distributed Storage Backends)。“,这句明显是说”文件系统不适合作为分布式存储后端“
2019 年 12 月 11 日 11:47
回复
感谢指正,已修改。
2019 年 12 月 11 日 13:03
回复
用户头像
无脑
2019 年 12 月 11 日 10:02
回复
用户头像
原文的意思是:Ceph团队总结10年的经验得出一条:分布式文件系统不适合构建在本地文件系统之上。结果你能翻译成『Ceph 文件系统不适合作为分布式存储后端』。翻译和策划到底有没有过脑子,严重误导用户。
2019 年 12 月 11 日 09:24
回复
原文中:Finally the Ceph team deserted the filesystem approach and started writing their own storage system BlueStore which doesn't use a filesystem.
Ceph放弃了文件系统的方法,换成了bluestore的存储引擎,bluestore doesn't use a filesystem。

murat教授总结认为:To sum up, the lesson learned was for distributed storage it was easier and better to implement a custom backend rather than trying to shoehorn a filesystem for this purpose.
文件系统并不适合分布式存储。

严格来说,意思是filestore 不适合做存储,建议使用 bluestore。但翻译本身遵循了murat原文。

展开全部
2019 年 12 月 11 日 10:40
回复
ryanking 回复 Tina
翻译正文没问题,”导读“有问题,”作者认为 Ceph 的并不适合作为分布式存储后端(File Systems Unfit as Distributed Storage Backends)。“,这句明显是说”文件系统不适合作为分布式存储后端“
2019 年 12 月 11 日 11:47
回复
没有更多了