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

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

バージョン 7.0

資料番号 GD88-6859-00

第 1 版 (2008 年 6 月)

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

WebSphere Edge Components バージョン 7.0

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

資料を注文する場合は、IBM 担当者または最寄りの IBM 営業所にご連絡ください。

(C) Copyright International Business Machines Corporation 2008. All rights reserved.


目次

  • 本書について
  • 本書の対象読者
  • アクセシビリティー
  • 本書で使用されている規則と用語

  • 概説

  • WebSphere Application Server Edge Components の紹介
  • Caching Proxy
  • Load Balancer
  • Dispatcher
  • Content Based Routing
  • Site Selector
  • Cisco CSS Controller
  • Nortel Alteon Controller
  • Metric Server
  • Edge Components および WebSphere ファミリー
  • Tivoli Access Manager
  • WebSphere Portal Server
  • WebSphere Site Analyzer
  • WebSphere Transcoding Publisher
  • Application Server および Edge components の詳細情報

  • Edge Components の概念および説明

  • キャッシング
  • Caching Proxy の基本構成
  • リバース Caching Proxy (デフォルト構成)
  • フォワード Caching Proxy
  • 拡張キャッシング
  • ロード・バランシングが行われた Caching Proxy クラスター
  • 動的コンテンツのキャッシュ
  • その他のキャッシング機能
  • ネットワーク・パフォーマンス
  • ネットワーク・ハードウェア
  • メモリーに関する考慮事項
  • ハード・ディスクに関する考慮事項
  • ネットワークに関する考慮事項
  • CPU に関する考慮事項
  • ネットワーク・アーキテクチャー
  • Web サイトの人気とプロキシー・サーバーの負荷に関する考慮事項
  • トラフィック・タイプに関する考慮事項
  • 可用性
  • ロード・バランシング
  • 複数のコンテンツ・ホストのロード・バランシング
  • 複数のリバース・プロキシー・サーバーのロード・バランシング
  • 複数のフォワード・プロキシー・サーバーのある Load Balancer
  • フェイルオーバー・サポート
  • Content Based Routing

  • シナリオ

  • 企業消費者間ネットワーク
  • フェーズ 1
  • フェーズ 2
  • フェーズ 3
  • 企業クライアント間バンキング・ソリューション

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

  • Edge Components のインストール

  • Edge Components の要件
  • ハードウェアおよびソフトウェアの前提条件
  • Caching Proxy の「構成および管理」フォームでのブラウザーの使用
  • Load Balancer のオンライン・ヘルプでのブラウザーの使用
  • セットアップ・プログラムを使用した Edge Components のインストール
  • Windows 用セットアップ・プログラムの使用
  • Linux および UNIX 用セットアップ・プログラムの使用
  • システム・パッケージ化ツールを使用した Caching Proxy のインストール
  • システム・ツールを使用した Caching Proxy のアンインストール
  • システム・パッケージ化ツールを使用した Load Balancer のインストール
  • AIX へのインストール
  • インストールする前に
  • インストール手順
  • HP-UX へのインストール
  • インストールする前に
  • インストール手順
  • Linux へのインストール
  • インストールする前に
  • インストール・ステップ
  • Solaris へのインストール
  • インストールする前に
  • インストール・ステップ

  • Edge Components の更新

  • AIX、HP-UX、Linux、および Solaris オペレーティング・システムでの Caching Proxy の更新
  • 作業を開始する前に
  • AIX、HP-UX、Linux、または Solaris オペレーティング・システムへの Caching Proxy のパッケージのインストール
  • Windows オペレーティング・システムでの Caching Proxy の更新

  • 更新の拒否

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

  • Caching Proxy ネットワークの構築
  • ワークフロー
  • 必須コンピューター・システムおよびソフトウェアの確認
  • サーバー 1 の作成 (Linux および UNIX システム)
  • サーバー 1 の作成 (Windows システム)
  • サーバー 1 の構成
  • Caching Proxy ネットワークのテスト
  • Load Balancer ネットワークの構築
  • ワークフロー
  • 必須コンピューター・システムおよびソフトウェアの確認
  • ネットワークの構成
  • Dispatcher の構成
  • コマンド行を使用した構成
  • 構成ウィザードを使用した構成
  • グラフィカル・ユーザー・インターフェース (GUI) を使用した構成
  • Load Balancer ネットワークのテスト

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

    本書について

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


    本書の対象読者

    WebSphere Application Server Edge Components の概念、計画とインストール」は、オペレーティング・システムと、インターネット・サービスの提供に精通した経験豊富なネットワーク管理者およびシステム管理者を対象にしています。 WebSphere Application Server または WebSphere Application Server Edge Components の使用経験は必要ありません。


    アクセシビリティー

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


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

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

    表 1. 本書で使用されている規則

    規則 意味
    太字 グラフィカル・ユーザー・インターフェース (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 Application Server Edge Components の紹介

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

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

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

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

    WebSphere Application Server には、Edge Components として Caching Proxy および Load Balancer が含まれています。


    Caching Proxy

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

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

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

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

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

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


    Load Balancer

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

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

    Load Balancer は、クライアントからのデータ要求をインターセプトして、現在各要求を満たすのに最も適しているサーバーに各要求を転送します。 つまり、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 には以下のコンポーネントが組み込まれています。

    Dispatcher

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

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

    Content Based Routing

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

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

    Site Selector

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

    このコンポーネントはすべての Edge Components インストール済み環境でサポートされていますが、以下の例外があります。

    Cisco CSS Controller

    注:
    IPv4 用の Load Balancer のバージョン 7.0 には、Cisco CSS Controller コンポーネントが用意されていますが、このコンポーネントは比較的新しいハードウェアをサポートしない場合があります。 サポートされているハードウェアに関する前提条件のページ (http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921) を参照してください。

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

    このコンポーネントはすべての Edge Components インストール済み環境でサポートされていますが、以下の例外があります。

    Nortel Alteon Controller

    注:
    IPv4 用の Load Balancer のバージョン 7.0 には、Nortel Alteon Controller コンポーネントが用意されていますが、このコンポーネントは比較的新しいハードウェアをサポートしない場合があります。 サポートされているハードウェアに関する前提条件のページ (http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921) を参照してください。

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

    このコンポーネントはすべての Edge Components インストール済み環境でサポートされていますが、以下の例外があります。

    Metric Server

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


    Edge Components および WebSphere ファミリー

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

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


    Tivoli Access Manager

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


    WebSphere Portal Server

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

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


    WebSphere Site Analyzer

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


    WebSphere Transcoding Publisher

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


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

    WebSphere Application Server Edge Components 用の以下の資料は、Edge Components インフォメーション・センターで入手することができます。

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

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

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


    Edge Components の概念および説明

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

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

    キャッシング

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

    可用性

    Content Based Routing


    キャッシング

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。


    Caching Proxy の基本構成

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

    リバース Caching Proxy (デフォルト構成)

    リバース・プロキシー構成を使用する際、Caching Proxy マシンは、インターネットと企業のコンテンツ・ホストとの間に配置されます。 プロキシー・サーバーは代理として機能し、インターネットから到着したユーザー要求をインターセプトして、それを適切なコンテンツ・ホストに転送し、戻りデータをキャッシュに入れてから、そのデータをインターネット経由でユーザーに引き渡します。 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 が動的に生成したコンテンツをキャッシュに入れて供給する機能もあります。

    フォワード Caching Proxy

    エンド・ユーザーへ直接インターネット・アクセスを提供することは、非常に非効率になる可能性があります。 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 (Linux システムのみ)

    フォワード Caching Proxy の変化形が透過 Caching Proxy です。 このロールの Caching Proxy は、基本のフォワード Caching Proxy と同じ機能を実行しますが、機能が実行されたことをクライアントが認識することはありません。 透過 Caching Proxy 構成は、Linux システムでのみサポートされています。

    フォワード Caching Proxy で説明した構成では、各クライアント・ブラウザーはそれぞれ個別に、特定のフォワード Caching Proxy に要求を送信するように構成されています。 このような構成を維持することは、 クライアント・マシンが多数ある場合には、とりわけ不都合なものになる可能性があります。 Caching Proxy では、管理を単純化するいくつかの代替手段をサポートしています。 1 つは、図 3 に示すように、透過プロキシーとして Caching Proxy を構成する方法です。通常のフォワード Caching Proxy と同様、透過 Caching Proxy はゲートウェイ近くのマシンにインストールしますが、クライアント・ブラウザー・プログラムは、フォワード Caching Proxy に要求を送信するようには構成されません。 クライアントは、構成にプロキシーが存在することを認識しません。 代わりに、クライアント要求をインターセプトして、それらの要求を透過 Caching Proxy に送信するようにルーターが構成されます。 1 という番号が付いたマシンのうちの 1 台で動作するクライアントが、コンテンツ・ホスト (6) に保管されているファイル X を要求すると、ルーター (2) はその要求を Caching Proxy に渡します。 Caching Proxy は、自身の IP アドレスを発信アドレスとして持つ新規要求を生成し、ルーター (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 準拠です。


    拡張キャッシング

    ロード・バランシングが行われた Caching Proxy クラスター

    より高度なキャッシング機能を利用するには、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 には、その他にも以下の重要な拡張キャッシング機能があります。


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

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

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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。


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

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

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

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

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

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

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

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

    CPU に関する考慮事項

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


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

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

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

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

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

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

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

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


    可用性

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。


    ロード・バランシング

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

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

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

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

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

    ここに示されたグラフィックは、複数のコンテンツ・ホストのロード・バランシングを示しています。

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

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

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

    Load Balancer の Dispatcher は、複数の Caching Proxy マシンのロード・バランスを取ることもできます。 企業の Web サイトの人気がある場合、単一のプロキシー・サーバーによって効率的に処理できる量を超える要求がコンテンツに対して寄せられて、プロキシー・サーバーのパフォーマンスを低下させる可能性があります。

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

    図 6. 複数のリバース・プロキシー・サーバーおよびコンテンツ・ホストのロード・バランシング

    ここに示されたグラフィックは、複数のプロキシー・サーバーおよびコンテンツ・ホストのロード・バランシングを示しています。

    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 をバイパスしてブラウザーに転送します。

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

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

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

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

    注:
    透過プロキシー・フィーチャーは、Linux システムでのみ使用可能です。

    図 7. 複数のキャッシング・プロキシーをロード・バランシングするための Dispatcher の使用。

    このグラフィックは、複数のプロキシーのロード・バランシングを示しています。

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

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

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

    図 8. ハイ・ アベイラビリティーのインターネット・アクセスを提供するための 1 次およびバックアップ Dispatcher の使用。

    このグラフィックは、複数のプロキシーのロード・バランスを取る 1 次およびバックアップの Dispatcher を示しています。

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

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

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

    図 9. Caching Proxy マシンにバックアップ Dispatcher を配置する

    このグラフィックは、複数のプロキシーのロード・バランスを取る 1 次およびバックアップの Dispatcher を示しています。


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

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

    図 10. 1 次 Load Balancer およびバックアップ Load Balancer の使用による Web コンテンツのハイ・ アベイラビリティーの確保

    ここに示されたグラフィックは、1 次 Dispatcher およびバックアップ Dispatcher の使用による 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 を配置する

    ここに示されたグラフィックは、コンテンツ・ホスト上で実行されるバックアップ Dispatcher を示しています。


    Content Based Routing

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

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

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

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

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

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

    図 12. CBR による HTTP 要求の経路指定

    ここに示されたグラフィックは、CBR による HTTP 要求の経路指定を示しています。

    図 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 要求のロード・バランシング

    ここに示されたグラフィックは、CBR により経路指定された HTTP 要求のロード・バランシングを示しています。

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


    シナリオ

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

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

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

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

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


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

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

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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。


    フェーズ 1

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

    図 14. 企業消費者間ネットワーク (フェーズ 1)

    このグラフィックは、基本的な企業消費者間ネットワークのサンプルを示しています。


    フェーズ 2

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

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

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

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

    図 15. 企業消費者間ネットワーク (フェーズ 2)

    このグラフィックは、企業消費者間ネットワークのサンプルを示しています。


    フェーズ 3

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

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

    図 16. 企業消費者間ネットワーク (フェーズ 3)

    このグラフィックは、企業消費者間ネットワークのサンプルを示しています。


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

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

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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。

    図 17. 企業消費者間バンキング・ソリューション

    このグラフィックは、企業消費者間バンキング・ソリューションのサンプルを示しています。


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

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

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

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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。

    図 18. Web ポータル

    このグラフィックは、Web ポータルのサンプルを示しています。


    Edge Components のインストール

    この部では、Edge Components のインストール手順について説明します。

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

    Edge Components の要件

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

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

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


    Edge Components の要件

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


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

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

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


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

    ブラウザーの最小要件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。


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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。

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

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

      AIX(R) の場合:

      installp -acXd ./packagename
      

      HP-UX の場合:

      swinstall -s source/ packagename
      

      Linux の場合:

      rpm -i ./packagename
      

      Solaris の場合:

      pkgadd -d ./packagename
      

    表 2. Caching Proxy のコンポーネント

    コンポーネントインストール・パッケージ (推奨順序)
    Caching Proxy
    1. gskit7
    2. icu
    3. admin
    4. msg-cp-lang
    5. cp

    Edge Component 資料

    doc-en_US1

    注:

    1. Load Balancer 資料は、2 つのパッケージで提供されます。 doc-en_US パッケージには Load Balancer 資料を含むすべての Edge Components 資料が含まれており、これらは、../edge/doc/ ディレクトリーに配置されます。 Load Balancer のインストール (システム・パッケージ化ツールを使用した Load Balancer のインストール) に関連した資料パッケージの場合は Load Balancer 資料のみがインストールされ、これらは ../edge/lb/ ディレクトリー内のサブディレクトリーに配置されます。


    表 3. AIX、HP-UX、および Solaris のパッケージ・ファイル名

    総称パッケージ名 AIX ファイル・セット HP-UX ファイル・セットSolaris ファイル名
    admin wses_admin.rte WSES-ADMINWSESadmin
    cp wses_cp.base WSES-CPWSEScp
    docwses_doc.en_US WSES-DOC-en_US WSESdocen
    gskit7gskkm.rte gsk7basgsk7bas
    icu wses_icu.rte WSES-ICUWSESicu
    msg-cp-lang wses_cp.msg.lang1 .baseWSES-cpmlang2 WSEScpmlang3

    注:

    1. AIX の場合、変数 lang は、言語固有コード (en_US、de_CH、de_DE、es_ES、fr_CA、fr_CH、fr_FR、it_CH、it_IT、ja_JP、Ja_JP、ko_KR、pt_BR、zh_CN、ZH_CN、zh_TW、Zh_TW) のいずれかに置き換えます。

    2. HP-UX の場合、変数 lang は、 言語固有コード (de_DE、 en_US、es_ES、fr_FR、it_IT、ja_JP、ko_KR、zh_CN、h_TW) のいずれかに置き換えます。(HP-UX では、ブラジル・ポルトガル語 (pt_BR) はサポートされていません。)

    3. Solaris の場合、変数 lang は、 言語固有コード (br、 cn、 cw、 de、 en、 es、 fr、 it、 ja、 kr) のいずれかに置き換えます。


    表 4. Linux のパッケージ・ファイル名

    総称パッケージ名 Linux ファイル名
    admin WSES_Admin_Runtime-release-version1.hardw2.rpm
    cp WSES_CachingProxy-release-version1.hardw2.rpm
    docWSES_Doc_en_US-release-version1.hardw2.rpm
    gskit7gsk7bas.rpm
    icu WSES_ICU_Runtime-release-version1.hardw2.rpm
    msg-cp-lang WSES_CachingProxy_msg_lang3-release-version1.hardw2.rpm

    注:

    1. release-version は、現行リリースを示します (例えば、6.1.0-0)。

    2. 変数 hardw は、値 i686、s390、ppc64 のいずれかに置き換えられます。

    3. 変数 lang は、言語固有コード (de_DE、en_US、es_ES、fr_FR、it_IT、ja_JP、ko_KR、pt_BR、zh_CN、zh_TW) のいずれかに置き換えられます。

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


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

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

    AIX の場合:

    installp -u packagename
    

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

    installp -u wses

    HP-UX の場合:

    swremove packagename
    

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

    swlist | grep WSES

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

    Linux の場合:

    rpm -e packagename
    

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

    rpm -qa |grep -i  wses
    

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

    Solaris の場合:

    pkgrm packagename
    

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

    pkginfo | grep WSES

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


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

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

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

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

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


    AIX へのインストール

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

    表 5. AIX ファイル・セット

    Load Balancer コンポーネント AIX ファイル・セット
    ベース ibmlb.base.rte
    管理 (メッセージ付き)
    • ibmlb.admin.rte
    • ibmlb.msg.lang.admin

    デバイス・ドライバー ibmlb.lb.driver
    ライセンス ibmlb.lb.license
    Load Balancer コンポーネント (メッセージ付き)
    • ibmlb.component.rte
    • ibmlb.msg.lang.lb

    資料 (メッセージ付き)
    • ibmlb.doc.rte
    • ibmlb.msg.en_US.doc

    Metric Server ibmlb.ms.rte

    注:

    1. 変数 component は次に置き換えることができます。 disp (dispatcher)、 cbr (CBR)、 ss (Site Selector)、 cco (Cisco CSS Controller)、 または nal (Nortel Alteon Controller)。

    2. 変数 lang は、次を置き換えることができます: en_US、de_CH、de_DE、es_ES、fr_CA、fr_CH、fr_FR、it_CH、it_IT、 ja_JP、Ja_JP、ko_KR、pt_BR、zh_CN、ZH_CN、zh_TW、Zh_TW

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

    インストールする前に

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

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

    インストール手順

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

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

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

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

    1. CD からインストールを行う場合は、以下のコマンドを入力して CD をマウントします。
      mkdir /cdrom
      mount -v cdrfs -p -r /dev/cd0 /cdrom
    2. 以下の表を参照して、必要な AIX 用 Load Balancer パッケージをインストールするために入力するコマンド (1 つ以上) を判別してください。

      表 6. AIX のインストール・コマンド

      パッケージ コマンド
      ベース installp -acXgd device ibmlb.base.rte
      管理 (メッセージ付き)installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin
      デバイス・ドライバー installp -acXgd device ibmlb.lb.driver
      ライセンス installp -acXgd device ibmlb.lb.license
      Load Balancer コンポーネント (メッセージ付き)。 Dispatcher、CBR、Site Selector、Cisco CSS Controller、および Nortel Alteon Controller が含まれています。

      installp -acXgd device ibmlb.component.rte

      ibmlb.msg.language.lb

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

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

    unmount /cdrom

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

    lslpp -h | grep ibmlb

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

    ibmlb.base.rte
    ibmlb.admin.rte
    ibmlb.lb.driver
    ibmlb.lb.license
    ibmlb.component.rte
    ibmlb.doc.rte
    ibmlb.ms.rte
    ibmlb.msg.language.admin
    ibmlb.msg.en_US.docibmlb.msg.language.lb
     
    

    Load Balancer のインストール・パスには、以下の内容が含まれています。


    HP-UX へのインストール

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

    インストールする前に

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

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

    インストール手順

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

    表 7. Load Balancer の HP-UX パッケージのインストールの詳細

    パッケージの説明 HP-UX パッケージ名
    ベース ibmlb.base
    管理およびメッセージ ibmlb.admin ibmlb.nlv-lang
    Load Balancer ライセンスibmlb.lic
    Load Balancer コンポーネント ibmlb.component
    資料 ibmlb.doc
    Metric Server ibmlb.ms

    注:

    1. 変数 lang は、次の言語固有コードの次のいずれか 1 つに置き換えます: de_DE、es_ES、fr_FR、it_IT、 ja_JP、ko_KR、zh_CN、zh_TW。

    2. 変数 component は次のいずれか 1 つに置き換えます: disp (dispatcher)、cbr (CBR)、ss (Site Selector)、cco (Cisco CSS Controller)、 または nal (Nortel Alteon Controller)。

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

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

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

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

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

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

      swinstall -s /source package_name
      

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

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

      swinstall -s /source ibmlb.base
      

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

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

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

      swlist -l fileset ibmlb
       
      

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

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

    Load Balancer のインストール・パスには、以下の内容が含まれています。


    Linux へのインストール

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

    インストールする前に

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

    インストール・ステップ

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

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

    2. 次のコマンドを入力して一時ディレクトリーに tar ファイルを展開します。
      tar -xf lblinux-version.tar
      
      その結果、.rpm 拡張子を持った以下の一連のファイルが生成されます。

      各項の内容は以下のとおりです。

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

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

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

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

      注:
      少なくとも 1 つの RPM ファイルで、Java(TM) がインストールされていることと、RPM データベースに登録済みであることが必要になります。 Java がインストールされていても、RPM データベースに登録されていない場合は、以下のように非依存オプションを指定したインストール・コマンドを使用してください。
      rpm -i --nodeps package.rpm 
      
    4. 製品がインストールされたことを検査します。 次のコマンドを入力します。
      rpm -qa | grep ibmlb
      

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

    Load Balancer のインストール・パスには、以下の内容が含まれています。

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


    Solaris へのインストール

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

    インストールする前に

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

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

    pkgrm pkgname
    

    インストール・ステップ

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

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

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

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

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

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

    Load Balancer のインストール・パスには、以下の内容が含まれています。


    Edge Components の更新

    以下のメディアから、AIX、HP-UX、Linux、Solaris オペレーティング・システム、または Microsoft Windows オペレーティング・システム用の Edge Components フィックスパックを入手できます。

    サポートされているオペレーティング・システムに関する情報については、WebSphere Application Server detailed system requirements を参照してください。

    WebSphere Application Server のサポート・サイトでは、Edge Components のリフレッシュ・パックまたはフィックスパックへのリンクが示されています。

    1. アップグレードする修正サービス・リリースを見つけ、リンクをたどってダウンロード・サイトに移動します。
    2. サイトの説明に従って、Edge Components のリフレッシュ・パックをダウンロードします。
    注:
    Edge Components の FTP サーバーから最新の Edge Components フィックスパックをダウンロードすることもできます。

    更新に関する説明については、以下のセクションを参照してください。

    Load Balancer の更新に関する説明については、「Load Balancer for IPv4 管理ガイド」または「Load Balancer for IPv4 and IPv6 管理ガイド」を参照してください。


    AIX、HP-UX、Linux、および Solaris オペレーティング・システムでの Caching Proxy の更新


    作業を開始する前に

    リフレッシュ・パックまたはフィックスパックのインストールを開始する前に、以下の項目について確認してください。


    AIX、HP-UX、Linux、または Solaris オペレーティング・システムへの Caching Proxy のパッケージのインストール

    ご使用のオペレーティング・システム用のパッケージ・インストール・ツールを使用して、正しい順序で Caching Proxy パッケージをインストールします。 すべての Edge Components パッケージおよびそれらのインストール順序のリストについては、表 4 を参照してください。 以下の手順は、この作業を完了するために必要な通常のステップを示したものです。

    1. ローカルのスーパーユーザーである root になります。
      su - root
      Password: password
      
    2. Caching Proxy のプロセスを停止します。
    3. インストール・ファイルがあるディレクトリーに移動します。 例えば、コマンド・プロンプトで以下のように入力します。
      cd download_package_directory/
      
    4. 以下の表に示されたインストール・コマンドを使用して、パッケージをインストールします。 リフレッシュ・パックまたはフィックスパックの各パッケージのインストール順序は、以下のとおりです。
      1. gskit - グローバル・セキュリティー・キット
      2. icu - ICU ランタイム
      3. admin - 管理ランタイム
      4. cp messages - Caching Proxy メッセージ
      5. cp - Caching Proxy
      6. documentation - オプション

      表 8. Caching Proxy をインストールするためのシステム固有のディレクティブ

      Caching Proxy をインストールするためのシステム固有のディレクティブ
      オペレーティング・システム コマンド
      AIX
      installp -acXd source package_name
      

      ここで、source はパッケージの場所を示すディレクトリー、package_name はパッケージの名前です。

      例:

      1. wses_admin.rte という管理パッケージが現行ディレクトリーにある場合、以下のコマンドを実行すると、そのパッケージがインストールされます。
        installp -acXd . wses_admin.rte
        
      2. 管理パッケージが /tmp ディレクトリーにある場合、以下のコマンドを実行すると、そのパッケージがインストールされます。
        installp -acXd /tmp wses_admin.rte
        

      System Management Interface Tool (SMIT) を使用している場合は、以下のようにします。

      1. install_latest」オプションを選択します。
      2. 「ソフトウェアの更新をコミットする」フィールドの値を「はい」に設定します。
      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
      
      注:
      -U オプションは使用しないでください。 ほとんどのパッケージに、--replacefiles オプションが必要です。 このオプションが不要なパッケージにこのオプションを使用しても、インストールに影響はありません。 インストール後、新規パッケージのうち既にインストールされているものは、そのままマシンに残されます。 これらはアンインストールしないでください。
      Solaris
      pkgadd -d source package_name
      

      ここで、source はパッケージの場所を示すディレクトリー、package_name はパッケージの名前です。

      例:

      • WSESadmin という管理パッケージが現行ディレクトリーにある場合、以下のコマンドを実行すると、そのパッケージがインストールされます。
        pkgadd -d . WSESadmin
        
      • 管理パッケージが /tmp ディレクトリーにある場合、以下のコマンドを実行すると、そのパッケージがインストールされます。
        pkgadd -d /tmp WSESadmin
        
      • GSKit をインストールする場合、以下のコマンドを実行すると、前のバージョンに対してパッケージが上書きインストールされます。
        pkgadd -a ./admin -d . gsk7bas
        

      サイレント・インストールを使用するには、-a オプションを使用して、管理ファイルを指定します。 インストールするパッケージに、instadm という管理ファイルが用意されています。

      インストール後、新規パッケージのうち既にインストールされているものは、そのままマシンに残されます。 これらはアンインストールしないでください。

    以下の表は、Caching Proxy が提供しているすべてのパッケージと、それらの必要なインストール順序をリストしたものです。 リフレッシュ・パックまたはフィックスパックに含まれているパッケージを、以下の表に指定された順序に従ってインストールします。

    注:
    ここにリストされているすべてのパッケージが、リフレッシュ・パックまたはフィックスパックに含まれているとは限りません。 リフレッシュ・パックまたはフィックスパックに含まれているパッケージ、およびシステム上に既にインストールされているパッケージのみを更新してください。

    表 9. パッケージのリスト

    パッケージのリスト
    インストールするコンポーネント パッケージの更新順序 (一般的なリスト)
    Caching Proxy
    1. gskit7 -- グローバル・セキュリティー・キット
    2. icu -- ICU ランタイム
    3. admin -- 管理ランタイム
    4. msg-cp-lang -- メッセージ
    5. cp -- Caching Proxy

    Edge Components 資料 doc-lang

    Edge Components の更新をインストールした後も、Edge Components の前の構成が維持されます。 リフレッシュ・パックまたはフィックスパックに新機能や機能拡張が含まれている場合、それらのフィーチャーを有効にするために、構成ファイルにディレクティブを追加しなければならない場合があります。


    Windows オペレーティング・システムでの Caching Proxy の更新

    Caching Proxy のセットアップ・プログラムを以下のようにして使用します。

    1. 現在インストールされている Load Balancer が開始されないように、作成したすべての開始スクリプトで、リブート時に Load Balancer を開始するすべてのコマンドが一時的に抑止されるように編集します。
    2. Load Balancer サービスを「手動」に設定します。
    3. Windows マシンを再始動します。
    4. Edge Components のリフレッシュ・パックまたはフィックスパックをダウンロードします。
    5. 現在、Load Balancer コンポーネントがある場合には、「プログラムの追加と削除」を使用して、これをアンインストールします。
    6. 以下のいずれかの方法でインストール・プログラムを実行します。
    7. インストール・プログラムの要求に従って情報を入力します。

    Edge Components の更新をインストールした後も、Edge Components の前の構成が維持されます。 リフレッシュ・パックまたはフィックスパックに新機能や機能拡張が含まれている場合、それらのフィーチャーを有効にするために、構成ファイルにディレクティブを追加しなければならない場合があります。


    更新の拒否

    更新を拒否するには、以下のようにします。

    大部分のコンポーネントでは、リフレッシュ・パックまたはフィックスパックが除去されると、oldfiles/component ディレクトリーに構成ファイルが保管されます。 再インストールした製品でこれらの構成ファイルを使用すると、パッチ適用前のバージョンでパッチ適用後の構成を維持することができます。


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

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

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

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

    Caching Proxy ネットワークの構築

    Load Balancer ネットワークの構築


    Caching Proxy ネットワークの構築

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

    重要: Caching Proxy はすべての Edge Components インストール済み環境で使用できますが、以下の例外があります。

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

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


    ワークフロー

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

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

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

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


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

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

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

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

    5. サーバー 1 の構成に進みます。

    サーバー 1 の作成 (Windows システム)

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

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

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

    5. サーバー 1 の構成に進みます。

    サーバー 1 の構成

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

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

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

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

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

    Load Balancer ネットワークの構築

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

    図 20. Load Balancer のデモンストレーション・ネットワーク

    クライアント、インターネット・クラウド、Load Balancer マシン、およびアドレスの示された 2 つのローカル接続サーバーを示すグラフィック。

    注:
    ワークステーションを 2 つのみ使用し、Dispatcher を 一方の Web サーバー・ワークステーションに配置して、この構成を完了することができます。 これは連結構成を表します。

    ワークフロー

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

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

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

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


    ネットワークの構成

    1. すべて同じ LAN セグメント上に配置するようにワークステーションをセットアップします。 3 つのマシンの間のネットワーク・トラフィックが、ルーターまたはブリッジを 一切通過する必要がないようにします。
    2. 3 つのワークステーションのネットワーク・アダプターを構成します。 この例では、以下のネットワーク構成を想定しています。
      ワークステーション 名前IP アドレス
      1 server1.company.com9.67.67.101
      2 server2.company.com9.67.67.102
      3 server3.company.com9.67.67.103
      ネットマスク = 255.255.255.0

      各ワークステーションには、標準の イーサネット・ネットワーク・インターフェース・カードが 1 つだけ装備されています。

    3. server1.company.com が server2.company.com と server3.company.com の両方を ping できるようにします。
    4. server2.company.com と server3.company.com が server1.company.com を ping できるようにします。
    5. 2 つの Web サーバー (サーバー 2 およびサーバー 3) の上でコンテンツが同じであることを確認します。 これは、データを両方のワークステーションに複製する方法、NFS、AFS(R)、または DFS(TM) などのファイル共用システムを使用する方法、またはサイトに合ったその他の方法で実行することができます。
    6. server2.company.com および server3.company.com にある Web サーバーが 操作可能であることを確認します。 Web ブラウザーを使用して http://server2.company.com および http://server3.company.com から 直接ページを要求します。
    7. この LAN セグメント用に別の有効な IP アドレスを取得します。 このアドレスは、サイトにアクセスしたいクライアントに与えるアドレスです。 この例では、この情報は次のようになります。
      Name= www.company.com
      IP=9.67.67.104 
      
    8. www.company.com のトラフィックを受け入れるように 2 つの Web サーバー・ワークステーションを構成します。

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

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

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


    Dispatcher の構成

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

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

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

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

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

    2. Dispatcher の executor 機能を開始します。
      dscontrol executor start
      
    3. クラスター・アドレスを Dispatcher 構成に追加します。
      dscontrol cluster add www.company.com
      
    4. http プロトコル・ポートを Dispatcher 構成に追加します。
      dscontrol port add www.company.com:80
    5. 各 Web サーバーを Dispatcher 構成に追加します。
      dscontrol server add www.company.com:80:server2.company.com
      dscontrol server add www.company.com:80:server3.company.com
      
    6. クラスター・アドレスに対するトラフィックを受け入れるようにワークステーションを構成します。

      dscontrol executor configure www.company.com
    7. Dispatcher の manager 機能を開始します。
      dscontrol manager start
      

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

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

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

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

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

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

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

    2. Dispatcher のウィザード機能 dswizard を開始します。

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

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

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

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

    1. dsserver プロセスが実行されていることを確認します。
    2. 次に、以下のいずれかを行います。

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

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