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

1、分布式存儲的興起

分布式存儲的興起與互聯網的發展密不可分，互聯網公司由于其數據量大而資本積累少，而通常都使用大規模分布式存儲系統。

與傳統的高端服務器、高端存儲器和高端處理器不同的是，互聯網公司的分布式存儲系統由數量眾多的、低成本和高性價比的普通PC服務器通過網絡連接而成。其主要原因有以下三點

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

（2）普通PC服務器性價比高，故障率也高，需要在軟件層面實現自動容錯，保證數據的一致性。

（3）另外，隨著服務器的不斷加入，需要能夠在軟件層面實現自動負載均衡，使得系統的處理能力得到線性擴展。

2、分布式存儲的重要性

從單機單用戶到單機多用戶，再到現在的網絡時代，應用系統發生了很多的變化。而分布式系統依然是目前很熱門的討論話題，那么，分布式系統給我們帶來了什么，或者說是為什么要有分布式系統呢？

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

企業發現通過更換硬件做垂直擴展的方式來提升性能會越來越不劃算；

（2）單機處理能力存在瓶頸；

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

（3）出于穩定性和可用性的考慮

如果采用單擊系統，那么在這臺機器正常的時候一切OK，一旦出問題，那么系統就完全不能用了。當然，可以考慮做容災備份等方案，而這些方案就會讓系統演變為分布式系統了；

（4）云存儲和大數據發展的必然要求

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

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

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

A、中間控制節點架構

以HDFS（HadoopDistributionFileSystem）為代表的架構是典型的代表。在這種架構中，一部分節點NameNode是存放管理數據（元數據），另一部分節點DataNode存放業務數據，這種類型的服務器負責管理具體數據。這種架構就像公司的層次組織架構，namenode就如同老板，只管理下屬的經理（datanode），而下屬的經理，而經理們來管理節點下本地盤上的數據。

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

B、完全無中心架構–計算模式

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

如上圖所示，在Ceph存儲系統架構中核心組件有MON服務、OSD服務和MDS服務等。

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

（2）OSD服務用于實現對磁盤的管理，實現真正的數據讀寫，通常一個磁盤對應一個OSD服務。

（3）MDS只為CephFS文件存儲系統跟蹤文件的層次機構和存儲元數據。Ceph塊設備和RADOS并不需要元數據，因此也不需要CephMDS守護進程

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

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

（6）CephFS：Ceph文件系統提供了一個使用Ceph存儲集群存儲用戶數據的與POSIX兼容的文件系統

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

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

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

C、完全無中心架構–一致性哈希

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

Swift中存在兩種映射關系，對于一個文件，通過哈希算法（MD5）找到對應的虛節點（一對一的映射關系），虛節點再通過映射關系（ring文件中二維數組）找到對應的設備（多對多的映射關系），這樣就完成了一個文件存儲在設備上的映射。

D、分布式存儲的比較

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

（1）HDFS

主要用于大數據的存儲場景，是Hadoop大數據架構中的存儲組件。HDFS在開始設計的時候，就已經明確的它的應用場景，就是大數據服務。主要的應用場景有：

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

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

c、HDFS采用多副本數據保護機制，使用普通的X86服務器就可以保障數據的可靠性，不推薦在虛擬化環境中使用。

（2）Ceph

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

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

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

c、Ceph是去中心化的分布式解決方案，需要提前做好規劃設計，對技術團隊的要求能力比較高。特別是在Ceph擴容時，由于其數據分布均衡的特性，會導致整個存儲系統性能的下降

（3）Swift

主要面向的是對象存儲。和Ceph提供的對象存儲服務類似。主要用于解決非結構化數據存儲問題。它和Ceph的對象存儲服務的主要區別是。

a、客戶端在訪問對象存儲系統服務時，Swift要求客戶端必須訪問Swift網關才能獲得數據。而Ceph使用一個運行在每個存儲節點上的OSD（對象存儲設備）獲取數據信息，沒有一個單獨的入口點，比Swift更靈活一些。

b、數據一致性方面，Swift的數據是最終一致，在海量數據的處理效率上要高一些，但是主要面向對數據一致性要求不高，但是對數據處理效率要求比較高的對象存儲業務。而Ceph是始終跨集群強一致性。主要的應用場景，在OpenStack中，對象存儲服務使用的就是Swift，而不是Ceph。
責任編輯人：CC