主流分布式存儲技術對比分析-GFS-HDFS-GlusterFS-Ceph-Swift

主流分布式存儲技術對比分析GFS、HDFS、GlusterFS、Ceph、Swift

【導讀】如今分布式存儲產(chǎn)品眾多令人眼花繚亂，如何選型？要根據(jù)其背后的核心架構來分析它本來的原貌，然后才能決定其是否適合我們的具體場景。1

引言目前市面上各個廠家的分布式存儲產(chǎn)品五花八門，但是如果透過產(chǎn)品本身的包裝看到其背后的核心技術體系，基本上會分為兩種架構，一種是有中心架構的分布式文件系統(tǒng)架構，以GFS、HDFS為代表；另外一種是完全無中心的分布式存儲架構，以Ceph、Swift、GlusterFS為代表。對具體分布式存儲產(chǎn)品選型的時候，要根據(jù)其背后的核心架構來分析它本來的原貌，然后才能決定其是否適合我們的具體場景。2

主流分布式存儲技術對比分析2.1

GFS&HDFSGFS和HDFS都是基于文件系統(tǒng)實現(xiàn)的分布式存儲系統(tǒng)；都是有中心的分布式架構（圖2.1）；通過對中心節(jié)點元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點上查詢數(shù)據(jù)本身的機制來完成數(shù)據(jù)的讀寫；都是基于文件數(shù)據(jù)存儲場景設計的架構；都是適合順序?qū)懭腠樞蜃x取，對隨機讀寫不友好。圖2.1中心化的分布式存儲架構接下來，我們來看GFS和HDFS都有哪些具體特性，我們應該如何應用？1.GFS是一種適合大文件，尤其是GB級別的大文件存儲場景的分布式存儲系統(tǒng)。2.GFS非常適合對數(shù)據(jù)訪問延遲不敏感的搜索引擎服務。3.GFS是一種有中心節(jié)點的分布式架構，Master節(jié)點是單一的集中管理節(jié)點，既是高可用的瓶頸，也是可能出現(xiàn)性能問題的瓶頸。4.GFS可以通過緩存一部分Metadata到Client節(jié)點，減少Client與Master的交互。5.GFS的Master節(jié)點上的Operationlog和Checkpoint文件需要通過復制方式保留多個副本，來保障元數(shù)據(jù)以及中心管理功能的高可用性。相對于GFS來說，我們來看HDFS做了哪些區(qū)別？1.HDFS的默認最小存儲單元為128M，比GFS的64M更大。2.HDFS不支持文件并發(fā)寫，對于單個文件它僅允許有一個寫或者追加請求。3.HDFS從2.0版本之后支持兩個管理節(jié)點（NameNode），主備切換可以做到分鐘級別。5.HDFS更適合單次寫多次讀的大文件流式讀取的場景。6.HDFS不支持對已寫文件的更新操作，僅支持對它的追加操作。2.2

GlusterFSGlusterFS雖然是基于文件系統(tǒng)的分布式存儲技術，但是它與GFS/HDFS有本質(zhì)的區(qū)別，它是去中心化的無中心分布式架構（圖2.2）；它是通過對文件全目錄的DHT算法計算得到相應的Brike地址，從而實現(xiàn)對數(shù)據(jù)的讀寫；它與Ceph/Swift的架構區(qū)別在于它沒有集中收集保存集群拓撲結構信息的存儲區(qū)，因此在做計算的時候，需要遍歷整個卷的Brike信息。圖2.2GlusterFS接下來，我們來看GlusterFS都有哪些具體特性，我們應該如何應用？1.GlusterFS是采用無中心對稱式架構，沒有專用的元數(shù)據(jù)服務器，也就不存在元數(shù)據(jù)服務器瓶頸。元數(shù)據(jù)存在于文件的屬性和擴展屬性中。2.GlusterFS可以提供Raid0、Raid1、Raid1+0等多種類型存儲卷類型。3.GlusterFS采用數(shù)據(jù)最終一致性算法，只要有一個副本寫完就可以Commit。4.GlusterFS默認會將文件切分為128KB的切片，然后分布于卷對應的所有Brike當中。所以從其設計初衷來看，更適合大文件并發(fā)的場景。5.GlusterFS采用的DHT算法不具備良好的穩(wěn)定性，一旦存儲節(jié)點發(fā)生增減變化，勢必影響卷下面所有Brike的數(shù)據(jù)進行再平衡操作，開銷比較大。6.GlusterFS文件目錄利用擴展屬性記錄子卷的中brick的hash分布范圍，每個brick的范圍均不重疊。遍歷目錄時，需要獲取每個文件的屬性和擴展屬性進行聚合，當目錄文件較多時，遍歷效率很差。2.3

Ceph&Swift我們知道，相對于文件系統(tǒng)的中心架構分布式存儲技術，Ceph&Swift都是去中心化的無中心分布式架構（圖2.3）；他們底層都是對象存儲技術；他們都是通過對對象的哈希算法得到相應的Bucket&Node地址，從而實現(xiàn)對數(shù)據(jù)的讀寫。圖2.3去中心化的分布式存儲架構接下來，我們來看Ceph和Swift都有哪些具體特性，我們應該如何應用？1.Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲平臺，上層應用支持Object、Block、File。2.Ceph采用Crush算法完成數(shù)據(jù)分布計算，通過Tree的邏輯對象數(shù)據(jù)結構自然實現(xiàn)故障隔離副本位置計算，通過將Bucket內(nèi)節(jié)點的組織結構，集群結構變化導致的數(shù)據(jù)遷移量最小。3.Ceph保持數(shù)據(jù)強一致性算法，數(shù)據(jù)的所有副本都寫入并返回才算寫事務的完成，寫的效率會差一些，所以更適合寫少讀多的場景。4.對象保存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結構化數(shù)據(jù)存儲。雖然底層都是對象存儲，相對于Ceph來說，Swift又有哪些獨特的特性呢？1.Swift只保障數(shù)據(jù)的最終一致性，寫完2個副本后即可Commit，這就導致讀操作需要進行副本的對比校驗，讀的效率相對較低。2.Swift采用一致性哈希算法完成數(shù)據(jù)分布計算，通過首次計算對象針對邏輯對象（Zone）的映射實現(xiàn)數(shù)據(jù)副本的故障隔離分布，然后通過哈希一致性算法完成對象在Bucket當中的分布計算，采用Ring環(huán)結構組織Bucket節(jié)點組織，數(shù)據(jù)分布不如Ceph均勻。3.Swift需要借助Proxy節(jié)點完成對數(shù)據(jù)的訪問，不同于通過客戶端直接訪問數(shù)據(jù)節(jié)點，相對數(shù)據(jù)的訪問效率來講，比Ceph要差一些?？偨Y來看，由于Swift需要通過Proxy節(jié)點完成與數(shù)據(jù)節(jié)點的交互，雖然Proxy節(jié)點可以負載均衡，但是畢竟經(jīng)歷了中間層，在并發(fā)量較大而且小文件操作量比較的場景下，Ceph的性能表現(xiàn)會優(yōu)秀一些。為了說明我們從原理層面的判斷，接下來借助ICCLAB&SPLAB的性能測試結果來說明。表1Ceph集群配置

[Node1-MON][Node2-OSD][Node2-OSD][HDD1:OS][HDD1:OS][HDD1:OS][HDD2:notused][HDD2:osd.0-xfs][HDD2:osd.2-xfs][HDD3:notused][HDD3:osd.1-xfs][HDD3:osd.3-xfs][HDD4:notused][HDD4:journal][HDD4:journal]表2Swift集群配置[Node1-Proxy][Node2-Storage][Node2-Storage][HDD1:OS][HDD1:OS][HDD1:OS][HDD2:notused][HDD2:dev1-xfs][HDD2:dev3-xfs][HDD3:notused][HDD3:dev2-xfs][HDD3:dev4-xfs][HDD4:notused][HDD4:notused][HDD4:notused]以上是測試本身對于Ceph和Swift的節(jié)點及物理對象配置信息，從表的對比，基本可以看出物理硬件配置都是相同的，只不過在Swift的配置當中還需要配置Container相關邏輯對象。{x}count{y}kb，x表示Swift集群當中設置的Container數(shù)量，y表示進行壓力測試所用的數(shù)據(jù)大小。從圖中表現(xiàn)出來的性能趨勢分析：1.Container的數(shù)量越多，Swift的讀寫性能會相對差一些；2.在4K-128K數(shù)據(jù)大小的范圍內(nèi)，Ceph和Swift的讀性能表現(xiàn)都是最佳的；3.在4K-64K數(shù)據(jù)大小范圍內(nèi)，Ceph的讀性能幾乎是Swift的2-3倍，但是寫的性能相差不是非常大。Ceph_{x}Swift{x},x表示并發(fā)數(shù)量。從圖中表現(xiàn)出來的性能趨勢分析：1.對于并發(fā)讀操作，Ceph的表現(xiàn)上明顯優(yōu)于Swift，無論是穩(wěn)定性還是IOPS指標；2.對于并發(fā)寫操作，Ceph的并發(fā)量越高其性能表現(xiàn)越接近Swift，并發(fā)量越少其性能表現(xiàn)會明顯遜色于Swift。3.對于并發(fā)讀寫操作的性能穩(wěn)定性上，Ceph遠勝于Swift。3結語通過對主流分布式存儲技術的各項特性分析梳