|
|
|
|
|
|
| | | |
Microsoft Internet Information Server（ISAPI）プラグインのインストールとコンフィグレーション
以下の節では、Microsoft Internet Information Server プラグインをインストールおよびコンフィグレーションする方法について説明します。
Microsoft Internet Information Server プラグインの概要
Microsoft Internet Information Server プラグインを使用すると、Microsoft Internet Information Server（IIS）から WebLogic Server へリクエストをプロキシできます。このプラグインは、WebLogic Server の動的な機能を必要とするリクエストを WebLogic Server が処理できるようにすることによって IIS を拡張します。
Microsoft Internet Information Server プラグインは、Internet Information Server（IIS）が HTML ページなどの静的ページを提供し、WebLogic Server が HTTP サーブレットまたは JavaServer Pages などの動的ページを提供する環境で使用されることを想定しています。WebLogic Server は別のプロセス（おそらく別のホスト）で動作しています。それでも、エンド ユーザ（ブラウザ）では、WebLogic Server に委託される HTTP リクエストは IIS から来ているものと認識されます。WebLogic クライアント/サーバ プロトコルの HTTP トンネリング機能もこのプラグインを介して動作するため、すべての WebLogic サービスへのアクセスを提供できます。
接続プールとキープアライブ
Microsoft Internet Information Server プラグインは、WebLogic Server との接続の再利用可能なプールを使用してパフォーマンスを向上させます。このプラグインは、同じクライアントからの後続リクエストに同じ接続を再利用することで、WebLogic Server との間で HTTP 1.1 キープアライブ接続を実装します。接続が 30 秒（またはユーザ定義の時間）を超えて非アクティブな場合、その接続は閉じられます。クライアントとの接続がタイムアウトしていない場合は、後でその接続を再利用して、同じクライアントに接続できます。この機能は、必要に応じて無効にできます。詳細については、 KeepAliveEnabledを参照してください。
リクエストのプロキシ
このプラグインは、指定されたコンフィグレーションに基づいてリクエストを WebLogic Server にプロキシします。リクエストは、リクエストの URL（または URL の一部）に基づいてプロキシできます。この方法は、パスによるプロキシ、と呼びます。リクエストのプロキシは、要求されたファイルの MIME タイプに基づいて行うこともできます（ファイル拡張子を基準としたプロキシ）。さらに、前述の方法を組み合わせて利用することもできます。リクエストが両方の基準に一致する場合、そのリクエストはパスを基準にプロキシされます。リクエストの種類ごとに、プラグインの補足的な動作を定義する追加パラメータを指定することもできます。詳細については、 Microsoft Internet Information Server プラグインのインストールを参照してください。
プラットフォーム サポート
Microsoft Internet Information Server プラグインと互換性のあるオペレーティング システムおよび IIS のバージョンに関する最新の情報については、プラットフォーム サポート ページを参照してください。
Microsoft Internet Information Server プラグインのインストール
Microsoft Internet Information Server プラグインをインストールするには、次の操作を行います。
bin ディレクトリにある iisproxy.dll ファイルを、IIS からアクセス可能なディレクトリにコピーします。このディレクトリには、iisproxy.ini ファイルも格納されていなければなりません。Microsoft Internet Information Server プラグインで 128 ビットのセキュリティを使用する必要がある場合には、iisproxy128.dll ファイルの名前を iisproxy.dll に変更しなければなりません。両方のファイルを残しておきたい場合は、元の iisproxy.dll ファイルの名前を変更する必要があります。
iisproxy.dll」ファイルを検索します。
注意: URL のサーバとポートの後ろに追加されたパス情報は、WebLogic Server にそのまま渡されます。たとえば、次の URL で IIS にファイルを要求した場合、
http://myiis.com/jspfiles/myfile.jsp
そのリクエストは次のような URL で WebLogic Server にプロキシされます。
http://mywebLogic:7001/jspfiles/myfile.jsp
ファイルを作成します。
iisproxy.ini ファイルには、プラグインのコンフィグレーション パラメータを定義する名前と値の組み合わせを格納します。パラメータのリストは、
Web サーバ プラグインの一般的なパラメータで参照できます。
注意: パラメータの変更は、コントロール パネルの [サービス] で「IIS Admin Service」を再起動するまで有効にはなりません。
BEA では、iisproxy.ini ファイルを iisproxy.dll ファイルと同じディレクトリに配置することをお勧めします。他のディレクトリを使用することも可能です。他のディレクトリに配置する場合は、iisproxy.ini が以下のディレクトリを以下の順序で検索されることに注意してください。
iisproxy.dll と同じディレクトリ。
iisproxy.ini ファイルが見つからない場合、WebLogic Server は、Windows レジストリで WebLogic Server の旧バージョンを調べ、古いインストール環境のホーム ディレクトリで iisproxy.ini ファイルを探します。
c:\weblogic ディレクトリ（存在する場合）。
iisproxy.ini ファイルで
WebLogicHost パラメータと
WebLogicPort パラメータを定義します。次に例を示します。
WebLogicHost=localhost
WebLogicPort=7001
iisproxy.ini ファイルで
WebLogicCluster パラメータを定義します。次に例を示します。
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001
myweblogic.com と yourweblogic.com は、クラスタ内で動作している WebLogic Server のインスタンスです。
iisproxy.ini ファイルで追加パラメータを指定することにより、パスに基づいてファイルを提供するようにMicrosoft Internet Information Server プラグインをコンフィグレーションすることもできます。パスを基準としたプロキシは、MIME タイプを基準としたプロキシに優先します。
また、パスを使用して IIS で定義されている複数の Web サイトをプロキシすることもできます。詳細については、 IIS の複数の仮想 Web サイトのプロキシを参照してください。
パスによるプロキシをコンフィグレーションするには、次の手順に従います。
iisforward.dll ファイルを iisproxy.dll ファイルと同じディレクトリに置き、iisforward.dll ファイルをフィルタ サービスとして IIS に追加します（Web サイトの [プロパティ] パネルで、[ISAPI フィルタ] タブの [追加] をクリックして iisforward dll を追加します）。
iisproxy.dll で処理される特殊なファイル タイプとして wlforward を登録します。
iisproxy.ini で
WlForwardPath プロパティを定義します。WlForwardPath では、次のように WebLogic Server にプロキシするパスを定義します。 WlForwardPath=/weblogic.
WlForwardPath を削除します。次に例を示します。
WlForwardPath=/weblogic
PathTrim=/weblogic
この場合は、IIS から WebLogic Server へのリクエストが削除されます。したがって、/weblogic/session は /session に変更されます。
iisproxy.ini で Debug=ON パラメータを設定します。デバッグに利用できるプラグインのアクティビティのログを記録した c:\tmp\iisforward.log が生成されます。
WlForwardPath=*/HTTPClnt*
PathTrim パラメータを使用する必要はありません。
注意: HTTP トンネリングを使用する必要があるのは、アプレットを使用して IIS/NES 経由で WebLogic Server に接続し、t3 の代わりのプロトコルとして http を使用する場合です（たとえば、プロバイダ URL のプロトコルとして t3:// の代わりに http:// を使用する場合）。
iisproxy.ini ファイルで追加パラメータを設定します。パラメータのリストについては、
Web サーバ プラグインの一般的なパラメータで参照できます。
IIS の複数の仮想 Web サイトのプロキシ
複数の Web サイト（IIS の仮想サーバとして定義）を WebLogic Server にプロキシするには、次の手順に従います。
dll および ini ファイルが格納されます。
iisforward.dll をコピーします。
iisforward.dll を IIS に登録します。
iisforward.ini というファイルを作成します。作成したファイルを、iisforward.dll と同じディレクトリに配置します。このファイルには、IIS に定義されている仮想 Web サイトごとに次のエントリを格納する必要があります。
vhost
N=websiteName:port:
websiteNameport=dll_directory/iisproxy.ini
各値の説明は次のとおりです。
N は、仮想 Web サイトを表す整数です。最初に定義する仮想 Web サイトには整数 1 を使用し、以降の Web サイトには順に 1 ずつ増やします。
websiteName は、IIS に登録した仮想 Web サイトの名前です。
port は、IIS が HTTP リクエストをリスンしているポート番号です。
dll_directory は、手順 1 で作成したディレクトリのパスです。
次に例を示します。
vhost1=strawberry.com:7001
strawberry.com:7001=c:\strawberry\iisproxy.ini
vhost2=blueberry.com:7001
blueberry.com:7001=c:\blueberry\iisproxy.ini
...
iisproxy.ini ファイルを作成します。仮想 Web サイトごとに、手順 1 で作成したディレクトリにこの iispoxy.ini ファイルをコピーします。
iisproxy.dll をコピーします。
iisproxy.dll が常に呼び出されることになります。その場合、リクエストはすべて、最初の Web サイトの iisproxy.ini で定義されている同じ WLS インスタンスにプロキシされます。
IIS を介した ACL の作成
認可ヘッダが IIS によって渡されない場合、ACL は Microsoft Internet Information Server プラグインを介して機能しません。次の説明に基づいて、認可ヘッダが IIS によって渡されるようにします。
基本認証を使用する場合、ユーザはローカルのログオン権限でログオンします。基本認証を使用するには、各ユーザにローカル ログオンのユーザ権利を与えます。ただし、基本認証でローカル ログオンを使用することで 2 つの問題が発生する可能性があります。
コンソールの [ディレクトリ セキュリティ] タブで基本認証を有効にするには、[匿名アクセスを許可する] オプションをオンに、その他のオプションをすべてオフにします。
ここでは、クラスタ化されていない 1 つの WebLogic Server で使用する iisproxy.ini ファイルのサンプルを示します。先頭に「#」が付いた行はコメントです。
# このファイルでは、IIS/WebLogic プラグイン用の
# 初期化パラメータの名前と値の組み合わせを指定する
WebLogicHost=localhost
WebLogicPort=7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2
次に示すのは、クラスタ化された WebLogic Server で使用する iisproxy.ini ファイルのサンプルです。先頭に「#」が付いた行はコメントです。
# このファイルでは、IIS/WebLogic プラグイン用の
# 初期化パラメータの名前と値の組み合わせを指定する
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2
注意: プラグインと WebLogic Server の間で SSL を使用する場合は、SSL リスン ポートとしてポート番号を定義する必要があります。
Microsoft Internet Information Server プラグインでの SSL の使用
セキュア ソケット レイヤ（SSL）プロトコルを使用すると、WebLogic Server プロキシ プラグインと Microsoft Internet Information Server の間の接続を保護できます。SSL プロトコルは、Microsoft Internet Information Server プラグインと WebLogic Server の間でやり取りされるデータに機密性と整合性を提供します。また、SSL プロトコルを使用すると、WebLogic Server プロキシ プラグインでは、信頼性のあるプリンシパルに情報が渡されることを確認するために、Microsoft Internet Information Server に対して自身を認証することができます。
Microsoft Internet Information Server プラグインでは、SSL プロトコルを使用してプロキシ プラグインと Microsoft Internet Information Server 間の接続を保護するかどうかを、転送プロトコル（http または https）によって決定できません。Microsoft Internet Information Server プラグインで SSL プロトコルを使用するには、プロキシされるリクエストを受け取る WebLogic Server で、SSL プロトコルを使用するようにコンフィグレーションする必要があります。WebLogic Server プロキシ プラグインでは、セキュアな SSL 通信を使用するようにコンフィグレーションされた WebLogic Server 上のポートを使用して Microsoft Internet Information Server と通信します。
注意: Microsoft Internet Information Server と WebLogic Server の間には相互 SSL をコンフィグレーションできません。SSL プロトコルは、ポイント ツー ポイントの接続であり、暗号化されたエンド ツー エンドのプロトコルです。したがって、どのようなタイプのプロキシまたはファイアウォールも、SSL ソケットの内容を見ることはできません。Microsoft Internet Information Server は、SSL 接続におけるサーバ エンドポイントとして機能します。コンフィグレーションは次のようになります。
クライアント --> 相互 SSL --> IIS <-- 一方向 SSL <-- WebLogic Server
Microsoft Internet Information Server は、クライアントのプライベート キーを使用できないので、1 番目の SSL 接続からのデジタル証明書を 2 番目の SSL 接続で使用することはできません。
Microsoft Internet Information Server プラグインと WebLogic Server の間で SSL プロトコルを使用するには、次の操作を行います。
iisproxy.ini ファイルの WebLogicPort パラメータを
手順 2. でコンフィグレーションしたリスン ポートに設定します。
iisproxy.ini ファイルの SecureProxy パラメータを ON に設定します。
iisproxy.ini ファイルで設定します。パラメータのリストについては、
Web サーバ プラグインの SSL パラメータを参照してください。
次に例を示します。
WebLogicHost=myweblogic.com
WebLogicPort=7002
SecureProxy=ON
IIS から WebLogic Server へのサーブレットのプロキシ
iisforward.dll がフィルタとして登録されている場合、サーブレットをパスでプロキシできます。その場合は、次の形式の URL でサーブレットを呼び出します。
http://IISserver/weblogic/myServlet
iisforward.dll がフィルタとして登録されていない場合にサーブレットをプロキシするには、ファイル タイプを基準としたプロキシをコンフィグレーションする必要があります。ファイル タイプでサーブレットをプロキシするには、次の操作を行います。
http://www.myserver.com/virtualName/anyfile.ext
virtualName は、このサーブレットの Web アプリケーション デプロイメント記述子（web.xml）の <servlet-mapping> 要素で定義された URL パターンで、ext は WebLogic Server に対してプロキシするように IIS に登録したファイル タイプ（拡張子）です。URL の anyfile の部分は、このコンテキストでは無視されます。
注意 :
Microsoft Internet Information Server プラグインをインストールしてコンフィグレーションした後は、次の手順に従ってデプロイメントとテストを行います。
filename.jsp という形式の URL を設定します。
http://myii.server.com/filename.jsp
filename.jsp がブラウザに表示される場合は、プラグインが正常に機能しています。
接続エラーとクラスタのフェイルオーバ
WebLogic Server に接続するときに、Microsoft Internet Information Server プラグインは複数のコンフィグレーション パラメータを使用して WebLogic Server ホストへの接続の待ち時間と、接続確立後の応答の待ち時間を判断します。接続できないか、応答がない場合、このプラグインはクラスタ内の別の WebLogic Server に接続してリクエストを送信しようとします。接続が失敗するか、クラスタ内のどの WebLogic Server からも応答がない場合は、エラー メッセージが送信されます。
図 12-1は、プラグインがどのようにフェイルオーバを処理するのかを示しています。
接続の失敗
接続要求にホストが応答できない場合は、ホスト マシンの問題やネットワークの問題など、サーバに障害があることが考えられます。
WebLogic Server が応答できない場合は、WebLogic Server が動作していないことや、サーバのハング、データベースの問題など、アプリケーションに障害があることが考えられます。
クラスタ化されていない単一 WebLogic Server でのフェイルオーバ
WebLogic Server が 1 つしか動作していない場合でも、ここで説明する同じ理論が適用されますが、プラグインは
WebLogicHost パラメータで定義されたサーバにのみ接続しようとします。その試みが失敗すると、HTTP 503 エラー メッセージが返されます。プラグインは、
ConnectTimeoutSecs に達するまで WebLogic Server への接続を繰り返し試みます。
動的サーバ リスト
WebLogicCluster パラメータで WebLogic Server のリストを指定すると、プラグインではクラスタ メンバー間でのロード バランシングの起点としてそのリストが使用されます。最初のリクエストがそれらのサーバの 1 つに転送された後に、クラスタ内のサーバの更新されたリストを格納する動的サーバ リストが返されます。更新されたリストはクラスタ内の新しいサーバを追加し、すでにクラスタから外れているか、リクエストに応答できなかったサーバを削除します。このリストは、クラスタで変更が行われたときに HTTP 応答によって自動的に更新されます。
テストの必要な新しいサーバに対してトラフィックが発生しないようにするには、新しく追加するサーバのテストが完全に終わるまで待ってから、サーバをクラスタの対象にします。この時点で、サーバはクラスタのノードになります。このノードは、自動的に、プロキシからのトラフィックの受信を開始します。
フェイルオーバ、クッキー、および HTTP セッション
リクエストがクッキー、POST データ、または URL エンコーディングを通じてセッション情報を格納している場合、そのセッション ID にはセッションが最初に確立された特定のサーバ（プライマリ サーバ）への参照と元のセッションがレプリケートされる追加サーバ（セカンダリ サーバ）への参照が含まれています。クッキーを含むリクエストはプライマリ サーバに接続しようとします。接続できない場合、リクエストはセカンダリ サーバにルーティングされます。プライマリ サーバとセカンダリ サーバが両方とも失敗すると、セッションが失われて、プラグインは動的クラスタ リストの別のサーバにあらためて接続しようとします。詳細については、 図 12-1（ 接続のフェイルオーバ）を参照してください。
注意: POST データが 64K を超える場合、プラグインは、セッション ID を取得するための POST データの解析を行いません。したがって、セッション ID を POST データに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ サーバにルーティングできないので、セッション データが失われる可能性があります。
図12-1 接続のフェイルオーバ
*赤いループで許可される再試行の限度は、次の式で計算されます。ConnectTimeoutSecs ÷ ConnectRetrySecs
|
|
|
