分散式儲存中的資料分佈策略

女主宣言

CRUSH 是應用於CEPH的資料分佈演算法，它是一個分層的，區分故障域的分散式演算法。在CRUSH演算法中，對於不同的物理裝置統一抽象成了bucket，每個結點都是一個bucket，其對應的物理結構各不相同。例如下圖中的root，row（機架）， cabinet（機櫃）， disk都是bucket的一種。

以下是對應的CRUSH演算法分層部分的介紹，

• 從root bucket開始, 對應Rule take(root)。

• 在下一層選擇一個row 對應Rule select(1, row)。這一層選出的是row2。

• 下一層將上一層的輸出當作這一層的輸入，遵循Rule select(3, cabinet), row2中選三個cabinet。最終的這一層輸出是cab21, cab23, cab24。

• 下一層對應Rule select(1, disk)。在cab21, cab23, cab24 中分別選一個disk。最終emit輸出是disk2107, disk2313, disk2437。

CRUSH如何實現Rule中的select N這個操作的呢？

對於每一個bucket，CRUSH的paper提供了幾種不同的選擇策略（Uniform, List, Tree, Straw）。如果有興趣的同學可以讀下論文。

這裡簡單介紹一下他的預設策略Straw：

Straw翻譯過來是抽籤，每個桶會計算其每個子節點的”引數值”，然後抽取一個最大的作為選中bucket，其”引數值”為的weight * hash。由於hash計算本身的隨機特性，雜湊值的變化會導致本來應該移動到A節點的PG，移動到了B節點。造成了額外的移動。

CEPH 的遷移是一個非常複雜的過程，涉及到其內部許多其它的機制，這裡只簡要說明與CRUSH演算法相關的步驟。CEPH 的遷移步驟概述如下：

1. 收到map的更新資訊。

2. 重新計算pg對應的osd資訊。

3. 對比之前的pg和osd的對應關係，得知如何遷移。

例如 ：

由老的map資訊計算得知 pg 101 對應的osd[1,2,3], 新的map資訊計算得知pg 101 對應osd[1,2,4], 所以遷移方向應該是從osd3到osd4

上圖是CRUSH論文中提到的資料遷移現象。由於新bucket的加入，新加入節點的上層bucket權重都會改變，在做select N操作的時候，由於hash值的存在，同樣權重的情況下選擇到了其它的分支，這樣就帶來了額外的遷移。如圖所示，流向新新增節點的pg是必要的移動，流向其他節點的pg是額外的遷移。

以上就是CRUSH的資料遷移策略。

這部分主要提出CRUSH的兩個問題，引出DPRD策略。

1、CRUSH 預設使用的straw bucket 會造成2到3倍於理論遷移率的移動。

2、對於pg分佈是否平衡文中沒有詳細的討論。

在調研階段對CRUSH進行了測試：

4(rack) * 10(host) * 10(node) 拓撲下 1024 * 3 副本

對於每個結點分配的pg比較少的情況，分佈不均勻的現象比較明顯。

2 * 10 * 2 拓撲下 1024 * 3 副本

對於每個結點分配pg比較多的情況下，分佈不均勻的現象會有一定的緩解, 但是依舊離理論值很遠。

具體測試資料位於測試資料中PG分佈平衡性測試部分。

DPRD Target：

(在分層拓撲，故障域分離情形下)

1, 副本的移動率應該儘可能的貼近理論值

2, 副本的分佈應該儘可能的貼近均勻分佈

Service：

1, 副本分佈的初始化過程

2, 擴容時副本的重新分佈

3, 縮容時副本的重新分佈

pg 和osd 是CEPH 中的概念, 對應到Zeppelin中分別為partition 和node

定義：

Factor：partition / weight

代表單位weight上所分佈的partition數量，這個數量來衡量bucket負擔是否過於重或者過於輕。partition傾向於在同一層中選擇負擔比較輕的bucket。

Base Factor: 1/ weight

partition 為1 的情況。代表移動一個partition對於Factor的影響。

Average Factor：sum of partition / sum of weight

平均的Factor引數，擴容或縮容過程中，衡量bucket是否均衡的引數。

1, 副本分佈的初始化過程

DPRD策略借鑑了CRUSH中的分層結構，從上層到下層遵循Rule依次進行partition選擇。但是，對於Select N策略，DPRD跟CRUSH有很大的區別。Select N策略中，parent bucket計運算元節點當前的“引數”值，然後選擇前N個子節點作為這次select N的輸出。所謂的引數值，在DPRD策略中是Factor（partition/weight） 代表了每個子節點的重量負擔，每一次的partition選擇都應該選擇當前負擔小的N個子節點。這樣，每一次partition都會放置到本層相對於輕的bucket中，以此來保證這一層的bucket都不會過重或者過輕。

具體的資料見 測試資料Partition初始化。

2, 擴容時副本的重新分佈

在新增bucket的時候會造成“不均衡”。

在rack2下面新增bucket會導致rack層 weight增加，以至於average factor變小。最終進行遷移之前，rack5由於本身的Factor值沒變，average factor變小，rack5有可能高於average factor“很多”。rack2 由於Factor變小幅度更大，有可能低於average factor“很多”。 這樣，由於新新增的bucket會有可能造成本層的不平衡（rack5超出average factor，rack2低於acerage factor）。下面定義DPRD中的“不平衡”概念，以及DPRD是如何實現平衡的。

定義“不均衡”

• 所謂不均衡是bucket的Factor超出average factor太多或者小於average factor太多

• 超出均值情況: factor - average_factor > base_factor

• 低於均值情況: average_factor - factor > base_factor

如下圖所示, 每一層經過均衡的過程之後，parent bucket的所有的children bucket都應該落在平衡區域內。

整體上來看, DPRD策略是從上層到下層做均衡，確保每一層都是均衡的。從root層開始，其children為rack，由於rack5高於average factor， rack2 低於average factor。DPRD策略會在rack5 子樹的node中選擇一個partition移動到rack2 中。直到rack層的每一個bucket都均衡之後，DPRD策略會再均衡下一層(host層)，直到遍歷整棵樹。

問題來了，我們應該選擇rack5種哪一個node中的哪一個partition呢？

DPRD選擇策略

Target：從rack5 子樹選出一個bucket的partition 移動到rack2中

Step1: 從rack5 children中選擇出正向偏離average factor最遠的host（host52）如下圖所示。

Step2: 遵循step1的原則向下遞迴選擇bucket，直到選擇一個node bucket。

Step3: 在node bucket中選擇一個rack2 中沒有的partition 移動到rack2。

如果沒有能夠在Step3中選擇出一個partition那麼重新回到Step1 選擇 host53，繼續流程。

至此，上文中說明了DPRD擴容的partition遷移策略。具體的測試結果位於測試資料中擴容測試部分。

3, 縮容時副本的重新分佈

最直觀的實現就是把要去除的bucket裡邊的partition從拓撲裡面全都移除掉，包括該partition在其他node上的副本。然後再從root進行副本的初始化過程。這樣會帶來3倍於理論移動率的遷移。

DPRD 的實現：

只去除需要刪除的bucket中的partition副本，同時為保障choose_n的故障域策略，需要在choose_n的那一層，在從沒有該partition副本的bucket中選擇出一個新的副本放置位置。

Step 1.記錄partition 10 在choose_n 層的位置(rack3, rack4, rack5)

Step 2. 移除要刪除的 bucket （bucket100）

Step 3. 在choose_n 層選擇一個目前沒有partition 10的bucket（rack1 或者rack2）

Step 4. 從選出的bucket 開始做副本的初始化過程。

至此，上文中介紹了DPRD縮容的partition遷移策略。具體的測試結果位於測試資料中縮容測試部分。

總結

本文提出了一種DPRD的資料分佈策略，在保證故障域分離的情況下，儘量保證資料的均勻分佈。同時本文討論了在擴容和縮容時，DPRD如何保證儘量貼近理論極限的資料遷移。

參考資料：

• github pull request（https://github.com/Qihoo360/zeppelin-client/pull/21）

• CRUSH（https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf）

• Zeppelin Source Code（https://github.com/Qihoo360/zeppelin-client）

• 淺談分散式儲存系統資料分佈方法（http://catkang.github.io/2017/12/17/data-placement.html）