如何對掛載 EFS 檔案系統時出現 "nfs: server 127.0.0.1 not responding" (nfs: 伺服器 127.0.0.1 無回應) 錯誤進行疑難排解?

2 分的閱讀內容
0

我的 Amazon Elastic File System (Amazon EFS) 伺服器無回應,並顯示 "nfs: server 127.0.0.1 not responding" (nfs: 伺服器 127.0.0.1 無回應) 錯誤訊息。我該如何對此錯誤進行疑難排解?

簡短描述

以下是您可能會看到 server not responding (伺服器無回應) 錯誤的常見原因:

  • NFS 用戶端無法連線至 EFS 伺服器。
  • 執行個體重新啟動或關閉。或者與 EC2 執行個體的任何其他連線中斷。這些事件會導致 NFS 用戶端和 EFS 伺服器之間的網路中斷連線。此行為與 TCP RFC 不一致。中斷連線可能會導致 Amazon EFS 對 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體或 NFS 用戶端的回應遭到數分鐘的封鎖。
  • 使用 NFS 用戶端掛載檔案系統時,並未使用 noresvport 掛載選項。
  • 核心版本可能出現導致 EFS 掛載失敗的問題。例如,RHEL6 有許多已知 NFS 用戶端問題,這會導致類似於檔案系統無回應的狀況。在 RHEL6.X 的舊版核心中,檔案系統可能變得無法使用且無法重新掛載。如果您正在執行下列項目,Amazon EFS 中可能會發生 NFS 連線懸置:
  • RHEL 或者 CentOS 7.6 或以上版本 (3.10.0-957 的核心版本)。
  • 任何其他具有核心版本 4.16 至 4.19 的 Linux 發行版本。

解決方案

1.    掛載檔案系統時,請使用 noresvport 掛載選項。此選項可確認 NFS 用戶端在必須重新建立網路連線時,使用新的 TCP 來源連接埠。使用 noresvport 可確認 EFS 檔案系統在網路復原事件發生後,具有不間斷的可用性。

$   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

如果您使用 EFS 掛載協助程式,則預設會出現 noresvport 選項。如果您使用 NFS 進行掛載,則必須明確新增此參數。如需詳細資訊,請參閱建議的 NFS 掛載選項

2.    檢查核心版本。特定核心版本可能存在問題,如 RHEL 或 CentOS 7.6 或更新版本 (3.10.0-957 的核心版本),可能會導致檔案系統掛載失敗。如果您正在執行這些核心版本其中之一,請重新啟動以復原檔案系統的存取權。若要確認核心版本是否有問題,請在無法執行 ls 時驗證 ps 命令的輸出:

$ ps auxwwwm | grep <mount_point_IP>

如果核心版本有問題,請升級核心。最佳實務是使用目前一代的 Linux NFS4v.1 用戶端或更新版本的用戶端,以獲得更佳效能。

3.    執行下列命令,確認用戶端可連線至伺服器:

telnet <ip-of-efs> 2049

檢閱 /var/log/messages 下的 NFS 客戶端日誌 (EC2 執行個體作業系統日誌) 是否有錯誤。日誌可能位於 /var/log/syslog/var/log/dmesg 目錄下,具體取決於您的作業系統。

此外,如果您使用 EFS 掛載協助程式來掛接檔案系統,請檢閱 /var/log/amazon/efs 目錄下的 EFS util logs。EFS 掛載協助程式具有內建的日誌記錄機制。

4.    確認您可以連線至 EC2 執行個體。

5.    驗證 EC2 是否由於資源過度使用而超載。您可以透過監控 Amazon CloudWatch 中的 EC2 指標,如 CPU 使用率和網路相關指標來執行此操作。資源可能包括 CPU、記憶體、應用程式層級問題等。

  • **記憶體過度使用:**當 RAM 過度使用時,可能會發生此情況。過度使用率意味著執行個體的記憶體空間不足,例如,如果應用程式開始取用更多 RAM。過度使用會導致記憶體不足 (OOM) 錯誤。啟動時,這些錯誤會終止具有較高 OOM 得分或取用更多記憶體的程序。理想情況下,當 OOM 錯誤啟動時,執行個體仍無法存取。
    若要暫時解決 OOM 錯誤,請重新啟動系統以釋放記憶體空間。
    針對長期解決方案,請使用 "atop" 和 "top" 等工具,來監控系統資源使用情況。然後,移至更適合您工作負載的其他執行個體類型。如需詳細資訊,請參閱為什麼我的 EC2 Linux 執行個體會因為資源過度使用而變得無回應?
  • **網路效能:**檢閱執行個體的網路效能。有時,即使 CloudWatch 指標顯示出低網路使用率,也可能會出現微型高載。微型高載會在幾秒鐘內從工作負載傳送大量流量。微型高載通常持續不到一分鐘。這種高載會在 CloudWatch 圖形和 Amazon Elastic Block Store (Amazon EBS) 統計資料中隱藏,因為這些工具中使用的最小間隔為一分鐘。使用 sar,nload,iftop 等工具監控微型高載行為。如需詳細資訊,請參閱為什麼我的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體在平均使用率較低時超出其網路限制?

6.    檢閱 EFS CloudWatch 指標,並確認是否在 EFS 層級發生限流。這意味著 EFS 的執行效能超出其容量。如果您使用高載輸送量模式,請檢閱 BurstBalance CloudWatch 指標,以確定高載平衡是否耗竭。此外,檢閱允許的輸送量 CloudWatch 指標,以確定您使用的輸送量是否高於佈建量。如需高載抵用金的詳細資訊,請參閱 Amazon EFS 高載抵用金如何運作?

如果您的應用程式需要幾乎持續的輸送量,請使用佈建輸送量模式。從「高載輸送量」切換為「佈建輸送量」模式之前,請考慮要佈建的輸送量。如要決定您所需的「佈建輸送量」下限,請檢查過去兩週檔案系統的「平均輸送量」使用量。請注意最高峰值,四捨五入至下一個 MB。如需詳細資訊,請參閱 EFS 中提供了哪些輸送量模式,及我工作負載的正確輸送量模式為何?


相關資訊

對掛載問題進行疑難排解

Amazon EFS 疑難排解

AWS 官方
AWS 官方已更新 2 年前