この記事では、Microsoft メッセージ キュー (MSMQ) をネットワーク負荷分散 (NLB) 経由で機能する方法について説明します。
元の製品バージョン: Microsoft メッセージ キュー
元の KB 番号: 899611
はじめに
本記事では、MSMQがNLB上でどのように機能するかについて説明します。 この記事では、MSMQ の不適切な構成の可能性についても説明します。
重要
この資料には、レジストリの編集方法が記載されています。 レジストリを変更する前にレジストリのバックアップを必ず作成してください。 また、問題が発生した場合に備えて、レジストリの復元方法を理解しておいてください。 レジストリをバックアップ、復元、および変更する方法の詳細については、「 Windows レジストリの詳細な情報を参照してください。
サポートされている構成
MSMQ は、次の構成でメッセージを送受信する NLB 環境でサポートされています。
- Direct=TCP を使用した非トランザクション メッセージング
- 検証が無効になっている Direct=OS を使用した非トランザクション メッセージング
- Direct=HTTP を使用した非トランザクション メッセージング
- ストア アンド フォワード サーバーと 1 つのバックエンド サーバーを使用する特定の構成を使用したトランザクション メッセージング。
メモ
これらの構成のいずれかでサポートされている宛先は、プライベート キューのみです。 仮想ネットワーク名には対応する Active Directory ディレクトリ サービス オブジェクトがないため、宛先キューのプロパティを照会できません。 パブリック キューにアクセスする場合は、標準パスを使用する代わりに、直接形式名を使用してメッセージをパブリック キューに送信できます。
Direct=TCP を使用した非トランザクション メッセージング
この構成は、特定の構成を変更せずに機能します。
Direct=OS を使用した非トランザクション メッセージング
この構成は、検証が無効になっている場合にのみ機能します。 検証を無効にするには、WINDOWS XP または Windows Server 2003 と共に、MSMQ 2.0 と Windows 2000 および MSMQ 3.0 で次のレジストリ キーを追加する必要があります。
警告
レジストリ エディターまたは別の方法を使用してレジストリを不適切に変更すると、深刻な問題が発生する可能性があります。 このような問題が発生した場合は、オペレーティング システムの再インストールが必要になることがあります。 こうした問題の修復について、マイクロソフトはいかなる保証もいたしません。 レジストリはユーザー自身の責任において変更してください。 次の手順に従って、レジストリ エディターを終了します。
- [スタート] をクリックし、[実行] をクリックし、「regedit」と入力して [OK] をクリックします。
- 次のレジストリ キーを特定して、クリックします。
HKEY_LOCAL_MACHINE\Software\Microsoft\MSMQ\Parameters - [編集] メニューの [新規] をポイントし、[DWORD 値] をクリックします。
- IgnoreOSNameValidation と入力し、ENTER キーを押。
- [ Edit メニューの Modify をクリックします。
- 「 1」と入力し、[ OK] をクリック。
既定では、MSMQ は受信したメッセージを検証して、メッセージがローカル コンピューターを対象としているかどうかを判断します。 メッセージがローカル コンピューターを対象としていない場合、メッセージは拒否されます。
ネットワーク ロード バランサーの背後にあるサーバーにメッセージが送信されると、メッセージはロード バランサーの名前を使用するか、ネットワーク ロード バランサーの仮想 IP に割り当てられているネットワーク名を使用して送信されます。 その後、ネットワーク ロード バランサーはメッセージを MSMQ レシーバーにルーティングします。 ただし、MSMQ 受信側のローカル キュー マネージャーは、メッセージ内のコンピューター名と宛先名が一致しないことを識別し、キュー マネージャーはメッセージを破棄します。 このレジストリ値を設定すると、MSMQ は対象のコンピューター名を検証しなくなり、メッセージを受け入れます。
Direct=HTTP を使用した非トランザクション メッセージング
この構成は、特定の構成を変更せずにサポートされます。
ストア アンド フォワード サーバーと 1 つのバックエンド サーバーを使用する特定の構成を使用したトランザクション メッセージング
この構成では、トランザクション メッセージングは、メッセージを受信するノードが受信キューを単一のバックエンド サーバーにマップする場合にのみ HTTP メッセージングをサポートします。 宛先キューが個々のノードにある場合、HTTP トランザクション メッセージはサポートされません。
この構成の詳細については、Windows Server 2003 および Windows XP Professional の Microsoft メッセージ キュー (MSMQ) HTTP 展開シナリオ ホワイト ペーパーを参照してください。
ロード バランサーの背後にある各メンバー ノードに宛先キューが存在するトランザクション メッセージングの構成では、次の理由によりメッセージの送受信はサポートされません。
- 重複するメッセージ
- 送信者の未確認メッセージ
- 不完全なトランザクション
トランザクション メッセージと受信確認
コンピューターがトランザクション メッセージを受信すると、メッセージがストレージに書き込まれ、メッセージがログに記録され、注文確認が送信者に返送されます。 注文確認は、direct=TCP を使用して、元のメッセージの元の IP アドレスに返送されます。 その後、メッセージは送信者によって受信され、メッセージは送信キューから削除されます。
指定した時間内に送信側サーバーが受信確認を受信しなかった場合、元のメッセージが再送信されます。 メッセージが宛先に到着すると、宛先サーバーはログを調べて、サーバーがそのメッセージを既に受信していることを確認します。 そのため、宛先サーバーはメッセージを拒否し、別の受信確認を返します。 宛先サーバーは、送信者が注文確認を受信するまで、受信確認を送信し続けます。 ログ記録により、重複メッセージの受信が禁止され、注文確認によってメッセージが受信されたことが送信者に確認されます。
ネットワーク ロード バランサーとトランザクション メッセージに関する問題
ロード バランサーを介してメッセージが送信されると、宛先コンピューターにはロード バランサーからのメッセージが表示されます。 次に、宛先コンピューターは、新しいセッションを通じて注文確認を送信します。 そのため、ロード バランサーは、Web サーバーまたは同様のサービスの状態を維持するために同じロジックを使用できません。
このシナリオで最も一般的な問題は、複数のサーバーがロード バランサーを介してメッセージを送信するが、すべての注文確認が正しくないサーバーに送信されるということです。 この動作により、未確認のメッセージが送信コンピューターの送信キューに蓄積されます。 さらに、送信者が注文確認を受信しなかった場合、送信者はメッセージを再送信します。 2 回目の試みでは、ロード バランサーを介してメッセージを送信しようとすると、別のコンピューターにメッセージが送信される可能性があります。 このコンピューターにはこのメッセージが表示されず、メッセージは新しいメッセージとして処理されます。 NLB を介してメッセージを移動できるように検証が無効にされたことを覚えておいてください。
ロード バランサー間で送信されたメッセージは、注文確認を受信する前に、ロード バランサーの背後にあるすべてのサーバーによって 1 回受信および処理される場合があります。 さらに、複数のメッセージにまたがるトランザクションを常に処理したり、順番に到着したりすることはできません。 そのため、NLB を使用する場合、MSMQ ではトランザクション メッセージの送信はサポートされません。