4

NServiceBus を使用して、負荷分散された大量の環境で MSMQ の問題が発生しています。

この環境は次のようになります。1 つの F5 が Web トラフィックをラウンド ロビン経由で 6 つのアプリケーション サーバーに分散します。これらの 6 つのサーバーのそれぞれは、クラスタに存在するリモート マシン上の Bus.Send to 1 キューを使用します。

通常の使用時のイベント スループットは、サーバーあたり 1 秒あたり約 5 ~ 10 です。したがって、負荷に応じて、環境全体で 1 秒あたり 30 ~ 60 のイベントが発生します。

私たちが見ている問題は、アプリケーション ボックスの 1 つがクラスター キューにメッセージを送信できるが、他の 5 つができないことです。障害が発生している 5 つのボックスを見ると、クラスターへの発信キューが非アクティブになっています。

トランザクションのデッド レター キューにも多数のイベントがあります。そのキューを消去すると、発信キューはクラスターに接続されますが、メッセージは発信キューで未確認のまま大きくなります。これは、トランザクションのデッド レター キューに再び移動するまで増加し続け、送信キューの状態が非アクティブに変わります。

興味深いことに、このパージ操作を実行すると、別のボックスが「良いボックス」になります。したがって、問題は 1 つの不良ボックスではなく、クラスター キューへの接続を確実に維持できるのは一度に 1 つのボックスのみであると確信しています。

誰もこれに遭遇したことがありますか?

4

2 に答える 2

10

ここに記載されている問題が原因でした: http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

短いバージョン: MSMQ をインストールすると、すべての MSMQ インストールに一意の ID が割り当てられます。これは QMId と呼ばれ、以下のレジストリにあります。

HKLM\Software\Microsoft\MSMQ\Parameters\Machine Cache\QMid

これは、リモート受信者に送信するときに識別子として使用され、リモート受信者はそれを使用して ACK を正しい送信者に送り返します。レシーバー (この場合はクラスター) は、QMId を IP にマップするキャッシュを維持します。私たちの問題は、従業員の何人かが同じ QMId を持っていたことです。これにより、クラスターは、すべてのマシンからのすべてのメッセージに対するすべての ACK を、メッセージを送信した最初のマシンに送信しました。ある時点で、MSMQ Windows サービスの再起動などの一部の操作では、キャッシュが期限切れになり、別のマシンが魔法のように「動作」します。

そのため、6 つのサーバーをチェックして、同じ QMid がないことを確認してください。MSMQ がインストールされた後に取得された Windows イメージからすべてゴースト化されたため、私たちのものは同じ値でした。

修正は簡単です。各マシンに MSMQ 機能を再インストールして、新しい一意の QMId を生成するだけです。

于 2012-11-15T22:04:00.017 に答える