?最新文章歡迎關(guān)注筆者公眾號(hào)“暢游云?！?/p>

??《重識(shí)云原生系列》專題索引：

第一章——不謀全局不足以謀一域
第二章計(jì)算第1節(jié)——計(jì)算虛擬化技術(shù)總述
第二章計(jì)算第2節(jié)——主流虛擬化技術(shù)之VMare ESXi
第二章計(jì)算第3節(jié)——主流虛擬化技術(shù)之Xen
第二章計(jì)算第4節(jié)——主流虛擬化技術(shù)之KVM
第二章計(jì)算第5節(jié)——商用云主機(jī)方案
第二章計(jì)算第6節(jié)——裸金屬方案
第三章云存儲(chǔ)第1節(jié)——分布式云存儲(chǔ)總述
第三章云存儲(chǔ)第2節(jié)——SPDK方案綜述
第三章云存儲(chǔ)第3節(jié)——Ceph統(tǒng)一存儲(chǔ)方案
第三章云存儲(chǔ)第4節(jié)——OpenStack Swift 對(duì)象存儲(chǔ)方案
第三章云存儲(chǔ)第5節(jié)——商用分布式云存儲(chǔ)方案
第四章云網(wǎng)絡(luò)第一節(jié)——云網(wǎng)絡(luò)技術(shù)發(fā)展簡(jiǎn)述
第四章云網(wǎng)絡(luò)4.2節(jié)——相關(guān)基礎(chǔ)知識(shí)準(zhǔn)備
第四章云網(wǎng)絡(luò)4.3節(jié)——重要網(wǎng)絡(luò)協(xié)議
第四章云網(wǎng)絡(luò)4.3.1節(jié)——路由技術(shù)簡(jiǎn)述
第四章云網(wǎng)絡(luò)4.3.2節(jié)——VLAN技術(shù)
第四章云網(wǎng)絡(luò)4.3.3節(jié)——RIP協(xié)議
第四章云網(wǎng)絡(luò)4.3.4節(jié)——OSPF協(xié)議
第四章云網(wǎng)絡(luò)4.3.5節(jié)——EIGRP協(xié)議
第四章云網(wǎng)絡(luò)4.3.6節(jié)——IS-IS協(xié)議
第四章云網(wǎng)絡(luò)4.3.7節(jié)——BGP協(xié)議
第四章云網(wǎng)絡(luò)4.3.7.2節(jié)——BGP協(xié)議概述
第四章云網(wǎng)絡(luò)4.3.7.3節(jié)——BGP協(xié)議實(shí)現(xiàn)原理
第四章云網(wǎng)絡(luò)4.3.7.4節(jié)——高級(jí)特性
第四章云網(wǎng)絡(luò)4.3.7.5節(jié)——實(shí)操
第四章云網(wǎng)絡(luò)4.3.7.6節(jié)——MP-BGP協(xié)議
第四章云網(wǎng)絡(luò)4.3.8節(jié)——策略路由
第四章云網(wǎng)絡(luò)4.3.9節(jié)——Graceful Restart(平滑重啟)技術(shù)
第四章云網(wǎng)絡(luò)4.3.10節(jié)——VXLAN技術(shù)
第四章云網(wǎng)絡(luò)4.3.10.2節(jié)——VXLAN Overlay網(wǎng)絡(luò)方案設(shè)計(jì)
第四章云網(wǎng)絡(luò)4.3.10.3節(jié)——VXLAN隧道機(jī)制
第四章云網(wǎng)絡(luò)4.3.10.4節(jié)——VXLAN報(bào)文轉(zhuǎn)發(fā)過程
第四章云網(wǎng)絡(luò)4.3.10.5節(jié)——VXlan組網(wǎng)架構(gòu)
第四章云網(wǎng)絡(luò)4.3.10.6節(jié)——VXLAN應(yīng)用部署方案
第四章云網(wǎng)絡(luò)4.4節(jié)——Spine-Leaf網(wǎng)絡(luò)架構(gòu)
第四章云網(wǎng)絡(luò)4.5節(jié)——大二層網(wǎng)絡(luò)
第四章云網(wǎng)絡(luò)4.6節(jié)——Underlay 和 Overlay概念
第四章云網(wǎng)絡(luò)4.7.1節(jié)——網(wǎng)絡(luò)虛擬化與卸載加速技術(shù)的演進(jìn)簡(jiǎn)述
第四章云網(wǎng)絡(luò)4.7.2節(jié)——virtio網(wǎng)絡(luò)半虛擬化簡(jiǎn)介
第四章云網(wǎng)絡(luò)4.7.3節(jié)——Vhost-net方案
第四章云網(wǎng)絡(luò)4.7.4節(jié)vhost-user方案——virtio的DPDK卸載方案
第四章云網(wǎng)絡(luò)4.7.5節(jié)vDPA方案——virtio的半硬件虛擬化實(shí)現(xiàn)
第四章云網(wǎng)絡(luò)4.7.6節(jié)——virtio-blk存儲(chǔ)虛擬化方案
第四章云網(wǎng)絡(luò)4.7.8節(jié)——SR-IOV方案
第四章云網(wǎng)絡(luò)4.7.9節(jié)——NFV
第四章云網(wǎng)絡(luò)4.8.1節(jié)——SDN總述
第四章云網(wǎng)絡(luò)4.8.2.1節(jié)——OpenFlow概述
第四章云網(wǎng)絡(luò)4.8.2.2節(jié)——OpenFlow協(xié)議詳解
第四章云網(wǎng)絡(luò)4.8.2.3節(jié)——OpenFlow運(yùn)行機(jī)制
第四章云網(wǎng)絡(luò)4.8.3.1節(jié)——Open vSwitch簡(jiǎn)介
第四章云網(wǎng)絡(luò)4.8.3.2節(jié)——Open vSwitch工作原理詳解
第四章云網(wǎng)絡(luò)4.8.4節(jié)——OpenStack與SDN的集成
第四章云網(wǎng)絡(luò)4.8.5節(jié)——OpenDayLight
第四章云網(wǎng)絡(luò)4.8.6節(jié)——Dragonflow
?第四章云網(wǎng)絡(luò)4.9.1節(jié)——網(wǎng)絡(luò)卸載加速技術(shù)綜述
第四章云網(wǎng)絡(luò)4.9.2節(jié)——傳統(tǒng)網(wǎng)絡(luò)卸載技術(shù)
第四章云網(wǎng)絡(luò)4.9.3.1節(jié)——DPDK技術(shù)綜述
第四章云網(wǎng)絡(luò)4.9.3.2節(jié)——DPDK原理詳解
第四章云網(wǎng)絡(luò)4.9.4.1節(jié)——智能網(wǎng)卡SmartNIC方案綜述
第四章云網(wǎng)絡(luò)4.9.4.2節(jié)——智能網(wǎng)卡實(shí)現(xiàn)
第六章容器6.1.1節(jié)——容器綜述
第六章容器6.1.2節(jié)——容器安裝部署

? ? ? ? 分布式云存儲(chǔ)知識(shí)地圖：?

1 分布式存儲(chǔ)發(fā)展簡(jiǎn)述

1.1 存儲(chǔ)發(fā)展簡(jiǎn)史

????????在了解什么是分布式存儲(chǔ)之前，我們先來簡(jiǎn)單了解一下存儲(chǔ)幾十年來的大概歷程。

直連存儲(chǔ)（DAS）：存儲(chǔ)和服務(wù)器直連，拓展性、靈活性差。
中心化存儲(chǔ)（SAN、NAS）：設(shè)備類型豐富，通過IP/FC網(wǎng)絡(luò)互連，具有一定的拓展性，但是受到控制器能力限制，拓展能力有限。同時(shí)，設(shè)備到了生命周期要進(jìn)行更換，數(shù)據(jù)遷移需要耗費(fèi)大量的時(shí)間和精力。
分布式存儲(chǔ)：基于標(biāo)準(zhǔn)硬件和分布式架構(gòu)，將數(shù)據(jù)分散存儲(chǔ)到多個(gè)存儲(chǔ)服務(wù)器上，并將這些分散的存儲(chǔ)資源構(gòu)成一個(gè)虛擬的存儲(chǔ)設(shè)備，可實(shí)現(xiàn)千節(jié)點(diǎn)/EB級(jí)擴(kuò)展，同時(shí)可以對(duì)塊、對(duì)象、文件等多種類型存儲(chǔ)統(tǒng)一管理。

????????直連存儲(chǔ)與中心化存儲(chǔ)也可以統(tǒng)稱為集中式存儲(chǔ)。

1.1.1 集中式存儲(chǔ)簡(jiǎn)述

????????集中式存儲(chǔ)系統(tǒng)中，整個(gè)存儲(chǔ)資源是集中在一個(gè)系統(tǒng)中的，但集中式存儲(chǔ)并不是一個(gè)單獨(dú)的設(shè)備，是集中在一套系統(tǒng)當(dāng)中的多個(gè)設(shè)備，比如下圖中的 EMC 存儲(chǔ)就需要幾個(gè)機(jī)柜來存放。

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

????????結(jié)構(gòu)中包含一個(gè)機(jī)頭，這個(gè)是存儲(chǔ)系統(tǒng)中最為核心的部件。通常在機(jī)頭中有包含兩個(gè)控制器，互為備用，避免硬件故障導(dǎo)致整個(gè)存儲(chǔ)系統(tǒng)的不可用。機(jī)頭中通常包含前端端口和后端端口，前端端口用戶為服務(wù)器提供存儲(chǔ)服務(wù)，而后端端口用于擴(kuò)充存儲(chǔ)系統(tǒng)的容量。通過后端端口機(jī)頭可以連接更多的存儲(chǔ)設(shè)備，從而形成一個(gè)非常大的存儲(chǔ)資源池。

????????在整個(gè)結(jié)構(gòu)中，機(jī)頭中是整個(gè)存儲(chǔ)系統(tǒng)的核心部件，整個(gè)存儲(chǔ)系統(tǒng)的高級(jí)功能都在其中實(shí)現(xiàn)。控制器中的軟件實(shí)現(xiàn)對(duì)磁盤的管理，將磁盤抽象化為存儲(chǔ)資源池，然后劃分為 LUN 提供給服務(wù)器使用。這里的 LUN 其實(shí)就是在服務(wù)器上看到的磁盤。當(dāng)然，一些集中式存儲(chǔ)本身也是文件服務(wù)器，可以提供共享文件服務(wù)。無論如何，從上面我們可以看出集中式存儲(chǔ) 最大的特點(diǎn)是有一個(gè)統(tǒng)一的入口，所有數(shù)據(jù)都要經(jīng)過這個(gè)入口，這個(gè)入口就是存儲(chǔ)系統(tǒng)的機(jī)頭。這也就是集中式存儲(chǔ)區(qū)別于分布式存儲(chǔ)最顯著的特點(diǎn)。如下圖所示：

1.1.2 分布式存儲(chǔ)簡(jiǎn)述

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

1 、分布式存儲(chǔ)的興起

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

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

互聯(lián)網(wǎng)的業(yè)務(wù)發(fā)展很快，而且注意成本消耗，這就使得存儲(chǔ)系統(tǒng)不能依靠傳統(tǒng)的縱向擴(kuò)展的方式，即先買小型機(jī)，不夠時(shí)再買中型機(jī)，甚至大型機(jī)?；ヂ?lián)網(wǎng)后端的分布式系統(tǒng)要求支持橫向擴(kuò)展，即通過增加普通 PC 服務(wù)器來提高系統(tǒng)的整體處理能力。
普通 PC 服務(wù)器性價(jià)比高，故障率也高，需要在軟件層面實(shí)現(xiàn)自動(dòng)容錯(cuò)，保證數(shù)據(jù)的一致性。
另外，隨著服務(wù)器的不斷加入，需要能夠在軟件層面實(shí)現(xiàn)自動(dòng)負(fù)載均衡，使得系統(tǒng)的處理能力得到線性擴(kuò)展。

2 、分布式存儲(chǔ)的重要性

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

升級(jí)單機(jī)處理能力的性價(jià)比越來越低，企業(yè)發(fā)現(xiàn)通過更換硬件做垂直擴(kuò)展的方式來提升性能會(huì)越來越不劃算;
單機(jī)處理能力存在瓶頸，某個(gè)固定時(shí)間點(diǎn)，單顆處理器有自己的性能瓶頸，也就說即使愿意花更多的錢去買計(jì)算能力也買不到了;
出于穩(wěn)定性和可用性的考慮，如果采用單擊系統(tǒng)，那么在這臺(tái)機(jī)器正常的時(shí)候一切 OK ，一旦出問題，那么系統(tǒng)就完全不能用了。當(dāng)然，可以考慮做容災(zāi)備份等方案，而這些方案就會(huì)讓系統(tǒng)演變?yōu)榉植际较到y(tǒng)了;
云存儲(chǔ)和大數(shù)據(jù)發(fā)展的必然要求，云存儲(chǔ)和大數(shù)據(jù)是構(gòu)建在分布式存儲(chǔ)之上的應(yīng)用。移動(dòng)終端的計(jì)算能力和存儲(chǔ)空間有限，而且有在多個(gè)設(shè)備之間共享資源的強(qiáng)烈的需求，這就使得網(wǎng)盤、相冊(cè)等云存儲(chǔ)應(yīng)用很快流行起來。然而，萬變不離其宗，云存儲(chǔ)的核心還是后端的大規(guī)模分布式存儲(chǔ)系統(tǒng)。大數(shù)據(jù)則更近一步，不僅需要存儲(chǔ)海量數(shù)據(jù)，還需要通過合適的計(jì)算框架或者工具對(duì)這些數(shù)據(jù)進(jìn)行分析，抽取其中有價(jià)值的部分。如果沒有分布式存儲(chǔ)，便談不上對(duì)大數(shù)據(jù)進(jìn)行分析。仔細(xì)分析還會(huì)發(fā)現(xiàn)，分布式存儲(chǔ)技術(shù)是互聯(lián)網(wǎng)后端架構(gòu)的神器，掌握了這項(xiàng)技能，以后理解其他技術(shù)的本質(zhì)會(huì)變得非常容易。

1.2 分布式存儲(chǔ)整體架構(gòu)總述

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

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

????????以 HDFS ( Hadoop Distribution File System )為代表的架構(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ù)。

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

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

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

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

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

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

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

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

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

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

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

(8) RADOS GW ：RGW 提供對(duì)象存儲(chǔ)服務(wù)，它允許應(yīng)用程序和 Ceph 對(duì)象存儲(chǔ)建立連接， RGW 提供了與 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API。

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

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

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

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

1.3 云上分布式存儲(chǔ)簡(jiǎn)述

????????分布式存儲(chǔ)架構(gòu)由三個(gè)部分組成：客戶端、元數(shù)據(jù)服務(wù)器和數(shù)據(jù)服務(wù)器?？蛻舳素?fù)責(zé)發(fā)送讀寫請(qǐng)求，緩存文件元數(shù)據(jù)和文件數(shù)據(jù)。元數(shù)據(jù)服務(wù)器負(fù)責(zé)管理元數(shù)據(jù)和處理客戶端的請(qǐng)求，是整個(gè)系統(tǒng)的核心組件。數(shù)據(jù)服務(wù)器負(fù)責(zé)存放文件數(shù)據(jù)，保證數(shù)據(jù)的可用性和完整性。該架構(gòu)的好處是性能和容量能夠同時(shí)拓展，系統(tǒng)規(guī)模具有很強(qiáng)的伸縮性。

????????分布式存儲(chǔ)分為文件存儲(chǔ)、對(duì)象存儲(chǔ)和塊存儲(chǔ)，但它們?nèi)N存儲(chǔ)方式的基本架構(gòu)都是大同小異的。即客戶端或應(yīng)用端、元數(shù)據(jù)（MDS）服務(wù)器和數(shù)據(jù)節(jié)點(diǎn)服務(wù)器?？蛻舳撕驮獢?shù)據(jù)服務(wù)器之間交互是“信令交互”，而客戶端到數(shù)據(jù)節(jié)點(diǎn)是“媒體交互”。元數(shù)據(jù)服務(wù)器或通過數(shù)據(jù)節(jié)點(diǎn)服務(wù)器獲取各節(jié)點(diǎn)服務(wù)器的基本配置情況和狀態(tài)信息。

1.3.1 塊存儲(chǔ)

????????典型設(shè)備：磁盤陣列，硬盤

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

????????接著塊存儲(chǔ)會(huì)采用映射的方式將這幾個(gè)邏輯盤映射給主機(jī)，主機(jī)上面的操作系統(tǒng)會(huì)識(shí)別到有5塊硬盤，但是操作系統(tǒng)是區(qū)分不出到底是邏輯還是物理的，它一概就認(rèn)為只是5塊裸的物理硬盤而已，跟直接拿一塊物理硬盤掛載到操作系統(tǒng)沒有區(qū)別的，至少操作系統(tǒng)感知上沒有區(qū)別。

????????此種方式下，操作系統(tǒng)還需要對(duì)掛載的裸硬盤進(jìn)行分區(qū)、格式化后，才能使用，與平常主機(jī)內(nèi)置硬盤的方式完全無異。

優(yōu)點(diǎn)：

這種方式的好處當(dāng)然是因?yàn)橥ㄟ^了Raid與LVM等手段，對(duì)數(shù)據(jù)提供了保護(hù)。
另外也可以將多塊廉價(jià)的硬盤組合起來，成為一個(gè)大容量的邏輯盤對(duì)外提供服務(wù)，提高了容量。
寫入數(shù)據(jù)的時(shí)候，由于是多塊磁盤組合出來的邏輯盤，所以幾塊磁盤可以并行寫入的，提升了讀寫效率。
很多時(shí)候塊存儲(chǔ)采用SAN架構(gòu)組網(wǎng)，傳輸速率以及封裝協(xié)議的原因，使得傳輸速度與讀寫速率得到提升。

缺點(diǎn)：

采用SAN架構(gòu)組網(wǎng)時(shí)，需要額外為主機(jī)購買光纖通道卡，還要買光纖交換機(jī)，造價(jià)成本高。
主機(jī)之間的數(shù)據(jù)無法共享，在服務(wù)器不做集群的情況下，塊存儲(chǔ)裸盤映射給主機(jī)，再格式化使用后，對(duì)于主機(jī)來說相當(dāng)于本地盤，那么主機(jī)A的本地盤根本不能給主機(jī)B去使用，無法共享數(shù)據(jù)。
不利于不同操作系統(tǒng)主機(jī)間的數(shù)據(jù)共享：另外一個(gè)原因是因?yàn)椴僮飨到y(tǒng)使用不同的文件系統(tǒng)，格式化完之后，不同文件系統(tǒng)間的數(shù)據(jù)是共享不了的。例如一臺(tái)裝了WIN7/XP，文件系統(tǒng)是FAT32/NTFS，而Linux是EXT4，EXT4是無法識(shí)別NTFS的文件系統(tǒng)的。就像一只NTFS格式的U盤，插進(jìn)Linux的筆記本，根本無法識(shí)別出來。所以不利于文件共享。

1.3.2 文件存儲(chǔ)

典型設(shè)備：FTP、NFS服務(wù)器

????????為了克服上述文件無法共享的問題，所以有了文件存儲(chǔ)。

????????文件存儲(chǔ)也有軟硬一體化的設(shè)備，但是其實(shí)普通拿一臺(tái)服務(wù)器/筆記本，只要裝上合適的操作系統(tǒng)與軟件，就可以架設(shè)FTP與NFS服務(wù)了，架上該類服務(wù)之后的服務(wù)器，就是文件存儲(chǔ)的一種了。

????????主機(jī)A可以直接對(duì)文件存儲(chǔ)進(jìn)行文件的上傳下載，與塊存儲(chǔ)不同，主機(jī)A是不需要再對(duì)文件存儲(chǔ)進(jìn)行格式化的，因?yàn)槲募芾砉δ芤呀?jīng)由文件存儲(chǔ)自己搞定了。

優(yōu)點(diǎn)：

造價(jià)交低：隨便一臺(tái)機(jī)器就可以了，另外普通以太網(wǎng)就可以，根本不需要專用的SAN網(wǎng)絡(luò)，所以造價(jià)低。
方便文件共享：例如主機(jī)A（WIN7，NTFS文件系統(tǒng)），主機(jī)B（Linux，EXT4文件系統(tǒng)），想互拷一部電影，本來不行。加了個(gè)主機(jī)C（NFS服務(wù)器），然后可以先A拷到C，再C拷到B就OK了。

缺點(diǎn)：

讀寫速率低，傳輸速率慢：以太網(wǎng)，上傳下載速度較慢，另外所有讀寫都要1臺(tái)服務(wù)器里面的硬盤來承擔(dān)，相比起磁盤陣列動(dòng)不動(dòng)就幾十上百塊硬盤同時(shí)讀寫，速率慢了許多。

1.3.3 對(duì)象存儲(chǔ)

典型設(shè)備：內(nèi)置大容量硬盤的分布式服務(wù)器

????????對(duì)象存儲(chǔ)最常用的方案，就是多臺(tái)服務(wù)器內(nèi)置大容量硬盤，再裝上對(duì)象存儲(chǔ)軟件，然后再額外搞幾臺(tái)服務(wù)作為管理節(jié)點(diǎn)，安裝上對(duì)象存儲(chǔ)管理軟件。管理節(jié)點(diǎn)可以管理其他服務(wù)器對(duì)外提供讀寫訪問功能。

????????之所以出現(xiàn)了對(duì)象存儲(chǔ)這種東西，是為了克服塊存儲(chǔ)與文件存儲(chǔ)各自的缺點(diǎn)，發(fā)揚(yáng)它倆各自的優(yōu)點(diǎn)。簡(jiǎn)單來說塊存儲(chǔ)讀寫快，不利于共享，文件存儲(chǔ)讀寫慢，利于共享。能否弄一個(gè)讀寫快，利于共享的出來呢。于是就有了對(duì)象存儲(chǔ)。

????????首先，一個(gè)文件包含了了屬性（術(shù)語叫metadata，元數(shù)據(jù)，例如該文件的大小、修改時(shí)間、存儲(chǔ)路徑等）以及內(nèi)容（以下簡(jiǎn)稱數(shù)據(jù)）。

????????以往像FAT32這種文件系統(tǒng)，是直接將一份文件的數(shù)據(jù)與metadata一起存儲(chǔ)的，存儲(chǔ)過程先將文件按照文件系統(tǒng)的最小塊大小來打散（如4M的文件，假設(shè)文件系統(tǒng)要求一個(gè)塊4K，那么就將文件打散成為1000個(gè)小塊），再寫進(jìn)硬盤里面，過程中沒有區(qū)分?jǐn)?shù)據(jù)/metadata的。而每個(gè)塊最后會(huì)告知你下一個(gè)要讀取的塊的地址，然后一直這樣順序地按圖索驥，最后完成整份文件的所有塊的讀取。

????????這種情況下讀寫速率很慢，因?yàn)榫退隳阌?00個(gè)機(jī)械手臂在讀寫，但是由于你只有讀取到第一個(gè)塊，才能知道下一個(gè)塊在哪里，其實(shí)相當(dāng)于只能有1個(gè)機(jī)械手臂在實(shí)際工作。

????????而對(duì)象存儲(chǔ)則將元數(shù)據(jù)獨(dú)立了出來，控制節(jié)點(diǎn)叫元數(shù)據(jù)服務(wù)器（服務(wù)器+對(duì)象存儲(chǔ)管理軟件），里面主要負(fù)責(zé)存儲(chǔ)對(duì)象的屬性（主要是對(duì)象的數(shù)據(jù)被打散存放到了那幾臺(tái)分布式服務(wù)器中的信息），而其他負(fù)責(zé)存儲(chǔ)數(shù)據(jù)的分布式服務(wù)器叫做OSD，主要負(fù)責(zé)存儲(chǔ)文件的數(shù)據(jù)部分。當(dāng)用戶訪問對(duì)象，會(huì)先訪問元數(shù)據(jù)服務(wù)器，元數(shù)據(jù)服務(wù)器只負(fù)責(zé)反饋對(duì)象存儲(chǔ)在哪些OSD，假設(shè)反饋文件A存儲(chǔ)在B、C、D三臺(tái)OSD，那么用戶就會(huì)再次直接訪問3臺(tái)OSD服務(wù)器去讀取數(shù)據(jù)。

????????這時(shí)候由于是3臺(tái)OSD同時(shí)對(duì)外傳輸數(shù)據(jù)，所以傳輸?shù)乃俣染图涌炝恕．?dāng)OSD服務(wù)器數(shù)量越多，這種讀寫速度的提升就越大，通過此種方式，實(shí)現(xiàn)了讀寫快的目的。

????????另一方面，對(duì)象存儲(chǔ)軟件是有專門的文件系統(tǒng)的，所以O(shè)SD對(duì)外又相當(dāng)于文件服務(wù)器，那么就不存在文件共享方面的困難了，也解決了文件共享方面的問題。

????????所以對(duì)象存儲(chǔ)的出現(xiàn)，很好地結(jié)合了塊存儲(chǔ)與文件存儲(chǔ)的優(yōu)點(diǎn)。

1.3.4 塊存儲(chǔ)、對(duì)象和文件存儲(chǔ)架構(gòu)區(qū)別

1.3.4.1 塊存儲(chǔ)

????????塊存儲(chǔ)是一種裸設(shè)備，它是將存儲(chǔ)設(shè)備以“塊”的方式直接提供給客戶，由客戶自己的操作系統(tǒng)里的文件系統(tǒng)進(jìn)行管理。

????????華為的FusionStorage是一個(gè)典型的“塊”存儲(chǔ)。FusionStorage分成了MDC、OSD和Client三部分。和其他分布式存儲(chǔ)重大的差別是:MDC是記錄、更新OSD服務(wù)器、磁盤等的狀態(tài)，并把這些狀態(tài)數(shù)據(jù)實(shí)時(shí)同步給Vbs，由Vbs計(jì)算出來數(shù)據(jù)所落的位置。MDC可以單獨(dú)部署，也可以集中部署，也可以分布部署。

????????一般分布式存儲(chǔ)的MDC采用的是數(shù)據(jù)庫或內(nèi)存儲(chǔ)數(shù)據(jù)庫來記錄數(shù)據(jù)塊和物理位置關(guān)系?？蛻舳讼騇DC發(fā)出詢問位置的請(qǐng)求，MDC查詢數(shù)據(jù)庫后返回請(qǐng)求數(shù)據(jù)的存儲(chǔ)位置。

????????這種方法存儲(chǔ)訪問的速度較慢，而且MDC作為交通的“樞紐”，絕對(duì)是整個(gè)存儲(chǔ)的核心，當(dāng)MDC發(fā)生故障，會(huì)導(dǎo)致整個(gè)存儲(chǔ)都不能使用。但是采取這個(gè)方式，也有好處，比如可以根據(jù)不同需求設(shè)置不同的副本策略等。

1.3.4.2 對(duì)象存儲(chǔ)

????????對(duì)象存儲(chǔ)是在同樣容量下提供的存儲(chǔ)性能比文件存儲(chǔ)更好，又能像文件存儲(chǔ)一樣有很好的共享性。實(shí)際使用中，性能不是對(duì)象存儲(chǔ)最關(guān)注的問題，需要高性能可以用塊存儲(chǔ)，容量才是對(duì)象存儲(chǔ)最關(guān)注的問題。

????????所以對(duì)象存儲(chǔ)的持久化層的硬盤數(shù)量更多，單盤的容量也更大。對(duì)象存儲(chǔ)的數(shù)據(jù)的安全性保障也各式各樣，可以是單機(jī)raid或網(wǎng)絡(luò)raid，也可以副本。

????????Ceph和google基于GFS的存儲(chǔ)就是典型的對(duì)象存儲(chǔ)。

1.3.4.3 區(qū)別

????????分布式塊存儲(chǔ)里是沒有文件系統(tǒng)的，是通過客戶端直接將最簡(jiǎn)單明了的命令傳遞給存儲(chǔ)的“塊”來執(zhí)行。

????????對(duì)象存儲(chǔ)和文件存儲(chǔ)雖然結(jié)構(gòu)類似，但并不將存儲(chǔ)底層的“塊”直接提供出來，而是通過隱藏著一個(gè)文件系統(tǒng)，包裝成為“文件”或“對(duì)象”提供出來。

????????這些存儲(chǔ)“不挑”操作系統(tǒng)或終端，最終執(zhí)行命令的是存儲(chǔ)里面的文件系統(tǒng)操控存儲(chǔ)執(zhí)行的，所以共享性很好。

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

????????而對(duì)象存儲(chǔ)采用“唯一對(duì)象ID+偏移量”來檢索，對(duì)象扁平存儲(chǔ)的，是沒有層次的。而且塊、對(duì)象、文件存儲(chǔ)是可以相互轉(zhuǎn)換的。

2 主流開源分布式存儲(chǔ)方案概述

????????在主流的分布式存儲(chǔ)技術(shù)中，HDFS/GPFS/GFS屬于文件存儲(chǔ)，Swift屬于對(duì)象存儲(chǔ)，而Ceph可支持塊存儲(chǔ)、對(duì)象存儲(chǔ)和文件存儲(chǔ)，故稱為統(tǒng)一存儲(chǔ)。

2.1 Ceph

????????Ceph最早起源于Sage就讀博士期間的工作、成果于2004年發(fā)表，并隨后貢獻(xiàn)給開源社區(qū)。經(jīng)過多年的發(fā)展之后，已得到眾多云計(jì)算和存儲(chǔ)廠商的支持，成為應(yīng)用最廣泛的開源分布式存儲(chǔ)平臺(tái)。

????????Ceph根據(jù)場(chǎng)景可分為對(duì)象存儲(chǔ)、塊設(shè)備存儲(chǔ)和文件存儲(chǔ)。Ceph相比其它分布式存儲(chǔ)技術(shù)，其優(yōu)勢(shì)點(diǎn)在于：它不單是存儲(chǔ)，同時(shí)還充分利用了存儲(chǔ)節(jié)點(diǎn)上的計(jì)算能力，在存儲(chǔ)每一個(gè)數(shù)據(jù)時(shí)，都會(huì)通過計(jì)算得出該數(shù)據(jù)存儲(chǔ)的位置，盡量將數(shù)據(jù)分布均衡。同時(shí)，由于采用了CRUSH、HASH等算法，使得它不存在傳統(tǒng)的單點(diǎn)故障，且隨著規(guī)模的擴(kuò)大，性能并不會(huì)受到影響。

2.1.1 Ceph的主要架構(gòu)

基礎(chǔ)存儲(chǔ)系統(tǒng)RADOS

????????Ceph的最底層是RADOS（分布式對(duì)象存儲(chǔ)系統(tǒng)），它具有可靠、智能、分布式等特性，實(shí)現(xiàn)高可靠、高可拓展、高性能、高自動(dòng)化等功能，并最終存儲(chǔ)用戶數(shù)據(jù)。RADOS系統(tǒng)主要由Ceph OSD、Ceph Monitors兩部分組成，Ceph OSD 的功能是存儲(chǔ)數(shù)據(jù)，處理數(shù)據(jù)的復(fù)制、恢復(fù)、回填、再均衡，并通過檢查其他OSD 守護(hù)進(jìn)程的心跳來向 Ceph Monitors 提供一些監(jiān)控信息。Ceph Monitor維護(hù)著展示集群狀態(tài)的各種圖表，包括監(jiān)視器圖、 OSD 圖、歸置組（ PG ）圖、和 CRUSH 圖。?

基礎(chǔ)庫LIBRADOS

????????LIBRADOS層的功能是對(duì)RADOS進(jìn)行抽象和封裝，并向上層提供API，以便直接基于RADOS進(jìn)行應(yīng)用開發(fā)。RADOS是一個(gè)對(duì)象存儲(chǔ)系統(tǒng)，因此，LIBRADOS實(shí)現(xiàn)的API是針對(duì)對(duì)象存儲(chǔ)功能的。物理上，LIBRADOS和基于其上開發(fā)的應(yīng)用位于同一臺(tái)機(jī)器，因而也被稱為本地API。應(yīng)用調(diào)用本機(jī)上的LIBRADOS API，再由后者通過socket與RADOS集群中的節(jié)點(diǎn)通信并完成各種操作。

上層應(yīng)用接口

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

應(yīng)用層

????????應(yīng)用層就是不同場(chǎng)景下對(duì)于Ceph各個(gè)應(yīng)用接口的各種應(yīng)用方式，例如基于LIBRADOS直接開發(fā)的對(duì)象存儲(chǔ)應(yīng)用，基于RADOSGW開發(fā)的對(duì)象存儲(chǔ)應(yīng)用，基于RBD實(shí)現(xiàn)的云主機(jī)硬盤等。

2.1.2 Ceph的功能模塊

Client客戶端：負(fù)責(zé)存儲(chǔ)協(xié)議的接入，節(jié)點(diǎn)負(fù)載均衡。
MON監(jiān)控服務(wù)：負(fù)責(zé)監(jiān)控整個(gè)集群，維護(hù)集群的健康狀態(tài)，維護(hù)展示集群狀態(tài)的各種圖表，如OSD Map、Monitor Map、PG Map和CRUSH Map。
MDS元數(shù)據(jù)服務(wù)：負(fù)責(zé)保存文件系統(tǒng)的元數(shù)據(jù)，管理目錄結(jié)構(gòu)。
OSD存儲(chǔ)服務(wù)：主要功能是存儲(chǔ)數(shù)據(jù)、復(fù)制數(shù)據(jù)、平衡數(shù)據(jù)、恢復(fù)數(shù)據(jù)，以及與其它OSD間進(jìn)行心跳檢查等。一般情況下一塊硬盤對(duì)應(yīng)一個(gè)OSD。

2.1.3 Ceph的優(yōu)點(diǎn)

1.CRUSH算法

????????CRUSH算法是ceph的兩大創(chuàng)新之一，簡(jiǎn)單來說，ceph摒棄了傳統(tǒng)的集中式存儲(chǔ)元數(shù)據(jù)尋址的方案，轉(zhuǎn)而使用CRUSH算法完成數(shù)據(jù)的尋址操作。采用CRUSH算法，數(shù)據(jù)分布均衡，并行度高，不需要維護(hù)固定的元數(shù)據(jù)結(jié)構(gòu)。

2.高可用

????????Ceph中的數(shù)據(jù)副本數(shù)量可以由管理員自行定義，并可以通過CRUSH算法指定副本的物理存儲(chǔ)位置以分隔故障域，支持?jǐn)?shù)據(jù)強(qiáng)一致性，適合讀多寫少場(chǎng)景；ceph可以忍受多種故障場(chǎng)景并自動(dòng)嘗試并行修復(fù)。

3.高擴(kuò)展性

????????Ceph本身并沒有主控節(jié)點(diǎn)，擴(kuò)展起來比較容易，并且理論上，它的性能會(huì)隨著磁盤數(shù)量的增加而線性增長(zhǎng)。

4.特性豐富

????????Ceph支持對(duì)象存儲(chǔ)、塊存儲(chǔ)和文件存儲(chǔ)服務(wù)，故稱為統(tǒng)一存儲(chǔ)。

2.1.4 Ceph的缺點(diǎn)

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

?2.2 GFS

????????GFS是google的分布式文件存儲(chǔ)系統(tǒng)，是專為存儲(chǔ)海量搜索數(shù)據(jù)而設(shè)計(jì)的，2003年提出，是閉源的分布式文件系統(tǒng)。適用于大量的順序讀取和順序追加，如大文件的讀寫。注重大文件的持續(xù)穩(wěn)定帶寬，而不是單次讀寫的延遲。

2.2.1 GFS的主要架構(gòu)

????????GFS 架構(gòu)比較簡(jiǎn)單，一個(gè) GFS 集群一般由一個(gè) master 、多個(gè) chunkserver 和多個(gè) clients 組成。

????????在 GFS 中，所有文件被切分成若干個(gè) chunk，每個(gè) chunk 擁有唯一不變的標(biāo)識(shí)（在 chunk 創(chuàng)建時(shí)，由 master 負(fù)責(zé)分配），所有 chunk 都實(shí)際存儲(chǔ)在 chunkserver 的磁盤上。

????????為了容災(zāi)，每個(gè) chunk 都會(huì)被復(fù)制到多個(gè) chunkserve.

2.2.2 GFS的功能模塊

GFS client客戶端：為應(yīng)用提供API，與POSIX API類似。同時(shí)緩存從GFS master讀取的元數(shù)據(jù)chunk信息；
GFS master元數(shù)據(jù)服務(wù)器：管理所有文件系統(tǒng)的元數(shù)據(jù)，包括命令空間（目錄層級(jí)）、訪問控制信息、文件到chunk的映射關(guān)系，chunk的位置等。同時(shí) master 還管理系統(tǒng)范圍內(nèi)的各種活動(dòng)，包括chunk 創(chuàng)建、復(fù)制、數(shù)據(jù)遷移、垃圾回收等；
GFS chunksever存儲(chǔ)節(jié)點(diǎn)：用于所有 chunk的存儲(chǔ)。一個(gè)文件被分割為多個(gè)大小固定的chunk（默認(rèn)64M），每個(gè)chunk有全局唯一的chunk ID。

2.2.3 GFS的寫入流程

Client 向 master 詢問要修改的 chunk在哪個(gè) chunkserver上，以及該chunk 其他副本的位置信息。
Master 將Primary、secondary的相關(guān)信息返回給 client。
Client 將數(shù)據(jù)推送給 primary 和 secondary；
當(dāng)所有副本都確認(rèn)收到數(shù)據(jù)后，client 發(fā)送寫請(qǐng)求給 primary，primary 給不同 client 的操作分配序號(hào)，保證操作順序執(zhí)行。
Primary 把寫請(qǐng)求發(fā)送到 secondary，secondary 按照 primary 分配的序號(hào)順序執(zhí)行所有操作
當(dāng) Secondary 執(zhí)行完后回復(fù) primary 執(zhí)行結(jié)果。
Primary 回復(fù) client 執(zhí)行結(jié)果。

????????由上述可見，GFS在進(jìn)行寫數(shù)據(jù)時(shí)，有如下特點(diǎn)：

GFS在數(shù)據(jù)讀寫時(shí)，數(shù)據(jù)流與控制流是分開的，并通過租約機(jī)制，在跨多個(gè)副本的數(shù)據(jù)寫入中, 保障順序一致性;
Master將chunk租約發(fā)放給其中一個(gè)副本，這個(gè)副本稱為主副本，由主副本確定chunk的寫入順序，次副本則遵守這個(gè)順序，這樣就保障了全局順序一致性
Master返回客戶端主副本和次副本的位置信息，客戶端緩存這些信息以備將來使用，只有當(dāng)主副本所在chunkserver不可用或返回租約過期了，客戶端才需要再次聯(lián)系Master；
GFS采用鏈?zhǔn)酵扑?，以最大化利用每個(gè)機(jī)器的網(wǎng)絡(luò)帶寬，避免網(wǎng)絡(luò)瓶頸和高延遲連接，最小化推送延遲；
GFS使用TCP流式傳輸數(shù)據(jù)，以最小化延遲。

2.2.4 GFS特點(diǎn)

適合大文件場(chǎng)景的應(yīng)用，特別是針對(duì)GB級(jí)別的大文件，適用于數(shù)據(jù)訪問延時(shí)不敏感的搜索類業(yè)務(wù)
中心化架構(gòu)，只有1個(gè)master處于active狀態(tài)
緩存和預(yù)取，通過在client端緩存元數(shù)據(jù)，盡量減少與master的交互，通過文件的預(yù)讀取來提升并發(fā)性能
高可靠性，master需要持久化的數(shù)據(jù)會(huì)通過操作日志與checkpoint的方式存放多份，故障后master會(huì)自動(dòng)切換重啟。

2.3 HDFS

????????HDFS（Hadoop Distributed File System），是一個(gè)適合運(yùn)行在通用硬件(commodity hardware)上的分布式文件系統(tǒng)，是Hadoop的核心子項(xiàng)目，是基于流數(shù)據(jù)模式訪問和處理超大文件的需求而開發(fā)的。該系統(tǒng)仿效了谷歌文件系統(tǒng)(GFS)，是GFS的一個(gè)簡(jiǎn)化和開源版本。

2.3.1 HDFS的主要架構(gòu)

HDFS Client（客戶端）：從NameNode獲取文件的位置信息，再從DataNode讀取或者寫入數(shù)據(jù)。此外，client在數(shù)據(jù)存儲(chǔ)時(shí)，負(fù)責(zé)文件的分割；
NameNode（元數(shù)據(jù)節(jié)點(diǎn)）：管理名稱空間、數(shù)據(jù)塊（Block）映射信息、配置副本策略、處理客戶端讀寫請(qǐng)求；
DataNode（存儲(chǔ)節(jié)點(diǎn)）：負(fù)責(zé)執(zhí)行實(shí)際的讀寫操作，存儲(chǔ)實(shí)際的數(shù)據(jù)塊,同一個(gè)數(shù)據(jù)塊會(huì)被存儲(chǔ)在多個(gè)DataNode上
Secondary NameNode：定期合并元數(shù)據(jù)，推送給NameNode，在緊急情況下，可輔助NameNode的HA恢復(fù)。

2.3.2 HDFS的特點(diǎn)（Vs GFS）

分塊更大，每個(gè)數(shù)據(jù)塊默認(rèn)128MB；
不支持并發(fā)，同一時(shí)刻只允許一個(gè)寫入者或追加者；
過程一致性,寫入數(shù)據(jù)的傳輸順序與最終寫入順序一致；
Master HA，2.X版本支持兩個(gè)NameNode，（分別處于Active和Standby狀態(tài)），故障切換時(shí)間一般幾十秒到數(shù)分鐘；

2.3.3 HDFS適合的應(yīng)用場(chǎng)景

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

2.3.4 HDFS不適合的場(chǎng)景

低延時(shí)數(shù)據(jù)訪問；
小文件存儲(chǔ)；
并發(fā)寫入、文件隨機(jī)修改；

2.4 OpenStack Swift

????????Swift 最初是由Rackspace公司開發(fā)的分布式對(duì)象存儲(chǔ)服務(wù)， 2010 年貢獻(xiàn)給 OpenStack 開源社區(qū)。作為其最初的核心子項(xiàng)目之一，為其 Nova 子項(xiàng)目提供虛機(jī)鏡像存儲(chǔ)服務(wù)。

2.4.1 Swift的主要架構(gòu)

????????Swift 采用完全對(duì)稱、面向資源的分布式系統(tǒng)架構(gòu)設(shè)計(jì)，所有組件都可擴(kuò)展，避免因單點(diǎn)失效而影響整個(gè)系統(tǒng)的可用性。

?Swift 組件包括：

代理服務(wù)（Proxy Server）：對(duì)外提供對(duì)象服務(wù) API，轉(zhuǎn)發(fā)請(qǐng)求至相應(yīng)的賬戶、容器或?qū)ο蠓?wù)
認(rèn)證服務(wù)（Authentication Server）：驗(yàn)證用戶的身份信息，并獲得一個(gè)訪問令牌（Token）
緩存服務(wù)（Cache Server）：緩存令牌，賬戶和容器信息，但不會(huì)緩存對(duì)象本身的數(shù)據(jù)
賬戶服務(wù)（Account Server）：提供賬戶元數(shù)據(jù)和統(tǒng)計(jì)信息，并維護(hù)所含容器列表的服務(wù)
容器服務(wù)（Container Server）：提供容器元數(shù)據(jù)和統(tǒng)計(jì)信息，并維護(hù)所含對(duì)象列表的服務(wù)
對(duì)象服務(wù)（Object Server）：提供對(duì)象元數(shù)據(jù)和內(nèi)容服務(wù)，每個(gè)對(duì)象會(huì)以文件存儲(chǔ)在文件系統(tǒng)中
復(fù)制服務(wù)（Replicator）：檢測(cè)本地副本和遠(yuǎn)程副本是否一致，采用推式（Push）更新遠(yuǎn)程副本
更新服務(wù)（Updater）：對(duì)象內(nèi)容的更新
審計(jì)服務(wù)（Auditor）：檢查對(duì)象、容器和賬戶的完整性，如果發(fā)現(xiàn)錯(cuò)誤，文件將被隔離
賬戶清理服務(wù)（Account Reaper）：移除被標(biāo)記為刪除的賬戶，刪除其所包含的所有容器和對(duì)象

2.4.2 Swift的數(shù)據(jù)模型

????????Swift的數(shù)據(jù)模型采用層次結(jié)構(gòu)，共設(shè)三層：Account/Container/Object（即賬戶/容器/對(duì)象)，每層節(jié)點(diǎn)數(shù)均沒有限制，可以任意擴(kuò)展。數(shù)據(jù)模型如下：

2.4.3 一致性散列函數(shù)

????????Swift是基于一致性散列技術(shù)，通過計(jì)算將對(duì)象均勻分布到虛擬空間的虛擬節(jié)點(diǎn)上，在增加或刪除節(jié)點(diǎn)時(shí)可大大減少需移動(dòng)的數(shù)據(jù)量；

????????為便于高效的移位操作，虛擬空間大小通常采用 2 n；通過獨(dú)特的數(shù)據(jù)結(jié)構(gòu) Ring（環(huán)），再將虛擬節(jié)點(diǎn)映射到實(shí)際的物理存儲(chǔ)設(shè)備上，完成尋址過程。如下圖所示：

????????散列空間4 個(gè)字節(jié)（32為），虛擬節(jié)點(diǎn)數(shù)最大為232，如將散列結(jié)果右移 m 位，可產(chǎn)生 2(32-m)個(gè)虛擬節(jié)點(diǎn)，（如上圖中所示，當(dāng)m=29 時(shí)，可產(chǎn)生 8 個(gè)虛擬節(jié)點(diǎn)）。

2.4.4 環(huán)的數(shù)據(jù)結(jié)構(gòu)

????????Swift為賬戶、容器和對(duì)象分別定義了的環(huán)。

????????環(huán)是為了將虛擬節(jié)點(diǎn)（分區(qū)）映射到一組物理存儲(chǔ)設(shè)備上，并提供一定的冗余度而設(shè)計(jì)的，環(huán)的數(shù)據(jù)信息包括存儲(chǔ)設(shè)備列表和設(shè)備信息、分區(qū)到設(shè)備的映射關(guān)系、計(jì)算分區(qū)號(hào)的位移（即上圖中的m）。

????????賬戶、容器和對(duì)象的尋址過程。（以對(duì)象的尋址過程為例）：

以對(duì)象的層次結(jié)構(gòu) account/container/object 作為鍵，采用 MD5 散列算法得到一個(gè)散列值；
對(duì)該散列值的前 4 個(gè)字節(jié)進(jìn)行右移操作（右移m位），得到分區(qū)索引號(hào)；
在分區(qū)到設(shè)備映射表里，按照分區(qū)索引號(hào)，查找該對(duì)象所在分區(qū)對(duì)應(yīng)的所有物理設(shè)備編號(hào)。如下圖：

2.4.5 Swift的一致性設(shè)計(jì)

Swift 采用 Quorum 仲裁協(xié)議

定義：N：數(shù)據(jù)的副本總數(shù)；W：寫操作被確認(rèn)接受的副本數(shù)量；R：讀操作的副本數(shù)量
強(qiáng)一致性：R+W>N，就能保證對(duì)副本的讀寫操作會(huì)產(chǎn)生交集，從而保證可以讀取到最新版本；
弱一致性：R+W<=N，讀寫操作的副本集合可能不產(chǎn)生交集，此時(shí)就可能會(huì)讀到臟數(shù)據(jù)；

????????Swift 默認(rèn)配置是N=3，W=2，R=2，即每個(gè)對(duì)象會(huì)存在 3 個(gè)副本，至少需要更新 2 個(gè)副本才算寫成功；如果讀到的2個(gè)數(shù)據(jù)存在不一致，則通過檢測(cè)和復(fù)制協(xié)議來完成數(shù)據(jù)同步。

????????如R=1，就可能會(huì)讀到臟數(shù)據(jù)，此時(shí)，通過犧牲一定的一致性，可提高讀取速度，（而一致性可以通過后臺(tái)的方式完成同步，從而保證數(shù)據(jù)的最終一致性）

????????Quorum 協(xié)議示例如下所示：

2.4.6 Swift特點(diǎn)

原生的對(duì)象存儲(chǔ)，不支持實(shí)時(shí)的文件讀寫、編輯功能
完全對(duì)稱架構(gòu)，無主節(jié)點(diǎn)，無單點(diǎn)故障，易于大規(guī)模擴(kuò)展，性能容量線性增長(zhǎng)
數(shù)據(jù)實(shí)現(xiàn)最終一致性，不需要所有副本寫入即可返回，讀取數(shù)據(jù)時(shí)需要進(jìn)行數(shù)據(jù)副本的校驗(yàn)
是OpenStack的子項(xiàng)目之一，適合云環(huán)境的部署
Swift的對(duì)象存儲(chǔ)與Ceph提供的對(duì)象存儲(chǔ)區(qū)別：客戶端在訪問對(duì)象存儲(chǔ)系統(tǒng)服務(wù)時(shí)，Swift要求客戶端必須訪問Swift網(wǎng)關(guān)才能獲得數(shù)據(jù)。而Ceph可以在每個(gè)存儲(chǔ)節(jié)點(diǎn)上的OSD（對(duì)象存儲(chǔ)設(shè)備）獲取數(shù)據(jù)信息；在數(shù)據(jù)一致性方面，Swift的數(shù)據(jù)是最終一致，而Ceph是始終跨集群強(qiáng)一致性）

2.5 Lustre分布式存儲(chǔ)

????????Lustre是基于Linux平臺(tái)的開源集群（并行）文件系統(tǒng)，最早在1999年由皮特?布拉姆創(chuàng)建的集群文件系統(tǒng)公司（Cluster File Systems Inc.）開始研發(fā)，后由HP、Intel、Cluster File System和美國(guó)能源部聯(lián)合開發(fā)，2003年正式開源，主要用于HPC超算領(lǐng)域。

2.5.1 Lustre的主要架構(gòu)

Lustre組件包括：

管理服務(wù)器(MGS)：存放集群中所有Lustre文件系統(tǒng)的配置信息，Lustre客戶通過聯(lián)系MGS獲取信息，可以與MDS共享存儲(chǔ)空間
元數(shù)據(jù)服務(wù)器(MDS): 管理存儲(chǔ)在MDT中的元數(shù)據(jù)，使存儲(chǔ)在一個(gè)或多個(gè)MDT中的元數(shù)據(jù)可供Lustre客戶端使用，每個(gè)MDS可管理一個(gè)或多個(gè)MDT。
元數(shù)據(jù)目標(biāo)(MDT): MDS用于存儲(chǔ)元數(shù)據(jù)(例如文件名，目錄，權(quán)限和文件布局)，一個(gè)MDT可用于多個(gè)MDS，但一次只能有一個(gè)MDS訪問
對(duì)象存儲(chǔ)服務(wù)器(OSS)：為一個(gè)或多個(gè)本地OST提供文件I / O服務(wù)和網(wǎng)絡(luò)請(qǐng)求處理, 通常，OSS服務(wù)于兩個(gè)到八個(gè)OST
對(duì)象存儲(chǔ)目標(biāo)(OST)：用戶文件數(shù)據(jù)存儲(chǔ)在一個(gè)或多個(gè)對(duì)象中，每個(gè)對(duì)象位于單獨(dú)OST中
Lustre客戶端：運(yùn)行Lustre客戶端軟件的計(jì)算節(jié)點(diǎn)，可掛載Lustre文件系統(tǒng)?？蛻舳塑浖ㄒ粋€(gè)管理客戶端(MGC)，一個(gè)元數(shù)據(jù)客戶端(MDC)和多個(gè)對(duì)象存儲(chǔ)客戶端(OSC)。每個(gè)OSC對(duì)應(yīng)于文件系統(tǒng)中的一個(gè)OST。
邏輯對(duì)象卷(LOV)通過聚合OSC以提供對(duì)所有OST的透明訪問，邏輯元數(shù)據(jù)卷(LMV)通過聚合MDC提供一種對(duì)所有MDT透明的訪問。

2.5.2 Lustre特點(diǎn)

支持?jǐn)?shù)萬個(gè)客戶端系統(tǒng)，支持PB級(jí)存儲(chǔ)容量，單個(gè)文件最大支持320TB容量
支持RDMA網(wǎng)絡(luò)，大文件讀寫分片優(yōu)化，多個(gè)OSS能獲得更高的聚合帶寬
缺少副本機(jī)制，存在單點(diǎn)故障。如果一個(gè)客戶端或節(jié)點(diǎn)發(fā)生故障，存儲(chǔ)在該節(jié)點(diǎn)上的數(shù)據(jù)在重新啟動(dòng)前將不可訪問
適用高性能計(jì)算HPC領(lǐng)域，適用于大文件連續(xù)讀寫。

2.6 主流分布式存儲(chǔ)技術(shù)的比較

????????幾種主流分布式存儲(chǔ)技術(shù)的特點(diǎn)比較如下：

? ? ? ? ?此外，根據(jù)分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)理念，其軟件和硬件解耦，分布式存儲(chǔ)的許多功能，包括可靠性和性能增強(qiáng)都由軟件提供，因此大家往往會(huì)認(rèn)為底層硬件已不再重要。但事實(shí)往往并非如此，我們?cè)谶M(jìn)行分布式存儲(chǔ)系統(tǒng)集成時(shí)，除考慮選用合適的分布式存儲(chǔ)技術(shù)以外，還需考慮底層硬件的兼容性。一般而言，分布式存儲(chǔ)系統(tǒng)的產(chǎn)品有三種形態(tài)：軟硬件一體機(jī)、硬件OEM和軟件+標(biāo)準(zhǔn)硬件，大家在選擇時(shí)，需根據(jù)產(chǎn)品的成熟度、風(fēng)險(xiǎn)規(guī)避、運(yùn)維要求等，結(jié)合自身的技術(shù)力量等，選擇合適的產(chǎn)品形態(tài)。