南加州大學(xué)和Facebook共同完成的Erasure Code演進(jìn)——LRC，通過增加本地存儲容量，提升了平均無故障時(shí)間，并減少恢復(fù)數(shù)據(jù)的開銷。

作為云計(jì)算的核心系統(tǒng)之一，存儲系統(tǒng)直接影響了整個(gè)系統(tǒng)的成本。七牛云存儲CEO許式偉 表示：

我第一個(gè)云存儲的講座就已經(jīng)講了成本在云存儲里面的重要性。實(shí)際上我更進(jìn)一步說到要想在Erasure Code上更進(jìn)一步只有成本轉(zhuǎn)嫁，用p2p。

金山云CTO楊鋼在近期接受CSDN采訪時(shí)表示：“金山云在創(chuàng)立初就采用了Erasure Code。”

作為OpenStack的對象存儲項(xiàng)目Swift，自然要對存儲成本進(jìn)行有效的控制。不過要在成本、數(shù)據(jù)持久性(durability)和性能之間找到平衡，并非那么容易。

在官方發(fā)行版中的Swift是不具備Erasure Code功能的，但SwiftStack已經(jīng)實(shí)現(xiàn)了Swift+Erasure Code。相信支持Erasure Code功能的Swift不久將會(huì)出現(xiàn)在官方發(fā)行版中。

不過，Swift+Erasure Code并非完美，這種算法會(huì)大量增加網(wǎng)絡(luò)負(fù)載。Joe Arnold透露，Swift會(huì)提供Erasure Code和傳統(tǒng)3副本兩種策略，供用戶選擇。而 LRC通過增加本地存儲來降低數(shù)據(jù)恢復(fù)時(shí)對網(wǎng)絡(luò)資源的消耗，也許這是Swift未來更需要的策略。以下為博客摘譯：

沒有免費(fèi)的午餐

CAP原理告訴我們，在數(shù)據(jù)一致性(Consistency )、可用性(Availability )和分區(qū)容錯(cuò)性(Partition tolerance)三者中只能同時(shí)滿足兩者。Swift優(yōu)先考慮可用性和分區(qū)容錯(cuò)性。

即當(dāng)某個(gè)分區(qū)發(fā)生故障，系統(tǒng)將容忍這一故障分區(qū)繼續(xù)響應(yīng)服務(wù)請求。因?yàn)镾wift可以恢復(fù)故障分區(qū)的數(shù)據(jù)，集群的任何部分依然可以提供服務(wù)。

可用性是分區(qū)帶來的巨大的好處。此外，分區(qū)還帶來許多其它優(yōu)勢：

延遲和重建

Swift的大部分客戶都對并發(fā)性和延遲時(shí)間有著全天候的要求。在數(shù)據(jù)恢復(fù)過程中，讀請求由一個(gè)存儲卷提供支持。這意味著較少的網(wǎng)絡(luò)流量和CPU負(fù)荷，最終用戶感知到的等待時(shí)間非常短。

失敗處理對于數(shù)據(jù)恢復(fù)系統(tǒng)而言也非常簡單。當(dāng)一個(gè)磁盤損壞并被替換后，任何其它包含副本的磁盤都能將數(shù)據(jù)直接拷貝到被替換的磁盤。這種簡單的拷貝方式只需很低的CPU處理能力，并且不需要與集群中的許多服務(wù)器并發(fā)連接。

復(fù)制和區(qū)域(Regions)

在目前的Swift副本模型中，集群內(nèi)的所有數(shù)據(jù)被拷貝多次。在SwiftStack的單集群中，我們推薦采用3副本策略;在雙集群和全球規(guī)模的分布式系統(tǒng)中，推薦采用n*2策略，即每個(gè)集群都使用2副本。這種策略給予集群強(qiáng)壯的持久性和可用性，因?yàn)楫?dāng)分區(qū)發(fā)生故障時(shí)，分散在本地的副本會(huì)響應(yīng)訪問請求，替代需通過網(wǎng)絡(luò)重新組裝的數(shù)據(jù)。

在保持已有策略的優(yōu)勢的同時(shí)，為什么不使用Erasure Code來即減少數(shù)據(jù)密集程度呢?

在Swift上使用Erasure Code

我們將在產(chǎn)品中集成Erasure Code策略，并根據(jù)實(shí)際應(yīng)用場景權(quán)衡并作出選擇。

存儲架構(gòu)——Ring

Swift目前使用稱之為“Ring”環(huán)形數(shù)據(jù)架構(gòu)，這種架構(gòu)在集群內(nèi)建立分布式的分區(qū)空間。分區(qū)空間是Swift數(shù)據(jù)副本策略的核心，它可以讓Swift快速、簡單的進(jìn)行同步。當(dāng)Swift的組件需要進(jìn)行數(shù)據(jù)交互時(shí)，通過在Ring中進(jìn)行本地快速查詢，為每個(gè)副本選擇最適合的分區(qū)。

圖：Swift的哈希Ring

在Swift中使用了3個(gè)環(huán)形架構(gòu)存儲不同類型的數(shù)據(jù)。一個(gè)用于存儲賬戶信息(各租戶的用戶信息)，第二個(gè)環(huán)用于容器(所以非常方便任意賬戶下的對象)，第三個(gè)環(huán)用于對象副本。為了支持Erasure Code，據(jù)需要建立第四個(gè)環(huán)，用于存儲Erasure Code校驗(yàn)塊。

寫入

在Swift集群中，代理服務(wù)器不斷的選擇適當(dāng)?shù)拇鎯?jié)點(diǎn)發(fā)出請求。當(dāng)請求存儲一個(gè)對象時(shí)，代理層將對這個(gè)對象進(jìn)行Erasure Code編碼生成校驗(yàn)塊，這些校驗(yàn)塊再不斷的寫入到擇適當(dāng)?shù)姆謪^(qū)中。

讀取

當(dāng)請求讀取一個(gè)Erasure Code的對象時(shí)，代理層會(huì)同存儲服務(wù)器間建立適合的連接，并對目標(biāo)對象進(jìn)行解碼，最后將解碼后的數(shù)據(jù)發(fā)送到客戶端。當(dāng)發(fā)生某個(gè)磁盤故障時(shí)，Erasure Code的優(yōu)勢就發(fā)揮出來了，只要有足夠的校驗(yàn)塊就可以重建對象中丟失的部分。

重建

在代理層進(jìn)行編碼是有一些優(yōu)勢的。首先，Swift已經(jīng)這么做了，我們選擇站在了巨人的肩膀上。其次，代理服務(wù)器上已經(jīng)準(zhǔn)備了強(qiáng)大的CPU，把編碼工作放在這里能更好的發(fā)揮CPU的性能。在真實(shí)應(yīng)用場景中，存儲容量增速要遠(yuǎn)遠(yuǎn)超過并發(fā)訪問增長需求，因此，編碼工作在代理服務(wù)器中能夠保持低成本運(yùn)行。

Handoff Locations策略

在Swift中已經(jīng)使用了handoff locations概念，來應(yīng)對存儲數(shù)據(jù)時(shí)發(fā)生的硬件或鏈接故障。同時(shí)，當(dāng)在本地主存儲中找不到校驗(yàn)數(shù)據(jù)是，節(jié)點(diǎn)知道如何從相鄰的節(jié)點(diǎn)找到到它。

復(fù)制

使用Erasure Code時(shí)，我們使用重構(gòu)器來掃描數(shù)據(jù)塊。Erasure Code的“重構(gòu)器”檢查相鄰數(shù)據(jù)塊來確保每個(gè)數(shù)據(jù)塊是可用的。若出現(xiàn)故障或者缺損，重構(gòu)器可以重建塊并將其復(fù)制到缺損處。

使用Erasure Code時(shí)，我們依然沿用了這種策略比對數(shù)據(jù)。Erasure Code的“重構(gòu)器”等同于原有的三副本的恢復(fù)形式，通過以快速檢查相鄰塊，以確保個(gè)別塊保持可用。若出現(xiàn)故障或者缺損，重構(gòu)器可以重建塊并將其復(fù)制到缺損處。

容器的粒度控制

Swift的容器與AWS S3的 Buckert很相似。他們可以很方便的修改某個(gè)賬戶下的對象的屬性，如修改訪問控制列表(ACL)。容器非常善于管理一套存儲策略，如副本數(shù)量或Erasure Code。

用不同的設(shè)備實(shí)現(xiàn)Erasure Code

只要增加數(shù)據(jù)Ring(詳見上文)，就能在不同的物理設(shè)備上實(shí)現(xiàn)Erasure Code。例如，如果分層數(shù)據(jù)用于歸檔，就可以使用密度更高的服務(wù)器部署，從而降低成本。

如何權(quán)衡

非常簡單，Erasure Code校驗(yàn)文件比文件副本更廣泛的存儲在服務(wù)器中。這就導(dǎo)致數(shù)據(jù)在讀取過程中必須在節(jié)點(diǎn)間創(chuàng)建更多的連接，這會(huì)讓整個(gè)系統(tǒng)更加復(fù)雜，出現(xiàn)故障的可能性更高，響應(yīng)請求的時(shí)延增長。編碼、解碼過程也會(huì)增加CPU的負(fù)擔(dān)。所有這一切都是要考慮的。