CephFS MDS 状态讨论

最近有很多人询问 Ceph MDS 的当前状态以及何时发布稳定版本。Inktank 一直在内部讨论 CephFS 的发布开发，我想与大家分享这些讨论，并征求反馈意见！

几个简短的说明：首先，这篇博文是从 Inktank 的开发角度出发的。我们并不是唯一生成元数据服务器 (MDS) 补丁的人，其他各方可能会做出具有不同优先级的贡献！其次，这是关于 MDS 开发的讨论——请期待一篇关于 MDS 作用和工作原理的博客文章，它很快就会推出！

当前状态

在过去的一年里，我们 Inktank 不幸地暂时搁置了文件系统——我们仍然相信它的功能集和能力将彻底改变存储，但我们意识到它需要比 RBD 和 RGW 更多的工作才能成为稳定的产品，所以我们将精力集中在我们能提供给客户的软件上。这仍然是 Inktank 的组织重点，但在新年伊始，发生了一些奇妙的事情（对我个人而言）！我们成立了一个内部 CephFS 团队，我和 Sam Lang 一直将越来越多的时间投入到 MDS 和文件系统的开发工作中。这种重新聚焦强调了仍然存在的问题。有一些勇敢的组织正在测试或生产环境中使用 CephFS，但对他们来说，其用途越重要，他们所依赖的功能就越少。对于社区成员，我的建议是在您的工作负载下测试 CephFS 两周，注入一些故障（节点重启等），如果它能顺利通过，那么它应该会继续工作——有些人已经运行系统数月没有问题，但其他人可能在第二次或第三次命令时就遇到了麻烦。基本上，如果您的工作负载碰巧看起来像我们定期运行的测试套件之一，它应该没问题——但如果它稍微偏离一点，就会有我们尚未发现的隐藏陷阱。

最初我们的目标是稳定文件系统已经具备的功能并开发 fsck，但通过最近的讨论，我们意识到我们没有坐下来弄清楚我们的用户和客户实际需要 CephFS 做什么才能将其投入生产部署。更重要的是，虽然我们多年来一直将 CephFS 视为一个包含快照、多个活动服务器和无限目录大小等功能的强大集合，但我们不知道哪些功能对于首次发布是真正必要的——我们一直在处理的错误提醒我们，其中一些功能需要比其他功能多得多的稳定性工作。

考虑到这一点，我们现在开始与客户、用户和整个社区讨论 CephFS 的“最小可行产品”会是什么样子。我们的起点是从开发角度来看容易实现的功能，我们欢迎用户就这是否对他们有用，或者在他们能够部署之前需要如何改变提供反馈。

最小可行产品提案

随着我们将更多的工程资源重新投入到 CephFS 中，我们正在考虑什么是最小的有用功能集，以便尽快将 CephFS 交到生产用户手中。我们目前正在考虑的是一个单一活动 MDS，单个目录中的最大条目数，没有 fsck，并且没有快照。它提供了一个 POSIX 兼容的文件系统，可以挂载到数千个客户端上，可扩展到任意大的数据吞吐量，允许层次结构中包含无限数量的文件，具有位置感知功能，并且可以通过多种接口使用（Ganesha NFS、Hadoop、内核内和基于 FUSE 的客户端、Samba 等）。

让我详细解释一下这些论断的含义。

单一活动 MDS

CephFS 的一个主要功能是它可以在大量元数据服务器守护程序之间实现横向扩展。这在未来仍将是一个主要功能，但目前它会引入显著的系统不稳定性，因此它不会包含在我们最初支持的版本中。

然而，备用和活动备用功能非常稳定，将成为第一个版本的一部分。这意味着快速故障转移功能（30 秒或更短，具体取决于用户设置、硬件以及对不必要故障转移的容忍度）将起作用，允许用户在硬件故障或维护期间配置任意数量的服务器以接管工作。

单一 MDS 配置带来的主要限制是系统可以处理的每秒元数据操作数、它可以处理的同时客户端连接数以及 MDS 可以在内存中存储的元数据量。最后一点限制了可以同时使用并具有良好性能的文件数量，但不限制系统中的文件总数（这仍然是无限的）。一如既往，MDS 节点可用的 RAM 和 CPU 量将对这些限制的精确位置产生巨大影响。

附注：我们目前默认缓存 100,000 个 inode，但这非常保守，并且适合低数百 MB 的 RAM。我们目前还没有每个 inode 内存消耗的最新具体数值。

单个目录中的最大条目数

CephFS 包括对目录“分段”（或分片）的初步支持，这使我们能够将单个目录在磁盘上拆分，并在多个 MDS 服务器之间拆分。然而，同样，尽管代码存在，但它需要大量的验证和调试，因此我们的第一个版本将不提供支持，并且我们需要限制单个目录中允许的总条目数。这是一个开放谈判的软限制——MDS 需要能够在从磁盘读取时将整个目录保存在内存中，如果目录包含的条目多于 MDS 缓存所能容纳的条目，缓存效率和整体性能自然会下降（并且，如果使用多个目录，它们将相互反馈）。

然而，“手动”通过任何给定的启发式方法（将其拆分得足够精细）来对目录进行分片工作正常，并且此限制并不意味着对系统中文件总数的限制。（只要考虑了上面讨论的活动元数据的最大量即可。）

没有 fsck

与许多分布式系统一样，CephFS 目前不提供 fsck。初步设计工作已经完成，但尚未实现。CephFS 当然继承了 RADOS 的底层可靠性方法，其中包括定期擦洗数据以确保副本之间的一致性、基于校验和的有效性检查（即将在 Cuttlefish 版本中推出）以及数据复制和降级时的恢复。不幸的是，这并不能完全确保 CephFS——完全丢失的对象将转化为文件空洞，并且不一定会触发警报。文件系统层次结构中任何丢失的目录（将被检测到）必须手动修复。

从积极方面看，由于 Ceph 的设计，层次结构中未受损的部分将继续运行，即使数据已丢失。

没有快照

虽然 CephFS 对目录层次结构的快照有初步支持，但它也需要显著的强化和调试。我们最初的版本将不支持它们。当它们发布时，它将成为分布式文件系统中的一项开创性功能。

POSIX 兼容

CephFS 是 POSIX 兼容的，一直如此，并且将永远如此。它提供正确的（而不是像 NFS 那样的 open-to-close）一致性，并且支持甚至不常用的功能，例如文件锁定。

硬链接也受支持，尽管在其当前的实现中，每个链接都需要少量的 MDS 内存，因此存在基于可用内存的隐含限制。我们已经设计但尚未实现一种新的解决方案来避免这个问题。

可供数千个客户端同时使用

在过去的测试中（在 Sage Weil 的博士论文工作中），MDS 服务器处理每个 1000 个客户端没有问题，虽然我们最近没有测试过，但我们预计这个数字有所改善而不是下降。

可扩展到任意数据吞吐量

在 CephFS 中，一旦客户端打开文件，MDS 就不再在数据路径中发挥作用。这意味着如果您的客户端可以发送数据，并且您的 OSD 可以写入数据，则单一 MDS 限制不会直接影响可用的总带宽。隐含的限制是基于每个客户端可以发送多少数据以及 MDS 可以处理的活动文件总数。

允许层次结构中包含无限数量的文件

尽管如上所述，单个目录的大小有限制，但 Ceph 不要求系统中的每个文件始终占用 MDS 内存。这意味着与许多其他系统不同，它没有也不会有对可用文件总数的硬限制。

具有位置感知功能

CephFS 构建在 RADOS 之上，后者具有基于故障域的布局引擎（默认情况下自然映射到数据中心的物理主机、机架、行、房间布局）。CephFS 允许客户端查询此布局数据以获取文件，并可选择从本地副本读取。对位置感知感兴趣的系统也会喜欢为每个文件设置自定义布局的能力，指定底层对象大小和池（这进一步决定了所使用的条带策略）。

多种接口

原生 ceph 客户端可在上游 Linux 内核中以及用户空间中作为库和 FUSE 模块使用。除了通过这些标准机制可用的常规接口选项之外，该库已集成到 Ganesha NFS 服务器和 Samba 中；与 Hadoop 完全集成；并且可以集成到任何自定义应用程序中。

反馈

如前所述，我们非常希望获得您对这些想法的反馈。这篇博客发布时，我正在 ceph-users 上发起一个讨论帖；您可以在这里评论；或者您可以通过 irc 联系我们中的任何一个。我们将感谢您提供的任何信息！

-Greg 敬上