InfiniFS论文解读

Posted 2023-02-02 lizhongwen1987

在前期分析BeeGFS的元数据实现思路的文章中有提到，BeeGFS的元数据具有很好的负载均衡和本地化性能，但也存在一些不足，正好看了一篇FAST2022上的论文<<InfiniFS:An Efficent Metadata Service for Large-Scale Distribuited Filesytems>>， 在论文中对近根热点、路径寻址等方面提供了相应的解决方式，论文解析如下，供大家参考。

InfiniFS的系统结构

InfiniFS是一个分布式元数据系统，希望用一个单一的命名空间满足整个数据中心的文件管理需求，包括如下几个组件：
客户端（Client）: 用户态实现的兼容POSIX标准的文件系统接口。
元数据服务（Metadata Server）：分布式元数据集群，用于管理文件系统目录树。
重命名协调器（Rename Coordinator）：中心化的重命名协调器，用于处理目录的重命名及设置目录权限的操作

核心技术

现代数据中心通常包含数十亿甚至数百亿的文件，用一个超大规模的文件系统来管理这些文件，将对元数据服务带来巨大的挑战。

• 首先，随着目录树的扩展以及工作负载变得多样，在目录树分区方面，同时取得优秀的元数据本地化能力和优秀的负载均衡能力将面临挑战。
• 第二，在超大规模文件系统中随着文件目录深度的增加，路径解析延迟可能会很高。
• 最后，由于超大规模的文件系统通常有大量的客户端在并发的操作，维护客户端缓存的一致性所带来的的开销将变得难以承受。

为了解决上述的挑战，InfiniFS采用如下的三个关键设计来解决目录树分布及元数据访问性能问题。

访问-内容元数据分离

拆分目录元数据、本地化及分组
首先，将目录元数据拆分为访问元数据（access metadata）和内容元数据（content metadata），访问元数据用来描述目录自身，包括：目录名、目录ID、目录权限，内容元数据用来表示目录的子目录及文件，包含：子目录和文件元数据、时间戳；访问元数据可以理解为很少变化的元数据，内容元数据是变化相对频繁的元数据，

如下图（b）。接着，将两部分元数据进行负载分布，策略为：目录的访问元数据与其父目录分组放置，目录的内容元数据与其下文件元数据分组放置，以目录ID为键进行一致性Hash，将分组分布到不同的元数据服务上，如下图（c）。注：○目录元数据，□文件元数据；◐访问元数据，◑内容元数据。

元数据存储
使用KV引擎作元数据分区的后端存储，元数据索引表结构如下，包含：目录访问元数据，目录内容元数据以及文件元数据三种Key-Value索引对表。如上图（a），假定（目录/，A，C 的ID分别为0，1，2），解析路径 /A/C/f1的过程如下：

1. 通过<0,A>获取A的访问元数据，得到A的ID=1
2. 通过<1,C>获取C的访问元数据，得到C的ID=2
3. 通过<2>获取C的内容元数据，接着通过<2,f1>获得文件元数据
   

推断式目录解析

基于一致性Hash算法，以<父目录ID，目录名，命名版本>为键，为每个目录生成一个可预测的ID，InfiniFS设计了一种推断式的路径解析机制实现目录树的并行遍历，可以缩短元数据访问延迟。
可预测的目录ID
1）创建目录。Hash函数以目录的"出生"元组<父目录id，目录名，命名版本>为键生成目录ID。如下图（a）
2）重命名目录。只有目录的访问元数据需要修改，其内容元数据及目录ID保持不变（所以该目录下的所有"孩子"都不需要修改）；父目录包含一个重命名列表（RL）记录其下子目录的重命名记录（记录它离家的孩子），格式为<目录名，命名版本>，目录首次重命名时会添加记录到RL，而目录自身包含一个后备指针（BP）记录其重命名记录（记录它亲爹是谁），格式为<父目录ID，命名版本>，通过RL来决定目录的命名版本。

如下图（b），注：当一个目录再次重命名时，只有目录的访问元数据会修改，其内容元数据、BP以及（亲生）父目录的RL都不会修改；当删除一个重命名目录（如：B）的（亲生）父目录（如：A）时，（亲生）父目录的访问元数据及内容元数据都会被删除，但是RL会保留直到重命名目录被删除（如：B）

3）删除目录。删除一个重命名目录时，会同时删除其（亲生）父目录RL上的记录，这样再次创建相同名字的目录时命名版本重置为0，如下图（c）

并行路径解析
根据可预测的目录ID，客户端通过如下的步骤实现并行路径解析：

1. 推断目录ID。client根据查找路径/子路径的根来推断中间目录的ID，首先通过命名版本为0的“出生”元组来计算路径上所有目录的目录ID，然后发起查找。
2. 并行查找。client并行的查找请求，检查访问权限以及比较推断的ID和元数据服务上保存的ID，如果不一致则将正确的ID返回给client。
3. 重复上述的1）和2）直到完成路径解析。

如下图（a），一个网络RRT完成路径解析；如下图（b），重命名后 h（2，x，0） ≠ 12 = h（1，x，0），2个网络RRT完成路径解析

优化的元数据缓存

InfiniFS将目录访问元数据缓存在客户端的内存中以缓解近根热点
缓存数据的组织
InfiniFS客户端只缓存目录的访问元数据，缓存命中将消除发往元数据服务的近根查找请求，避免近根热点以及确保路径查找解析的扩展性。如下图，InfiniFS按照文件系统目录树在组织缓存项，并将叶子节点组织为LRU链表。

缓存延迟失效
在目录重命名或者修改目录权限后，很多缓存项将会过期，在上述情况下立即，对所有相关客户端进行缓存失效实操上是不太可行的，首先因为客户端（元数据）关系很难维护，其次客户端可能会很多且远远多余元数据服务数。
延迟失效机制，通过将失效消息广播给元数据服务来解决该问题（元数据服务的数量远远少于客户端数），这样每个元数据服务在处理客户端请求时能够延迟确认过期缓存，如下图（b）

1. client并不知道缓存已过期，在进行路径解析时还会继续使用缓存项，每个客户端都有一个版本号，通过它来判断缓存是否因为重命名而更新了。client与元数据服务交互时会带上路径及该版本号。
2. 元数据服务通过比较请求路径与失效列表中的路径来确认状态（只需要比较失效列表中请求版本号与最新版本号之间的条目）。如果路径合法，请求将被处理并返回成功
3. 元数据服务发现路径不合法，会拒绝处理请求并新的路径及版本返回给客户端

特别地，目录重命名操作，会由中心化的重命名协调器来处理，以避免目录的孤儿循环，协调器会将重命名消息广播给元数据服务，如下图（a）

1. 重命名请求发给协调器，由其检测该重命名操作是否与其他正在进行的重命名操作有冲突，检查通过将会给改重命名请求赋予一个递增的版本号
2. 锁定目标目录（直到重命名完成），并行地向元数据服务广播重命名消息，等待应答
3. 将目录的访问元数据从源元数据服务移到目标元数据服务，如果是首次重命名，则更新父目录的RL以及目录自身的BP
   
   论文中，对跨目录的重命名的一致性问题，也进行了特别的说明

一致性

重命名协调器维护一个重命名图，用于跟踪进行中的重命名操作的源和目标路径。
循环孤儿
并发的目录重命名可能导致循环孤儿，这会导致数据丢失，如下图（a）是一棵正常的文件系统目录树，
如下图（b）和（c），C1想要将E重命名为C的子目录（/D/E -> /A/B/C/），而C2想要将B重命名为F的子目录（/A/B->/D/E/F/），两个客户端的重命名操作的是完全独立的，它们并行执行将导致产生循环孤儿子树，破坏文件系统树。

元数据事务
InfiniFS中的元数据操作可以归为3类：

1. 单元数据服务操作。如：目录的readdir，文件的create/delete/open/close/stat/set_permission。这些操作只需要单个元数据服务参与，通过本地的KV引擎来保障一致性
2. 两个元数据服务的操作。如：目录的mkdir/rmdir/statdir，文件的rename。这些操作需要两个元数据服务参与，通过两阶段提交协议来保证一致性
3. 目录重命名。通常目录重命名和修改目录权限的操作频率不高，这两类操作有重命名协调器负责处理

论文解读到此，各位读者也可以通过文章开头的链接阅读论文原文。