服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

RHCS 5 NFS群集节点在重定位时不释放TCP 2049

想象一下,如果你有一个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 […]