提高 NFS Azure 文件共享性能

大隐隐于野2024-01-31 10:19

本文内容

  1. 适用于
  2. 增加预读大小以提高读取吞吐量
  3. Nconnect
  4. 另请参阅

本文介绍如何提高 NFS Azure 文件共享的性能。

适用于

展开表

文件共享类型 SMB NFS
标准文件共享 (GPv2)、LRS/ZRS
标准文件共享 (GPv2)、GRS/GZRS
高级文件共享 (FileStorage)、LRS/ZRS

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

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 规则。 只需运行此命令一次，即可了解新文件。

    Bash复制

    复制代码 
    sudo udevadm control --reload

Nconnect

Nconnect 是客户端 Linux 装载选项，通过允许在客户端与 NFSv4.1 的 Azure 高级文件服务之间使用更多 TCP 连接来大规模提高性能，同时保持平台即服务 (PaaS) 的复原能力。

nconnect 的优势

借助 nconnect，可以使用更少的客户端计算机大规模提高性能，以降低总拥有成本 (TCO)。 Nconnect 通过在一个或多个 NIC 上使用多个 TCP 通道或者使用一个或多个客户端来提高性能。 如果没有 nconnect，则需要大约 20 台客户端计算机，才能达到最大高级 Azure 文件共享预配大小提供的带宽规模限制 (10 GiB/s)。 使用 nconnect，只需使用 6-7 个客户端即可达到这些限制。 这几乎减少了 70% 的计算成本，同时大规模地提高了 IOPS 和吞吐量，（请参阅表）。

展开表

指标（操作） I/O 大小 性能提升
IOPS（写入） 64K、1024K 3x
IOPS（读取） 所有 I/O 大小 2-4x
吞吐量（写入） 64K、1024K 3x
吞吐量（读取） 所有 I/O 大小 2-4x

先决条件

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

nconnect 的性能影响

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

有关 nconnect 的建议

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

设置 nconnect=4

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

仔细调整虚拟机大小

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

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

队列深度是存储资源可处理的待处理 I/O 请求数。 建议不要超过最佳队列深度 64。 如果这样做，则不会再看到任何性能提升。 有关详细信息，请参阅队列深度。

Nconnect 按装载配置

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

方案 1：（支持）使用多个存储帐户通过专用终结点进行 nconnect 按装载配置
方案 2：（不支持）通过公共终结点进行 nconnect 按装载配置

备注

即使存储帐户解析为其他 IP 地址，也不能保证该地址会保留，因为公共终结点不是静态地址。

方案 3：（不支持）在单个存储帐户上使用多个共享通过专业终结点进行 nconnect 按装载配置
  • 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 存储： Azure 文件存储高级文件共享（预配 30 TiB，设置nconnect=4

展开表

大小 vCPU 内存 临时存储 (SSD) 最大数据磁盘数 最大 NIC 数 预期网络带宽
Standard_D16_v4 16 64 GiB 仅限远程存储 32 8 12,500 Mbps

基准测试工具和测试

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

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

高 IOPS：100% 读取

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

Bash复制

复制代码 
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 队列深度

Bash复制

复制代码 
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% 读取

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

Bash复制

复制代码 
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

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

Bash复制

复制代码 
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% 写入

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

Bash复制

复制代码 
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

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

Bash复制

复制代码 
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% 写入

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

Bash复制

复制代码 
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

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

Bash复制

复制代码 
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 是否有益于工作负载。 建议使用绿色突出显示的方案，而红色突出显示的方案则不推荐。 黄色突出显示的方案则介于二者之间。

另请参阅

相关推荐
有梦想的攻城狮2 天前
【一起来学kubernetes】29、NFS使用详解
云原生·容器·kubernetes·nfs·网络文件系统
qq_4136913511 天前
CI/CD(三) 安装nfs并指定k8s默认storageClass
ci/cd·docker·kubernetes·storageclass·nfs
天糊土15 天前
Windows主机、虚拟机Ubuntu、开发板，三者之间文件互传
nfs·tftp
超级阿飞2 个月前
在K8s中部署动态nfs存储provisioner
云原生·容器·kubernetes·nfs
DZSpace2 个月前
Kubernetes 部署 RabbitMQ 集群教程
kubernetes·rabbitmq·storageclass·nfs
斯普信专业组3 个月前
NFS 组件容器化部署实战指南
nfs
nangonghen3 个月前
smb和nfs双栈协议共享目录
nfs·samba·双栈
鹏大师运维3 个月前
聊聊开源的虚拟化平台--PVE
linux·开源·虚拟化·虚拟机·pve·存储·nfs
大隐隐于野5 个月前
NFS Write IO 不对齐深度分析
linux·nfs
陈小肚5 个月前
使用 docker 的方式部署 NFS server 提供文件共享能力
docker·nfs·1024程序员节
热门推荐
01我决定放弃搞 Java 了02DeepSeek各版本说明与优缺点分析03如何在WPS和Word/Excel中直接使用DeepSeek功能04本地化部署AI知识库：基于Ollama+DeepSeek+AnythingLLM保姆级教程05苍穹外卖面试总结06从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑07循环神经网络RNN（含LSTM，GRU）小综述08RAG 实践- Ollama+RagFlow 部署本地知识库09如何本地部署AI智能体平台，带你手搓一个AI Agent10Android下HWC以及drm_hwcomposer普法(上)