深度：全面解析Lustre文件系统（下）-技术圈

本文内容参考自“Lustre文件系统操作手册（2021）”，全文内容包含45章节，620+页干货。52份Lustre及HPC技术方案下载链接如下：

Lustre文件系统操作手册（2021）

Lustre文件系统技术汇总（1）

Lustre文件系统技术汇总（2）

Lustre文件系统技术汇总（3）

Lustre文件系统技术汇总（4）

Lustre文件系统关键特性（1）

Lustre文件系统关键特性（2）

Lustre文件系统关键特性（3）

Lustre文件系统关键特性（4）

Lustre文件系统关键特性（5）

Lustre常见解决方案汇总（1）

Lustre常见解决方案汇总（2）

高性能计算HPC方案及技术汇总

在Lustre 2.4中，分布式命名空间环境(DNE)中可支持多个MDT。除保存文件系统根目录的主MDT之外，还可以添加其他MDS节点，每个MDS节点都有自己的MDT，以保存文件系统的子目录树。在Lustre 2.8中，DNE还允许文件系统将单个目录的文件分布到多个MDT节点。分布在多个MDT上的目录称为条带化目录。

对象存储服务器(OSS)：OSS为一个或多个本地OST提供文件I / O服务和网络请求处理。通常，OSS服务于两个到八个OST，每个最多16TB；在专用节点上配置一个MDT；在每个OSS节点上配置两个或更多OST；而在大量计算节点上配置客户端。

对象存储目标(OST)：用户文件数据存储在一个或多个对象中，每个对象位于Lustre文件系统的单独OST中。每个文件的对象数由用户配置，并可根据工作负载情况调试到最优性能。

Lustre客户端：Lustre客户端是运行Lustre客户端软件的计算、可视化或桌面节点，可挂载Lustre文件系统。

Lustre客户端软件为Linux虚拟文件系统和Lustre服务器之间提供了接口。客户端软件包括一个管理客户端(MGC)，一个元数据客户端(MDC)和多个对象存储客户端(OSC)。每个OSC对应于文件系统中的一个OST。

逻辑对象卷(LOV)通过聚合OSC以提供对所有OST的透明访问。因此，挂载了Lustre文件系统的客户端会看到一个连贯的同步名字空间。多个客户端可以同时写入同一文件的不同部分，而其他客户端可以同时读取文件。

与LOV文件访问方式类似，逻辑元数据卷(LMV)通过聚合MDC提供一种对所有MDT透明的访问。这使得了客户端可将多个MDT上的目录树视为一个单一的连贯名字空间，并将条带化目录合并到客户端形成一个单一目录以便用户和应用程序查看。

Lustre Networking(LNet)是一种定制网络API，提供处理Lustre文件系统服务器和客户端的元数据和文件I/O数据的通信基础设施。

Lustr文件系统在规模上，一个Lustre文件系统集群可以包含数百个OSS和数千个客户端(如下图所示)。Lustre集群中可以使用多种类型的网络，OSS之间的共享存储启用故障切换功能。

Lustre文件系统存储与I/O，在 Lustre 2.0 中引入了Lustre文件标识符(FID)来替换用于识别文件或对象的UNIX inode编号。FID是一个128位的标识符，其中，64位用于存储唯一的序列号，32位用于存储对象标识符(OID)，另外32位用于存储版本号。序列号在文件系统(OST和MDT)中的所有Lustre目标中都是唯一的。这一改变使未来支持多种 MDT 和ZFS(均在Lustre 2.4中引入)成为了可能。

同时，在此版本中也引入了一个名为FID-in-dirent(也称为Dirdata)的ldiskfs功能，FID作为文件名称的一部分存储在父目录中。该功能通过减少磁盘I/O显著提高了ls命令执行的性能。FID-in-dirent是在创建文件时生成的。

在 Lustre 2.4 中，LFSCK文件系统一致性检查工具提供了对现有文件启用FID-in-dirent的功能。具体如下：

为1.8版本文件系统上现有文件生成IGIF模式的FID。

验证每个文件的FID-in-dirent，如其无效或丢失，则重新生成FID-in-dirent。
验证每个linkEA条目，如其无效或丢失，则重新生成。linkEA由文件名和父类FID组成，它作为扩展属性存储在文件本身中。因此，linkEA可以用来重建文件的完整路径名。

有关文件数据在OST上的位置信息将作为扩展属性布局EA，存储在由FID标识的MDT对象中(具体如下图所示)。若该文件是普通文件(即不是目录或符号链接)，则MDT对象1对N地指向包含文件数据的OST对象。若该MDT文件指向一个对象，则所有文件数据都存储在该对象中。若该MDT文件指向多个对象，则使用RAID 0将文件数据划分为多个对象，将每个对象存储在不同的OST上。

当客户端读写文件时，首先从文件的MDT对象中获取布局EA，然后使用这个信息在文件上执行I / O，直接与存储对象的OSS节点进行交互。具体过程如下图所示。

（1）写性能优于读性能：Lustre系统中通常写性能会优于读性能。首先，对于写操作，客户端是以异步方式执行的，RPC调用分配以及写入磁盘顺序按到达顺序执行，可以实现聚合写以提高效率。而对于读，请求可能以不同的顺序来自多个客户端，需要大量的磁盘seek与read操作，显著影响吞吐量。

其次，目前Lustre没有实现OST read cache，仅仅在客户端实现了Readahead。这样的设计也是有充分理由的，每个OST有可能会有大量客户端并发访问，如果进行数据预读，内存消耗将会非常大，而且这个是不可控制的。Writecache是在客户端上实现的，内存占用不会太大并且是可控的。再者，对于TCP/IP网络而言，读会占用更多的CPU资源。读操作，Lustre需要从网络接口缓存进行数据Copy而获得所需数据，而写操作可以通过sendfile或Zero Copy避免额外的数据复制。

（2）大文件性能表现好：Lustre的元数据与数据分离、数据分片策略、数据缓存和网络设计非常适合大文件顺序I/O访问，大文件应用下性能表现非常好。这些设计着眼于提高数据访问的并行性，实现极大的聚合I/O带宽，这其中关键得益于数据分片设计（具体见上面的分析）。另外，后端改进的EXT3文件系统本身也非常适合大文件I/O。

（3）小文件性能表现差：然而，Lustre的设计却非常不利于小文件I/O，尤其是LOSF（Lots of small files）。Lustre在读写文件前需要与MDS交互，获得相关属性和对象位置信息。与本地文件系统相比，增加了一次额外的网络传输和元数据访问开销，这对于小文件I/O而言，开销是相当大的。对于大量频繁的小文件读写，Lustre客户端Cache作用会失效，命中率大大降低。

如果文件小于物理页大小，则还会产生额外的网络通信量，小文件访问越频繁开销越大，对Lustre总体I/O性能影响就越大。OST后端采用改进的EXT3文件系统，它对小文件的读写性能本身就不好，其元数据访问效率不高，磁盘寻址延迟和磁盘碎片问题严重。这也是大多数磁盘文件系统的缺点，Reiserfs是针对小文件设计的文件系统，性能表现要好很多。Lustre的设计决定了它对小文件I/O性能表现差，实际I/O带宽远低于所提供的最大带宽。在4个OSS的千兆网络配置下，单一客户端小文件读写性能不到4MB/s。

Lustre文件系统的可用带宽如下：

网络带宽等于OSS到目标的总带宽。
磁盘带宽等于存储目标(OST)的磁盘带宽总和，受网络带宽限制。
总带宽等于磁盘带宽和网络带宽的最小值。
可用的文件系统空间等于所有OST的可用空间总和。

Lustre文件系统高性能的主要原因之一是能够以轮询方式跨多个OST将数据条带化。用户可根据需要为每个文件配置条带数量，条带大小和OST。当单个文件的总带宽超过单个OST的带宽时，可以使用条带化来提高性能。同时，当单个OST没有足够的可用空间来容纳整个文件时，条带化也能发挥它的作用。

如图下图所示，条带化允许将文件中的数据段或“块”存储在不同的OST中。在Lustre文件系统中，通过RAID 0模式将数据在一定数量的对象上进行条带化。一个文件中处理的对象数称为stripe_count。每个对象包含文件中的一个数据块，当写入特定对象的数据块超过stripe_size时，文件中的下一个数据块将存储在下一个对象上。stripe_count和stripe_size的默认值由为文件系统设置的，其中，stripe_count为1，stripe_size为1MB。用户可以在每个目录或每个文件上更改这些值。

下图中，文件C的stripe_size大于文件A的stripe_size，表明更多的数据被允许存储在文件C的单个条带中。文件A的stripe_count为3，则数据在三个对象上条带化。文件B和文件C的stripe_count是1。OST上没有为未写入的数据预留空间。

最大文件大小不受单个目标大小的限制。在Lustre文件系统中，文件可以跨越多个对象(最多2000个)进行分割，每个对象可使用多达16 TB的ldiskfs，多达256PB的ZFS。也就是说，ldiskfs的最大文件大小为31.25 PB，ZFS的最大文件大小为8EB。Lustre文件系统上的文件大小受且仅受OST上可用空间的限制，Lustre最大可支持2 ^ 63字节(8EB)的文件。

注意: Lustre 2.2之前，单个文件的最大条带数为160个OST。尽管一个文件只能被分割成2000个以上的对象，但是Lustre文件系统可以有数千个。

实际上前面已经提到，Lustre并不适合小文件I/O应用，性能表现非常差。因此，建议不要将Lustre应用于LOSF场合。不过，Lustre操作手册仍然给出了一些针对小文件的优化措施。

1、通过应用聚合读写提高性能，比如对小文件进行Tar，或创建大文件或通过loopback mount来存储小文件。小文件系统调用开销和额外的I/O开销非常大，应用聚合优化可以显著提高性能。另外，可以使用多节点、多进程/多线程尽可能通过聚合来提高I/O带宽。

2、应用采用O_DIRECT方式进行直接I/O，读写记录大小设置为4KB，与文件系统保持一致。对输出文件禁用locking，避免客户端之间的竞争。

3、应用程序尽量保证写连续数据，顺序读写小文件要明显优于随机小文件I/O。

4、OST采用SSD或更多的磁盘，提高IOPS来改善小文件性能。创建大容量OST，而非多个小容量OST，减少日志、连接等负载。

5、OST采用RAID 1+0替代RAID 5/6，避免频繁小文件I/O引起的数据校验开销。

Lustre提供了强大的系统监控与控制接口用于进行性能分析与调优，对于小文件I/O，也可以通过调整一些系统参数进行优化。

禁用所有客户端LNET debug功能：缺省开启多种调试信息，sysctl -w lnet.debug=0，减少系统开销，但发生错误时将无LOG可询。

增加客户端Dirty Cache大小：lctl set_param osc./*.max_dirty_mb=256，缺省为32MB，增大缓存将提升I/O性能，但数据丢失的风险也随之增大。

使用loopback mount文件：创建大Lustre文件，与loop设备关联并创建文件系统，然后将其作为文件系统进行mount。小文件作用其上，则原先大量的MDS元数据操作将转换为OSS读写操作，消除了元数据瓶颈，可以显著提高小文件性能。这种方法应用于scratch空间可行，但对于生产数据应该谨慎使用，因为Lustre目前工作在这种模式下还存在问题。

下载链接：