为什么服务器locking将其他服务器closures？

我几乎可以肯定你的问题不是由一个单一的因素造成的，而是由多种因素共同造成的。 这些个人因素是不确定的，但最有可能的一个因素是networking接口或驱动程序，另一个因素是交换机本身。 因此，这个问题很可能只能通过与这个特定品牌的networking接口相结合的这个特定品牌的交换机来再现。

你似乎触发了这个问题是发生在一个单独的服务器上，然后有一个内核恐慌有影响，以某种方式pipe理传播交换。 这听起来很可能，但我认为这很可能是触发器在别的地方。

可能是交换机或networking接口上发生了某些事情，这同时会导致交换机上出现内核恐慌和链接问题。 换句话说，即使内核没有发生内核恐慌，触发器也可能会降低交换机的连通性。

一个人不得不问，单个服务器上可能发生什么情况，这可能会对其他服务器产生这种影响。 这不应该是可能的，所以解释必须涉及系统中的某个缺陷。

如果它只是坠毁的服务器和交换机之间的链路断开或变得不稳定，那么这应该不会影响到其他服务器的链路状态。 如果是这样的话，这将被视为交换机中的缺陷。 在stream量方面，一旦崩溃的服务器丢失连接，其他服务器应该看到的stream量略less，这不能解释为什么他们看到他们所做的问题。

这导致我相信交换机上的devise缺陷是可能的。

然而，当试图解释一台服务器上的问题如何导致交换机上的其他服务器出现问题时，链接问题不是第一个解释。 广播风暴将是一个更明显的解释。 但是，有内核恐慌的服务器和广播风暴之间可能存在链接吗？

发往未知MAC地址的多播和数据包或多或less与广播相同，所以这样的数据包的风暴也会被计算在内。 paniced服务器可能试图通过networking发送故障转储到交换机无法识别的MAC地址？

如果这是触发器，那么在其他服务器上出现问题。 因为数据包风暴不应该导致这种networking接口上的错误。 Reset adapter unexpectedly不听起来像一个数据包风暴（这应该只会导致性能下降，但没有错误，这样），它听起来不像一个链接问题（这应该导致有关链接的消息，但不是错误你看到）。

所以networking接口硬件或驱动程序中可能存在一些由交换机触发的缺陷。

一些build议可以提供更多的线索：

1. 您能否将其他设备连接到交换机，并查看问题出现时交换机上显示的stream量（我预测stream量安静或者发现洪水）。
2. 是否有可能使用不同的驱动程序replace其中一个服务器上的networking接口，以查看结果是如何变化的？
3. 是否有可能用不同品牌replace其中一个交换机？ 我希望更换交换机将确保问题不再影响多个服务器。 更有意思的是，它也能阻止内核恐慌的发生。

这听起来像是一个在以太网驱动程序或硬件/固件的错误，这是一个红旗：

 e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly 

我以前见过这些，它可以使服务器脱机。 我不记得是否在英特尔以太网卡，但我相信。 它甚至可能与以太网卡本身的错误有关。 我记得阅读有关特定的以太网卡有这样的问题的东西。 但是我失去了文章的链接。

我可以想象这个触发器部分依赖于正在使用的驱动程序（版本），事实上老版本的软件工作正常似乎证实了这一点。 您说供应商使用他们自己的定制内核，尝试更新用于您的特定以太网硬件的以太网驱动程序模块。 来自您的供应商的一个或官方内核源代码树中的一个。

也考虑绑定您的以太网硬件，通常服务器将有两个以太网端口，板载和/或添加卡。 这样，如果一个以太网卡有这个问题，另一个会拿起。 我使用单词“卡”，但它当然适用于任何以太网硬件。

另外更换以太网硬件可以解决它。 要么replace或添加一个较新的（英特尔）以太网卡，并使用它。 如果问题出在硬件/固件上，则更新的卡有修复（或更旧？）的可能性。