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

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

Amazon FSx for Lustre 性能

Amazon FSx for Lustre，建立在 Lustre，一种流行的高性能文件系统，它提供的横向扩展性能会随着文件系统的大小而线性提高。Lustre 文件系统可在多个文件服务器和磁盘之间水平扩展。这种扩展让每个客户端可以直接访问存储在每个磁盘上的数据，从而消除传统文件系统中存在的诸多瓶颈。Amazon FSx for Lustre 建立在 Lustre 可扩展的架构，可在大量客户机上支持高水平的性能。

Lustre 文件系统的工作原理 FSx

每个 FSx for Lustre 文件系统都由客户机与之通信的文件服务器和一组连接到存储数据的文件服务器的磁盘组成。每台文件服务器都使用快速内存缓存来增强最常访问数据的性能。此外，也可以为基于 HDD 的文件系统配置基于 SSD 的读取缓存，以便进一步增强最常访问数据的性能。当客户端访问存储在内存缓存或 SSD 缓存中的数据时，文件服务器无需从磁盘读取数据，这样便可降低延迟并增加您可以驱动的总吞吐量。下图阐明了写入操作、从磁盘提供的读取操作以及从内存缓存或 SSD 缓存提供的读取操作的路径。

FSx 用于 Lustre 性能架构。

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

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

聚合文件系统性能

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

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

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

HDD 存储选项的文件系统性能
部署类型 网络吞吐量（MBps/TiB 的存储空间或 SSD 缓存已配置） 网络 IOPS（预置存储的 IOPS/TiB） 缓存存储（预置存储的 RAM/TiB GiB） 每次文件操作的磁盘延迟（毫秒，P50） 磁盘吞吐量（MBps/TiB 的存储空间或 SSD 缓存已配置）

基准

突增

基准

突增
PERSISTENT-12
HDD 存储 40 375*

数万基准

数十万突增

 0.4 内存

元数据：亚毫秒

数据：个位数毫秒

 12

80（读取）

50（写入）
SSD 读取缓存

200

 1,900

200 SSD 缓存

数据：亚毫秒

 200

-
PERSISTENT-40
HDD 存储 150 1,300*

数万基准

数十万突增

 1.5

元数据：亚毫秒

数据：个位数毫秒

 40

250（读取）

150（写入）
SSD 读取缓存

750

6500

 200 SSD 缓存

数据：亚毫秒

 200

-
注意

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

注意

* 以下永久文件系统可 Amazon Web Services 区域 提供高达 MBps 每 TiB 530 个存储空间的网络爆发：非洲（开普敦）、亚太地区（香港）、亚太地区（大阪）、亚太地区（新加坡）、加拿大（中部）、欧洲（法兰克福）、欧洲（伦敦）、欧洲（米兰）、欧洲（斯德哥尔摩）、中东（巴林）、南美（圣保罗）、中国、和美国西部（洛杉矶）。

例如：聚合基准吞吐量和突增吞吐量

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

永久文件系统的存储容量为 4.8 TiB，每单位存储的吞吐量为 50 MBps TiB，其总基准磁盘吞吐量为 240 MBps ，突发磁盘吞吐量为 1.152。 GBps

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

文件系统存储布局

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

要查看构成文件系统的 MDT 的存储使用情况，请在装有文件系统的客户机上运行以下命令。 OSTs 

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 会自动将文件分散到各 OSTs 处，以确保所有存储服务器都能提供数据。通过配置如何在多个文件之间进行条带化处理，可以在文件级别应用相同的概念 OSTs。

条带化意味着可以将文件分成多个块，然后将其存储在不同的区块中。 OSTs当一个文件跨多个条带化时 OSTs，对该文件的读取或写入请求会分散在这些文件中 OSTs，从而增加应用程序可以驱动的总吞吐量或 IOPS。

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

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

  • 对于 2020 年 12 月 18 日之后创建的文件系统，默认布局为渐进式文件布局，在这种布局中，大小低于 1GiB 的文件存储在一个条带中，而更大的文件则会分配条带计数 5。

  • 对于 2023 年 8 月 25 日之后创建的文件系统，默认布局为 4 个组件的渐进式文件布局，如 渐进式文件布局 中所述。

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

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

lfs getstripe path/to/filename

此命令会报告文件的条带计数、条带大小和条带偏移量。条带计数是 OSTs 指文件被条带化的数量。条带大小是一个 OST 上存储的连续数据量。条带偏移量是文件被条带化的第一个 OST 的索引。

修改条带化配置

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

lfs setstripe filename --stripe-count number_of_OSTs

lfs setstripe 命令仅影响新文件的布局。您可以在创建文件前，用它来指定文件的布局。您也可以定义目录的布局。在目录上进行设置后，该布局将应用于添加到该目录的每个新文件，但不适用于现有文件。您创建的任何新子目录也会继承新布局，然后应用于您在该子目录中创建的任何新文件或目录。

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

在某些情况下，默认布局配置可能不是您工作负载的最优选择。例如，具有数十 OSTs 和大量多 GB 文件的文件系统如果将文件条带分成超过默认条带计数值 5，则性能可能会更高。 OSTs创建条带数量较低的大文件可能会导致 I/O 性能瓶颈，也可能 OSTs 导致数据填满。在这种情况下，您可以为这些文件创建一个条带计数更大的目录。

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

  • 允许多台服务器及其关联服务器在读取 OSTs 和写入大型文件时提供 IOPS、网络带宽和 CPU 资源，从而提高吞吐量。

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

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

没有适合所有使用案例的最优布局配置。有关文件布局的详细指南，请参阅 Lustre.org 文档中的 Managing File Layout (Striping) and Free Space。以下是一般准则：

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

  • 条带计数是您应针对支持大型文件的系统进行调整的布局参数。条带计数指定了将存放条带化文件块的 OST 卷的数量。例如，如果条带数为 2，条带大小为 1MiB，Lustre 将一个文件的 1MiB 块交替写入两个数据块。 OSTs

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

  • 为小文件设置较大的条带数量并不理想，因为对于某些操作 Lustre 需要网络往返布局中的每个 OST，即使文件太小而无法占用所有 OST 卷上的空间。

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

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

渐进式文件布局

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

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

lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname/directory

此命令设置了四个布局组件：

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

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

  • 第三个组件（-E 100G -c 16）表示大小不超过 100GiB 的文件的条带计数为 16。

  • 第四个组件（-E -1 -c 32）表示大于 100GiB 的文件的条带计数为 32。

重要

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

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

亚马逊上在 2023 年 8 月 25 日之后创建 FSx 的 Lustre 文件系统的默认 PFL 配置是使用以下命令设置的：

lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname

如果客户的工作负载对中型和大型文件具有高度并发访问权限，则客户可能会受益于这样的布局：在较小的尺寸下使用更多的条带，而 OSTs 对于最大的文件，则在所有条带上都采用条带化处理，如四部分示例布局所示。

监控性能和使用情况

Amazon f FSx or Lustre 每分钟都会向亚马逊发布每个磁盘（MDT 和 OST）的使用率指标。 CloudWatch

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

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

性能提示

使用 Amazon f FSx or Lustre 时，请记住以下性能提示。有关服务限制的信息，请参阅Amazon for Lust FSx re 的配额。

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

  • 请求模型 — 通过启用对文件系统的异步写入，待处理的写入操作会在异步写入 Amazon for Lustre 之前在 Amazon EC2 实例上 FSx 进行缓冲。异步写入通常具有较低的延迟。在执行异步写入时，内核使用额外内存进行缓存。启用同步写入功能的文件系统向 Amazon 发出 Lustre FSx 的同步请求。每项操作都要在客户和 Amazon FSx for Lustre 之间往返。

    注意

    您选择的请求模式需要权衡一致性（如果您使用多个 Amazon EC2 实例）和速度。

  • 限制目录大小 — 要在 Lustre 文件系统的 Persit FSx ent 2 上实现最佳元数据性能，请将每个目录的文件限制在 10 万以下。限制目录中的文件数可以减少文件系统在父目录上获取锁定所需的时间。

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

  • 建议调整客户端实例以获得最佳性能

    1. 对于内存超过 64 GiB 的客户端实例类型，我们建议应用以下调整：

      sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000
sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>

    2. 对于超过 64 个 vCPU 核心的客户端实例类型，我们建议应用以下调整：

      echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
            
# reload all kernel modules to apply the above two settings
sudo reboot

      挂载客户端后，需要应用以下调整：

      sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
sudo lctl set_param mdc.*.max_rpcs_in_flight=64
sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50

    请注意，已知 lctl set_param 重启后不会继续有效。由于无法从客户端侧永久设置这些参数，因此建议实施启动 cron 作业，使用推荐的调整来设置配置。

  • 工作负载平衡 OSTs — 在某些情况下，您的工作负载并不能推动文件系统所能提供的聚合吞吐量（ MBps 每 TiB 存储 200 个）。如果是，如果工作负载的 I/O 模式不平衡会影响性能，则可以使用 CloudWatch 指标进行故障排除。要确定这是否是造成这种情况的原因，请查看 Amazon FSx for Lustre 的最大 CloudWatch 指标。

    在某些情况下，此统计数据显示的负载等于或大于 240 MBps 的吞吐量（单个 1.2 TiB 的 A FSx mazon for Lustre 磁盘的吞吐容量）。在这种情况下，您的工作负载不会均匀分布在磁盘上。在这种情况下，您可以使用 lfs setstripe 命令修改工作负载最常访问的文件的条带化。为了获得最佳性能，请在 OSTs 构成您的所有文件系统中对吞吐量要求很高的文件进行条带化。

    如果您的文件是从数据存储库导入的，则可以采用另一种方法将高吞吐量文件均匀地分散在数据存储 OSTs库中。为此，您可以在创建下一个 Amazon FSx for Lustre 文件系统时修改该ImportedFileChunkSize参数。

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

  • Lustre 元数据 IOPS 客户端 — 如果您的文件系统指定了元数据配置，我们建议您安装 Lustre 2.15 客户端或 Lustre 使用以下操作系统版本之一的 2.12 客户端：亚马逊 Linux 2023；亚马逊 Linux 2；Red Hat/Rocky Linux 8.9、8.10 或 9.x；CentOS 8.9 或 8.10；带有 6.2、6.5 或 6.8 内核的 Ubuntu 22；或 Ubuntu 20。