本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon FSx for Lustre
Amazon FSx for Lustre 基于流行的高性能文件系统 Lustre 构建，可提供随文件系统大小线性增加的横向扩展性能。Lustre 文件系统横向扩展到多个文件服务器和磁盘。这种扩展使每个客户端可以直接访问存储在每个磁盘上的数据，从而消除了传统文件系统中存在的许多瓶颈。适用于 Lustre 的 Amazon FSx 建立在 Lustre 的可扩展架构之上，支持大量客户端的高水平性能。
FSx for Lustre 文件系统的工作原理
每个 FSx for Lustre 文件系统都由客户端与之通信的文件服务器和连接到每个文件服务器的一组磁盘组成，用于存储您的数据。每个文件服务器都使用快速的内存缓存来增强最常访问数据的性能。基于 HDD 的文件系统也可以配置基于 SSD 的读取缓存，以进一步增强最常访问数据的性能。当客户端访问存储在内存或 SSD 缓存中的数据时，文件服务器无需从磁盘读取数据，这样可以减少延迟并增加您可以驱动的总吞吐量。下图说明了写入操作、从磁盘提供的读取操作以及从内存或 SSD 缓存提供的读取操作的路径。
当您读取存储在文件服务器的内存或 SSD 缓存中的数据时，文件系统的性能由网络吞吐量决定。当您将数据写入文件系统时，或者当您读取未存储在内存缓存中的数据时，文件系统的性能由网络吞吐量和磁盘吞吐量中的较低者决定。
当您使用固态硬盘缓存配置 HDD Lustre 文件系统时，Amazon FSx 会创建一个 SSD 缓存，该缓存会自动调整为文件系统硬盘存储容量的 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 | |||||||
| HDDDD | 40 | 375* |
数十万 几十万 |
0.4 memory |
元数据：subms 数据：个位数 ms |
12 |
80（读取） 50（写入） |
| SSDDDD |
200 |
1,900 |
20S 缓存 |
数据：sub-ms |
200 |
- |
|
| 持久-40B | |||||||
| HDDDD | 150 | 1,300* |
数十万 几十万 |
1.5 |
元数据：subms 数据：个位数 ms |
40 |
250（读取） 150（写入） |
| SSDDDD |
750 |
6500 |
200 SSD cache |
数据：sub-ms |
200 |
- |
|
Scratct 2 文件系统在中国区域中不可用。
*以下为永久文件系统Amazon Web Services 区域每 TiB 存储提供高达 530 MB/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 上，从而增加您的应用程序可以驱动的总吞吐量或 IOPS。
以下是新的 Amazon FSx for Lustre 文件系统的默认布局。
对于 2020 年 12 月 18 日之前创建的 Amazon FSx for Lustre 文件系统，默认布局将条带数指定为 1。这意味着，除非指定不同的布局，否则使用标准 Linux 工具在 Amazon FSx for Lustre 中创建的每个文件都存储在单个磁盘上。
对于 2020 年 12 月 18 日之后创建的 Amazon FSx for Lustre 文件系统，默认布局是渐进式文件布局，其中大小低于 1GiB 的文件存储在一个条带中，而较大的文件分配的条带数为五个。
对于所有 Amazon FSx for Lustre 文件系统，无论其创建日期如何，从 Amazon S3 导入的文件都不使用默认布局，而是使用文件系统中的布局
ImportedFileChunkSize参数。S3 导入的文件大于ImportedFileChunkSize将存储在条带数为的多个 OS 上(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 和大量多 GB 文件的文件系统，通过将文件分条数超过五个 OST 的默认条带数值，可能会获得更高的性能。创建条带数较少的大文件可能会导致 I/O 性能瓶颈，还可能导致 OST 填满。在这种情况下，您可以为这些文件创建一个条带数更大的目录。
为大型文件（尤其是大小超过一千兆字节的文件）设置条带布局很重要，原因如下：
允许多个 OST 及其关联服务器在读取和写入大型文件时提供 IOPS、网络带宽和 CPU 资源，从而提高吞吐量。
降低一小部分 OST 成为限制整体工作负载性能的热点的可能性。
防止单个大文件填满 OST，这可能会导致磁盘已满错误。
没有适用于所有用例的单一最佳布局配置。有关文件布局的详细指南，请参阅管理文件布局（条带化）和可用空间
条纹布局对于大型文件最为重要，尤其是在文件大小通常为数百兆字节或以上的用例中。因此，新文件系统的默认布局为大小超过 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 parallel 发送请求，从而给文件系统增加大量的网络负载。
因此，对于任何随后可能附加数据的小型或中等长度的文件，请谨慎限制条带数。由于日志文件通常通过附加新记录而增长，因此 Amazon FSx for Lustre 会为在追加模式下创建的任何文件分配默认条带数 1，无论其父目录指定的默认条带配置如何。
在 2020 年 12 月 18 日之后创建的 Lustre 文件系统的 Amazon FSx 上的默认 PFL 配置是使用以下命令设置的：
lfs setstripe -E 1G -c 1 -E -1 -c 5/mountname
对于具有高度并发访问中型和大型文件的工作负载的客户，可能会受益于这样的布局：在较小的尺寸下使用更多条带，而在所有操作系统中对最大文件进行分条，如前面显示的三组件示例布局所示。
监控性能和使用量
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 发出 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）。如果是这样，您可以使用 CloudWatch 用于排除性能是否受到工作负载 I/O 模式不平衡影响的指标。要确定这是否是原因，请查看最大值 CloudWatch Amazon FSx for Lustre
在某些情况下，此统计数据显示负载等于或超过 240 Mbps 的吞吐量（用于 Lustre 磁盘的单个 1.2 TiB Amazon FSx 的吞吐容量）。在这种情况下，您的工作负载在磁盘上分布不均匀。如果出现这种情况，您可以使用
lfs setstripe命令修改您的工作负载最常访问的文件条带。为了获得最佳性能，请将具有高吞吐量要求的文件分条到构成文件系统的所有 OST 上。如果您的文件是从数据存储库导入的，则可以采用另一种方法将高吞吐量文件均匀地划分到操作系统中。要执行该操作，可修改
ImportedFileChunkSize为 Amazon FSx for Lustre 文件系统时，参数。例如，假设您的工作负载使用 7.0 TiB 文件系统（由 6x 1.17-TiB 操作系统组成），并且需要提高 2.4 GiB 文件的高吞吐量。在这种情况下，您可以设置
ImportedFileChunkSize值为(2.4 GiB / 6 OSTs) = 400 MiB这样您的文件就可以均匀地分布在文件系统的操作系统中。