IndexFS: Scaling File System Metadata Performance論文讀后感

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操作；
• 一些復雜的管理任務中出現的頻繁的元數據讀取，掃描；
• 以及文件大小，目錄大小不均衡產生的單熱點問題
</ul>
整體系統架構如下：
來自應用程序的metadata操作以及data操作被分配到不同的組件中。Metadata以及一些小于64KB的文件，通過IndexFS服務器來進行管理；真正的數據(大于64KB)通過底層的分布式文件系統來服務。具體到每一個IndexFS中， 并未實現任何replication或者RAID機制，而是通過將metadata或者小文件被組織成大的，順序文件存儲在底層的分布式文件系統中來保證容錯。［這個設計非常有趣］

</div> 針對上面所說的幾個challenges，IndexFS都有比較好的解決思路：



• 首先，類似社交網絡，文件的大小，目錄的大小都遵守類似的長尾規律：文件系統中大部分的目錄中文件數目小于128，但是極少數目錄可以有上百萬個子目錄。為了能夠將小的目錄存連續的放在本地，并且將大的目錄分布到多臺機器上，IndexFS引入了Giga+的動態分割算法 (來自同組師兄的工作)，動態的根據目錄的增長，引入更多的服務器來存儲。
</ul>

• 其次，針對頻繁的讀，IndexFS引入了客戶端緩存。客戶端緩存的最大問題就是不一致性，這在客戶端數目遠遠大于服務器數目的環境下，容易導致緩存無效風暴：一個小的服務器端修改，就能導致海量的客戶端重新請求數據。為了避免這個，同時保證緩存數據的一致性。IndexFS為每一個緩存引入了lease，客戶端每次申請一個lease，并且緩存相關數據；lease到期之后，會再次向服務器請求延長lease；而此時如果服務器端有寫操作，所有的lease延長請求都會被拒絕，而服務器端的修改也必須等到已經辦法的lease超時無效才進行。簡單的說，這種辦法延緩了寫操作，保證了數據一致性，避免了無效風暴。
</ul>

• 最后，針對高頻寫，IndexFS首先在服務器端使用LSM來存儲數據 (實際上使用的是LevelDB)。 LSM是典型的為寫優化的存儲結構，但隨之而來的compaction會占據很長的時間。IndexFS通過只將部分數據(主要是文件的 permission數據，以及一個指針)存儲在LSM中，將數據極大的減少了compaction的次數；未緩存的數據也存放在LSM中，但是不再進行 compaction。當需要訪問非緩存的數據的時候，可以先搜索緩存部分的LSM，然后直接通過指針找到對應的非緩存數據。代價是一次額外的disk seek，好處是大大減少了compaction，這個performance killer。
</ul>

• 額外的補充：bulk insertion。這個推薦閱讀同時在此次SC PDSW workshop發表的BatchFS，里面更詳細的介紹了如何進行bulk insert。同樣是來自同組的文章，不得不贊一下。
</ul>

IndexFS表明了Metadata管理在分布式文件系統中的重要性。我想Object-based Storage其實也是元數據管理能力跟不上的一個不得不進行的選擇吧。

補充：一個性能圖，恐怖的性能


轉自：http://weibo.com/p/1001603794837626332928