本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon FSx for Lustre 性能 本章提供了 Amazon FSx for Lustre 性能主题，包括一些有关最大限度地提高文件系统性能的重要提示和建议。 **Topics** + [概述](#performance-overview) + [Lustre 文件系统的工作原理 FSx](#how-lustre-fs-work) + [文件系统元数据性能](#dne-metadata-performance) + [单个客户端实例的吞吐量](#throughput-clients) + [文件系统存储布局](#storage-layout) + [对文件系统中的数据进行条带化](#striping-data) + [监控性能和使用情况](#performance-monitoring) + [SSD 和 HDD 存储类别的性能特点](ssd-storage.md) + [Intelligent-Tiering 存储类别的性能特征](intelligent-tiering-file-systems.md) + [性能提示](performance-tips.md) ## 概述 Amazon FSx for Lustre 建立在流行的高性能文件系统之上Lustre，可提供随文件系统大小线性增加的横向扩展性能。 Lustre文件系统可在多个文件服务器和磁盘之间水平扩展。这种扩展让每个客户端可以直接访问存储在每个磁盘上的数据，从而消除传统文件系统中存在的诸多瓶颈。Amazon FSx for Lustre 建立在Lustre可扩展架构之上，可支持大量客户的高水平性能。 ## Lustre 文件系统的工作原理 FSx 每个 FSx for Lustre 文件系统都由客户机与之通信的文件服务器和一组连接到存储数据的文件服务器的磁盘组成。每台文件服务器都使用快速内存缓存来增强最常访问数据的性能。根据存储类别，可为文件服务器预置可选的 SSD 读取缓存。当客户端访问存储在内存缓存或 SSD 缓存中的数据时，文件服务器无需从磁盘读取数据，这样便可降低延迟并增加您可以驱动的总吞吐量。下图阐明了写入操作、从磁盘提供的读取操作以及从内存缓存或 SSD 缓存提供的读取操作的路径。 ![\[FSx 用于 Lustre 性能架构。\]](http://docs.aws.amazon.com/zh_cn/fsx/latest/LustreGuide/images/LustrePerfDiagram.png) 当读取存储在文件服务器的内存缓存或 SSD 缓存中的数据时，文件系统的性能取决于网络吞吐量。当将数据写入文件系统或读取未存储在内存缓存中的数据时，文件系统的性能取决于网络吞吐量和磁盘吞吐量中的较低者。 要详细了解网络吞吐量、磁盘吞吐量以及 SSD 和 HDD 存储类别的 IOPS 特性，请参阅 [SSD 和 HDD 存储类别的性能特点](ssd-storage.md) 和 [Intelligent-Tiering 存储类别的性能特征](intelligent-tiering-file-systems.md)。 ## 文件系统元数据性能 文件系统元数据的每秒 IO 操作数（IOPS）决定了每秒可创建、列出、读取和删除的文件和目录的数量。 Persistent 2 文件系统可让您独立于存储容量之外预置元数据 IOPS，并提高对文件系统上客户端实例驱动的元数据 IOPS 数量和类型的可见性。借助 SSD 文件系统，可根据预置的存储容量自动预置元数据 IOPS。Intelligent-Tiering 文件系统不支持自动模式。 FSx 对于 Lustre Persistent 2 文件系统，您预配置的元数据 IOPS 数量和元数据操作的类型决定了您的文件系统可以支持的元数据操作的速率。您预置的元数据 IOPS 级别决定了为文件系统的元数据磁盘预置的 IOPS 数。 | 操作类型 | 每秒可以为每个预置元数据 IOPS 执行的操作次数 | | --- | --- | | 文件创建、打开和关闭 | 2 | | 文件删除 | 1 | | 目录创建、重命名 | 0.1 | | 目录删除 | 0.2 | 对于 SSD 文件系统，可选择使用“自动”模式预置元数据 IOPS。在自动模式下，Amazon FSx 会根据您的文件系统的存储容量自动配置元数据 IOPS，如下表所示： | 文件系统存储容量 | 自动模式下包含的元数据 IOPS | | --- | --- | | 1200 GiB | 1500 | | 2400 GiB | 3000 | | 4800–9600 GiB | 6000 | | 12000–45600 GiB | 12000 | | ≥ 48000 GiB | 每 24000 GiB 有 12000 的 IOPS | 在“用户预置”模式下，可以选择指定要预置的元数据 IOPS 数。有效值如下所示： + 对于 SSD 文件系统，有效值为 `1500`、`3000`、`6000`、`12000` 和 `12000` 的倍数，最大值为 `192000`。 + 对于 Intelligent-Tiering 文件系统，有效值为 `6000` 和 `12000`。 有关如何配置元数据 IOPS 的信息，请参阅 [管理元数据性能](managing-metadata-performance.md)。请注意，您需要为预置元数据 IOPS 数超出文件系统默认元数据 IOPS 数的部分付费。 ## 单个客户端实例的吞吐量 如果您要创建吞吐容量超过 10 GBps % 的文件系统，我们建议您启用 Elastic Fabric Adapter (EFA) 以优化每个客户端实例的吞吐量。为了进一步优化每个客户端实例的吞吐量，启用 EFA 的文件系统还支持支持 EFA 的 NVIDIA 基于 GPU 的客户端实例的 GPUDirect 存储，以及支持 ENA Express 的客户端实例的 ENA Express。 可以驱动到单个客户端实例的吞吐量取决于所选择的文件系统类型和客户端实例上的网络接口。 | 文件系统类型 | 客户端实例网络接口 | 每个客户端最大吞吐量，以 Gbps 计 | | --- | --- | --- | | 非启用 EFA 的文件系统 | 任何 | 100Gbps\$1 | | 启用 EFA 的文件系统 | ENA | 100Gbps\$1 | | 启用 EFA 的文件系统 | ENA Express | 100 Gbps | | 启用 EFA 的文件系统 | EFA | 700 Gbps | | 启用 EFA 的文件系统 | 使用 GDS 的 EFA | 1200 Gbps | **注意** \$1 Lustre 对象存储服务器的单个 FSx 客户端实例和个人客户端实例之间的流量限制为 5 Gbps。有关支持 f [文件系统的 IP 地址](using-fsx-lustre.md#ip-addesses-for-fs) or Lustre 文件系统的对象存储服务器 FSx 的数量，请参阅。 ## 文件系统存储布局 中的所有文件数据Lustre都存储在名为*对象存储目标 (OSTs) 的存储*卷上。所有文件元数据（包括文件名、时间戳、权限等）都存储在名为*元数据目标* (MDTs) 的存储卷上。Amazon f FSx or Lustre 文件系统由一个或多个 MDTs 和多个 OSTs文件系统组成。Amazon FSx for Lustre 将您的文件数据分散到 OSTs 构成您的文件系统的各个部分，以平衡存储容量与吞吐量和 IOPS 负载。 要查看构成文件系统的 MDT 的存储使用情况，请在装有文件系统的客户机上运行以下命令。 OSTs ``` lfs df -h mount/path ``` 此命令的输出如下所示。 **Example** ``` 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 个组件的渐进式文件布局，如 [渐进式文件布局](#striping-pfl) 中所述。 + 对于所有文件系统，无论其创建日期如何，从 Amazon S3 导入的文件都不使用默认布局，而是使用文件系统 `ImportedFileChunkSize` 参数中的布局。大于 s3 的导入文件`ImportedFileChunkSize`将存储在多个文件中，条 OSTs带计数为。`(FileSize / ImportedFileChunksize) + 1``ImportedFileChunkSize` 的默认值为 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](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace)。以下是一般准则： + 条带化布局对大型文件最为重要，特别是对于文件大小通常为数百兆字节或以上的使用案例。因此，新文件系统的默认布局会为大小超过 1GiB 的文件分配的条带计数为 5。 + 条带计数是您应针对支持大型文件的系统进行调整的布局参数。条带计数指定了将存放条带化文件块的 OST 卷的数量。例如，如果条带计数为 2，条带大小为 1MiB，则将文件的 1MiB 交替区块Lustre写入两个区块中。 OSTs + 有效条带计数是 OST 卷的实际数量和您指定条带计数值中的较小者。您可以使用特殊条带计数值 `-1` 来表示应在所有 OST 卷上放置条带。 + 为小文件设置较大的条带计数并不是理想做法，因为对于某些操作，Lustre 需要网络往返布局中的每个 OST，即使文件非常小，无法占用所有 OST 卷上的空间。 + 您可以设置渐进式文件布局（PFL），允许文件布局随大小变化。PFL 配置可以简化对具有大文件和小文件的文件系统的管理，而无需为每个文件明确设置配置。有关更多信息，请参阅 [渐进式文件布局](#striping-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 文件系统](monitoring_overview.md)。 # SSD 和 HDD 存储类别的性能特点 配置了 SSD 或 HDD 存储等级的 for Lustre 文件系统所支持的吞吐量与其存储容量成正比。 FSx Amazon f FSx or Lustre 文件系统可扩展到吞吐 TBps量的倍数和数百万的 IOPS。Amazon FSx for Lustre 还支持从数千个计算实例同时访问同一个文件或目录。这种访问可以实现从应用程序内存到存储的快速数据检查点，这是高性能计算（HPC）中的常用技术。创建文件系统后，您可以根据需要，随时增加存储容量和吞吐能力。有关更多信息，请参阅 [管理存储容量](managing-storage-capacity.md)。 FSx for Lustre 文件系统使用网络 I/O 信用机制提供突发读取吞吐量，根据平均带宽利用率分配网络带宽。文件系统在网络带宽低于其基准限制时会积累积分，并能够在执行网络数据传输时使用这些积分。 下表显示了使用 SSD 和 HDD 存储类别的 for Lustre 部署选项的设计性能。 FSx **SSD 存储选项的文件系统性能** | 部署类型 | **网络吞吐量（MBps/TiB 预配置的存储空间）** | **网络 IOPS（预置存储的 IOPS/TiB）** | **缓存存储空间（预配置 GiB RAM/TiB 的存储空间）** | **每次文件操作的磁盘延迟（毫秒，P50）** | **磁盘吞吐量（MBps/TiB 的存储空间或 SSD 缓存已配置）** | | --- |--- |--- |--- |--- |--- | | **** | **基准** | **突增** | **** | **** | **** | **基准** | **突增** | | --- |--- |--- |--- |--- |--- |--- |--- | | SCRATCH\$12 | 200 | 1300 | 数万基准数十万突增 | 6.7 | 元数据：亚毫秒 数据：亚毫秒 | 200（读取） 100（写入） | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-125 | 320 | 1300 | 3.4 | 125 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTENT-250 | 640 | 1300 | 6.8 | 250 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTENT-500 | 1300 | ‐ | 13.7 | 500 | ‐ | | --- |--- |--- |--- |--- |--- | | PERSISTENT-1000 | 2600 | ‐ | 27.3 | 1000 | ‐ | | --- |--- |--- |--- |--- |--- | **HDD 存储选项的文件系统性能** | 部署类型 | **网络吞吐量（MBps/TiB 的存储空间或 SSD 缓存已配置）** | **网络 IOPS（预置存储的 IOPS/TiB）** | **缓存存储空间（预配置 GiB RAM/TiB 的存储空间）** | **每次文件操作的磁盘延迟（毫秒，P50）** | **磁盘吞吐量（MBps/TiB 的存储空间或 SSD 缓存已配置）** | | --- |--- |--- |--- |--- |--- | | **** | **基准** | **突增** | | **基准** | **突增** | | --- |--- |--- |--- |--- |--- | | PERSISTENT-12 | | --- | | HDD 存储 | 40 | 375\$1 | 数万基准 数十万突增 | 0.4 内存 | 元数据：亚毫秒 数据：个位数毫秒 | 12 | 80（读取） 50（写入） | | --- |--- |--- |--- |--- |--- |--- |--- | | SSD 读取缓存 | 200 | 1,900 | 200 SSD 缓存 | 数据：亚毫秒 | 200 | - | | --- |--- |--- |--- |--- |--- |--- | | PERSISTENT-40 | | --- | | HDD 存储 | 150 | 1,300\$1 | 数万基准 数十万突增 | 1.5 | 元数据：亚毫秒 数据：个位数毫秒 | 40 | 250（读取） 150（写入） | | --- |--- |--- |--- |--- |--- |--- |--- | | SSD 读取缓存 | 750 | 6500 | 200 SSD 缓存 | 数据：亚毫秒 | 200 | - | | --- |--- |--- |--- |--- |--- |--- | **上一代 SSD 存储选项的文件系统性能** | 部署类型 | **网络吞吐量（MBps 每 TiB 的预配置存储）** | **网络 IOPS（预置存储的 IOPS/TiB）** | **缓存存储（预置存储的 GiB/TiB）** | **每次文件操作的磁盘延迟（毫秒，P50）** | **磁盘吞吐量（MBps 每 TiB 的存储空间或预配置 SSD 缓存）** | | --- |--- |--- |--- |--- |--- | | **** | **基准** | **突增** | **** | **** | **** | **基准** | **突增** | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-50 | 250 | 1,300\$1 | 数万基准数十万突增 | 2.2 RAM | 元数据：亚毫秒 数据：亚毫秒 | 50 | 240 | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-100 | 500 | 1,300\$1 | 4.4 内存 | 100 | 240 | | --- |--- |--- |--- |--- |--- | | PERSISTENT-200 | 750 | 1,300\$1 | 8.8 RAM | 200 | 240 | | --- |--- |--- |--- |--- |--- | **注意** \$1 以下永久文件系统可 AWS 区域 提供高达 MBps 每 TiB 530 个存储空间的网络爆发：非洲（开普敦）、亚太地区（香港）、亚太地区（大阪）、亚太地区（新加坡）、加拿大（中部）、欧洲（法兰克福）、欧洲（伦敦）、欧洲（米兰）、欧洲（斯德哥尔摩）、中东（巴林）、南美（圣保罗）、中国、和美国西部（洛杉矶）。 ## 例如：聚合基准吞吐量和突增吞吐量 以下示例说明了存储容量和磁盘吞吐量对文件系统性能的影响。 永久文件系统的存储容量为 4.8 TiB，每单位存储的吞吐量为 50 MBps TiB，其总基准磁盘吞吐量为 240 MBps ，突发磁盘吞吐量为 1.152。 GBps 无论文件系统大小如何，Amazon f FSx or Lustre 都为文件操作提供一致的亚毫秒级延迟。 # Intelligent-Tiering 存储类别的性能特征 f FSx or Lustre Intelligent-Tiering 存储类为传统上在基于 HDD/SDD 的混合型高性能文件存储文件系统上运行的工作负载提供弹性、成本优化的存储。使用 Intelligent-Tiering 存储类别的文件系统利用完全弹性、智能分层、区域存储，该存储会随着工作负载的变化而自动增长和缩小，以适应工作负载。有关如何对数据进行分层的信息，请参阅 [Intelligent-Tiering 存储类别如何分层数据](using-fsx-lustre.md#how-INT-tiering-works)。 具有智能分层存储类别 FSx 的 for Lustre 文件系统所支持的吞吐量与其存储无关。智能分层文件系统可扩展到吞吐量的倍数和数百万 TBps 的 IOPS。使用 Intelligent-Tiering 存储类别的文件系统还提供可选的预置 SSD 读取缓存，以实现对频繁访问数据的低延迟访问。默认情况下，Amazon f FSx or Lustre 会为经常访问的元数据预置 SSD 读取缓存。由于大多数工作负载通常为读取密集型，且在任意时刻仅对整体数据集的一小部分子集进行活跃操作，Intelligent-Tiering 存储与 SSD 读取缓存的混合模型使采用 Intelligent-Tiering 存储类别的文件系统能够为多数工作负载提供媲美 SSD 文件系统的性能表现，同时相较于 SSD 和 HDD 存储类别实现显著的存储成本节约。 在 Intelligent-Tiering 文件系统中读取和写入数据，尤其是近期访问过的数据或访问频率不足以存放在文件服务器内存缓存的数据，性能取决于 SSD 读取缓存的大小。从 Intelligent-Tiering 存储进行数据访问的 time-to-first-byte延迟约为数十毫秒，而且每个请求的成本也很高，而从固态硬盘读取缓存进行访问的延迟为亚毫秒，并且没有每个请求的成本。 在为文件系统配置 SSD 读取缓存的大小时，应考虑工作负载中频繁访问的数据集大小，以及工作负载对较少访问数据读取延迟增高的敏感度。创建文件系统后，您可以在 SSD 读取缓存大小调整模式之间切换，并向上或向下扩展缓存。有关如何修改 SSD 读取缓存的更多信息，请参阅 [管理预置的 SSD 读取缓存](managing-ssd-read-cache.md)。 当 FSx for Lustre 将数据块写入智能分层存储时，就会出现写入请求。将数据写入文件系统时，写入请求会被聚合并写入 Intelligent-Tiering 存储，从而提高吞吐量并降低请求成本。读取可以从文件服务器的内存缓存、SSD 读取缓存或直接从 Intelligent-Tiering 存储中提供。当从 Intelligent-Tiering 存储中进行读取时，每个检索到的数据块都会发出读取请求。当您按顺序读取数据时，for Lustre 将预取数据 FSx 以提高性能。 使用 Intelligent-Tiering 存储类别的文件系统中，内存缓存的数据将作为*网络 I/O* 直接提供给请求客户端。当客户端访问未存储在内存缓存中的数据时，这些数据将作为*磁盘 I/O* 从 SSD 读取缓存或 Int-Tiering 存储读取，然后作为网络 I/O 提供给客户端。 ## Intelligent-Tiering 的文件系统性能 下表显示了 Lustre Intelligent-Tiering 文件系统所设计的性能。 FSx | 预配置吞吐容量 () MBps | **网络吞吐量 (MBps)** | **网络 IOPS** | **内存缓存存储空间（GB）** | **最大 SSD 缓存磁盘吞吐量 (MBps)** | **最大 SSD 缓存磁盘 IOPS** | | --- |--- |--- |--- |--- |--- | | **** | **基准** | **突增** | **** | **** | **** | **基准** | **突增** | | --- |--- |--- |--- |--- |--- |--- |--- | | 每 4000 | 12500 | ‐ | 数十万 | 76.8 | 4000 | 160000 | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | # 性能提示 使用 Amazon f FSx or Lustre 时，请记住以下性能提示。有关服务限制的信息，请参阅[Amazon for Lustre FSx 的服务配额](limits.md)。 + **平均 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> ``` 1. 对于超过 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 ``` 1. 要优化目录列表 (ls) 的性能，需要进行以下调整： ``` sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi ``` 请注意，已知 `lctl set_param` 重启后不会继续有效。由于无法从客户端侧永久设置这些参数，因此建议实施启动 cron 作业，使用推荐的调整来设置配置。 + **工作负载平衡 OSTs** — 在某些情况下，您的工作负载并不能推动文件系统所能提供的聚合吞吐量（ MBps 每 TiB 存储 200 个）。如果是这样，您可以使用 CloudWatch 指标来排除性能是否受到工作负载 I/O 模式不平衡的影响。要确定这是否是造成这种情况的原因，请查看 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 Linux 8.9、8.10 或 9. Hat/Rocky x；CentOS 8.9 或 8.10；带有 6.2、6.5 或 6.8 内核的 Ubuntu 22\$1；或 Ubuntu 20。 ## Intelligent-Tiering 性能注意事项 以下是使用 Intelligent-Tiering 存储类别处理文件系统时一些重要的性能注意事项： + 由于智能分层存储层的延迟更高，读取较小 I/O 大小数据的工作负载需要更高的并发性，并且需要更多的请求成本才能实现与使用大容 I/O 量的工作负载相同的吞吐量。我们建议将 SSD 读取缓存配置得足够大，以便在处理较小的 IO 大小时支持更高的并发性和吞吐量。 + 客户端使用 Intelligent-Tiering 文件系统所能达到的最大磁盘 IOPS 值，取决于工作负载的具体访问模式以及是否预置 SSD 读取缓存。对于具有随机访问权限的工作负载，如果数据缓存在 SSD 读取缓存中，客户端通常能实现远高于未缓存数据的 IOPS 性能。 + Intelligent-Tiering 存储类别支持预读功能，以优化顺序读取请求的性能。我们建议尽可能按顺序配置数据访问模式，以便预取数据并提升性能。