分 布式文件系统均为Client/Server架构。数据保存在服务器端，而客户端的应用程序能够像访问本地文件系统一样访问位于远程服务器上的文件。在 Client通常都对文件数据进行缓存，以提高读写性能和系统可扩展性。然而，缓存和一致性总是一对矛盾，一致性的实现往往比较复杂，这方面的研究有大量 论文。本文仅限于讨论服务器端的架构，分析其面临的挑战和相应的解决方法。

一种技术总是带有时代的烙印。以时间为线索，可以将分布式文件系统的发展历程大致分为3个阶段：

l   网络文件系统（ 1980s ）

l   共享存储（ SAN ）集群文件系统（ 1990s ）

l   基于对象存储的并行文件系统     （ 2000s ）

 

下面依次展开论述。

1.            网络文件系统（ 1980s ）

       在上世纪 80 年代，以以太网为代表的局域网技术蓬勃发展并大规模普及，而广域网（因特网）也逐成气候。以资源共享为目的的网络操作系统、网络文件系统获得快速发展。典型的成果有：

l   1981 年， IBM 发布第一款 PC 机； 1982 年， CMU 和 IBM 合作，启动面向 PC 机资源共享的 ITC （ Information Technology Center ）项目，研制出了著名的网络文件系统 AFS ；

l   1983 年， Novell 发布了网络操作系统 Netware ；同年， Berkeley 发布了支持 TCP/IP 的 BSD4.2 操作系统；

l   At&T 推出 RFS 网络文件系统 [H. Chartock, “RFS in SunOS”, USENIX Conference Proceedings, Summer 1987, 281-290.]

l   1985 年， Sun 发布了 NFS 文件系统 .

图 网络文件系统架构

 

80 年代的网络文件系统研究重点在于实现网络环境下的文件共享。而服务器端的结构基本为对称结构，存储服务器节点之间不共享存储空间。服务器对外提供统一的命名空间（目录树），通过每个服务器存储不同目录子树的方式实现扩展。服务器之间缺乏负载均衡和容错机制。

 

经典文献：

 

The ITC distributed file system: principles and design.

M. Satyanarayanan ， John H. Howard ， David A. Nichols. Proceedings of the tenth ACM symposium on Operating systems principles, Orcas Island, Washington, United States, Pages: 35 - 50  ,blication: 1985

该文献主要介绍了 ITC 系统的架构。 ITC 系统目标在于为 CMU 大学的师生提供统一命名空间的信息共享平台，其支持的客户端数量高达 5000 以上。 ITC 由运行在客户端的 Venus 软件和运行在服务器端的 VICE 组成。 Venus 的软件架构为运行在内核态的系统调用截获模块和运行在用户态的守护进程组成（目前流行的 FUSE 和它基本类似）。

图 ITC 系统架构

 

该文献可大致浏览一下，作为阅读下一篇文章的铺垫。

 

u   Scale and Performance in a Distributed File System

JOHN H. HOWARD, MICHAEL L. KAZAR, SHERRI G. MENEES. ACM  Transactions  cm Computer  Systems, Vol. 6, No. 1, Feb. 1988,  Pages 51-81.

该文献全面、详细、深入地总结分析了 AFS 测试结果、问题分析和优化策略。其中提出的一些方法如 cache 管理、 callback 机制等，成为分布式文件系统中解决性能和可扩展性的基本方法。

 

u   Design and Implementation of the Sun Network Filesystem (NFS).

R. Sandberg et al.   Proc. of the Summer 1985 USENIX Conference, June 1985, pp. 119-130.

相对于学院派的 AFS, 出自业界的 NFS 显得既不优雅，也不完美。但它有一个优点却使得它脱颖而出：简单、客户端和服务器端有清晰的接口。因为简单，就易于理解，易于实现。 NFS 目前已发展到 v4 版本。最初推出的 NFSv2 、 NFSv3 是无状态的，既客户端和 server 端都不维护对方的状态（松耦合），使得系统的鲁棒性得到有效提高，系统的设计也较容易。 NFS 推出后，很快就获得 IBM,HP 等大公司的支持，从而一统天下。

在 cache 和一致性管理方面， NFS 采用了简单的弱一致性方式：对于缓存的数据， client 端周期性（ 30 秒）去询问 server ，查询文件被最后修改的时间，如果本地缓存数据的时间早于该时间，则让本地 cache 数据无效，下次读取数据时就去 server 获取最新的数据。

2.            共享存储（ SAN ）集群文件系统（ 1990s ）

       90 年代，存储系统逐渐开始独立于计算机系统而获得快速发展。面向集群计算机系统的存储区域网（ SAN: Storage Area Network ）成为解决存储系统可扩展性的最有效的途径。而由集群计算系统中节点共享的、面向 SAN 的集群文件系统则成为 90 年代的研究重点。典型的文件系统包括 IBM 研制的 GPFS(General Parallel File System) ，和目前由 Redhat 支持的 GFS （ Global File System ）。

图 共享存储集群文件系统

 

用网络（ SAN ）替代总线（ SCSI ） 使得存储系统本身的容量和性能的可扩展性都得以极大提高。在共享存储集群系统中，采用条带化技术将一个文件的数据分布到多个节点中，一个计算节点可以并行 地向多个存储节点写入或读取数据；多个计算节点也可以并发地访问同一文件的不同部分，因此这类系统也称为并行文件系统。

共享存储集群文件系统为对称结构，计算节点之间共享存储空间，共同维护统一命名空间和文件数据。由于计算节点之间是紧耦合的，共享临界资源（存储空间、命名空间、文件数据），则节点间需要复杂的协同和互斥操作，而分布式锁的设计也往往成为影响系统性能的主要因素。

       由于紧耦合特性，共享存储集群系统的（计算）节点规模难以大规模扩展，通常小于 64 个节点。

 

经典文献：

 

u  GPFS: A Shared-Disk File System for Large Computing Clusters.

Frank Schmuck ， Roger Haskin. Proceedings of the Conference on File and Storage Technologies (FAST’02),28–30 January 2002, Monterey, CA, pp. 231–244. (USENIX, Berkeley, CA.

 

    由IBM公司在上世纪90年代设计，在全球范围内的高性能计算机上得到大量部署。GPFS的突破， 在于支持集群节点可以并发方式读取同给一个文件的不同部分，可以针对单个文件提供极高的吞吐量，在GPFS之前是没有如此高性能的文件系统的。

    GPFS在分布式锁管理、存储空间管理、inode元数据更新等方面做了大量的优化，系统具有容错功能。

    体会GPFS系统的庞大、复杂性，就能深入理解对象存储技术的优点。对象存储技术提供了一种新的架构和方法，从而可以用更简单的方式设计更大规模、更高性能的分布式存储系统。

3.            基于对象存储的并行存储系统 （ 2000s ）

       对象存储是近十几年来文件系统研究的最重要成果之一。 2000 年后研发的分布式文件系统无一例外地均采用了该思想和方法。

对象存储技术起源于 CMU 的 NASD （ Network Attached Storage Device ）项目，其核心思想为通过在存储设备（磁盘）上加上 CPU ，使其具有一定的处理能力而实现自我管理、提供基于网络的数据访问，和更高的安全性。

       要理解为什么该成果具有重要意义，就需要首先清楚是哪些因素制约文件系统的可扩展性（容量和性能）。

I/O 瓶颈方面，物理设备和磁盘则最终决定了系统的 I/O 性能。很显然，系统的规模（设备 / 磁盘数据）则从根本上决定了系统可能达到的聚合 I/O 带宽。

计算瓶颈方面，制约文件系统性能的主要因素为几类大规模数据的管理。包括：

l  命名空间

l  文件元数据

l  存储空间

其中存储空间的管理开销高达文件系统总开销的 30% 以上，成为制约系统性能的主要因素之一。

 

l  利用对象存储设备，就可以将存储空间的管理开销均衡地分布到每个对象存储设备上，从而消除了传统文件系统中的存储空间管理导致的性能瓶颈；

l  将文件分割为多个对象，分别存储到不同的对象存储设备上，使得文件的元数据得以有效减少（ 4K ： 64M ）；

l  对象存储设备之间完全独立，从而使得其规模可以极大地进行扩展，有效解决了存储系统的容量的扩展能力。

l  对象存储设备可以直接对客户端提供面向对象访问的 I/O 通道，从而使系统的 I/O 吞吐量可随着存储设备的数量而线性扩展。

 

基于对象存储的并行存储系统的架构如下图所示。

<!--[endif]--> <!--[endif]-->

图   基于对象存储的并行文件系统架构

服务器为非对称结构，由元数据服务器 MDS 实现和对象存储节点组成。元数据服务器实现对命名空间（目录）和文件元数据的管理。当 client 端访问文件时，首先向 MDS 发送请求， MDS 将文件包含哪些对象，对象位于哪个存储节点等信息发送给 client 端；此后 client 就直接向对象存储节点发送请求读写数据，不需要和 MDS 交互。

 

经典文献：

 

u  PVFS ： Parallel Virtual File System

http://www.pvfs.org/documentation/

PVFS 由 Clemson 等多所大学合作开发，是面向高性能计算的并行文件系统，目前已成为开源项目。早期发布的 PVFS 为共享存储结构（ 1993 ），但 PVFS 的开发者不断对其进行升级完善，目前发布版本为 2.0 ，采用了对象存储技术。 PVFS 的客户端提供 MPI 接口，主要用于高性能计算领域。

PVFS 中的 client/server 采用无状态交互，类似于 NFSv3 。支持多种网络连接方式，如 TCP/IP ， Myrinet 等。

PVFS 将文件切分为多个固定大小的对象（ chunk ），以 round-robin 方式依次写入到一组存储设备中。

下面表、图描述了 PVFS 内部的数据存储方式。

从表 1 可以看出，对于文件 /pvfs/foo ，文件被切分为 64K 大小的对象，依次分布到存储设备 2 （ base ） ,3,4 上。（ count 为 3 ，表示条带化宽度为 3 ）

对于每个文件，在存储设备上只有一个对象，对象名为文件的 inode 号。多个 chunk 数据被合并到同一个对象中。

       PVFS 具有突出的性能。 PVFS 具有完善的技术资料，目前已成为开源项目。国内研发的集群文件系统多以此为基础。

       PVFS 的不足之处在于未考虑容错性。

 

u  Scalable Performance of the Panasas Parallel File System. （ Panasas ）

Proceedings of the 6th USENIX Conference on File and Storage Technologies San Jose, California ， 2008

Panasas是业界最早的基于对象技术的高性能存储系统。和所有基于对象存储的并行存储系统一样， Panasas 也由 client 端、管理节点、数据节点（对象存储节点）组成。但和其它系统不同的是， Panasas 是包括硬件设计的性能优越、功能完善、成熟的商业产品。该系统的技术起源于 CMU 大学的 PDL 实验室，后面将要提及的 Luster 系统的源头也可以追溯到 CMU 。

Panasas 系统的突出特征在于支持文件级的 RAID ，提高了数据安全性。

Panasas 公司后来将自己的客户端技术公开，成为目前 pNFS （ NFSv4.1 ）标准的基础。

 

u  Google File System

Sanjay Ghemawat,Howard Gobioff,and Shun-TakLeung. SOSP’03, Oct., 2003, Bolton Landing, NewYork, USA.

GoogleFS 是 Google 公司为了实效的海量信息的检索而设计的分布式文件系统。 GoogleFS 的设计面向特定环境的应用，做了如下定制：

l  特定的 API （不支持 Posix 接口和语义）

l  一致性语义方面，要求所有 client 看到相同的数据，但不一定是最新的数据；

l  WORM （一次写入，多次读取），面向读进行优化；数据只能以追加（ Append ）写入；

l  采用通用的硬件平台；

l  系统节点高达上万台，容错成为优先考虑问题。

为了提高元数据服务器（ MDS, 或称为控制节点）的性能， GoogleFS 采用压缩编码方式，将所有元数据保存在内存中。

文件被切分为 64M 大小的对象（ chunk ）。如果文件小于 64M, 则将多个文件合并到一起。每个对象有 3 份副本，存储到不同的对象存储设备上。在副本的放置策略上，考虑的机架（ rack ）的因素，从而能够支持 rack 级的容错，在读取数据时网络带宽能得到更均衡的利用。

在对象信息的管理上，采取每个存储节点在启动时主动汇报的方式。

目前已有开源项目 HDFS 实现了类似于 GoogleFS 的功能。

 

u  Luster file system.  Sun whitepaper.

u  Understanding Lustre Filesystem Internals （ Luster ）

http://wiki.lustre.org/images/d/da/Understanding_Lustre_Filesystem_Internals.pdf

第一篇文献介绍了 luster 的架构和特性。第二篇文献从设计角度详细描述了 Luster 的内部结构。

Luster 是目前在全球 top100 高性能计算机中部署最多的高性能并行文件系统。支持一个 MDS ，存储节点可扩展到上千台。

Luster 为开源软件，目前主要由 Sun 公司维护开发。 Luster 的存储节点的文件系统由 ext3 修改而成，这部分成果成为后来 ext4 的基础。修改内容包括支持 extent 的存储空间管理和文件 inode 管理、支持大目录等。

Luster 系统中 client 端和 server 采用 Portal RPC 协议，其主要特性类似于 RDMA ，以零拷贝方式传递数据，具有极高的性能。

在实现方式上， Luster 和 PVFS/GoogleFS 不同， client 端和 server 都在 OS 内核实现。

Luster 支持对 MDS 节点的 Active/Standby 方式的容错，但缺乏数据冗余保护。