サーバーがロックアップすると、他のサーバーがネットワークから切り離されるのはなぜですか？

数十台のProxmoxサーバー（ProxmoxはDebian上で実行されます）があり、月に1回程度、そのうちの1台にカーネルパニックが発生してロックアップします。これらのロックアップに関する最悪の部分は、サーバーがクラスターマスターとは別のスイッチ上にある場合、そのスイッチ上の他のすべてのProxmoxサーバーは、実際にクラッシュしたサーバーを見つけて再起動するまで応答を停止することです。

この問題をProxmoxフォーラムで報告したときに、Proxmox 3.1にアップグレードするようにアドバイスされました。私たちは過去数か月間それを行っています。残念ながら、Proxmox 3.1に移行したサーバーの1つは、金曜日にカーネルパニックでロックされ、クラッシュしたサーバーを見つけて再起動するまで、同じスイッチ上にあるすべてのProxmoxサーバーにネットワーク経由で到達できませんでした。

ええと、スイッチ上のほとんどすべてのProxmoxサーバー...同じスイッチ上のProxmoxサーバーが、Proxmoxバージョン1.9のままであったことは、影響を受けなかったことが興味深いものでした。

クラッシュしたサーバーのコンソールのスクリーンショットは次のとおりです。

サーバーがロックアップすると、同じスイッチ上にある、Proxmox 3.1を実行していた残りのサーバーが到達不能になり、次の問題が発生しました。

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
...etc...

uname-ロックされたサーバーの出力：

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v出力（省略形）：

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

2つの質問：

1. カーネルパニックの原因となる手がかり（上記の画像を参照）

2. ロックされたサーバーが再起動されるまで、同じスイッチとバージョンのProxmox上の他のサーバーがネットワークから切断されるのはなぜですか？（注：同じスイッチ上に、以前のバージョンの1.9バージョンのProxmoxを実行していた他のサーバーは影響を受けませんでした。また、同じ3.1クラスター内の他のProxmoxサーバーは影響を受けず、同じスイッチ上にありませんでした。）

アドバイスを事前にありがとう。

問題の原因が1つだけではなく、要因の組み合わせにあると私は確信しています。これらの個々の要素が何であるかは明確ではありませんが、おそらく1つの要素はネットワークインターフェイスまたはドライバであり、別の要素はスイッチ自体にあります。したがって、この特定のブランドのスイッチをこの特定のブランドのネットワークインターフェイスと組み合わせた場合にのみ、問題が再現する可能性が非常に高いです。

問題のトリガーは、1つの個別のサーバーで発生した何かで、カーネルパニックが発生し、なんとかしてスイッチ全体に影響を及ぼしているようです。これはおそらく聞こえますが、トリガーがどこか別の場所にある可能性はほぼ同じです。

スイッチまたはネットワークインターフェイスで何かが発生しているため、スイッチでカーネルパニックとリンクの問題が同時に発生している可能性があります。つまり、カーネルにパニックが発生していなくても、トリガーによってスイッチの接続が切断された可能性があります。

個々のサーバーで何が起こり、他のサーバーに影響を与える可能性があるかを尋ねる必要があります。それは可能ではないはずなので、説明にはシステムのどこかに欠陥が含まれている必要があります。

クラッシュしたサーバーとスイッチとの間のリンクがダウンしたり不安定になったりしただけの場合は、他のサーバーへのリンク状態に影響はありません。もしそうなら、それはスイッチの欠陥として数えられるでしょう。トラフィックに関しては、クラッシュしたサーバーが接続を失うと、他のサーバーはわずかにトラフィックが少なくなるはずです。

これにより、スイッチの設計上の欠陥が発生している可能性が高いと思います。

ただし、リンクの問題は、1つのサーバーの問題がスイッチ上の他のサーバーにどのように問題を引き起こす可能性があるかを説明しようとするときに最初に探す説明ではありません。ブロードキャストストームの方がわかりやすいでしょう。しかし、カーネルパニックを持つサーバーとブロードキャストストームの間にリンクがあるのでしょうか。

不明なMACアドレス宛てのマルチキャストとパケットは、ほぼブロードキャストと同じように扱われるため、そのようなパケットのストームもカウントされます。パニックになったサーバーが、ネットワークを介してスイッチで認識されないMACアドレスにクラッシュダンプを送信しようとしているのでしょうか。

それがトリガーである場合、他のサーバーで問題が発生しています。パケットストームはネットワークインターフェイスでこの種のエラーを引き起こすべきではないためです。Reset adapter unexpectedlyパケットストームのようには聞こえません（これにより、パフォーマンスが低下するだけでエラーは発生しません）。また、リンクの問題のようにも聞こえません（リンクに関するメッセージが表示されるはずですが、エラーではありません）見る）。

そのため、スイッチによってトリガーされるネットワークインターフェイスハードウェアまたはドライバーに欠陥がある可能性があります。

追加の手がかりを与えることができるいくつかの提案：

1. 他の機器をスイッチに接続して、問題が発生したときにスイッチに表示されるトラフィックを確認できますか（静かになるか、洪水が発生するかと思います）。
2. 別のドライバーを使用して、サーバーの1つのネットワークインターフェイスを別のブランドに置き換えて、結果の違いを確認することはできますか？
3. スイッチの1つを別のブランドに交換することはできますか？スイッチを交換することで、問題が複数のサーバーに影響しなくなることが期待されます。さらに興味深いのは、カーネルパニックの発生を停止するかどうかです。

イーサネットドライバーまたはハードウェア/ファームウェアのバグのように聞こえますが、これは危険信号です。

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

これらは以前に見たことがあり、サーバーをオフラインにすることができます。インテルのイーサネットカードにあったかどうかは正確には覚えていませんが、そう思います。イーサネットカード自体のバグに関連している可能性もあります。そのような問題がある特定のインテルイーサネットカードについて何かを読んだことを覚えています。しかし、私は記事のリンクを失いました。

これのトリガーは、使用されているドライバー（バージョン）に部分的に依存していると思います。古いバージョンのソフトウェアで問題なく動作するという事実は、それを確認しているようです。ベンダーが独自のカスタムカーネルを使用していると言い、特定のイーサネットハードウェアに使用されているイーサネットドライバーモジュールを更新してみます。ベンダーからのものか、公式のカーネルソースツリーからのものです。

また、イーサネットハードウェアの結合についても検討します。通常、サーバーには2つのイーサネットポートが搭載されているか、カードに追加されています。そうすれば、1つのイーサネットカードでこの問題が発生した場合、もう1つのイーサネットカードで問題が発生します。私は「カード」という言葉を使用していますが、それはもちろんすべてのイーサネットハードウェアに当てはまります。

また、イーサネットハードウェアを交換すると修正できます。新しい（インテル）イーサネットカードを交換または追加して、代わりにそれを使用してください。問題がハードウェア/ファームウェアにある場合、新しいカードに修正（または古い？）がある可能性があります。