分散式儲存高可用設計

 

一、背景

      面對著業務的發展，不管是線上，近線還是離線系統，其所需要的儲存規模以及儲存成本，成倍上漲。如果還是採取傳統的分散式儲存管理方式，不但帶來高昂的管理分散式儲存的成本，而且還會增加儲存成本。

因此，我們極需要有一種即高效且省成本的資料儲存以及儲存管理方式。自然的，我們把目光聚焦在了分散式儲存系統上。

      從目前行業發展趨勢來看，各大網際網路公司都設計或者維護了自己的分散式儲存系統。如Google的GFS（Colossus 為GFS第二代分散式儲存系統），Facebook和LinkedIn的HDFS等。因此，分散式儲存也是大勢所越趨，目前社群上非常火爆的開源分散式儲存軟體Ceph，就是OpenStack的一朵奇葩。各大傳統廠商如Intel，Red Hat，San Disk等紛紛加盟，正愈演愈烈，有望成為儲存領域的“Linux”。

      我們也緊跟開源社群，不斷吸收其優秀成果，並對Ceph做了大量的研究，測試和驗證。另外，我們根據業務場景，也進行了深入的原始碼開發和軟硬體最佳化，在分散式儲存開源領域正與社群積極合作，為集團業務的發展賦能。

分散式儲存系統所具備的優點就是為了克服傳統儲存方式的缺點。那麼，它將會給我們帶來哪些收益呢？

二、分散式儲存的收益

    分散式儲存系統所帶來的收益主要體現在以下幾個方面。總體上來講，主要是降低儲存成本，同時也提高了資源的分配效率，助力計算資源的彈性排程：

2.1解除機型配比

    一般性的，我們將伺服器分為兩部分，計算資源和儲存資源。計算資源如CPU和記憶體，計算資源的特點就是無狀態，資源分配比較靈活。儲存資源有狀態，需要保證資料的一致性和永續性，資源分配比較固定，會涉及到資料的遷移。如果資料量太大，就會遇到遷移效能的問題。

傳統的儲存方式，是單臺伺服器型別的，將計算資源與儲存資源（HHD和SSD等儲存裝置）繫結在一起。因此一臺機器CPU，記憶體與儲存裝置比值都是固定的。這帶來的一個問題，就是我們會比較頻繁的改變我們的機型，因每年我們的計算資源與儲存資源的配比都在變化，業務資料的增長非常快。這也在某種程度上提高了每年採購機器的成本。

引入分散式儲存系統後，解除了這兩者緊密耦合的現狀，使得降低儲存成本成為了可能。計算資源和儲存資源解耦後，各自可以按不同的策略進行過保，在一定程度上降低了成本。

2.2解決儲存碎片

    傳統分散式的儲存模型，必然會有儲存碎片問題的儲存。因為每臺伺服器都會為線上業務預留一定的儲存空間，以滿足將來業務資料增長的需要。但是採用預留空間的方式會有一個問題，就是我們無法準確的評估真實的實際空間需求，往往預留的會比較多，業務實際需求與預留空間這兩者的差距就是儲存空間浪費量。

這些伺服器殘留了獨立的10G，20G等空間碎片，在一定程度上也並不能滿足業務例項申請的規格，但將這些碎片合併在一起就能滿足業務所需。

引入分散式儲存系統後，大大減少這種碎片，業務實際的資料儲存空間按需進行動態分配。我們引入資料增長趨勢分析，每天或者每週進行儲存線上動態擴容，以提高管理效率，降低儲存成本。

2.3計算資源彈性

    傳統資源配置下，我們的計算資源排程水平受限於單臺機器的儲存容量。在制定Docker容器化規格時，連同儲存容量一起考慮，其排程和資源分配演算法異常複雜。當CPU，記憶體以及儲存容量這三者在某種程度上發生衝突時，往往會犧牲一定的儲存資，來達成Docker例項規格的妥協。

將計算資源與儲存資源分離後，計算資源得到解脫。我們在安排機器的過保時，採用不同的策略，降低機器採購成本。另外，計算資源是無狀態的，獨立之後，進行容器化，就可以方便的進行排程，提高效率。

2.4解決差異化需求

    某些新星業務，往往會呈現爆發式增長。自然而然，其資料量也會呈跳躍式的爆炸。此時對儲存的規格的需求就會比較大，因為業務短時間內往往來不及做架構最佳化，或者做資料分片來降低單機的資料儲存容量。這會給傳統的儲存模型帶來非常的挑戰，因為傳統的分散式的單臺伺服器的儲存容量已經不能滿足需求。

分散式儲存系統破除了這種大儲存容量例項規格的天花板限制，業務不再關心底層儲存的實現，我們根據業務資料的增長趨勢分析，動態擴充套件儲存空間。

三、面臨的問題

     儘管分散式儲存有上述的諸多優點，然而如何設計其高可用性，如何減少資料丟失的機率，是擺在我們面前必須要去克服的問題。那麼我們又是如何來架構和設計的呢？ 3.1資料丟失

在分散式檔案系統中，為了防止單機故障而造成資料丟失，往往會引入多個資料副本，我們稱之為replica set。此replica set中資料的副本個數用R來表示。一般的，R等於3，就表示是這份資料的儲存份數是“3”，也就是我們通常所說的 3-way replication。

     在隨機的模式下，有可能replica set的3份資料位於同一個RAC中，那麼當此RAC掉電就會導致資料丟失，對線上業務造成影響。隨著叢集規模的變大，如果有超過1%的資料節點遭遇斷電，並且斷電之後又有一部分機器重起失敗，或者程式異常導致資料檔案損壞；那麼其影響都將隨著叢集規模的增長而變得異常嚴重，成為分散式儲存系統致命的問題。

當然，我們可能透過增加資料的副本數即“replica set size“，來降低資料丟失的機率。又或者提高底層IDC以及網路的高可用性，減少斷網或者網路故障發生的機率。但是這些方法都是繞開問題的本質來最佳化的，另外帶來的儲存成本的增長也是不能接受的。

    早期，Facebook和LinkedIn在使用HDFS時，也同樣面臨這樣的問題，也做了這方面不少的驗證和測試。最終較為一個合理的方案就是透過合理安排replica set中資料儲存的位置來降低資料丟失的可能性。 3.2資料散射度

為了能夠更好的理解資料副本儲存位置（data locality），我們引入資料散射度（scatter width）的概念。怎麼來理解資料散射度？

假設一個叢集，有N個節點，資料副本replica set size為R，那麼資料散射度最差的情況就是從N個節點中任意取R個的組合數，也就是C(N,R)。我們假定N為“9”，R為“3”。

同時，我們定義三個copy set（存放的都是不同的資料）:{1，2，3}，{4，5，6}，{7，8，9}。任意一組copy set中存放的資料沒有重複，也就是說一份資料的三個副本分別放置在：{1，4，7}或者{2，5，8}或者{3，6，9}。那麼這個時候，我們稱之為其資料散射度S為“3”，遠小於隨機組合的C(9,3)。

隨機組合時，任意3臺機器Down機都會存在資料丟失。而採用Copy Set方案後，只有當{1，4，7}或者{2，5，8}或者{3，6，9}其中的任意一個組合不可用時，才會影響高可用性，才會有資料丟失。

綜上可知，我們引入copy set的目標就是儘量的降低資料散射度“S“。但是現實遠非這麼簡單，當我們降低資料散射度後，其資料恢復速度變小，也就是說恢復時間變長。因此，我們必須在資料散射度“S”和恢復速度中找到一個平衡。

四、高可用設計

    一般地，業務統一用N個“9”來表示一個分散式系統的高可用性。一般業界做得好的，都已經能達到9個“9”。那麼，我們的分佈儲存系統又如何來設計，又能達到多個“9”呢？

在設計高可用架構之前，我們先來看一下Ceph的資料儲存的拓撲結構，即CRUSH MAP。 4.1Ceph OSD Domain

Ceph預設的OSD節點bucket是基於Host的，也就是說取決於一臺機器上儲存裝置的數量。如下圖所示，一臺Host上面有4個OSD（device，如HDD或SSD等）。所以當Ceph儲存資料時，會尋找資料存放位置。首先會將Primary放入到Host0的四個節點中，即{0，1，2，3}。同一組中的OSD會根據權重進行平衡。另外兩個副本按同樣的權重計算方法放到Host1和Host2中。從總上來看，就是三份資料分別放到Host0，Host1和Host2上面，在每一個Host中資料均勻的分佈在4個OSD節點上。

當Host0中的OSD 0節點（儲存裝置）掛掉，會做兩個事情：

l 會從Host0中剩餘的OSD節點中，找可替代節點，將新增資料寫到剩餘的節點中

l 當OSD 0恢復時，會將Host0其它OSD節點中剛才新增的資料copy回OSD 0，這個叫recovery的backfill過程

我們的目的，就是減少recovery時backfill的時間。所以如果一個Host下面的OSD節點越多，就會有越多的節點參加backfill，恢復速度就會越快。一般單臺機器的儲存裝置掛載都是有限制的，我們很快就會遇到瓶頸。另外，目前的SSD 128K的寫入速度也在400-500M/s之間，跟我們的目標相比，並不算太高。

基於此，我們根據CRUSH MAP新設計了一種OSD domain，它擺脫了單臺機器的裝置掛載量限制。如下所示，其中黃色虛線框中的OSD都在同一個OSD domain中。一個OSD domain中包含4臺機器，每臺機器有4個OSD節點（儲存裝置）。此時，當一個OSD掛掉後，會有15個OSD參加新增資料的平衡和recovery的backfill，大大縮短了恢復時間。

4.2Ceph Replica Domain

在第三個章節中，我們提到了資料散射度問題，資料散射度越大，可用性越差，丟失資料的可能性越高。因此，我們怎麼來解決這個問題呢？

還是要從CRUSH MAP入手，再結合copy set的的原理來做合理架構與設計。基於上面OSD domain的設計，我們再新增replica domain，將三個不同RAC中的OSD domain組成三個copy set，用於存放replica set的三個資料副本。具體架構圖如下，這樣部署後，copy set做到了一個非常低的水平。

另外，為了節省IDC機架位資源，我們在一個叢集下分為兩個replica domain，每個replica domain下面又有3個OSD domain：

4.3泊松分佈

    到這裡，我們的CRUSH MAP架構設計差不多完成了，那麼接下來，我們來計算下這種部署能做到多個“9”呢？

在分散式儲存叢集中，X個磁碟發生故障的事件是獨立的，其機率是符合泊松分佈的。

拿磁碟來講，其MTTF為1million，因此AFR為“1-(24*365/1million)= 0.98832“，約為“0.99”。泊松分佈中，兩個重要的變數因還素X和Mean我們都確定了。對於分散式儲存池來講，X就是replica set size “R”，Mean就是“0.99”。

我們拿Ceph為例，Ceph叢集的高可用性可以簡單的按以下函式來量化：P = f(N, R, S, AFR)，其中：

l P: 丟失所有副本的機率

l R: 副本數，也就是replica set size

l S: Ceph中，Item Bucket中OSD的個數

l N: 整個Ceph 叢集中OSD的總數

l AFR: 磁碟的年平均故障率

進行演化後，我們得到可用性公式：P = Pr * M / C(N,R)，其中：

Pr：為R個資料副本同時失效的機率，在Ceph中相當於是Primary在做recovery恢復時，其它R-1個副本也Fault掉了。

M：為Ceph可能的Copy set數目

R：為replicat set size，即副本數

N：為Ceph叢集OSD總數

C(N,R)：為N個OSD節點中，取R個副本的組合數

從上面的高可用性公式可以看出，一般在給定Ceph叢集OSD節點數和副本數“R”後，C(N,R)也就確定了。那麼，為了提高可用性，我們必須想辦法降低Pr和M的值。

在Ceph系統中，儲存節點的拓撲結構，統一由CRUSH MAP來管理，因此要想改變高可用性，就得從CRUSH MAP入手。這個點，我們在上面的篇章中已經提到，而且做了架構最佳化：

l 為了降低Pr，我們引入了OSD domain，Ceph預設基於Host單機，無法發揮網路“多打一”的優勢，我們引入OSD domain，提高單個OSD恢復的速度。將原來三個OSD節點擴大到16個，恢復速度提高了5倍以上。

l 為了降低M，也就是copy set的size，我們引入了replica domain。同一個PG中所有的OSD必須在同一個replica domain中，降低了資料丟失的機率了，提高了高可用性。

以下經我們架構設計後，再根據泊松分佈計算出來的高可用性：

Ceph預設配置
N=96,S=4	R=1	R=2	R=3
C(N,R)	96	4560	142880
M	96	3072	32768
Pr	0.99	4.95E-05	1.64E-07
P	0.99	3.33E-05	3.76E-08
可用性	0	4	8
增加osd domin，提高恢復速度，降低Pr
N=96,S=16	R=1	R=2	R=3
C(N,R)	96	2556	59640
M	96	3072	32768
Pr	0.99	3.12E-06	2.59E-09
P	0.99	3.75E-06	1.42E-09
可用性	0	5	9
增加replica domain，減少replica set,減少M值
N=96,S=16	R=1	R=2	R=3
C(N,R)	96	2556	59640
M	96	1536	8192
Pr	0.99	3.12E-06	2.59E-09
P	0.99	1.87E-06	3.56E-10
可用性	0	5	10

根據這個架構設計，在同一個IDC內，我們基本上能做到接近於10個“9”的高可用性。比之於預設的演算法，高可用性整整提高了將近100倍。 4.4網路拓撲結構

根據上面的分散式拓撲結構設計，再結合現有的網路拓撲結構，我們的架構設計最終方案為：

一個Ceph叢集24臺機器，兩個replica domain，每個replica domain中有三個OSD domain，每個OSD domain中4臺機器：

2（一般為兩個，由網路交換機下掛的機器數決定）* 3（replica set，replica domain） * 4（scatter width，OSD domain）= 24

原則性的，replica domain的機器位於三個不同的RAC時，這三個RAC不能在同一個port中。一個交換裝置下掛16臺機器，兩個OSD domain，這兩個OSD domain屬於不同的replica domain。