提高 NFS Azure 文件共享的性能

本文介绍如何提高网络文件系统 (NFS) Azure 文件共享的性能。

适用于

管理模型	计费模式	媒体层	冗余	中小型企业 (SMB)	网络文件系统(NFS)
Microsoft.Storage	预配 v2	HDD（标准）	本地 (LRS)
Microsoft.Storage	预配 v2	HDD（标准）	区域 (ZRS)
Microsoft.Storage	预配 v2	HDD（标准）	异地 (GRS)
Microsoft.Storage	预配 v2	HDD（标准）	GeoZone （GZRS）
Microsoft.Storage	预配版本 v1	SSD（高级）	本地 (LRS)
Microsoft.Storage	预配版本 v1	SSD（高级）	区域 (ZRS)
Microsoft.Storage	即用即付	HDD（标准）	本地 (LRS)
Microsoft.Storage	即用即付	HDD（标准）	区域 (ZRS)
Microsoft.Storage	即用即付	HDD（标准）	异地 (GRS)
Microsoft.Storage	即用即付	HDD（标准）	GeoZone （GZRS）

增加预读大小以提高读取吞吐量

Linux 中的 read_ahead_kb 内核参数表示应在顺序读取操作期间“预读”或预提取的数据量。 5.4 之前的 Linux 内核版本将预读值设置为装载的文件系统的 rsize（代表读取缓冲区大小的客户端装载选项）的 15 倍的等效值。 这会将预读值设置为足够高，以便在大多数情况下提高客户端顺序读取吞吐量。

但是，从 Linux 内核版本 5.4 开始，Linux NFS 客户端使用默认 read_ahead_kb 值 128 KiB。 此小值可能会减少大型文件的读取吞吐量。 从具有较大预读值的 Linux 版本升级到具有 128 KiB 默认值的版本的客户可能会遇到顺序读取性能下降的问题。

对于 Linux 内核 5.4 或更高版本，建议将 read_ahead_kb 设置为 15 MiB 以提高性能。

若要更改此值，请在 Linux 内核设备管理器 udev 中添加规则来设置预读大小。 执行以下步骤：

1. 在文本编辑器中，通过输入并保存以下文本来创建 /etc/udev/rules.d/99-nfs.rules 文件：

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. 在控制台中，通过以超级用户身份运行 udevadm 命令并重新加载规则文件和其他数据库来应用 udev 规则。 只需运行此命令一次，即可了解新文件。

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect 是 NFS 文件共享的客户端装载选项，可用于在客户端与 NFS 文件共享之间使用多个 TCP 连接。

优点

使用 nconnect，可以使用更少的客户端计算机来大规模提高性能，以减少总拥有成本（TCO）。 nconnect 功能通过使用一个或多个客户端在一个或多个 NIC 上使用多个 TCP 通道来提高性能。 如果没有 nconnect，则需要大约 20 台客户端计算机才能达到最大 SSD 文件共享预配大小提供的带宽缩放限制（10 GiB/秒）。 使用 nconnect，只需使用 6-7 个客户端即可实现这些限制，从而将计算成本降低近 70%，同时大规模提高每秒 I/O作数（IOPS）和吞吐量。 请参见下表。

先决条件

• 最新的 Linux 分发版完全支持 nconnect。 对于较旧的 Linux 分发版，请确保 Linux 内核版本为 5.3 或更高版本。
• 仅当每个存储帐户通过专用终结点使用单个文件共享时，才支持按装载配置。

性能影响

在大规模将 nconnect 装载选项与 Linux 客户端上的 NFS Azure 文件共享配合使用时，我们取得了以下性能结果。 有关如何实现这些结果的详细信息，请参阅性能测试配置。

建议

遵循这些建议，从 nconnect 中获得最佳结果。

设置 nconnect=4

虽然 Azure Files 支持将 nconnect 最多设置为 16，但配置装载选项时建议使用最佳设置 nconnect=4。 目前，对于 nconnect 的 Azure 文件存储实现来说，超过 4 个通道不会带来增益。 事实上，由于 TCP 网络饱和，单个客户端中单个 Azure 文件共享连接的通道超过四个可能会对性能产生负面影响。

仔细调整虚拟机大小

根据工作负载要求，请务必正确调整客户端虚拟机 (VM) 的大小以避免受到其预期网络带宽的限制。 无需多个网络接口控制器 (NIC) 也可实现预期的网络吞吐量。 虽然通常使用具有 Azure 文件存储的常规用途 VM，但根据工作负载需求和区域可用性，可以使用各种 VM 类型。 有关详细信息，请参阅 Azure VM 选择器。

将队列深度保持小于或等于 64

队列深度是存储资源可处理的待处理 I/O 请求数。 建议不要超过 64 的最佳队列深度，因为性能不会再提升。 有关详细信息，请参阅队列深度。

每个装载配置

如果工作负载需要从单个客户端装载多个具有不同 nconnect 设置的存储帐户的共享，则无法保证这些设置在通过公共终结点装载时会维持不变。 仅当每个存储帐户通过专用终结点使用单个 Azure 文件共享时，才支持按装载配置，如场景 1 中所述。

场景 1：通过具有多个存储帐户的专用终结点进行按装载配置（支持）

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

场景 2：通过公共终结点进行按装载配置（不支持）

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

场景 3：通过在单个存储帐户上具有多个共享的专用终结点进行按装载配置（不支持）

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

性能测试配置

我们使用以下资源和基准测试工具来实现并衡量本文中概述的结果。

• 单个客户端：具有单个 NIC 的 Azure 虚拟机（DSv4 系列）
• OS：Linux (Ubuntu 20.40)
• NFS 存储： SSD 文件共享（已预配 30 TiB，设置 nconnect=4）

基准测试工具和测试

我们使用了 Flexible I/O Tester (FIO)，这是一款免费的开源磁盘 I/O 工具，用于基准和压力/硬件验证。 要安装 FIO，请参照 FIO 自述文件中的“二进制软件包”部分，为所选平台进行安装。

虽然这些测试侧重于随机 I/O 访问模式，但使用顺序 I/O 时会获得类似的结果。

高 IOPS：100% 读取

4k I/O 大小 - 随机读取 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k I/O 大小 - 随机读取 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高吞吐量：100% 读取

64 KiB I/O 大小 - 随机读取 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1,024 KiB I/O 大小 - 100% 随机读取 - 队列深度为 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高 IOPS：100% 写入

4 KiB 输入/输出大小 - 100% 随机写入 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 KiB 输入/输出大小 - 100% 随机写入 - 队列深度为64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

高吞吐量：100% 写入

64 KiB I/O 大小 - 100% 随机写入 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 KiB I/O 大小 - 100% 随机写入 - 64 队列深度

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

nconnect 的性能注意事项

使用 nconnect 装载选项时，应密切评估具有以下特征的工作负载：

• 单线程和/或使用低队列深度（小于 16）的延迟敏感型写入工作负载
• 单线程和/或使用低队列深度与较小 I/O 大小的延迟敏感型读取工作负载

并非所有工作负载都需要大规模 IOPS 或吞吐量性能。 对于规模较小的工作负载，nconnect 可能没有意义。 使用下表来确定 nconnect 是否有益于工作负载。 建议使用以绿色突出显示的方案，而不使用以红色突出显示的方案。 使用黄色突出显示的方案则介于二者之间。

另请参阅

• 将 NFS 文件共享装载到 Linux
• 装载选项列表
• 了解 Azure 文件存储的性能