Amazon FSx for Lustre 性能 - Amazon FSx for Lustre
Amazon FSx for Lustre 文件系统的工作原理聚合文件系统性能文件系统存储布局文件系统中的数据条带化监控性能和使用情况性能提示
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

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

Amazon FSx for Lustre 性能

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

Amazon FSx for Lustre 文件系统的工作原理

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

Amazon FSx for Lustre 性能架构。

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

聚合文件系统性能

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

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

以下表格显示 Amazon FSx for Lustre 部署选项的性能。

硬盘存储选项的文件系统性能
部署类型 网络吞吐量（每 TiB 存储 MB/s 或 SSD 缓存） 网络 IOPS（预配置的每 TiB 存储 IOPS） 缓存存储（预配置的每 TiB 存储） 每个文件操作的磁盘延迟（毫秒，P50） 磁盘吞吐量（每 TiB 存储 MB/s 或 SSD 缓存）

Base

突增

Base

突增
持久性
HDD 存储 40 375*

几十万

几十万

 0.4 memory

元数据：子毫秒

数据：单位毫秒

 12

80（已读）

50 (写入)
SSD 读缓存

200

 1,900

200 SSD 高速缓存

数据：子毫秒

 200

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

几十万

几十万

 1.5 RAM

元数据：子毫秒

数据：单位毫秒

 40

250 (已读)

150 (写入)
SSD 读缓存

750

6500

 200 SSD cache

数据：子毫秒

 200

-
注意

临时 2 文件系统不在中国区域提供。

SSD 存储选项的文件系统性能
部署类型 网络吞吐量（每 TiB 预配的存储 MB/s） 网络 IOPS（预配置的每 TiB 存储 IOPS） 缓存存储（预配置的每 TiB 存储） 每个文件操作的磁盘延迟（毫秒，P50） 磁盘吞吐量（每 TiB 存储 MB/s 或 SSD 缓存）

Base

突增

Base

突增
划痕 _2 200 1300

几十万

几十万

 6.7 RAM

元数据：子毫秒

数据：子毫秒

200（已读）

100 (写入)

 –
持久性 250 1,300* 2.2 RAM 50

240
持久性 500 1,300* 4.4 RAM 100 240
持久性 750 1,300* 8.8 RAM 200 240
注意

* 以下内容中的持久文件系统Amazon每 TiB 存储 530 MB/s 的网络突增：非洲（开普敦）、亚太地区（香港）、亚太地区（新加坡）、加拿大（中部）、欧洲（法兰克福）、欧洲（伦敦）、欧洲（米兰）、欧洲（斯德哥尔摩）、中东（巴林）、南美洲（圣保罗）、中国和美国西部（洛杉矶）。

示例：聚合基线和突发吞吐量

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

持久文件系统的存储容量为 4.8 TiB，每存储单位吞吐量为 50 MB/s，可提供 234 MB/s 的聚合基准磁盘吞吐量和 1.125 Gb/s 的突发磁盘吞吐量。

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

文件系统存储布局

Lustre 中的所有文件数据都存储在名为对象存储目标(外层管制组织). 所有文件元数据（包括文件名、时间戳、权限等）都存储在名为元数据目标(多边发展中心). Amazon FSx the Lustre 文件系统由一个 MDT 和多个操作系统组成。每个 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 进行条带化时，对该文件的读取或写入请求将分布在这些 OST 之间，从而增加应用程序可以通过它驱动的聚合吞吐量或 IOPS。

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

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

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

  • 对于所有用 Amazon FSx for Lustre 文件系统，无论其创建日期如何，从 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 和大量多 GB 文件的文件系统可能会看到更高的性能，方法是将文件条带化到超过 5 个 OST 的默认条带计数值。创建具有较低条带计数的大文件可能会导致 I/O 性能瓶颈，并且还可能导致 OST 填满。在这种情况下，您可以为这些文件创建一个具有较大条带计数的目录。

为大型文件（特别是大于 GB 的文件）设置条带布局非常重要，原因如下：

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

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

  • 防止单个大文件填充 OST，从而可能导致磁盘已满错误。

对于所有使用案例，没有单一的最佳布局配置。有关文件布局的详细指导，请参阅管理文件布局（条带化）和可用空间在卢斯特雷 .org 文档中。以下是一般准则：

  • 条带布局对于大型文件来说最重要，特别是对于文件通常大小为数百兆字节或更多的用例。因此，新文件系统的默认布局会为大小超过 1GiB 的文件分配五个条带化计数。

  • 条带计数是针对支持大文件的系统应调整的布局参数。条带计数指定将保存条带文件块的 OST 卷的数量。例如，如果条带计数为 2，条带大小为 1miB，Lustre 会将文件的备用 1miB 块写入两个 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 to Lustre 会为在追加模式下创建的任何文件分配默认条带计数 1，而不考虑其父目录指定的默认条带配置。

使用以下命令设置 2020 年 12 月 18 日之后创建的 Lustre 文件系统的 Amazon FSX 上的默认 PFL 配置：

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

具有对中型和大型文件具有高度并发访问权限的客户很可能会受益于具有较小尺寸的更多条带和跨所有操作系统对最大文件进行条带化的布局，如前面所示的三组件示例布局所示。

监控性能和使用情况

每分钟，用 Amazon FSx for Lustre 都会向亚马 Amazon CloudWatch 发送每个磁盘（MDT 和 OST）的使用量指标。

要查看聚合文件系统使用情况详细信息，您可以查看每个度量的总和统计信息。例如，DataReadBytes统计信息报告文件系统中所有 OST 可见的总读取吞吐量。同样，FreeDataStorageCapacity统计信息报告文件系统中文件数据的总可用存储容量。

有关监视文件系统性能的更多信息，请参阅监控 Amazon FSx for Lustre。

性能提示

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

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

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

    注意

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

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

  • 操作系统间的工作负载平衡— 在某些情况下，您的工作负载不会驱动文件系统可以提供的聚合吞吐量（每 TiB 存储 200 MB/s）。如果是这样，您可以使用 CloudWatch 指标对性能是否受到工作负载 I/O 模式不平衡的影响进行故障排除。要确定这是否是原因，请查看适用于 Amazon FSx for Lustre 最大 CloudWatch 指标。

    在某些情况下，此统计数据显示负载达到或高于 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 中均匀分布。