分布式文件系统研究
由于工作性质的关系，我觉得自己很有必要对当今主流的分布式文件系统（Distributed File System，DFS）做系统的研究，总结优缺点，为下一步的工作提供必要的参考。因此，我动手搜集了不少资料，并进行了很初步的学习，以后我会把自己对DFS的学习心得整理起来，陆续放到博客上来。这就当是开篇吧，嘿嘿
概述
文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。
根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的本地文件系统，如Unix的本地文件系统；多处理器多用户的分布式文件系统，如Lustre文件系统。
本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。
由于互联网应用的不断发展，本地文件系统由于单个节点本身的局限性，已经很难满足海量数据存取的需要了，因而不得不借助分布式文件系统，把系统负载转移到多个节点上。
传统的分布式文件系统（如NFS）中，所有数据和元数据存放在一起，通过单一的存储服务器提供。这种模式一般称之为带内模式（In-band Mode）。随着客户端数目的增加，服务器就成了整个系统的瓶颈。因为系统所有的数据传输和元数据处理都要通过服务
器，不仅单个服务器的处理能力有限，存储能力受到磁盘容量的限制，吞吐能力也受到磁盘I/O和网络I/O的限制。在当今对数据吞吐量要求越来越大的互联网应用中，传统的分布式文件系统已经很难满足应用的需要。
于是，一种新的分布式文件系统的结构出现了，那就是利用存储区域网络（SAN）技术，将应用服务器直接和存储设备相连接，大大提高数据的传输能力，减少数据传输的延时。在这样的结构里，所有的应用服务器都可以直接访问存储在SAN中的数据，而只有关于文件信息的元数据才经过元数据服务器处理提供，减少了数据传输的中间环节，提高了传输效率，减轻了元数据服务器的负载。每个元数据服务器可以向更多的应用服务器提供文件系统元数据服务。这种模式一般称之为带外模式（Out-of-band Mode）。最近的Storage Tank、CXFS、Lustre、BWFS等都采用这样的结构，因此它们可以取得更好的性能和扩展性。区分带内模式和带外模式的主要依据是，关于文件系统元数据操作的控制信息是否和文件数据一起都通过服务器转发传送。前者需要服务器转发，后者是直接访问。
分布式文件系统的历史
随着计算机应用范围的扩展，通过文件访问接口在不同主机之间共享文件的需求日益增强。下面分为几个阶段介绍分布式文件系统的发展过程。
最初的分布式文件系统应用发生在20世纪70年代，之后逐渐扩展到各个领域。从早期的NFS到现在的StorageT ank，分布式文件系统在体系结构、系统规模、性能、可扩展性、可用性等方面经历了巨大的变化。
第一代分布式文件系统（1980年代）
早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的
性能和数据的可靠性，以NFS和AFS(Andrew File System)最具代表性，它们对以后的文件系统设计也具有十分重要的影响。
NFS从1985年出现至今，已经经历了四个版本的更新，被移植到了几乎所有主流的操作系统中，成为分布式文件系统事实上的标准。NFS利用Unix系统中的虚拟文件系统（Virtual File System，VFS）机制，将客户机对文件系统的请求，通过规范的文件访问协议和远程过程调用，转发到服务器端进行处理；服务器端在VFS之上，通过本地文件系统完成文件的处理，实现了全局的分布式文件系统。Sun公司公开了NFS的实施规范，互联网工程任务组（The Internet Engineering T ask Force，IETF）将其列为征求意见稿（RFC-Request for Comments），这很大程度上促使NFS的很多设计实现方法成为标准，也促进了NFS的流行。NFS不断发展，在第四版中提供了基于租赁（Lease）的同步锁和基于会话（Session）语义的一致性等。
Carnegie Mellon大学在1983年设计开发的AFS将分布式文件系统的可扩展性放在了设计和实现的首要位置，并且着重考虑了在不安全的网络中实现安全访问的需求。因此，它在位置透明、用户迁移、与已有系统的兼容性等方面进行了特别设计。AFS具有很好的扩展性，能够很容易地支持数百个节点，甚至数千个节点的分布式环境。同时，在大规模的分布式文件系统中，AFS利用本地存储作为分布式文件的缓存，在远程文件无法访问时，依然可以部分工作，提高了系统可用性。后来的Coda File System、Inter-mezzo File System 都受到AFS的影响，更加注重文件系统的高可用性（High Availability）和安全性，特别是Coda，在支持移动计算方面做了很多的研究工作。
早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，在受网络环境、本地磁盘、处理器速度等方面限制的情况下，更多地关注访问的性能和数据的可靠性。AFS 在系统结构方面进行了有意义的探索。它们所采用的协议和相关技术，为后来的分布式文件
系统设计提供了很多借鉴。
第二代分布式文件系统（1990～1995）
20世纪90年代初，面对广域网和大容量存储应用的需求，借鉴当时先进的高性能对称多处理器的设计思想，加利福尼亚大学设计开发的xFS，克服了以前的分布式文件系统一般都运行在局域网（LAN）上的弱点，很好地解决了在广域网上进行缓存，以减少网络流量的难题。它所采用的多层次结构很好地利用了文件系统的局部访问的特性，无效写回（Invalidation-based Write Back）缓存一致性协议，减少了网络负载。对本地主机和本地存储空间的有效利用，使它具有较好的性能。
Tiger Shark并行文件系统是针对大规模实时多媒体应用设计的。它采用了多种技术策略保证多媒体传输的实时性和稳定性：采用资源预留和优化的调度手段，保证数据实时访问性能；通过加大文件系统数据块的大小，最大限度地发挥磁盘的传输效率；通过将大文件分片存储在多个存储设备中，取得尽量大的并行吞吐率；通过复制文件系统元数据和文件数据，克服单点故障，提高系统可用性。
基于虚拟共享磁盘Petal的Frangipani分布式文件系统，采用了一种新颖的系统结构—分层次的存储系统。Petal提供一个可以全局统一访问的磁盘空间。Frangipani基于Petal 的特性提供文件系统的服务。这种分层结构使两者的设计实现都得到了简化。在Frangipani 中，每个客户端也是文件系统服务器，参与文件系统的管理，可以平等地访问Petal提供的虚拟磁盘系统，并通过分布式锁实现同步访问控制。分层结构使系统具有很好的扩展性，可以在线动态地添加存储设备，增加新用户、备份等，同时系统具有很好的机制来处理节点失效、网络失效等故障，提高了系统的可用性。
Slice File System（SFS）考虑标准的NFS在容量、性能方面存在的限制，采用在客
户机和服务器之间架设一个μproxy中间转发器，以提高性能和可扩展性。它将客户端的访问分为小文件、元数据服务、大文件数据三类请求。通过μproxy将前两种请求转发到不同的文件服务器上，将后者直接发送到存储服务器上。这样SFS系统就可以支持多个存储服务器，提高整个系统的容量和性能。μproxy根据请求内容的转发是静态的，对于整个系统中负载的变化难以做出及时反应。
第三代分布式文件系统（1995～2000）
网络技术的发展和普及应用极大地推动了网络存储技术的发展，基于光纤通道的SAN、NAS得到了广泛应用。这也推动了分布式文件系统的研究。在这个阶段，计算机技术和网络技术有了突飞猛进的发展，单位存储的成本大幅降低。而数据总线带宽、磁盘速度的增长无法满足应用对数据带宽的需求，存储子系统成为计算机系统发展的瓶颈。这个阶段，出现了多种体系结构，充分利用了网络技术。
出现了多种分布式文件系统体系结构，如Global File System（GFS）、General Parallel File System （GPFS）、惠普的DiFFS、SGI公司的CXFS、EMC的HighRoa d、Sun的qFS、XNFS等。数据容量、性能和共享的需求使得这一时期的分布式文件系统管理的系统规模更大、系统更复杂，对物理设备的直接访问、磁盘布局和检索效率的优化、元数据的集中管理等都反映了对性能和容量的追求。规模的扩展使得系统的动态性，如在线增减设备、缓存的一致性、系统可靠性的需求逐渐增强，更多的先进技术应用到系统实现中，如分布式锁、缓存管理技术、SoftUpdates技术、文件级的负载平衡等。
第四代分布式文件系统（2000年以后）
随着SAN和NAS两种结构逐渐成熟，研究人员开始考虑如何将两种结构结合起来。
网格的研究成果等也推动了分布式文件系统体系结构的发展。
随着SAN和NAS两种体系结构逐渐成熟，研究人员开始考虑如何将两种体系结构结合起来，以充分利用两者的优势。另一方面，基于多种分布式文件系统的研究成果，人们对体系结构的认识不断深入，网格的研究成果等也推动了分布式文件系统体系结构的发展。这一时期，IBM的StorageTank、Cluster的Lustre、Panasas的PanFS、蓝鲸文件系统（BWFS）等是这种体系结构的代表。各种应用对存储系统提出了更多的需求：?大容量：现在的数据量比以前任何时期更多，生成的速度更快；
?高性能：数据访问需要更高的带宽；
?高可用性：不仅要保证数据的高可用性，还要保证服务的高可用性；
?可扩展性：应用在不断变化，系统规模也在不断变化，这就要求系统提供很好的扩展性，并在容量、性能、管理等方面都能适应应用的变化；
?可管理性：随着数据量的飞速增长，存储的规模越来越庞大，存储系统本身也越来越复杂，这给系统的管理、运行带来了很高的维护成本；
?按需服务：能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等。
处于这个阶段的系统都在研究中，但从中也可以看出一些发展趋势：体系结构的研究逐渐成熟，表现在不同文件系统的体系结构趋于一致；系统设计的策略基本一致，如采用专用服务器方式等；每个系统在设计的细节上各自采用了很多特有的先进技术，也都取得了很好的性能和扩展性。另外，在协议方面的探索也是研究的热点之一，如Direct Access File System利用了远程内存直接访问的特性，借鉴了NFS第四版本和Common Internet File System等协议，设计了一套新的网络文件访问协议。
NFS文件系统
研究分布式文件系统，不得不提NFS文件系统，NFS已经成为分布式文件系统事实上的标准。
历史：
NFS从1985年出现至今，已经经历了四个版本的更新，被移植到了几乎所有主流的操作系统中，成为分布式文件系统事实上的标准。NFS利用Unix系统中的虚拟文件系统（Virtual File System，VFS）机制，将客户机对文件系统的请求，通过规范的文件访问协议和远程过程调用，转发到服务器端进行处理；服务器端在VFS之上，通过本地文件系统完成文件的处理，实现了全局的分布式文件系统。Sun公司公开了NFS的实施规范，互联网工程任务组（The Internet Engineering Task Force，IETF）将其列为征求意见稿（RFC-Request for Comments），这很大程度上促使NFS的很多设计实现方法成为标准，也促进了NFS的流行。
架构：
NFS是个分布式的C/S文件系统。NFS的实质在于用户间计算机的共享。用户可以联结到共享计算机并象访问本地硬盘一样访问共享计算机上的文件。管理员可以建立远程系统上文件的访问，以至于用户感觉不到他们是在访问远程文件。
拥有实际的物理磁盘并且通过NFS将这个磁盘共享的主机叫NFS文件服务器，通过NFS访问远程文件系统的主机叫NFS客户机。一个NFS客户机可以利用许多NFS服务器
提供的服务。相反，一个NFS服务器可以与多个NFS客户机共享它的磁盘。一个共享了部分磁盘的NFS服务器可以是另一个NFS服务器的客户机。
Linux直接在内核对NFS提供支持。NFS允许用户使用与本地文件系统一样的命令mount把NFS文件系统挂接在本地文件树结构上，这些主机将远程主机的文件系统看做好象是本地文件系统一样，并且是可安装的，可读的和可写的。如下图所示：
一个简单的NFS网络拓扑结构
通过与Linux的VFS的结合，通常用户是感觉不到正在使用的NFS与UFS（Unix File System）之间的差别。
NFS的客户端和服务器端
运行模式：
NFS服务器可以以stand-alone、xinetd两种模式运行。
stand－alone方式是Unix传统的C/S模式的访问模式。服务器监听（Listen）在一个特点的端口上等待客户端的联机。如果客户端产生一个连接请求，守护进程就创建（Fork）一个子服务器响应这个连接，而主服务器继续监听。以保持多个子服务器池等待下一个客户端请求。因为在NFS这种负载很大服务器上，预先创子服务器，可以提高客户的服务速度。stand－alone模式工作原理下图。
NFS的stand－alone工作模式
和stand－alone工作模式相比，xinetd模式不想要每一个网络服务进程都监听其服务端口。运行单个xinetd就可以同时监听所有服务端口，这样就降低了系统开销，保护系统资源。但是对于访问量大、经常出现并发访问时，xinetd想要频繁启动对应的网络服务进程，反而会导致系统性能下降。
总结：
NFS的优点：
1. 发展多年，简单但是成熟；
2. Linux直接在内核予以支持，使用方便；
NFS的缺点：
1. 可扩展性差，难以应用于大量存储节点和客户端的集群式（cluster）系统；
2. 文件服务器的定位（location）对客户端非透明，维护困难；
3. 缓存管理机制采用定期刷新机制，可能会发生文件不一致性问题；
4. 不支持数据复制，负载均衡等分布式文件系统的高级特性，很容易出现系统的
性能瓶颈；
5. NFS服务器的更换会迫使系统暂停服务
6. 对于异地服务的支持能力不强
总之，NFS太老了，对于追求海量数据吞吐量、存在成千上万个客户端和存储节点的互联网应用来说已经力不从心了。
AFS文件系统
历史
AFS是美国卡内基梅隆大学CMU与IBM联合研制的（项目开始于1982年，相关文章始见于1986年），发行了几个版本，AFS3.0是顶峰之作。其后，针对AFS的工作转移
到Transarc公司，AFS演变为OSF的分布式计算环境（DCE）的分布式系统（DFS）组成部分。1998 年IBM 收购了Transarc，并使AFS 成为一个开放源码产品，叫做OpenAFS。同时，OpenAFS 衍生了其他的分布式文件系统，如Coda 和Arla。其版本发展如下图所示：
AFS的版本演化
基本概念
AFS是专门为在大型分布式环境中提供可靠的文件服务而设计的。AFS扩展性好，能够扩展到几千个节点，提供一个统一的位置无关的名字空间。AFS规定了以"/afs/cellname"为第一级目录的基本结构，使用户能够在任何地方都能够使用同一个目录地址对自已的文件进行透明访问。
AFS的挂载示例
AFS中几个重要的概念：
单元（Cell）：是AFS一个独立的维护站点（如上图的https://www.doczj.com/doc/853714026.html,），通常代表一个组织的计算资源。一个存储节点在同一时间内只能属于一个站点；而一个单元可以管理数个存储节点。
卷（Volumes）：是一个AFS目录的逻辑存储单元，我们可以把它理解为AFS的cell 之下的一个文件目录，如上图单元https://www.doczj.com/doc/853714026.html,之下的usr目录。AFS系统负责维护一个单元中存储的各个节点上的卷内容保持一致。
挂载点（Mount Points）：关联目录和卷的机制，挂载点<---> 卷，例如上图的
/afs/https://www.doczj.com/doc/853714026.html,/usr这个挂载点就关联在usr卷上。
复制（Replication）：隐藏在一个单元之后的卷可能在多个存储节点上维护着备份，但是他们对用户是不可见的。当一个存储节点出现故障是，另一个备份卷会接替工作。
缓存和回调（Caching and Callbacks）：AFS依靠客户端的大量缓存来提高访问速度。当被多个客户端缓存的文件被修改时，必须通过回调来通知其他客户端更新。
T okens和Access Control List：用于访问权限管理，这里不在赘述。
设计架构
AFS 管理人员把单元划分为所谓的卷。虽然卷可以随硬盘分区协同扩展
(co-extensive)，但大多数管理人员都不会将整个分区只分为一个卷。AFS 卷实际上是由一个单独的、称作Volume Manager 的UNIX 类型的进程管理的。您可以以一种常见的方式从UNIX 文件系统目录安装卷。但是，您可以将AFS 卷从一个文件服务器移动到另一个文件服务器——同样是由一个UNIX 类型的进程来管理的——但是UNIX 目录不能从一个分区实际地移动到另一个分区上。AFS 通过Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录。因此，每当文件服务器非预期地停止操作，用户根本无需担心，因为AFS 会把用户切换到另一个文件服务器机器上的复制卷，而用户可能都不会注意到。用户从来不对AFS 服务器上的文件进行操作。他们操作已经由客户端缓存管理器从文件服务器中取出的文件。
AFS部署示例
AFS服务器运行下列进程：
文件服务器（File Server）进程：这个进程响应客户工作站对文件服务的请求，维护目录结构，监控文件和目录状态信息，检查用户的访问。
卷宗服务器（Volume Server）进程：此进程处理与卷宗有关的文件系统操作，如卷宗生成、移动、复制、备份和恢复。
基本监察服务器（Basic OverSeer Server）进程：这个进程运行于有BOS设定的服务器。它监控和管理运行其他服务的进程并可自动重启服务器进程，而不需人工帮助。
卷定位服务器（Volume Location Server）进程：该进程提供了对文件卷宗的位置透明性。即使卷宗被移动了，用户也能访问它而不需要知道卷宗移动了。
鉴别服务器（Authentication Server）进程：此进程通过授权和相互鉴别提供网络安全性。用一个“鉴别服务器”维护一个存有口令和加密密钥的鉴别数据库，此系统是基于Kerberos的。
保护服务器（Protection Server）进程：此进程基于一个保护数据库中的访问信息，使用户和组获得对文件服务的访问权。
更新服务器（Update Server）进程：此进程将AFS的更新和任何配置文件传播到所有AFS服务器。
备份服务器（Backup Server）：维护备份数据库中的信息并管理卷的备份操作。
缓存管理器（Cache Manager）：响应本地应用程序的请求，来跨AFS 文件系统取出文件。并存放在缓存中。
AFS通过在客户端大量开辟文件缓存来提高性能。如果文件是经常更改的源文件，那么文件的几个复制版本存在于多个客户端中可能不太好。因为用户很可能要频繁地更改经常被请求的源文件，所以您会遇到两个问题：首先，文件很可能被保存在客户机缓存内，而同时
还保存在几个文件服务器机器上的几个复制卷内；然后，Cache Manager不得不更新所有的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统可以处理发生在其他地方的任何更改。如果用户更改了缓存在其他地方的复制文件，原始文件服务器将会激活回调，并提醒原始缓存版本它需要更新。
分布式版本控制系统也面临这个经典问题，但是有一点重要的区别：分布式版本控制系统在断开时可以运行得很好，而AFS 文件系统的任一部分都不能断开。断开的AFS 部分无法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的AFS 文件服务器重新同步，但是不能添加可能在它断开后保存在本地的新更改
AFS还配有一套用于差错处理，系统备份和AFS分布式文件系统管理的实用工具程序。例如，SCOUT定期探查和收集AFS文件服务器的信息。信息在给定格式的屏幕上提供给管理员。设置多种阈值向管理者报告一些将发生的问题，如磁盘空间将用完等。另一个工具是USS，可创建基于带有字段常量模板的用户帐户。Ubik提供数据库复制和同步服务。一个复制的数据库是一个其信息放于多个位置的系统以便于本地用户更方便地访问这些数据信息。同步机制保证所有数据库的信息是一致的。
总结
AFS的优势：
1．历史悠久，技术成熟。
2．有较强的安全性（基于Kerberos）。
3．支持单一、共享的名字空间。
4．良好的客户端缓存管理极大的提高了文件操作的速度。
但以AFS作为机群中的共享文件系统也存在一些问题：
1．消息模型：和NFS一样，AFS作为早期的分布式文件系统是基于消息传递（Message-Based）模型的，为典型的C\S模式，客户端需要经过文件服务器才
能访问存储设备，维护文件共享语义的开销往往很大。
2．性能方面：它使用本地文件系统来缓存最近被访问的文件块，但却需要一些附加的极为耗时的操作，结果，要访问一个AFS文件要比访问一个本地文件多花一倍
的时间。
3．吞吐能力不足：AFS设计时考虑得更多的是数据的可靠性和文件系统的安全性，并没有为提高数据吞吐能力做优化，也没有良好的实现负载均衡；而当今互联网
应用则经常面对海量数据的冲击，必须提高文件系统的I/O并行度，最大化数据
吞吐率。
4．容错性较差：由于它采用有状态模型，在服务器崩溃，网络失效或者其他一些像磁盘满等错误时，都可能产生意料不到的后果。
5．写操作慢：AFS为读操作做优化，写操作却很复杂，读快写慢的文件系统不能提供好的读、写并发能力。
6．不能提供良好的异地服务能力，不能良好的控制热点信息的分布
AFS 的后代
由于一些对新文件系统的尝试，AFS 已经明显要退出了。两个这样的结合了开发人员从原始分布式文件系统架构中学到的经验的系统就是：Coda 和瑞典开放源码志愿者的成果Arla。
Coda 文件系统是改进原始的AFS 系统的第一次尝试。1987 年在Carnegie Mellon University，开发人员想要使Coda 成为对AFS 的一次自觉的改进，当时AFS 达到了V2.0 版本。在上个世纪80 年代末90 年代初，Coda 文件系统首次发布了一个不同的缓存管理器：Venus。虽然Coda 的基本功能集与AFS 的类似，但是Venus 支持支持Coda 的客户机的连续操作，即使客户机已经从分布式文件系统断开了。Venus 具有与AFS Cache Manager 完全相同的功能，即把文件系统任务从内核内部的VFS 层取出。
从1993 年起，编程人员就开始开发Arla，这是一个提供OpenAFS 的GPL 实现的瑞典项目，但是大部分的开发都发生在1997 年以后。Arla 模仿OpenAFS 模仿得非常好，只是XFS 文件系统必须运行在所有运行Arla 的操作系统上。Arla 已经达到V0.39 版本了，而且，就像OpenAFS 一样，运行在所有的BSD 流派、内核V2.0x 版本以上的许多Linux 内核以及Sun Solaris 之上。Arla 确实为AFS 实现了一个原本不在AFS 代码中的功能：断开操作。但是具体情况可能会不同，开发人员也还没有完成测试。
至今，AFS及其变种仍然活跃在分布式文件系统的研究和应用领域。
GPFS/Tiger Shark文件系统
历史
Tiger Shark是由IBM公司Almaden研究中心为AIX操作系统设计的并行文件系统，约1993年的时候完成。它被设计用于支持大规模实时交互式多媒体应用，如交互电视（interactive television, ITV）。基于Tiger Shark文件系统，可以构建大规模的视频服务器，并能以每秒6Mb的速度传递几百个并行的MPEG流。Tiger Shark文件系统已经应用到了RS/6000的完整的产品线上，从最小的桌面机到SP-2并行超级计算机。
IBM公司Almaden研究中心不断的对Tiger Shark文件系统进行完善和发展，并最终诞生了目前应用广泛的GPFS（General Parallel File System，通用并行文件系统，也就是Almaden's Tiger Shark file system的产品名字）。
1990年代后期，GPFS逐渐进入Linux操作系统，但未能获得有效的技术支持。目前，IBM公司已经逐步将GPFS转成开源软件，以期待获得更多的平台支持。
设计架构
图1 GPFS的系统框架
如上图，GPFS通过它的共享磁盘结构来实现它的强大的扩展性，一个GPFS系统由许多集群节点组成，GPFS文件系统和应用程序在上面运行。这些节点通过switch fabric连接磁盘和子磁盘。所有的节点对所有的磁盘有相同的访问权。文件被分割存储在文件系统中所有的磁盘上。
GPFS支持4096个每个容量达1TB的磁盘，每个文件系统可以达到4 petabytes。产品中最大的单个GPFS文件系统是75TB，机器是ASCI White。GPFS支持64位文件接口。虽然它对大文件系统的支持不是只针对Linux集群的，但是数据结构和算法还是值得讨论的。
图2 GPFS系统配置图
在每个GPFS文件系统的存储节点上，系统配置框架如上图所示，主要由以下组件构成：1．GPFS kernel module extension (mmfs)：核心扩展模块提供与Linux核心中VFS （虚拟文件系统）的接口。通过此模块，对GPFS文件系统的操作就像对普通文件系统一样。
2．Portability Layer module：PLM 提供linux核心与GPFS核心模块之间的通信，必须进行编译生成。
3．RSCT daemon：GPFS 中使用到了RSCT 守护进程中的两个服务：hagsd和hatsd。Hagsd 守护进程提供分布系统中信息同步和交换的功能；Hatsd 守护进程属于Topology 子系统，提供网卡状态、节点连通性等监控结果。
4．GPFS daemon (mmfsd)：GPFS守护进程是GPFS 文件系统的核心进程，它保证所有的输入输出操作和缓冲区管理的正常。GPFS 守护进程是一个多线程进程，其中很多线程专门提供特定的服务，这样保证大量请求发生时，不会发生阻塞。GPFS 守护进程还负责与其它节点的GPFS 守护进程通信，来保证数据的一致性。
设计特点
为了支持高数据容量和多媒体文件的高并发访问，GPFS文件系统提供了如下的设计：支持长时间的文件实时访问：GPFS通过2种方法来实现文件的长时间访问——资源预留策略和实时磁盘调度算法。资源预留策略为已有的客户端连接确保足够的磁盘带宽；实时磁盘调度算法则满足客户端的实时传输需求。
大磁盘块：一般的文件系统使用4KB作为磁盘块的大小，而GPFS为了支持多媒体文件的大数据流，使用256KB（也可以在16K到1M之间调节）的大型数据块作为磁盘块大小，最大限度地发挥磁盘的传输效率。
写分块：为了提高并行性，GPFS把文件分块存储到多个存储节点上，以并行访问的方式大大提高文件的数据吞吐量，并通过整个系统的负载均衡避免了某个磁盘过大的读写。
由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即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一样共享这个虚拟性的存储了。 元数据服务器安装和配置
６苏州大学学报（工科版）第３０卷 图１Ｉ－ＩＤＦＳ架构 ２ＨＤＦＳ与ＬｉｎｕｘＦＳ比较 ＨＤＦＳ的节点不管是ＤａｔａＮｏｄｅ还是ＮａｍｅＮｏｄｅ都运行在Ｌｉｎｕｘ上，ＨＤＦＳ的每次读／写操作都要通过ＬｉｎｕｘＦＳ的读／写操作来完成，从这个角度来看，ＬｉｎｕｘＰＳ是ＨＤＦＳ的底层文件系统。 ２．１目录树（ＤｉｒｅｃｔｏｒｙＴｒｅｅ） 两种文件系统都选择“树”来组织文件，我们称之为目录树。文件存储在“树叶”，其余的节点都是目录。但两者细节结构存在区别，如图２与图３所示。 一二 Ｒｏｏｔ ＼ 图２ＩｔＤＦＳ目录树围３ＬｉｎｕｘＦＳ目录树 ２．２数据块（Ｂｌｏｃｋ） Ｂｌｏｃｋ是ＬｉｎｕｘＦＳ读／写操作的最小单元，大小相等。典型的ＬｉｎｕｘＦＳＢｌｏｃｋ大小为４ＭＢ，Ｂｌｏｃｋ与ＤａｔａＮ－ｏｄｅ之间的对应关系是固定的、天然存在的，不需要系统定义。 ＨＤＦＳ读／写操作的最小单元也称为Ｂｌｏｃｋ，大小可以由用户定义，默认值是６４ＭＢ。Ｂｌｏｃｋ与ＤａｔａＮｏｄｅ的对应关系是动态的，需要系统进行描述、管理。整个集群来看，每个Ｂｌｏｃｋ存在至少三个内容一样的备份，且一定存放在不同的计算机上。 ２．３索引节点（ＩＮｏｄｅ） ＬｉｎｕｘＦＳ中的每个文件及目录都由一个ＩＮｏｄｅ代表，ＩＮｏｄｅ中定义一组外存上的Ｂｌｏｃｋ。 ＨＤＰＳ中ＩＮｏｄｅ是目录树的单元，ＨＤＦＳ的目录树正是在ＩＮｏｄｅ的集合之上生成的。ＩＮｏｄｅ分为两类，一类ＩＮｏｄｅ代表文件，指向一组Ｂｌｏｃｋ，没有子ＩＮｏｄｅ，是目录树的叶节点；另一类ＩＮｏｄｅ代表目录，没有Ｂｌｏｃｋ，指向一组子ＩＮｏｄｅ，作为索引节点。在Ｈａｄｏｏｐ０．１６．０之前，只有一类ＩＮｏｄｅ，每个ＩＮｏｄｅ都指向Ｂｌｏｃｋ和子ＩＮ－ｏｄｅ，比现有的ＩＮｏｄｅ占用更多的内存空间。 ２．４目录项（Ｄｅｎｔｒｙ） Ｄｅｎｔｒｙ是ＬｉｎｕｘＦＳ的核心数据结构，通过指向父Ｄｅｎ姆和子Ｄｅｎｔｒｙ生成目录树，同时也记录了文件名并 指向ＩＮｏｄｅ，事实上是建立了＜ＦｉｌｅＮａｍｅ，ＩＮｏｄｅ＞，目录树中同一个ＩＮｏｄｅ可以有多个这样的映射，这正是连
分布式文件系统（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 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于
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分布式文件系统也是通过计算机网络与节点相连，但也有优于传统分布式文件系统的优点。 1. 支持超大文件 HDFS分布式文件系统具有很大的数据集，可以存储TB或PB级别的超大数据文件，能够提供比较高的数据传输带宽与数据访问吞吐量，相应的，HDFS开放了一些POSIX的必须接口，容许流式访问文件系统的数据。 2. 高容错性能 HDFS面向的是成百上千的服务器集群，每台服务器上存储着文件系统的部分数据，在集群的环境中，硬件故障是常见的问题，这就意味着总是有一部分硬件因各种原因而无法工作，因此，错误检测和快速、自动的恢复是HDFS最核心的架构目标，因此，HDFS具有高度的容错性。 3. 高数据吞吐量 HDFS采用的是“一次性写，多次读”这种简单的数据一致性模型，在HDFS 中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了，这样简单的一致性模型，有利于提高吞吐量。 4. 流式数据访问 HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理，应用程序能以流的形式访问数据
集。 Hadoop已经迅速成长为首选的、适用于非结构化数据的大数据分析解决方案，HDFS分布式文件系统是Hadoop的核心组件之一，保证了大数据的可靠存储，与MapReduce配合使用，可以对结构化和复杂大数据进行快速、可靠分析，从而为企业做出更好的决策，促进收入增长，改善服务，降低成本提供有力支撑！
分布式文件系统概述（一） 杨栋 yangdonglee@https://www.doczj.com/doc/853714026.html, 2006-12 摘要 文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。 1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.doczj.com/doc/853714026.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)
分布式文件系统架构设计 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根目录： 不使用 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文件块。
第一部分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算法来实现的。
分布式文件系统研究16：Global File System 分类：技术日志 前段时间比较忙，好久没发技术文章了，几天来一个，嘿嘿 Global File System 简介 GFS（Global File System）是Minnesota大学开发的基于SAN的共享存储的机群文件系统，后来Sis tina公司将GFS产品化。GFS在很长一段时间都是以源代码开放软件的形式出现的，后来由于Sistina希望通过向用户提供支持和服务的计划未能取得成功，为了要促进自己的财务收入，Sistina在2001年将GFS 变成了一种“专有软件”。Red Hat公司收购Sistina之后，在遵循GPL协议（General Public License）的条件下履行诺言公开了GFS的源代码。现在，GFS的全名被称为“红帽全球文件系统”（Red Hat Global File System ，GFS）的软件，每台服务器每年收取2200美元的费用。 可能是redhat为了更好的收取服务费的缘故，有关GFS的文档真是少之又少，我只能从网上一些零星的资料来看看GFS的概貌。 框架 GFS最初是在IRIX上开发的，后来移植到LINUX上，并开放源码。基本框架如下图所示。 图1 GFS的基本框架图 通过使用GFS，多台服务器可以共用一个文件系统来存储文件。信息既可以存储在服务器上，也可以存储在一个存储局域网络上。 GFS与GPFS结构相似，但它是全对称的机群文件系统，没有服务器，因而没有性能瓶颈和单一故障点。GFS将文件数据缓存于节点的存储设备中，而不是缓存在节点的内存中。并通过设备锁来同步不同节点对文件的访问，保持UNIX文件共享语义。GFS实现了日志，节点失效可以快速恢复。GFS使用SCSI
分布式文件系统研究 由于工作性质的关系，我觉得自己很有必要对当今主流的分布式文件系统（Distributed File System，DFS）做系统的研究，总结优缺点，为下一步的工作提供必要的参考。因此，我动手搜集了不少资料，并进行了很初步的学习，以后我会把自己对DFS的学习心得整理起来，陆续放到博客上来。这就当是开篇吧，嘿嘿 概述 文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。 根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的本地文件系统，如Unix的本地文件系统；多处理器多用户的分布式文件系统，如Lustre文件系统。 本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。 由于互联网应用的不断发展，本地文件系统由于单个节点本身的局限性，已经很难满足海量数据存取的需要了，因而不得不借助分布式文件系统，把系统负载转移到多个节点上。 传统的分布式文件系统（如NFS）中，所有数据和元数据存放在一起，通过单一的存储服务器提供。这种模式一般称之为带内模式（In-band Mode）。随着客户端数目的增加，服务器就成了整个系统的瓶颈。因为系统所有的数据传输和元数据处理都要通过服务
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)
Hadoop分布式文件系统：架构和设计要点 Hadoop分布式文件系统：架构和设计要点 原文：https://www.doczj.com/doc/853714026.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，不过这比较少见。
常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。做个中文版下载源：https://www.doczj.com/doc/853714026.html,/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： https://www.doczj.com/doc/853714026.html,/papers/gfs.html https://www.doczj.com/doc/853714026.html,/papers/bigtable.html https://www.doczj.com/doc/853714026.html,/papers/mapreduce.html GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类 GFS的产品。
Software Engineering and Applications 软件工程与应用, 2017, 6(2), 21-27 Published Online April 2017 in Hans. https://www.doczj.com/doc/853714026.html,/journal/sea https://https://www.doczj.com/doc/853714026.html,/10.12677/sea.2017.62003 文章引用: 杜振南, 朱崇军. 分布式文件系统综述[J]. 软件工程与应用, 2017, 6(2): 21-27. A Survey of Distributed File System Zhennan Du, Chongjun Zhu College of Computer Science, National University of Defense Technology, Changsha Hunan Received: Mar. 27th , 2017; accepted: Apr. 10th , 2017; published: Apr. 14th , 2017 Abstract The file system is an important part of the computer system. With the development of personal computer and network technology, the generation of distributed file system has effectively solved the problem of infinite growth of massive information storage. This paper summarizes the origin of the distributed file system and comprehensively analyzes and organizes the architecture of several typical distributed file systems by consulting a large number of documents. Keywords Distributed File System, Storage Technology 分布式文件系统综述 杜振南，朱崇军 国防科学技术大学计算机学院，湖南 长沙 收稿日期：2017年3月27日；录用日期：2017年4月10日；发布日期：2017年4月14日 摘 要 文件系统是计算机系统的重要组成部分，随着个人计算机和网络技术的发展，分布式文件系统的产生有效解决了无限增长的海量信息存储问题。本文通过查阅大量文献，概述了分布式文件系统的起源并综合分析整理了几种典型分布式文件系统的体系架构。 关键词 分布式文件系统，存储技术
明确要求采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN的原因：从软件定义存储概念提出到现在，分布式架构存储系统正成为业界存储主流和发展方向，逐渐取代传统集中式存储系统，随着云计算和大数据的建设成为数据中心建设主流形态，互联网+、人工智能、物联网应用等的普及，以非结构化数据为主的海量数据爆发式增长，如视音频存储、图像存储及识别、流媒体处理等，基于海量数据存储、分析、挖掘等，传统集中式存储无论从架构、扩展性、性能及成本，运维管理优势等方面，都无法满足业务增长及数据处理所带来的存储问题。 首先从架构上，集中式存储FC SAN/IP SAN 采用Scale up的扩展方式，通过存储控制器挂接扩展柜的方式，实现存储容量的扩展，扩展能力有限，并且性能随着容量扩展并非线性关系，可能存储前端及后端端口带宽会成为海量数据并发处理的瓶颈，并且存储资源分布不均，无法做到资源动态均衡伸缩及调度，这对于响应级别要求不一致的应用来说是致命的；分布式架构存储系统，采用Scale out 横向扩展方式，无节点扩展限制，存储容量可轻易扩展至几十甚至几百PB以上，这是集中式存储无法做到的，能够很好解决在云计算架构下海量数据存储及并发问题。并且基于分布式软件的分布式调度算法，可实现资源动态伸缩，随着节点增加，其性能是线性增加，能够很好满足如云计算架构下海量数据存储及处理对存储资源池可动态伸缩及并发访问性能要求。 由于采用软件定义存储方式，无论是成本还是后期运维管理，比传统集中式存储FC SAN/ IP SAN优势明显，分布式软件自动实现对存储资源调度及管理，实现跨数据中心资源分配。集中式存储系统，需要借助存储虚拟化技术（虚拟化网关）才能将存储资源聚合为统一存储资源池，随着规模扩大，网关往往更易成为性能瓶颈。 关于数据安全性问题，分布式架构存储系统基于机架自动感知的数据多副本技术，例如采用三副本技术，即使数据中心同一机架故障，对业务透明无感知，数据安全级别高，业务连续性更好。集中式存储往往采用双活架构实现容灾，不仅初期投入成本高，运维部署复杂。 从应用角度来看，现在越来越多的应用迁到分布式存储系统上，例如海量视频、音频、图像、文档的存储，流媒体及视频图像处理所带来的高并发低延迟，高性能计算应用等，都非常适合分布式架构存储系统，而不采用集中式存储系统，并且从数据存储及性能要求、容量扩展方便，集中式存储做起来非常困难。 诸如以上原因，明确要求采用采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN。