RHEL 挂载挂起:nfs: server [...] not responding, still try
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
次并且每次都超时。 当使用retrans
和timeo
的默认设置时,这个消息会在 180 秒后输出。 如需更多信息,请参阅 NFS 手册页('man nfs')中的retrans
和timeo
选项信息。 - 注意: 如果
timeo
NFS 挂载选项的值非常低(远远小于默认的 600),则会增加生成此消息的可能性和频率。 例如,当设置了timeo=5
并使用默认的retrans=2
时,如果 NFS 服务器对 NFS 请求的响应时间超过 0.5 + 1.0=1.5 秒,则会生成这个消息。 在有大量 NFS 工作负载的情况下,NFS 服务器对一个或多个 NFS 请求做出响应的时间超过 1.5 秒并不是一个不正常的情况。 关于timeo
和retrans
的更多信息,请参阅 NFS 手册页 (man nfs
)。
根本原因的的类别
根本原因可能有以下 3 类:
- NFS 客户端和服务器之间的问题
- NFS 服务器中的问题
- NFS 客户端中的问题
以下是每类问题中的特定示例。
NFS 客户端和 NFS 服务器间的问题
例如,过载、错误配置、交换机出现故障、防火墙问题或网络问题都可能会导致 NFS 请求在 NFS 客户端和 NFS 服务器之间被丢弃。
一些特定实例有:
- 一个有问题的安全设备破坏了在 NFS 客户端和 NFS 服务器之间的数据包:
https://access.redhat.com/solutions/1122483 - 交换机上的 port-channel(也称为 EtherChannel,bonding)配置不正确:
https://access.redhat.com/solutions/190183 - 网络中存在一个与 NFS 服务器的 IP 地址相同的系统
- 交换机丢弃 TCP SYN,ACK 数据包:https://access.redhat.com/solutions/1262663
- Riverbed WAN optimizer 设备有问题
- 在 NFS 服务器和 NFS 客户端之间的 Cisco ASA 无法处理 TCP 序列号:
https://access.redhat.com/solutions/2778561
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 流量。
一些特定实例有:
- 客户端上不正确的 MTU (网络)设置导致超时(和 watchdog 重启)
- 在一个系统上选择了巨型数据包 (
MTU=9000
),而在网络的其他系统上没有选择 - 使用了一个不正确/低效的绑定模式:What is the best bonding mode for TCP traffic such as NFS, ISCSI, CIFS, etc?
net.ipv4.tcp_frto
设置可能会触发这个问题:https://access.redhat.com/solutions/1531943- 因为 NFS 客户端中存在一个回归的错误,导致 RPC 层无法正常工作。 如需更多信息,请参阅 RHEL6.7.z: NFS client with kernels 2.6.32-573.10.2.el6 or above hangs with 'not responding, still trying' messages and running processes in _spin_lock
- RHEL6.9 内核中的一个可能的回归问题,涉及 NFS 客户端的 sunrpc TCP 端口重新使用逻辑(https://access.redhat.com/solutions/3018371)
- RHEL7.6: NFSv3 客户端在闲置 5 分钟后挂起并关闭 TCP 连接,后续的 TCP 3 方握手会因为来自 NFS 客户端的重复的 SYN 或非预期的 RST 而失败,如 https://access.redhat.com/solutions/3765711 所述
- RHEL7 NFS 客户端或服务器的负载非常大,特定的 NIC 和巨型帧可能会因为默认的/太低的 min_free_kbytes 设置而以静默的方式丢弃数据包:https://access.redhat.com/solutions/4085851
Diagnostic Steps
排除常见问题的初始步骤
- 首先,确定问题的时间线。 事件开始的时间是
not responding, still trying
消息的时间戳,再根据timeo
和retrans
的值对其进行调整(请参阅根本原因部分中有关timeo
和retrans
的信息)。
事件结束的时间是您看到 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
下的计数器,如retransmits
或congestion
可能表示有外部数据包丢失。 但请注意,对于系统范围内的 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 服务器厂商。
- 对于 NetApp filers,请联系 NetApp 以获得您需要的帮助。 您可以使用
pktt
命令,如 How do I capture a packet trace of NFS operations on a NetApp filer? 所述。 - 对于 EMC Isilon filers,请联系 EMC 以获得您所需的帮助。 您可以使用
isi_netlogger
命令或 web 接口,如 How do I capture a packet trace of NFS operations on a EMC Isilon filer? 所述。
分析数据包捕获
使用在初始步骤中计算的问题时间线信息,使用 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