1. 程式人生 > 其它 >StripeMerge: Efficient Wide-Stripe Generation for Large-Scale Erasure-Coded Storage

StripeMerge: Efficient Wide-Stripe Generation for Large-Scale Erasure-Coded Storage

0.Abstract

極限儲存-寬條帶 頻寬開銷巨大

StripeMerge 寬條帶生成機制

將窄條帶變成寬條帶,這個過程中是為了最小化寬條帶生成頻寬

本文工作證明了最優方案的存在,還有兩個啟發式演算法,生成時間減小87.8%

1.INTRODUCTION

為了保證data durability提出複製,但是冗餘開銷太大

RS是一種替代方案,冗餘開銷很低,但是現在還在追求更低的儲存開銷

寬條帶

極端的儲存冗餘

more on low-cost storage durability than high data access performance

重構的時候,頻寬消耗很嚴重

應該根據年齡不同,做不同的引數化,分層處理

資料塊在新寫入時往往被訪問得更頻繁,但隨著它們的年齡變得更少

隨著資料的老化,窄條帶被重新編碼為寬條帶

將窄條帶重新編碼為寬條帶不可避免地會重新定位資料塊並重新生成校驗塊,從而導致資料傳輸中巨大的頻寬開銷

主要觀點

寬條帶的生成發生在有大量節點和條帶的大型儲存系統

選擇兩個窄條帶合併成一個

StripeMerge

2.BACKGROUND ANDMOTIVATION

A Erasure Coding

講了糾刪碼的概念,MDS碼

B Wide-Stripe Generation

寬條帶的概念

假設

寬條帶用於很少被訪問的冷資料,比如備份和歸檔資料[1]、[6]或二進位制大物件(blob),它們的訪問頻率隨著時間的推移而下降

寬條帶有較高的修復代價,隨著k增大而增大

寬條帶生成問題

寬條帶生成步驟(兩個窄條帶生成一個寬條帶)

重新分配2k塊,分佈在不同的節點

將兩個窄條帶的一些資料和校驗塊遷移到一些負責生成寬條帶的新校驗塊的節點上,它們的奇偶校驗塊稍後分佈在不同的節點上。

資料塊的重新分佈,從窄條帶重新生成校驗塊,存在明顯的資料傳輸

目標最小化頻寬

C Storage Scaling

增加新節點擴容,為了在現有和新增加的節點上重新分配擦除編碼塊,他們研究瞭如何將(k,m)條轉換為(k+s,m)條,以最小化伸縮頻寬(即伸縮期間傳輸的資料量)

NCScale的擴充套件方法

此時寬條帶生成頻寬依舊不為0,寬條帶與儲存擴充套件有所不同的是它不需要增加新的節點,這種差異導致它有不同的解決方案。

D Our Idea

Perfect merging

從當前儲存的大量窄條帶中,選擇兩條合適的窄條帶,用來合併為寬條帶,不需要生成頻寬

例子如下

b和a的區別在於c ,d在單獨的節點,並不需要再遷移,這個地方不消耗頻寬

圖示的兩個條帶有這樣的特點,用來消除寬條帶生成頻寬

資料塊在不同的節點

因為寬條帶最後資料塊分佈在不同的節點,如果有在相同節點的,那麼會導致資料塊遷移到其他節點,有頻寬開銷

校驗塊有相同的編碼係數,並駐留在相同的節點,這些可以用來生成新的校驗塊

例子如下

由上面兩個式子可以看出來,新的校驗塊可以通過之前的校驗塊本地生成,不產生頻寬消耗

Challenges:Perfect merging不產生頻寬開銷,但是如何在系統中應用Perfect merging生成多個寬條帶。並且Perfect merging跟窄條帶的放置方式有關。大規模儲存系統中,搜尋所有的窄條帶會消耗大量時間。

3.ANALYSIS

SectionIII-A 我們將寬條帶生成問題轉換為bipartite graph model

SectionIII-B 證明在給定足夠多的窄條帶的情況下,總是存在一個可以生成所有寬條帶而不需要任何寬條帶生成頻寬的最優方案。

A Bipartite Graph Model

n個節點,足夠多的(k,m)narrow stripes,目標是選擇所有符合Perfect merging的窄條帶,合併成(2k,m)的寬條帶,這樣就不存在跨節點的生成頻寬

(k,m)條帶,隨機分佈在k+m節點上

總共排列方案,假設是每個都不同。但是實際上我們合併的時候,資料塊順序無所謂(我們計算的時候只用了校驗塊),校驗塊的順序是重要的,對計算產生影響(主要是前面的係數)

這種被認為是同一種擺放方式。

所以總共可能性如上,被稱為complete chunk placement set。

提出了 bipartite graph

為什麼x和y之間的節點連線起來就是完美匹配?

B Existence

證明perfect merging的存在

證明沒看懂

4.STRIPEMERGE

A Limitations of Optimal Scheme

頻寬問題,轉化為二部圖的最大匹配問題

最大匹配演算法時間複雜度高,形成一個二部圖在時間和空間上都是昂貴的,並且實際中,塊數不一定一樣,不一定能形成完美匹配。

B Greedy Heuristic: StripeMerge-G

利用現有窄條紋的完美合併來生成儘可能多的寬條紋,而對於剩餘的窄條紋,我們轉移一些塊使它們滿足完美合併來生成剩餘的寬條紋

merging cost

轉移塊的數量

例子

設計演算法:

思路

stripemerg首先計算任意一對窄條紋的合併代價,並構造一個包含所有窄條紋對及其合併代價的集合(第1-7行)

根據代價排序,代價為0到k+m之間的整數,計數排序時間複雜度O(n2),n為窄條帶數量,那麼一共n(n-1)/2對,選擇最小的合併,然後刪除相關元素

時間複雜度為O((k+m)n2)並沒有顯著降低(主要是遍歷求代價這部分)

C Parity-aligned Heuristic: StripeMerge-P

完美合併的條帶有以下特點

parity-aligned

parity chunks have identical encoding coefficients and reside in identical nodes

目標是識別完全奇偶對齊的窄條紋對,從而快速獲得滿足完美合併的窄條紋對,顯著減少了作為演算法1輸入的條紋數量,還識別partially parity-alignedpairs的條帶塊

構造一個集合校驗塊對齊的數量的集合,為了構造這個,將校驗塊的位置的元資料儲存在雜湊表中。

雜湊表儲存key-value,key指向奇偶塊的具體拜訪,value是具有相應奇偶塊位置的條帶的索引列表。O(1)時間查詢到具有相同校驗塊位置的條帶

對於任意條帶,其校驗塊放置在m節點中,它可以為其所有奇偶校驗塊放置生成2m - 1個不同的鍵,這些會造成二外的記憶體開銷,但是這個開銷是有限的。

在StripeMerge-G基礎上做了修改

具體演算法

這種方法思想是找校驗塊對齊的條帶,進行合併。但是他們的資料塊可能在同一個節點,這樣會造成資料遷移,cost增加

5.PERFORMANCE EVALUATION

Amazon EC2

StripeMerge VS NCScale

比較點,節省多少頻寬

可以減少多少執行時間

A Simulations

not implement coding operations and data transfers(沒有資料傳輸這個頻寬咋來的???)

Intel Xeon Silver 4110 2.10 GHz CPU

256 GiB RAM

ST1000DM003 7200 RPM 1 TiB SATA hard disk

設N為2k+m的倍數

Experiment A.1 (Wide-stripe generation bandwidth)

10000個條帶隨機分佈在N個節點,測試不同的N和(k,m)的組合

StripeMerge-P ,StripeMerge-G, NCScale

4≤k≤64,2≤m≤4 N=2(2k+m) and N=4(2k+m)

從圖中可以看出來,頻寬隨著k和m的增加而增加,因為會使得完美匹配更加難滿足

當k比較小時生成頻寬隨著N的增大而增大,k比較大時,隨著N的增大而減小。

正面影響,N越大資料塊越容易分佈在不同的節點上,負面影響校驗塊越不容易駐留在相同節點。

k不大時,m和k差不都,負面影響大。k較大時,k遠大於m,正面影響大,頻寬減小。所以更大的k和N會受益(覺得缺乏說服力)

StripeMerge-P 和 StripeMerge-G效能差不多

Experiment A.2 (Running time versus(k,m))

StripeMerge-G and StripeMerge-P的執行時間對比(為啥不跟NCScale比,這個時間是0麼)

StripeMerge-P比StripeMerge-G 快,說明parity-aligned有效的加快了速度,k較小時,基本上是0.

優化幅度隨著k的增大而減小,k越大,更多的資料塊有糟糕的資料塊佈局,parity-aligned不能加速演算法。

Experiment A.3 (Running time versus the number of narrow stripes)

測試演算法執行時間與窄條紋數量

固定(k,m) = (16,4)andN=2(2k+m) =72

StripeMerge-G 隨著條帶數量顯著增加(O((k+m)n2 )),StripeMerge-P線性增加(O((k+m)mn))更適合大型系統

Experiment A.4 (Memory consumption of StripeMerge-P)

total memory usage

the memory usage of the hash table that stores parity-aligned metadata

fix(k,m) = (16,4) and N=2(2k+m) =72

(注意軸是指數型的),由此可見雜湊表的開銷和總記憶體開銷相比是有限的,處理10000條窄條帶需要4.85GB的記憶體,雜湊表本身只需要72.5MB的記憶體,StripeMerge-P產生的額外開銷是可以接受的。

B Amazon EC2 Experiments

擴充套件了coding and data transfer功能,使用ISA-L實現編解碼

N=2(2k+m) 個 m5.xlarge 例項 當儲存節點,為了評估網路頻寬的影響,專門配置了一個用作閘道器的專用例項。

來自例項的任何傳輸塊都必須在到達另一個例項之前遍歷閘道器。我們使用Linux流量控制命令來控制閘道器的輸出頻寬

實驗中,將頻寬從1Gb/s到8Gb/s變化,實驗考慮不同的塊大小 10,000 narrow

Experiment B.1 (Time breakdown)

時間分為3部分

  1. 演算法執行時間,找到需要合併的窄條帶

  2. 轉移時間,指的是用於合併的塊的轉移

  3. 計算時間,是指將窄條帶的校驗塊合併為寬條帶的新校驗塊的本地計算

(k,m) = (16,4),N=2(2k+m) =72

chunk size of 64MiB

gateway bandwidth of 8Gb/s

由表格可知傳輸時間占主導地位

stripemerg的執行時間佔用了10,000條條紋總時間的1.65%,但這個百分比將隨著條紋數量的增加而急劇增加(實驗A.3)。因此,對於具有大量分條的大型儲存系統,stripemerg的執行時間會降低整體效能。相比之下,stripemerg - p的執行時間僅佔10,000條帶總時間的0.068%,而這一百分比只隨著條帶數量的增加而線性增加

Experiment B.2 (Wide-stripe generation time versus (k,m))

gateway bandwidth as 8 Gb/s and the chunk size as 64 MiB

k m 增加生成時間增加 ,完美匹配的少了,需要傳輸的資料多了,時間會變長

Experiment B.3 (Impact of gateway bandwidth)

(k,m) = (16,4),N=2(2k+m) =72

gateway bandwidth, from 1 Gb/s to 8 Gb/s

生成時間隨著頻寬增大而線性減小,並且StripeMerge 優於NCScale

Experiment B.4 (Impact of chunk size)

chunk sizes, from 8 MiB to 64 MiB

(k,m) = (16,4),N=2(2k+m) =72

gateway bandwidth of 8 Gb/s

生成時間隨著塊大小線性增加,而且StripeMerge效能仍然較好

6.RELATEDWORK

在repair和scaling roblem最小化頻寬的研究

repair

locally repairable codes (LRC)

通過額外的儲存減小修復I/O

regenerating codes(再生碼)

通過額外的儲存減小修復I/O

repair-efficient techniques

lazy recovery通過謹慎地延遲立即修復操作來減少修復流量

parallelizing and pipelining repair

減少修復時間

scheduling repair tasks in free timeslots

適應工作負載的動態變化

scaling problem

minimize the bandwidth

under RAID-0, RAID-5 (i.e., single fault tolerance) , or RS codes

code conversion

研究可轉換的程式碼結構,以最小化程式碼轉換中的I/O

本文研究的問題其實和上面的都不一樣,研究如何最小化頻寬並且減少寬條帶生成問題的計算開銷。

寬條帶問題的相關研究

VAST

locally decodable codes提高寬條帶的修復效能

Haddock et

general-purpose GPUs 提高寬條帶的解碼效率

ECWide

combined locality

系統的解決了修復頻寬問題,提出了有效的編碼和更新方案

本文關注點在於如何生成寬條帶

7.CONCLUSIONS

StripeMerge生成寬條帶

本文轉換為bipartite graph modeling,證明了最優方案的存在。提出了兩個演算法,在有限頻寬下生成(完美情況時間複雜度比較大),生成效能比現有效能好。