- 中文名
- 分布式文件系统
- 外文名
- Distributed File System
- 类 别
- 文件系统 [2]
- 有关术语
- 拓扑分布式文件系统 [1]
- 逻辑结构
- 树形文件系统结构 [1]
- 特 点
- 共享 [2]
计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍的增长，单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数据安全等方面的表现都差强人意。分布式文件系统可以有效解决数据的存储和管理难题：将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布式文件系统是建立在客户机/服务器技术基础之上的，一个或多个文件服务器与客户机文件系统协同操作，这样客户机就能够访问由服务器管理的文件。 [2]分布式文件系统的发展大体上经历子三个阶段：第一阶段是网络文件系统，第二阶段是共享SAN文件系统，第三阶段是面向对象的并行文件系统 [3]。
分布式文件系统把大量数据分散到不同的节点上存储，大大减小了数据丢失的风险。分布式文件系统具有冗余性，部分节点的故障并不影响整体的正常运行，而且即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来。因此，安全性是分布式文件系统最主要的特征。分布式文件系统通过网络将大量零散的计算机连接在一起，形成一个巨大的计算机集群，使各主机均可以充分发挥其价值。此外，集群之外的计算机只需要经过简单的配置就可以加入到分布式文件系统中，具有极强的可扩展能力。 [3]
飞客数据恢复中心提供AFS是一种分布式的文件系统用来共享与获得在计算机网络中存放的文件。AFS使得用户获得网络文件就像本地机器般方便。AFS文件系统被称为“分布式”是因为文件可以分散地存放在很多不同的机器上，但这些文件对于用户而言是可及的，用户可以通过一定的方式得到这些文件 [5]。
KASS File System（简称KFS）是开始软件自主研发基于JAVA的纯分布式文件系统，功能类似于DFS、GFS、Hadoop，通过HTTP WEB为企业的各种信息系统提供底层文件存储及访问服务，搭建企业私有云存储服务平台 [6]。
只读共享 任何客户机只能访问文件，而不能修改它，这实现起来很简单。 [7]
受控写操作 采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。 [7]
并发写操作 这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受 [7]。
NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步 [8]：
无状态系统：在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统 [8]。
回呼(Callback)系统：在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变 [8]。
无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回叫应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了 [8]。
网络文件系统（Network File System，NFS）是个分布式的客户机/服务器文件系统。NFS的实质在于用户间计算机的共享。用户可以联结到共享计算机并像访问本地硬盘一样访问共享计算机上的文件。管理员可以建立远程系统上文件的访问，以至于用户感觉不到他们是在访问远程文件。NFS是个到处可用和广泛实现的开放式系统。 [4]
简化应用程序对远程文件的访问使得不需要因访问这些文件而调用特殊的过程 [4]。
使用一次一个服务请求以使系统能从已崩溃的服务器或工作站上恢复。 [4]
采用安全措施保护文件免遭偷窃与破坏。 [4]
使NFS协议可移植和简单，以便它们能在许多不同计算机上实现，包括低档的PC机 [4]。
大型计算机、小型计算机和文件服务器运行NFS时，都为多个用户提供了一个文件存储区。工作站只需要运行TCP/IP协议来访问这些系统和位于NFS存储区内的文件。工作站上的NFS通常由TCP/IP软件支持。对DOS用户，一个远程NFS文件存储区看起来是另一个磁盘驱动器盘符。对Macintosh用户，远程NFS文件存储区就是一个图标 [4]。
服务器目录共享 服务器广播或通知正在共享的目录，一个共享目录通常叫做出版或出口目录。有关共享目录和谁可访问它们的信息放在一个文件中，由操作系统启动时读取。 [4]
客户机访问 在共享目录上建立一种链接和访问文件的过程叫做装联(mounting)，用户将网络用作一条通信链路来访问远程文件系统。 [4]
AFS是专门为在大型分布式环境中提供可靠的文件服务而设计的。它通过基于单元的结构生成一种可管理的分布式环境。一个单元是某个独立区域中文件服务器和客户机系统的集合，这个独立区域由特定的机构管理。通常代表一个组织的计算资源。用户可以和同一单元中其他用户方便地共享信息，他们也可以和其他单元内的用户共享信息，这取决于那些单元中的机构所授予的访问权限 [5]。
基本监察(BOS)服务器进程 这个进程运行于有BOS设定的服务器。它监控和管理运行其他服务的进程并可自动重启服务器进程，而不需人工帮助 [5]。
鉴别服务器进程 此进程通过授权和相互鉴别提供网络安全性。用一个“鉴别服务器”维护一个存有口令和加密密钥的鉴别数据库，此系统是基于Kerberos的 [5]。
保护服务器进程 此进程基于一个保护数据库中的访问信息，使用户和组获得对文件服务的访问权 [5]。
更新服务器进程 此进程将AFS的更新和任何配置文件传播到所有AFS服务器 [5]。
AFS还配有一套用于差错处理，系统备份和AFS分布式文件系统管理的实用工具程序。例如，SCOUT定期探查和收集AFS文件服务器的信息。信息在给定格式的屏幕上提供给管理员。设置多种阈值向管理者报告一些将发生的问题，如磁盘空间将用完等。另一个工具是USS，可创建基于带有字段常量模板的用户帐户。Ubik提供数据库复制和同步服务。一个复制的数据库是一个其信息放于多个位置的系统以便于本地用户更方便地访问这些数据信息。同步机制保证所有数据库的信息是一致的 [5]。
一个 KFS 集群包括单个元数据服务器节点和多个Chunk 服务器节点，并由多个客户端来访问。其中元数据服务器主要用于维护元数据并负责控制垃圾回收、负载均衡等系统活动，Chunk 服务器负责保存数据以及接收处理数据I/O 请求。这两类节点均运行 Linux 操作系统，需要分别安装、运行 KFS 提供的元数据服务器和 Chunk 服务器软件。客户端需要安装专门的 KFS 客户端库，由应用程序链接使用来访问 KFS 文件系统。KFS 的所有节点都均采用 X86 架构硬件，并通过以太网方式连接在一起，节点之间采用 TCP协议通讯，使得整个系统具有较高的性价比。 [6]
Chunk 服务器
在KFS中，一个文件被分割成多个Chunk，每个Chunk大小固定为 64MB，所以可以通过简单的模运算计算出某文件偏移量在该文件第几个Chunk 的多少偏移量上。每个Chunk 由一个全局唯一的 Chunk 号来标识。Chunk 服务器主要的功能就是保存 Chunk，并对外提供创建、删除、读写Chunk 的访问接口。一个 Chunk 默认被复制成3份，保存在3个不同的 Chunk 服务器中，客户端可以为每个文件指定不同的副本个数。三副本就保证了在两个 Chunk 服务器故障的情况下，仍能从第三个 Chunk 服务器上的副本读出数据，提高了系统的可靠性。在 Chunk 数据写入时，若某个 Chunk 服务器突然故障，会导致的相应副本更新失败，进而影响 Chunk 各副本数据的一致性。为了解决这个问题，KFS为每个 Chunk 副本分配一个版本号，副本每被更新一次则版本号上升，这样就可以通过比较版本号来发现过期的副本。Chunk 服务器中，单个 Chunk 由一个文件来表示，这些Chunk 文件被保存在本地的文件系统中，文件系统可以是XFS、Ext3/4 等。每个 Chunk 文件除了保存数据外，其头部还保存了 16KB 大小的校验和信息：写数据时，为每个64K数据块计算一个32 位校验和（Adler-32 算法），保存至 Chunk文件头部；读数据时，首先验证读出数据的校验和，这就保证了本地磁盘保存数据时可能发生的数据损坏可以被检查出来。 [6]
Chunk 文件在本地文件系统的文件名命名规则为：文件号.Chunk 号.版本号。Chunk 服务器启动时通过扫描存放Chunk 文件的目录，就可获知自己拥有哪些 Chunk，然后把该信息提交给元数据服务器。元数据服务器在验证 Chunk信息后，会告知 Chunk 服务器哪些 Chunk 已经过期（版本号过期或属于已被删除的文件），Chunk 服务器便可以删除这些 Chunk。 [6]
在 KFS 中，一个文件系统的所有元数据由单个元数据服务器统一管理，这一做法虽然影响了系统的可扩展性，但极大简化了系统的设计。元数据包括了 [6]：
（1） 目录项信息：KFS 采用传统的目录结构命名空间，目录树中的所有节点（文件和目录），均由一个全局唯一的文件号来标识，根目录的文件号固定为 2，目录项信息指的是目录树中各目录所包含的各目录项（可以是子目录或文件）的名称及文件 ID [6]；
（2） 属性信息：各目录、文件的创建、修改时间，及文件的副本数、大小 [6]；
（3） Chunk 信息：一个文件依次由哪些 Chunk 组成的； [6]
（4） 位置信息：Chunk 的各个副本的被保存在哪个Chunk服务器上； [6]
（5） 租约信息：KFS 采用租约来维持多个客户端情况下数据的一致性，这些租约信息由元数据服务器统一管理 [6]。
客户端
KFS 的客户端库向应用程序开发者提供了 create、read、write、mkdir、rmdir 等类似 POSIX 语义的编程接口，支持的编程语言有 C++、Python、Java。客户端库通过与元数据服务器及 Chunk 服务器交互，完成对文件系统中文件的修改、访问等操作。此外，客户端还支持 FUSE（File system in Userspace），使得传统文件系统工具（如 ls 命令）也可以访问 KFS 文件系统，提高了系统的互操作性。 [6]
为了减少与元数据服务器的交互次数，客户端会缓存元数据信息。此外，KFS 的客户端还会对读取、写入的数据进行缓存，这就存在缓存一致性的问题，KFS 采用读写租约（Lease）解决了这个问题，所有的租约由元数据服务器统一管理，每个租约有 300 秒的时限，过期作废。读写租约的具体方式是： [6]
（1） 写租约：当需要向 Chunk 写入数据时，对应的主Chunk 服务器首先查看是否拥有该 Chunk 的写租约，如果没有或已过期则尝试向元数据服务器获取或更新写租约，如果该 Chunk 正在被复制到其他 Chunk 服务器或者已经分配写租约或读租约，则返回失败，否则返回成功并且 Chunk 的版本号增一； [6]
（2） 读租约：在客户端需要读取某个Chunk的数据时，它首先尝试去获取这个 Chunk 的读租约，如果该 Chunk 没有分配写租约而且数据已全部写入磁盘，则返回成功，否则返回失败。读写租约保证了一个 Chunk 同时只能由一个客户端写入，而且一个或多个客户端在读取某 Chunk 数据时，该Chunk 数据不会被修改，这样客户端就能够把读取的数据缓存在本地，因为缓存中的数据与 Chunk 服务器上保存的数据一定是一致的。 [6]
在分布式系统中通常有数量巨大的服务器节点，由于客户端在访问服务器节点的时候具有随机性，这就必然会导致部分主机在某些时刻成为热点，对整个分布式系统的性能产生了制约。与此同时，部分服务器节点的负载却远远没有达到额定值，从而造成资源浪费。显然，在分布式文件系统中进行负载均衡控制是十分必要的。在软件工程中，网站访问流量的分配、数据库访问的重定向等都是负载均衡应用的典型场景。通过负载均衡技术的应用，可以实现分布式系统中所有节点的负载相对平衡，既保证了系统的性能，又充分利用了资源。负载均衡意味着节点之间需要进行数据迁移，因此负载均衡本身需要有一定的开销，所以通常要求负载均衡算法具有较高的效率 [3]。
分布式文件系统是以数据服务器为核心的存储系统，根据数据服务器在形式上是否具有中心节点，一般将其分为集中式和非集中式两大类拓扑结构，其中前者是以某台服务器作为中心节点进行分布式组网，而后者则不需要中心节点服务器。之所以要这样区分，是因为中心节点的存在与否，对负载均衡策略的制定有重要影响。 [3]
对于集中式的分布式文件系统，其中心节点就是对数据分发起到主要控制作用的节点，又称为主控节点。在现有的分布式文件存储系统中，GFS和HDFS就是最典型的有中心节点分布式文件系统，下面以HDFS为例进行分析。HDFS采用了机架分配机制实现分布式存储和负载的平衡，其主要实现思路如下 [3]：
（1）用户向集群提交数据块，系统在接收到数据后，按照预告设定的副本参数（默认为3）复制出若干副本； [3]
（2）按照定义好的机架分配策略，把刚才生成的各个副本逐一分发到集群中 [3]；
（3）对于默认3个副本的情况，按照机架分配规则，其中两个需要放置于同一个机架上，但这两个副本分别处于该机架的不同节点上，另外一个副本则要求单独置于另一个机架上 [3]；
（4）启动一个定时任务，通过Name Node节点定时扫描所有节点，统计出整体负载分布情况 [3]；
（5）将集群当前负载状态与预设的阈值进行对比，并根据对比的结果对各节点的负载情况进行调整，从而实现负载均衡 [3]。
不难看出，这种负载均衡策略不仅可以保证数据的安全，还保证了数据的可用性，在系统的可靠性和读写性能上也有很大的优势。通过该策略，可以实现各节点的负载动态平衡。但这种策略也并非十全十美，在整个集群进行大规模横向扩展时，将对Name Node节点的性能提出巨大的挑战，因此对于后期需要大规模扩展的系统而言是有一定的局限性的。 [3]
与集中式的分布式文件系统不同，非集中式的分布式文件系统不存在一个用于分配数据的主控节点，集群中的每个节点都是相互平行的。P2P网络就是一种典型的无中心节点分布式文件系统，因此又被称为对等网络。网络中的任意一个节点都具有同等的作用，可以向其它节点发起连接。其负载均衡策略如下 [3]：
（1） 用户向集群提交数据块，系统在接收到数据后，采用分布式哈希表（DHT）来决定这些数据会被保存到哪个节点。根据哈希算法的特征，数据在分发后实际上就已经实现了初步的负载平衡； [3]
（2）然而，随着系 统运行时间的不断增加，各节点的负载会慢慢失衡，导致负载向某些节点集中，从而出现高负载节点和低负载节点。每个节点都会定时计算自己的负载状态，如果发现自己是低负载节点，则开始对网络中的所有节点进行扫描； [3]
（3）如果发现某节点是高负载节点，则立即停止通信遍历，启动数据迁移，部分数据由高负载节点转移到低负载节点，实现两个节点之间的负载均衡 [3]；
（4）为了避免节点扫描和数据重复迁移带来的额外开销，也可以在多个节点中进行数据迁移。首先由高负载节点对其它节点进行遍历，如果某节点是低负载节点，就把它放到一个队列中 [3]；
（5）当队列数量达到一定数量，或者所有节点已经遍历完成时，对队列中的节点按照负载的高低进行排序 [3]；
（6）取出负载最低的节点，对其进行数据迁移，完成一轮负载平衡，如此反复进行，实现集群的动态负载平衡。Napster是最早的P2P系统之一，但它有一个索引服务器，本质上还不是真正的P2P系统，不适合大型网络应用。基于Gnutella的网络抛弃了索引服务器，实现了所有机器的对等关系，但又带来了较大的带宽消耗 [3]。Tapestry，Pastry，Chord和CAN等基于DHT的网络的出现，系统的可扩展性和精确发现性。为了改善DHT系统在维护机制上的复杂性，当前广泛采用KaZaa等P2P文件共享系统，软件，通过超级结点的引入，解决了传统分布式网络的诸多问题 [3]。
DFS拓扑（DFS topology）：一个分布式文件系统的整体逻辑层次，包括DFS管理控制台及其中的元素，如根目录共享和副本集。 [1]
DFS根（DFS root）：在DFS拓扑的最顶层共享，它是组成整个的DFS共享文件的开始点。DFS根能为基于域的操作系统在域一级定义。基于域的DFS可在域中有多个根，但在一个服务器上只能有一个根 [1]。
根副本（root replica）：服务器复制一个DFS根，以提供更好的有效性。保存DFS根的服务器承担为共享文件夹向客户分发引用的任务。如果服务器不可用，并且创建有根副本，则可以通过根副本所在服务器访问DFS空间。 [1]
DFS链接（DF Slink）：DFS拓扑的一部分，是组成DFS空间的具体的内容。它形成一个到一个或者一个到多个共享目录的连接。它通过把一个DNS名映射到目标共享文件夹的标准UNC来实现。 [1]
复制策略（replication policy）：域DFS的链接建立后，就可以为其创建副本。为了使原文件和副本之间保持同步，需要配置复制策略。基于域的DFS根目录或者子目录都支持复制。一个独立的DFS不支持复制 [1]。
