典型分布式文件系统概述
分布式文件系统概述（一）
杨栋
yangdonglee@https://www.wendangku.net/doc/586809926.html,
2006-12
摘要
文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。
1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.wendangku.net/doc/586809926.html,，我会尽全力完善，或者请各位同学自行修正。笔者目前在百度进行云计算方面的研究和开发，希望有兴趣的同学一起进行探讨。
目录
1．引言 (5)
2．本地文件系统 (5)
2.1FFS (6)
2.2LFS (6)
2.3Ext3 (7)
3．分布式文件系统 (7)
3.1 发展历程 (7)
3.2分布式文件系统分类 (8)
3.2.1 实现方法 (8)
3.2.2研究状况 (8)
3.3 NFS (9)
3.3.1概述 (9)
3.3.2 体系结构 (9)
3.3.3 通信机制 (10)
3.3.4进程 (10)
3.3.5 命名 (10)
3.3.6 同步机制 (11)
3.3.7 缓存和复制 (11)
3.3.8 容错性 (12)
3.3.9 安全性 (13)
3.4 AFS、DFS、Coda和InterMezzo (13)
3.5 SpriteFS和Zebra (14)
3.6xFS (16)
3.6.1 概述 (16)
3.6.2 体系结构 (16)
3.6.3 通信 (16)
3.6.4 进程 (17)
3.6.5 命名 (18)
3.6.6 缓存 (19)
3.6.7 容错性 (19)
3.6.8 安全性 (19)
3.7Tiger Shark和Frangipani (20)
3.7.1TigerShark (20)
3.7.2Frangipani (21)
3.8PVFS (21)
3.8.1 概述 (21)
3.8.2 存取机制 (21)
3.8.3 管理机制 (23)
3.8.4 存在问题 (25)
3.8.5 PVFS2 (25)
3.9DAFS (27)
3.9.1 概述 (27)
3.9.2 文件访问方式 (28)
3.9.3 客户端实现 (28)
3.10GFS、GPFS、Storage Tank和Lustre (29)
3.10.1GFS (30)
3.10.2GPFS (31)
3.10.3Storage Tank (33)
3.10.4Lustre (34)
3.11Ceph (36)
3.11.1 概述 (36)
3.11.2 设计理念 (37)
3.11.3 体系结构 (39)
3.11.4 关键技术 (39)
3.11.5 客户端操作 (41)
3.11.6 容错性 (41)
4.分布式文件系统之比较 (42)
4.1设计目标 (42)
4.2体系结构 (42)
4.2.1 数据访问方式 (42)
4.2.2 系统服务器的方式 (43)
4.2.3 文件与系统服务器的映射 (44)
4.3命名机制 (44)
4.4同步机制 (45)
4.5缓存一致性 (45)
4.6可扩展性 (46)
4.7容错性 (46)
4.8安全性 (47)
4.9关键技术 (47)
5．总结 (48)
参考文献 (50)
1．引言
最初的分布式文件系统应用发生在20世纪70年代，之后逐渐扩展到各个领域。从早期的NFS到现在的Lustre，分布式文件系统在体系结构、系统规模、性能、可扩展性、可用性等方面经历了较大的变化。
文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。
根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的文件系统，如Unix的本地文件系统；多处理器多用户的分布式文件系统。
本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。高层次的文件系统都是以低层次的文件系统为基础，实现了更高级的功能。
随着层次的提高，文件系统在设计和实现方面的难度也会成倍提高。但是，现在的分布式文件系统一般还是保持与最基本的本地文件系统几乎相同的访问接口和对象模型，这主要是为了向用户提供向后的兼容性，同时保持原来的简单对象模型和访问接口。但这并不说明文件系统设计和实现的难度没有增加。正是由于对用户透明地改变了结构，满足用户的需求，以掩盖分布式文件操作的复杂性，才大大增加了分布式文件系统的实现难度。
在计算机性能不断提升的同时，计算机部件的平均价格却在不断下降。用户可以用更低的成本，购买更好、更快、更稳定的设备。存储系统、文件系统面临的新挑战也随之而来：如何管理更多的设备，提供更好的性能，更加有效地降低管理成本等。各种新的存储技术和分布式文件技术层出不穷，以满足用户日益增长的需求。因此，有必要分析对比当前主流的分布式文件系统在体系结构、缓存一致性、可扩展性、安全等方面的长处和不足。
2．本地文件系统
本地文件系统通常仅仅位于一个磁盘或一个磁盘分区上，它只能被唯一的主机访问，不能被多个主机共享。本地文件系统通常含有四类信息：
超级块：用来描述文件系统整体信息的，含有整个文件系统中数据块和inode的相关信息；inode：用来描述文件和目录的属性和文件块在块设备上的位置信息；文件内容：是用户的数据，是无结构的；目录内容：是目录项，是有结构的。
超级块通常位于磁盘（或分区）上的固定位置。根据文件系统类型，可定位超级块；通过超级块可定位根目录的inode，从而可读出根目录的内容。通过在文件系统名字空间的逐级名字解析，可得到指定文件的ino。根据ino可定位文件的inode在磁盘上的位置，从而读出文件的inode。根据inode中的块映射信息，最后定位指定的文件块，从而读出或写入数据。归结起来，单机文件系统所含的信息可以分为三类，它们是文件数据、文件系统元数据和存储元数据。
早期的UNIX文件系统运行在PDP-11上，拥有简单规范的文件系统特性。文件系统的输入/输出由内核缓存；数据传输和同步操作没有对齐限制。所有到磁盘的传输以512字节块为单位，能够置于文件系统数据区域的任何位置。Inode区与内容存储区相分离，导致查找速度慢（磁臂在inode区与块存储区之间往复移动，尤其长路径名）。当在VAX-11上和其他UNIX增进一起使用的时候，最初的512字节UNIX文件系统不能提供许多应用所需的数据输出率，这要求文件系统提供比早期512字节UNIX系统更高的带宽。
UNIX快速文件系统（FFS）是传统UNIX文件系统的一种重新实现，通过更加复杂的分配策略，充分提高了输出率，效率提高了一个数量级。
FFS将磁盘卷划分为若干个柱面组（cylinder group），每个柱面组占若干连续的柱面，作为相对独立的文件卷管理；采用较大的磁盘块以减少I/O间址并提高I/O效率；FFS打破了文件名长度最多为14字节的限制，文件名长度可达255字节；也支持符号连接（symbolic link），这种连接可以跨文件卷或主机。
2.2 L FS
由于磁盘寻道时间的限制，许多文件系统存在着瓶颈。Berkely设计了一种全新的文件系统，即日志结构的文件系统（log-structured file system），试图解决这个问题。
促成LFS设计的想法是：CPU越来越快，RAM内存越来越大，磁盘高速缓存的容量迅速增加。因此，无需访问磁盘，从文件系统的高速缓存中就可能满足所有读请求。将来大多数磁盘访问是写操作。某些文件系统使用的预读机制，即把数据块在实际需要前调入内存，对文件系统性能的改进不再那么重要了。
LFS的设计人员决定重新设计UNIX的文件系统，他们希望即使在有大量小块随机写的情况下，也能获得磁盘的全部带宽。基本思想是把整个磁盘作为日志。所有写操作都存放在内存的缓冲区中，并定期地收集到一个单独的段中，作为日志尾部的相邻段写回磁盘。因此，每个段都含有inode、目录块、数据块等，并且是他们的混合体。在每段起始位置还有一个摘要，给出了该段中的内容。如果段的平均长度大约为1MB，那么几乎所有的磁盘带宽都能利用。
在这一设计中，inode依然存在，并且和UNIX中的inode具有相同结构。但是这些inode 并不放在磁盘的固定位置，而是分散在日志之中。一旦找到inode，可以用通常的方法找到相应块。为了查找inode，需要维护一张inode映照表，它以inode号为下标，其中第i项指向磁盘上第i个inode。这张映照表存放在磁盘中，但它同样使用缓存机构，所以在大多时候，最常用的部分将保存在内存中。
LFS的工作方式为：所有写的数据开始时都存放在缓冲区中，并且定期地把这些缓冲区中的数据以一个段的形式写到磁盘中，放在日志的尾部。打开一个文件首先要在inode映照表中查找该文件的inode，一旦找到了inode，也就知道了相应块的地址，所有的块也存放在段中，即日志的某个地方。
真正的磁盘都有有限的容量，最终日志将占满整个磁盘，这时新段不能被写到日志中。许多现有段都包含一些不再使用的块。
LFS中有一个清理（cleaner）线程循环地浏览和压缩磁盘。
Ext3 文件系统是直接从Ext2文件系统发展而来，它也秉承了FFS与LFS的主要特点。目前Ext3文件系统已经非常稳定可靠，它完全兼容Ext2文件系统，用户可以平滑地过渡到一个日志功能健全的文件系统。
Ext3日志文件系统的思想就是对文件系统进行的任何高级修改都分两步进行。首先，把待写块的一个副本存放在日志中；其次，当发往日志的 I/O 数据传送完成时（即数据提交到日志），块就写入文件系统。当发往文件系统的I/O 数据传送终止时（即数据提交给文件系统），日志中的块副本就被丢弃。
3．分布式文件系统
本地文件系统只能访问与主机通过I/O总线直接相连的磁盘上的数据。当局域网出现后，主机间通过网络互连起来。如果每台主机上都保存一份大家都需要的文件，既浪费存储资料，又不容易保持各份文件的一致性。于是就提出文件共享的需求，即一台主机需要访问其它主机的磁盘（或文件系统）。这直接导致了分布式文件系统的诞生。
3.1 发展历程
分布式文件系统的发展主要经历了四个阶段：
1980~1990年，早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的性能和数据的可靠性。早期的文件系统以NFS和AFS最具代表性，它们对以后的文件系统设计也具有十分重要的影响。
1990～1995年，20世纪90年代初，面对广域网和大容量存储需求，出现了xFS、Tiger Shark并行文件系统及Frangipani等分布式文件系统。
1995～2000年，网络技术的发展和普及应用极大地推动了网络存储技术的发展，基于光纤通道的SAN、NAS得到了广泛应用。这也推动了分布式文件系统的研究。这个阶段，出现了多种体系结构，充分利用了网络技术，像具有鲜明特点的GFS和GPFS等。数据容量、性能和共享的需求使得这一时期的分布式文件系统管理的系统规模更大、系统更复杂，对物理设备的直接访问、磁盘布局和检索效率的优化、元数据的集中管理等都反映了对性能和容量的追求。规模的扩展使得系统的动态性，如在线增减设备、缓存的一致性、系统可靠性的需求逐渐增强，更多的先进技术应用到系统实现中，如分布式锁、缓存管理技术、SoftUpdates技术、文件级的负载平衡等。
2000年以后，随着SAN和NAS两种体系结构逐渐成熟，研究人员开始考虑如何将两种体系结构结合起来，以充分利用两者的优势。另一方面，基于多种分布式文件系统的研究成果，人们对体系结构的认识不断深入，网格的研究成果等也推动了分布式文件系统体系结构的发展。这一时期，IBM的StorageTank、Cluster的Lustre、Panasas的PanFS、蓝鲸文件系统（BWFS）等是这种体系结构的代表。各种应用对存储系统提出了更多的需求：
①大容量——现在的数据量比以前任何时期更多，生成的速度更快；
②高性能——数据访问需要更高的带宽；
③高可用性——不仅要保证数据的高可用性，还要保证服务的高可用性；
④可扩展性——应用在不断变化，系统规模也在不断变化，这就要求系统提供很好的扩展性，并在容量、性能、管理等方面都能适应应用的变化；
⑤可管理性——随着数据量的飞速增长，存储的规模越来越庞大，存储系统本身也越来越复杂，这给系统的管理、运行带来了很高的维护成本；
⑥按需服务——能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等。
3.2分布式文件系统分类
3.2.1 实现方法
实现分布式文件系统（尤其是机群文件系统）一般有两种方法：共享文件系统（shared file system approach）和共享磁盘（shared disk approach），共享文件系统的方法已被许多分布式文件系统所采用，如NFS、AFS和Sprite文件系统，而使用共享磁盘方法的有VAXCluster的文件系统，IBM GPFS，GFS等。
共享文件系统是实现分布式文件系统单一映象功能的传统方法，它把文件系统的功能分布到客户和服务器上来完成这一任务。挂着磁盘的结点可以作为服务器，其他结点作为客户，客户向服务器提出请求，服务器通过文件系统调用读写其本地磁盘，然后将结果发给客户。
在共享磁盘模型中，系统中没有文件服务器，而代之以共享磁盘。共享磁盘往往是一种专用的高端存储设备，如IBM SSA 磁盘。共享磁盘和客户主机都联接在系统内部的高速网络上，通常是用光通道（Fiber Channel）。每个客户都将共享磁盘作为其一个存储设备，直接以磁盘块的方式来存取共享磁盘上的文件数据。为了保证数据一致性和读写原子性，一般采用加锁或令牌机制。
共享磁盘模型是构造NAS（Network Attached Storage）和SAN（Storage Area Network）等存储设备的主要方法。与共享文件系统方法相比，它对设备的要求高（高速网络和共享磁盘），实现的难度也要大，往往被用来构造高端或专用的存储设备。共享文件系统模型实现起来比较简单，它对于设备的要求不高，而且通用性好。
3.2.2研究状况
目前分布式/并行文件系统研究情况大致可以分为三类：
商业用途的并行文件系统；公开的分布式文件系统；供研究的并行文件系统。
第一类包括商业并行文件系统像Intel Paragon的PFS和IBM SP的GPFS，HP Exemplar 的HFS以及SGI Origin2000的XFS 。这些文件系统提供了I/O密集型应用所需的高性能和功能性，但是仅仅适用于专门的平台。（SGI发布了Linux的XFS。SGI也为cluster开发一种版本的XFS，称为CXFS）
第二类包括分布式文件系统，诸如NFS、AFS/Coda、InterMezzo、xFS和GFS。这些文件系统被设计来提供来自多个客户端机器的对文件的分布式访问，并且设计根据这种访问设计它们的一致性语义和缓存行为。大型并行科学应用的负载类型通常不会与为分布式访问设计的文件系统很好地结合；特别地，分布式文件系统不会为并行应用典型需要的高带宽并发写而设计。
一些研究项目存在于并行I/O和并行文件系统的领域，像PIOUS、PPFS及Galley。PIOUS
专注于以事务的观点来看I/O，PPFS研究着眼于自适应缓存和预取，Galley关注的是磁盘访问的优化和可选的文件组织。这些文件系统可以是免费获得的，但是大多数仅仅是研究原型，没有被他人使用。
3.3 NFS
3.3.1 概述
NFS从1985年出现至今，已经经历了四个版本的更新，被移植到了几乎所有主流的操作系统中，成为分布式文件系统事实上的标准。NFS利用Unix系统中的虚拟文件系统（Virtual File System，VFS）机制，将客户机对文件系统的请求，通过规范的文件访问协议和远程过程调用，转发到服务器端进行处理；服务器端在VFS之上，通过本地文件系统完成文件的处理，实现了全局的分布式文件系统。Sun公司公开了NFS的实施规范，互联网工程任务组（The Internet Engineering Task Force，IETF）将其列为征求意见稿（RFC-Request for Comments），这很大程度上促使NFS的很多设计实现方法成为标准，也促进了NFS的流行。NFS不断发展，在第四版中提供了基于租赁（Lease）的同步锁和基于会话（Session）语义的一致性等。
3.3.2 体系结构
NFS的核心思想是每台文件服务器提供它的本地文件系统的标准化视图。也就是说，它不关心如何实现本地文件系统，每台NFS服务器支持相同的模型。这个模型带有一个通信协议，该协议允许客户访问存储在一台服务器上的文件。NFS已经开发了多种版本以用于许多不同的操作系统。实际上，对现代UNIX系统而言，NFS通常采用下图所示的层次式体系结构实现。
图1 UNIX系统的基于NFS体系结构
客户使用其本地操作系统提供的系统调用访问文件系统。但是，本地UNIX文件系统接口已被VFS的接口代替。VFS接口上的操作或者被传送到本地文件系统，或者被传送到一
个称为NFS客户的单独组件，该组件负责处理对存储在远程服务器上的文件的访问。在NFS 中，所有客户－服务器通信都是通过RPC完成的。NFS客户将NFS文件系统的操作实现为服务器的RPC。注意，VFS接口所提供的操作可以不同于NFS客户所提供的那些操作。VFS 的整体思路是隐藏不同文件系统之间的差异。
在服务器端，我们可以看到相似的组织方式。NFS服务器负责处理输入的客户请求。RPC存根对请求进行解编，NFS服务器将它们转化成常规的VFS文件操作，随后这些操作被送到VFS层。总之，VFS负责实现真实文件所在的本地文件系统。
这种方法的主要优点在于NFS很大程度上独立于本地文件系统。本质上，它确实不关心客户端或服务器端的操作系统实现的是什么，所关心的唯一重要问题是这些文件系统是否与NFS所提供的文件系统模型兼容。像MSDOS使用短文件名，所以它不能被用于以完全透明的方式实现NFS服务器。
3.3.3 通信机制
NFS设计的一个重要问题是各种操作系统、网络体系结构和传输协议的独立性。比如，这一独立性确保运行在windows系统上的客户可以与UNIX文件服务器通信。这一独立性可以在很大程度上归因于NFS协议本身被置于RPC层之上的事实，因为RPC层隐藏了各种操作系统和网络之间的差异。在NFS中，客户和服务器之间的所有通信都遵循ONC RPC （open network computing RPC，开放式网络计算RPC）协议以及表示编组数据的标准。
3.3.4进程
NFS是一个传统的客户端/服务器系统，在此系统中，客户端请求文件服务器在文件上执行操作。与其他分布式文件系统相比，它长期独有的一个特性是服务器可以是无状态的。换句话说，NFS协议不要求服务器保留任何客户的状态。版本2和版本3沿用了该方法，但是版本4放弃了该方法。
无状态方法的主要优点是简单性。实际的实现不可能完全遵循NFS协议的无状态方法。比如，无状态服务器难以实现文件的锁定。从版本4开始，NFS放弃无状态方法。除了上面的原因外，选择有状态的方法还有一些其他原因。一个重要原因是期望NFS4能够应用于广域网。这就需要客户能够有效地利用高速缓存，这就需要有效的高速缓存一致性协议。这些协议通常在与能够保留客户所用文件的某些信息的服务器合作时工作得最好。
3.3.5 命名
与任何其他分布式文件系统一样，命名在NFS中也起到了非常重要的作用。NFS命名模型的基本思想是为客户端提供完全透明地访问由服务器保存的远程文件系统的机制。这种透明性是通过让客户端在本地文件系统上装载一个远程文件系统实现的，如图2所示。
NFS允许客户端不全部装入整个文件系统，而只装入文件系统的一部分。当服务器允许其他客户使用一个目录及该目录的项目时，称该服务器输出（export）那个目录。一个输出目录可以由客户装入其本地名称空间。
图2 在NFS中装入（部分）远程文件系统
一台NFS服务器可以装入其他服务器输出的目录。但是，它不能再将这些目录输出给它自己的客户端。客户端必须显式地从维护目录的目录服务器那里装入该目录。
3.3.6 同步机制
文件共享的语义
分布式文件系统中的文件通常由多个客户端共享。分布式系统中共享文件的方法主要有四种：UNIX语义（文件上的每个操作对所有进程都是瞬间可见的）、会话语义（文件关闭之前所有改动对其进程都是不可见的）、不可改变的文件（不允许更新文件）和事务处理（所有改动以原子操作的方式发生）。与大多数分布式系统一样，NFS实现了会话语义。
文件锁定
在NFS的传统中，文件锁定是通过一个单独协议处理的，由一个锁管理器实现这个协议。由于该协议过于复杂，而且可能导致执行效果较差的实现，因此未得到广泛使用。NFS 版本4中，文件锁定集成到NFS文件访问协议中。它本质上提供4种与锁定相关的操作，lock、lockt、locku和renew。除了这些操作之外，还有一种锁定文件的隐含方法，称为共享预约（share reservation）。它完全独立于锁定。客户打开文件时，它指定它所需的访问类型，以及服务器应该拒绝的其他客户的访问类型。如果服务器不能满足客户的需求，则该客户打开操作失败。
3.3.7 缓存和复制
与许多分布式文件系统一样，NFS也广泛使用客户缓存来提高性能。另外，它对文件复制提供最低限度的支持。
客户端缓存
NFS3中的缓存主要在协议外部处理。这种方法导致了不同缓存策略的实现，而其中的大部分实现从不保证一致性。
NFS4解决了一些相关一致性的问题，但是其本质上仍以实现相关的方式实现高速缓存的一致性。下图给出了NFS假定的通用缓存模型。每个客户都可以有一个存储器高速缓存，
它包含先前从服务器读取的数据，另外，客户端还有一个磁盘高速缓存，它作为存储器高速
缓存的扩展，并使用相同的一致性参数。
图3 NFS中的客户缓存
通常，客户缓存文件数据、属性、文件句柄及目录。处理被缓存的数据等的一致性可采用不同策略。NFS4支持两种缓存文件数据的方法。一种相当于会话语义。另一种是打开文件时，服务器可以将它的某些权限委派给客户。
复制服务器
NFS4对文件复制提供最低限度的支持。只有整个文件系统可以被复制。实际提供复制服务器的方法取决于特定的NFS实现。NFS4中并未规定如何实现复制。
3.3.8 容错性
在最新版NFS之前的各种版本NFS中，容错根本不是问题，其原因是NFS协议不要求服务器是有状态的。所以，从服务器崩溃状态恢复服务器是相当简单的，这是因为没有状态会丢失。当然，在单独的锁管理器维护状态的情况下，需要采取特殊的措施。
由于NFS4放弃了无状态的设计方案，所以它需要处理容错和恢复问题。特别是，文件锁定和委派时会用到状态。另外，我们还需要采取特殊措施来处理位于NFS协议底层的RPC 机制的不可靠性。
RPC故障
NFS的底层RPC语义存在的主要问题是它缺少对重复请求的检测。因此，当RPC响应丢失而客户又成功地重传原先请求时，服务器最终会多次执行该请求。由服务器实现的重复请求高速缓存（duplicate request cache）[NFS: Network File System V ersion 3 Protocol Specification]可以减轻该问题。每个来自客户端的请求头部都带一个唯一XID，当RPC请求到来时，服务器缓存其标识符。只要服务器还未发出响应，就说明服务器正在处理该请求。当服务器处理了某请求后，也缓存该请求的关联响应，此后该响应才返回客户。
出现故障时的文件锁定
NFS3中的文件锁定是由单独的服务器处理的。这样，NFS协议的无状态性质仍可保留，与容错相关的问题将由锁服务器处理。但是，由于NFS4引入了文件锁，它必然要提供一种处理客户和服务器崩溃的基本机制，以此作为NFS协议的一部分。为了解决客户崩溃问题，服务器为它授予的每个锁分配一个租用。当租用到期时，服务器删除对应的锁，从而释放其关联的资源。为了防止服务器删除锁，客户应在其租用到期之前更新租用。
出现故障时的打开委派
当客户或服务器崩溃时，打开委派引起了另外的问题。考虑执行被委派文件的打开操作的客户，客户对文件恢复负部分责任。服务器崩溃并随后得到恢复时，它的处理过程与锁恢复类似。
3.3.9 安全性
如前所述，NFS的基本思想就是远程文件系统应该像客户端的本地文件系统那样提供给用户。从这个角度来说，NFS的安全性主要集中于客户端与服务器之间的通信。除了安全RPC之外，控制对文件的访问也是十分必要的，这是通过NFS中的访问控制文件属性处理的。文件服务器负责验证其客户的访问权限。结合安全RPC，NFS的安全体系结构如下图4所示：
图4 NFS安全体系结构
3.4 AFS、DFS、Coda和InterMezzo
AFS是由美国卡内基-梅隆大学（CMU）和IBM 公司联合成立的信息技术中心（ITC）研制开发的分布式文件系统，并成为研制开发某些文件系统的基础。DFS是分布式计算环境DCE （Distibuted Computing Environment）的重要组成部分和支持弱连接环境的分布式文件系统，DFS和CODA都是由AFS 演变而来的。AFS 最初是为了支持大学校园内数千台工作站间的文件共享而开发的，目前已被某些单位的Intranet用做信息共享机制。AFS 性能与一般的分时系统相当。AFS 提供了对话期间文件共享语义（session semantics）。对话期间共享语义保证：当一个客户关闭文件后，它对该文件的所有修改可被随后打开该文件的其它客户可见。当某个客户打开一个文件，并对之作了修改，不能立即被其它客户看到，只有在由打开/关闭组成的对话期间完成之后，其它客户才可以看到被修改文件的最新数据。AFS 的主要设计目标是良好的可扩展性，可扩展性好是AFS最大的特点。AFS 采用机群式的体系结构，支持组织结构的一定自治性，同时也提高了可扩展性。从2.0 版开始AFS 使用了服务器启动的、基于回调的缓存机制，减少了服务器网络负载开销。在可用性方面，因为服务器是有状态的、且是专用的，若服务器失败，则服务器所提供的整个共享文件空间将失效，若某个客户失败，则对其它客户和服务器没有影响。
AFS在可扩展性方面强于NFS。但是仍存在以下问题：第一，它采用有状态模型，服务器一旦失效，它提供的整个共享空间将失效。第二，AFS不是UNIX语义。多个客户端同时打开同一个文件时，一个客户端对文件的修改并不能立即反应给其它客户端。
DFS也是基于AFS文件系统进行研究开发的。它的协议特点在很多方面同AFS类似。但DFS实现的是UNIX文件共享语义，DFS用令牌机制取代了AFS的callback机制，用来
实现缓存副本数据的全局唯一性。通过对客户端发放和收回令牌来控制客户端对文件的操作权限。当服务器令牌管理器发现某个令牌请求与已发放的令牌产生冲突时，服务器会通知所有持有冲突令牌的客户端把缓存的数据写回更新。令牌本身还有生命期，只有在生命期期间对缓存数据的操作才是有效的。DFS的结构复杂，不容易实现，而且高速缓存的一致性维护机制和死锁避免机制也是高度复杂的，这使得DFS没有得到广泛应用。
NFS和AFS都是为提供文件共享服务设计的早期的分布式文件系统。AFS客户端使用了本地磁盘来缓存数据，它的扩展性强于NFS。但是AFS的可用性和所提供的共享语义并不理想。为了改进可用性，CMU开发了Coda文件系统以及实现更加简单的InterMezzo文件系统。为了实现细粒度的UNIX共享语义，DFS被开发出来。
AFS在功能、性能、易于管理等方面做的比较出色，但可用性较差。一旦服务器或网络出现问题，将造成不可预料的后果。为了解决这个问题，1990年CMU在AFS的基础上又开发了Coda文件系统。Coda采用了两种新的机制来保证可用性：服务器端复制和断开连接操作。服务器端复制就是将一个文件在多个服务器中保存多个副本。这样，一个服务器失效，其它的服务器可以继续为客户端提供服务。在缓存策略方面，Coda继承了AFS，即客户端在本地磁盘中缓存整个文件。Coda客户端一旦检测到服务器失效，仍然可以继续访问本地缓存的操作，这就是所谓的断开连接操作。连接恢复时，又恢复到正常状态。此外，客户端还可以主动进行断开连接操作，这样就能够更好地支持移动计算。
InterMezzo也是CMU开发的分布式文件系统。InterMezzo的设计目标是用更加简洁方法实现Coda文件系统协议特点。它从以下三个方面简化了文件系统的实现：第一，服务器端和客户端缓存都直接利用本地文件系统，实际上都是在本地文件系统外面再封装一层。第二，使用了功能强大更加高级的语言，如Perl。第三，直接利用已有的高级协议，如利用TCP协议实现通信，利用rsync实现同步操作，利用ssl/ssh实现安全性。InterMzzo只用了2500行的C代码和6000行的Perl代码就实现了Coda协议的基本功能。
3.5 SpriteFS和Zebra
图5 SpriteFS中的缓存
为了进一步提高分布式文件系统的访问性能，加州大学伯克力分校开发了Sprite文件系统。SpriteFS是Sprite网络操作系统的一个重要组成部分。它使用大容量的主存来缓存文件数据，并且在服务器端和客户端都设置了缓存。客户端的一个进程发出一个文件访问请求后，先在客户端的缓存中查找缓存数据。如果数据不在客户端缓存中，这个请求才被发送到服务器端。服务器端处理请求时也是先看内存中是否缓存有请求数据，只有数据不在内存中时，才真正地从服务器端的磁盘读取数据，最后返回给客户端。使用缓存技术的优势在于：首先
可以减少数据请求的延时；其次，在多个进程并发访问同一个文件时，至多从磁盘读取一次就可以满足各个进程的请求，大大减少了磁头移动的次数。
SpriteFS文件数据在多个客户端缓存中有多个副本，这就涉及到维护客户端缓存一致性的问题。Sprite的开发者认为写共享发生的频率较低，因此采用了简单的读写锁来解决一致性问题。文件缓存的容量越大，它给文件系统性能提升方面带来的优势也就越大。为了更加充分利用操作系统的内存，SpriteFS可以和虚拟内存交互来动态改变文件系统缓存的大小，这种设计既可以尽可能多地缓存文件数据又不会影响虚拟内存的使用。SpriteFS在提升文件系统性能方面作出了较大的贡献，但在处理并发写请求时的性能仍旧较低。在可用性方面，SpriteFS也没有给与充分的考虑。
Zebra也是由加州大学伯克力分校开发的，它设计目标是进一步提升文件系统的访问性能及可用性。它的设计思想借鉴了LFS(log-structured FS) 和RAID技术.Zebra通过在多个服务器上分条存储文件数据来提高吞吐率。传统的分条策略只是基于单个文件，即将单个文件分为多个部分存储于多个服务器。这只对提升大文件的读写请求起作用。为了能同样提升小文件的请求性能，Zebra借鉴了LFS的技术。LFS修改或写入新的文件数据时，不是在数据原有的位置上进行修改，而是已追加的方式将数据写到文件系统的末尾。这种策略可以把多个小的写操作合并成一个大的请求数据流，最后再一并提交到磁盘。可见，LFS可以显著提升文件系统写性能。Zebra使用同LFS类似的技术，每次修改数据都是以追加的方式写到文件系统末尾，它将每个客户端所有写请求合并成一个大的数据流，并将这个大的数据流在多个服务器上分条存储。因此，Zebra可以同样提升小文件的写性能。在提高可用性方面Zebra 还使用了RAID技术。它在分片存储文件数据的同时还存储了每个分片的奇偶信息，这样，即使有一个文件服务器失效，文件系统仍就可以使用奇偶信息来还原出失效服务器上的文件数据。当一个文件服务器失效时，Zebra可以不间断地继续提供文件系统服务。
图6 Zebra中对每个客户端的数据流分条存储
SpriteFS和Zebra都是加州大学伯克力分校开发的分布式文件系统。两个文件系统都把提升性能作为设计的首要目标，但是所采用的策略却截然不同。SpriteFS采用的是缓存技术；Zebra采用的是分条存储技术。
3.6 xFS
3.6.1 概述
20世纪90年代初，面对广域网和大容量存储应用的需求，借鉴当时先进的高性能对称多处理器的设计思想，加利福尼亚大学设计开发的xFS，克服了以前的分布式文件系统一般都运行在局域网（LAN）上的弱点，很好地解决了在广域网上进行缓存，以减少网络流量的难题。它所采用的多层次结构很好地利用了文件系统的局部访问的特性，无效写回（Invalidation-based Write Back）缓存一致性协议，减少了网络负载。对本地主机和本地存储空间的有效利用，使它具有较好的性能。
3.6.2 体系结构
xFS的与众不同之处在于它的无服务器设计，整个文件系统分布于多台机器，包括客户。这种方法完全不同于大多数其他文件系统，后者通常以集中式的方式组织，即使系统中存在多个用于发送和复制文件的服务器，像AFS和Coda。
xFS设计为运行在高速局域网之上，即其中的机器通过高速连接互连。很多现代网络都满足这一要求，特别是工作站的集群。通过将数据和控制完全地分布于局域网内的机器，xFS 的设计人员旨在达到比使用（可能是复制的）文件服务器的传统分布式文件系统更高的可扩展性和容错性。
在xFS的体系结构中，有三种不同类型的进程。存储服务器是负责存储文件的某些部分的进程。多个存储服务器共同地实现虚拟磁盘的阵列，此阵列类似于以RAID形式实现的磁盘阵列。元数据管理器是负责记录文件数据块的实际存储位置的进程。注意，同一文件的数据块可能散布于多个存储服务器，管理器将客户的请求转发到适当的存储服务器。由此看来，元数据管理器作为文件数据块的定义服务器运行。最后xFS的客户是接受用户请求以执行文件操作的进程，每个客户有缓存的能力，并且可以向其他客户提供被缓存的数据。
xFS的基本设计原则是任何机器都可以担当客户、管理器和服务器的角色。在完全对称的系统中，每台机器都运行这三个进程。但是，使用专用机器运行存储服务器，而其他机器运行客户或管理器进程也是可能的。
图7 xFS进程在多台机器上的一种典型分布
3.6.3 通信
最初xFS中的所有通信都是使用RPC处理的，但是后来由于某些原因，xFS放弃了这
种方法，最重要的原因是其性能较低。RPC的另一个问题是它通常假设通信是peer-to-peer 的。因为数据和控制完全分布于多台机器，所以单一客户的请求可能设计一连串进程间的通信。RPC服务器必须显示地记录未完成的请求，并把输入的响应匹配到适当的请求。因而，简单的阻塞机制是行不通的。
由于以上原因，xFS中的通信被活动消息取代。在活动消息中，接收方的处理程序以及调用它的必要参数都是指定的。消息到达时，处理程序被直接调用，运行直至程序完成。处理程序执行时，不能传递其他消息。这种方法的优点体现在效率方面，但是，活动消息使通信的设计变得更加复杂，比如，不允许阻塞处理程序。处理程序还应该相对较小，这是因为处理程序的执行妨碍了处理程序所在主机的其他网络通信。
3.6.4 进程
xFS的实现基于LFS日志文件系统的存储系统。
在LFS中，写入文件系统的各种数据，包括对inode、目录块和数据块的修改都被存入缓冲区，用一个单独操作将它们一起写入磁盘。所有的写入数据共同组成一个（固定大小的）记录段，该记录段被追加到日志后面。因为数据此时可能散布于整个日志，所以这种方法的主要问题是查找文件块。为此，使用一个称为imap的附加表将inode引用映射为它们在日志中的位置，一旦找到了inode，也就可以定位文件块了。
为了提高性能和可用性，xFS采用Zebra文件系统采用的方法。在Zebra文件系统中，日志分布于多台服务器，日志的组织结构类似于一类RAID数据的组织结构。下图显示了这种方法。每当客户向日志追加包含更新数据的记录段时，它将记录段分成几个大小相等的分段，这被称为带区划分（striping）。每个段存储在不同的存储服务器上。客户还计算出一个奇偶校验分段（parity fragment），该分段存储在附加服务器上。如果任何一个服务器出现故障，那么可以从奇偶校验分段和存储在其他无故障服务器上的分段重新计算出一个段来。
图8 xFS的基于日志的带区划分原理
xFS中的存储服务器被组织成带区组（stripe group）。将记录划分成多个分段时，客户向一个带区组中的服务器写入这些分段。这种方法不同于Zebra所采用的方法，在Zebra方法中，记录段的各个分段总是被写入所有存储服务器。用带区组代替所有存储服务器，使得xFS能够容易地添加更多的存储服务器：因为它没有记录段的各个分段需要存储于所有服务器（因而由所有服务器管理）的要求。它使用一个全局复制的表来查找哪些服务器属于哪个带区组。
使用日志结构文件系统要求我们记录数据的实际存储位置。为此，xFS中的每个文件都有一个关联的管理器。这个管理器维护inode引用的imap表，通过这个表，它可以在日志中找到文件的当前inode。每当在文件上执行更新操作的时候，文件的inode也会改变。而这种改变要求向日志追加一个新版本的inode，而这又要求文件的管理器必须得到通知以使它更新其imap。
xFS将文件的管理分布于多个管理器，而不是只使用一个单一的管理器，也就是说，系统中可能存在很多管理器，它们共同维护文件数据的存储位置的信息。那么，搜索一个文件要求客户联系该文件的管理器以访问该文件。一个单独的、全局复制的表，称为管理器映射（manager map），用于搜索给予文件标识符的管理器哦。文件标识符相当于前面所说的inode 引用。
如果我们忽略客户端缓存，那么xFS的客户是相当简单的进程，它只提出读、写文件的请求。下图显示了从文件f读取数据块b的基本方法。
图9 读取xFS中的数据块
步骤1：客户首先在目录中搜索文件f，搜索操作返回文件标识符fid；
步骤2：使用该标识符在管理器映射中搜索f所关联的元数据管理器；
步骤3：定位到管理器之后，fid和b被传送到管理器。管理器在它的内部表中搜索实际的inode。此时，在日志中应找到该inode的确切位置。这一位置信息包括带区组标识符、记录段标识符和该记录段中的偏移；
步骤4：现在需要做的是找到该inode所在的服务器，这要求搜索文件所写入的带区组，包含inode的记录段被写入到一些服务器中，而这个搜索操作返回这些服务器的列表；
步骤5：通过记录段标识符和偏移，客户可以计算出哪个服务器实际存储该inode，并向它传送该inode的磁盘地址。
然后重复执行步骤4和步骤5，但这次是为了读取数据块b。
3.6.5 命名
除了使用各种系统范围的标识符来搜索管理器、块、inode等的位置之外，xFS的命名
表1 xFS所用的主要数据结构
3.6.6 缓存
xFS的客户维护本地高速缓存。其一致性方案类似于Coda的一致性方案，只是它缓存的是数据块，而不是整个文件。也就是说，当一个客户想要写入一块数据时，它联系该数据块所属文件的管理器，并请求写权限。管理器首先使由其他客户缓存的该数据块的所有拷贝无效，然后，它授予该客户写权限。这样，管理器就记录了数据块被缓存的位置，以及哪个客户被授予了写权限。后者也被称为当前所有者。
只要所有者拥有一个数据块的写权限，它不需要联系管理器就可以使用它的缓存拷贝来执行更新操作。当另一个客户想要访问该数据块时，所有者的写权限被撤销。此时，清洗当前所有者的高速缓存，并存储该数据块，直到它可以被转发到一个存储服务器。另外，该数据块被发送到新的客户，而这个新的客户称为写一个所有者。
xFS进一步实现了协作缓存（collaborative caching）。在该方法中，每当客户想要访问一个数据块时，它联系适当的管理器，如上所述。但是，管理器不是在存储服务器上定位所请求的数据块，而是先检查当前是否存在其他已经缓存了所请求数据块的客户。如果存在这样的客户，那么它就从高速缓存获取一份拷贝，并将其返回给提出请求的客户。
3.6.7 容错性
通过将存储服务器实现为保留冗余信息的带区组，使得xFS的可用性比传统方法的可用性要高。每当一个单独的服务器崩溃时，它可以通过获取其他服务器上的奇偶校验分段来恢复分段。如果奇偶校验分段丢失了，那么它可以容易地从现有的分段计算出来。但是如果统一组内的多个服务器崩溃了，那么需要采取特殊的措施，但是这些措施还未被实现。
管理器的恢复主要是通过不时地对管理器当前持有的数据设置检查点得到支持。一个难以处理的问题是恢复管理器的映射。设置检查点对此有帮助，但是仍需考虑检查点后更改。为此，各个客户记录它们自最后一个检查点以来向管理器发送的更新。这样，管理器可以请求客户重放一个检查点之后的更新，从而使得它的imap进入与存储服务器上的信息一致的状态。
3.6.8 安全性
xFS仅对安全性提供最低限度的支持。除了实现常见的访问控制机制外，xFS要求客户、管理器和存储服务器运行于可信任的机器上以实施安全性。但是，它提供了一种让不被信任的NFS客户使用安全RPC访问一些xFS机器的简单措施。实际上，NFS客户使用安全RPC 联系xFS客户。因此，xFS客户将作为那个NFS客户的NFS服务器。
xFS是一种采用了无服务方式以提供可扩展的文件服务的机群文件系统。同zebra一样，xFS 集成了存储分组结构和日志结构，并且也实现了数据存储于元数据管理的彼此分离。
XFS通过全部分布数据存储于元数据管理的功能减少了集中的瓶颈。为了获得更高的性能，xFS采用了合作缓存，一种通过各客户缓存的协调合作来替代传统的集中的服务端缓存。在xFS中，任何机器都可以缓存、存储或则控制任意的数据块，这种方式可以提供比传统文件系统结构更好的性能和可扩展性。
xFS的一个主要的特点是它的合作缓存的算法，即是―N-C hance‖算法。这种算法动态地把每个客户端的缓存分开成块，以提供给当地的和那些存储在合作缓存的应用程序的应用。算法的置换机制是综合应用了当地―LRU‖信息和重复避免（duplicate avoidance）以决定所最应该置换的块。实际上，xFS所应用的缓存结构与远端缓存结构以及―Feeley‖描述的全局存储服务（GMS）具有相类似的构想。GMS比―N-Chance‖算法更具有通用性，但它没有提供一致性机制并且依靠一种集中式的算法来决定块的置换。Sarkar and Hartman 提出了一种基于提示（hint-based）的合作缓存方式,这种方式可以减少客户机在通过提示调用和置换块是对管理者的依靠性。实验表明这种方式可以在增加少量的负载的情况下获得同xFS所相似的效果。但是它有一个缺点是它必须维护在文件级粒度下的缓存一致性，否则可能导致在某些情况下的共享错误问题（false-sharing problem）。
3.7 Tiger Shark和Frangipani
3.7.1 TigerShark
TigerShark是IBM公司为AIX操作系统开发的并行文件系统。它最初的设计目标是支持大规模实时多媒体应用，如视频点播系统。大规模视频点播系统在提供实时数据，可扩展性，高可用性和易管理等方面对文件系统提出了更高的要求。为了达到这些设计目标，TigerShark采用了如下几个策略：第一，为了保证服务质量采用了资源预留技术和deadline 调度策略。资源预留技术通过控制同时服务的客户端数量来保证数据传输的带宽。即如果新的客户端请求会影响到已经正在服务的客户端的服务质量，新的请求将被拒绝。Deadline 调度技术可以使数据传输速率达到磁盘带宽的90％。第二，采用了更大的数据块来支持大的多媒体文件。第三，在更多的磁盘上实现分条存储，这样可以更有效地提高吞吐率。第四，服务器端采用块级的数据复制来提高可用性。第五，在线管理策略可以帮助实现自动故障恢复和reconfigure。TigerShark是一个比较成功的分布式文件系统，它在大规模地多媒体应用服务市场上已经被广泛使用，同时它还被进一步扩展以适应通用大规模并行计算的需求。
图10 Tiger Shark 结构图
分布式文件系统Hadoop HDFS与传统文件系统Linux FS的比较与分析
６苏州大学学报（工科版）第３０卷 图１Ｉ－ＩＤＦＳ架构 ２ＨＤＦＳ与ＬｉｎｕｘＦＳ比较 ＨＤＦＳ的节点不管是ＤａｔａＮｏｄｅ还是ＮａｍｅＮｏｄｅ都运行在Ｌｉｎｕｘ上，ＨＤＦＳ的每次读／写操作都要通过ＬｉｎｕｘＦＳ的读／写操作来完成，从这个角度来看，ＬｉｎｕｘＰＳ是ＨＤＦＳ的底层文件系统。 ２．１目录树（ＤｉｒｅｃｔｏｒｙＴｒｅｅ） 两种文件系统都选择“树”来组织文件，我们称之为目录树。文件存储在“树叶”，其余的节点都是目录。但两者细节结构存在区别，如图２与图３所示。 一二 Ｒｏｏｔ ＼ 图２ＩｔＤＦＳ目录树围３ＬｉｎｕｘＦＳ目录树 ２．２数据块（Ｂｌｏｃｋ） Ｂｌｏｃｋ是ＬｉｎｕｘＦＳ读／写操作的最小单元，大小相等。典型的ＬｉｎｕｘＦＳＢｌｏｃｋ大小为４ＭＢ，Ｂｌｏｃｋ与ＤａｔａＮ－ｏｄｅ之间的对应关系是固定的、天然存在的，不需要系统定义。 ＨＤＦＳ读／写操作的最小单元也称为Ｂｌｏｃｋ，大小可以由用户定义，默认值是６４ＭＢ。Ｂｌｏｃｋ与ＤａｔａＮｏｄｅ的对应关系是动态的，需要系统进行描述、管理。整个集群来看，每个Ｂｌｏｃｋ存在至少三个内容一样的备份，且一定存放在不同的计算机上。 ２．３索引节点（ＩＮｏｄｅ） ＬｉｎｕｘＦＳ中的每个文件及目录都由一个ＩＮｏｄｅ代表，ＩＮｏｄｅ中定义一组外存上的Ｂｌｏｃｋ。 ＨＤＰＳ中ＩＮｏｄｅ是目录树的单元，ＨＤＦＳ的目录树正是在ＩＮｏｄｅ的集合之上生成的。ＩＮｏｄｅ分为两类，一类ＩＮｏｄｅ代表文件，指向一组Ｂｌｏｃｋ，没有子ＩＮｏｄｅ，是目录树的叶节点；另一类ＩＮｏｄｅ代表目录，没有Ｂｌｏｃｋ，指向一组子ＩＮｏｄｅ，作为索引节点。在Ｈａｄｏｏｐ０．１６．０之前，只有一类ＩＮｏｄｅ，每个ＩＮｏｄｅ都指向Ｂｌｏｃｋ和子ＩＮ－ｏｄｅ，比现有的ＩＮｏｄｅ占用更多的内存空间。 ２．４目录项（Ｄｅｎｔｒｙ） Ｄｅｎｔｒｙ是ＬｉｎｕｘＦＳ的核心数据结构，通过指向父Ｄｅｎ姆和子Ｄｅｎｔｒｙ生成目录树，同时也记录了文件名并 指向ＩＮｏｄｅ，事实上是建立了＜ＦｉｌｅＮａｍｅ，ＩＮｏｄｅ＞，目录树中同一个ＩＮｏｄｅ可以有多个这样的映射，这正是连
Hadoop分布式文件系统：架构和设计
Hadoop分布式文件系统：架构和设计 引言 (2) 一前提和设计目标 (2) 1 hadoop和云计算的关系 (2) 2 流式数据访问 (2) 3 大规模数据集 (2) 4 简单的一致性模型 (3) 5 异构软硬件平台间的可移植性 (3) 6 硬件错误 (3) 二HDFS重要名词解释 (3) 1 Namenode (4) 2 secondary Namenode (5) 3 Datanode (6) 4 jobTracker (6) 5 TaskTracker (6) 三HDFS数据存储 (7) 1 HDFS数据存储特点 (7) 2 心跳机制 (7) 3 副本存放 (7) 4 副本选择 (7) 5 安全模式 (8) 四HDFS数据健壮性 (8) 1 磁盘数据错误，心跳检测和重新复制 (8) 2 集群均衡 (8) 3 数据完整性 (8) 4 元数据磁盘错误 (8) 5 快照 (9)
引言 云计算（cloud computing)，由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。在此过程中被服务者只是提供需求并获取服务结果，对于需求被服务的过程并不知情。同时服务者以最优利用的方式动态地把资源分配给众多的服务请求者，以求达到最大效益。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS 能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 一前提和设计目标 1 hadoop和云计算的关系 云计算由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。针对海量文本数据处理,为实现快速文本处理响应,缩短海量数据为辅助决策提供服务的时间,基于Hadoop云计算平台,建立HDFS分布式文件系统存储海量文本数据集,通过文本词频利用MapReduce原理建立分布式索引,以分布式数据库HBase 存储关键词索引,并提供实时检索,实现对海量文本数据的分布式并行处理.实验结果表 明,Hadoop框架为大规模数据的分布式并行处理提供了很好的解决方案。 2 流式数据访问 运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3 大规模数据集 运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
分布式存储系统的一些理解和实践
分布式存储系统的一些理解和实践 张建伟 一、分布式存储系统介绍 1.简介 互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不能很好的满足需求。分布式存储系统应运而生。它有良好的扩展性，弱化关系数据模型，甚至弱化一致性要求，以得到高并发和高性能。按功能分类，主要有以下几种： ?分布式文件系统 hdfs ceph glusterfs tfs ?分布式对象存储 s3(dynamo) ceph bcs(mola) ?分布式表格存储 hbase cassandra oceanbase ?块存储 ceph ebs(amazon) 分布式存储系统，包括分布式系统和单机存储两部分；不同的系统，虽在功能支持、实现机制、实现语言等方面是有差异的，但其设计时，关注的关键问题是基本相同的。单机存储的主流实现方式，有hash引擎、B+树引擎和LSM树(Log Structured Merge Tree)三种，不展开介绍。本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计部分，需要关注的关键问题。 2.适用场景 各分布式存储系统功能定位不尽相同，但其适用和不适用的场景，在一定程度上是相同的，如下。
1)适用 大数据量（大于100T，乃至几十PB） key/value或者半结构化数据 高吞吐 高性能 高扩展 2)不适用 Sql查询 复杂查询，如联表查询 复杂事务 二、分布式存储系统设计要点 1.数据分布 分布式存储，可以由成千甚至上万台机器组成，以实现海量数据存储和高并发。那它最先要解决的就是数据分布问题，即哪些数据存储在哪些机器（节点）上。常用的有hash类算法和用meta表映射两种方式。一般完全分布式的设计（无master节点），会用hash类算法；而集中式的设计（有master节点）用meta表映射的方式。两者各有优缺点，后面讲到具体问题时再做比较。 1)一致性hash 将存储节点和操作的key（key唯一标识存储的object，有时也叫object name）都hash到0~2的32次方区间。映射到如下环中的某个位置。沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。如下图所示：
分布式文件存储方案
1DFS系统 (DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布 分布式文件系统 式计算环境(DCE)中的文件系统部分。 如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式： 只读共享任何客户机只能访问文件，而不能修改它，这实现起来很简单。 受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。 并发写操作这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。 NFS和AFS的区别 NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步： 无状态系统在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS 就是个无状态系统。 回呼(Callback)系统在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。 无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若
HDFS分布式文件系统具备的优点
HDFS分布式文件系统具备的优点 随着互联网数据规模的不断增大，对文件存储系统提出了更高的要求，需要更大的容量、更好的性能以及更高安全性的文件存储系统，与传统分布式文件系统一样，HDFS分布式文件系统也是通过计算机网络与节点相连，但也有优于传统分布式文件系统的优点。 1. 支持超大文件 HDFS分布式文件系统具有很大的数据集，可以存储TB或PB级别的超大数据文件，能够提供比较高的数据传输带宽与数据访问吞吐量，相应的，HDFS开放了一些POSIX的必须接口，容许流式访问文件系统的数据。 2. 高容错性能 HDFS面向的是成百上千的服务器集群，每台服务器上存储着文件系统的部分数据，在集群的环境中，硬件故障是常见的问题，这就意味着总是有一部分硬件因各种原因而无法工作，因此，错误检测和快速、自动的恢复是HDFS最核心的架构目标，因此，HDFS具有高度的容错性。 3. 高数据吞吐量 HDFS采用的是“一次性写，多次读”这种简单的数据一致性模型，在HDFS 中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了，这样简单的一致性模型，有利于提高吞吐量。 4. 流式数据访问 HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理，应用程序能以流的形式访问数据
集。 Hadoop已经迅速成长为首选的、适用于非结构化数据的大数据分析解决方案，HDFS分布式文件系统是Hadoop的核心组件之一，保证了大数据的可靠存储，与MapReduce配合使用，可以对结构化和复杂大数据进行快速、可靠分析，从而为企业做出更好的决策，促进收入增长，改善服务，降低成本提供有力支撑！
分布式文件系统架构设计(20201126073806)
分布式文件系统架构设计 1. 前言...................................................... 3.
2. HDFS1 (3) 3. HDFS2 (5) 4. HDFS3 ............................................................................................. 1 1 5. 结语..................................................... 1.5
1. 刖言 Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System )，简称HDFS，解 决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce ，解决了海量数据如何计 算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。而我 们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。 Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。同时也相对应的有HDFS1 ，HDFS2，HDFS3三个大版本。后面的HDFS的版本，都是对前一个版本的架构进行了调整优 化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我 们的系统架构能力。 2. HDFS1
分布式文件系统DFS使用方法总结(超详细)
DFS使用方法总结（超详细） 使用分布式文件系统 (DFS)，系统管理员可以使用户方便地访问和管理物理上分布在网络各处的文件。通过DFS，可以使分布在多个服务器上的文件如同位于网络上的一个位置一样显示在用户面前。 您可采用两种方式实施分布式文件系统：一种是独立的根目录分布式文件系统，另一种是域分布式文件系统。 独立的DFS根目录： 不使用 Active Directory。 至多只能有一个根目录级别的目标。 使用文件复制服务不能支持自动文件复制。 通过服务器群集支持容错。 域DFS根目录： 必须宿主在域成员服务器上。 使它的DFS名称空间自动发布到 Active Directory 中。 可以有多个根目录级别的目标。 通过 FRS 支持自动文件复制。 通过 FRS 支持容错。 分布式文件系统 (DFS) 映射由一个DFS根目录、一个或多个DFS链接以及指向一个或多个目标的引用组成。 DFS根目录所驻留的域服务器称为主服务器。通过在域中的其他服务器上创建根目标，可以复制DFS根目录。这将确保在主服务器不可用时，文件仍可使用。因为域分布式文件系统的主服务器是域中的成员服务器，所以默认情况下，DFS映射将自动发布到 Active Directory 中，从而提供了跨越主服务器的DFS拓扑同步。这反过来又对DFS根目录提供了容错性，并支持目标的可选复制。通过向DFS根目录中添加DFS链接，您可扩展DFS映射。Windows Server 2003 家族对DFS映射中分层结构的层数的唯一限制是对任何文件路径最多使用 260 个字符。新DFS链接可以引用具有或没有子文件夹的目标，或引用整个Windows Server 2003 家族卷。 创建DFS根目录 使用DFS管理工具，您可以指定某个目标，指派它为DFS根目录。除了访问该目标外，用户还可以访问该目标的任何子文件夹。使用 Windows Server 2003 Enterprise Edition 或Windows Server 2003 Datacenter Edition 时，您可在单独计算机上作为多个DFS根目录的宿主。由于DFS Active Directory 对象的大小，大型的基于域的DFS名称空间可能会显著地增加网络传输量。因此，建议您为域根使用的DFS链接的个数少于 5000。建议在运行 Windows Server 2003 的服务器上的独立的根目录的最大名称空间为 50,000 个链接。 如何创建DFS根目录: 1.打开分布式文件系统。 2.在“操作”菜单上，单击“新建根目录”。
分布式文件系统架构设计
分布式文件系统架构设计
目录 1.前言 (3) 2.HDFS1 (3) 3.HDFS2 (5) 4.HDFS3 (11) 5.结语 (15)
1.前言 Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS，解决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce，解决了海量数据如何计算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。而我们今天重点给大家介绍的是Hadoop里享誉世界的优秀的分布式文件系统-HDFS。 Hadoop重要的比较大的版本有:Hadoop1，Hadoop2，hadoop3。同时也相对应的有HDFS1，HDFS2，HDFS3三个大版本。后面的HDFS的版本，都是对前一个版本的架构进行了调整优化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。 2.HDFS1
最早出来投入商业使用的的Hadoop的版本，我们称为Hadoop1，里面的HDFS就是HDFS1，当时刚出来HDFS1，大家都很兴奋，因为它解决了一个海量数据如何存储的问题。HDFS1用的是主从式架构，主节点只有一个叫：Namenode，从节点有多个叫：DataNode。 我们往HDFS上上传一个大文件，HDFS会自动把文件划分成为大小固定的数据块（HDFS1的时候，默认块的大小是64M，可以配置），然后这些数据块会分散到存储的不同的服务器上面，为了保证数据安全，HDFS1里默认每个数据块都有3个副本。Namenode是HDFS的主节点，里面维护了文件系统的目录树，存储了文件系统的元数据信息，用户上传文件，下载文件等操作都必须跟NameNode进行交互，因为它存储了元数据信息，Namenode为了能快速响应用户的操作，启动的时候就把元数据信息加载到了内存里面。DataNode是HDFS的从节点，干的活就很简单，就是存储block文件块。
3种分布式文件系统
第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备
Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式： 1. 直接通过Client实例连接到Client； 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面： 第一，数据的定位是通过CRUSH算法来实现的。
分布式文件系统设计方案
分布式文件系统（DFS）解决方案 一“分布式文件系统（DFS）”概述 DFS并不是一种文件系统，它是Windows Server System上的一种客户/服务器模式的网络服务。它可以让把局域网中不同计算机上的不同的文件共享按照其功能组织成一个逻辑的分级目录结构。系统管理员可以利用分布式文件系统(DFS)，使用户访问和管理那些物理上跨网络分布的文件更加容易。通过DFS，可以使分布在多个服务器或者不同网络位置的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。 例如，如果您的销售资料分散在某个域中的多个存储设备上，您可以利用DFS 使其显示时就好像所有的资料都位于同一网络共享下，这样用户就不必到网络上的多个位置去查找他们需要的信息。 二部署使用“分布式文件系统（DFS）”的原因 ●访问共享文件夹的用户分布在一个站点的多个位置或多个站点上； ●大多数用户都需要访问多个共享文件夹； ●通过重新分布共享文件夹可以改善服务器的负载平衡状况； ●用户需要对共享文件夹的不间断访问；
●您的组织中有供内部或外部使用的Web 站点； ●用户访问共享文件需要权限。 三“分布式文件系统（DFS）”类型 可以按下面两种方式中的任何一种来实施分布式文件系统： 1．作为独立的分布式文件系统。 ●不使用Active Directory。 ●至多只能有一个根目录级别的目标。 ●使用文件复制服务不能支持自动文件复制。 ●通过服务器群集支持容错。 2．作为基于域的分布式文件系统。 ●必须宿主在域成员服务器上。 ●使它的DFS 名称空间自动发布到Active Directory 中。 ●可以有多个根目录级别的目标。 ●通过FRS 支持自动文件复制。 ●通过FRS 支持容错。 四分布式文件系统特性 除了Windows Server System 中基于服务器的DFS 组件外，还有基于客户的DFS 组件。DFS 客户程序可以将对DFS 根目录或DFS 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于
分布式文件系统MFS(moosefs)实现存储共享
由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用户反馈访问慢的问题。通过排查个服务器的情况，发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，N个服务器通过nfs方式共享一个服务器的存储空间，使得 NFS服务器不堪重负。察看系统日志，全是nfs服务超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题；一旦NFS服务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我们所期待的。 下面是某个集群使用nfs共享的示意图： 这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有靠共享提供数据的应用就不再可用，尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份，但这对提高整个系统的性能毫无帮助。基于这样一种需求，我们需要对nfs服务器进行优化或采取别的解决方案，然而优化并不能对应对日益增多的客户端的性能要求，因此唯一的选择只能是采取别的解决方案了；通过调研，分布式文件系统是一个比较合适的选择。采用分布式文件系统后，服务器之间的数据访问不再是一对多的关系（1个NFS服务器，多个NFS 客户端），而是多对多的关系，这样一来，性能大幅提升毫无问题。 到目前为止，有数十种以上的分布式文件系统解决方案可供选择，如 lustre,hadoop,Pnfs等等。我尝试了 PVFS,hadoop,moosefs这三种应用，参看了lustre、KFS等诸多技术实施方法，最后我选择了moosefs（以下简称MFS）
这种分布式文件系统来作为我的共享存储服务器。为什么要选它呢？我来说说我的一些看法： 1、实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容易得多。看看lustre 700多页的pdf文档，让人头昏吧。 2、不停服务扩容。MFS框架做好后，随时增加服务器扩充容量；扩充和减少容量皆不会影响现有的服务。注：hadoop也实现了这个功能。 3、恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，原因参照第1条。 4、我在实验过程中得到作者的帮助，这让我很是感激。 MFS文件系统的组成 1、元数据服务器。在整个体系中负责管理管理文件系统，目前MFS只支持一个元数据服务器master，这是一个单点故障，需要一个性能稳定的服务器来充当。希望今后MFS能支持多个master服务器，进一步提高系统的可靠性。 2、数据存储服务器chunkserver。真正存储用户数据的服务器。存储文件时，首先把文件分成块，然后这些块在数据服务器chunkserver之间复制（复制份数可以手工指定，建议设置副本数为3）。数据服务器可以是多个，并且数量越多，可使用的“磁盘空间”越大，可靠性也越高。 3、客户端。使用MFS文件系统来存储和访问的主机称为MFS的客户端，成功挂接MFS文件系统以后，就可以像以前使用NFS一样共享这个虚拟性的存储了。 元数据服务器安装和配置
Hadoop分布式文件系统方案
Hadoop分布式文件系统：架构和设计要点 Hadoop分布式文件系统：架构和设计要点 原文：https://www.wendangku.net/doc/586809926.html,/core/docs/current/hdfs_design.html 一、前提和设计目标 1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。 2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。 4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。 5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。 6、在异构的软硬件平台间的可移植性。 二、Namenode和Datanode HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode 组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。Namenode和Datanode 都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部署在很大围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。
典型分布式文件系统概述
分布式文件系统概述（一） 杨栋 yangdonglee@https://www.wendangku.net/doc/586809926.html, 2006-12 摘要 文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。 1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.wendangku.net/doc/586809926.html,，我会尽全力完善，或者请各位同学自行修正。笔者目前在百度进行云计算方面的研究和开发，希望有兴趣的同学一起进行探讨。
目录 1．引言 (5) 2．本地文件系统 (5) 2.1FFS (6) 2.2LFS (6) 2.3Ext3 (7) 3．分布式文件系统 (7) 3.1 发展历程 (7) 3.2分布式文件系统分类 (8) 3.2.1 实现方法 (8) 3.2.2研究状况 (8) 3.3 NFS (9) 3.3.1概述 (9) 3.3.2 体系结构 (9) 3.3.3 通信机制 (10) 3.3.4进程 (10) 3.3.5 命名 (10) 3.3.6 同步机制 (11) 3.3.7 缓存和复制 (11) 3.3.8 容错性 (12) 3.3.9 安全性 (13) 3.4 AFS、DFS、Coda和InterMezzo (13) 3.5 SpriteFS和Zebra (14) 3.6xFS (16) 3.6.1 概述 (16) 3.6.2 体系结构 (16) 3.6.3 通信 (16) 3.6.4 进程 (17) 3.6.5 命名 (18) 3.6.6 缓存 (19)
7种分布式文件系统介绍
FastDFS (7) Fastdfs简介 (7) Fastdfs系统结构图 (7) FastDFS和mogileFS的对比 (8) MogileFS (10) Mogilefs简介 (10) Mogilefs组成部分 (10) 0）数据库（MySQL）部分 (10) 1）存储节点 (11) 2）trackers（跟踪器） (11) 3）工具 (11) 4）Client (11) Mogilefs的特点 (12) 1. 应用层——没有特殊的组件要求 (12) 2. 无单点失败 (12) 3. 自动的文件复制 (12) 4. “比RAID好多了” (12) 5. 传输中立，无特殊协议 (13) 6.简单的命名空间 (13) 7.不用共享任何东西 (13) 8.不需要RAID (13)
9.不会碰到文件系统本身的不可知情况 (13) HDFS (14) HDFS简介 (14) 特点和目标 (14) 1. 硬件故障 (14) 2. 流式的数据访问 (14) 3. 简单一致性模型 (15) 4. 通信协议 (15) 基本概念 (15) 1. 数据块(block) (15) 2. 元数据节点(Namenode)和数据节点(datanode) . 16 2.1这些结点的用途 (16) 2.2元数据节点文件夹结构 (17) 2.3文件系统命名空间映像文件及修改日志 (18) 2.4从元数据节点的目录结构 (21) 2.5数据节点的目录结构 (21) 文件读写 (22) 1.读取文件 (22) 1.1 读取文件示意图 (22) 1.2 文件读取的过程 (23) 2.写入文件 (24) 2.1 写入文件示意图 (24)
常见的分布式文件系统
常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。做个中文版下载源：https://www.wendangku.net/doc/586809926.html,/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： https://www.wendangku.net/doc/586809926.html,/papers/gfs.html https://www.wendangku.net/doc/586809926.html,/papers/bigtable.html https://www.wendangku.net/doc/586809926.html,/papers/mapreduce.html GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类 GFS的产品。
大数据技术与应用 - 大数据存储和管理 - 分布式文件系统 - 第二课
大数据技术与应用 网络与交换技术国家重点实验室 交换与智能控制研究中心 程祥 2016年9月
提纲-大数据存储和管理1. 分布式文件系统 1.1 概述 1.2 典型分布式文件系统 1.3 HDFS 2. 分布式数据库 2.1 概述 2.2 NoSQL 2.3 HBase 2.4 MongoDB（略） 2.5 云数据库（略）
1.1 概述 ?定义：相对于本地文件系统，分布式文件系统是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。 ?分布式文件系统一般采用C/S模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求。 ?客户端和服务器可以通过设置访问权限来限制请求方对底层数据存储块的访问。
1.2 典型的分布式文件系统 ?NFS (Network File System) 由Sun微系统公司作为TCP/IP网上的文件共享系统开发，后移植到Linux等其他平台。其接口都已经标准化。 ?AFS (Andrew File System) 由卡耐基梅隆大学信息技术中心(ITC)开发，主要用于管理分部在不同网络节点上的文件。AFS与 NFS不同，AFS提供给用户的是一个完全透明，永远唯一的逻辑路径（NFS需要物理路径访问）。
1.2 典型的分布式文件系统（续） ?GFS（Google File System） 由Google开发，是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。 ?HDFS（Hadoop Distributed File System） HDFS是Apache Hadoop项目的一个子项目，是一个高度容错的分布式文件系统，设计用于在低成本硬件上运行，适合存储大数据，GFS的开源版本。
分布式文件系统、集群文件系统、并行文件系统
分布式文件系统、集群文件系统、并行文件系统，这三种概念很容易混淆，实际中大家也经常不加区分地使用。总是有人问起这三者的区别和联系，其实它们之间在概念上的确有交叉重叠的地方，但是也存在显著不同之处。分布式文件系统自然地，分布式是重点，它是相对与本地文件系统而言的。分布式文件系统通常指C/S架构或网络文件系统，用户数据没有直接连接到本地主机，而是存储在远程存储服务器上。NFS/CIFS是最为常见的分布式文件系统，这就是我们说的NAS系统。分布式文件系统中，存储服务器的节点数可能是1个(如传统NAS)，也可以有多个(如集群NAS)。对于单个节点的分布式文件系统来说，存在单点故障和性能瓶颈问题。除了NAS以外，典型的分布式文件系统还有AFS，以及下面将要介绍的集群文件系统(如Lustre, GlusterFS, PVFS2等)。集群文件系统集群主要分为高性能集群HPC(High Performance Cluster)、高可用集群HAC(High Availablity Cluster)和负载均衡集群LBC(Load Balancing Cluster)。集群文件系统是指协同多个节点提供高性能、高可用或负载均衡的文件系统，它是分布式文件系统的一个子集，消除了单点故障和性能瓶问题。对于客户端来说集群是透明的，它看到是一个单一的全局命名空间，用户文件访问请求被分散到所有集群上进行处理。此外，可扩展性(包括Scale-Up和Scale-Out)、可靠性、易管理等也是集群文件系统追求的目标。在元数据管理方面，可以采用专用的服务器，也可以采用服务器集群，或者采用完全对等分布的无专用元数据服务器架构。目前典型的集群文件系统有SONAS, ISILON, IBRIX, NetAPP-GX, Lustre, PVFS2, GlusterFS, Google File System, LoongStore, CZSS等。并行文件系统这种文件系统能够支持并行应用，比如MPI。在并行文件系统环境下，所有客户端可以在同一时间并发读写同一个文件。并发读，大部分文件系统都能够实现。并发写实现起来要复杂许多，既要保证数据一致性，又要最大限度提高并行性，因此在锁机制方面需要特别设计，如细粒度的字节锁。通常SAN 共享文件系统都是并行文件系统，如GPFS、StorNext、GFS、BWFS，集群文件系统大多也是并行文件系统，如Lustre, Panasas等。如何区分？区分这三者的重点是分布式、集群、并行三个前缀关键字。简单来说，非本地直连的、通过网络连接的，这种为分布式文件系统；分布式文件系统中，服务器节点由多个组成的，这种为集群文件系统；支持并行应用(如MPI)的，这种为并行文件系统。在上面所举的例子中也可以看出，这三个概念之间具有重叠之处，比如Lustre，它既是分布式文件系统，也是集群和并行文件系统。但是，它们也有不同之处。集群文件系统是分布式文件系统，但反之则不成立，比如NAS、AFS。SAN文件系统是并行文件系统，但可能不是集群文件系统，如StorNext。GFS、HDFS之类，它们是集群文件系统，但可能不是并行文件系统。实际中，三者概念搞理清后，分析清楚文件系统的特征，应该还是容易正确地为其划分类别的。
分布式存储相对集中式存储优势
明确要求采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN的原因：从软件定义存储概念提出到现在，分布式架构存储系统正成为业界存储主流和发展方向，逐渐取代传统集中式存储系统，随着云计算和大数据的建设成为数据中心建设主流形态，互联网+、人工智能、物联网应用等的普及，以非结构化数据为主的海量数据爆发式增长，如视音频存储、图像存储及识别、流媒体处理等，基于海量数据存储、分析、挖掘等，传统集中式存储无论从架构、扩展性、性能及成本，运维管理优势等方面，都无法满足业务增长及数据处理所带来的存储问题。 首先从架构上，集中式存储FC SAN/IP SAN 采用Scale up的扩展方式，通过存储控制器挂接扩展柜的方式，实现存储容量的扩展，扩展能力有限，并且性能随着容量扩展并非线性关系，可能存储前端及后端端口带宽会成为海量数据并发处理的瓶颈，并且存储资源分布不均，无法做到资源动态均衡伸缩及调度，这对于响应级别要求不一致的应用来说是致命的；分布式架构存储系统，采用Scale out 横向扩展方式，无节点扩展限制，存储容量可轻易扩展至几十甚至几百PB以上，这是集中式存储无法做到的，能够很好解决在云计算架构下海量数据存储及并发问题。并且基于分布式软件的分布式调度算法，可实现资源动态伸缩，随着节点增加，其性能是线性增加，能够很好满足如云计算架构下海量数据存储及处理对存储资源池可动态伸缩及并发访问性能要求。 由于采用软件定义存储方式，无论是成本还是后期运维管理，比传统集中式存储FC SAN/ IP SAN优势明显，分布式软件自动实现对存储资源调度及管理，实现跨数据中心资源分配。集中式存储系统，需要借助存储虚拟化技术（虚拟化网关）才能将存储资源聚合为统一存储资源池，随着规模扩大，网关往往更易成为性能瓶颈。 关于数据安全性问题，分布式架构存储系统基于机架自动感知的数据多副本技术，例如采用三副本技术，即使数据中心同一机架故障，对业务透明无感知，数据安全级别高，业务连续性更好。集中式存储往往采用双活架构实现容灾，不仅初期投入成本高，运维部署复杂。 从应用角度来看，现在越来越多的应用迁到分布式存储系统上，例如海量视频、音频、图像、文档的存储，流媒体及视频图像处理所带来的高并发低延迟，高性能计算应用等，都非常适合分布式架构存储系统，而不采用集中式存储系统，并且从数据存储及性能要求、容量扩展方便，集中式存储做起来非常困难。 诸如以上原因，明确要求采用采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN。