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

【作者】 趙海

1 引言

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

2 主流分布式存儲技術(shù)對比分析

2.1 GFS & HDFS

GFS和HDFS都是基于文件系統(tǒng)實現(xiàn)的分布式存儲系統(tǒng)；都是有中心的分布式架構(gòu) （圖2.1） ；通過對中心節(jié)點元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點上查詢數(shù)據(jù)本身的機(jī)制來完成數(shù)據(jù)的讀寫；都是基于文件數(shù)據(jù)存儲場景設(shè)計的架構(gòu) ；都是適合順序?qū)懭腠樞蜃x取，對隨機(jī)讀寫不友好。

圖2.1 中心化的分布式存儲架構(gòu)

接下來，我們來看GFS和HDFS都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. GFS是一種適合大文件，尤其是GB級別的大文件存儲場景的分布式存儲系統(tǒng)。
2. GFS非常適合對數(shù)據(jù)訪問延遲不敏感的搜索引擎服務(wù)。
3. GFS是一種有中心節(jié)點的分布式架構(gòu)，Master節(jié)點是單一的集中管理節(jié)點，既是高可用的瓶頸，也是可能出現(xiàn)性能問題的瓶頸。
4. GFS可以通過緩存一部分Metadata到Client節(jié)點，減少Client與Master的交互。
5. GFS的Master節(jié)點上的Operation log和Checkpoint文件需要通過復(fù)制方式保留多個副本，來保障元數(shù)據(jù)以及中心管理功能的高可用性。

相對于GFS來說，我們來看HDFS做了哪些區(qū)別？

1. HDFS的默認(rèn)最小存儲單元為128M，比GFS的64M更大。
2. HDFS不支持文件并發(fā)寫，對于單個文件它僅允許有一個寫或者追加請求。
3. HDFS從2.0版本之后支持兩個管理節(jié)點（NameNode），主備切換可以做到分鐘級別。
4. HDFS 更適合單次寫多次讀的大文件流式讀取的場景。
5. HDFS不支持對已寫文件的更新操作，僅支持對它的追加操作。

2.2 GlusterFS

GlusterFS雖然是基于文件系統(tǒng)的分布式存儲技術(shù)，但是它與GFS/HDFS有本質(zhì)的區(qū)別，它是去中心化的無中心分布式架構(gòu)（圖2.2）；它是通過對文件全目錄的DHT算法計算得到相應(yīng)的Brike地址，從而實現(xiàn)對數(shù)據(jù)的讀寫；它與Ceph/Swift的架構(gòu)區(qū)別在于它沒有集中收集保存集群拓?fù)浣Y(jié)構(gòu)信息的存儲區(qū)，因此在做計算的時候，需要遍歷整個卷的Brike信息。

圖2.2 Gluster FS

接下來，我們來看GlusterFS都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. GlusterFS是采用無中心對稱式架構(gòu)，沒有專用的元數(shù)據(jù)服務(wù)器，也就不存在元數(shù)據(jù)服務(wù)器瓶頸。元數(shù)據(jù)存在于文件的屬性和擴(kuò)展屬性中 。
2. GlusterFS可以提供Raid0、Raid1、Raid1+0等多種類型存儲卷類型。
3. GlusterFS采用數(shù)據(jù)最終一致性算法，只要有一個副本寫完就可以Commit。
4. GlusterFS默認(rèn)會將文件切分為128KB的切片，然后分布于卷對應(yīng)的所有Brike當(dāng)中。所以從其設(shè)計初衷來看，更適合大文件并發(fā)的場景。
5. GlusterFS 采用的DHT算法不具備良好的穩(wěn)定性，一旦存儲節(jié)點發(fā)生增減變化，勢必影響卷下面所有Brike的數(shù)據(jù)進(jìn)行再平衡操作，開銷比較大。
6. Gluster FS文件 目錄利用擴(kuò)展屬性記錄子卷的中brick的hash分布范圍，每個brick的范圍均不重疊。遍歷目錄時，需要獲取每個文件的屬性和擴(kuò)展屬性進(jìn)行聚合，當(dāng)目錄文件 較多 時，遍歷 效率很差 。

2.3 Ceph & Swift

我們知道， 相對于文件系統(tǒng)的中心架構(gòu)分布式存儲技術(shù)，Ceph&Swift都是去中心化的無中心分布式架構(gòu)（圖2.3）；他們底層都是對象存儲技術(shù)；他們都是通過對對象的哈希算法得到相應(yīng)的Bucket&Node地址，從而實現(xiàn)對數(shù)據(jù)的讀寫 。

圖2.3 去中心化的分布式存儲架構(gòu)

接下來，我們來看Ceph和Swift都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲平臺，上層應(yīng)用支持Object、Block、File 。
2. Ceph采用Crush算法完成數(shù)據(jù)分布計算，通過Tree的邏輯對象數(shù)據(jù)結(jié)構(gòu)自然實現(xiàn)故障隔離副本位置計算，通過將Bucket內(nèi)節(jié)點的組織結(jié)構(gòu)，集群結(jié)構(gòu)變化導(dǎo)致的數(shù)據(jù)遷移量最小。
3. Ceph保持?jǐn)?shù)據(jù)強(qiáng)一致性算法，數(shù)據(jù)的所有副本都寫入并返回才算寫事務(wù)的完成，寫的效率會差一些，所以更適合寫少讀多的場景。
4. 對象保存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結(jié)構(gòu)化數(shù)據(jù)存儲。

雖然底層都是對象存儲，相對于Ceph來說，Swift又有哪些獨特的特性呢？

1. Swift只保障數(shù)據(jù)的最終一致性，寫完2個副本后即可Commit，這就導(dǎo)致讀操作需要進(jìn)行副本的對比校驗，讀的效率相對較低。
2. Swift采用一致性哈希算法完成數(shù)據(jù)分布計算，通過首次計算對象針對邏輯對象（Zone）的映射實現(xiàn)數(shù)據(jù)副本的故障隔離分布，然后通過哈希一致性算法完成對象在Bucket當(dāng)中的分布計算，采用Ring環(huán)結(jié)構(gòu)組織Bucket節(jié)點組織，數(shù)據(jù)分布不如Ceph均勻。
3. Swift 需要借助Proxy節(jié)點完成對數(shù)據(jù)的訪問，不同于通過客戶端直接訪問數(shù)據(jù)節(jié)點，相對數(shù)據(jù)的訪問效率來講，比Ceph要差一些。

總結(jié)來看，由于Swift需要通過Proxy節(jié)點完成與數(shù)據(jù)節(jié)點的交互，雖然Proxy節(jié)點可以負(fù)載均衡，但是畢竟經(jīng)歷了中間層，在并發(fā)量較大而且小文件操作量比較的場景下，Ceph的性能表現(xiàn)會優(yōu)秀一些。 為了說明我們從原理層面的判斷，接下來借助ICCLAB&SPLAB的性能測試結(jié)果來說明。

表1 Ceph集群配置

表2 Swift集群配置

以上是測試本身對于Ceph和Swift的節(jié)點及物理對象配置信息，從表的對比，基本可以看出物理硬件配置都是相同的，只不過在Swift的配置當(dāng)中還需要配置Container相關(guān)邏輯對象。

{x}count{y}kb，x表示Swift集群當(dāng)中設(shè)置的Container數(shù)量，y表示進(jìn)行壓力測試所用的數(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指標(biāo)；
2. 對于并發(fā)寫操作，Ceph的并發(fā)量越高其性能表現(xiàn)越接近Swift，并發(fā)量越少其性能表現(xiàn)會明顯遜色于Swift。
3. 對于并發(fā)讀寫操作的性能穩(wěn)定性上，Ceph遠(yuǎn)勝于Swift。

3 結(jié)語

通過對主流分布式存儲技術(shù)的各項特性分析梳理之后，我們基本上可以得出以下若干結(jié)論：

1. GFS/HDFS還是適合特定大文件應(yīng)用的分布式文件存儲系統(tǒng)（搜索、大數(shù)據(jù)...）；
2. GlusterFS是可以代替NAS的通用分布式文件系統(tǒng)存儲技術(shù)，可配置性較強(qiáng)；
3. Ceph是平衡各個維度之后相對比較寬容的統(tǒng)一分布式存儲技術(shù)；
4. 分布式存儲技術(shù)終究不適合應(yīng)用到熱點比較集中的關(guān)系型數(shù)據(jù)庫的存儲卷場景上。