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