通过遵循最佳做法来提高 EDA 和 HPC 应用程序的 Azure NetApp 文件性能

介绍

Azure NetApp 文件是一项托管存储解决方案，适用于各种方案，包括高性能计算 (HPC) 基础结构。低延迟和每秒高 I/O 操作数 (IOPS) 对于大规模企业而言是一种很好的组合。

假设你就职于一家半导体公司。你的任务是设计公司的集成电路芯片，其需要很多电子设计自动化 (EDA) 模拟。你在本地没有足够的容量用于此项目，因此你决定使用 Azure 来满足那些 HPC 模拟需求。

管理层希望你能够及时且经济高效地完成此项目。你选择 Azure NetApp 文件作为后端存储解决方案，因为它提供了与本地类似的体验和性能。你需要了解性能技巧和最佳做法，以提高 EDA 应用程序的 Azure NetApp 文件性能。

本模块介绍关于参考体系结构、客户端虚拟机 (VM) 和网络的性能建议。接下来，我们讨论性能技巧，包括装载选项和客户端 VM 配置。最后，我们检查基准检验结果，以验证所讨论的性能技巧。

学习目标

学习完本模块以后，您将能够：

列出能够提高 Azure NetApp 文件性能的最佳做法。
介绍这些 Azure NetApp 文件性能最佳做法对 FIO 和 EDA 基准套件的影响。

先决条件

了解 Azure NetApp 文件的存储层次结构，包括 NetApp 帐户、容量池和卷。
能够设置 Azure NetApp 文件并创建卷。
能够从虚拟机装载 Azure NetApp 文件卷。

总体性能建议

在此模块中，我们介绍在 Azure NetApp 文件上运行 EDA 应用程序时关于参考体系结构、客户端 VM 和网络的性能建议。

通过审阅参考体系结构来了解 EDA 工作负载

此 EDA 工具和芯片模拟过程可能具有不同的参考体系结构。下面的参考体系结构展示了一般用例，即如何在云突发（混合）和完全在 Azure 上这两种方案中将 Azure NetApp 文件用于 EDA 工作负载。

关于虚拟网络、加速网络和客户端更新的建议

尽可能将客户端 VM 和 Azure NetApp 文件驻留在相同的区域和虚拟机中，这样可以减少两者之间的网络延迟。

如果支持，在客户端 VM 上启用加速网络，以提供超过 30 Gbps 的网络吞吐量。加速网络降低了从客户端 VM 到 Azure NetApp 文件的延迟。它还提高了整体性能，特别是在分布式多方案分析 (DMSA) 类型的模拟中。

最佳做法是运行适用于操作系统的最新修补程序版本。还应将网络文件系统 (NFS) 实用工具更新到其最新版本，以获得最新的 bug 修复和功能。这些更新有助于确保最佳性能和系统稳定性。

例如，运行以下命令：

sudo yum update
sudo yum update nfs-utils

装载选项和客户端 VM 配置

在此模块中，我们讨论装载选项和客户端 VM 配置，以便在 Azure NetApp 文件上运行 HPC 或 EDA 应用程序时提高性能。

NFS 客户端的最佳做法取决于所使用的应用程序。下面的建议不是绝对的，可以通过应用程序建议或工作负载测试进行替代。因此，强烈建议在部署到生产环境之前测试这些做法。

使用 actimeo 和 nocto 装载选项来提高性能

可以使用以下装载选项提高相对静态数据集和大规模读取方案的性能：

actimeo：控制目录的 NFS 客户端缓存特性。如果未指定此值，则 NFS 客户端将使用最大值 60秒。
nocto：表示“不用关闭再打开”，这意味着文件可以在写入完成前关闭，以节省时间。默认情况下，未设置 nocto。这意味着所有文件都得等待写入完成，然后才允许关闭。

大多数 HPC 应用程序（包括此方案中的 EDA）都有相对静态数据集。在此案例中，你可以使用 nocto 和 actimeo 来减少对存储的 getattr 或访问操作，并加快应用程序的速度。

例如，我们建议为 EDA 工具和库卷设置 "nocto,actimeo=600"。由于这些文件不会发生变化，因此无需维护缓存一致性。设置这些装载选项后，即无需调用元数据并可提高整体性能。

调整系统参数以获得最佳性能

运行下面的命令，对客户端 VM 应用基本的服务器优化和典型的延迟优化：

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

以下部分或所有系统参数 (/etc/sysctl.conf) 可能有助于 Linux 客户端 VM 获得最佳性能。如果客户端 VM 有大量 RAM 或更高的网络带宽（如 InfiniBand），则不妨设置一些比以下示例所示更高的值。

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

若要让这些优化持久，请运行下面的代码：

sudo sysctl -P

适当时，使用装载选项 nconnect 扩展网络连接

在 Linux 内核 5.3 或更高版本中，nconnect NFS 装载选项已正式发布。若要检查客户端 VM 的 Linux 内核，请运行下面的代码：

uname -r

nconnect 旨在为客户端上的每个 TCP 连接或装入点提供多个传输连接。此技术有助于提高 NFS 装载的并行度和性能。

客户端数量越小，nconnect 帮助提高性能的价值就越高，因为它可能会利用所有网络带宽。它的价值随着客户端数量增加而逐渐减少，因为总共只有一定数量的带宽。

如果使用的是 nconnect=8 或 16，请考虑设置 sunrpc.tpc_max_slot_table_entries=256 或 512。

nconnect 选项仅适用于 Linux 内核 5.3 + VM。升级内核时，可能需要重启 VM。也就是说，它可能不适用于某些案例。

当只考虑性能时，使用 NFSv3，而不是 NFSv4.1

Azure NetApp 文件支持 NFSv3 和 NFSv4.1。应验证应用程序需要的版本，并使用适当的版本创建卷。

当只考虑性能时，在大多数 HPC 和 EDA 应用程序中，NFSv3 的性能将优于 NFSv4.1。

为 rsize 和 wsize 装载选项选择适当大小

装载选项 rsize 和 wsize 确定在 NFS 客户端和服务器之间发送的每个数据包的数据量。设置这些选项可能有助于优化特定应用程序的性能，因为最适合某个应用程序的方法可能并不适合其他应用程序。

关于 Azure NetApp 文件的最佳做法是，将 rsize 和 wsize 设置为相同值。通常建议在装载选项中将 rsize 和 wsize 值都设置为 262144(256 K)。

为 hard、soft 和 intr 装载选项选择适当的设置

hard和 soft 装载选项指定使用 NFS 文件的程序是否应执行下列操作之一：

如果 NFS 服务器不可用，请停止并等待 (hard) 服务器恢复到联机状态。
报告错误 (soft)。

intr 装载选项允许在装载被指定为 hard 装载时中断 NFS 进程。建议在适用时结合使用 intr 与 hard 装载。

考虑不更改 MTU

对于 Azure VM，默认的最大传输单位 (MTU) 为 1,500 字节。不建议客户为巨型帧增加 VM MTU。

装载示例

下面的示例代码通过使用上述适用于 actimeo、nocto、NFSv3、nconnect、rsize、wsize、hard、intr、tcp 的最佳做法和默认 MTU (1,500) 来装载 Azure NetApp 文件卷：

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

基准结果

现在，我们检查基准结果，验证我们在上一单元中讨论的性能技巧。具体来说，我们重点介绍如何使用 SPEC SFS 基准套件以生成模拟类似 EDA 生产的工作负载的多个线程。此外，我们将展示 FIO 结果，以检查一些性能做法。

这两个基准工具的概览

SPEC SFS 套件是 EDA 的标准行业基准。典型的 EDA 工作负载包括功能阶段和物理阶段。功能阶段驱动大多数随机 I/O 和文件系统元数据操作。物理阶段驱动大规模顺序读取和写入操作。

FIO 是一种 I/O 工具，它可以生成一致的随机或顺序读取/写入负载，以对存储目标的 IOPS 和吞吐量进行基准检验。

SPEC EDA 工具的基准检验结果

本部分中的图演示了 I/O 和延迟曲线。它们检查以下性能做法的一些组合：

nocto,actimeo=600
sysctl tuned
nconnect=16

应用上述所有三种做法后，每秒 I/O 操作数会增加，同时仍保持较低的延迟（小于 1 毫秒）。

下图表明，NFSv3 的性能优于 NFSv4.1。

下图表明，rsize=wsize=262144(256 K) 的性能优于其他设置。

FIO 工具的基准结果

以下 FIO 命令分别对 IOPS 和吞吐量进行基准检验。

Bash复制

// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

以下两个图表明了在优化 nocto,actimeo=600、nconnect=16 和 sysctl 时，Azure NetApp 文件可以实现更高的 IOPS 和吞吐量。