Xenを実行しているいくつかのLinuxボックスで問題が発生しています。これらはハイパーバイザーとして機能し、マルチパスセットアップを使用してSANに接続され、ゲストVMにストレージを提供します。
2つのパスのいずれかが失敗することがありますが、次のコマンドを実行することですばやく復元できます。
multipath
multipath -ll
問題の根底に立ち、なぜこれが起こっているのかを知る必要があります。ハイパーバイザーがあまりビジーでない場合(ネットワークおよびI/Oに関して)、これは発生しないことに気づきました。また、すべてのサービスを同一の新しいシャーシに移動することで、ハードウェアの問題の可能性を排除しました。 NICモジュールの問題またはカーネルの問題を示す可能性のあるいくつかのシステムログを収集しましたが、マルチパスの失敗はこれの結果である可能性があります!! ??マルチパス時に常に表示されるログを次に示します。低下する:
kernel: BUG: soft lockup - CPU#0 stuck for 60s! [swapper:0]
kernel: BUG: soft lockup - CPU#2 stuck for 60s! [events/2:76]
読みやすくするために、この投稿の最後に完全なログを貼り付けます。今、私のセットアップについてもう少し:
サーバ:
CentOSリリース5.7(最終)2.6.18-274.18.1.el5xen
ファイル名:/lib/modules/2.6.18-274.18.1.el5xen/kernel/drivers/net/igb/igb.ko
バージョン:3.0.6-k2-1
詳細が必要な場合は、ご連絡ください。どんな助けでも大歓迎です。
これはiSCSIセットアップのように見えるため、パスフェイルオーバーが発生する可能性のある領域がいくつかあります。
マルチパスのセットアップは、回線の遅延に非常に敏感であり、iSCSI +イーサネットはファイバーチャネル環境よりも多くの遅延を持ちます。多少の羽ばたきは正常になります。
これはHVMがビジーのときに発生するように見えるため、カーネルNICパスがデータで混雑しているか、CPUが不足している(おそらく両方)ため、マルチパスフェイルオーバーがトリガーされていることを示しています。それについてできることはたくさんありませんが、物事を絞り込むことができるので、なぜそれがしていることをしているのかをよりよく説明できます。
サーバーのロードは非常に簡単で、すでに実行しているように聞こえます。
混雑の診断はより困難です。ネットワークポートの帯域幅モニターに大量のトラフィックが表示されていないのに、投稿したログエントリが発生する場合は、サーバーが内部で詰まっていることを示しています。これらのイベントのいずれかで実際にパケットキャプチャを取得できる場合、タイムスタンプ付きのパケットカウントにより、通過したトラフィックに実際に10秒のギャップが発生しているかどうかがわかります。サーバーが内部的に詰まっていることを示す確かな兆候。
修正問題はドライバー固有である可能性が高く、TCP/IPスタックチューナブルのチューニングの可能性があります。