主页 / unix / 问题 / 456571
Accepted
John Bollinger
Asked: 2018-07-17 07:23:13 +0800 CST

如何解决与主机探测相关的 autofs 挂载延迟？

  • 772

我有一个 CentOS 6 和 CentOS 7 客户端机器的基础架构，它们依赖 autofs 来自动挂载由我组织中其他地方的服务导出的各种 NFS 文件系统。最近，客户端开始表现出一种麻烦的行为，即自动挂载这些文件系统变得非常缓慢——而过去挂载需要几秒钟，现在开始需要将近两分钟。

我想我已经将问题归结为多种因素：

  • 服务器的主机名有大量不同的分辨率 (32)
  • 当主机名有多个解析时，autofs 会探测每一个以尝试拒绝无响应的解析，并从其余当前具有最佳响应时间的解析中选择一个
  • autofs 向每个服务器发出的两个探测 RPC 中的一个似乎对我的所有服务器都持续超时。

这是调试日志的代表性摘录：

Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20
Jul 13 15:48:21 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.84) proto 6 version 0x20

这显示了一个完整的探测以及三秒后下一个探测的开始。除了延迟之外，我看不到任何有关对第二个 RPC 的响应的信息。这对我来说是“超时”。虽然超时单独只有 3 秒，但将其乘以 32 台机器意味着在实际尝试挂载之前超时超过一分半。

客户端运行 CentOS 6 和 7 的标准 NFS 客户端堆栈：分别由 CentOS 打包的 nfs-utils 1.2.3 和 autofs 5.0.5 或 nfs-utils 1.3.0 和 autofs 5.0.7。客户处于配置管理之下，因此我相信他们在问题开始出现之前就没有进行任何软件或配置更改。

服务器正在运行 Ganesha 用户空间 NFS 堆栈，特别是，它们不支持 NFS4 可能是相关的，尽管这在过去没有出现问题。服务器管理声称没有故意进行配置更改，但允许可能已安装例行软件更新。

所以，最后，问题如标题所示：如何解决主机探测导致的挂载延迟？Ganesha 中是否有相关的配置设置，其默认设置可能已更改？或者，有没有办法配置 autofs 以避免尝试失败的 RPC？还是我可能错误地识别了问题？

打开 autofs 配置参数use_hostname_for_mounts似乎可以解决这个问题，但据我了解，这是以失去对故障和单个服务器过载的弹性为代价的。没有更好的办法吗？

nfs autofs

1 个回答

  1. Best Answer

    日志消息中的关键线索似乎是记录为“proto 6”的探测成功，而记录为“proto 17”的探测失败。6 和 17 分别是代表 TCP 和 UDP 的 IP 传输协议号。

    尽管 NFS 传统上通过 UDP 提供服务，但大多数堆栈都支持通过 TCP 提供服务，并且在这种情况下，服务器始终配置为仅通过 TCP 提供 NFS。然而，这并没有出现问题，直到服务器上出现一个尚未表征的更改，结果导致 nfs/udp 流量随后被静默丢弃，而不是被适当的 ICMP 响应拒绝。这很可能是由防火墙更改引起的，但我目前不能排除服务器上的应用程序级别更改。

    无论如何，我通过proto=tcp在 autofs 映射文件中添加每个受影响文件系统的挂载选项来解决客户端的问题。Autofs 足够聪明，一旦该选项到位，就放弃了 UDP 风格的探测。不仅问题得到了解决，而且现在的挂载性能似乎比超时问题开始之前还要好一些。

    • 2

相关问题