分布式檔案系統名字空間實現研究

1、名字空間概述

名字空間(namespace)即檔案系統檔案目錄的組織方式，是檔案系統的重要組成部分，為使用者提供視覺化的、可理解的檔案系統檢視，從而解決或降低人類與計算機之間在資料儲存上的語義間隔。目前樹狀結構的檔案系統組織方式與現實世界的組織結構最為相似，被人們所廣泛接受。因此絕大多數的檔案系統皆以tree方式來組織檔案目錄，包括各種磁碟檔案系統(extx, xfs, jfs, reiserfs, zfs, btrfs, ntfs, fat32等)、網路檔案系統(nfs, afs, cifs/smb等)、集群檔案系統(lustre, pnfs, pvfs, gpfs, panfs等)、分布式檔案系統(googlefs, hdfs, mfs, kfs, taobaofs, fastdfs等)。

隨著物件導向儲存和雲儲存的發展，出現了一種稱為偏平化(flat)的檔案系統組織方式，典型代表有lustre, panfs, amazon s3, google storage。這種方式把所有檔案目錄看作物件object，每乙個物件有乙個全域性唯一的標識uuid，戶使用此uuid(而非路徑)來訪問儲存系統。然而，uuid僅僅對計算機有意義，在使用者介面層往往還是需要提供樹狀檔案系統檢視，再由系統在path和uuid之間進行轉換。在物件儲存層，物件或對象資料分片以檔案形式儲存在磁碟檔案系統之上，物理儲存層仍然是樹狀儲存結構。另外，對於法規遵從資料儲存領域廣泛使用的固定內容儲存系統 cas(content addressed storage, 內容定址儲存)，採用基於物件的儲存系統，機制與此類似。

具體實現上，磁碟檔案系統的名字空間直接在磁碟上來實現，通常以b*/b+/b-樹的形式來組織，元資料和資料儲存在相同的介質上。而對於分布式檔案系統來說，元資料和資料和儲存和訪問是分離的，這是由高效能、可用性、可擴充套件性等設計要求所決定的。通常，資料的訪問由i/o伺服器來實現，而元數據由元資料伺服器來負責。名字空間是元資料伺服器的核心任務之一，此外可能還要負責安全機制(如授權與認證)、鎖機制、i/o負載均衡等。因此，由於元數據與資料的分離，分布式檔案系統名字空間實現的自由度比較大，實現方式有更多的選擇空間。這裡將要介紹四種分布式檔案系統名字空間實現機制，均為樹狀檔案系統檢視，大致分為基於檔案系統的實現和基於全記憶體的實現，但不包括基於資料庫的實現。基於資料庫來實現檔案系統名字間有眾所周知的效能問題，尤其是遞迴遍歷檔案目錄空間。

2、四種檔案系統名字空間實現

(1)基於檔案系統的設計

這是一種"站在巨人肩膀上"的設計。磁碟檔案系統本身就是樹狀結構檢視，因此可以利用這現成的機制在元資料伺服器上實現名字空間。對於分布式檔案系統中的每乙個目錄或檔案，在元資料服務器的本地檔案系統之上一一對應建立乙個目錄或檔案(以下稱為元目錄和元檔案)，兩者之間的對映關係如圖1所示。元目錄用來表示dfs中的目錄，其元目錄屬性儲存dfs目錄屬性；元檔案用來表示dfs中的檔案，元檔案屬性儲存dfs檔案屬性，元檔案內容則用來儲存元資料，包括更詳細的檔案屬性、訪問控制信息、資料分片資訊、資料儲存位置等資訊。

圖1 基於檔案系統的設計(dfs與本地檔案系統名字對映)

基於檔案系統我們以極小的代價構建了dfs的名字空間，實現起來簡單快速。元檔案僅用來儲存資料檔案的元資料，一般都是小於1kb的小檔案，如果檔案目錄數量達到千萬量級就會形成losf(lots of small files)的效能問題。實際應用中如何來解決這種問題呢？目前主要有兩種解決方法，一是採用適合海量小檔案儲存的檔案系統。reiserfs對小檔案存儲進行了特別優化，它不僅檔案查詢效率高，而且節省磁碟儲存空間，實際測試結果也驗證了這一點。二是採用高效能的儲存介質，尤其是iops指標。非常幸運，固態硬碟ssd技術上已經比較成熟，成本不斷降低，非常適合高效能的儲存應用。ssd的特點是iops高，普通ssd讀寫ipos可以達到10000 ~ 50000，高階ssd甚至可以達到100000以上，而fc、sas、sata磁碟的ipos基本小於300，遠遠小於ssd。因此，採用ssd和 reiserfs檔案系統，效能能夠得到大幅提公升，大多數應用問題不大。　　

(2)基於全記憶體的分層設計

這種方式與hdfs實現相仿。與基於檔案系統的實現不同，名字空間完全在元資料伺服器的記憶體中，使用層次結構來表示，如圖2所示。這種層次結構相當於一棵樹，每個結點表示dfs的乙個目錄或檔案，結點的孩子結點理論上沒有數量限制(取決於記憶體可用量)，孩子結點使用動態陣列來表示。結點資料結構如下所示，其中metadata表示(1)中檔案目錄類似的元資料信息，children是孩子結點動態陣列，使用二分法實現插入、查詢和刪除操作，嚴格按照名稱進行公升序排序。

圖2 基於全記憶體的分層設計

view plain

copy to clipboard

print?

struct inode ;

(3)基於全記憶體的hash設計

這種方式與gfs實現相仿。gfs**中指出其名字空間採用了全內存設計、偏平式組織、字首壓縮演算法、二分查詢演算法、沒有支援ls的資料結構，**中還指出ls操作的效率較低。gfs沒有開源，不像hdfs可以查閱原代碼，因此也無法完全重現gfs的名字空間實現，基本全記憶體的hash設計可能比較接近其設計。這種設計採用hash和二分查詢相結合的來實現，即目錄以完整的絕對路徑進行hash定位，該目錄下的孩子結點使用二分查詢進行定位，如圖3所示。它與分層設計的主要不同在於，只需要一次hash和一次二分查詢，而分層設計需要多次的二分查詢，在效能上更優。我們僅對目錄進行hash，名字空間具有一定的偏平性，但沒有達到gfs的完全偏平；子檔案目錄不包括父路徑部分，相當於作了字首壓縮，但不如分層字首壓縮徹底。大膽猜測，gfs可能採用了全hash設計或全列表設計，ls操作通過字首匹配來實現，即具有相同字首的檔案屬於同乙個目錄，如此實現名字空間。

圖3 基於記憶體的hash設計

這種設計下，查詢指定檔案或執行ls，首先將路徑分解成父路徑名和目錄檔名，對父路徑名進行hash運算定位至其孩子結點列表，然後二分查詢指定檔案，或者遍歷孩子結點列表實現ls操作。假設目錄寬度為n，查詢時間複雜性為log(n)，在記憶體佔用量上要稍稍大於分層設計，因為目錄結點均重複一次。這種設計具有支援ls的資料結構，相對於gfs來說，執行ls效率要高出許多，如果gfs是全hash設計則需要遍歷整個檔案空間進行字首匹配，如果gfs是全列表設計則需要以父路徑名進行二分查詢然後區域性字首匹配。

(4)基於全記憶體的雙重hash設計

這種方式是對基於全記憶體hash設計的改進。它先對目錄進行第一次hash運算，然後對子檔案目錄進行第二次hash運算，從而將查詢時間複雜性從log(n)進一步降低至o(2)，如圖4所示。目錄hash表是全局的，而目錄結點的hash表是區域性的，每乙個目錄結點都包含乙個hash表，僅用來儲存本目錄下的子檔案目錄資訊，目錄結點資料結構如下所示。

圖4 基於記憶體的雙重hash設計

view plain

copy to clipboard

print?

struct inode ;

對於檔案系統ls操作，對路徑名進行一次hash運算定位到目錄結點，然後對目錄結點中的hash表進行遍歷即可。檔案查詢時，首先將路徑名分解成父路徑名和檔案目錄名，對父路徑名進行hash運算定位父目錄結點，然後對檔案目錄名進行hash運算並在父目錄結點中的hash表進行定位。目錄結點中的hash表初始為未建立，直到第一次建立子檔案目錄時方才建立，hash表項數量定義為平均目錄包含的子檔案目錄數量，在效能和記憶體空間節省之間進行折中。如果記憶體充足，hash表項數量應該盡量設定大些，以達到更好的雜湊效果。與基於全記憶體的hash設計相比，這種設計查詢效能上更上層樓，記憶體消耗相應有所增加。

3、對比分析與應用選擇

上述分布式檔案系統名字空間的四種實現方式，按照實現位置劃分，可分為基於檔案系統的實現和基於記憶體的實現。基於檔案系統實現的優點是實現簡單，記憶體要求低，可以執行在普通的機器上，缺點是效能可能較低。如果採用 ssd＋reiserfs實現，效能應該不是大問題，但成本也隨之提高許多。基於記憶體實現的優點是效能高，缺點是對記憶體要求極高，實現起來比較複雜，並需要對記憶體的名字空間進行永續性保護措施防止意外宕機或出錯。基於記憶體的三種實現，效能方面雙重hash設計 > hash設計 > 分層設計，記憶體需求方面則相反。實際實現和應用中，應該結合成本預算和效能需求進行選擇，選擇的原則是，在滿足設計要求的前提下盡量爭取價效比最大化。

分布式檔案系統名字空間實現研究

分布式檔案系統名字空間實現研究

分布式檔案系統

分布式檔案系統

相關推薦