Ceph 文件系统 (CephFS) 是 Ceph 的文件存储解决方案。自 Jewel 版本发布以来，它在配置单个活动元数据服务器（具有一个或多个待机服务器以实现冗余）的情况下被认为是稳定的。现在在 Luminous 中，多活动元数据服务器配置已经稳定并准备好部署！这使得 CephFS 元数据操作负载容量能够随着活动元数据服务器的数量线性扩展。

默认情况下，新创建的文件系统仅使用单个活动元数据服务器，但操作员可以通过增加文件系统上的 ranks 数量来转换为使用多个活动元数据服务器。可以使用以下命令来完成此操作：

$ ceph fs setmax_mds

例如

$ ceph fs set cephfs_a max_mds 2 $ ceph fs status cephfs_a - 0 clients

+------+--------+-----+---------------+-------+-------+ | Rank | 状态 | MDS | 活动 | dns | inos | +------+--------+-----+---------------+-------+-------+ | 0 | active | a | 请求: 0 /s | 0 | 0 | | 1 | active | b | 请求: 0 /s | 0 | 0 | +------+--------+-----+---------------+-------+-------+ +-------------------+----------+-------+-------+ | Pool | 类型 | 已用 | 可用 | +-------------------+----------+-------+-------+ | cephfs_metadata_a | metadata | 4098 | 9554M | | cephfs_data_a | data | 0 | 9554M | +-------------------+----------+-------+-------+ +-------------+ | 待机 MDS | +-------------+ | c | +-------------+

多活动元数据服务器 (multimds) 是如何工作的？ ¶

CephFS 的一个显著特点是它能够将文件系统树划分为子树，每个子树都可以分配给特定的 MDS 进行权威管理。这使得文件系统的元数据负载能够随着元数据服务器数量的增加而线性扩展。

每个子树都是根据给定目录树中元数据的热度动态创建的。一旦子树创建，其元数据就会迁移到负载不足的 MDS。随后的客户端请求会转发到以前的权威 MDS。

对于好奇的人来说，可以通过每个 MDS 的 admin socket 获取有关当前子树分区的信息：

$ ceph daemon mds.a get subtrees | jq '.[] | [.dir.path, .auth_first]' ["", 0] ["~mds0", 0] ["/users/joe", 1] ["~mds0/stray1/10000000001", 1]

“” 子树是文件系统的根 (“/”)，始终由 rank 0 管理。“/users/joe” 子树由 rank 1 管理。（以“~” 开头的子树路径是文件系统层次结构中不包含的内部子树。）

(请注意：对于任何尝试此命令的人，请注意每个 MDS 并不一定拥有文件系统子树划分的完整视图。MDS 只需要知道其自身子树的相邻子树。因此，如果您想对整个文件系统的子树划分进行任何类型的分析，则必须在每个 MDS 上运行此命令。)

有关配置多个活动元数据服务器的更多信息，请参阅 文档。

您期望看到哪些改进？ ¶

每个 MDS 处理其管理的子树上的请求。这使得 MDS 集群能够处理比任何单个 MDS 能够支持的更多的请求。

例如，在对多个并发 Linux 内核构建（tar -x、make，然后rm -rf）进行分布式实验的独立客户端中，我们观察到工作负载在多个元数据服务器上均匀分布。下图显示了在实验过程中每个 MDS（16 个 ranks）处理的客户端请求。

这是 最近在 Vault 2017 上展示的 CephFS 测试的一部分。

当然，这种“令人尴尬地并行”的工作负载（在独立的目录树中运行的多个客户端）有些人为。并非所有工作负载都能受益，尤其是在客户端在单个目录或文件上进行更新时。

结论 ¶

使用元数据服务器集群协同管理文件系统层次结构一直是 CephFS 自诞生以来的一个定义性方面。Ceph 团队在过去两年中努力设计新的测试并修复任何潜在的错误，以实现稳定的产品。我们期待听到社区的成功案例和反馈！