一種分布式存儲系統(tǒng)中處理面向海量目錄和文件的方法
【專利摘要】本發(fā)明提出了一種分布式存儲系統(tǒng)中處理面向海量目錄和文件的方法。在集群中，將所有的用于存放元數(shù)據(jù)的MetaServer用一致性哈希方案組織。對于每一個MetaServer，其上運行的元數(shù)據(jù)服務(wù)會將元數(shù)據(jù)組織成不同的文件。每個元數(shù)據(jù)都是一個元數(shù)據(jù)項，記錄了各種元數(shù)據(jù)信息，如時間、權(quán)限等。本發(fā)明將目錄打包成一個較大的塊，存放在本地文件系統(tǒng)中，塊由系統(tǒng)預(yù)分配。為了適應(yīng)不同大小的目錄，并適應(yīng)目錄所包含元數(shù)據(jù)不斷增長的應(yīng)用需求，因此將不同大小的目錄放在不同級別的塊中（低階別的塊存放小目錄，高級別的塊存放打得目錄），如圖1，對不斷增大的目錄通過移動其元數(shù)據(jù)項移動到更高級別的塊。
【專利說明】一種分布式存儲系統(tǒng)中處理面向海量目錄和文件的方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及分布式存儲和海量小文件存儲領(lǐng)域，具體涉及一種分布式存儲系統(tǒng)中處理面向海量目錄和文件的方法。
【背景技術(shù)】
[0002]近年來，隨著大數(shù)據(jù)時代的來臨，分布式文件系統(tǒng)的研究逐漸增多，云計算時代。對于大多數(shù)分布式文件系統(tǒng)而言，元數(shù)據(jù)的管理是個十分復(fù)雜的問題，元數(shù)據(jù)的管理部件的設(shè)計架構(gòu)直接影響到系統(tǒng)的性能、可擴展性、系統(tǒng)可用性等。分布式存儲系統(tǒng)最根本的是將大量普通商用機器組織成高性能、低延遲、對用戶層屏蔽失效和不可用事件的集群，這要求分布式存儲系統(tǒng)必須能夠進行良好的橫向擴展(Scale-Out)，而不能僅僅通過更換更快的CPU，增大內(nèi)存容量，增大磁盤存儲容量，更換SSD來進行縱向的擴展(Scale-Up)。
[0003]橫向擴展(Scale-Out)最主要考慮的問題的就是處理記錄數(shù)據(jù)邏輯與物理位置的映像關(guān)系即數(shù)據(jù)元數(shù)據(jù)，另外包括諸如屬性和訪問權(quán)限等信息。尤其對于面向海量小文件的應(yīng)用中，元數(shù)據(jù)問題是個非常棘手的挑戰(zhàn)。
[0004]分布式文件系統(tǒng)中，數(shù)據(jù)會分布在多個獨立的物理節(jié)點上，對數(shù)據(jù)的IO請求通常也會被分散到相應(yīng)的物理節(jié)點中。這也是分布式文件系統(tǒng)橫向擴展(Scale-Out)所要求的。現(xiàn)有的分布式文件系統(tǒng)中，如果以文件為單位進行調(diào)度，則不同的文件會存儲在不同的節(jié)點上，當(dāng)文件比較大時，一些分布式文件系統(tǒng)將文件分塊(例如GFS，HDFS將比較大的文件系統(tǒng)分為64M的塊)。因此帶來的問題就是如何確保對數(shù)據(jù)的定位，也即如何確定一個文件(或者文件的每一個數(shù)據(jù)塊)在哪一臺物理節(jié)點上。分布式系統(tǒng)中往往會提供元數(shù)據(jù)服務(wù)來解決這個問題解決這個問題的。元數(shù)據(jù)服務(wù)記錄數(shù)據(jù)與其對應(yīng)的存儲位置的映射關(guān)系，另外還包含文件訪問控制所需要的所有元數(shù)據(jù)(訪問時間、訪問權(quán)限、屬主用戶等)。對文件進行訪問時，先向元數(shù)據(jù)服務(wù)請求查詢對應(yīng)的元數(shù)據(jù)，然后通過獲得的元數(shù)據(jù)進行后續(xù)的文件讀與等I/O操作。
[0005]目前主流的分布式文件系統(tǒng)的元數(shù)據(jù)管理方式大致可以分為三種模型，即
[0006]1.中心化元數(shù)據(jù)服務(wù)模型:
[0007]中心化元數(shù)據(jù)服務(wù)模型是比較簡單的一種模型。出于設(shè)計上簡單、實現(xiàn)容易等因素的考慮，同時由于歷史遺留問題，很多分布式文件系統(tǒng)采用了中心化的元數(shù)據(jù)服務(wù)。例如Google 的 GFS, Apache 的 HDFS, Lustre, PVFS, StorNext,等。
[0008]在中心化元數(shù)據(jù)服務(wù)模型中，通常設(shè)置一個中心化的元數(shù)據(jù)服務(wù)器來支持元數(shù)據(jù)的存儲和客戶端查詢請求，例如GFS和HDFS中的NameServer節(jié)點。中心化的元數(shù)據(jù)服務(wù)器節(jié)點提供統(tǒng)一的文件系統(tǒng)命名空間，并處理名字解析和數(shù)據(jù)定位，訪問權(quán)限控制，元數(shù)據(jù)查詢等功能。因此，中心化元數(shù)據(jù)服務(wù)模型的最大優(yōu)點就是設(shè)計實現(xiàn)簡單，實際上相當(dāng)于一個單機的服務(wù)，獨立地維護目錄和文件，對外提供網(wǎng)絡(luò)訪問接口即可。元數(shù)據(jù)服務(wù)設(shè)計實現(xiàn)的關(guān)鍵考量是節(jié)點的OPS吞吐量，即單位時間處理的請求數(shù)。為了優(yōu)化0PS，中心化元數(shù)據(jù)服務(wù)模型對CPU、內(nèi)存、磁盤要求較高，條件允許的情況下盡量使用高性能CPU、大內(nèi)存和高速磁盤，甚至后端存儲可考慮使用高端磁盤陣列或SSD。
[0009]2.分布式元數(shù)據(jù)服務(wù)模型
[0010]與中心化元數(shù)據(jù)服務(wù)模型相對應(yīng)的是分布式元數(shù)據(jù)服務(wù)模型。
[0011]目前常見的分布式元數(shù)據(jù)服務(wù)模型主要有四種設(shè)計方案:
[0012](I)基于文件系統(tǒng)的設(shè)計:由于磁盤文件系統(tǒng)本身就是樹狀結(jié)構(gòu)視圖，因此可以利用這現(xiàn)成的機制在元數(shù)據(jù)服務(wù)器上實現(xiàn)名字空間。對于分布式文件系統(tǒng)中的每一個目錄或文件，在元數(shù)據(jù)服務(wù)器的本地文件系統(tǒng)之上一一對應(yīng)創(chuàng)建一個目錄或文件(以下稱為元目錄和元文件)。元目錄用來表示DFS中的目錄，其元目錄屬性保存DFS目錄屬性；元文件用來表示DFS中的文件，元文件屬性保存DFS文件屬性，元文件內(nèi)容則用來保存元數(shù)據(jù)，包括更詳細的文件屬性、訪問控制信息、數(shù)據(jù)分片信息、數(shù)據(jù)存儲位置等信息。由此，基于現(xiàn)有的本地文件系統(tǒng)構(gòu)建了 DFS的名字空間，設(shè)計簡單實現(xiàn)容易。元文件僅用來存儲數(shù)據(jù)文件的元數(shù)據(jù)，一般都是小于IKB的小文件，如果文件目錄數(shù)量比較大，本地文件系統(tǒng)性能會急劇下降。
[0013](2)位于內(nèi)存的分層設(shè)計=Apache HDFS采用了這種方案。與基于文件系統(tǒng)的實現(xiàn)不同，名字空間完全在元數(shù)據(jù)服務(wù)器節(jié)點的內(nèi)存中，使用層次結(jié)構(gòu)來表示，具體實現(xiàn)可以使用樹結(jié)構(gòu)或者層次化的數(shù)組結(jié)構(gòu)。在層次結(jié)構(gòu)中，每個結(jié)點表示DFS的一個目錄或文件，結(jié)點的孩子結(jié)點理論上沒有數(shù)量限制(取決于內(nèi)存可用量)，孩子結(jié)點使用動態(tài)數(shù)組或者鏈表來表不。
[0014](3)位于內(nèi)存的Hash設(shè)計:這種方式與Google GFS實現(xiàn)相仿。GFS論文中指出其名字空間采用了全內(nèi)存設(shè)計、偏平式組織、前綴壓縮算法、二分查找算法、沒有支持Is的數(shù)據(jù)結(jié)構(gòu)，論文中還指出Is操作的效率較低。GFS沒有開源，從論文中可以看出位于內(nèi)存的Hash設(shè)計可能比較接近其設(shè)計。這種設(shè)計采用Hash和二分查找相結(jié)合的來實現(xiàn)，即目錄以完整的絕對路徑進行hash定位，該目錄下的孩子結(jié)點使用二分查找進行定位。它與分層設(shè)計的主要不同在于，只需要一次hash和一次二分查找，而分層設(shè)計需要多次的二分查找，在性能上更優(yōu)。我們僅對目錄進行Hash，名字空間具有一定的偏平性，但沒有達到GFS的完全偏平；子文件目錄不包括父路徑部分，相當(dāng)于作了前綴壓縮，但不如分層前綴壓縮徹
。
[0015](4)位于內(nèi)存的雙重Hash設(shè)計:這種方式是對基于全內(nèi)存hash設(shè)計的改進。它先對目錄進行第一次hash運算，然后對子文件目錄進行第二次hash運算，從而將查找時間復(fù)雜性從log(n)進一步降低至0(2)。目錄Hash表是全局的,而目錄結(jié)點的Hash表是局部的，每一個目錄結(jié)點都包含一個Hash表，僅用來存儲本目錄下的子文件目錄信息。
[0016]3.無元數(shù)據(jù)服務(wù)模型:理論上，無元數(shù)據(jù)服務(wù)模型是可行的，只要尋找到元數(shù)據(jù)查詢定位的替代方法即可。目前，基于無元數(shù)據(jù)服務(wù)模型的分布式文件系統(tǒng)非常少，比較具有代表性的是Glusterfs。Glusterfs使用彈性哈希算法代替?zhèn)鹘y(tǒng)分布式文件系統(tǒng)中的集中或分布式元數(shù)據(jù)服務(wù)，使用算法進行數(shù)據(jù)定位，集群中的任何服務(wù)器和客戶端只需根據(jù)路徑和文件名就可以對數(shù)據(jù)進行定位和讀寫訪問。
[0017]三種元數(shù)據(jù)服務(wù)模型比較
[0018]傳統(tǒng)分布式存儲系統(tǒng)使用集中式或布式元數(shù)據(jù)服務(wù)來維護元數(shù)據(jù)，集中式元數(shù)據(jù)服務(wù)會導(dǎo)致單點故障和性能瓶頸問題，而分布式元數(shù)據(jù)服務(wù)存在性能開銷、元數(shù)據(jù)同步一、致性和設(shè)計復(fù)雜性等問題。無元數(shù)據(jù)服務(wù)模型，消除了元數(shù)據(jù)訪問問題，但同時增加了數(shù)據(jù)本身管理的復(fù)雜性，缺乏全局監(jiān)控管理功能，并增加了客戶端的負載。由此可見，這三種模型都不是完美的，分別有各自的優(yōu)點和不足，沒有絕對的優(yōu)劣與好壞之分，實際選型要根據(jù)具體情況選擇合適的模型，并想方設(shè)法完善其不足之處，從而提高分布式文件系統(tǒng)的擴展性、高性能、可用性等特性。

【發(fā)明內(nèi)容】

[0019]本發(fā)明提出了一種分布式存儲系統(tǒng)中處理面向海量目錄和文件的方法。
[0020]在集群中，將所有的用于存放元數(shù)據(jù)的MetaServer在邏輯上組織成環(huán)。系統(tǒng)采用一致性哈希方案，按照指定的哈希算法對MetaServer的ID進行哈希,并根據(jù)哈希值將各個MetaServer分布在整個哈希值域的環(huán)上。
[0021]每個MetaServer提供元數(shù)據(jù)服務(wù)，即在MetaServer上啟動元數(shù)據(jù)功能服務(wù),對于每一個元數(shù)據(jù)操作請求(例如，readdir, create),首先將該請求中的目錄名用上述哈希算法進行哈希，根據(jù)哈希值確定一個(在元數(shù)據(jù)服務(wù)配置備份時可能有多個)處理該請求的MetaServer0
[0022]對于每一個MetaServer，其上運行的元數(shù)據(jù)服務(wù)會將元數(shù)據(jù)組織成不同的文件。
[0023]每個元數(shù)據(jù)都是一個元數(shù)據(jù)項,如圖1, d/f標(biāo)記是文件還是目錄,文件/目錄名字，創(chuàng)建時間，修改時間,屬主和組,訪問權(quán)限位。
[0024]每個目錄都包含了一組元數(shù)據(jù)項，這組元數(shù)據(jù)項記錄了該目錄下的文件和子目錄的元數(shù)據(jù)信息。
[0025]由于分布式文件系統(tǒng)中，目錄數(shù)目可能非常多。因此將目錄打包成一個較大的塊，存放在本地文件系統(tǒng)中，塊由系統(tǒng)預(yù)分配。如圖2。
[0026]由于不同目錄所包含的元數(shù)據(jù)項數(shù)目差別比較大，例如有些目錄只包含少量的文件和子目錄，因此這樣的目錄包含的元數(shù)據(jù)項就比較少，有些目錄可能包含成千上萬個元數(shù)據(jù)項。為了適應(yīng)不同大小的目錄，并適應(yīng)目錄所包含元數(shù)據(jù)不斷增長的應(yīng)用需求，每個目錄在最初創(chuàng)建時被打包到IevelO的塊中，IevelO的塊中每個目錄可以存放4個元數(shù)據(jù)項。若該目錄下創(chuàng)建更多的文件或子目錄，則在超過4個后，將該目錄對應(yīng)的所有元數(shù)據(jù)項全部移動到Ievell的塊中，Ievell中的塊中，每個目錄可以存放8個元數(shù)據(jù)項。如果該目錄下繼續(xù)創(chuàng)建文件或子目錄，則類推移動到下一個level的塊中，如圖3所示。
[0027]由于塊是預(yù)分配的，并且移動元數(shù)據(jù)項是批量移動，順序讀順序?qū)?，磁盤IO效率很高。另外，如果連續(xù)向同一目錄創(chuàng)建1000000個文件，實際只需要移動18次。
[0028]每個塊都有一個檢索文件Menifest描述每一個目錄在塊中的位置和已經(jīng)寫入的元數(shù)據(jù)項個數(shù)，例如，圖4中‘/home’目錄從O開始存放，當(dāng)前有6個文件或子目錄。系統(tǒng)將每個檢索文件Menifest的信息在內(nèi)存用哈希表重建，加速查找。
【專利附圖】

【附圖說明】
[0029]圖1是元數(shù)據(jù)項示意圖
[0030]圖2是目錄打包成塊示意圖
[0031]圖3是不同level的塊示意圖[0032]圖4是Menifest文件信息示意圖
【具體實施方式】
[0033]步驟1:
[0034]每一個MetaServer配置一個id,選定一個哈希函數(shù)，如Murmurhash,將所有的MetaServer的id進行哈希。
[0035]步驟2:
[0036]對于任意一個元數(shù)據(jù)請求,例如在/home/zhang/下建立一個文件myf ile,則先對目錄字符串進行哈希(使用同樣的哈希函數(shù)Murmurhash),按照一致性哈希算法選定一個MetaServer來處理這個元數(shù)據(jù)請求。
[0037]步驟3:
[0038]分別針對不同的元數(shù)據(jù)請求，執(zhí)行不同的動作:
[0039]I)創(chuàng)建目錄請求:
[0040]首先判斷該請求是否能夠執(zhí)行，如果該MetaServer上已經(jīng)有了這個目錄,則返回目錄已存在消息。否則在IevelO塊中查找一個空閑的位置，在Menifest中添加該記錄。
[0041]2)在目錄下創(chuàng)建文件請求:
[0042]首先從內(nèi)存中記錄的檢索信息文件Menifest中找到該目錄，如果找不到，則返目錄不存在消息。如果該目錄所在的level塊中還能添加新的元數(shù)據(jù)項條目，則增加這個文件元數(shù)據(jù)信息，如果沒有空閑空間，則在下一個級別的level塊中找到一個空閑位置，將該目錄對應(yīng)的所有元數(shù)據(jù)項移動到新位置(元數(shù)據(jù)清除)，然后添加請求中這個文件的元數(shù)據(jù)信息。
[0043]3)在目錄下創(chuàng)建子目錄請求:
[0044]首先從內(nèi)存中記錄的檢索信息文件Menifest中找到該目錄,如果找不到，貝Ij返目錄不存在消息。根據(jù)一致性哈希算法，找到應(yīng)該處理子該目錄的MetaServer，然后向該MetaServer發(fā)送創(chuàng)建該子目錄的請求。如果成功,需要向本地level塊中添加新條目。如果該目錄所在的level塊中還能添加新的元數(shù)據(jù)項條目，則增加這個子目錄元數(shù)據(jù)信息，如果沒有空閑空間，則在下一個級別的level塊中找到一個空閑位置，將該目錄對應(yīng)的所有元數(shù)據(jù)項移動到新位置(元數(shù)據(jù)清除)，然后添加請求中這個子目錄的元數(shù)據(jù)信息。
[0045]4)刪除目錄下某個元數(shù)據(jù)項:
[0046]首先從內(nèi)存中記錄的檢索信息文件Menifest中找到該目錄，如果找不到，則返目錄不存在消息。從該目錄所在的塊查找這一個元數(shù)據(jù)項，標(biāo)記為已刪除。如果該目錄下的元數(shù)據(jù)項少于當(dāng)前l(fā)evel塊中目錄存放元數(shù)據(jù)項最大數(shù)目的一半，則在上一個級別的level塊中找到一個空閑位置，將該目錄對應(yīng)的所有元數(shù)據(jù)項移動到新位置(元數(shù)據(jù)清除)。
[0047]5)刪除目錄請求:
[0048]首先找到該目錄，如果該目錄下有文件或者子目錄，則返回錯誤。根據(jù)一致性哈希找到其父目錄對應(yīng)的MetaServer,向該MetaServer發(fā)送刪除該元數(shù)據(jù)項的請求。
【權(quán)利要求】
1.本發(fā)明設(shè)計了自適應(yīng)的目錄存放方法，其特征在于:能夠針對不同大小的目錄，自適應(yīng)存放，一個元數(shù)據(jù)操作的平均磁盤數(shù)據(jù)略高于I次。
【文檔編號】G06F17/30GK103473337SQ201310431658
【公開日】2013年12月25日 申請日期:2013年9月22日 優(yōu)先權(quán)日:2013年9月22日
【發(fā)明者】王魯俊, 龍翔, 王雷 申請人:北京航空航天大學(xué)