サーバーのロックアップが他のサーバーをネットワークからノックアウトするのはなぜですか？
数十台の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つの質問：
カーネルパニックの原因となる手がかりはありますか（上の画像を参照）？
ロックされたサーバーが再起動されるまで、同じスイッチとバージョンのProxmox上の他のサーバーがネットワークからノックオフされるのはなぜですか？ （注：影響を受けなかった古い1.9バージョンのProxmoxを実行していた同じスイッチ上の他のサーバーがありました。また、同じ3.1クラスター内の他の同じスイッチ上になかったProxmoxサーバーは影響を受けませんでした。）
アドバイスをよろしくお願いします。
あなたの問題は、単一の要因だけでなく、要因の組み合わせによって引き起こされているとほぼ確信しています。これらの個々の要因が何であるかは定かではありませんが、おそらく1つの要因はネットワークインターフェイスまたはドライバーのいずれかであり、別の要因はスイッチ自体にあります。したがって、この特定のブランドのネットワークインターフェイスと組み合わせたこの特定のブランドのスイッチでのみ問題を再現できる可能性が非常に高くなります。
問題のトリガーは、1つの個別のサーバーで発生している何かであり、カーネルパニックが発生し、何らかの形でスイッチ全体に伝播する影響があるようです。これは可能性が高いように聞こえますが、トリガーがどこかにある可能性はほぼ同じだと思います。
スイッチまたはネットワークインターフェイスで何かが発生している可能性があります。これにより、スイッチでカーネルパニックとリンクの問題が同時に発生します。つまり、カーネルにカーネルパニックが発生していなくても、トリガーによってスイッチの接続がダウンした可能性があります。
個々のサーバーで何が起こり、他のサーバーにこの影響を与える可能性があるのかを尋ねる必要があります。それは不可能なはずなので、説明にはシステムのどこかに欠陥が含まれている必要があります。
クラッシュしたサーバーとスイッチがダウンしたり不安定になったりしただけの場合は、他のサーバーへのリンク状態に影響はありません。もしそうなら、それはスイッチの欠陥として数えられます。また、トラフィックに関しては、クラッシュしたサーバーが接続を失うと、他のサーバーのトラフィックはわずかに少なくなるはずです。これは、他のサーバーが問題を抱えている理由を説明できません。
これにより、スイッチの設計上の欠陥が発生する可能性が高いと私は信じています。
ただし、リンクの問題は、あるサーバーの問題がスイッチ上の他のサーバーに問題を引き起こす可能性があることを説明しようとするときに最初に探す説明ではありません。ブロードキャストストームは、より明白な説明になります。しかし、カーネルパニックを起こしているサーバーとブロードキャストストームの間にリンクがある可能性はありますか？
不明なMACアドレス宛てのマルチキャストおよびパケットは、多かれ少なかれブロードキャストと同じように扱われるため、そのようなパケットのストームもカウントされます。パニック状態のサーバーが、ネットワークを介してスイッチで認識されないMACアドレスにクラッシュダンプを送信しようとしている可能性がありますか？
それがトリガーである場合は、他のサーバーで問題が発生しています。パケットストームがネットワークインターフェイスでこの種のエラーを引き起こすことはないはずだからです。 Reset adapter unexpectedlyはパケットストームのようには聞こえません（パフォーマンスの低下を引き起こすだけでエラーは発生しません）。また、リンクの問題のようにも聞こえません（リンクのダウンに関するメッセージが表示されるはずですが、エラーは発生しません）。あなたが見ている）。
そのため、スイッチによってトリガーされるネットワークインターフェイスハードウェアまたはドライバーに何らかの欠陥がある可能性があります。
追加の手がかりを与えることができるいくつかの提案：
- 他の機器をスイッチに接続して、問題が発生したときにスイッチに表示されるトラフィックを確認できますか（静かになるか、洪水が発生すると予測します）。
- 別のドライバーを使用して、サーバーの1つのネットワークインターフェイスを別のブランドに置き換えて、結果がどのように異なるかを確認することは可能でしょうか？
- スイッチの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
私は以前にこれらを見たことがあり、サーバーをオフラインにする可能性があります。それがIntelイーサネットカードにあったかどうかは正確には覚えていませんが、そう信じています。イーサネットカード自体のバグに関連している可能性もあります。そのような問題を抱えている特定のインテルイーサネットカードについて何か読んだことを覚えています。しかし、私は記事のリンクを失いました。
これのトリガーは、使用されているドライバー（バージョン）に部分的に依存していると思います。古いバージョンのソフトウェアが正常に機能しているという事実は、それを確認しているようです。ベンダーが独自のカスタムカーネルを使用しているとのことですが、特定のイーサネットハードウェアに使用されているイーサネットドライバモジュールを更新してみてください。ベンダーからのものか、公式のカーネルソースツリーからのものです。
また、イーサネットハードウェアのボンディングも検討してください。通常、サーバーには、オンボードまたはアドオンカードの2つのイーサネットポートがあります。そうすれば、一方のイーサネットカードでこの問題が発生した場合、もう一方のイーサネットカードが問題を解決します。私は「カード」という言葉を使用していますが、もちろんすべてのイーサネットハードウェアに適用されます。
また、イーサネットハードウェアを交換することで修正できます。新しい（Intel）イーサネットカードを交換または追加して、代わりに使用してください。問題がハードウェア/ファームウェアにある場合は、新しいカードに修正がある（または古い？）可能性があります。