分布式存儲最早是由谷歌提出的，其目的是通過廉價的服務(wù)器來提供使用與大規(guī)模，高并發(fā)場景下的Web訪問問題。它采用可擴(kuò)展的系統(tǒng)結(jié)構(gòu)，利用多臺存儲服務(wù)器分擔(dān)存儲負(fù)荷，利用位置服務(wù)器定位存儲信息，它不但提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴(kuò)展。

1、分布式存儲的興起

分布式存儲的興起與互聯(lián)網(wǎng)的發(fā)展密不可分，互聯(lián)網(wǎng)公司由于其數(shù)據(jù)量大而資本積累少，而通常都使用大規(guī)模分布式存儲系統(tǒng)。

與傳統(tǒng)的高端服務(wù)器、高端存儲器和高端處理器不同的是，互聯(lián)網(wǎng)公司的分布式存儲系統(tǒng)由數(shù)量眾多的、低成本和高性價比的普通PC服務(wù)器通過網(wǎng)絡(luò)連接而成。其主要原因有以下三點(diǎn)

（1）互聯(lián)網(wǎng)的業(yè)務(wù)發(fā)展很快，而且注意成本消耗，這就使得存儲系統(tǒng)不能依靠傳統(tǒng)的縱向擴(kuò)展的方式，即先買小型機(jī)，不夠時再買中型機(jī)，甚至大型機(jī)。互聯(lián)網(wǎng)后端的分布式系統(tǒng)要求支持橫向擴(kuò)展，即通過增加普通PC服務(wù)器來提高系統(tǒng)的整體處理能力。

（2）普通PC服務(wù)器性價比高，故障率也高，需要在軟件層面實(shí)現(xiàn)自動容錯，保證數(shù)據(jù)的一致性。

（3）另外，隨著服務(wù)器的不斷加入，需要能夠在軟件層面實(shí)現(xiàn)自動負(fù)載均衡，使得系統(tǒng)的處理能力得到線性擴(kuò)展。

2、分布式存儲的重要性

從單機(jī)單用戶到單機(jī)多用戶，再到現(xiàn)在的網(wǎng)絡(luò)時代，應(yīng)用系統(tǒng)發(fā)生了很多的變化。而分布式系統(tǒng)依然是目前很熱門的討論話題，那么，分布式系統(tǒng)給我們帶來了什么，或者說是為什么要有分布式系統(tǒng)呢？

（1）升級單機(jī)處理能力的性價比越來越低；

企業(yè)發(fā)現(xiàn)通過更換硬件做垂直擴(kuò)展的方式來提升性能會越來越不劃算；

（2）單機(jī)處理能力存在瓶頸；

某個固定時間點(diǎn)，單顆處理器有自己的性能瓶頸，也就說即使愿意花更多的錢去買計算能力也買不到了；

（3）出于穩(wěn)定性和可用性的考慮

如果采用單擊系統(tǒng)，那么在這臺機(jī)器正常的時候一切OK，一旦出問題，那么系統(tǒng)就完全不能用了。當(dāng)然，可以考慮做容災(zāi)備份等方案，而這些方案就會讓系統(tǒng)演變?yōu)榉植际较到y(tǒng)了；

（4）云存儲和大數(shù)據(jù)發(fā)展的必然要求

云存儲和大數(shù)據(jù)是構(gòu)建在分布式存儲之上的應(yīng)用。移動終端的計算能力和存儲空間有限，而且有在多個設(shè)備之間共享資源的強(qiáng)烈的需求，這就使得網(wǎng)盤、相冊等云存儲應(yīng)用很快流行起來。然而，萬變不離其宗，云存儲的核心還是后端的大規(guī)模分布式存儲系統(tǒng)。大數(shù)據(jù)則更近一步，不僅需要存儲海量數(shù)據(jù)，還需要通過合適的計算框架或者工具對這些數(shù)據(jù)進(jìn)行分析，抽取其中有價值的部分。如果沒有分布式存儲，便談不上對大數(shù)據(jù)進(jìn)行分析。仔細(xì)分析還會發(fā)現(xiàn)，分布式存儲技術(shù)是互聯(lián)網(wǎng)后端架構(gòu)的神器，掌握了這項技能，以后理解其他技術(shù)的本質(zhì)會變得非常容易。

3、分布式存儲的種類和比較

分布式存儲包含的種類繁多，除了傳統(tǒng)意義上的分布式文件系統(tǒng)、分布式塊存儲和分布式對象存儲外，還包括分布式數(shù)據(jù)庫和分布式緩存等，但其中架構(gòu)無外乎于三種

A、中間控制節(jié)點(diǎn)架構(gòu)

以HDFS（HadoopDistributionFileSystem）為代表的架構(gòu)是典型的代表。在這種架構(gòu)中，一部分節(jié)點(diǎn)NameNode是存放管理數(shù)據(jù)（元數(shù)據(jù)），另一部分節(jié)點(diǎn)DataNode存放業(yè)務(wù)數(shù)據(jù)，這種類型的服務(wù)器負(fù)責(zé)管理具體數(shù)據(jù)。這種架構(gòu)就像公司的層次組織架構(gòu)，namenode就如同老板，只管理下屬的經(jīng)理（datanode），而下屬的經(jīng)理，而經(jīng)理們來管理節(jié)點(diǎn)下本地盤上的數(shù)據(jù)。

在上圖中，如果客戶端需要從某個文件讀取數(shù)據(jù)，首先從NameNode獲取該文件的位置（具體在哪個DataNode），然后從該NameNode獲取具體的數(shù)據(jù)。在該架構(gòu)中NameNode通常是主備部署（SecondaryNameNode），而DataNode則是由大量節(jié)點(diǎn)構(gòu)成一個集群。由于元數(shù)據(jù)的訪問頻度和訪問量相對數(shù)據(jù)都要小很多，因此NameNode通常不會成為性能瓶頸，而DataNode集群中的數(shù)據(jù)可以有副本，既可以保證高可用性，可以分散客戶端的請求。因此，通過這種分布式存儲架構(gòu)可以通過橫向擴(kuò)展datanode的數(shù)量來增加承載能力，也即實(shí)現(xiàn)了動態(tài)橫向擴(kuò)展的能力。

B、完全無中心架構(gòu)–計算模式

以Ceph為代表的架構(gòu)是其典型的代表。在該架構(gòu)中與HDFS不同的地方在于該架構(gòu)中沒有中心節(jié)點(diǎn)。客戶端是通過一個設(shè)備映射關(guān)系計算出來其寫入數(shù)據(jù)的位置，這樣客戶端可以直接與存儲節(jié)點(diǎn)通信，從而避免中心節(jié)點(diǎn)的性能瓶頸。

如上圖所示，在Ceph存儲系統(tǒng)架構(gòu)中核心組件有MON服務(wù)、OSD服務(wù)和MDS服務(wù)等。

（1）MON服務(wù)用于維護(hù)存儲系統(tǒng)的硬件邏輯關(guān)系，主要是服務(wù)器和硬盤等在線信息。MON服務(wù)通過集群的方式保證其服務(wù)的可用性。

（2）OSD服務(wù)用于實(shí)現(xiàn)對磁盤的管理，實(shí)現(xiàn)真正的數(shù)據(jù)讀寫，通常一個磁盤對應(yīng)一個OSD服務(wù)。

（3）MDS只為CephFS文件存儲系統(tǒng)跟蹤文件的層次機(jī)構(gòu)和存儲元數(shù)據(jù)。Ceph塊設(shè)備和RADOS并不需要元數(shù)據(jù)，因此也不需要CephMDS守護(hù)進(jìn)程

（4）RADOS：RADOS就是包含上述三種服務(wù)的ceph存儲集群。在Ceph中所有的數(shù)據(jù)都以對象形式存在的，并且無論哪種數(shù)據(jù)類型RADOS對象存儲都將負(fù)責(zé)保存這些對象。RADOS層可以確保數(shù)據(jù)始終保持一致性。要做到這一點(diǎn)必須執(zhí)行數(shù)據(jù)復(fù)制、故障檢測和恢復(fù)，以及數(shù)據(jù)遷移和所在集群節(jié)點(diǎn)實(shí)現(xiàn)在平衡

（5）RBD（塊設(shè)備）：原名RADOS塊設(shè)備，提供可靠的分布式和高性能塊存儲磁盤給客戶端。

（6）CephFS：Ceph文件系統(tǒng)提供了一個使用Ceph存儲集群存儲用戶數(shù)據(jù)的與POSIX兼容的文件系統(tǒng)

（7）Librados：libRADOS庫為PHP、RUBY、Java、Python、C++等語言提供了方便的訪問RADOS接口的方式

（8）RADOSGW：RGW提供對象存儲服務(wù)，它允許應(yīng)用程序和Ceph對象存儲建立連接，RGW提供了與AmazonS3和openstackSwift兼容的RUSTFULAPI

客戶端訪問存儲的大致流程是，客戶端在啟動后會首先通過RADOSGW進(jìn)入，從MON服務(wù)拉取存儲資源布局信息，然后根據(jù)該布局信息和寫入數(shù)據(jù)的名稱等信息計算出期望數(shù)據(jù)的位置（包含具體的物理服務(wù)器信息和磁盤信息），然后和該位置信息對應(yīng)的CephFS對應(yīng)的位置直接通信，讀取或者寫入數(shù)據(jù)

C、完全無中心架構(gòu)–一致性哈希

以swift為代表的架構(gòu)是其典型的代表。與Ceph的通過計算方式獲得數(shù)據(jù)位置的方式不同，另外一種方式是通過一致性哈希的方式獲得數(shù)據(jù)位置。一致性哈希的方式就是將設(shè)備做成一個哈希環(huán)，然后根據(jù)數(shù)據(jù)名稱計算出的哈希值映射到哈希環(huán)的某個位置，從而實(shí)現(xiàn)數(shù)據(jù)的定位。

Swift中存在兩種映射關(guān)系，對于一個文件，通過哈希算法（MD5）找到對應(yīng)的虛節(jié)點(diǎn)（一對一的映射關(guān)系），虛節(jié)點(diǎn)再通過映射關(guān)系（ring文件中二維數(shù)組）找到對應(yīng)的設(shè)備（多對多的映射關(guān)系），這樣就完成了一個文件存儲在設(shè)備上的映射。

D、分布式存儲的比較

那么現(xiàn)在問題來了，如果我們要選擇分布式存儲，選擇哪種好呢？其實(shí)它們各有各的優(yōu)勢和使用場景，具體要看需求。

（1）HDFS

主要用于大數(shù)據(jù)的存儲場景，是Hadoop大數(shù)據(jù)架構(gòu)中的存儲組件。HDFS在開始設(shè)計的時候，就已經(jīng)明確的它的應(yīng)用場景，就是大數(shù)據(jù)服務(wù)。主要的應(yīng)用場景有：

a、對大文件存儲的性能比較高，例如幾百兆，幾個G的大文件。因為HDFS采用的是以元數(shù)據(jù)的方式進(jìn)行文件管理，而元數(shù)據(jù)的相關(guān)目錄和塊等信息保存在NameNode的內(nèi)存中，文件數(shù)量的增加會占用大量的NameNode內(nèi)存。如果存在大量的小文件，會占用大量內(nèi)存空間，引起整個分布式存儲性能下降，所以盡量使用HDFS存儲大文件比較合適。

b、適合低寫入，多次讀取的業(yè)務(wù)。就大數(shù)據(jù)分析業(yè)務(wù)而言，其處理模式就是一次寫入、多次讀取，然后進(jìn)行數(shù)據(jù)分析工作，HDFS的數(shù)據(jù)傳輸吞吐量比較高，但是數(shù)據(jù)讀取延時比較差，不適合頻繁的數(shù)據(jù)寫入。

c、HDFS采用多副本數(shù)據(jù)保護(hù)機(jī)制，使用普通的X86服務(wù)器就可以保障數(shù)據(jù)的可靠性，不推薦在虛擬化環(huán)境中使用。

（2）Ceph

目前應(yīng)用最廣泛的開源分布式存儲系統(tǒng)，已得到眾多廠商的支持，許多超融合系統(tǒng)的分布式存儲都是基于Ceph深度定制。而且Ceph已經(jīng)成為LINUX系統(tǒng)和OpenStack的“標(biāo)配”，用于支持各自的存儲系統(tǒng)。Ceph可以提供對象存儲、塊設(shè)備存儲和文件系統(tǒng)存儲服務(wù)。同時支持三種不同類型的存儲服務(wù)的特性，在分布式存儲系統(tǒng)中，是很少見的。

a、Ceph沒有采用HDFS的元數(shù)據(jù)尋址的方案，而且采用CRUSH算法，數(shù)據(jù)分布均衡，并行度高。而且在支持塊存儲特性上，數(shù)據(jù)可以具有強(qiáng)一致性，可以獲得傳統(tǒng)集中式存儲的使用體驗。

b、對象存儲服務(wù)，Ceph支持Swift和S3的API接口。在塊存儲方面，支持精簡配置、快照、克隆。在文件系統(tǒng)存儲服務(wù)方面，支持Posix接口，支持快照。但是目前Ceph支持文件的性能相當(dāng)其他分布式存儲系統(tǒng)，部署稍顯復(fù)雜，性能也稍弱，一般都將Ceph應(yīng)用于塊和對象存儲。

c、Ceph是去中心化的分布式解決方案，需要提前做好規(guī)劃設(shè)計，對技術(shù)團(tuán)隊的要求能力比較高。特別是在Ceph擴(kuò)容時，由于其數(shù)據(jù)分布均衡的特性，會導(dǎo)致整個存儲系統(tǒng)性能的下降

（3）Swift

主要面向的是對象存儲。和Ceph提供的對象存儲服務(wù)類似。主要用于解決非結(jié)構(gòu)化數(shù)據(jù)存儲問題。它和Ceph的對象存儲服務(wù)的主要區(qū)別是。

a、客戶端在訪問對象存儲系統(tǒng)服務(wù)時，Swift要求客戶端必須訪問Swift網(wǎng)關(guān)才能獲得數(shù)據(jù)。而Ceph使用一個運(yùn)行在每個存儲節(jié)點(diǎn)上的OSD（對象存儲設(shè)備）獲取數(shù)據(jù)信息，沒有一個單獨(dú)的入口點(diǎn)，比Swift更靈活一些。

b、數(shù)據(jù)一致性方面，Swift的數(shù)據(jù)是最終一致，在海量數(shù)據(jù)的處理效率上要高一些，但是主要面向?qū)?shù)據(jù)一致性要求不高，但是對數(shù)據(jù)處理效率要求比較高的對象存儲業(yè)務(wù)。而Ceph是始終跨集群強(qiáng)一致性。主要的應(yīng)用場景，在OpenStack中，對象存儲服務(wù)使用的就是Swift，而不是Ceph。
責(zé)任編輯人：CC