UCS FC适配器

Question

这是一个场景，我希望@Chopper3 3能在这里加入。我们的SAN结构，我们有一对思科MDS 9513 FC交换机与三个EMC帧和四个思科UCS域直接连接。

我们所看到的行为是，刀片上的CNA正在发送FC中止，这是由于fabric互连传输FCoE暂停帧的结果。Cisco TAC解释说，这种行为是上游拥塞或延迟的结果。我们确实在环境中的大约200个ESXi服务器中看到了相应的数据峰值，报告延迟从100 in上升到2000 in。一些框架和路径似乎比其他的更难一些，这使我相信我们是热点发现一个或多个链接。

使用的刀片是B200M2、B200M3和B420M3服务器。M2系列使用"Palo“适配器M81KR，M3系列使用VIC1240适配器。

由于我不太深入的FC知识，我会感谢一些建议，如何找到这个。

Answer 1

下面是这个故事：

我是从错误的角度看它的。适配器中止正常的症状，表示某个组件在某个地方跟不上。在这种情况下，适配器中止是SAN前端端口忙于处理请求的一个症状。几个不同的条件使这一情况更加复杂。

1)糟糕的驱动程序--我们的UCS固件级别要求ESXi中的匹配驱动程序知道从中止中恢复问题，将其发送到只能通过重新启动才能清除的循环中。

2)变量太多--三个SAN，三个不同的问题都由适配器中止来表示。

3) SAN Bugs -我们不得不禁用VAAI，因为我们的EMC VNX代码中的错误导致了问题。

2015年编辑：

我想更新这个线程，因为很多新的信息也被曝光了，而且检测也很困难。我希望这篇文章能引导一些人走向正确的方向。

1)所有这些实际上仍然是相关的，尽快得到所有的平方和在支持矩阵内。

2)一些UCS2.1版本意外地关闭了优先级流控制(尽管NXOS仍然被配置为这样做)，这会导致一些FCoE流量被视为其他流量，因此有时会出现错误的FC帧。

3)在UCS2.1代码的某个地方，IO节流设置从一个化妆品领域变成了一个活跃领域。旧的“烧录”固件设置是一个IO Throttle计数256，几乎所有主机都使用，尽管Windows驱动程序确实允许您调优。在此代码的某个地方，用于将"256“安装到硬件中的原始默认值"16”成为无效设置，UCSM代码开始将其解释为"2048“，这是最大值。其结果是，一个单一的UCS国际中心适配器被配置成绝对谋杀我们的存储阵列。

那就读读你的发行说明。吸取的教训，我们终于解决了这个问题。

IO节气栓虫：https://tools.cisco.com/quickview/bug/CSCum10869

PFC Bug：https://tools.cisco.com/quickview/bug/CSCus61659