WebSphere Application Server

Edge Components 概念、計画とインストール

バージョン 6.1
GD88-6859-00

この版は、以下のプログラムに適用されます。

また、新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。

http://www.ibm.com/jp/manuals/main/mail.html

なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは

http://www.ibm.com/jp/manuals/  の「ご注文について」をご覧ください。

(URL は、変更になる場合があります)

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

 原 典: GC31-6918-00
WebSphere Application Server
Concepts, Planning, and Installation for Edge Components
Version 6.1
 発 行: 日本アイ・ビー・エム株式会社
 担 当: ナショナル・ランゲージ・サポート

第1刷 2006.5

Copyright International Business Machines Corporation 2006. All rights reserved.
(C) Copyright IBM Japan 2006

目次

  1. リバース・プロキシーとして機能する Caching Proxy
  2. フォワード・プロキシーとして機能する Caching Proxy
  3. 透過フォワード・プロキシーとして機能する Caching Proxy
  4. ロード・バランスの対象となる クラスターのプロキシー・サーバーとして機能する Caching Proxy
  5. 複数のコンテンツ・ホストのロード・バランシング
  6. 複数のリバース・プロキシー・サーバーおよびコンテンツ・ホストのロード・バランシング
  7. 複数のキャッシング・プロキシーをロード・バランシングするための Dispatcher の使用。
  8. 高可用性のインターネット・アクセスを提供するための 1 次およびバックアップ Dispatcher の使用。
  9. Caching Proxy マシンにバックアップ Dispatcher を配置する。
  10. Web コンテンツを高可用にするための 1 次およびバックアップ Load Balancer の使用
  11. コンテンツ・ホストへのバックアップ Load Balancer の配置
  12. CBR による HTTP 要求の経路指定
  13. CBR により経路指定された HTTP 要求のロード・バランシング
  14. 企業消費者間ネットワーク (フェーズ 1)
  15. 企業消費者間ネットワーク (フェーズ 2)
  16. 企業消費者間ネットワーク (フェーズ 3)
  17. 企業消費者間バンキング・ソリューション
  18. Web ポータル
  19. Caching Proxy デモンストレーション・ネットワーク
  20. Load Balancer デモンストレーション・ネットワーク

本書について

本書 WebSphere(R) Application Server Edge Components 概念、計画とインストール は、WebSphere Application Server Edge Components の入門書です。本書は、製品についての高水準な概説、キー・コンポーネントの機能についての詳細な解説、ネットワーク・エッジ・シナリオ、インストールおよび初期構成情報、およびデモンストレーション・ネットワークを提供します。

本書の対象読者

WebSphere Application Server Edge Components 概念、計画とインストール は、オペレーティング・システムと、インターネット・サービスの提供に精通した、経験豊富なネットワークおよびシステム管理者を対象として作成されています。 WebSphere Application Server または WebSphere Application Server Edge Components についての知識が事前になくても、問題はありません。

アクセシビリティ

アクセシビリティ機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるようにサポートします。以下は、WebSphere Application Server、バージョン 6.1 の主要なアクセシビリティー機能です。

本書で使用されている規則と用語

本書では、以下のような書体およびキー操作の規則を使用しています。

表 1. 本書の規則
規則 意味
太字 グラフィカル・ユーザー・インターフェース (GUI) に関しては、太字は、メニュー、メニュー項目、ラベル、ボタン、アイコン、およびフォルダーを示します。また、太字にしないと周りのテキストと混同される恐れがあるコマンド名を強調するためにも使用されます。
モノスペース コマンド・プロンプトから入力する必要のあるテキストを示します。また、モノスペースは、画面上のテキスト、コード例、およびファイルからの引用も示します。
イタリック 指定する必要のある可変値を示します (例 : fileName でファイルの名前を指定します)。イタリックは、強調表示および書名の表示にも使用されます。
Ctrl-x x がキーの名前である場合、制御文字のシーケンスを示します。例えば、Ctrl-c は、Ctrl キーを押しながら c キーを押すという意味になります。
Return Return、Enter または左矢印が表示されていたキーを指します。
% Linux および UNIX(R) のコマンド・シェル・プロンプト (root 権限を必要としないコマンド用) を示します。
# Linux および UNIX のコマンド・シェル・プロンプト (root 権限を必要とするコマンド用) を示します。
C:¥ Windows コマンド・プロンプトを表します。
コマンド入力 コマンドを "入力" する、または "発行" すると指示された場合は、コマンドを入力してから Return を押します。例えば、「ls コマンドを入力してください」という指示は、コマンド・プロンプトに ls とタイプしてから Return を押すという意味になります。
[ ] 構文記述内のオプション項目を囲みます。
{ } 構文記述内の、項目を選択する必要があるリストを囲みます。
| 構文記述の中で { } (中括弧) で囲まれた選択項目リストにある項目を区切るために使用されます。
... 構文記述内の省略記号は、前の項目を 1 回以上繰り返すことができることを示します。例にある省略記号は、簡潔にするために例から情報が省略されていることを示します。

概説

この部では、WebSphere Application Server Edge Components、Caching Proxy、および Load Balancer の概要と、これらを Application Server と統合する方法について説明します。また、Caching Proxy および Load Balancer のコンポーネントを定義します。さらに、このセクションでは、他の関連する WebSphere ファミリー製品も紹介します。

この部は、以下の章で構成されています。

WebSphere Application Server Edge components の紹介

WebSphere は、企業間 e-commerce 用アプリケーションなどの次世代 e-business アプリケーションの、企業による開発、展開、および統合を可能にするインターネット・インフラストラクチャー・ソフトウェアです。 WebSphere ミドルウェアは、単純な Web 公開から企業規模のトランザクション処理までのビジネス・アプリケーションをサポートします。

WebSphere Application Server は、WebSphere プラットフォームの基礎として、ユーザーによるビジネス・アプリケーションの設計、インプリメント、展開、および管理を可能にする 包括的なミドルウェアのセットを提供します。これらのアプリケーションは、単純な Web サイト・ストアフロントから組織のコンピューター・インフラストラクチャーの完全な改訂まで多岐にわたります。

パーソナライゼーションなどのプロセッサー集中機能は、すべての e-business の競争力を高めます。ただし、これらの機能を中央サーバーに常に任せていると、インターネットへの重要な機能の拡張が妨げられる可能性があります。したがって、新しい Web アプリケーションを常に追加して、企業のインターネット・インフラストラクチャーの範囲を広げて性能を高める必要があります。また、e-business にとって、信頼性とセキュリティーは極めて重要です。サービスがごく短い間中断するだけで、取引を失うこともあります。

Edge Components (従来の Edge Server) は、WebSphere Application Server オファリングの一部になりました。Edge Components を WebSphere Application Server と共に使用すると、Web サーバーへのクライアント・アクセスを制御して、インターネットまたは企業のイントラネットを 介して Web ベース・コンテンツにアクセスするユーザーに企業がより良いサービスを提供できるようになります。 Edge Components を使用すると、Web サーバーの輻輳 (ふくそう) を削減し、コンテンツの可用性を高め、Web サーバーのパフォーマンスを向上させることができます。 Edge Components は、その名前が示すとおり、通常、企業のイントラネットとインターネットの境界に (ネットワーク構成上) 近い位置にあるマシンで実行されます。

WebSphere Application Server には Caching Proxy および Load Balancer Edge components が組み込まれています。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Caching Proxy

Caching Proxy は、1 つ以上のバックエンド・コンテンツ・サーバー用の POP (Point-of-Presence) ノードを提供して、帯域幅使用量を削減し、Web サイトの速度と信頼性を高めます。 Caching Proxy は、静的コンテンツおよび WebSphere Application Server が動的に生成したコンテンツをキャッシュに入れて処理できます。

Caching Proxy は、リバース・プロキシー・サーバー (デフォルト構成) のロールで構成することも、フォワード・プロキシー・サーバーのロールで構成することもでき、要求時間および応答時間の改善を行なう役割をもつ、ネットワークの POP (point-of-presence) または内部ネットワーク・サーバーを提供します。リバース構成とフォワード構成についての詳細は、Caching Proxy の基本構成を参照してください。

プロキシー・サーバー では、クライアントのデータ要求をインターセプトして、コンテンツ・ホスティング・マシンの要求情報を引き出し、そのコンテンツをクライアントに引き渡します。通常エンド・ユーザーの要求の大部分は、Web サーバー・マシン (起点サーバー またはコンテンツ・ホスト ともいう) に保管されている文書を HTTP を使用して引き渡すよう求めるものです。 しかし、プロキシー・サーバーの構成によっては、ファイル転送プロトコル (FTP) および Gopher など、他のプロトコルも扱うことができます。

プロキシー・サーバーは、キャッシュ可能コンテンツを、要求側に引き渡す前にローカル・キャッシュに保管します。キャッシュ可能コンテンツの例として、静的 Web ページと、動的に生成されたほとんど変更されない情報をもつ JavaServer Pages ファイルが挙げられます。キャッシングにより、プロキシー・サーバーは、以後同じコンテンツが要求されたときにそのコンテンツをキャッシュから直接引き渡すことができるので、改めてコンテンツ・ホストから検索するよりはるかに迅速に処理できます。

Caching Proxy 用のプラグインを使用すると、プロキシー・サーバーに機能が追加されます。

アプリケーション・プログラミング・インターフェース (API) に対するカスタム・プラグイン・モジュールを作成することによって、Caching Proxy の機能をさらに拡張することができます。 API はフレキシブルで使用しやすく、プラットフォームに依存しません。プロキシーは、処理するクライアント要求ごとに一連のステップを実行します。プラグイン・アプリケーションは、クライアント認証または要求フィルター操作などの要求処理ワークフロー内のステップを変更または置換します。例えば、強力な Transmogrify インターフェースは、HTTP データへのアクセスを提供し、URL と Web コンテンツの置換または変換を可能にします。指定した処理ステップをプラグインを使用して変更または置換することが可能であり、特定のステップのために複数のプラグインを起動することができます。

Load Balancer

Load Balancer は、ネットワーク・トラフィック・フローを管理するネットワーク・エッジ・システムを作成して、輻輳を削減し、その他のさまざまなサービスとシステムに対する負荷のバランシングを行います。 Load Balancer により、サイト選択、ワークロード管理、セッション類縁性、および透過性フェイルオーバーが可能になります。

Load Balancer は、インターネットと企業のバックエンド・サーバーの間にインストールされます。バックエンド・サーバーには、コンテンツ・ホストまたは Caching Proxy マシンを使用できます。大量の要求に応えるためまたは大量のコンテンツを扱うために企業で複数のバックエンド・サーバーを使用している場合にも、Load Balancer はインターネットにおける企業の単一の POP (Point-of-Presence) ノードとして機能します。また、1 次 Load Balancer に一時的に障害が起きたときにそれを引き継ぐバックアップ Load Balancer をインストールすることによって、ハイ・アベイラビリティーを保証することができます。

Load Balancer は、クライアントからのデータ要求をインターセプトして、現在各要求を満たすのに最も適しているサーバーに要求を転送します。つまり、Network Dispatcher は、同じタイプの要求にサービスを行うマシンの定義済みセット間で、着信要求のロードのバランスを取ります。 Load Balancer は、WebSphere Application Server および Caching Proxy マシンを含むさまざまなタイプのサーバーに要求を分散することができます。カスタム advisor を使用することによって、ロード・バランシングを特定のアプリケーションまたはプラットフォーム用にカスタマイズできます。 WebSphere Application Server のロード・バランシング用の情報を取得するために、特定目的の advisor を使用できます。

Content Based Routing コンポーネントが Caching Proxy と共にインストールされている場合、 HTTP および HTTPS 要求を URL または管理者が決定したその他の特性に基づいて分散することも可能になります。これにより、すべてのバックエンド・サーバーに同一のコンテンツを保管する必要がなくなります。 Dispatcher コンポーネントも HTTP 要求についての同じ機能を提供できます。

ロード・バランシングを使用すると、コンテンツ・サーバーが透過的にクラスター化されるため、 Web サイトの可用性とスケーラビリティーが向上します。コンテンツ・サーバーには、HTTP サーバー、アプリケーション・サーバー、および代理コンテンツ・サーバーであるプロキシー・サーバーが含まれます。並列性、ロード・バランシング、およびフェイルオーバー・サポートによって、可用性が向上します。サーバーがダウンしても、取引は妨げられません。バックエンド処理能力を透過的に追加できることによって、インフラストラクチャーのスケーラビリティーは非常に向上します。

IPv6 のサポート: IPv6 の拡張 IP アドレッシング方式のサポートは、「Load Balancer for IPv4 and IPv6」で使用可能です。Load Balancer for IPv4 and IPv6 は、Dispatcher コンポーネントのみ で構成される別々のインストール・イメージです。このインストール・タイプは、Dispatcher の MAC ベース・パケット転送を使用するネットワーク内部に構成されたサーバーに対して IPv4 および IPv6 トラフィック両方のロード・バランシングを提供します。Load Balancer for IPv4 and IPv6 をインストールする前に、以前の Load Balancer はアンインストールしておく必要があることに注意してください。2 つの Load Balancer を同じマシンにインストールすることはできません。(Dispatcher コンポーネントの簡単な概要については、Dispatcher を参照してください。

Load Balancer には以下のコンポーネントが組み込まれています。

Dispatcher

HTTP、FTP、HTTPS、および Telnet のようなすべてのインターネット・サービスの場合、Dispatcher コンポーネントは、ローカル・エリア・ネットワーク (LAN) または広域ネットワーク (WAN) 内のサーバーでロード・バランシングを実行します。 HTTP サービスの場合、Dispatcher はサーバーのロード・バランシングをクライアント要求の URL コンテンツに基づいて実行できます。

Dispatcher コンポーネントを使用すると、大規模でスケーラブルなサーバーのネットワークを継続的かつ効率よく管理できます。 Dispatcher を使用して多くの個々のサーバーをリンクし、単一の仮想サーバーとして扱うことができます。したがって、サイトは単一の IP アドレスとして表示されます。

Load Balancer for IPv4 and IPv6 インストールを使用している場合は、WebSphere Application Server Load Balancer 管理ガイド の「Load Balancer for IPv4 and IPv6 に Dispatcher をデプロイする」の章を参照してください。そこには制限と構成の相違に関する情報も含まれます。

Content Based Routing

HTTP および HTTPS サービスの場合、Content Based Routing コンポーネントは、クライアント要求のコンテンツに基づいたサーバーのロード・バランシングを実行します。Content Based Routing コンポーネントは、Application Server Caching Proxy コンポーネントと共に機能します。

重要: Content Based Routing (CBR) コンポーネントは、以下の例外はありますが、すべてのサポートされるプラットフォームで使用可能です。

Site Selector

Site Selector コンポーネントは、ロード・バランシング・システムをネットワークの POP (Point-of-Presence) ノードとして機能させ、 DNS 名を IP アドレスにマップすることによって着信要求のロード・バランシングを可能にすることで、ロード・バランシング・システムの機能を拡張します。 Site Selector は、Metric Server と共に使用すると、サーバー上のアクティビティー・レベルをモニターし、サーバーの負荷がいつ最小になるかを検出し、障害の起きたサーバーを検出することができます。

このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Cisco CSS Controller

Cisco CSS Controller コンポーネントは、サーバー選択、負荷最適化、およびフォールト・トレランスのために Cisco CSS スイッチに送信される、サーバー加重メトリックを生成します。

このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Nortel Alteon Controller

Nortel Alteon Controller コンポーネントは、サーバー選択、負荷最適化、およびフォールト・トレランスのために Nortel Alteon スイッチに送信される、サーバー加重メトリックを生成します。

このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Metric Server

Metric Server コンポーネントは、ロード・バランシングされたサーバーでデーモンとして実行され、Load Balancer コンポーネントにシステム負荷についての情報を提供します。

Edge Components と WebSphere ファミリー

IBM WebSphere ファミリーは、ユーザーによる e-business の可能性の実現を助けることを目的に設計されています。これは、ユーザーによる高性能な Web サイトの開発と管理、および新規または既存の非 Web ビジネス情報システムとの Web サイトの統合に役立つ、一連のソフトウェア製品です。

WebSphere ファミリーは、 Edge Components を含む WebSphere Application Server と、WebSphere Application Server と緊密に統合されてそのパフォーマンスを向上させるその他の WebSphere ファミリー・ソフトウェアで構成されています。 WebSphere Application Server とそのコンポーネントの概説については、WebSphere Application Server Edge components の紹介を参照してください。

Tivoli Access Manager

Tivoli Access Manager (旧 Tivoli Policy Director) は個別に入手可能です。これは、既存の Web アプリケーションのアクセスの制御と集中セキュリティー、および複数の Web リソースへのアクセスでの一回限りの認証機能を提供します。 Caching Proxy プラグインは、プロキシー・サーバーに Access Manager に組み込まれた許可または認証サービスを使用可能にし、Access Manager のセキュリティー・フレームワークを活用します。

WebSphere Portal Server

WebSphere Portal Server (別個に使用可能) は、ポータルに関連した、プレゼンテーション、セキュリティー、スケーラビリティー、および可用性の課題に応えるフレームワークを提供します。 Portal Server を使用すると、企業が従業員、ビジネス・パートナー、および顧客の要求に応えるための、独自のカスタム・ポータル Web サイトを作成することができます。ユーザーは、ポータルにサインオンして、必要な情報、個人、アプリケーションにアクセスできるパーソナライズされた Web ページを受信できます。必要なすべてのリソースへのこのパーソナライズされた単一アクセス・ポイントは、情報の過負荷を削減し、生産性を上げ、Web サイトの使用量を増やします。

WebSphere Portal Server は WebSphere Application Server クラスター内で実行され、スケーラビリティーと信頼性を実現します。さらに、ロード・バランシングとハイ・アベイラビリティーを向上させるために、Application Server Load Balancer コンポーネントも使用できます。

WebSphere Site Analyzer

WebSphere Site Analyzer (別個に使用可能) を使用すると、企業は容量とパフォーマンスの問題を予測しやすくなります。 Site Analyzer があると、Caching Proxy および Load Balancer ログと、その他の管理容易化機能を使用して、Web サイトの使用率をモニターし、分析し、報告させることで、追加リソースがどれだけ必要になるかを予測することができます。さらに、Site Analyzer 管理容易化コンポーネントは、Edge Components のインストールとアップグレード、構成の管理と保管、リモートでの Edge Components の操作、およびイベントの表示と報告を行うユーザーに役立ちます。

WebSphere Transcoding Publisher

WebSphere Transcoding Publisher (別個に使用可能) は、インターネットに接続できる電話などのモバイル装置で表示するための Web ページの変換、ユーザーの希望する各国語への Web コンテンツの翻訳 (WebSphere Translation Server を起動)、マークアップ言語の変換を行うことができます。 Transcoding Publisher は、Caching Proxy の能力を拡張して、コンテンツをさまざまなデバイスとユーザーに提供可能にします。 Web サーバーからのコンテンツへのアクセス後に、Caching Proxy の Transmogrify インターフェースを構成して、 Transcoding Publisher を起動してデータを変換し、バリアント・キャッシングおよび可能な再利用のためのタグを付けることができます。次に、Transcoding Publisher は、Caching Proxy の認証後インターフェースで、コンテンツがユーザーとデバイスの要件を満たすかどうかプロキシー・サーバーを検査して、要件を満たすコンテンツが見つかるとプロキシー・サーバーのキャッシュからそのコンテンツを提供します。

Application Server および Edge components の詳細情報

以下の WebSphere Application Server Edge Components 専門資料を、Edge Components Information Center で入手することができます。

その他の WebSphere Application Server 資料は、WebSphere Application Server ライブラリー・ページから入手できます。

Edge Components に関する技術サポート情報は、WebSphere Application Server サポート・ページから入手できます。

以下に、Edge Components の情報またはその関連情報を入手するための Web サイトを挙げます。

Edge コンポーネントの概念および説明

この部では、Edge コンポーネントで使用可能ないくつかの機能について特に詳しく説明します。 Application Server の Caching Proxy コンポーネントの概説については、WebSphere Application Server Edge components の紹介を参照してください。

この部は、以下の章で構成されています。

キャッシング

ネットワーク・パフォーマンス

可用性

Content Based Routing

キャッシング

Caching Proxy のキャッシング機能を使用すると、ネットワーク帯域幅の使用率が最小化され、エンド・ユーザーはより高速で信頼できるサービスを受け取ることができるようになります。これはプロキシー・サーバーがキャッシングを実行して、バックエンド・サーバーとピア・リンクがオフロードされるために実現可能となります。 Caching Proxy は、静的コンテンツと、WebSphere Application Server によって動的に生成されたコンテンツをキャッシュに入れることができます。また、拡張キャッシングを行うために、Caching Proxy は Application Server Load Balancer コンポーネントと連動して機能します。これらのシステムの概要については、WebSphere Application Server Edge components の紹介を参照してください。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Caching Proxy の基本構成

Caching Proxy は、リバース・キャッシング・プロキシー・サーバー (デフォルト構成) のロールで構成することも、フォワード・キャッシング・プロキシー・サーバーのロールで構成することもできます。コンテンツ・ホストで使用されるとき、Caching Proxy は、インターネットと企業のコンテンツ・ホストの間に位置付けられるリバース・キャッシング・プロキシー・サーバーのロールで構成することができます。インターネット・アクセス・プロバイダーで使用される場合は、クライアントとインターネットの間に位置するフォワード・キャッシング・プロキシー・サーバーのロールで Caching Proxy を構成することができます。

リバース・キャッシング・プロキシー (デフォルト構成)

リバース・プロキシー構成を使用する際、Caching Proxy マシンは、インターネットと企業のコンテンツ・ホストとの間に位置付けられます。プロキシー・サーバーは代理として機能し、インターネットから到着したユーザー要求をインターセプトして、それを該当するコンテンツ・ホストに転送し、戻りデータをキャッシュに入れてから、そのデータをインターネット経由でユーザーに引き渡します。このプロセスでキャッシングを行うことにより、Caching Proxy は以後同じコンテンツが要求されたときにその要求をキャッシュから直接処理することができるため、改めてコンテンツ・ホストから検索するよりはるかに迅速に処理できます。情報は、その有効期限、キャッシュのサイズ、および情報の更新時期にしたがってキャッシュに入れることが可能です。キャッシュ・ヒットをより高速にダウンロードできるということは、カスタマーにとっては、サービスの品質がよりよいということになります。図 1 はこの基本 Caching Proxy 機能を示しています。

図 1. リバース・プロキシーとして機能する Caching Proxy
この図は基本リバース・プロキシー構成を表します
凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Caching Proxy   5--キャッシュ   6--コンテンツ・ホスト

この構成において、プロキシー・サーバー (4) は、URL にコンテンツ・ホストのホスト名 (6) が含まれている要求をインターセプトします。クライアント (1) がファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通過してその企業の内部ネットワークに入ります。プロキシー・サーバーは、要求をインターセプトし、自分自身の IP アドレスを発信アドレスとして持つ新規要求を生成して、その新規要求をコンテンツ・ホスト (6) に送信します。

コンテンツ・ホストは、ファイル X を、エンド・ユーザーに直接戻さないでプロキシー・サーバーに戻します。ファイルがキャッシュ可能なら、Caching Proxy はファイルをエンド・ユーザーに引き渡す前にキャッシュ (5) にコピーを保管します。キャッシュ可能コンテンツの 最もわかりやすい例は静的 Web ページです。ただし、Caching Proxy にも、WebSphere Application Server によって動的に生成されたコンテンツをキャッシュに入れて、処理する機能があります。

フォワード Caching Proxy

エンド・ユーザーへ直接インターネット・アクセスを提供することは、非常に非効率になる可能性があります。 Web サーバーから所定のファイルを取り出すすべてのユーザーは、たとえそのファイルを変更していないとしても、そのファイルを取り出した最初のユーザーとして、ネットワークおよびインターネット・ゲートウェイにおいて同量のトラフィックを生成していることになります。これに対する解決策は、ゲートウェイの近くにフォワード Caching Proxy をインストールすることです。

フォワード・プロキシー構成を使用する際、Caching Proxy マシンは、クライアントとインターネットとの間に位置付けられます。 Caching Proxy はクライアントの要求を、インターネットにあるコンテンツ・ホストに転送し、取り出したデータをキャッシュに入れ、そのデータをクライアントに配布します。

図 2. フォワード・プロキシーとして機能する Caching Proxy
この図は基本フォワード・プロキシー構成を表します

図 2 は、フォワード Caching Proxy 構成を表しています。クライアントのブラウザー・プログラム (1 というマークの付いたマシン上のプログラム) は、フォワード・キャッシング・プロキシー (2) に要求を送るように構成され、フォワード・キャッシング・プロキシーは要求をインターセプトするように構成されます。コンテンツ・ホスト (6) に保管されているファイル X をエンド・ユーザーが要求すると、フォワード・キャッシング・プロキシーはその要求をインターセプトし、起点アドレスとして自身の IP アドレスを使用して新規の要求を生成し、インターネット (5) で企業のルーター (4) を使って新規の要求を送信します。

このようにして、起点サーバーはファイル X を、エンド・ユーザーに直接戻さずに、フォワード・キャッシング・プロキシーに戻します。フォワード Caching Proxy のキャッシング・フィーチャーが有効になっている場合、Caching Proxy は、その戻りヘッダーの設定値 (例えば、有効期限、およびそのファイルが動的に生成されたかどうかについての指示) をチェックして、ファイル X がキャッシングに適格であるかどうかを判断します。ファイルがキャッシュ可能である場合、Caching Proxy は、そのキャッシュ (3) にファイルのコピーを保管してから、ファイルをエンド・ユーザーに引き渡します。デフォルトでは、キャッシングが有効の設定であり、フォワード Caching Proxy はメモリー・キャッシュを使用します。ただし、ユーザーは他のタイプのキャッシングを構成することもできます。

ファイル X に対する最初の要求では、フォワード Caching Proxy によって、インターネットへのアクセスの効率はそれほど向上しません。実際、ファイル X にアクセスする最初のユーザーに対する応答時間は、フォワード Caching Proxy なしの場合よりもおそらく、遅くなります。これはフォワード Caching Proxy が、元の要求パケットを処理し、ファイル X を受け取ったときにそのヘッダーでキャッシュ可能性に関する情報について調べるのに長く時間がかかるためです。フォワード・キャッシング・プロキシー使用の利点が生ずるのは、後で他のユーザーがファイル X を要求したときです。フォワード Caching Proxy は、ファイル X のキャッシュに入れたコピーがまだ有効である (期限切れでない) ことをチェックし、有効である場合は、インターネットでコンテンツ・ホストに要求を転送することなく、キャッシュから直接ファイル X を供給します。

フォワード Caching Proxy は、要求ファイルの有効期限が切れていることを発見したときでも、必ずしもコンテンツ・ホストからファイルを再フェッチする必要はありません。代わりに、特別な状況検査メッセージをコンテンツ・ホストに送信します。ファイルが変更されていないとコンテンツ・ホストが示した場合でも、フォワード・キャッシング・プロキシーは、キャッシュに入れたバージョンを要求ユーザーに引き渡すことができます。

フォワード Caching Proxy をこのように構成することを、フォワード・プロキシーという用語で表しています。これは、Caching Proxy がブラウザーに代って機能し、要求をインターネット経由でコンテンツ・ホストに転送するからです。キャッシングでのフォワード・プロキシーの利点は次の 2 点です。

Caching Proxy は、いくつかのネットワーク転送プロトコルをプロキシーできます。プロキシー可能なプロトコルには、HTTP (Hypertext Transfer Protocol)、FTP (File Transfer Protocol)、および Gopher があります。

透過フォワード Caching Proxy (Linux システムのみ)

フォワード Caching Proxy のバリエーションとして、透過 Caching Proxy があります。Caching Proxy はこのロールでは、基本のフォワード Caching Proxy と同じ機能を実行しますが、機能は、その存在をクライアントに認識されることなく実行されます。透過 Caching Proxy 構成は、Linux システムでのみサポートされています。

フォワード Caching Proxyで説明した構成では、各クライアント・ブラウザーはそれぞれ個別に、特定のフォワード Caching Proxy に要求を送信するように構成されます。 このような構成を維持することは、クライアント・マシンが多数ある場合には、とりわけ不都合なものになる可能性があります。 Caching Proxy では、管理を単純化するいくつかの代替手段をサポートしています。 1 つの可能性として挙げられるのは、図 3 に表すような透過プロキシーのために Caching Proxy を構成する方法です。 通常のフォワード Caching Proxy と同様、透過 Caching Proxy は、ゲートウェイ近くのマシンにインストールしますが、クライアント・ブラウザー・プログラムは、フォワード Caching Proxy に要求を送信するようには構成されません。クライアントは、構成にプロキシーが存在することを認識しません。代わりに、クライアント要求をインターセプトし、それらの要求を透過 Caching Proxy に送信するように、ルーターが構成されます。 1 というマークの付いたマシンのうちの 1 台で動作するクライアントが、コンテンツ・ホスト (6) に保管されているファイル X を要求すると、ルーター (2) はその要求を Caching Proxy に受け渡します。 Caching Proxy は起点アドレスとして自身の IP アドレスを使用して新規の要求を生成し、インターネット (5) でルーター (2) を介して新規の要求を送信します。 ファイル X が到着すると、Caching Proxy はそのファイルを適宜 (フォワード Caching Proxyで説明した条件に応じて) キャッシュに入れ、ファイルを要求クライアントに受け渡します。

図 3. 透過フォワード・プロキシーとして機能する Caching Proxy
この図は基本フォワード・プロキシー構成を表します

HTTP 要求の場合、各ブラウザーでのプロキシー構成情報の保守に代わる、別の考えられる手法は、いくつかのブラウザー・プログラムで使用可能な自動プロキシー構成フィーチャーを使用することです。このフィーチャーが使用可能なブラウザー・プログラムとしては、Netscape Navigator バージョン 2.0 およびそれ以降のバージョン、Microsoft Internet Explorer バージョン 4.0 およびそれ以降のバージョンがあります。この場合、1 つ以上の中央プロキシー自動構成 (PAC) ファイルを作成し、ローカルのプロキシー構成情報ではなく、それらのファイルのいずれか 1 つを参照するようにブラウザーを構成することができます。ブラウザーは自動的に、PAC への変更を認識し、適宜、そのプロキシーの使用量を調整します。これによって、各ブラウザーに個別の構成情報を保守する必要がなくなるだけでなく、プロキシー・サーバーが使用不可になったときに要求を転送することも容易になります。

3 つ目の代替手法は、一部のブラウザー・プログラム (Internet Explorer バージョン 5.0 以降) で使用可能な、Web Proxy Auto Discovery (WPAD) メカニズムを使用することです。このフィーチャーをブラウザーで使用可能にすると、このフィーチャーはそのネットワーク内で自動的に WPAD 準拠のプロキシー・サーバーを探し出し、その Web 要求をそこに送信します。この場合、ユーザーが中央プロキシー構成ファイルを保守する必要はありません。 Caching Proxy は、WPAD 準拠です。

拡張キャッシング

ロード・バランスされた Caching Proxy クラスター

より高度なキャッシング機能を利用するには、Load Balancer コンポーネントとともに、リバース・プロキシーとして Caching Proxy を使用します。キャッシング機能とロード・バランシング機能を統合することによって、能率的で非常に扱いやすい Web パフォーマンス・インフラストラクチャーを作成できます。

図 4 は、Caching Proxyを Load Balancer と結合して、大量要求の状況でも Web コンテンツを効率的に引き渡せる方法を描いたものです。この構成では、プロキシー・サーバー (4) は、Load Balancer (6) によってロード・バランシングされているコンテンツ・ホスト (7) のクラスターのホスト名がその URL に含まれている要求をインターセプトするように構成されます。

図 4. ロード・バランスの対象となる クラスターのプロキシー・サーバーとして機能する Caching Proxy
この図は、ロード・バランスの対象となるクラスターの 代理として機能するプロキシー・サーバーを示します
凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Caching Proxy   5--キャッシュ   6--Load Balancer   7--コンテンツ・ホスト

クライアント (1) がファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通過してその企業の内部ネットワークに入ります。プロキシー・サーバーは、要求をインターセプトし、自分自身の IP アドレスを発信アドレスとして持つ新規要求を生成して、その新規要求をクラスター・アドレスの Load Balancer に送信します。Load Balancer はそのロード・バランシングのアルゴリズムを使用して、ファイル X に関する要求を満たすのに現在どのコンテンツ・ホストが最も適しているかを判断します。そのコンテンツ・ホストは、Load Balancer を通じてではなく、ファイル X をプロキシー・サーバーに戻します。プロキシー・サーバーは、ファイルをキャッシュするかどうかを判断し、前に説明したのと同じ方法でエンド・ユーザーに引き渡します。

動的コンテンツのキャッシュ

Caching Proxy の Dynamic Caching プラグインも、拡張キャッシング機能を提供します。 WebSphere Application Server とともに使用すると、Caching Proxy は、WebSphere Application Server によって生成された JavaServer Pages (JSP) およびサーブレット応答という形式の動的コンテンツをキャッシュ、処理、および無効化できます。

時間に基づく標準的なキャッシュ有効期限ロジックでは、有効期限が無期限に設定されている動的コンテンツは適切な状況で必ず除去されるとは限らないため、一般にこのようなコンテンツは「キャッシュに入れない」とマークする必要があります。 Dynamic Caching プラグインのイベント・ドリブン有効期限ロジックを使用すると、プロキシー・サーバーによって無期限の有効期限を持つコンテンツをキャッシュに入れることができます。このようなコンテンツがネットワークの端にある場合、これをキャッシュに入れると、コンテンツ・ホストがクライアントからの要求を満たすためにアプリケーション・サーバーを繰り返し起動する必要がなくなります。これには次のような利点があります。

アプリケーション・ロジックまたはデータベースからのメッセージなどのイベントに基づいて有効期限が切れる、動的に生成された Web ページの場合、サーブレット応答キャッシングが理想的です。このようなページの存続時間は限定されていますが、有効期限トリガーを前もって認識することはできないので、作成時に存続時間値を設定することは不可能です。このようなページの存続時間をゼロに設定すると、コンテンツ・ホストは、動的コンテンツの処理時に大きなペナルティーを被ります。

Caching Proxy および Application Server の動的キャッシュの同期化は、両方のシステムによって履行されます。例えば、現在の天気予報を提供するアプリケーションによって動的に作成された公開 Web ページを、Application Server でエクスポートして、 Caching Proxy でキャッシュに入れることができます。これで、Caching Proxy は、このページが無効になったことを通知されるまで、アプリケーションの実行結果を多くの別のユーザーに繰り返し供給できます。キャッシュが輻輳しているか、Caching Proxy の構成ファイル内の ExternalCacheManager ディレクティブによって設定されたデフォルト・タイムアウトの有効期限が切れたか、またはキャッシュからコンテンツをパージするように指示する無効化 (Invalidate) メッセージを Caching Proxy が受け取った、という理由でプロキシー・サーバーが項目を除去するまで、Caching Proxy のサーブレット応答キャッシュ内のコンテンツは有効です。 Invalidate 無効化 (Invalidate) メッセージはコンテンツを所有する WebSphere Application Server で生成され、構成された各 Caching Proxy に伝搬されます。

注:
一般に、動的に生成されたプライベート・ページ (ユーザーのショッピング・カートの内容を表示するページなど) は Caching Proxy によってキャッシュに入れることはできず、また入れられないようになっています。意図されたユーザーにのみ供給されることを保証するために認証および許可を行うようにプライベート・ページが構成されているときにのみ、 Caching Proxy はそのプライベート・ページをキャッシュに入れて、処理することができます。

その他のキャッシング機能

Caching Proxy は、その他にも以下の重要な拡張キャッシング機能を提供します。

ネットワーク・パフォーマンス

Caching Proxy 機能の導入はネットワーク・パフォーマンスに影響を与えます。ネットワークのパフォーマンスを向上させるには、Caching Proxy を単独で使用するか、または Load Balancer と共に使用してください。これらのシステムの概要については、WebSphere Application Server Edge components の紹介を参照してください。

企業内の Caching Proxy のパフォーマンスは、実行されるハードウェアと、導入されるシステムの全体的なアーキテクチャーによって決まります。ネットワーク・パフォーマンスを最適化するには、ハードウェアおよび全体的なネットワーク・アーキテクチャーをプロキシー・サーバーの特性に合わせてください。

Caching Proxy ソフトウェアの基本構成と管理、およびオペレーティング・システム・レベルでのチューニングも、Caching Proxy のパフォーマンスの向上に大きく貢献します。パフォーマンスを向上させるために、多くのソフトウェア構成を変更できます。これには、ロギング・ディレクティブ、マッピング・ルール、プラグイン、タイムアウト値、キャッシュ構成値、およびアクティブ・スレッド値の調整が含まれますが、これらに限定されるものではありません。 Caching Proxy ソフトウェア構成の詳細については、Caching Proxy 管理ガイド を参照してください。

パフォーマンスを向上させるために、多くのオペレーティング・システム構成を変更することもできます。これには、TCP と ARP のチューニング、ファイル記述子制限の増加、システム・クロックの同期化、ネットワーク・インターフェース・カード (NIC) のチューニング、およびシステム管理タスクを実行するときに有効な一般的方法に従うことが含まれますが、これらに限定されるものではありません。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

ネットワーク・ハードウェア

このセクションでは、ネットワークに Caching Proxy 機能を導入するときに考慮するべきネットワーク・ハードウェアの問題について説明します。

メモリーに関する考慮事項

プロキシー・サーバーは大量のメモリーを占有します。大規模なメモリー専用キャッシュが構成されると、Caching Proxy が 2 GB の仮想アドレス・スペースを消費することがあります。メモリーは、カーネル、共用ライブラリー、およびネットワーク・バッファーのためにも必要になります。このため、プロキシー・サーバーが 3 または 4 GB の物理メモリーを消費する可能性があります。メモリー専用キャッシュはロー・ディスク・キャッシュに比べて著しく高速であり、この変更のみがパフォーマンスを向上させると見なすことができることに注意してください。

ハード・ディスクに関する考慮事項

Caching Proxy がインストールされているマシンに大きなディスク・スペースを確保することは重要です。これは特にディスク・キャッシュを使用する場合に重要になります。ハード・ディスクからの読み込みと書き込みは、コンピューターを集中的に使用するプロセスです。 Caching Proxy の入出力プロシージャーは効率的ですが、Caching Proxy がディスク・キャッシュを使用する構成になっていると、ハード・ディスクの機械的な制限が原因でパフォーマンスが制限される可能性があります。ディスク入出力のボトルネックは、ロー・キャッシュ・デバイスおよびログ・ファイル用に複数のハード・ディスクを使用したり、シーク・タイム、回転速度、転送速度が高速であるディスク・ドライブを使用したりするなどの操作によって軽減できます。

ネットワークに関する考慮事項

速度、タイプ、および NIC の数などのネットワーク要件、およびプロキシー・サーバーへのネットワーク接続の速度は、Caching Proxy のパフォーマンスに影響を与えます。一般的に、1 つのプロキシー・サーバー・マシンで、着信トラフィック用と発信トラフィック用の 2 つの NIC を使用すると、パフォーマンスが最適化されます。単一の NIC では、HTTP 要求とそれに対する応答トラフィックだけで、限界に達してしまう可能性があります。さらに、NIC は少なくとも 100 MB でなければならず、常に全二重オペレーション用に構成される必要があります。これは、ルーティング装置とスイッチング装置の間の自動折衝によって、エラーが発生したりスループットが犠牲になったりする可能性があるためです。最後に、ネットワーク接続の速度は非常に重要です。例えば、Caching Proxy マシンへの接続が、飽和状態の T1 キャリアである場合、高い要求負荷に対応して最適なスループットを達成することは期待できません。

CPU に関する考慮事項

Caching Proxy マシンの中央演算処理装置 (CPU) は、パフォーマンスを制限する原因になる可能性があります。 CPU の能力は要求を処理する時間に影響を与え、ネットワーク内の CPU の数はスケーラビリティーに影響を与えます。プロキシー・サーバーの CPU 要件を環境に合わせること、特に、プロキシー・サーバーが処理するピーク要求負荷をシミュレーションすることは重要です。

ネットワーク・アーキテクチャー

一般に、全体的なパフォーマンスのためには、個々のハードウェアを追加するだけではなく、アーキテクチャーを調整することが得策です。単一のマシンにハードウェアをいくつ追加するとしても、そのハードウェアにはパフォーマンスの最大レベルが存在します。

このセクションでは、ネットワークに Caching Proxy 機能を導入するときに考慮するべきネットワーク・アーキテクチャーの問題について説明します。

Web サイトの人気とプロキシー・サーバーの負荷に関する考慮事項

企業の Web サイトに人気がある場合、単一のプロキシー・サーバーによって有効に処理できる量を超える要求がコンテンツに対して寄せられて、応答時間が長くなることがあります。ネットワーク・パフォーマンスを最適化するには、クラスター化されてロード・バランシングが行われる Caching Proxy マシンを組み込むか、またはネットワーク・アーキテクチャー全体で、リモート・キャッシュ・アクセス (RCA) を使用する共用キャッシュ・アーキテクチャーを使用することを考慮してください。

トラフィック・タイプに関する考慮事項

パフォーマンスは、主に Caching Proxy のキャッシング能力によって向上します。ただし、プロキシー・サーバーのキャッシュは、正しく構成されていない場合にボトルネックになる可能性があります。最良のキャッシュ構成を判別するには、トラフィックの特性の分析に力を注がなければなりません。コンテンツのタイプ、サイズ、量、および属性は、起点サーバーから文書を取り出すための時間とサーバーにかかる負荷の点で、プロキシー・サーバーのパフォーマンスに影響を与えます。 Caching Proxy がプロキシーとなるかキャッシュから提供するトラフィックのタイプを判別すれば、プロキシー・サーバーを構成するときにそれらの特性を考慮に入れることができます。例えば、キャッシュに入れられるオブジェクトの 80% がイメージ (*.gif または *.jpg) であり、そのサイズが約 200 KB であることが判別できれば、キャッシング・パラメーターのチューニングとキャッシュのサイズの決定に間違いなく役立ちます。さらに、コンテンツの多くがキャッシングの対象ではないパーソナライズされた動的ページであることの判別も、Caching Proxy のチューニングに直接関連します。

トラフィック特性の分析を行うと、メモリー・キャッシュとディスク・キャッシュのどちらを使用するとキャッシュのパフォーマンスを最適化できるかを判別することができます。また、ネットワークのトラフィック特性に精通すると、Caching Proxy の動的キャッシング機能の使用によってパフォーマンスが向上するかどうかの判別が可能になります。

可用性

Application Server Load Balancer コンポーネントは、WebSphere Application Server などのコンテンツ・ホスト、または Application Server Caching Proxy コンポーネントとともに機能して、ネットワークの可用性およびスケーラビリティーを向上させます。 (これらの Edge Components の概要については、WebSphere Application Server Edge components の紹介を参照してください。) Load Balancer は企業ネットワークで使用され、インターネットと企業のバックエンド・サーバーとの間にインストールされます。大量の要求に応えるためまたは大量のコンテンツを扱うために企業で複数のバックエンド・サーバーを使用している場合にも、Load Balancer はインターネットにおける企業の単一の POP (Point-of-Presence) として働きます。

可用性はロード・バランシングとフェイルオーバー・サポートによって実現されます。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

ロード・バランシング

ロード・バランシングは、プロキシー・サーバーとアプリケーション・サーバーを透過的にクラスター化することによって、Web サイトの可用性およびスケーラビリティーを向上させます。バックエンド処理能力は透過的に追加することができるため、 IT インフラストラクチャーのスケーラビリティーがかなり向上されます。

複数のコンテンツ・ホストのロード・バランシング

複数のホストにコンテンツの複製を置いて大量の要求を満たすことはできますが、その場合はそれらホスト間のロード・バランシングを取る方法が必要です。ドメイン・ネーム・サービス (DNS) は基本的なラウンドロビン・ロード・バランシングを提供できますが、これがうまく実行できない場合もあります。

複数のコンテンツ・ホストのロード・バランシングのための高度なソリューションの 1 つとして、 図 5 に示す Load Balancer の Dispatcher コンポーネントを使用する方法があります。この構成では、すべてのコンテンツ・ホスト (5 の番号の付いたマシン) に同じコンテンツが保管されます。これらのホストはロード・バランシングが行われる クラスター を形成するものとして定義され、 Load Balancer マシン (4) のネットワーク・インターフェースのいずれかにそのクラスター専用のホスト名および IP アドレスが割り当てられます。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。 URL は Dispatcher のホスト名および IP アドレスにマップされているため、Dispatcher は、要求をインターセプトします。 Dispatcher は、現在クラスターの中のどのコンテンツ・ホストが要求に応えるために最も適しているかを判断し、要求をそのコンテンツ・ホストに転送します。 MAC 転送方式が構成されていると、このコンテンツ・ホストはファイル X を直接クライアントに戻します (つまり、ファイル X は Load Balancer を通りません)。

図 5. 複数のコンテンツ・ホストのロード・バランシング
この図は複数のコンテンツ・ホストのロード・バランシングを描いたものです

凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Dispatcher   5--コンテンツ・ホスト

注:
Dispatcher は、以下の 3 つの転送方式を提供します。

デフォルトでは、Dispatcher は DNS のようにラウンドロビン・ロード・バランシングを使用しますが、その場合でも DNS の欠点の多くが解消されます。 Dispatcher は、DNS と異なり、コンテンツ・ホストが使用不可またはアクセス不能かどうかを追跡しているため、使用不能なコンテンツ・ホストにクライアントを送り込むことがありません。また、Dispatcher は、新しい接続、活動状態の接続、終了した接続を追跡し、コンテンツ・ホストの現在の負荷を考慮します。 Load Balancer の advisor および manager コンポーネントを活動化すると、ロード・バランシングをさらに最適化することができます。これらのオプショナル・コンポーネントは、コンテンツ・ホストの状況をさらに正確に追跡して、ロード・バランシング決定プロセスに追加情報を取り入れます。 manager を使用すると、決定プロセスで使用される各種の要因に異なる重みを割り当てて、ロード・バランシングをサイトに合わせてさらにカスタマイズすることができます。

複数のリバース・プロキシー・サーバーのロード・バランシング

Load Balancer の Dispatcher は、複数の Caching Proxy マシンに対してロード・バランシングを行うこともできます。企業の Web サイトが有名である場合、単一のプロキシー・サーバーでは効果的に満足させることができないほど大量の要求がサイトのコンテンツに寄せられることがあり、プロキシー・サーバーのパフォーマンスを潜在的に低下させることがあります。

複数の Caching Proxy システムで単一のコンテンツ・ホストのためのプロキシー機能を実行することができますが (図 1 に示した構成のように)、複数のプロキシー・サーバーが必要なほどサイトへのアクセスが多い場合は、Load Balancer によってそのロード・バランスを取る複数のコンテンツ・ホストが必要になります。図 6 にこの構成が示されています。 4 の番号の付いた Dispatcher は 2 つのプロキシー・サーバー (5) のクラスターのロード・バランスを取り、7 の番号の付いた Dispatcher は 3 つのコンテンツ・ホスト (8) のクラスターのロード・バランスを取ります。

図 6. 複数のリバース・プロキシー・サーバーおよびコンテンツ・ホストのロード・バランシング
この図は複数の プロキシー・サーバー およびコンテンツ・ホストのロード・バランシングを描いたものです

凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Dispatcher   5--プロキシー・サーバー   6--キャッシュ   7--Dispatcher   8--コンテンツ・ホスト

4 の番号の付いた Dispatcher のクラスター・ホスト名は、企業の Web コンテンツの URL に出現するホスト名です (つまり、インターネットで表示される Web サイトの名前です)。 7 の番号の付いた Dispatcher のクラスター・ホスト名は、インターネットでは表示されないので、任意の値にすることができます。例えば、ABC Corporation という会社の場合、4 の番号の付いた Dispatcher のホスト名には www.abc.com が適切ですが、7 の番号の付いた Dispatcher には http-balancer.abc.com などの名前を付けることができます。

1 の番号の付いたクライアント・マシンの 1 つのブラウザーから、8 の番号の付いたコンテンツ・サーバーに保管されているファイル X にアクセスする必要があるとします。HTTP 要求はインターネット (2) を経由してゲートウェイ (3) から企業の内部ネットワークに入ります。ルーターは、4 の番号の付いた Dispatcher に要求を送り、これはロード・バランシング・アルゴリズムに従って、現在その要求の処理に最も適しているプロキシー・サーバー (5) に要求を渡します。プロキシー・サーバーのキャッシュ (6) にファイル X が入っている場合は、Caching Proxy は 4 の番号の付いた Dispatcher をバイパスして、ファイルを直接ブラウザーに戻します。

プロキシー・サーバーのキャッシュにファイル X が入っていない場合は、Caching Proxy はヘッダーの起点フィールドに自分のホスト名を入れた新しい要求を作成して、7 の番号の付いた Dispatcher に送信します。 Load Balancer は、現在要求を満たすのに最も適したコンテンツ・ホスト (8) を判断し、そのコンテンツ・ホストに要求を送ります。コンテンツ・ホストはストレージからファイル X を検索し、7 の番号の付いた Dispatcher をバイパスして直接プロキシー・サーバーに戻します。プロキシー・サーバーは、適切な場合はファイル X をキャッシュに入れ、4 の番号の付いた Dispatcher をバイパスしてブラウザーに転送します。

複数のフォワード・プロキシー・サーバーのある Load Balancer

インターネット・アクセスを多数のクライアントに提供すると、インターネット・アクセスの要求が大量に発生し、単一のプロキシーで効率よく要求に対処できなくなる可能性があります。 Caching Proxy が要求で過負荷になると、クライアントへの応答時間はおそらく、直接のインターネット・アクセスよりも遅くなります。また、Caching Proxy が、障害が起こした場合や、ネットワーク障害が原因でアクセス不能になったりした場合、インターネット・アクセスが不可能になります。これに対する解決策は、複数の Caching Proxy マシンをインストールし、それらのマシンの間の負荷のバランスをとるために Load Balancer の Dispatcher を使用することです。

Dispatcher を使用しないで複数の Caching Proxy マシンで真の透過プロキシーを実現できるのは、ご使用のルーターが、複数の Caching Proxy に同一タイプのトラフィックをルーティングすることが可能な場合に限定されます。ただし、すべてのルーターでこれがサポートされるわけではありません。Dispatcher なしで、複数の Caching Proxy マシン上で通常のフォワード・プロキシー・サービスを提供することは可能ですが、 Caching Proxy マシンのうちの 1 台を 1 次プロキシーとして使用するように、クライアント・ブラウザーを明示的に構成する必要があります。その Caching Proxy に障害が起こった場合や、過負荷またはアクセス不能になった場合は、エンド・ユーザーがインターネットにアクセスできなくなる可能性があります。そのような状態を発生するのを回避するため、プロキシー自動構成 (PAC) ファイル (説明は、透過フォワード Caching Proxy (Linux システムのみ)にあります) を作成することができます。このファイルは、ブラウザーが 1 つ以上の 2 次キャッシング・プロキシーにフェイルオーバーするように指示します。 PAC ファイルは、Caching Proxy マシン間の負荷のバランスを取るものではありません。ただし、1 つの Caching Proxy が別の Caching Proxy よりも多くの要求を受信した場合、そのパフォーマンスは、そのブラウザー・クライアントへの応答時間が遅くなるため、低下する可能性があります。すべてのクライアントで同様のパフォーマンスが得られるようにするには、それぞれの Caching Proxy がほぼ同数のブラウザーによって使用されるように構成し、また配分の追跡は手動で行うようにして、ブラウザーを追加または除去する際に負荷が均等になるようにしなければなりません。

図 7 は、 Dispatcher が Caching Proxy マシンのクラスターをロード・バランシングするネットワーク構成を表しています。 Dispatcher マシンのネットワーク・インターフェースの 1 つが、クラスターの占有ホスト名および IP アドレスを持つように構成されています。クライアント・ブラウザーは、それらのインターネット要求をクラスター・ホスト名に送信するように構成されます。たとえば、1 というマークの付いたクライアント・マシンのうちの 1 台にあるブラウザーが、コンテンツ・ホスト (7) 上のファイル X にアクセスする必要があるとき、ブラウザーはその要求をクラスターのホスト名またはアドレスに送信します。そこで、Dispatcher (2) は要求をインターセプトし、要求を適切な Caching Proxy (3) に送信します。Caching Proxy は新規の要求を作成し、それを企業のゲートウェイ (5) およびインターネット (6) 経由で受け渡し、また該当する場合は、戻されたファイルを、そのキャッシュ (4) (詳細は、フォワード Caching Proxyで説明します) に保管します。

注:
透過プロキシー・フィーチャーは、Linux システムでのみ使用可能です。
図 7. 複数のキャッシング・プロキシーをロード・バランシングするための Dispatcher の使用。
この図は複数のプロキシーのロード・バランシングを表します

Dispatcher は、Caching Proxy マシンのうち 1 台が使用不可になるとそれを検出し、自動的に要求を他のマシンに送付します。これにより、インターネット・アクセスを中断することなく、保守のために Caching Proxy マシンをシャットダウンすることができます。 Dispatcher には、数多くの構成オプションがあり、これを使用することによりロード・バランシング決定の際に考慮される要因を制御することができます。また、補助の Dispatcher プログラムを Caching Proxy マシンにインストールして、それらの状況をモニターし、その情報を Dispatcher に戻すこともできます。 詳細については、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。 複数の Caching Proxy を使用することにより、効率性が損なわれる可能性があります。これは、異なるクライアントが異なる Caching Proxy マシンからファイルを要求した場合に、複数の Caching Proxy が同じファイルをキャッシュに入れることがあるためです。このような冗長性を除去するには、リモート・キャッシュ・アクセス (RCA) を構成することができます。これは、定義済みのグループのすべてのプロキシーが、それらのキャッシュのコンテンツを相互にシェアできるようにするものです。 RCA グループのプロキシーはすべて、同じアルゴリズムを使用して、所定の URL に対してどの Caching Proxy が担当するのかを判別します。 Caching Proxy は、担当ではない URL をインターセプトした場合、その担当の Caching Proxy に要求を受け渡します。 担当の Caching Proxy は、要求を満たすために必要な処理を実行します。キャッシュから取り出すか、または、関係のあるコンテンツ・ホストに要求を転送して、戻されたファイルを適宜キャッシュに入れるかします。次に、担当の Caching Proxy はファイルを元の Caching Proxy に受け渡し、元の Caching Proxy はそれを要求エンド・ユーザーへ引き渡します。

RCA グループでは、特定の URL を担当する Caching Proxy が障害を起こした場合、 (クライアント要求を受け取った) 元の Caching Proxy は直接、コンテンツ・ホスト (または、定義されていれば、バックアップ Caching Proxy サーバー) にアクセスします。このことは、 RCA グループ内の少なくとも 1 つの Caching Proxy が正しく機能しているかぎり、ユーザーがファイルにアクセスできることを意味します。

この構成は、複数の Caching Proxy マシン間での要求のロードのバランスをとるために Dispatcher を使用することで、インターネット・アクセスに対する高い要求を満たします。潜在的な問題が 1 つあります。それは、Dispatcher が single point of failure であることです。ディスパッチャーに障害が起こった場合や、ネットワーク障害によりアクセス不能になった場合、ブラウザー・クライアントは、 Caching Proxy にもインターネットにも到達できません。これに対する解決策は、1 次 Dispatcher のバックアップとして動作する別の Dispatcher を構成することです。この構成は、図 8 に表されているとおりです。

図 8. 高可用性のインターネット・アクセスを提供するための 1 次およびバックアップ Dispatcher の使用。
この図は、複数のプロキシーのロード・バランスを取るための 1 次およびバックアップ Dispatcher を表しています

1 のマークの付いたマシンの 1 つで稼働しているブラウザーは通常、ファイル X が要求されると、1 次 Dispatcher (2) にその要求を送ります。 1 次 Dispatcher は、Dispatcher のロード・バランシング基準を基にして選択した Caching Proxy (4) に、その要求を送付します。 Caching Proxy は新規の要求を作成し、それを企業のゲートウェイ (6) 経由でインターネット (7) によりコンテンツ・ホスト (8) に送付し、また該当する場合は、戻されたファイル X を、そのキャッシュ (5) に保管します (このプロセス部分についての詳細な説明は、フォワード Caching Proxyを参照してください)。

この構成では、バックアップ Dispatcher (3) は、1 次ディスパッチャーが作動可能である限り、ロード・バランシングを実行しません。1 次 Dispatcher とバックアップ Dispatcher は、ハートビートと呼ばれるメッセージを定期的に交換して、互いに相手の状況を追跡します。バックアップ Dispatcher は、1 次 Dispatcher の障害を検出すると、 1 次 Dispatcher のホスト名と IP アドレスに送られた要求をインターセプトして、ロード・バランシングの任務を自動的に引き継ぎます。また、2 つの Dispatcher を相互高可用性のために構成することもできます。この場合、2 つの Dispatcher はそれぞれ別々のキャッシング・プロキシー・クラスターのロード・バランシングをアクティブに実行し、同時に相手のバックアップとしても働きます。詳細については、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。

Dispatcher は一般に大量の処理リソースまたはメモリー・リソースを消費しないので、Dispatcher マシンで他のアプリケーションを実行することができます。設備費を最小限に抑えることが重要な場合は、 Caching Proxy と同じマシンでバックアップ Dispatcher を実行することもできます。そのような構成を示したのが、図 9 です。この場合、バックアップ Dispatcher は、Caching Proxy と同じマシン (3) で実行されます。

図 9. Caching Proxy マシンにバックアップ Dispatcher を配置する。
この図は、複数のプロキシーのロード・バランスを取るための 1 次およびバックアップ Dispatcher を表しています

フェイルオーバー・サポート

Load Balancer は、企業のコンテンツ・ホストの単一の POP (point-of-presence) として機能します。この利点は、各コンテンツ・ホストのホスト名およびアドレスではなく、クラスターのホスト名およびアドレスを DNS に公示することで、企業の Web サイトに、不測の事態に対する一定レベルの保護と統一された外観が備わるということです。さらに Web サイトの可用性を高めるには、図 10 に示すように、 1 次 Load Balancer のバックアップとして機能するように別の Load Balancer を構成します。一方の Load Balancer に障害が起こった場合、またはネットワーク障害によりアクセス不能になった場合でも、エンド・ユーザーはコンテンツ・ホストに到達できます。

図 10. Web コンテンツを高可用にするための 1 次およびバックアップ Load Balancer の使用
この図は Web コンテンツを高可用にするための 1 次およびバックアップ Dispatcher の使用を描いたものです

凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--1 次Dispatcher   5--バックアップ Dispatcher   6--コンテンツ・ホスト

通常の場合、1 の番号の付いたマシンの 1 つで稼働しているブラウザーは、ファイル X が要求されると、1 次 Load Balancer (4) に対応付けられているクラスター・ホスト名にその要求を送ります。 Dispatcher は、Dispatcher のロード・バランシング基準を基に選択されたコンテンツ・ホスト (6) へ要求の経路を定めます。コンテンツ・ホストは、企業のゲートウェイ (3) を通してインターネット (2) 経由でファイル X をブラウザーに直接 (Load Balancer をバイパスして) 送信します。

1 次 Dispatcher が作動可能である限り、バックアップ Dispatcher (5) はロード・バランシングを実行しません。1 次 Dispatcher とバックアップ Dispatcher はハートビートと呼ばれるメッセージを定期的に交換して、互いに相手の状況を追跡します。バックアップ Dispatcher は、1 次 Dispatcher の障害を検出すると、 1 次 Dispatcher のクラスター・ホスト名と IP アドレスに送られた要求をインターセプトして、ロード・バランシングの任務を自動的に引き継ぎます。

また、2 つの Dispatcher を相互高可用性のために構成することもできます。この場合、2 つの Dispatcher はそれぞれ別々のコンテンツ・ホスト・クラスターのロード・バランシングをアクティブに実行し、同時に相手のバックアップとしても働きます。(Load Balancer for IPv4 and IPv6 インストールでは、単純な高可用性がサポートされていますが、相互高可用性はサポートされていません。)

Dispatcher は一般に大量の処理リソースまたはメモリー・リソースを消費しないので、Load Balancer マシンで他のアプリケーションを実行することができます。設備費を最小限に抑えることが重要な場合は、ロード・バランシングの対象となるクラスター内のマシンの 1 つでバックアップ Dispatcher を実行することもできます。そのような構成を示したのが図 11 です。この場合、バックアップ Dispatcher はクラスター内のコンテンツ・ホストの 1 つ (5) で実行されます。

図 11. コンテンツ・ホストへのバックアップ Load Balancer の配置
この図はコンテンツ・ホストで実行中のバックアップ Dispatcher を描いたものです

凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--1 次 Dispatcher   5--バックアップ Dispatcher およびコンテンツ・ホスト   6--コンテンツ・ホスト

Content Based Routing

重要: Content Based Routing (CBR) コンポーネントは、以下の例外はありますが、すべてのサポートされるプラットフォームで使用可能です。

Application Server Load Balancer コンポーネントは Application Server Caching Proxy コンポーネントとともに機能して、さまざまなコンテンツのホストとして機能する複数のバックエンド・サーバーに要求を配布できるようにします。 (これらの Edge Components の概要については、WebSphere Application Server Edge components の紹介を参照してください。)

Load Balancer の Content Based Routing (CBR) コンポーネントを Caching Proxy とともにインストールすると、 URL または管理者が決定したその他の特性を基に HTTP 要求を分散することができ、同一のコンテンツをすべてのバックエンド・サーバーに保管する必要がなくなります。

CBR は、Web サーバーで複数の異なる機能の実行または複数の異なるタイプのサービスの提供が必要な場合にとくに適しています。例えば、オンライン小売業の Web サイトでは、カタログの表示と受注の両方を行う必要があります。カタログの大部分は静的ですが、受注では Common Gateway Interface (CGI) スクリプトなどの対話式アプリケーションを実行して品目番号や顧客情報を受け入れる必要があります。別々の 2 セットのマシンに異なる機能を実行させ、CBR を使用して異なるタイプのトラフィックを別々のマシンに経路指定する方法により効率が改善される場合がよくあります。また、購買要求をより強力な Web サーバーに経路指定して、Web サイトの偶発的な訪問者よりも、購買意欲のある顧客に対するサービスを優先するように、CBR を使用することもできます。

CBR は、ユーザーが作成したルールを基にして要求を経路指定します。最も一般的なタイプは コンテンツ・ルール で、このルールは URL のパス名に基づいて要求を送ります。 例えば、ABC Corporation という会社の場合、URL http://www.abc.com/catalog_index.html への要求をあるサーバーのクラスターに送り、http://www.abc.com/orders.html への要求を別のクラスターに送るように、ルールを作成することができます。また、要求を送信したクライアントの IP アドレスまたはその他の特性に基づいて要求を経路指定するルールもあります。詳しい説明は、WebSphere Application Server Load Balancer 管理ガイド の CBR の構成に関する章および Load Balancer と CBR の拡張機能に関する章を参照してください。ルールの構文定義については、「WebSphere Application Server Load Balancer 管理ガイド」の CBR ルール・タイプに関する付録を参照してください。

図 12 に示すものは単純な構成の 1 つです。この構成では、Load Balancer の CBR コンポーネントと Caching Proxy が共に 4 の番号の付いたマシンにインストールされ、異なるコンテンツを保管する 3 つのコンテンツ・ホスト (678) に要求を経路指定します。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。プロキシー・サーバーは要求をインターセプトし、同じマシン上の CBR コンポーネントに渡します。 CBR は要求の中の URL を解析して、ファイル X がコンテンツ・ホスト 6 にあると判断します。プロキシー・サーバーはファイル X に関する新しい要求を生成し、キャッシング機能が使用可能になっている場合は、ホスト 6 がファイルを戻したときにそのファイルがキャッシュに適格であるかどうかを判断します。ファイルがキャッシュ可能なら、プロキシー・サーバーはファイルをエンド・ユーザーに引き渡す前にキャッシュ (5) にコピーを保管します。他のファイルの経路指定もこれと同様に行われます。ファイル Y に関する要求はコンテンツ・ホスト 7 に送られ、ファイル Z に関する要求はコンテンツ・ホスト 8 に送られます。

図 12. CBR による HTTP 要求の経路指定
この図は CBR による HTTP 要求の経路指定を描いたものです
凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Caching Proxy および Load Balancer の CBR コンポーネント   5--キャッシュ   6、7、8--コンテンツ・ホスト

図 13 に、オンライン小売業に適していると考えられるより複雑な構成を示します。 Load Balancer の CBR コンポーネントとプロキシー・サーバーは、共に 4 の番号の付いたマシンにインストールされ、要求を 2 つの Load Balancer マシンに経路指定します。 6 の番号が付いた Load Balancer は、主として小売業者のカタログの静的コンテンツを保管するコンテンツ・ホスト (8) のクラスターのロード・バランシングを取り、7 の番号の付いた Load Balancer は、受注を処理する Web サーバー (9) のクラスターのロード・バランスを取ります。

1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーが小売業者のカタログの URL にアクセスすると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。プロキシー・サーバーは要求をインターセプトし、同じマシン上の CBR コンポーネントに渡します。CBR は URL を解析して、6 の番号の付いた Load Balancer が URL を処理すると判断します。プロキシー・サーバーは新しいアクセス要求を作成して Load Balancer に送信します。Dispatcher は (ユーザー定義の基準を基にして)、8 の番号の付いたコンテンツ・ホストのうち、どのホストが現在最もよく要求にサービスを提供できるかを判断します。このコンテンツ・ホストは Load Balancer をバイパスして、カタログ・コンテンツをプロキシー・サーバーに直接引き渡します。前の例の場合と同様、プロキシー・サーバーは、コンテンツがキャッシュ保管の対象であるかどうかを判断し、該当する場合はそのコンテンツをキャッシュ (5) に保管します。

通常はカタログのハイパーリンクを経由して小売業者の注文 URL にアクセスすることによって、エンド・ユーザーは発注します。この要求がたどるパスは、マシン 4 の CBR コンポーネントにより 7 の番号の付いた Load Balancer マシンに送られる点を除けば、カタログ・アクセスの要求の場合と同じです。 Load Balancer は 9 の番号の付いた Web サーバーのうち最も適したものに要求を転送し、その Web サーバーはプロキシー・サーバーに直接応答します。通常、注文情報は動的に生成されるので、プロキシー・サーバーが注文情報をキャッシュに入れることはありません。

図 13. CBR により経路指定された HTTP 要求のロード・バランシング
この図は CBR により経路指定された HTTP 要求のロード・バランシングを描いたものです

凡例: 1--クライアント   2--インターネット   3--ルーター/ゲートウェイ   4--Caching Proxy および Load Balancer の CBR コンポーネント   5--キャッシュ   6、7--Load Balancer   8--コンテンツ・ホスト   9--Web サーバー

Load Balancer の CBR 機能は cookie 類縁性 をサポートします。これは、エンド・ユーザーの最初の要求にサービスを提供するサーバーの識別が、サーバーの応答に含まれる特殊なデータ・パケット (cookie) に記録されるということです。定義した期間内にエンド・ユーザーが同じ URL に再びアクセスすると、要求に cookie が含まれている場合 CBR は標準ルールを適用する代わりに要求を元のサーバーに経路指定します。一般に、サーバーが再び取得する必要のないエンド・ユーザー情報 (クレジット・カード番号など) がサーバーに保管されている場合、cookie により応答時間が改善されます。

シナリオ

この部では、IBM WebSphere Application Server Edge components を使用するビジネス・シナリオについて説明します。これらは、アーキテクチャーについて安全なテスト済みのソリューションであり、優れたパフォーマンス、可用性、スケーラビリティー、および信頼性を提供するものです。

この部は、以下の章で構成されています。

企業消費者間ネットワーク

企業クライアント間バンキング・ソリューション

Web ポータル・ネットワーク

企業消費者間ネットワーク

基本的なエレクトロニック・コマース Web サイトは、企業消費者間ネットワークです。一般的に、企業がインターネットに進出する最初のフェーズでは、Web 上にサイトを作ることにのみに焦点が置かれます。企業情報と商品カタログがディジタル形式に変換され、Web サイトで表示可能になります。ショッピングは電子メール・アドレス、電話番号、および FAX 番号の提供によって可能になり、さらに、自動化されたフォームによっても可能になります。しかし、本当のオンライン・ショッピングを行うことはできません。注文の処理に人的な作業を必要とするため、すべてのトランザクションに必ず待ち時間が伴います。

2 番目のフェーズでは、企業は直接オンライン購入用のセキュア・ショッピング・カートをインプリメントすることによって、この待ち時間を取り除き、販売操作を能率的にします。これらの販売トランザクションを完全なものにするには、ウェアハウス・データベースとの同期化を図り、バンキング・システムとの統合が非常に重要になります。在庫のない商品は販売できず、その品目について顧客の会計に課金することはできません。同様に、有効な会計上のトランザクションが発生するまで、在庫の商品を取り出して顧客に配送することはできません。

3 番目のフェーズでは、企業の Web サイトはさらに進化し、顧客はクライアントへと発展し、各クライアントにはそれぞれ固有のコンテンツが示される、動的なプレゼンテーション・サイトへと発展します。

次のシナリオには、Load Balancer および Caching Proxy の両方が含まれています。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

フェーズ 1

図 14 は、効率のよいカタログのブラウズを目的に設計された小さな商用 Web サイトを示しています。すべてのクライアント要求はファイアウォールを経由して Dispatcher へとパススルーして、 Web サーバーの代理サーバーとして働く、アクティブ・キャッシュを使用するプロキシー・サーバーのクラスターに経路指定されます。 Metric Server がプロキシー・サーバーと同じ場所に配置されて、Dispatcher にロード・バランシング・データを提供します。この配置は、Web サーバーにかかるネットワーク負荷を軽減し、インターネットとの直接的接触から Web サーバーを切り離します。

図 14. 企業消費者間ネットワーク (フェーズ 1)
この図は基本の企業消費者間ネットワークの例を示しています

フェーズ 2

図 15 は、商用 Web サイトの発展の 2 番目のフェーズを示しています。このサイトは、効率的なカタログのブラウズおよび潜在的な顧客に高速なセキュア・ショッピング・カートを提供することを目的に設計されています。すべての顧客の要求は、インターネット・プロトコルに基づいて要求を分離する Dispatcher によって、ネットワーク内の該当するブランチに経路指定されます。 HTTP 要求は静的 Web サイトに移動します。 HTTPS 要求はショッピング・ネットワークに移動します。基本の静的 Web サイトはこのフェーズでも、Web サーバーの代理として機能するアクティブ・キャッシュを持つプロキシー・サーバーのクラスターによって処理されます。ネットワークのこの部分は、最初のフェーズのネットワークを反映しています。

Web サイトのエレクトロニック・コマースの部分も、プロキシー・サーバーのクラスターによって処理されます。ただし、Caching Proxy ノードはいくつかのプラグイン・モジュールによって拡張されています。 SSL ハンドシェークは暗号ハードウェア・カードにオフロードされ、認証は Access Manager (旧 Policy Director) プラグインを通じて実行されます。動的キャッシング・プラグインは、共通データを保管して WebSphere アプリケーション・サーバー上のワークロードを削減します。アプリケーション・サーバー上のプラグインは、必要であれば動的キャッシングのオブジェクトを無効にします。

すべてのショッピング・カート・アプリケーションはユーザーの認証に使用された顧客データベースに結合されています。これにより、ユーザーが個人情報を認証に 1 回、ショッピングに 1 回の計 2 回システムに入力しないで済むようになります。

このネットワークは、クライアントの使用法に応じてトラフィックを分割し、基本 Web サイトからプロセッサー集中の SSL 認証およびエレクトロニック・コマース・ショッピング・カートを切り離します。この二重トラック Web サイトにより、ネットワーク内のサーバーの役割に基づいて優れたパフォーマンスを提供するようにさまざまなサーバーを調整できます。

図 15. 企業消費者間ネットワーク (フェーズ 2)
この図は企業消費者間ネットワークの例を示しています

フェーズ 3

図 16 は、企業消費者間ネットワークの発展の 3 番目のフェーズを示しています。ここでは、静的 Web に動的プレゼンテーション・メソッドが取り入れられています。プロキシー・サーバー・クラスターが拡張されて、動的 Web コンテンツのキャッシングと、Edge Side Includes (ESI) プロトコルに準拠して作成されたページ・フラグメントのアセンブリーをサポートしています。サーバー側インクルード機構を使用して、コンテンツ・サーバー上に Web ページを作成してから、これらのクライアント固有の、キャッシュ不可能なページをネットワーク全体に伝搬するのとは違い、ESI 機構はキャッシュに入れられたコンテンツからネットワークのエッジでページをアセンブルすることを許可し、これによって帯域幅使用量と応答時間を削減します。

この 3 番目のフェーズのシナリオでは ESI 機構が重要になります。このシナリオでは、パーソナライズされたホーム・ページを各クライアントが Web サイトから受信します。これらのページのビルディング・ブロックは、一連の WebSphere Application Servers から検索されます。機密ビジネス・ロジックと、セキュア・データベースへのタイを含むアプリケーション・サーバーは、ファイアウォールの後ろで分離されています。

図 16. 企業消費者間ネットワーク (フェーズ 3)
この図は企業消費者間ネットワークの例を示しています

企業クライアント間バンキング・ソリューション

図 17 は、企業消費者間ネットワークに説明されている企業消費者間ネットワークに類似した、効率的なオンライン・バンキング・ソリューションを示しています。すべてのクライアント要求はファイアウォールを抜けて Dispatcher へとパススルーし、 Dispatcher はトラフィックをインターネット・プロトコルに基づいて分離します。 HTTP 要求は、Web サーバーの代理サーバーとして働く、アクティブ・キャッシュを使用するプロキシー・サーバーのクラスターに移動します。 Metric Server はプロキシー・サーバーと同じ場所に配置されて、 Dispatcher にロード・バランシング・データを提供します。この配置により、Web サーバーにかかるネットワーク負荷が軽減され、 Web サーバーとインターネットの間に追加のバッファーが作成されます。

HTTPS 要求は、クライアントに個人会計情報を提供してオンライン・バンキング・トランザクションを許可するように設計されたセキュア・ネットワークに渡されます。拡張されたプロキシー・サーバーのクラスターにより、サイトにスケーラビリティーが与えられます。これらのプロキシー・サーバーは、動的 Web コンテンツのキャッシングと、Edge Side Includes (ESI) プロトコルに準拠して作成されたページ・フラグメントのアセンブリーをサポートしています。暗号ハードウェア・カードが SSL ハンドシェークを管理しているため、プロキシー・サーバー・ホストで行う必要のある処理が著しく削減されます。また、Access Manager (旧 Policy Director) がクライアント認証を指示します。

アプリケーション・サーバー・クラスターのコレクションは、EJB コンポーネントに含まれるビジネス・ロジックを、サーブレットと JSP ファイルに含まれるプレゼンテーション層から分離することによって、要求の処理を配布します。これらのクラスターのそれぞれが、個別のセッション・サーバーによって管理されます。

次のシナリオには、Load Balancer および Caching Proxy の両方が含まれています。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

図 17. 企業消費者間バンキング・ソリューション
この図は企業消費者間バンキング・ソリューションの例を示しています

Web ポータル・ネットワーク

図 18 は、各クライアントにパーソナライズされたコンテンツを提供するときの大量のトラフィックをサポートすることを目的に設計された Web ポータル・ネットワークを示しています。さまざまなサーバーにかかる処理負荷を最小化するため、ネットワークのどの部分も SSL トラフィックを運びません。ポータルは機密データを送達しないため、セキュリティーは重要な問題ではありません。クライアント ID、パスワード、および設定を含むデータベースが適度に安全で破壊されていないことは重要ですが、この要件は Web サイトの残りの部分のパフォーマンスを損なうものではありません。

すべてのクライアント要求はファイアウォールを介して Dispatcher へとパススルーします。 Dispatcher は、Web サーバーの代理サーバーとして働く、アクティブ・キャッシュを使用するプロキシー・サーバーのクラスター内でネットワーク負荷のバランシングを行います。 Metric Server はプロキシー・サーバーと同じ場所に配置されて、 Dispatcher にロード・バランシング・データを提供します。

実際の動的 Web サイトは、プロキシー・サーバーにアセンブリーのために渡される ESI フラグメントを生成するアプリケーション・サーバーのクラスターです。セキュリティーがそれほど考慮されていないため、Web サイトを構成するために必要なすべての機能を各アプリケーション・サーバーが実行します。すべてのアプリケーション・サーバーは同一です。 1 つのアプリケーション・サーバーのサービスが休止されると、セッション・サーバーが要求を他のサーバーに経路指定して、サイト全体のハイ・アベイラビリティーを保ちます。またこの構成では、ポータルが特殊イベントのホストになるなどして過度のトラフィックが発生した場合に、Web サイトの急速なエスカレーションも可能になります。追加のプロキシー・サーバーとアプリケーション・サーバーを、素早くサイトに構成できます。

イメージ・ファイルおよび定形文面テキストなどのすべての静的コンテンツは、個別の Web サーバーに保管されます。このため、より複雑なアプリケーション・サーバーを破壊してしまうようなリスクを負わずに、必要に応じて更新を行うことができます。

次のシナリオには、Load Balancer および Caching Proxy の両方が含まれています。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

図 18. Web ポータル
この図はサンプル Web ポータルを 描いたものです。

Edge Components のインストール

この部では、Edge Components のインストールについての手順が提供されます。

この部は、以下の章で構成されています。

Edge Components の要件

セットアップ・プログラムを使用した Edge Components のインストール

システム・パッケージ・ツールを使用した Caching Proxy のインストール

システム・パッケージ・ツールを使用した Load Balancer のインストール

Edge Components の要件

このトピックでは、Edge Components のハードウェアとソフトウェアの要件へのリンクを提供し、また Caching Proxy 構成および管理フォームおよび Load Balancer オンライン・ヘルプで Web ブラウザーを使用するためのガイドラインを記載します。

ハードウェアおよびソフトウェアの前提条件

WebSphere Application Server、バージョン 6.1 Edge Components でサポートされるハードウェアおよびソフトウェアの要件については、次の Web ページを参照してください: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

SDK インストール: Java 2 SDK は、すべてのプラットフォームで Load Balancer と一緒に自動的にインストールされます。

Caching Proxy「構成および管理」フォームを使用するブラウザーの使用

ブラウザーの最小要件

「構成および管理」フォームを使用して Caching Proxy を構成するには、ブラウザーは以下のことが可能である必要があります。

Linux および UNIX システムの場合: Mozilla および Firefox の各ブラウザーの推奨バージョンについては、次の Web サイトを参照し、サポートされるソフトウェアについての Web ページへのリンクをたどってください: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

Windows システムの場合: Internet Explorer、 Mozilla、および Firefox の各ブラウザーの推奨バージョンについては、次の Web サイトを参照し、サポートされるソフトウェアについての Web ページへのリンクをたどってください: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

注:
64 ビットの PowerPC Linux システムでは、Mozilla ブラウザーで「構成および管理」フォームにアクセスすることはできません。このアーキテクチャーには使用可能な SDK がないためです。代わりに、サポートされた Web ブラウザーのある別のマシンから「構成および管理」フォームにアクセスすることができます。

制限: 展開エレメントの数が多すぎてブラウザーのウィンドウに表示しきれない場合、管理フォームの左側の垂直スクロール・バーが表示されない場合があります。これにより、リスト下部の展開エレメントがブラウザーの現行表示ウィンドウから押し出され、エレメントにアクセスできなくなります。この問題を解決するには、左側のメニューの展開エレメントの数を制限します。展開エレメントの数が多すぎる場合は、一部のエレメントを縮小表示して、ブラウザーのウィンドウでリスト下部のエレメントが表示されるようにします。

フォームを適切に表示するには、フォームを実際に表示する (ブラウザーが常駐する) オペレーティング・システムに、フォームが書かれた言語に該当するフォント・セットが含まれていなければなりません。ただし、ブラウザー・インターフェースが必ずしもフォームと同じ言語である必要はありません。

例えば、Solaris 9 システムで中国語版のプロキシー・サーバーが実行されているとします。 インターフェースが英語バージョンの Mozilla ブラウザーが、Solaris ホストにロードされています。このブラウザーは、「構成および管理」フォームのローカルな編集に使用できます。(フォームは、プロキシー・サーバーが使用する文字セットでブラウザーに提供されます (この例では中国語)。ただし、プロキシー・サーバーが送信した文字セットを表示するようにブラウザーとその基礎オペレーティング・システムが適切に構成されていない場合、フォームが正しく表示されないことがあります。)

あるいは、中国語をサポートする Windows ワークステーションをプロキシー・サーバーにリモート接続できる場合には、Netscape ブラウザーの中国語版を Windows ワークステーション上にロードし、このブラウザーを使用してフォームに値を入力することが可能です。この 2 番目のソリューションには、管理者に対し一貫した言語インターフェースを維持できる利点があります。

オペレーティング・システムに特有のフォント・セットは、ブラウザー内の各種の言語、特に 2 バイト文字の表示に大きく影響します。例えば、ある中国語フォント・セットは、AIX 上と Windows プラットフォーム上とで、表示が若干異なります。このため、「構成および管理」フォームの中で HTML テキストと Java アプレットの外観に多少の不ぞろいが生じます。最良の外観を得るためにお勧めできるのは、Windows オペレーティング・システムで実行されるブラウザーだけです。

S/390 および PowerPC 上の Mozilla 1.4 ブラウザーに関する注意

Mozilla 1.4 とともにインストールされている Java プラグインは、バージョン 1.4.2 以降に更新する必要があります (管理フォームを適切に表示できるようにするため)。プラグインを更新するには、以下のステップを行います。

  1. http://plugindoc.mozdev.org にアクセスします。
  2. 「文書」セクションでプラットフォームを選択します。
  3. 「Java ランタイム環境」セクションでリストされている説明に従ってプラグインを更新します。

Load Balancer オンライン・ヘルプでのブラウザーの使用

Load Balancer オンライン・ヘルプを使用するには、ブラウザーが以下をサポートしている必要があります。

上記の要件をサポートしていないブラウザーを使用すると、ページのフォーマットに問題が発生したり、機能が正しく動作しない場合があります。

セットアップ・プログラムを使用した Edge Components のインストール

このトピックでは、セットアップ・プログラム を使用して Edge Components をインストールする方法について説明します。

Java 2 SDK は、すべてのプラットフォームで Load Balancer と一緒に自動的にインストールされます。

インストール後に、Caching Proxy パッケージ内のスクリプトが、デフォルトの構成を使用してプロキシー・サーバーを開始しようとします。ポート 80 が (別の Web サーバーなどによって) 使用中の場合、プロキシー・サーバーの開始は失敗します。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

Windows でのセットアップ・プログラムの使用

セットアップ・プログラムを使用して、ご使用の Windows(R) システムに Edge Components をインストールします。手順は、以下のとおりです。

  1. Windows システムがハードウェアおよびソフトウェア要件 (Edge Components の要件) をすべて満たしていることを確認します。
  2. 管理者特権を持つユーザーとしてログインします。
  3. Edge Components の CD-ROM をマシンの CD-ROM ドライブに挿入します。ランチパッドが自動的に開始されます。
  4. WebSphere Application Server - Edge Components のインストール・ウィザードを立ち上げる」をクリックします。セットアップ・プログラムは自動的に開始されます。InstallShield ウィザードが準備され「ようこそ」ウィンドウがオープンします。
    注:
    ご使用のマシンで Autoplay オプションがサポートされない場合や、またはこのオプションがオフになっている場合は、セットアップ・プログラムを手動で開始します。それには、CD-ROM の最上位レベルのディレクトリーにある setup.exe プログラムを実行してください。
  5. 次へ」をクリックしてインストールを続行します。「ソフトウェア・ライセンス契約」ウィンドウがオープンします。
  6. ライセンス契約を読んで「はい」をクリックし、すべての条項を受け入れます。 「コンポーネント選択」ウィンドウがオープンします。

    Edge components がすでにインストールされている場合は、「保守オプション」ウィンドウが開いてから、「コンポーネント選択」ウィンドウが開きます。「変更」ラジオ・ボタンを選択してから「次へ」をクリックします。「コンポーネント選択」ウィンドウがオープンします。

  7. インストールするコンポーネントを選択します。
  8. 所定のコンポーネントでインストールされるサブコンポーネントの選択を変更するには、コンポーネントの名前をクリックしてそれを選択してから、「サブコンポーネントの変更」をクリックします。 活動状態のコンポーネントの別のサブコンポーネントを示す、別の「コンポーネント選択」ウィンドウがオープンします。 インストールするサブコンポーネント、コンポーネントの言語、およびコンポーネントをインストールする場所を選択するには、以上の同じ手順を使用してください。
  9. 現行言語」メニューを使用して、 Edge Components をインストールしたい言語 (1 つまたは複数) を選択します。使用可能な言語がメニューの左側にリストされます。選択された言語がメニューの右側にリストされます。
  10. 「コンポーネント選択」ウィンドウを使用して Edge Components のインストール場所を確認します。デフォルト値を受け入れるか、あるいは「フォルダーの変更」をクリックして新しい場所を指定できます。
    注:
    デフォルト以外のインストール場所を選択する場合、パス名の中にブランク・スペースがないことを確認してください。例えば、 C:¥My Files¥edgeserver¥ のようなパス名は避けてください。
  11. 「コンポーネント選択」ウィンドウを使用して、選択したインストール場所に使用可能なスペースが十分にあることを確認します。選択した場所に使用可能なスペースが十分にない場合、「フォルダーの変更」をクリックして新しいインストール場所を指定します。
  12. Edge Components、インストール場所、および言語を選択したら、「次へ」をクリックします。オープンした「インストールの確認」ウィンドウ内の情報を確認します。1 つ以上の選択を変更するには、「戻る」をクリックして「コンポーネント選択」ウィンドウに戻り、変更を行います。選択項目を確認したら、「終了」をクリックします。
  13. Edge Components 製品セットアップ・プログラムは、選択した Edge Components および GSK (必要な場合) の指定したインストール場所へのインストールを開始します。
  14. 「セットアップ完了」ウィンドウがオープンします。Edge Components README ファイルをお読みになりたい場合は、「はい、README ファイルを表示します」チェック・ボックスが選択されていることを確認します。README ファイルがデフォルト・ブラウザーでオープンされます。
  15. はい、コンピューターを再始動します」チェック・ボックスが選択されていることを確認してから、「終了」をクリックします。README ファイルを表示するように選択した場合、ファイルを表示するブラウザーのウィンドウをクローズするとマシンが再始動されます。選択しなければ、Edge Components 製品セットアップ・プログラムは即時にクローズされてマシンが再始動されます。新たにインストールした Edge Components を使用する前にマシンを再始動する必要があることに注意してください。

制限: ご使用条件のウィンドウではタブ・キーを使用して、「I accept」オプションと「I do not accept」オプションの切り替えを行います。ただし、タブ・キーを使用して、「戻る」、「次へ」、または「取り消し」のナビゲーション・オプションに進むことはできません。次善策として、これらのナビゲーション・オプションに進むには、 Shift+Tab を使用します。また、Enter キーはナビゲーション・ボタンでしか機能しないため、「I accept」または「I do not accept」オプションを選択するときはスペース・バーを使用する必要があります。

Linux および UNIX でのセットアップ・プログラムの使用

CD からインストールしようとする場合、セットアップ・プログラム を使用して、ご使用の Linux および UNIX システムに、以下の手順で Edge Components をインストールすることができます。

  1. コンピューター・サーバーが、Edge Components の要件で説明するハードウェアおよびソフトウェア要件をすべて満たしていることを確認します。
    • Linux システムの場合の追加要件: compat-libstdc++-33 パッケージ (GCC 3.3 C++ 互換性ライブラリーを含む) をインストールする必要があります。
  2. スーパーユーザー (通常は、root) としてログインします。
  3. Edge Components CD-ROM を CD-ROM ドライブに挿入します。必要であれば、 CD-ROM をマウントします。
  4. 作業ディレクトリーを CD-ROM の最上位レベルのディレクトリーに変更します。
  5. 次のコマンドを入力して、セットアップ・プログラムを起動します。
    # ./install
    「ようこそ」ウィンドウがオープンします。
  6. 次へ」をクリックしてインストールを続行します。「ソフトウェア・ライセンス契約」ウィンドウがオープンします。
  7. ライセンス契約を読んで「はい」をクリックし、すべての条項を受け入れます。 「言語選択」ウィンドウがオープンします。
  8. Edge Components の今回のインストールでサポートされる言語を選択します。「次へ」をクリックします。「コンポーネント選択」ウィンドウがオープンします。
  9. インストールするコンポーネントを選択します。
  10. 次へ」をクリックします。 「インストールの確認」ウィンドウがオープンします。
  11. 「インストールの確認」ウィンドウの情報を確認します。1 つまたは複数の選択を変更したい場合、「戻る」をクリックして「コンポーネント選択」ウィンドウに戻り、変更を行います。 選択項目を確認したら、「次へ」をクリックします。

    セットアップ・プログラムは、選択した Edge Components および必須パッケージのインストールを開始します。

  12. 「インストールの結果要約」ウィンドウがオープンします。結果を確認したら、「終了」をクリックします。

制限: ご使用条件のウィンドウではタブ・キーを使用して、「I accept」オプションと「I do not accept」オプションの切り替えを行います。ただし、タブ・キーを使用して、「戻る」、「次へ」、または「取り消し」のナビゲーション・オプションに進むことはできません。次善策として、これらのナビゲーション・オプションに進むには、 Shift+Tab を使用します。また、Enter キーはナビゲーション・ボタンでしか機能しないため、「I accept」または「I do not accept」オプションを選択するときはスペース・バーを使用する必要があります。

Red Hat Linux 3.0 アップデート 3: Edge Components のインストーラー・プログラムの実行中、GUI パネルを最大化してから復元すると、ボタンが動作しなくなります。この問題を解決するには、以下を実行してください。

  1. パネルの右上の隅にある「X」ボタンをクリックしてインストーラー・プログラムを閉じます。
  2. 「Do you want to exit?」という質問に「Yes」と応答します。
  3. パネルのサイズを最大化および復元をしないでインストーラー・プログラムを再開始します。

Linux および UNIX システム: Edge Components をインストールするのにセットアップ・プログラムを使用した場合、GUI アンインストーラーを使用して Edge Components をアンインストールすることができます。ただし、ネイティブ・コマンドを使用してインストールしたリフレッシュ・パックをアンインストールするために、Edge Components の GUI アンインストーラーを使用することはできません。最初にネイティブ・コマンド (オペレーティング・システムのコマンド) を使用してリフレッシュ・パックをアンインストールしてから、GUI アンインストーラーを使用してコンポーネントのアンインストールを行う必要があります。

ネイティブ・コマンドの使用法については、システム・パッケージ・ツールを使用した Caching Proxy のインストールおよび システム・パッケージ・ツールを使用した Load Balancer のインストールを参照してください。

システム・パッケージ・ツールを使用した Caching Proxy のインストール

このトピックでは、システム・パッケージ・ツールを使用して Caching Proxy をインストールする方法について説明します。

インストール後に、Caching Proxy パッケージ内のスクリプトが、デフォルトの構成を使用してプロキシー・サーバーを開始しようとします。ポート 80 が (別の Web サーバーなどによって) 使用中の場合、プロキシー・サーバーの開始は失敗します。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

オペレーティング・システムのパッケージ・インストール・システムを使用して、 表 2 でリストされた順序でパッケージをインストールします。以下の手順には、このタスクを完了するのに必要な通常ステップが示されています。

  1. 必要に応じて、Edge Components の CD を CD-ROM ドライブに挿入し、ドライブをマウントします。
  2. ローカル superuser root になります。
    su - root
    
    Password: password
  3. CD の、適切なディレクトリーに変更します。
    cd mount_point/package_directory/
  4. パッケージをインストールします。

    AIX(R) の場合:

    installp -acXd ./packagename

    HP-UX の場合:

    swinstall -s source/ packagename

    Linux の場合:

    rpm -i ./packagename

    Solaris の場合:

    pkgadd -d ./packagename
表 2. Caching Proxy コンポーネント
コンポーネント インストール・パッケージ (推奨順序)
Caching Proxy
  1. gskit7
  2. icu
  3. admin
  4. msg-cp-lang
  5. cp
Edge Component 資料

doc-en_US1

注:
  1. Load Balancer 資料は、2 つのパッケージで提供されます。doc-en_US パッケージには、Load Balancer 資料を含むすべての Edge Components 資料が組み込まれており、これらは、../edge/doc/ ディレクトリーに配置されます。Load Balancer インストールに関連した資料パッケージ (システム・パッケージ・ツールを使用した Load Balancer のインストール) では、Load Balancer 資料のみがインストールされ、それらは ../edge/lb/ ディレクトリー内のサブディレクトリーに配置されます。
表 3. AIX、HP-UX、 および Solaris パッケージ・ファイル名
総称パッケージ名 AIX ファイル・セット HP-UX ファイル・セット Solaris ファイル名
admin wses_admin.rte WSES-ADMIN WSESadmin
cp wses_cp.base WSES-CP WSEScp
doc wses_doc.en_US WSES-DOC-en_US WSESdocen
gskit7 gskkm.rte gsk7bas gsk7bas
icu wses_icu.rte WSES-ICU WSESicu
msg-cp-lang wses_cp.msg.lang1 .base WSES-cpmlang2 WSEScpmlang3
注:
  1. AIX の場合、変数 lang は、言語固有コード (en_US、de_CH、de_DE、es_ES、fr_CA、 fr_CH、fr_FR、it_CH、it_IT、ja_JP、Ja_JP、ko_KR、pt_BR、zh_CN、ZH_CN、zh_TW、 Zh_TW) のいずれかに置き換えます。
  2. HP-UX の場合、変数 lang は、言語固有コード (de_DE、 en_US、es_ES、fr_FR、it_IT、ja_JP、ko_KR、zh_CN、h_TW) のいずれかに置き換えます。(HP-UX では、ブラジル・ポルトガル語 (pt_BR) はサポートされていません。)
  3. Solaris の場合、変数 lang は、言語固有コード (br、 cn、 cw、 de、 en、 es、 fr、 it、 ja、 kr) のいずれかに置き換えます。
表 4. Linux パッケージ・ファイル名
総称パッケージ名 Linux ファイル名
admin WSES_Admin_Runtime-release-version1.hardw2.rpm
cp WSES_CachingProxy-release-version1.hardw2.rpm
doc WSES_Doc_en_US-release-version1.hardw2.rpm
gskit7 gsk7bas.rpm
icu WSES_ICU_Runtime-release-version1.hardw2.rpm
msg-cp-lang WSES_CachingProxy_msg_lang3-release-version1.hardw2.rpm
注:
  1. release-version は、現行リリースを示します (例えば、6.1.0-0)。
  2. 変数 hardw は、値 i686、s390、ppc64 のいずれかに置き換えられます。
  3. 変数 lang は、言語固有コード (de_DE、en_US、es_ES、fr_FR、it_IT、ja_JP、ko_KR、pt_BR、zh_CN、zh_TW) のいずれかに置き換えられます。

資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html

システム・ツールを使用した Caching Proxy のアンインストール

パッケージをアンインストールするには、以下を行います。

AIX の場合:

installp -u packagename

Caching Proxy パッケージをすべてアンインストールするには、以下のコマンドを使用します。

installp -u wses

HP-UX の場合:

swremove packagename

インストール済みの Caching Proxy パッケージを照会するには、以下のコマンドを使用します。

swlist | grep WSES

パッケージは、インストール時とは逆の順番で除去されます。

Linux の場合:

rpm -e packagename

インストール済みの Caching Proxy パッケージを照会するには、以下のコマンドを使用します。

rpm -qa |grep -i  wses

パッケージは、インストール時とは逆の順番で除去されます。

Solaris の場合:

pkgrm packagename

インストール済みの Caching Proxy パッケージを照会するには、以下のコマンドを使用します。

pkginfo | grep WSES

パッケージは、インストール時とは逆の順番で除去されます。

システム・パッケージ・ツールを使用した Load Balancer のインストール

このトピックでは、AIX、HP-UX、Linux、および Solaris システムへの Load Balancer のインストールについて説明します。

インストールのタイプによっては、以下のセクションにリストされているすべての Load Balancer コンポーネント・パッケージが提供されるとは限りません。

以前のバージョンの Load Balancer からマイグレーションする場合、またはオペレーティング・システムを再インストールする場合は、インストールに先立ち、Load Balancer の既存の構成ファイルやスクリプト・ファイルを保管しておきます。

Load Balancer をインストールした後にマシンからログオフした場合、再度ログオンしたときにすべての Load Balancer サービスを再始動する必要があります。

AIX へのインストール

表 5 は、Load Balancer 用の AIX ファイル・セットと、システムのパッケージ・インストール・ツールを使用して行うインストールの推奨順序をリストしています。

表 5. AIX ファイル・セット
Load Balancer コンポーネント AIX ファイル・セット
ベース ibmlb.base.rte
管理 (メッセージ付き)
  • ibmlb.admin.rte
  • ibmlb.msg.lang.admin
デバイス・ドライバー ibmlb.lb.driver
ライセンス ibmlb.lb.license
Load Balancer コンポーネント (メッセージ付き)
  • ibmlb.component.rte
  • ibmlb.msg.lang.lb
資料 (メッセージ付き)
  • ibmlb.doc.rte
  • ibmlb.msg.en_US.doc
Metric Server ibmlb.ms.rte
注:
  1. 変数 component は次に置き換えることができます。 disp (dispatcher)、 cbr (CBR)、 ss (Site Selector)、 cco (Cisco CSS Controller)、または nal (Nortel Alteon Controller)。
  2. 変数 lang は、次を置き換えることができます: en_US、de_CH、de_DE、es_ES、fr_CA、fr_CH、fr_FR、it_CH、it_IT、 ja_JP、Ja_JP、ko_KR、pt_BR、zh_CN、ZH_CN、zh_TW、Zh_TW

資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html

インストールする前に

AIX への Load Balancer のインストールを行う前に、以下を確認してください。

製品をインストールするとき、以下の一部またはすべてをインストールするためのオプションが提供されます。

インストール手順

SMIT では、すべてのメッセージが自動的にインストールされるため、 SMIT を使用して Load Balancer for AIX をインストールすることをお勧めします。

SMIT を使用した Load Balancer for AIX のインストール

  1. ソフトウェア・インストールおよび保守 (Software Installation and Maintenance)」を選択します。
  2. ソフトウェアのインストール / 更新 (Install and Update Software)」を選択します。
  3. 最新の使用可能なソフトウェアからインストール / アップデート (Install and update from latest Available Software)」を選択します。
  4. ファイル・セットを含むデバイスまたはディレクトリーを入力します。
  5. *インストールするソフトウェア (*SOFTWARE to Install)」フィールドに、オプションを指定するための適切な情報を入力します (または「リスト (List)」を選択します)。
  6. OK」を押します。
  7. コマンドが完了したら、「Done (完了)」を押します。
  8. 終了 (Exit)」メニューの「Smit の終了 (Exit Smit)」を選択するか、または F12 を押して SMIT を終了します。 SMITTY を使用している場合は、F10 を押してプログラムを終了します。

コマンド行からの Load Balancer のインストール

  1. CD からインストールを行う場合は、以下のコマンドを入力して CD をマウントします。
    mkdir /cdrom
    
    mount -v cdrfs -p -r /dev/cd0 /cdrom
  2. 以下の表を参照して、必要な AIX 用 Load Balancer パッケージをインストールするために入力するコマンド (1 つ以上) を判別してください。
    表 6. AIX インストール・コマンド
    パッケージ コマンド
    ベース installp -acXgd device ibmlb.base.rte
    管理 (メッセージ付き) installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin
    デバイス・ドライバー installp -acXgd device ibmlb.lb.driver
    ライセンス installp -acXgd device ibmlb.lb.license
    Load Balancer コンポーネント (メッセージ付き)。次を含む: Dispatcher、 CBR、 Site Selector、 Cisco CSS Controller、および Nortel Alteon Controller

    installp -acXgd device ibmlb.component.rte

    ibmlb.msg.language.lb

    資料 (メッセージ付き) installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb
    Metric Server installp -acXgd device ibmlb.ms.rte
    ここで、device は以下のとおりです。
    • CD からインストールする場合、/cdrom
    • ファイル・システムからインストールする場合、 /dir (ファイル・セットを含むディレクトリー)
  3. インストール (APPLY) する Load Balancer の各パーツについて、要約に示される結果の列に SUCCESS が含まれていることを確認してください。インストールするパーツがすべて正常に適用されない限り、続行しないでください。
    注:
    特定のデバイスについてファイル・セットのリスト (使用可能なすべてのメッセージ・カタログを含む) を生成するには、次を入力します。
    installp -ld device

CD からインストールを行う場合は、以下のコマンドを入力して CD をアンマウントします。

unmount /cdrom

次のコマンドを入力して製品がインストールされたことを検査します。

lslpp -h | grep ibmlb

全製品をインストールした場合、このコマンドは以下を戻します。

ibmlb.base.rte

ibmlb.admin.rte

ibmlb.lb.driver

ibmlb.lb.license

ibmlb.component.rte

ibmlb.doc.rte

ibmlb.ms.rte

ibmlb.msg.language.admin

ibmlb.msg.en_US.doc

ibmlb.msg.language.lb

Load Balancer インストール・パスには、以下が組み込まれています。

HP-UX へのインストール

このセクションでは、製品 CD を使用して、 Load Balancer を HP-UX にインストールする方法について説明します。

インストールする前に

インストール手順を開始する前に、ソフトウェアをインストールする root 権限を持っていることを確認してください。

以前のバージョンをインストールしている場合は、そのバージョンをアンインストールしてから現行バージョンをインストールしてください。まず、executor とサーバーの両方を停止したことを確認してください。次に、Load Balancer アンインストール手順について、パッケージのアンインストール手順を参照してください。

インストール手順

表 7 には、Load Balancer のインストール・パッケージ名のリストと、システムのパッケージ・インストール・ツールを使用してパッケージをインストールする場合の推奨順序を示しています。

表 7. Load Balancer 用の HP-UX パッケージのインストールの詳細
パッケージの説明 HP-UX パッケージ名
ベース ibmlb.base
管理およびメッセージ ibmlb.admin ibmlb.nlv-lang
Load Balancer ライセンス ibmlb.lic
Load Balancer コンポーネント ibmlb.component
資料 ibmlb.doc
Metric Server ibmlb.ms
注:
  1. 変数 lang は、次の言語固有コードの次のいずれか 1 つに置き換えます: de_DE、es_ES、fr_FR、it_IT、 ja_JP、ko_KR、zh_CN、zh_TW。
  2. 変数 component は次のいずれか 1 つに置き換えます: disp (dispatcher)、cbr (CBR)、ss (Site Selector)、cco (Cisco CSS Controller)、または nal (Nortel Alteon Controller)。
  3. 資料パッケージ (ibmlb.doc) には英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html

HP-UX では ブラジル・ポルトガル語 (pt_BR) ロケールはサポートされていません。 HP-UX でサポートされているロケールは、以下のとおりです。

パッケージのインストール手順

以下の手順では、この作業の完了に必要なステップの詳細を示します。

  1. ローカル superuser root になります。
    su - root
    
    Password: password
  2. インストール・コマンドを実行し、パッケージをインストールします。

    インストール・コマンドを発行します。

    swinstall -s /source
    
    package_name

    ここで、source はパッケージの入っているディレクトリー、package_name はパッケージの名前です。

    例えば、 CD のルートからインストールしている場合は、次のコマンドで Load Balancer のベース・パッケージ (ibmlb.base) がインストールされます。

    swinstall -s /source ibmlb.base

    CD のルートからインストールする場合、 Load Balancer のすべてのパッケージをインストールするには、次のコマンドを発行します。

    swinstall -s /source ibmlb
  3. Load Balancer パッケージがインストールされていることを確認します。

    swlist コマンドを実行し、これまでにインストールしたすべてのパッケージをリストします。例えば、

    swlist -l fileset ibmlb
    
    

パッケージのアンインストール手順

swremove コマンドを使用してパッケージをアンインストールできます。パッケージは、最後にインストールしたものから順に除去する必要があります。例えば、次のコマンドを実行します。

Load Balancer インストール・パスには、以下が組み込まれています。

Linux へのインストール

このセクションでは、Edge Components CD を使用して Load Balancer を Linux にインストールする方法について説明します。

インストールする前に

Load Balancer をインストールする前に、以下を確認してください。

インストール・ステップ

  1. Edge Components メディアを挿入するか、Web サイトから製品をダウンロードして、RPM (Red Hat Packaging Manager) を使用してインストール・イメージをインストールします。

    インストール・イメージのファイルは、lblinux- version.tar 形式です。

  2. 次のコマンドを入力して一時ディレクトリーに tar ファイルを展開します。
    tar -xf lblinux-version.tar
    その結果、.rpm 拡張子を持った以下の一連のファイルが生成されます。
    • ibmlb-base-release-version.hardw.rpm (ベース)
    • ibmlb-admin-release-version.hardw.rpm (管理)
    • ibmlb-lic-release-version.hardw.rpm (ライセンス)
    • ibmlb-component-release-version.hardw.rpm (LB コンポーネント)
    • ibmlb-doc-release-version.hardw.rpm (資料)
    • ibmlb-ms-release-version.hardw.rpm (Metric Server)

    ここで、

    • release-version は、現行リリースを示します (例えば、6.1.0-0)。
    • hardw は、次のいずれかの値です: i386、ppc64、ppc、s390、s390x、x86_64
    • component は、disp (Dispatcher コンポーネント)、cbr (CBR コンポーネント)、ss (Site Selector コンポーネント)、cco (Cisco CSS Controller)、または nal (Nortel Alteon Controller) のいずれかの値になります。

    資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html

  3. RPM ファイルがあるディレクトリーから、次のコマンドを実行してそれぞれのパッケージをインストールします。例:
    rpm -i package.rpm

    Red Hat Linux システム: Red Hat Linux の既知の問題があるため、_db* RPM ファイルを削除することが必要になります。削除しないと、エラーが起こります。

    以下の、各コンポーネントに必要なパッケージのリストに示された順序でパッケージをインストールすることが重要です。

    • ベース (base)
    • 管理 (admin)
    • ライセンス (lic)
    • Load Balancer コンポーネント (ds、cbr、ss、cco、nal)
    • Metric Server (ms)
    • 資料 (doc)
    注:
    RPM ファイルのうち、少なくとも 1 つは、 Java(TM) がインストールされていて、RPM データベースに登録済みであることを必要とします。 Java がインストールされていても、RPM データベースに登録されていない場合は、以下のように非依存オプションを指定したインストール・コマンドを使用してください。
    rpm -i --nodeps package.rpm 
  4. 製品がインストールされたことを検査します。次のコマンドを入力します。
    rpm -qa | grep ibmlb

    全製品をインストールした場合、以下が出力されます。

    • ibmlb-base-release-version
    • ibmlb-admin-release-version
    • ibmlb-lic-release-version
    • ibmlb-dsp-release-version
    • ibmlb-cbr-release-version
    • ibmlb-ss-release-version
    • ibmlb-cco-release-version
    • ibmlb-nal-release-version
    • ibmlb-doc-release-version
    • ibmlb-ms-release-version

Load Balancer インストール・パスには、以下が入っています。

パッケージをアンインストールする必要がある場合、パッケージのインストールで使用した順序を逆にして、管理パッケージが最後にアンインストールされるようにします。

Solaris へのインストール

このセクションでは、Edge Components CD を使用して Load Balancer を Solaris にインストールする方法について説明します。

インストールする前に

インストール手順を開始する前に、root としてログインしていること、および前のバージョンの製品はアンインストールされていることを確認してください。

アンインストールを行うには、すべての executor およびサーバーが停止されていることを確認します。次に、次のコマンドを入力します。

pkgrm pkgname

インストール・ステップ

  1. Load Balancer ソフトウェアが収納されている CD-ROM を適切なドライブに挿入します。
  2. コマンド・プロンプトで、次のコマンドを入力します。
    pkgadd -d pathname
    ここで、-d pathname は、CD-ROM ドライブのデバイス名またはこのパッケージが入っているハード・ディスクのディレクトリーです(例: -d /cdrom/cdrom0/)。

    以下は、表示されるパッケージのリストと、インストールする際の推奨順序です。

    • ibmlbbase (ベース)
    • ibmlbadm (管理)
    • ibmlblic (ライセンス)
    • ibmlbdisp (Dispatcher コンポーネント)
    • ibmlbcbr (CBR コンポーネント)
    • ibmlbss (Site Selector コンポーネント)
    • ibmlbcco (Cisco CSS Controller コンポーネント)
    • ibmlbnal (Nortel Alteon Controller コンポーネント)
    • ibmlbdoc (資料)
    • ibmlbms (Metric Server)

    資料パッケージ (ibmlbdoc) には英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html

    すべてのパッケージをインストールしたい場合は、all とだけ入力して Return を押します。いくつかのコンポーネントをインストールしたい場合は、インストールするパッケージに対応する名前をスペースまたはコンマで区切って入力し、Return を押します。既存のディレクトリーまたはファイルに対する許可を変更するように指示されることがあります。 Return を押すか、または yes と応答します。前提条件のパッケージをインストールする必要があります (インストールが、前提条件のパッケージからではなく、パッケージのアルファベット順に行われるため)。 all と入力し、次にすべてのプロンプトに yes と応答した場合、インストールが正常に完了します。

    例えば、Dispatcher コンポーネントのみを資料および Metric Server と一緒にインストールする場合は、ibmlbbase、ibmlbadm、ibmlblic、ibmdisp、ibmlbdoc、および ibmlbms のパッケージをインストールする必要があります。

  3. 製品がインストールされたことを検査します。次のコマンドを実行します。
    pkginfo | grep ibm

Load Balancer インストール・パスには、以下が入っています。

Edge Components を使用したネットワークの構築

この部では、Edge Components を使用して基本デモンストレーション・ネットワークを構築する手順を説明します。これらのネットワークは、実稼働環境での使用を意図していません。ネットワークの最初の構成プロセスによって、この製品を初めて扱う管理者に対して、多くのエッジ・オブ・ネットワークの概念をわかりやすく説明します。すべてのコンポーネント機能の詳細な解説および構成情報については、「Caching Proxy 管理ガイド」および「Load Balancer 管理ガイド」を参照してください。

この手順では、コンポーネントによってサポートされる任意のコンピューター・システムを任意のノードで使用できます。

この部は、以下の章で構成されています。

Caching Proxy ネットワークの構築.

Load Balancer ネットワークの構築.

Caching Proxy ネットワークの構築

図 19 は、 3 つのネットワーク・ノードにある 3 台のコンピューター・システムを使用する基本的なプロキシー・サーバー・ネットワークを示しています。このネットワークは、プロキシー・サーバーをサーバー 2 にある専用コンテンツ・ホスト (IBM HTTP Server) に結合し、プロキシー・サーバーがホストを処理します。これは、インターネットによってワークステーションとサーバー 1 の間に位置するように見えます。

重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。

図 19. Caching Proxy デモンストレーション・ネットワーク
Caching Proxy デモンストレーション・ネットワーク

ワークフロー

Caching Proxy ネットワークを構築するには、以下の順序で手順を実行します。

  1. 必須コンピューター・システムおよびソフトウェアの確認.
  2. サーバー 1 の構築 (Linux および UNIX システム) またはサーバー 1 の構築 (Windows システム)
  3. サーバー 1 の構成.
  4. Caching Proxy ネットワークのテスト.

必須コンピューター・システムおよびソフトウェアの確認

以下のコンピューター・システムおよびソフトウェア・コンポーネントが必要です。

サーバー 1 の構築 (Linux および UNIX システム)

以下のように Caching Proxy をインストールして構成します。

  1. コンピューター・サーバーが、ハードウェアおよびソフトウェア要件をすべて満たしていることを確認します。
  2. スーパーユーザー (通常は、root) としてログインします。
  3. Caching Proxy コンポーネントをインストールします。
  4. 次のコマンドを入力して、「構成および管理」フォームにアクセスするための管理者 ID およびパスワードを作成します。
    # htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd

    プロンプトが出されたら、htadm プログラムに、管理者のユーザー名、パスワード、および実名を指定します。

  5. サーバー 1 の構成を続けます。

サーバー 1 の構築 (Windows システム)

以下のように Caching Proxy をインストールして構成します。

  1. Windows 2000 と Windows 2003 の両オペレーティング・システムが、すべてのハードウェアおよびソフトウェア要件を満たしていることを確認します。
  2. 管理者特権を持つユーザーとしてログインします。
  3. Caching Proxy コンポーネントをインストールします。
  4. 次のコマンドを入力して、「構成および管理」フォームにアクセスするための管理者 ID およびパスワードを作成します。
    cd "Program Files¥IBM¥edge¥cp¥server_root¥protect"
    
    htadm -adduser webadmin.passwd"

    プロンプトが出されたら、htadm プログラムに、管理者のユーザー名、パスワード、および実名を指定します。

  5. サーバー 1 の構成を続けます。

サーバー 1 の構成

ワークステーションから、以下の手順を実行してください。

  1. Web ブラウザーを開始します。
  2. ブラウザーの「アドレス」フィールドに、 http://server_1 を入力します。 server_1 は、サーバー 1 として指定したマシンの実際のホスト名または IP アドレスを指します。
  3. 構成および管理フォーム」をクリックします。
  4. 管理者名およびパスワードを入力します。「構成および管理」フォームがブラウザーでオープンされます。
  5. 「サーバー構成」-->「要求処理」-->「要求経路指定」をクリックします。
  6. 前に挿入」ラジオ・ボタン、および既存のワイルドカード・マッピング・ルールの索引値を選択して、新しいワイルドカード・マッピング・ルールを既存のルールの前に挿入します。
  7. アクション」ドロップダウン・ボックスから「プロキシー」を選択します。
  8. URL 要求テンプレート」フィールドに /* を入力します。
  9. サーバー IP アドレスまたはホスト名」フィールドに、 HTTP 要求を宛先変更するサイトのホスト名を入力します。この値の前に http:// を付けます。
  10. 実行依頼」をクリックします。
  11. 前に挿入」ラジオ・ボタン、およびステップ 6 で作成されたマッピング・ルールの索引値を選択して、「構成および管理」フォームにアクセスできるマッピング・ルールを作成します。
  12. アクション」ドロップダウン・ボックスから「パス」を選択します。
  13. URL 要求テンプレート」フィールドに /pub/* を入力します。
  14. 「構成および管理」フォームの場所を入力します。
    • Caching Proxy が Linux または UNIX マシンにある場合には、/opt/ibm/edge/cp/server_root/pub/en_US/* を「サーバー IP アドレスまたはホスト名」フィールドに入力します。
    • Caching Proxy が Windows マシンにある場合には、"C:¥Program Files¥IBM¥edge¥cp¥server_root¥pub¥en_US¥*" を「サーバー IP アドレスまたはホスト名」フィールドに入力します。
  15. 実行依頼」をクリックします。
  16. 構成フォームの最上部で、「サーバーの再始動」アイコンをクリックします。
  17. Caching Proxy ネットワークのテストを続けます。

Caching Proxy ネットワークのテスト

ワークステーションから、以下の手順を実行してください。

  1. Web ブラウザーを開始します。
  2. ブラウザーの「アドレス」フィールドに http://server_1 を入力します。サーバー 2 からの HTML ページはサーバー 1 を経由してプロキシーに入り、 Web ブラウザーに引き渡されます。
  3. 「構成および管理」フォームにアクセスするには、ブラウザーの「アドレス」フィールドに http://server_1/pub/ を入力します。「構成および管理」フォームのホーム・ページが表示されます。

Load Balancer ネットワークの構築

図 20 は、3 つのローカル接続ワークステーションを持つ基本的な Load Balancer ネットワークを示しています。このネットワークでは、Dispatcher コンポーネントの MAC 転送方式を使用して、Web サーバー間の Web トラフィックのロード・バランスを取っています。構成は、他の任意の TCP またはステートレス UDP アプリケーション・トラフィックのロード・バランスを取る場合と同じです。

図 20. Load Balancer デモンストレーション・ネットワーク
クライアント、インターネットを表す雲の図、 Load Balancer マシン、および 2 つのローカル接続サーバーをアドレスを示して表した図。
注:
ワークステーションを 2 つのみ使用し、Dispatcher を一方の Web サーバー・ワークステーションに配置して、この構成を完了することができます。これは連結構成を表します。

ワークフロー

Load Balancer ネットワークを構築するには、以下の順序で手順を実行します。

  1. 必須コンピューター・システムおよびソフトウェアの確認.
  2. ネットワークの構成.
  3. Dispatcher の構成.
  4. Load Balancer ネットワークのテスト.

必須コンピューター・システムおよびソフトウェアの確認

以下のコンピューター・システムおよびソフトウェア・コンポーネントが必要です。

ネットワークの構成

  1. すべて同じ LAN セグメント上に配置するようにワークステーションをセットアップします。 3 つのマシンの間のネットワーク・トラフィックが、ルーターまたはブリッジを一切通過する必要がないようにします。
  2. 3 つのワークステーションのネットワーク・アダプターを構成します。この例では、以下のネットワーク構成を想定しています。
    ワークステーション 名前 IP アドレス
    1 server1.company.com 9.67.67.101
    2 server2.company.com 9.67.67.102
    3 server3.company.com 9.67.67.103
    ネットマスク = 255.255.255.0
    各ワークステーションには、標準のイーサネット・ネットワーク・インターフェース・カードが 1 つだけ装備されています。
  3. server1.company.com が server2.company.com と server3.company.com の両方を ping できるようにします。
  4. server2.company.com と server3.company.com が server1.company.com を ping できるようにします。
  5. 2 つの Web サーバー (サーバー 2 およびサーバー 3) の上でコンテンツが同じであることを確認します。これを行うには、データを両方のワークステーションに複製するか、あるいは NFS、 AFS(R)、または DFS(TM) などのファイル共用システムを使用します。また、サイトに合ったその他の方法を使用することもできます。
  6. server2.company.com および server3.company.com にある Web サーバーが操作可能であることを確認します。 Web ブラウザーを使用して http://server2.company.com および http://server3.company.com から直接ページを要求します。
  7. この LAN セグメント用に別の有効な IP アドレスを取得します。このアドレスは、サイトにアクセスしたいクライアントに与えるアドレスです。この例では、この情報は次のようになります。
    Name= www.company.com
    
    IP=9.67.67.104  
  8. www.company.com のトラフィックを受け入れるように 2 つの Web サーバー・ワークステーションを構成します。

    server2.company.com および server3.company.com にある ループバック・インターフェースに www.company.com の別名を追加してください。

    • AIX の場合:

      ifconfig lo0 alias www.company.com netmask 255.255.255.0

    • Solaris 7 の場合:

      ifconfig lo0:1 www.company.com 127.0.0.1 up

  9. ループバック・インターフェースの別名割り当ての結果として作成された可能性があるエクストラ経路を削除します。

    これで、2 つの Web サーバー・ワークステーションに必要なすべての構成ステップが完了しました。

Dispatcher の構成

Dispatcher があれば、コマンド行、構成ウィザード、またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。

注:
パラメーター値は、英字で入力する必要があります。例外は、ホスト名およびファイル名のパラメーター値だけです。

コマンド行を使用した構成

コマンド行を使用する場合は、以下のステップに従ってください。

  1. Dispatcher で dsserver を開始します。

    • AIX、Linux、HP-UX、または Solaris の場合は、 dsserver コマンドを root ユーザーとして実行します。
    • Windows プラットフォームの場合、 dsserver はサービスとして実行され、自動的に開始されます。
  2. Dispatcher の executor 機能を開始します。
    dscontrol executor start
  3. クラスター・アドレスを Dispatcher 構成に追加します。
    dscontrol cluster add www.company.com
  4. http プロトコル・ポートを Dispatcher 構成に追加します。
    dscontrol port add www.company.com:80
  5. Web サーバーをそれぞれ Dispatcher 構成に追加します。
    dscontrol server add www.company.com:80:server2.company.com
    dscontrol server add www.company.com:80:server3.company.com
  6. クラスター・アドレスに対するトラフィックを受け入れるようにワークステーションを構成します。
    dscontrol executor configure www.company.com
  7. Dispatcher の manager 機能を開始します。
    dscontrol manager start

    これで、Dispatcher は、サーバー・パフォーマンスに基づいてロード・バランシングを行うようになります。

  8. Dispatcher の advisor 機能を開始します。
    dscontrol advisor start http 80

    これで Dispatcher はクライアント要求が失敗 Web サーバーに送信されないようにします。

ローカル接続サーバーの基本構成はこれで完了です。

重要: Load Balancer for IPv4 and IPv6 インストールでの Dispatcher コマンド (dscontrol) の構文は、1 つの重要な例外をのぞき、同一です。dscontrol コマンドの区切り文字は、コロン (:) ではなく、単価記号 (@) です。(コロン以外の区切り文字を定義することが必要でした。IPv6 形式は、アドレッシング方式内部でコロンを使用するからです。)

例 (以前の Dispatcher 構成例から)

詳しくは、Load Balancer for IPv4 and IPv6 インストールを使用している場合、WebSphere Application Server Load Balancer 管理ガイド 内の、制限および構成の相違に関する情報を含む「Load Balancer for IPv4 and IPv6 に Dispatcher をデプロイする」の章を参照してください。

構成ウィザードを使用した構成

構成ウィザードを使用する場合は、以下のステップに従ってください。

  1. Dispatcher で dsserver を開始します。

    • AIX、HP-UX、Linux、または Solaris の場合、以下のコマンドをルート・ユーザーとして実行します。
      dsserver
    • Windows システムの場合、dsserver はサービスとして実行され、自動的に開始されます。
  2. Dispatcher のウィザード機能 dswizard を開始します。

このウィザードは、Dispatcher コンポーネントの基本構成を作成するプロセスを段階的に案内します。このウィザードはネットワークについての確認を行い、Dispatcher のクラスターのセットアップをガイドします。このクラスターによって、サーバー・グループのトラフィックのロード・バランシングが行われます。

構成ウィザードには、以下のパネルがあります。

グラフィカル・ユーザー・インターフェース (GUI) を使用した構成

GUI を開始するには、以下のステップに従ってください。

  1. dsserver プロセスが実行されていることを確認します。
    • AIX、HP-UX、Linux、または Solaris の場合、以下のコマンドをルートとして実行します。
      dsserver
    • Windows システムの場合、dsserver はサービスとして実行され、自動的に開始されます。
  2. 次に、以下のいずれかを行います。
    • AIX、Linux、HP-UX、または Solaris の場合、lbadmin を入力します。
    • Windows システムの場合、「スタート」>「プログラム」>「IBM WebSphere」>「Edge Components」>「IBM Load Balancer」>「Load Balancer」をクリックします。

Load Balancer ネットワークのテスト

  1. Web ブラウザーから、ロケーション http://www.company.com に移動してページが表示されることを確認します。
  2. このページを Web ブラウザーに再ロードします。
  3. コマンド dscontrol server report www.company.com:80: を実行します。 2 つのサーバーを加算した合計接続数の欄が 2 になることを確認します。

付録および後付け