セキュアな環境における WebSphere プロキシー・サーバーのルーティング機能

この記事では、IBM® WebSphere® Application Server Network Deployment のフィーチャーの 1 つである、WebSphere プロキシー・サーバーが提供するさまざまなルーティング機能を検討します。セキュアな環境で、プロキシー・サーバーの機能を使用して、コンテンツのルーティングを成功させるために役立つ背景情報、セットアップ手順、およびヒントを織り交ぜながら、複数の構成シナリオを紹介します。この記事は IBM WebSphere 開発者向け技術ジャーナルの記事です。

Hermann Huebler, IT Specialist, IBM

Hermann Huebler は、AS/400 (現在の System i) のシステム・エンジニアとして 1994年に IBM に入社しました。それから数年間、欠陥および欠陥以外のサービスに携わった後、2000年から分散プラットフォームでの WebSphere Application Server に従事するようになり、WebSphere Application Server を実装する各国の顧客プロジェクトに関与しました。2005年からは、大容量の顧客環境を担当する WebSphere Application Server プロフェッショナルとして働いています。彼は、ITSO WebSphere Application Server V6.1: Performance and Scalability ワークショップの共著者兼インストラクターであり、「WebSphere Application Server V7.0: Concepts, Planning, and Design Redbook」(SG24-7708-00) の著者の一人です。2010年 12月より、スキル開発プログラムの一環として、インドの Bangalore デリバリー・センターに勤務しています。



2012年 7月 09日

はじめに

大規模 Web サイトでは多くの場合、最適なコストで十分なパフォーマンスを実現できるように、コンテンツをクライアントに近づけるメカニズムに依存しています。これは一般的に、ある種のキャッシングおよびキャッシュ管理を意味します。

静的コンテンツによる負荷を過小評価しないことは重要ですが、ほとんどのケースでは静的コンテンツをキャッシングするだけでは十分ではなくなってきています。今日の最新のキャッシング・メカニズムは、動的コンテンツをキャッシングする機能も備えている必要があります。

IBM WebSphere Application Server Network Deployment (以下、Network Deployment と呼びます) には、仲介サービスとして使用できるだけでなく、静的キャッシング機能および動的キャッシング機能の両方を提供する、複数のソリューションが組み込まれています。アプリケーション・サーバー自体に用意されている動的キャッシング機能に加え、以下のコンポーネントもキャッシング機能を提供します。

IBM WebSphere ソフトウェア製品ラインには、アプリケーションおよびビジネス・データのキャッシングに最適化された特別なソリューションも用意されています。その一例に、IBM WebSphere DataPower Appliance XC10 があります。

  • HTTP プラグイン
  • WebSphere プロキシー・サーバー
  • DMZ セキュア・プロキシー・サーバー
  • Edge Componentsのキャッシング・プロキシー

これらのソリューションには、それぞれに特有の長所と短所があります。Network Deployment が提供する仲介サービスの概要については、記事「Proxy server versus the HTTP plug-in: Choosing the best WebSphere Application Server workload management option」で分かりやすくまとめられています。トポロジーおよび構成内での WebSphere プロキシー・サーバーの配置に関する貴重な追加情報については、「スーパー・クラスターで解決する: 第 1 回」と、それに続く第 2 回の記事を参照してください。

この記事では、WebSphere プロキシー・サーバーが提供するルーティング機能を詳しく見ていきます。また、プロキシー・サーバーから配信されるコンテンツをホストするセキュアな WebSphere Application Server セルで必要となる構成手順についても説明します。


WebSphere プロキシー・サーバー管理の概要

WebSphere プロキシー・サーバーは、WebSphere Application Server Network Deployment V6.0.2 で初めて導入されましたが、WebSphere プロキシー・サーバーを可視化するためには Deployment Manager プロファイルを拡張する必要がありました。しかし、より新しいバージョンの WebSphere Application Server では、Deployment Manager 管理コンソール上で、拡張の必要なくそのまま WebSphere プロキシー・サーバーを構成できます。

WebSphere プロキシー・サーバーは、Network Deployment セルの一部として稼動するので、ネットワーク・トポロジーの DMZ に配置するのは適切でありません。Network Deployment V7.0 では、強化された DMZ 対応バージョンの WebSphere プロキシー・サーバーがリリースされました。それが、DMZ セキュア・プロキシー・サーバーです。しかし、この記事ではセル内で稼動する WebSphere プロキシー・サーバーのみ取り上げます。

管理および構成の観点から見ると、WebSphere プロキシー・サーバーは、管理対象ノード上の WebSphere Application Server セル内で、単独で稼動するタイプのサーバーです。セル内に WebSphere プロキシー・サーバーを生成して構成するには、WebSphere Application Server 管理コンソールを使用することも、スクリプト・ベースで管理する wsadmin を使用することもできます。

管理コンソールを使用してセル内の WebSphere プロキシー・サーバーを管理する場合は、「Servers (サーバー)」 > 「Server Types (サーバー・タイプ)」 > 「WebSphere proxy servers (WebSphere プロキシー・サーバー)」の順にナビゲートします。ここから、サーバーを作成する通常の手順に従って WebSphere プロキシー・サーバーを作成できます。WebSphere プロキシー・サーバーを使用して、セル内にデプロイされたアプリケーションにリクエストをルーティングするには、少なくとも以下の構成を行う必要があります。

  1. プロキシー・サーバー定義の PROXY_HTTP_ADDRESS および PROXY_HTTPS_ADDRESS ポートを、デプロイ済みアプリケーションの仮想ホスト定義のホスト別名リストに加えます。
  2. プロキシー・サーバー経由でサービスを提供する必要があるモジュールについては、「Enable Proxy (プロキシーの使用可能化)」プロパティーを設定します (次のセクションを参照)。

基本的に、WebSphere プロキシー・サーバーが、リクエストをルーティングできるコンテンツ・リソースには、以下の 2種類があります。

  • 管理対象リソース

    管理対象リソースとは、WebSphere Application Server が管理するリソースのことで、WebSphere プロキシー・サーバーと同じセル内、またはリモート・セル内のいずれかにあります。管理対象リソースは完全に WebSphere Application Server の管理下に置かれるため、各リソースの状態およびそのリソースへのルーティング情報は、HA(高可用性)マネージャーの Bulletin Board Service によって動的に伝搬されます。したがって、管理対象リソースに対するルーティングは動的に行われます。しかし、環境によっては、適切なコア・グループを構成する必要があります。これにより、HAマネージャーが、各管理対象リソースの状態を伝搬できるようになります。

    管理対象リソースに対する動的ルーティングを有効にするには、デプロイ済みアプリケーション・モジュールの「Enable Proxy (プロキシーの使用可能化)」チェック・ボックスを選択する必要があります。このチェック・ボックスは、アプリケーションのデプロイ時にデフォルトで設定されます。

    モジュールの「Enable Proxy (プロキシーの使用可能化)」オプションが選択されていることを確認するには、管理コンソールを開き、「Applications (アプリケーション)」 > 「Application Types (アプリケーション・タイプ)」 > 「WebSphere enterprise application (WebSphere エンタープライズ・アプリケーション)」 > 「<アプリケーション名>」 > 「Manage modules (モジュールの管理)」 > 「<モジュール名>」 > 「Web Module Proxy Configuration (Web モジュール・プロキシー構成)」の順にナビゲートします (図 1 を参照)。

    図 1. Web モジュール・プロキシー構成
    Web モジュール・プロキシー構成

    「Enable Proxy (プロキシーの使用可能化)」チェック・ボックスはデフォルトで選択されているので、プロキシー・サーバーによるこのモジュールへのルーティングは有効になっています。プロキシー・サーバーとアプリケーション・サーバーとの間で使用するプロトコル (HTTP または HTTPS) は、「Web Module Transport Protocol (Web モジュール・トランスポート・プロトコル)」ドロップダウン・ボックスで選択できます。

  • 非管理対象リソース

    非管理対象リソースとは、WebSphere Application Server の管理制御下にないリソースのことです。WebSphere Application Server はこれらのリソースを制御できないため、非管理対象リソースの現在の状態や可用性に関する認識は限られています。したがって、手動による構成が必要になります。このことから、WebSphere プロキシー・サーバーがチェックできるのは、TCP/IP 通信レベルでの可用性と、コンテンツをホストするサーバーが使用可能であるかどうかだけです。

    さらに、WebSphere Application Server は、非管理対象リソースに対するルーティング情報を収集できないため、非管理対象リソースへのルーティングも同様に手動で構成しなければなりません。非管理対象コンテンツ・リソースの典型例は、HTTP または HTTPS プロトコルを使用してアクセスできる HTTP サーバーや他の J2EE™ アプリケーション・サーバーなどによって提供されるリソースです。


動的ルーティングおよびコア・グループ

WebSphere プロキシー・サーバーを使用したルーティングは、コンテンツをホストしているサーバーのタイプや、環境がどのように構築されているかによって、さまざまな方法で行うことができます。管理対象コンテンツ・リソースでは動的なリクエスト・ルーティングを完全に使用できますが、非管理対象コンテンツ・リソースには手動によるルーティングの構成が必要です。

前述のとおり、動的ルーティングは管理対象リソースに対してのみ可能です。管理対象リソースに対するルーティング情報は、HAマネージャーの Bulletin Board Service によって伝搬されます。このサービスは、コア・グループを基にしてルーティングおよび可用性に関する情報を伝搬します。そのため、WebSphere プロキシー・サーバーにとって、ルーティングの構成はプロキシーをどのように構成するかの問題ではなく、コア・グループをどのように構成するかの問題となります。したがって、考えられる構成は、実現可能なコア・グループの構成によって制限されることになります。コア・グループ・ブリッジについての詳細は、WebSphere Application Server インフォメーション・センターを参照してください。

コア・グループの構成は、WebSphere プロキシー・サーバーのルーティング構成タスクにとって不可欠な部分であるため、コア・グループおよびコア・グループ関連の用語を十分に理解している必要があります。この記事全体で使用するコア・グループ関連の用語は以下のとおりです (詳しい説明については、WebSphere Application Server v7.0 インフォメーション・センターを参照してください)。

  • コア・グループとは、HAマネージャー内部の高可用性ドメインのことです。直接的な高可用性関係を確立できるプロセスのセットは、コア・グループによって定義されます。高可用性コンポーネントは、同じコア・グループ内のプロセスに対してのみフェイルオーバーできます。
  • アクセス・ポイント・グループは、互いに通信して高可用性情報を交換できるコア・グループのセットを定義します。
  • アクセス・ポイントは、他のコア・グループと通信するために使用する、コア・グループ内のアプリケーション・サーバーのセットを定義します。アクセス・ポイントにおいてブリッジ・インターフェースとして構成されたアプリケーション・サーバーは、コア・グループ・ブリッジ・サーバーと呼ばれます。
  • コア・グループ・ブリッジ・インターフェースは、コア・グループ間の境界を越えてデータを交換するために使用するノード、アプリケーション・サーバー、およびトランスポート・チャネル・チェーンを定義します。
  • コア・グループ・ブリッジ・サービスは、高可用性情報をコア・グループ間で共有できるようにするための、WebSphere Application Server のHAマネージャー関連のサービスです。
  • ピア・コア・グループとは、コア・グループ関連の情報を交換するために相互接続された、別のセル内にあるコア・グループのことです。
  • ピア・アクセス・ポイントは、ピア・コア・グループ間での通信に使用されるアクセス・ポイントです。コア・グループのピア・アクセス・ポイントごとに、ピア・セル内の対応するコア・グループ・アクセス・ポイントが必要です。

構成例

構成は事実上無制限に複雑にできますが、図 2 に、WebSphere プロキシー・サーバーの動的ルーティング機能、および必要となる構成を説明するために、この記事全体を通して使用するサンプル・トポロジーを示します。

図 2. 使用するサンプル・トポロジー
使用するサンプル・トポロジー

このトポロジーは 2 つのセルで構成されています。一方のセルは、プロキシー・サーバーをホストする d0002 で、このセルは DefaultCoreGroup と WebCoreGroup という 2 つのコア・グループに分割されています。プロキシー・サーバーは、DefaultCoreGroup のメンバーです。もう一方のセル d0003 には、DefaultCoreGroup コア・グループしかありません。コア・グループ・ブリッジを構成することにより、セル d0002 のプロキシー・サーバーは同じコア・グループ (d0002-DefaultCoreGroup) のアプリケーション・サーバーだけでなく、別のコア・グループ (d0002-WebCoreGroup) のサーバーにデプロイされたアプリケーションにも、別のセル内 (d0003-DefaultCoreGroup) にデプロイされたアプリケーションにも動的にトラフィックをルーティングできるようになります。

本番環境でのベスト・プラクティスとしては、この環境を WebSphere Application Server セキュリティーで保護することです。それにより、セル内でのすべての管理通信は、認証され、認可され、暗号化されます。しかし、他のシステム (LDAP サーバーやデータベース・サーバーなど) との通信についても確実にセキュアにすることは、管理者の責任です。


WebSphere Application Server が同じセル内の同じコア・グループに含まれる場合

このシナリオで WebSphere プロキシー・サーバーが配置されるのは、リクエストのルーティング先となるアプリケーションをホストする WebSphere Application Server と同じセル内の同じコア・グループです。図 3 に、プロキシー・サーバーのクラスターを使用した単純なトポロジーを示します (クラスターを使用するのは、高可用性および負荷分散のためです)。

図 3. 同じコア・グループに含まれるアプリケーション・サーバーへのルーティング
同じコア・グループに含まれるアプリケーション・サーバーへのルーティング

この構成は、WebSphere プロキシー・サーバー経由で管理対象コンテンツ・サーバーにリクエストをルーティンルするための非常に基本的なセットアップです。このセットアップに必要なのは、トラフィックをルーティングするための最小構成だけです。同じセル内の同じコア・グループに WebSphere プロキシー・サーバーを実装して、アプリケーション・サーバーにトラフィックをルーティングするには、アプリケーション・モジュールでプロキシーを使用可能にするだけで済みます。モジュールをプロキシー・サーバーにマッピングする必要さえありません。アプリケーション・モジュールの「Enable Proxy (プロキシーの使用可能化)」オプションを設定するだけで十分です。


WebSphere Application Servers が同じセル内の異なるコア・グループに含まれる場合

このセットアップでのプロキシー・サーバーは、自身と同じコア・グループ内のアプリケーション・サーバーだけでなく、同じセル内の異なるコア・グループにある管理対象コンテンツ・サーバーにもトラフィックをルーティングします。

図 4 に示すトポロジーは 1 つのセルで構成されており、プロキシー・サーバーのクラスターを使用して、これらのプロキシー・サーバーと同じコア・グループ (DefaultCoreGroup) に含まれるアプリケーション・サーバーと、プロキシー・サーバーとは異なるコア・グループ (WebCoreGroup) に含まれるアプリケーション・サーバーにリクエストをルーティングします。この 2 つのコア・グループが状態および可用性情報を交換できるようにするには、これらのコア・グループの間にコア・グループ・ブリッジを構成する必要があることに注意してください。

図 4. 同じセル内の異なるコア・グループに含まれるアプリケーション・サーバーへのルーティング
同じセル内の異なるコア・グループに含まれるアプリケーション・サーバーへのルーティング

管理対象リソースに関するルーティングおよび可用性の情報は、前述したようにHAマネージャーの Bulletin Board Service によって伝搬されます。コア・グループによって WebSphere Application Server セル内で可用性情報を交換するための境界は定義されるものの、コア・グループ・ブリッジを使用することで、同じセル内のコア・グループ間、および異なるセル内のコア・グループ間での高可用性情報の交換が可能になります。

プロキシー・サーバーが適切にリクエストをルーティングできるようにするためには、各コア・グループで少なくとも 1 つのコア・グループ・ブリッジ・インターフェース・サーバーをアクティブにしなければなりません。可用性に関する理由から、各コア・グループ内の 2 つの異なるノードのそれぞれに、コア・グループ・ブリッジ・インターフェース・サーバーを構成してください。3つ以上のコア・グループ・ブリッジ・インターフェース・サーバーを構成すると、メモリーおよび CPU のオーバーヘッドが増すため、このような構成は、十分に検討された特定の状況に限る必要があります。その一例は、各コア・グループ内のノードが、3台以上のサーバーに分散されている場合です。この場合は、そのうちの 2 台のサーバーに障害または保守が発生しても、コア・グループ・ブリッジの通信が中断されないように、耐障害性を最大化する必要があります。

さらに、コア・グループ・ブリッジ・サービスは、メモリーおよび CPU リソースを消費することにも留意してください。したがってベスト・プラクティスは、コア・グループ・ブリッジ・インターフェース・サーバーとしてだけ機能するサーバーを構成し、自動再起動用の監視ポリシーを構成することです。

同じセル内の 2 つのコア・グループの間に、コア・グループ・ブリッジ・サービスをセットアップするための基本ステップの要約を以下に示します。

  1. アクセス・ポイント・グループを定義します (あるいは、既存の DefaultAccessPointGroup を使用します)。
  2. アクセス・ポイント・グループのコア・グループごとに、コア・グループ・アクセス・ポイントを構成します。
  3. コア・グループ・アクセス・ポイントごとに、コア・グループ・ブリッジ・インターフェースを構成します。

次のステップでは、DefaultCoreGroup と WebCoreGroup の間のコア・グループ・ブリッジの構成を詳しく説明します。使用するトポロジーは、図 2 に概略したものです。コア・グループ・ブリッジをセットアップするには、WebCoreGroup が作成されていて、その WebCoreGroup に必要なアプリケーション・サーバーが割り当てられていることが前提条件となります。

図 5 に、管理コンソールでのコア・グループ・ブリッジの設定を示します。ここでは、ブリッジをセットアップする前に 2 つのコア・グループが構成されています。

図 5. ブリッジを構成する前に 2 つのコア・グループのために関連付けられたコア・グループ・ブリッジの設定
ブリッジを構成する前に 2 つのコア・グループのために関連付けられたコア・グループ・ブリッジの設定

一般的に、一貫した命名規則を使用すると、管理がより簡単で正確になります。

表 1 に、サンプル・トポロジーで、コア・グループ・ブリッジ・サービスを構成するために使用される、構成オブジェトの概要を記載します。

表 1. コア・グループ・ブリッジの構成パラメーター
セルコア・グループノードコア・グループ・アクセス・ポイント名コア・グループ・ブリッジ・インターフェース・サーバーホスト名/IP アドレスブリッジ・インターフェース・サーバーの DCS ポート
d0002DefaultCoreGrouphhuelinux_m00021d0002_dft_ap01d0002DftCgBr_01hhuelinux41266
hhuelinux_m00022d0002DftCgBr_0242266
d0002WebCoreGrouphhuelinux_m00021d0002_web_ap01d0002WebCgBr_01hhuelinux41291
hhuelinux_m00022d0002WebCgBr_0242291

2 つのコア・グループの間にコア・グループ・ブリッジをセットアップするには、以下のステップを実行します。

  1. セル d0002 の WebSphere Application Server 管理コンソールで、「Servers (サーバー)」 > 「Core Groups (コア・グループ)」 > 「Core group bridge settings (コア・グループ・ブリッジ設定)」の順にナビゲートします。
  2. 各コア・グループ間の通信には、コア・グループ・アクセス・ポイント・グループが使用されます。このシナリオで、同じセル内にある 2 つのコア・グループの間にブリッジを作成するために、事前定義された DefaultAccessPointGroup を使用することができます。ここで、DefaultAccessPointGroup を使用して、WebCoreGroup のコア・グループ・ブリッジ・インターフェース・サーバーを構成することで、コア・グループ・アクセス・ポイントを追加します。「DefaultAccessPointGroup」をクリックしてください (図 6 を参照)。
    図 6. コア・グループ・アクセス・ポイントを選択する
    コア・グループ・アクセス・ポイントを選択する
  3. 「Core group access points (コア・グループ・アクセス・ポイント)」をクリックして、WebCoreGroup のコア・グループ・アクセス・ポイントを構成します (図 7 を参照)。
    図 7. コア・グループ・アクセス・ポイントの構成
    コア・グループ・アクセス・ポイントの構成

アクセス・ポイント・グループにピア・アクセス・ポイントも含まれている場合、アクセス・ポイント・グループが持てるコア・グループ・アクセス・ポイントは、コア・グループあたり 1 つに制限されます。

  1. コア・グループ・アクセス・ポイント・パネルでは、既存のコア・グループ・アクセス・ポイントを更新する (既存のコア・グループ・アクセス・ポイントを選択して、「Show Detail (詳細表示)」をクリック) ことも、新しいコア・グループ・アクセス・ポイントを作成する (「New (新規)」をクリック) こともできます。図 8 に、既存のコア・グループ・アクセス・ポイントを選択して、設定を更新する方法を示します。
    図 8. 値を編集するためにコア・グループ・ポイントを選択する
    値を編集するためにコア・グループ・ポイントを選択する

必須ではありませんが、コア・グループ・アクセス・ポイントに意味のある名前を付けることは、グッド・プラクティスです。

  1. コア・グループ・アクセス・ポイントの構成では、基本的に以下の項目を構成する必要があります。
    1. コア・グループ・アクセス・ポイント名
    2. アクセス・ポイントを構成するコア・グループ
    3. ブリッジ・インターフェースの定義
    4. カスタム・プロパティー
    コア・グループ・アクセス・ポイントの名前を入力し、このアクセス・ポイントを定義するコア・グループをドロップダウン・ボックスから選択します (図 9 を参照)。「Apply (適用)」ボタンをクリックし、次に「Bridge interfaces (ブリッジ・インターフェース)」をクリックして、ブリッジ・インターフェース・サーバーを構成します。
    図 9. コア・グループ・アクセス・ポイントの名前を変更しブリッジ・インターフェースを選択する
    コア・グループ・アクセス・ポイントの名前を変更しブリッジ・インターフェースを選択する
  2. このコア・グループ・アクセス・ポイントに追加するコア・グループ・ブリッジ・インターフェース・サーバーごとに、以下のステップを繰り返します。
    1. 新しいブリッジ・インターフェース・サーバーを追加するには、「New (新規)」をクリックします (図 10 を参照)。
    2. 表 1の 「コア・グループ・ブリッジの構成パラメーター」に従って、コア・グループ・ブリッジ・インターフェース・サーバーとして動作するサーバーを、ドロップダウン・リストから選択します。図 10 に、DefaultCoreGroup に定義されたブリッジ・インターフェース・サーバーを示します。
    図 10. DefaultCoreGroup に構成されたブリッジ・インターフェース・サーバー
    DefaultCoreGroup に構成されたブリッジ・インターフェース・サーバー
  3. WebCoreGroup にもステップ 5 からステップ 9 を繰り返し、このコア・グループのブリッジ・インターフェース・サーバーを定義します。
  4. コア・グループ・アクセス・ポイント・グループのすべてのグループ・ブリッジ・サーバーを定義したら、「Core group bridge settings (コア・グループ・ブリッジ設定)」をクリックし、コア・グループ・ブリッジ設定パネルに戻ります。エントリーを展開して、コア・グループ・ブリッジ設定を確認してください。

コア・グループ通信は、サーバーの DCS ポートを介して実行されます。そのため、コア・グループがファイヤーウォールで隔離された別のネットワーク・ゾーンに存在する場合は、ファイヤーウォールでこれらのポートが開いていることを確認してください。

  1. ブリッジ構成および関連するネットワーク構成の概要がわかるように、図 11 にアクセス・ポイント、コア・グループ・ブリッジ・サーバー、およびそれらの属性がすべて展開された状態の DefaultAccessPointGroup を示します。このセル d0002 内のコア・グループ・ブリッジの構成の概要では、サーバー d0002DftCgBr_01、d0002DftCgBr_02、d0002WebCgBr_01、および d0002WebCgBr_02 の DCS ポートを介して、DefaultCoreGroup が WebCoreGroup にブリッジされることがわかります。
    図 11. ブリッジ・インターフェースがすべて表示されたコア・グループ・ブリッジ設定
    ブリッジ・インターフェースがすべて表示されたコア・グループ・ブリッジ設定
  2. アクセス・ポイント・グループに構成されたコア・グループ・ブリッジ・インターフェース・サーバーをすべてシャットダウンして再起動し、JVM ログを確認してブリッジが機能していることを確認します。ログでは、以下のメッセージを確認してください。
    • CWRCB0106I
    • CWRCB0107I
    リスト 1
    [11/27/11 16:38:37:081 IST] 00000008 CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m0002 1\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266 
    [11/27/11 16:38:54:009 IST] 00000008 CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01
    (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

コア・グループ・ブリッジ・サービスが機能していることを確認できたら、両方のコア・グループに含まれるアプリケーションに、WebSphere プロキシー・サーバー経由でアクセスできる状態にあるということです。各コア・グループの WebSphere Application Server にデプロイされたアプリケーションに HTTP プロトコルを使用してアクセスするには、ブラウザーの URL にプロキシー・サーバーの PROXY_HTTP_ADDRESS ポート (例えば、80) を指定する必要があります。HTTPS プロトコルを使用してアプリケーションにアクセスする場合には、ブラウザーの URL にプロキシー・サーバーの PROXY_HTTPS_ADDRESS ポート (例えば、443) を指定します。アプリケーションにアクセスするために使用するホスト名は、WebSphere プロキシー・サーバーのインターネット・ホスト名です。したがって、Information.ear の Web モジュールにアクセスするために使用する URL は、例えば https://proxyhost/info/Information.jsp となり、CoeTest.ear の Web モジュールにアクセスするための URL は、https://proxyhost/jdbctest/index.jsp となります。

WebSphere プロキシー・サーバーによってルーティングされたリクエストの結果が (エラーの中でも) 503 HTTP 戻りコードとなった場合、よくある原因として以下が考えられます。

  • コア・グループ・ブリッジが正常に機能していない。この場合、各コア・グループ・アクセス・ポイントで少なくとも 1 つのコア・グループ・ブリッジ・サーバーが稼動していることを確認してください。
  • エンタープライズ・アプリケーション自体が起動されていない。

この時点で、プロキシー・サーバーを介してアプリケーションにアクセスできることをテストして確認してください。図 2 のサンプル・トポロジーによると、以下のアプリケーションが動作していることになります。

  • Information.ear
  • CoETest.ear

各コア・グループで少なくとも 1 つのコア・グループ・ブリッジ・インターフェース・サーバーが稼動していなければならないことに注意してください。

コア・グループ・ブリッジ・サービスのセットアップについては、WebSphere Application Server インフォメーション・センターを参照してください。


WebSphere Application Server がプロキシー・サーバーとは異なるセル内にある場

このセットアップでは、プロキシー・サーバーが、自身と同じコア・グループに含まれるアプリケーション・サーバーだけでなく、同じセル内の異なるコア・グループに含まれるアプリケーション・サーバー、さらにリモート・セル内の管理対象コンテンツ・サーバーにもトラフィックをルーティングします。

図 12 に示す構成のトポロジーでは、プロキシー・サーバーのクラスターを使用して、これらのプロキシー・サーバーと同じコア・グループ (DefaultCoreGroup) に含まれるアプリケーション・サーバーと、プロキシー・サーバーのセル (d0002) 内の別のコア・グループ (WebCoreGroup) にリクエストをルーティングします。このシナリオではさらに、プロキシー・サーバーのセルとは異なるセル (d0003) 内のアプリケーション・サーバーにもリクエストをルーティングします。前のシナリオで説明したように、同じセル内の 2 つのグループの間にはコア・グループ・ブリッジを構成する必要があります。それに加え、プロキシー・サーバーのコア・グループとリクエストのルーティング先となるリモート・セルとの間には、ピア・コア・グループ・ブリッジを確立しなければなりません。

図 12. 異なるセル内にあるアプリケーション・サーバーへのルーティング
異なるセル内にあるアプリケーション・サーバーへのルーティング

前述のとおり、管理対象リソースに関するルーティングおよび可用性の情報は、HAマネージャーの Bulletin Board Service を使用して伝搬されますが、コア・グループにより、WebSphere Application Server セル内で可用性情報を交換するための境界が定義されます。そのため、コア・グループ間およびセル間で高可用性情報を交換できるようにするためには、コア・グループ・ブリッジを構成する必要があります。同じセル内の異なるコア・グループに含まれるサーバーにデプロイされているアプリケーションにリクエストをルーティングするために必要なコア・グループの構成については、前のセクションで説明したとおりです。このセクションでは、リモート・セル内のサーバーにリクエストをルーティングするために必要なコア・グループの構成 (これをピア・コア・グループ・ブリッジと呼びます) に焦点を当てます。

セルをまたがってコア・グループをブリッジする場合には、以下の条件が満たされていることを確認してください。

プロキシー・サーバーが適切にリクエストをルーティングできるようにするためには、各コア・グループで少なくとも 1 つのコア・グループ・ブリッジ・インターフェース・サーバーをアクティブにしなければなりません。可用性に関する理由から、各コア・グループ内の異なるノードに、2 つのコア・グループ・ブリッジ・インターフェース・サーバーを構成してください。3つ以上のコア・グループ・ブリッジ・インターフェース・サーバーを構成すると、メモリーおよび CPU のオーバーヘッドが増えるため、このような構成は、十分に検討された特定の状況に限る必要があります。その一例は、各コア・グループ内のノードが、3台以上のサーバーに分散されている場合です。この場合、そのうちの 2 台のサーバーに障害または保守が発生しても、コア・グループ・ブリッジの通信が中断されないように、耐障害性を最大化する必要があります。

さらに、コア・グループ・ブリッジ・サービスは、メモリーおよび CPU リソースを消費することにも留意してください。したがってベスト・プラクティスとなるのは、コア・グループ・ブリッジ・インターフェース・サーバーとしてのみ機能するサーバーを構成し、これらの専用サーバーで、自動再起動用に設定した監視ポリシー・セットを構成することです。

  • コア・グループ・ブリッジ通信を構成しているセルには、固有の名前が設定されていること。
  • 2 つのピア・コア・グループを接続するために使うコア・グループ・アクセス・ポイント・グループには、それぞれのセル内で同じ名前が設定されていること。
  • 各アクセス・ポイント・グループに以下が含まれていること。
    • ローカル・セルのコア・グループに対応する 1 つのコア・グループ・アクセス・ポイント。
    • リモート・セルの各コア・グループに対応する 1 つのコア・グループ・アクセス・ポイント。
    • 同じコア・グループ・ブリッジ・サーバーが、同じセル内のコア・グループ間のブリッジ、およびリモート・セル内のコア・グループとのブリッジに使用されること。
  • セキュアな環境 (通常、本番環境はこれに該当します) で動作している場合には、セル間にコア・グループ・ブリッジをセットアップする際に検討を要する点が他にもいくつかあります。具体的には、以下の検討事項が挙げられます。
    • セキュリティー・レルムの名前が、両方のセルで一致していること。
    • セルは互いを信頼し、2 つのセルの間で署名者証明書を交換できること。
    • セルの間で LTPA 鍵を交換できること。したがって、手動で適切な措置を取らない限り、LTPA 鍵の自動再生成によってコア・グループ・ブリッジは切断されます。このため、LTPA 鍵の自動再生成を無効にすることを検討する必要があります。

2 つのセルの間に、コア・グループ・ブリッジ・サービスをセットアップするためのステップは以下のとおりです。

  1. アクセス・ポイント・グループを定義します。アクセス・ポイント・グループの名前は、両方のセルで一致していなければならないことに注意してください。
  2. アクセス・ポイント・グループのコア・グループごとに、コア・グループ・アクセス・ポイントを構成します。
  3. コア・グループ・アクセス・ポイントごとに、コア・グループ・ブリッジ・インターフェースを構成します。

以下のステップで、セル d0002 とセル d0003 の間にコア・グループ・ブリッジ・サービスを構成する方法を説明します。いずれのセル内でも、コア・グループ・ブリッジ・インターフェース・サーバーは DefaultCoreGroup のメンバーになります。

表 2 に、コア・グループ・ブリッジ・サービスを構成するために使用している構成オブジェトの概要を記載します。

表 2. ピア・コア・グループ・ブリッジ用のコア・グループ・ブリッジの構成パラメーター
セルコア・グループノードコア・グループ・アクセス・ポイント名コア・グループ・ブリッジ・インターフェース・サーバーホスト名/IP アドレスブリッジ・インターフェース・サーバーの DCS ポート
d0002DefaultCoreGrouphhuelinux_m00021d0002_dft_ap01d0002DftCgBr_01hhuelinux41266
hhuelinux_m00022d0002DftCgBr_0242266
d0003DefaultCoreGrouphhuelinux_m00031d0003_dft_ap01d0003DftCgBr_01hhuelinux41366
hhuelinux_m00032d0003DftCgBr_0242366

この環境をセットアップするために必要なステップは、セルごとに適切な構成値を使用して行う必要があります。最初に、セル d0002 の構成ステップを説明します。

  1. セル d0002 の WebSphere Application Server 管理コンソールを開き、「Servers (サーバー)」 > 「Core Groups (コア・グループ)」 > 「Core group bridge settings (コア・グループ・ブリッジ設定)」の順にナビゲートします。
  2. 「Peer access points (ピア・アクセス・ポイント)」を選択します (図 13 を参照)。
    図 13. ピア・アクセス・ポイントの構成
    ピア・アクセス・ポイントの構成
  3. 新しいピア・アクセス・ポイントを作成するには、「New (新規)」をクリックします。
  4. 表 2 の構成値のとおりに、構成を入力します (図 14 を参照)。
    図 14. 新しいコア・グループ・ピア・アクセス・ポイントを作成する
    新しいコア・グループ・ピア・アクセス・ポイントを作成する
  5. 「Next (次へ)」をクリックして、次のパネルに進みます。
  6. リモート・セル内の最初のブリッジ・インターフェース・サーバーの DCS 接続情報を入力します。このセットアップでは、これがセル d0003 内の DefaultCoreGroup の最初のコア・グループ・ブリッジ・サーバーになります。表 2 に従ってここに入力するのは、サーバー d0003DftCgBr_01 のホスト名およびポート名です。図 15 に、この最初のピア・ポート定義の構成を示します。
    図 15. コア・グループ・アクセス・ポイントのピア・ポートの構成
    コア・グループ・アクセス・ポイントのピア・ポートの構成
  7. 「Next (次へ)」をクリックして、要約パネルに進みます。
  8. 「Finish (完了)」をクリックして、最初のピア・アクセス・ポイントの作成を完了します。
  9. もう 1 つのピア・アクセス・ポイントを追加するために、そのピア・アクセス・ポイント名をクリックします (図 16 を参照)。
    図 16. ポートに追加するコア・グループ・ピア・アクセス・ポイントの選択
    ポートに追加するコア・グループ・ピア・アクセス・ポイントの選択
  10. 「Peer ports (ピア・ポート)」をクリックし、ピア・コア・グループ・ブリッジの高可用性を目的としたアクセス・ポイント・ポートをもう 1 つ追加します (図 17 を参照)。
    図 17.ピア・ポート定義の追加
    ピア・ポート定義の追加
  11. 「New (新規)」をクリックして、ピア・ポートをもう 1 つ追加します。
  12. リモート・セル内の 2 番目のブリッジ・インターフェース・サーバーの DCS 接続情報を入力します。表 2 に従ってここに入力するのは、サーバー d0003DftCgBr_02 のホスト名およびポート名です。
  13. 「Peer ports (ピア・ポート)」をもう一度クリックして、ピア・アクセス・ポイントのピア・ポート定義を確認します (図 18 を参照)。
    図 18. ピア・ポート定義の確認
    ピア・ポート定義の確認

d0003 にブリッジするためのコア・グループ・アクセス・ポイント・グループを構成する

次の主要なステップは、コア・グループ・ブリッジ・サービスのコア・グループ・アクセス・ポイント・グループを構成することです。コア・グループ・アクセス・ポイント・グループの作成中に、アクセス・ポイントおよびピア・アクセス・ポイントを、同じステップで割り当てることができます。あるいは、後でアクセス・ポイント情報をグループに割り当てることもできます。この例では、最初に空のアクセス・ポイント・グループを作成し、後でアクセス・ポイントおよびピア・アクセス・ポイントを割り当てます。

アクセス・ポイント・グループの名前は、両方のセルで一致していなければならないことに注意してください。

  1. セル d0002 の WebSphere Application Server 管理コンソールで、「Servers (サーバー)」 > 「Core Groups (コア・グループ)」 > 「Core group bridge settings (コア・グループ・ブリッジ設定)」 > 「Access point groups (アクセス・ポイント・グループ)」の順にナビゲートし、「New (新規)」をクリックします。
  2. 「Access point group name (アクセス・ポイント・グループ名)」フィールドに、作成するコア・グループ・アクセス・ポイント・グループの名前を入力します。このシナリオの場合、入力する名前は dft_d0002_to_dft_d0003 です。
  3. 以後 3 つのパネルで「Next (次へ)」をクリックし、最後に「Finish (完了)」をクリックします。
  4. 作成したばかりのアクセス・ポイント・グループの名前をクリックします (図 19 を参照)。
    図 19. アクセス・ポイントを追加するコア・グループ・アクセス・ポイント・グループの選択
    アクセス・ポイントを追加するコア・グループ・アクセス・ポイント・グループの選択
  5. ピア・アクセス・ポイントを割り当てるために、「Access points (アクセス・ポイント)」コンテナー内の「Peer access points (ピア・アクセス・ポイント)」をクリックします。
  6. 「Available peer access points (使用可能なピア・アクセス・ポイント)」コンテナーで前で作成したピア・アクセス・ポイントを選択し、右矢印をクリックして、このピア・アクセス・ポイントをアクセス・ポイント・グループに追加します (図 20 を参照)。
    図 20. アクセス・ポイント・グループへピア・アクセス・ポイントを追加する
    アクセス・ポイント・グループへピア・アクセス・ポイントを追加する
  7. 「OK」をクリックします。
  8. 次に、ローカル・コア・グループのアクセス・ポイントを、アクセス・ポイント・グループに割り当てます。セルに 1 つのコア・グループしか含まれていない場合には、このステップはスキップできます。「Access points (アクセス・ポイント)」コンテナー内の「Core groups access points (コア・グループ・アクセス・ポイント)」をクリックします (図 21 を参照)。
    図 21. コア・グループ・アクセス・ポイント・グループへローカル・アクセス・ポイントを追加する
    コア・グループ・アクセス・ポイント・グループへローカル・アクセス・ポイントを追加する

コア・グループ・ブリッジの耐障害性を最大化するためには、各ブリッジ・インターフェース・サーバーをそれぞれ異なるノードおよび異なるシステムで稼動させてください。

コア・グループ通信は、サーバーの DCS ポートを介して実行されます。そのため、コア・グループがファイヤーウォールで隔離された別のネットワーク・ゾーンに存在する場合は、ファイヤーウォールでこれらのポートが開いていることを確認してください。

  1. 「Available peer access points (使用可能なピア・アクセス・ポイント)」コンテナーで、追加するコア・グループ・アクセス・ポイントを選択し、右矢印をクリックして、そのアクセス・ポイントをアクセス・ポイント・グループに追加します (図 22 を参照)。この例では、セル d0002 の DefaultCoreGroup とセル d0003 の DefaultCoreGroup との間にコア・グループ・ブリッジを構成しているので、d0002_dft_ap01\DefaultCoreGroup アクセス・ポイントを選択して、コア・グループ・アクセス・ポイント・グループに追加してください。
    図 22. コア・グループ・アクセス・ポイント・グループに追加するアクセス・ポイントを選択する
    コア・グループ・アクセス・ポイント・グループに追加するアクセス・ポイントを選択する
  2. 「OK」をクリックします。
  3. 「Core group bridge settings (コア・グループ・ブリッジ設定)」をクリックします。エントリーを展開して、コア・グループ・ブリッジ設定を確認します。
    図 23. セル d0002 のコア・グループ・ブリッジ構成の概要
    セル d0002 のコア・グループ・ブリッジ構成の概要

ブリッジ構成および関連するネットワーク構成の概要がわかるように、図 23 にアクセス・ポイント、コア・グループ・ブリッジ・サーバー、およびそれらの属性がすべて展開された状態で、セル d0002 の両方のコア・グループ・アクセス・ポイント・グループを示します。このセル d0002 のコア・グループ・ブリッジ構成の概要からわかるのは、セル d0002 の DefaultCoreGroup は、サーバー d0002DftCgBr_01 および d0002DftCgBr_02 を介して、セル d0003 の DefaultCoreGroup にブリッジされることです。コア・グループ・ブリッジのトラフィックは、この 2 つのサーバーの間を流れ、これらのサーバーの DCS ポートは、サーバー hhuelinux.huebler.at:41366 および hhuelinux.huebler.at:42366 上でリッスンします。

これで、セル d0002 のコア・グループ・ブリッジの構成は完了です。

セル d0003 のコア・グループ・ブリッジの構成

次に、同じ構成ステップをセル d0003 に対して繰り返します。これらのステップは、セル d0003 に対応する名前を使用して実行する必要があります。構成値は、同じく表 2 から決定できます。この構成ステップは基本的に同じなので、ここでは簡単な要約を以下に示します。

  1. セル d0003 の WebSphere Application Server 管理コンソールで、「Servers (サーバー)」 > 「Core Groups (コア・グループ)」 > 「Core group bridge settings (コア・グループ・ブリッジ設定)」の順にナビゲートします。
  2. コア・グループ・アクセス・ポイント・グループの名前は、セル d0002 とセル d0003 で一致していなければならないため、最初のステップでは、dft_d0002_to_dft_d0003 という名前のコア・グループ・アクセス・ポイント・グループを作成します。
  3. コア・グループ・アクセス・ポイント・グループ名をクリックして、「Core group access points (コア・グループ・アクセス・ポイント)」を選択します。
  4. 「Available core group access points (使用可能なコア・グループ・アクセス・ポイント)」にリストされている CGAP_1\DefaultCoreGroup をクリックして、「Show detail (詳細表示)」を選択します。
  5. 表 2 に従って、コア・グループ・アクセス・ポイントの名前を変更し、ブリッジ・インターフェース・サーバーを追加します。必要なステップは、図 9 に詳しく示されています。
  6. d0003_dft_ap01 コア・グループ・アクセス・ポイントを、コア・グループ・アクセス・ポイント・グループ dft_d0002_to_dft_d0003 に追加します。
  7. セル d0002 のピア・アクセス・ポイントを構成し (図 13 を参照)、ピア・アクセス・ポイント d0002_dft_peer_ap01 をコア・グループ・アクセス・ポイント・グループ dft_d0002_to_dft_d0003 に追加します。
  8. セル d0003 のコア・グループ・ブリッジの構成は、図 24 に示すようになっているはずです。
    図 24. セル d0003 のコア・グループ・ブリッジ構成
    セル d0003 のコア・グループ・ブリッジ構成
  9. 両方のセルで構成したすべてのコア・グループ・ブリッジ・インターフェース・サーバーを、シャットダウンして再起動します。
  10. セル d0002 のコア・グループ・ブリッジ・サーバーを起動し、コア・グループ・ブリッジ・サーバーの JVM ログで、ブリッジが機能していることを確認します。ログでは、以下のメッセージを確認してください。
    • CWRCB0106I
    • CWRCB0107I
    セル d0002 のコア・グループ・ブリッジ・サーバーだけを起動した後、セル d0002 の DefaultCoreGroup に関連付けられたコア・グループ・ブリッジ・サーバーの SystemOut.log を確認してください。すると、リスト 2 に記載されたメッセージから、WebCoreGroup へのブリッジは正常に機能していることは確認できますが、アクセス・ポイント・グループ dft_d0002_to_dft_d0003 については、セル d0003 へのブリッジが現時点では使用できないことを意味するメッセージ NO BRIDGES が示されているはずです。
    リスト 2
    [12/6/11 12:08:58:846 IST] 0000000b CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266 
    [12/6/11 12:08:58:850 IST] 0000000b CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup NO BRIDGES 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)
  11. セル d0003 のコア・グループ・ブリッジ・サーバーを起動し、コア・グループ・ブリッジ・サーバーの JVM ログで、ブリッジが機能していることを確認します。ログでは、以下のメッセージを確認してください。
    • CWRCB0106I
    • CWRCB0107I
    セル d0003 のコア・グループ・ブリッジ・サーバーを起動して、セル d0003 の DefaultCoreGroup に関連付けられたコア・グループ・ブリッジ・サーバーの SystemOut.log を確認します。すると、アクセス・ポイント・グループ dft_d0002_to_dft_d0003 には、やはりメッセージ NO BRIDGES が表示され、セル d0002 へのブリッジが使用可能でないことが示されていますが、コア・グループ・ブリッジ・インターフェース・サーバーは稼動しています (リスト 3 を参照)。
    リスト 3
    [12/6/11 13:19:19:685 IST] 00000009 CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0003\hhuelinux_m00031 
    \d0003DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41366 
    [12/6/11 13:19:19:694 IST] 00000009 CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following 
     Access Point Group member(s) available: 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES 
    [12/6/11 13:19:19:702 IST] 00000009 CGBridge      I   CWRCB0108I: The core group 
    bridge service is currently unstable for Access Point Group(s) DefaultAccessPoint
    Group.
    [12/6/11 13:19:21:487 IST] 0000000a CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0003\hhuelinux_m00031\d0003DftCgBr_01) uses the following DCS 
    endpoint:
    127.0.0.1:41366 
    [12/6/11 13:19:21:495 IST] 0000000a CGBridge      I   CWRCB0107I: This core group
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES
  12. さらに SystemOut.log を調べてみると、HMGR0149E エラー・メッセージ (リスト 4) も記録されています。このメッセージが、問題の核心への手掛かりとなります。
    リスト 4
    [12/6/11 13:19:41:763 IST] 00000023 DefaultTokenP E   HMGR0149E: An attempt to open 
    a connection to core group dft_d0002_to_dft_d0003 has been rejected. The sending 
    process has a name of 127.0.0.1:41266 and an IP address of /127.0.0.1. Global 
    security in the local process is Enabled. Global security in the sending process 
    is Enabled. The received token starts with lf>c%$oO. The exception is com.ibm.
    websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due 
    to invalid keys or token type. 
            at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
    (LTPAServerObject.java:1161) 
            at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
    (LTPAServerObject.java:1078) 
            at com.ibm.ws.security.token.WSCredentialTokenMapper.validateLTPAToken
    (WSCredentialTokenMapper.java:1376) 
            at com.ibm.ws.hamanager.runtime.DefaultTokenProvider.authenticateMember
    (DefaultTokenProvider.java:214) 
            at com.ibm.ws.hamanager.coordinator.dcs.MemberAuthenticatorImpl.
    authenticateMember(MemberAuthenticatorImpl.java:87) 
            at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery.DiscoveryRcv.
    acceptStream(DiscoveryRcv.java:185) 
            at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.fetchStream(Packet
    Processor.java:470) 
    at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.run(PacketProcessor.java:860)

    HMGR0149E エラー・メッセージを受け取る理由は、(本番環境では当然の) セキュリティーが有効にされた 2 つのセル間でコア・グループ・ブリッジを確立しようとしている一方、これらのセルの間にはまだ SSO がセットアップされていないためです。

コア・グループ・ブリッジ・サービスは、セル間の認証に LTPA 認証方式を使用します。

  1. WebSphere Application Server で、「LTPA (Lightweight Third Party Authentication)」および「LTPA cookies を使用した認証のためのシングル・サインオン」のセットアップ手順に従って、ピア・コア・グループ・ブリッジに対して LTPA による認証を使用可能にする必要があります。ここで重要となる検討事項を以下に要約します。
    • セル間での LTPA 鍵の共有。以後の問題を回避するために、自動再生成を無効に設定し、新しい鍵を手動で再生成して配布するようにしてください。
    • サーバーの日時が同期されていること。
    • ユーザー・レジストリーを、例えば LDAP や Windows® Active Directory のように一元管理されたレジストリーにすること。
    • LDAP サーバーに接続するために LDAPS プロトコルを実装したセキュアな環境を使用している場合には、LDAP サーバーのサーバー証明書の署名者証明書を、WebSphere プロキシー・サーバーで使用しているトラストストアにインポートします。WebSphere Application Server V7.0 のデフォルトのトラストストアは、CellDefaultTrustStore です。

SSL を使用してサイトにアクセスする場合には、コンテンツ・サーバーのサーバー証明書の署名者証明書を、プロキシーで使用しているトラストストアに追加する必要があります。プロキシーで使用しているトラストストアに追加するのは、サーバー証明書ではなく、署名者証明書です。WebSphere Application Server はある種のミニ CA を使用するため、1 つの署名者証明書がセルのすべての証明書に署名するために使用されます。そのため通常は、この署名者証明書 (root) を2 つのセルの間で交換するだけで十分です。

  1. HTTPS プロトコルを使用して Web ページにアクセスすることを予定している場合、WebSphere プロキシー・サーバーは SSL を使用して、アプリケーションをホストしているサーバーに WC_defaulthost_secure ポートを介してアクセスすることになります。サーバーが同じセル内にある限り、これが問題になることはありませんが (WebSphere Application Server V7.0 以降では、デフォルトで同じセル内のすべてのサーバーは互いを信頼します)、プロキシー・サーバーとコンテンツ・サーバーが異なるセル内にある場合には、署名者証明書の交換が必要になります。署名者証明書を交換できないと、CWPKI0022E: SSL HANDSHAKE FAILURE エラー・メッセージに続いて、「署名者は、ローカル・トラストストアに追加される必要がある可能性があります」と通知する CWPKI0428I エラー・メッセージを受け取る結果となります。その場合、エンド・ユーザーは 503 Service Unavailable 応答コードを受け取ります。
  2. 前述の検討事項に対処した上でサーバーを再起動すると、プロキシー・セル (このシナリオの場合、d0002) のデフォルト・コア・グループに関連付けられたコア・グループ・ブリッジ・サーバー内に、2 つのセルの間にコア・グループ・ブリッジ・サービスが確立されたことを通知するメッセージが見つかるはずです。ログでは、以下のメッセージを確認してください。
    • CWRCB0106I
    • CWRCB0107I
    リスト 5
    [12/7/11 14:43:05:039 IST] 0000000b CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266
    [12/7/11 14:43:05:045 IST] 0000000b CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01 
    (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

コア・グループ・ブリッジ・サービスが機能していることを確認できたら、両方のコア・グループに含まれるアプリケーションに WebSphere プロキシー・サーバーを介してアクセスしてみてください。各コア・グループの WebSphere Application Server にデプロイされたアプリケーションに HTTP プロトコルを使用してアクセスするには、ブラウザーの URL にプロキシー・サーバーの PROXY_HTTP_ADDRESS ポート (この例では、80) を指定します。HTTPS プロトコルを使用してアプリケーションにアクセスする場合には、ブラウザーの URL にプロキシー・サーバーの PROXY_HTTPS_ADDRESS ポート (この例では、443) を使用します。アプリケーションにアクセスするために使用するホスト名は、WebSphere プロキシー・サーバーのインターネット・ホスト名です。

したがって、例えばInformation.ear の Web モジュールにアクセスするために使用する URL は、https://proxyhost/info/Information.jsp となり、CoeTest.ear の Web モジュールにアクセスする URL は、https://proxyhost/jdbctest/index.jsp となります。これと同じルールに従えば、Web モジュール DefaultApplication.ear (セルd0003 にデプロイされていて、/dft のコンテキスト・ルートを使用するモジュール) には、URL https://proxyhost/dft/snoop を使用して WebSphere プロキシー・サーバー経由でアクセスできます。

WebSphere プロキシー・サーバーによってルーティングされたリクエストの結果が 503 HTTP 戻りコードや類似した結果となった場合、最もよくある原因としては以下が考えられます。

  • コア・グループ・ブリッジが正常に機能していない。この場合、各コア・グループ・アクセス・ポイントで少なくとも 1 つのコア・グループ・ブリッジ・サーバーが稼動していることを確認してください。
  • エンタープライズ・アプリケーション自体が起動されていない。
  • 異なるセル間での SSL セットアップに問題がある。

ここで、プロキシー・サーバーを介して、以下のアプリケーションにアクセスできることをテストして確認してください。図 2 に概要を示したサンプル・トポロジーによると、現時点で以下のアプリケーションが起動しているはずです。

  • Information.ear
  • CoETest.ear
  • DefaultApplication.ear

各コア・グループで、少なくとも 1 つのコア・グループ・ブリッジ・インターフェース・サーバーが稼動していなければならないことに注意してください。


非管理対象リソースへのルーティング

管理対象リソースや動的ルーティングとは対照的に、非管理対象リソースに対しては、手動でルーティングを構成しなければなりません。非管理対象リソースは、WebSphere Application Server の管理制御下にないためです。したがって、コア・グループ・メカニズムを介して状態に関する情報を交換することはできません。

図 25 に、WebSphere プロキシー・サーバーを使用して、非管理対象サーバーにリクエストをルーティングする方法を示します。この図から、リクエストに対応する非管理対象サーバーは、WebSphere Application Server 内の汎用サーバー・クラスターのメンバーとして構成しなければならないことがわかります。

図 25. 非管理対象サーバーへのリクエストのルーティング
非管理対象サーバーへのリクエストのルーティング

汎用サーバー・クラスターの構成

WebSphere プロキシー・サーバーを使用して非管理対象リソースにリクエストをルーティングするには、最初のステップとして、WebSphere Application Server に汎用サーバー・クラスターを構成します。WebSphere Application Server セルに汎用サーバー・クラスターを構成する方法は以下のとおりです。

  1. WebSphere プロキシー・サーバーをホストしているセルの管理コンソールで、「Servers (サーバー)」 > 「Clusters (クラスター)」 > 「Generic server clusters (汎用サーバー・クラスター)」 > 「New (新規)」の順にナビゲートします。
  2. 作成する汎用サーバー・クラスターの名前を入力し、使用するプロトコル (HTTP または HTTPS) を選択します (図 26 を参照)。
    図 26. 汎用サーバー・クラスターの作成
    汎用サーバー・クラスターの作成
  3. 汎用サーバー・クラスターを作成した後、接続情報と併せて各クラスター・メンバーのウェイトを入力します。図 27 に、汎用サーバー・クラスターのメンバーの構成例を示します。TCP/IP 接続情報は、ホスト名/IP アドレスとポート、そしてウェイトを指定するという形式で入力する必要があります。ウェイトの値はゼロにしないでください。ウェイトをゼロにすると、そのクラスター・メンバーにはリクエストがルーティングされません。さらに、この図には IBM HTTP Server 構成に応じた重要な構成の指示も示されています。
    図 27. 汎用サーバー・クラスター・メンバーの作成
    汎用サーバー・クラスター・メンバーの作成
  4. 汎用サーバー・クラスターを構成するすべてのメンバーを、汎用サーバー・クラスター定義に登録します。これにより、WebSphere プロキシー・サーバーは、これらのクラスター・メンバーの間での負荷分散およびフェイルオーバー機能を実装できるようになります。
    • この負荷分散は、Web サーバー・プラグインで使用するアルゴリズムと同様の、重み付けラウンドロビン・アルゴリズムです。
    • 汎用サーバー・クラスターのメンバーは HTTP または HTTPS によってのみ接続されるため、障害の検出は TCP/IP 機能によって制限されます。WebSphere プロキシー・サーバーが汎用サーバー・クラスター・メンバーのいずれかで障害を発見すると、定期的に (5 秒ごと) 接続の確立を試行することによって、サーバーが使用可能であるかどうかを調べます。
  5. HTTPS プロトコルを使用する場合には、非管理対象サーバーのサーバー証明書の署名者証明書が、WebSphere プロキシー・サーバーで使用するトラストストアに含まれていることを確実にしてください。WebSphere Application Server V7.0 以降では、デフォルトのトラストストアは CellDefaultTrustStore です。

以上のステップを完了した時点で、汎用サーバー・クラスターのための基本的な WebSphere 構成が完了したことになります。汎用サーバー・クラスターの構成についての詳細は、WebSphere Application Server インフォメーション・センターを参照してください。

汎用サーバー・クラスターへのルーティングの構成

汎用サーバー・クラスターは非管理対象リソースを意味するので、WebSphere Application Server は汎用サーバー・クラスターから使用できるアプリケーションを認識しません。したがって、プロキシーがどのリクエストを汎用サーバー・クラスターに転送するべきかを「把握」できるように、手動でルーティングを構成する必要があります。

管理対象リソースの場合、ルーティングの決定は、以前説明したようにプロキシー・ルーティングが有効化されたWeb モジュールのコンテキスト・ルートに基づいて行われます。非管理対象リソースでも同様のことを行うためには、URIgroup を構成する必要があります。URIgroup は基本的に、コンテキスト・ルートおよび「ルーティング・ルール」を提供します。WebSphere Application Server のこの 2 つの構成アイテムにより、プロキシーは非管理対象リソースに対するルーティングが決定できるようになります。

以下に、URIgroup およびルーティング・ルールを作成するために最小限必要なステップを説明します。

URI グループ定義で使用する URI パターンは、汎用クラスターの各メンバーに存在する必要があります。このパターンは、ターゲット・サーバーに転送されるリクエストの一部です。

  1. WebSphere プロキシー・サーバーをホストするセルの管理コンソールで、「Servers (サーバー)」 > 「Server types (サーバー・タイプ)」 > 「WebSphere proxy servers (WebSphere プロキシー・サーバー)」 > 「<proxy_name>」 > 「HTTP Proxy Server settings (HTTP プロキシー・サーバー設定)」 > 「Proxy settings (プロキシー設定)」 > 「URI Groups (URI グループ)」 > 「New (新規)」の順にナビゲートします。図 28 に、基本的にシンボリック名および 1 つ以上の URI パターンからなる URI グループの構成を示します。WebSphere プロキシー・サーバーによって処理される各リクエストは、これらの URI パターンと照合されて、リクエストがその URI グループに属するかどうかが判定されます。
    図 28. URI グループの定義画面
    URI グループの定義画面
  2. URI グループを構成後、ルーティングを明示的に構成して、WebSphere プロキシー・サーバーがリクエストのルーティング先を把握できるようにする必要があります。この構成作業も、同じく管理コンソール上で行います。「Servers (サーバー)」 > 「Server types (サーバー・タイプ)」 > 「WebSphere proxy servers (WebSphere プロキシー・サーバー)」 > 「<proxy_name>」 > 「HTTP Proxy Server settings (HTTP プロキシー・サーバー設定)」 > 「Routing rules (ルーティング・ルール)」 > 「New (新規)」の順にナビゲートしてください。

    図 29 に、プロキシー・サーバーのルーティング・ルールの基本的な構成を示します。基本的にルーティング・ルールを定義するには、シンボリック名を指定し、このルールを適用する WebSphere 仮想ホストおよび URI グループを選択します。「Routing action (ルーティング・アクション)」では、「Generic Server Cluster (汎用サーバー・クラスター)」のラジオ・ボタンを選択し、ドロップダウン・ボックスから汎用サーバー・クラスターを選択します。最後に、「Enable this rule (このルールを有効にする)」チェック・ボックスが選択されていることを確認してください。

    図 29. ルーティング・ルールの構成画面
    ルーティング・ルールの構成画面
  3. WebSphere プロキシー・サーバーを再起動します。
  4. URI グループ定義の URI パターンと一致するリクエストを送信して、非管理対象リソースへのアクセスをテストします。

WebSphere プロキシー・サーバーのルーティング・ルールの構成の詳細については、WebSphere Application Server インフォメーション・センターを参照してください。


まとめ

この記事では、WebSphere プロキシー・サーバーで使用できるさまざまなリソースと、WebSphere プロキシー・サーバーが提供するルーティング機能について説明しました。複数の構成シナリオでの依存関係、そして潜在的な問題点を明らかにするために、サンプル・トポロジーに基づく詳細な手順を示しました。この情報が、特定のシナリオを素早く成功裏に実装する役に立つことを願います。


謝辞

この記事の作成中に貴重な情報を提供してくださった Tim Blank 氏、Marie Gann 氏、Kevin Kelle 氏、John T. Pape 氏、Ying Wang 氏、Bill Wigger 氏に感謝の意を表します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=824411
ArticleTitle=セキュアな環境における WebSphere プロキシー・サーバーのルーティング機能
publish-date=07092012