RHCS 5 NFS 集群節點在重定位時未釋放 TCP 2049

想像一下，如果你有一個 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 守護程序）ESTABLISHED 連接，即使這在技術上是不可能的（據我所知）。“解決方案”是在從客戶端安裝時轉向使用 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 node-B ”命令將 NFS 移動到節點 B；在節點 A 和節點 B 的系統日誌中，您會看到正確的消息 - NFS 被停止、IP 被釋放/移動、SAN 解除安裝/安裝等等。在 NFS 客戶端上，您會看到一些關於 NFS 伺服器沒有響應的 syslog 消息，然後它恢復正常，一切都很好。基本上，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），所有客戶端都會因 NFS 停止並死掉無論幻象連接是否處於 ESTABLISHED 或 FIN_WAIT1 狀態，都掛載。只有當虛擬連接最終從節點 A 消失時，NFS 客戶端才能重新獲得其 NFS 掛載——這大約需要 5 到 15 分鐘。

我們來回測試了很多次，確保它與防火牆無關，並且作為一個問題是可重複的，而不僅僅是一些僥倖。在許多小時結束時，唯一可行的解​​決方案是將客戶端移動到 UDP 並完全避免該問題。我真的很想知道什麼壞了以及如何修復它。

我的印像是，使用基於 TCP 的 NFS，您無法在短時間內從 A->B->A 轉換。參見，例如，http://www.spinics.net/lists/cluster/msg08758.html

用於netstat -p找出正在偵聽的程序的 PID（或者，你說它是 nfsd，所以從 PID 中找出它的 PID ps），然後strace對其進行操作，您也許可以弄清楚它發生了什麼。或者，也許您可以strace在執行命令之前對其進行操作clusvcadm，看看它是否收到任何信號或其他東西（它可能掛在信號處理程序中或等待某個系統呼叫返回……）。

如果最壞的情況發生，您可以建構一個調試版本的 nfsd 並在 gdb 下執行它並執行 clusvcadm 並查看它在做什麼……

引用自：https://serverfault.com/questions/175672