想象一下，如果你有一个2节点的红帽NFS群集， 每个节点都是RHEL5.4 64位，它们共享数据的SAN LUN。 每个服务器上的主接口都是HA故障转移绑定（bond0，eth0 + eth1），并且NFS有一个标准的浮动群集资源IP。 群集configuration使用标准的红帽工具进行设置，NFS在/ etc / sysconfig / nfs中定义了静态端口，以便通过防火墙工作。 到目前为止这么好，对吧？ 非常靠书，最佳实践 – 在服务器或群集设置中使用的并不是什么奇怪的或奇怪的东西。
问题的核心是客户端使用TCP来挂载导出的NFSv4共享; 在一个集群服务重定位到另一个节点上，新被动节点保留了一个2049 / tcp（nfs守护进程）ESTABLISHED连接，使用现在丢失的集群IP给客户端，尽pipe这在技术上是不可能的（据我所知）。 “解决scheme”是从客户端挂载时转移到使用UDP，因为我们无法弄清楚发生了什么（更重要的是如何解决这个问题）。 任何线索，为什么欢迎，细节如下。
Cluster IP: 1.1.1.10 Client IP: 2.2.2.100 从节点-A开始，NFS服务正在运行，节点-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 node-B ”命令将NFS移动到节点B; 在节点A和节点B的系统日志中，您都可以看到适当的消息 – NFS正在停止，IP被释放/移动，SAN卸载/挂载等等。 在NFS客户端上，你会看到一些关于NFS服务器没有响应的系统日志消息，那么它会回来，一切都很好。 基本上，NFS重新定位到节点B工作正常。
但是 ，回到不再拥有集群IP 1.1.1.10的节点A上，您仍然可以在2049年的netstat中看到一个连接！ 一个快速的' 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 phantom 2049连接仍然在节点A上，并且你现在将NFS服务重新定位到节点A（所以它再次获得该集群IP），所有的客户端都会停顿并且随着NFS安装该幻像连接是否处于ESTABLISHED或FIN_WAIT1状态。 只有当虚拟连接最终从节点A消失时，NFS客户端才能重新获得它们的NFS挂载 – 大约是5到15分钟。
我们多次来回testing，确保它不是防火墙相关的，它是可重复的问题，而不仅仅是一些侥幸。 在几个小时的最后，唯一可行的解决scheme是将客户端移动到UDP，并完全避免这个问题。 我真的想知道什么是坏的，如何解决它。
我的印象是，使用NFS over TCP，你不能在短时间内从A-> B-> A去。 参见例如http://www.spinics.net/lists/cluster/msg08758.html
使用netstat -p来计算正在监听的进程的PID（或者，你说它是nfsd，所以find它是PID的PID），然后做一个strace ，你也许可以弄清楚是怎么回事它。 或者，也许你可以在执行clusvcadm命令之前对它执行操作，看看它是否得到了任何信号或者什么东西（它可能挂在信号处理程序中，或等待某个系统调用返回…）。
如果最坏的情况发生，你可以构build一个nfsd的debugging版本，并在gdb下运行它，并执行clusvcadm，看看它在做什么。