要求マッピング
プロキシー・サーバーは、要求マッピングを使用して、届いた HTTP 要求を、セルにデプロイされたアプリケーションまたはルーティング・ルールに合わせます。
ルーティングの優先順位がディレクティブの順序に継承されているフラット構成ファイルを持つ Apache Web サーバーやキャッシング・プロキシーとは異なり、 プロキシー・サーバーは、ベスト・マッチ・メカニズムを使用して、インストールされたアプリケーションや要求に対応するルーティング・ルールを判別します。 仮想ホストまたは URI パターンによって、Web モジュールまたはルーティング・ルールの中でベスト・マッチが決まり ます。 クラスターにデプロイされたアプリケーションの場合、 プロキシー・サーバーは、アフィニティー (Secure Sockets Layer ID、 Cookie、および URL 再書き込み) を維持しますが、そうでない場合は、加重ラウンドロビン方式でターゲット・サーバーを選択します。 以下に、ルーティング・ルールとアプリケーションを同じセル内にデプロイする際のさまざまなルーティング・シナリオの例を示します。
- プロキシー環境
WebSphere® プロキシー・サーバー (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 ルーティング・ルールを変更すると、 問題が解決されます。
注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.log、SystemErr.log、trace.log、activity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。 - 例 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 応答が戻されるためです。