云存储中的分布式文件系统的研究

(山东大学信息科学与工程学院，山东济南 250100)

摘要：云存储专注于解决云计算系统中的海量数据存储问题；文件系统用来管理大量的文件信息，并负责对文件的存储空间进行分配；分布式文件系统不仅要管理本地计算机的数据文件，同时还要管理整个存储系统的中的数据文件。文章首先对云计算云存储概念简单介绍，并通过对云存储的技术原理、性能优势等进行分析，指出分布式文件系统对于云存储技术的重要性；最后对现有的云存储分布式文件系统进行详细评论。全文工作将指导我们进一步深入研究云存储技术。

关键词：云计算 云存储 分布式文件系统 

1、引言

   随着信息化程度不断提高，全球数据日益膨胀。面对当前PB级的海量数据存储需求，云存储以其扩展性强、性价比高、容错性好等优势得到了业界的广泛认同。云存储伴随云计算而生，它很早就进入了广大研究人员的视野，众多企业将其作为其进军云计算的第一步、

   文件系统【1】是操作系统的重要组成部分，用来管理和存储大量的文件信息，负责对文件的存储空间进行分配和管理，并对存入其中的文件进行保护和检索，同时为用户提供包括文件创建、删除、命名、读写、访问等一系列功能。

   分布式文件系统除了具有本地文件系统的所有功能外，还必须管理整个系统中所有计算机上的文件资源，从而把整个分布式文件资源以统一的视图呈现给用户。此外，分布式文件系统还需要隐藏内部的实现细节，提供给用户统一的访问接口和方便的资源管理手段【2】。很明显，作为一种典型的分布式系统，云存储需要分布式文件系统的底层支撑以实现各种功能。

2、云存储和云计算

云存储是在云计算(cloud computing)概念上延伸和发展出来的一个新的概念，是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时，云计算系统中就需要配置大量的存储设备，那么云计算系统就转变成为一个云存储系统，所以云存储是一个以数据存储和管理为核心的云计算系统。简单来说，云存储就是将储存资源放到云上供人存取的一种新兴方案。使用者可以在任何时间、任何地方，透过任何可连网的装置连接到云上方便地存取数据[3]。

云存储系统的结构模型由4层组成。

存储层

存储层是云存储最基础的部分。存储设备可以是FC光纤通道存储设备，可以是NAS和 iSCSI等IP存储设备，也可以是 SCSI或SAS等 DAS存储设备。云存储中的存储设备往往数量庞大且分布多不同地域，彼此之间通过广域网、互联网或者 FC光纤通道网络连接在一起。

存储设备之上是一个统一存储设备管理系统，可以实现存储设备的逻辑虚拟化管理、多链路冗余管理，以及硬件设备的状态监控和故障维护。

基础管理

基础管理层是云存储最核心的部分，也是云存储中最难以实现的部分。基础管理层通过集群、分布式文件系统和网格计算等技术，实现云存储中多个存储设备之间的协同工作，使多个的存储设备可以对外提供同一种服务，并提供更大更强更好的数据访问性能。

应用接口

应用接口层是云存储最灵活多变的部分。不同的云存储运营单位可以根据实际业务类型，开发不同的应用服务接口，提供不同的应用服务。比如视频监控应用平台、IPTV和视频点播应用平台、网络硬盘引用平台，远程数据备份应用平台等。

访问层

任何一个授权用户都可以通过标准的公用应用接口来登录云存储系统，享受云存储服务。云存储运营单位不同，云存储提供的访问类型和访问手段也不同。

云存储系统是一个多存储设备、多应用、多服务协同工作的集合体，任何一个单点的存储系统都不是云存储。   

云计算与云存储密不可分，我们可以说云存储是云计算服务的一种，即SaaS(storage as aservice，存储即服务)。甚至可以说，利用云计算系统来建立存储系统，此时的云存储概念相当于一个云计算服务，它往往称之为“存储云”。如亚马逊的S3服务，我们可以利用它来建立另外一个存储系统，S3服务本身就是云服务，所以这样的系统可以称为云存储。

另外，云计算系统需要底层海量文件的存储支持，这一般采用大型的分布式文件系统实现，这就是云存储的模型，它可以直接对外提供云的存储服务。所以可以说云存储位于云计算的底层。本文所出现的云存储概念均指这种关系，它是云计算系统的基础设施。

3、分布式文件系统

   分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样，下面是三个基本的分布式文件系统。

   云存储是云计算系统的基础和支撑，也是提供云计算IaaS服务核心系统。它是一种复杂的分布式文件系统。分布式文件系统有许多成熟而简单的架构方案，然而无法满足云存储和支持云计算系统的需求。这是因为面向云存储的分布式文件系统应该建立在超大规模的基础之上，并且具有海量文件存储能力、高并发低延迟的读写效率以及相当高的可靠性、稳定性和安全性。可见，面向云存储需求的应用目标为分布式文件系统的架构设计带来了新的挑战。

   现有的云存储分布式文件系统包括GFS[4]、HDFS[5]、Lustre、PVFS、PFS、Dynamo[6]等。它们的许多设计理念相似，同时也各有特色。下面对现有的分布式文件系统进行详细介绍。

2.1 GFS(Google File System)架构研究

   GFS与传统的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的研究[7]。

一个GFS集群由一个master和大量的chunk server构成，并被许多客户访问。如图2．1所示。Master和chunk server通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunk server和客户端可以运行在同一个机器上。master维护文件系统所以的元数据，包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约管理，孤儿块的垃圾收集，chunk server间的块迁移。master定期通过心跳消息与每一个chunk server通信，给chunk server传递指令并收集它的状态。

综上，GFS与以往的文件系统的架构的不同如下：

1．部件错误不再被当作异常，而是将其作为常见的情况加以处理。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。

2．海量文件分块的存储。设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。

3．大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。一旦写完，文件就只可读。

4．系统工作量主要由两种读操作构成。对大量数据的流方式的读操作和对少量数据的随机方式的读操作。此外，还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。

由以上分析可以看出，GFS并不是一个通用的云存储系统，它更适合于大型的搜索业务以至于GFS的设计考虑了许多具体业务特性，如文件的大小、读写频率等，这些将GFS的业务应用。同时，主从式结构的单点失效和性能瓶颈问题也是业内关注的焦点[7]。当然，GFS本身也在优化和改进之中。

                          图2.1  GFS系统框架

2.2 HDFS(Hadoop Distribute File System)

   Hadoop是Apache开源组织的一个分布式计算框架，其主要包括HDFS、MapReduce和HBase三个部分，它们分别对应谷歌云计算核心技术GFS、MapReduce和BigTable的开源实现。HDFS是Hadoop的存储基础，具有高容错、高吞吐等优点，其将硬件错误视为常态而非异常情况，并以错误监测和快速恢复为核心架构目标。

                          图2.2 HDFS系统框架

HDFS采用maLster／slaVe架构，如图2．2所示。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间以及客户端对文件的访问[8]。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

2.3 Dynamo架构深入研究

                          图2.3 Dynamo平台的架构 

   Dynamo是一个完全分布式的、无中心节点的存储系统。相比传统的集中式存储系统，Dynamo在设计之初就被定位为一个高可靠、高可用且具有良好容错性的系统。尽管这是一个很有争议的系统[9]，然而，实践表明Dynamo作为亚马逊的key．value模式的存储平台，可用性和扩展性较高：读写访问中99．9％的响应时间都在300ms内[10]。

   Dynamo采用了一些技术，解决了其对等式架构下的一致性问题。如表2．1所示。

   Dynamo按分布式系统常用的哈希算法切分数据，分放在不同的节点上。之所以采用该算法的原因是环上每个节点只需要处理落在它和它的前驱节点之间的数据，这样当有新的节点加入或者撤出时系统的震荡较小。

   同时，一致性哈希是一种随机函数，在节点量较少的情况下很有可能造成节点数据分布的不均匀，而且基本的一致性哈希算法在选择节点位置时并没有考虑环上不同节点的性能差异。为了解决这个问题，亚马逊在Dynamo中引入了节点虚拟化的概念。每个虚拟节点都属于一个实际的物理节点。一个物理节点可能有多个虚拟节点。分布在一致性环上的虚拟节点有效的解决了性能不均问题。也可以理解为，它放在环上作为一个节点的是一组机器，这一组机器是通过同步机制保证数据一致的。

   Dynamo的一个节点中的同步是由客户端来“解决”的，使用所谓的(Ⅳ冠形)模型，其中，N表示节点中机器的总数，尺表示一个读请求需要的机器参与总数，形代表一个写请求需要的机器参与总数，这些值由client端配置。

     总的来说，Dynamo的架构有以下三个特点：

     1．Dynamo最终一致性及同步的设计对于是节点故障是有价值的，但是却无法估算有多少数据未同步。如果改用常规的提交日志方式的话，很容易就能实现故障恢复并且计算未同步的数据量。

     2．Dynamo很多一致性问题都是去中心化的设计所导致的。过去，中心化设计导致了很多灾难，我们意识到要远离中心化。去中心化后，系统会更简洁，更具有可扩展性及可用性。中心化确实会形成瓶颈，但是没有证据说明中心化就低可用性[11]。

     3．Dynamo其实在部分情况下还是一个中心化的体系，如交换机故障发生了网络分片，服务器分成2个的小网，这时候Dynamo对客户端是不可用的，尽管客户端可以连接上Dynamo。

4、总结

   自云计算技术出现以来，随着科学技术的不断发展，云计算应用不断发展壮大，云存储也从理论走向实践。本文首先对云计算云存储技术简要介绍，并对云存储的技术原理、性能优势等进行分析，同时指出分布式文件系统是实现云存储系统高可扩展性、高容错性。高性价比等一系列优势的基础保障。最后对现有的云存储分布式文件系统进行详细而深入的讨论。在云存储的发展和应用过程中，近年来不断涌现新的技术和创意。本文总结历年经验，希望为以后的云存储研究提供基础支撑。

参考文献：

[1]  赵文辉，徐俊，周如林等，网络存储技术[M] 北京：清华大学出版社，2005

[2]  Mario F Jauvin. A methodology for the new CPE pankligm in large UNIX networks[M]   

    Computer measurement group conference,1995

[3]  王鹏．云计算的关键技术及应用实例．第一版．中国：人民邮电出版社，2010．3．287

[4]  Andrew S．Tanenbaum， Maarten  Van  Steen． Distributed  Systems  and    

    paradigms.China.Tsinghua,2007.5-234   

[5]  Hadoop Org．”Hadoop Documents”．http:∥hadoop．apaache．org

[6]  叶伟．SaaS架构设计．中国：电子工业出版社．2009．56．78

[7]  Hoang Pham．Special Issue on Critical Reliability  Challenges and Practices   

    IEEE transactions on systems．2007，3．37(2)．141-142

[8]  邓自立．云计算中的网络拓扑设计和Hadoop平台研究．2009，5，12．13

[9]  刘鹏．云计算．第一版．中国：电子工业出版社，2010．9．85

[10] Iall Foster，Yong Zhao，Ioan Raicu，Shiyong Lu. Clud Computing and  Grid

    Computing 360—Degree Compared．Grid Computing EnVironments Workshop，

    2008．2(8)，1—10

[11] Zhan Ying，Sun Yong；Cloud Storage Management Technology，Second Intemational   

    Conference on Information and Computing Science，2009．301．3ll