原文： Inside the Magic Pocket
作者： James Cowling，在MIT就讀PhD時(shí)師從圖靈獎(jiǎng)得主Barbara Liskov
翻譯： 孫薇
責(zé)編： 錢(qián)曙光，關(guān)注架構(gòu)和算法領(lǐng)域，尋求報(bào)道或者投稿請(qǐng)發(fā)郵件qianshg@csdn.net，另有「CSDN 高級(jí)架構(gòu)師群」，內(nèi)有諸多知名互聯(lián)網(wǎng)公司的大牛架構(gòu)師，歡迎架構(gòu)師加微信qshuguang2008申請(qǐng)入群，備注姓名+公司+職位。

自從內(nèi)部使用、擴(kuò)展至EB級(jí)別的存儲(chǔ)系統(tǒng)“Magic Pocket”發(fā)布之后，我們收到了很多正面反饋。我們會(huì)繼續(xù)跟進(jìn)Magic Pocket，陸續(xù)發(fā)布一系列技術(shù)博文，從各種有趣的角度來(lái)觀(guān)察這個(gè)系統(tǒng)，包括我們的保護(hù)機(jī)制、操作工具以及軟件與硬件之間的方法創(chuàng)新。不過(guò)首先，我們需要了解一些背景：在本文中，我們會(huì)從宏觀(guān)角度對(duì)Magic Pocket的架構(gòu)以及設(shè)計(jì)標(biāo)準(zhǔn)做以概覽。

在之前的序篇中我們解釋過(guò)（注：上篇的翻譯請(qǐng)點(diǎn)擊這里查看），Dropbox存儲(chǔ)兩類(lèi)數(shù)據(jù)：文件內(nèi)容與文件/用戶(hù)的元數(shù)據(jù)。Magic Pocket是我們用來(lái)存儲(chǔ)文件內(nèi)容的系統(tǒng)，這些文件被分成塊狀存儲(chǔ)，并存有副本以保證持久化，它們分布在整個(gè)系統(tǒng)中的多個(gè)物理位置上。

雖然Magic Pocket的基礎(chǔ)是相當(dāng)簡(jiǎn)單的核心協(xié)議組，但它本身仍是龐大而復(fù)雜的系統(tǒng)，因此我們需要略過(guò)一些細(xì)節(jié)。歡迎反饋，我們會(huì)在后續(xù)文章中盡量深入探究。

注：在Dropbox內(nèi)部，這個(gè)系統(tǒng)也被稱(chēng)為“MP”，這樣我們就不用因?yàn)槔咸崞稹吧衿妫∕agic）”這個(gè)詞而感覺(jué)傻乎乎的了，本文中我們也會(huì)用MP來(lái)代指這個(gè)系統(tǒng)。

需求

不可變的數(shù)據(jù)塊存儲(chǔ)

MP是一個(gè)具有不變性的數(shù)據(jù)塊存儲(chǔ)系統(tǒng)，其中存儲(chǔ)了多達(dá)4MB的加密塊區(qū)文件，某個(gè)數(shù)據(jù)塊一旦寫(xiě)入系統(tǒng)就不會(huì)再發(fā)生變化。不變性讓一切簡(jiǎn)單得多。

當(dāng)用戶(hù)在Dropbox上對(duì)文件作出變更時(shí)，我們會(huì)在另一個(gè)單獨(dú)的系統(tǒng)中（FileJournal）記錄下所有的變更。這樣一來(lái)，通過(guò)將支持易變性的邏輯轉(zhuǎn)移到堆棧的更高層級(jí)，就能簡(jiǎn)單地存儲(chǔ)不變的數(shù)據(jù)塊了。許多大規(guī)模的存儲(chǔ)系統(tǒng)都對(duì)可變數(shù)據(jù)塊提供內(nèi)部支持，但在較低層級(jí)中一般都是基于不可變的存儲(chǔ)基元。

工作負(fù)載

Dropbox有很多數(shù)據(jù)，并具有高度的時(shí)間局部性（temporal locality）。許多數(shù)據(jù)在上傳后一個(gè)小時(shí)之內(nèi)會(huì)有頻繁的訪(fǎng)問(wèn)量，而隨著時(shí)間流逝，訪(fǎng)問(wèn)頻率也會(huì)越來(lái)越低。這種模式合乎情理：Dropbox的用戶(hù)有大量的協(xié)作任務(wù)，因此文件上傳后很可能需要同步到其它設(shè)備上。但我們?nèi)孕枰煽康目焖僭L(fǎng)問(wèn)：也許從1997年開(kāi)始你就沒(méi)怎么看過(guò)稅務(wù)記錄了，但在需要的時(shí)候，你會(huì)想要立即看到。我們有一個(gè)相當(dāng)“冷”的存儲(chǔ)系統(tǒng)，但需要以低延遲快速訪(fǎng)問(wèn)所有數(shù)據(jù)區(qū)域。

為了處理這種工作負(fù)載，我們?cè)跇?gòu)建系統(tǒng)時(shí)用到了硬盤(pán)驅(qū)動(dòng)，由于硬盤(pán)具有持久、價(jià)廉、存儲(chǔ)密集、延遲較低等優(yōu)勢(shì)，我們使用了SSD盤(pán)來(lái)保存數(shù)據(jù)庫(kù)以及緩存內(nèi)容。對(duì)于新近上傳的內(nèi)容，我們使用了高度的初始復(fù)制與緩存技術(shù)；而對(duì)于其余的數(shù)據(jù)，我們使用了更為高效的存儲(chǔ)編碼技術(shù)。

持久性

在MP中，持久性是必備的。理論上，我們要求系統(tǒng)的持久性能保持到地老天荒，除非小行星導(dǎo)致天災(zāi)——我們有更重要的事情要操心，不能因?yàn)殡S機(jī)的磁盤(pán)故障就出現(xiàn)數(shù)據(jù)損毀的問(wèn)題。這些數(shù)據(jù)以效率更高的糾刪碼（erasure-coded）形式存儲(chǔ)，同時(shí)還使用了跨區(qū)（地理位置）高度復(fù)制以保障在災(zāi)難或自然災(zāi)害發(fā)生時(shí)數(shù)據(jù)的安全性。

規(guī)模

對(duì)工程師來(lái)說(shuō)，這個(gè)部分非常有趣，MP必須在差不多半年的時(shí)間里，從初始數(shù)十PB的原型成長(zhǎng)到EB級(jí)別的龐然大物，這可真是空前的轉(zhuǎn)變。因此，我們需要花費(fèi)大量時(shí)間來(lái)思考、設(shè)計(jì)、構(gòu)建原型，以克服能預(yù)見(jiàn)到的瓶頸問(wèn)題。在這個(gè)過(guò)程中，我們也確認(rèn)了這個(gè)架構(gòu)完全可以擴(kuò)展，因此在出現(xiàn)不可預(yù)知的需求時(shí)，也能進(jìn)行相應(yīng)的修改。

關(guān)于不可預(yù)知的需求，其實(shí)有很多例子：比如流量突然增長(zhǎng)，網(wǎng)絡(luò)集群間的路由器工作負(fù)載逐漸飽和。因此，我們需要修改數(shù)據(jù)存放的算法以及路徑請(qǐng)求，以便更好地反映集群間的關(guān)聯(lián)（以及可用存儲(chǔ)量、集群成長(zhǎng)計(jì)劃等），并最終為集群間的網(wǎng)絡(luò)架構(gòu)帶來(lái)改變。

簡(jiǎn)單性

是個(gè)工程師都知道，復(fù)雜性通常會(huì)導(dǎo)致不可靠性。有很多人在花費(fèi)大量時(shí)間編寫(xiě)復(fù)雜的一致性協(xié)議后發(fā)現(xiàn)：在Paxos算法的重實(shí)現(xiàn)上浪費(fèi)一整天可不是什么好主意。MP盡可能避免了quorum一致或分布式協(xié)作的情況，并在使用容錯(cuò)及可伸縮方式時(shí)大量利用集中的協(xié)作點(diǎn)。有時(shí)在數(shù)據(jù)塊索引（Block Index）中，我們可以選擇分布式哈希表或trie樹(shù)，而不僅是巨大的分片MySQL集群。這一決策在簡(jiǎn)化開(kāi)發(fā)與減少未知因素方面表現(xiàn)非常優(yōu)秀。

數(shù)據(jù)模型

在討論架構(gòu)自身之前，我們先來(lái)研究一下所存儲(chǔ)的內(nèi)容。

在Dropbox的MP系統(tǒng)中，存儲(chǔ)的是最大4MB的文件數(shù)據(jù)塊：

經(jīng)過(guò)壓縮加密后，這些數(shù)據(jù)塊（block）被發(fā)送到MP中進(jìn)行存儲(chǔ)，每個(gè)數(shù)據(jù)塊都需要一個(gè)鍵值或者名稱(chēng)，大多情況下我們會(huì)使用SHA-256哈希。

然而在EB級(jí)別的存儲(chǔ)系統(tǒng)中，4MB的數(shù)據(jù)量猶如滄海一粟，如果需要替換磁盤(pán)或者對(duì)某些數(shù)據(jù)使用糾刪碼技術(shù)，這個(gè)大小就顯得太小了。為了簡(jiǎn)化這個(gè)問(wèn)題，我們將這些數(shù)據(jù)塊整合成1GB大小的邏輯存儲(chǔ)容器，稱(chēng)為bucket。指定bucket中的數(shù)據(jù)塊無(wú)需有什么相同的特性，只是上傳的時(shí)間差不多相同。

為了保證可靠性，我們需要將這些bucket復(fù)制到多臺(tái)物理機(jī)器上，新近上傳的數(shù)據(jù)塊可直接復(fù)制到多臺(tái)機(jī)器上。最終系統(tǒng)會(huì)將包含數(shù)據(jù)塊的bucket整合到一起，再通過(guò)糾刪碼技術(shù)提高存儲(chǔ)的效率。我們使用volume來(lái)指代復(fù)制到一系列物理存儲(chǔ)節(jié)點(diǎn)的一個(gè)或多個(gè)bucket。

總結(jié)一下：數(shù)據(jù)塊可通過(guò)哈希進(jìn)行識(shí)別，并且要寫(xiě)入bucket中。每個(gè)bucket都存儲(chǔ)在volume中，volume分布在多臺(tái)機(jī)器上，這些bucket或是復(fù)制的，或是糾刪碼形式的。

架構(gòu)

那么現(xiàn)在我們了解了自身需求與數(shù)據(jù)模型，實(shí)際中MP又到底是什么樣子呢？其實(shí)有些類(lèi)似下圖這樣：

也許看似簡(jiǎn)單，卻非常重要。MP是一種多區(qū)域的架構(gòu)，其服務(wù)器集群分別位于美國(guó)的西區(qū)、中區(qū)和東區(qū)。MP的每個(gè)數(shù)據(jù)塊都會(huì)分別存儲(chǔ)在至少兩個(gè)獨(dú)立的區(qū)域中，然后在這些區(qū)中再進(jìn)行可靠的復(fù)制。這種冗余備份不僅很好地避免了因自然災(zāi)害或大規(guī)模停電而產(chǎn)生的問(wèn)題，還允許我們建立非常清晰的管理區(qū)域與虛擬邊界，避免因跨區(qū)級(jí)聯(lián)而造成錯(cuò)誤配置或者網(wǎng)絡(luò)崩潰。

針對(duì)訪(fǎng)問(wèn)量較少（較冷）的那些數(shù)據(jù)，我們采用了與上述架構(gòu)不同的多區(qū)域架構(gòu)。

神奇的地方多在各區(qū)域內(nèi)出現(xiàn)，我們繼續(xù)往下看：

下面我們對(duì)上圖的組件一一進(jìn)行講解。

前端（Frontends）

這些節(jié)點(diǎn)負(fù)責(zé)從系統(tǒng)外部接收存儲(chǔ)請(qǐng)求，它們是MP的網(wǎng)關(guān)，負(fù)責(zé)確認(rèn)某個(gè)數(shù)據(jù)塊應(yīng)當(dāng)存儲(chǔ)在什么地方，并在MP內(nèi)部發(fā)布讀取/寫(xiě)入數(shù)據(jù)塊的命令。

數(shù)據(jù)塊索引（Block Index）

這項(xiàng)服務(wù)將每個(gè)數(shù)據(jù)塊映射到相應(yīng)的存儲(chǔ)bucket中，我們可以將其視為如下結(jié)構(gòu)的大型數(shù)據(jù)庫(kù)：

hash → cell, bucket, checksum
其真實(shí)結(jié)構(gòu)要比上面的簡(jiǎn)化版稍微復(fù)雜些，還需要支持類(lèi)似刪除、跨區(qū)復(fù)制等操作。

數(shù)據(jù)塊索引是一個(gè)巨大的分片MySQL集群，以RPC服務(wù)層為前端，再加上許多操作數(shù)據(jù)庫(kù)和確保數(shù)據(jù)庫(kù)可靠性的工具。起初我們計(jì)劃建立一個(gè)專(zhuān)門(mén)的鍵值存儲(chǔ)庫(kù)，不過(guò)MySQL完全能勝任這一職責(zé)。我們已有數(shù)以千計(jì)跨Dropbox堆棧的數(shù)據(jù)庫(kù)節(jié)點(diǎn)可提供服務(wù)，因此也能規(guī)模化地管理MySQL。

最終建立的系統(tǒng)可能略有些復(fù)雜，不過(guò)到目前為止我們都很滿(mǎn)意。鍵值存儲(chǔ)方式十分流行，性能表現(xiàn)優(yōu)秀，但數(shù)據(jù)庫(kù)有著高度的可靠性，所提供的數(shù)據(jù)模型讓我們今后能容易地對(duì)結(jié)構(gòu)和功能進(jìn)行擴(kuò)展。

跨區(qū)復(fù)制（Cross-zone replication）

跨區(qū)復(fù)制的后臺(tái)程序負(fù)責(zé)異步執(zhí)行操作，將一個(gè)區(qū)的所有數(shù)據(jù)塊復(fù)制到另一個(gè)區(qū)中。在數(shù)據(jù)上傳后一秒之內(nèi)，系統(tǒng)就會(huì)將各個(gè)數(shù)據(jù)塊寫(xiě)入遠(yuǎn)程區(qū)域。我們將這種復(fù)制延遲作為持久性模型的一部分，并確保在本地區(qū)域內(nèi)對(duì)數(shù)據(jù)進(jìn)行了足夠廣泛的復(fù)制。

單元（Cells）

每個(gè)單元都是獨(dú)立的邏輯存儲(chǔ)集群，存儲(chǔ)著約50PB的原始數(shù)據(jù)。一般我們想給MP增加容量時(shí)，就會(huì)添加新的單元。由于各單元在邏輯上完全獨(dú)立，各個(gè)單元分布在各個(gè)機(jī)架上，以確保每個(gè)單元的物理多樣性最大化。

下面我們來(lái)深入探究一下其工作原理：

對(duì)象存儲(chǔ)設(shè)備（OSD）

單元中最重要的角色就是OSD，整個(gè)磁盤(pán)上都是這種可以在單臺(tái)機(jī)器上存儲(chǔ)超過(guò)1PB數(shù)據(jù)、在各機(jī)架上存儲(chǔ)超過(guò)8PB數(shù)據(jù)的存儲(chǔ)容器。在這些設(shè)備上，緩存管理、負(fù)責(zé)磁盤(pán)調(diào)度與數(shù)據(jù)驗(yàn)證都有一些非常復(fù)雜的邏輯，不過(guò)從系統(tǒng)其他設(shè)備的角度來(lái)看，這些都屬于“傻瓜”節(jié)點(diǎn)：它們存儲(chǔ)數(shù)據(jù)塊，但并不了解單元拓?fù)浣Y(jié)構(gòu)，也不參與分布式協(xié)議。

復(fù)制表（Replication Table）

復(fù)制表是單元的索引，從數(shù)據(jù)的每個(gè)邏輯bucket映射到該bucket所存儲(chǔ)的volume與OSD上。與數(shù)據(jù)塊索引類(lèi)似，復(fù)制表是作為MySQL數(shù)據(jù)庫(kù)存儲(chǔ)的，但比MySQL數(shù)據(jù)庫(kù)要小得多，更新也遠(yuǎn)沒(méi)那么頻繁。復(fù)制表的工作集完全適用于這些數(shù)據(jù)庫(kù)中的存儲(chǔ)，賦予我們對(duì)少量物理機(jī)器的高讀取吞吐能力。

復(fù)制表的模式就像下面這樣：

bucket → volume
volume → OSDs, open, type, generation

這里有一個(gè)重要的概念就是open flag，指示著volume是“打開(kāi)”還是“關(guān)閉”，開(kāi)啟的volume只在要寫(xiě)入新數(shù)據(jù)時(shí)打開(kāi)，而關(guān)閉的volume則是保持不變的，可以在單元間安全移動(dòng)。只有很少一些volume會(huì)在任何時(shí)候都保持開(kāi)啟。

類(lèi)型（type）指定了volume的類(lèi)型：是復(fù)制的volume，還是以某種糾刪碼形式編譯的volume。生成（generation）序號(hào)則用于確保在從磁盤(pán)故障中恢復(fù)或優(yōu)化存儲(chǔ)布局時(shí)，能確保移動(dòng)的volume一致。

Master

Master被認(rèn)定是最適合單元的管理或協(xié)調(diào)程序，包含系統(tǒng)中大部分復(fù)雜的協(xié)議邏輯，主要任務(wù)就是監(jiān)控OSD，并在出現(xiàn)錯(cuò)誤時(shí)觸發(fā)數(shù)據(jù)修復(fù)操作。同時(shí)，Master也負(fù)責(zé)協(xié)調(diào)類(lèi)似創(chuàng)建新存儲(chǔ)bucket這樣的后臺(tái)操作，在刪除數(shù)據(jù)時(shí)觸發(fā)垃圾回收操作，或者在垃圾回收過(guò)后，bucket過(guò)小時(shí)對(duì)其進(jìn)行合并的操作。

復(fù)制表存儲(chǔ)了volume狀態(tài)，因此Master自身是完全soft-state的。注意：Master并不在數(shù)據(jù)層面中，其中并沒(méi)有實(shí)時(shí)的流量，如果Master宕掉的話(huà)，單元是可以繼續(xù)負(fù)責(zé)讀取的。單元甚至可以在沒(méi)有Master的情況下接收寫(xiě)入的操作，盡管最終會(huì)由于缺乏Master產(chǎn)生的新內(nèi)容，而導(dǎo)致可用存儲(chǔ)bucket耗盡的情況。如果Master沒(méi)有時(shí)間創(chuàng)建新的bucket，總會(huì)有許多其他的單元可以支持寫(xiě)入操作。

逐單元運(yùn)行單獨(dú)的Master，能夠?yàn)閺?fù)雜的數(shù)據(jù)分布決策提供集中式的協(xié)調(diào)方案，并且不會(huì)因分布式協(xié)議而導(dǎo)致情況太過(guò)復(fù)雜。這種集中式的模式確實(shí)導(dǎo)致每個(gè)單元的大小受限：在內(nèi)存與CPU開(kāi)銷(xiāo)達(dá)到瓶頸前，可以支持的容量只有大約100PB。幸好，從部署角度來(lái)看擁有多個(gè)單元也是非常方便的，可以提供更大的隔離性以避免級(jí)聯(lián)故障。

volume管理器

volume管理器負(fù)責(zé)單元的重型搬運(yùn)工作，根據(jù)Master發(fā)回的請(qǐng)求來(lái)移動(dòng)volume，或者對(duì)volume執(zhí)行糾刪。這通常意味著系統(tǒng)要讀取一大堆的OSD，向其他OSD寫(xiě)入，再將控制權(quán)交回給Master以完成操作。

volume管理器進(jìn)程運(yùn)行在與OSD相同的物理硬件上，這樣可以讓單元中閑置的存儲(chǔ)硬件分擔(dān)其繁重的網(wǎng)絡(luò)容量需求。

協(xié)議

到這里，希望大家對(duì)較高層面的MP架構(gòu)有了合理的了解。我們會(huì)對(duì)一些核心MP協(xié)議做個(gè)粗略的概覽，并在今后的系列文中再進(jìn)行詳細(xì)的闡述。不過(guò)，幸好這些協(xié)議已經(jīng)非常簡(jiǎn)單了。

Put

在接收Put請(qǐng)求前，前端便存有一些信息：它們定期與每個(gè)單元聯(lián)系，以確認(rèn)其中有多少可用空間，并包含能夠接受新寫(xiě)入請(qǐng)求的open volume列表。

當(dāng)收到Put請(qǐng)求時(shí)，前端會(huì)（通過(guò)數(shù)據(jù)塊索引）首先檢查數(shù)據(jù)塊是否存在，然后選擇存儲(chǔ)數(shù)據(jù)塊的目標(biāo)volume。volume的選擇方式如下：將單元負(fù)載均勻分擔(dān)，使得存儲(chǔ)集群之間的網(wǎng)絡(luò)流量降到最低。然后前端會(huì)詢(xún)問(wèn)復(fù)制表，以確定目前存儲(chǔ)在volume中的OSD。
前端向這些OSD發(fā)出存儲(chǔ)命令，而OSD在響應(yīng)前會(huì)fsync所有數(shù)據(jù)塊到磁盤(pán)上（或者隨身SSD上）。如果成功的話(huà)，前端會(huì)向數(shù)據(jù)塊索引增加新的條目，并向客戶(hù)端返回成功信息。如果有OSD出錯(cuò)，那么前端會(huì)嘗試其他volume（可能在另一個(gè)單元中）。如果數(shù)據(jù)庫(kù)索引出錯(cuò)，那么前端會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到另一個(gè)區(qū)域。Master會(huì)定期運(yùn)行后臺(tái)任務(wù)，清理出錯(cuò)操作部分寫(xiě)入的內(nèi)容。

雖然這里有一些細(xì)節(jié)問(wèn)題，最終還是相當(dāng)簡(jiǎn)單的。如果采用僅需前端在volume中寫(xiě)入OSD一個(gè)子集的那種基于quorum的協(xié)議，我們就能避免一些重試的問(wèn)題，并有可能實(shí)現(xiàn)低尾延遲，但會(huì)以增加復(fù)雜性為代價(jià)。在基于重試的方案中，系統(tǒng)對(duì)超時(shí)進(jìn)行合理的管理便已實(shí)現(xiàn)了低尾延遲，性能也很讓人滿(mǎn)意。

Get

一旦我們知道了Put協(xié)議，Get的過(guò)程就不言自明了。前端會(huì)從數(shù)據(jù)塊索引中查找單元與bucket，然后從復(fù)制表中查看volume與OSD，再之后從某個(gè)OSD中獲取數(shù)據(jù)塊，并在出現(xiàn)故障時(shí)進(jìn)行重試。

如前所述，我們?cè)贛P中存儲(chǔ)了復(fù)制數(shù)據(jù)與糾刪碼數(shù)據(jù)。由于volume中的每個(gè)OSD都存儲(chǔ)了所有數(shù)據(jù)塊，從復(fù)制volume中讀取數(shù)據(jù)非常簡(jiǎn)單。

從糾刪碼volume中讀取數(shù)據(jù)可能有些復(fù)雜，根據(jù)編碼的方式，每個(gè)數(shù)據(jù)塊我們都能從單個(gè)指定OSD中整體讀取，因此大多讀取請(qǐng)求都只會(huì)涉及單個(gè)磁盤(pán)，這極大地降低了我們硬盤(pán)的負(fù)載。如果OSD不可用，那么前端需要通過(guò)從其他OSD中讀取編碼數(shù)據(jù)，來(lái)重建數(shù)據(jù)塊。volume管理器會(huì)在重建方面提供協(xié)助。

在上述的編碼結(jié)構(gòu)中，前端可以從OSD1讀取Block A（以綠色圈出）。如果讀取失敗，系統(tǒng)會(huì)從其他OSD中讀取足夠數(shù)量的數(shù)據(jù)塊，用以重建Block A（以紅色圈出）。實(shí)際中編碼要更復(fù)雜一些，并且經(jīng)過(guò)了優(yōu)化——在大多數(shù)故障情況下，會(huì)從更小的OSD子集中進(jìn)行重建。

修復(fù)

Master運(yùn)行著一些不同的協(xié)議，來(lái)管理單元中的volume，并在操作出錯(cuò)時(shí)執(zhí)行清理，但Master所執(zhí)行的最重要操作是修復(fù)。

修復(fù)是用來(lái)在磁盤(pán)出錯(cuò)時(shí)重新復(fù)制volume的操作，Master會(huì)繼續(xù)通過(guò)我們的服務(wù)探測(cè)系統(tǒng)監(jiān)控OSD的健康性，并在OSD離線(xiàn)15分鐘之后觸發(fā)修復(fù)操作——這個(gè)時(shí)間足以在不觸發(fā)不必要修復(fù)的情況下重啟一個(gè)節(jié)點(diǎn)了，但卻不足以執(zhí)行快速恢復(fù)并讓任何有漏洞的窗口最小化。

在一個(gè)單元中，volume的分布是比較隨機(jī)的，每個(gè)OSD包括幾千個(gè)volume。這代表著如果我們失去了單個(gè)OSD，是可以同時(shí)通過(guò)其它數(shù)百個(gè)OSD來(lái)重建整套volume的：

在上圖中我們失去了OSD3，但可以通過(guò)OSD 1、2、4、5來(lái)恢復(fù)volume A，volume B以及volume C。在實(shí)踐中，每個(gè)OSD有幾千個(gè)volume，它們與其它數(shù)百個(gè)OSD共享數(shù)據(jù)。這樣我們就能通過(guò)數(shù)百個(gè)網(wǎng)卡和數(shù)千個(gè)碟盤(pán)來(lái)分擔(dān)重建的流量，使得恢復(fù)時(shí)間減到最低。

當(dāng)OSD出錯(cuò)時(shí)，Master首先會(huì)關(guān)閉OSD上的所有volume，并命令其它OSD在本地反映出這一變化?，F(xiàn)在volume關(guān)閉，我們知道它們不會(huì)再接受寫(xiě)入操作，因此可以安全地移動(dòng)。
然后Master創(chuàng)建了重建計(jì)劃，選擇一組OSD作為復(fù)制源頭，另一組作為復(fù)制目標(biāo)，通過(guò)這樣的方式將負(fù)載分布到盡可能多的OSD上。這一步可以避免在特定磁盤(pán)或機(jī)器上出現(xiàn)流量峰值。重建計(jì)劃讓我們?cè)诿總€(gè)OSD硬件配置上的花費(fèi)減到最低，不過(guò)若沒(méi)有將Master作為協(xié)調(diào)的中心點(diǎn)的話(huà)，將很難產(chǎn)生。

我們會(huì)讓數(shù)據(jù)傳輸進(jìn)程盡可能平滑，不過(guò)其中的volume管理器要負(fù)責(zé)將數(shù)據(jù)從源頭復(fù)制到目標(biāo)，在必要時(shí)進(jìn)行糾刪，然后將控制權(quán)返給Master。

最后的步驟相對(duì)簡(jiǎn)單一些，但卻很重要：此刻在源與目標(biāo)OSD上都存在有volume，但尚未執(zhí)行移動(dòng)。如果Master此時(shí)出錯(cuò)，volume會(huì)存在原來(lái)的位置，等待新的Master來(lái)修復(fù)。為了完成修復(fù)操作，Master首先要修改新OSD上的volume生成序號(hào)，然后更新復(fù)制表以便在新生成時(shí)（提交點(diǎn)）存儲(chǔ)新的volume-OSD映像?，F(xiàn)在隨著生成序號(hào)遞增，我們知道哪個(gè)volume在哪個(gè)OSD里，這一點(diǎn)將不會(huì)產(chǎn)生混淆，即便出錯(cuò)的OSD恢復(fù)了活動(dòng)。

這個(gè)協(xié)議確保任何時(shí)候在任何節(jié)點(diǎn)出錯(cuò)時(shí)，都不會(huì)導(dǎo)致系統(tǒng)出現(xiàn)不一致的狀態(tài)。在生產(chǎn)環(huán)境中我們見(jiàn)過(guò)各種類(lèi)型的案例，其中一例中，數(shù)據(jù)庫(kù)前端停滯了整整一個(gè)小時(shí)，之后恢復(fù)并向復(fù)制表轉(zhuǎn)發(fā)請(qǐng)求，期間Master也出錯(cuò)并重啟，發(fā)出了一套完全不同的修復(fù)操作，我們的一致性協(xié)議需要在面對(duì)這類(lèi)故障時(shí)也完全可靠。Master還運(yùn)行著很多其他的后臺(tái)進(jìn)程，比如Reconcile進(jìn)程，它會(huì)確認(rèn)OSD狀態(tài)，并回滾出錯(cuò)的修復(fù)進(jìn)程或者未完成的操作。

開(kāi)放或閉合的volume模型是確保實(shí)時(shí)流量不會(huì)干擾后臺(tái)操作的關(guān)鍵，讓我們得以使用更為簡(jiǎn)單的一致性協(xié)議。

封裝

感謝閱讀本文，希望能讓大家對(duì)MP的工作原理以及我們的一些設(shè)計(jì)動(dòng)機(jī)有些了解。

這里主要的設(shè)計(jì)原則在于保持簡(jiǎn)單性！設(shè)計(jì)分布式存儲(chǔ)系統(tǒng)是很大的挑戰(zhàn)，不過(guò)構(gòu)建一個(gè)能夠大規(guī)模執(zhí)行可靠操作的分布式存儲(chǔ)系統(tǒng)\支持所有監(jiān)控與驗(yàn)證系統(tǒng)還有工具，確保其正常運(yùn)行更是困難得多。為對(duì)的問(wèn)題給出正確的解決方案，在進(jìn)行技術(shù)決策方面也有著非同尋常的重要性。MP大部分都是由一支不足6人的團(tuán)隊(duì)完成構(gòu)建的，這要求我們將精力放在重要的事情上，所有人都要在項(xiàng)目成功上起到重要的作用。

很明顯有很多細(xì)節(jié)本文沒(méi)有提及，有些問(wèn)題可能尚未涉及，不過(guò)我們已經(jīng)在考慮這些問(wèn)題了。在今后的博文中，我們會(huì)就大規(guī)模構(gòu)建與運(yùn)行系統(tǒng)的細(xì)節(jié)問(wèn)題進(jìn)行更細(xì)致的討論，敬請(qǐng)期待。