Translated message

A translation of this page exists in English.

RHEL 挂载挂起:nfs: server [...] not responding, still try

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 5, 6, 7, 8, 9
  • NFS Client (nfs-utils 软件包)

Issue

  • NFS 共享挂起,并在 /var/log/messages 中包括以下错误:

    kernel: nfs: server <servername> not responding, still trying
    
    kernel: nfs: server <servername> not responding, timed out
    

Resolution

这个问题的具体解决方案会根据造成这个问题的根本原因的不同而有所不同:

  • 在 NFS 客户端和服务器间的问题
  • NFS 服务器的问题
  • NFS 客户端的问题

NFS 客户端和 NFS 服务器都需要调查。

如果使用非红帽的 NFS 客户端或服务器,请与相关的供应商联系。 调查网络连接的问题,如没有网络连接、网络数据包丢失、系统挂起、NFS 客户端/服务器挂起或速度较慢、存储挂起或速度较慢。

负责维护 NFS 客户端和 NFS 服务器之间的网络的团队,应参与对网络连接问题的调查。

Root Cause

消息解释

  • 如果 NFS 客户端没有收到 NFS 服务器的响应,则会在 syslog 中出现 "server ... not responding, still trying" 信息。
  • 每一条消息都表示,一个 NFS/RPC 请求(例如,一个 NFS WRITE)已发送了 retrans 次并且每次都超时。 当使用 retranstimeo 的默认设置时,这个消息会在 180 秒后输出。 如需更多信息,请参阅 NFS 手册页('man nfs')中的 retranstimeo 选项信息。
  • 注意: 如果 timeo NFS 挂载选项的值非常低(远远小于默认的 600),则会增加生成此消息的可能性和频率。 例如,当设置了 timeo=5 并使用默认的 retrans=2 时,如果 NFS 服务器对 NFS 请求的响应时间超过 0.5 + 1.0=1.5 秒,则会生成这个消息。 在有大量 NFS 工作负载的情况下,NFS 服务器对一个或多个 NFS 请求做出响应的时间超过 1.5 秒并不是一个不正常的情况。 关于 timeoretrans 的更多信息,请参阅 NFS 手册页 (man nfs)。

根本原因的的类别

根本原因可能有以下 3 类:

  • NFS 客户端和服务器之间的问题
  • NFS 服务器中的问题
  • NFS 客户端中的问题

以下是每类问题中的特定示例。

NFS 客户端和 NFS 服务器间的问题

例如,过载、错误配置、交换机出现故障、防火墙问题或网络问题都可能会导致 NFS 请求在 NFS 客户端和 NFS 服务器之间被丢弃。

一些特定实例有:

NFS 服务器中的问题

例如:NFS 服务器过载,或包含会导致 NFS 请求被丢弃的硬件或软件错误。

一些特定实例有:

  • 非红帽 NFS 服务器:存储池级别的磁盘配置存在问题。 NFS 服务器厂商:"具体来说,我们认为池中缺少可用空间以及访问文件的随机性质,会导致重新定位操作的 auto-tierin 失败。"
  • 非红帽的 NFS 服务器:当满足特定条件时会导致一个 TCP 性能问题,一个特定的补丁可以解决这个问题
  • 非红帽的 NFS 服务器:因为配置问题,导致数据通过错误的网络接口发送
  • Red Hat NFS Server:NFS 服务器中的线程数可能太低。 有关此问题的更多信息,请参阅 "How do I increase the number of threads created by the NFS daemon in RHEL 4, 5 and 6?"
  • Red Hat NFS Server: 存在三个不同的错误,当它们同时存在时,可以实现对 NFS 服务器的DoS 攻击:https://access.redhat.com/solutions/544553
  • RHEL7 NFS 客户端或服务器的负载非常大,特定的 NIC 和巨型帧可能会因为默认的/太低的 min_free_kbytes 设置而以静默的方式丢弃数据包:https://access.redhat.com/solutions/4085851

NFS 客户端中的问题

例如,NFS 客户端网络错误配置、NIC 驱动程序或固件错误导致 NFS 请求被丢弃,NFS 客户端的防火墙不允许相关的 NFS 流量。

一些特定实例有:

Diagnostic Steps

排除常见问题的初始步骤

  • 首先,确定问题的时间线。 事件开始的时间是 not responding, still trying 消息的时间戳,再根据 timeoretrans 的值对其进行调整(请参阅根本原因部分中有关 timeoretrans 的信息)。

事件结束的时间是您看到 nfs server: ... OK 信息。

如果没有 OK 信息,则代表问题仍存在 (NFS 服务器仍没有响应)。

如果有多个 not respond 信息,则可能存在多个时间线,或您可能需要根据具体情况进一步调整。

例如:

# 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

由于使用了默认挂载选项,问题开始于 not respond 信息之前的 180 秒。 当出现 '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 服务器上,检查日志来识别问题时间线内可能存在的性能问题。 对于非红帽 NFS 服务器,请联系您的 NFS 服务器厂商,并为其提供调查问题的时间线。

  • 在 NFS 客户端和 NFS 服务器上,检查网络接口和/或网络是否存在问题。 例如:

    • ip -s link 和/或 ethtool 输出中查找丢弃的数据包。 对于这种可能,请参阅:系统因为 rx_fw_discards 丢弃数据包
    • 也可以使用 xsos 工具查找网络接口上的数据包丢失,请参阅: How can I install xsos command in Red Hat Enterprise Linux?
    • 检查 NFS 客户端、NFS 服务器以及从 NFS 客户端到 NFS 服务器所经过的路径中的 MTU 设置。 所有系统都必须配置相同的 MTU。
    • 在 RHEL 上运行 netstat -s ,查找系统外的数据包丢失。 在 TcpExt 下的计数器,如 retransmitscongestion 可能表示有外部数据包丢失。 但请注意,对于系统范围内的 TCP 计数器会自系统引导后不断增加,因此错误可能是与其他 TCP 连接而不是 NFS 连接相关的。
    • 如果使用绑定且通过 TCP 进行 NFS 传输,检查是否有不正确的绑定模式,如 What is the best bonding mode for TCP traffic such as NFS, ISCSI, CIFS, etc? 所述。
  • 识别访问同一 NFS 服务器的任何其他 NFS 客户端,特别是任何相同的 NFS 客户端(挂载相同的导出、相同的挂载选项、相同的红帽版本等)。 在相同的时间线内,任何其他类似的 NFS 客户端是否也有 not respond 信息? 如果其他 NFS 客户端也有相同的问题,这通常代表 NFS 服务器问题,或在 NFS 客户端和 NFS 服务器之间的网络/连接问题。

  • 找出 NFS 客户端和 NFS 服务器之间的任何网络设备,如路由器、交换机或防火墙。 如果可能,检查这些设备在问题时间线内的日志信息或监控统计数据(例如: Cacti、rrdtool)。

使用数据包捕获进行故障排除

这些步骤的目标是将问题归到 3 个类别之一:

  • NFS 客户端和 NFS 服务器间的问题
  • NFS 服务器中的问题
  • NFS 客户端中的问题

在将问题归类后,需要进一步进行故障排除以解决相关问题,这超出了此解决方案文档的范围。

排除此问题的最直接方法至少需要从 NFS 客户端和 NFS 服务器进行数据包捕获。 在某些情况下,可能只能在某一端使用数据包捕获进行诊断(如 NFS 客户端),但强烈建议在两端都进行。

注意:任何 tcpdump 捕获应该只包含有问题 NFS 服务器的数据包。 如果使用 tcpdump,使用 'host' pcap-filter 并提供在 "not responding" 消息中的 NFS 服务器名称或 IP 地址。 如果数据包捕获还包括了除有问题的 NFS 服务器以外的数据,则很可能延迟对根本原因的分析。 示例:

# grep "not responding" /var/log/messages
Sep 29 22:54:39 client kernel: nfs: server server.example.com  not responding, still trying
# tcpdump -i eth0 -s 0 -w /tmp/tcpdump.pcap host server.example.com

使用 tcpdump 收集数据包捕获 (Red Hat NFS 客户端或服务器)

有关如何在任何 Red Hat NFS 服务器或 NFS 客户端上收集数据包捕获的通用步骤,请参阅 How to capture network packets with tcpdump?

在 RHEL NFS 客户端上使用 tcpdump 工具来收集数据包捕获的简单方法是,使用 tcpdump-watch.sh 脚本,如 https://access.redhat.com/articles/4330981#intermittent 所述。

该脚本需要一个参数来指定 NFS 服务器名称或 IP 地址,并监视 /var/log/messages 中的 nfs: server ... not responding, still trying 消息。 当看到这个消息时,tcpdump 将会停止。

请注意:tcpdump-watch.sh 脚本中的默认 tcpdump 参数在多数环境中都可以正常工作,但有些环境可能需要对其进行更改。 例如,在初始的数据包捕获过程中如果存在大的 NFS READ 和 WRITE,和/或有大量数据包被 tcpdump 进程丢弃,则可以将数据包捕获的大小减小到大约 512 字节,使用 "snaplen" 参数 (-s 512)。 另外,如果数据包捕获还收集在 NFS 客户端和 NFS 服务器之间以外的 NFS 流量,您可能需要添加一个或多个 pcap-filters(如 port 2049)来仅捕获发送到 NFS 端口或从 NFS 端口发出的流量。 有关 pcap-filters 的详细信息,请参阅手册页 man pcap-filter

在 NFS 服务器上收集数据包捕获(非红帽 NFS 服务器)

有关从 NFS 服务器收集数据包捕获,或使用端口镜像从 NFS 服务器捕获流量的官方步骤,请联系您的 NFS 服务器厂商。

分析数据包捕获

使用在初始步骤中计算的问题时间线信息,使用 Wireshark 或 tshark 来检查数据包捕获文件。 在运行 Wireshark 或 tshark 时,请确保使用正确的 TZ shell 变量,这样数据包上的时间戳才会与问题的时间线的时间一致。 有关 TZ 变量的更多信息,请参阅 NFS packet trace analysis tips and tricks 中的 "Timestamps in packet traces and matching other event timestamps" 部分。 在数据包捕获中检查网络问题的痕迹,如重新传输/重复数据、TCP/IP 握手问题、NFS RPC 回复的延迟等。

有关 NFS 客户端收集的 tcpdump 中可能会看到的一些常见场景示例,请参阅 NFS client tcpdump analysis: 3 common failure scenarios

使用 vmcore 进行故障排除

在诊断与连接相关的问题时,通常不需要 vmcore (导致内核 panic 的内核内存数据的一个副本)。

如果红帽的支持工程师认为在相关的 RHEL 中存在特定的错误,可能会要求您提供 NFS 客户端或 NFS 服务器的 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.

Comments