這是場景，我希望@Chopper3 能在這裡插話。對於 SAN 結構，我們有一對 Cisco MDS 9513 FC 交換機，具有三個 EMC 框架和四個直接連接的 Cisco UCS 域。
我們看到的行為是，由於交換矩陣互連傳輸 FCoE 暫停幀，刀片上的 CNA 正在發送 FC 中止。思科 TAC 解釋說，此行為是上游擁塞或延遲的結果。我們確實看到環境中 200 台左右 ESXi 伺服器的資料出現了相應的峰值，報告延遲峰值從 100 毫秒到 2000 毫秒。某些框架和路徑似乎比其他框架和路徑受到的打擊更大，這使我相信我們正在對一個或多個連結進行熱點定位。
刀鋒伺服器為B200M2、B200M3、B420M3伺服器。 M2系列使用「Palo」轉接器M81KR，M3系列使用VIC1240轉接器。
由於我對 FC 的了解不太深入，因此我希望得到一些有關如何解決此問題的建議。
答案1
這是關於這個的故事：
我從錯誤的角度看待它。適配器中止正常症狀，表示某處的某些組件沒有跟上。在這種情況下，適配器中止是 SAN 前端連接埠太繁忙而無法滿足請求的症狀。一些不同的條件使情況變得更加複雜。
1) 錯誤的驅動程式 - 我們的 UCS 韌體層級規定了 ESXi 中的匹配驅動程序，該驅動程式存在從中止恢復的已知問題，將其發送到只能透過重新啟動才能清除的循環中。
2) 變數太多 - 三個 SAN，三個不同的問題都以適配器中止為代表。
3) SAN 錯誤 - 由於 EMC VNX 程式碼中的錯誤導致出現問題，我們不得不停用 VAAI。
2015年編輯：
我想更新這個帖子，因為也有很多新資訊被曝光，而檢測是非常困難的。我希望這篇文章能夠引導一些人走向正確的方向。
1）上述所有內容實際上仍然相關，盡快將所有這些平方並放入支援矩陣內。
2) 某些 UCS 2.1 版本會意外關閉（儘管 NXOS 仍被配置為執行此操作）優先流量控制，這會導致某些 FCoE 流量被像其他流量一樣對待，因此有時會出現亂序 FC 訊框。
3) 在 UCS 2.1 代碼中間的某個位置，IO 節流設定從裝飾欄位變成活動欄位。舊的「燒入」韌體設定是 IO Throttle 計數為 256，所有主機幾乎都使用該計數，儘管 Windows 驅動程式確實允許您對此進行調整。在此代碼中間的某個位置，用於將“256”安裝到硬體中的原始預設值“16”變成了無效設置，UCSM 代碼開始將其解釋為“2048”，這是最大值。結果是，單一 UCS VIC 適配器被配置為完全破壞我們的儲存陣列。
因此，請閱讀您的發行說明。吸取教訓，我們終於解決了這個問題。