分布式文件系统管理策略研究

摘要：随着云计算的发展，出现了越来越多的应用需求。作为云计算的基础，分布式文件系统的作用显得尤为重要。文章重点分析了典型的分布式文件系统在应用中存在的一些问题，最后提出一种元数据服务器设计方法。

关键词：分布式文件系统；管理；主服务器；元数据

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)01-0011-02

Management Strategy For Distributed File System

XUE Zhi-Qiang, LIU Peng, WEN Ai, ZHOU You，XU Chuang

(MilGrid Research Center, PLA Univ. of Sci. & Tech. , Nanjing 210007, China)

Abstract: With the development of cloud computing, more and more applied requirements have appeared. As the basis of cloud computing, distributed file dystem plays an important role. The paper mainly studies the problems existing in some classical distributed file dystems, and proposes a method to design Metadata servers.

Key words: distributed file system; management; master; metadata

目前，云计算备受关注。谷歌、Amazon、微软、IBM等国外著名IT企业都纷纷推出自己的云计算系统，意图在这一轮软件新浪潮中占据一席之地。分布式文件系统作为云计算的基础，实现多个存储设备之间的协同工作，使多个存储设备可以对外提供同一种服务，并提供更强大、更好的数据访问性能[1-2]。因此，深入研究可靠的高性能分布式文件系统，以寻求更好地解决系统性能问题的途径[3]，具有非常重要的意义。

1 典型的分布式文件系统介绍

众所周知，谷歌拥有全球最强大的搜索引擎。它取得的巨大成功，很大程度上在于其先进的存储和计算平台，已公开发表的论文Google File System介绍了部分的技术细节。谷歌的分布式文件系统GFS采用中心服务器模式来管理，系统架构如图1所示。

GFS整个文件系统有三类节点：主服务器（Master）、数据块服务器（Chunk Server）和客户端（Client）。Master是GFS的管理节点，负责保存元数据，管理整个文件系统；Chunk Server负责具体的存储工作，文件以数据块形式分散存储在多个Chunk Server上；客户端在访问GFS时，首先访问Master，获取需要交互的Chunk Server信息，然后直接访问这些Chunk Server，完成数据存取。这种设计方案实现了控制信息和数据信息的分离，极大地降低了Master的负载；客户端与Chunk Server之间直接传输数据流，而且可以同时访问多个Chunk Server进行数据存取，从而使得整个系统I/O高度并行，系统整体性能得到提高。另外GFS还采用控制元数据的规模、对Master进行远程备份等多种机制来避免Master成为系统性能和可靠性上的瓶颈。[5]

参照谷歌模式，目前出现了很多具有一定影响力和借鉴价值的分布式文件系统及应用。开源项目Hadoop File System（HDFS）、MooseFS等分布式文件系统的架构与GFS非常相似，IBM的“蓝云”[6]更是直接使用Hadoop作为基础平台。

2 中心服务器存储模式的优缺点

中心服务器模式是指在系统中有一个中心服务器专门负责管理元数据，所有元数据都存储在中心服务器的存储设备上。GFS以及众多模仿GFS实现的分布式文件系统都采用这种架构。这种模式可以大大简化系统设计，从而降低实现难度，同时这种模式也还存在着一些问题。

2.1 中心服务器模式的优点

主服务器管理所有的元数据，由于只有一个中心（Master），元数据不存在一致性问题。中心服务器模式使得系统在扩展方面也易于实现，增加新的Chunk Server只需要到Master注册即可，不用通知其他的Chunk Server。Master作为唯一的管理节点，掌握整个系统Chunk Server的存储情况，使得整个系统的负载均衡更加易于实现。这些优势都是无中心、完全对等模式无法比拟的。

2.2 中心服务器模式存在的问题

系统性能与可靠性上的瓶颈是中心服务器模式固有的缺点。元数据存储在主服务器上，所有客户端请求文件时，都要先从主服务器获取元数据，在一定的操作频繁度内可以获得较好的性能，但是当对元数据操作过于频繁时，单一的主服务器必定会成为系统的性能瓶颈。因为GFS以及HDFS设计的目的在于存储大文件，单个Master可以把所有文件与数据块之间的关系信息放在内存[7]，而对于有大量小文件的存储需求，单Master模式显然力不从心。另外，在可靠性方面也存在单一失效点问题，若主服务器失效，整个系统将无法正常工作。

3 元数据服务器设计模型

随着云计算在各领域的广泛应用，数据量的增加，对分布式文件系统的规模、I/O带宽和元数据处理性能提出了很高的需求。单一的元数据服务器已经不能满足日益增长的规模和性能需求[8]，采用多元数据服务器势在必行。

3.1 设计模型

本文提出一种元数据服务器设计模型，对中心服务器模式进行了改进，用多个服务器代替原来单个主服务器进行元数据的管理。具体设计如图2所示：

系统中有多个元数据服务器，相当于由多个子系统构成。为了避免元数据出现不一致的问题，每个元数据服务器独立负责一部分文件的读写，各个元数据服务器之间不会出现任务的重叠。客户端在读写文件时，对文件名进行HASH处理（也可以选择其他方式进行元数据划分，元数据的划分是一个难点），根据得到的结果选择对应的元数据服务器，这就实现了特定的文件由特定的元数据服务器服务。元数据存储服务器可靠存储整个系统的元数据，并负责检测元数据服务器的工作状态。备用服务器在元数据服务器故障的情况下取代其进行服务。

3.2 工作流程

下面介绍两个主要的操作流程：写文件和读文件。

写文件流程如下：

1）客户端写文件时，根据对文件名的HASH结果选择对应的元数据服务器，发送写文件请求；

2）元数据服务器分配数据块，返回块列表信息给客户端；

3）客户端与数据块存储服务器联系，写入数据；

4）数据写完后，数据块存储服务器返回块信息到客户端；

5）直到文件写完，客户端发送文件元数据信息到元数据服务器，并可靠存储到元数据存储服务器；

6）元数据服务器和元数据存储服务器返回确认信息，写文件成功。

读文件流程如下：

1）客户端读文件时，根据对文件名的HASH结果选择对应的元数据服务器，发送读文件请求；

2）元数据服务器收到读请求后，返回文件元数据给客户端；

3）客户端根据元数据信息，与相关的数据块存储服务器联系；

4）数据块存储服务器读取块数据并返回给客户端；

5）读文件成功。

3.3 可靠性保证

目前有很多种算法可以实现数据的高可靠存储。IDA算法是一种信息分散算法（Information Dispersal Algorithm）。这种算法能将一个长度为L的文件F，分成n+m个分片Fi（l≤i≤n+m），每个分片的长度为L/n，在Fi中任取n个分片都能重组回原来的文件F，并且IDA算法的时间复杂度很低，这种文件分片和重组不会影响对数据的操作。[9]

元数据信息经过IDA算法分片存储在元数据存储服务器上，元数据存储服务器分配特定的存储区域给每个元数据服务器，以便于管理，分片工作由元数据存储服务器完成。这样的设计可以保证元数据的可靠存储，只要存在足够数目的元数据存储服务器，系统就可以获得任何文件的元数据信息。虽然元数据的分片存储有一定的时间代价，但是只有在写文件、更新文件时才会有分片，加上IDA算法的效率很高，不会影响对文件的操作。

所有的元数据存储服务器通过一定的选举算法得到一个Leader，由Leader负责检测元数据服务器的工作状态。元数据服务器定期向Leader发送心跳信号，使对方知道自己还在正常工作。如果超过指定时间没有心跳信号，Leader就认为这个元数据服务器出现故障，然后通知备用服务器。备用服务器从元数据存储服务器取得相关元数据分片信息，重组后放入内存，取代故障元数据服务器进行对外服务。

3.4 多元数据服务器的优势

在这种模式下，系统由多个子系统组成。这样的设计有以下几个突出的优点：

1）一个中心变为多个中心，分散了系统的压力，没有中心会成为系统的性能瓶颈，可以满足更多的用户需求。

2）各个子系统之间是独立的，可以进行个性化的设计，满足多样化的用户需求。例如，不同的子系统可以设置不同的副本个数。

3）一般系统很难同时高效存储海量大文件和小文件，例如GFS、HDFS不适合小文件的存储。面对各种不同的存储需求，在客户端可以选择最合适的子系统进行存储，提高系统的性能。

4）随着系统规模的增大，可以通过增加元数据服务器的方式保证性能。

4 结束语

随着云计算的发展和广泛应用，出现了越来越多的存储需求，现有的分布式文件系统管理模式逐渐不能满足需要。本文提出的元数据设计模型，解决了中心服务器模式存在的一些问题，为日益增长的系统规模和性能需求提供了可能的解决思路。相信在不久的将来，对云计算的研究必定会更加深入和成熟。

参考文献：

[1] 武永卫,黄小猛.云存储[J].中国计算机学会通讯,2009,5(6):44-52.

[2] 云存储的发展及其问题[N].网络世界,2009年第008版.

[3] 杜聪,徐志伟.COSMOS文件系统的性能分析[J].计算机学报,2001,7.

[4] Sanjay Ghemawat,Howard Gobioff,Shun-Tak Leung.The Google File system[J].Proceedings of the 19th ACM Symposium on Operating Systems Principles,2003:29-43.

[5] 刘鹏.云计算[M].北京:电子工业出版社,2010.

[6] 陈康,郑纬民.云计算:系统实例与研究现状[J].软件学报,2009,20(5):1337-1348.

[7] 叶伟.互联网时代的软件革命:SaaS架构设计[M].北京:电子工业出版社,2009.

[8] 熊劲,范志华,马捷,等.DCFS2的元数据一致性策略[J].计算机研究与发展,1019-1027,2005.

[9] 李胜利,唐维.高可用并行文件系统的分布式元数据管理[J].应用科学学报,2005,23.