バージョン 7.0
資料番号 GD88-6859-00
第 1 版 (2008 年 6 月)
この版は、以下のプログラムに適用されます。
また、新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。
資料を注文する場合は、IBM 担当者または最寄りの IBM 営業所にご連絡ください。
(C) Copyright International Business Machines Corporation 2008. All rights reserved.
Edge Components を使用したネットワークの構築
本書「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 バージョン 7.0 の主なアクセシビリティー機能です。
本書では、以下のような書体およびキー操作の規則を使用しています。
規則 | 意味 |
---|---|
太字 | グラフィカル・ユーザー・インターフェース (GUI) に関しては、太字は、メニュー、メニュー項目、 ラベル、ボタン、アイコン、およびフォルダーを示します。 また、太字にしないと周りのテキストと混同される恐れがあるコマンド名を強調するためにも 使用されます。 |
モノスペース | コマンド・プロンプトから入力する必要のあるテキストを示します。 また、モノスペースは、画面上のテキスト、コード例、およびファイルからの引用も示します。 |
イタリック | 指定する必要のある可変値を示します (例 : fileName でファイルの名前を指定します)。 イタリックは、強調表示および書名の表示にも使用されます。 |
Ctrl-x | x がキーの名前である場合、制御文字のシーケンスを示します。例えば、Ctrl-c は、Ctrl キーを押しながら c キーを押すという意味になります。 |
Return | Return、Enter または左矢印が表示されているキーを指します。 |
% | root 権限を必要としないコマンド用の Linux および UNIX(R) コマンド・シェル・プロンプトを表します。 |
# | root 権限を必要とするコマンド用の Linux および UNIX コマンド・シェル・プロンプトを表します。 |
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 には、Edge Components として Caching Proxy および Load Balancer が含まれています。
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 は、クライアントからのデータ要求をインターセプトして、現在各要求を満たすのに最も適しているサーバーに各要求を転送します。 つまり、Load Balancer は、同じタイプの要求を処理する定義済みセットのマシン間で、着信要求の負荷のバランスを取ります。 Load Balancer は、WebSphere Application Server および Caching Proxy マシンを含むさまざまなタイプのサーバーに要求を分散させることができます。 カスタム advisor を使用することによって、 ロード・バランシングを特定のアプリケーションまたはプラットフォーム用にカスタマイズできます。 WebSphere Application Server のロード・バランシングを行うための情報を取得するために、特殊目的の advisor を使用できます。
Content Based Routing コンポーネントと Caching Proxy がインストールされている場合、HTTP および HTTPS 要求を、URL または管理者が決定したその他の特性に基づいて分散させることも可能になります。これにより、すべてのバックエンド・サーバーに同一のコンテンツを保管する必要がなくなります。 Dispatcher コンポーネントにも HTTP 要求についての同じ機能があります。
ロード・バランシングを使用すると、コンテンツ・サーバーが透過的にクラスター化されるため、 Web サイトの可用性とスケーラビリティーが向上します。 コンテンツ・サーバーには、HTTP サーバー、アプリケーション・サーバー、 および代理コンテンツ・サーバーであるプロキシー・サーバーが含まれます。 並列性、ロード・バランシング、およびフェイルオーバー・サポートによって、 可用性が向上します。 サーバーがダウンしても、ビジネス機会の損失にはつながりません。 バックエンド処理能力を透過的に追加できることによって、 インフラストラクチャーのスケーラビリティーは非常に向上します。
Load Balancer には以下のコンポーネントが組み込まれています。
HTTP、FTP、HTTPS、および Telnet などのすべてのインターネット・サービスで、Dispatcher コンポーネントは、ローカル・エリア・ネットワーク (LAN) または広域ネットワーク (WAN) 内のサーバー間のロード・バランシングを実行します。 HTTP サービスでは、Dispatcher はサーバーのロード・バランシングをクライアント要求の URL コンテンツに基づいて実行できます。
Dispatcher コンポーネントを使用すると、 大規模でスケーラブルなサーバーのネットワークを継続的かつ効率よく管理できます。 Dispatcher を使用して多くの個々のサーバーをリンクし、 単一の仮想サーバーとして扱うことができます。 したがって、サイトは単一の IP アドレスとして表示されます。
HTTP および HTTPS サービスで、Content Based Routing コンポーネントは、クライアント要求のコンテンツに基づいたサーバーのロード・バランシングを実行します。 Content Based Routing コンポーネントは、Application Server の Caching Proxy コンポーネントと共に機能します。
重要: Content Based Routing (CBR) コンポーネントは、サポートされているすべてのプラットフォーム上で使用できますが、以下の例外があります。
代わりに、このタイプのインストール済み環境では、Load Balancer の Dispatcher コンポーネントの CBR 転送方式を使用して、Caching Proxy を使用せずに HTTP 要求および HTTPS 要求のコンテンツ・ベース・ルーティングを実行することができます。 詳細については、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。
IPv4 および IPv6 用の Load Balancer は、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 サーバーからコンテンツにアクセスした後、Transcoding Publisher を起動してデータを変換し、異なる形式のキャッシングおよび再利用のためのタグ付けを行うように Caching Proxy の Transmogrify インターフェースを構成することができます。 次に、Transcoding Publisher は、Caching Proxy の認証後インターフェースで、ユーザーとデバイスの要求を満たすコンテンツがプロキシー・サーバーにあるかどうかを検査し、要件を満たすコンテンツがあった場合には、プロキシー・サーバーのキャッシュからそのコンテンツを提供します。
WebSphere Application Server Edge Components 用の以下の資料は、Edge Components インフォメーション・センターで入手することができます。
その他の WebSphere Application Server 資料は、WebSphere Application Server のライブラリー・ページから入手できます。
Edge Components に関する技術サポート情報は、WebSphere Application Server のサポート・ページから入手できます。
以下に、Edge Components の情報またはその関連情報を入手するための Web サイトを挙げます。
この部では、Edge Components で使用可能ないくつかの機能を中心に説明します。 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. リバース・プロキシーとして機能する Caching Proxy
この構成において、プロキシー・サーバー (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
図 2 は、フォワード Caching Proxy の構成を示しています。 クライアントのブラウザー・プログラム (1 という番号が付いたマシン上のプログラム) は、フォワード・キャッシング・プロキシー (2) に要求を送るように構成され、フォワード・キャッシング・プロキシーは要求をインターセプトするように構成されています。 コンテンツ・ホスト (6) に保管されているファイル X をエンド・ユーザーが要求すると、フォワード Caching Proxy はその要求をインターセプトして、自身の IP アドレスを発信アドレスとして持つ新規要求を生成し、企業のルーター (4) を使用してインターネット (5) 経由でその新規の要求を送信します。
このようにして、起点サーバーはファイル 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 アドレスを発信アドレスとして持つ新規要求を生成し、ルーター (2) を使用してインターネット (5) 経由でその新規要求を送信します。 ファイル 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 準拠です。
より高度なキャッシング機能を利用するには、Load Balancer コンポーネントと共に、リバース・プロキシーとして Caching Proxy を使用します。 キャッシング機能とロード・バランシング機能を統合することによって、 能率的で非常に扱いやすい Web パフォーマンス・インフラストラクチャーを作成できます。
図 4 は、Caching Proxy と Load Balancer を組み合わせて、大量要求の状況でも Web コンテンツを効率的に引き渡すための方法を示しています。 この構成の場合、プロキシー・サーバー (4) は、Load Balancer (6) によってロード・バランシングが行われているコンテンツ・ホスト (7) のクラスターのホスト名が URL に含まれている要求をインターセプトするように構成されています。
図 4. ロード・バランシングが行われたクラスターのプロキシー・サーバーとして機能する Caching Proxy
クライアント (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) メッセージは、コンテンツを所有する 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 サーバーに広げられ、それらのサーバーでは、通常、Internet Cache Protocol (ICP) または 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) のネットワーク・インターフェースの 1 つに、そのクラスター専有のホスト名および IP アドレスが割り当てられます。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。 URL が Dispatcher のホスト名および IP アドレスにマップされているため、Dispatcher が要求をインターセプトします。 Dispatcher は、現在クラスター内のどのコンテンツ・ホストが要求に応えるために最も適しているかを判断し、要求をそのコンテンツ・ホストに転送します。MAC 転送方式が構成されている場合、このコンテンツ・ホストはファイル X を直接クライアントに返します (つまり、ファイル X は Load Balancer を通りません)。
デフォルトでは、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. 複数のリバース・プロキシー・サーバーおよびコンテンツ・ホストのロード・バランシング
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 に要求を送り、この Dispatcher は、ロード・バランシング・アルゴリズムに従って、現在その要求の処理に最も適しているプロキシー・サーバー (5) に要求を渡します。 キャッシュ (6) にファイル X が入っている場合、プロキシー・サーバーは、4 の番号が付いた Dispatcher をバイパスして、ファイルを直接ブラウザーに返します。
キャッシュにファイル X が入っていない場合、プロキシー・サーバーは、ヘッダーの起点フィールドに自身のホスト名が入った新規要求を作成して、それを 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 にあります)。
図 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 にもインターネットにも到達できません。 これに対する解決策は、図 8 に示されているように、1 次 Dispatcher のバックアップとして機能する別の Dispatcher を構成することです。
図 8. ハイ・ アベイラビリティーのインターネット・アクセスを提供するための 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 を配置する
Load Balancer は、企業のコンテンツ・ホストの単一の POP (Point-of-Presence) として機能します。 この利点は、各コンテンツ・ホストのホスト名およびアドレスではなく、クラスターの ホスト名およびアドレスを DNS に公示することで、企業の Web サイトに、 不測の事態に対する一定レベルの保護と統一された外観が備わるということです。 さらに Web サイトの可用性を高めるには、図 10 に示すように、1 次 Load Balancer のバックアップとして機能する別の Load Balancer を構成します。 一方の Load Balancer に障害が起こった場合、またはネットワーク障害によりアクセス不能になった場合でも、エンド・ユーザーは引き続きコンテンツ・ホストに到達できます。
図 10. 1 次 Load Balancer およびバックアップ Load Balancer の使用による Web コンテンツのハイ・ アベイラビリティーの確保
通常の場合、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 はそれぞれ別々のコンテンツ・ホスト・クラスターのロード・バランシングをアクティブに実行し、同時に相手のバックアップとしても働きます。(IPv4 および IPv6 用の Load Balancer インストール済み環境では、単純なハイ・ アベイラビリティーはサポートされていますが、相互ハイ・ アベイラビリティーはサポートされていません。)
Dispatcher は一般に大量の処理リソースまたはメモリー・リソースを消費しないため、Load Balancer マシンでは他のアプリケーションを実行することができます。 設備費を最小限に抑えることが重要な場合は、ロード・バランシングの対象となるクラスター内のマシンの 1 つでバックアップ Dispatcher を実行することもできます。 そのような構成を示したのが、図 11 です。この場合、バックアップ Dispatcher はクラスター内のコンテンツ・ホストの 1 つ (5) で実行されます。
図 11. コンテンツ・ホストにバックアップ Load Balancer を配置する
重要: Content Based Routing (CBR) コンポーネントは、サポートされているすべてのプラットフォーム上で使用できますが、以下の例外があります。
代わりに、このタイプのインストール済み環境では、Load Balancer の Dispatcher コンポーネントの CBR 転送方式を使用して、Caching Proxy を使用せずに HTTP 要求および HTTPS 要求のコンテンツ・ベース・ルーティングを実行することができます。 詳細については、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。
IPv4 および IPv6 用の Load Balancer は、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 を解析して、コンテンツ・ホスト 6 にファイル X が保管されていることを判別します。 プロキシー・サーバーはファイル X に対する新規の要求を生成して、キャッシング機能が使用可能になっている場合は、ホスト 6 がファイルを返したときに、そのファイルがキャッシュに適格であるかどうかを判断します。 ファイルがキャッシュ可能である場合、プロキシー・サーバーはそのファイルのコピーをキャッシュ (5) に格納してから、エンド・ユーザーに引き渡します。 他のファイルの経路指定もこれと同様に行われます。ファイル Y に関する要求はコンテンツ・ホスト 7 に送られ、ファイル Z に関する要求はコンテンツ・ホスト 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 に送信します。Load Balancer は (ユーザーが定義した基準に基づいて) 8 の番号が付いたコンテンツ・ホストのうち、現在どのホストがその要求へのサービス提供に最も適しているかを判断します。 このコンテンツ・ホストは Load Balancer をバイパスして、カタログ・コンテンツをプロキシー・サーバーに直接引き渡します。 前の例の場合と同様、プロキシー・サーバーは、コンテンツがキャッシュ可能であるかどうかを判断し、必要に応じてそのコンテンツをキャッシュ (5) に格納します。
通常はカタログのハイパーリンクを経由して小売業者の注文 URL にアクセスすることによって、エンド・ユーザーは発注します。 この要求がたどる経路は、マシン 4 の CBR コンポーネントによって 7 の番号が付いた Load Balancer マシンに送られる点を除けば、カタログ・アクセスの要求の場合と同じです。Load Balancer は 9 の番号が付いた Web サーバーのうち最も適したものに要求を転送し、その Web サーバーはプロキシー・サーバーに直接応答します。 通常、注文情報は動的に生成されるため、プロキシー・サーバーが注文情報をキャッシュに入れることはほとんどありません。
図 13. CBR により経路指定された HTTP 要求のロード・バランシング
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 に送られ、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 Application Server 上のワークロードを軽減します。 アプリケーション・サーバー上の プラグインは、必要であれば動的キャッシングのオブジェクトを無効にします。
すべてのショッピング・カート・アプリケーションはユーザーの認証に使用された 顧客データベースに結合されています。これにより、 ユーザーが個人情報を認証に 1 回、ショッピングに 1 回の計 2 回システムに 入力しないで済むようになります。
このネットワークは、クライアントの使用法に応じてトラフィックを分割し、 基本 Web サイトからプロセッサー集中の SSL 認証および エレクトロニック・コマース・ショッピング・カートを切り離します。 この二重トラック Web サイトにより、 ネットワーク内のサーバーの役割に基づいて優れたパフォーマンスを提供するように さまざまなサーバーを調整できます。
図 16 は、企業消費者間ネットワークの発展の 3 番目のフェーズを示しています。ここでは、静的 Web に動的プレゼンテーション方式が取り入れられています。 プロキシー・サーバー・クラスターが拡張されて、 動的 Web コンテンツのキャッシングと、Edge Side Includes (ESI) プロトコルに 準拠して作成されたページ・フラグメントのアセンブリーをサポートしています。 サーバー側インクルード機構を使用して、 コンテンツ・サーバー上に Web ページを作成してから、 これらのクライアント固有の、 キャッシュ不可能なページをネットワーク全体に 伝搬するのとは違い、ESI 機構はキャッシュに入れられたコンテンツから ネットワークのエッジでページをアセンブルすることを許可し、 これによって帯域幅使用量と応答時間を削減します。
この 3 番目のフェーズのシナリオでは ESI 機構が重要になります。 このシナリオでは、パーソナライズされたホーム・ページを各クライアントが Web サイトから受信します。 これらのページのビルディング・ブロックは、一連の WebSphere Application Server から取得されます。 機密ビジネス・ロジックと、 セキュア・データベースへのタイを含むアプリケーション・サーバーは、 ファイアウォールの後ろで分離されています。
図 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 バージョン 7.0 の 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」オプションを選択するときはスペース・バーを使用する必要があります。
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
|
注:
|
表 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 |
注:
|
総称パッケージ名 | 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 |
注:
|
資料パッケージには英語のみ含まれています。 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 からマイグレーションする場合、 またはオペレーティング・システムを再インストールする場合は、インストールに先立ち 、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
Load Balancer を AIX にインストールする前に、以下のことを確認してください。
installp -u ibmlb
または、前のバージョンに対して次のコマンドを入力します。
installp -u ibmnd
特定のファイル・セットをアンインストールするには、パッケージ名 ibmlb を 指定する代わりにファイル・セットを個別にリストします。
製品をインストールするとき、以下の一部またはすべてをインストールするための オプションが提供されます。
SMIT ではすべてのメッセージが自動的にインストールされるため、SMIT を使用して AIX に Load Balancer をインストールすることをお勧めします。
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.docibmlb.msg.language.lb
Load Balancer のインストール・パスには、以下の内容が含まれています。
このセクションでは、製品 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 |
注:
|
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 のインストール・パスには、以下の内容が含まれています。
以下のメディアから、AIX、HP-UX、Linux、Solaris オペレーティング・システム、または Microsoft Windows オペレーティング・システム用の Edge Components フィックスパックを入手できます。
サポートされているオペレーティング・システムに関する情報については、WebSphere Application Server detailed system requirements を参照してください。
WebSphere Application Server のサポート・サイトでは、Edge Components のリフレッシュ・パックまたはフィックスパックへのリンクが示されています。
更新に関する説明については、以下のセクションを参照してください。
Load Balancer の更新に関する説明については、「Load Balancer for IPv4 管理ガイド」または「Load Balancer for IPv4 and IPv6 管理ガイド」を参照してください。
リフレッシュ・パックまたはフィックスパックのインストールを開始する前に、以下の項目について確認してください。
ご使用のオペレーティング・システム用のパッケージ・インストール・ツールを使用して、正しい順序で Caching Proxy パッケージをインストールします。 すべての Edge Components パッケージおよびそれらのインストール順序のリストについては、表 4 を参照してください。 以下の手順は、この作業を完了するために必要な通常のステップを示したものです。
su - root Password: password
stopsrc -c -s ibmproxy
kill -9 proxy_PID
proxy_PID の項は、Caching Proxy プロセスのプロセス ID です。 Caching Proxy の PID を確認するには、以下のコマンドを使用します。
ps -e | grep ibmproxy
/etc/init.d/ibmproxy stop
/etc/rc.d/init.d/ibmproxy stop
kill -9 proxy_PID
proxy_PID の項は、Caching Proxy プロセスのプロセス ID です。 Caching Proxy の PID を確認するには、以下のコマンドを使用します。
ps -e | grep ibmproxy
cd download_package_directory/
表 8. Caching Proxy をインストールするためのシステム固有のディレクティブ
Caching Proxy をインストールするためのシステム固有のディレクティブ | |
---|---|
オペレーティング・システム | コマンド |
AIX |
installp -acXd source package_name ここで、source はパッケージの場所を示すディレクトリー、package_name はパッケージの名前です。 例:
System Management Interface Tool (SMIT) を使用している場合は、以下のようにします。
|
HP-UX |
swinstall -s /source package_name ここで、source はパッケージの場所を示すディレクトリー、package_name はパッケージの名前です。 例えば、WSES-ADMIN という Caching Proxy 用の管理パッケージが現行ディレクトリーにある場合、以下のコマンドを実行すると、そのパッケージがインストールされます。 swinstall -s /admin WSES-ADMIN パッケージがインストールされたかどうかを確認するには、swlist コマンドを発行して、インストールしたすべてのパッケージをリストします。 例えば、以下のコマンドを発行すると、Caching Proxy 用にインストールされたすべてのパッケージがリストされます。 swlist gsk* swlist WSES* |
Linux |
rpm -iv --replacefiles package_name ここで、package_name はパッケージの名前です。 例えば、以下のようなコマンドを使用します。 rpm -iv --replacefiles WSES_Admin_Runtime-6.1.0-1.686.rpm
|
Solaris |
pkgadd -d source package_name ここで、source はパッケージの場所を示すディレクトリー、package_name はパッケージの名前です。 例:
サイレント・インストールを使用するには、-a オプションを使用して、管理ファイルを指定します。 インストールするパッケージに、instadm という管理ファイルが用意されています。 インストール後、新規パッケージのうち既にインストールされているものは、そのままマシンに残されます。 これらはアンインストールしないでください。 |
以下の表は、Caching Proxy が提供しているすべてのパッケージと、それらの必要なインストール順序をリストしたものです。 リフレッシュ・パックまたはフィックスパックに含まれているパッケージを、以下の表に指定された順序に従ってインストールします。
パッケージのリスト | |
インストールするコンポーネント | パッケージの更新順序 (一般的なリスト) |
Caching Proxy |
|
Edge Components 資料 | doc-lang |
Edge Components の更新をインストールした後も、Edge Components の前の構成が維持されます。 リフレッシュ・パックまたはフィックスパックに新機能や機能拡張が含まれている場合、それらのフィーチャーを有効にするために、構成ファイルにディレクティブを追加しなければならない場合があります。
Caching Proxy のセットアップ・プログラムを以下のようにして使用します。
Edge Components の更新をインストールした後も、Edge Components の前の構成が維持されます。 リフレッシュ・パックまたはフィックスパックに新機能や機能拡張が含まれている場合、それらのフィーチャーを有効にするために、構成ファイルにディレクティブを追加しなければならない場合があります。
更新を拒否するには、以下のようにします。
大部分のコンポーネントでは、リフレッシュ・パックまたはフィックスパックが除去されると、oldfiles/component ディレクトリーに構成ファイルが保管されます。 再インストールした製品でこれらの構成ファイルを使用すると、パッチ適用前のバージョンでパッチ適用後の構成を維持することができます。
この部では、Edge Components を使用した基本的なデモンストレーション・ネットワークの構築手順について説明します。 これらのネットワークは、 実稼働環境での使用を意図していません。ネットワークの最初の構成プロセスによって、 この製品を初めて扱う管理者に対して、多くのエッジ・オブ・ネットワークの概念を わかりやすく説明します。すべてのコンポーネント機能の詳細な解説および構成情報については、 「Caching Proxy 管理ガイド」および「Load Balancer 管理ガイド」を 参照してください。
この手順では、コンポーネントによってサポートされる任意のコンピューター・システムを 任意のノードで使用できます。
この部は、以下の章で構成されています。
図 19 は、3 つのネットワーク・ノードにある 3 台のコンピューター・システムを使用する基本的なプロキシー・サーバー・ネットワークを示しています。 このネットワークは、プロキシー・サーバーをサーバー 2 にある専用コンテンツ・ホスト (IBM HTTP Server) にバインドし、このプロキシー・サーバーでホスト処理を行います。 これは、インターネットによって ワークステーションとサーバー 1 の間に位置するように見えます。
重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。
図 19. Caching Proxy のデモンストレーション・ネットワーク
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 転送方式を使用して、2 つの Web サーバー間の Web トラフィックのロード・バランスを取っています。 構成は、他の任意の TCP またはステートレス UDP アプリケーション・トラフィックの ロード・バランスを取る場合と同じです。
図 20. Load Balancer のデモンストレーション・ネットワーク
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 |
各ワークステーションには、標準の イーサネット・ネットワーク・インターフェース・カードが 1 つだけ装備されています。
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 plumb www.company.com netmask 255.255.255.0
これで、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 サーバーに送信されないようにします。
ローカル接続サーバーの基本構成はこれで完了です。
構成ウィザードを使用する場合は、以下のステップに従ってください。
dsserver
このウィザードは、Dispatcher コンポーネントの基本構成を作成するプロセスを段階的に案内します。 このウィザードはネットワークについての確認を行い、Dispatcher のクラスターのセットアップをガイドします。 このクラスターによって、サーバー・グループのトラフィックのロード・バランシングが行われます。
構成ウィザードには、以下のパネルがあります。
GUI を開始するには、以下のステップに従ってください。
dsserver