NFS 伺服器重新啟動後 NFS 過時檔案處理:為什麼會發生這種情況以及產業如何處理這種情況?

NFS 伺服器重新啟動後 NFS 過時檔案處理:為什麼會發生這種情況以及產業如何處理這種情況?

這個問題一直讓我抓狂。

我有一個 NFS 伺服器,在各個客戶端上安裝了 NFS 共用。然而,每當我必須重新啟動 NFS 伺服器時,我總是會在所有客戶端的掛載上出現一堆「陳舊檔案句柄」錯誤,這迫使我必須手動卸載並重新掛載客戶端上的 NFS 共用。

我已經檢查了 NFS 伺服器上的匯出,cat /etc/exports並且在重新啟動後為每個 NFS 導出傳遞相同的 fsid。

我的問題:

  1. 工業界如何處理這個問題?我很難想像系統管理員會手動卸載/重新安裝每個客戶端,或簡單地重新啟動所有連接的客戶端。或者這真的是這樣處理的嗎? (除了標準之外,「我們永遠不會停機,也永遠不需要重新啟動 NFS 伺服器。」)
  2. 為什麼會出現這種情況?這是因為,即使 fsid 可能相同,NFS 伺服器也會重新計算檔案句柄,而這些句柄在重新啟動後可能會不相同?
  3. 我應該在安裝配置中做一些更好的事情來防止這種情況發生嗎?

/etc/fstab:

[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0

這個帖子,建議添加hardintr安裝選項,但這似乎沒有任何區別。

  1. 如果所有其他方法都失敗了,我是否應該回退到使用 bash 腳本來監視掛載/目錄中的過時文件錯誤並讓它執行卸載/掛載循環?

提前致謝。

-扭力扳手

答案1

您使用的是 NFS 版本 3,除了連接埠 2049 中的主 NFS 服務之外,它還需要多個輔助服務rpc.statd。作用。

這些幫助程式服務可能位於隨機連接埠中,並且透過聯絡 RPC 連接埠映射器(通常是rpcbind現代 Linux 上命名的進程)來發現它們。在具有防火牆的現代網路中,這種行為可能會讓事情變得困難:即使您在重新啟動後可能會在看起來確定的連接埠中找到它們,但如果/當您重新啟動NFS 服務時,它們可能會被分配到完全不同的連接埠號碼。

幸運的是,在許多現代類 Unix 系統上,您可以鎖定 NFS 鎖管理器的連接埠號碼(歷史上是這樣rpc.lockd,現在通​​常在核心中實現),rpc.statd並且rpc.mountd.如果您希望 NFSv3 以任何可靠性通過防火牆,這一點至關重要。

對於 RHEL 和相關發行版,您可以透過在下列位置新增以下行來鎖定 NFS 幫助程式連接埠號碼/etc/sysconfig/network

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047

對於 Debian 和相關發行版,您可以將此行新增至/etc/modprobe.d/nfs.conf

options lockd nlm_udpport=4045 nlm_tcpport=4045

……這行在/etc/default/nfs-common

STATDOPTS="-p 4046"

……這行在/etc/default/nfs-kernel-server

RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here

(如果您願意,可以使用不同的連接埠號,但 4045 是 Solaris 中 NFSv3 鎖定管理器的預設端口,並且在 HP-UX 11.31 中對其進行硬編碼。)


但 NFSv3 協定還有另一個缺陷。儘管僅使用 IP 位址即可成功掛載 NFS 共享,但 NFSv3 鎖定協定在內部使用主機名稱。客戶端和伺服器都必須透過正確的名稱相互認識,否則 NFS 檔案鎖定和重新啟動後的鎖定恢復將無法運作。每個系統的「正確名稱」是 報告的名稱uname -n

因此,如果分別在伺服器和用戶端uname -n上傳回,那麼您應該確保這些確切的名稱將解析為主機需要用於 NFS 的 IP 位址。換句話說,伺服器必須能夠使用該名稱聯繫客戶端,反之亦然。server.exampleclient.examplerpc.statdclient.example

如果不這樣做,一開始一切似乎都運作良好......但是當任一端重新啟動時,您可能會收到這些Stale file handle錯誤。

答案2

除了@telcoM 的出色回答之外,我還想建議另外兩種可能的解決方案:

  • 使用noac選項掛載 nfs(請注意,這將要ls在大目錄或許多檔案上發出時會導致效能損失stat

  • 使用 NFS v4.1(v4.0 有一些錯誤導致“過時文件處理”,因此請務必選擇 v4.1 協定)。

相關內容