MooseFS中chunkserver負載均衡算法研究*

艾云霄，譚躍生，王靜宇

（內蒙古科技大學 信息工程學院，內蒙古 包頭 014010）

隨著云計算迅速發(fā)展，IT界將進入“云”時代。然而，云計算[1]中會產生海量的數(shù)據(jù)存儲，傳統(tǒng)的文件系統(tǒng)已不能滿足其性能要求。作為云存儲的核心基礎平臺，分布式文件系統(tǒng)的重要性日益凸顯。目前，互聯(lián)網上應用最多的分布式文件系統(tǒng)有 GFS[2]、HDFS[3]、MooseFS等。MooseFS分布式文件系統(tǒng)，其設計思想來源于google文件系統(tǒng)，采用的是主從式服務器架構，通過將文件數(shù)據(jù)分成64 MB的chunk塊分散存儲在多臺通過網絡連接起來的計算機節(jié)點上，這種模式不可避免地存在一些節(jié)點分配的chunk塊過多，而另外一些節(jié)點卻是空閑的，導致系統(tǒng)的chunkserver數(shù)據(jù)塊分配負載不均衡問題。

數(shù)據(jù)的負載均衡是分布式文件系統(tǒng)的核心之一，是否有好的負載均衡算法直接影響系統(tǒng)的性能，如果算法沒有選擇好，會導致負載嚴重失衡，使系統(tǒng)的性能不能得到充分的發(fā)揮。因此有必要研究chunkserver的數(shù)據(jù)塊負載均衡選擇算法，以解決chunkserver數(shù)據(jù)塊分配的負載均衡問題。

1 相關工作

負載均衡[4-5]的實現(xiàn)方法主要有靜態(tài)模式和動態(tài)模式。靜態(tài)模式是指在系統(tǒng)執(zhí)行前，提前采取相應措施，把數(shù)據(jù)存儲到各個節(jié)點上，盡可能地保證系統(tǒng)運行過程中不出現(xiàn)負載不均衡現(xiàn)象。動態(tài)模式是指在系統(tǒng)執(zhí)行過程中，實時根據(jù)節(jié)點的存儲狀況來實現(xiàn)負載均衡。很顯然，靜態(tài)模式仍然還會有較高的概率出現(xiàn)系統(tǒng)負載不均衡現(xiàn)象，動態(tài)模式雖然實現(xiàn)起來比靜態(tài)模式復雜，但是執(zhí)行后效果好。MooseFS分布式文件系統(tǒng)就是采用動態(tài)模式來實現(xiàn)chunkserver的負載均衡的。

負載的量化有多種標準，如CPU利用率、內存利用率等。目前，最常見的負載均衡算法有輪轉法、隨機法、散列法、最快響應法[3]等。輪轉法，均衡器將新的請求輪流發(fā)給節(jié)點表中的下一個節(jié)點，是一種絕對平等。隨機法，把偽隨機算法產生的值賦給各節(jié)點，具有最大或最小隨機數(shù)的節(jié)點最有優(yōu)先權，各個節(jié)點的機會也是均等的。散列法也叫哈希法，利用單射不可逆的HASH函數(shù)，按照某種規(guī)則將新的請求發(fā)送到某個節(jié)點。最快響應法，平衡器記錄自身到每個節(jié)點的網絡響應時間，并將下一個到達的連接請求分配給響應時間最短的節(jié)點。

本文以chunkserver上chunk塊的多少作為負載均衡的指標。這里負載均衡是指各個chunkserver上chunk塊數(shù)的多少大致相同，不會出現(xiàn)一些chunkserver上塊數(shù)很多，而另外一些chunkserver上塊數(shù)很少或是沒有塊數(shù)，造成一些chunkserver運行繁忙，而一些chunkserver處于空閑狀態(tài)的不均衡現(xiàn)象。

2 MooseFS的chunkserver負載均衡算法

Moose File System[6]是一個具備容錯功能的網絡分布式文件系統(tǒng)，它將數(shù)據(jù)分布在網絡中的不同服務器上，MooseFS通過FUSE使之看起來就是一個Unix的文件系統(tǒng)。即分布在各個范圍的計算機將它們未使用的分區(qū)統(tǒng)一進行管理使用的一種文件系統(tǒng)。

2.1 MooseFS文件系統(tǒng)架構

MooseFS分布式文件系統(tǒng)主要由四部分組成[7]：

（1）管理服務器 managing server（master）：負責各個數(shù)據(jù)存儲服務器的管理，文件讀寫調度，文件空間回收以及恢復，多節(jié)點拷貝。

（2）元數(shù)據(jù)日志服務器 Metalogger server（Metalogger）：負責備份master服務器的變化日志文件，文件類型為changelog_ml.*.mfs，以便于在 master server出問題的時候接替其進行工作。

（3）數(shù)據(jù)存儲服務器 data servers（chunkservers）：負責連接管理服務器，聽從管理服務器調度，提供存儲空間，并為客戶提供數(shù)據(jù)傳輸。

（4）客戶機掛載使用 client computers：通過 fuse內核接口掛接遠程管理服務器上所管理的數(shù)據(jù)存儲服務器，使共享的文件系統(tǒng)和本地unix文件系統(tǒng)的使用效果類似。

2.2 chunkserver負載均衡算法

在MFS系統(tǒng)中，當客戶端向數(shù)據(jù)存儲服務器上傳文件時，這些被上傳的文件被劃分成64 MB大小的chunk塊，然后再根據(jù)chunkserver選擇算法被存儲在數(shù)據(jù)存儲服務器上。如果chunk塊被均衡分配，則系統(tǒng)不會出現(xiàn)一些chunkserver運行繁忙，而一些chunkserver處于空閑狀態(tài)的現(xiàn)象，提高了用戶訪問系統(tǒng)的速度。

MFS源代碼中定義了matoceeerventry結構體，用來描述chunkserver的信息。在這個結構體中有一個carry變量，它是MFS中數(shù)據(jù)存儲時分布算法的核心。MFS中每臺chunkserver會有自己的carry值，在選擇chunkserver時會將每臺chunkserver按照carry值從大到小做快速排序，優(yōu)先選擇carry值大的chunkserver來使用。算法流程圖如圖1所示。其中，allcnt表示mfs中可用的chunkserver的個數(shù)，availcnt表示mfs中當前可以直接存儲數(shù)據(jù)的chunkserver的個數(shù)，demand表示當前文件的副本數(shù)目。

MFS系統(tǒng)啟動時，通過rndu32（）函數(shù)為每一個chunkserver隨機產生一個大于0且小于1的carry值。系統(tǒng)運行時，每臺chunkserver的carry值的變化滿足以下規(guī)律[8]：

（1）僅當 carry值大于 1時，才可以向此 chunkserver中存儲數(shù)據(jù)，并將此chunkserver的carry值減1。

（2）當 demand〉availcnt時，循環(huán)增加每臺 chunkserver對應的carry變量的值，直到滿足demand〈availcnt時為止。

（3）變量carry每次增加的增量為本臺chunkserver的總空間與系統(tǒng)中總空間最大chunkserver的總空間的比值。

根據(jù)以上算法的分析可知，在MFS系統(tǒng)中，數(shù)據(jù)并不是均勻地分配到各臺chunkserver上的，而是chunkserver總空間大的，分配到的數(shù)據(jù)就多，即分配到chunkserver上的數(shù)據(jù)與此chunkserver的總空間大小成正比。如果chunkserver的總空間大小相同，則數(shù)據(jù)被均勻分配到chunkserver上，表1為隨機生成500個、1 000個、1 500個、2 000個文件時，chunk塊在各個chunkserver上的分布，測試結果顯示，數(shù)據(jù)被均勻分配到各個chunkserver上。

表1 chunk塊的分布情況測試

2.3 改進的chunkserver負載均衡算法

在MFS系統(tǒng)中，如果chunkserver的總空間大小差別很大，就會造成總空間大的chunkserver被多次選擇，chunk塊數(shù)多，而總空間小的chunkserver很少或幾乎不被選擇，chunk塊數(shù)少，造成chunk塊分布不均衡。在圖1整個算法流程圖中循環(huán)增加可直接存儲數(shù)據(jù)的chunkserver的個數(shù)，即增加carry的值直至demand=availcnt是負載均衡算法的核心部分，而其中carry的增加量servtab[allcnt].w如何計算是算法的關鍵問題。增加可直接存儲數(shù)據(jù)的chunkserver的流程圖如圖2所示，算法實現(xiàn)代碼如下：

圖2 chunkserver增加算法流程圖

在原算法中carry的增加量servtab[allcnt].w=（double）eptr-〉totalspace/（double）maxtotalspace，就是把本臺chunkserver的總空間與系統(tǒng)中總空間最大chunkserver的總空間的比值作為carry變量的增加量。而改進后carry的增加量 servtab[allcnt].w=（（double）maxtotalspace-（double）eptr-〉usedspace）/（double）maxtotalspace， 就是把系統(tǒng)中總空間最大chunkserver的總空間減去本臺chunkserver已用去的空間大小后與系統(tǒng)中總空間最大chunkserver的總空間的比值作為carry變量的增加量。

2.4 對改進負載均衡算法的測試

本測試的實驗環(huán)境是在VMware里虛擬出5臺虛擬機 ，1 臺 master，3 臺 chunkserver，1 臺 client。 其 中 ，3 臺chunkserver的硬盤大小分別為 5 GB，8 GB，11 GB，其他配置均相同。測試的主要目的是檢測改進的算法是否能將數(shù)據(jù)均勻地存儲到各臺chunkserver上，此時系統(tǒng)的冗余備份設置為1。

利用測試腳本隨機生成1 000個隨機文件，然后上傳到MFS系統(tǒng)中。算法改進前后chunk塊的分布情況如表2和表3所示。

表2 算法改進前chunk的分布情況

表3 算法改進后chunk的分布情況

實驗分別對改進前和改進后做了4次測試。從測試結果可以看出，算法改進前chunkserver硬盤容量越大，其上數(shù)據(jù)的分布就越多，這種情況容易導致各臺chunkserver上的訪問壓力不一樣，使系統(tǒng)性能不能達到最優(yōu)。算法改進后，數(shù)據(jù)在chunkserver上基本是平均分配，各臺chunkserver訪問壓力也基本一致，避免了總空間大的chunkerver總被不停地訪問，而總空間小的chunkserver被閑置，使系統(tǒng)性能得到了優(yōu)化。

本文對MooseFS分布式文件系統(tǒng)進行了分析，針對chunkserver選擇算法存在負載不均衡的不足進行了改進，避免出現(xiàn)系統(tǒng)中總空間大的chunkserver上存儲chunk塊數(shù)多、訪問量大，而總空間小的chunkserver上存儲的chunk塊數(shù)少或沒有chunk塊存數(shù)而處于閑置狀態(tài)。通過實驗測試，改進后達到了預期的效果，chunk塊在各個chunkserver上分布均衡，系統(tǒng)性能得到優(yōu)化。

[1]王德政，申山宏，周寧寧．云計算環(huán)境下的數(shù)據(jù)存儲[J]．計算機技術與發(fā)展，2011，21（4）：81-82.

[2]GHEMAWAT S， GOBIOFF H， LEUNG S T.The Google file system[C].Proceedings of the 19th ACM Symposium on Operating Systems Principles．Lake George，New York：2003：29-43．

[3]APACHE HADOOP．Hadoop[EB/OL]．[2009-03-06]．（2012-03-19）http：//hadoop．apache．org/．

[4]譚支鵬．對象存儲系統(tǒng)副本管理研究[D]．武漢：華中科技大學，2008.

[5]張聰萍，尹建偉．分布式文件系統(tǒng)的動態(tài)負載均衡算法[J].小型微型計算機系統(tǒng)，2011，32（7）：1424-1426.

[6]百度文庫.MFS文檔[DB/OL].2010.http：//wenku.baidu.com/view/320b56260722192e4536f61b.html.

[7]51CT0 博 客.MooseFS 介 紹[DB/OL].2011.http：//haiquan517.blog.51cto.com/165507/526252.

[8]mfs （mooseFS） 深入分析 （chunkserver選擇算法）[DB/OL]．2011.http：//www.oratea.net/？ p=285#comment-481.