提高 NFS Azure 文件共享的性能

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

管理模型	计费模式	媒体层	冗余	中小型企业	网络文件系统 (NFS)
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 规则。 只需运行此命令一次，即可使 udev 识别新文件。

   sudo udevadm control --reload
   

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 中获得最佳结果。

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

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

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

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

• StorageAccount.file.core.chinacloudapi.cn = 10.10.10.10
• StorageAccount2.file.core.chinacloudapi.cn = 10.10.10.11
  • Mount StorageAccount.file.core.chinacloudapi.cn:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.chinacloudapi.cn:/StorageAccount2/FileShare1

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

• StorageAccount.file.core.chinacloudapi.cn = 10.10.10.10
  • Mount StorageAccount.file.core.chinacloudapi.cn:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.chinacloudapi.cn:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.chinacloudapi.cn:/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 时会获得类似的结果。

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

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

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

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 装载选项时，应密切评估具有以下特征的工作负载：

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

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

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