この章では、Caching Proxy 付きの CBR コンポーネントをインストールおよび構成する前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。
本章には、以下のセクションが含まれています。
CBR コンポーネントにより、要求を代行する Caching Proxy を使用して、HTTP および SSL トラフィックをロード・バランシングできます。 CBR を使用すると、cbrcontrol コマンドによって CBR 構成ファイルを使用して構成するサーバーのロード・バランシングを行うことができます。
CBR は、そのコンポーネントの構造の点で Dispatcher とよく似ています。CBR は以下の機能から構成されています。
CBR の 3 つの主要な機能 (executor、manager、および advisor) は相互に対話して、サーバー間の受信要求を平衡化したりディスパッチしたりします。ロード・バランシング要求とともに、executor は、新規接続と活動接続の数をモニターし、この情報を manager に提供します。
CBR コンポーネントを使用すれば、クライアント要求内容の正規表現一致に基づいて要求を処理しなければならない一組のサーバーを指定することができます。CBR を使用すればサイトを区分化することができるため、別のサーバー・セットから別の内容またはアプリケーション・サービスを提供することができます。この区分化は、 サイトにアクセスするクライアントには透過的です。
サイトを分割する方法の 1 つは、CGI 要求だけを処理するためにいくつかのサーバーを割り当てることです。こうすれば、数値計算の cgi スクリプトによってサーバーの通常の HTML トラフィックが低下するのを防止することができるため、クライアントは全般的な応答時間を改善することができます。この方式を使用すれば、通常の要求に対してより強力なワークステーションを割り当てることもできます。これにより、クライアントは、すべてのサーバーをアップグレードすることなしに、よりよい応答時間を得ることができます。また、cgi 要求に対してより強力なワークステーションを割り当てることもできます。
もう 1 つのサイト区分化方法は、登録が必要なページにアクセスするクライアントを 1 つのサーバー・セットに割り当て、その他のすべての要求を別のサーバー・セットに割り当てることです。こうすれば、登録するクライアントが使用すると考えられるリソースをサイトのブラウザーが表示しないようになります。このほか、より強力なワークステーションを使用して、登録済みのクライアントにサービスを提供することもできます。
もちろん、これらの方式を組み合わせて、さらに融通性のある、よりよいサービスを提供することもできます。
CBR では各要求タイプごとに複数のサーバーを指定することができるため、最適のクライアント応答を得るために要求のロード・バランシングを行うことができます。各タイプの内容に複数のサーバーを割り当てることができるため、1 つのワークステーションまたはサーバーが失敗してもユーザーは保護されます。CBR は、この失敗を認識し、引き続きクライアント要求をセット内の他のサーバーでロード・バランシングします。
Caching Proxy は、そのプラグイン・インターフェースを使用して CBR プロセスと通信します。これが機能するために、CBR はローカル・マシン上で 実行していなければなりません。これは 2 つの別個の処理であるため、Caching Proxy の複数インスタンスを実行し、CBR の単一インスタンスを 処理することができます。このセットアップは、複数の Caching Proxy 間でアドレスと機能性を分離させたり、または 複数の Caching Proxy にクライアント・トラフィックを処理させてマシンのリソース使用率を 向上させたりするために構成する場合があります。プロキシー・インスタンスは、トラフィック要件に最も適した内容によって、別々のポート上で listen したり、または同一ポート上で固有の IP アドレスにバインドしたりすることができます。
CBR および Caching Proxy は、指定のルール・タイプを使用して HTTP 要求数を調べます。Caching Proxy は実行中にクライアント要求を受け入れて、最適なサーバーについて CBR コンポーネントに照会します。この照会に基づき、CBR は優先順位が付けられたルールのセットとこの要求を突き合わせます。ルールと一致した場合は、事前に構成されたサーバー・セットから適切なサーバーを選択します。最後に、CBR は選択したサーバーを Caching Proxy に通知し、そのサーバーで要求が代行されます。
あるクラスターのロード・バランシングを行うように定義した場合は、そのクラスターに対するすべての要求にサーバーを選択するルールがあることを確認する必要があります。特定の要求と一致しないルールが見つかると、クライアントは Caching Proxy からエラー・ページを受け取ります。すべての要求をあるルールと一致させるための最も簡単な方法は、「常に真」であるルールを非常に高い優先順位番号で作成することです。このルールによって使用されるサーバーは、それより低い優先順位のルールによって明示的に処理されなかったすべての要求を処理できることを確認してください。(注: 優先順位の低いルールが先に評価されます。)
詳細については、ルール・ベースのロード・バランシングの構成を参照してください。
Caching Proxy 付きの CBR は、クライアントからプロキシーへの (クライアント - プロキシー・サイド) SSL 送信と、プロキシーから SSL サーバーへの (プロキシー - サーバー・サイド) サポート送信を受信できます。SSL 要求をクライアントから受け取るために CBR 構成のサーバー上に SSL ポートを定義すると、セキュア (SSL) サーバーのロード・バランシングを行う CBR を使用して完全セキュア・サイトを保守する機能を得ます。
SSL 暗号化をプロキシー - サーバー・サイドで使用可能にするには、CBR 用の他の ibmproxy.conf ファイルの変更に加えて、Caching Proxy 用に ibmproxy.conf ファイルに構成ステートメントをもう 1 つ追加する必要があります。形式は以下のとおりでなければなりません。
proxy uri_pattern url_pattern address
ここで、uri_pattern は突き合わせるパターンの 1 つ (例: /secure/*) であり、url_pattern は置換 URL (例: https://clusterA/secure/*) であり、さらに address はクラスター・アドレス (例: clusterA) です。
Caching Proxy 付きの CBR がクライアントから SSL 送信を受け取ると、HTTP サーバーに対する SSL 要求を代行する前にその要求を暗号化解除します。CBR が SSL でクライアントとプロキシー間をサポートし、HTTP でプロキシーとサーバー間をサポートするようにするために、cbrcontrol server コマンドにオプションのキーワード mapport があります。サーバー上のポートがクライアントからの着信ポートと異なることを示す必要があるときには、このキーワードを使用してください。以下は、mapport キーワードを使用してポートを追加する例です。ここでクライアントのポートは 443 (SSL) であり、サーバーのポートは 80 (HTTP) です。
cbrcontrol server add cluster:443 mapport 80
mapport のポート番号は、任意の正整数値にできます。デフォルトは、クライアントからの着信ポートのポート番号値です。
CBR はポート 443 (SSL) で構成されているサーバーへの HTTP 要求についてアドバイスできなければならないため、特殊な advisor である ssl2http が提供されています。この advisor はポート 443 (クライアントからの着信ポート) を開始して、そのポートに構成されているサーバーにアドバイスします。クラスターが 2 つ構成されて、各クラスターに異なる mapport で構成されたポート 443 およびサーバーがある場合には、結果的に advisor の単一インスタンスが該当するポートをオープンできます。以下はこの構成の例です。
Executor
Cluster1
Port:443
Server1 mapport 80
Server2 mapport 8080
Cluster2
Port:443
Server3 mapport 80
Server4 mapport 8080
Manager
Advisor ssl2http 443