云存储系统中基于更新日志的元数据缓存同步策略*

吴海佳，陈卫卫，刘 鹏，董继光

（解放军理工大学指挥自动化学院 南京 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