本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Amazon FSx for Lustre 性能
Amazon FSx for Lustre 基于热门高性能文件系统 Lustre 构建,可提供随文件系统大小线性增加的横向扩展性能。Lustre 文件系统可跨多个文件服务器和磁盘横向扩展。这种扩展让每个客户端可以直接访问存储在每个磁盘上的数据,从而消除传统文件系统中存在的诸多瓶颈。Amazon FSx for Lustre 建立在 Lustre 的可扩展架构之上,可支持大量客户端获得高水平性能。
FSx for Lustre 文件系统的工作原理
每个 FSx for Lustre 文件系统都由与客户机通信的文件服务器和一组连接到每个存储数据的文件服务器的磁盘组成。每台文件服务器都使用快速内存缓存来增强最常访问数据的性能。此外,也可以为基于 HDD 的文件系统配置基于 SSD 的读取缓存,以便进一步增强最常访问数据的性能。当客户端访问存储在内存缓存或 SSD 缓存中的数据时,文件服务器无需从磁盘读取数据,这样便可降低延迟并增加您可以驱动的总吞吐量。下图阐明了写入操作、从磁盘提供的读取操作以及从内存缓存或 SSD 缓存提供的读取操作的路径。
当读取存储在文件服务器的内存缓存或 SSD 缓存中的数据时,文件系统的性能取决于网络吞吐量。当将数据写入文件系统或读取未存储在内存缓存中的数据时,文件系统的性能取决于网络吞吐量和磁盘吞吐量中的较低者。
当为 HDD Lustre 文件系统配置 SSD 缓存时,Amazon FSx 会创建一个自动调整为文件系统 HDD 存储容量的 20% 的 SSD 缓存。这样做可以为经常访问的文件提供亚毫秒级延迟和更高的 IOPS。
聚合文件系统性能
FSx for Lustre 文件系统支持的吞吐量与其存储容量成正比。Amazon FSx for Lustre 文件系统可扩展至数百 GBps 的吞吐量和数百万的 IOPS。Amazon FSx for Lustre 还支持从数千个计算实例并行访问同一个文件或目录。这种访问可以实现从应用程序内存到存储的快速数据检查点,这是高性能计算(HPC)中的常用技术。创建文件系统后,您可以根据需要,随时增加存储容量和吞吐能力。有关更多信息,请参阅 管理存储容量。
FSx for Lustre 文件系统使用网络 I/O 积分机制,根据平均带宽利用率分配网络带宽,提供突增读取吞吐量。文件系统在网络带宽低于其基准限制时会积累积分,并能够在执行网络数据传输时使用这些积分。
下表显示了 FSx for Lustre 部署选项的设计性能。
HDD 存储选项的文件系统性能 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
部署类型 | 网络吞吐量(预置存储或 SSD 缓存的 MB/s/TiB) | 网络 IOPS(预置存储的 IOPS/TiB) | 缓存存储(预置存储的 RAM/TiB GiB) | 每次文件操作的磁盘延迟(毫秒,P50) | 磁盘吞吐量(预置存储或 SSD 缓存的 MBps/TiB) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
基准 |
突增 |
基准 |
突增 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PERSISTENT-12 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
HDD 存储 | 40 | 375* |
数万基准 数十万突增 |
0.4 memory |
元数据:亚毫秒 数据:个位数毫秒 |
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 cache |
数据:亚毫秒 |
200 |
- |
注意
Scratch 2 文件系统在中国区域中不可用。
注意
*以下 Amazon Web Services 区域的持久性文件系统提供高达每 TiB 存储 530 MB/s 的网络突增:非洲(开普敦)、亚太地区(香港)、亚太地区(大阪)、亚太地区(新加坡)、加拿大(中部)、欧洲地区(法兰克福)、欧洲地区(伦敦)、欧洲地区(米兰)、欧洲地区(斯德哥尔摩)、中东(巴林)、南美洲(圣保罗)、中国和美国西部(洛杉矶)。
例如:聚合基准吞吐量和突增吞吐量
以下示例说明了存储容量和磁盘吞吐量对文件系统性能的影响。
存储容量为 4.8 TiB,每单位存储的吞吐量为 50 MB/s/TiB 的持久性文件系统的聚合基准磁盘吞吐量为 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 将您的文件数据分散到构成文件系统的 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 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
,将存储在多个 OST 上,条带计数为(FileSize / ImportedFileChunksize) + 1
。ImportedFileChunkSize
的默认值为 1GiB。
您可以使用 lfs getstripe
命令查看文件或目录的布局配置。
lfs getstripe
path/to/filename
此命令会报告文件的条带计数、条带大小和条带偏移量。条带计数是文件在多少个 OST 上被条带化。条带大小是一个 OST 上存储的连续数据量。条带偏移量是文件被条带化的第一个 OST 的索引。
修改条带化配置
文件的布局参数是在首次创建文件时设置的。使用 lfs setstripe
命令创建新的空文件,并指定布局。
lfs setstripe
filename
--stripe-countnumber_of_OSTs
lfs setstripe
命令仅影响新文件的布局。您可以在创建文件前,用它来指定文件的布局。您也可以定义目录的布局。在目录上进行设置后,该布局将应用于添加到该目录的每个新文件,但不适用于现有文件。您创建的任何新子目录也会继承新布局,然后应用于您在该子目录中创建的任何新文件或目录。
要修改现有文件的布局,请使用 lfs migrate
命令。此命令按需复制文件,以便根据您在命令中指定的布局分发其内容。例如,追加的文件或大小增加的文件不会更改条带计数,因此您必须迁移这类文件才能更改文件布局。或者,您可以使用 lfs setstripe
命令创建新文件以指定其布局,将原始内容复制到新文件中,然后重命名新文件以替换原始文件。
在某些情况下,默认布局配置可能不是您工作负载的最优选择。例如,对于具有数十个 OST 和大量数 GB 文件的文件系统,如果将文件分成超过默认条带计数值(五个 OST)的条带,则性能可能会更高。创建条带计数低的大文件可能会导致 I/O 性能瓶颈,还可能会导致 OST 填满。在这种情况下,您可以为这些文件创建一个条带计数更大的目录。
为大型文件(尤其是大于 1 GB 的文件)设置条带化布局非常重要,原因如下:
通过允许多个 OST 及其关联服务器在读取和写入大型文件时提供 IOPS、网络带宽和 CPU 资源,提高吞吐量。
降低一小部分 OST 成为限制整体工作负载性能的热点的可能性。
防止单个大文件填满 OST,从而导致磁盘已满错误。
没有适合所有使用案例的最优布局配置。有关文件布局的详细指南,请参阅 Lustre.org 文档中的 Managing File Layout (Striping) and Free Space
条带化布局对大型文件最为重要,特别是对于文件大小通常为数百兆字节或以上的使用案例。因此,新文件系统的默认布局会为大小超过 1GiB 的文件分配的条带计数为 5。
条带计数是您应针对支持大型文件的系统进行调整的布局参数。条带计数指定了将存放条带化文件块的 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 -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,即系统中的所有 OST。这并不意味着数据会被写入每个 OST,但是读取文件长度之类的操作会并行向每个 OST 发送请求,从而给文件系统增加巨大的网络负载。
因此,对于任何随后可能追加数据的任何中小长度文件,请注意限制其条带计数。由于日志文件通常通过追加新记录增长,因此 Amazon FSx for Lustre 会为在追加模式下创建的任何文件分配默认条带计数 1,无论其父目录指定的默认条带配置如何。
2023 年 8 月 25 日后创建的 Amazon FSx for Lustre 文件系统的默认 PFL 配置使用以下命令设置:
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32
/mountname
如果客户的工作负载对中型和大型文件进行高度并发访问,则采用以下布局客户可能会获益:小文件设置较多条带,而最大的文件跨所有 OST 进行条带化,如上述四组件示例布局所示。
监控性能和使用情况
每分钟,Amazon FSx for Lustre 都会向亚马逊发布每个磁盘(MDT 和 OST)的使用率指标。 CloudWatch
要查看聚合文件系统使用情况的详细信息,可以查看每个指标的 Sum 统计数据。例如,DataReadBytes
统计数据的 Sum 会报告文件系统中所有 OST 的总读取吞吐量。同样,FreeDataStorageCapacity
统计数据 Sum 会报告文件系统中文件数据的总可用存储容量。
有关监控文件系统性能的更多信息,请参阅监控 Amazon FSx for Lustre。
性能提示
在使用 Amazon FSx for Lustre 时,请记住以下性能提示。有关服务限制的信息,请参阅配额。
-
平均 I/O 大小 – 由于 Amazon FSx for Lustre 是网络文件系统,因此每个文件操作都要在客户端和 Amazon FSx for Lustre 间往返,产生的延迟开销很少。由于这种每次操作的延迟,总吞吐量通常会随着平均 I/O 大小增加而增加,因为开销在大量数据之间分摊。
-
请求模型 – 通过启用对文件系统的异步写入,待处理的写入操作先在 Amazon EC2 实例上缓冲,然后才异步写入 Amazon FSx for Lustre。异步写入通常具有较低的延迟。在执行异步写入时,内核使用额外内存进行缓存。启用同步写入功能的文件系统向 Amazon FSx for Lustre 发出同步请求。每个操作都将在客户端和 Amazon FSx for Lustre 间往返一次。
注意
您选择的请求模型将在一致性(如果您使用多个 Amazon EC2 实例)和速率之间进行取舍。
-
Amazon EC2 实例 – 执行大量读取和写入操作的应用程序可能比不执行这些操作的应用程序需要更多的内存或计算容量。在为计算密集型工作负载启动 Amazon EC2 实例时,应选择具有您的应用程序需要的这些资源量的实例类型。Amazon FSx for Lustre 文件系统的性能特征不依赖于使用 Amazon EBS 优化的实例。
-
建议调整客户端实例以获得最佳性能
对于所有客户端实例类型和大小,我们建议应用以下调整:
sudo lctl set_param osc.*.max_dirty_mb=64
对于内存超过 64 GiB 的客户端实例类型,我们建议应用以下调整:
lctl set_param ldlm.namespaces.*.lru_max_age=600000
对于超过 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 作业,使用推荐的调整来设置配置。 -
各 OST 间的工作负载平衡 – 在某些情况下,您的工作负载并不会提高文件系统所能提供的聚合吞吐量(每 TiB 存储 200 MB/s)。如果是,如果工作负载的 I/O 模式不平衡会影响性能,则可以使用 CloudWatch 指标进行故障排除。要确定这是否是原因,请查看 Amazon FSx for Lustre 的最大 CloudWatch 指标。
在某些情况下,此统计数据显示吞吐量(单个 1.2 TiB Amazon FSx for Lustre 磁盘的吞吐能力)等于或大于 240 MBps 的负载。在这种情况下,您的工作负载不会均匀分布在磁盘上。在这种情况下,您可以使用
lfs setstripe
命令修改工作负载最常访问的文件的条带化。为获得最佳性能,请在构成文件系统的所有 OST 中对吞吐量要求很高的文件进行条带化。如果您的文件是从数据存储库导入的,则可以采用另一种方法,将高吞吐量文件均匀在 OST 中条带化。为此,您可以在创建下一个 Amazon FSx for Lustre 文件系统时修改
ImportedFileChunkSize
参数。例如,假设您的工作负载使用 7.0-TiB 文件系统(由 6 个 1.17-TiB OST 组成),并且需要在 2.4 GiB 文件上实现高吞吐量。在这种情况下,您可以将
ImportedFileChunkSize
值设置为(2.4 GiB / 6 OSTs) = 400 MiB
,以便文件均匀分布在文件系统的 OST 中。