分布式文件系统研究.doc

分布式文件系统研究由于工作性质的关系，我觉得自己很有必要对当今主流的分布式文件系统（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到现在的StorageTank，分布式文件系统在体系结构、系统规模、性能、可扩展性、可用性等方面经历了巨大的变化。 第一代分布式文件系统（1980年代） 早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的性能和数据的可靠性，以NFS和AFS(Andrew File System)最具代表性，它们对以后的文件系统设计也具有十分重要的影响。 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）语义的一致性等。 Carnegie Mellon大学在1983年设计开发的AFS将分布式文件系统的可扩展性放在了设计和实现的首要位置，并且着重考虑了在不安全的网络中实现安全访问的需求。因此，它在位置透明、用户迁移、与已有系统的兼容性等方面进行了特别设计。AFS具有很好的扩展性，能够很容易地支持数百个节点，甚至数千个节点的分布式环境。同时，在大规模的分布式文件系统中，AFS利用本地存储作为分布式文件的缓存，在远程文件无法访问时，依然可以部分工作，提高了系统可用性。后来的Coda File System、Inter-mezzo File System都受到AFS的影响，更加注重文件系统的高可用性（High Availability）和安全性，特别是Coda，在支持移动计算方面做了很多的研究工作。 早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，在受网络环境、本地磁盘、处理器速度等方面限制的情况下，更多地关注访问的性能和数据的可靠性。AFS在系统结构方面进行了有意义的探索。它们所采用的协议和相关技术，为后来的分布式文件系统设计提供了很多借鉴。 第二代分布式文件系统（19901995） 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根据请求内容的转发是静态的，对于整个系统中负载的变化难以做出及时反应。 第三代分布式文件系统（19952000） 网络技术的发展和普及应用极大地推动了网络存储技术的发展，基于光纤通道的SAN、NAS得到了广泛应用。这也推动了分布式文件系统的研究。 在这个阶段，计算机技术和网络技术有了突飞猛进的发展，单位存储的成本大幅降低。而数据总线带宽、磁盘速度的增长无法满足应用对数据带宽的需求，存储子系统成为计算机系统发展的瓶颈。这个阶段，出现了多种体系结构，充分利用了网络技术。 出现了多种分布式文件系统体系结构，如Global File System（GFS）、General Parallel File System （GPFS）、惠普的DiFFS、SGI公司的CXFS、EMC的HighRoad、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两种模式运行。standalone方式是Unix传统的C/S模式的访问模式。服务器监听（Listen）在一个特点的端口上等待客户端的联机。如果客户端产生一个连接请求，守护进程就创建（Fork）一个子服务器响应这个连接，而主服务器继续监听。以保持多个子服务器池等待下一个客户端请求。因为在NFS这种负载很大服务器上，预先创子服务器，可以提高客户的服务速度。standalone模式工作原理下图。NFS的standalone工作模式和standalone工作模式相比，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一个独立的维护站点（如上图的），通常代表一个组织的计算资源。一个存储节点在同一时间内只能属于一个站点；而一个单元可以管理数个存储节点。卷（Volumes）：是一个AFS目录的逻辑存储单元，我们可以把它理解为AFS的cell之下的一个文件目录，如上图单元之下的usr目录。AFS系统负责维护一个单元中存储的各个节点上的卷内容保持一致。挂载点（Mount Points）：关联目录和卷的机制，挂载点 卷，例如上图的/afs//usr这个挂载点就关联在usr卷上。复制（Replication）：隐藏在一个单元之后的卷可能在多个存储节点上维护着备份，但是他们对用户是不可见的。当一个存储节点出现故障是，另一个备份卷会接替工作。缓存和回调（Caching and Callbacks）：AFS依靠客户端的大量缓存来提高访问速度。当被多个客户端缓存的文件被修改时， 必须通过回调来通知其他客户端更新。Tokens和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）模型的，为典型的CS模式，客户端需要经过文件服务器才能访问存储设备，维护文件共享语义的开销往往很大。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，通用并行文件系统，也就是Almadens 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文件系统的存储节点上，系统配置框架如上图所示，主要由以下组件构成：1GPFS kernel module extension (mmfs)：核心扩展模块提供与Linux核心中VFS（虚拟文件系统）的接口。通过此模块，对GPFS文件系统的操作就像对普通文件系统一样。2Portability Layer module： PLM 提供linux核心与GPFS核心模块之间的通信，必须进行编译生成。3RSCT daemon：GPFS 中使用到了RSCT 守护进程中的两个服务：hagsd和hatsd。Hagsd 守护进程提供分布系统中信息同步和交换的功能；Hatsd 守护进程属于Topology 子系统，提供网卡状态、节点连通性等监控结果。4GPFS daemon (mmfsd)：GPFS守护进程是GPFS 文件系统的核心进程，它保证所有的输入输出操作和缓冲区管理的正常。GPFS 守护进程是一个多线程进程，其中很多线程专门提供特定的服务，这样保证大量请求发生时，不会发生阻塞。GPFS 守护进程还负责与其它节点的GPFS 守护进程通信，来保证数据的一致性。设计特点为了支持高数据容量和多媒体文件的高并发访问，GPFS文件系统提供了如下的设计：支持长时间的文件实时访问：GPFS通过2种方法来实现文件的长时间访问资源预留策略和实时磁盘调度算法。资源预留策略为已有的客户端连接确保足够的磁盘带宽；实时磁盘调度算法则满足客户端的实时传输需求。大磁盘块：一般的文件系统使用4KB作为磁盘块的大小，而GPFS为了支持多媒体文件的大数据流，使用256KB（也可以在16K到1M之间调节）的大型数据块作为磁盘块大小，最大限度地发挥磁盘的传输效率。写分块：为了提高并行性，GPFS把文件分块存储到多个存储节点上，以并行访问的方式大大提高文件的数据吞吐量，并通过整个系统的负载均衡避免了某个磁盘过大的读写。数据复制：通过复制文件系统元数据和文件数据，GPFS实现了一个较为简单的软件RAID模式，支持数据块级别的文件复制，以克服单点故障，提高系统可用性。数据一致性：GPFS通过一套复杂的信令管理机制提供数据一致性；通过这套机制允许任意节点通过各自独立的路径到达同一个文件。即使节点无法正常工作，GPFS也可以找到其它的路径。数据安全性：GPFS是一种日志文件系统，为不同节点建立各自独立的日志。日志种记录metadata的分布，一旦节点发生故障后，可以保证快速恢复数据。系统可扩展性：GPFS可以动态调整系统资源；可以在文件系统挂载情况下添加或者删除硬盘，GPFS自动在各个节点间同步配置文件和文件系统信息。总结GPFS作为当今较成功的一个商业分布式文件系统，其显著特点是性能高、扩展性好，高可用。但GPFS目前主要应用于IBM公司自身的AIX操作系统，其他平台则很难应用，且GPFS价格昂贵；同时，GPFS需要特殊的存储设备的支持，如典型的GPFS需要用双重附带的RAID控制器。这给普通用户构建集群服务器带来困难，并提高了成本。为了取得更多的平台支持，IBM已经将GPFS的源代码逐步公开。虽然GPFS的性能优越，但GPFS的问题在于非常复杂的数据一致性处理和高延迟的数据传输。同时，由于设计的年代较早，并没有应用分布式文件系统领域的最新研究成果。随着SAN（存储区域网络）和 NAS（网络连接存储）两种结构逐渐成熟，研究人员开始考虑如何将两种结构结合起来。网格的研究成果等也推动了分布式文件系统体系结构的发展。为此，IBM公司在GPFS的基础上发展进化来的Storage Tank，以及基于Storage Tank的TotalStorage SAN File System，又将分布式文件系统的设计理念和系统架构向前推进了一步。PVFS文件系统历史很多商业化的分布式文件系统，如IBM的GPFS，Intel的PFS等，它们在性能，可用性上都有不错的表现，但一般价格昂贵，且需要特殊的存储设备的支持，普通用户构建基于此类的集群服务器代价高昂；而较老的开放源码的分布式文件系统，如NFS、AFS等，性能和可用性又不是十分理想。因此，对开放源码的新型分布式并行文件系统的需求一直比较迫切。目前，对于公开源码的分布式文件系统，声誉最好的是Clemson大学和NASA实验室联合开发的PVFS，它相对与传统的集中存储NFS具有良好的性能。并行虚拟文件系统(PVFS)工程为Linux集群提供了高性能和可扩展行的并行文件系统。PVFS是开放原代码的，于1998年公开，并且在GNU公共版权许可证下发布。它无需特殊的硬件设备和内核的改动，可以直接应用于廉价的Linux集群。PVFS目前为止有两个重要版本：PVFS1是早期的版本，在运行时存在严重的单点故障问题，一旦管理服务器宕机，则整个系统都无法正常工作；而且，PVFS的程序开发者认为代码写得过于混乱，因而，他们整理并重写了PVFS的源代码，并发布了PVFS2。在PVFS2中，不再单独设立管理服务器，而是各个运行IOD进程的节点都可以接管管理服务器功能，以此来改善系统的单点故障问题。目前，PVFS已被广泛地用作临时存储的高性能的大型文件系统和并行I/O研究的基础架构。国内的浪潮并行文件系统就是在PVFS的基础上研制的。设计架构与当前很多分布式文件系统一样，PVFS基于C/S架构和消息传递机制实现。其客户和服务器之间的消息传递通过TCP/IP来完成，提供可靠的通讯环境。所有的PVFS文件系统数据都保存在I/O节点的本地文件系统中，本地的文件系统可以是一个硬盘驱动器上的一个分区，可以是整个磁盘驱动器，也可以利用本地所支持的Linux文件系统（例如ext2，ext3和ReiserFS）所提供的多个磁盘驱动器的逻辑卷。PVFS的逻辑视图如图1所示，使用了三种类型的节点：管理节点、I/O节点和计算节点。PVFS采用多个I/O服务器、单一元数据服务器设计。 图1 PVFS的逻辑视图管理节点：即元数据服务器，负责管理所有的文件元数据信息；I/O节点：运行I/O服务器，负责分布式文件系统中数据的存储和检索；计算节点：处理应用访问，通过PVFS专有的libpvfs接口库，从底层访问PVFS服务器。PVFS系统中的任何一个节点作为其中的一个节点运行，也可以同时作为两种或是三种节点运行。PVFS提供重要的4个功能：1一致性的访问名字空间：为了易于安装和使用，PVFS提供了统一的文件命名空间；2支持现存的系统访问方式：在已安装PVFS文件和目录能够继续使用Linux类似的命令和工具，比如ls、cp和rm，方便用户的使用。该功能由Linux核心的一个模块提供支持。3将数据分配到多个磁盘上：为高速访问群集中的文件系统，PVFS将文件数据进行条块化划分，分散存储到某些群集节点（称作I/O节点）的多个磁盘上，从而消除了I/O路径的瓶颈，且增加了客户端并发带宽。4为应用程序提供高性能的数据访问方式：对PVFS来说，应用程序除了可以通过现有的系统调用访问方式外，还可以通过本地libpvfs库，以专有API的方式访问PVFS文件系统的。而libpvfs直接与PVFS服务器相连接，而不是传递消息给内核，提高了访问效率。运行机制PVFS的运行机制如下：当打开、关闭、创建或删除一个文件时，计算节点上的应用程序通过libpvfs接口直接与元数据服务器通信：图2 PVFS中的数据访问详细流程1发起文件操作请求，请求被传送到底层的 PVFS 文件系统模块。2PVFS 向元数据服务器发送一个请求，要求取得相关文件在各个 I/O 节点上的元数据信息。（步骤1）3PVFS元数据服务器把元数据信息返回给计算结点。（步骤2）4使用这些信息，计算节点直接与所有相关的 I/O 节点进行通信，获得整个文件（步骤 3）。 这些步骤对于调用应用程序来说都是透明的；计算节点使用libpvfs直接联系相应的I/O节点进行读写操作，而不必与元数据服务器通信（见图2），从而大大提高了访问效率。PVFS相比NFS、AFS等传统的文件系统，有很大的性能提升。其采用一个元数据服务器来维护一个全局的名字空间，而文件存储于多个I/O服务器上，因此大大提高了I/O并发性能；多个I/O节点被虚拟为一个单一数据源，各个前端计算节点可以面对这个单一的数据源进行读写操作，省去了复杂的管理；而PVFS架构中的管理服务器，将前端的所有I/O请求均衡负载到各个I/O节点，从而实现了系统I/O的自动负载均衡。存在的不足PVFS存在的问题： 1集中的元数据管理成为整个系统的瓶颈，可扩展性受到一定限制。 2系统容错性有待提高：数据没有采取相应的容错机制，采用非Unix语义，并且没有文件锁，其可扩展性较差，应用规模很大时容易导致服务器崩溃。3系统可扩展性有待加强：PVFS使用静态配置，不具备动态扩展性，如果要扩展一个I/O节点，系统必须停止服务，并且不能做到空间的合理利用。4PVFS目前还不是由商业公司最终产品化的商品，而是基于GPL开放授权的一种开放技术。虽然免费获取该技术使整体系统成本进一步降低，但由于没有商业公司作为发布方，该技术的后续升级维护等一系列服务，都难以得到保证。 多媒体分布式文件系统1. 研究背景1.1. 研究历史和研究现状1 在1990年代的中后期很火爆，能够查阅到的论文基本上是这个时期的2 到2000左右发生变化，相关的研究论文突然消失了，似乎没有人对这个感兴趣了，why？猜测的原因：l 1990年代可能这方面的应用刚刚起步，整个架构设计处于草创阶段，各主要大学的计算机系都对此方面展开了比较深入的研究，如CMU，NYU等等；各个商业公司对这个比较有前途的应用领域也是采取比较开放的态度，鼓励科研人员发表相关的论文；l 2000年左右，多媒体分布式文件系统逐渐成熟，已经实现了商业化，各个公司出于商业利益考虑，开始保守秘密，雪藏研究成果；l 多媒体分布式文件系统的基本理论已经在1990年代的大讨论中定型，在基础理论上近年来也没有重大突破；l 多媒体分布式文件系统的实现中，原来很多需要文件系统底层支持的特性，现在都可以通过上层的软件或是廉价的硬件轻松的实现，因而对底层系统的需求也不是特别迫切。原来的多媒体分布式文件系统都已经发展成为通用的分布式文件系统，如GPFS。3 2000年之后，成熟的多媒体分布式文件系统的商业系统只有IBM基于Tiger Shark的GPFS文件系统，在GPFS的基础上发展进化来的Storage Tank，以及基于Storage Tank的TotalStorage SAN File System。但是他们均已经发展成为通用的分布式文件系统，专用的多媒体分布式文件系统的研究和产品似乎消失了。1.2. 研究分类1 单机：如MMFS，重新设计了整个底层文件系统。现在应用不是很多，构建文件系统底层架构代价很大，但是效果却不是很明显，而且不够灵活，可能大家更加倾向于在播放器软件上下功夫，既方便，见效又快。2 分布式的，如：GPFS，已经商业化；NASD，CMU，研究型，项目已在2000年左右停止，后来该项目的研究成果成为了Lustre文件系统的前身； HBDFS，松下的，研究型，最近的资料在2000年发布，现在的项目进展未知。当前的基于SAN和NAS技术的新型分布式文件系统，如Lustre，PanFS等，都有应用于多媒体系统的潜力。1.3. 简单总结 多媒体DFS商业驱动的氛围很浓，目前已经很难发掘到比较有意义的开源资料；专用的多媒体分布式文件系统日渐消亡，大家都在向通用文件系统转型。2. 相关技术2.1. 应用特点1. 有一定的实时要求2. 巨大的文件大小和相当高的数据传输率3. 多重数据流2.2. 研究方向1. 磁盘调度u 成绩优先算法（Performance-oriented algorithms）u 实时保证算法（Real-time algorithmsu 基于流的算法（Stream-oriented algorithms）u 混合算法（Mixed-media algorithms）2. 数据存放1) 块分配（Block Allocation）：一般通过底层文件系统实现u 随机分块u 连续分块u 扩展分块u 基于柱面u 基于日志u 区域分配u 限制分配2) 日志（Journaling）快速恢复3) 多磁盘问题u 交错分块提高并发度u 复制通过对文件复制，文件系统不仅可以增加数据的可靠性，还能提高操作的并发性，增加吞吐量。a) 静态复制：完整复制文件的副本，提供多个用户同时访问的入口。b) 动态段复制：根据预测文件的并发度，将文件划分为大小相同的段，并复制到不同服务器上；c) 极限动态复制：根据当前系统的极限负载并发度划分文件段，并复制到不同服务器；d) 部分复制：对文件中被访问次数最多的部分进行复制，以提高这部分的并发性。u 负载均衡防止某个服务器上的负载过量，而其他服务器的负载过少。a) G-SDCL：通过交错Round-Robin方式向服务器写入数据，使得每次循环中写入的服务器都是不同的。b) 素数Round-Robin(PRR)：在Round-Robin循环中，采用素数的方式选取服务器写入数据。3. 缓存管理u 基于块分配u 基于流分配4. 元数据管理元数据和普通数据分开存放u 集中式元数据u 分布式元数据5. 文件系统接口根据需要实现3. 应用需求多媒体应用到底在那些方面提出了哪些要求？3.1. 播放器部分1 暂停（Pause）和继续（resume）支持，同时支持并行的记录（record）和回放（playback) ；2 同时记录两个不同的视频流 ；3 快速播放（Fast forward）、重放（rewind）和拖尾（through the playing program）；4 跳跃（Skip），支持前跳（forward）和后跳（backward ) ；5 在磁盘上组织文件记录，以便他们能被方便的访问；6 流控制（flow control）：如何精确定位，特别是一些压缩的视频流；3.2. 文件系统部分1 多媒体分布式文件系统需要很高的数据流量，因而必