云存儲系統(tǒng)中基于更新日志的元數(shù)據(jù)緩存同步策略*

吳海佳，陳衛(wèi)衛(wèi)，劉 鵬，董繼光

（解放軍理工大學(xué)指揮自動化學(xué)院 南京 210007）

1 引言

由于信息大爆炸以及對海量信息處理的實時性要求，云計算這種新型的計算模式應(yīng)運而生。傳統(tǒng)的海量存儲系統(tǒng)無法滿足云計算處理海量數(shù)據(jù)的需求，作為云計算的支撐技術(shù)，云存儲得到了飛速發(fā)展。從支撐Google云計算的大型分布式文件系統(tǒng) GFS[1]，到其開源實現(xiàn) HDFS[2]，從EC2的底層存儲服務(wù) S3[3]，到 Windows Azure的3種數(shù)據(jù)存儲結(jié)構(gòu) Blob、Table和 Queue[4]，這些云存儲技術(shù)都顛覆了傳統(tǒng)海量存儲技術(shù)，使用簡單、可靠的集群存儲方法存儲和管理數(shù)據(jù)。國內(nèi)的一些大型企業(yè)也開始部署和使用云存儲系統(tǒng)，如淘寶網(wǎng)和阿里巴巴網(wǎng)站分別使用Taobao File System（TFS）[5]和 Alibaba Distributed File System（ADFS）[6]構(gòu)建其底層云存儲系統(tǒng)。國內(nèi)的某些科研單位也開發(fā)了具有海量存儲能力的云存儲系統(tǒng)，如全軍網(wǎng)格研究中心開發(fā)的MassCloud存儲系統(tǒng)，解放軍理工大學(xué)開發(fā)的Formicary File System（FFS）等。

云存儲系統(tǒng)除了滿足海量數(shù)據(jù)可靠存儲的需求，還要考慮性能與成本的平衡。以上提到的各類云存儲系統(tǒng)都是建立在網(wǎng)絡(luò)環(huán)境下，通過集群文件系統(tǒng)將物理上分布的各存儲結(jié)點集中管控，形成邏輯上單一的存儲視圖。通常一個云存儲系統(tǒng)中包含兩類數(shù)據(jù)，一類是文件數(shù)據(jù)，另一類是元數(shù)據(jù)。元數(shù)據(jù)又包括描述文件系統(tǒng)目錄結(jié)構(gòu)的數(shù)據(jù)，以及描述文件數(shù)據(jù)與文件存儲位置映射關(guān)系的數(shù)據(jù)。文件數(shù)據(jù)分布存儲在各存儲結(jié)點上，而元數(shù)據(jù)往往通過主控結(jié)點集中管理。有調(diào)查顯示[7]，在文件系統(tǒng)中元數(shù)據(jù)操作和文件數(shù)據(jù)的讀寫操作大概各占50%的系統(tǒng)資源。衡量文件系統(tǒng)性能有兩個重要指標(biāo)：IOPS和MBPS。在云存儲系統(tǒng)中，IOPS是指云存儲文件系統(tǒng)對元數(shù)據(jù)請求的每秒響應(yīng)次數(shù)，其與網(wǎng)絡(luò)的RTT（round-trip time）有關(guān)；MBPS是指云存儲系統(tǒng)的每秒吞吐量，其與網(wǎng)絡(luò)的帶寬有關(guān)。改善云存儲系統(tǒng)性能可通過提升網(wǎng)絡(luò)質(zhì)量實現(xiàn)，如將百兆網(wǎng)絡(luò)升級為吉比特網(wǎng)絡(luò)，將雙絞線網(wǎng)絡(luò)升級為光纖網(wǎng)絡(luò)。然而，提升網(wǎng)絡(luò)質(zhì)量需要同步更新大量現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施，其成本可觀。在不對網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行升級的前提下，可通過應(yīng)用合理的緩存技術(shù)，降低網(wǎng)絡(luò)延遲對云存儲系統(tǒng)性能的影響。

2 問題提出

云存儲系統(tǒng)一般通過一個元數(shù)據(jù)服務(wù)器集中管理文件系統(tǒng)中的元數(shù)據(jù)信息，客戶端通過與元數(shù)據(jù)服務(wù)器通信，獲取元數(shù)據(jù)信息，并根據(jù)元數(shù)據(jù)信息訪問分布在各存儲服務(wù)器上的文件數(shù)據(jù)。由于客戶端需要通過網(wǎng)絡(luò)訪問元數(shù)據(jù)服務(wù)器，這一方面會因為網(wǎng)絡(luò)延遲，造成客戶端IOPS下降；另一方面，當(dāng)客戶端數(shù)目增多時，頻繁的元數(shù)據(jù)訪問會造成元數(shù)據(jù)服務(wù)器負(fù)載過重，網(wǎng)絡(luò)報文丟失等，從而進(jìn)一步影響客戶端的IOPS，不利于系統(tǒng)的可擴(kuò)展性。

解決該問題的方法是建立客戶端元數(shù)據(jù)緩存，將元數(shù)據(jù)服務(wù)器中的元數(shù)據(jù)同步到本地使用。利用元數(shù)據(jù)緩存可以極大地提高系統(tǒng)性能，但是會帶來一致性問題，以及維護(hù)一致性所帶來的額外開銷?，F(xiàn)作如下定義：

m（modification）：云存儲系統(tǒng)中元數(shù)據(jù)在一個同步周期前后的變化率，其取值范圍是，對于只讀文件系統(tǒng)，對于一個修改極其頻繁的文件系統(tǒng)，趨近于1。

g（gross）：元數(shù)據(jù)服務(wù)器中元數(shù)據(jù)的總量，可用元數(shù)據(jù)的項數(shù)來表示。

f（frequency）：客戶端從元數(shù)據(jù)服務(wù)器同步元數(shù)據(jù)的頻率。

q（quantum）：每個同步周期內(nèi)元數(shù)據(jù)同步的數(shù)據(jù)量。

r（redundancy）：同步數(shù)據(jù)的冗余度。在一個同步周期內(nèi)系統(tǒng)元數(shù)據(jù)更新g×m項，而同步操作傳送了q項，則r=q/(g×m)，從而可得到式（1）：

s（spending）：同步開銷，其與 q和 f呈正比關(guān)系，從而可得到式（2）：

c（coherence）：客戶端元數(shù)據(jù)緩存與元數(shù)據(jù)服務(wù)器的一致性，其與f呈正比，與m呈反比關(guān)系，從而可得到式（3）：

從式（2）可以看出，降低同步開銷可以從兩方面入手，一是降低同步頻率f，一是降低單周期內(nèi)同步的數(shù)據(jù)量q。

然而，從式（3）可以看出，降低f是以犧牲一致性為代價，這只能算是一種治標(biāo)不治本的方法。

從式（1）可以看出，降低 q可以通過降低 r、g、m來實現(xiàn)，然而g、m是由特定的應(yīng)用環(huán)境決定，只有可通過對算法進(jìn)行優(yōu)化來降低。本文則提出基于更新日志的元數(shù)據(jù)緩存同步策略，以降低云存儲系統(tǒng)中客戶端元數(shù)據(jù)緩存的同步開銷。

3 算法描述

以全軍網(wǎng)格研究中心的MassCloud云存儲系統(tǒng)為例。如圖1所示，在該云存儲系統(tǒng)中，元數(shù)據(jù)服務(wù)器和存儲結(jié)點部署于Linux服務(wù)器上，并分別提供Windows端和Linux端的客戶端掛載點。元數(shù)據(jù)服務(wù)器上保存著系統(tǒng)的完整目錄樹，目錄樹的內(nèi)結(jié)點保存系統(tǒng)中某一級目錄的信息，葉結(jié)點保存系統(tǒng)中某文件的元數(shù)據(jù)信息或者表示某一級空目錄?？蛻舳司彺嬷斜４嬖撃夸洏涞溺R像。

3.1 完全同步策略

在改進(jìn)之前，MassCloud的客戶端元數(shù)據(jù)緩存使用完全同步策略，完全同步策略是最簡單的同步策略?？蛻舳藢υ獢?shù)據(jù)的修改立即提交給元數(shù)據(jù)服務(wù)器，這樣就能保證元數(shù)據(jù)服務(wù)器總是保存著系統(tǒng)中最新的目錄樹。同時，客戶端每隔一定時間（同步周期）從元數(shù)據(jù)服務(wù)器完整獲取最新的目錄樹，替換本地緩存中的鏡像目錄樹。

完全同步策略的優(yōu)點是實現(xiàn)簡單；缺點是即使在上一個同步周期內(nèi)，元數(shù)據(jù)服務(wù)器中的目錄樹僅做了非常有限的修改，客戶端仍會從元數(shù)據(jù)服務(wù)器下載完整的目錄樹，從而造成網(wǎng)絡(luò)帶寬的浪費。這一缺點在系統(tǒng)客戶端數(shù)目增多時，或元數(shù)據(jù)服務(wù)器中目錄樹結(jié)構(gòu)比較大時，體現(xiàn)得尤為明顯。圖2為完全同步策略下，隨著客戶端數(shù)目的增多，客戶端到元數(shù)據(jù)服務(wù)器平均RTT的變化情況。

從圖2可看出，隨著客戶端數(shù)目的增多，客戶端到元數(shù)據(jù)服務(wù)器的RTT逐漸增大。當(dāng)客戶端數(shù)目超過20時，RTT將大于200 ms，此時若客戶端進(jìn)行元數(shù)據(jù)修改提交，將會感受到可觀的延遲，從而影響了客戶端的IOPS；當(dāng)客戶端數(shù)目超過70時，RTT將大于同步周期，此時會造成目錄樹同步不完整。

由此可見，在使用元數(shù)據(jù)緩存完全同步策略的情況下，MassCloud的客戶端掛載點數(shù)在低于20時，會獲得較高性能；當(dāng)超過20，但低于70的情況下，隨著客戶端掛載點數(shù)目的增多，IOPS性能逐漸下降；當(dāng)超過70時，系統(tǒng)將失效。

在使用完全同步策略的情況下，元數(shù)據(jù)服務(wù)器中的目錄樹即使在上一個同步周期內(nèi)變化率很小，到了下一同步周期，也會被客戶端完整下載，以替換本地元數(shù)據(jù)緩存中的鏡像目錄樹。對于一個具有1 000個結(jié)點的目錄樹，若表示每個結(jié)點平均需要256 byte，則每次完全同步將需要占用256 KB網(wǎng)絡(luò)流量，隨著目錄樹中結(jié)點數(shù)的增多以及客戶端數(shù)目的增多，消耗的網(wǎng)絡(luò)流量將會更多。這是客戶端數(shù)目增多導(dǎo)致系統(tǒng)IOPS性能迅速下降的主要原因。

3.2 基于更新日志的同步策略

針對使用完全同步策略會造成額外網(wǎng)絡(luò)流量消耗的問題，設(shè)計實現(xiàn)了基于更新日志的元數(shù)據(jù)緩存精確同步策略。圖3為元數(shù)據(jù)服務(wù)器同步流程，圖4為客戶端元數(shù)據(jù)緩存同步流程。

3.2.1 元數(shù)據(jù)服務(wù)器同步流程

元數(shù)據(jù)服務(wù)器中除了保存目錄樹，還保存一個更新計數(shù)器和一個更新日志。如圖3中步驟①所示，當(dāng)客戶端向元數(shù)據(jù)服務(wù)器請求修改元數(shù)據(jù)時，更新計數(shù)器會增1，并在修改完畢后添加一條記錄到日志的末尾。更新計數(shù)器的值作為時間戳，記錄在日志中。日志項的基本格式如下：

其中，Timestamp屬性記錄該項修改發(fā)生時更新計數(shù)器的當(dāng)前值；Type屬性記錄元數(shù)據(jù)的修改類型，客戶端向元數(shù)據(jù)服務(wù)器提交的元數(shù)據(jù)修改請求共有3類：對象（目錄/文件）創(chuàng)建請求、對象刪除請求和對象更新請求，這3類請求對應(yīng)的 Type屬性值分別為 Create、Delete和 Update；Path屬性記錄被修改對象的路徑。

如圖3中步驟②所示，當(dāng)元數(shù)據(jù)服務(wù)器收到客戶端元數(shù)據(jù)同步請求時，首先查看請求報文中的時間戳，根據(jù)該時間戳，定位到日志記錄的相應(yīng)位置，根據(jù)自該位置之后的所有日志記錄，構(gòu)建響應(yīng)報文。響應(yīng)報文構(gòu)建規(guī)則如下。

若Type屬性值為Create或Update，則根據(jù)Path所指位置，從目錄樹中讀取該對象的元數(shù)據(jù)信息，并在響應(yīng)報文中添加如下一條記錄：

xxxx

…

若Type屬性值為Delete，則在響應(yīng)報文中添加如下一條記錄：

在響應(yīng)報文的最后位置，需要添加更新計數(shù)器的當(dāng)前值，作為客戶端在下一次提交同步請求時的時間戳。

3.2.2 客戶端元數(shù)據(jù)緩存同步流程

當(dāng)客戶端發(fā)生元數(shù)據(jù)修改時，直接向元數(shù)據(jù)服務(wù)器提交修改請求，當(dāng)修改請求被成功響應(yīng)后，修改本地緩存中的元數(shù)據(jù)，從而完成一次元數(shù)據(jù)修改任務(wù)。

同時，客戶端還在周期性地向元數(shù)據(jù)服務(wù)器發(fā)送元數(shù)據(jù)同步請求。同步請求報文中包含上一次同步過程從元數(shù)據(jù)服務(wù)器所獲得的時間戳。

如圖4中步驟①所示，當(dāng)客戶端獲得同步請求的響應(yīng)報文后，根據(jù)報文內(nèi)容，更新本地緩存中的元數(shù)據(jù)項和時間戳。元數(shù)據(jù)項的更新規(guī)則如下。

·若響應(yīng)報文中記錄項的Type屬性值為Create，則根據(jù)Path字段查找鏡像目錄中新建項所在父目錄位置，根據(jù)IsDirectory字段值在該目錄下新建目錄或文件，并按照其他各字段值設(shè)置新建項的各項屬性。若新建對象為文件，則根據(jù)ChunkList字段值設(shè)置該文件的存儲位置映射列表。

·若Type屬性值為Delete，則根據(jù)Path字段查找鏡像目錄中待刪除項所在父目錄位置，并從父目錄中刪除該子項。

·若Type屬性值為Update，則根據(jù)Path字段查找待更新對象位置，并根據(jù)其他各字段值重新設(shè)置待更新對象的各項屬性。

4 性能測試

通過應(yīng)用基于更新日志的元數(shù)據(jù)緩存同步策略，MassCloud客戶端可在每個同步周期內(nèi)進(jìn)行精確的元數(shù)據(jù)更新，避免了使用完全同步策略帶來的不必要的網(wǎng)絡(luò)流量消耗，極大地提高了元數(shù)據(jù)緩存同步效率，進(jìn)一步提高了MassCloud的可擴(kuò)展性。測試條件為：系統(tǒng)目錄樹結(jié)點數(shù)為1 000，同步周期為1 s，單周期內(nèi)元數(shù)據(jù)修改率約為1%。如圖5所示，實線部分為在測試條件下，隨著客戶端數(shù)目的增多，客戶端到元數(shù)據(jù)服務(wù)器平均RTT的變化情況；虛線部分表示使用基于更新日志的元數(shù)據(jù)緩存同步策略比完全同步策略性能提高的倍數(shù)。該倍數(shù)為在同等客戶端數(shù)量的條件下，兩者平均RTT的比值。

從圖5可以看出，隨著客戶端數(shù)目的不斷增多，客戶端到元數(shù)據(jù)服務(wù)器的RTT一直保持極低的水平，即使客戶端數(shù)目超過70，各客戶端仍能獲得高性能的IOPS。從圖中虛線部分可看出，較之于完全同步策略，使用基于更新日志的同步策略能獲得20～140倍的性能提升。

1 Sanjay Ghemawat,Howard Gobioff,Shun-Tak Leung.The Google file system.In:Proceedings of the 19th ACM Symposium on operating systems principles,Bolton Landing,NY,2003

2 Tom White.Hadoop:the definitive guide Sebastopol.CA:O’Reilly Media,2009

3 Gideon Juve,Ewa Deelman,Karan Vahi,et al.Data sharing options for scientific workflows on amazon EC2.In:2010 InternationalConference for High Performance Computing,Networking,Storage and Analysis(SC),New Orleans,LA,2010

4 Chappell D.Introducting windows azure,2009

5 楚才.TFS簡介.http://rdc.taobao.com/blog/cs

6 葉偉等.互聯(lián)網(wǎng)時代的軟件革命：SaaS架構(gòu)設(shè)計.北京:電子工業(yè)出版社,2010

7 Klosterman A J,Ganger G.Cuckoo:layered clustering for NFS.Technical Report CMU-CS-02-183.Carnegie Mellon University,2002