このトピックでは、プロキシー・サーバーが、
受信した HTTP 要求と、セルまたはルーティング規則にデプロイされたアプリケーションを突き合わせる方法についての概要を説明します。
ルーティングの優先順位がディレクティブの順序に継承されているフラット構成ファイルを持つ Apache Web サーバーやキャッシング・プロキシーとは異なり、
プロキシー・サーバーは、ベスト・マッチ・メカニズムを使用して、インストールされたアプリケーションや要求に対応するルーティング規則を判別します。
仮想ホストまたは URI パターンによって、Web モジュールまたはルーティング規則の中でベスト・マッチが決まり
ます。
クラスターにデプロイされたアプリケーションの場合、
プロキシー・サーバーは、類縁性 (Secure Sockets Layer ID、
Cookie、および URL 再書き込み) を維持しますが、そうでない場合は、加重ラウンドロビン方式でターゲット・サーバーを選択します。
以下に、ルーティング規則とアプリケーションを同じセル内にデプロイする際のさまざまなルーティング・シナリオの例を示します。
プロキシー環境。
WebSphere Application Server プロキシー (proxy1) は、
アプリケーションおよびルーティング規則と同じセル内でアクティブです。
アプリケーションとルーティング規則は、すべて proxy1 のセル内で使用可能であり、
proxy1 の PROXY_HTTP_ADDRESS は 80 に設定されています。
仮想ホスト |
ホスト名 |
ポート |
default_host |
host1.company.com |
80 |
|
host1.company.com |
9080 |
|
* |
80 |
proxy_host |
host2.company.com |
80 |
|
* |
443 |
|
* |
80 |
server_host |
host3.company.com |
80 |
URI グループ名 |
URI パターン |
ALL |
/* |
ROOMS |
/kitchen/*, /bathroom/*, /bedroom/* |
CONFLICT |
/WM2C/* |
汎用サーバー・クラスター名 |
プロトコル |
ホスト |
ポート |
CLUSTER1 |
HTTP |
webserver1.company.com |
9081 |
|
|
webserver2.company.com |
9083 |
CLUSTER2 |
HTTP |
host47.company.com |
8088 |
|
|
host48.company.com |
8088 |
CLUSTER2-SSL |
HTTPS |
host47.company.com |
8443 |
|
|
host48.company.com |
8443 |
ルーティング規則名 |
仮想ホスト |
URI グループ |
アクション |
ALLTOCLUSTER1 |
proxy_host |
ALL |
汎用サーバー・クラスター - CLUSTER1 |
ROOMTOCLUSTER2 |
proxy_host |
ROOMS |
汎用サーバー・クラスター - CLUSTER2 |
ALLTOCLUSTER2 |
server_host |
ALL |
汎用サーバー・クラスター - CLUSTER2 |
REDIRECTTOCONFLICT |
default_host |
CONFLICT |
リダイレクト - http://www.conflict.com |
アプリケーション名 |
コンテキスト・ルート |
Web モジュール名 |
仮想ホスト |
Web モジュール URI パターン |
App1 |
/WM1A/ |
Web Mod A |
default_host |
wm1a.jsp |
|
/WM1B/ |
Web Mod B |
default_host |
wm1b.jsp |
App2 |
/WM2C/ |
Web Mod C |
default_host |
/*, wm2c.jsp |
|
/WM2D/ |
Web Mod D |
default_host |
/*, wm2d.jsp |
例 1: 基本要求。
proxy1 プロキシーは、次の要求を受信します。
GET /WM1A/wm1a.jsp HTTP/1.1
Host: host1.company.com
結果。
wm1a.jsp ファイルが応答として送信されます。
ALLTOCLUSTER1 ルーティング規則が一致すると考えられますが、
Web Mod A がベスト・マッチとして proxy1 によって選択されます。
これは、そのコンテキスト・ルートと URI パターン
/WM1A/wm1a.jsp の組み合わせのほうが、
/* よりも一致の度合いが高いためです。
仮想ホストに
host1.company.com:80 別名が含まれているため、
Web Mod A もベスト・マッチとして選択されます。
これは、
*:80 ワイルドカード別名よりも具体的です。
例 2: 同じ URI グループと異なる仮想ホストを使用するルーティング規則。
proxy1 プロキシーは、次の要求を受信します。
GET /index.html HTTP/1.1
Host: host3.company.com
結果。
proxy1 プロキシーは、要求を ALLTOCLUSTER2 ルーティング規則にマップし、
応答が CLUSTER2 内のサーバーから受信されます。
ALLTOCLUSTER1 ルーティング規則が一致すると考えられ、
ALLTOCLUSTER2 ルーティング規則が存在しなかった場合に要求を処理できます。
しかし、仮想ホスト (server_host) に
host3.company.com が明示的にリストされているため、
ALLTOCLUSTER2 規則がベスト・マッチになります。
例 3: 同じ仮想ホストと異なる URI グループを使用するルーティング規則。
proxy1 プロキシーは、次の要求を受信します。
GET /kitchen/sink.gif HTTP/1.1
Host: host2.company.com
結果。
proxy1 プロキシーは、要求を ROOMSTOCLUSTER2 ルーティング規則にマップし、
CLUSTER2 クラスターのサーバーが応答を送信します。
ALLTOCLUSTER1 ルーティング規則が一致すると考えられますが、
ROOMSTOCLUSTER2 規則の URI グループにパターン
/kitchen/* が含まれており、これの方が要求 URI
/kitchen/sink.gif に一致する度合いが高いため、ROOMSTOCLUSTER2 規則がベスト・マッチになります。
例 4: ルーティング規則 URI グループと、
同じ仮想ホストを使用する Web モジュールの URI パターンとの競合。
proxy1 プロキシーは、次の要求を受信します。
GET /WM2C/index.html HTTP/1.1
Host: host1.company.com
結果。
不確定。
同じ仮想ホストを使用し、同じ URI パターンを持っているため、
Web Mod C または REDIRECTTOCONFLICT ルーティング規則のいずれが要求を処理するのか不明です。
このような場合は、ID DWCT0007E メッセージが
proxy1 プロキシーの
SystemOut.log ファイルに表示されます。
この例では、異なる仮想ホストを使用するように REDIRECTTOCONFLICT ルーティング規則を変更すると、
問題が解決されます。
例 5: PROXY_HTTP_ADDRESS アドレスが仮想ホスト内にない。
その他のすべての構成情報が同じままであるのに対して、
proxy1 プロキシー・アドレス PROXY_HTTP_ADDRESS は、
81 に変更されているとします。
proxy1 プロキシーは、次の要求を受信します。
GET /index.html HTTP/1.1
Host: host1.company.com:81
結果。
proxy1 プロキシーは、要求を処理できません。
これは、PROXY_HTTP_ADDRESS アドレスが仮想ホスト内で使用不可で、クライアントに HTTP 404 応答が戻されるためです。