并行编程模型，Lustre

最新推荐文章于 2024-08-05 15:42:17 发布

Pierson_Wu

最新推荐文章于 2024-08-05 15:42:17 发布

阅读量1.2k

点赞数

1 并行编程模型

现代高性能计算机通过将单个任务并行化，降低任务处理时间、提升计算精度或扩大规

模，要完成这些目标，需要选择合适的并行编程模型，并行编程模型与并行计算机体系

结构紧密相关，目前主流的并行编程模型包括共享内存编程模型和分布式内存编程模型。

共享内存体系架构（如NUMA，SMP 等）下的编程模型主要是共享内存编程模型，共

享内存编程模型具有单一地址空间，编程方法简单，但可移植性和可扩展性较差的特点，

目前使用较多的是OpenMP。OpenMP 是基于线程级的并行化，它通过在串行脚本内添

加pragma 制导语句来指导并行化。

分布式内存体系架构（如MMP，Cluster 等）下的编程模型是分布式内存编程模型，其

中较常用的是消息传递编程模型，具有多地址空间，编程较复杂，可移植性和可扩展性

较好的特点，目前使用较多的是MPI（Message Passing Interface），以函数库的形式被程

序调用，MPI 是基于进程级的并行，自1993 年2 月发布了MPI-1.0 标准后，至今已发

展了20 年，并于2012 年9 月发布了最新的MPI-3.0 标准，基于MPI 标准，业界有多种

开源和商用的MPI 实现，如开源的有MPICH、MVAPICH、OpenMPI 等，商用的有Intel

MPI、Platform MPI 等等。

当前高性能集群具有多层次结构，集群系统兼具了共享内存体系结构和分布式内存体系

结构的特点，这就导致了共享内存编程模型和分布式内存编程模型相结合的混合编程模

型出现，在节点内部使用共享内存编程模型，而节点间则采用分布式内存编程模型，即

OpenMP+MPI 的模式，其优势在于结合了OpenMP 线程级的细粒度并行（如循环并行）

和MPI进程级的粗粒度并行（如区域分解），在很多情况下，其性能要优于单纯的OpenMP

程序或MPI 程序。

计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍

的增长，单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、

容量增长速度、数据备份、数据安全等方面的表现都差强人意。

分布式文件系统（Distributed File System）可以有效解决数据的存储和管理难题：将固

定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一

个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据

传输。人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪

个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布

式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问

的服务器。

当前比较流行的分布式文件系统包括：Lustre、Hadoop、MogileFS、FreeNAS、FastDFS、

NFS、OpenAFS、MooseFS、pNFS、以及GoogleFS

1.1 Lustre

Lustre 体系结构是一个为集群设计的存储体系结构。其核心组件是运行在Linux 操作系

统上、支持标准的POSIX* UNIX 文件系统接口、并遵循GPL2.0 许可的Lustre 文件系

统。据IDC 的统计，Lustre 是在HPC 领域应用最广的文件系统，世界上最快的50 个超

算网站有60%都使用Lustre。

注：由于Lustre 结构的特点，每两台设备间存在备份关系，所以有时称为集群文件系统，而对于I/O

的处理模式来说，Lustre 业务是并行处理的所以也可称作并行文件系统，而对于业务的处理来说，

Lustre 的I/O 通常会分发给不同的I/O 节点处理，所以也可称之为分布式文件系统，以上三种称

谓只是分类角度不同，没有对错之分。

在集群计算机里，计算机与磁盘间数据交换的提升无法跟上微处理器和内存增长的速度，

从而也拖累了应用程序的性能。Lustre 文件系统很好的解决了这一问题，它可为数以万

计的客户端系统服务，提供PB 级的存储容量和百吉比特字节每秒（GB／秒）的I/O 吞

吐量。

Lustre 文件系统基于C/S 模式设计，其对象存储的特性（客户端与磁盘上的文件分离，

存储的升级和变更不影响客户端的使用），极大的降低了企业购买存储设备的成本，并

改变企业购买存储的方式。分布式和并行化的工作方式，使Lustre 的用户不必一次性购

买价格高昂的高端存储来满足性能需求，而可以通过低端存储和I/O 节点的动态扩充来

满足业务需求的增长。同时客户为每个集群应用建立一个文件系统，也可转换为使用全

局统一命名的文件系统，客户可以为每个文件配置条带等文件系统属性，从而减少了集

群间的数据拷贝、简化的集群的管理，聚集了服务器和集群的存储容量，减少了资源的

浪费，更易于性能动态的扩展。

Lustre 文件系统支持多种高性能、低时延的网络，例如基于OFED（OpenFabrics Enterprise

Distribution）的InfiniBand。在多种不同的RDMA 网络间还可以通过Lustre routing 进行

桥接。保证了Lustre 可以获得充足的网络带宽。

Lustre 文件系统通过共享存储分区的方式支持OST（Object storage target）的AA

（Active-Active）故障切换，实现了底层故障对应用透明，MMP（Multiple mount protection）

技术的使用为可能导致文件系统故障的系统错误提供了完整的保护。

组件

Lustre 文件系统的主要组件有：MDS、MDT、OSS、OST、Client。各个组件间的链接

关系如图2-7 所示。

MDS（Metadata Server）：MDS 负责管理Lustre 文件系统的文件名、目录、权限、文件

结构等元数据信息，MDS 生成的元数据存储在一个或者多个MDT 上，并为每个Client

提供服务。MDS 可以有多个，但只有一个为主MDS，其余MDS 工作在备份模式。

MDT（Metadata Target）：每个文件系统都有一个MDT，MDT 可以是MDS 本地硬盘（只

有一个MDS 时）、也可以是远端存储的一个LUN 设备。一个MDT 可以通过同时映射

于华为OceanStor V3 融合存储部署HPC 分布式文件系统参考架构

载最佳实践

给两台主机，供多个MDS 进行访问，但同一时刻只能有一个MDS 进行访问，通过这

种方式可以实现MDS 的高可用性。

OSS（Object Storage Servers）：OSS 为Client 提供文件I/O 服务，客户端从MDS 获取元

数据信息后，从OSS 访问文件数据，文件数据最终存储在与OSS 相连的OST 上。通常

每个OSS 会配置2~8 个OST，每个OST 最大16TB。

OST（Object Storage Target）：用户文件存储在一个或者多个对象中，每个对象对应一个

独立的OST，每个文件可以存储在一个OST 上，也可以跨越多个OST 进行存储。一个

OST 可以通过同时映射给两台主机实现OSS 的高可用性。

Lustre Client：Lustre 客户端是指装有Lustre 客户端软件并可以挂载Lustre 文件系统的计

算节点、虚拟化节点或者桌面节点。在高性能集群中，通常是计算节点、管理节点或登

陆节点。

图2-7 Lustre 组件组网示意图

文件存储

Lustre 文件系统使用FID（Lustre file identifiers）作为文件或者对象的标识。而文件数据

在OST 中存储位置的信息被存储在MDT 上，形式为FID 的一个扩展属性，称之为layout

EA（extended attribute）。

假设文件是一个数据文件（非目录和链接符），MDT 上存储着这个文件在OST 上的存

放位置。如果MDT 指向的是单个OST 对象，则整个数据文件都存储在这个OST 对象

上，如果MDT 文件指向多个对象，文件则被使用RAID0 的方式条带化到各个对象。如

下图所示，当一个客户端需要读写数据文件时，它首先需要从MDT 处获取layout EA

的信息，由layout EA 信息可以得知具体的数据被存放在哪些OST 上，然后即可是读写。

图2-8 Layout EA 存储示意图

Lustre 文件系统高性能的一个主要因素是它可以在多个OST 间通过round-robin 算法进

行基于数据的分段或者chunk 的条带化，用户可以为每个文件配置条带数目、大小、应

用于哪个OST。当访问单一文件时，条带化可以使文件系统的性能大于单个OST 的带

宽。条带化还用于单个OST 没有足够的空间存放整个文件时，使用多个OST 同时存储

数据。

举例说明文件在Lustre 中的存储方式，文件C 的stripe_size 比文件A 的stripe_size 大，

文件C 允许更多的数据存放在单个分条。文件A 的stripe_count 是3，即数据跨越三个

对象存储，文件B 和文件C 的stripe_count 是1。在第一次下发I/O 时，文件A 按stripe_size

被存放在了OST1、OST、OST3 上。第二次下发I/O 时，文件A、文件B、文件C、同

时写入，根据均衡算法，最终文件A 存储了两份到OST1 上，文件B 存储在了OST2 上，

文件C 存储在了OST3 上，而整体来看，OST1、OST2、OST3 存储的数据是一样多的。

图2-9 Lustre 文件存储示意图

由上面的例子也可以看出来，Lustre 文件系统中的文件大小不受限于单个OST 的大小，

文件可以被条带化，跨越多个对象（最多200 个）来进行存储，使用ldiskfs 时每个对象

最大可以到16TB，总文件大小最大可以达31.25PB，使用zfs 时可以最大到256PB，总

文件大小最大可以达8EB。

文件读写

在Lustre 文件系统中，一个文件读写主要经历以下流程：

l Lustre 客户端向MDT 发送file open 的请求；

l MDT 收到请求后查找存储这个文件的对象的layout EA 信息；

l MDT 将layout EA 信息通过FID 返回给Lustre 客户端；

l 客户端直接找到相应的OSS，并提交I/O 请求；

l OSS 找到对应的OST 进行文件读写，并返回给Lustre 客户端。

图2-10 Lustre 文件读写示意图

1.2 Lustre I/O性能特点与最佳实践

1 Lustre概述
Lustre是面向集群的存储架构，它是基于Linux平台的开源集群（并行）文件系统，提供与POSIX兼容的文件系统接口。Lustre两个最大特征是高扩展性和高性能，能够支持数万客户端系统、PB级存储容量、数百GB的聚合I/O吞吐量。Lustre是Scale-Out存储架构，借助强大的横向扩展能力，通过增加服务器即可方便扩展系统总存储容量和性能。Lustre的集群和并行架构，非常适合众多客户端并发进行大文件读写的场合，但目前对于小文件应用非常不适用，尤其是海量小文件应用LOSF（Lots Of Small Files）。Lustre广泛应用于各种环境，目前部署最多的为高性能计算HPC，世界超级计算机TOP 10中的70%，TOP 30中的50%，TOP 100中的40%均部署了Lustre。另外，Lustre在石油、天然气、制造、富媒体、金融等行业领域也被大量部署应用。

2 Lustre Stripe
Lustre采用对象存储技术，将大文件分片并以类似RAID0的方式分散存储在多个OST上，一个文件对应多个OST上的对象。Lustre系统中，每个文件对应MDT上的一个元数据文件，inode以扩展属性记录了数据分片布局信息，包括stripe_count（对象数）, stripe_size（分片大小）, stripe_offset（起始OST）以及每个OST对象信息。当客户数据端访问文件时，首先从MDS请求文件元数据并获得分片布局信息（stripe layout），然后直接与多个OST同时交互进行并发读写。Lustre这种数据分片策略，提高了多用户访问的并发度和聚合I/O带宽，这是Lustre获得高性能的主要因素。再者，Stripe还能够使得Lustre可以存储超大文件，突破单一OST对文件大小的限制。当然，数据分片策略同时也会带来负面影响，比如增加系统负载和数据风险。

Lustre的OST数量可以达到数千，但是出于复杂性、性能、实际存储需求等考虑，目前设计实现中将单个文件对象数限制为160个。对于EXT4后端文件系统，单个文件最大可达2TB，因此Lustre单个文件最大可以达到320TB。那么，Lustre如何在可用OST集合中选择合适的OST呢？目前有两种选择算法，即Round-Robin和随机加权算法，这两种算法调度的依据是，任意两个OST剩余存储容量相差是否超过20%的阈值。一般在系统使用之初，直接使用Round-Robin算法以顺序轮转方式选择OST，这种算法非常高效。随着文件数据量的增加，一旦达到20%的阈值，Lustre将启用随机加权算法选择OST。Lustre维护着一个剩余空间的优先列表，采用随机算法在此列表中选择OST，这种算法会产生开销并影响性能。如果任意两个OST剩余存储容量相差重新降到20%阈值之内，则重新启用Round-Robin算法选择OST。Lustre在创建文件时就按照分片模式并采用OST选择算法，预先创建好文件所需的OST对象。分片模式可以使用lfs setstripe进行设置，或者由系统自动选择缺省模式，文件目录会自动继承父目录的分片模式，但可以进行修改。数据写入后，文件分片模式就不能修改，新加入的OST只会参与新创建的文件目录OST选择调度。Lustre目前还没有实现OST存储空间的自动均衡，需要手工进行数据迁移复制达到均衡的效果。

Lustre缺省情况下，stripe_count = 1, stripe_size = 1MB, stripe_offset = -1，即每个文件仅包含一个OST对象，分片大小为1MB，起始OST由Lustre自动选择。实际上这种分片模式就是不对文件进行分片存储，显然不能满足许多应用的存储需求，实际应用时需要在分析数据特点、网络环境、访问行为的基础上进行适当配置。分片不是越多越好，在满足存储需求的前提下，应该使得OST对象数量尽可能少。应用lustre Stripe时，应该考虑如下因素：
（1）提供高带宽访问。Lustre文件分片并存储于多个OSS，对于单一大文件来说，它可以提供远大于单一OSS提供的聚合I/O带宽。在HPC环境中，成百上千的客户端会同时并发读写同一个文件，当文件很大时，分散与多个OSS能够获得非常高的聚合带宽。Lustre文件系统理论上可以提供2.5 TB/s的带宽，经过验证的带宽达到240 GB/s。当然对于小于1GB的文件来说，分片数量不宜多于4个，更多分片不会带来更高的性能提升，还会引入额外开销。对于小文件，文件大小本身可能小于分片大小，实际上是不作分片，对性能不会有提升。
（2）改善性能。如果聚合的客户端带宽超过单个OSS的带宽，文件分片存储策略可以充分利用聚合的OSS带宽，极大提高性能，为应用程序提供高速的数据读写访问。合理的分片数量可以估算，客户端聚合I/O带宽除以单个OSS I/O性能即可得到。
（3）提供超大容量文件。Lustre后端文件系统采用改进的EXT3文件系统（接近于EXT4），单个文件最大为2TB。如果不进行分片，则单个Lustre文件最大只能为2TB。Lustre目前分片最多可达到160个，因此文件最大可以达到320TB，这是容量是非常大的，基本上可以满足所有单一文件存储容量的需求。
（4）提高存储空间利用率。当Lustre剩余存储空间有限时，每个OSS的剩余空间也就更加有限，这时再写入一个的大文件至单一OSS很大可能会由于空间不足而失败。采用分片策略，写入单个OSS的对象容量会成倍减小，如果OSS数量选择合适，文件仍然可以写入Lustre系统。这使得Lustre存储空间利用更为充分，有效提高了利用率。
（5）增加负载。Stripe会导致额外的锁和网络操作消耗，比如stat, unlink，虽然这些操作可以并发执行，但仍会对性能产生影响。另外，分片多会造成服务器的开销。设想这样一个情形:Lustre中有100个OSS，100个客户端，100个文件，每个客户端访问一个文件。如果不分片，则每个客户端仅与一个OSS相互，可以进行顺序I/O读写。如果每个文件分成100片，则每个客户端都需要分别与100个OSS进行相交，并发访问时，OSS上的磁盘I/O为随机读写。这些都是额外的负载开销，一定程度上影响性能。
（6）增加风险。从概率的角度看，多个OSS发生故障的概率要高出单个OSS许多。文件分片存储于多个OSS上，一个分片不可用就会导致整个文件不可访问，即使其他分片仍然是完好的。因此，分片大大增加了数据发生丢失的风险，需要采用适当的措施进行保护，比如RAID5/6或者Failover。

3 Lustre I/O性能特征

（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。

4 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，也可以通过调整一些系统参数进行优化。
（1）禁用所有客户端LNET debug功能：缺省开启多种调试信息，sysctl -w lnet.debug=0，减少系统开销，但发生错误时将无LOG可询。
（2）增加客户端Dirty Cache大小：lctl set_param osc./*.max_dirty_mb=256，缺省为32MB，增大缓存将提升I/O性能，但数据丢失的风险也随之增大。
（3）增加RPC并行数量：echo 32 > /proc/fs/lustre/osc/*-OST000*/max_rpcs_in_flight，缺省为8，提升至32将提高数据和元数据性能。不利之处是如果服务器压力很大，可能反而会影响性能。
（4）控制Lustre striping：lfs setstripe -c 0/1/-1 /path/filename，如果OST对象数大于1，小文件性能会下降，因此将OST对象设置为1。
（5）客户端考虑使用本地锁：mount -t lustre -o localflock，如果确定多个进程从同一个客户端进行写文件，则可用localflock代替flock，减少发送到MDS的RPC数量。
（6）使用loopback mount文件：创建大Lustre文件，与loop设备关联并创建文件系统，然后将其作为文件系统进行mount。小文件作用其上，则原先大量的MDS元数据操作将转换为OSS读写操作，消除了元数据瓶颈，可以显著提高小文件性能。这种方法应用于scratch空间可行，但对于生产数据应该谨慎使用，因为Lustre目前工作在这种模式下还存在问题。操作方法如下：
dd if=/dev/zero of=/mnt/lustre/loopback/scratch bs=1048576 count=1024
losetup /dev/loop0 /mnt/lustre/loopback/scratch
mkfs -t ext4 /dev/loop0
mount /dev/loop0 /mnt/losf

5 Lustre I/O最佳实践
Lustre具有鲜明的I/O特点，并具有非常高的扩展性和大文件I/O性能。如果进行适当的配置和操作，Lustre则会展现更高的性能。下面给出一些Lustre I/O最佳实践，可根据实际应用情况择优实践。
（1）使用单进程读取完整的共享小文件，需要时传输数据至其他进程。
（2）使用单进程访问容量在(1MB, 1GB)之间的小文件，将文件OST对象数设为1。
（3）使用单进程访问大于1GB的中等文件，文件OST对象数不超过4个。
（4）远大于1GB的大文件OST对象数应设为＞4，这种文件不要采用顺序I/O或file-per-process的I/O访问模式。
（5）限制单个目录下的文件数量，包含大量小文件的目录stripe_count设置为1。
（6）小文件存放在单一OST上，单进程文件创建和读写性能会得到提高。
（7）包含大量小文件的目录存放在单一OST上，文件创建性能会提到极大提升。
（8）尽量避免频繁地打开和关闭文件。
（9）仅在必要时使用ls -l，它会与所有相关的OST交互，操作代价很大，尽可能使用ls和lfs find代替。
（10）考虑使用I/O中间件来改善性能，如ADIOS、HDF5、MPI-IO。