この版は、以下のプログラムに適用されます。
また、新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。
本マニュアルに関するご意見やご感想は、次の 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
本書 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 の主要なアクセシビリティー機能です。
本書では、以下のような書体およびキー操作の規則を使用しています。
規則 | 意味 |
---|---|
太字 | グラフィカル・ユーザー・インターフェース (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 は、企業間 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 は、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 は、インターネットと企業のバックエンド・サーバーの間にインストールされます。バックエンド・サーバーには、コンテンツ・ホストまたは 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 には以下のコンポーネントが組み込まれています。
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 をデプロイする」の章を参照してください。そこには制限と構成の相違に関する情報も含まれます。
HTTP および HTTPS サービスの場合、Content Based Routing コンポーネントは、クライアント要求のコンテンツに基づいたサーバーのロード・バランシングを実行します。Content Based Routing コンポーネントは、Application Server Caching Proxy コンポーネントと共に機能します。
重要: Content Based Routing (CBR) コンポーネントは、以下の例外はありますが、すべてのサポートされるプラットフォームで使用可能です。
代わりに、このタイプのインストールの場合には、Load Balancer の Dispatcher コンポーネントの cbr 転送方式を使用して、Caching Proxy を使用せずに HTTP および HTTPS 要求の Content Based Routing を提供することができます。詳しくは、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。
Load Balancer for IPv4 and IPv6 は、Dispatcher コンポーネントの mac 転送方式のみをサポートします。nat および cbr 転送方式はサポートされません。
Site Selector コンポーネントは、ロード・バランシング・システムをネットワークの POP (Point-of-Presence) ノードとして機能させ、 DNS 名を IP アドレスにマップすることによって着信要求のロード・バランシングを可能にすることで、ロード・バランシング・システムの機能を拡張します。 Site Selector は、Metric Server と共に使用すると、サーバー上のアクティビティー・レベルをモニターし、サーバーの負荷がいつ最小になるかを検出し、障害の起きたサーバーを検出することができます。
このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
Cisco CSS Controller コンポーネントは、サーバー選択、負荷最適化、およびフォールト・トレランスのために Cisco CSS スイッチに送信される、サーバー加重メトリックを生成します。
このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
Nortel Alteon Controller コンポーネントは、サーバー選択、負荷最適化、およびフォールト・トレランスのために Nortel Alteon スイッチに送信される、サーバー加重メトリックを生成します。
このコンポーネントは、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
Metric Server コンポーネントは、ロード・バランシングされたサーバーでデーモンとして実行され、Load Balancer コンポーネントにシステム負荷についての情報を提供します。
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 Policy Director) は個別に入手可能です。これは、既存の Web アプリケーションのアクセスの制御と集中セキュリティー、および複数の Web リソースへのアクセスでの一回限りの認証機能を提供します。 Caching Proxy プラグインは、プロキシー・サーバーに Access Manager に組み込まれた許可または認証サービスを使用可能にし、Access Manager のセキュリティー・フレームワークを活用します。
WebSphere Portal Server (別個に使用可能) は、ポータルに関連した、プレゼンテーション、セキュリティー、スケーラビリティー、および可用性の課題に応えるフレームワークを提供します。 Portal Server を使用すると、企業が従業員、ビジネス・パートナー、および顧客の要求に応えるための、独自のカスタム・ポータル Web サイトを作成することができます。ユーザーは、ポータルにサインオンして、必要な情報、個人、アプリケーションにアクセスできるパーソナライズされた Web ページを受信できます。必要なすべてのリソースへのこのパーソナライズされた単一アクセス・ポイントは、情報の過負荷を削減し、生産性を上げ、Web サイトの使用量を増やします。
WebSphere Portal Server は WebSphere Application Server クラスター内で実行され、スケーラビリティーと信頼性を実現します。さらに、ロード・バランシングとハイ・アベイラビリティーを向上させるために、Application Server Load Balancer コンポーネントも使用できます。
WebSphere Site Analyzer (別個に使用可能) を使用すると、企業は容量とパフォーマンスの問題を予測しやすくなります。 Site Analyzer があると、Caching Proxy および Load Balancer ログと、その他の管理容易化機能を使用して、Web サイトの使用率をモニターし、分析し、報告させることで、追加リソースがどれだけ必要になるかを予測することができます。さらに、Site Analyzer 管理容易化コンポーネントは、Edge Components のインストールとアップグレード、構成の管理と保管、リモートでの Edge Components の操作、およびイベントの表示と報告を行うユーザーに役立ちます。
WebSphere Transcoding Publisher (別個に使用可能) は、インターネットに接続できる電話などのモバイル装置で表示するための Web ページの変換、ユーザーの希望する各国語への Web コンテンツの翻訳 (WebSphere Translation Server を起動)、マークアップ言語の変換を行うことができます。 Transcoding Publisher は、Caching Proxy の能力を拡張して、コンテンツをさまざまなデバイスとユーザーに提供可能にします。 Web サーバーからのコンテンツへのアクセス後に、Caching Proxy の Transmogrify インターフェースを構成して、 Transcoding Publisher を起動してデータを変換し、バリアント・キャッシングおよび可能な再利用のためのタグを付けることができます。次に、Transcoding Publisher は、Caching Proxy の認証後インターフェースで、コンテンツがユーザーとデバイスの要件を満たすかどうかプロキシー・サーバーを検査して、要件を満たすコンテンツが見つかるとプロキシー・サーバーのキャッシュからそのコンテンツを提供します。
以下の WebSphere Application Server Edge Components 専門資料を、Edge Components Information Center で入手することができます。
その他の WebSphere Application Server 資料は、WebSphere Application Server ライブラリー・ページから入手できます。
Edge Components に関する技術サポート情報は、WebSphere Application Server サポート・ページから入手できます。
以下に、Edge Components の情報またはその関連情報を入手するための Web サイトを挙げます。
この部では、Edge コンポーネントで使用可能ないくつかの機能について特に詳しく説明します。 Application Server の Caching Proxy コンポーネントの概説については、WebSphere Application Server Edge components の紹介を参照してください。
この部は、以下の章で構成されています。
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 は以後同じコンテンツが要求されたときにその要求をキャッシュから直接処理することができるため、改めてコンテンツ・ホストから検索するよりはるかに迅速に処理できます。情報は、その有効期限、キャッシュのサイズ、および情報の更新時期にしたがってキャッシュに入れることが可能です。キャッシュ・ヒットをより高速にダウンロードできるということは、カスタマーにとっては、サービスの品質がよりよいということになります。図 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 によって動的に生成されたコンテンツをキャッシュに入れて、処理する機能があります。
エンド・ユーザーへ直接インターネット・アクセスを提供することは、非常に非効率になる可能性があります。 Web サーバーから所定のファイルを取り出すすべてのユーザーは、たとえそのファイルを変更していないとしても、そのファイルを取り出した最初のユーザーとして、ネットワークおよびインターネット・ゲートウェイにおいて同量のトラフィックを生成していることになります。これに対する解決策は、ゲートウェイの近くにフォワード Caching Proxy をインストールすることです。
フォワード・プロキシー構成を使用する際、Caching Proxy マシンは、クライアントとインターネットとの間に位置付けられます。 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 のバリエーションとして、透過 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で説明した条件に応じて) キャッシュに入れ、ファイルを要求クライアントに受け渡します。
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 準拠です。
より高度なキャッシング機能を利用するには、Load Balancer コンポーネントとともに、リバース・プロキシーとして Caching Proxy を使用します。キャッシング機能とロード・バランシング機能を統合することによって、能率的で非常に扱いやすい Web パフォーマンス・インフラストラクチャーを作成できます。
図 4 は、Caching Proxyを Load Balancer と結合して、大量要求の状況でも Web コンテンツを効率的に引き渡せる方法を描いたものです。この構成では、プロキシー・サーバー (4) は、Load Balancer (6) によってロード・バランシングされているコンテンツ・ホスト (7) のクラスターのホスト名がその URL に含まれている要求をインターセプトするように構成されます。
凡例: 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 を単独で使用するか、または 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 キャリアである場合、高い要求負荷に対応して最適なスループットを達成することは期待できません。
Caching Proxy マシンの中央演算処理装置 (CPU) は、パフォーマンスを制限する原因になる可能性があります。 CPU の能力は要求を処理する時間に影響を与え、ネットワーク内の CPU の数はスケーラビリティーに影響を与えます。プロキシー・サーバーの CPU 要件を環境に合わせること、特に、プロキシー・サーバーが処理するピーク要求負荷をシミュレーションすることは重要です。
一般に、全体的なパフォーマンスのためには、個々のハードウェアを追加するだけではなく、アーキテクチャーを調整することが得策です。単一のマシンにハードウェアをいくつ追加するとしても、そのハードウェアにはパフォーマンスの最大レベルが存在します。
このセクションでは、ネットワークに Caching Proxy 機能を導入するときに考慮するべきネットワーク・アーキテクチャーの問題について説明します。
企業の Web サイトに人気がある場合、単一のプロキシー・サーバーによって有効に処理できる量を超える要求がコンテンツに対して寄せられて、応答時間が長くなることがあります。ネットワーク・パフォーマンスを最適化するには、クラスター化されてロード・バランシングが行われる Caching Proxy マシンを組み込むか、またはネットワーク・アーキテクチャー全体で、リモート・キャッシュ・アクセス (RCA) を使用する共用キャッシュ・アーキテクチャーを使用することを考慮してください。
アーキテクチャーを調整する 1 つの方法として、プロキシー・サーバーをクラスター化して Load Balancer コンポーネントを使用し、負荷のバランスを取ることが挙げられます。プロキシー・サーバーのクラスター化は、パフォーマンスとスケーラビリティーを向上させるためだけではなく冗長度と信頼性の問題を解決する上でも有益な設計上の配慮です。単一のプロキシー・サーバーは Single Point of Failure (SPOF) になります。つまり、これに障害が発生するかネットワーク障害が原因でアクセス不能になった場合、ユーザーは Web サイトにアクセスできなくなります。
RCA を使用した共用キャッシュ・アーキテクチャーの使用も考慮してください。共用キャッシュ・アーキテクチャーでは、全体の仮想キャッシュが複数の Caching Proxy サーバーに広げられ、それらのサーバーでは、通常、ICP (Internet Cache Protocol) または Cache Array Routing Protocol (CARP) などのキャッシュ間プロトコルが使用されます。 RCA は、大規模な仮想キャッシュの提供によって、クラスター化されたキャッシュのヒット率を最大化することを目的に設計されています。
プロキシー・サーバーの RCA 配列を使用すると、単一のスタンドアロン Caching Proxy だけではなくスタンドアロン Caching Proxy マシンのクラスターに比較しても、パフォーマンスが向上します。パフォーマンスは、主として合計仮想キャッシュ・サイズの増加によって向上します。これにより、キャッシュ・ヒット率が最大になり、キャッシュの矛盾と待ち時間が最小になります。 RCA を使用すると、特定の文書の 1 つのコピーのみがキャッシュに入れられます。プロキシー・サーバーのクラスターを使用すると、合計キャッシュ・サイズは大きくなりますが、複数のプロキシー・サーバーが同じ情報を取り出したりキャッシュに入れたりする可能性があります。このため、合計キャッシュ・ヒット率は高くなりません。
一般的に、RCA は大規模企業のコンテンツ・ホスティングのシナリオで使用されます。ただし、RCA の有用性は、非常に大規模な企業での展開に限定されるものではありません。ネットワークの負荷がキャッシュ・サーバーのクラスターを必要とする場合、および要求の多くがキャッシュ・ヒットの場合に、RCA の使用を考慮してください。ネットワークの設定によっては、RCA が構成されるとクライアントが使用する TCP 接続の数が増えるため、RCA が常に企業のパフォーマンスを向上させるとは限りません。これは、RCA メンバーが最高スコアの URL の提供を担当するだけではなく、最高スコアではない URL の要求を受けた場合に他のメンバーまたはクラスターに要求を送信する必要もあるからです。これは、RCA 配列の任意のメンバーが、スタンドアロン・サーバーとして作動する場合よりもオープンな TCP 接続を持つ可能性があることを意味します。
パフォーマンスは、主に Caching Proxy のキャッシング能力によって向上します。ただし、プロキシー・サーバーのキャッシュは、正しく構成されていない場合にボトルネックになる可能性があります。最良のキャッシュ構成を判別するには、トラフィックの特性の分析に力を注がなければなりません。コンテンツのタイプ、サイズ、量、および属性は、起点サーバーから文書を取り出すための時間とサーバーにかかる負荷の点で、プロキシー・サーバーのパフォーマンスに影響を与えます。 Caching Proxy がプロキシーとなるかキャッシュから提供するトラフィックのタイプを判別すれば、プロキシー・サーバーを構成するときにそれらの特性を考慮に入れることができます。例えば、キャッシュに入れられるオブジェクトの 80% がイメージ (*.gif または *.jpg) であり、そのサイズが約 200 KB であることが判別できれば、キャッシング・パラメーターのチューニングとキャッシュのサイズの決定に間違いなく役立ちます。さらに、コンテンツの多くがキャッシングの対象ではないパーソナライズされた動的ページであることの判別も、Caching Proxy のチューニングに直接関連します。
トラフィック特性の分析を行うと、メモリー・キャッシュとディスク・キャッシュのどちらを使用するとキャッシュのパフォーマンスを最適化できるかを判別することができます。また、ネットワークのトラフィック特性に精通すると、Caching Proxy の動的キャッシング機能の使用によってパフォーマンスが向上するかどうかの判別が可能になります。
ディスク・キャッシュは、大量の情報をキャッシュに入れるサイトに適しています。例えば、サイト・コンテンツが 5 GB を超えるほど大きく、キャッシュ・ヒット率が 80% から 90% までの場合は、ディスク・キャッシュが推奨されます。ただし、メモリー (RAM) キャッシュを使用すれば処理速度は上がり、メモリー専用キャッシュを使用することが大規模サイトに適しているというケースが多数存在することも明らかです。例えば、Caching Proxy のキャッシュ・ヒット率があまり重要ではない場合か、共用キャッシュ構成が使用されている場合には、メモリー・キャッシュが現実的な選択になります。
Caching Proxy は、ネットワーク・ベース・キャッシュへの Application Server キャッシュの仮想拡張を提供して、WebSphere Application Server 動的キャッシュによって生成された動的コンテンツ (JSP およびサーブレットの結果) をキャッシュに入れたり無効にしたりできます。動的に生成されたコンテンツのキャッシングを使用可能にすると、アプリケーション論理またはデータベースからのメッセージなどのイベントによって有効期限が切れる、動的に生成された公開 Web ページへの要求が多い環境でのネットワーク・パフォーマンスが向上します。ページの存続時間は有限ですが、有効期限トリガーを作成時に設定することはできません。このため、動的キャッシングおよび無効化機能のないホストは、そのようなページの存続時間値をゼロと指定しなければなりません。
動的に生成されたこのようなページが存続時間中に 1 人以上のユーザーから複数回要求される場合、動的キャッシングによってオフロードが行われ、ネットワークのコンテンツ・ホストに対するワークロードを削減します。動的キャッシングを使用すると、インターネットの横断がより少なくなるためにネットワークの遅延が除去されて帯域幅の使用量が削減されて、ユーザーへの応答がより高速になることによって、ネットワーク・パフォーマンスも向上します。
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 を通りません)。
凡例: 1--クライアント 2--インターネット 3--ルーター/ゲートウェイ 4--Dispatcher 5--コンテンツ・ホスト
デフォルトでは、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) のクラスターのロード・バランスを取ります。
凡例: 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 をバイパスしてブラウザーに転送します。
インターネット・アクセスを多数のクライアントに提供すると、インターネット・アクセスの要求が大量に発生し、単一のプロキシーで効率よく要求に対処できなくなる可能性があります。 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で説明します) に保管します。
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 に表されているとおりです。
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) で実行されます。
Load Balancer は、企業のコンテンツ・ホストの単一の POP (point-of-presence) として機能します。この利点は、各コンテンツ・ホストのホスト名およびアドレスではなく、クラスターのホスト名およびアドレスを DNS に公示することで、企業の Web サイトに、不測の事態に対する一定レベルの保護と統一された外観が備わるということです。さらに Web サイトの可用性を高めるには、図 10 に示すように、 1 次 Load Balancer のバックアップとして機能するように別の Load Balancer を構成します。一方の Load Balancer に障害が起こった場合、またはネットワーク障害によりアクセス不能になった場合でも、エンド・ユーザーはコンテンツ・ホストに到達できます。
凡例: 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) で実行されます。
凡例: 1--クライアント 2--インターネット 3--ルーター/ゲートウェイ 4--1 次 Dispatcher 5--バックアップ Dispatcher およびコンテンツ・ホスト 6--コンテンツ・ホスト
重要: Content Based Routing (CBR) コンポーネントは、以下の例外はありますが、すべてのサポートされるプラットフォームで使用可能です。
代わりに、このタイプのインストールの場合には、Load Balancer の Dispatcher コンポーネントの cbr 転送方式を使用して、Caching Proxy を使用せずに HTTP および HTTPS 要求の Content Based Routing を提供することができます。詳しくは、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。
Load Balancer for IPv4 and IPv6 は、Dispatcher コンポーネントの mac 転送方式のみをサポートします。nat および 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 つのコンテンツ・ホスト (6、7、8) に要求を経路指定します。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。プロキシー・サーバーは要求をインターセプトし、同じマシン上の CBR コンポーネントに渡します。 CBR は要求の中の URL を解析して、ファイル X がコンテンツ・ホスト 6 にあると判断します。プロキシー・サーバーはファイル X に関する新しい要求を生成し、キャッシング機能が使用可能になっている場合は、ホスト 6 がファイルを戻したときにそのファイルがキャッシュに適格であるかどうかを判断します。ファイルがキャッシュ可能なら、プロキシー・サーバーはファイルをエンド・ユーザーに引き渡す前にキャッシュ (5) にコピーを保管します。他のファイルの経路指定もこれと同様に行われます。ファイル Y に関する要求はコンテンツ・ホスト 7 に送られ、ファイル Z に関する要求はコンテンツ・ホスト 8 に送られます。
凡例: 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 サーバーはプロキシー・サーバーに直接応答します。通常、注文情報は動的に生成されるので、プロキシー・サーバーが注文情報をキャッシュに入れることはありません。
凡例: 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 サイトで表示可能になります。ショッピングは電子メール・アドレス、電話番号、および FAX 番号の提供によって可能になり、さらに、自動化されたフォームによっても可能になります。しかし、本当のオンライン・ショッピングを行うことはできません。注文の処理に人的な作業を必要とするため、すべてのトランザクションに必ず待ち時間が伴います。
2 番目のフェーズでは、企業は直接オンライン購入用のセキュア・ショッピング・カートをインプリメントすることによって、この待ち時間を取り除き、販売操作を能率的にします。これらの販売トランザクションを完全なものにするには、ウェアハウス・データベースとの同期化を図り、バンキング・システムとの統合が非常に重要になります。在庫のない商品は販売できず、その品目について顧客の会計に課金することはできません。同様に、有効な会計上のトランザクションが発生するまで、在庫の商品を取り出して顧客に配送することはできません。
3 番目のフェーズでは、企業の Web サイトはさらに進化し、顧客はクライアントへと発展し、各クライアントにはそれぞれ固有のコンテンツが示される、動的なプレゼンテーション・サイトへと発展します。
次のシナリオには、Load Balancer および Caching Proxy の両方が含まれています。
重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
図 14 は、効率のよいカタログのブラウズを目的に設計された小さな商用 Web サイトを示しています。すべてのクライアント要求はファイアウォールを経由して Dispatcher へとパススルーして、 Web サーバーの代理サーバーとして働く、アクティブ・キャッシュを使用するプロキシー・サーバーのクラスターに経路指定されます。 Metric Server がプロキシー・サーバーと同じ場所に配置されて、Dispatcher にロード・バランシング・データを提供します。この配置は、Web サーバーにかかるネットワーク負荷を軽減し、インターネットとの直接的接触から Web サーバーを切り離します。
図 15 は、商用 Web サイトの発展の 2 番目のフェーズを示しています。このサイトは、効率的なカタログのブラウズおよび潜在的な顧客に高速なセキュア・ショッピング・カートを提供することを目的に設計されています。すべての顧客の要求は、インターネット・プロトコルに基づいて要求を分離する Dispatcher によって、ネットワーク内の該当するブランチに経路指定されます。 HTTP 要求は静的 Web サイトに移動します。 HTTPS 要求はショッピング・ネットワークに移動します。基本の静的 Web サイトはこのフェーズでも、Web サーバーの代理として機能するアクティブ・キャッシュを持つプロキシー・サーバーのクラスターによって処理されます。ネットワークのこの部分は、最初のフェーズのネットワークを反映しています。
Web サイトのエレクトロニック・コマースの部分も、プロキシー・サーバーのクラスターによって処理されます。ただし、Caching Proxy ノードはいくつかのプラグイン・モジュールによって拡張されています。 SSL ハンドシェークは暗号ハードウェア・カードにオフロードされ、認証は Access Manager (旧 Policy Director) プラグインを通じて実行されます。動的キャッシング・プラグインは、共通データを保管して WebSphere アプリケーション・サーバー上のワークロードを削減します。アプリケーション・サーバー上のプラグインは、必要であれば動的キャッシングのオブジェクトを無効にします。
すべてのショッピング・カート・アプリケーションはユーザーの認証に使用された顧客データベースに結合されています。これにより、ユーザーが個人情報を認証に 1 回、ショッピングに 1 回の計 2 回システムに入力しないで済むようになります。
このネットワークは、クライアントの使用法に応じてトラフィックを分割し、基本 Web サイトからプロセッサー集中の SSL 認証およびエレクトロニック・コマース・ショッピング・カートを切り離します。この二重トラック Web サイトにより、ネットワーク内のサーバーの役割に基づいて優れたパフォーマンスを提供するようにさまざまなサーバーを調整できます。
図 16 は、企業消費者間ネットワークの発展の 3 番目のフェーズを示しています。ここでは、静的 Web に動的プレゼンテーション・メソッドが取り入れられています。プロキシー・サーバー・クラスターが拡張されて、動的 Web コンテンツのキャッシングと、Edge Side Includes (ESI) プロトコルに準拠して作成されたページ・フラグメントのアセンブリーをサポートしています。サーバー側インクルード機構を使用して、コンテンツ・サーバー上に Web ページを作成してから、これらのクライアント固有の、キャッシュ不可能なページをネットワーク全体に伝搬するのとは違い、ESI 機構はキャッシュに入れられたコンテンツからネットワークのエッジでページをアセンブルすることを許可し、これによって帯域幅使用量と応答時間を削減します。
この 3 番目のフェーズのシナリオでは ESI 機構が重要になります。このシナリオでは、パーソナライズされたホーム・ページを各クライアントが Web サイトから受信します。これらのページのビルディング・ブロックは、一連の WebSphere Application Servers から検索されます。機密ビジネス・ロジックと、セキュア・データベースへのタイを含むアプリケーション・サーバーは、ファイアウォールの後ろで分離されています。
図 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 インストールで利用可能です。ただし、以下の例外があります。
図 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 インストールで利用可能です。ただし、以下の例外があります。
この部では、Edge Components のインストールについての手順が提供されます。
この部は、以下の章で構成されています。
セットアップ・プログラムを使用した Edge Components のインストール
システム・パッケージ・ツールを使用した Caching Proxy のインストール
システム・パッケージ・ツールを使用した Load Balancer のインストール
このトピックでは、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 を構成するには、ブラウザーは以下のことが可能である必要があります。
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
制限: 展開エレメントの数が多すぎてブラウザーのウィンドウに表示しきれない場合、管理フォームの左側の垂直スクロール・バーが表示されない場合があります。これにより、リスト下部の展開エレメントがブラウザーの現行表示ウィンドウから押し出され、エレメントにアクセスできなくなります。この問題を解決するには、左側のメニューの展開エレメントの数を制限します。展開エレメントの数が多すぎる場合は、一部のエレメントを縮小表示して、ブラウザーのウィンドウでリスト下部のエレメントが表示されるようにします。
フォームを適切に表示するには、フォームを実際に表示する (ブラウザーが常駐する) オペレーティング・システムに、フォームが書かれた言語に該当するフォント・セットが含まれていなければなりません。ただし、ブラウザー・インターフェースが必ずしもフォームと同じ言語である必要はありません。
例えば、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 以降に更新する必要があります (管理フォームを適切に表示できるようにするため)。プラグインを更新するには、以下のステップを行います。
Load Balancer オンライン・ヘルプを使用するには、ブラウザーが以下をサポートしている必要があります。
上記の要件をサポートしていないブラウザーを使用すると、ページのフォーマットに問題が発生したり、機能が正しく動作しない場合があります。
このトピックでは、セットアップ・プログラム を使用して Edge Components をインストールする方法について説明します。
Java 2 SDK は、すべてのプラットフォームで Load Balancer と一緒に自動的にインストールされます。
インストール後に、Caching Proxy パッケージ内のスクリプトが、デフォルトの構成を使用してプロキシー・サーバーを開始しようとします。ポート 80 が (別の Web サーバーなどによって) 使用中の場合、プロキシー・サーバーの開始は失敗します。
重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
セットアップ・プログラムを使用して、ご使用の Windows(R) システムに Edge Components をインストールします。手順は、以下のとおりです。
Edge components がすでにインストールされている場合は、「保守オプション」ウィンドウが開いてから、「コンポーネント選択」ウィンドウが開きます。「変更」ラジオ・ボタンを選択してから「次へ」をクリックします。「コンポーネント選択」ウィンドウがオープンします。
制限: ご使用条件のウィンドウではタブ・キーを使用して、「I accept」オプションと「I do not accept」オプションの切り替えを行います。ただし、タブ・キーを使用して、「戻る」、「次へ」、または「取り消し」のナビゲーション・オプションに進むことはできません。次善策として、これらのナビゲーション・オプションに進むには、 Shift+Tab を使用します。また、Enter キーはナビゲーション・ボタンでしか機能しないため、「I accept」または「I do not accept」オプションを選択するときはスペース・バーを使用する必要があります。
CD からインストールしようとする場合、セットアップ・プログラム を使用して、ご使用の Linux および UNIX システムに、以下の手順で Edge Components をインストールすることができます。
# ./install「ようこそ」ウィンドウがオープンします。
セットアップ・プログラムは、選択した Edge Components および必須パッケージのインストールを開始します。
制限: ご使用条件のウィンドウではタブ・キーを使用して、「I accept」オプションと「I do not accept」オプションの切り替えを行います。ただし、タブ・キーを使用して、「戻る」、「次へ」、または「取り消し」のナビゲーション・オプションに進むことはできません。次善策として、これらのナビゲーション・オプションに進むには、 Shift+Tab を使用します。また、Enter キーはナビゲーション・ボタンでしか機能しないため、「I accept」または「I do not accept」オプションを選択するときはスペース・バーを使用する必要があります。
Red Hat Linux 3.0 アップデート 3: Edge Components のインストーラー・プログラムの実行中、GUI パネルを最大化してから復元すると、ボタンが動作しなくなります。この問題を解決するには、以下を実行してください。
Linux および UNIX システム: Edge Components をインストールするのにセットアップ・プログラムを使用した場合、GUI アンインストーラーを使用して Edge Components をアンインストールすることができます。ただし、ネイティブ・コマンドを使用してインストールしたリフレッシュ・パックをアンインストールするために、Edge Components の GUI アンインストーラーを使用することはできません。最初にネイティブ・コマンド (オペレーティング・システムのコマンド) を使用してリフレッシュ・パックをアンインストールしてから、GUI アンインストーラーを使用してコンポーネントのアンインストールを行う必要があります。
ネイティブ・コマンドの使用法については、システム・パッケージ・ツールを使用した Caching Proxy のインストールおよび システム・パッケージ・ツールを使用した Load Balancer のインストールを参照してください。
このトピックでは、システム・パッケージ・ツールを使用して Caching Proxy をインストールする方法について説明します。
インストール後に、Caching Proxy パッケージ内のスクリプトが、デフォルトの構成を使用してプロキシー・サーバーを開始しようとします。ポート 80 が (別の Web サーバーなどによって) 使用中の場合、プロキシー・サーバーの開始は失敗します。
重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
オペレーティング・システムのパッケージ・インストール・システムを使用して、 表 2 でリストされた順序でパッケージをインストールします。以下の手順には、このタスクを完了するのに必要な通常ステップが示されています。
su - root Password: password
cd mount_point/package_directory/
AIX(R) の場合:
installp -acXd ./packagename
HP-UX の場合:
swinstall -s source/ packagename
Linux の場合:
rpm -i ./packagename
Solaris の場合:
pkgadd -d ./packagename
コンポーネント | インストール・パッケージ (推奨順序) |
---|---|
Caching Proxy |
|
Edge Component 資料 |
doc-en_US1 |
注:
|
資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html
パッケージをアンインストールするには、以下を行います。
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
パッケージは、インストール時とは逆の順番で除去されます。
このトピックでは、AIX、HP-UX、Linux、および Solaris システムへの Load Balancer のインストールについて説明します。
インストールのタイプによっては、以下のセクションにリストされているすべての Load Balancer コンポーネント・パッケージが提供されるとは限りません。
Load Balancer for IPv4 and IPv6 のインストールの場合、これらのパッケージをインストールする際の推奨順序が若干異なります。管理コンポーネント・パッケージのインストールは、ディスパッチャー・コンポーネント・パッケージの後に行う必要があるので注意してください。システムのツールを使用して Load Balancer for IPv4 and IPv6 のパッケージをインストールする場合の推奨順序は、ベース、ライセンス、ディスパッチャー・コンポーネント、管理、資料、Metric Server の順です。
以前のバージョンの Load Balancer からマイグレーションする場合、またはオペレーティング・システムを再インストールする場合は、インストールに先立ち、Load Balancer の既存の構成ファイルやスクリプト・ファイルを保管しておきます。
Load Balancer をインストールした後にマシンからログオフした場合、再度ログオンしたときにすべての Load Balancer サービスを再始動する必要があります。
表 5 は、Load Balancer 用の AIX ファイル・セットと、システムのパッケージ・インストール・ツールを使用して行うインストールの推奨順序をリストしています。
Load Balancer コンポーネント | AIX ファイル・セット |
---|---|
ベース | ibmlb.base.rte |
管理 (メッセージ付き) |
|
デバイス・ドライバー | ibmlb.lb.driver |
ライセンス | ibmlb.lb.license |
Load Balancer コンポーネント (メッセージ付き) |
|
資料 (メッセージ付き) |
|
Metric Server | ibmlb.ms.rte |
資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html
AIX への Load Balancer のインストールを行う前に、以下を確認してください。
installp -u ibmlbまたは、前のバージョンに対して次のコマンドを入力します。
installp -u ibmnd特定のファイル・セットをアンインストールするには、パッケージ名 ibmlb を指定する代わりにファイル・セットを個別にリストします。
製品をインストールするとき、以下の一部またはすべてをインストールするためのオプションが提供されます。
SMIT では、すべてのメッセージが自動的にインストールされるため、 SMIT を使用して Load Balancer for AIX をインストールすることをお勧めします。
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
パッケージ | コマンド |
---|---|
ベース | 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 |
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 インストール・パスには、以下が組み込まれています。
このセクションでは、製品 CD を使用して、 Load Balancer を HP-UX にインストールする方法について説明します。
インストール手順を開始する前に、ソフトウェアをインストールする root 権限を持っていることを確認してください。
以前のバージョンをインストールしている場合は、そのバージョンをアンインストールしてから現行バージョンをインストールしてください。まず、executor とサーバーの両方を停止したことを確認してください。次に、Load Balancer アンインストール手順について、パッケージのアンインストール手順を参照してください。
表 7 には、Load Balancer のインストール・パッケージ名のリストと、システムのパッケージ・インストール・ツールを使用してパッケージをインストールする場合の推奨順序を示しています。
HP-UX では ブラジル・ポルトガル語 (pt_BR) ロケールはサポートされていません。 HP-UX でサポートされているロケールは、以下のとおりです。
以下の手順では、この作業の完了に必要なステップの詳細を示します。
su - root Password: password
インストール・コマンドを発行します。
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
swlist コマンドを実行し、これまでにインストールしたすべてのパッケージをリストします。例えば、
swlist -l fileset ibmlb
swremove コマンドを使用してパッケージをアンインストールできます。パッケージは、最後にインストールしたものから順に除去する必要があります。例えば、次のコマンドを実行します。
swremove ibmlb個々のパッケージ (例えば、Cisco CSS Controller) をアンインストールする場合:
swremove ibmlb.cco
Load Balancer インストール・パスには、以下が組み込まれています。
このセクションでは、Edge Components CD を使用して Load Balancer を Linux にインストールする方法について説明します。
Load Balancer をインストールする前に、以下を確認してください。
rpm -e pkgnameアンインストールを行うときは、パッケージのインストールで使用した順序を逆にして、管理パッケージが最後にアンインストールされるようにします。
インストール・イメージのファイルは、lblinux- version.tar 形式です。
tar -xf lblinux-version.tarその結果、.rpm 拡張子を持った以下の一連のファイルが生成されます。
ここで、
資料パッケージには英語のみ含まれています。 Edge Component 資料セットの翻訳版は、次の Web サイトにあります: www.ibm.com/software/webservers/appserv/ecinfocenter.html
rpm -i package.rpm
Red Hat Linux システム: Red Hat Linux の既知の問題があるため、_db* RPM ファイルを削除することが必要になります。削除しないと、エラーが起こります。
以下の、各コンポーネントに必要なパッケージのリストに示された順序でパッケージをインストールすることが重要です。
rpm -i --nodeps package.rpm
rpm -qa | grep ibmlb
全製品をインストールした場合、以下が出力されます。
Load Balancer インストール・パスには、以下が入っています。
パッケージをアンインストールする必要がある場合、パッケージのインストールで使用した順序を逆にして、管理パッケージが最後にアンインストールされるようにします。
このセクションでは、Edge Components CD を使用して Load Balancer を Solaris にインストールする方法について説明します。
インストール手順を開始する前に、root としてログインしていること、および前のバージョンの製品はアンインストールされていることを確認してください。
アンインストールを行うには、すべての executor およびサーバーが停止されていることを確認します。次に、次のコマンドを入力します。
pkgrm pkgname
pkgadd -d pathnameここで、-d pathname は、CD-ROM ドライブのデバイス名またはこのパッケージが入っているハード・ディスクのディレクトリーです(例: -d /cdrom/cdrom0/)。
以下は、表示されるパッケージのリストと、インストールする際の推奨順序です。
資料パッケージ (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 のパッケージをインストールする必要があります。
pkginfo | grep ibm
Load Balancer インストール・パスには、以下が入っています。
この部では、Edge Components を使用して基本デモンストレーション・ネットワークを構築する手順を説明します。これらのネットワークは、実稼働環境での使用を意図していません。ネットワークの最初の構成プロセスによって、この製品を初めて扱う管理者に対して、多くのエッジ・オブ・ネットワークの概念をわかりやすく説明します。すべてのコンポーネント機能の詳細な解説および構成情報については、「Caching Proxy 管理ガイド」および「Load Balancer 管理ガイド」を参照してください。
この手順では、コンポーネントによってサポートされる任意のコンピューター・システムを任意のノードで使用できます。
この部は、以下の章で構成されています。
図 19 は、 3 つのネットワーク・ノードにある 3 台のコンピューター・システムを使用する基本的なプロキシー・サーバー・ネットワークを示しています。このネットワークは、プロキシー・サーバーをサーバー 2 にある専用コンテンツ・ホスト (IBM HTTP Server) に結合し、プロキシー・サーバーがホストを処理します。これは、インターネットによってワークステーションとサーバー 1 の間に位置するように見えます。
重要: Caching Proxy は、すべての Edge Components インストールで利用可能です。ただし、以下の例外があります。
Caching Proxy ネットワークを構築するには、以下の順序で手順を実行します。
以下のコンピューター・システムおよびソフトウェア・コンポーネントが必要です。
以下のように Caching Proxy をインストールして構成します。
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
プロンプトが出されたら、htadm プログラムに、管理者のユーザー名、パスワード、および実名を指定します。
以下のように Caching Proxy をインストールして構成します。
cd "Program Files¥IBM¥edge¥cp¥server_root¥protect" htadm -adduser webadmin.passwd"
プロンプトが出されたら、htadm プログラムに、管理者のユーザー名、パスワード、および実名を指定します。
ワークステーションから、以下の手順を実行してください。
ワークステーションから、以下の手順を実行してください。
図 20 は、3 つのローカル接続ワークステーションを持つ基本的な Load Balancer ネットワークを示しています。このネットワークでは、Dispatcher コンポーネントの MAC 転送方式を使用して、Web サーバー間の Web トラフィックのロード・バランスを取っています。構成は、他の任意の TCP またはステートレス UDP アプリケーション・トラフィックのロード・バランスを取る場合と同じです。
Load Balancer ネットワークを構築するには、以下の順序で手順を実行します。
以下のコンピューター・システムおよびソフトウェア・コンポーネントが必要です。
ワークステーション | 名前 | 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 |
Name= www.company.com IP=9.67.67.104
server2.company.com および server3.company.com にある ループバック・インターフェースに www.company.com の別名を追加してください。
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 www.company.com 127.0.0.1 up
これで、2 つの Web サーバー・ワークステーションに必要なすべての構成ステップが完了しました。
Dispatcher があれば、コマンド行、構成ウィザード、またはグラフィカル・ユーザー・インターフェース (GUI) を使用して構成を作成できます。
コマンド行を使用する場合は、以下のステップに従ってください。
dscontrol executor start
dscontrol cluster add www.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.com
dscontrol manager start
これで、Dispatcher は、サーバー・パフォーマンスに基づいてロード・バランシングを行うようになります。
dscontrol advisor start http 80
これで Dispatcher はクライアント要求が失敗 Web サーバーに送信されないようにします。
ローカル接続サーバーの基本構成はこれで完了です。
重要: Load Balancer for IPv4 and IPv6 インストールでの Dispatcher コマンド (dscontrol) の構文は、1 つの重要な例外をのぞき、同一です。dscontrol コマンドの区切り文字は、コロン (:) ではなく、単価記号 (@) です。(コロン以外の区切り文字を定義することが必要でした。IPv6 形式は、アドレッシング方式内部でコロンを使用するからです。)
例 (以前の Dispatcher 構成例から)
dscontrol port add www.company.com@80
dscontrol server add www.company.com@80@server2.company.com
dscontrol server add www.company.com@80@server3.company.com
詳しくは、Load Balancer for IPv4 and IPv6 インストールを使用している場合、WebSphere Application Server Load Balancer 管理ガイド 内の、制限および構成の相違に関する情報を含む「Load Balancer for IPv4 and IPv6 に Dispatcher をデプロイする」の章を参照してください。
構成ウィザードを使用する場合は、以下のステップに従ってください。
dsserver
このウィザードは、Dispatcher コンポーネントの基本構成を作成するプロセスを段階的に案内します。このウィザードはネットワークについての確認を行い、Dispatcher のクラスターのセットアップをガイドします。このクラスターによって、サーバー・グループのトラフィックのロード・バランシングが行われます。
構成ウィザードには、以下のパネルがあります。
GUI を開始するには、以下のステップに従ってください。
dsserver