3.3.3 CephFS 高级特性
1. Snapshot（快照）
（1）Snapshot 特性介绍
CephFS 支持快照功能，快照文件被创建后将保存在快照对象目录中的隐藏子目录里。
通常来说，快照功能设计是为了保存文件系统在创建快照时间点的状态视图，但为了实现以下的附加特性，CephFS 快照设计选择有别于其他几类快照。
1）任意子树：快照可以在选择的任何目录中创建（而非仅能在根目录下创建），并覆盖该目录下文件系统中的所有数据。
2）异步：快照创建行为异步化，创建快照后由快照数据与实时数据差异造成的数据复制和数据迁移不能影响正常读写性能，只能延缓完成。
为了实现这两点，CephFS 快照使用了基于 COW 的实现。
（2）Snapshot 特性实现原理与细节
CephFS 快照中，较为重要的数据结构如下。
◆ SnapContext
一个 RADOS 系统的 SnapContext 由一个快照序列 ID（即 snapid）列表和每一个RADOS Object 在此列表上存亡时间所对应的关联表组成（如 Object 在 snap02 后创建，在 snap04 后删除，在表中会有所表示）。为了生成该列表，会将与 SnapRealm 关联的快照ID 和其 past_parents 的所有有效快照 ID 组合在一起（SnapClient 的缓存模式会过滤掉过期的快照，以确定哪些是有效快照）。
◆ SnapRealm
无论在任何时候创建快照，都会生成一个 SnapRealm，它的功能较为单一，主要用于将 SnapContext 与每个打开的文件关联，以进行写入。SnapRealm 中还包含 sr_t srnode、past_parents、past_children、inodes_with_caps 等信息。
◆ sr_t（srnode）
sr_t 是存储在 RADOS 系统 OSD 中的文件系统快照元数据结构，包含序列计数器、时间戳、相关的快照 ID 列表和 past_parent。
◆ SnapServer
SnapServer 管理快照 ID 分配、快照删除，并跟踪文件系统中有效快照的列表，一个文件系统只有一个 SnapServer 实例。
◆ SnapClient
SnapClient 用于与 SnapServer 通信，每个 MDS rank（每个 rank 视作一个元数据分片 shard，从 MDS 中选出当前管理此 rank 的 Server）都有其自己的 SnapClient 实例，SnapClient 还负责在本地缓存有效快照数据。
（3）Snapshot 处理细节
◆ 创建快照
CephFS 内部通过在目录创建 .snap 子目录的方式管理当前目录的快照。客户端会将请求发送到 MDS 服务器，然后在服务器的 Server::handle_client_mksnap（）中处理。它会从 SnapServer 中分配一个 snapid，利用新的 SnapRealm 创建并链接一个新的 inode，然 后 将其 提 交 到 MDlog， 提 交 后 会 触 发 MDCache::do_realm_invalidate_and_update_notify()，此函数将此 SnapRealm 广播给所有对快照目录下任一文件有管辖权的客户端。客户端收到通知后，将同步更新本地 SanpRealm 层级结构，并为新的 SnapRealm 结构生成新的 SnapContext，用于将快照数据写入 OSD 端。同时，快照的元数据会作为目录信息的一部分更新到 OSD 端（即 sr_t）。整个过程是完全异步处理的。
◆ 更新快照
快照信息更新分为两种情况。快照删除：这个过程和快照创建类似，不过行为都变为删除；文件或目录重命名：从父目录 SnapRealm 中删除这个文件或目录 inode，rename代码会为重命名的 inode 创建一个新的 SnapRealm，并将对旧父目录（past_parent）SnapRealm 有效的快照 ID 保存到新的 SnapRealm 的 past_parent_snaps 中。
◆ RADOS 存储快照数据
CephFS 文件被分割成 Object 后，Object 层级快照行为由 RADOS 自行管理。此外，在将文件数据 Object 写入 OSD 时，还额外用到了 SnapContext 这一结构。
◆ RADOS 存储快照元数据 sr_t
目录快照信息（及快照本身的 Inode 信息）作为目录信息的一部分字段进行存储。所有目录项的快照字段都包含其生效的第一个和最后一个 Snapid（表示这个目录项创建于哪次快照，消亡于哪次快照）。未快照的目录项，将快照字段的最后位置设置为 CEPH_NOSNAP。
◆ 快照回写
当客户端收到 MClientSnap 消息时，它将更新本地 SnapRealm 内容，并将旧 Inode 链接更新为需要回写的 Inode 的新链接，并为这些回写的 Inode 生成 CapSnap。CapSnap 被用于缓冲新写入的数据，直到快照回写在 OSD 中完成。同时，另一方面，在 MDS 中，会为这些 CapSnap 一并记录日志，以保障这一过程的完成。
◆ 删除快照
直接尝试删除带快照的目录会失败，必须先删除快照。在客户端删除快照信息后，将发送请求给映射的 OSD，使其删除相关的快照文件数据。而通过将目录信息更新覆盖后写入 OSD 对象的方式，快照元数据将被异步删除。
◆ 硬链接
具有过多硬链接的 Inode 将被转移到虚拟全局 SnapRealm。虚拟全局 SnapRealm 覆盖文件系统中的所有快照，以处理这种棘手情况。Inode 的数据将为任何新快照保留，这些保留的数据也将覆盖 Inode 的任何链接上的快照。
◆ 多文件系统
需要注意的是，CephFS 的快照和多个文件系统的交互是存在问题的——每个 MDS 集群独立分配 snappid，如果多个文件系统共享一个池，快照会冲突。如果此时有客户删除一个快照，将会导致其他人丢失数据，并且这种情况不会提升异常，这也是 CephFS 的快照不推荐使用的原因之一。
（4）Snapshot 工具命令限制总结
◆ 创建快照
默认情况下，文件系统没有启用快照功能，要想在现有文件系统上启用它，可使用以下命令开启。
# 创建快照 # ceph fs set <fs_name> allow_new_snaps true
启用快照后，CephFS 中的所有目录都将具有一个特殊的 .snap 目录（如果需要，可以
使用客户端 snapdir 配置其他名称）。
要创建 CephFS 快照，请在 .snap 目录下创建一个具有你选择的名称的子目录。例如，
要在目录“/1/2/3/”上创建快照，请调用以下命令。
# 在目录 "/1/2/3/" 上创建快照 # mkdir /1/2/3/.snap/my-snapshot-name
◆ 恢复快照
# 恢复快照 # cp -ra /1/2/3/.snap/my-snapshot-name/* /1/2/3/
◆ 删除快照
# 删除快照 # rmdir /1/2/3/.snap/my-snapshot-name
◆ 快照限制（“s”标志）
要创建或删除快照，客户端除了需要“rw”外还需要“s”权限标志。请注意，当权限字符串还包含“p”标志时，“s”标志必须出现在其后（除“rw”以外的所有标志都必须按字母表顺序指定）。例如，在以下代码段中，client.0 可以在子文件系统“cephfs_a”的“bar”目录中创建或删除快照。
client.0 key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw== caps: [mds] allow rw allow rws path=/bar caps: [mon] allow r caps: [osd] allow rw tag cephfs data=cephfs_a
◆ ceph-syn
ceph-syn 是一个适用于 CephFS 的简单的人造载荷生成器。它通过 libcephfs 库在当前运行着的文件系统上生成简单的载荷，此文件系统不必通过 ceph-fuse 或内核客户端挂载。可以用一个或多个 --syn 命令参数规定特定的载荷，而此测试工具也可以用来操作快照（但作为一个测试工具，不推荐直接使用）。
# 在 path 上创建一个名为 snapname 的快照 # ceph-syn --syn mksnap path snapname # 删除 path 上名为 snapname 的快照 # ceph-syn --syn rmnap path snapname
◆ cephfs-shell
cephfs-shell 提供类似于 shell 的命令，可以直接与 CephFS 系统进行交互（需要注意的是，cephfs-shell 基于 Python，需要依赖 cmd2 模块）。
cephfs-shell [options] [command] cephfs-shell [options] – [command command ...] -c --confifig FILE // Path to cephfs-shell.conf -b --batch FILE // Path to batch fifile -t --test FILE // Path to transcript(s) in FILE for testing
创建或删除快照：
snap {create|delete} <snap_name> <dir_name> snap_name - Snapshot name to be created or deleted dir_name - directory under which snapshot should be created or deleted
◆ 客户端版本
Mimic 版本（13 版本）以后的 fuse 与 lib 库客户端都可以支持快照。内核版本等于及高于 4.17 的内核客户端可以支持快照，这点与之后讲述的 Quota 一致。
2. Quota 配额
（1）Quota 特性介绍
CephFS 允许在系统中的任何目录上设置配额。配额可以限制目录层次结构中该节点下方存储的字节或文件的数量。
（2）Quota 特性实现原理与细节
目前来说，CephFS Quota 特性有以下细节。
◆ CephFS Quota 是针对目录的，可限制目录下存放的文件数量和容量。
◆ CephFS 没有一个统一的 UID/GID 机制，传统的基于用户和组的配额管理机制很难使用。
◆ CephFS 一般与客户端应用配合使用，将用户关联到对应的 CephFS 目录。
（3）Quota 目前实现的局限性
◆ 配额需要客户端合作
CephFS Quota 取决于挂载文件系统的客户端的合作，以在达到限制时停止写入程序。CephFS 服务端本身不能阻止客户端写入所需数量的数据，在客户端完全不受信任的环境中，Quota 无法阻止客户端填满文件系统。
◆ Quota 控制时间因素不精确
达到 Quota 限制后，写入文件系统的进程将在短时间内停止而非立刻停止。客户端将不可避免地被允许写入超出配置限制的数据量。一般而言，在超出配置的限制后的 10s（取决于检测已使用 Quota 的时间间隔，此参数可以调整，但一般推荐默认为 10s，过短可能会影响性能）内，进程将被停止写入。
◆ Quota 仅在内核版本等于及高于 4.17 的内核客户端中实现
Mimic 版本（13 版本）以后的 fuse 与 lib 库客户端都可以支持 Quota。内核版本等于及高于 4.17 的内核客户端可以支持 Quota。
◆ 在与基于路径的访问限制一起使用时，必须仔细配置 Quota
基于路径限制挂载时必须谨慎地配置 Quota。客户端必须能够访问配置了 Quota 的那个目录的索引节点，这样才能执行 Quota 管理。如果某一客户端被 MDS 能力限制成了只能访问一个特定路径（如 /home/user），并且无权访问配置了 Quota 的父目录（如 /home），这个客户端就不会受父目录（如 /home）的限制去执行 Quota。所以，基于路径做访问控制时，最好在限制了客户端的那个目录（如 /home/user）或者它更下层的子目录上配置 Quota。
◆ 快照未计入 Quota
目前创建快照造成的 COW 增量数据未被计入 Quota 进行限制。避免出现此种状况的基本方法是不要同时使用快照和 Quota 功能。快照 COW 增量数据计入 Quota 统计有待未来开发。
（4）Quota 工具命令总结
CephFS 的 mount 方式分为内核态 mount 和用户态 mount，内核态使用 mount 命令挂载，用户态使用 ceph-fuse 命令挂载。内核态只有在 kernel 4.17 + Ceph mimic 以上的版本才支持 Quota，用户态则没有限制。
◆ 内核态 mount 与用户态 mount 挂载
# 内核态 mount # mount -t ceph 192.168.3.1:/test /mnt/cephfs/ -o name=adminsecret=AQCs2Q9bqA jCHRAAlQUF+hAiXhbErk4NdtvORQ== # 用户态 mount # ceph-fuse -r /test /mnt/cephfs/ --name client.admin
◆ 配置 Quota
# 首先在 CephFS 创建一个要限额的目录 # mkdir /mnt/cephfs # ceph-fuse /mnt/Cephfs # 然后在目录上使用 setfattr 设置限额属性 # setfattr -n ceph.quota.max_bytes -v 100000000 /mnt/cephfs/test
3. QoS 服务质量
（1）QoS 特性介绍
QoS（Quality of Service，服务质量）指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务的能力，是一种用来解决网络时延和阻塞等问题的网络安全机制。在 CephFS 中，目前倾向使用限流的方式来实现 QoS 目的。此功能目前尚未引入，Ceph社区考虑在 16 版本及之后着手开发限流功能。
（2）QoS 特性实现设想与 Ceph 社区方向
目前 Ceph 社区对限流功能设想的实现方向是在客户端进行令牌桶算法流控。通过将QoS 信息设置为目录的 xattrs 之一（和 Quota 一样）来控制流控开启、关闭与监控，同时可以使用一次 QoS 设置来控制访问相同目录的所有客户端的限流。而配置 QoS 的流程则参照 Quota 的配置流程，当 MDS 收到 QoS 设置时，它将向所有客户端广播该信息。流控限额可以在线更改，设置以后如 Quota 一样由客户端进行具体的流控行为。
Ceph 社区为限流功能预留的配置方式如下。
setfattr -n ceph.qos.limit.iops -v 200 / mnt / cephfs / testdirs / setfattr -n ceph.qos.burst.read_bps -v 200 / mnt / cephfs / testdirs / getfattr -n ceph.qos.limit.iops / mnt / cephfs / testdirs / getfattr -n ceph.qos / mnt / cephfs / testdirs /
Ceph社区也讨论了这样设计可能会遇到的问题。由于CephFS 客户端I/O路径中没有队列，因此，如果流控小于请求的块大小，则整个客户端将被完全阻塞，直到获得足够的令牌为止。
此外，在单个共享目录多客户端共享挂载情况下，如果不对客户端分别控制，流控会变得不可预测。对于这一点，Ceph 社区计划了两种模式。
1）所有客户端都使用相同的 QoS 设置而不去理会多个客户端的情况，即干脆放任上述不可预测性。这样做的好处是不会因为总的流控限制，间接影响了客户端的可挂载数量。
2）所有客户端共享特定的 QoS 设置。
◆ 设置总限制，所有客户端均受平均数限制：total_limit/clients_num。
◆ 设置总限额，mds 通过客户端的历史 I/O ＆ BPS 分担客户端的限额。
