分布式元数据缓存

Ceph 文件系统中的 inode 数据存储在 RADOS 中并由客户端直接访问，而 inode 元数据和目录信息由 Ceph 元数据服务器 (MDS) 管理。 MDS 充当所有元数据相关活动的媒介，将结果存储在与文件数据不同的、单独的 RADOS 池中。

CephFS 客户端可以请求 MDS 获取或更改inode元数据，但MDS也可以为每个inode授予客户端相应访问权限（caps）。

授予客户端的访问权限使得客户端可以缓存并修改inode相关的数据与元数据。当另一个客户端需要访问相同的信息时，MDS 将撤销（revoke）授予客户端的访问权限，客户端最终将返回访问权限以及更新的inode元数据（客户端在拥有访问权限期间，对 inode 元数据进行了更改）。

客户端可以向MDS请求并获取访问权限，但是，存在竞争访问或者MDS内存压力较大时，客户端获得的访问权限会被撤销（revoke），当客户端的访问权限被撤销时，客户端有责任尽快返回访问权限。未能及时返回访问权限的客户端最终可能会被列入阻止名单（blocklist）并且无法与集群通信。

由于缓存是分布式的，MDS 必须确保客户端的访问权限不会与其他客户端的访问权限或MDS本身执行的操作相冲突。这允许 cephfs 的客户端依赖于比 NFS 等文件系统更高的缓存一致性，NFS等文件系统的客户端缓存的数据与元数据可能与服务端不同（服务端很可能已经修改数据与元数据）。

当客户端需要查询/更改inode元数据或对目录执行操作时，客户端有两个选择：可以直接向MDS发出请求，或者，访问并操作本地缓存。在CephFS中，只有在客户端拥有必要的访问权限才可能访问并操作本地缓存。

客户端可以向 MDS 发送简单请求，以查询或请求更改某些元数据。 对这些请求的回复也可以授予客户端一组特定的 inode 访问权限，允许它在不咨询 MDS 的情况下执行后续请求。客户端还可以直接从MDS请求访问权限，这是读取或写入文件数据所必需的。

当 MDS 想要读取或更改inode相关信息时，它必须为其收集适当的锁（lock）。 MDS集群可能在给定的inode上有一系列不同类型的锁，每个MDS可能有不相交的锁集。

如果存在与这些锁冲突的访问权限，则必须在获得锁之前撤销（revoke）该访问权限。一旦竞争的访问权限返回给 MDS，MDS就可以获取锁并进行操作。

在由多个MDS服务的文件系统上，元数据缓存也分布在集群中的MDS之间。 对于每个 inode，在任何给定时间，集群中只有一个 MDS 被认为是权威的。 任何更改该inode的请求都必须由权威MDS完成，尽管非权威 MDS 可以将请求转发给权威 MDS。

非权威MDS也可以获得读锁，防止权威MDS在读锁被删除之前更改数据，以便非权威MDS可以向客户端提供 inode 信息。

inode的权威MDS也会随着时间而改变。 多个MDS将对缓存在它们中的inode主动进行责任平衡，也可以直接通过将某些子树固定（pinning）到单个 MDS ，然后有固定的MDS负责对应的inode。

 

动态元数据管理

元数据操作通常占所有文件系统操作的 50% 以上。与数据存储扩展（ I/O 吞吐量线性扩展）相比，元数据以更加复杂的方式进行扩展，这是由文件系统元数据的分层和相互依赖的特点决定的。因此，在 CephFS 中，元数据工作负载与数据工作负载分离，以避免给 RADOS 集群带来不必要的压力：元数据由一组元数据服务器 (MDS) 处理，CephFS通过动态子树分区在MDS 之间分发元数据。

动态子树分区

在上图展示的文件系统层次树中，阴影节点代表目录，非阴影节点代表文件。子树的划分方式是：灰色子树的元数据由MDS 0管理，浅蓝色子树的元数据由 MDS 1管理，橙色子树的元数据由MDS 2处理，红色子树的元数据由 MDS 3管理，深蓝色子树（只是一个目录）元数据由MDS 4管理。

传统子树分区的问题是工作负载按深度（跨单个MDS）增长会导致活动热点。 这导致缺乏垂直扩展和非繁忙资源（MDS）的浪费。

这导致采用更动态的元数据处理方式：动态子树分区，将目录层次结构中负载密集的部分从繁忙的MDS迁移到不繁忙的MDS。

此策略可确保活动热点在出现时得到缓解，从而导致元数据工作负载的垂直扩展以及水平扩展。

 

配置目录分片

在 CephFS 中，当目录变得非常大或非常繁忙时，目录就会进行分片。 这将拆分元数据 ，以便它可以在多个 MDS 守护进程之间以及元数据池中的多个对象之间共享。

在正常操作中，目录碎片对用户和管理员是不可见的，这里提到的所有配置的设置都应保留其默认值。

虽然目录分片使 CephFS 能够处理单个目录中的大量条目，但应用程序应该尽量避免创建非常大的目录，比如，CephFS客户端执行list操作列举目录的时候，必须将目录分片立即加载，这需要消耗资源成本的。

所有目录最初都是作为单个分片创建的。 可以拆分该分片以将目录分成更多的分片，并且可以合并这些分片以减少目录中的分片数量。注意根目录是不能分片的。

拆分与合并

当 MDS 确定要将一个目录分片进行拆分时，不会立即进行拆分。 由于拆分会中断元数据 IO，因此在拆分开始之前会有一个时间的延迟以便于短时突发的客户端IO的能够完成。 这个延迟是用配置项mds_bal_fragment_interval 设置的，默认为5秒。

 

拆分完成后，目录分片将拆分为2次幂的新分片。 新分片的数量为 mds_bal_split_bits 的2次幂，即如果 mds_bal_split_bits为2，则将创建4个新分片。 默认设置为 3，即拆分创建 8 个新分片。

 

分片大小阈值

当目录分片的大小超过mds_bal_split_size（默认10000）时，它就可以进行拆分。通常会按照配置项mds_bal_fragment_interval设置的时间进行延迟拆分，但是，如果分片大小超过拆分大小 mds_bal_split_size*mds_bal_fragment_fast_factor ，则拆分将立即发生（阻止目录上的任何客户端元数据 IO）。

mds_bal_fragment_size_max 是目录分片大小的硬限制。如果目录分片达到mds_bal_fragment_size_max大小，客户端在尝试在分片中创建文件时将收到 ENOSPC 错误。在正确配置的系统上，普通目录永远不应该达到此限制，因为它们很早以前就会分裂。默认情况下，这被设置为mds_bal_split_size的 10 倍，因此目录分片大小限制为 100000。增加此限制可能会导致元数据池中的目录分片对象过大，而 OSD 可能无法处理。

当目录分片的大小小于 mds_bal_merge_size 时，它就可以进行合并。合并没有类似于拆分时候的快速拆分的场景，快速拆分是为了避免创建过大的目录分片，拆分的时候不存在这样的问题。默认情况下，mds_bal_merge_size设置为50。

 

分片负载阈值

除了根据它们的大小拆分碎片之外，如果它们的访问活动负载超过阈值，MDS 可能会对目录分片进行拆分。

MDS 为目录分片的读、写操作维护单独的时间衰减负载计数器。衰减负载计数器会按照 配置项mds_decay_halflife 的设置进行指数衰减。

写入时，写入计数器递增，并与 mds_bal_split_wr 进行比较，如果超过阈值则触发拆分。写操作包括元数据 IO，例如， rename、unlink、 create。

mds_bal_split_rd 阈值的应用是基于读取操作负载计数器的，该计数器跟踪 readdir 操作。

默认情况下，读取阈值为 25000，写入阈值为 10000，即触发拆分所需的读取次数是写入次数的 2.5 倍。

由活动阈值导致的目录分片拆分后的分片，仅根据分片大小阈值(mds_bal_merge_size) 进行合并，因此访问活动负载激增可能会导致目录永远保持分片状态，除非分片中的一些条目被unlink了。

 

配置多个active的MDS进程

默认情况下，每个CephFS文件系统都配置一个active的MDS进程。要为大规模系统扩展元数据性能，您可以启用多个活动的 MDS 守护进程，它们将相互共享元数据工作负载。为大规模系统扩展元数据性能，可以启用多个active的MDS守护进程，多个MDS共同分担元数据工作负载。

 

使用多个active的 MDS 进程的时机

元数据性能在单个MDS进程上出现瓶颈时，应该配置多个active的MDS进程。增加active的MDS进程可能不会提高所有工作负载的性能。 通常，除非应用程序并行执行大量元数据操作，否则在单个客户端上运行的单个应用程序不会受益于多个active的MDS进程。

多个客户端访问多个不同的目录的情况下，此时的工作负载会受益于多个active的MDS进程。

 

如何增加 active的MDS进程

每个CephFS文件系统都有一个max_md设置，它控制将创建多少个rank。文件系统中的实际rank数量只有在有备用程序可用于承担新rank时才会增加。例如，如果只有一个MDS进程在运行，并且max_mds设置为2，则不会创建第二个rank。（注意，这种配置不是表示高可用性 (HA)，因为没有standby MDS可用于接管失败的rank。以这种方式配置时，集群运行中会出现健康告警的）。

将 max_mds 设置为所需的rank数。 在以下示例中，ceph mds stat结果以说明命令的预期结果。

$ ceph mds stat
cephfs:1 {0=ceph01=up:active} 2 up:standby
$ ceph fs set cephfs max_mds 2
$ ceph mds stat
cephfs:2 {0=ceph01=up:active,1=ceph03=up:active} 1 up:standby

 

多active的MDS进程场景下的standby的MDS进程

即使有多个active的MDS进程，如果任何运行active的MDS进程出现故障，高可用性文件系统仍然需要standby的MDS进程来接管。

因此，高可用文件系统的 max_mds 的实际最大值至多比文件系统中的MDS进程总数少1。

如果在发生多个active的MDS进程故障时保持可用，需要增加系统中standby的MDS进程数量，以匹配希望能够承受失败的active的MDS进程数量。

 

如何减少 rank数量

减少rank数是通过减少max_mds的值来实现的。

$ ceph mds stat
cephfs:2 {0=ceph01=up:active,1=ceph03=up:active} 1 up:standby
$ ceph fs set cephfs max_mds 1
$ ceph mds stat
cephfs:2 {0=ceph01=up:active,1=ceph03=up:stopping} 1 up:standby
$ ceph mds stat
cephfs:1 {0=ceph01=up:active} 2 up:standby

集群将自动逐个停止额外的rank，直到总rank数达到max_mds。

注意：关闭的rank将首先进入stopping状态一段时间，在此期间，它将自己负责的元数据移交给剩余的active的MDS进程。此阶段可能需要几秒钟到几分钟的时间。 如果 MDS 似乎卡在stopping状态，则应将其作为可能的bug进行定位跟踪。

如果MDS守护进程在 up:stopping 状态下崩溃或被杀死，standby的MDS将接管，并且MON尝试停止该MDS进程。

当守护进程完成up:stopping 状态，它会重新生成并恢复为standby状态。

 

动将目录树固定到特定rank

在多个active的MDS进程场景下，平衡器运行在整个集群中以对元数据负载进行均匀分布。这通常对大多数用户来说够用，但有时需要使用元数据到特定rank的显式映射来覆盖动态平衡器的元数据分布策略。这可以将应用程序访问负载进行均匀分布，或者限制用户元数据请求对整个集群的影响。

CephFS为实现此目标提供的机制称为*export pin*，这是目录的一个扩展属性。 这个扩展属性的名称是 *ceph.dir.pin*。 用户可以使用如下命令设置此属性：

setfattr -n ceph.dir.pin -v 2 path/to/dir

扩展属性的值是将目录子树分配到哪个rank。 默认值 -1 表示目录未分配到固定的rank。

目录的export pin是从其最近的父级继承的，在目录上设置export pin会影响其所有子目录。 但是，可以通过设置子目录的export pin来覆盖父目录的export pin。 例如：

mkdir -p a/b
# "a" and "a/b" both start without an export pin set
setfattr -n ceph.dir.pin -v 1 a/
# a and b are now pinned to rank 1
setfattr -n ceph.dir.pin -v 0 a/b
# a/b is now pinned to rank 0 and a/ and the rest of its children are still pinned to rank 1

 

设置子树分区策略

还可以通过一组策略设置子树的自动静态分区。在CephFS中，这种自动静态分区称为***临时固定\***。任何临时固定的目录（inode）将根据其 inode 编号的一致哈希，从而自动分配到特定rank。所有临时固定目录的集合应该均匀分布在所有rank中。

为什么称为临时固定，是因为一旦目录的 inode 从缓存中删除，该pin可能不会持续存在。但是，MDS故障转移不会影响目录的临时固定，MDS在其日志中记录哪些子树被临时固定，MDS 故障转移不会丢弃此信息。

目录要么是临时固定的，要么不是。它被固定到哪个rank是从它的inode号和一致哈希得出的。这意味着临时固定的目录在MDS集群中有些均匀分布。当MDS集群增长或缩小时，一致性哈希还可以最大限度地减少重新分配。因此，增长MDS集群可能会自动增加元数据吞吐量，而无需其他管理干预。

目前，有两种类型的临时固定：

Distributed Ephemeral Pins：此策略将目录进行分片（甚至远低于正常分片阈值）并将其分片作为临时固定子树分发到MDS集群。这等于是将直接子树分布到一系列 MDS rank上了。典型的示例是/home 录：我们希望每个用户的home目录都分布在整个MDS集群中。 可以通过以下方式设置：

setfattr -n ceph.dir.pin.distributed -v 1 /cephfs/home

Random Ephemeral Pins：此策略表明任何后代子目录都可能被临时固定。 这是通过目录的扩展属性 ceph.dir.pin.random设置的，该值设置为应该固定的后代子目录的百分比。 例如：

setfattr -n ceph.dir.pin.random -v 0.5 /cephfs/tmp

该命令将加载到缓存中或在 /tmp下创建的任何目录在在当时有50%的子目录被临时固定。

建议仅将其设置为较小的值，例如 .001 或 0.1%。 拥有太多子树可能会降低性能。 出于这个原因，配置项mds_export_ephemeral_random_max 对该百分比的最大值进行了限制（默认值：0.01）。 当尝试设置超出此配置的值时，MDS 返回 EINVAL。

Octopus 版本中的随机和分布式临时 pin 策略默认处于关闭状态。 这些功能可以通过 mds_export_ephemeral_random 和 mds_export_ephemeral_distributed 配置选项启用。

临时固定可能会覆盖父目录export pin，反之亦然。 决定遵循哪个策略的是最近的父目录的规则：如果较近的父目录有冲突的策略，则改用该策略。 例如：

mkdir -p foo/bar1/baz foo/bar2
setfattr -n ceph.dir.pin -v 0 foo
setfattr -n ceph.dir.pin.distributed -v 1 foo/bar1

 

foo/bar1/baz 目录将被临时固定，因为 foo/bar1 策略覆盖了foo上的*export pin*。 foo/bar2目录通常会服从 foo 上的 export pin。

 

相反的情况：

mkdir -p home/{patrick,john}
setfattr -n ceph.dir.pin.distributed -v 1 home
setfattr -n ceph.dir.pin -v 2 home/patrick

home/patrick 目录及其子目录将被固定到rank 2，因为它的export pin 覆盖了home目录上的临时固定策略。