IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion——论文泛读

SC 2014 Paper 分布式元数据论文汇总

问题

在现代存储系统不断增长的情况下，预计其对象数量将超过数十亿，这使得元数据可伸缩性对整体性能至关重要。许多现有的分布式文件系统只关注提供对文件数据的高度并行快速访问，并缺乏可伸缩的元数据服务。

受限的元数据可伸缩性妨碍了需要并发和高性能元数据操作的大规模并行应用程序。其中一个应用程序是每进程一个文件（NN）检查点，它要求元数据服务在检查点的开始处理大量的文件创建[9]。另一个例子是存储管理，它产生一个读密集型的元数据工作负载，通常会扫描整个文件系统的元数据来执行管理任务[28]，[30]。最后，在大数据时代，即使在最大的集群文件系统中，大多数文件都很小[19]，[61]，其中中位文件大小通常仅为几百千字节。可伸缩的存储系统应该预期存储的小文件数量将超过数十亿，这对许多现有文件系统来说是一个已知的挑战[44]。

大量小文件和元数据管理的问题。例如，许多存储系统的文件大小中值小于64KB，即使最大的文件大小可能是几TB。这些存储系统中近90%的目录都很小，目录条目少于128个。但是，一些最大的目录可能有超过一百万个条目。在文件系统元数据操作方面，对文件和目录的只读操作，如open for read、stat和readdir，是最流行的操作[48]。

挑战

如何优化大量元数据和小文件的访问

现有方法的缺陷

以前的文件系统使用30年前的磁盘上数据结构（如索引节点和目录）存储核心外的元数据，这些数据结构在元数据密集型工作负载[36]、[15]、[47]期间会经历多次磁盘查找。对目录条目的更高效的核心外表示的需求促使我们使用基于列的日志结构方法[14]，[42]，[49]来开发一种新颖的元数据布局。所有文件系统元数据（包括目录和inode属性）和小文件的数据都打包到几个日志文件中，同时进行细粒度索引以加快查找和扫描操作。这种组织便于高速元数据创建、查找和扫描，即使在单节点本地文件系统中也是如此[47]。

本文方法

设计思路：第一种机制是以目录子集的粒度对命名空间进行分区，并动态拆分大目录以实现负载平衡。大目录的拆分基于GIGA+[44]，这是一种为快速读取目录保留小目录的磁盘位置并允许并行访问大目录的技术。第二种机制是以最小的服务器状态在客户端上维护元数据缓存，以减少在路径解析和权限验证期间对元数据服务器的不必要请求。这会阻止服务器跟踪和同步大量状态。

我们介绍了一种名为IndexFS的中间件设计，它为现有的文件系统（如PVFS、Lustre和HDFS）添加了对元数据和小文件可伸缩高性能操作的支持，关键思想是重用集群文件系统的可扩展数据路径，以提供对元数据路径的并发快速访问。IndexFS采用基于表的体系结构，根据每个目录逐步划分命名空间，保留小目录的服务器和磁盘局部性。优化的日志结构布局用于高效存储元数据和小文件。我们还提出了两种基于客户端的缓存技术：用于创建密集型工作负载（如N-N检查点）的批量命名空间插入；以及用于热点缓解的无状态一致性元数据缓存。

我们已经证明了IndexFS可扩展到128个元数据服务器。实验结果显示，我们的离线元数据吞吐量在性能上优于现有解决方案，如PVFS、Lustre和HDFS，性能提高了50%至两个数量级。

总结

对大量元数据访问和小文件访问的优化。利用扩展索引技术与扩展元数据表示的组合，以增强元数据服务的可扩展性和性能；采用基于表的架构，按目录划分命名空间保证局部性；采用LSM tree优化存储元数据和小文件；用于缓解热点的无状态一致性元数据缓存；用于密集型工作负载的批量命名空间插入。

构建在文件系统之上的中间件，通过重新构建一些便于查找的表来优化元数据和小文件访问的并行性