这就是场景，我希望@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 节流计数 256，几乎所有主机都使用这个值，尽管 Windows 驱动程序允许您调整这个值。在此代码的中间某个地方，用于将“256”安装到硬件中的原始默认值“16”变成了无效设置，UCSM 代码开始将其解释为“2048”，这是最大值。结果是，单个 UCS VIC 适配器被配置成绝对会毁掉我们的存储阵列。
因此，请阅读您的发行说明。吸取教训，我们终于解决了这个问题。