想象一下，如果您有一个 2 节点 Red Hat NFS 集群；每个节点都是 RHEL5.4 64 位，它们共享一个 SAN LUN 来存储数据。每台服务器上的主接口都是 HA 故障转移绑定（bond0、eth0+eth1），并且有一个用于 NFS 的标准浮动集群资源 IP。集群配置使用标准 Red Hat 工具设置，NFS 在 /etc/sysconfig/nfs 中定义了静态端口，以便通过防火墙工作。到目前为止一切顺利，对吧？非常符合惯例——在服务器或集群设置中没有使用任何古怪或奇怪的东西。
问题的核心是当客户端使用 TCP 挂载导出的 NFSv4 共享时；在集群服务重新定位到另一个节点时，新被动节点使用现在丢失的集群 IP 保留与客户端的 2049/tcp（nfs 守护进程）已建立连接，尽管这在技术上是不可能的（据我所知）。“解决方案”是从客户端挂载时转为使用 UDP，因为我们无法弄清楚发生了什么（更重要的是如何修复它）。欢迎提供任何有关原因的线索，详情如下。
Cluster IP: 1.1.1.10
Client IP: 2.2.2.100
开始时，NFS 服务在节点 A 上运行，节点 A 的集群 IP 别名为 bond0:0，并且已安装 SAN。NFS 客户端通过 NFSv4 TCP 连接到集群 IP，一切运行正常。在节点 A 上的 netstat 中，我们看到：
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
一切都如预期。在节点 A 上运行标准“clusvcadm -r nfs-svc -m 节点 B' 命令将 NFS 移至节点 B；在节点 A 和节点 B 的系统日志中，您都会看到正确的消息 - NFS 已停止、IP 已释放/移动、SAN 已卸载/安装等等。在 NFS 客户端上，您会看到一些有关 NFS 服务器未响应的系统日志消息，然后它恢复正常，一切正常。基本上，NFS 重新定位到节点 B 工作正常。
然而回到不再拥有集群 IP 1.1.1.10 的节点 A，您仍然会在 netstat 中看到 2049 上的连接！快速 'rcpinfo -p' 确认该端口上仍有 nfsd。
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
当然，在节点 B 上你会看到同样的事情，因为这是正确的事情。价值 1000 万美元的问题是为什么它仍然出现在节点 A 上？一旦 IP 消失，它就应该被刷新……如果你只是重新启动 nfsd，节点 A 上的连接状态就会变成 FIN_WAIT1，最终会超时。集群 IP 不再显示为节点 A 上的接口，只是在 netstat 中。
而这正是问题的关键所在——如果这个 TCP 幻影 2049 连接仍然在节点 A 上，而您现在将 NFS 服务重新定位到节点 A（因此它再次获得该集群 IP），则无论幻影连接处于 ESTABLISHED 还是 FIN_WAIT1 状态，所有客户端都会停滞并挂载 NFS。只有当幻影连接最终从节点 A 消失时，NFS 客户端才能重新获得其 NFS 挂载——这大约需要 5 到 15 分钟。
我们反复测试了多次，确保问题与防火墙无关，并且是可重复的问题，而不是偶然的。经过几个小时的测试，唯一可行的解决方案是将客户端移至 UDP，从而完全避免该问题。我真的想知道问题出在哪里以及如何修复它。
答案1
我印象中，使用 NFS over TCP 时，短时间内无法从 A->B->A。例如，http://www.spinics.net/lists/cluster/msg08758.html
答案2
使用netstat -p找出正在监听的进程的 PID（或者，您说它是 nfsd，因此从 中找到它的 PID ps），然后strace对其执行 ，您也许可以找出它发生了什么。或者，您可以strace在执行clusvcadm命令之前对其执行 ，看看它是否收到任何信号或其他东西（它可能挂在信号处理程序中或等待某个系统调用返回...）。
如果情况变得更糟，你可以构建一个 nfsd 的调试版本并在 gdb 下运行它，然后执行 clusvcadm 并查看确切地它在做什么……