http://mss.sjtu.edu.cn/bencandy.php?fid=14&id=149
xiaoyongli@sjtu.edu.cn
上海交通大学 海量存储与安全实验室
2010年9月
分布式文件系统均为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年代的网络文件系统研究重点在于实现网络环境下的文件共享，主要解决client和文件（存储）服务器的交互问题。而服务器端的结构基本为对称结构，以每个服务器存储不同目录子树的方式实现扩展。服务器对外提供统一的命名空间（目录树），存储服务器节点之间不共享存储空间，服务器之间缺乏负载均衡和容错机制。
经典文献：
u 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）
虽然80年代的网络文件系统解决了不同计算机之间的数据共享问题，但是文件（存储）服务器的可扩展性问题仍然十分突出：每个存储服务器所支持的存储容量局限于SCSI总线的限制而难以扩展，不同服务器之间的存储空间也不能得以均衡利用。
90年代，存储系统逐渐开始独立于计算机系统而获得快速发展。存储区域网（SAN: Storage Area Network）成为解决存储系统可扩展性的最有效的途径。简单来看，SAN就是用网络（早期为光线通道网络：FC-SAN，后来扩展到IP网络：iSCSI）取代SCSI总线，从而使存储系统的容量与性能的可扩展性都得以极大提高。在SAN网络中，可以接入多个存储节点，每个节点都对外提供I/O通道。在写入数据时，服务器端可以采用条带化技术将一个文件的数据并行写入到多个存储节点中，从而显著提高I/O吞吐量。
早期的SAN主要用于集群计算系统中，面向SAN的集群文件系统是90年代的研究重点。典型的文件系统包括IBM研制的GPFS(General Parallel File System)，和目前由Redhat支持的GFS（Global File System）。
图 共享存储集群文件系统
共享存储集群文件系统为对称结构，计算节点之间共享存储空间，共同维护统一命名空间和文件数据。由于计算节点之间是紧耦合的，共享临界资源（存储空间、命名空间、文件数据），则节点间需要复杂的协同和互斥操作，而分布式锁的设计也往往成为影响系统性能的主要因素。
由于紧耦合特性，共享存储集群系统的（计算）节点规模难以大规模扩展，通常小于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）项目（1997-2001），其核心思想为给存储设备（磁盘）配备CPU，使其具有一定的处理能力而实现自我管理、对外提供更加智能的对象访问接口，并实现更高的安全性。
要理解为什么该成果具有重要意义，就需要首先清楚是哪些因素制约文件系统的可扩展性（容量和性能）：
1) 容量和I/O瓶颈方面，系统的规模（设备/磁盘数量）从根本上决定了系统可能达到的最大容量与聚合I/O带宽。用网络替代总线可以有效解决该问题；
2) 计算瓶颈方面，制约文件系统性能的主要因素为几类大规模数据的管理。包括：
l 命名空间
l 文件元数据
l 存储空间
其中存储空间的管理开销高达文件系统总开销的30%以上，成为制约系统性能的主要因素之一。
SAN技术有效解决了问题1），而未解决问题2）。由于SAN对外提供类似于磁盘的块访问接口，缺乏自我管理能力，即使像“哪个磁盘块是空闲的？”、“文件的数据在哪个磁盘块上？”这类最基本的问题也不能回答或解决。所有这些管理功能都需要由前端的文件服务器来完成，但由于上述资源为被频繁访问的临界资源，文件服务器之间需要紧耦合方式协同工作，系统设计非常复杂，且规模难以扩展。
基于对象存储的并行存储架构能够从以下几个方面解决上述挑战：
l 利用对象存储设备，存储空间的管理开销均衡地分布到每个对象存储设备上，从而消除了传统文件系统中的存储空间管理导致的性能瓶颈；
l 将文件分割为多个对象，分别存储到不同的对象存储设备上，使得文件的元数据得以显著减少（4K：1M）；
l 对象存储设备之间完全独立，从而使得其规模可以极大地进行扩展（可高达上万个存储节点），有效解决了存储系统的容量的扩展能力。
l 对象存储设备直接向客户端提供面向对象访问的I/O通道，从而使系统的I/O吞吐量可随着存储设备数量增加而线性扩展。
基于对象存储的并行存储系统的架构如下图所示。
图 基于对象存储的并行文件系统架构
服务器端为非对称结构，由元数据服务器MDS（Meta Data Server）和对象存储节点组成。元数据服务器实现对命名空间（目录）和文件元数据的管理。当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的不足之处在于未考虑容错性。
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 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（集群MDS正在开发过程中），存储节点可扩展到上千台。
Luster为开源软件，目前主要由Sun公司维护开发。Luster的存储节点的文件系统由ext3修改而成，这部分成果成为后来ext4的基础。修改内容包括支持extent的存储空间管理和文件inode管理、支持大目录等。
Luster系统中client端和server的通信采用Portal RPC协议，其主要特性类似于RDMA，以零拷贝方式传递数据，具有极高的性能。
在实现方式上，Luster和PVFS/GoogleFS不同，client端和server都在OS内核实现。
Luster支持对 MDS节点的Active/Standby方式的容错，但缺乏数据冗余保护。
u Ceph: A Scalable, High-Performance Distributed File System
Sage A. Weil, Scott A. Brandt, Ethan L. Miller, Darrell D. E. Long, Carlos Maltzahn. In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI’06)
Ceph 是由加州大学Santa Cruz分校SSRC实验室开发的高性能分布式文件系统。和PVFS、Panasas、Luster不同之处在于，Ceph采用HASH计算方式确定每个对象的存储节点，该方法能够显著减少MDS需要存储的元数据，从而使系统具有更好的可扩展性。Ceph采用了很多先进的思想与方法，包括自适应的MDS集群、基于复制的数据保护、主动数据迁移等。
Ceph已成为一个开源项目，正在努力发展成为云存储系统。目前还未在生产环境中得到应用。
u Google File System
Sanjay Ghemawat,Howard Gobioff,and Shun-TakLeung. SOSP’03, Oct., 2003, Bolton Landing, NewYork, USA.
和前面几种分布式文件系统不同的是，GFS是Google公司为了特定应用：高效的海量信息存储与检索而定制开发的系统。其特点为：
l 面向WORM（一次写入，多次读取）应用，对读操作进行优化；
l 数据只能以追加（Append）方式写入；
l 特定的API（不支持Posix接口和语义）；
l 一致性语义方面，要求所有client看到相同的数据，但不一定是最新的数据；
l 系统节点高达上万台，容错成为优先考虑问题。
为了提高元数据服务器MDS的性能，GoogleFS采用压缩编码方式，将所有元数据保存在内存中。
每个文件被切分为64M大小的对象（chunk）。
采用数据复制方式实现容错，每个对象有3份副本，所有副本的数据以流水线方式同步写入。
在对象放置策略上考虑机架（rack）因素，确保3个副本位于不同的设备和机架上，从而能够支持rack级的容错，在读取数据时网络带宽能得到更均衡的利用。
目前已有开源项目HDFS（JAVA语言）和KFS（Kosmos File System，C++语言）实现了类似于GoogleFS架构的分布式文件系统。