VNX：NFS 資料存放區間歇性地在單一主機上離線

一個或多個 NFS 資料存放區一次進入單一主機上的 APD （所有路徑中斷） 狀態。這可能發生在不同主機上的不同數據存儲上，也可能發生在多個主機上的同一數據存儲上。通常這是隨機和間歇性的，可透過在 ESXi 主機上關閉再增加乙太網路連接埠，或者重新開機來解決。它不一定總是發生在同一個數據存儲或同一個主機上。

此問題的主要特點是仍可從其他主機存取受影響的資料存放區或 NFS 匯出。如果所有主機的資料存放區都已關閉，則不太可能發生此問題。如果無法通過關閉網路埠或重新啟動主機來解決，則也不會是此問題。

這會影響 VNX1、VNX2 和 eNAS 產品。

VMware 支援可能會建議設定 NFS。將 MaxQueueDepth 變更為 64，但 Dell 目前沒有此值的建議。但是，它不太可能解決此特定問題。

工程部門發現在某些情況下處理 TCP 傳送視窗計算的方式存在問題。實質上，VNX 會在某一時刻不恰當地將 TCP 傳送視窗值設定為 0。這不允許 VNX 將任何新資料傳送至它在該連線上與之通訊的主機。VNX 仍可確認 TCP 層上的傳入資料，但無法傳送任何 NFS 回應。

據我們目前所知，我們目前只看到此行為影響 ESXi NFS 資料存放區，因為 ESXi 有時會以特定方式執行 TCP 確認。在某些時間點，即使 VNX 的傳輸佇列中有資料，ESXi 也不會隨其下一個資料包一起傳送確認函，而是使用額外的個別確認。此行為使 DM 認為傳輸是單向的，並將其置於標頭預測模式。如果 ESXi TCP 確認行為在從 DM 傳輸超過 2GB 的資料時保持一致，則 DM 會將 TCP 傳送視窗慢慢縮短至 0，使該特定 TCP 連線只能從一個方向傳送資料 （從主機傳送至陣列）。如果資料移動者在該 2GB 傳輸中收到具有新 ACK 編號的資料包，或有任何導致重新傳輸的封包遺失，則不會遇到此問題。

ESXi 會在資料存放區執行活動訊號，以判斷其是否仍可使用。此檢測信號是對數據存儲上特定檔的 GetAttr 請求。如果失敗，ESXi 主機會將數據存儲標記為 APD。由於 VNX 無法回覆來自 ESXi 主機的 GetAttr 要求，而其 TCP 傳送視窗設為 0，因此會將資料存放區標記為無法存取。無論出於何種原因，ESXi 都不會嘗試重置連接，這也可以解決此問題。這就是為什麼重新開機或關閉並升級主機上的網路埠可以恢復訪問的原因。

TCP 發送視窗是為每個連接單獨計算的。因此，其他數據存儲保持在線狀態，前提是它們未面臨相同的情況。數據存儲本身不是問題，因此其他主機應該仍然能夠訪問它，除非它們在連接到此特定數據存儲時遇到相同的情況。

如果存在涵蓋數據存儲從連線到離線狀態的數據包跟蹤，則可以確認此問題。

TCP 傳送視窗計算行為將在 7.1 和 8.1 代碼版本 （VNX1、VNX2 和 eNAS） 的未來程式碼版本中修正。目前有可用的修正程式，如果需要立即修正，請聯絡支援提出要求，並排定重新開機/容錯移轉中斷。