この付録では、CBR コンポーネント用コンテンツ・ルール (パターン) 構文および Dispatcher コンポーネントの CBR 転送方式の使用方法を、その使用のシナリオおよび例とともに説明します。
適用できるのは、ルール・タイプに "content" を選択した場合だけです。
使用したいパターン構文は、以下の制限を使用して入力します。
予約済みのキーワードの後ろには、必ず等号 『=』 を付けます。
結果的に、ブラウザー・ターゲットの指定 http://www.company.com/path/webpage.htm は次のような値になる可能性があります:
Method=GET
URI=/path/webpage.htm
Version=HTTP/1.1
Host=www.company.com
Connection=Keep-Alive
Referer=http://www.company.com/path/parentwebpage.htm
例えば、次のコマンドが有効であるのは、cbrcontrol>> プロンプトを使用するときか、構成ファイルから使用するときだけです。
rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern "uri=/nipoek/*"
特殊文字を使用するときは、これと同じコマンドがオペレーティング・システムのプロンプトで機能するためには、以下のように、コマンド全体を二重引用符で囲む必要があります。
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern uri=/nipoek/*"
引用符を使用しないと、ルールを CBR に保存するときにパターンの一部が切り捨てされる場合があります。
以下は、パターン構文を使用する場合の使用可能なシナリオおよび例の集合です。
シナリオ 1:
1 つのクラスター名のセットアップには、標準 HTML コンテンツ用の 1 セットの Web サーバー、サーブレット要求用の WebSphere® Application Server のある別の Web サーバーのセット、NSF ファイル用の別の Lotus® Lotus Notes® サーバーのセットなどが必要となります。要求されたこれらのページを区別するためには、クライアント・データへのアクセスが必要です。また、それらを該当するサーバーに送ることも必要です。 コンテンツ・パターン・マッチング・ルールは、これらのタスクを実行するために必要な分離を提供します。要求に必要な分離が自動的に行われるように、一連のルールが構成されます。例えば、次のコマンドは言及された 3 つの分割を実行します。
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1
>>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2
>>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3
>>rule uses cluster1:80:regular server5+server6
NSF ファイルに対する要求が Load Balancer に到着すると、最初にサーブレット・ルールが検査されますが、一致しません。そうすると、この要求は Notes ルールで検査され、一致を戻します。クライアントは、server3 と server4 の間でロード・バランシングされます。
シナリオ 2
別の共通シナリオは、メイン Web サイトがいくつかの異なる内部グループを制御する場合です。例えば、 www.company.com/software には、異なるサーバーのセットおよび www.company.com/hardware 部門からのコンテンツが含まれています。要求はすべてルート www.company.com クラスターには基づいていないので、コンテンツ・ルールは URI の違いを検出してロード・バランシングを完了する必要があります。シナリオのルールは以下のようになります:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1
>>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2
>>rule uses cluster1:80:div2 server3+server4
シナリオ 3
一定の組み合わせは、ルールが検索される順序に依存します。例えば、シナリオ 2 では、クライアントはそれらの要求パスの中のディレクトリーに基づいて分割されますが、ターゲット・ディレクトリーはパスの複数のレベルで現れることがあり、配置上の別の物を意味することがあります。例えば、www.company.com/pcs/fixes/software は、www.company.com/mainframe/fixes/software とは違うターゲットです。ルールは、この可能性を考慮して定義しなければならず、同時に多くのシナリオをキャッチしないようにしなければなりません。例えば、"uri=*/software/*" テストは、この場合のワイルドカード検索には範囲が広すぎます。代わりのルールを次の方法で組み立ててください。
組み合わせ検索を以下の範囲に絞ることができます。
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)"
>>rule uses cluster 1:80:pcs server1
使用する組み合わせがない場合には、順序が重要となります。
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*"
>>rule uses cluster1:80:pc1 server2
"pcs" が後のディレクトリー (最初ではなく) に現れると、2 番目のルールがキャッチされます。
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*"
>>rule uses cluster1:80:pc2 server3
ほとんどすべての場合に、他のルールを失敗させるものをすべてキャッチするために、デフォルトのルール 常に真 を使用してルールを完了する必要があります。このクライアントの他のすべてのサーバーが失敗するシナリオの場合は、これは、『このサイトは現在ダウンしています。後からやり直してください。』というサーバーとなることがあります。
>>rule add cluster1:80:sorry type true priority 100
>>rule uses cluster1:80:sorry server5