云存儲系統中基于更新日志的元數據緩存同步策略*

吳海佳，陳衛衛，劉 鵬，董繼光

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

1 引言

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

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

2 問題提出

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

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

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

g（gross）：元數據服務器中元數據的總量，可用元數據的項數來表示。

f（frequency）：客戶端從元數據服務器同步元數據的頻率。

q（quantum）：每個同步周期內元數據同步的數據量。

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

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

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

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

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

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

3 算法描述

以全軍網格研究中心的MassCloud云存儲系統為例。如圖1所示，在該云存儲系統中，元數據服務器和存儲結點部署于Linux服務器上，并分別提供Windows端和Linux端的客戶端掛載點。元數據服務器上保存著系統的完整目錄樹，目錄樹的內結點保存系統中某一級目錄的信息，葉結點保存系統中某文件的元數據信息或者表示某一級空目錄。客戶端緩存中保存該目錄樹的鏡像。

3.1 完全同步策略

在改進之前，MassCloud的客戶端元數據緩存使用完全同步策略，完全同步策略是最簡單的同步策略。客戶端對元數據的修改立即提交給元數據服務器，這樣就能保證元數據服務器總是保存著系統中最新的目錄樹。同時，客戶端每隔一定時間（同步周期）從元數據服務器完整獲取最新的目錄樹，替換本地緩存中的鏡像目錄樹。

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

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

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

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

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

針對使用完全同步策略會造成額外網絡流量消耗的問題，設計實現了基于更新日志的元數據緩存精確同步策略。圖3為元數據服務器同步流程，圖4為客戶端元數據緩存同步流程。

3.2.1 元數據服務器同步流程

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

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

如圖3中步驟②所示，當元數據服務器收到客戶端元數據同步請求時，首先查看請求報文中的時間戳，根據該時間戳，定位到日志記錄的相應位置，根據自該位置之后的所有日志記錄，構建響應報文。響應報文構建規則如下。

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

xxxx

…

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

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

3.2.2 客戶端元數據緩存同步流程

當客戶端發生元數據修改時，直接向元數據服務器提交修改請求，當修改請求被成功響應后，修改本地緩存中的元數據，從而完成一次元數據修改任務。

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

如圖4中步驟①所示，當客戶端獲得同步請求的響應報文后，根據報文內容，更新本地緩存中的元數據項和時間戳。元數據項的更新規則如下。

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

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

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

4 性能測試

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

從圖5可以看出，隨著客戶端數目的不斷增多，客戶端到元數據服務器的RTT一直保持極低的水平，即使客戶端數目超過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 葉偉等.互聯網時代的軟件革命：SaaS架構設計.北京:電子工業出版社,2010

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