networking/多path丢弃

我有几个运行xen的linux系统的问题。他们充当虚拟机pipe理程序，并使用多path设置将它们连接到SAN，以向guest虚拟机提供存储。

时不时的两个path之一失败，但它可以通过运行快速恢复：

multipath multipath -ll

我需要深入了解问题的原因，并找出原因。我注意到，当pipe理程序不太忙（networking和I / O明智）时，不会发生这种情况。我也通过将所有服务移动到相同的新机箱来消除了可能的硬件问题。我已经收集了几个系统日志，可能表明NIC模块问题或内核问题，多path失败可能只是这个结果！以下是多path下降时总是显示的一些日志：

 kernel: BUG: soft lockup - CPU#0 stuck for 60s! [swapper:0] kernel: BUG: soft lockup - CPU#2 stuck for 60s! [events/2:76]

在这篇文章的最后我会粘贴完整的日志，以便于阅读。现在多一点关于我的设置：

Internet访问通过eth0和eth2（绑定）
SAN多path访问通过eth1和eth3进行设置

服务器：

Supermicro SuperServer 6016T-NTRF
Intel（R）Xeon（R）CPU E5645
英特尔公司82576千兆networking
CentOS版本5.7（最终）2.6.18-274.18.1.el5xen
filename：/lib/modules/2.6.18-274.18.1.el5xen/kernel/drivers/net/igb/igb.ko
版本：3.0.6-k2-1
logging01
日志02

如果有人需要更多的细节，请联系。任何帮助都感激不尽。

由于这似乎是一个iSCSI设置，有几个地方可以进行path故障转移。

简单的以太网片状 。数据包被丢弃，从而触发故障转移到其他path，而不是等待重新发送和重新组装。
较简单的以太网问题 。交换机端口短暂翻转，触发故障切换。
多path堆栈中的东西触发了故障转移 。多path比普通的TCP / IP对networking怪异性更敏感，所以不会等待重build连接。它会故障转移。
networking堆栈中的东西出错了 。这里有几种可能性，但从错误信息的外观来看，这可能是问题所在。

多path设置对线路上的延迟非常敏感，iSCSI +以太网将比光纤通道环境更多。一些扑动将是正常的。

由于这似乎发生在HVM忙时，这表明内核NICpath正在获取数据拥挤或饿死CPU（可能两者），这是触发多path故障切换。对此你可以做的不多，但你可以缩小范围，这样你就可以更好地解释为什么它正在做什么。

服务器负载很容易，听起来像你已经做到了。

诊断拥塞是困难的。如果您的networking端口带宽监视器没有显示大量的stream量，但是您发布的日志条目仍然发生，这是服务器内部堵塞的迹象。如果在这些事件中的一个事件中，您实际上可以获取数据包捕获，则带有时间戳的数据包计数将告诉您是否真的在通过的stream量中看到10秒的间隔; 肯定的迹象表明服务器内部堵塞。

解决这个问题很可能是针对驱动程序的，可能会调整TCP / IP协议栈的可调参数。