装载选项和客户端 VM 配置
在此模块中,我们讨论装载选项和客户端 VM 配置,以便在 Azure NetApp 文件上运行 HPC 或 EDA 应用程序时提高性能。
注意
NFS 客户端的最佳做法取决于所使用的应用程序。 下面的建议不是绝对的,可以通过应用程序建议或工作负载测试进行替代。 因此,强烈建议在部署到生产环境之前测试这些做法。
使用 actimeo 和 nocto 装载选项来提高性能
可以使用以下装载选项提高相对静态数据集和大规模读取方案的性能:
actimeo
:控制目录的 NFS 客户端缓存特性。 如果未指定它,则 NFS 客户端将使用 60 秒最大默认值。nocto
:表示“不用关闭再打开”,这意味着文件可以在写入完成前关闭,以节省时间。 默认情况下,nocto
不在 NFS 装载选项中设置。 这意味着所有文件都得等待写入完成,然后才允许关闭。
大多数 HPC 应用程序(包括方案中的 EDA)具有相对静态的数据集(这意味着数据不会频繁更改)。 在此案例中,你可以使用 nocto
和 actimeo
来减少对存储的 getattr
或访问操作,这可以加快应用程序的速度。
例如,我们建议为 EDA 工具和库卷设置 "nocto,actimeo=600"
(600 秒或 10 分钟)。 由于这些文件不会发生变化,因此无需维护缓存一致性。 设置这些装载选项可减少元数据调用,从而提高整体性能。
调整系统参数以获得最佳性能
Tuned
是一个守护程序,可用于在 Linux 客户端上监视和配置连接的设备。 在大多数情况下,将默认安装 tuned
。 如果未安装,可以添加并启用它,以使用内置默认模板简化客户端优化参数。
运行下面的命令,对客户端 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
在帮助提升性能方面提供的值就越大,因为它可能会利用所有可用的网络带宽。 当客户端数量增加时,其值会逐渐降低;由于可供使用的带宽总量是一定的,因此可能会更快地耗尽 TCP 连接最大数量,在 TCP 连接释放之前,这可能会导致拒绝服务。
由于 Azure NetApp 文件允许在发生限制之前每个 TCP 连接最多可以发出 128 个同时进行的请求(新的请求会在在资源可用之前排队),因此 nconnect
可以通过增加每个装载点的可用 TCP 连接来扩充允许的正在进行的请求数。 例如,如果 nconnect
设置为使用 8 个 TCP 连接,则客户端可能可以使用 1,024 (8x128) 个请求。
使用新式 Linux 客户端,每个连接最多可以使用 65,535 个请求(动态值)。 这可能会溢出 Azure NetApp 文件卷的可用动态请求队列,并导致不良的性能结果,其中客户端发送的请求数超过了可在给定时间处理的请求数。 要降低此行为对性能造成影响的风险,如果使用的是 nconnect=8
或 16
,请考虑将 sunrpc.tpc_max_slot_table_entries=256
或 512
设置为较低的静态值。 使用下表作为指导。
注意
不同的 Linux 客户端 OS 类型可能具有不同的方法来设置此值。 有关详细信息,请参阅 OS 文档。
值nconnect |
建议的 TCP 最大槽表条目 |
---|---|
0-1 | 128 |
2-4 人 | 256 |
6 到 8 | 512 |
>8 | 无需更改 |
注意
nconnect
选项仅适用于 Linux 内核 5.3 + VM。 升级内核时,可能需要重启 VM。 也就是说,它可能不适用于某些案例。
当只考虑性能时,使用 NFSv3,而不是 NFSv4.1
NFSv3 是一种无状态协议,这意味着客户端和服务器不会就正在使用的文件相互通信。 锁定由网络锁定管理器 (NLM) 在协议堆栈之外执行,这会在锁过期后带来一些问题,因此必须进行手动清理。 锁定仅在应用程序请求时建立,因此可能存在不需要协商锁定的情况。 由于没有要跟踪的客户端 ID、状态 ID、会话 ID、锁定状态等,因此在一些工作负载中,NFSv3 的性能往往比 NFSv4.1 要更好一些,尤其是在高文件计数/高元数据工作负载(如 EDA 和软件开发)中。
NFSv4.1 会跟踪文件的状态,包括锁。 如果在 NFSv4.1 中一次使用许多文件,则每个文件都会分配有状态 ID 并且会收到锁。 有状态会增加工作负载性能的开销,因为每个状态和锁都必须由 NFS 服务器处理。 在一些工作负载(如 EDA)中,NFSv4.1 性能可能受到影响的程度为 25% 到 75% 之间。 使用 NFSv4.1 时,其他工作负载(如大型文件、流式处理 IO 或数据库)的性能不会下降,并且甚至可能会受益于协议使用的复合操作。
Azure NetApp 文件支持 NFSv3 和 NFSv4.1。 应通过比较 NFS 版本(以及测试)之间的异同,以及使用合适的版本创建自己的卷来验证应用程序所需的版本。 如有必要,可以在创建后将 Azure NetApp 文件卷配置为其他协议版本。
为 rsize 和 wsize 装载选项选择合适的值
装载选项 rsize
(读取大小)和 wsize
(写入大小)会确定所发送的每个数据包在 NFS 客户端和服务器之间发送的数据量。 例如,将 rsize
或 wsize
设置为 65,536 意味着每个数据包最多可以发送 64 K 数据。 如果应用程序以较小的区块(如 8 K)发送数据,则发送的数据量取决于使用的装载选项(例如 sync
)。
关于 Azure NetApp 文件的最佳做法是,将 rsize
和 wsize
设置为相同值。 通常建议在装载选项中将 rsize
和 wsize
值都设置为 262144 (256 K)
。
了解同步和异步装载选项
如果使用 sync
,则会使用命令 FILE_SYNC
发送每个 WRITE
调用。 这意味着每个 WRITE 必须得到服务器的确认并提交到磁盘,然后才能执行下一个 WRITE
。 当应用程序必须保证将所有数据提交到磁盘时,将会使用 Sync
。 WRITE
调用仅发送由应用程序块大小指定的数据量,这意味着无论装载的 wsize
或 rsize
为何值,较小的块大小都会生成更多的 NFS 流量,从而导致性能受到影响。
如果使用(默认的)async
装载操作,客户端可以使用 UNSTABLE
命令通过 NFS 发送多个 WRITE
调用。 在此方案中,数据会在超时期限后刷新到磁盘。 由于在开始下一次 WRITE 之前,NFS 客户端并不始终在服务器上等待将数据提交到磁盘,因此写入到异步装载的作业完成时间会远低于同步装载。当较小的块大小与较大的 rsize
和 wsize
值一起使用时,WRITE
调用会发送与单个 NFS 调用所允许的数量一样的数据量。 例如,如果 8 K 块大小与 64 K wsize
/rsize
一起使用,则每个 NFS WRITE 调用会为每个数据包发送 8 个块(64 K/8 K)。 将写入刷新到磁盘时,NFS 服务器会将 FILE_SYNC
回复发送回 NFS 客户端。 这减少了为完成作业而必须在网络上进行的 WRITE
调用和回复的总数,从而提高了性能。
例如,在使用 8 K 块大小创建了 1-GiB 文件的测试中,使用 sync
装载选项时,生成了 262,144 个 WRITE
调用和回复,并在 70 秒内完成。 使用 8 K 块大小和 async
装载选项的相同文件创建仅发送了 16,384 个 WRITE 调用和回复,并在 6 秒内完成。
Azure NetApp 文件将电池支持的 NVRAM 存储用作传入 NFS 写入的缓冲区缓存。 NVRAM 中的数据将每 10 秒一次,或在缓冲区缓存填满之前刷新到磁盘(以先到者为准)。 由于 NVRAM 由电池提供支持,因此在保留数据时,它可以在发生意外中断(例如 Azure 数据中心断电之类不太可能的事件)后至少工作 72 小时。 借助 Azure NetApp 文件数据复原能力和使用 sync
装载选项的性能影响的组合,异步已成为几乎所有用例中的首选选择。
了解 wsize 和 rsize 值的影响
通过 NFS 装载时,wsize
和 rsize
值可确定每个 NFS 调用可以发送到 NFS 服务器的数据量。 如果在装载选项中未指定,则该值将设置为 NFS 服务器所配置的任何值。 Azure NetApp 文件对 wsize
和 rsize
均使用 1 MB (1048576) 的最大传输大小。 无法在 Azure NetApp 文件中更改此值。 这意味着如果 NFS 装载未指定 wsize
和 rsize
值,则装载将默认为 1 MB。 EDA 工作负载中建议用于 NFS 装载的 wsize
和 rsize
值为 256 K。
如果应用程序需要在 Azure NetApp 文件 NFS 装载上创建一个 1 GiB 文件,则需要向存储写入 1048,576 KiB。 通过一个数学练习可以说明为什么更高效的 wsize
或 rsize
值可以提高性能。
- 如果将
wsize
设置为 64 K,则写入该 1 GiB 文件所需的操作/数据包数为 1048576/64=16384。 - 如果将
wsize
设置为 256 K,则写入该 1 GiB 文件所需的操作/数据包数为 1048576/256=4096。
数据包/操作数的减少意味着网络延迟(这会影响 RTT)对工作负载的影响会减小,这对云部署可能非常重要。 但如果应用程序写入的文件小于 wsize
/rsize
值,则较大的 wsize
/rsize
值不会影响性能。
较大的数据区块意味着客户端和服务器上会发生更多的处理周期,但大多数新式 CPU 都足以有效地处理这些请求。
关于 Azure NetApp 文件的最佳做法是,将 rsize
和 wsize
设置为相同值。 建议在装载选项中将 rsize
和 wsize
值均设为 262144 (256K)。 此设置涵盖了一组应用程序读取和写入大小值。
为 hard、soft 和 intr 装载选项选择适当的设置
hard
和 soft
装载选项指定使用 NFS 文件的程序是否应执行下列操作之一:
- 如果 NFS 服务器不可用,请停止并等待 (
hard
) 服务器恢复到联机状态。 此选项在客户端上会显示为装载挂起,但会确保在发生网络中断时不会丢失正在进行的操作。 相反,客户端在服务器可用或应用程序超时前会继续重试请求。 - 报告错误 (
soft
)。 装载不会挂起,但正在进行的操作可能会丢失。
使用 intr
装载选项,可以在将装载指定为 hard
装载(例如 CTRL+C
)时中断 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
注意
Async
未指定,因为 NFS 装载默认为 async
。