4 4-1 WAS

4 プロキシー・サーバー............................................................................................................... 3
4-1 WAS が提供するプロキシー・サーバー ............................................................................... 3
4-1-1 プロキシー・サーバーのキーワード .................................................................................. 3
4-1-1-1 オンデマンド構成(ODC)................................................................................................ 4
4-1-1-2 汎用サーバー・クラスター ............................................................................................. 4
4-1-1-3 URI グループ .................................................................................................................. 4
4-1-2 プロキシー・サーバーのトポロジー ................................................................................... 4
4-1-3 プロキシー・サーバー構成手順 ........................................................................................ 5
4-1-4 HTTP プロキシー・サーバー設定 ..................................................................................... 7
4-1-4-1 プロキシー設定 .............................................................................................................. 7
4-1-4-2 ルーティング・ルール ................................................................................................... 10
4-1-4-3 静的キャッシュ・ルール ............................................................................................... 11
4-1-4-4 再書き込みルール ....................................................................................................... 11
4-1-5 プロキシー仮想ホスト構成 .............................................................................................. 11
4-2 オンデマンド・ルーター ........................................................................................................ 24
4-2-1 オンデマンド・ルーター概要 ............................................................................................ 24
4-2-2 オンデマンド・ルーターのトポロジー ............................................................................... 24
4-2-3 オンデマンド・ルーターによるワークロード管理 ............................................................. 25
4-2-3-1 オンデマンド構成(ODC).............................................................................................. 26
4-2-3-2 BBSON ......................................................................................................................... 28
4-2-3-3 動的ワークロードマネージャー(DWLM) .................................................................... 28
4-2-4 セッション管理 .................................................................................................................. 29
4-2-4-1 セッション・リバランス機能........................................................................................... 29
4-2-5 オンデマンド・ルーターの構成手順 ................................................................................ 31
4-2-5-1 単体サーバーの場合 .................................................................................................. 31
4-2-5-2 静的クラスターの場合 ................................................................................................. 34
4-2-5-3 動的クラスターの場合 ................................................................................................. 35
4-2-6 IHS と ODR の連携 ......................................................................................................... 38
4-2-6-1 HAPluginCfgGenerator によるプラグイン構成ファイルの生成 ................................ 39
4-2-7 オンデマンド・ルーターの設定 ........................................................................................ 44
4-2-7-1 オンデマンド・ルーターのトランスポート ..................................................................... 45
4-2-7-2 アウトバウンド接続設定 .............................................................................................. 45
4-2-7-3 キャッシング ................................................................................................................. 47
4-2-7-4 圧縮ポリシー................................................................................................................ 47
4-2-7-5 ODR による SSL 解除 ................................................................................................. 48
4-2-7-6 カスタム・エラー・ページ・ポリシー .............................................................................. 50
4-2-7-7 ロギング ....................................................................................................................... 50
4-2-7-8 ODR カスタム・ログ ...................................................................................................... 51
4-2-7-9 ルーティング・ポリシー................................................................................................. 52
4-2-8 ODR のチューニング ....................................................................................................... 60
4-2-8-1 JVM ヒープ・サイズ ...................................................................................................... 60
4-2-8-2 パーシスタント接続（HTTP KeepAlive） .................................................................... 60
4-2-8-3 アウトバウンド最大接続数 .......................................................................................... 62
4-2-8-4 キャッシング ................................................................................................................. 62
4-2-8-5 スレッド・グループ ........................................................................................................ 62
-1-
4-3 セキュア・プロキシー・サーバー ......................................................................................... 63
4-3-1 セキュリティー設定 .......................................................................................................... 63
4-3-2 管理 .................................................................................................................................. 64
4-3-3 ルーティング..................................................................................................................... 64
4-3-3-1 静的ルーティング構成 ................................................................................................. 65
4-3-3-2 動的ルーティング構成 ................................................................................................. 67
4-3-4 開始の許可 ...................................................................................................................... 70
4-3-5 エラー処理 ....................................................................................................................... 70
4-4 その他 作成手順 ................................................................................................................ 71
4-4-1 汎用サーバー・クラスター作成手順 ............................................................................... 71
4-4-2 URI グループの作成........................................................................................................ 73
-2-
4 プロキシー・サーバー
この章では、WebSphere Application Server Network Deployment (以下、WAS ND) のプロキシー・サ
ーバーについて説明します。
4-1 WAS が提供するプロキシー・サーバー
WAS ND V8.5 では、プロキシー・サーバーとして以下の 3 種類を提供しています。なお、Edge
Component に含まれる Caching Proxy とは異なる製品(機能)です。
•
•
•
WebSphere プロキシー・サーバー
オンデマンド・ルーター
セキュア・プロキシー・サーバー
WebSphere プロキシー・サーバーとは、WAS V6.0.2 から提供されている WAS の実装を利用した Java
ベースのプロキシーです。管理コンソールを使用した構成が可能です。JDK を含んでいるため、DMZ
ゾーン(非武装地帯)への配置は推奨されません。
オンデマンド・ルーターとは WAS V8.5 新機能である Intelligent Management 機能を利用する際に必
要となる重要なプロキシー・サーバーです。
セキュア・プロキシー・サーバーとは、WAS V7.0 から登場した DMZ ゾーン(非武装地帯)へ配置する
ためにセキュリティーが強化されたプロキシー・サーバーです。詳細は、「4-3セキュア・プロキシー・サー
バー (P63)」をご参照下さい。
これらのプロキシー・サーバーは、HTTP 要求および SIP 要求をコンテンツ・サーバーへ送付する事が
可能です。また、プロキシー・サーバーでは、Secure Socket Layer (SSL) を使用してトランスポートを保
護することや、さまざまな認証および許可スキームを使用してコンテンツを保護することも可能です。 そ
の他の重要な機能として、応答変換 (URL 再書き込み) を使用して、Web クライアントからコンテンツ・
サーバーの ID の保護や、ローカルでコンテンツをキャッシュし、大量のトラフィックからコンテンツ・サ
ーバーを保護することによって、パフォーマンスを向上させることができます。
また、オンデマンド構成(ODC)と呼ばれる機能により、プロキシー・サーバーと同一セル内のアプリケ
ーション・サーバーに対して、追加の設定をせずに動的に割り振りを行うことができます。例えば、IHS で
は、アプリケーション・サーバーへ割り振りを行うためにプラグイン構成ファイルの生成/伝播が必要です
が、プロキシー・サーバーでは、追加の設定無しに同一セル内に登録されているアプリケーション・サー
バーへの割り振りを実行できます。
4-1-1 プロキシー・サーバーのキーワード
プロキシー・サーバーを構成する上で、重要となるキーワードの説明および、作成手順をご説明しま
す。
-3-
4-1-1-1 オンデマンド構成(ODC)
オンデマンド構成(ODC)では、プロキシー・サーバーを作成すると自動で同一セル内の WAS に対し
て割り振りが行われます。デフォルトで有効となっており、HA マネージャーの機能により WAS がどのよう
な構成をしているかについての情報がプロキシー・サーバーへ自動で伝播されます。そのため、IHS の
ようにプラグイン構成ファイルの伝播といった作業は必要なくなります。
4-1-1-2 汎用サーバー・クラスター
同一セル以外のサーバーや、IHS へ割り振りを行う必要があるときに、構成するクラスターです。汎用
クラスターを作成し、割り振り対象となるサーバーを汎用クラスターのメンバーとして追加します。
汎用サーバー・クラスターの作成方法は「4-4-1 汎用サーバー・クラスター作成手順」をご参照くださ
い。
4-1-1-3 URI グループ
汎用サーバー・クラスターに対してマップできるユーザー定義の URI パターンのグループです。ユ
ーザーからの要求が URI グループで定義したパターンに一致すると、マップされた汎用サーバー・クラ
スターのメンバーへ割り振りを行います。
URI グループの作成方法は「4-4-2 URI グループの作成」をご参照ください。
4-1-2 プロキシー・サーバーのトポロジー
プロキシー・サーバーを構成する一般的なトポロジーを説明します。WebSphere プロキシー・サーバー
は、オンデマンド構成(ODC)をするために、WAS と同一セル内に構成します。
セル
マシン E
マシン C
マシン A
Load Balancer
(Primary)
アプリケーション
サーバー
WebSphere
プロキシー・サーバー
DB
マシン D
マシン F
マシン B
Load Balancer
(Backup)
WebSphere
プロキシー・サーバー
アプリケーション
サーバー
図 4-1 WebSphere プロキシー・サーバー基本トポロジー
トポロジーとしては Single Point of Failure を避けるため、WebSphere プロキシー・サーバーも最低 2 台
配置します。その前段に負荷分散装置（Load Balancer）を配置します。上記構成では、オンデマンド構
成(ODC)により WebSphere プロキシー・サーバーから自動でアプリケーション・サーバーへの割り振りが
行われますので、IHS は必須ではありません。
-4-
4-1-3 プロキシー・サーバー構成手順
ここからは、実際にプロキシー・サーバーを構成する方法について説明します。プロキシー・サーバー
を構成するプロファイルとしては、デプロイメント・マネージャー（以下、DM）に統合されたカスタム・プロ
ファイルを使用します。
Step1 プロキシー・サーバーの作成
管理コンソールで、[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サーバー] を選択し、
[新規作成] ボタンを選択します。
Step2 プロキシー・サーバーの名前の入力
作成するプロキシー・サーバーに任意の名前を指定します。
Step3 プロトコルの選択
プロキシーとして対応させるプロトコルを、HTTP もしくは SIP から選択します。例えば、SIP を使用しな
い場合は、SIP のチェックボックスのチェックを外します。 [固有ポートの生成]にチェックする事で、同じ
ノード上に複数のプロキシー・サーバーを作成して垂直クラスタリング構成とする場合に、ポート競合を
避けるために固有ポートを生成することができます。設定後、[次へ]を選択します。
-5-
Step4 テンプレートの選択
サーバー・テンプレートとして proxy_server_foundation が選択されていることを確認し、[次へ]を選択
します。
Step4 新規サーバーの確認
作成するプロキシー・サーバーの構成が正しいか確認し、[終了]を選択します。
-6-
Step5 仮想ホストの登録
作成された WebSphere プロキシー・サーバーでは、オンデマンド構成(ODC)により、デフォルトで同一
セル内にある WAS への割り振りが有効になります。但し、WAS の仮想ホストに、作成した WebSphere プ
ロキシー・サーバーのホスト名およびポートの登録が必要となります。
4-1-4 HTTP プロキシー・サーバー設定
HTTP プロキシー・サーバー設定では、作成したプロキシー・サーバー単位の振る舞いを調整するこ
とができます。アプリケーション・サーバーへの接続および要求、キャッシングの有無、要求の拒否、エラ
ー応答の処理、プロキシー・ログのロケーションなどを構成できます。
プロキシー・サーバーは、作成時に環境を自動で検知し WAS に要求をルーティングすることができま
すが、必要に応じてプロキシー・サーバーに追加の構成を設定することができます。管理コンソールで、
[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サーバー]→[Proxy_name]→[HTTP プロキ
シー・サーバー設定] を選択します。
HTTP プロキシー・サーバー設定で構成できる主な項目は、以下の通りです。
4-1-4-1 プロキシー設定
プロキシー設定では、次のようにプロキシー全般に関する構成が可能です。
•
•
•
•
•
•
一般プロパティー
アウトバウンド接続設定
インバウンド接続 SSL 構成
キャッシング
ロギング
セキュリティー
-7-
•
•
•
•
プロキシー・プラグイン構成ポリシー
カスタム・エラー・ページ・ポリシー
静的ファイル・サービス
ワークロード管理
例えば、カスタム・エラー・ページ・ポリシーを変更してエラー・ページを構成する手順は次のようにな
ります。管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSpher プロキシー・
サーバー]→[Proxy_name]→[HTTP プロキシー・サーバー設定]→[プロキシー設定]を選択します。
ローカル・エラー・ページ処理の設定
•
ローカル・エラー・ページ処理
ローカル・ファイル・システムに保管したカスタムの静的エラー・ページを表示する場合に選択します。
•
プロキシー・サーバーが生成したエラーを処理
プロキシー・サーバーがエラー・ページを生成した場合、それに代わってローカル・ファイル・システム
に保管したカスタムの静的エラー・ページを表示するかを設定します。
•
アプリケーション・サーバーが生成したエラーを処理
プロキシー・サーバーの割り振り先のサーバーがエラー・ページを生成した場合、それに代わって、ロ
ーカル・ファイル・システムに保管したカスタムの静的エラー・ページを表示するかを設定します。
•
エラー・マッピング
エラー・コードとファイル・システム上に保管した静的エラー・ページとの組み合わせを設定します。
エラー・コードは、特定のエラー・コードを指定することも、ワイルドカード”*”を使用して、500 番台のエラ
ー全てを 5*のように範囲指定することも可能です。ローカル・ファイルは、保管したカスタムの静的エラ
ー・ページを指定します。下記の図は、400 番台のエラーは 400.html に、500 番台は 500.html にマッピ
ングした設定例です。
-8-
リモート・エラー・ページ処理の設定
•
•
リモート・エラー・ページ処理
エラー・ページ生成アプリケーションに表示するエラー･ページを生成させたい場合に、選択しま
す。
•
エラー・ページ生成アプリケーションの URI
カスタムのエラー・ページ生成アプリケーションの URI を設定します。エラー・ページを生成するサン
プルアプリケーションとして、<WAS_root>/installableApps/HttpErrorHandler.ear が提供されています。ア
プリケーション・サーバーにデプロイしたエラーページ生成アプリケーションを、プロキシー・サーバーの
割り振り先として設定し、エラーとして認識されるように HTTP 状況コードを設定することで、対象となるエ
ラー状況が発生した場合に、応答が転送されます。下図は、HttpErrorHandler アプリケーションに転送さ
れた場合に表示される画面です。
図 4-2 HttpErrorHandler アプリケーションのサンプル
•
プロキシー・サーバーが生成したエラーを処理
プロキシー・サーバーがエラー・ページを生成した場合、それに代わって、エラー・ページ生成アプリ
ケーションが生成したエラー・ページを表示するかを設定します。
•
アプリケーション・サーバーが生成したエラーを処理
プロキシー・サーバーの割り振り先サーバーがエラー・ページを生成した場合、それに代わって、エラ
ー・ページ生成アプリケーションが生成したエラー・ページを表示するかを設定します。
•
エラー・ページ・アプリケーションに転送するヘッダー
エラー・ページ生成アプリケーションに転送する要求ヘッダーを設定します。
-9-
•
エラーとして認識される HTTP 状況コード
エラー・ページ生成アプリケーションに送信される応答のスタータス・コードを設定します。HTTP ステ
ータス・コードを指定しない場合は、404 および 500 番台のエラーが、エラー・ページ生成アプリケーショ
ンの URI に転送されます。
4-1-4-2 ルーティング・ルール
ルーティング・ルールでは、プロキシー・サーバーに到着する要求を仮想ホストおよび URI で識別
し、それらをどのように処理するかをルーティング・アクションに指定します。対象となるアプリケーション
について、あらかじめ「4-1-1-3 URI グループ」を定義しておく必要があります。
定義可能なルーティング・アクションは以下の４つです。
•
汎用サーバー・クラスター
要求が URI グループにマップされた場合に、汎用サーバー・クラスターのメンバーへ要求を割り振りま
す。
•
障害状況コード
要求が URI グループにマップされた場合に、指定したエラー・コードを返します。
•
リダイレクト URL
要求が URI グループにマップされた場合に、指定したリダイレクト URL へ要求をリダイレクトします。
•
ローカル経路
要求が URI グループにマップされた場合に、指定したプロキシー・サーバー内のローカルの文書ル
ートへと割り振ります。
- 10 -
4-1-4-3 静的キャッシュ・ルール
プロキシー・サーバーの URI グループに関連付けられたキャッシュ・ルールを構成する事ができま
す。指定した URI グループにマップされた要求のキャッシュを無効にしたり、有効期限の設定などを構
成する事が可能です。
4-1-4-4 再書き込みルール
•
•
要求または応答内の特定の URL の再書き込みをどのようにするかを定義します。
再書き込み元の URL パターン
再書き込み先の URL パターン
現在サポートされているのは、リダイレクトされた応答の再書き込みだけです。ターゲット・サーバーが
応答をリダイレクトした場合、通常、応答としては、クライアントがリダイレクトされる先の URL を定義する
ロケーション・ヘッダーが、状況コード 302 と一緒に戻ります。ターゲット・サーバーがプロキシー・サー
バーを意識していない場合にクライアントが直接ターゲット・サーバーに要求を送ってしまわないよう、
URL の再書き込みを行い、要求が正しくプロキシー・サーバーを経由するように修正します。
4-1-5 プロキシー仮想ホスト構成
プロキシー仮想ホストは、Web ドメインの名前およびポートと、プロキシー・アクションを特定の基準で
実行するためのプロキシー・ルール式で構成されます。また、各プロキシー仮想ホストでは、「4-1-4
HTTP プロキシー・サーバー設定」をオーバーライドして、設定した構成をその仮想ホストに特化して定
義することができます。管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→
[WebSphere プロキシー・サーバー]→[Proxy_name]→[プロキシー仮想ホスト構成]を選択します。
プロキシー仮想ホストは、プロキシー・サーバー・アクションおよびプロキシー・ルール式を次のように
適用します。プロキシー仮想ホストがインバウンド要求を受信すると、プロキシー・ルール式が評価されま
す。式が true と評価されると、そのプロキシー・ルール式で指定されているすべてのプロキシー・サー
バー・アクションが実行されます。実行されるプロキシー・サーバー・アクションは、後述するようにユーザ
ーが定義できます。
プロキシー・サーバーに対して異なるプロキシー仮想ホストを作成して、そのプロキシー・サーバーが
ホ ス テ ィ ン グ し て い る 各 Web ド メ イ ン を 表 す こ と が で き ま す 。 例 え ば 、 ポ ー ト 80 に お け る
www.proxy1.com の要求は、www.proxy1.com:80 に指定された構成を使用します。ポート 80 におけ
る www.proxy2.com の要求は、www.proxy2.com:80 に指定された構成を使用します。ワイルドカード
文字を使用して、プロキシー仮想ホストをすべての Web ドメインまたはポートで使用できるよう指定する
事もできます。例えば、www.proxy1.com:* は、ポートにかかわらず、Web ドメイン www.proxy1.com
のすべての要求でプロキシー仮想ホストを使用できることを指定します。 *:80 のプロキシー仮想ホスト
は、Web ドメインにかかわらず、ポート 80 のすべての要求で使用可能となることを指定します。
- 11 -
プロキシー仮想ホストの構成方法は、以下の通りです。
Step1 プロキシー・アクションの作成
プロキシーに実行させるアクションを定義します。定義したアクションは、プロキシー・ルール式に基づ
き、実行されます。プロキシー・ルール式が true に評価されると、プロキシー・アクションが実行されま
す。プロキシー・ルール式に対して次のプロキシー・アクションを構成できます。
•
キャッシング・アクション
•
圧縮アクション
•
ヘッダー・アクション
•
再書き込みアクション
•
ルーティング・アクション
キャッシング・アクション
プロキシー・サーバーに対するキャッシング・アクションの設定を構成できます。キャッシング・アクショ
ンは、応答をキャッシュに入れるかどうかを判別するために設定します。
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サ
ーバー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・アクション]→[新規キャッシング・
アクション...]を選択します。[新規キャッシング・アクション...]を選択すると次の画面が表示されます。
上記の構成により、キャッシュを無効にしたり、有効期限の設定などを構成する事が可能です。
圧縮アクション
プロキシー・サーバーに対する HTTP 要求圧縮アクションまたは HTTP 応答圧縮アクションの設定
を構成できます。圧縮アクションは、サーバーへの要求メッセージまたはクライアントへの応答メッセージ
を圧縮するように設定されます。
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サ
ーバー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・アクション] を選択し、圧縮アクシ
ョンから[新規作成]を選択します。[新規作成]を選択すると、2 種類の圧縮アクションが表示されますの
で、要求(プロキシー・サーバーからコンテンツ・サーバー)を圧縮する場合は[HTTP 要求圧縮アクショ
ン... ]を、応答(プロキシー・サーバーからクライアント)を圧縮する場合は[HTTP 応答圧縮アクション... ]
を選択します。
- 12 -
[HTTP 要求/応答圧縮・アクション... ]を選択すると、次の画面が表示されます。アクションの名前の入
力、および圧縮タイプとして「Gzip」、「Deflate」もしくは「任意」を指定します。また、コンテンツ・タイプとし
て、圧縮が適用されるコンテンツ・タイプを指定します。
ヘッダー・アクション
プロキシー・サーバーに対する HTTP 要求ヘッダー・アクションまたは HTTP 応答ヘッダー・アクシ
ョンの設定を構成できます。ヘッダー・アクションは、要求および応答ヘッダーを追加、変更、または削
除するように設定できます。
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSpher プロキシー・サー
バー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・アクション] を選択し、ヘッダー・ア
クションから[新規作成]を選択します。[新規作成]を選択すると、2 種類のヘッダー・アクションが表示さ
れますので、要求ヘッダーを編集する場合は[HTTP 要求ヘッダー・アクション... ]を、応答ヘッダーを編
集する場合は[HTTP 応答ヘッダー・アクション... ]を選択します。
- 13 -
[HTTP 要求/応答ヘッダー・アクション... ]を選択すると、次の画面が表示されます。アクションの名前
の入力、および編集する対象となる HTTP ヘッダー名を指定します。また、変更アクションや変更する値
を指定します。
•
ヘッダー変更アクション
要求ヘッダーまたは応答ヘッダーに対して実行するアクション (SET、APPEND、EDIT、REMOVE)
を指定します。
ヘッダー変更アクションの設定内容は次の通りです。
表 4-1 ヘッダー変更アクション
設定値
SET
APPEND
EDIT
REMOVE
•
•
説明
要求ヘッダーまたは応答ヘッダーの新しい値を追加します。値が存在しない場合は、こ
の値が追加されます。値が存在する場合は、この値が現行値に取って代わります。
要求ヘッダーまたは応答ヘッダーの現行値に値を追加します。ヘッダーの値が存在しな
い場合は、この値が追加されます。ヘッダーの値が存在する場合は、この値が現行値の
後に追加されます。
要求ヘッダーまたは応答ヘッダーの現行値を別の値に変更します。ヘッダーの値が存
在する場合は、この値が正規表現検索置換に等価変更されます。
指定されたヘッダーを除去します。ヘッダーが存在する場合は、ヘッダーが除去されま
す。ヘッダーが存在しない場合は、何のアクションも実行されません。
ヘッダー値
ヘッダー変更アクションとして実行される値を指定します。
ヘッダー値の式
- 14 -
ヘッダー名フィールドの値に適用される正規表現を指定します。一致するものが存在する場合は、ヘ
ッダー値フィールドに指定された値がヘッダー名フィールドの現行値に取って代わります。
•
メソッド名 (要求のみ)
アクションが適用される HTTP メソッド (GET や POST など) を指定します。値が指定されていな
いと、すべてのメソッド名に対してアクションが適用されます。
•
状況コード (応答のみ)
アクションが適用される戻り状況コード (200 や 503 など) を指定します。値が指定されていないと、
すべての状況コードに対してアクションが適用されます。
再書き込みアクション
プロキシー・サーバーが処理するインバウンド要求に対して書き換えアクションを実行するように構成
できます。書き換えアクションは、プロキシー・サーバーが応答メッセージの URL のエレメントをどのよう
に書き換えるかを定義します。多くの場合、書き換えアクションの目的は、バックエンド・サーバー ID を
プロキシー・サーバーの ID でマスクすることにあります。
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSpher プロキシー・サー
バー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・アクション]→[新規再書き込みアク
ション...]を選択します。[新規再書き込みアクション...]を選択すると次の画面が表示されます。
•
再書き込みアクション・タイプ
実行する書き換えアクションのタイプを指定します。指定できる書き換えアクション・タイプは、絶対
URL 応答、リダイレクト・ロケーション・ヘッダー、リダイレクト状況コード、相対 URL 応答、Cookie ドメイ
ンの設定、および Cookie パスの設定です。
再書き込みアクション・タイプの設定内容は次の通りです。
表 4-2 再書き込みアクション・タイプ
設定値
説明
- 15 -
絶対 URL 応答
リダイレクト・ロケー
ション・ヘッダー
リダイレクト状況コ
ード
相対 URL 応答
Cookie ド メイ ン の
設定
Cookie パスの設定
HTTP 応答のタグ属性にある絶対 URI を書き換えます。 プロキシー・サーバー
は応答をスキャンして、From パターンと一致する属性を探します。 From パター
ンと一致するものが見つかると、プロキシーは To パターンに基づいて応答を書
き換えます。以下に例を示します。
frPattern = '/(.*)'
toPattern = '/prefix/$1'
タグ <img src="http://someserver/1.jpg" /> は
<img src="http://prefix/someserver/1.jpg" /> に変更されます。
HTTP 応答の relocation ヘッダーにある URI を書き換えます。以下に例を示し
ます。
fromPattern = 'http:(.*)'
toPattern = 'https:$1'
ロ ケ ー シ ョ ン ・ ヘ ッ ダ ー : "Location: http://www.ibm.com" は "Location:
https://www.ibm.com" に変更されます。
応答メッセージの先頭行にあるリダイレクト状況コード (301 や 302 など) を指
定します。
応答のタグ属性にある相対 URL を書き換えます。プロキシー・サーバーは応答
をスキャンして、From パターンと一致する属性を探します。 From パターンと一
致するものが見つかると、プロキシーは To パターンに基づいて応答を書き換え
ます。以下に例を示します。
fromPattern = '/(.*)'
toPattern = '/prefix/$1'
タグ <img src="/myimages/1.jpg" /> は <img src="/prefix/myimages/1.jpg" />
に変更されます。
Set Cookie ヘッダーのドメイン属性を書き換えます。以下に例を示します。
fromPattern = '(.*)'
toPattern = '$1.cn'
Set Cookie ヘッダー:
"Set-Cookie: JSESSIONID: abcdefg; domain="www.ibm.com""
は
"Set-Cookie: JSESSIONID: abcdefg; domain="www.ibm.com.cn""
に変更されます。
Set Cookie ヘッダーのパス属性を書き換えます。以下に例を示します。
frPattern = '(.*)'
toPattern = '/prefix$1'
Set Cookie ヘッダー:
"Set-Cookie: JSESSIONID: abcdefg; domain="www.ibm.com"; path="/""
は
"Set-Cookie: JSESSIONID: abcdefg; domain="www.ibm.com"; path="/prefix/""
に変更されます。
•
From パターン
ターゲット・サーバーからの応答の中にある元の URL パターンを指定します。パターンにはワイルド
カード記号として * を含めることができます。 URL パターンには 1 つ以上のアスタリスク (*) を含め
ることができます。
•
To パターン
- 16 -
書き換え後の結果パターンを指定します。パターンにはワイルドカード記号として * を含めることが
できます。 URL パターンには 1 つ以上のアスタリスク (*) を含めることができます。
•
受動再書き込みを使用可能にする(チェックボックス)
URI の書き換えを、その URI に対する後続要求がクライアントから送られてくるまで据え置くかどう
かを指定します。受動書き換えを使用可能にすると、プロキシー・サーバーは、応答をクライアントに送り
返す前に応答内のすべてのリンクを必ずしも書き換えなくなります。
•
Cookie 名
パスまたはドメイン属性が書き換えられる Cookie を指定します。この設定は、アクション・タイプが
Set-Cookie パスまたは Set-Cookie ドメインである場合にのみ有効です。
•
URL パターンの制限
再書き込み・アクションが実行される URL パターンを制限する事ができます。
•
Cookie ドメインの制限
Cookie ドメインの書き換え対象を指定された一組のドメインにのみ制限する制約を指定します。ドメイ
ンが指定されていないと、すべてのドメインが書き換えられます。このフィールドは、指定された書き換え
アクション・タイプが Set Cookie ドメインである場合にのみ有効です。
•
Cookie パスの制限
Cookie パスを指定されたパスに書き換えるアクションを制限する制約を指定します。パスが指定され
ていないと、すべてのパスが書き換えられます。このフィールドは、指定された書き換えアクション・タイプ
が Set Cookie パスである場合にのみ有効です。
ルーティング・アクション
プロキシー・サーバーに対するルーティング・アクションの設定を構成できます。ルーティング・アクショ
ンでは、以下の 5 つを選択できます。
•
•
•
•
•
アプリケーション・サーバー経路...
汎用サーバー・クラスター経路...
失敗経路...
リダイレクト経路...
ローカル経路...
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSpher プロキシー・サー
バー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・アクション]→を選択し、ルーティン
グ・アクションから[新規作成]を選択します。[新規作成]を選択すると、上記の 5 つ種類のルーティング・
アクションが表示されますので、設定したいアクションを選択します。
＜アプリケーション・サーバー経路…＞
- 17 -
•
時刻ルール
このルールは通常、保守時間帯を設定したい場合に使用されます。特定のクラスター・メンバーへの
ルーティングの組み込みまたは除外を行う開始時刻と終了時刻を指定できます。
「新規時間マッピング…」を選択すると、時間マッピングの時間間隔を指定する「時間マッピング設定」
ページが表示されます。時間マッピングを作成、削除、または編集できます。
表 4-3 時刻ルール
設定
時間
アクション
説明
マッピングさせる時間の開始時刻と終了時刻を指定します。
「組み込み」を設定すると、サーバーは指定した時間にクラスター・メンバーにル
ーティングします。
「除外」を設定すると、サーバーは、指定した時間中、クラスター・メンバーにルー
ティングしません。
- 18 -
＜汎用サーバー・クラスター経路…＞
特定の汎用サーバー・クラスターへのインバウンド要求用経路を定義する汎用サーバー・クラスター・
ルーティング・アクションを追加できます。
•
汎用サーバー・クラスター名
汎用サーバー・クラスターの作成時に提供された汎用サーバー・クラスター名を指定します。汎用サ
ーバー・クラスターについては、「4-1-1-2 汎用サーバー・クラスター」を参照ください。
•
アクティブなアフィニティー
汎用サーバー・アプリケーションとのアプリケーション・アフィニティーを管理するかどうかを指定しま
す。「アクティブなアフィニティー」は、汎用サーバー・アプリケーションが Cookie を発行できないなどの
理由でアフィニティーを管理できないときに使用されます。
プロキシー・サーバーは、アフィニティーを維持し、かつ構成された一定時間内に要求が正しいサー
バーに返されるように、Cookie を設定します
•
受動のアフィニティー
プロキシー・サーバーがターゲットの汎用サーバーによって設定された Cookie を使用してアフィニ
ティーを管理するかどうかを指定します。「受動のアフィニティー」は、プロキシーが汎用サーバーとのア
フィニティーを管理する際に使用する Cookie を設定するときに使用されます。
管理者は、Cookie 名を指定してから、Cookie 値を各汎用サーバーにマップします。
•
Cookie マッピング
Cookie のマッピングを指定します。 Cookie マッピングは、Cookie 値を汎用サーバーにマップする
ために使用されます。
表 4-4 Cookie マッピングの設定
設定
Cookie 値
Cookie ホスト
説明
サーバーが設定する Cookie の値を指定します。 Cookie 値は、ホストとポート
によって定義されたサーバーにマップされます。
ターゲット・サーバーのホスト名を指定します。
- 19 -
Cookie ポート
•
ターゲット・サーバーのポートを指定します。
時刻ルール
アプリケーション・サーバー経路で説明した時刻ルールと同様です。
＜失敗経路…＞
失敗経路では、インバウンド要求に対して指定した障害状況コードを返すために使用します。
•
失敗状況コード
クライアントに送る、要求が失敗したしたことを示す HTTP 状況コードを指定します。有効な値はゼロ
より大きい値の整数です。
＜リダイレクト経路…＞
リダイレクト経路は、インバウンド要求を別の URL にリダイレクトするために使用します。
•
リダイレクト URL
302 リダイレクト応答でクライアントに送る URL を指定します。
- 20 -
＜ローカル経路…＞
ローカル経路では、インバウンド要求をローカルで処理させたい時に使用します。
•
静的ファイルの文書ルート
静的ファイルが置かれている、ファイル・システム上のルート・ディレクトリーを指定します。「編集」を選
択すると、プロキシー・サーバーまたは個々のプロキシー・サーバー仮想ホストの静的ファイル文書ルー
トを設定する「プロキシー設定」ページが表示されます。
Step2 プロキシー・ルール式の作成
プロキシー・アクションを作成したら、次に、どのような有効範囲でアクションを実行するか判別させる
ために、プロキシー・ルール式を作成します。定義したプロキシー・ルール式の条件がマッチすると、
True となり、「Step1 プロキシー・アクションの作成(P11))」で作成したアクションが実行されます。
Step2-1
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サ
ーバー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・ルール式] を選択し、[新規作
成]を選択します。[新規作成] を選択すると次の画面が表示されますので、式を作成するために[副次
式ビルダー…]を選択します。
- 21 -
Step2-2
副次式ビルダーを選択すると次の画面が表示されますので、これを使用して有効範囲を指定します。
設定できるオペランドは次の単位になります。
表 4-5 ルール式のオペランド
オペランド
セル
アプリケーション
モジュール
URI
URI グループ
説明
要求のマップ先となる、バックエンド・サーバーが含まれているセルを指定します。
要求のマップ先となる、バックエンド・サーバー上の Java EE アプリケーションを指
定します。
要求のマップ先となる、Java EE アプリケーション・モジュールを指定します。
インバウンド要求の URI を指定します。
この URI と突き合わせる URI のグループを指定します。インバウンド要求が URI
グループ内にあると、式は true に評価されます。
上記の有効範囲を選択し、各有効範囲の対象を選択したら、[副次式の生成]を選択します。選択す
ると、[副次式]の欄に式が表示されますので、 OK を選択します。
Step2-3
式を作成したら、次にどのアクションを有効にするか選択します。
- 22 -
作成されたアクションが表示されますので、実行させたいアクションを選択し、矢印を選択して右へ移
動させ、ルール式に対応するアクションを選択します。
Step3 プロキシー仮想ホストの作成
要求が、指定された仮想ホスト名およびポートにマッチした場合、さらにプロキシー・ルール式との比
較が行われます。そして、更にプロキシー・ルール式にもマッチした場合に、アクションが実行されます。
管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere プロキシー・サ
ーバー]→[Proxy_name]→[プロキシー仮想ホスト構成]→[プロキシー・仮想ホスト] を選択し、[新規作
成]を選択します。[新規作成] を選択すると次の画面が表示されます。
作成されたプロキシー・ルール式が表示されますので、実行させたいルール式を選択し、矢印を選択
して右へ移動させ、プロキシー仮想ホストに対応するルール式を選択します。
- 23 -
4-2 オンデマンド・ルーター
4-2-1 オンデマンド・ルーター概要
オンデマンド・ルーター(ODR)は、Intelligent Management 環境で使用する HTTP および SIP プロキシ
ー・サーバーです。ODR は一般的なプロキシー・サーバーと同様に JVM プロセスとして稼動します。
WAS V8.5 より前のバージョンでは ODR を使用するためには WAS の上位製品である WebSphere
Virtual Enterprise(WVE)という製品を使用する必要がありました。WAS V8.5 では WVE が WAS に統合
され、追加ライセンス不要で WVE のコンポーネント(ODR やオートノミック・マネージャーなど)および機
能が利用できるようになりました。ODR は Intelligent Management 環境への重要なエントリーポイントであ
り、HTTP リクエストや SIP メッセージをバックエンドのアプリケーション・サーバーに転送するゲートウェイ
となります。ODR を配置することで、Intelligent Management 機能であるリクエストの優先制御や流量制
御、動的ワークロード管理、エディション・コントロール機能などを利用することが可能です。
4-2-2 オンデマンド・ルーターのトポロジー
Intelligent Management 環境における ODR の基本的なトポロジーを図 8-3 に示します。
単一障害点（SPOF）を排除するために ODR を冗長化し、前段に負荷分散装置を配置します。ODR
は JVM プロセスとして稼働するため、アプリケーション・サーバーと同じセキュアゾーンに配置する必要
があります。（プロセス間内部通信が発生するため）
また、一般的に ODR はアプリケーション・サーバープロセスと別 OS に配置することが推奨とされてい
ます。これは、ODR はリクエストの統計情報やサーバーのリソース使用状況から割り振り等の最適化を
行いますが、ODR とアプリケーション・サーバーを同一 OS 上に混在させると、同居させたノード上の統
計情報やリソース使用状況は ODR とアプリケーション・サーバー両方をあわせたものとなってしまい、各
アプリケーション・サーバープロセス単体が使用するリソース状況の適切な判断ができなくなる恐れがあ
るためです。
セル
ノードA
Load Balancer
(Primary)
ノードE
ノードC
アプリケーション
サーバー
ODR
ODR
ノードB
ノードF
ノードD
Load Balancer
(Backup)
アプリケーション
サーバー
ODR
図 4-3 ODR の基本的なトポロジー
- 24 -
次に ODR の前段に Web サーバーである IHS を配置するトポロジーを示します。以下のような要件が
ある場合にこのトポロジーを検討します。
・ DMZ に IHS を配置してクライアントからの接続を終端させたい（DMZ への ODR 配置は NG）
・ IHS 側で SSL 解除を行いたい
・ IHS に静的コンテンツを配置したい
・ IHS のキャッシュ機能を利用したい
DMZ
Firewall
Secure
セル
ノードA
Load Balancer
(Primary)
ノードC
ノードE
IHS
ODR
Plugin
ノードG
アプリケーション
サーバー
ノードB
Load Balancer
(Backup)
ノードD
ノードF
IHS
ODR
Plugin
ノードH
アプリケーション
サーバー
図 4-4 ODR の前段に IHS を配置するトポロジー
4-2-3 オンデマンド・ルーターによるワークロード管理
次に ODR によるワークロード管理について記載します。
従来の Web サーバー・プラグインによるワークロード管理
従来の Web サーバー・プラグインによる割り振り方式は重み付きラウンドロビンであり、リクエストを順
番に割り振ります。また実際のリクエストは重い処理や軽い処理などがあり、リクエスト処理毎に必要なリ
ソースに差が生じることで、アプリケーション・サーバーの負荷の偏りが発生する可能性があります。ま
た、サーバー拡張に伴うルーティング情報の更新は Web サーバー・プラグイン構成ファイルの生成・伝
播を手動で行う必要があります。
ODR によるワークロード管理
ODR はオートノミック・マネージャーの動的ワークロード・マネージャー(DWLM)がオンデマンド構成
（ODC）のルーティング情報を使用して動的にワークロード管理を行います。DWLM コンポーネントがア
プリケーション・サーバーの稼働状況を監視して、動的に割振りの重みを計算して ODC 上の値を更新し
ます。その重みをもとに DWLM が負荷分散を行い、負荷が高いサーバーへの割り振りが抑制され、負
荷が少ないサーバーへの割り振りが増えるといった調整が自律的に行われます。したがって、アプリケ
ーション・サーバーの負荷が平準化され、リソース使用率を均一にすることが可能となります。またサー
- 25 -
バー増強を実施した場合においてもルーティング情報が動的に更新されるため、プラグイン構成ファイ
ルの生成・伝播といった作業は必要ありません。
オンデマンド・ルーター
(ODR)
A
ARFM
動的ワークロード
マネージャー
(DWLM)
B
C
ルーティング情報の動的更新
(On Demand Configuration)
D
負荷の平準化
サーバー監視
• CPU使用率
• スループット
• 同時リクエスト数など
サーバー拡張
図 4-5 ODR による動的なワークロード管理
4-2-3-1 オンデマンド構成(ODC)
ODR はプロキシー・サーバーであるため、ルーティング情報はオンデマンド構成(ODC)によって動的
に更新されます。このルーティング情報は通常メモリー上に保持され、各 JVM 間の ODC 情報の交換は
BBSON (Bulletin Board over Service Overlay Network)が使用されます。（BBSON の詳細は後述）
ODC のルーティング情報は以下のトレース設定を行うことで target.xml ファイルに書き出すことがで
きます。管理コンソールにて、[トラブルシューティング]→[ログおよびトレース]→[<ODR 名>]→[ログ詳
細レベルの変更]を選択します。次のトレース・ストリングを設定して、設定を保管します。
com.ibm.ws.odc.nd.ODCTreeImpl$Save=all
- 26 -
出力されるルーティング情報は以下のファイルに書き出されます。ODR 起動時と、セルに対して構
成の変更があった際に、自動的に新しい target.xml が生成されます。
<ODR_Profile_Root>/installedFilters/wlm/<ODR 名>/target.xml
target.xml ファイルには以下のような情報が含まれます。ルーティングに問題がある場合、target.xml
の内容を確認し問題判別を実施します。ただし、target.xml はあくまである一時点でのダンプ情報です
ので、構成変更が行われると内部的に保持される情報も変わります。
・ セル情報 (ARFM パラメーターなど)
・ ノード情報 (CPU Spec (Speed, CPU 数など))
・ サーバー情報 (クローン ID、稼働状況、DWLM ウエイト値、エンド・ポイント情報など)
・ 仮想ホスト/アプリケーション関連情報
・ 動的クラスター情報 (マッピングされたノード・グループおよびノード、導入 Web モジュール)
・ サービス・ポリシー情報 (ビジネス・ゴールと重要度の定義)
・ トランザクション・クラス (ポリシー定義の対象となる URI)
target.xml の例
<server name="DCluster01_CustNode01">
<property name="id" priority="1" value="17v1p87or"/>
<property name="type" priority="1" value="APPLICATION_SERVER"/>
<property name="state" priority="1" value="STARTED"/>
<property name="ODR" priority="1" value="false"/>
<property name="reachable" priority="0" value="true"/>
<property name="weight" priority="1" value="20"/>
<property name="staticweight" priority="1" value="2"/>
<property name="threadPoolMin" priority="1" value="20"/>
<property name="threadPoolMax" priority="1" value="20"/>
<property name="threadPoolIsGrowable" priority="1" value="false"/>
<property name="sessionPersistenceMode" priority="1" value="NONE"/>
<property name="sessionAffinityCookies" priority="1" value="JSESSIONID"/>
<property name="server.maintenancemode" priority="1" value="false"/>
・・・・・
また、ODR 障害時の情報収集の際に利用する odrDebug.py スクリプトや dumpOdrState.jacl スクリプト、
dumpIMPState.py スクリプトにてルーティング情報を取得することが可能です。
WAS V8.5 Information Center 「odrDebug.py スクリプト」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odrdebugscript.html
WAS V8.5 Information Center 「dumpOdrState.jacl スクリプト」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odrdump.html
WAS V8.5 Information Center 「dumpIMPState.py スクリプト」
- 27 -
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_xddumpscript.html
4-2-3-2 BBSON
Intelligent Management 環境では、HA マネージャーと独立した Bulletin Board Service Overlay
Network (BBSON) を提供しています。BBSON は HA マネージャーと同様に各 JVM のプロセス間通信
を行うコンポーネントであり、ODC 情報を連携するための掲示板として利用されます。BBSON は
Intelligent Management コンポーネントでのみ使用されます。
WAS V8.5 Information Center 「BBSON 電子掲示板」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/cwve_bbsonover.html
4-2-3-3 動的ワークロードマネージャー(DWLM)
ODR が持つオートノミック・マネージャーのひとつに動的ワークロード管理(DWLM)があります。実際
の割り振りを行う DWLM の実体は ODR 内に存在しますが、この割り振りのウェイトを計算し DWLM に
レポートするコンポーネントが DWLM コントローラーです。
DWLM コントローラーはパフォーマンス情報(ノードの CPU 使用率、アプリケーション・サーバーのス
ループット、アプリケーション・サーバーの同時リクエスト数など)からアプリケーション・サーバー毎の重
み(ウェイト)を自動的に計算し、DWLM に定期的(20 秒毎)にレポートします。DWLM はこのウェイト値に
したがってリクエストの各アプリケーション・サーバーへの割り振りを行います。DWLM コントローラーは
いずれかのノード・エージェントまたはアプリケーション・サーバー上で HA Manager の管理のもとで稼動
しています。DWLM コントローラーが稼動しているプロセスが落ちたとしても HA Manager によって別の
稼動プロセス上にフェイルオーバーされます。DWLM は動的クラスターではデフォルトで利用可能に設
定されています。通常の静的クラスターに対しても DWLM を動作させることができますが、デフォルトで
は利用可能にはなっていません。
DWLM
コントローラー
DWLM
ウェイト値
オンデマンド・ルーター
(ODR)
各アプリケーション・サー
バーのパフォーマンス情報
を取得し、DWLMウェイト値
を計算
DWLM
DWLM
ウェイト値
ルーティング情報
- 28 -
図 4-6 DWLM による動的なワークロード管理
4-2-4 セッション管理
ODR を使用した Intelligent Management 環境におけるセッション管理は、従来の WAS と同様に
Cookie を使用したセッション・アフィニティーによってセッション維持を行います。アプリケーション・サー
バー障害時においてもセッション維持を行いたい場合はセッション・パーシスタンスを構成します。
Intelligent Management 環境においては、サービスレベル維持やサービス無停止のために障害時以外
のシナリオにおいてもリクエストを別メンバーにルーティングするケースがあります。例えば、サービスレ
ベル維持のために動的クラスターのメンバーを動的に起動停止する場合や、サービス無停止でアプリケ
ーションを更新するためにエディション管理機能を使用する場合などのシナリオがあります。そのような
ケースにおいてもセッションを維持してエンドユーザーに影響を与えないようにするためにはセッション・
パーシスタンスを構成する必要があります。
4-2-4-1 セッション・リバランス機能
次に、セッション・リバランス（セッションの再平衡化）機能について説明します。セッション・リバランス
機能は DWLM(動的ワークロードマネージャー）がアプリケーション・サーバー間で HTTP セッションのリ
バランスを動的に行う機能です。動的クラスターが対象となります。動的クラスター・メンバーが追加され
たり、メンバーサーバーが障害から復旧したような場合、新規メンバーには新規リクエストが割り振られる
ものの、アフィニティーが効いたリクエストは既存メンバーに割り振られることになります。そのため、既存
メンバー上のセッション数が多くメンバー間でセッション数の不均衡が発生し得ます。セッション・リバラン
ス機能を使用することで、セッション数が DWLM のウェイト値に比例するようにリバランスが行われます。
また、ただし、セッション・リバランス機能を使用する場合にはセッション・パーシスタンスが構成されてい
ることが前提になります。
以下のケースではセッション・リバランスが実行されませんので注意してください。
・ HTTP POST リクエストの場合
・ ODR をバイパスして直接アプリケーション・サーバーの HTTP ポートにリクエストを投げてセッショ
ンにアクセスした場合
・ URL 再書き込みや SSL ID によってセッション維持をしている場合（Cookie によるセッション維持
のみ対象）
構成方法
1.
2.
セッション・パーシスタンスを構成します。セッション・パーシスタンス構成方法は 3 章の「セッション・
パーシスタンス設定」をご参照ください。
管理コンソールで、[サーバー]→[クラスター]→[動的クラスター]を選択し、動的クラスター名をクリッ
クして追加プロパティーのカスタム・プロパティーを選択します。新規作成をクリックして以下のカス
タム・プロパティーを追加します。
名前：HttpSessionRebalanceOff
値：false(デフォルト)
セッション・リバランス機能を使用不可にしたい場合は true を指定します。
- 29 -
3.
新規メンバーに対するアフィニティーを元のメンバーの復旧後にも維持するために、全クラスター・
メンバー上のカスタム・プロパティーを設定します。管理コンソールで、[サーバー]→[動的クラスタ
ー]→[動的クラスター名]→[サーバー・テンプレート]→[セッション管理]→[カスタム・プロパティー]
を選択します。
[新規]をクリックして、以下のカスタム・プロパティーを追加します。
名前：NoAffinitySwitchBack
値：true(デフォルトは false)
- 30 -
4.
設定を保管してサーバーを再起動します。
WAS V8.5 Information Center 「HTTP セッションの再平衡化」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/cwve_odrsessionbalance.html
WAS V8.5 Information Center 「動的クラスター・カスタム・プロパティー (HttpSessionRebalanceOff)」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odccustprop.html
WAS V8.5 Information Center 「セッション管理のカスタム・プロパティー (NoAffinitySwitchBack)」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.nd.doc/ae/r
prs_custom_properties.html
4-2-5 オンデマンド・ルーターの構成手順
ここからは、実際にオンデマンド・ルーターを構成する方法について説明します。オンデマンド・ルー
ターを構成するプロファイルとしては、DM に統合されたカスタム・プロファイルを使用します。
以下、単体サーバーおよびクラスター構成の ODR を作成する手順を記載します。
・ 単体サーバー
・ 静的クラスター
・ 動的クラスター
4-2-5-1 単体サーバーの場合
Step1 オンデマンド・ルーターの作成
管理コンソールで、[サーバー]→[サーバー・タイプ]→[オンデマンド・ルーター] を選択し、 [新規作
成] ボタンを選択します。
- 31 -
Step2 オンデマンド・ルーターの名前の入力
作成するオンデマンド・ルーターに任意の名前を指定します。
Step3 プロトコルの選択
プロキシーとして対応させるプロトコルを、HTTP もしくは SIP から選択します。SIP を使用しない場合な
どはチェックボックスからチェックを外し、[次へ]を選択します。[固有ポートの生成]にチェックする事で、
垂直クラスタリングのため、同じノード上に複数の JVM を作成する場合、ポート競合を避けるために固有
ポートを生成することができます。
Step4 テンプレートの選択
サーバー・テンプレートとして http_sip_odr_server が選択されていることを確認し、[次へ]を選択しま
す。
- 32 -
Step4 新規サーバーの確認
作成するプロキシー・サーバーの構成が正しいか確認し、[終了]を選択します。
Step5 仮想ホストの登録
作成されたオンデマンド・ルーターでは、オンデマンド構成(ODC)により、デフォルトで同一セル内に
ある WAS への割り振りが有効になります。但し、WAS の仮想ホストに、作成した ODR のホスト名および
ポートの登録が必要となります。
- 33 -
4-2-5-2 静的クラスターの場合
次に ODR の静的クラスターを作成する手順について示します。
Step1 ODR の静的クラスターの作成
ODR の静的クラスターは管理コンソールにて作成することができません。wsadmin コマンドを使用して
作成します。静的クラスターを作成する前に単体の ODR は事前に作成しておく必要があります。
以下のコマンドを実行して ODR の静的クラスターを作成します。クラスター名、事前に作成した ODR
のノード名と ODR の名前を指定します（斜体文字部分）。
$AdminTask createCluster {-clusterConfig {-clusterName ODRStaticClusterName -clusterType
ONDEMAND_ROUTER} -convertServer {-serverNode NodeName -serverName ODRName}}
$AdminConfig save
作成済みの ODR 静的クラスターにクラスター・メンバーを追加したい場合は以下のコマンドを実行し
ます。クラスター名、メンバーサーバー作成先のノード名、ODR メンバーサーバー名を指定します（斜体
文字部分）。クラスター・メンバーは下記コマンドで作成されるため、事前に作成する必要はありません。
$AdminTask createClusterMember {-clusterName ODRStaticClusterName -memberConfig {-memberNode
NodeName -memberName ODRMemberName}}
$AdminConfig save
なお、作成した ODR 静的クラスターは管理コンソールで確認することが可能です。
- 34 -
4-2-5-3 動的クラスターの場合
次に ODR の動的クラスターを作成する手順について示します。
Step1 動的クラスターの作成
管理コンソールで、[サーバー]→[クラスター]→[動的クラスター] を選択し、 [新規作成] ボタンを選
択します。
Step2 サーバー・タイプの選択
動的クラスター・サーバー・タイプとして「オンデマンド・ルーター」選択します。
Step3 メンバーシップ・メソッドの定義
[ルールによるクラスター・メンバーの自動定義]が選択されていることを確認して、動的クラスター名を
入力して[次へ]をクリックします。
- 35 -
Step4 動的クラスター・メンバーの定義
副次式ビルダーを使用してメンバーシップ・ポリシーを定義して[次へ]をクリックします。
ここではノード・グループを指定しています。ノード・グループには ODR 動的クラスター・メンバーを配
置するノードを予め定義しています。
メンバーシップ・ポリシーとして、以下の例のようにノード名を指定することも可能です。
例：node_name = 'ODR_Node01' and node_name = 'ODR_Node02'
- 36 -
Step4 動的クラスター・テンプレートの選択
使用するテンプレートを選択して[次へ]をクリックします。
Step4 動的クラスター特定のプロパティーの指定
クラスターインスタンスの最小数および最大数、垂直スタッキングの許可、分離設定について設定を
行い、[次へ]をクリックします。
- 37 -
Step4 動的クラスターの設定確認
作成する ODR 動的クラスターの構成が正しいか確認し、[終了]を選択して構成を保管します。
4-2-6 IHS と ODR の連携
下記図のようなトポロジーで ODR の前段に IHS を配置して高可用構成を組むことが可能です。
DMZ
Firewall
Secure
セル
ノードA
Load Balancer
(Primary)
ノードC
ノードE
IHS
ODR
Plugin
ノードG
アプリケーション
サーバー
ノードB
Load Balancer
(Backup)
ノードD
ノードF
IHS
ODR
Plugin
ノードH
アプリケーション
サーバー
図 4-7 ODR の前段に Web サーバーを配置した場合のトポロジー図
IHS から ODR へリクエストを割り振るためのプラグイン構成ファイルは構成が変更されると動的に生成
および更新することが可能です。
また、プラグイン構成ファイルが更新される度に実行されるスクリプトを定義することができます。
そのスクリプトに plugin-cfg.xml を httpd.conf で指定しているディレクトリーにコピーする処理を定義す
ることで自動伝播が可能です（後述）。
- 38 -
ODR のプラグイン構成ファイルの生成は以下２つの方法を選択することができます。
【方法 1】ODR によるプラグイン構成ファイルの生成
【方法 2】HAPluginCfgGenerator によるプラグイン構成ファイルの生成（推奨）
【方法 1】は ODR プロセスによるプラグイン生成となります。この方法は ODR プロセスが停止している
とプラグイン構成ファイルの生成ができないという考慮点があるため、【方法 2】の HAPluginCfgGenerator
の利用を推奨しています。
【方法 2】の方法はオートノミック・マネージャーのひとつである”HAPluginCfgGenerator”がプラグイン
構成ファイルの生成および更新を行います。
Information Center で は 高 可 用 性 プ ラ グ イ ン 構 成 生 成 と 和 訳 さ れ て い ま す が 、 本 ガ イ ド で は
HAPluginCfgGenerator と記載します。オートノミック・マネージャーはセル内の任意の１プロセス上で常
時稼働していますので、稼働していたプロセスが停止した場合においても別プロセス上で稼働しつづけ
るため、常にプラグイン構成ファイルを動的に生成および更新することが可能です。
本ガイドでは推奨となる HAPluginCfgGenerator によるプラグイン生成に必要な設定を記述します。
尚、ODR によるプラグイン生成は以下の URL を参照してください。
WAS V8.5 Information Center 「Web サーバー・プラグイン構成を動的に更新するための ODR の構
成」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_odrWebserver.html
4-2-6-1 HAPluginCfgGenerator によるプラグイン構成ファイル
の生成
HAPluginCfgGenerator によるプラグイン生成を行うためには、以下のステップを実施する必要があり
ます。
ステップ
ステップ
ステップ
ステップ
ステップ
ステップ
1. 信頼されるセキュリティー・プロキシーに Web サーバーを登録する
2. Web サーバー・プラグインの自動生成、伝播のチェックを OFF にする
3. 動的に生成された plugin-cfg.xml ファイルを転送するためのスクリプトを用意する
4. HAPluginCfgGenerator によるプラグイン構成ファイル生成のための設定を行う
5.（オプション）プラグインプロパティーの設定
6. (オプション)HAPluginCfgGenerator の稼働場所の指定
ステップ 1. 信頼されるセキュリティー・プロキシーに Web サーバーを登録す
る
ODR の前段に Web サーバーが配置されている場合、Web サーバーを信頼されるセキュリティー・プロ
キシー・サーバーとして構成する必要があります。
信頼されるセキュリティー・プロキシーとして登録された Web サーバーはプライベートヘッダー内の仮
想ホスト名やユーザーID などの情報を ODR に渡すことが許可されます。
- 39 -
信頼されないプロキシー(Web サーバー)から受け取ったプライベートヘッダーは ODR によって破棄さ
れます。
Web サーバーを信頼できるプロキシー・サーバーとして構成するには、管理コンソールで[サーバー]
→[サーバー・タイプ]→[オンデマンド・ルーター]→[ODR 名]→[オンデマンド・ルーター設定]→[オンデ
マンド・ルーター・プロパティー]→[オンデマンド・ルーター設定]をクリックします。
オンデマンド・ルーターの動的クラスターを使用している場合、[サーバー]→[クラスター]→[動的クラ
スター]→[ODR 動的クラスター名]→[サーバー・テンプレート]→[オンデマンド・ルーター・プロパティー]
→[オンデマンド・ルーター設定]とクリックします。
「信頼されるセキュリティー・プロキシー」に Web サーバーの IP アドレスあるいはホスト名(FQDN)を指
定します。
ステップ 2. Web サーバー・プラグインの自動生成、伝播のチェックを OFF に
する
Web サーバーが管理ノードとして構成されている場合、もしくは非管理ノードの Web サーバーでプラ
グイン構成ファイルを自動で伝搬するように設定していた場合、ODR 用のプラグイン構成ファイルが上
書きされ、Web サーバー・プラグインの自動生成、伝播によって作成された plugin-cfg.xml が使用されま
す。その場合、Web サーバーから直接アプリケーション・サーバーにリクエストが転送され、ODR を経由
しなくなってしまいます。そのため、管理コンソールから Web サーバー・プラグインの自動生成、伝搬の
チェックを外す必要があります。
ステップ 3. 動的に生成された plugin-cfg.xml ファイルを転送するためのスク
リプトを用意する
HAPluginCfgGenerator がプラグイン構成ファイルを自動生成する度にスクリプトを実行することができ
ます。このスクリプトで、自動生成された plugin-cfg.xml ファイルを IHS 側に転送する処理を行うよう定義
します。注意点として、IHS が DMZ、ODR がセキュアゾーンに配置されており、IHS と ODR の間に
Firewall が存在する場合は、ファイルコピーができるように Firewall 側の設定を確認する必要がありま
す。スクリプトは HAPluginCfgGenerator が稼働するすべてのノードに配置する必要があり、ステップ 4.の
設定ではスクリプトへの絶対パスを指定します。
プラグイン構成ファイルをコピーする単純なサンプルスクリプトをご紹介します。
#!/bin/sh
/usr/bin/scp
/opt/IBM/WebSphere/AppServer/profiles/odr1/etc/plugin-cfg.xml
web2:/usr/IBM/WebSphere/Plugins/config/web2
/usr/bin/scp
/opt/IBM/WebSphere/AppServer/profiles/odr1/etc/plugin-cfg.xml
web1:/usr/IBM/WebSphere/Plugins/config/web1
exit 0
- 40 -
ステップ 4. HAPluginCfgGenerator によるプラグイン構成ファイル生成のた
めの設定を行う
HAPluginCfgGenerator にプラグイン構成ファイルを生成させるために WAS の管理コンソールで設定
（セルのカスタム・プロパティー）を行います。この設定を行うことで、HAPluginCfgGenerator が稼働して
いるノード上に最新のプラグイン構成ファイルが指定したディレクトリー配下に生成され、指定したスクリ
プトが自動生成の都度実行されるようになります。
管理コンソールで、[システム管理]→[セル]→[カスタム・プロパティー]→[新規]をクリックして、カスタ
ム・プロパティーを定義します。
ODR がクラスター構成ではない場合、以下のカスタム・プロパティーを定義します。
•
ODCPluginCfgOdrList_<configName>
•
ODCPluginCfgOutputPath_<configName>
•
ODCPluginCfgUpdateScript_<configName>
•
•
•
•
ODR がクラスター構成の場合、以下のカスタム・プロパティーを定義します。
ODCPluginCfgOdrClusterList_<configName>
ODCPluginCfgOutputPath_<configName>
ODCPluginCfgUpdateScript_<configName>
ODCPluginCfgOdrIncludeStopped_<configName>
- 41 -
以下が各カスタム・プロパティーの説明となります。
名前
ODCPluginCfgOdrList_<configName>
値
cell1:node1:odr1,cell2:node2:*,[cell1:node3:odr3],[cell1:node4:odr4]
説明
このプロパティーは、plugin-cfg.xml ファイルに組み込む ODR を指定します。 各パス・セグメントの有
効なワイルドカードとしてアスタリスク (*) 記号を使用します。odr1 および odr2 には、1 次サーバーの
マークが付けられます。odr3 および odr4 には、バックアップ・サーバーのマークが付けられます。
名前
ODCPluginCfgOdrClusterList_<configName>
値
cell1:cluster1,cell1:cluster2,cell1:*,[cell1:cluster3],[cell1:cluster4]
説明
このプロパティーは、plugin-cfg.xml ファイルに組み込む ODR のクラスターを指定します。各パス・セ
グメントの有効なワイルドカードとしてアスタリスク (*) 記号を使用します。cluster1 および cluster2 に
は、1 次サーバーのマークが付けられます。cluster3 および cluster4 には、バックアップ・サーバーの
マークが付けられます。
名前
ODCPluginCfgOutputPath_<configName>
値
/path/file_name.txt
説明
このプロパティーは、plugin-cfg.xml ファイルがその生成後に入れられるロケーションを指定します。セ
ル内のいずれのノードにもプラグイン構成を生成できるので、各ノードに出力ディレクトリーが存在するこ
とを確認する必要があります。
名前
ODCPluginCfgUpdateScript_<configName>
値
/path/script <parameter1> <parameter2>
説明
このプロパティーは、ステップ 3.で作成したスクリプトへの絶対パスと、定義済みのスクリプトに渡される
引数を定義します。定義済みのスクリプトは、plugin-cfg.xml が生成されるたびに起動されます。
Web モジュールやクラスターやノードグループ、仮想ホスト毎に HTTP トラフィックが経由する ODR ク
ラスターを指定したい場合には以下のカスタム・プロパティーを定義します。
名前
ODCPluginCfgRoutingPolicy_<config>
値
<webModuleSpec>=ODR=<odrClusterName>
説明
<webModuleSpec>=ODR=<odrClusterName> というフォーマットのエレメントのコンマ区切りリストで指定
します。 この値の <webModuleSpec> の部分は、次のいずれかのフォーマットで指定します。
・WebModule:<cell>[/<application>/[<edition>/[<webModule>]]]]
・Cluster:<cell>/<cluster>
・NodeGroup:<cell>/<nodeGroup>
・VirtualHost:<cell>[/<VirtualHost>]
WAS V8.5 Information Center 「ODR クラスターによる HTTP トラフィックの分離」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_hasegregate.html
また、Web サーバーからバックエンド・アプリケーション・サーバーに直接に要求をルーティングした
い場合には以下のカスタム・プロパティーを定義します。
名前
ODR_Module_Routing_Policy
- 42 -
値
cell_name/app_name/edition/module_name=direct
説明
要求をバックエンド・サーバーに直接ルーティングすることができます。ODR 経由でバックエンド・サーバ
ーにルーティングする場合は、cell_name/app_name/edition/module_name=ODR を指定します。例えば、
値を cell/app/edition/module=direct,cell/app2/edition/module=ODR に設定した場合、各モジュールが
そのモジュールへの要求を ODR 経由で送信するか、バックエンド・サーバーに直接送信するかに関し
て個別に構成されます。
WAS V8.5 Information Center 「Web サーバーからバックエンド・アプリケーション・サーバーに直接に
要求をルーティング」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_odrdirect.html
ステップ 5.（オプション）プラグイン・プロパティーの設定
動的に生成される plugin-cfg.xml ファイルに定義されているプラグイン・プロパティーはデフォルト値
に設定されています。このカスタム・プロパティーを使用することでプラグイン・プロパティーをオーバーラ
イドすることが可能です。
 ODCPluginCfgIHSConfigProperties_<configName>
プラグインログ(http_plugin.log)出力先ディレクトリーやログレベル、ServerIOTimeout や MaxConnections
などのパラメーターをカスタム・プロパティーとして設定しておくことで、生成される plugin-cfg.xml には事
前定義したプロパティー値が反映されます。
例)
ODCPluginCfgIHSConfigProperties_1
TrustedProxyEnable=true,LogLevel=INFO,Name=C:¥IBM¥WebSphere¥Plugins¥logs¥webserver1¥http_
plugin.log,ServerIOTimeout=60
WAS V8.5 Information Center 「HA 環境でのプラグイン構成の生成」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_haplugincfg.html
- 43 -
ステップ 6. (オプション)HAPluginCfgGenerator の稼働場所の指定
HAPluginCfgGenerator の稼働場所は管理コンソールで確認することが可能です。管理コンソールに
て[ランタイム操作]→[コンポーネント安定度]を選択して、[コア・コンポーネント]タブを選択します。
HAPluginCfgGenerator の現在の位置が表示されています。
HAPluginCfgGenerator の稼働場所を特定のノード、または、デプロイメント・マネージャー・プロセスで
開始するように構成することも可能です。
管理コンソールにて、以下のカスタム・プロパティーを設定します。尚、このパラメーターは複数の
JVM に対して設定することが可能です。
HAManagedItemPreferred_PluginCfgGenerator=true
 ノード・エージェントに設定する場合
「システム管理]→[ノード]→[ノード名]→[ノード・エージェント]→[Java およびプロセス管理]→[プロセス
定義]→[Java 仮想マシン]→[カスタム・プロパティー]
 デプロイメント・マネージャーに設定する場合
管理コンソールで、「システム管理]→[デプロイメント・マネージャー]→[Java およびプロセス管理]→[プ
ロセス定義]→[Java 仮想マシン]→[カスタム・プロパティー]
WAS V8.5 Information Center 「オートノミック・コントローラー・カスタム・プロパティー」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_hamanagecp.html
4-2-7 オンデマンド・ルーターの設定
オンデマンド・ルーターの設定として以下の項目について説明します。
・ オンデマンド・ルーターのトランスポート
・ アウトバウンド接続設定
・ キャッシング
・ 圧縮ポリシー
- 44 -
・
・
・
・
・
ODR による SSL 解除
カスタム・エラー・ページ・ポリシー
ロギング
ODR カスタム・ログ
ルーティング・ルール
4-2-7-1 オンデマンド・ルーターのトランスポート
クライアントからのリクエストを受けつける際に ODR が Listen する HTTP および SIP ポートは以下のと
おりです。管理コンソールより[サーバー]→[オンデマンド・ルーター]→[<ODR 名>]→[ポート]を選択し
て、設定を確認および変更することができます。
ポート名
説明
PROXY_HTTP_ADDRESS
HTTP リクエストの受付ポート
PROXY_HTTPS_ADDRESS
HTTPS リクエストの受付ポート
PROXY_SIP_ADDRESS
SIP リクエストの受付ポート
PROXY_SIPS_ADDRESS
SIPS リクエストの受付ポート
4-2-7-2 アウトバウンド接続設定
ODR からバックエンドのアプリケーション・サーバーへの接続に関するパラメーターとして、アウトバウ
ンド接続設定があります。
管理コンソールより[サーバー]→[サーバー・タイプ]→[オンデマンド・ルーター]→[<ODR 名>]→[オン
デマンド・ルーターの設定]→[オンデマンド・ルーター・プロパティー]→[オンデマンド・ルーター設定]を
選択すると下記のアウトバウンド接続設定が表示されます。尚、ODR 動的クラスターの場合はサーバ
ー・テンプレートから設定することが可能です。[サーバー]→[クラスター]→[動的クラスター]→[<ODR 動
的クラスター名>]→[サーバー・テンプレート]→[オンデマンド・ルーターの設定]→[オンデマンド・ルータ
ー・プロパティー]→[オンデマンド・ルーター設定]を選択します。
設定項目
説明
アウトバウンド要求読み取りタイムアウト
アプリケーション・サーバーへのリクエストがタイムアウ
- 45 -
トする前に ODR がレスポンスを待つデフォルトの秒数を
指定します。
ODR のトランザクション・タイマーとなり、Web サーバー・プラグ
インの ServerIOTimeout と同様に長時間処理がタイムアウトさ
れないように注意して設定する必要があります。
アウトバウンド要求書き込みタイムアウト
アプリケーション・サーバーへの書き込みリクエストを
ODR が待機するデフォルトの秒数を指定します。ODR のト
ランザクション・タイマーとなり、Web サーバー・プラグインの
ServerIOTimeout と同様に長時間処理がタイムアウトされない
ように注意して設定する必要があります。
アウトバウンド接続タイムアウト
アプリケーション・サーバーへの接続を待つ時間をミリ秒単位
で指定します。
コンテンツ・サーバーへの接続プール
ODR とアプリケーション・サーバー間の接続をプーリン
グして再利用することができます。
サーバーへのソケット接続を頻繁に作成し、破棄する必要が
なくなります。
サーバーあたりの最大接続数
サーバーあたりの最大接続数の一般的な設定は、並行して存
在するクライアントのピーク数を、アプリケーションに割り当てら
れたサーバーの数で割ったものとして計算できます。動的サ
ーバー・クラスターの場合、サーバーの数は、クラスターが定
義されているサーバーの最小数となります。
Web サーバー・プラグインと ODR のタイムアウトの関係
ODR の前段に Web サーバーが配置されている構成の場合、Web サーバー・プラグインと ODR が持
つタイムアウトの関連に注意が必要です。
Web サーバー・プラグインはリクエストがタイムアウトした後に ODR をダウンとマークします。アプリケー
ション・サーバー側の処理が遅いために ODR がダウンとマークされてしまうのを防止するためには、以
下のようにタイムアウトを調整します。
プラグインの”ServerIOTimeout” ≧ ODR の”アウトバウンド要求読み取りタイムアウト”
+ ”アウトバウンド要求書き込みタイムアウト”
+ “アウトバウンド接続タイムアウト”
+ 5秒
クライアント
IHS
IHS
Plugin
Plugin
ODR
ODR
アプリケーション
サーバー
• アウトバウンド要求読み取りタイムアウト
ServerIOTimeout
• アウトバウンド要求書き込みタイムアウト
• アウトバウンド接続タイムアウト
図 4-8 Web サーバー・プラグインと ODR のタイムアウトの関係
- 46 -
4-2-7-3 キャッシング
ODR にはキャッシュ機能が提供されています。キャッシュデータは JVM の Native Memory 上に格納
され、Java ヒープより参照されます。ODR のキャッシング機能を使用しない場合は使用不可にしてくださ
い。ODR キャッシングが使用可能になっている場合、ODR は、要求がキャッシュされるかどうかを決定
するプロセス全体を実行し、キャッシュ・リポジトリーを調べて要求が前にキャッシュされていたかどうかを
判別する必要があります。ODR に対するこの追加オーバーヘッド によって、ODR でボトルネックが生
じる可能性があります。
管理コンソールより[サーバー]→[サーバー・タイプ]→[オンデマンド・ルーター]→[<ODR 名>]→[オン
デマンド・ルーターの設定]→[オンデマンド・ルーター・プロパティー]→[オンデマンド・ルーター設定]を
選択すると下記のキャッシングの設定が表示されます。尚、ODR 動的クラスターの場合はサーバー・テ
ンプレートから設定することが可能です。[サーバー]→[クラスター]→[動的クラスター]→[<ODR 動的ク
ラスター名>]→[サーバー・テンプレート]→[オンデマンド・ルーターの設定]→[オンデマンド・ルーター・
プロパティー]→[オンデマンド・ルーター設定]を選択します。
キャッシングを使用不可にするには「キャッシング使用可能」のチェックボックスを外して設定を保存
し、ODR を再起動します。
4-2-7-4 圧縮ポリシー
ODR は HTTP 応答を圧縮することが可能です。デフォルトは無効になっていますので、使用したい場
合は応答圧縮を有効化してください。
管理コンソールより[サーバー]→[オンデマンド・ルーター]→[ODR 名]を選択して、[オンデマンド・ル
ーター設定]を選択します。尚、ODR 動的クラスターの場合はサーバー・テンプレートから設定すること
が可能です。[サーバー]→[クラスター]→[動的クラスター]→[<ODR 動的クラスター名>]→[サーバー・
テンプレート]→[オンデマンド・ルーターの設定]→[オンデマンド・ルーター・プロパティー]→[オンデマ
ンド・ルーター設定]を選択します。
“応答圧縮を有効化する“にチェックを入れて、応答圧縮を選択します。
- 47 -
応答圧縮のタイプは下記から選択することができます。
オプション
説明
gzip のみ
gzip 圧縮メカニズムを使用する
deflate のみ
Deflate 圧縮メカニズムを使用する
自動のみ
クライアント側の設定によって、gzip/deflate/非圧縮のいずれかを使用する
4-2-7-5 ODR による SSL 解除
ODR は SSL を解除することが可能です。クライアントからの HTTPS 通信を ODR で SSL 解除し、バッ
クエンドのアプリケーション・サーバーに対して HTTP で通信を行います。SSL オフロードは以下の２つ
のレベルで構成することができます。
（１） ODR を通過するすべての HTTPS トラフィックを SSL 解除する
（２） アプリケーション（Web モジュール）毎に SSL 解除する
以下、（１）（２）の２つのレベルにおける構成方法を記述します。
（１） ODR を通過するすべての HTTPS トラフィックを SSL 解除する方法
管理コンソールで、[サーバー]→[サーバー・タイプ]→[オンデマンド・ルーター]→[ODR 名]→[オンデ
マンド・ルーター・プロパティー]→[オンデマンド・ルーター設定]→[カスタム・プロパティー]を選択しま
す。尚、ODR 動的クラスターの場合はサーバー・テンプレートから設定することが可能です。[サーバー]
→[クラスター]→[動的クラスター]→[<ODR 動的クラスター名>]→[サーバー・テンプレート]→[オンデマ
ンド・ルーターの設定]→[オンデマンド・ルーター・プロパティー]→[オンデマンド・ルーター設定]を選択
します。
”新規”ボタンをクリックして以下の値を設定します。
名前：http.protocolMap
値：SSL-offload
- 48 -
WAS V8.5 Information Center 「すべての HTTPS トラフィックに対する SSL オフロードの構成」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_cgssloffload.html
（２） アプリケーション（Web モジュール）毎に SSL 解除する
管理コンソールで、[アプリケーション]→[アプリケーション・タイプ]→[WebSphere エンタープライズ・ア
プリケーション]→[アプリケーション名]→[モジュールの管理]→[Web モジュール名]→[Web モジュー
ル・プロキシー構成]を選択します。[Web モジュールのトランスポート・プロトコル]で[HTTP]を選択しま
す。
- 49 -
4-2-7-6 カスタム・エラー・ページ・ポリシー
従来の Web サーバーで返すエラー・ページの代わりに、ODR でエラー・ページを返すことができま
す。カスタム・エラー・ページはプロキシー・サーバーが提供する機能であり、ODR もプロキシー・サーバ
ーであるため当該機能を利用することが可能です。例えば、アプリケーション遅延スタートを設定してい
る場合、非アクティブなインスタンスが稼働するまでの時間、503 のエラーがクライアントに返されること
になりますが、ODR でエラー・ページをカスタマイズして、リクエストを再送するメッセージを表示させる
ことが可能となります。
カスタム・エラー・ページに関する設定はカスタム・エラー・ページ・ポリシーで行います。設定詳細に
ついては、“8-1-4-1 プロキシー設定“を参照してください。尚、ODR 動的クラスターの場合はサーバー・
テンプレートからカスタム・エラー・ページ・ポリシーを設定することが可能です。
4-2-7-7 ロギング
ODR のアクセス・ログとして以下のログファイルが提供されています。
ログ名
説明
proxy.log
リモート・サーバーから受け取った応答をログに記録する
cache.log
ローカル・キャッシュから提供された応答をログに記録する
local.log
すべての非キャッシュ・ローカル応答、例えば、リダイレクトや内部エラーをログに記録する
管理コンソールより[サーバー]→[オンデマンド・ルーター]→[オンデマンド・ルーターの設定]→[オン
デマンド・ルーター・プロパティー]を選択します。尚、ODR 動的クラスターの場合はサーバー・テンプレ
ートから設定することが可能です。[サーバー]→[クラスター]→[動的クラスター]→[<ODR 動的クラスター
名>]→[サーバー・テンプレート]→[オンデマンド・ルーターの設定]→[オンデマンド・ルーター・プロパテ
ィー]→[オンデマンド・ルーター設定]を選択します。
アクセス・ロギングの有効化およびアクセス・ログの最大サイズ、各アクセス・ログのファイル名を確認
および設定することができます。
- 50 -
4-2-7-8 ODR カスタム・ログ
ODR カスタム・ログはリクエスト毎にロギングされ、取得条件と記録形式をカスタマイズすることが可能
です。IHS のアクセス・ログのように応答時間やリクエスト URL や HTTP 応答コードなどを確認することが
可能です。カスタム・ログを使用するためには ODR のアクセス・ロギングが有効になっている必要があり
ます。
例えば、記録形式として下記のような設定があります。
%a
リモート IP アドレス。
%t
共通ログの時刻形式の時刻 (標準英語形式の時刻)。
%U 要求された URL パス。照会ストリングは含みません。
%s
状況、HTTP 応答コード (すなわち 503、404、200)。
%B HTTP ヘッダーを除く送信バイト数。
%R 応答時間(ms)。ODR での処理時間＋バックエンドでの処理時間
%T サービス時間(ms)。バックエンドでの処理時間(リクエストが ODR を出てから戻ってく
るまでの時間)
ODR カスタム・ログの設定は wsadmin コマンドで実施します。以下に設定コマンドのサンプルを記述
します。
（１）ルールクラスの作成
wsadmin>AdminTask.createRuleset('-odrname ODR01 -nodename CustNode01 -rulesetName myRuleset
-rulesetType HTTP -defaultContinue true')
（２）ルールクラスにルールを設定
wsadmin>AdminTask.addRuleToRuleset('-odrname ODR01 -nodename CustNode01 -rulesetName
myRuleset -ruleName myRule -rulePriority 0 -expression "port = 80"')
（３）上記ルールに合致した場合のアクションを設定（カスタムログ出力を指定する）
wsadmin>AdminTask.addActionToRule('-odrname ODR01 -nodename CustNode01 -rulesetName
myRuleset -ruleName myRule
-actionName myCustomLogAction -actionType log -actionValue
"Custom.log %a %t %U %s %B %R %T" -actionContinue true')
（４）設定を保存
wsadmin>AdminConfig.save()
カスタムログとして、下記のようなログが出力されます。
Custom.log の抜粋
x.x.x.x 17/9/2013:12:27:59 JST http://hostname/HelloJAXWS 200 271 6850 6532
x.x.x.x 17/9/2013:12:29:11 JST http://hostname/HelloJAXWS 200 271 5135 5079
x.x.x.x 17/9/2013:12:29:24 JST http://hostname/HelloJAXWS 200 260 1101 1042
x.x.x.x 17/9/2013:12:29:31 JST http://hostname/HelloJAXWS 503 90 59 -1
x.x.x.x 17/9/2013:12:29:38 JST http://hostname/HelloJAXWS 503 90 61 -1
x.x.x.x 17/9/2013:12:29:43 JST http://hostname/HelloJAXWS 503 90 62 -1
x.x.x.x 17/9/2013:12:29:49 JST http://hostname/HelloJAXWS 503 90 63 -1
x.x.x.x 17/9/2013:12:29:55 JST http://hostname/HelloJAXWS 503 90 59 -1
x.x.x.x 17/9/2013:12:30:00 JST http://hostname/HelloJAXWS 503 90 53 -1
x.x.x.x 17/9/2013:12:30:21 JST http://hostname/HelloJAXWS 503 90 2053 -1
x.x.x.x 17/9/2013:12:30:43 JST http://hostname/HelloJAXWS 200 269 11508 10200
- 51 -
x.x.x.x 17/9/2013:12:30:59 JST http://hostname/HelloJAXWS 200 263 10130 10064
x.x.x.x 17/9/2013:12:31:13 JST http://hostname/HelloJAXWS 200 266 5175 5095
その他、カスタム・ログの構成方法や出力可能な項目の詳細については Information Center をご参照
ください。
WAS V8.5 Information Center 「カスタム・ログの構成」 （構成方法）
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wve.do
c%2Fae%2Ftwve_xdcustomlog.html
WAS V8.5 Information Center 「カスタム・ログ・ファイル・フォーマット」 （取得項目のリストなど）
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wve.do
c%2Fae%2Fcwve_xdcustomlog.html
4-2-7-9 ルーティング・ポリシー
ODR やプラグイン、負荷分散装置による割り振り方式は 1:1 と 1:N の割り振り方式に分類することがで
きますが、ODR はデフォルトで 1:N 方式で割り振りを行います。ODR は DWLM によって動的に計算さ
れた重みを利用して、重み付きラウンドロビンによって割り振りを行います。ODR のデフォルトのワークロ
ード管理によって負荷の平準化が行われ、負荷の偏りによる性能悪化を防止することが可能となりま
す。ただし要件によっては一時的あるいは特定のリクエストなどのルーティング方法を手動で制御したい
ケースがあります。
例）
・ リクエストの URI やユーザーID、HTTP ヘッダー等に特定の情報が入っている場合には特定のサ
ーバーに割り振りたい
・ アプリケーション更新の際にテストユーザーのみ新しいエディションに割り振って稼働確認を行い
たい
その場合、ルーティング・ポリシーを定義することにより ODR によるデフォルトの割り振り方法を変更す
ることができます。ルーティング・ポリシーとは ODR がどのようにリクエストをルーティングするかを決定す
るルールのセットとなります。つまり、ルーティング・ポリシーには複数のルーティング・ルールを定義する
ことが可能であり、優先順位の高いルールから順番に評価されます。尚、アフィニティーはルーティン
グ・ルールよりも優先されますので、アフィニティーが効いたリクエストは同一サーバーへ割り振られる点
に留意する必要があります。
ルーティング・ポリシーは、3 つのロケーションで定義することが可能で用途に応じて使い分ける必要
があります。
ルーティング・ポリシー
ロケーション
説明
ODR ルーティング・ポリシー
ODR レベル
ODR レベルで設定するルーティング・ポリシーで
す。ODR レベルで作成されるルールはアプリケ
ーション・レベルのルールに優先します。
汎用サーバー・クラスター用ルーテ
ODR レベルで作業クラ
汎用サーバー・クラスターに対するルーティング・
ィング・ポリシー
ス内
ポリシーを定義する際に使用します。
アプリケーション・エディション用ル
アプリケーション・レベ
アプリケーション毎にルーティング・ポリシーを定
ーティング・ポリシー
ルで作業クラス内
義します。エディション管理機能を使用して特定
のリクエストを特定のエディションへルーティング
- 52 -
したい場合に使用します。
下記の図は ODR でのリクエストの分類処理をまとめたものです。ODR にリクエストが到着すると、まず
ODR レベルのルーティング・ルールが評価され、後続のステップでアプリケーション・レベルが評価され
る流れとなります。尚、図中の SP とはサービス・ポリシーを指します。
ODRへの
リクエスト
到着
ODR ルール
の評価
最適なマッチング
の選択
マッチするクラスター、
サーバー、モジュール
のリストを特定
仮想ホストと
URIを元にリクエスト
の最適なマッチ先
を特定
アプリケーション
・ルールの評価
アフィニティがなければアプリケーション・ルール
を評価。いずれかのルールにマッチした場合は
エディションが特定される。該当エディションの
SPが評価されマッチするSPを適用
キューに
送信
（流量制御）
割り振り先
サーバー
の決定
（DWLM)
アプリケー
ション・
サーバーへ
の送信
図 4-9 ODR でのリクエストの分類処理
ルーティング・ポリシー設定方法
ルーティング・ポリシーは管理コンソールおよび wsadmin スクリプトで定義することが可能です。当ガイ
ドでは管理コンソールを使用した ODR ルーティング・ポリシーの設定方法を紹介しますが、その他のル
ーティング・ポリシー設定方法は下記 URL を参照してください。
＜ODR レベルにおけるルーティング・ポリシー設定方法＞
・ wsadmin スクリプトによる設定方法
WAS V8.5 Information Center 「ODR ルーティング・ポリシー・ルールの管理用タスク」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_xdhttprules.html
＜ODR レベルで作業クラス内におけるルーティング・ポリシー設定方法＞
・ 管理コンソールによる設定方法
WAS V8.5 Information Center 「汎用サーバー・クラスターのルーティング・ポリシーの定義」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_odoerouting.html
・ wsadmin スクリプトによる設定方法
WAS V8.5 Information Center 「workclassoperations.py スクリプト」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odwcscript.html
＜アプリケーション・レベルで作業クラス内におけるルーティング・ポリシー設定方法＞
- 53 -
・ 管理コンソールによる設定方法
WAS V8.5 Information Center 「アプリケーション・エディション用ルーティング・ポリシーの作成」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_appedroute.html
・ wsadmin スクリプトによる設定方法
WAS V8.5 Information Center 「workclassoperations.py スクリプト」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odwcscript.html
以下に管理コンソールを使用した ODR ルーティング・ポリシーの設定方法を紹介します。
1). 管理コンソールより[サーバー]→[オンデマンド・ルーター]→[<ODR 名>]→[オンデマンド・ルー
ターの設定]→[オンデマンド・ルーター・プロパティー]→[ルーティング・ポリシー HTTP ルール]
を選択します。
- 54 -
2). ルールの[追加]ボタンをクリックします。
3). ルールを定義するために副次式ビルダーを選択します。副次式ビルダーはオプション・ツールで
あり、AND、OR、NOT、および括弧によるグループ化を使用して、副次式から複雑なルール条
件を作成する際に役立ちます。尚、適用するルールに直接ルールを記載することも可能です。
4). 当ガイドではルールとして HTTP ヘッダーを条件として指定します。以下の情報を選択および入
力して“副次式の生成“ボタンをクリックすると副次式が表示されますので、”付加”ボタンをクリッ
クします。“クローズ“を選択することで副次式ビルダーを閉じます。
オペランドの選択：
要求ヘッダー名（リストから選択）
要求ヘッダー名：
iv-remote-address（任意）
演算子：
等しい（リストから選択）
値：
10.0.0.1(任意)
- 55 -
ルールで指定することができるオペランドの一覧は下記 URL を参照してください。
WAS V8.5 Information Center 「ルーティング・ポリシーおよびサービス・ポリシーの副次式ビルダー・オ
ペランド」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/rwve_odrsubexpress.html
5). 適用するルールに副次式ビルダーで生成したルールが記載されていることを確認します。
- 56 -
6). ルールに合致した場合のアクションを選択します。ここでは“アフィニティーによる”ルーティング
の許可”を選択します。
使用するプロトコル(HTTP/SOAP/SIP)およびルーティング・ポリシーのロケーション（ODR レベル/アプリ
ケーション・レベル作業クラス内）に基づくアクション・タイプの一覧は下記 URL を参照してください。
WAS V8.5 Information Center 「ルーティング・ポリシーのアクション・タイプ」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/cwve_odoeroute.html
- 57 -
7). 次に要求のルーティング先の指定を行います。ここでは動的クラスターのメンバーサーバーを指
定しています。“指定者“、”セル名“、”ノード名”、“サーバー名”をリストから選択して“追加“ボタ
ンをクリックします。
8). [追加]ボタンの右側のボックスに、リクエストのルーティング先の情報がリストされていることを確認
します。
- 58 -
9). マルチクラスター・ルーティング・ポリシーを選択します。
これは複数のセルにルーティングするケースで使用されるもので、複数のルーティング・ロケーシ
ョン・クラスターが一致した場合に、リクエストをルーティングする方式を指定します。



フェイルオーバー:
使用可能なサーバーがある最初のクラスターを検索し、
そのクラスターに対してロード・バランシングを行います。
WeightedRoundRobin(WRR):
重み付きラウンドロビン・ロード・バランシング
WeightedLeastOutstandingRequest(WLOR): 重み付き最小未解決要求
(WRR 値ではなく、WLOR 値の使用が推奨されます。)
10). ルールが適切に設定されているかどうかを検証するため、“ルールの検証“ボタンをクリックしま
す。
11). “適用”または“OK”ボタンをクリックして変更を保存します。
- 59 -
4-2-8 ODR のチューニング





ODR のチューニング項目を紹介します。
JVM ヒープ・サイズ
パーシスタント接続（HTTP KeepAlive）
アウトバウンド最大接続数
キャッシング
スレッド・グループ
4-2-8-1 JVM ヒープ・サイズ
ODR はアプリケーション・サーバーと同様に JVM プロセスとして稼働しますので、パフォーマンス検証
を実施することによって JVM ヒープ・サイズを適切に調整する必要があります。
尚、ODR の初期ヒープの推奨値については、以下のように計算式にて見積もることができます。
90MB + 0.05 MB/要求 × ピーク要求数/秒 × ガーベッジ・コレクション間に必要な時間 (秒)
WAS V8.5 Information Center 「オンデマンド・ルーターの JVM ヒープ・サイズの変更」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.wve.doc/ae
/twve_odrheap.html
4-2-8-2 パーシスタント接続（HTTP KeepAlive）
従来のクライアント－IHS－アプリケーション・サーバー間のチューニング項目として HTTP KeepAlive
の設定がありますが、ODR も同様に KeepAlive 接続がチューニング項目として挙げられ ます。
KeepAlive 接続の対象となる接続としては、
 クライアント－ODR 間の接続
 ODR－アプリケーション・サーバー間の接続
があります。クライアント－ODR 間の KeepAlive 設定は ODR で設定を行いますので、以下に説明しま
す。尚、ODR－アプリケーション・サーバー間の KeepAlive 設定はアプリケーション・サーバー側で設定
します。
クライアント－ODR 間の KeepAlive 接続設定
クライアント－ODR 間の接続におけるリクエスト単位での TCP セッション確立のオーバーヘッドを緩和
するために KeepAlive 接続を有効にすることをお勧めします。ODR における KeepAlive 接続のパラメー
ターは以下の表のとおりです。
表 6 クライアント－ODR 間の KeepAlive 接続に関するパラメーター
パラメーター名
説明
ユーザー・パーシスタント ・キープアライブ接続
必ずチェックを入れ、HTTP keepAlive 接続を有
効にしてください。（デフォルト：有効）
接続当たりの無制限のパーシスタント要求数
接続ごとのリクエスト数を無制限にする場合に選
択します。
- 60 -
接続当たりの最大のパーシスタント要求数
接続ごとの最大パーシスタント要求数を指定する
場合に選択します。“接続当たりの最大のパーシ
スタント要求数”を選択します。この値を -1 に設
定すると、最高のパフォーマンスを得ることがで
きます。
パーシスタント・タイムアウト
アイドル状態の接続をタイムアウトさせるための
時間を指定します。タイムアウトになるタイミング
で接続が破棄されます。デフォルト値が 30 秒と
比較的長い値に設定されていますので、ネットワ
ー ク 遅 延 が な い 環 境 に お い て は IHS の
KeepAliveTimeout と同様に短い値に設定するこ
とを検討してください。
KeepAlive 接続は HTTP_PROXY_CHAIN および HTTPS_PROXY_CHAIN にて設定します。
管 理 コ ン ソ ー ル に て [ サ ー バ ー ] → [ オ ン デ マ ン ド ・ ル ー タ ー ] → [<ODR 名 >] → [ ポ ー ト ] →
PROXY_HTTP(S)_ADDRESS の関連トランスポートの表示]→[HTTP(S)_PROXY_CHAIN]→[HTTP
インバウンド・チャネル (HTTP_3)]を選択します。
- 61 -
4-2-8-3 アウトバウンド最大接続数
ODR とアプリケーション・サーバー間の接続をプーリングして再利用することができます。ア
ウトバウンド最大接続数については”4-2-7-2アウトバウンド接続設定”を参照してください。
4-2-8-4 キャッシング
ODR にはキャッシング機能が提供されています。使用しない場合は使用不可に設定します。キャッシ
ングの詳細については“4-2-7-3キャッシング“を参照してください。
4-2-8-5 スレッド・グループ
一般的にアプリケーション・サーバーのチューニングではスレッド・プールは非常に重要ですが、ODR
に関してはあまり重要ではありません。ODR はアプリケーション・サーバーとかなり異なった形でスレッド
を使用します。Web コンテナー・スレッド・プールは ODR がエラー・ページを提供するときのみ使用され、
通常のリクエスト処理には使用されません。
ODR は完全に非同期で処理を実行します。I/O 処理などのブロッキング操作の間にスレッドを保持す
ることはなく、スレッドは別の処理をアサインされます。そのため、ODR はスレッドを効果的に使用するこ
とができ、同時接続数として数千のオーダーまでスケールすることが可能となります。
ODR は自己調整を行うスレッドのセットを持っています。キューイング要求およびスロットル要求は、
オーバーフロー要求のみを処理するように調整できる Default スレッド・プールにディスパッチされるた
め、Default スレッド・プールについては適切にチューニングする必要があります。
スレッド・グループに関するチューニングとして、インバウンドとアウトバウンドの両方の作業に同じスレ
ッド・グループを使用することがガイドされています。これにより、リクエストがスレッド間で移動することが
避けられ、この移動が原因で生じるオーバーヘッドがなくなります。インバウンドとアウトバウンドの両方
の作業に同じスレッド・グループを使用するには、以下のステップを実行します。
[サーバー]→[サーバー・タイプ]→[オンデマンド・ルーター]→[<ODR 名>]→[スレッド・プール]→
[Default]→[カスタム・プロパティー]を選択して”新規”をクリックします。下記内容を指定して、”OK”をク
リックして”保存”をクリックします。
名前： combineSelectors
値：
1
- 62 -
4-3 セキュア・プロキシー・サーバー
DMZ Secure Proxy Server for IBM WebSphere Application Server(以降、セキュア・プロキシー・サー
バー)は、WAS V7.0 から登場した DMZ ゾーン(非武装地帯)へ配置するためにセキュリティーが強化さ
れたプロキシー・サーバーです。具体的には、必要最低限のポートのみの開放、デジタル署名された
JAR のみのロードによりセキュリティーが強化されています。さらに、Java™ Development Kit (JDK) から
Java Runtime Environment (JRE) に切り替えることで、インストール時にコンパイラーが組み込まれなく
なっています。インストール手順につきましては、「第 2 章 インストール・プロファイル作成」を参照下さ
い。
4-3-1 セキュリティー設定
セキュア・プロキシー・サーバーでは、「高」／「中」／「低」のセキュリティ・レベルを選択することで、要
件に応じてセキュリティーを設定することが可能です。下記の表のように、セキュリティ・レベル毎に管理
／ルーティング／開始の許可／カスタム・エラー・ページ・ポリシーの 4 項目が、自動的に設定されま
す。
表 4-7 プロキシー・セキュリティ・レベル毎のセキュリティー設定
項目
管理
ルーティング
開始の許可
カスタム・エラー・ペー
ジ・ポリシー
高
ローカル管理
静的ルーティング
非特権ユーザーとして
実行
ローカル・エラー・ペー
ジ処理
中
ローカル管理
動的ルーティング
非特権ユーザーとして
実行
リモート・エラー・ページ
処理
低
リモート管理
動的ルーティング
特権ユーザーとして実
行
リモート・エラー・ページ
処理
この設定項目は、管理コンソールのツリー・ビュー上で、[サーバー]→[プロキシー・サーバー] →[プ
ロキシー・サーバー名] →[プロキシー・セキュリティ・レベル]を選択することで確認、および設定変更す
ることが出来ます。
- 63 -
4-3-2 管理
ローカル管理、もしくはリモート管理から、セキュア・プロキシー・サーバーの管理方法を選択します。
表 4-8 管理オプション
オプション
ローカル管理
セキュリティ・レベル
「中」／「高」セキュリティー
リモート管理
「低」セキュリティー
説明
ローカルで実行される wsadmin コマンドを使用す
る場合にのみ許可されます。
リモート管理が許可されます。
セキュア・プロキシー・サーバーは、Web コンテナーが導入されないため、ローカル環境で管理コンソ
ールを起動することができません。従って、wsadmin コマンドを使用して、構成管理を実施します。
ローカル管理では、wsadmin コマンドの接続タイプとして、Inter-Process Communication(IPC)のみが
許可され、デフォルトの接続タイプである SOAP は利用することが出来ません。IPC 接続時のポート番号
は、IPC_CONNECTOR_ADDRES 値を指定します。ローカル管理は、外部のリスニング・ポートを開く必
要がないため、最もセキュアであると言えます。リモート管理では、wsadmin コマンドの接続タイプの制限
はありません。
例 8- 1 IPC 接続の wsadmin コマンド実行例
# <WAS_root>/bin/wsadmin.sh -conntype IPC -ipchost ホスト名 -port ポート番号
また、別の方法として、WAS ND 環境内の管理コンソールを使用して構成管理を実施することができ
ます。WAS ND 環境内に構成専用のプロファイルを作成し、WAS ND 環境内の管理コンソール経由で
セキュア・プロキシー・サーバーを構成します。その構成情報を、wsadmin コマンドを使用して構成アー
カイブ(CAR)ファイルにエクスポートし、FTP を使用してセキュア・プロキシー・サーバーの環境に送信し
ます。さらに、wsadmin コマンドを使用して、この構成アーカイブ(CAR)ファイルをインポートします。この
時、エクスポート/インポートを、プロファイル単位で実施する場合は ProxyProfile コマンドを、サーバー単
位で実施する場合は ProxyServer コマンドを使用して下さい。
例 8- 2 構成アーカイブファイルのエクスポート実行例
AdminTask.exportProxyProfile ('[-archive ProxyConfig.car]')
AdminTask.exportProxyServer(‘[-archive ProxyConfig.ear
-nodeName Node_name
–serverName ApplicationServer_name]]')
例 8- 3 構成アーカイブファイルのインポート実行例
AdminTask.importProxyProfile ('[-archive ProxyConfig.car]')
AdminTask.importProxyServer(‘[-archive ProxyConfig.ear -nodeInArchive Node_name
-serverInArchive ApplicationServer_name]]')
4-3-3 ルーティング
静的ルーティング、もしくは動的ルーティングから、セキュア・プロキシー・サーバーのルーティング方
法を選択します。
- 64 -
表 4-9 ルーティングオプション
オプション
静的ルーティング
セキュリティ・レベル
「高」セキュリティー
動的ルーティング
「中」／「低」セキュリティー
説明
構成ファイルに基づいて、要求のルーティングを
行います。HTTP のみ。
宛先への最適な経路を動的に検出し、同様のプ
ロトコルを備えたサーバーへ配布します。
静的ルーティングでは、プロキシー・サーバーが構成ファイルに基づいて要求がルーティングされま
す。動的ルーティングでは、HA マネージャーの機能を利用して、割り振り先の稼動状況を動的に確認
し、要求がルーティングされます。動的ルーティングでは、セキュア・プロキシー・サーバーが割り振り先
のアプリケーション・サーバーと通信し要求をマッピングさせるため、静的ルーティングを使用する方が
セキュアであると言えます。セキュア・プロキシー・サーバーのルーティング構成は、下記 URL を参照下
さい。
WAS V8.5 Information Center 「IBM WebSphere Application Server の DMZ セキュア・プロキシー・サ
ーバー のセキュアなルーティングの構成」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.nd.doc/ae/tj
px_secrouting.html
4-3-3-1 静的ルーティング構成
ここでは、静的ルーティングにて TaegetTree.xml を使用して、セキュア・プロキシー・サーバーから割り
振り先のアプリケーション・サーバーに要求を割り振る手順を説明します。全体の構成図は、下記になり
ます。
- 65 -
Cell
guideCell01
Cell
guideCell02
host02.ise.ibm.com
192.168.0.2
host01.ise.ibm.com
192.168.0.1
Machine
host02
Machine
host01
Secure Proxy Server
host02Node01
proxy01
DM
host01CellManager01
TargetTree.xml
NA
host01Node01
AppServer
Amember11
図 4-10 TargetTree.xml を使用する静的ルーティング構成
Step1 TagetTree.xml の作成
割り振り先のアプリケーション・サーバーにて、wsadmin ツールを使用して TargetTreeMbean mbean を
照会し、exportTargetTree メソッドを指定した xml ファイルに対して実行します。
<WAS_root>/bin/wsadmin.sh -lang jython -port <ポート番号>
wsadmin>mbean=AdminControl.queryNames('*:*,type=TargetTreeMbean,process=dmgr')
wsadmin>AdminControl.invoke(mbean, 'exportTargetTree', '/tmp/targetTree.xml')
Step2 TagetTree.xml の転送
取得した TargetTree.xml ファイルを、セキュア プロキシー・サーバーが導入されている筐体のプロファ
イルルート配下の/staticRoutes ディレクトリーに転送します。
Step3 セキュア プロキシー・サーバーの再起動および設定確認
セキュア・プロキシー・サーバーを再起動します。TargetTree.xml が読み込まれているかは、トレース
(com.ibm.ws.odc.*=all)を設定すると確認できます。
- 66 -
[08/11/27 17:25:42:565 JST] 00000000 TreeBuilder
3
start parsing file:
/usr/IBM/WebSphere/AppServer/profiles/Secure01/staticRoutes/TargetTree.xml
(省略)
[08/11/27 17:25:43:476 JST] 00000000 TreeBuilder
3
end parsing file:
/usr/IBM32/WebSphere7/AppServer/profiles/Secure01/staticRoutes/TargetTree.xml
4-3-3-2 動的ルーティング構成
ここでは、動的ルーティングにてトンネル・アクセス・ポイント・グループを使用して、ファイアウォールの
内側にあるセル(割り振り先のアプリケーション・サーバー)とセキュア・プロキシー・サーバーとをコア・グ
ループ・ブリッジ・トンネルにて接続する手順を説明します。全体の構成図は、下記になります。
Cell
guideCell02
Cell
guideCell01
CoreGroup
DefaultCoreGroup
CoreGroup
DefaultCoreGroup
host02.ise.ibm.com
192.168.0.2
host01.ise.ibm.com
192.168.0.1
Machine
host01
Machine
host02
DM
host01CellManager01
トンネル・アクセス・ポイント・グループ
TAPG01
コア・グループ・アクセス・ポイント
CGAP_1¥DefaultCoreGroup
Secure Proxy Server
host02Node01
proxy01
トンネル・ピア・アクセス・ポイント
TPAP01¥guideCell02
HAマネージャー
NA
host01Node01
HAマネージャー
AppServer
Amember11
HAマネージャー
図 4-11 トンネル・ピア・アクセス・ポイントを利用するコア・グループ通信
Step1 コア・グループ・ブリッジ・トンネルの設定
トンネル・テンプレートを作成し、コア・グループ・ブリッジ・トンネルを設定します。
管理コンソールのツリー・ビュー上で、[サーバー]→[コア・グループ] →[コア・グループ・ブリッジ設
定]→[トンネル・ピア・アクセス・ポイント]を選択し、トンネル・ピア・アクセス・ポイントを作成します。セル
名は、セキュア・プロキシー・サーバーが属しているセル名を指定します。
•
トンネル・ピア・アクセス・ポイントの設定
TPAP01 (任意)
トンネル・ピア・アクセス・ポイント
セル名
guideCell02
- 67 -
次に、管理コンソールのツリー・ビュー上で、[サーバー]→[コア・グループ] →[コア・グループ・ブリッ
ジ設定]→[トンネル・アクセス・ポイント・グループ]を選択し、トンネル・アクセス・ポイント・グループを作
成します。コア・グループ・アクセス・ポイントは、割り振り先のアプリケーション・サーバーが属しているコ
ア・グループ・アクセス・ポイントを指定します。下記は、デフォルトのコア・グループ・アクセス・ポイントで
ある CGAP_1¥DefaultCoreGroup、上記で作成したトンネル・ピア・アクセス・ポイント(TPAPG01)を設定し
た例です。
•
トンネル・アクセス・ポイント・グループの設定
トンネル・アクセス・ポイント・グループ
TAPG01 (任意)
CGAP_1¥DefaultCoreGroup
コア・グループ・アクセス・ポイント
トンネル・ピア・アクセス・ポイント
TPAP01¥guideCell02
続いて、管理コンソールのツリー・ビュー上で、[サーバー]→[コア・グループ] →[コア・グループ・ブリ
ッジ設定]→[トンネル・アクセス・ポイント・グループ]→[コア・グループ・アクセス・ポイント]→[ブリッジ・イ
ンターフェース]を選択し、ブリッジ・インターフェースを作成します。下記は、コア・グループ・アクセス・ポ
イント(CGAP1¥DefaultCoreGroup)と nodeagent をブリッジ・インターフェースにて接続した設定例です。
•
ブリッジ・インターフェースの設定
CGAP_1¥DefaultCoreGroup
コア・グループ・アクセス・ポイント
ブリッジ・インターフェース
host01Node01¥nodeagent¥DCS
最後に、管理コンソールのツリー・ビュー上で、[サーバー]→[コア・グループ] →[コア・グループ・ブリ
ッジ設定]→[トンネル・テンプレート]を選択し、トンネル・テンプレートを作成します。下記は、トンネル・テ
ンプレートに、上記で作成したトンネル・アクセス・ポイント・グループ(TAPG01)を設定した例です。
•
トンネル・テンプレートの設定
host01_host02_Tunnel01 (任意)
トンネル・テンプレート
トンネル・アクセス・ポイント・グループ
TAPG01
Step2 トンネル・テンプレートのエクスポート
トンネル・テンプレートの設定をファイルにエクスポートします。
管理コンソールから実行する場合、管理コンソールのツリー・ビュー上で、[サーバー]→[コア・グルー
プ] →[コア・グループ・ブリッジ設定]→[トンネル・テンプレート]→[エクスポート] を選択します。
<DM_Profile_root>/host01_host02_Tunnel01.props ファイルにエクスポートされます。
wsadmin コマンドから実行する場合、以下を実行します。
wsadmin> AdminTask.exportTunnelTemplate('[-tunnelTemplateName host01_host02_Tunnel01
-outputFileName host01_host02_Tunnel01.props]')
当構成におけるトンネル・テンプレート情報は、以下になります。
# cat host01_host02_Tunnel01.props
#Fri Nov 14 17:26:29 JST 2008
tunnelAccessPointGroupName=TAPG01
port1CoreGroup1=9357
host1CoreGroup1=host01.ise.ibm.com
- 68 -
CoreGroup1=DefaultCoreGroup
isUseSSLOutbound=false
RemoteCellName=guideCell02
Step3 トンネル・テンプレートのインポート
Step2 で作成したトンネル・テンプレートを、wsadmin コマンドを使用しセキュア・プロキシー・サーバー
にインポートします。
AdminTask.importTunnelTemplate('[-inputFileName host01_host02_Tunnel01.props
-bridgeInterfaceNodeName host02Node01 -bridge InterfaceServerName proxy01]')
Step4 セキュア・プロキシー・サーバーの再起動および設定確認
セキュア・プロキシー・サーバーを再起動し、セキュア・プロキシー・サーバーと割り振り先のアプリケー
ション・サーバーがコア・グループ・ブリッジ・トンネルにて接続されているかを確認します。正常時、およ
び異常時のセキュア・プロキシー・サーバー、割り振り先のアプリケーション・サーバーの SystemOut.log
へのログ出力は、以下になります。異常時には、”NO_BRIDGES”と出力されます。
•
＜接続正常時＞割り振り先のアプリケーション・サーバー(nodeagent)のログ出力
[08/11/14 17:39:11:166 JST] 0000002c CGBridge
I
CWRCB0107I: このコア・グループ・ブリッジ
は安定していて、次のアクセス・ポイント・グループ・メンバーが使用可能です:
DefaultAccessPointGroup guideCell01:DefaultCoreGroup guideCell01\host01Node01\nodeagent
(,guideCell01,DefaultCoreGroup,CGAP_1,host01.ise.ibm.com,9357,NFWP,602)
TAPG01 guideCell01:DefaultCoreGroup guideCell01\host01Node01\nodeagent (192.168.0.1:9357)
TAPG01 guideCell02:DefaultCoreGroup guideCell02\host02Node01\proxy01 (NO_DCS_ENDPOINT)
•
＜接続正常時＞セキュア・プロキシー・サーバー(proxy01)のログ出力
[08/11/14 18:00:55:042 JST] 00000010 CGBridge
I
CWRCB0107I: このコア・グループ・ブリッジ
は安定していて、次のアクセス・ポイント・グループ・メンバーが使用可能です:
TAPG01 guideCell01:DefaultCoreGroup guideCell01\host01Node01\nodeagent (192.168.0.1:9357)
TAPG01 guideCell02:DefaultCoreGroup guideCell02\host02Node01\proxy01 (NO_DCS_ENDPOINT)
•
＜接続異常時＞割り振り先のアプリケーション・サーバー(nodeagent)のログ出力
[08/11/14 17:45:53:861 JST] 00000020 CGBridge
I
CWRCB0107I: このコア・グループ・ブリッジ
は安定していて、次のアクセス・ポイント・グループ・メンバーが使用可能です:
DefaultAccessPointGroup guideCell01:DefaultCoreGroup guideCell01\host01Node01\nodeagent
(,guideCell01,DefaultCoreGroup,CGAP_1,host01.ise.ibm.com,9357,NFWP,602)
TAPG01 guideCell01:DefaultCoreGroup guideCell01\host01Node01\nodeagent (192.168.0.1:9357)
TAPG01 guideCell02:DefaultCoreGroup NO_BRIDGES
•
＜接続異常時＞セキュア・プロキシー・サーバー(proxy01)のログ出力
[08/11/14 17:59:43:293 JST] 00000019 CGBridge
I
CWRCB0107I: このコア・グループ・ブリッジ
は安定していて、次のアクセス・ポイント・グループ・メンバーが使用可能です:
TAPG01 guideCell01:DefaultCoreGroup NO_BRIDGES
TAPG01 guideCell02:DefaultCoreGroup guideCell02\host02Node01\proxy01 (NO_DCS_ENDPOINT)
以上で、動的ルーティングに必要なコア・グループ・ブリッジ・トンネルの設定、およびトンネル・テンプ
レートのエクスポートとインポートは完了です。
- 69 -
4-3-4 開始の許可
「非特権ユーザーとして実行」、もしくは「特権ユーザーとして実行」から、セキュア・プロキシー・サー
バーの開始方法を選択します。
表 4-10 始動アクセス権のオプション
オプション
非特権ユーザーと
して実行
特権ユーザーとし
て実行
セキュリティ・レベル
「高」／「中」セキュリティー
「低」セキュリティー
説明
サーバー・プロセスの始動後、事前に定義された
非特権ユーザーに変更します。
サーバー・プロセスの始動後、非特権ユーザーに
変更されません。
セキュア・プロキシー・サーバーは、DMZ 内に配置されることが想定されています。この場合、非特権
ユーザーでセキュア・プロキシー・サーバーを実行することで、ローカルのオペレーティング・リソースを
保護することができ、ファイアウォールよりセキュリティーを強化することが可能です。
非特権ユーザーでセキュア・プロキシー・サーバーを起動する際に、1024 番より低いポート番号であ
る特権ポートを初期化する必要があります。そのため、特権ポートの初期化は特権ユーザーで実行し、
その後の処理は非特権ユーザーで実行されることで、非特権ユーザーでプロセスが開始されます。非
特権ユーザーのユーザー名とユーザー・グループは、管理コンソールのツリー・ビュー上で、[サーバー]
→[プロキシー・サーバー] →[プロキシー・サーバー名] →[プロキシー・セキュリティ・レベル]を選択し、
[開始の許可]で設定します。
4-3-5 エラー処理
ローカル・エラー・ページ処理、もしくはリモート・エラー・ページ処理から、セキュア・プロキシー・サー
バーのエラー処理方法を選択します。
表 4-11 カスタム・エラー・ページ・ポリシー
オプション
ローカル・エラー・
ページ処理
リモート・エラー・ペ
ージ処理
セキュリティ・レベル
「高」／「中」セキュリティー
「低」セキュリティー
説明
サーバー・プロセスの始動後、事前に定義された
非特権ユーザーに変更します。
サーバー・プロセスの始動後、非特権ユーザーに
変更されません。
設定方法は、WebSphere プロキシー・サーバーのエラー・ページ処理(「4-1-4-1 プロキシー設定」)と
同様です。
- 70 -
4-4 その他 作成手順
プロキシー・サーバーを構成する上で、重要となる要素の作成手順をご説明します。
4-4-1 汎用サーバー・クラスター作成手順
Step1 汎用サーバー・クラスターの作成
管理コンソールのツリー・ビュー上で、[サーバー]→[クラスター]→[汎用サーバー・クラスター] を選択
し、 [新規作成] を選択します。
Step2 汎用サーバー・クラスターの名前およびプロトコルの選択
作成する汎用サーバー・クラスターに任意の名前を指定し、対応させるプロトコルを、HTTP もしくは
HTTPS から選択します。選択後[OK]を選択すると汎用サーバー・クラスターが作成されます。
- 71 -
Step3 メンバーの追加
作成した汎用サーバー・クラスターにメンバーを登録します。作成した汎用サーバー・クラスターを選
択し、[ポート]を選択します。
以下の画面が表示されるので、[新規作成]を選択します。
メンバーとして追加したいサーバーの[ホスト]および[ポート]を入力します。ここで登録したサーバー
が、汎用クラスター・サーバーのメンバーとして追加されます。
- 72 -
4-4-2 URI グループの作成
Step1 URI グループの作成
管理コンソールで、[環境]→[URI グループ] を選択し、 [新規作成] を選択します。
Step2 URI パターンの登録
URI グループに任意の[名前]を指定し、[URI パターン]を記述します。[URI パターン]には 1 つ以上
のワイルドカード文字を含むことができます。
- 73 -
- 74 -