主流分佈式存儲技術的對比分析與應用

摘 要：

隨着數字化轉型的深入，海量數據對存儲提出了新的要求。傳統存儲雖然有技術成熟、性能良好、可用性高等優點，但面對海量數據，其缺點也越來越明顯：如擴展性差、成本高等。爲了克服上述缺點，滿足海量數據的存儲需求，市場上出現了分佈式存儲技術。

分佈式存儲系統，通常包括主控服務器、存儲服務器，以及多個客戶端組成。其本質是將大量的文件，均勻分佈到多個存儲服務器上。

當前，分佈式存儲有多種實現技術，如HDFS、Ceph、GFS、Switf等。在實際工作中，爲了更好地引入分佈式存儲技術，我們需瞭解各種分佈式存儲技術的特點，以及各種技術的適用場景。

本文擬通過對Ceph、HDFS、Swift、GFS、Luster等幾種主流的分佈式存儲技術實現原理的闡述，並總結其各自的特點和合適的使用場景，以幫助架構師在進行存儲架構規劃時，選擇合適的存儲技術。

關鍵詞：傳統存儲技術 分佈式存儲技術 塊存儲 文件存儲 對象存儲 Ceph GFS HDFS Swift Luster

存儲根據其類型，可分爲塊存儲，對象存儲和文件存儲。在主流的分佈式存儲技術中，HDFS/GPFS/GFS屬於文件存儲，Swift屬於對象存儲，而Ceph可支持塊存儲、對象存儲和文件存儲，故稱爲統一存儲。

一、 Ceph

Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表，並隨後貢獻給開源社區。經過多年的發展之後，已得到衆多雲計算和存儲廠商的支持，成爲應用最廣泛的開源分佈式存儲平臺。
Ceph根據場景可分爲對象存儲、塊設備存儲和文件存儲。Ceph相比其它分佈式存儲技術，其優勢點在於：它不單是存儲，同時還充分利用了存儲節點上的計算能力，在存儲每一個數據時，都會通過計算得出該數據存儲的位置，儘量將數據分佈均衡。同時，由於採用了CRUSH、HASH等算法，使得它不存在傳統的單點故障，且隨着規模的擴大，性能並不會受到影響。
1.Ceph的主要架構

Ceph的最底層是RADOS（分佈式對象存儲系統），它具有可靠、智能、分佈式等特性，實現高可靠、高可拓展、高性能、高自動化等功能，並最終存儲用戶數據。RADOS系統主要由兩部分組成，分別是OSD和Monitor。
RADOS之上是LIBRADOS，LIBRADOS是一個庫，它允許應用程序通過訪問該庫來與RADOS系統進行交互，支持多種編程語言，比如C、C++、Python等。
基於LIBRADOS層開發的有三種接口，分別是RADOSGW、librbd和MDS。
RADOSGW是一套基於當前流行的RESTFUL協議的網關，支持對象存儲，兼容S3和Swift。
librbd提供分佈式的塊存儲設備接口，支持塊存儲。
MDS提供兼容POSIX的文件系統，支持文件存儲。

2.Ceph的功能模塊

Ceph的核心組件包括Client客戶端、MON監控服務、MDS元數據服務、OSD存儲服務，各組件功能如下：
 Client客戶端：負責存儲協議的接入，節點負載均衡
 MON監控服務：負責監控整個集羣，維護集羣的健康狀態，維護展示集羣狀態的各種圖表，如OSD Map、Monitor Map、PG Map和CRUSH Map
 MDS元數據服務：負責保存文件系統的元數據，管理目錄結構
 OSD存儲服務：主要功能是存儲數據、複製數據、平衡數據、恢復數據，以及與其它OSD間進行心跳檢查等。一般情況下一塊硬盤對應一個OSD。

3.Ceph的資源劃分
Ceph採用crush算法，在大規模集羣下，實現數據的快速、準確存放，同時能夠在硬件故障或擴展硬件設備時，做到儘可能小的數據遷移，其原理如下：
當用戶要將數據存儲到Ceph集羣時，數據先被分割成多個object，(每個object一個object id，大小可設置，默認是4MB），object是Ceph存儲的最小存儲單元。
由於object的數量很多，爲了有效減少了Object到OSD的索引表、降低元數據的複雜度，使得寫入和讀取更加靈活，引入了pg(Placement Group )：PG用來管理object，每個object通過Hash，映射到某個pg中，一個pg可以包含多個object。
Pg再通過CRUSH計算，映射到osd中。如果是三副本的，則每個pg都會映射到三個osd，保證了數據的冗餘。

4.Ceph的數據寫入
Ceph數據的寫入流程

1. 數據通過負載均衡獲得節點動態IP地址；
2. 通過塊、文件、對象協議將文件傳輸到節點上；
3. 數據被分割成4M對象並取得對象ID；
4. 對象ID通過HASH算法被分配到不同的PG；
5. 不同的PG通過CRUSH算法被分配到不同的OSD
   
   5.Ceph的特點
    Ceph支持對象存儲、塊存儲和文件存儲服務，故 稱爲統一存儲。
    採用CRUSH算法，數據分佈均衡，並行度高，不需要維護固定的元數據結構；
    數據具有強一致，確保所有副本寫入完成才返回確認，適合讀多寫少場景；
    去中心化，MDS之間地位相同，無固定的中心節點
   Ceph存在一些缺點：
    去中心化的分佈式解決方案，需要提前做好規劃設計，對技術團隊的要求能力比較高。
    Ceph擴容時，由於其數據分佈均衡的特性，會導致整個存儲系統性能的下降。

二、 GFS

GFS是google的分佈式文件存儲系統，是專爲存儲海量搜索數據而設計的，2003年提出，是閉源的分佈式文件系統。適用於大量的順序讀取和順序追加，如大文件的讀寫。注重大文件的持續穩定帶寬，而不是單次讀寫的延遲。

1.GFS的主要架構
GFS 架構比較簡單，一個 GFS 集羣一般由一個 master 、多個 chunkserver 和多個 clients 組成。
在 GFS 中，所有文件被切分成若干個 chunk，每個 chunk 擁有唯一不變的標識（在 chunk 創建時，由 master 負責分配），所有 chunk 都實際存儲在 chunkserver 的磁盤上。
爲了容災，每個 chunk 都會被複制到多個 chunkserve

2.GFS的功能模塊

 GFS client客戶端：爲應用提供API，與POSIX API類似。同時緩存從GFS master讀取的元數據chunk信息；
 GFS master元數據服務器：管理所有文件系統的元數據，包括命令空間（目錄層級）、訪問控制信息、文件到chunk的映射關係，chunk的位置等。同時 master 還管理系統範圍內的各種活動，包括chunk 創建、複製、數據遷移、垃圾回收等；
 GFS chunksever存儲節點：用於所有 chunk的存儲。一個文件被分割爲多個大小固定的chunk（默認64M），每個chunk有全局唯一的chunk ID。

3.GFS的寫入流程

1. Client 向 master 詢問要修改的 chunk在哪個 chunkserver上，以及 該chunk 其他副本的位置信息。
2. Master 將Primary、secondary的相關信息返回給 client。
3. Client 將數據推送給 primary 和 secondary；。
4. 當所有副本都確認收到數據後，client 發送寫請求給 primary，primary 給不同 client 的操作分配序號，保證操作順序執行。
5. Primary 把寫請求發送到 secondary，secondary 按照 primary 分配的序號順序執行所有操作
6. 當 Secondary 執行完後回覆 primary 執行結果。
7. Primary 回覆 client 執行結果。
   
   由上述可見，GFS在進行寫數據時，有如下特點：
    GFS在數據讀寫時，數據流與控制流是分開的，並通過租約機制，在跨多個副本的數據寫入中, 保障順序一致性;
    Master將chunk租約發放給其中一個副本，這個副本稱爲主副本，由主副本確定chunk的寫入順序，次副本則遵守這個順序，這樣就保障了全局順序一致性
    Master返回客戶端主副本和次副本的位置信息，客戶端緩存這些信息以備將來使用，只有當主副本所在chunkserver不可用或返回租約過期了，客戶端才需要再次聯繫Master；
    GFS採用鏈式推送，以最大化利用每個機器的網絡帶寬，避免網絡瓶頸和高延遲連接，最小化推送延遲；
    GFS使用TCP流式傳輸數據，以最小化延遲。

4.GFS特點
 適合大文件場景的應用，特別是針對GB級別的大文件，適用於數據訪問延時不敏感的搜索類業務
 中心化架構，只有1個master處於active狀態
 緩存和預取，通過在client端緩存元數據，儘量減少與master的交互，通過文件的預讀取來提升併發性能
 高可靠性，master需要持久化的數據會通過操作日誌與checkpoint的方式存放多份，故障後master會自動切換重啓。

三、 HDFS

HDFS（Hadoop Distributed File System），是一個適合運行在通用硬件(commodity hardware)上的分佈式文件系統，是Hadoop的核心子項目，是基於流數據模式訪問和處理超大文件的需求而開發的。該系統仿效了谷歌文件系統(GFS)，是GFS的一個簡化和開源版本。

1.HDFS的主要架構

 HDFS Client（客戶端）：從NameNode獲取文件的位置信息，再從DataNode讀取或者寫入數據。此外，client在數據存儲時，負責文件的分割；
 NameNode（元數據節點）：管理名稱空間、數據塊（Block）映射信息、配置副本策略、處理客戶端讀寫請求；
 DataNode（存儲節點）：負責執行實際的讀寫操作，存儲實際的數據塊,同一個數據塊會被存儲在多個DataNode上
 Secondary NameNode：定期合併元數據，推送給NameNode，在緊急情況下，可輔助NameNode的HA恢復。

2.HDFS的特點（Vs GFS）
 分塊更大，每個數據塊默認128MB；
 不支持併發，同一時刻只允許一個寫入者或追加者;
 過程一致性,寫入數據的傳輸順序與最終寫入順序一致;
 Master HA，2.X版本支持兩個NameNode，（分別處於Active和Standby狀態），故障切換時間一般幾十秒到數分鐘

3.HDFS適合的應用場景：
 適用於大文件、大數據處理，處理數據達到 GB、TB、甚至PB級別的數據。
 適合流式文件訪問，一次寫入，多次讀取。
 文件一旦寫入不能修改，只能追加。

4.HDFS不適合的場景：
 低延時數據訪問。
 小文件存儲
 併發寫入、文件隨機修改

四、 Swift

Swift 最初是由Rackspace公司開發的分佈式對象存儲服務， 2010 年貢獻給 OpenStack 開源社區。作爲其最初的核心子項目之一，爲其 Nova 子項目提供虛機鏡像存儲服務。

1.Swift的主要架構
Swift 採用完全對稱、面向資源的分佈式系統架構設計，所有組件都可擴展，避免因單點失效而影響整個系統的可用性。

Swift 組件包括：
 代理服務（Proxy Server）：對外提供對象服務 API，轉發請求至相應的賬戶、容器或對象服務
 認證服務（Authentication Server）：驗證用戶的身份信息，並獲得一個訪問令牌（Token）
 緩存服務（Cache Server）：緩存令牌，賬戶和容器信息，但不會緩存對象本身的數據
 賬戶服務（Account Server）：提供賬戶元數據和統計信息，並維護所含容器列表的服務
 容器服務（Container Server）：提供容器元數據和統計信息，並維護所含對象列表的服務
 對象服務（Object Server）：提供對象元數據和內容服務，每個對象會以文件存儲在文件系統中
 複製服務（Replicator）：檢測本地副本和遠程副本是否一致，採用推式（Push）更新遠程副本
 更新服務（Updater）：對象內容的更新
 審計服務（Auditor）：檢查對象、容器和賬戶的完整性，如果發現錯誤，文件將被隔離
 賬戶清理服務（Account Reaper）：移除被標記爲刪除的賬戶，刪除其所包含的所有容器和對象

2.Swift的數據模型
**Swift的數據模型採用層次結構，共設三層：**Account/Container/Object（即賬戶/容器/對象)，每層節點數均沒有限制，可以任意擴展。數據模型如下：

3.一致性散列函數
Swift是基於一致性散列技術，通過計算將對象均勻分佈到虛擬空間的虛擬節點上，在增加或刪除節點時可大大減少需移動的數據量；
爲便於高效的移位操作，虛擬空間大小通常採用 2 n；通過獨特的數據結構 Ring（環），再將虛擬節點映射到實際的物理存儲設備上，完成尋址過程。如下圖所示：

散列空間4 個字節（32爲），虛擬節點數最大爲232，如將散列結果右移 m 位，可產生 2(32-m)個虛擬節點，（如上圖中所示，當m=29 時，可產生 8 個虛擬節點）。

4.環的數據結構
Swift爲賬戶、容器和對象分別定義了的環。
環是爲了將虛擬節點（分區）映射到一組物理存儲設備上，並提供一定的冗餘度而設計的，環的數據信息包括存儲設備列表和設備信息、分區到設備的映射關係、計算分區號的位移（即上圖中的m）。
賬戶、容器和對象的尋址過程。（以對象的尋址過程爲例）：

1. 以對象的層次結構 account/container/object 作爲鍵，採用 MD5 散列算法得到一個散列值；
2. 對該散列值的前 4 個字節進行右移操作（右移m位），得到分區索引號；
3. 在分區到設備映射表裏，按照分區索引號，查找該對象所在分區對應的所有物理設備編號。如下圖：
   
   5.Swift的一致性設計
   Swift 採用 Quorum 仲裁協議
    定義：N：數據的副本總數；W：寫操作被確認接受的副本數量；R：讀操作的副本數量
    強一致性：R+W>N， 就能保證對副本的讀寫操作會產生交集，從而保證可以讀取到最新版本；
    弱一致性：R+W<=N，讀寫操作的副本集合可能不產生交集，此時就可能會讀到髒數據；
   Swift 默認配置是N=3，W=2，R=2，即每個對象會存在 3 個副本，至少需要更新 2 個副本纔算寫成功；如果讀到的2個數據存在不一致，則通過檢測和複製協議來完成數據同步。
   如R=1，就可能會讀到髒數據，此時，通過犧牲一定的一致性，可提高讀取速度，（而一致性可以通過後臺的方式完成同步，從而保證數據的最終一致性）
   Quorum 協議示例如下所示：
   
   6.Swift特點
    原生的對象存儲，不支持實時的文件讀寫、編輯功能
    完全對稱架構，無主節點，無單點故障，易於大規模擴展，性能容量線性增長
    數據實現最終一致性，不需要所有副本寫入即可返回，讀取數據時需要進行數據副本的校驗
    是OpenStack的子項目之一，適合雲環境的部署
    Swift的對象存儲與Ceph提供的對象存儲區別：客戶端在訪問對象存儲系統服務時，Swift要求客戶端必須訪問Swift網關才能獲得數據。而Ceph可以在每個存儲節點上的OSD（對象存儲設備）獲取數據信息； 在數據一致性方面，Swift的數據是最終一致，而Ceph是始終跨集羣強一致性）

五、 Lustre分佈式存儲

Lustre是基於Linux平臺的開源集羣（並行）文件系統，最早在1999年由皮特•布拉姆創建的集羣文件系統公司（Cluster File Systems Inc.）開始研發，後由HP、Intel、Cluster File System和美國能源部聯合開發，2003年正式開源，主要用於HPC超算領域。

1、Lustre的主要架構

Lustre組件包括：
 管理服務器(MGS)：存放集羣中所有Lustre文件系統的配置信息，Lustre客戶通過聯繫MGS獲取信息，可以與MDS共享存儲空間
 元數據服務器(MDS): 管理存儲在MDT中的元數據，使存儲在一個或多個MDT中的元數據可供Lustre客戶端使用，每個MDS可管理一個或多個MDT。
 元數據目標(MDT): MDS用於存儲元數據(例如文件名，目錄，權限和文件佈局)，一個MDT可用於多個MDS，但一次只能有一個MDS訪問
 對象存儲服務器(OSS)：爲一個或多個本地OST提供文件I / O服務和網絡請求處理, 通常，OSS服務於兩個到八個OST
 對象存儲目標(OST)：用戶文件數據存儲在一個或多個對象中，每個對象位於單獨OST中
 Lustre客戶端：運行Lustre客戶端軟件的計算節點，可掛載Lustre文件系統。客戶端軟件包括一個管理客戶端(MGC)，一個元數據客戶端(MDC)和多個對象存儲客戶端(OSC)。每個OSC對應於文件系統中的一個OST。
 邏輯對象卷(LOV)通過聚合OSC以提供對所有OST的透明訪問，邏輯元數據卷(LMV)通過聚合MDC提供一種對所有MDT透明的訪問。

2、Lustre特點
 支持數萬個客戶端系統，支持PB級存儲容量，單個文件最大支持320TB容量
 支持RDMA網絡，大文件讀寫分片優化，多個OSS能獲得更高的聚合帶寬
 缺少副本機制，存在單點故障。如果一個客戶端或節點發生故障，存儲在該節點上的數據在重新啓動前將不可訪問
 適用高性能計算HPC領域，適用於大文件連續讀寫。

六、 主流分佈式存儲技術的比較

幾種主流分佈式存儲技術的特點比較如下：


此外，根據分佈式存儲系統的設計理念，其軟件和硬件解耦，分佈式存儲的許多功能，包括可靠性和性能增強都由軟件提供，因此大家往往會認爲底層硬件已不再重要。但事實往往並非如此，我們在進行分佈式存儲系統集成時，除考慮選用合適的分佈式存儲技術以外，還需考慮底層硬件的兼容性。一般而言，分佈式存儲系統的產品有三種形態：軟硬件一體機、硬件OEM和軟件+標準硬件，大家在選擇時，需根據產品的成熟度、風險規避、運維要求等，結合自身的技術力量等，選擇合適的產品形態。

參考資料：http://www.talkwithtrend.com/Article/244687