深入理解Lustre文件系统-第2篇 体系结构的模块视图

Lustre是一个以GNUGeneral Public为许可证的，开源的分布式并行文件系统，由Sun Microsystems Inc. 公司开发和维护。由于Lustre文件系统的体系结构具有极好的可扩展性，它得以在科学计算、石油天然气、制造业、rich media、金融等领域得到广泛部署。Lustre为其客户端提供了包含对共享文件对象的并行存取能力在内的POSIX接口。截止本文编写时为止，根据Top500的数据，在全世界前30个超级计算机中，有15个使用了Lustre文件系统。

Lustre是一个面向对象的文件系统。它由三个部件组成：元数据服务器（Metadataservers, MDSs）、对象存储服务器（objectstorage servers, OSSs）和客户端。图1给出了文件系统的体系结构。Lustre使用块设备来作为文件数据和元数据的存储介质，每个块设备只能由一个Lustre服务管理。Lustre文件系统的容量是所有单个OST的容量之和。客户端通过POSIX I/O系统调用来并行访问和使用数据。

• MDS（元数据服务器）提供元数据服务。相应的，MDC（元数据客户端）则是这些服务的客户端。每个文件系统的一个MDS管理一个元数据目标（MDT）。MDT存储诸如文件名、文件夹结构、访问权限之类的文件元数据。

• MGS（管理服务器）提供Lustre文件系统的配置信息。

• OSS（对象存储服务器）expose块设备并提供数据。对应的OSC（对象存储客户端）则是这些服务的客户端。每个OSS管理一个或者多个对象存储目标（OSTs），而OSTs存储文件数据对象。

       MDS/MGS和OSS/OST的集合有时称为Lustre服务前端（Lustreserver fronts），而fsfilt和ldiskfs则被称为Lustre服务后端（Luster server backends）。在接下来的探讨中，我们从Lustre的客户端开始，顺着数据和控制路线，一直到OST和MDS。这些探讨牵涉到很多的部件，为使其结构关系更加明显，省略了很多细节，。

1.1      Lustre客户端

Lustre作为一个遵从POSIX标准的文件系统，为用户提供了诸如open()、read()、write()等统一的文件系统接口。在Linux中，这些接口是通过虚拟文件系统（Virtual File System,VFS）层实现的（在BSD/Solaris中，则称为vnode层）。为了提供这些接口，Lustre中有一个称为llite的薄层，与VFS相连。接着，到达llite的文件操作请求，通过整个的Lustre软件栈来访问Lustre文件系统，如Figure 2所示。

在Lustre中，诸如创建、打开、读等一般的文件操作，都需要存储在MDS上的元数据信息。这些服务通过一个称为MDC的客户端接口模块来访问。

从MDS的观点来看，每个文件都是分条（stripe）在一个或者多个OST上的多个数据对象的集合。一个文件的布局（layout）信息在索引节点（inode）的扩展属性（extended attribute, EA）中定义。从本质上说，EA描述了从文件对象ID到它对应的OST之间的映射关系。这些信息成为分条扩展属性（striping EA）。

例如，如果一个文件A的分条数目为3，那么它的EA可能类似于：

所以如果分条大小是1MB，那么这意味着[0, 1M), [3M, 4M) …作为对象x存储在OST p；[1M, 2M),  [4M, 5M) …作为对象y存储在OST q; [2M,3M),  [5M, 6M) …作为对象z存储在OST r。

在读取文件之前，客户端将首先通过MDC询问MDS，从而得知它应当就这个操作，和<ost p, ost q, ostr>进行对话。这些信息组织在所谓的LSM中，而客户端的LOV（logical object volume，逻辑对象卷）则是用来解释这个信息的，这样就使得客户端能够向OST发送请求。需要重申的是，客户端通过一个称为OSC的客户端模块接口，和OST进行通信。根据上下文的不同，OSC也可以用来指称OSS客户端。

在Lustre中的所有的客户端/服务器通信，都以RPC请求和应答的形式编码。在Lustre源码中，这个中间层称为Portal RPC，或者ptl-rpc。它在文件系统请求和与之等价的PRC请求和应答之间，进行翻译和解释，而LNET模块则最后将这些RPC请求/应答发送到传输线上。

1.2      OSS

在OSS栈的底层，是我们所熟悉的LNET和Portal-RPC层。和客户端的栈一样，Portal RPC也翻译请求。需要注意的是，由OSS处理的请求是数据请求，而不是元数据请求。元数据请求应当由MDS栈来传递和处理，正如Figure 2中最右栏所示。

溯栈而上，OST像一个发报机（dispatcher?）一样工作：它根据请求的类型,调用不同的函数。宽泛地说，有两类请求：关乎锁的和关乎数据的。前者将被传递到ldlm（Lustredistributed lock manager）进行处理，而后者将被传递道obdfilter。obdfilter可以说是用来在Lustre栈和常规的OS栈之间相互联系的模块。通过另外一个称为fsfilt的封装API模块（wrapper API component）的帮助，它定义了一个一般性API，从而将Lustre特有的请求翻译为后端文件系统特有的请求。从概念上说，fsfilt就像一个VFS层，如果你在其中定义了适当的文件操作，它将使用这个特定的文件系统作为后端；在Lustre中，这个后端文件系统暂时为ldiskfs。将来，也将支持ZFS作为后端文件系统，而 fsfilt则可能被重新设计或者被替代为一个更好的与文件系统无关的中间层。

1.3      MDS

MDS软件栈与OSS的软件栈类似，但是它们之间也有一些不同。主要的不同是MDS没有obdfilter，如图2所示。这个发报机被称为MDS。当然它不仅仅只作为一个发报机，这将在第6部分作进一步分析。对于一个元数据变更请求，MDS的日志有一点不同：它在直接调用VFS API之前开始一个事务。这一特定的部件块可以称为dcache，因为它主要关心对dentrycache进行的操作，但是在大的框架上，它实际上是VFS的一部分。

2012-11-01: 更正了分条计算的错误。

本文章欢迎转载，请保留原始博客链接http://blog.csdn.net/fsdev/article