如何解決與主機探測相關的 autofs 掛載延遲？
我有一個 CentOS 6 和 CentOS 7 客戶端機器的基礎架構，它們依賴 autofs 來自動掛載由我組織中其他地方的服務導出的各種 NFS 文件系統。最近，客戶端開始表現出一種麻煩的行為，即自動掛載這些文件系統變得非常緩慢——而過去掛載需要幾秒鐘，現在開始需要將近兩分鐘。
我想我已經將問題歸結為多種因素：
- 伺服器的主機名有大量不同的解析度 (32)
- 當主機名有多個解析時，autofs 會探測每一個以嘗試拒絕無響應的解析，並從其餘目前具有最佳響應時間的解析中選擇一個
- autofs 向每個伺服器發出的兩個探測 RPC 中的一個似乎對我的所有伺服器都持續超時。
這是調試日誌的代表性摘錄：
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0 Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20 Jul 13 15:48:21 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.84) proto 6 version 0x20這顯示了一個完整的探測以及三秒後下一個探測的開始。除了延遲之外，我看不到任何有關對第二個 RPC 的響應的資訊。這對我來說是“超時”。雖然超時單獨只有 3 秒，但將其乘以 32 台機器意味著在實際嘗試掛載之前超時超過一分半。
客戶端執行 CentOS 6 和 7 的標準 NFS 客戶端堆棧：分別由 CentOS 打包的 nfs-utils 1.2.3 和 autofs 5.0.5 或 nfs-utils 1.3.0 和 autofs 5.0.7。客戶處於配置管理之下，因此我相信他們在問題開始出現之前就沒有進行任何軟體或配置更改。
伺服器正在執行 Ganesha 使用者空間 NFS 堆棧，特別是，它們不支持 NFS4 可能是相關的，儘管這在過去沒有出現問題。伺服器管理聲稱沒有故意進行配置更改，但允許可能已安裝例行軟體更新。
所以，最後，問題如標題所示：如何解決主機探測導致的掛載延遲？Ganesha 中是否有相關的配置設置，其預設設置可能已更改？或者，有沒有辦法配置 autofs 以避免嘗試失敗的 RPC？還是我可能錯誤地辨識了問題？
打開 autofs 配置參數
use_hostname_for_mounts似乎可以解決這個問題，但據我了解，這是以失去對故障和單個伺服器過載的彈性為代價的。沒有更好的辦法嗎？
日誌消息中的關鍵線索似乎是記錄為“proto 6”的探測成功，而記錄為“proto 17”的探測失敗。6 和 17 分別是代表 TCP 和 UDP 的 IP 傳輸協議號。
儘管 NFS 傳統上通過 UDP 提供服務，但大多數堆棧都支持通過 TCP 提供服務，並且在這種情況下，伺服器始終配置為僅通過 TCP 提供 NFS。然而，這並沒有出現問題，直到伺服器上出現一個尚未表徵的更改，結果導致 nfs/udp 流量隨後被靜默丟棄，而不是被適當的 ICMP 響應拒絕。這很可能是由防火牆更改引起的，但我目前不能排除伺服器上的應用程序級別更改。
無論如何，我通過
proto=tcp在 autofs 映射文件中添加每個受影響文件系統的掛載選項來解決客戶端的問題。Autofs 足夠聰明，一旦該選項到位，就放棄了 UDP 風格的探測。不僅問題得到了解決，而且現在的掛載性能似乎比超時問題開始之前還要好一些。