分布式文件系统概述

分布式文件系统概述
文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。

根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的文件系统，如Unix的本地文件系统；多处理器多用户的分布式文件系统。

本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。

上述按照层次的分类中，高层次的文件系统都是以低层次的文件系统为基础，实现了更高级的功能。

比如多处理器单用户的本地文件系统需要比单处理器单用户的本地文件系统多考虑并发控制（Concurrency Control），因为可能存在多个处理器同时访问文件系统的情况；多处理器多用户的文件系统需要比多处理器单用户的本地文件系统多考虑数据安全访问方面的设计，因为多个用户存在于同一个系统中，保证数据的授权访问是一个关键；多处理器多用户的分布式文件系统需要比多处理器多用户的文件系统多考虑分布式体系结构带来的诸多问题，比如同步访问、缓冲一致性等。

随着层次的提高，文件系统在设计和实现方面的难度也会成倍提高。

但是，现在的分布式文件系统一般还是保持与最基本的本地文件系统几乎相同的访问接口和对象模型，这主要是为了向用户提供向后的兼容性，同时保持原来的简单对象模型和访问接口。

但这并不说明文件系统设计和实现的难度没有增加。

正是由于对用户透明地改变了结构，满足用户的需求，以掩盖分布式文件操作的复杂性，才大大增加了分布式文件系统的实现难度[12]。

一、分布式文件系统的发展历史
在计算机性能不断提升的同时，计算机部件的平均价格却在不断下降。

用户可以用更低的成本，购买更好、更快、更稳定的设备。

存储系统、文件系统面临的新挑战也随之而来：如何管理更多的设备，提供更好的性能，更加有效地降低管理成本等。

各种新的存储技术和分布式文件技术层出不穷，以满足用户日益增长的需求。

以下为分布式文件系统的发展过程中的几个阶段[12]：
1980～1990年早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的性能和数据的可靠性。

主要以NFS和AFS(Andrew File System)最具代表性，它们对以后的文件系统设计也具有十分重要的影响。

1990～1995年20世纪90年代初，面对广域网和大容量存储应用的需求，以及当时产生的先进的高性能对称多处理器的设计思想，加利福尼亚大学设计开发的xFS，克服了以前的分布式文件系统一般都运行在局域网（LAN）上的弱点，很好地解决了在广域网上进行缓存，以减少网络流量的难题。

它所采用的多层次结构很好地利用了文件系统的局部访问的特性，无效写回（Invalidation-based Write Back）缓存一致性协议，减少了网络负载。

对本地主机和本地存储空间的有效利用，使它具有较好的性能。

1995～2000年在这个阶段，计算机技术和网络技术有了突飞猛进的发展，单位存储的成本大幅降低。

而数据总线带宽、磁盘速度的增长无法满足应用对数据带宽的需求，存储
子系统成为计算机系统发展的瓶颈。

网络技术的发展和普及应用极大地推动了网络存储技术的发展，基于光纤通道的SAN、NAS得到了广泛应用。

这也推动了分布式文件系统的研究，出现了多种体系结构，充分利用了网络技术。

2000年以后随着SAN和NAS两种体系结构逐渐成熟，研究人员开始考虑如何将两种体系结构结合起来，以充分利用两者的优势。

另一方面，基于多种分布式文件系统的研究成果，人们对体系结构的认识不断深入，网格的研究成果等也推动了分布式文件系统体系结构的发展。

这一时期，IBM的StorageTank、Cluster的Lustre、Panasas的PanFS、蓝鲸文件系统（BWFS）等是这种体系结构的代表。

各种应用对存储系统提出了更多的需求：大容量－现在的数据量比以前任何时期更多，生成的速度更快；
高性能－数据访问需要更高的带宽；
高可用性－不仅要保证数据的高可用性，还要保证服务的高可用性；
可扩展性－应用在不断变化，系统规模也在不断变化，这就要求系统提供很好的扩展性，并在容量、性能、管理等方面都能适应应用的变化；
可管理性－随着数据量的飞速增长，存储的规模越来越庞大，存储系统本身也越来越复杂，这给系统的管理、运行带来了很高的维护成本；
按需服务－能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等。

二、分布式文件系统的关键问题
分布式文件系统的目标就是利用已有的网络和资源向用户透明的提供一个类似本地文件系统的大容量，高性能，具有容错性和可扩展性的系统。

设计一个分布式系统需要考虑很多因素，如数据组织，网络情况，安全性，容错性等等。

大多数分布式系统的都有一定的目标性，也就是并不意图提供一个通用的文件系统，而只是提供在某种情况下性能比较高的解决方法，如GFS[5]，就是Google专门为自己的应用程序提供的解决方案；Cegor[1]主要是提供一种在异构网络环境下自适应的文件系统；IncFS[2]则是以NFS[6]为基础提供一种分布式文件系统的简单解决方法；Coda[11]则比较侧重于移动计算方面等等。

可见要设计一个通用的分布式文件系统是多么的困难，后面主要以这次阅读的文献中的一些资料及自己的想法从以下几个方面来谈谈：
1.总体结构
分布式文件系统结构上有两种大的方式[12]，一种是专用服务器结构，一种是无服务器结构，这次看的资料基本上都是专用服务器结构的。

专用服务器又分为两种，一种是单个系统服务器。

由于只有一个系统服务器，数据的一致性问题得到很大的缓解，但其可扩展性却受到限制。

另外一种是多个系统服务器。

这种系统一般具有较好的可扩展性，但由于多个系统服务器的原因，数据一致性很难处理。

GFS[5]是由单个主控服务器，多个数据块服务器组成，严格来说算是多个系统服务器。

但是GFS将所有的元数据和数据的分布信息都保留在主控服务器上，客户端的数据读写首先必须得通过与主控服务器的交互才能进行，所以我觉得又有点单个系统服务器的意思，这样可以简化整个系统的设计。

GFS架构
另外，在看文献的时候，发现一些系统在构建时就是以其它的分布式文件系统为基础的。

如IncFS[2]就是以NFS为基础构建，所有的网络通信都是以NFS为基础进行；而Coda[11]的很多特性都是从AFS[8]继承下来的。

而大部分的分布式文件系统则是以本地文件系统（主要是Linux文件系统或者VFS）为基础的，甚至还出现了用户空间的文件系统[3]。

2.数据组织及管理
分布式文件系统的一个主要目的就是整合资源，将不同机器上的存储资源进行有效利用。

如何对系统的数据进行组织并进行有效的管理，对整个系统的性能有重要的影响。

大部分的分布式文件系统都是将数据以Linux文件的形式存储在服务器上。

但是各个系统可能根据实际需要会对数据的组织形式有所改变。

如上图，GFS[5]将元数据（文件名，数据块到文件的映射，数据块的位置）与文件数据区分，元数据保存在主控服务器上，而文件数据则被分成固定大小的块（以Linux文件的形式保存）保存在数据块服务器上。

而文件数据的分布信息则是保存在主控服务器上的，这样，当要进行数据的读写时，都必须首先与主控服务器进行交互，当然，如果在一定的生命期内，客户端缓存的元数据据有效时则可跳过这一步的执行。

那么，主控服务器如何来得知数据块的变化信息呢？比如因为某个数据块服务器在某个时刻崩溃了。

事实上，主控服务器并不是保存数据块位置的固定信息，而是通过“心跳”机制来动态的更新，这样当某一个数据块服务器崩溃时，主控服务器至少在下一次通过“心跳”来交互时就会更新这一信息。

另外，并且为了保证可靠性，每个数据块都会被复制到多个不同的数据块服务器上。

并且当主控服务器在某一次通过“心跳”交互后，发现某个数据块的副本量少于特定的值时，主控服务器会重新创建新的副本，以达到要求。

Ceph[7]，IncFS[2]采用了和GFS[5]类似的机制，以元数据服务器（Meta Server）来保存文件信息，而以存储服务器（Storage Server）来保存文件的数据。

采用这种形式的数据组织，可以有效的保证全局的文件名称空间。

类似GFS，IncFS[2]这种底层以Linux文件保存数据、通过系统提价的文件操作接口访问数据的形式称之为文件级别的存储。

而在TLDFS[4]中，作者提出了一种块级别的存储方案，分布式文件系统直接操作设备块，而不是文件。

并且为了提高在并发访问时的锁定操作的效率，文件提出了一种改良的块组织形式，如下：
将原来分配专门的块来保存inode的方式改成将inode平均的分布在数据区中。

这样，当需要锁定某个inode时就不会同时锁定在同一个块上的其它inode，从而可以更好的支持并发访问。

3.数据一致性
分布式文件系统中，需要保证多个客户端并发访问时的数据一致性。

为了保证以上语义，分布式文件系统需要仔细的处理客户端与服务端交互的协议。

保证数据一致性需要保证以下语义[6]：
⏹每一次对文件数据的读操作都应该看到所有之前写操作的结果。

⏹对于一个已打开文件的写操作应该对本地客户端可见，但是对同时打开这个文件
的其它远程客户端并不可见。

⏹当一个文件被关闭时，对此文件所做的修改要到下一次的会话中才对其它客户端
可见，已经打开的文件并不反映这些变化。

租赁协议[10]：租赁就是保证某些属性在固定的时间段内有效的一个约定。

当客户端用服务器发出一个读操作请求时，它不仅收到所请求的数据，而且会收到一个租赁，它保证在租赁的有效期内，服务器不会对客户端收到的数据进行更新。

如果客户端对一个本地已经缓存的文件进行操作，只要那个文件的租赁没有过期，客户端就不需要从服务端重新请求数据，而只要对缓存中的数据时行操作即可，也就是说，在租赁过期时，客户端必须与服务器进行交互以确认本地的数据是否是最新的数据，如若不然，则必须从服务器获取新的数据。

当服务器收到客户端的更新请求时，它并不是立即就确认此次更新。

在提交更新前，服务器必须征得所有拥有这个文件有效租赁的客户端同意。

当客户端收到服务器的更新确认请求时，就将已经拥有的有效租赁标记为无效，这样，更新才会最终写入文件。

此后，如果客户端需要读取相同的文件时，它必须从服务器获取新的数据，同时获取一个新的有效租赁。

调和一致性协议[1]：是一个基于租赁的一致性协议。

在拥有的租赁过期时，客户端必须和文件服务器进行调和。

在两次调和事件之间，所有在本地缓存中的数据都将作为最新数据使用，也就是最后一次调和产生的数据。

调和一致性协议将保证客户端在下一次调和后看到所有文件的最新版本数据。

这个协议保证一个客户端所做的修改在最多两个调和周期后被另一个客户看到。

上面的协议都只提供了多读者单写者的机制，也就是说同一时间在同一个文件上可以有多个读操作，但同一时间只能有一个写操作进行，类似的如TLDFS[4]。

另一方面，一些分布式系统提供了多个更新操作并发执行的机制，如GFS中提出的一致性模型，它只保证每个写操作都以原子操作对每个副本以相同的顺序至少执行一次，而并不保证最终的数据结果完全一样（字节相似）。

另外，GFS使用版本号来检测已经过期的数据，采用类似机制的还有Coda的版本号向量[9]。

而有些系统的实现仅对文件操作提供数据一致性保障，没有保证读操作获得的内容结果的有效性[13]。

4.Cache
当客户端进程需要访问服务器数据时，一般都会加入缓存机制，以提高数据访问的性能。

当客户端第一次请求数据时，服务器总会返回更多数据，并且将这些数据缓存在本地，以后
客户端的操作都是对本地缓存进行操作，以减少网络通信流量，提高效率。

这样，当存在多个客户端的并发访问时，就需要一个机制来保证缓存数据的一致性。

分布式系统中缓存的设计需要解决以下的设计问题[6]：
●缓存数据的粒度。

●客户端缓存的位置（主存或者硬盘）。

●缓存副本的更新如何进行。

●如何判断客户端缓存数据的一致性。

GFS区分了元数据和文件数据，客户端会缓存元数据（文件属性，数据块位置等），以加快访问速度，并且在一定的有效期后，这些信息需要从服务器重新获取。

而对于文件数据，客户端和数据块服务器都不会进行缓存[5]。

客户端不进行缓存主要是因为GFS处理的主要是大文件，这对缓存来说不太现实，并且这样的话可以简化因为缓存而带来的数据一致性问题；而数据块服务器不对文件数据缓存主要是因为数据块是以Linux文件的形式存在的，Linux系统会自动缓存经常访问的数据。

类似的还有NFS也是只缓存文件或者目录的属性信息，并且保存一定的时间，而并不缓存文件数据[12]。

在AFS中，服务器会记录客户端的缓存行为，客户端缓存文件的属性和数据，并且采用LRU算法对缓存进行更新。

当有其它客户端试图修改已经被别的客户端缓存的文件属性或者数据时，服务器会采用回调的机制来通知客户端这些缓存已经失效[8]。

虽然回调机制减少了缓存确认的通信流量，但是使整个系统变得更加复杂，因为客户端和服务端都必须保存回调的状态信息。

Cegor在借鉴AFS中缓存机制的基础上，提出了基于语义视图的缓存机制[1]。

以阴影缓存（Shadow Cache）来保存暂时不经常访问的文件；对于阴影缓存中的数据，采用自适应放缩协议（Adaptive Zooming Protocol）来进行更新。

从以上可以看出，不同的系统都会根据各自的需要，对缓存机制进行一些调整，来更好的适应应用环境的需要。

5.安全性
在传统的分布式文件系统中，所有关于文件的数据和元数据都要经过元数据服务器进行存取，因为系统的安全性都可以在元数据服务器那里集中控制。

这样的情况下，安全性比较容易实现，一般采用简单的身份验证和访问授权的形式即可，如NFS，GFS等。

Cegor提出了在异构网络环境中以连接视图（Connection View）为基础的安全访问机制[1]。

连接视图被定义成客户端和文件服务器断开连接时，所有连接的一个快照。

为连接视图中的每个结点以HASH算法为基础递归的生成一个密钥，而另一个预先定义的密钥则在初始的文件挂载过程中分发给客户端，以后的客户端访问都是在此基础上进行授权的。

6.性能优化
在分布式系统中，为了提高数据访问的速度，减少网络通信的流量，不同的系统都会采用不同的策略来对性能做出优化。

比如在GFS中，为了节省文件操作的时间，所有的元数据信息都是常住内存的；Cegor[1]不仅使用缓存技术来减少通信流量，还提出了基于类型的通信延迟优化策略：它使用差异算法来计算两个文件之间的差别产生一个“△”并将这部分做为最终的更新数据，主要的观点是对不同类型的文件采用不同的差异算法，以最大限度的节省计算时间和利用带宽。

7.容错性
在分布式环境中，容错性是一个重要的问题。

当服务器对一个客户端提供数据服务时，如果缓存有关客户端的信息时，则称服务器是有状态的（stateful），反之，则称为无状态的（stateless）[6]。

当服务器在一次数据服务过程中崩溃时，无状态和有状态服务器之间的区别就更加明显：有状态服务器会丢失所有易失性状态，所以就需要一种机制来重新恢复到崩
溃以前的状态；而在崩溃后，新的无状态服务器却可以很方便的重新向客户端提供数据服务，但是，却需要更长的请求消息和更久的处理过程，因为，服务器并没有保留任何信息来加速这个过程。

容错性环境下定义了两种文件属性[6]：
●可恢复，当操作一个文件失败时，存在一种机制可以把已经不一致的文件数据恢
复到一个更早的一致性状态，则被定义为可恢复的。

●健壮性，如果一个文件保证在部分存储设备或者媒体失效时可以正常访问，则被
定义为健壮的。

可恢复性可以通过原子更新操作来保证，健壮性则可以通过冗余技术来实现。

GFS中，因为系统所用设备的原因，既不能完全的信任机器，也不能完全的信任磁盘，所以为了提高可用性，它提供了两种策略[5]：快速恢复和保存多个副本。

快速恢复保证不管服务器如何崩溃，它们都可以在几秒钟内重新起动并恢复到原来的状态。

保存多个副本的策略有两个方面，一个是数据块备份，每个数据块都会在不同架的不同服务器上进行备份，并且保证每个数据块的完全备份（副本的数量达到一定要求）；另一方面，为了保证可靠性，主控服务器的状态也会进行备份，当主控服务器的状态需要更新时，会先对所有的备份更新成功后才进行。

同时，为了保证数据完整性，每个数据块服务器都会使用检验和来检测已经破坏的数据，因为在数据块服务器之间比较各个数据块是不现实的，并且，GFS并不保证每个数据块的完全相似性。

在SODA中，因为之前提到的租赁协议本身就是具有容错性的[10]，所以并不需要其它的机制来实现容错性。

8.可扩展性
应用对分布式文件系统在性能和容量方面的需要在不断的增长。

分布式文件系统一般都是通过扩充系统规模来取得更好的性能和更大的容量。

但是对于各种系统结构，系统在规模上可能存在不同的限制。

比如NFS采用单个服务器，那个整个系统的性能和容量都存在瓶颈，难以突破单个服务器系统的极限。

设法保证系统的性能随着系统的规模能够性性增长，是分布式文件系统一直努力的目标[12]。

另一方面，扩展性还体现在系统规模的增长不会带来系统管理复杂度的过度增加。

降低控制系统的管理成本，简化系统的管理流程，都是分布式文件系统实现的关键技术。

比如在GFS中，因为主控服务器和数据块服务器的分离，动态的添加服务器并不会影响整个系统的管理难度，但同时又提高了整体容量、访问性能和更高的可靠性。

三、总结
通过这次的文献阅读，大体上了解了分布式文件系统的发展过程，各个阶段提出的文件系统的特点以及在设计分布式文件系统时需要考虑的问题。

技术的进步，应用需求的发展，是分布式文件系统不断进步的原动力。

现在的分布式文件系统，已经不再是单纯的文件系统，而是整合了很多其它方面计算机技术的综合系统，其发展更加注重系统的性能、扩展性、可用性等因素，同时结合存储管理，也更加强调降低整个系统的总体拥有成本，包括系统的管理成本。

总的来说，还是收获不少，但是还需要在这方面进行更多的了解，特别是在移动计算环境方面，因为随着移动技术的发展，支持移动计算的分布式文件系统将会成为迫切的要求。

[1] Weisoing Shi, Sharun Santhosh, Hanping Lufei. Cegor: An Adaptive Distributed File System for Heterogeneous Network Environments. Wayne State University. IEEE Proc. of the tenth ICPADS’04, 2004.
[2] Yi Zhao, Rongfeng Tang, Jin Xiong, Jie Ma. IncFS: An Integrated High-Performance Distributed File System Based on NFS. IEEE Proc. of IWNAS2006, 2006.
[3] Ivan Voras, Mario Zagar. Network Distributed File System in User Space. Faculty of Electrical Engineering & Computing, University of Zagreb. Information Technology Interfaces, 2006.
[4] Lei Wang, Chen Yang. TLDFS: A Distributed File System Based on the Layered Structure. International Conference on Network and Parallel Computing, 2007.
[5] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google File System. ACM SOSP’03.
[6] Eliezer Levy, Abraham Silberschatz. Distributed File Systems: Concepts and Examples. ACM Computing Surveys (CSUR) 1990.
[7] Sage A. Weil, Scott A. Brandt, Ethan L. Miller, Darrell . Long. Ceph: A Scalable, High-Performance Distributed File System. USENIX OSDI’06.
[8] John H. Howard, Michael , Sherri G. Menees. Scale and Performance in a Distributed File System. ACM Transactions on Computer Systems, 1988.
[9] M. Satyanarayanan. Coda: A Highly Available File System for a Distributed Workstation Environment. IEEE Transactions on Computers, V ol. 39, No. 4, April 1990.
[10] Fabio Kon, Arnaldo Mandel. SODA: A Lease-Based Consistent Distributed File System. Proceedings of the 13th Brazilian Symposium on Computer Networks, 1995.
[11] Peter . The Coda Distributed File System. Linux Journal June, 1998.
[12] 黄华, 杨德志, 张健刚. 分布式文件系统. 信息技术快报, 2004年第10期.
[13] 杨德志, 黄华, 张健刚, 许鲁. 大容量、高性能、高扩展能力的蓝鲸分布式文件系统. 计算机研究与发展, 42, 2005.。