副本放置演算法

1、raft協議原理

raft

2、單個shard的複製

raft-single
3、Raft group組

raft-group
在一定情況下， copyset的數量不是越多越好，在恢復時間確定的情況下，找到合適的copyset的數量可以降低資料丟失的機率。為了提高儲存系統資料可靠性，首先在系統允許的成本範圍內選擇合適的副本數，再次在系統設計中我們首先優先考慮加快資料恢復時間，在此基礎上減小系統的copyset數量。使得在既定的成本下達到儘可能高的可靠性。參考論文《Copysets:Reducing the Frequency of Data Loss in Cloud Storage》，該論文中的實驗資料顯示，在facebook HDFS叢集上作實驗，為了有效降低資料丟失機率，資料放置演算法，從原來的Random Replicaiton更改為copyset Replication 演算法，實驗結果說明可 將FaceBook HDFS叢集1%節點故障時的資料丟失機率從22.8%降低道0.78%。
在大型叢集中，多個節點的同時丟失具有很高的資料丟失機率。例如，考慮使用副本數為 3的100個節點的群集，其shard數範圍約為10k。同時丟失2個或更多節點具有很高的資料丟失機率，因為可能存在10k shard之外的shard，而該shard在2個丟失的節點上具有3個副本中的2個。在存在多節點故障的情況下，copyset演算法可以顯著降低了資料丟失的可能性。
根據系統節點數，和副本數量，進行多個輪次的計算，每一輪次把所有節點按照副本數劃分為 N／R 個copyset。每次確保其中的copyset 不與當前和之前所有輪次中已經產生的copyset相同，最後資料寫入的時候，選擇一個copyset 寫入即可。由於每個排列會吧S(Scatter Width)  增加R-1,所以 演算法執行P = S/（R-1） 次， K(CopySet數量) = P  (N/R) = S/(R-1) (N/R)。
複製集將群集分為不相交的節點集。每組的大小將基於使用的副本數。為每個副本建立單獨的副本集。 shard應該更喜歡在副本集中分配其副本，而不是在副本集中散佈其副本。

所以有兩個主要組成部分：

1.管理副本集（哪個節點屬於哪個副本集）副本集分配應考慮節點的位置，以便不會丟失位置容錯能力。將節點分配給副本集時，應考慮新增/刪除/損壞的節點。
2.重新平衡範圍中的所有副本，以盡最大努力將其駐留在單個副本集中。將副本重新平衡到副本集很重要，但是某些屬性（如使用者設定的約束）應優先於副本集。
副本集最初將是一個選擇加入功能（基於群集設定），並且實現為分散寬度為 replication_factor - 1。

管理副本集

該叢集將被分為多個副本集。對於群集中的每個副本，將生成單獨的副本集。

副本的副本集的要求是

1.對於rf -1的散佈寬度，副本集之間的節點應該沒有重疊，並且對於散佈寬度> = rf（其中rf是複製因子），應使重疊節點最小化。
2.副本集應具有本地容錯能力
3.副本集應重新平衡節點的新增/刪除/故障。
為系統中使用的每個副本生成副本集。如果對齊了不同副本的副本集，則可以提供更好的容錯能力。
副本分配策略採用最佳副本集分割分配演算法。

特定的副本的副本集的最佳分配可以如下進行：

1.計算 num_copysets = floor(num_stores/replication_factor)
2.基於機架等特定配置進行儲存排序
3.分配副本集到儲存，採用輪詢排程方案（Round-robin）
例如，有如下儲存情況：
Rack1：S1 S2 S3
Rack2: S4 S5 S6
Rack3: S7 S8 S9 S10
複製因子是 3的副本集將建立：
num_copysets = 10/3 = 3
CS1: S1 S4 S7 S10
CS2: S2 S5 S8
CS3: S3 S6 S9
Swap
在源副本集和目標副本集之間進行交換，以確保源副本集的多樣性增加，而目標副本集的多樣性確實減少（或者如果減少，它仍然 >複製因子）。

基於源副本集和目標副本集中存在的位置，在源副本集和目標副本集之間進行儲存交換。交換所需的條件是：

1.源副本集的多樣性<複製因子。這意味著源副本集在特定位置具有兩個儲存。這些付出之一將是源交換候選者。
2.目標副本集具有源副本集中不存在的區域性性（我們稱此目標區域性性）。來自該地區的商店將成為目標交換候選人。
3.以下之一是正確的
4.目標副本集中不存在源交換候選的位置。

目標副本集

1.在目標位置有兩個儲存。
2.具有多樣性>複製因子。
上面的多樣性是指副本集中的位置數量。
上面的要點 3確保目標副本集的多樣性不會減少（或者如果減少，它就不會低於複製因子）。
進行交換的單個迭代會考慮所有 (n choose 2)副本集組合，其中副本集n的數量為。這些迭代將繼續進行，直到無法進一步改善所有副本集的多樣性之和為止（整個迭代都沒有找到交換物件）。
例如，考慮以下我們擁有儲存的情況：
Rack1: S1 S2 S3
Rack2: S4 S5 S6
Rack3: S7 S8 S9
Rack4: S10 S11 S12 S13
最初副本集的分配：
CS1: S1 S5 S9
CS2: S2 S6 S10
CS3: S3 S7 S11
CS4: S4 S8 S12 S13
如果儲存 S6被刪除，步驟2之後（將儲存分配到相同的副本集ID，直到大小達到rf），我們有了
CS1: S1 S5 S9
CS2: S2 S10
CS3: S3 S7 S11
CS4: S4 S8 S12
再透過新增剩餘儲存來填充空白點之後
CS1: S1 S5 S9
CS2: S2 S10 S13
CS3: S3 S7 S11
CS4: S4 S8 S12
交換之後（由於 CS1和CS2之中CS2有兩個儲存來自與rack4）
CS1: S1 S5 S13
CS2: S2 S10 S9
CS3: S3 S7 S11
CS4: S4 S8 S12
這種交換策略可能無法實現最佳的多樣性，但會嘗試確保副本集中的每個位置都不同。

副本集重新生成

考慮用於副本集分配的儲存列表將是當前的實時儲存。實時儲存的計算方式與分配器檢測實時儲存的方式相同（但不會排除受限制的儲存。）如果儲存列表穩定且未更改 3個心跳數（每個心跳聲都有），則會重新生成副本集。間隔10秒）。
副本集分配可以作為原型保留在分散式儲存層中。最小化資料移動的副本集策略要求保留副本集（它要求先前的狀態為全域性狀態並在重新啟動後仍然有效）。群集中最低的活動節點 ID將是管理（持久）副本集。其他節點將定期（每10s）快取持久化的副本集，並將其用於重新平衡。
僅當儲存列表更改時，副本集才會重新生成（並保留）。在穩定狀態下，所有節點將定期讀取持久化的副本集，而無需重新生成並持久化新的副本集。
對於 RF = 3，群集可以容忍每個副本集中一個節點的故障。例如，在最佳情況下（對於RF = 3），一個100個節點的群集可以承受33個節點的同時故障，而不會造成任何資料丟失。

重平衡範圍

範圍需要重新平衡以包含在副本集中。
HUBBLE目前使用兩種範圍再平衡器：
1.複製對略
2.儲存池管理器

對於平衡使用評分功能：

1.確定範圍內要用於新副本的儲存
2.當範圍超過所需副本數時要刪除的副本
3.副本必須從一個儲存移動到另一個儲存，該範圍的結果得分將更高

計分功能考慮一下因素（按優先順序順序排列）：

1.區域約束：在某些區域中具有某些表的約束
2.磁碟已滿：檢查儲存是否太滿
3.多樣性分數差異：多樣性分數與該範圍記憶體在的副本數所處機架的數量成正比。它基於地點的nC2多樣性分數，其中n是副本的數量。
4.收斂分數差異：收斂分數用於避免移動shard，移動shard的移動會導致shard的統計資訊偏離全域性平均值。
5.平衡分數差異：平衡分數是節點的標準化利用率，當前它考慮範圍的數量，平衡分數較低的節點是首選。
6.範圍計數差異：範圍計數較低的儲存是首選。

副本集分數

為了將 shard重新平衡到副本集中，新的副本評分將新增到分配器中。區域約束和磁碟填充比副本集得分具有更高的優先順序。
由於副本集分配考慮了多樣性，因此可以將其優先順序置於多樣性得分之上。
如果滿足一下條件，則該副本集得分較高：
1.Shard完全包含在副本集中
2.Shard所在的副本集未得到充分利用。我們希望每個副本集均被載入。如果shard在複製集中完全包含x我們應該完全移動到副本集y中。如果副本集y的節點有更低的負載，更多的可用磁碟空間等情況。

 

以上為副本機制， 「分散式技術專題」是國產資料庫 hubble 團隊精心整編，專題會持續更新，歡迎大家保持關注。