Amazon FSx for Lustre 性能 - FSx for Lustre
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Amazon FSx for Lustre 性能

Amazon FSx for Lustre 基于流行的高性能文件系统 Lustre 构建,可提供随文件系统大小线性增加的横向扩展性能。Lustre 文件系统横向扩展多个文件服务器和磁盘。这种扩展使每个客户端可以直接访问存储在每个磁盘上的数据,以消除传统文件系统中存在的许多瓶颈。Amazon FSx for Lustre 基于 Lustre 的可扩展架构构建,以支持大量客户端的高水平性能。

Lustre 文件系统的 FSx 如何工作

每个 FSx for Lustre 文件系统包括客户端与之通信的文件服务器以及连接到存储数据的每个文件服务器的一组磁盘。每个文件服务器都使用快速的内存缓存来提高最频繁访问的数据的性能。还可以使用基于 SSD 的读缓存来配置基于 HDD 的文件系统,以进一步提高最常访问的数据的性能。当客户端访问存储在内存中或 SSD 缓存中的数据时,文件服务器无需从磁盘读取数据,这样可以减少延迟并增加可以驱动的总吞吐量。下图说明了写入操作、从磁盘提供的读取操作以及从内存中或 SSD 缓存提供的读操作的路径。


        FSx for Lustre 性能架构。

读取存储在文件服务器内存中或 SSD 缓存中的数据时,文件系统的性能取决于网络吞吐量。当您将数据写入文件系统时,或者读取未存储在内存中缓存中的数据时,文件系统的性能取决于网络吞吐量和磁盘吞吐量的较低。

当您配置带有 SSD 缓存的 HDD Lustre 文件系统时,Amazon FSx 会创建一个固态硬盘缓存,该缓存会自动调整到文件系统 HDD 存储容量的 20%。这样做可以为经常访问的文件提供亚毫秒级的延迟和更高的 IOPS。

聚合文件系统性能

Lustre 文件系统的 FSx 支持的吞吐量与其存储容量成正比。适用于 Lustre 文件系统的 Amazon FSx 可扩展到数百 GBP 的吞吐量和数百万 IOPS。Amazon FSx for Lustre 还支持从数千个计算实例中并发访问同一个文件或目录。这种访问能够从应用程序内存到存储的快速数据检查点,这是高性能计算 (HPC) 中的常见技术。创建文件系统后,您可以随时根据需要增加存储量和吞吐量容量。有关更多信息,请参阅 管理存储和吞吐量容量

FSx for Lustre 文件系统使用一种网络 I/O 积分机制,根据平均带宽使用率分配网络带宽,提供突发读取吞吐量。文件系统在其网络带宽使用率低于其基准限制时会积累积分,并能够在执行网络数据传输时使用这些积分。

下表显示了 FSx for Lustre 部署选项的性能。

硬盘存储选项的文件系统性能
部署类型 网络吞吐量(MB/s/TIB 的存储空间或 SSD 缓存预配置) 网络 IOPS(预配置的存储空间的 IOPS/TIB) 缓存存储空间(预置的 RAM /TiB 存储空间的 GiB) 每个文件操作的磁盘延迟(毫秒,P50) 磁盘吞吐量(MB/s/TIB 的存储空间或 SSD 缓存预配置)

基准

突增

基准

突增

持久性 12
HDD 存储 40 375*

数十万

几十万爆发

0.4 memory

元数据:Subms

数据:个位数 ms

12

80(阅读)

50(写)

SSD 读缓存

200

1,900

200 SSD 缓存

数据:Subms

200

-

持久性 40
HDD 存储 150 1,300*

数十万

几十万爆发

1.5

元数据:Subms

数据:个位数 ms

40

250(阅读)

150(写)

SSD 读缓存

750

6500

200 SSD cache

数据:Subms

200

-

注意

Scratch 2 文件系统在中国区域中不可用。

注意

* 以下内容中的持久性文件系统Amazon Web Services 区域每 TiB 存储提供高达 530 MB/s 的网络突增量:非洲(开普敦)、亚太地区(香港)、亚太地区(大阪)、亚太地区(新加坡)、加拿大(中部)、欧洲(伦敦)、欧洲(米兰)、欧洲(斯德哥尔摩)、中东(巴林)、南美洲(圣保罗)、中国和美国西部(洛杉矶)。

例如:汇总基准量和突增吞吐量

以下示例说明存储容量和磁盘吞吐量如何影响文件系统性能。

持久性文件系统的存储容量为 4.8 TiB 和每 TiB 吞吐量 50 MB/s,可提供 240 MB/s 的总基准磁盘吞吐量,突发磁盘吞吐量为 1.152 Gb/s。

无论文件系统大小如何,Amazon FSx for Lustre 都能为文件操作提供一致的亚毫秒级延迟。

文件系统存储布局

Lustre 中的所有文件数据都存储在名为对象存储目标(OST)。所有文件元数据(包括文件名、时间戳、权限等)都存储在名为元数据目标(MDT)。Amazon FSx for Lustre 文件系统由一个 MDT 和多个 OST 组成。每个 OST 的大小约为 1 到 2 TiB,具体取决于文件系统的部署类型。Amazon FSx for Lustre 将您的文件数据分布到构成文件系统的 OST 之间,以平衡存储容量与吞吐量和 IOPS 负载。

要查看构成文件系统的 MDT 和 OST 的存储使用情况,请从装载了文件系统的客户端运行以下命令。

lfs df -h mount/path

此命令的输出如下所示。

UUID bytes Used Available Use% Mounted on mountname-MDT0000_UUID 68.7G 5.4M 68.7G 0% /fsx[MDT:0] mountname-OST0000_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:0] mountname-OST0001_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:1] filesystem_summary: 2.2T 9.0M 2.2T 0% /fsx

在文件系统中对数据进行条带化

您可以通过文件条带化优化文件系统的吞吐量性能。Amazon FSx for Lustre 会自动在 OST 之间分布文件,以确保所有存储服务器提供数据。您可以通过配置文件在多个 OST 之间进行条带化的方式,在文件级应用相同的概念。

条带化意味着文件可以分成多个区块,然后在不同的 OST 之间存储。当一个文件跨多个 OST 条带化时,对该文件的读取或写入请求会分散在这些操作系统上,从而提高应用程序可以通过它驱动的总吞吐量或 IOPS。

以下是 Amazon FSx for Lustre 文件系统的默认布局。

  • 对于 2020 年 12 月 18 日之前创建的 Lustre 文件系统的 Amazon FSx,默认布局将条带计数指定为 1。这意味着,除非指定不同的布局,否则使用标准 Linux 工具在 Amazon FSx for Lustre 中创建的每个文件都存储在单个磁盘上。

  • 对于 2020 年 12 月 18 日之后创建的 Amazon FSx for Lustre 文件系统,默认布局是渐进式文件布局,其中大小小小于 1GiB 的文件存储在一个条带中,较大的文件被分配为 5 个条带计数。

  • 对于适用于 Lustre 文件系统的所有 Amazon FSx,无论其创建日期如何,从 Amazon S3 导入的文件都不使用默认布局,而是使用文件系统中的布局ImportedFileChunkSize参数。s3 导入的文件大于ImportedFileChunkSize将存储在多个 OST 上,条带计数为(FileSize / ImportedFileChunksize) + 1. 的默认值ImportedFileChunkSize是 1GiB。

您可以使用查看文件或目录的布局配置lfs getstripe命令。

lfs getstripe path/to/filename

此命令报告文件的条带计数、条带大小和条带偏移量。这些区域有:条纹计数是文件条带化了多少 OST。这些区域有:条纹大小是 OST 上存储了多少连续数据。这些区域有:条纹偏移量是文件条带化的第一个 OST 的索引。

修改条带化配置

文件的布局参数是在首次创建文件时设置的。使用lfs setstripe命令创建具有指定布局的新的空文件。

lfs setstripe filename --stripe-count number_of_OSTs

这些区域有:lfs setstripe命令只影响新文件的布局。在创建文件之前,使用它来指定文件的布局。您也可以为目录定义布局。在目录上设置后,该布局将应用于添加到该目录的每个新文件,但不应用于现有文件。您创建的任何新子目录也将继承新布局,然后将其应用于您在该子目录中创建的任何新文件或目录。

要修改现有文件的布局,请使用lfs migrate命令。此命令根据您在命令中指定的布局复制文件,以便分发其内容。例如,附加到或增加大小的文件不会更改条带计数,因此您必须迁移它们才能更改文件布局。另外,您也可以使用lfs setstripe命令来指定其布局,将原始内容复制到新文件中,然后重命名新文件以替换原始文件。

在某些情况下,默认布局配置不适合您的工作负载。例如,具有数十个 OST 和大量数千兆字节文件的文件系统可能会通过将文件分割在超过默认条带计数值五个 OST 的条带计数值之间,从而获得更高的性能。创建条带数较少的大文件可能会导致 I/O 性能瓶颈,还可能导致 OST 填满。在这种情况下,您可以为这些文件创建一个带数较大的目录。

为大文件(尤其是大小超过 GB 的文件)设置条带布局很重要,原因如下:

  • 通过允许多个 OST 及其关联的服务器在读取和写入大文件时贡献 IOPS、网络带宽和 CPU 资源,从而提高吞吐量。

  • 降低了一小部分 OST 成为限制总体工作负载性能的热点的可能性。

  • 防止单个大文件填充 OST,这可能会导致磁盘已满错误。

对于所有使用案例,没有单一的最佳布局配置。有关文件布局的详细指导,请参阅管理文件布局(条带化)和可用空间在 Lustre.org 文档中。以下是一般准则:

  • 条带布局对于大型文件来说最重要,尤其是对于文件通常大小达到数百兆字节或更大的用例。因此,新文件系统的默认布局为大小超过 1GiB 的文件分配 5 个条带计数。

  • 条带计数是应针对支持大文件的系统进行调整的布局参数。条带计数指定将保存条带文件块的 OST 卷的数量。例如,如果条带计数为 2,条带大小为 1MiB,Lustre 将备用 1MiB 文件块写入两个 OST 中的每个 OST。

  • 有效的条带计数是实际 OST 卷数和指定的条带计数值中的较小者。你可以使用特殊的条带计数值-1以表明应在所有 OST 卷上放置条带。

  • 为小文件设置较大的条带数并不是最佳的,因为对于某些操作,Lustre 要求对布局中的每个 OST 进行网络往返,即使文件太小,无法占用所有 OST 卷上的空间。

  • 您可以设置渐进式文件布局 (PFL),以允许文件的布局随大小而更改。PFL 配置可以简化管理具有大文件和小文件组合的文件系统,而无需为每个文件明确设置配置。有关更多信息,请参阅 渐进式文件布局

  • 默认情况下,条带大小为 1MiB。在特殊情况下,设置条带偏移量可能有用,但一般来说,最好不指定它并使用默认值。

渐进式文件布局

您可以为目录指定渐进式文件布局 (PFL) 配置,以便在填充大小文件之前为其指定不同的条带配置。例如,在将任何数据写入新文件系统之前,您可以在顶级目录上设置 PFL。

要指定 PFL 配置,请使用lfs setstripe命令-E用于为不同大小的文件指定布局组件的选项,例如以下命令:

lfs setstripe -E 100M -c 1 -E 10G -c8 -E -1 -c -1 /mountname/directory

此命令设置三个布局组件:

  • 第一个组件 (-E 100M -c 1) 表示大小不超过 100MiB 的文件的条带计数值为 1。

  • 第二个组件 (-E 10G -c8) 表示大小不超过 10GiB 的文件的条带计数为 8。

  • 第三个组成部分 (-E -1 -c -1) 表示大于 10GiB 的文件将在所有 OST 之间进行条带化。

重要

将数据追加到使用 PFL 布局创建的文件中将填充其所有布局组件。例如,使用上面显示的 3 组件命令,如果创建 1MIB 文件然后将数据添加到文件末尾,则该文件的布局将扩展为条带计数 -1,这意味着系统中的所有 OST。这并不意味着将数据写入每个 OST,但是诸如读取文件长度之类的操作将向每个 OST 并行发送请求,从而增加文件系统的大量网络负载。

因此,要小心限制随后可能会附加数据的任何中小文件的条带计数。由于日志文件通常会通过附加新记录而增长,所以 Amazon FSx for Lustre 会为在追加模式下创建的任何文件分配默认条带计数 1,而不管其父目录指定的默认条带配置如何。

在 2020 年 12 月 18 日之后创建的针对 Lustre 文件系统的 Amazon FSx 默认 PFL 配置可使用以下命令进行设置:

lfs setstripe -E 1G -c 1 -E -1 -c 5 /mountname

具有对中型和大型文件具有高度并发访问权限的工作负载的客户可能会受益于具有较小尺寸更多条带的布局以及对最大文件的所有 OST 进行条带化,如前面所示的三组件示例布局所示。

性能提示

在使用 Amazon FSx for Lustre 时,请记住以下性能提示。有关服务限制,请参阅配额.

  • 平均 I/O 大小— 由于 Amazon FSx for Lustre 是一个网络文件系统,因此每个文件操作都会在客户端和 Amazon FSx for Lustre 之间进行往返,造成小额延迟开销。由于这种每次操作的延迟,总吞吐量通常会随着平均 I/O 大小增加而增加,因为开销在大量数据之间分摊。

  • 请求模型— 通过启用对文件系统的异步写入,待处理的写入操作先在 Amazon EC2 实例上缓冲,然后才异步写入 Amazon FSx for Lustre。异步写入通常具有较低的延迟。在执行异步写入时,内核使用额外内存进行缓存。启用了同步写入的文件系统向 Amazon FSx 发出同步请求 for Lustre。每个操作都将在客户端和 Amazon FSx for Lustre 之间往返一次。

    注意

    您选择的请求模型将在一致性(如果您使用多个 Amazon EC2 实例)和速率之间进行取舍。

  • Amazon EC2 实例— 执行大量读取和写入操作的应用程序可能比不执行这些操作的应用程序需要更多的内存或计算容量。在为您的计算密集型工作负载启动 Amazon EC2 实例时,应选择具有您的应用程序需要的这些资源量的实例类型。Amazon FSx for Lustre 文件系统的性能特征不依赖于使用 Amazon EBS 优化的实例。

  • 在 OST 之间平衡工作负载— 在某些情况下,您的工作负载无法推动文件系统可以提供的总吞吐量(每 TiB 存储 200 MB/s)。如果是,您可以使用CloudWatch用于诊断性能是否受到工作负载 I/O 模式不平衡影响的指标。要确定这是否是原因,请查看最大值CloudWatchAmazon FSx for Lustre 的指标。

    在某些情况下,此统计数据显示的负载达到或超过 240 MBps 的吞吐量(Lustre 磁盘的单个 1.2-TiB Amazon FSx 的吞吐量)。在这种情况下,您的工作负载不会在磁盘上均匀分布。如果是这种情况,您可以使用lfs setstripe命令来修改工作负载最常访问的文件的条带化。为了获得最佳性能,请在构成文件系统的所有 OST 中划分具有高吞吐量要求的文件。

    如果您的文件是从数据存储库导入的,则可以采取另一种方法在 OST 之间均匀划分高吞吐量文件。要执行该操作,可修改ImportedFileChunkSize创建您的下一个 Amazon FSx for Lustre 文件系统时,请参数。

    例如,假设您的工作负载使用 7.0-TiB 文件系统(由 6x 1.17-TiB OST 组成),并且需要在 2.4-GiB 文件中实现高吞吐量。在此情况下,您可以设置ImportedFileChunkSize值为(2.4 GiB / 6 OSTs) = 400 MiB以便您的文件在文件系统的 OST 中均匀分布。