【導(dǎo)讀】 如今分布式存儲(chǔ)產(chǎn)品眾多令人眼花繚亂,如何選型?要根據(jù)其背后的核心架構(gòu)來分析它本來的原貌,然后才能決定其是否適合我們的具體場(chǎng)景。
【作者】 趙海
1 引言
目前市面上各個(gè)廠家的分布式存儲(chǔ)產(chǎn)品五花八門,但是如果透過產(chǎn)品本身的包裝看到其背后的核心技術(shù)體系,基本上會(huì)分為兩種架構(gòu),一種是有中心架構(gòu)的分布式文件系統(tǒng)架構(gòu),以GFS、HDFS為代表;另外一種是完全無中心的分布式存儲(chǔ)架構(gòu),以Ceph、Swift、GlusterFS為代表。對(duì)具體分布式存儲(chǔ)產(chǎn)品選型的時(shí)候,要根據(jù)其背后的核心架構(gòu)來分析它本來的原貌,然后才能決定其是否適合我們的具體場(chǎng)景。
2 主流分布式存儲(chǔ)技術(shù)對(duì)比分析
2.1 GFS & HDFS
GFS和HDFS都是基于文件系統(tǒng)實(shí)現(xiàn)的分布式存儲(chǔ)系統(tǒng);都是有中心的分布式架構(gòu) (圖2.1) ;通過對(duì)中心節(jié)點(diǎn)元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間,然后再去數(shù)據(jù)節(jié)點(diǎn)上查詢數(shù)據(jù)本身的機(jī)制來完成數(shù)據(jù)的讀寫;都是基于文件數(shù)據(jù)存儲(chǔ)場(chǎng)景設(shè)計(jì)的架構(gòu) ;都是適合順序?qū)懭腠樞蜃x取,對(duì)隨機(jī)讀寫不友好。
圖2.1 中心化的分布式存儲(chǔ)架構(gòu)
接下來,我們來看GFS和HDFS都有哪些具體特性,我們應(yīng)該如何應(yīng)用?
- GFS是一種適合大文件,尤其是GB級(jí)別的大文件存儲(chǔ)場(chǎng)景的分布式存儲(chǔ)系統(tǒng)。
- GFS非常適合對(duì)數(shù)據(jù)訪問延遲不敏感的搜索引擎服務(wù)。
- GFS是一種有中心節(jié)點(diǎn)的分布式架構(gòu),Master節(jié)點(diǎn)是單一的集中管理節(jié)點(diǎn),既是高可用的瓶頸,也是可能出現(xiàn)性能問題的瓶頸。
- GFS可以通過緩存一部分Metadata到Client節(jié)點(diǎn),減少Client與Master的交互。
- GFS的Master節(jié)點(diǎn)上的Operation log和Checkpoint文件需要通過復(fù)制方式保留多個(gè)副本,來保障元數(shù)據(jù)以及中心管理功能的高可用性。
相對(duì)于GFS來說,我們來看HDFS做了哪些區(qū)別?
- HDFS的默認(rèn)最小存儲(chǔ)單元為128M,比GFS的64M更大。
- HDFS不支持文件并發(fā)寫,對(duì)于單個(gè)文件它僅允許有一個(gè)寫或者追加請(qǐng)求。
- HDFS從2.0版本之后支持兩個(gè)管理節(jié)點(diǎn)(NameNode),主備切換可以做到分鐘級(jí)別。
- HDFS 更適合單次寫多次讀的大文件流式讀取的場(chǎng)景。
- HDFS不支持對(duì)已寫文件的更新操作,僅支持對(duì)它的追加操作。
2.2 GlusterFS
GlusterFS雖然是基于文件系統(tǒng)的分布式存儲(chǔ)技術(shù),但是它與GFS/HDFS有本質(zhì)的區(qū)別,它是去中心化的無中心分布式架構(gòu)(圖2.2);它是通過對(duì)文件全目錄的DHT算法計(jì)算得到相應(yīng)的Brike地址,從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫;它與Ceph/Swift的架構(gòu)區(qū)別在于它沒有集中收集保存集群拓?fù)浣Y(jié)構(gòu)信息的存儲(chǔ)區(qū),因此在做計(jì)算的時(shí)候,需要遍歷整個(gè)卷的Brike信息。
圖2.2 Gluster FS
接下來,我們來看GlusterFS都有哪些具體特性,我們應(yīng)該如何應(yīng)用?
- GlusterFS是采用無中心對(duì)稱式架構(gòu),沒有專用的元數(shù)據(jù)服務(wù)器,也就不存在元數(shù)據(jù)服務(wù)器瓶頸。元數(shù)據(jù)存在于文件的屬性和擴(kuò)展屬性中 。
- GlusterFS可以提供Raid0、Raid1、Raid1+0等多種類型存儲(chǔ)卷類型。
- GlusterFS采用數(shù)據(jù)最終一致性算法,只要有一個(gè)副本寫完就可以Commit。
- GlusterFS默認(rèn)會(huì)將文件切分為128KB的切片,然后分布于卷對(duì)應(yīng)的所有Brike當(dāng)中。所以從其設(shè)計(jì)初衷來看,更適合大文件并發(fā)的場(chǎng)景。
- GlusterFS 采用的DHT算法不具備良好的穩(wěn)定性,一旦存儲(chǔ)節(jié)點(diǎn)發(fā)生增減變化,勢(shì)必影響卷下面所有Brike的數(shù)據(jù)進(jìn)行再平衡操作,開銷比較大。
- Gluster FS文件 目錄利用擴(kuò)展屬性記錄子卷的中brick的hash分布范圍,每個(gè)brick的范圍均不重疊。遍歷目錄時(shí),需要獲取每個(gè)文件的屬性和擴(kuò)展屬性進(jìn)行聚合,當(dāng)目錄文件 較多 時(shí),遍歷 效率很差 。
2.3 Ceph & Swift
我們知道, 相對(duì)于文件系統(tǒng)的中心架構(gòu)分布式存儲(chǔ)技術(shù),Ceph&Swift都是去中心化的無中心分布式架構(gòu)(圖2.3);他們底層都是對(duì)象存儲(chǔ)技術(shù);他們都是通過對(duì)對(duì)象的哈希算法得到相應(yīng)的Bucket&Node地址,從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫 。
圖2.3 去中心化的分布式存儲(chǔ)架構(gòu)
接下來,我們來看Ceph和Swift都有哪些具體特性,我們應(yīng)該如何應(yīng)用?
- Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲(chǔ)平臺(tái),上層應(yīng)用支持Object、Block、File 。
- Ceph采用Crush算法完成數(shù)據(jù)分布計(jì)算,通過Tree的邏輯對(duì)象數(shù)據(jù)結(jié)構(gòu)自然實(shí)現(xiàn)故障隔離副本位置計(jì)算,通過將Bucket內(nèi)節(jié)點(diǎn)的組織結(jié)構(gòu),集群結(jié)構(gòu)變化導(dǎo)致的數(shù)據(jù)遷移量最小。
- Ceph保持?jǐn)?shù)據(jù)強(qiáng)一致性算法,數(shù)據(jù)的所有副本都寫入并返回才算寫事務(wù)的完成,寫的效率會(huì)差一些,所以更適合寫少讀多的場(chǎng)景。
- 對(duì)象保存的最小單元為4M,相比GFS&HDFS而言,適合一些小的非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。
雖然底層都是對(duì)象存儲(chǔ),相對(duì)于Ceph來說,Swift又有哪些獨(dú)特的特性呢?
- Swift只保障數(shù)據(jù)的最終一致性,寫完2個(gè)副本后即可Commit,這就導(dǎo)致讀操作需要進(jìn)行副本的對(duì)比校驗(yàn),讀的效率相對(duì)較低。
- Swift采用一致性哈希算法完成數(shù)據(jù)分布計(jì)算,通過首次計(jì)算對(duì)象針對(duì)邏輯對(duì)象(Zone)的映射實(shí)現(xiàn)數(shù)據(jù)副本的故障隔離分布,然后通過哈希一致性算法完成對(duì)象在Bucket當(dāng)中的分布計(jì)算,采用Ring環(huán)結(jié)構(gòu)組織Bucket節(jié)點(diǎn)組織,數(shù)據(jù)分布不如Ceph均勻。
- Swift 需要借助Proxy節(jié)點(diǎn)完成對(duì)數(shù)據(jù)的訪問,不同于通過客戶端直接訪問數(shù)據(jù)節(jié)點(diǎn),相對(duì)數(shù)據(jù)的訪問效率來講,比Ceph要差一些。
總結(jié)來看,由于Swift需要通過Proxy節(jié)點(diǎn)完成與數(shù)據(jù)節(jié)點(diǎn)的交互,雖然Proxy節(jié)點(diǎn)可以負(fù)載均衡,但是畢竟經(jīng)歷了中間層,在并發(fā)量較大而且小文件操作量比較的場(chǎng)景下,Ceph的性能表現(xiàn)會(huì)優(yōu)秀一些。 為了說明我們從原理層面的判斷,接下來借助ICCLAB&SPLAB的性能測(cè)試結(jié)果來說明。
表1 Ceph集群配置
[Node1 - MON] | [Node2 - OSD] | [Node2 - OSD] |
---|---|---|
[HDD1: OS] | [HDD1: OS] | [HDD1: OS] |
[HDD2: not used] | [HDD2: osd.0 - xfs] | [HDD2: osd.2 - xfs] |
[HDD3: not used] | [HDD3: osd.1 - xfs] | [HDD3: osd.3 - xfs] |
[HDD4: not used] | [HDD4: journal] | [HDD4: journal] |
表2 Swift集群配置
[Node1 - Proxy] | [Node2 - Storage] | [Node2 - Storage] |
---|---|---|
[HDD1: OS] | [HDD1: OS] | [HDD1: OS] |
[HDD2: not used] | [HDD2: dev1 - xfs] | [HDD2: dev3 - xfs] |
[HDD3: not used] | [HDD3: dev2 - xfs] | [HDD3: dev4 - xfs] |
[HDD4: not used] | [HDD4: not used] | [HDD4: not used] |
以上是測(cè)試本身對(duì)于Ceph和Swift的節(jié)點(diǎn)及物理對(duì)象配置信息,從表的對(duì)比,基本可以看出物理硬件配置都是相同的,只不過在Swift的配置當(dāng)中還需要配置Container相關(guān)邏輯對(duì)象。
{x}count{y}kb,x表示Swift集群當(dāng)中設(shè)置的Container數(shù)量,y表示進(jìn)行壓力測(cè)試所用的數(shù)據(jù)大小。從圖中表現(xiàn)出來的性能趨勢(shì)分析:
- Container的數(shù)量越多,Swift的讀寫性能會(huì)相對(duì)差一些;
- 在4K-128K數(shù)據(jù)大小的范圍內(nèi),Ceph和Swift的讀性能表現(xiàn)都是最佳的;
- 在4K-64K數(shù)據(jù)大小范圍內(nèi),Ceph的讀性能幾乎是Swift的2-3倍,但是寫的性能相差不是非常大。
Ceph_{x}Swift{x},x表示并發(fā)數(shù)量。從圖中表現(xiàn)出來的性能趨勢(shì)分析:
- 對(duì)于并發(fā)讀操作,Ceph的表現(xiàn)上明顯優(yōu)于Swift,無論是穩(wěn)定性還是IOPS指標(biāo);
- 對(duì)于并發(fā)寫操作,Ceph的并發(fā)量越高其性能表現(xiàn)越接近Swift,并發(fā)量越少其性能表現(xiàn)會(huì)明顯遜色于Swift。
- 對(duì)于并發(fā)讀寫操作的性能穩(wěn)定性上,Ceph遠(yuǎn)勝于Swift。
3 結(jié)語
通過對(duì)主流分布式存儲(chǔ)技術(shù)的各項(xiàng)特性分析梳理之后,我們基本上可以得出以下若干結(jié)論:
- GFS/HDFS還是適合特定大文件應(yīng)用的分布式文件存儲(chǔ)系統(tǒng)(搜索、大數(shù)據(jù)...);
- GlusterFS是可以代替NAS的通用分布式文件系統(tǒng)存儲(chǔ)技術(shù),可配置性較強(qiáng);
- Ceph是平衡各個(gè)維度之后相對(duì)比較寬容的統(tǒng)一分布式存儲(chǔ)技術(shù);
- 分布式存儲(chǔ)技術(shù)終究不適合應(yīng)用到熱點(diǎn)比較集中的關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)卷場(chǎng)景上。
-
分布式存儲(chǔ)
+關(guān)注
關(guān)注
4文章
166瀏覽量
19480 -
HDFS
+關(guān)注
關(guān)注
1文章
30瀏覽量
9546 -
GFS
+關(guān)注
關(guān)注
0文章
5瀏覽量
2143
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論