Windows ゲートウェイサービス設定ガイド - Mule 4

Mule Runtime で実行中の MSMQ Connector について、サービスは最初に RFC 2616 の指定に従って HTTP 認証ヘッダーを調べることで、呼び出しを認証します。

認証は、MSMQ Connector が使用する、この一意のセキュリティトークンによって行われます。このトークンは、Mule スキームを使用してゲートウェイに送信されるすべての HTTP 要求に含まれます。次の例では、MSMQ がゲートウェイを活用して、このセクションで指定されているようにセキュリティトークンを送信することで特定のキューに接続しています。

認証トークンは、コネクタとゲートウェイ設定ファイルで一致する必要があります。次の例は、ゲートウェイ設定ファイルの Mule.SelfHost.exe.config でトークンがどのように設定されるかを示しています。

Mule Runtime で実行されるコネクタを設定する際には、ゲートウェイアクセストークン設定 (コネクタの XML 設定にある accessToken 属性) で認証トークン値を設定してください。

注意:​ Windows ゲートウェイサービスのインストーラーは、最初のインストール時に、コーラーが使用する暗号化されたセキュアトークンを自動的に生成します。このトークンは、Mule アプリケーションに簡単にコピーできるように、インストール中に表示され、クリップボードに格納されます。

ゲートウェイが処理するコネクタの代わりにコールを実行するユーザーは、2 つのカスタム HTTP ヘッダーである mule-impersonate-username と mule-impersonate-password によって認証されます。

これらの 2 つのヘッダーは、Windows ゲートウェイサービスが動作している Active Directory フォレストにある既存ユーザーの Windows ログイン情報、またはサービスをホストしているマシンのローカルアカウントの Windows ログイン情報を表します。これらの HTTP ヘッダーが HTTP 要求に含まれている場合、Windows ゲートウェイサービスはこのユーザーを認証して偽装してから、コネクタが必要とする操作を実行します。これにより、Windows ログイン情報を使用して正しいアクセス制御リスト権限を設定できます。

MSMQ Connector にのみ関連する設定を次の表に示します。

キューで認証が必要であるとマークされている場合、設定で指定されているようにコーラーユーザーを偽装することができます。さらに、リモートキューを使用している場合は、この動作を上書きするための特別なヘッダーがコネクタにあります。

Windows ゲートウェイサービスは、フォールトトレランスを高めるために負荷分散設定での動作をサポートしています。複数のゲートウェイサービスインスタンスを実行する場合は、重複しない間隔で MSMQ バックグラウンドジョブを実行するように各メンバーを設定する必要があります。

MSMQ バックグラウンドジョブの処理は、デフォルトでは正時から 10 分間隔で実行されます。負荷分散設定において、複数のゲートウェイインスタンスが同時にキューのクリーンアップを実行しないようにするには、​cleanup-delay​ と呼ばれる設定を、ゲートウェイインスタンスごとに行う必要があります。この場合に各マシンで推奨される値は (10 / instanceCount) * (instanceNumber - 1) で、instanceNumber は 1 …​ n の整数です。

たとえば、マシンが 2 台のクラスターでは、cleanup-delay をマシン 1 では 0、マシン 2 では 5 に設定します。マシンが 3 台のクラスターでは、cleanup-delay をマシン 1 では 0、マシン 2 では 3、マシン 3 では 6 に設定します。このオフセットが正しく適用されるように、NTP や同等のメカニズムでクラスター内のマシンのクロックを同期させます。

cleanup-delay​ 設定は ​Mule.SelfHost.config​ ファイルにあります。

注意:​ 負荷分散設定において、関与するノード (MSMQ、ゲートウェイ) がワークグループに属していてドメインには結合されていない場合には、ゲートウェイサービスを「管理者として実行」するように設定する必要があります。同じドメインに結合した場合は、ドメイン管理者は関与する各ノードとオブジェクト (キュー) の権限を適切に設定する必要があります。

Windows ゲートウェイサービスは、[Information (情報)] イベントをログに記録するように設定されています。この設定は ​<switches>​ 要素で行います。すべてをログに記録する場合は、トレースレベルを設定要素で [Verbose (冗長)] レベルに変更してください。

設定ファイルの ​<switch>​ レベルでトレースレベルを設定します。

他にも次のレベルが使用できます。

Windows ゲートウェイサービス内のルーティングサービスをトレースまたはデバッグするには、ルーティングサービスの接続時に生成されたエラーの詳細を取得するための設定を有効にします。この情報をトレースリスナーで取得するには、​serviceDebug​ 要素の ​includeExceptionDetailInFaults​ 属性で有効にします。これを行うには、その値を ​true​ に設定します。

この設定は、サービスが返すエラーメッセージを拡張して、原因の内部スタックトレースを追加します。このことが、場合によっては問題を理解するのに役立つ可能性があります。

問題のトラブルシューティングに役立つ手段の 1 つは、コンソールリスナーを有効にして (デフォルトでは有効ですが、有効ではない場合には、リスナーセクションに追加する必要があります)、Windows ゲートウェイサービスをコマンドラインから実行することです。

コンソールでは、要求、応答、警告、エラーなど、トレースされている情報をリアルタイムで見ることができます。コネクタがゲートウェイに正しく接続されているかどうかを確認したり、障害につながる可能性がある、考えられる他の原因を確認したりするのに便利です。

Windows イベントトレーシング (ETW) は、カーネルレベルでイベントのトレースを実行する非常に効率的な組み込みパブリッシュ/サブスクライブメカニズムです。I/O に依存してファイルやデータベースなどに永続的に保存する従来のトレースソリューションと比較して、この機能を使用するにあたってオーバーヘッドはほとんどありません。Windows の組み込みメカニズムであるため、オペレーティングシステムの多くのサービスやコンポーネントもこの機能を使用しています。そのため、トラブルシューティングの対象は、アプリケーションだけではなく、同じ実行中に関与する多くの OS コンポーネントにも及びます。

ETW では、一部のアプリケーションがイベントをキュー (プロバイダー) にパブリッシュし、他のアプリケーションが ETW セッションを介してリアルタイムでこれらのキューからイベントをコンシュームします。プロバイダーでイベントがパブリッシュされると、そのキューからイベントを収集するセッションが発生しない限り、イベントはどこにも行きません。(イベントは持続的ではありません。)

​.NET のトレースシステムには、ETW 用のトレースリスナーである EventProviderTraceListener があり、ETW がトレースを収集するために使用するセッション識別子で設定できます。

この例では、この識別子にセッションが関連付けられています。

{47EA5BF3-802B-4351-9EED-7A96485323AC}

このコマンドは、有益な情報を ​dumpfile.xml​ というテキストファイルに転送します。詳細については、「Tracerpt」を参照してください。