Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

RHEL mount hungs: 出现“ nfs: server [...] not responding, still trying” 报错

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 5
  • NFS Client (nfs-utils package)

Issue

  • NFS 服务 hung 并在 /var/log/messages中发现如下报错:
kernel: nfs: server <servername> not responding, still trying

Resolution

解决方案会根据发生问题的原因而有所不同:

  • NFS Client 和 Server 之间的问题
  • NFS Server 的问题
  • NFS Client 的问题
    应该对 NFS Client 和 NFS Server 都进行检查

让非 Red Hat 系统的厂商协助处理关于非 Red Hat 的 NFS Clients 或者 Servers 问题。检查以下问题:网络链路断掉, 网络包丢失, 系统 hang, NFS client/server hang 或运行缓慢, 存储 hang 或运行缓慢等连通性问题。

让调查 NFS Client 和 NFS Server 间网络问题的小组检查连通性和网络容量问题。

Root Cause

日志解释

  • 如果 NFS client 没有收到来自 NFS server 的响应, 可能会在 syslog 中出现"server ... not responding, still trying" 信息。
  • 每篇日志显示出一个 NFS/RPC 请求 (例如, NFS WRITE) 已经被重新发送且每次发送都会超时。设置 retranstimeo的默认选项后,将会在180s 后输出这篇日志。更多信息请参考 NFS man 手册中的retrans and timeo 选项。('man nfs')
  • 注释: 将 NFS mount 选项 timeo设置成一个很小的值(比默认值 600 小很多)后,可能会增加日志出现的概率和频率。例如,如果 NFS server 超过 0.5 + 1.0 = 1.5 秒来相应一些NFS 请求时,设置默认值 retrans=2timeo=5后会导致日志输出。在一个高负荷的NFS下, NFS server 超过 1.5s 来响应一个或更多 NFS 请求并不罕见。关于 timeoretrans的更多信息请查看 NFS man 手册 (man nfs)

Root Causes 的范畴

root cause 分为3类:

  • NFS Client 和 Server 之间的问题
  • NFS Server 的问题
  • NFS Client 的问题

针对每一类情况,下面给出了具体实例。

NFS Client 和 NFS Server 之间的问题

例如,高负荷,配置错误,交换机故障,防火墙或者网络问题可能会造成 NFS Client 和 NFS Server 间的NFS请求被丢弃或者被破坏。

有一些实例:

NFS Server 的问题

例如,NFS server 超载或者包含一个导致丢弃NFS请求的硬件或者软件bug

有一些实例:

  • 非 Red Hat NFS Server: 存储池级别的磁盘配置问题。NFS Server 厂商表示: "这时,我们认为池中空区的缺乏以及文件访问的随机性,导致了重定位操作时的auto-tiering失败。"
  • 非 Red Hat NFS Server: 某些情况下的 TCP 性能问题可被特定的补丁修复。
  • 非 Red Hat NFS Server: 配置问题导致数据通过错误的网络接口发送。
  • Red Hat NFS Server: NFS server 上运行的线程数可能太少。更多信息请参考 "How do I increase the number of threads created by the NFS daemon in RHEL 4, 5 and 6?"
  • Red Hat NFS Server: 三个不同的 bugs 如果都出现的话,一个NFS Server的完整 DoS 就会产生: https://access.redhat.com/solutions/544553

NFS Client 的问题

例如,NFS Client 网络的配置错误, NIC driver 或者 firmware bug 导致 NFS 请求 被丢弃;NFS Client 防火墙不允许 NFS 通信。

有一些实例:

  • 在客户端上不正确的 MTU (网络) 设置造成超时(以及 watchdog 重启)
  • 某个系统选择了Jumbo 包 (MTU=9000) ,但是该包不能通过网络的其他部分。

Diagnostic Steps

排除常见问题的基本步骤:

  • 首先,确认问题发生的时间点。问题在 not responding, still trying 日志出现的时候开始, 将 timeoretrans 值调大(在 Root Cause 部分中查看关于 timeoretrans的信息)。
    当看到 nfs server: ... OK 日志时,表示问题已经结束。

如果没有出现 OK 的日志信息 ,表示问题还在继续 ( NFS Server 仍然没有响应)。

如果日志中出现很多 not responding 的信息,可能在很多时间点发生问题或者需要进一步调整。
例如:

# grep server.example.com /proc/mounts 
server.example.com:/export /mnt nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,minorversion=0,local_lock=none,addr=y.y.y.y 0 0
# grep "server.example.com" /var/log/messages
Sep 29 22:54:39 client kernel: nfs: server server.example.com  not responding, still trying
Sep 29 22:54:49 client kernel: nfs: server server.example.com OK

由于您使用了默认的 mount 选项,问题在not responding 日志出现前180s发生。当 出现'OK' 日志时,问题结束:

Sep 29 22:51:39 - Problem BEGIN:  adjusted start time of the problem based on 'timeo' and 'retrans'
Sep 29 22:54:39 - 'not responding, still trying' seen
Sep 29 22:54:49 - Problem END: 'OK' seen

至此已经确定了发生问题的时间。

  • 在 NFS Server 上,在确认问题发生的时间点的过程中,请检查所有关于性能问题的日志。对于非 Red Hat 提供的 NFS servers,联系 NFS Server 厂商然后给他们提供问题发生的时间点。
  • 在 NFS Client 和 NFS Server 上,检查网络接口或者网络是否有问题。例如:

    • 查看ip -s link 和/或 ethtool 输出显示的丢包情况,请参考: System dropping packets due to rx_fw_discards
    • xsos 工具也可用来查找在网络设备中丢失的包,请参考: How can I install xsos command in Red Hat Enterprise Linux?
    • 检查 NFS Client,NFS Server 以及 从NFS Client 到 NFS Server 所有路径上的 MTU 设置。所有的系统必须有相同的 MTU 配置。
    • 在 RHEL 上通过运行 netstat -s 命令,寻找系统外丢失包的证据。在 TcpExt heading 下的计数器,例如 retransmits 或者 congestion可能意味着外部包的丢失。然而,注意由于启动系统后,系统的 TCP counter 值会自动叠加,所以错误可能与其他 TCP 连接相关而不仅与 NFS 连接相关。
  • 确认访问同一个 NFS Server 的其他 NFS Client ,特别是那些相同的 NFS Client (挂载相同的共享目录,有相同的挂载选项和相同的 Red Hat 版本等),查看是否相似的 NFS Clients 在相同时间点都会出现 not responding日志。 如果有一些其他的 NFS Clients, 将会导致 NFS Client 和 NFS Server 之间 NFS Server 的 credence 问题或者网络连接问题。

  • 请检查 NFS Client 和 NFS Server 之间的网络设备,例如路由器,交换机或者防火墙。如果有可能,在事故发生的时间点检查一些 log 或者监测数据。(例如 Cacti, rrdtool)

抓包问题的排错

下述步骤的目的是将问题分为三类:

  • NFS Client 和 NFS Server 间的问题
  • NFS Server 的问题
  • NFS Client 的问题

一旦问题被隔离,需要进一步排错来解决这个问题,然而这在解决方案的范畴之外。

解决这个问题最直接的方法是在 NFS Client 和 NFS Server 端抓包。某些情况下,仅对某一方例如对 NFS Client 进行抓包分析即可,但是建议您对 NFS Client 和 NFS Server 都进行抓包。

使用 tcpdump 抓包

在 RHEL NFS Client 端 一个简单的抓包方法是使用下述方案中的 tcpdump 工具 tcpdump-watch.sh 脚本: https://access.redhat.com/solutions/544883#intermittent.

这个脚本仅有一个参数,NFS Server 名或者 IP address, 查看 /var/log/messages 中关于 nfs: server ... not responding, still trying 的日志。看到这个日志后,tcpdump 完成。

请注意:在 tcpdump-watch.sh 脚本中的默认 tcpdump参数可能会在很多环境中起作用,但是在一些环境中可能会有微小的变化。 例如,如果有大量的 NFS READs 和 WRITEs 请求,在初始的抓包或者有很多被 tcpdump 进程丢弃的包,然后设置 "snaplen" 参数 (-s 512)将抓包的大小降到 ~512 bytes 。此外,如果抓包收集到的 NFS 通信量多于 NFS Client 和 NFS Server 之间的量, 可能需要添加一个或者更多 pcap-filters( 例如 port 2049),抓取来自或者发送到 NFS port 上包的通信。关于 pcap-filters 的更多信息,请看 man pcap-filter

RHEL NFS Server 或者 NFS Client 上抓包的一般步骤, 参考 How to capture network packets with tcpdump?

关于来自 NFS Server 的抓包信息,联系 NFS Server 厂商或者以NFS Server 的角度使用 port mirror 来获取通信。联系 NetApp 来为您的 filer 和环境获取NetApp filers 的官方推荐。或者你也可以使用 How do I capture a packet trace of NFS operations on a NetApp filer?中所描述的 pktt 命令 。

抓包分析

用 Wireshark 或者 tshark 分析在初始步骤中发生问题的时间点上所抓取的包。确认在运行 Wireshark or tshark 时使用了正确的 TZ shell 变量使得包上的时间戳和发生问题的时间戳保持一致。关于 TZ 变量的更多信息,请参考以下链接NFS packet trace analysis tips and tricks中的"Timestamps in packet traces and matching other event timestamps"文档 。检查例如 retransmits/duplicates,TCP/IP 握手问题,NFS RPC 回应延时等关于网络的抓包问题。
关于在 NFS Client 端收集的 tcpdump 中可能会看到的一些常见例子,请参考 NFS client tcpdump analysis: 3 common failure scenarios

对 vmcore 问题排错

一般来讲,像这样的连接性问题不需要分析 vmcore (copy of kernel memory created by causing a kernel panic)

之后如果在 RHEL 中发现某个 bug,Red Hat 可能需要收集来自 NFS Client 或者 NFS Server 的 vmcore。但其实 vmcore 不是这类问题的初始或常见的排错步骤。

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.