轉自：http://www.uml.org.cn/sjjm/201507284.asp
1 文檔說明
研究分布式文件系統時間也不短了，接觸過的文件系統也不少，趁着這2014到來之際，花點時間用來總結總結。
接觸過的文件系統有glusterfs、moosefs、lustre及hdfs等，其架構簡單順帶解說一點，總體來說分為元數據中心式及去中心式。其實除了glusterfs，其他的都是元數據中心式的分布式文件系統。
對於文件系統的架構只進行簡單的解說，現在主要對以上各種文件系統的數據分布方式進行總結分析，順便從其數據分布方式中分析其性能，可用性，適用性等等。
2 典型DFS及其數據分布
2.1 Lustre
2.1.1系統架構
Lustre是個人最早接觸的一個分布式文件系統，其給我留下最深刻的映象就是“無與倫比”的快，其存儲速度是我見過用過的分布式文件系統中最快的。
先來張Lustre文件系統的架構圖：
圖2.1.1 Lustre架構圖
從架構圖中，我們可以看出Lustre是典型的元數據中心式的分布式文件系統，其元數據服務器為MDS，用於存儲文件的元數據信息，OSS服務器用於存儲實際的文件數據。Lustre支持常規以太網，也支持快速的IB網絡。
從結構上看，MDS支持active-standy支持主備切換，OSS也支持failover，但實際上MDS的主備配置及OSS的故障恢復遠沒有想象中的好用。其主備配置也好，failover也好只是支持服務器級別的切換，其底層真正用於存儲對象結構MDT及OST是不支持主備及故障恢復的。一般底層對象存儲會采用共享存儲的方式來支持MDS的active-standy、OSS的failover。但是這種配置不但會影響性能，配置起來復雜，安全性也沒有想象中高，只要共享存儲層出現故障，整個系統將無法正常使用。
2.1.2數據分布方式
Lustre支持兩種數據分布方式，文件單個整體存儲及文件分片(stripe)存儲兩種方式。
首先是文件整體存儲，文件以單個文件的形式存儲在OST中，不進行任何的數據分片、糾刪碼設置及checksum(校驗)設置等操作，這是一種比較常見的數據分布方式。
Lustre還支持文件分片存儲，也就是常說的stripe方式，很多DFS會提供這么一種數據分布方式。
Lustre支持目錄級的Stripe存儲，即可以通過設置指定某個子目錄的Stripe相關設置，包括Stripe_count、Stripe_size、Stripe_ost。Stripe_size指定子目錄下的文件分片大小；Stripe_count指定選擇OST個數，即分片分布在多少個OST上；Stripe_ost指定起始存儲OST位置，系統默認為-1,即由MDS根據剩余容量及負載選擇初始OST，否則從指定的OST開始分片存儲。
具體設置如下：
lfs setstripe -s Stripe_sizeM -c Stripe_count /mnt/SubDir /Stripe_size必須為page_size的整數據倍X*64KB //Stripe_count小於等於OST數 |
圖2.1.2 Lustre Stripe數據分布示意圖
如圖示例：Lustre存儲由6個OST提供對象存儲空間。/mnt/SubDir1目錄未進行Stripe處理，該目錄下file1以文件的形式存儲在單個OST中，例如存儲在OST0中；/mnt/SubDir2目錄設置Stripe_count=6，則如圖所示，Stripe_size大小的數據分別在6個OST中分布，且按照數據順序輪詢合並；/mnt/SubDir3與SubDir2情形相似，Stripe_count=5。
2.1.3系統優缺點
Lustre可以設置具體子目錄的Stripe參數，這種方式比較靈活，可以根據文件大小進行合適的Stripe目錄設置。並且Stripe的數據分布方式比文件整體存儲高效，無論是文件讀還是寫。
Lustre是基於內核級的分布式文件系統。其文件的讀寫性能在分布式文件系統是比較快的(目前個人使用過，測試過的DFS中是最快的，其他分布式文件系統拍馬難及)。鑒於其性能及其強悍的擴展性，多數用於高性能計算中。高性能，這正是Lustre最大的亮點。
在某種角度上說，Lustre基本不提供數據的保護，無論是數據冗余保護，還是數據的糾刪保護，還是數據校驗保護等等；當然，同樣，其元數據也存在單點問題。這是Lustre的一大弱點。
2.2 HDFS
2.2.1系統架構
HDFS，或者說Hadoop大家會了解多些。其實對於hadoop，個人了解的並不是很多，只是接觸過一些相關的培訓及進行過相關的了解使用，並不是特別的熟悉(正在一步一步的研究他呢)。所以，要是有不對的地方，歡迎大家指正。
先給大家上個架構圖：
圖2.2.1 HDFS架構圖
相信很多人會很熟悉這張hdfs的架構圖。如圖所示，HDFS由兩部分組成，一部分是負責元數據存儲的Namenode，一部分是負責實際存儲數據的Datanodes。Namenode是一個中心服務器，負責管理文件系統的名字空間、負責文件數據塊的組織及處理客戶端對數據的訪問；而Datanode則是一般是一個節點一個，負責管理其所在節點的數據存儲。
最新版本的HDFS會支持一個備用的Namenode，負責定時的備份Namenode上的持久化的元數據信息，但實際上HDFS依然存在單點問題(熟悉MFS架構的朋友會發現，這種架構方式與MFS是如此的相似，又是如此的沒用)。
2.2.2數據分布方式
HDFS只支持數據分塊的方式存儲，默認的數據塊大小為64MB。其與一般的Stripe存儲方式不同(參考Lustre Stripe存儲)，其會把文件分成一個個64MB大小的數據塊，在Datanodes存儲着一個個的64MB大小的數據塊而不是數據塊的集合。
HDFS支持文件存儲時創建副本，用於保證數據的安全性。並且系統保證文件的數據塊的副本塊不會出現在同一個Datanode上，避免某個Datanode失效時，文件無法訪問。並且HDFS可以支持多個副本。
如下圖所示：
圖2.2.2 HDFS數據分布圖
副本數據塊與原數據塊不在同一個datanode中，這種方式保證了任何一個datanode失效，都有其他datanode上的副本數據塊進行替換，從而保證了數據的安全性。
在HDFS的文件實際存儲節點Datanodes中，數據塊是以單獨的文件塊存在，而不是與Lustre那樣將數據塊輪詢合並(對比Lustre數據分布圖)。
HDFS在數據分布中，最特別的是其對數據的校驗。在存儲文件時，HDFS會為每一個64MB的數據塊創建一個對應的checksum，用於文件訪問時對數據塊的校驗。這在分布式文件系統中是很不常見的。
文件在HDFS中是以私有格式存儲的，只能通過系統的API進行訪問。
2.2.3系統優缺點
HDFS作為存儲本身來說，沒有多少存儲優勢。例如其系統本身並不支持標准的POSIX接口，文件需要以專門的數據操作API進行文件數據操作，這在通用存儲中是很不方便的方式；在性能上，其存儲並沒有顯著的優勢，其為每一個數據塊創建一個checksum，雖然在數據安全性上提高了，在某種程度上說會降低其存儲效率；其元數據處理方式，即將元數據加載在內存中，這種方式可以說是優點，即提高了客戶端與元數據及存儲節點與元數據的交互效率，但是由於內存的擴充限制，這會導致其規模擴充受阻(這點與MFS又是極其相似)。所以就目前來說，很少人會將HDFS單純用於存儲的。
然而，就目前研究熱度來說，hadooop絕對是首屈一指的。HDFS其優勢在於以其為基礎的一系列衍生架構，就是大家所說的hadoop生態環境，包括Nosql數據庫系統HBase，Sql操作化的Hive，及數據倉庫Pig等等。Hadoop在批處理上有着無與倫比的優勢，所以，配合其衍生架構，大多數人將其用於數據挖掘數據分析等。
2.3 MooseFS
2.3.1系統架構
MFS主要由四部分組成，元數據服務器Master、元數據日志服務器Metalogger、數據存儲服務器chunkservers、及掛載客戶端client。
圖2.3.1 MFS架構圖
如圖所示，其架構與一般的元數據中心化的分布式文件系統架構相似，多出來不同之處在於Metalogger即元數據日志服務器的增加(這是1.5.X版本之后添加的組件)。該部分組件用於定時備份Master上的元數據文件及Master使用期間產生的changelog文件。在元數據服務器當機的情況下，可以通過Metalogger上的元數據文件及changelog文件來恢復元數據，並且可以通過修復元數據及修改Metalogger的IP方式來替換當機的Master。
2.3.2數據分布方式
MFS支持兩種數據分布方式，一種是常規的以文件為單位的存儲；另一種就是分塊存儲。
MFS的分塊存儲與HDFS的分塊相似，以64MB的數據塊分別存儲在不同的chunkserver中，並且不進行數據塊再次合並存儲。其實MFS與HDFS有很多相似的地方，之前所說的文件分塊方式，其元數據在系統啟動時置於內存的方式及添加日志服務器來備份元數據的方式等。但HDFS的數據是以私有格式存儲，不支持POSIX標准協議的訪問，這點是不同的，其次MFS的數據塊不進行創建校驗值(checksum)，這樣做，降低了一定的數據安全性，但是提高了副本方式的存儲效率。
圖2.3.2 MFS數據分布圖
如圖所示，可以看出MFS的兩種數據存儲方式，此外，MFS還支持多數據副本，其副本的設置是是根據目錄進行設置的，即設置目錄內的文件為副本方式存儲。以目錄為單位，設置比較靈活。單文件存儲方式的副本存儲在另一個chunkserver中，而以數據塊存儲的方式，在保證副本塊不在同一個chunkserver中，如此，則能保證chunkserver不會出現單點問題。
2.3.3系統優缺點
由於MFS機制中，在系統啟動時會將元數據緩存在內存中，這種方式在某種程度上提高了chunkserver與master的交互效率，但是，同樣，由於內存擴充的局限性，這會導致MFS的擴展容易出現限制。根據官方說法，8G的內存能夠存儲2500KW的文件元數據信息，這樣的話，存儲海量的小文件就很容易達到文件個數的限制，而不是chunkserver的容量限制。其實HDFS也會面臨同樣的問題，只是HDFS在元數據結構進行了優化，減少了單個文件的元數據SIZE。
此外，就目前版本的MFS，依然存在單點問題，雖然1.6版本之后添加了Metalogger組件，但是並不能很好的解決元數據的單點問題。實際上，系統至今仍然無法達到故障切換的目的，添加了日志服務器之后，只是在某些情況下出現故障后能夠根據日志服務器進行元數據恢復。
在小規模存儲上MFS還是比較有優勢的，目前已經有不少公司在使用他進行相關的存儲業務，或者在此基礎上進行相關的二次開發。
2.4 GlusterFS
2.4.1系統架構
GlusterFS是個人研究時間最長一個分布式文件系統，總體來說對其還是比較熟悉，無論是從架構還是從他的一些系統機制來說。
GlusterFS架構相對於其他分布式文件系統是最簡單的架構，如圖所示，除去網絡層、外掛Samba及NFS相關東西，就只剩下client及Storage Brick，其實真正的存儲核心就是Storage Brick。
圖2.4.1 GlusterFS架構圖
GlusterFS的架構是去中心式架構，即沒有元數據中心結構，也就意味着其沒有存儲元數據的結構，這正是其異於Lustre、HDFS及MooseFS的地方，這也是其架構的最大特色。
那么其究竟是如何完成文件數據讀寫定位的呢？這就是去中心式的分布式文件系統的特色，GlusterFS通過內部的hash算法實現文件的定位，通過這種方法代替元數據組件產生的作用。就目前來說，去中心式的分布式文件系統就個人所知，只有GlusterFS。
2.4.2數據分布方式
GlusterFS是一個比較全面的分布式文件系統，包括其數據的分布方式。GlusterFS支持三種數據分布，即其可以創建三種卷：分布式卷(Distributed)、條帶卷(Stripe)及副本卷(Replicated)。
分布式卷(Distributed)，系統在存儲文件時，根據文件路徑及brick進行hash計算，根據計算結果決定其將存儲於哪個brick之上，並且在brick中是以單個文件的形式而存在的。這種hash計算會做到盡可能的負載均衡。同樣，在讀取文件時，也會根據hash計算定位文件的位置。
條帶卷(Stripe)，這種數據分布方式是大部分常見的分布式文件系統所支持的。GlusterFS的條帶化數據分布與Lustre的條帶化數據分布很相似。系統根據Stripe count進行輪詢分塊，並且在單個brick中再進行數據塊合並。並且其Stripe size大小默認為128KB。
副本卷(Replicated)，文件在brick中會存儲文件副本，並且副本數可以自由設置，但是會根據brick數進行相關的限制。系統還針對副本卷設計了文件自動修復機制，以保持副本文件的正確性。
GlusterFS是數據分布最靈活的分布式文件系統，以上三種數據分布方式可以任意的搭配使用。
圖2.4.2-1 GlusterFS Distributed-Striped Volume
圖2.4.2-2 GlusterFS Distributed-Replicated Volume
圖2.4.2-3 GlusterFS Replicated-Striped Volume
如圖2.4.2-1所示，底層一共兩個server，每個server上做兩個brick，供四個brick做成2x2的Distributed-Striped卷。File1/2是以分布式方式，即hash方式存儲在不同的brick上；而從單個文件的角度看，如File1，其內部是通過Stripe的方式進行條帶化存儲的，其Stripe count為2，通過文件分塊編號，可以看出其數據是Stripe之后再組合成兩個文件存儲在兩個brick上。
如圖2.4.2-2所示，同樣是4個brick，做成2x2的Distributed-Replicated卷。File1/2分別以單個文件為單位hash存儲在不同的brick上，並且保證每個文件都會一個副本文件在其brick之外，從而保證了數據的安全。
如圖2.4.2-3所示，系統是2x2的Replicated-Striped卷。File在兩個brick上Stripe切片存儲，且在另外兩個brick上保存了所有切片的對應副本。
在最新的GlusterFS3.3.X上，系統還是支持Distributed-Replicated-Stripe卷，即三種數據分布方式組成的系統卷，其數據具體分布方式由上面三個圖就很容易推斷出來了。GlusterFS其卷的數據分布設置與其brick數目有很大的關系。
就目前所知的情況，Stripe卷一般較少的人使用，其性能有待於提高，而最常使用的數據分布組合方式就是Distributed-Replicated。總體上說，GlusterFS提供了多種數據分布方式，並提供了靈活多變的組合方式，讓我們在使用方便了許多。
2.4.3系統優缺點
GlusterFS最大的特點在於其無元數據的整體架構，但這只能說是他的一大特色，算不上其優點。據其官網上所說的無中心結構使其存儲擴展近似線性，這也只是理論上的線性擴展，實際上GlusterFS的擴展性能比能達到70%-80%就很不錯了。這可能會比其他分布式文件系統擴展性能損耗上好一點點(中心化的分布式文件系統隨着存儲節點的增加，並行量上升，元數據負載會越來越大，導致其性能會損耗很大)，但隨之而來的問題是，文件遍歷時的效率呈直線下降，特別是在存儲了大批量文件時。由於其是無元數據結構，導致文件遍歷需要遍歷需要實際遍歷整個系統卷，而不是如其他分布式文件系統那樣直接從元數據服務器中獲取。這是其一大缺點。
GlusterFS提供了比較多的功能，其多種卷的組合是一個，他還提供了文件修復機制、遠程地域備份、在線擴容縮容、存儲節點在線替換等等。此外，個人認為其最大的優點在於其具有一個完善的命令行管理接口，在眾多分布式文件系統中，GlusterFS管理起來是最方便的，所有操作都可以通過命令行工具進行管理，而不是像很多文件系統那樣通過修改配置文件進行操作等等。
3 總結
從數據基本分布方式來看，目前開源的總體就分為單個文件存儲、副本或者是鏡像文件存儲、及數據分塊存儲。在數據分塊存儲中，有典型的條帶化Stripe存儲，如lustre及gluster的stripe存儲方式，以及HDFS、MFS文件真正分塊(chunk)存儲的方式。
分塊存儲在大多數情況下並不能提升文件寫效率，當然這也和系統機制有關，如lustre的stripe存儲就比文件單獨存儲的方式效率要高，但其他的分布式文件系統沒有如此明顯的差異，glusterfs的stripe存儲效率還極其的低，很少人會使用它。但分塊存儲在讀效率上會有明顯的提升，特別是針對大文件讀時。
副本存儲或者鏡像存儲的數據存儲方式是一種比較普遍的數據安全保證的數據分布。實現起來也比較容易。還有一種提供數據保護的數據分布方式就是糾刪碼。目前在開源分布式文件系統中好像沒有看到有人將其實現，但在一些商業分布式文件系統中能看到它的身影，其實現難度也比副本存儲的難度大。一些國內的分布式文件系統研發公司將其作為開源分布式文件系統二次開發目標。這種數據存儲方式類似於RAID5，不僅能夠提供數據保護，還節約了硬件成本。
在技術群中不少人都會問一個相類似的問題“大家認為哪個開源分布式文件系統最好？”其實這個問題是很難回答的。就目前這些開源的文件系統中，各有各的特色，但同樣他們都存在一定缺陷或者說是不足之處。哪怕是商業分布式文件系統，同樣也會存在這個問題。沒有最好，只有最合適！
如果你追求的高效，並且在一定程度上可以容忍少量數據的丟失，那么lustre將會是你的不二選擇，至於數據的安全性，你可以使用第三方的軟件或者系統來實現，或者說直接就忽略之；如果你的業務需求是做數據挖掘數據分析，那么不用多想了，沒有人不選擇HDFS而去選擇其他的；如果你想使用起來功能比較完善，並且管理起來比較方便，那么GlusterFS會是不錯的選擇；如果你想使用它來存儲小文件，好吧，以上那些除了MFS適合一點點(不少公司使用MFS進行小規模存儲小文件)，其他的也都是扯犢子的；當然，如果確實需要存儲海量小文件，也是有專門為小文件設計的開源分布式文件系統，例如國人開發的FastDFS、MogileFS以及淘寶開源的TFS，只是對於這些分布式文件系統個人就不是很熟悉了，也只是知道個大概而已。