本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon FSx for Lustre 性能
Amazon FSx for Lustre 建立在广受欢迎的高性能文件系统 Lustre 之上，可提供横向扩展性能，该性能会随着文件系统的大小而线性提高。Lustre 文件系统可横向扩展到多个文件服务器和磁盘。这种扩展允许每个客户端直接访问存储在每个磁盘上的数据，从而消除了传统文件系统中存在的许多瓶颈。Amazon FSx for Lustre 建立在 Lustre 的可扩展架构之上，以支持大量客户端的高性能水平。
适用于 Lustre 文件系统的 FSx 的工作原理
每个 FSx for Lustre 文件系统都由客户端与之通信的文件服务器以及一组连接到每个文件服务器的磁盘组成，用于存储您的数据。每台文件服务器都使用快速的内存缓存来增强最常访问数据的性能。还可以为基于 HDD 的文件系统配置基于 SSD 的读取缓存，以进一步增强最常访问数据的性能。当客户端访问存储在内存或 SSD 缓存中的数据时，文件服务器无需从磁盘读取数据，这样可以减少延迟并增加您可以驱动的总吞吐量。下图说明了写入操作、从磁盘提供的读取操作以及从内存或 SSD 缓存中提供的读取操作的路径。
当您读取存储在文件服务器的内存或 SSD 缓存中的数据时，文件系统的性能由网络吞吐量决定。当您将数据写入文件系统或读取未存储在内存缓存中的数据时，文件系统的性能由网络吞吐量和磁盘吞吐量中的较低者决定。
当您预置带有 SSD 缓存的 HDD Lustre 文件系统时，Amazon FSx 会创建一个 SSD 缓存，其大小会自动调整为文件系统 HDD 存储容量的 20%。这样做会为经常访问的文件提供亚毫秒级的延迟和更高的 IOPS。
聚合文件系统性能
FSx for Lustre 文件系统支持的吞吐量与其存储容量成正比。适用于 Lustre 文件系统的 Amazon FSx 可扩展到数百 Gbps 的吞吐量和数百万次 IOPS。Amazon FSx for Lustre 还支持从数千个计算实例并行访问同一个文件或目录。这种访问可以快速检查从应用程序内存到存储的数据，这是高性能计算 (HPC) 中的常用技术。创建文件系统后，您可以随时根据需要增加存储量和吞吐容量。有关更多信息，请参阅管理存储和吞吐量容量：
FSx for Lustre 文件系统使用一种网络 I/O 积分机制，根据平均带宽使用率分配网络带宽，提供突增读吞吐量。文件系统在网络带宽使用率低于其基准限制时会积累积分，并能够在执行网络数据传输时使用这些积分。
下表显示了 FSx for Lustre 部署选项的设计性能。
HDD 存储选项的文件系统性能 | |||||||
|---|---|---|---|---|---|---|---|
| 部署类型 | 网络吞吐量（已配置 MB/s/TiB 的存储空间或 SSD 缓存） | 网络 IOPS（已配置存储的 IOPS/TiB） | 缓存存储空间（GiB 的 RAM/TiB 预置的存储空间） | 每个文件操作的磁盘延迟（毫秒，P50） | 磁盘吞吐量（已配置 Mbps/TiB 的存储空间或 SSD 缓存） | ||
基线 |
爆裂 |
基线 |
爆裂 |
||||
| 持续-12 | |||||||
| HDD 存储 | 40 | 375* |
数万 几万 |
0.4 memory |
元数据：sub-ms 数据：个位数 ms |
12 |
80（阅读） 50（写入） |
| SSD 读取缓存 |
200 |
1,900 |
200 SSD 缓存 |
数据：sub-ms |
200 |
- |
|
| 持续-40 | |||||||
| HDD 存储 | 150 | 1,300* |
数万 几万 |
1.5 |
元数据：sub-ms 数据：个位数 ms |
40 |
250（读取） 150（写入） |
| SSD 读取缓存 |
750 |
6500 |
200 SSD cache |
数据：sub-ms |
200 |
- |
|
Scratch 2 文件系统在中国区域中不可用。
*以下的持久文件系统Amazon Web Services 区域提供每TiB 5MB/s 的网络突增率：非洲（开普敦）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）、亚太地区（大阪）巴林）、南美（圣保罗）、中国和美国西部（洛杉矶）。
示例：聚合基准和突增吞吐量
以下示例说明了存储容量和磁盘吞吐量如何影响文件系统性能。
存储容量为 4.8 TiB、每单位存储的吞吐量为 50 MTiB /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 将您的文件数据分布在构成文件系统的各主机上，以平衡存储容量与吞吐量和 IOPS 负载。
要查看构成文件系统的 MDT 和 OST 的存储使用情况，请从安装了文件系统的客户端运行以下命令。
lfs df -hmount/path
此命令的输出如下所示。
UUID bytes Used Available Use% Mounted onmountname-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 日之前创建的 Amazon FSx for Lustre 文件系统，默认布局将条带数指定为一。这意味着，除非指定不同的布局，否则使用标准 Linux 工具在 Amazon FSx for Lustre 中创建的每个文件都存储在单个磁盘上。
对于 2020 年 12 月 18 日之后创建的 Amazon FSx for Lustre 文件系统，默认布局是渐进式文件布局，其中大小小于 1GiB 的文件存储在一个条带中，而为较大的文件分配的条带数为五个。
对于所有 Amazon FSx for Lustre 文件系统，无论其创建日期如何，从 Amazon S3 导入的文件都不使用默认布局，而是使用文件系统
ImportedFileChunkSize参数中的布局。大于的 S3 导入文件ImportedFileChunkSize将存储在条带数为的多个 OST 上(FileSize / ImportedFileChunksize) + 1。的默认值ImportedFileChunkSize为 1GiB。
您可以使用lfs getstripe命令查看文件或目录的布局配置。
lfs getstripepath/to/filename
此命令报告文件的条带数、条带大小和条带偏移量。条带数是指文件跨越多少个 OST。条带大小是 OST 上存储的连续数据量。条带偏移量是文件分条的第一个 OST 的索引。
修改您的条带配置
文件的布局参数是在首次创建文件时设置的。使用lfs setstripe命令创建一个新的空文件，并指定布局。
lfs setstripefilename--stripe-countnumber_of_OSTs
该lfs setstripe命令仅影响新文件的布局。在创建文件之前，使用它来指定文件的布局。您也可以为目录定义布局。在目录上设置后，该布局将应用于添加到该目录的每个新文件，但不应用于现有文件。您创建的任何新子目录也会继承新布局，然后该布局将应用于您在该子目录中创建的任何新文件或目录。
要修改现有文件的布局，请使用lfs migrate命令。此命令根据需要复制文件，以便根据您在命令中指定的布局分发其内容。例如，附加到文件或大小增加的文件不会更改条带数，因此您必须迁移它们才能更改文件布局。或者，您可以使用lfs setstripe命令创建新文件来指定其布局，将原始内容复制到新文件中，然后重命名新文件以替换原始文件。
在某些情况下，默认布局配置可能不适合您的工作负载。例如，具有数十个 OST 和大量数千兆字节文件的文件系统可能会通过在超过五个 OST 的默认条带数值上对文件进行条带化来获得更高的性能。创建条带数量少的大文件可能会导致 I/O 性能瓶颈，还可能导致 OST 占满。在这种情况下，您可以为这些文件创建一个条带数较大的目录。
为大文件（尤其是大于一千兆字节的文件）设置条带布局非常重要，原因如下：
允许多个 OST 及其关联服务器在读取和写入大型文件时提供 IOPS、网络带宽和 CPU 资源，从而提高吞吐量。
降低一小部分 OST 成为限制整体工作负载性能的热点的可能性。
防止单个大文件填满 OST，这可能会导致磁盘已满错误。
没有适用于所有用例的单一最佳布局配置。有关文件布局的详细指导，请参阅 Lu stre.org 文档中的管理文件布局（条带）和可用空间
条带布局对于大型文件最为重要，尤其是对于文件大小通常为数百兆字节或以上的用例。因此，新文件系统的默认布局为大小超过 1GiB 的文件分配了五条带化数。
条带数是您应该为支持大文件的系统调整的布局参数。条带数量指定了将容纳条带化文件区块的 OST 卷的数量。例如，如果条带数为 2，条带大小为 1MiB，Lustre 会将文件的 1MiB 备用区块写入两个 OST。
有效条带数量是实际的 OST 卷数和您指定的条带计数值中的较小者。您可以使用特殊条带计数值
-1来指示应在所有 OST 卷上放置条带。为小文件设置较大的条带数并不理想，因为对于某些操作，Lustre 需要网络往返布局中的每个 OST，即使文件太小而无法占用所有 OST 卷上的空间。
您可以设置渐进式文件布局 (PFL)，允许文件的布局随大小而变化。PFL 配置可以简化包含大文件和小文件组合的文件系统的管理，而无需为每个文件明确设置配置。有关更多信息，请参阅渐进式文件布局：
默认情况下，条带大小为 1MiB。在特殊情况下，设置条带偏移量可能很有用，但总的来说，最好不指定条带偏移量并使用默认值。
渐进式文件布局
您可以为目录指定渐进式文件布局 (PFL) 配置，以便在填充小文件和大型文件之前为其指定不同的条带配置。例如，在将任何数据写入新文件系统之前，可以在顶级目录上设置 PFL。
要指定 PFL 配置，请使用带有-E选项的lfs setstripe命令为不同大小的文件指定布局组件，例如以下命令：
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 布局创建的文件追加数据将填充其所有布局组件。例如，使用上面显示的三组件命令，如果您创建一个 1MiB 文件，然后在文件末尾添加数据，则该文件的布局将扩展为条带数为 -1，这意味着系统中的所有 OST。这并不意味着数据将写入每个 OST，但是诸如读取文件长度之类的操作会向每个 OST parallel 发送请求，从而给文件系统增加大量的网络负载。
因此，请谨慎限制随后可能附加数据的任何中小长度文件的条带数量。由于日志文件通常通过追加新记录而增长，因此 Amazon FSx for Lustre 会为在追加模式下创建的任何文件分配默认条带数 1，无论其父目录指定的默认条带配置如何。
2020 年 12 月 18 日之后创建的 Amazon FSx 上的 Lustre 文件系统的默认 PFL 配置是使用以下命令设置的：
lfs setstripe -E 1G -c 1 -E -1 -c 5/mountname
具有高并发访问中型和大型文件的工作负载的客户可能会受益于这样的布局，即在较小的尺寸下有更多条带，对于最大的文件，则在所有 OST 上进行条带化，如前面所示的四组件示例布局所示。
监控性能和使用情况
Amazon FSx for Lustre 每分钟都会向亚马逊发布每个磁盘（MDT 和 OST）的使用量指标 CloudWatch。
要查看汇总文件系统使用情况的详细信息，可以查看每个指标的总和统计数据。例如，DataReadBytes统计数据总和报告了文件系统中所有 OST 看到的总读取吞吐量。同样，FreeDataStorageCapacity统计数据总和报告文件系统中文件数据的总可用存储容量。
有关监控文件系统性能的更多信息，请参阅监控 Amazon FSx for Lustre。
性能提示
在使用 Amazon FSx for Lustre 时，请记住以下性能提示。有关服务限制，请参阅配额。
-
平均 I/O 大小 — 由于 Amazon FSx for Lustre 是一个网络文件系统，因此每个文件操作都要在客户端和 Amazon FSx for Lustre 之间往返，从而产生少量延迟开销。由于这种每次操作的延迟，总吞吐量通常会随着平均 I/O 大小增加而增加，因为开销在大量数据之间分摊。
-
请求模型 — 通过启用对文件系统的异步写入，待写入操作将在异步写入 Amazon FSx for Lustre 之前，先在 Amazon EC2 实例上缓冲这些操作。异步写入通常具有较低的延迟。在执行异步写入时，内核使用额外内存进行缓存。启用同步写入的文件系统向 Amazon FSx for Lustre 发出同步请求。每项操作都要在客户和 Amazon FSx for Lustre 之间往返。
注意 您选择的请求模型在一致性（如果您使用多个 Amazon EC2 实例）和速度方面需要权衡利弊。
-
Amazon EC2 实例 — 执行大量读写操作的应用程序可能比不执行大量读写操作的应用程序需要更多的内存或计算容量。为计算密集型工作负载启动 Amazon EC2 实例时，请选择具有应用程序所需资源量的实例类型。适用于 Lustre 文件系统的 Amazon FSx 的性能特征不依赖于 Amazon EBS 优化实例的使用。
-
针对大型客户机实例类型的建议调整
要调整大型客户端实例以获得最佳性能，请执行以下操作：
对于内存超过 64 GiB 的客户端实例类型，我们建议应用以下调整：
lctl set_param ldlm.namespaces.*.lru_max_age=600000对于超过 64 个 CPU 内核的客户端实例类型，我们建议应用以下调整：
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已知重启后不会持续下去。由于无法从客户端永久设置这些参数，因此建议实现 boot cron 作业，以使用推荐的调整设置配置。 -
各主机之间的工作负载平衡 — 在某些情况下，您的工作负载并未推动文件系统所能提供的总吞吐量（每 TiB 存储 200 MB/s）。如果是，如果工作负载的 I/O 模式不平衡会影响性能，则可以使用 CloudWatch 指标来排除故障。要确定这是否是原因，请查看 Amazon FSx for Lustre 的最大 CloudWatch 指标。
在某些情况下，此统计数据显示负载达到或超过 240 Mbps 的吞吐量（单个 1.2-TiB Amazon FSx for Lustre 磁盘的吞吐容量）。在这种情况下，您的工作负载不会均匀地分布在磁盘上。在这种情况下，您可以使用
lfs setstripe命令修改工作负载最常访问的文件的条带化。为了获得最佳性能，请在构成文件系统的所有 OST 上对具有高吞吐量要求的文件进行条带化。如果您的文件是从数据存储库导入的，则可以采用另一种方法在 OST 上均匀地分条高吞吐量文件。为此，您可以在创建下一个 Amazon FSx for Lustre 文件系统时修改
ImportedFileChunkSize参数。例如，假设您的工作负载使用 7.0-TiB 文件系统（由 6x 1.17-TiB OST 组成），需要在 2.4-GiB 文件上实现高吞吐量。在这种情况下，您可以将该
ImportedFileChunkSize值设置为，(2.4 GiB / 6 OSTs) = 400 MiB以便您的文件在文件系统的 OST 中均匀分布。