CBR コンポーネントのコンテンツ・ルール (パターン) 構文の使用法を、使用シナリオおよび使用例と共に示します。
コンテンツ・ルール (パターン) 構文
重要: ルール・タイプに content を選択した場合のみ
該当します。
使用したいパターン構文は、以下の制限を使用して入力します。
- パターン内ではスペースを使用できません。
- 特殊文字。ただし、文字の前に円記号 (¥) が付けられている場合は除きます。
- *
- ワイルドカード (任意の文字の 0 から x と一致)
- (
- 論理グループ化に使用される左括弧
- )
- 論理グループ化に使用される右括弧
- &
- 論理 AND
- |
- 論理 OR
- !
- 論理 NOT
予約済みキーワード
予約済みのキーワードの後ろには、必ず等号「=」を付けます。
- Method
- 要求の中の HTTP メソッド (例: GET、POST)
- URI
- URL 要求のパス (大/小文字を区別する)
- Version
- 要求の特定のバージョン。HTTP/1.0 または HTTP/1.1 のいずれか
- Host
- ホストからの値: ヘッダー (大/小文字を区別しない)
重要: HTTP/1.0 プロトコルでは任意指定
- <key>
- Dispatcher が検索できる任意の有効な HTTP ヘッダー名。HTTP ヘッダー
の例には、User-Agent、Connection、Referrer などがあります。
例えば、
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 が評価する前に、そういった文字を代替テキストに変換する場合があります。
dscontrol、
cbrcontrol、または構成ファイルからコマンドを入力する場合は、特殊文字の前後に二重引用符 (
" ") を使用します。
例えば、次のコマンドが有効であるのは、
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 コンテンツ用の Web サーバーのセット、サーブレット要求用の WebSphere® Application Server の Web サーバーのセット、および、NSF ファイル用の 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
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