分布式文件系统设计主要关注几个方面

本文主要是介绍分布式文件系统设计主要关注几个方面，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

分布式文件系统设计主要关注几个方面：

设计特点、分布式能力、性能、容灾、维护和扩展、成本

分布式文件系统主要关键技术：

全局名字空间、缓存一致性、安全性、可用性、可扩展性

其他关键技术：

文件系统的快照和备份技术、热点文件处理技术、元数据集群的负载平衡技术、分布式文件系统的日志技术

一、GFS（google file system）

GFS与过去的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。

GFS与以往的文件系统需要共同关注的：

性能、可扩展性、可靠性、可用性

GFS与以往的文件系统的不同的观点如下：

1、组件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。

2、按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计对象的数据集时，即使底层文件系统提供支持，我们也很难管理成千上万的KB规模的文件块。因此在设计中，操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。

3、大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。

4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达 1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。

5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。

GFS设计策略：

1、一个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk-handle标识，chunk-handle是在块创建时由 master分配的。

2、出于可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。这些副本在linux文件系统上作为本地文件存储。

3、每个GFS集群只有一个Master，维护文件系统所有的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。

4、Master定期通过HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。

5、客户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。此外，Chunkserver也不必缓存文件，因为块是作为本地文件存储的。依靠linux本身的缓存cache在内存中保存数据

图1 读操作暨GFS 架构

GFS组件

1、Master

（1）保存文件/Chunk名字空间、访问控制信息、文件到块的映射以及块的当前位置，全内存操作（64字节每Chunk）；

（2）Chunk租约管理、垃圾和孤儿Crunk回收、不同服务器间的Chunk迁移；

（3）操作日志：操作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一、永久地被标识；

（4）在多个远程机器备份Master数据；

（5）Checkpoint用于快速恢复。

2、Chunk Server

（1）64MB固定大小，较大的Chunk size，以减少元数据开销，减少同Master的交互

（2）Chunk位置信息并不是一成不变的

（3）启动时polling

块规模是设计中的一个关键参数，GFS选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。

块规模较大的好处有：

（1）减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。

（2）Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。

（3）这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。

但是块规模较大也有不利的一面：

（1）Chunk较大可能产生内部碎片

（2）同一个Chunk中存在许多小文件可能产生访问热点。

容错和诊断

1、高可靠性

（1）快速恢复

不管如何终止服务，MASTER和数据块服务器都会在几秒钟内恢复状态和运行。实际上，并不对正常终止和不正常终止进行区分，服务器进程都会被切断而终止。客户机和其他的服务器会经历一个小小的中断，然后它们的特定请求超时，重新连接重启的服务器，重新请求。

（2）数据块备份

如上文所讨论的，每个数据块（Chunk）都会被备份到放到不同机架上的不同服务器上。对不同的名字空间，用户可以设置不同的备份级别。在数据块服务器掉线或是数据被破坏时，MASTER会按照需要来复制数据块。

（3）MASTER备份

为确保可靠性，MASTER的状态、操作记录和检查点（check point）都在多台机器上进行了备份。一个操作只有在数据块服务器硬盘上刷新并被记录在MASTER和其备份的上之后才算是成功的。如果MASTER或是硬盘失败，系统监视器会发现并通过改变域名启动它的一个备份机，而客户机则仅仅是使用规范的名称来访问，并不会发现MASTER的改变。

2、数据完整性

每个数据块服务器都利用校验和来检验存储数据的完整性。原因：每个服务器随时都有发生崩溃的可能性，并且在两个服务器间比较数据块也是不现实的，同时，在两台服务器间拷贝数据并不能保证数据的一致性。

每个Chunk按64kB的大小分成块，每个块有32位的校验和，校验和和日志存储在一起，和用户数据分开。

在读数据时，服务器首先检查与被读内容相关部分的校验和，因此，服务器不会传播错误的数据。如果所检查的内容和校验和不符，服务器就会给数据请求者返回一个错误的信息，并把这个情况报告给MASTER。客户机就会读其他的服务器来获取数据，而MASTER则会从其他的拷贝来复制数据，等到一个新的拷贝完成时，MASTER就会通知报告错误的服务器删除出错的数据块。

附加写数据时的校验和计算优化了，因为这是主要的写操作。因此只是更新增加部分的校验和，即使末尾部分的校验和数据已被损坏而没有检查出来，新的校验和与数据会不相符，这种冲突在下次使用时将会被检查出来。

相反，如果是覆盖现有数据的写，在写以前，我们必须检查第一和最后一个数据块，然后才能执行写操作，最后计算和记录校验和。如果我们在覆盖以前不先检查首位数据块，计算出的校验和则会因为没被覆盖的数据而产生错误。

在空闲时间，服务器会检查不活跃的数据块的校验和，这样可以检查出不经常读的数据的错误。一旦错误被检查出来，服务器会拷贝一个正确的数据块来代替错误的。

系统扩展性能：

由于GFS采用单一Master的设计结构，因此扩展主要在于Chunk的加入，每当有chuankserver加入的时候Master会询问其所拥有的块的情况。而Master在每次启动的时候也会主动询问所有chunk server的情况。

GFS单一Chunk的设计方式使得系统管理简单、方便，但也有不利的一面：随着系统规模的扩大，单一Master是否会成为瓶颈？

GFS的扩展性能受限于其单个Master的限制。（"GFS doesn’t scale. Its single master is a bottleneck"）

GFS是一个成功的系统，但它在FDS中带来了一些新的概念和实现，缺乏一般性决定了它不能得到广泛的应用。（"GFS is a successful system. But it brings few new concepts in DFS design and implementation. Its lack of generality determines that it cannot have wide application"，GMM1.ppt）

另：Lustre正在研究元数据集群

成本：

GFS主要运行在大量运行Linux系统的普通机器上，从而降低了其硬件成本。但一系列冗余备份、快速恢复等技术保证其正常和高效运行。

二、AFS（Andrew File System）

AFS产生背景：

AFS是Carnegie Mellon University在1983设计开发的AFS将分布式文件系统的可扩展性放在了设计和实现的首要位置，并且着重考虑了在不安全的网路中实现安全访问的需求，因此它在位置透明、用户迁移、与已有系统的兼容性等方面进行了特别设计。AFS具有很好的扩展性，它能够很容易地支持数百个节点，甚至数千个节点的分布式环境。同时，在大规模的分布式文件系统中，AFS利用本地存储作为分布式文件的缓存，在远程文件无法访问时，依然可以部分工作，提高了系统可用性。

目前AFS已经相当成熟，已经不仅仅用于研究用途，它已经应用于一些大型网络（5000台工作站）。众多知名大学如Stanford, MIT and KTH在他们的计算机网络中使用AFS。OpenAFS仍然在活跃开发中，2006-04-23还发布了版本1.4.1并增加了对MacOSX 10.4的支持。

AFS架构

示意图

AFS 是围绕一组叫做Cell的文件服务器组织的。每个服务器的标识通常是隐藏在文件系统中的。从AFS客户机登录的用户将分辨不出他们在哪个服务器上运行，因为从用户的观点来看，他们像在有可识别的UNIX文件系统语义的单个系统上运行。文件系统内容通常都是跨Cell复制，以便一个硬盘的失效不会损害AFS客户机的运行。AFS需要高达1GB的大容量客户机缓存，以允许访问经常使用的文件。它还是一个十分安全的基于Kerbero的系统，它使用访问控制列表(ACL)以便可以进行细粒度的访问，这不是基于通常的Linux和UNIX安全模型。

AFS技术细节：

AFS通信实现于TCP/IP之上，并使用为之开发的RPC协议Rx在机器之间进行通信。通信协议已经对广域网进行了优化，并不受服务器和客户机的地址位置的限制。AFS的主要组件描述如下：

Cells：

AFS的基本组织单元，是一个独立管理的服务器和客户机的集合。一般一个Cell对应一个域名。在同一时刻一个服务器或者客户机只能属于一个Cell，但用户可在多个Cell拥有多个帐号，登录时首先进入的称为home Cell，其他的称为foreign。从用户角度来看，通过正常的文件操作在/afs/[Cell name]中访问AFS的层次结构，由于AFS是位置无关的，因此不管用户在什么地方都会看到相同的目录树。而文件的实际可用与否则取决于用户的存取许可，可通过访问控制列表（Access Control List）设置

AFS clients：

AFS的用户端组件是Cache Manager，它可以作为用户进程运行（需要对内核的少量修改），或者作为内核的修改版本（OpenAFS）。其主要工作在于从服务器取问文件、保持本地文件缓存、将文件请求翻译为RPC（remote procedure calls），以及保存回调。

AFS的设计受到以下观察到的用户模式的影响：

（1）一般访问文件的大小为数千字节；

（2）读比写更常见；

（3）连续访问比随机访问更常见；

（4）即使文件是共享的，通常只能有一个用户进行文件写操作；

（5）文件访问存在突发。

AFS选择的策略是在用户本地缓存文件，当一个文件打开时，Cache Manager首先检查在Cache中有无该文件的合法拷贝，如果没有就去文件服务器上获取。在客户端修改的文件在关闭后将传回给服务器。

为了保证文件始终是最新的，使用了一种回调机制。在一个文件第一次打开时，一个Callback Promise与新打开的文件被一起发给客户，Callback Promise保存在客户机上并标记为Valid，如果文件被其他的客户修改了，那么服务器将发送回调给Cache Manager，后者将Callback Promise状态设置为canCelled。那么下次在应用程序访问该文件的时候，当前拷贝必须从服务器获取。如果文件从Cache中flushed，服务器将得到通知移除回调。

客户端重启后Callback Promise需要检查它们的状态是否改变，通过Cache Manager执行一个Cache Validation Request来实现。

AFS不支持多个并发更新，将此责任交给应用程序。如果多个客户端同时打开、修改、关闭同一个文件，最后一个更新覆盖前面的改变。

Volumes：

AFS中的基本存储单元称为Volume，它是对应于文件树中一个目录的逻辑单元。比如，它通常将用户的home目录映射到独立的volume上。

AFS管理人员把Cell划分为卷。虽然卷可以随硬盘分区协同扩展(co-extensive)，但大多数管理人员都不会将整个分区只分为一个卷。AFS卷实际上是由一个单独的、称作Volume Manager的UNIX类型的进程管理的。可以以一种常见的方式从UNIX文件系统目录安装卷。你可以将AFS卷从一个文件服务器移动到另一个文件服务器——同样是由一个UNIX类型的进程来管理的——但是UNIX目录不能从一个分区实际地移动到另一个分区上。AFS通过Volume Location Manager自动跟踪卷和目录的位置，并留意复制的卷和目录。因此，每当文件服务器非预期地停止操作，用户根本无需担心，因为AFS会把用户切换到另一个文件服务器机器上的复制卷，而用户可能都不会注意到。

Volume replication

经常由多个客户访问的Volume可以被复制。这要求将一个Volume的只读拷贝复制到不通的服务器上，这对修改较少、访问较多的卷来说非常有用。比如Unix的库和程序等。

AFS servers

服务器可以扮演多种角色，包括：

（1）作为一个单独的文件服务器；

（2）作为一个复制的AFS数据库服务器；

（3）作为一个二进制发布服务器，来分发服务器软件的更新版本；

（4）作为一个系统控制机器来分发公共配置文件和作为一个主时钟同步节点。

当一个Cell中只有一个服务器时，它将扮演上面提到的所有角色。mentioned roles。

服务器进程：

AFS的实现是模块化的，并不要求在每台服务器上运行所有的服务器进程。下面对不同进程及其功能进行简单介绍：

（1）Basic OverSeer Server (BOS)：

BOS server用于启动和管理其他所有的服务器进程。确认其他服务器进程正常运转，并重启失效进程。它的主要功能是使系统的outtages最小，并减少对系统手动干涉的需要。当一个文件服务器或者卷服务器失效的时候，BOS会调用一个称为Salvager的特殊进程来修复由于失效引起的磁盘不一致。

（2）File Server：

负责文件的传递和储存，维持层次化的文件结构，处理copy/move/create/delete等请求，并跟踪文件状态（大小、修改时间等）。在创建文件和granting advisory locks之间的连接时也会得到调用。

为了决定用户是否有权限执行请求的操作，File Server还需要与Protection Server通信。

（3）Authentication Server：

用于储存权限数据库，该数据库保存用户口令和服务器密钥，采用Kerberos在客户和服务器之间提供相互验证。并提供有时限的令牌供客户使用已证明其已经通过验证。

（4）Protection Server：

保存保护数据库，是访问控制列表的关键组件，访问控制列表用于目录级别，并组成了一个精致的UNIX许可系统。有7个不同的访问许可，分别是lookup, insert, delete, administer, read, write, and lock。

（5）Volume Server：

提供卷管理相关工具，比如creation, relocation, deletion and replication, and preparation for backup and archival of volumes。

（6）Volume Location Server：

卷位置服务器保存卷位置数据库，用于明了不同的卷位于哪个服务器上。这也是一个提高数据访问透明的关键组件，因为Cache Manager通过访问它来获知从哪个File Server来获取文件。

（7）Update Server：

保证每个服务器都具有最新的服务器进程版本以及公共配置文件。

（8）Backup Server

保存备份数据库，用于创建卷的备份档案。

数据库复制：

AFS的4类数据库经常得到修改，因此所有服务器的拥有数据库的相同拷贝对于系统性能来说至关重要。使用一项称作Ubik的技术，一种通过RPC实现的复制数据库技术。只有一个服务器——同步节点，可以接收对数据库的更新。它运行一个称为Ubik coordinator的进程，并将改变立即分发给其他服务器。在此期间，所有对数据库的读/写操作失效，如果没有收到大部分服务器的响应，更新将取消，退回到更新前的状态。

必须维护一个列表以知道哪些服务器实际上得到了同步，必要时Ubik coordinator可以通过选举的方法移到其他的服务器上，以获得最大的可用性。

时钟同步：

AFS通常（特别是它的数据库复制）依赖于服务器时钟同步，这通过Network Time Protocol Daemon实现。一个服务器作为同步节点从外部时钟源获取时间，其他服务器通过该服务器更新时钟。

AFS的主要特点在于其位置透明（location transparency），性能（performance）和内置安全（built-in security性）。

（1）位置透明：

AFS通过系统进程和卷位置数据库进行文件位置自动跟踪。NFS必须通过管理员和用户设置挂载点来跟踪文件物理位置。用户只需要知道路径名就可以访问文件和它所在的AFS Cell。

（2）AFS的性能和可扩展性：

AFS最大的一个优点就是它的卷的符号（notation of volumes），相对于普通文件系统分区它可以在不退出服务的情况下从一台机器复制到另外一台机器。这在许多情况下非常有用。当一到两个卷的副本失效的时候，正常工作的卷可以立即拷贝到另外一台服务器上。这也增强了AFS的扩展性，新服务器可以无干扰地加入系统。

容灾：

Andrew 文件系统将文件组成名为“逻辑卷”的集合，一个典型的逻辑卷可以是单个用户的文件，或者是特定的系统二进制发布文件。逻辑卷被“挂载点”机制互联，类似标准的UNIX挂载。终端用户很少需要在意逻辑卷。另一方面，操作者和系统管理员几乎只用关心逻辑卷，而不需要关心独立的用户文件，因为逻辑卷是用于像备份、平衡文件服务器和只读文件的冗余存储这些操作的单位。

从一个操作者的角度看，一种重要的文件系统操作是为一个逻辑卷生成一个只读的映像，或者是“克隆”。这种操作通过快速和经济地制作克隆来实现，因此它们在一些重要的方面使用。首先，新软件的发行一般通过克隆系统二进制文件完成。只读克隆可以在多服务器上复制，导致在可用性和性能上的显著增加。（在Carnegie Mellon，有三台服务器仅用于系统卷的只读克隆。）第二，独立用户的逻辑卷在每天午夜被克隆。这样做的原因是为了得到一个连续的映像，然后可以在第二天备份。第二个好处是每个用户都可以在“<nop>OldFiles”名称下得到克隆，这样万一出错，还能得到所有用户前一天的工作。这显著地减少了从备份磁带恢复文件的需要。

AFS的扩展性受限于经常访问的服务器的性能，将文件复制到多台服务器上可以在一定程度上这种压力，不过这只适用于只读文件，AFS中读写文件不可复制，这是它的最大缺点。

最初的AFS规范目标是客户/服务器比例达到200/1，目前有AFS系统达到了这个比列，但是推荐比例为50/1。Andrew的性能测试说明在用户增加时，AFS比NFS具有更好的性能。

安全性：

AFS使用Kerbero来进行用户验证，在多个方面改进了安全性，密码不通过明文传输，同时，验证是相互的，用户和服务提供者的身份都得到了验证。

AFS优点：

扩展性好，同时客户端缓存带来了性能的提升和可用性的提高。不过这也带来了缓存一致性问题，需要回调函数的使用。

此外，由于在客户端使用了系统调用方式（这样在客户端可以像访问本地文件一样访问网络文件，对用户透明），因此需要对客户端内核进行一定程度的修改。

缺点：

对管理员的用户友好性不足，比NFS或者SMB需要具有更多的专业知识；

读写文件大量存在时性能下降

“由CMU与IBM联合研制, AFS 3.0之后转给Transarc公司，后演变为DCE DFS。AFS有着非常高的可扩展性，可扩展到几千个节点，采用全局名字空间，且与位置无关，并基于Kerberos认证体系，有着良好的安全性。但AFS性能不高，容错性也较差，同时一致性也太弱，采用会话语义导致很多应用受限制。”

（http://www.etiri.com.cn/publish/article_show.php?id=~17924865964）

“分布式版本控制系统也面临这个经典问题，但是有一点重要的区别：分布式版本控制系统在断开时可以运行得很好，而AFS文件系统的任一部分都不能断开。断开的AFS部分无法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的AFS文件服务器重新同步，但是不能添加可能在它断开后保存在本地的新更改。”

("Why not AFS?

Requires more specialized administrator knowledge than NFS or SMB.

2 GB file size limitation.

Doesn’t scale down to high performance file sharing between a small number of clients.")

扩展性：

容灾：

客户和服务器属于特定的Cell，数据存储于服务器上，每个服务器至少有一个存储AFS数据的备份。（"Clients and servers belong to a particular Cell; data storage takes place on servers, each of which has at least one vice partition for storing AFS data.")

成本：

操作例子：

AFS中的打开文件操作

² 用户进程执行 open ( filename, mode ) 调用

² 如果文件是共享的，UNIX内核将请求传给Venus

² Venus检查文件是否在Cache中，如果不是或者是非法的Callback promise，就从Vice取文件

² Vice将文件拷贝给Venus并附带一个Callback Promise，同时对Callback Promise记录日志

² Venus将文件拷贝到本地Cache中

² UNIX内核打开文件并返回文件描述符

Opening a File in AFS

• User process issues open(FileName, mode) call.

• UNIX kernel passes request to Venus if file is shared.

• Venus checks if file is in cache. If not, or no valid callback promise, gets file from Vice.

• Vice copies file to Venus, with a callback promise. Logs callback promise.

• Venus places copy of file in local cache.

• UNIX kernel opens file and returns file descriptor to application.

三、Lustre

Lustre是HP,Intel,Cluster File System公司联合美国能源部开发的Linux集群并行文件系统.该系统目前推出1.0的发布版本,是第一个基于对象存储设备的,开源的并行文件系统。Lustre名称来源于Linux和Clusters，是一个新颖的存储和文件架构，并实现在大集群上。Lustre是开源软件，遵从GPL。其设计目标是下一代集群文件系统，该系统可以支持10000个节点，PB量级存储，以及数百GBps的传输速率（with state of the art security and management infrastructure）。Lustre的1.0版目标是最大1000个节点，存储量100TB。

目前可以支持1000个客户端节点的I/O请求，两个MDS采用共享存储设备的Active-Standby方式的容错机制,存储设备跟普通的、基于块的IDE存储设备不同，是基于对象的智能存储设备.。Lustre采用分布式的锁管理机制来实现并发控制，元数据和文件数据的通讯链路分开管理。与PVFS相比，Lustre虽然在性能，可用行和扩展性上略胜一踌，但它需要特殊设备的支持，而且分布式的元数据服务器管理还没有实现。

图 lustre架构

Lustre采用的技术包括：面向对象磁盘、元数据请求的批处理、支持通过网络来对Lustre进行管理和监控等。文件数据存储在面向对象的磁盘（Object-base Disk）上，用分布式的面向对象的存储服务器（OST，Object Storage Target）来负责真正的文件系统I/O和与存储设备的接口；用元数据服务器（MDS，Metadata Server）来存储与管理文件和文件系统的元数据。

Lustre包括三个主要模块（逻辑上）

Client (Remote Parallel File System)

MDS (Meta Data Server)

OST (Object Storage Target)

Lustre架构；

Lustre主要由元数据服务器（MDS, Meta Data Server）和对象存储目标（OST，Object Storage Target）构成：

（1）客户机（Clients）：应用运行在客户机上，并可以标准的POSIX语义看见一个共享文件系统。文件系统建立于文件集上（filesets）并提供一个全局名字空间，特定应用可以迂回（bypass）文件系统直接访问存储在集群里的目标。

（2）元数据控制系统（Metadata Control Systems）：管理名字空间和文件系统元数据一致性，安全、集群恢复以及协调存储管理功能。但不不介入文件数据的传输。

（3）存储目标（Storage Targets）：files,提供目标（Object）的可靠存储，目标可以是file，stripes or extents of files or serve other purposes。

（4）资源和安全数据库（Resource and security databases）：为系统提供配置管理信息，安全服务，用户和组数据库以及文件集文治数据库。Inter-site referrals provide key mechanisms for global infrastructure。通过共享存储容灾方案提供这些系统的冗余。

图lustre架构

图 Lustre子系统交互过程

性能：

I/O：目前Lustre是采用写透（wirte through）的方式，即写请求只有在数据真正被写到目标OST上的时候才算完成。这将在较为繁忙的服务器集群上导致较大的写操作延时。通过采用写回Cache（writeback cache），文件写被记录日志并允许异步执行，从而很大地提高了文件写请求的性能。

一些指标：

1文件夹、1200节点可以达到每秒创建8000个文件

单客户机/服务器可以达到2.5GB/sec

汇聚流量可达11GB/sec

数秒内可挂载上千个客户机

可扩展至数千节点、PB数量级存储

摘抄网上的一段评论：

“目前分布式文件系统比如 PVFS, lustre, 对于大量小文件的操作性能都一塌糊涂,原因很清楚, 在分布式文件系统中,通过多个服务器组成的IO cluster 建立一个跨越物理节点的虚拟的文件系统,当用户请求IO的时候,如果请求操作的文件块,被条带化在多个物理节点上, 多个物理IO节点和metadata node协同工作,可以并发的操作你的数据, 比如一个500MB的文件被条带化在10个节点上,如果存储策略是等分的,每个IO node并发的存取1/10的这个文件, node数越多, 存取速度越快。

再来考虑小文件,比如16KB以下的文件, 当IO request过来的时候,metadata server发现这个data实际上并没有跨越在多个IO node上,而是位于一个server上,所以整个处理过程等同于IO client -> metadata server -> IO node, 当如果你有大量的小文件(<16KB)分布在若干个IO node上的时候, 存取的性能除了需要考虑单台IO node的IO延迟之外,还要加上整个分布式文件系统在同一读写的时候的元数据操作开销. 所以当你的数据文件尺寸越小, 整个文件系统的性能就越差.”

（http://bbs.chinaunix.net/archiver/?tid-779132.html）

在客户机上Cache元数据，但不Cache文件数据。

元数据：目前Lustre采用单个元数据服务器，虽然简单、精确并具有扩展性，但是依赖于单台服务器降低了Lustre中元数据操作的性能。如果能够实现元数据集群则可以极大地提高系统元数据性能。

可扩展性：

元数据和文件数据分离（Separation of meta data and file data）

元数据可升级（Scalable meta data）

文件数据可升级（Scalable file data）

高效锁（effecient locking）

目标架构（Object Architecture）

扩展性：静态扩展Lustre Good Static

元数据管理：中心管理Centralize (present)

存储设备：需要特定存储设备支持Object Storage Device