文章/ebofs-design-overview

6 分钟阅读

EBOFS 简介

介绍 Ceph 早期 EBOFS 存储引擎的设计与取舍。

介绍 EBOFS 的资料很少,下面是一些可以公开的情报。

the Ceph paper

Ceph: A Scalable, High-Performance Distributed File System

很多分布式存储系统使用 ext3 这样的本地文件系统来管理底层存储,但我们发现对于对象负载,这些本地文件系统的接口和性能都很差。当前的内核接口限制了我们判断对象的更新是否已经安全地提交到了磁盘的能力。

同步写(synchronous writes)或 journaling 提供了期望的安全性 ,但会带来很大的延迟和性能损失。更重要的是,POSIX 接口无法支持原子的数据和元数据(例如,attribute)更新事务,而这对于维持 RADOS 的一致性非常重要。

因此,每个 OSD 用 EBOFS(an Extent and B-tree based Object File System)管理它的本地对象存储。

EBOFS 完全在用户态实现,直接和裸块设备交互,这使得我们可以自己定义低层的对象存储接口和更新语义,从而将更新的顺序化(update serialization)(为了同步)和 磁盘提交(为了安全性)分离开来。 EBOFS 支持原子事务(例如,对多个对象进行写和属性更新),更新函数在内存中的缓存更 新之后就返回,提供异步的磁盘提交通知。用户态的实现除了提供更好的灵活性和更简单的 实现之外,也避免了和 Linux VFS 和 页缓存(page cache)的笨重的交互,这两者都是为 不同的接口和负载设计的。

大部分内核文件系统都是惰性地(lazily)将更新 flush 到磁盘,但 EBOFS 是主动地调度磁盘写操作,并且如果后面的更新会覆盖前面的更新,那前面的 pending 更新可能会在 flush 之前就被取消了。这使得我们的低层磁盘调度器有一个更长的 I/O 队列,可以提高调度的效率。用户态的调度器还使得按优先级排序更容易(例如,client I/O 和恢复相比 ),或者提供 QoS 保证。

EBOFS 的核心设计是一个健壮的、灵活的、功能完整的 B-Tree 服务,用于定位对象在磁盘中的位置、管理块分配、对 PG 进行索引

块分配是以 extent (start, length) 为粒度进行的,而不是以 block list 的方式,这样可以使元数据更紧凑。 磁盘上空闲的 block extent 按位置排序,按大小管理在一起,使得 EBOFS 可以在限制长期的碎片的同时,快速的定位写位置附近的空闲空间,或者磁盘中的数据。 除了每个对象的块分配信息这个例外,出于性能和简单考虑,其他的元数据都保持在内存中(元数据很小,即使对于非常大的 volume)。

最后,EBOFS 主动执行写时复制(Copy on Write,COW),除 superblock 的更新外,其他数据都是写到磁盘上还未分配的区域。

Leveraging Intra-object Locality with EBOFS

Leveraging Intra-object Locality with EBOFS

摘要

目前和未来的大型分布式文件系统跨大量 OSD 分割数据。然而,单个 OSD workload 往往没有对象间引用的局部性。 由于磁盘查找的开销,小的对象尺寸会降低 OSD 效率。EBOFS 允许任意大小的对象,并通过在磁盘上连续分配数据来保留对象内引用的局部性,甚至在磁盘文件系统的整个生命周期内都保持较高的连续性,从而使 OSD 可以更高效地运行,最大化整个分布式文件系统的性能。

引言

大型分布式存储系统的一种引人注目的体系结构包括使用半智能的基于对象的存储设备(OSD),以及将元数据(命名空间和层次结构)操作与文件读写分开。

OSD 是一种有吸引力的设计选择,因为它们隐藏了块分配和磁盘一致性的繁琐细节,暴露了基于 Object ID 的简单接口,简化了文件系统设计。这种设计选择的结果是 OSD 模型会阻止通用文件系统使用的久经考验的真实策略来放置文件数据,即基于目录或时间局部性的策略。取而代之的是,文件被分散在大量 OSD 上,从而提供了对数据的大规模并行和可扩展访问。因此,单个 OSD 的工作负载在不同的读取和写入请求之间很少可以看到可以参考的局部性引用。保留在工作负载中的唯一形式的局部性是对象内部的局部性,通常是顺序访问对象数据的形式。许多跨大量存储服务器的分布式文件系统对文件数据进行条带化,以提高并行吞吐量,并使用固定大小的块来分配负载。因此,在单个存储设备上观察到的工作负载似乎是随机的,并且通常涉及对每个数据访问的 seek,导致效率相对较差。

EBOFS 试图通过存储任意大小的对象并将这些对象的内容连续写入磁盘来提高性能。在 Linux 2.6 内核中实现的原型显示了类似于现有通用文件系统的顺序读写吞吐量,并且处理碎片的行为优于 ext2 等基于块的文件系统。一个分配模拟器对文件系统的预期寿命(文件系统的预期寿命)进行长期建模(大约 5 年,数十亿次写入或删除操作),表明长期碎片级别受到有效限制,并且分配器的效率保持一致, 这表明 EBOFS 可以使得 OSD 更好,从而实现更高的整体系统效率和吞吐量。

结论

基准测试表明,EBOFS 的性能与其他基于 VFS 的 Linux 文件系统相当,除了 XFS 和 Reiser3。它们重写了 VFS page 和 buffer caches 的部分内容。 生产级别的 OSD 设备应明确注意原始 IO 性能,并保持 caching 操作和代码路径的效率。

EBOFS 分配模拟器表明,碎片在文件系统的预期生命周期内受到限制,并且增长速度非常慢。 这种长期的碎片不会严重影响 EBOFS 为大型文件分配大范围数据的能力。 对象数据中的这种连续性使得 OSD 可以利用顺序访问的优势,这是 OSD 工作负载中可能存在的唯一一种局部性。 在未来的工作中,需要确定连续性将在多大分布式文件系统中影响 OSD 和聚合系统吞吐量的程度。

相关阅读

Memo修正 ZFS 主机的 Node Exporter 内存告警Memo两块 Gen3 x4 NVMe,速度差了一倍文章为什么 InnoDB doublewrite buffer 不能恢复 torn page

讨论

邮箱用于身份识别和回复通知,并由 Waline 存储。