最新文章歡迎關注筆者公衆號“暢遊雲海”

《重識雲原生系列》專題索引：

分佈式雲存儲知識地圖：

1 分佈式存儲發展簡述

1.1 存儲發展簡史

在瞭解什麼是分佈式存儲之前，我們先來簡單瞭解一下存儲幾十年來的大概歷程。

直連存儲（DAS）：存儲和服務器直連，拓展性、靈活性差。
中心化存儲（SAN、NAS）：設備類型豐富，通過IP/FC網絡互連，具有一定的拓展性，但是受到控制器能力限制，拓展能力有限。同時，設備到了生命週期要進行更換，數據遷移需要耗費大量的時間和精力。
分佈式存儲：基於標準硬件和分佈式架構，將數據分散存儲到多個存儲服務器上，並將這些分散的存儲資源構成一個虛擬的存儲設備，可實現千節點/EB級擴展，同時可以對塊、對象、文件等多種類型存儲統一管理。

直連存儲與中心化存儲也可以統稱爲集中式存儲。

1.1.1 集中式存儲簡述

集中式存儲系統中，整個存儲資源是集中在一個系統中的，但集中式存儲並不是一個單獨的設備，是集中在一套系統當中的多個設備，比如下圖中的 EMC 存儲就需要幾個機櫃來存放。

在這個存儲系統中包含很多組件，除了核心的機頭(控制器)、磁盤陣列( JBOD )和交換機等設備外，還有管理設備等輔助設備。

結構中包含一個機頭，這個是存儲系統中最爲核心的部件。通常在機頭中有包含兩個控制器，互爲備用，避免硬件故障導致整個存儲系統的不可用。機頭中通常包含前端端口和後端端口，前端端口用戶爲服務器提供存儲服務，而後端端口用於擴充存儲系統的容量。通過後端端口機頭可以連接更多的存儲設備，從而形成一個非常大的存儲資源池。

在整個結構中，機頭中是整個存儲系統的核心部件，整個存儲系統的高級功能都在其中實現。控制器中的軟件實現對磁盤的管理，將磁盤抽象化爲存儲資源池，然後劃分爲 LUN 提供給服務器使用。這裏的 LUN 其實就是在服務器上看到的磁盤。當然，一些集中式存儲本身也是文件服務器，可以提供共享文件服務。無論如何，從上面我們可以看出集中式存儲最大的特點是有一個統一的入口，所有數據都要經過這個入口，這個入口就是存儲系統的機頭。這也就是集中式存儲區別於分佈式存儲最顯著的特點。如下圖所示：

1.1.2 分佈式存儲簡述

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

1 、分佈式存儲的興起

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

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

互聯網的業務發展很快，而且注意成本消耗，這就使得存儲系統不能依靠傳統的縱向擴展的方式，即先買小型機，不夠時再買中型機，甚至大型機。互聯網後端的分佈式系統要求支持橫向擴展，即通過增加普通 PC 服務器來提高系統的整體處理能力。
普通 PC 服務器性價比高，故障率也高，需要在軟件層面實現自動容錯，保證數據的一致性。
另外，隨着服務器的不斷加入，需要能夠在軟件層面實現自動負載均衡，使得系統的處理能力得到線性擴展。

2 、分佈式存儲的重要性

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

升級單機處理能力的性價比越來越低，企業發現通過更換硬件做垂直擴展的方式來提升性能會越來越不划算;
單機處理能力存在瓶頸，某個固定時間點，單顆處理器有自己的性能瓶頸，也就說即使願意花更多的錢去買計算能力也買不到了;
出於穩定性和可用性的考慮，如果採用單擊系統，那麼在這臺機器正常的時候一切 OK ，一旦出問題，那麼系統就完全不能用了。當然，可以考慮做容災備份等方案，而這些方案就會讓系統演變爲分佈式系統了;
雲存儲和大數據發展的必然要求，雲存儲和大數據是構建在分佈式存儲之上的應用。移動終端的計算能力和存儲空間有限，而且有在多個設備之間共享資源的強烈的需求，這就使得網盤、相冊等雲存儲應用很快流行起來。然而，萬變不離其宗，雲存儲的核心還是後端的大規模分佈式存儲系統。大數據則更近一步，不僅需要存儲海量數據，還需要通過合適的計算框架或者工具對這些數據進行分析，抽取其中有價值的部分。如果沒有分佈式存儲，便談不上對大數據進行分析。仔細分析還會發現，分佈式存儲技術是互聯網後端架構的神器，掌握了這項技能，以後理解其他技術的本質會變得非常容易。

1.2 分佈式存儲整體架構總述

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

A、中間控制節點架構

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

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

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

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

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

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

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

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

(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) RADOS GW ：RGW 提供對象存儲服務，它允許應用程序和 Ceph 對象存儲建立連接， RGW 提供了與 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API。

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

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

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

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

1.3 雲上分佈式存儲簡述

分佈式存儲架構由三個部分組成：客戶端、元數據服務器和數據服務器。客戶端負責發送讀寫請求，緩存文件元數據和文件數據。元數據服務器負責管理元數據和處理客戶端的請求，是整個系統的核心組件。數據服務器負責存放文件數據，保證數據的可用性和完整性。該架構的好處是性能和容量能夠同時拓展，系統規模具有很強的伸縮性。

分佈式存儲分爲文件存儲、對象存儲和塊存儲，但它們三種存儲方式的基本架構都是大同小異的。即客戶端或應用端、元數據（MDS）服務器和數據節點服務器。客戶端和元數據服務器之間交互是“信令交互”，而客戶端到數據節點是“媒體交互”。元數據服務器或通過數據節點服務器獲取各節點服務器的基本配置情況和狀態信息。

1.3.1 塊存儲

典型設備：磁盤陣列，硬盤

塊存儲主要是將裸磁盤空間整個映射給主機使用的，就是說例如磁盤陣列裏面有5塊硬盤（爲方便說明，假設每個硬盤1G），然後可以通過劃邏輯盤、做Raid、或者LVM（邏輯卷）等種種方式邏輯劃分出N個邏輯的硬盤。（假設劃分完的邏輯盤也是5個，每個也是1G，但是這5個1G的邏輯盤已經於原來的5個物理硬盤意義完全不同了。例如第一個邏輯硬盤A裏面，可能第一個200M是來自物理硬盤1，第二個200M是來自物理硬盤2，所以邏輯硬盤A是由多個物理硬盤邏輯虛構出來的硬盤。）

接着塊存儲會採用映射的方式將這幾個邏輯盤映射給主機，主機上面的操作系統會識別到有5塊硬盤，但是操作系統是區分不出到底是邏輯還是物理的，它一概就認爲只是5塊裸的物理硬盤而已，跟直接拿一塊物理硬盤掛載到操作系統沒有區別的，至少操作系統感知上沒有區別。

此種方式下，操作系統還需要對掛載的裸硬盤進行分區、格式化後，才能使用，與平常主機內置硬盤的方式完全無異。

優點：

這種方式的好處當然是因爲通過了Raid與LVM等手段，對數據提供了保護。
另外也可以將多塊廉價的硬盤組合起來，成爲一個大容量的邏輯盤對外提供服務，提高了容量。
寫入數據的時候，由於是多塊磁盤組合出來的邏輯盤，所以幾塊磁盤可以並行寫入的，提升了讀寫效率。
很多時候塊存儲採用SAN架構組網，傳輸速率以及封裝協議的原因，使得傳輸速度與讀寫速率得到提升。

缺點：

採用SAN架構組網時，需要額外爲主機購買光纖通道卡，還要買光纖交換機，造價成本高。
主機之間的數據無法共享，在服務器不做集羣的情況下，塊存儲裸盤映射給主機，再格式化使用後，對於主機來說相當於本地盤，那麼主機A的本地盤根本不能給主機B去使用，無法共享數據。
不利於不同操作系統主機間的數據共享：另外一個原因是因爲操作系統使用不同的文件系統，格式化完之後，不同文件系統間的數據是共享不了的。例如一臺裝了WIN7/XP，文件系統是FAT32/NTFS，而Linux是EXT4，EXT4是無法識別NTFS的文件系統的。就像一隻NTFS格式的U盤，插進Linux的筆記本，根本無法識別出來。所以不利於文件共享。

1.3.2 文件存儲

典型設備：FTP、NFS服務器

爲了克服上述文件無法共享的問題，所以有了文件存儲。

文件存儲也有軟硬一體化的設備，但是其實普通拿一臺服務器/筆記本，只要裝上合適的操作系統與軟件，就可以架設FTP與NFS服務了，架上該類服務之後的服務器，就是文件存儲的一種了。

主機A可以直接對文件存儲進行文件的上傳下載，與塊存儲不同，主機A是不需要再對文件存儲進行格式化的，因爲文件管理功能已經由文件存儲自己搞定了。

優點：

造價交低：隨便一臺機器就可以了，另外普通以太網就可以，根本不需要專用的SAN網絡，所以造價低。
方便文件共享：例如主機A（WIN7，NTFS文件系統），主機B（Linux，EXT4文件系統），想互拷一部電影，本來不行。加了個主機C（NFS服務器），然後可以先A拷到C，再C拷到B就OK了。

缺點：

讀寫速率低，傳輸速率慢：以太網，上傳下載速度較慢，另外所有讀寫都要1臺服務器裏面的硬盤來承擔，相比起磁盤陣列動不動就幾十上百塊硬盤同時讀寫，速率慢了許多。

1.3.3 對象存儲

典型設備：內置大容量硬盤的分佈式服務器

對象存儲最常用的方案，就是多臺服務器內置大容量硬盤，再裝上對象存儲軟件，然後再額外搞幾臺服務作爲管理節點，安裝上對象存儲管理軟件。管理節點可以管理其他服務器對外提供讀寫訪問功能。

之所以出現了對象存儲這種東西，是爲了克服塊存儲與文件存儲各自的缺點，發揚它倆各自的優點。簡單來說塊存儲讀寫快，不利於共享，文件存儲讀寫慢，利於共享。能否弄一個讀寫快，利於共享的出來呢。於是就有了對象存儲。

首先，一個文件包含了了屬性（術語叫metadata，元數據，例如該文件的大小、修改時間、存儲路徑等）以及內容（以下簡稱數據）。

以往像FAT32這種文件系統，是直接將一份文件的數據與metadata一起存儲的，存儲過程先將文件按照文件系統的最小塊大小來打散（如4M的文件，假設文件系統要求一個塊4K，那麼就將文件打散成爲1000個小塊），再寫進硬盤裏面，過程中沒有區分數據/metadata的。而每個塊最後會告知你下一個要讀取的塊的地址，然後一直這樣順序地按圖索驥，最後完成整份文件的所有塊的讀取。

這種情況下讀寫速率很慢，因爲就算你有100個機械手臂在讀寫，但是由於你只有讀取到第一個塊，才能知道下一個塊在哪裏，其實相當於只能有1個機械手臂在實際工作。

而對象存儲則將元數據獨立了出來，控制節點叫元數據服務器（服務器+對象存儲管理軟件），裏面主要負責存儲對象的屬性（主要是對象的數據被打散存放到了那幾臺分佈式服務器中的信息），而其他負責存儲數據的分佈式服務器叫做OSD，主要負責存儲文件的數據部分。當用戶訪問對象，會先訪問元數據服務器，元數據服務器只負責反饋對象存儲在哪些OSD，假設反饋文件A存儲在B、C、D三臺OSD，那麼用戶就會再次直接訪問3臺OSD服務器去讀取數據。

這時候由於是3臺OSD同時對外傳輸數據，所以傳輸的速度就加快了。當OSD服務器數量越多，這種讀寫速度的提升就越大，通過此種方式，實現了讀寫快的目的。

另一方面，對象存儲軟件是有專門的文件系統的，所以OSD對外又相當於文件服務器，那麼就不存在文件共享方面的困難了，也解決了文件共享方面的問題。

所以對象存儲的出現，很好地結合了塊存儲與文件存儲的優點。

1.3.4 塊存儲、對象和文件存儲架構區別

1.3.4.1 塊存儲

塊存儲是一種裸設備，它是將存儲設備以“塊”的方式直接提供給客戶，由客戶自己的操作系統裏的文件系統進行管理。

華爲的FusionStorage是一個典型的“塊”存儲。FusionStorage分成了MDC、OSD和Client三部分。和其他分佈式存儲重大的差別是:MDC是記錄、更新OSD服務器、磁盤等的狀態，並把這些狀態數據實時同步給Vbs，由Vbs計算出來數據所落的位置。MDC可以單獨部署，也可以集中部署，也可以分佈部署。

一般分佈式存儲的MDC採用的是數據庫或內存儲數據庫來記錄數據塊和物理位置關係。客戶端向MDC發出詢問位置的請求，MDC查詢數據庫後返回請求數據的存儲位置。

這種方法存儲訪問的速度較慢，而且MDC作爲交通的“樞紐”，絕對是整個存儲的核心，當MDC發生故障，會導致整個存儲都不能使用。但是採取這個方式，也有好處，比如可以根據不同需求設置不同的副本策略等。

1.3.4.2 對象存儲

對象存儲是在同樣容量下提供的存儲性能比文件存儲更好，又能像文件存儲一樣有很好的共享性。實際使用中，性能不是對象存儲最關注的問題，需要高性能可以用塊存儲，容量纔是對象存儲最關注的問題。

所以對象存儲的持久化層的硬盤數量更多，單盤的容量也更大。對象存儲的數據的安全性保障也各式各樣，可以是單機raid或網絡raid，也可以副本。

Ceph和google基於GFS的存儲就是典型的對象存儲。

1.3.4.3 區別

分佈式塊存儲裏是沒有文件系統的，是通過客戶端直接將最簡單明瞭的命令傳遞給存儲的“塊”來執行。

對象存儲和文件存儲雖然結構類似，但並不將存儲底層的“塊”直接提供出來，而是通過隱藏着一個文件系統，包裝成爲“文件”或“對象”提供出來。

這些存儲“不挑”操作系統或終端，最終執行命令的是存儲裏面的文件系統操控存儲執行的，所以共享性很好。

文件存儲通過“目錄+文件名+偏移量”來檢索，文件間有目錄層次的；

而對象存儲採用“唯一對象ID+偏移量”來檢索，對象扁平存儲的，是沒有層次的。而且塊、對象、文件存儲是可以相互轉換的。

2 主流開源分佈式存儲方案概述

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

2.1 Ceph

Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表，並隨後貢獻給開源社區。經過多年的發展之後，已得到衆多雲計算和存儲廠商的支持，成爲應用最廣泛的開源分佈式存儲平臺。

Ceph根據場景可分爲對象存儲、塊設備存儲和文件存儲。Ceph相比其它分佈式存儲技術，其優勢點在於：它不單是存儲，同時還充分利用了存儲節點上的計算能力，在存儲每一個數據時，都會通過計算得出該數據存儲的位置，儘量將數據分佈均衡。同時，由於採用了CRUSH、HASH等算法，使得它不存在傳統的單點故障，且隨着規模的擴大，性能並不會受到影響。

2.1.1 Ceph的主要架構

基礎存儲系統RADOS

Ceph的最底層是RADOS（分佈式對象存儲系統），它具有可靠、智能、分佈式等特性，實現高可靠、高可拓展、高性能、高自動化等功能，並最終存儲用戶數據。RADOS系統主要由Ceph OSD、Ceph Monitors兩部分組成，Ceph OSD 的功能是存儲數據，處理數據的複製、恢復、回填、再均衡，並通過檢查其他OSD 守護進程的心跳來向 Ceph Monitors 提供一些監控信息。Ceph Monitor維護着展示集羣狀態的各種圖表，包括監視器圖、 OSD 圖、歸置組（ PG ）圖、和 CRUSH 圖。

基礎庫LIBRADOS

LIBRADOS層的功能是對RADOS進行抽象和封裝，並向上層提供API，以便直接基於RADOS進行應用開發。RADOS是一個對象存儲系統，因此，LIBRADOS實現的API是針對對象存儲功能的。物理上，LIBRADOS和基於其上開發的應用位於同一臺機器，因而也被稱爲本地API。應用調用本機上的LIBRADOS API，再由後者通過socket與RADOS集羣中的節點通信並完成各種操作。

上層應用接口

Ceph上層應用接口涵蓋了RADOSGW（RADOS Gateway）、RBD（Reliable Block Device）和Ceph FS（Ceph File System），其中，RADOSGW和RBD是在LIBRADOS庫的基礎上提供抽象層次更高、更便於應用或客戶端使用的上層接口。

應用層

應用層就是不同場景下對於Ceph各個應用接口的各種應用方式，例如基於LIBRADOS直接開發的對象存儲應用，基於RADOSGW開發的對象存儲應用，基於RBD實現的雲主機硬盤等。

2.1.2 Ceph的功能模塊

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

2.1.3 Ceph的優點

1.CRUSH算法

CRUSH算法是ceph的兩大創新之一，簡單來說，ceph摒棄了傳統的集中式存儲元數據尋址的方案，轉而使用CRUSH算法完成數據的尋址操作。採用CRUSH算法，數據分佈均衡，並行度高，不需要維護固定的元數據結構。

2.高可用

Ceph中的數據副本數量可以由管理員自行定義，並可以通過CRUSH算法指定副本的物理存儲位置以分隔故障域，支持數據強一致性，適合讀多寫少場景；ceph可以忍受多種故障場景並自動嘗試並行修復。

3.高擴展性

Ceph本身並沒有主控節點，擴展起來比較容易，並且理論上，它的性能會隨着磁盤數量的增加而線性增長。

4.特性豐富

Ceph支持對象存儲、塊存儲和文件存儲服務，故稱爲統一存儲。

2.1.4 Ceph的缺點

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

2.2 GFS

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

2.2.1 GFS的主要架構

GFS 架構比較簡單，一個 GFS 集羣一般由一個 master 、多個 chunkserver 和多個 clients 組成。

在 GFS 中，所有文件被切分成若干個 chunk，每個 chunk 擁有唯一不變的標識（在 chunk 創建時，由 master 負責分配），所有 chunk 都實際存儲在 chunkserver 的磁盤上。

爲了容災，每個 chunk 都會被複制到多個 chunkserve.

2.2.2 GFS的功能模塊

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

2.2.3 GFS的寫入流程

Client 向 master 詢問要修改的 chunk在哪個 chunkserver上，以及該chunk 其他副本的位置信息。
Master 將Primary、secondary的相關信息返回給 client。
Client 將數據推送給 primary 和 secondary；
當所有副本都確認收到數據後，client 發送寫請求給 primary，primary 給不同 client 的操作分配序號，保證操作順序執行。
Primary 把寫請求發送到 secondary，secondary 按照 primary 分配的序號順序執行所有操作
當 Secondary 執行完後回覆 primary 執行結果。
Primary 回覆 client 執行結果。

由上述可見，GFS在進行寫數據時，有如下特點：

GFS在數據讀寫時，數據流與控制流是分開的，並通過租約機制，在跨多個副本的數據寫入中, 保障順序一致性;
Master將chunk租約發放給其中一個副本，這個副本稱爲主副本，由主副本確定chunk的寫入順序，次副本則遵守這個順序，這樣就保障了全局順序一致性
Master返回客戶端主副本和次副本的位置信息，客戶端緩存這些信息以備將來使用，只有當主副本所在chunkserver不可用或返回租約過期了，客戶端才需要再次聯繫Master；
GFS採用鏈式推送，以最大化利用每個機器的網絡帶寬，避免網絡瓶頸和高延遲連接，最小化推送延遲；
GFS使用TCP流式傳輸數據，以最小化延遲。

2.2.4 GFS特點

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

2.3 HDFS

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

2.3.1 HDFS的主要架構

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

2.3.2 HDFS的特點（Vs GFS）

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

2.3.3 HDFS適合的應用場景

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

2.3.4 HDFS不適合的場景

低延時數據訪問；
小文件存儲；
併發寫入、文件隨機修改；

2.4 OpenStack Swift

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

2.4.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.4.2 Swift的數據模型

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

2.4.3 一致性散列函數

Swift是基於一致性散列技術，通過計算將對象均勻分佈到虛擬空間的虛擬節點上，在增加或刪除節點時可大大減少需移動的數據量；

爲便於高效的移位操作，虛擬空間大小通常採用 2 n；通過獨特的數據結構 Ring（環），再將虛擬節點映射到實際的物理存儲設備上，完成尋址過程。如下圖所示：

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

2.4.4 環的數據結構

Swift爲賬戶、容器和對象分別定義了的環。

環是爲了將虛擬節點（分區）映射到一組物理存儲設備上，並提供一定的冗餘度而設計的，環的數據信息包括存儲設備列表和設備信息、分區到設備的映射關係、計算分區號的位移（即上圖中的m）。

賬戶、容器和對象的尋址過程。（以對象的尋址過程爲例）：

以對象的層次結構 account/container/object 作爲鍵，採用 MD5 散列算法得到一個散列值；
對該散列值的前 4 個字節進行右移操作（右移m位），得到分區索引號；
在分區到設備映射表裏，按照分區索引號，查找該對象所在分區對應的所有物理設備編號。如下圖：

2.4.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 協議示例如下所示：

2.4.6 Swift特點

原生的對象存儲，不支持實時的文件讀寫、編輯功能
完全對稱架構，無主節點，無單點故障，易於大規模擴展，性能容量線性增長
數據實現最終一致性，不需要所有副本寫入即可返回，讀取數據時需要進行數據副本的校驗
是OpenStack的子項目之一，適合雲環境的部署
Swift的對象存儲與Ceph提供的對象存儲區別：客戶端在訪問對象存儲系統服務時，Swift要求客戶端必須訪問Swift網關才能獲得數據。而Ceph可以在每個存儲節點上的OSD（對象存儲設備）獲取數據信息；在數據一致性方面，Swift的數據是最終一致，而Ceph是始終跨集羣強一致性）

2.5 Lustre分佈式存儲

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

2.5.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.5.2 Lustre特點

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

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

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

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