今年是 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 提供的宝贵意见。
原文链接：
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论