作者 | Yehuda Sadeh-Weinraub

译者 | 刘雅梦

策划 | 丁晓昀

今年是 RADOS 块设备（RBD），Ceph 块存储接口诞生后的第十五年。Ceph 是一个分布式存储系统。它由 Sage Weil 在加州大学圣克鲁斯分校的博士论文中启动，最初的设计只是作为一个从头开始构建的分布式文件系统。随着 Ceph 发展成为一个统一的企业级存储平台，除了文件系统接口外，Ceph 现在还支持对象和块存储。RESTful 对象存储接口（RADOS Gateway，或 RGW），旨在与 AWS S3 兼容，以及 RBD，一个块存储系统，是后来增加的，扩展了 Ceph 的能力。这个周年纪念是一个很好的回顾 RBD 如何诞生的机会。

我于 2008 年加入 Ceph 项目。我的第一次提交是在一月份；那年晚些时候我开始全职工作。一开始就很激动人心。Sage 和我在洛杉矶市中心一栋高层建筑的五十层共用一间办公室。每天午餐时，我们都有一个非常私人的 Ceph 会议。如今，Cephalocon，一年一度的 Ceph 会议吸引了来自世界各地的数百名参与者。那时，Ceph 刚刚从学术界毕业，在 DreamHost （Sage 多年前与人共同创立的一家公司）开始了第二阶段的孵化。全职从事 Ceph 工作的总人数就 2 个。

在我工作的第一天，Sage 告诉我，存储库里有一个 TODO 文件，我应该做我想做的。我把这句话的两个部分视为两个不同且独立的信息。在看了 TODO 文件后，我倾向于“我应该做我想做的”，并看到以下内容：

在早期，我们能做的事情堆积如山，所以我们真的尝试探索了很多方向。Sage 最近为 Ceph 添加的快照功能占用了这个 TODO 文件的很大一部分。我选择的第一个项目，ceph.conf 配置系统，它不那么引人注目，但却是必不可少的。在此之前，为了运行任何 Ceph 命令，你需要在命令行中传入所有配置。对于一个学术项目来说，这可能是可以接受的，但任何有用的应用程序都需要一个可行的配置系统。

一个 RESTful 对象存储系统

我们继续致力于让 Ceph 文件系统为黄金时间做好准备，在此过程中，我们还考虑了存储系统可以做的其他伟大的事情。在 2009 年初，我开始研究一个新的和令人兴奋的 RESTful 对象存储系统（最初命名为 C3，很快切换到临时名称 RADOS Gateway 或 RGW）。Ceph 已经有了一个名为 RADOS 的内部对象存储系统，那么为什么不直接通过 S3 API 暴露它呢？结果发现有很多原因可以解释为什么将 RADOS 直接 1:1 映射到 S3 不是一个好主意。

RADOS 语义与 S3 兼容系统所需的语义有很大不同。例如，RADOS 的对象大小限制相对较小，而 S3 可以支持高达 5TB 的对象。S3 将对象保存在索引桶中。然而，RADOS 将对象保存在未索引的池中，因此列出没有索引的对象是一种非常低效的操作。我们在弄清楚正确的 RGW 架构的过程中遇到了很多这样的问题。

我探索了一个并行的工作，我们称之为“活动对象”，这是 Ceph 对象类的前身。我们的想法是让计算更接近数据，这样我们就可以扩展存储做更多的事情。在第一次迭代中，你可以推送一个 Python 代码片段，然后在 Ceph 对象存储守护进程（OSDs）中执行。

关注谷歌新闻

那时，当你在谷歌上搜索 Ceph 时，大多数搜索结果要么是关于公共卫生教育委员会的，要么是关于电子艺术 Crysis 游戏系列中的 Ceph 外星物种的。我为“Ceph”关键词设置了一个谷歌新闻提醒，看看是否有人发表了关于我们项目的任何内容。在 2009 年 11 月初，我收到了一个通知，链接到一篇 关于 Sheepdog 的文章，这是一个新的 QEMU 分布式块存储系统。这触发了谷歌新闻提醒，因为有人在评论中建议 Ceph 可能是一个更可行的解决方案。我指着 Sage 说：

早期的 RBD 实现

可以理解的是，我们并没有为了实现这一点而搁置所有其他工作。我们正忙于实现 CephX，Ceph 的身份验证和授权子系统（在我们决定如何命名之前，X 是一个占位符，这是一项我们从未有时间完成的任务）。Ceph 文件系统内核模块尚未合并到 Linux 内核中，这是我们一段时间以来一直在积极努力实现的一个里程碑。为了保持 Ceph 的真正开放过程，Sage 在接下来的一周发布了一封邮件列表消息，介绍了这个想法。他建议了 两个项目（Weil, Sage, Email to Ceph-devel 邮件列表。2009 年 11 月 11 日）：

几个月后，Christian Brunner 对我们的行动呼吁做出了回应，他向我们发送了一个 QEMU 驱动程序的初始实现。我们能够使用他创建的基础，并开始准备将其包含到上游 QEMU 中。Ceph 文件系统模块在几周内被合并到 Linux 内核中，这对项目来说是一个巨大的成功。我还决定开发第二个内核驱动程序，这次是一个与这个 QEMU 驱动程序兼容的块设备驱动程序。

这两个 RBD 驱动程序是两个独立的实现；它们之间共享的代码非常少，因为其中一个是编写为在用户空间运行并与 QEMU 块接口集成，而另一个是创建为作为 Linux 内核模块运行并实现内核块驱动程序的接口。两个驱动程序都非常精简，并将 I/O 操作转换为 RADOS 对象操作。一个单一的块图像被分割成多个小尺寸的 RADOS 对象，这允许操作在多个 OSD 上并行运行，这得益于 Ceph 的横向扩展功能。

更多功能

我们为两个 RBD 驱动程序添加了更多功能：用于 RBD 卷的管理工具和对快照的支持。为了使快照正确工作，运行实例需要在创建时了解它们。为此，我实现了一个新的 Ceph 子系统，称为 Watch/Notify，它允许通过 RADOS 对象发送事件。RBD 实例“监视”其图像元数据对象，管理工具在创建新快照时向其发送通知。

我们创建的首次使用的另一个子系统是 Ceph 对象类。这种机制允许在 RADOS I/O 路径中创建专门的代码，可以被调用以对 RADOS 对象进行变异或进行复杂的读取操作。第一个对象类被实现以跟踪 RBD 快照的名称及其映射到 RADOS 快照 ID。与需要更复杂的锁或其他机制来处理竞争的动态读 - 修改 - 写周期不同，我们只会发送一个单一的 RBD 快照创建调用，它将在 OSD 上原子地完成。

上游验收

创建 RBD Linux 内核设备驱动程序需要清理所有 Ceph 内核代码，并将通用的 RADOS 代码移动到一个单独的内核库中。我们在创纪录的时间内将其纳入 Linux 内核。它于 2010 年 10 月在上游被合并，距离文件系统被合并后仅六个多月。

Christian 继续帮助 QEMU 驱动程序的开发，现在他回忆起让 QEMU 驱动程序上游的最困难的部分是：

“当时，为了说服 QEMU 项目相信分布式存储系统的驱动程序是必要的，我们进行了相当大的讨论。”

此外，在 QEMU 项目内部还有一场单独的讨论，讨论是否应该合并驱动程序，或者他们是否应该创建一个插件块存储机制，允许外部添加不同的驱动程序，而不需要它们的参与。大约在同一时间，sheepdog 项目也在审查中，并参与了同样的讨论。QEMU 项目开发人员不想处理新驱动程序不可避免会带来的问题和错误。我们和 sheepdog 开发人员都表示我们将处理我们的驱动程序出现的问题。最后，单体路径占了上风，并决定将驱动程序作为 QEMU 存储库的一部分。

我们经历了审查过程，并确保我们对审查人员提出的所有问题做出了回应和解决。例如，驱动程序使用的原始线程模型是错误的，需要解决。最后，在将内核 RBD 驱动程序合并到 Linux 内核几周后，我们还合并了上游的 QEMU 驱动程序。

从第一个想法到两个驱动程序被合并，只花了大约一年的时间。整个项目催生了多个子项目，这些项目现在已成为 Ceph 生态系统的基础。RBD 建立在 RADOS 提供的坚实基础之上，因此，它得益于所有 Ceph 项目贡献者的辛勤工作。

RBD 的好处

RBD 几乎一夜成名。现在，它成为了虚拟化和云系统中的关键存储基础设施。由于其无缝集成和可扩展性，它成为了 OpenStack 事实上的标准持久存储。在 Kubernetes 中，它提供了有状态容器化应用程序所需的可靠持久存储层。在传统的虚拟化和私有云环境中，它提供了一个开放的、分布式的、高可用的虚拟机存储，作为专有存储的替代品。由于许多 Ceph 项目贡献者和其他与之交叉的项目的努力，它仍在不断改进和演变。

展望未来

这是一个展示开源力量的合作努力。希望取代旧 TODO 文件的内容不会那么模糊，但不会更短。我们仍然有很多工作要做，还有更多我们甚至无法想象的创新领域。有时，一个想法的火花和一个有愿意的社区就是所需要的一切。

感谢 Christian Brunner 和 Sage Weil 提供的宝贵意见。