IndexFS: Scaling File System Metadata Performance论文读后感

wcwx 9年前

IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion

这篇论文比较新,发表于2014年11月SC(supercomputing)会议上。SC是高性能计算领域的旗舰会议,每年录取约80篇论文,但参会人数经常超过万人,今年在新奥尔良召开。IndexFS获得了本年度SC的 best paper。该会每年只选出一篇best paper,一篇best student paper。IndexFS的作者 Kai Ren 本身正是CMU的博士生,却得到了best paper,足可见其功力之深。

本文的核心思想就是尝试解决分布式文件系统中metadata (元数据)管理的问题:
  • 比如在做N-N Checkpointing的时候产生的高并发metadata操作;
  • 一些复杂的管理任务中出现的频繁的元数据读取,扫描;
  • 以及文件大小,目录大小不均衡产生的单热点问题

整体系统架构如下:
来自应用程序的metadata操作以及data操作被分配到不同的组件中。Metadata以及一些小于64KB的文件,通过IndexFS服务器来进行管理;真正的数据(大于64KB)通过底层的分布式文件系统来服务。具体到每一个IndexFS中, 并未实现任何replication或者RAID机制,而是通过将metadata或者小文件被组织成大的,顺序文件存储在底层的分布式文件系统中来保证容错。[这个设计非常有趣]

针对上面所说的几个challenges,IndexFS都有比较好的解决思路:

  • 首先,类似社交网络,文件的大小,目录的大小都遵守类似的长尾规律:文件系统中大部分的目录中文件数目小于128,但是极少数目录可以有上百万个子目录。为了能够将小的目录存连续的放在本地,并且将大的目录分布到多台机器上,IndexFS引入了Giga+的动态分割算法 (来自同组师兄的工作),动态的根据目录的增长,引入更多的服务器来存储。
  • 其次,针对频繁的读,IndexFS引入了客户端缓存。客户端缓存的最大问题就是不一致性,这在客户端数目远远大于服务器数目的环境下,容易导致缓存无效风暴:一个小的服务器端修改,就能导致海量的客户端重新请求数据。为了避免这个,同时保证缓存数据的一致性。IndexFS为每一个缓存引入了lease,客户端每次申请一个lease,并且缓存相关数据;lease到期之后,会再次向服务器请求延长lease;而此时如果服务器端有写操作,所有的lease延长请求都会被拒绝,而服务器端的修改也必须等到已经办法的lease超时无效才进行。简单的说,这种办法延缓了写操作,保证了数据一致性,避免了无效风暴。
  • 最后,针对高频写,IndexFS首先在服务器端使用LSM来存储数据 (实际上使用的是LevelDB)。 LSM是典型的为写优化的存储结构,但随之而来的compaction会占据很长的时间。IndexFS通过只将部分数据(主要是文件的 permission数据,以及一个指针)存储在LSM中,将数据极大的减少了compaction的次数;未缓存的数据也存放在LSM中,但是不再进行 compaction。当需要访问非缓存的数据的时候,可以先搜索缓存部分的LSM,然后直接通过指针找到对应的非缓存数据。代价是一次额外的disk seek,好处是大大减少了compaction,这个performance killer。
  • 额外的补充:bulk insertion。这个推荐阅读同时在此次SC PDSW workshop发表的BatchFS,里面更详细的介绍了如何进行bulk insert。同样是来自同组的文章,不得不赞一下。

IndexFS表明了Metadata管理在分布式文件系统中的重要性。我想Object-based Storage其实也是元数据管理能力跟不上的一个不得不进行的选择吧。

补充:一个性能图,恐怖的性能


转自:http://weibo.com/p/1001603794837626332928