分散式儲存中的資料分佈策略
女主宣言
本文提出一種分層的資料放置策略DPRD。DPRD主要應用於分散式儲存系統中,目前DPRD應用於Zeppelin中。DPRD策略的想法脫胎於CRUSH演算法,吸取了CRUSH演算法中最顯著的故障域分離的特性,同時對擴容和縮容場景做出了效果顯著的最佳化。
CRUSH簡介
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節點。造成了額外的移動。
CRUSH 遷移策略
CEPH 的遷移是一個非常複雜的過程,涉及到其內部許多其它的機制,這裡只簡要說明與CRUSH演算法相關的步驟。CEPH 的遷移步驟概述如下:
收到map的更新資訊。
重新計算pg對應的osd資訊。
對比之前的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的資料遷移策略。
Is CRUSH Perfect? Em……NO!
這部分主要提出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來了!
DPRD Target:
(在分層拓撲,故障域分離情形下)
1, 副本的移動率應該儘可能的貼近理論值
2, 副本的分佈應該儘可能的貼近均勻分佈
Service:
1, 副本分佈的初始化過程
2, 擴容時副本的重新分佈
3, 縮容時副本的重新分佈
DPRD 策略
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()
CRUSH()
Zeppelin Source Code()
淺談分散式儲存系統資料分佈方法()
HULK一線技術雜談
由360雲平臺團隊打造的技術分享公眾號,內容涉及雲端計算、資料庫、大資料、監控、泛前端、自動化測試等眾多技術領域,透過夯實的技術積累和豐富的一線實戰經驗,為你帶來最有料的技術分享
原文連結:https://mp.weixin.qq.com/s/-OgxpAz6Zz817N9hfK8njQ
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31555491/viewspace-2221151/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 淺談分散式儲存系統的資料分佈演算法分散式演算法
- 大資料分散式儲存的部署模式:分離式or超融合大資料分散式模式
- 分散式系統中的資料儲存方案實踐分散式
- 分散式資料恢復-hbase+hive分散式儲存資料恢復方案分散式資料恢復Hive
- DAOS 分散式非同步物件儲存|資料平面分散式非同步物件
- ceph解讀:crush分散式資料分佈的問題分散式
- 「分散式技術專題」資料分佈(原理、資料分片)分散式
- 【大資料】BigTable分散式資料儲存系統分散式資料庫 | 複習筆記大資料分散式資料庫筆記
- 10分鐘搞懂:億級使用者的分散式資料儲存解決方案!分散式
- Redis 分散式儲存Redis分散式
- HDFS分散式儲存分散式
- 分散式儲存概述分散式
- 分散式系統技術:儲存之資料庫分散式資料庫
- 分散式文件儲存資料庫之MongoDB索引管理分散式資料庫MongoDB索引
- 分散式文件儲存資料庫之MongoDB副本集分散式資料庫MongoDB
- 星環科技多模型資料統一儲存的大資料分散式儲存平臺方案分享模型大資料分散式
- Hadoop HDFS 3.3.1分散式儲存搭建Hadoop分散式
- 大資料儲存解決方案中的分離式與超融合部署大資料
- 【融雲分析】從過剩儲存資源到分散式時序資料庫的長儲存分散式資料庫
- pgsql資料庫的表儲存策略原理SQL資料庫
- 分散式文件儲存資料庫之MongoDB分片叢集分散式資料庫MongoDB
- 分散式文件儲存資料庫之MongoDB訪問控制分散式資料庫MongoDB
- 崑崙分散式資料庫儲存叢集 Fullsync 機制分散式資料庫
- Hadoop 分散式儲存分散式計算Hadoop分散式
- iOS中的資料儲存iOS
- GlusterFS分散式儲存資料的恢復機制(AFR)的說明分散式
- DAOS 分散式非同步物件儲存|儲存模型分散式非同步物件模型
- 分散式儲存ceph 物件儲存配置zone同步分散式物件
- 《資料儲存》之《分庫,分表》
- Vsan資料恢復—Vsan分散式儲存資料恢復案例資料恢復分散式
- 分散式文件儲存資料庫之MongoDB基礎入門分散式資料庫MongoDB
- 分散式塊儲存 ZBS 的自主研發之旅|後設資料管理分散式
- 分離式or超融合,分散式儲存建設時的兩種部署模式分散式模式
- 分散式儲存轉崗記分散式
- 分散式儲存技術概念分散式
- 分散式 PostgreSQL 叢集(Citus),分散式表中的分佈列選擇最佳實踐分散式SQL
- Gartner:浪潮儲存進入分散式儲存前三分散式
- 分散式系統中資料儲存方案實踐分散式