Azure NetApp 文件是一项托管存储解决方案,适用于各种方案,包括高性能计算 (HPC) 基础结构。 低延迟和每秒高 I/O 操作数 (IOPS) 对于大规模企业而言是一种很好的组合。
假设你就职于一家半导体公司。 你的任务是设计公司的集成电路芯片,其需要很多电子设计自动化 (EDA) 模拟。 你在本地没有足够的容量用于此项目,因此你决定使用 Azure 来满足那些 HPC 模拟需求。
管理层希望你能够及时且经济高效地完成此项目。 你选择 Azure NetApp 文件作为后端存储解决方案,因为它提供了与本地类似的体验和性能。 你需要了解性能技巧和最佳做法,以提高 EDA 应用程序的 Azure NetApp 文件性能。
本模块介绍关于参考体系结构、客户端虚拟机 (VM) 和网络的性能建议。 接下来,我们讨论性能技巧,包括装载选项和客户端 VM 配置。 最后,我们检查基准检验结果,以验证所讨论的性能技巧。
学习完本模块以后,您将能够:
在此模块中,我们介绍在 Azure NetApp 文件上运行 EDA 应用程序时关于参考体系结构、客户端 VM 和网络的性能建议。
此 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 配置,以便在 Azure NetApp 文件上运行 HPC 或 EDA 应用程序时提高性能。
NFS 客户端的最佳做法取决于所使用的应用程序。 下面的建议不是绝对的,可以通过应用程序建议或工作负载测试进行替代。 因此,强烈建议在部署到生产环境之前测试这些做法。
可以使用以下装载选项提高相对静态数据集和大规模读取方案的性能:
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
在 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。 也就是说,它可能不适用于某些案例。
Azure NetApp 文件支持 NFSv3 和 NFSv4.1。 应验证应用程序需要的版本,并使用适当的版本创建卷。
当只考虑性能时,在大多数 HPC 和 EDA 应用程序中,NFSv3 的性能将优于 NFSv4.1。
装载选项 rsize
和 wsize
确定在 NFS 客户端和服务器之间发送的每个数据包的数据量。 设置这些选项可能有助于优化特定应用程序的性能,因为最适合某个应用程序的方法可能并不适合其他应用程序。
关于 Azure NetApp 文件的最佳做法是,将 rsize
和 wsize
设置为相同值。 通常建议在装载选项中将 rsize
和 wsize
值都设置为 262144(256 K)
。
hard
和 soft
装载选项指定使用 NFS 文件的程序是否应执行下列操作之一:
hard
) 服务器恢复到联机状态。soft
)。intr
装载选项允许在装载被指定为 hard
装载时中断 NFS 进程。 建议在适用时结合使用 intr
与 hard
装载。
对于 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 和吞吐量进行基准检验。
本部分中的图演示了 I/O 和延迟曲线。 它们检查以下性能做法的一些组合:
nocto,actimeo=600
sysctl tuned
nconnect=16
应用上述所有三种做法后,每秒 I/O 操作数会增加,同时仍保持较低的延迟(小于 1 毫秒)。
下图表明,rsize=wsize=262144(256 K)
的性能优于其他设置。
以下 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 和吞吐量。
回顾一下,你使用 Azure NetApp 文件作为后端存储解决方案,以便在 Azure 上运行 HPC 和 EDA 应用程序。 你需要了解性能技巧和最佳做法,以提高这些应用程序的 Azure NetApp 文件性能。
本模块介绍了关于参考体系结构、客户端 VM 和网络的性能建议。 然后,我们讨论了几个性能技巧,包括装载选项和客户端 VM 配置。 最后,我们检查了 SPEC EDA 和 FIO 基准检验结果,以验证所讨论的性能技巧。
现在,你应该能够列出并描述有助于提高 HPC 和 EDA 应用程序的 Azure NetApp 文件性能的性能做法。