☰

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

tag-icon • tag-icon nfs autofs
如何解决与主机探测相关的 autofs 安装延迟？

我有一个 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 客户端堆栈：nfs-utils 1.2.3 和 autofs 5.0.5 或 nfs-utils 1.3.0 和 autofs 5.0.7，分别由 CentOS 打包。客户端处于配置管理之下，因此我确信自问题开始出现之前他们就没有进行任何软件或配置更改。

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

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

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

答案1

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

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

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

相关内容