コンテンツ・ルール (パターン) 構文

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 が評価する前に、そういった文字を代替テキストに変換する場合があります。 dscontrolcbrcontrol、または構成ファイルからコマンドを入力する場合は、特殊文字の前後に二重引用符 (" ") を使用します。 例えば、次のコマンドが有効であるのは、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
Reference topic    

Terms and conditions for information centers | Feedback

Last updated: May 28, 2013 08:30 AM EDT
File name: rprf_contentsyntax.html