Cisco Content Services Switch コンテント ロード バランシング コンフィギュレーション ガイド Software Version 7.50
コンテンツ ルールの設定
コンテンツ ルールの設定
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 3MB) | フィードバック

目次

コンテンツ ルールの設定

コンテンツ ルールの概要

コンテンツ ルールの階層

レイヤ 5 ルールの一致優先順位

コンテンツ ルール設定のクイック スタート

コンテンツ ルール名の設定と所有者への割り当て

仮想 IP アドレスの設定

ドメイン名コンテンツ ルールの設定

複数のドメイン名とコンテンツ ルールの照合

ドメイン名と VIP アドレスを使用したコンテンツ ルールの設定

ドメイン名コンテンツ ルールでのワイルドカードの使用

コンテンツ ルールでのドメイン名ワイルドカードの一般的なガイドライン

ドメイン修飾子リストの設定

DQL の作成

DQL の説明の記述

DQL へのドメインの追加

コンテンツ ルールへの DQL の追加

コンテンツ ルールからの DQL の削除

DQL 設定の表示

仮想 Web ホスティングの設定

コンテンツ ルールへのサービスの追加

コンテンツ ルールへのサービスの追加

サービスの重みの指定

コンテンツ ルールへのプライマリ ソーリー サーバの追加

コンテンツ ルールへのセカンダリ ソーリー サーバの追加

コンテンツ ルールへの DNS 名の追加

コンテンツ ルールでの DNS の無効化

コンテンツ ルールのアクティブ化

コンテンツ ルールの一時停止

コンテンツ ルールの削除

コンテンツ ルールからのサービスの削除

プロトコルの設定

ポートの設定

ロード バランシングの設定

DNS バランス タイプの設定

ホットリストの設定

ドメイン ホットリストの設定

HTTP メソッド解析の設定

RFC-2518 拡張メソッド解析の設定

ユーザ定義メソッドの設定

HTTP メソッド解析の設定および状態の表示

拡張子修飾子リストの設定

URL での EQL の指定

EQL の拡張子と説明の表示

URL 修飾子リストの設定

URQL 設定のクイック スタート

URQL の作成

URQL での URL の設定

URL エントリの指定

URL の定義

URL の説明の記述

URQL での URL のドメイン名の指定

コンテンツ ルールへの URQL の追加

URQL の説明の記述

URQL のアクティブ化

URQL の一時停止

startup-config ファイル内の URQL 設定

URQL の表示

Uniform Resource Locator(URL)の指定

URL での拡張子修飾子リストの指定

一度に解析するパケットの数の指定

負荷しきい値の指定

CSS の Ping 応答決定へのサービス組み込み

TCP フローのリセット拒否の許可

持続性、再マッピング、およびリダイレクションの設定

コンテンツ ルールの持続性の設定

バイパスの持続性の設定

HTTP リダイレクションとサービスの再マッピングの設定

コンテンツへの要求のリダイレクション

HTTP 302 リダイレクト メッセージへの TCP FIN フラグまたは RST フラグの設定

持続性の設定の表示

フェールオーバーの定義

アプリケーション タイプの指定

FTP 接続のコンテンツ ルールの設定

FTP で標準以外のポートを使用するための CSS の設定

コンテンツ要求による透過キャッシュのバイパスの許可

コンテンツの表示

コンテンツ ルールの表示

コンテンツ ルールでのカウンタのクリア

コンテンツ ルールのカウンタのクリア

コンテンツ ルールでのサービス統計情報カウンタのクリア

以降の内容について

コンテンツ ルールの設定

この章では、コンテンツ ルールの作成および設定方法について説明します。この章の内容は、特に指定のない限り、すべての CSS モデルに共通です。

この章の主な内容は次のとおりです。

コンテンツ ルールの概要

コンテンツ ルール名の設定と所有者への割り当て

仮想 IP アドレスの設定

ドメイン名コンテンツ ルールの設定

コンテンツ ルールへのサービスの追加

コンテンツ ルールのアクティブ化

コンテンツ ルールの一時停止

コンテンツ ルールの削除

コンテンツ ルールからのサービスの削除

プロトコルの設定

ポートの設定

ロード バランシングの設定

DNS バランス タイプの設定

ホットリストの設定

HTTP メソッド解析の設定

拡張子修飾子リストの設定

URL 修飾子リストの設定

Uniform Resource Locator(URL)の指定

一度に解析するパケットの数の指定

負荷しきい値の指定

CSS の Ping 応答決定へのサービス組み込み

TCP フローのリセット拒否の許可

持続性、再マッピング、およびリダイレクションの設定

フェールオーバーの定義

アプリケーション タイプの指定

コンテンツ要求による透過キャッシュのバイパスの許可

コンテンツの表示

コンテンツ ルールの表示

コンテンツ ルールでのカウンタのクリア

サービスと所有者、およびコンテンツ ルール間の関係については、 「コンテンツ ロード バランシングの概要」 を参照してください。

コンテンツ ルールの概要

CSS はコンテンツ ルールを使用して、次の内容を判断します。

コンテンツが物理的に存在する場所(ローカルまたはリモート)

コンテンツ要求を送信する場所(サービス(複数可))

使用するロード バランシング方式

ルールのタイプは、ルールが機能するレイヤも意味します。

レイヤ 3 コンテンツ ルールは、送信先のホストまたはネットワークの IP アドレスを使用します。

レイヤ 4 コンテンツ ルールでは、送信先 IP アドレス、プロトコル、およびポートの組み合わせを使用します。

レイヤ 5 コンテンツ ルールは、送信先 IP アドレス、プロトコル、ポートおよび URL の組み合わせを使用します。HTTP クッキーまたはドメイン名を使うこともできます。

コンテンツ ルールの階層

コンテンツ ルールは、階層になっています。つまり、コンテンツへの要求が複数のルールに一致する場合、最も具体的なルールの特性がそのフローに適用されます。CSS では、次の優先順位を使用してコンテンツへの要求を処理します。最も一致度の高いものが 1、最も一致度が低いものが 9 です。コンテンツ ルールの階層は次のとおりです。

1. ドメイン名、IP アドレス、プロトコル、ポート、URL

2. ドメイン名、プロトコル、ポート、URL

3. IP アドレス、プロトコル、ポート、URL

4. IP アドレス、プロトコル、ポート

5. IP アドレス、プロトコル

6. IP アドレス

7. プロトコル、ポート、URL

8. プロトコル、ポート

プロトコル

レイヤ 5 ルールの一致優先順位

レイヤ 5 コンテンツ ルールでは、CSS は IP アドレス、プロトコル、およびポート番号の照合後、さらに URL を照合します。レイヤ 5 コンテンツ ルールで HTTP ヘッダー フィールド グループを使用すると、URL だけを定義する場合に比べ、より具体的なルールを作成できます。HTTP ヘッダー フィールド グループの設定方法の詳細については、 「HTTP ヘッダー ロード バランシングの設定」 を参照してください。

コンテンツ ルールは階層構造になっているため、コンテンツの要求が複数のルールに一致した場合は、最も具体的なルールの特性がフローに適用されます。レイヤ 5 コンテンツ ルールの場合、CSS は次の優先順位に従ってコンテンツ要求を処理します。最も一致度の高いものが 1、最も低いものが 10 です。

1. ヘッダー フィールド グループが設定された URL 全体(/test/index.html など)

2. URL 全体(/test/index.html など)

3. ヘッダー フィールド グループが設定された URL のファイル名部分のワイルドカード指定(/test/ind*、/test/index.h* など)

4. ワイルドカードを適用する前に部分パスが一致する URL のファイル名部分のワイルドカード指定(/test/ind*、/test/index.h* など)

5. ヘッダー フィールド グループが設定された URL の拡張子付きワイルドカード指定(/test/*.html など)

6. URL の拡張子付きワイルドカード指定(/test/*.html など)

7. ヘッダー フィールド グループが設定された Extension Qualifier List(EQL; 拡張子修飾子リスト)のワイルドカード指定("/test/*" eql EQL_LIST など)。EQL の詳細については、「拡張子修飾子リストの設定」の項を参照してください。

8. EQL のワイルドカード指定("/test/*" eql EQL_LIST など)

9. ヘッダー フィールド グループが設定された URL の部分的なワイルドカード指定(/test/* など)

10. 部分パスの一致に関係なくパス全体がワイルドカード指定された URL の部分的なワイルドカード指定(/test/* など)

次に示す 2 つのコンテンツ ルール例(ruleWap、ruleNoWap)は、ruleWap がヘッダー フィールド グループを含むことを除けば、互いに同一です。

ruleWap :HTTP ヘッダーに MSISDN フィールド(ヘッダー フィールド グループ設定で定義)を含み、TCP ポート 80 から VIP 192.168.128.151 宛てに送信されるすべてのトラフィックに一致する。

ruleNoWap :HTTP ヘッダーに MSISDN フィールドを含まず、TCP ポート 80 から VIP 192.168.128.151 宛てに送信されるすべてのトラフィックに一致する。

ruleWap コンテンツ ルールにはヘッダー フィールド グループが含まれるため、CSS はruleNoWap より先に、このコンテンツ ルールでトラフィックを照合します。

header-field-group wap
header-field 1 msisdn exist
 
owner arrowpoint
content ruleWap
vip address 192.168.128.151
protocol tcp
port 80
url “/*”
add service server1
add service server2
header-field-rule wap
active
 
content ruleNoWap
vip address 192.168.128.151
protocol tcp
port 80
url “/*”
add service server21
add service server22
active

コンテンツ ルール設定のクイック スタート

表 10-1 に、レイヤ 3 コンテンツ ルールを作成して設定するために必要な手順の概要を示します。それぞれの手順には、作業に必要となる CLI コマンドも示しています。各機能の完全な説明とすべてのコンテンツ ルールの設定オプションについては、 表 10-1 以降の項を参照してください。

コンテンツ ルールに使用するサービスと所有者がすでに作成されていることを確認します。 表 10-1 のコマンド例では、所有者 arrowpoint にレイヤ 3 コンテンツ ルールを作成しています。

 

表 10-1 コンテンツ ルール設定のクイック スタート

作業とコマンドの例

1. config と入力して設定モードに入ります。

# config
(config)#

2. コンテンツ ルールを作成する対象となる所有者の所有者モードに入ります。

(config)# owner arrowpoint

3. この所有者のコンテンツ ルールを作成します。

(config-owner[arrowpoint])# content rule1
 

CSS は所有者コンテンツ ルール モードに入ります。

(config-owner-content[arrowpoint-rule1]#

4. 所有者のコンテンツの VIP アドレスまたはドメイン名を設定します。次の例では、VIP アドレスを設定します。これは、このルールが、レイヤ 3 コンテンツ ルールであることを示します。

(config-owner-content[arrowpoint-rule1]# vip address 192.168.3.6
 

レイヤ 4 コンテンツ ルールが必要な場合は、コンテンツ ルールのプロトコルを指定して、TCP/UDP ポート番号を指定します(VIP アドレスまたはドメイン名の指定後に)。

(config-owner-content[arrowpoint-rule1]# protocol tcp
(config-owner-content[arrowpoint-rule1]# port 80
 

レイヤ 5 コンテンツ ルールが必要な場合は、コンテンツ ルールの URL を指定します(プロトコルとポート番号の指定後に)。

(config-owner-content[arrowpoint-rule1]# url “//www.arrowpoint.com/*”

5. ロード バランシングのタイプを指定します。

(config-owner-content[arrowpoint-rule1]# balance aca

6. 設定済みのサービスをコンテンツ ルールに追加します。

(config-owner-content[arrowpoint-rule1]# add service serv1
(config-owner-content[arrowpoint-rule1]# add service serv2

7. コンテンツ ルールを有効にします。

(config-owner-content[arrowpoint-rule1]# active

8. コンテンツ ルールを表示します(オプション)。

(config-owner-content[arrowpoint-rule1]# show rule

表 10-1 に示した各コマンドを実行すると、次のような実行設定が得られます。

!*************************** OWNER ***************************
owner arrowpoint
address "200 Beaver Brook Road, Boxborough, MA 01719"
 
content rule1
add service server1
vip address 192.168.3.6
balance aca
add service serv2
protocol tcp
port 80
url "//www.arrowpoint.com/"

コンテンツ ルール名の設定と所有者への割り当て

コンテンツ ルールを所有者に割り当てることにより、コンテンツへのアクセスを管理することができます。対象となる所有者のモードでコンテンツ ルールを作成して、コンテンツ ルールを所有者に割り当てます。CSS は、ユーザが割り当てた名前でコンテンツ ルールを識別します。

コンテンツ ルールに名前を付け、所有者へ割り当てるには、 content コマンドを使用します。コンテンツ ルールの名前は 1~31 文字で入力します。


) CSS はコンテンツ ルールの名前として、31 文字以下の文字列をサポートしています。コンテンツ ルールに基づく DNS 設定では、CSS ピアが APP セッションを通じてコンテンツ ルールを共有します。CSS はピアからコンテンツ ルールを学習するときに、コンテンツ ルール名に @ 記号と CSS ピアの VIP アドレスを付加します。その結果、元のコンテンツ ルールの名前とピアの VIP アドレスの長さによっては、学習したコンテンツ ルールの名前が 31 文字を超えてしまう可能性があります。

その場合、CSS は学習したコンテンツ ルールの名前が 31 文字になるまで、名前の先頭から文字を切り捨てます。コンテンツ ルールに基づく DNS 設定で、コンテンツ ルール名の長さが 15 文字を超える場合は、この切り捨て処理で生成されるコンテンツ ルール名が既存のルール名と同じになり、どちらのコンテンツ ルールも使用できない事態に陥るおそれがあります。このような事態を回避するためにも、コンテンツ ルール名の末尾には、常に一意の文字を使用してください。


下記の例では、次のように割り当てています。

名前 rule1 をコンテンツ ルールへ

コンテンツ ルール rule1 を所有者 arrowpoint へ

(config-owner[arrowpoint])# content rule1
 

コンテンツ ルールを所有者に割り当てると、次のように CLI プロンプトが変わり、割り当てた所有者とコンテンツ ルールのモードになります。

(config-owner-content[arrowpoint-rule1])#
 

所有者モードとコンテンツ モードでは、コンテンツへの要求の処理方法を設定できます。既存のコンテンツ ルールを所有者から削除するには、次のように所有者モードで no content コマンドを入力します。たとえば、次のように入力します。

(config-owner[arrowpoint])# no content rule1

仮想 IP アドレスの設定

VIP アドレスとは、インターネット上の Domain Name System(DNS; ドメイン ネーム システム)が、ドメイン名の解決要求に応じて提供するアドレスです。たとえば、DNS サーバは、 www. arrowpoint.com を、VIP アドレス 192.217.4.15 などに変換します。Internet Service Provider(ISP; インターネット サービス プロバイダ)が、通常 VIP アドレスを割り当てます。ISP は、Internet Assigned Numbers
Authority(IANA)に VIP アドレスを要求します。

VIP アドレスを所有者のコンテンツ ルールに割り当てることにより、CSS は Network Address Translation(NAT; ネットワーク アドレス変換)を使用して、VIP アドレスをコンテンツが存在するサービスの IP アドレスに変換できるようになります。


) CSS では、VIP アドレスの代わりにドメイン名を設定することができます。ドメイン名の設定方法については、次の項を参照してください。コンテンツ ルールには、VIP アドレスとドメイン名のいずれか、またはそれらの両方を設定することができます。


CSS が、所有者のインターネット IP アドレスを、コンテンツが存在するサービスの IP アドレスに変換できるようにするには、その所有者のコンテンツ ルールに VIP アドレスを設定します。VIP アドレスがサービスの IP アドレスに変換されることにより、ネットワーク セキュリティが強化されます。これは、インターネット ユーザが私設ネットワークの IP アドレスにアクセスできなくなるためです。


注意 すべての VIP アドレスが一意の IP アドレスであることを確認してください。ネットワークにすでに存在する IP アドレス、または Address Resolution Protocol(ARP; アドレス解決プロトコル)の静的エントリと同じアドレスを、VIP アドレスに設定しないでください。


) CSS は、アクティブ-バックアップ VIP 冗長と仮想インターフェイス冗長を持つ環境にある Cisco CSS 11500 シリーズのピアで Adaptive Session Redundancy(ASR; 適応型セッションの冗長性)をサポートします。これにより、既存フローのステートフル フェールオーバーが可能になります。ASR の詳細については、『Cisco Content Services Switch Global Server Load-Balancing Configuration Guide』を参照してください。



) VIP アドレスを使わずにルールを設定した場合(ワイルドカード VIP ルール)、ルールは、設定した他のルールのアトリビュート(たとえば、ポートやプロトコル)に一致するすべての VIP アドレスに一致します。VIP アドレスとポートを使わずにルールを設定した場合(ダブルワイルドカード キャッシング ルール)、ルールは、設定した他のルールのアトリビュート(たとえば、プロトコル)に一致するすべての VIP アドレスまたはポートに一致します。ダブルワイルドカード キャッシング ルールの詳細については、 「キャッシングの設定」を参照してください。このようなタイプのルールを必要とする設定を行った場合は、クライアントの要求がサーバの IP アドレスに直接接続するものでも、その要求は、このルールと一致するので注意してください。


vip address コマンドには、次の変数とオプションがあります。

ip_address (または host :コンテンツ ルールの IP アドレスまたは名前。IP アドレスはドット付き 10 進表記(たとえば、192.168.11.1)またはニーモニック ホスト名(たとえば、myhost.mydomain.com)で入力します。

CSS では、コンテンツ ルールの VIP アドレスと IP アドレスは、A、B、C のいずれかのクラスに限定されます。マルチキャスト アドレス(クラス D および E)や、アドレス上限を超える範囲の IP アドレスは許可されません。

range number :range オプションとその変数を使用して、VIP アドレスから始まる IP アドレスの範囲を指定できる。1~65535 の数値を入力します。デフォルトの範囲は 1 です。 ip_or_host 変数は、範囲の最初のアドレスです。たとえば、範囲 10 で VIP アドレスに 172.16.3.6 を指定すると、VIP アドレスの範囲は 172.16.3.6~172.16.3.15 になります。

ソース グループ内のポート マッパーを、コンテンツ ルールと同じ VIP アドレスで設定する場合は、ポート マッパーとコンテンツ ルールの両方を、同じ VIP アドレス範囲で設定する必要があります。

ポート マッパーの最大 VIP アドレス範囲は 255 です。255 より大きい VIP アドレス範囲でルールを作成する必要が生じた場合は、255 以下の範囲でルールを複数作成してください。


) FTP コンテンツ ルールに VIP アドレスの範囲を設定して使用する場合は、対応するソース グループも同じ VIP アドレス範囲で設定する必要があります( 「サービスの設定」参照)。


VIP アドレスを設定するには、 vip address コマンドで IP アドレスまたはホスト名を指定します。次にコマンドの入力例を示します。

(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6
 

) VIP アドレスに ping を送ると、CSS は、稼働中のサービス、稼働中のソーリー サーバ、または VIP アドレスに対して設定されたリダイレクト文字列のいずれかが存在する場合、あるいはサービスがソース グループに関連付けられている場合だけに応答します。サービスまたはソーリー サーバがダウンしており、VIP アドレスにリダイレクト文字列を定義していない場合は、ping に応答しません。


範囲が 10 の VIP アドレスを設定するには、 vip address コマンドで range オプションを使用します。次に例を示します。

(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6 range 10
 

vip address range コマンドを使用する場合は、使用しているサブネット内の IP アドレスを使用します。CSS では、回線のサブネット上に存在しない IP アドレスに対しては、ARP は使用されません。たとえば、回線を 10.10.10.1/24 に設定し、VIP アドレスの範囲を 10.10.10.2 range 400 として設定した場合、10.10.10.254 を超える範囲の IP アドレスは ARP での解決対象になりません。これと同じ例で、VIP アドレスの範囲を 200 に設定した場合は、この範囲のすべての IP アドレスが ARP での解決対象になります。コンテンツ ルールから VIP アドレスを削除するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no vip address
 

図 10-1 は、VIP アドレスの設定例です。この例では、ユーザが arrowpoint のコンテンツを要求しています。コンテンツは、IP アドレスが 10.3.6.1 のサーバに物理的に存在しています。コンテンツ ルールに VIP アドレス 158.37.6.0 を設定することにより、CSS は、この VIP アドレスをコンテンツが実際に存在するサーバの IP アドレスに変換します。内部 IP アドレスは外部からわかりません。

図 10-1 仮想 IP アドレスの設定例

 

ドメイン名コンテンツ ルールの設定

CSS では、コンテンツ ルールに VIP アドレスの代わりにドメイン名を使用することができます。また、ドメイン名と VIP アドレスの両方を使うこともできます。コンテンツ ルールにドメイン名を使用すると、次のような利点があります。

ドメイン名から IP へのマッピングに依存しないで、サービスをプロビジョニングできる。

ドメイン名をもとに、必要に応じてキャッシュ帯域を提供できる。


) コンテンツ ルールのドメイン名は、case コマンドの設定に関係なく、大文字と小文字が区別されません。


コンテンツ ルールにドメイン名を設定するには、 url コマンドを使用して、
url_name
または url_path の前にスラッシュを 2 本(//)挿入して引用符で囲みます。

次に例を示します。

(config-owner-content[arrowpoint-rule1])# url “//www.arrowpoint.com/*”
 

通常、ポート 80 を使用するトラフィックについては、ドメイン名にポート番号を付ける必要はありません。80 番以外のポートを使用する場合は、その番号をドメイン名に付加します。ドメイン名とポート番号はコロン(:)で区切ります。次に例を示します。

(config-owner-content[arrowpoint-rule1])# url “//www.arrowpoint.com:8080/*”
 

透過キャッシュがいくつかあり、特定のドメインで最も強力なキャッシュ サーバを使用したい場合は、VIP ルールよりもドメイン名ルールを使用します。残りのキャッシュ サーバの間で、その他のすべてのドメインの負荷を分散します。この設定では、強力なキャッシュ サーバに送出するドメインに、ドメイン名ルールを設定します。次にワイルドカード VIP ルール(ポート 80、VIP アドレスなしを指定)を設定し、その他すべての HTTP トラフィックを残りのキャッシュ間で分散します。

また、多くのドメイン名をホストする 1 台のサーバに 1 つの VIP アドレスを使用することができます。将来それらのドメイン名の一部が受信するトラフィックが増加した場合、それらのコンテンツを別のサーバに格納したい場合があります。それらのトラフィックを分離するには、特定のサービスに振り分けるドメイン名をコンテンツ ルールに設定します。CSS はコンテンツ ルール内で、これらのドメイン名を一致基準として使用するため、分離するドメイン名に VIP アドレスを追加設定する必要はありません。

複数のドメイン名とコンテンツ ルールの照合

コンテンツ ルールとの照合が複数のドメイン名で必要な場合、Domain Qualifier List(DQL; ドメイン修飾子リスト)をコンテンツ ルールに関連付けることができます。DQL は、ユーザが設定するドメイン名のリストです。ルールで DQL を使用すると、リスト内の各ドメインに対するコンテンツ要求がそのルールと照合されるように指定できます。

DQL 内のドメイン名の順序は、指定可能です。リストに名前を追加するときにインデックス番号を割り当てて、DQL 内の名前を番号順に並べることができます。

DQL は、いかなる範囲マッピングにも依存しません。このため、このリストを、VIP またはポートの範囲を持たないサーバ間のバランスをとるための一致基準として使用することができます。範囲を持つサービスを使用するときに範囲マッピングを使用する場合は、DQL のすべてのドメイン名のインデックスを考慮する必要があります。


) DQL のインデックスは、サービス範囲にマッピングする必要があります。DQL のインデックスが正しくマッピングされない場合、ルールをアクティブにするとエラー メッセージが表示されます。


DQL でサービスの範囲を使用しない場合は、インデックスを設定する必要はありません。この場合、デフォルトのインデックスは 1 となります。

たとえば、Woodworker という名前の DQL を設定します。

(config)# dql Woodworker
 

例として、この DQL の一部として追加するドメイン名が、 www.wood.com、
www.woodworker.com、www.maple.com、www.oak.com で、www.wood.com と
www.woodworker.com に同じマッピング インデックスを設定する場合を考えてみます。入力できるインデックス番号は、1~1000 です。また、各インデックスに説明を引用符で囲んで記述することができます。

次に例を示します。

(config-dql[Woodworker]# domain www.wood.com index 1 “This is the same as the woodworker domain”
 
(config-dql[Woodworker]# domain www.woodworker.com index 1
 
(config-dql[Woodworker]# domain www.maple.com index 2
 
(config-dql[Woodworker]# domain www.oak.com index 3
 

ある DQL をコンテンツ ルール WoodSite の一致基準として指定し、このルールに関連付けられた 2つのサービス(S1 および S2)が存在するとします。この場合、CSS はマッピング時にこれらのサービスの範囲をチェックします。コンテンツ ルールに DQL を追加するには、次のように url コマンドを使用します。

(config-owner-content[WoodSites])# url “/*“ dql Woodworker
 

たとえば、CSS がその他の基準とともに www.oak.com への要求を受信すると、ルール WoodSites では、DQL のインデックス 3 と一致します。このルールにラウンドロビン ロード バランシング方式が設定されている場合、CSS はサービス(この例では S2)の、バックエンド接続のマッピング パラメータを調べます。S2 の VIP アドレスを 10.0.0.1、範囲を 5 に設定していた場合、アドレスは 10.0.0.1~10.0.0.5 となります。このサービスにはアドレスの範囲が設定されており、ポートに 0(any)が設定されているので、DQL のインデックス 3 は、サービスの VIP アドレス範囲のインデックス 3、つまりアドレス 10.0.0.3 に一致します。

DQL を削除するには、 no dql コマンドを使用します。次に例を示します。

(config)# no dql Woodworker
 

) コンテンツ ルールで現在使用されている DQL は、削除できません。


DQL の詳細については、「ドメイン修飾子リストの設定」を参照してください。

ドメイン名と VIP アドレスを使用したコンテンツ ルールの設定

CSS で、特定の VIP アドレスにある特定のドメインを宛先とするコンテンツ要求を照合したい場合は、コンテンツ ルールにドメイン名と VIP を使用します。CSS でドメイン名に複数の VIP アドレスを設定する場合は、ドメイン名コンテンツ ルールを 2 つ作成して、それぞれ別の VIP アドレスを指定します。

この設定を、次の実行設定(running-config)で示します。この例の IP アドレスは連続しているため、 vip address range コマンドを使用して範囲 2 の VIP アドレスを指定することもできます。

次に設定例を示します。

content domainRule1
vip address 192.168.1.1
protocol tcp
port 80
url “//domain.com/*”
add service Serv1
activate
 
content domainRule2
vip address 192.168.1.2
protocol tcp
port 80
url “//domain.com/*”
add service Serv1
activate
 

ネットワーク トポロジで、CSS が VIP アドレスについての ARP 応答を行う必要がない場合は、ドメイン名と VIP アドレスに別のコンテンツ ルールを設定する必要はありません。この場合は、ドメイン名のコンテンツ ルールが VIP アドレスの有無に関わらず、そのドメインに送信されるすべてのコンテンツ要求を処理できるため、ドメイン名コンテンツ ルールだけで十分であり、VIP アドレスをルールに設定する必要はありません。たとえば、次のように設定します。

content domainRule3
protocol tcp
port 80
url “//domain.com/*”
add service Serv1
active
 

ARP 応答が不要なトポロジとは、たとえば、上流のルータで CSS が、VIP アドレスの次のホップのルータとして静的に設定されている場合です。

ドメイン名コンテンツ ルールでのワイルドカードの使用

コンテンツ ルールの一致基準の一部として、ドメイン名にワイルドカードを使用することができます。ドメイン名のワイルドカードは、コンテンツ ルールの階層内で処理されます。つまり、コンテンツへの要求が複数のルール(ワイルドカード ドメイン名を含む)に一致する場合、CSS は最も詳細な記述のルールの特性でそのフローを設定します。


) ワイルドカードは、ドメイン修飾子リスト(DQL)または Uniform Resource Locator Qualifier List(URQL; URL 修飾子リスト)には使用できません。


たとえば、次のコンテンツ ルールの基準セットは、コンテンツの一致ルールとして最も詳細な記述なので、優先順位が一番高くなります。

ドメイン名、IP アドレス、プロトコル、ポート、URL

次の例の設定のように、これらの基準をすべて使用してコンテンツ ルールを作成する場合、コンテンツ ルールに一致するのは、VIP アドレス、プロトコル、ポート番号の基準を満たし、「arr」で始まるドメイン名を持つドメインにある JPEG ファイルだけです。

(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6
(config-owner-content[arrowpoint-rule1])# protocol tcp
(config-owner-content[arrowpoint-rule1])# port 80
(config-owner-content[arrowpoint-rule1])# url “//arr*.com/*.jpg”
 

CSS は、ワイルドカードのドメイン名を持つコンテンツ ルールを見つけると、そのコンテンツ ルールの階層に従って照合を続け、一致した時点で検索を終了します。この動作は、CSS のコンテンツ ルールの一般的な管理方法と整合性がとれています。

たとえば、コンテンツ要求が、VIP アドレス 192.168.3.6 と URL /* のルールに一致した場合、CSS は 2 番目のルール(ワイルドカード VIP アドレス(アドレスは未指定)と URL/*.jpg)による検索は行いません。これは、最初のルールの方が 2 番目のルールよりもより詳細であるためです。

さらに、//arrowpoint*.com/* のルールで一致した場合、この時点で検索は終了し、//arr*.com/*.gif のルールとの照合は行ないません。これは、最初のルールでの一致の方がより対象を絞り込んでいるためです。また、完全指定したドメイン名のルール(arrowpoint.com)は、ワイルドカードのドメイン名ルール(arr*.com)よりも詳細な記述ですので注意してください。

たとえば、コンテンツ ルールのドメイン名部分のテキスト文字列「arr」を含むすべてのインスタンスを一致させるには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# url “//arr*.com/*”

コンテンツ ルールでのドメイン名ワイルドカードの一般的なガイドライン

ドメイン名は、「単語」と呼ばれるテキスト文字列と、「ドット」と呼ばれる単語の区切り文字で構成されます。CSS では、右の単語から左の単語へドメイン名を解析します。CSS では、1 単語または複数単語のドメイン名の一部にワイルドカードを使用することができますが、ワイルドカードで単語を始めることはできません。

たとえば、CSS では次のドメイン名がサポートされます。

www.arr*.com

arr*.com

*.arr*.com

arr*.home.com

この例では、ワイルドカード文字を、ドメイン名の 1 単語としてそのまま使用するか、または単語の先頭数文字の 右側 に使用しています。ただし、ワイルドカード文字でドメイン名の単語を開始することはできません。

たとえば、CSS では次のドメイン名はサポートされません。

*point.com

*.*point.com

*point.home.com


) ドメイン名の右端部分(たとえば、.com、.org、.gov)にワイルドカードを使用することはできません。このため、ドメイン名のシンタックス f* はサポートされません。ドメイン名を構成するその他の単語には、ワイルドカードを使用できます。


ドメイン修飾子リストの設定

コンテンツ ルールを複数のドメイン名に照合する必要がある場合は、そのルールにドメイン修飾子リスト(DQL)を関連付けることができます。DQL は、コンテンツ ルールに割り当てた設定済みドメイン名のリストです。これを使用すると、ドメインごとにコンテンツ ルールを作成する手間が省けます。複数のドメイン名を DQL に割り当てると、多くのドメイン名を 1 つのコンテンツ ルールと照合することができます。

ルールで DQL を使用すると、リスト内の各ドメインへのコンテンツ要求がそのルールと照合されるように指定できます。DQL 内のドメイン名の順序は、指定可能です。リストにドメイン名を追加するときにインデックス番号を割り当てて、DQL 内の名前を番号順に並べることができます。


) CSS は、最大 512 の DQL をサポートし、最大 2,500 のドメイン名エントリをサポートします。つまり、DQL が 1 つであれば 2,500 のエントリが可能であり、5 つであればそれぞれ最大 500 のエントリが可能です。


DQL は、いかなる範囲マッピングにも依存しません。このため、このリストを、VIP またはポートの範囲を持たないサーバ間のバランスをとるための一致基準として使用することができます。範囲を持つサービスを使用するときに範囲マッピングを使用する場合は、DQL のすべてのドメイン名のインデックスを考慮する必要があります。DQL でサービスの範囲を使用しない場合は、インデックスを設定する必要はありません。この場合、デフォルトのインデックスは 1 となります。

たとえば、Woodworker という名前の DQL を設定します。

(config)# dql Woodworker
 

例として、この DQL の一部として追加するドメイン名が、 www.wood.com、
www.woodworker.com、www.maple.com、www.oak.com で、www.wood.com と
www.woodworker.com に同じマッピング インデックスを設定する場合を考えてみます。入力できるインデックス番号は、1~1000 です。また、各インデックスに説明を引用符で囲んで記述することができます。

次に例を示します。

(config-dql[Woodworker]# domain www.wood.com index 1 “This is the same as the woodworker domain”
(config-dql[Woodworker]# domain www.woodworker.com index 1
(config-dql[Woodworker]# domain www.maple.com index 2
(config-dql[Woodworker]# domain www.oak.com index 3
 

ある DQL をコンテンツ ルール WoodSite の一致基準として指定し、このルールに関連付けられた 2つのサービス(S1 および S2)が存在するとします。この場合、CSS はマッピング時にこれらのサービスの範囲をチェックします。コンテンツ ルールに DQL を追加するには、次のように url コマンドを使用します。

(config-owner-content[WoodSites])# url “/*” dql Woodworker
 

たとえば、CSS がその他の基準とともに www.oak.com への要求を受信すると、ルール WoodSites では、DQL のインデックス 3 と一致します。このルールにラウンドロビン ロード バランシング方式が設定されている場合、CSS はサービス(この例では S2)の、バックエンド接続のマッピング パラメータを調べます。S2 の VIP アドレスを 10.0.0.1、範囲を 5 に設定していた場合、アドレスは 10.0.0.1~10.0.0.5 となります。このサービスにはアドレスの範囲が設定され、ポートが any になっているため、DQL のインデックス 3 は VIP の範囲のインデックス 3(アドレス 10.0.0.3)と一致します。

DQL 設定モードにアクセスするには、ブート設定モード、グループ設定モード、RMON アラーム設定モード、RMON イベント設定モード、および RMON 履歴設定モード以外の任意のモードで dql コマンドを使用します。プロンプトは、(config-dql [name]) に変わります。DQL モードでこのコマンドを使用して、他の DQL にアクセスすることもできます。

DQL の設定については、次の各項を参照してください。

DQL の作成

DQL の説明の記述

DQL へのドメインの追加

コンテンツ ルールへの DQL の追加

コンテンツ ルールからの DQL の削除

DQL 設定の表示

DQL の作成

新しい DQL を作成するには、DQL の名前をスペースを含まない 31 文字以内の文字列を引用符で囲まずに入力します。既存の DQL にアクセスするには、DQL の名前を入力します。既存の DQL 名のリストを表示するには、 dql ? を入力します。

たとえば、DQL を設定するには、次のように入力します。

(config)# dql pet_domains
(config-dql[pet_domains])#

DQL の説明の記述

DQL の説明を記述するには、 description コマンドを使用します。説明は、スペースを含む 63 文字以内のテキスト文字列を引用符で囲んで入力します。

次に入力例を示します。

(config-dql[pet_domains])# description “pet supplies”

DQL へのドメインの追加

複数のドメイン名を 1 つの DQL に割り当てると、多くのドメイン名を 1 つのコンテンツ ルールと照合することができます。 domain コマンドを使用して、DQL でサポートされるドメインのリストにドメインを追加します。このコマンドのシンタックスは次のとおりです。

domain name index number {" description "}

変数とオプションは次のとおりです。

name ドメインの名前 63 文字以内のテキスト文字列を、引用符で囲まずに入力します(たとえば、www. arrowpoint.com など)。 CSS は、指定されたドメイン名と正確に一致するかどうかを照合します。

number :ドメインのインデックス番号。1~10000 の範囲内の番号を入力します。1 つのドメインに複数のドメイン名がある場合は、それらの名前に同じインデックス番号を割り当てることができます。

" description " :ドメイン名の説明。スペースを含む 63 文字以内のテキスト文字列を引用符で囲んで入力します。


) CSS は、最大 512 の DQL をサポートし、最大 2500 のドメイン名エントリをサポートします。つまり、DQL が 1 つであれば 2500 のエントリが可能であり、5 つであればそれぞれ最大 500 のエントリが可能です。


次に例を示します。

(config-dql[pet_domains])# domain www.birds.com index 1 “idaho-based”
(config-dql[pet_domains])# domain www.cats.com index 2 “worldwide”
(config-dql[pet_domains])# domain www.horses.com index 3 “florida-based”
 

通常、ポート 80 を使用するトラフィックについては、ドメイン名にポート番号を付ける必要はありません。80 番以外のポートを使用する場合は、その番号をドメイン名に付加します。ドメイン名とポート番号はコロン(:)で区切ります。次に例を示します。

(config-dql[pet_domains])# domain www.dogs.com:8080 index 4
 

コンテンツ ルールに割り当てられた DQL からドメイン名を追加または削除する場合は、最初に suspend コマンドを使用してコンテンツ ルールを一時停止する必要があります。コンテンツ ルールで現在使用中の DQL は変更できません。

たとえば、この例の DQL からドメインを削除するには、次のように入力します。

(config-dql[pet_domains])# no domain www.birds.com

コンテンツ ルールへの DQL の追加

DQL を設定したら、 url コマンドを使用して、このリストをコンテンツ ルールに追加します。DQL エントリにはワイルドカードは使用できません。

次に入力例を示します。

(config-owner-content[pets.com-rule1])# url “/*” dql pet_domains

コンテンツ ルールからの DQL の削除

コンテンツ ルールに割り当てられている DQL を削除するには、最初に suspend コマンドを使用して、コンテンツ ルールを一時停止する必要があります。コンテンツ ルールで現在使用中の DQL は削除できません。コンテンツ ルールを一時停止してから、 no dql コマンドを使用してコンテンツ ルールから DQL を削除します。

次に例を示します。

(config) no dql pet_domains

DQL 設定の表示

DQL の設定をすべて表示するには、 show dql コマンドを使用します。特定の DQL を表示するには、コマンド行に DQL の名前を入力します。

次に例を示します。

(config-dql[pet_domains])# show dql pet_domains
 

表 10-2 に、 show dql コマンドで表示されるフィールドについて説明します。

 

表 10-2 show dql コマンドの出力フィールド

フィールド
説明

Name

DQL の名前

Index

CSS で一意の、DQL を特定するインデックス

Description

DQL の説明

Index

DQL で一意の、このドメインのインデックス番号

Domain

インデックス番号に関連付けられたドメインの名前

Description

ドメインの説明

仮想 Web ホスティングの設定

仮想 Web ホスティングを使用すると、ミラー化されたコンテンツを保存する数台(通常 2~10 台)のサーバで多くの Web サイトを処理できます。各サーバでは複数の IP アドレス、ポート、ドメイン名を仮想的に提供し、数百または数千の Web サイトを格納できます。サーバは、IP アドレス、ポート、またはドメイン名に基づいてどの Web サイトが要求されているかを判断します。

File Transfer Protocol(FTP; ファイル転送プロトコル)アプリケーションまたは UDP アプリケーションを使用する場合は、仮想 Web ホスティングを設定します。

仮想 Web ホスティングを使用する場合は、次の設定を行います。

IP アドレスまたはポートの範囲が設定されているサービス

VIP の範囲または DQL(いずれか一方のみ)が設定されているコンテンツ ルール。このコンテンツ ルールを設定すると、VIP の範囲または DQL 内のドメイン名をサーバにマップできます。

VIP の範囲、または範囲なしで 1 台のサーバにマップされる DQL のいずれか一方のみが設定されているコンテンツ ルール。このコンテンツ ルールを設定すると、VIP の範囲または複数のドメイン名を 1 つのサーバにマップできます。

FTP アプリケーションまたは UDP アプリケーションを使用する場合にだけ、送信元 IP アドレスとポートの NAT 変換用の VIP 範囲が設定されているソース グループ。このソース グループを設定すると、サービス IP アドレスまたはポートの範囲をソース グループ VIP の範囲にマップできます。

ポートの範囲、VIP の範囲、または DQL を設定すると、CSS で Web サイトのロード バランシング処理を行うように設定することができます。必要なサービスとコンテンツ ルールの詳細については、 「サービスの設定」 および本章を参照してください。

たとえば、着信コンテンツ要求の宛先 IP アドレスがコンテンツ ルールに設定された範囲の 2 番目の VIP に一致する場合は、フローを対応するサービスに設定された範囲の 2 番目の IP アドレスまたはポートにマップできます。サービスに設定された範囲の 3 番目の IP アドレスまたはポートから発信されるフローの場合は、フローを対応するソース グループに設定されている範囲の 3 番目の VIP にマップできます。

仮想 Web ホスティングを設定するための手順については、 表 10-3 を参照してください。

 

表 10-3 仮想 Web ホスティング設定のクイック スタート

作業とコマンドの例

1. config と入力して設定モードに入ります。

(config)#

2. サービスを作成します。

(config)# service serv1
(config-service[serv1])#

3. サービスに IP アドレスを割り当て、IP アドレスの範囲を定義します。1~65535 の範囲内の番号を入力します。

ip address range コマンドを使用する場合は、使用中のサブネット内の IP アドレスを使用します。CSS では、回線のサブネット上に存在しない IP アドレスに対しては、ARP は使用されません。

(config-service[serv1])# ip address 10.3.6.1 range 200

4. 必要に応じて、他のサービスのルール(プロトコル、キープアライブなどのパラメータ)を設定します。

(config-service[serv1])# protocol tcp
(config-service[serv1])# keepalive type http
(config-service[serv1])# keepalive method get
(config-service[serv1])# keepalive uri “/index.html”

) CSS では、IP アドレス範囲またはポート範囲で設定されたサービス用のキープアライブを 1 つ使用し、必ずその範囲の最初の IP アドレスまたはポートにキープアライブを送信します。


 

5. サービスをアクティブにします。

(config-service[serv1])# active

6. コンテンツ ルールを作成します。

(config-owner[arrowpoint])# content rule1
(config-owner-content[arrowpoint-rule1])#

7. VIP を設定します。VIP の範囲を設定できるのは、DQL を設定しない場合だけです。

(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6 range 10
 

vip address range コマンドを使用する場合は、使用しているサブネット内の IP アドレスを使用します。CSS では、回線のサブネット上に存在しない IP アドレスに対しては、ARP は使用されません。

8. 必要に応じて、他のコンテンツ ルール(ポート、プロトコル、サービスの追加など)を設定します。

(config-owner-content[arrowpoint-rule1])# port 80
(config-owner-content[arrowpoint-rule1])# protocol tcp
(config-owner-content[arrowpoint-rule1])# add service serv1

9. コンテンツ ルールを有効にします。

(config-owner-content[arrowpoint-rule1])# active

10. ソース グループを作成します。

(config)# group group1
(config-group[group1])#

11. ソース グループに VIP アドレス範囲を設定します。

(config-group[group1])# vip address 192.168.5.7 range 10

12. ソース グループの一部となるサービスを追加します。

(config-group[group1])# add service serv1

13. ソース グループをアクティブにします。

(config-group[group1])# active

14. コンテンツ ルールに VIP 範囲を設定していない場合は、DQL を作成できます。

(config)# dql pet_domains
(config-dql[pet_domains])#

15. 作成した DQL にドメインを追加します。

(config-dql[pet_domains])# domain www. birds.com index 1 “idaho-based”
(config-dql[pet_domains])# domain www. cats.com index 2 “worldwide”
(config-dql[pet_domains])# domain www. horses.com index 3 “florida-based”

16. url コマンドを使用して、コンテンツ ルールに DQL を追加します。

(config-owner-content[arrowpoint-rule1])# url “/*” dql pet_domains

表 10-3 に示した各コマンドを実行すると、次のような実行設定が得られます。

!************************** SERVICE **************************
service serv1
ip address 10.3.6.1 range 200
protocol tcp
keepalive type http
keepalive method get
keepalive uri "/index.html"
active
 
!**************************** DQL ****************************
dql pet_domains
domain www.birds.com index 1 "idaho-based"
domain www.cats.com index 2 "worldwide"
domain www.horses.com index 3 "florida-based"
!*************************** OWNER ***************************
owner arrowpoint
 
content rule1
vip address 192.168.3.6 range 10
add service serv1
protocol tcp
port 80
url "/*" dql pet_domains
active
 
!*************************** GROUP ***************************
group group1
vip address 192.168.5.7 range 10
add service serv1
active

コンテンツ ルールへのサービスの追加

サービスをコンテンツ ルールに追加すると、リソース プールに格納され、CSS がコンテンツ要求のロード バランシングを行う場合に使用されます。1 つのコンテンツ ルールに追加できるサービスの最大数は 64 です。サービスは、複数のコンテンツ ルールに属することもできます。

既存のサービスをコンテンツ ルールに追加するには、 add コマンドを使用します。コンテンツ ルールに追加できるサービスのリストを表示するには、 add service ? コマンドを使用します。


) ドメイン修飾子リスト(DQL)とサービス ポートの範囲のいずれかが設定されているコンテンツ ルールには、ローカル サービスだけを追加できます。


add service コマンドでは、次のタイプのサービスをコンテンツ ルールに追加できます。

サービス

プライマリ ソーリー サーバ

セカンダリ ソーリー サーバ

サービス タイプの設定については、 「サービスの設定」 「サービス タイプの指定」を参照してください。

レイヤ 3 またはレイヤ 4 のコンテンツ ルールを設定した場合、 このルールは次のようにローカル サービスにヒットします。

ローカル サービスが動作していない、または設定されていない場合、ルールはプライマリ ソーリー サーバにヒットします。

プライマリ ソーリー サーバで障害が発生した場合、ルールはセカンダリ ソーリー サーバにヒットします。

レイヤ 3 または 4 のルールでは、HTTP プロトコルを使用するため、リダイレクト サービスとリダイレクト コンテンツの文字列は使用できません。

レイヤ 5 のコンテンツ ルールを設定すると、 CSS はコンテンツ要求をローカル サービスに次のように送出します。

ローカル サービスが動作していないか設定されていない場合、ルールはリダイレクト サービスへの場所が指定されている HTTP リダイレクトをクライアントへ送信します。

ローカル サービスおよびリダイレクト サービスが動作していないか設定されていない場合、ルールは HTTP 要求をプライマリ ソーリー サーバに転送します。

セカンダリ ソーリー サーバ以外のすべてのサービスが停止している場合、ルールは HTTP 要求をセカンダリ ソーリー サーバに転送します。


) レイヤ 5 コンテンツ ルールは、RFC-2518 の CONNECT、GET、HEAD、POST、PUSH、PUT の各 HTTP メソッドをサポートします。また、透過キャッシュ環境では、CSS は RFC-2518 拡張メソッドを認識して宛先サーバに直接転送しますが、ロード バランシングは行いません。RFC-2518 拡張メソッドには、OPTIONS、TRACE および PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE があります。RFC-2518 拡張メソッドをサポートするように CSS を設定する方法については、「HTTP メソッド解析の設定」を参照してください。



) 一部の環境では、URL、クッキー文字列、または他の HTTP ヘッダー情報が複数のパケットにまたがっている場合があります。 このような環境では、レイヤ 5 の情報を得るために複数のパケットを解析してから、ロード バランシングの判断を行うことができます。 グローバル設定モードの spanning-packets コマンドを使用すると、20 パケットまで解析できるようになります(デフォルトは 6)。ロード バランシングの判断は、一致が見つかるとただちに行われるので、設定した数のパケットをすべて解析する必要はありません。 複数のパケットを解析すると接続の遅延は必然的に長くなるため、複数のパケットにわたる長い文字列はパフォーマンスに影響を与えます。spanning-packets コマンドの使用についての詳細は、この章で後述する「一度に解析するパケットの数の指定」を参照してください。


コンテンツ ルールへのサービスの追加

コンテンツ ルールにサービスを追加するには、 add service コマンドを使用します。1 つのコンテンツ ルールに追加できるサービスの最大数は 64 です。

たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# add service serv2

サービスの重みの指定

CSS では、コンテンツ ルールに加重ラウンドロビン方式のロード バランシングを設定するときに、サービスの重みを使用します。サービスに指定した重みが大きいほど、CSS がそのサービスにリダイレクトする要求が増えます。

コンテンツ ルールにサービスを追加するときに、次に説明する add service
service_name
weight (または change service service_name weight )コマンドを使用すれば、そのサービスに重みを割り当てることができます。

add service service_name weight :このコマンドにより、コンテンツ ルールで加重ラウンドロビン ロード バランシング方式を設定するときに使用するサービスの重みを指定できる。

change service service_name weight :サービスの重みを変更できる。対象のサービスをコンテンツ ルールから削除し、追加しなおす必要はありません。サービスをコンテンツ ルールから削除すると、スティッキ コンテンツ ルールに一致した結果としてそのサービスで作成された既存の全スティッキ セッションが、停止してしまいます。サーバ名は、スペースを含まないテキスト文字列を引用符で囲まずに入力します。大文字小文字は区別します。

両方のコマンドを使用すると、サーバ固有の重みが無効になり、サービスを追加したコンテンツ ルールだけに適用されます。

サービスの重みを設定するには、0~10 の範囲内の値を入力します(0 :グレイスフル シャットダウン)。デフォルト値は、 (config-service) weight コマンドでこのサービスに設定した重みです( 「サービスの設定」 「重みとグレイスフル シャットダウンの設定」参照)。すべてのサービスの重みは、デフォルトで 1 に設定されています。


) 加重ラウンドロビン方式のロード バランシングをコンンツ ルールに設定すると、そのコンテンツ ルールでは、この設定された重みが、DFP エージェントが報告したサービスの重みや、サービスモードに設定された重みより優先されます。


過負荷サービスのグレイスフル シャットダウンを行う場合、または、メンテナンスのためにサービスを正常にオフラインにする場合は、重み 0 を指定することによって、新しい接続がそのサービスに設定されることはありません。ただし、存在するスティッキ セッションの接続を除きます。時間が経過して存在するスティッキ セッションが完了すると、そのサービスの負荷は小さくなり始めます。重みの値を 0 から他の値(1~10)に変更すると、すべてのロード バランシング方式で、そのサービスがローテーションに再度組み込まれます。

たとえば、サービスの重み 3 を指定するには、次のように入力します。

(config-owner-content[arrowpoint-rule1]) add service serv2 weight 3
 

たとえば、重み 0 をアクティブなサービスのグレイスフル シャットダウンに指定するには、次のように入力します。

(config-owner-content[arrowpoint-rule1]) change service serv2 weight 0
 

重みをサービス モードに設定された重みに戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1]) no change service serv2
 

CSS のグレイスフル シャットダウンを設定する際に、 add service service_name weight コマンドと change service service_name weight コマンドに関して、留意すべきポイントを次に示します。

コンテンツ ルールに指定された加重ラウンドロビン ロード バランシング方式を設定していない場合、またはサーバ ロード バランシングに指定された DFP を設定していない場合は、サービス モードだけで weight コマンドを使用します( 「サービスの設定」 「重みとグレイスフル シャットダウンの設定」参照)。このような ロード バランシング方式では、コンテンツ モードで add service service_name weight コマンドまたは change service service_name weight コマンドを使用してもサービスの重みには反映されないので、これらのコマンドをサービスのグレイスフル シャットダウンに使用することはできません。

重みは、プライマリ ソーリー サーバまたはセカンダリ ソーリー サーバのコンテンツ ルールには設定できません。ソーリー サーバは、重みをサービス モードで 0 に設定した場合にだけ、グレイスフル シャットダウンできます。

グレイスフル シャットダウンとともに sticky-srcip または sticky-srcip-dstport などの拡張 ロード バランシング方式を使用する場合は、sticky-inact-timeout コマンドを使用して、無活動タイムアウト期間を指定することをお勧めします。スティッキ エントリが無活動でタイム アウトすると、シャットダウン サービスへの接続カウントは減少します。

コンテンツ ルールへのプライマリ ソーリー サーバの追加

CSS は、プライマリ ソーリー サーバ以外のサービスがどれも使用できないときに、コンテンツ要求をプライマリ ソーリー サーバに送出します。このサービスは、コンテンツを追加するため、つまりドロップ メッセージやリダイレクト メッセージを提供するために設定できます。このサービスは、ロード バランシングには使用されません。


) グローバル設定で persistence reset remap コマンドを設定し、 no persistent コマンドをコンテンツ ルールに設定した場合、ローカル サービスが再び使用可能になると、CSS は新しい接続と継続中の固定接続をすべてソーリー サーバからローカル サーバに再マッピングします。これ以外の場合、新しい接続は利用可能なローカル サービスに向かいますが、継続中の固定接続はソーリー サーバに留まります。サービスの再マッピングとリダイレクションの詳細については、HTTP リダイレクションとサービスの再マッピングの設定の項を参照してください。


コンテンツ ルールにプライマリ ソーリー サービスを設定するには、
primarySorryServer
コマンドを使用します。サーバ名は、スペースを含まないテキスト文字列を引用符で囲まずに入力します。大文字小文字は区別します。


) プライマリ ソーリー サーバをルールに追加できるのは、そのサーバの IP アドレスまたはポート番号の範囲が、ルールの各サービスの IP アドレスまたはポートの範囲と一致する場合だけです。たとえば、ルールに 2 つのサービスが含まれており、どちらの IP アドレスの範囲も 3 の場合、そのサービスに追加するプライマリ ソーリー サーバの IP アドレス範囲も 3 でなければなりません。


このコマンドの使用例を次に示します。

(config-owner-content[arrowpoint-rule1])# primarySorryServer slowserver
 

プライマリ ソーリー サービスを削除するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no primarySorryServer

コンテンツ ルールへのセカンダリ ソーリー サーバの追加

セカンダリ ソーリー サービスは、プライマリ ソーリー サービスが使用できない場合に CSS が使用するバックアップ サービスです。このサービスは、コンテンツを追加するため、つまりドロップ メッセージやリダイレクト メッセージを提供するために設定できます。このサービスは、ロード バランシングには使用されません。

コンテンツ ルールにセカンダリ ソーリー サービスを設定するには、
secondarySorryServer
コマンドを使用します。サーバ名は、スペースを含まないテキスト文字列を引用符で囲まずに入力します。大文字小文字は区別します。


) セカンダリ ソーリー サーバをルールに追加できるのは、そのサーバの IP アドレスまたはポート番号の範囲が、ルールの各サービスの IP アドレスまたはポートの範囲と一致する場合だけです。たとえば、ルールに 2 つのサービスが含まれており、どちらの IP アドレスの範囲も 3 の場合、そのサービスに追加するセカンダリ ソーリー サーバの IP アドレス範囲も 3 でなければなりません。


このコマンドの使用例を次に示します。

(config-owner-content[arrowpoint-rule1])# secondarySorryServer slowestserver
 

セカンダリ ソーリー サービスを削除するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no secondarySorryServer

コンテンツ ルールへの DNS 名の追加

コンテンツ ルールへマップする DNS 名を指定するには、 add dns コマンドを使用します。このコマンドには次のオプションがあります。

add dns dns_name :コンテンツ ルールにマップする DNS 名。スペースを含まない 1~31 文字のテキスト文字列を、大文字小文字を区別し、引用符で囲まずに入力します。

add dns dns_name ttl_value :コンテンツ ルールにマップする DNS 名であり、オプションの Time to Live(TTL; 存続可能時間)値を秒単位で指定する。この値は、問い合せに対する IP アドレスの応答を DNS クライアントが記憶する期間を設定します。0~255 の値を入力します。デフォルトは 0 です。


) コンテンツ add dns コマンドを使用する場合、追加する DNS 名には小文字だけを使用します。入力した DNS 名に大文字と小文字が混在していると起動エラーが表示され、名前をすべて小文字で入力し直す必要があります。


たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# add dns arrowpoint 120
 

コンテンツ ルールにマップした DNS 名を削除するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# remove dns arrowpoint
 

) CSS で DNS サーバの機能を設定するには、(config) dns-server コマンドを使用します。


コンテンツ ルールでの DNS の無効化

コンテンツ ルールに関係するサービスが DNS のアクティビティで利用できない場合、CSS は Application Peering Protocol(APP)セッション経由でそのことを他の CSS に通知します。ただし、他の機能に対しては、サービスはアクティブな状態を保ちます。

コンテンツ ルールで DNS を無効にするには、 dns-disable-local コマンドを使用します。

GSLB 環境でコンテンツ ルールに dns-disable-local コマンドを設定する際に、コンテンツ ルールがアクティブで、ドメイン名に対して DNS ピアが設定されていない場合には、CSS は DNS 解決を要求したサーバに SERVERFAIL を返します。

たとえば、特定のコンテンツ ルールに対して DNS を無効にするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# dns-disable-local
 

コンテンツ ルールで DNS を有効にするには、no dns-disable-local コマンドを使用します。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no dns-disable-local

コンテンツ ルールのアクティブ化

コンテンツ ルールをアクティブにすると、CSS はそのコンテンツへのアクセスを提供できるようになります。コンテンツ ルールをアクティブにするには、コンテンツ モードで active コマンドを使用して、特定のコンテンツ ルールをアクティブにします。


) コンテンツ ルールがアクティブになると、アクティブなコンテンツ ルールは、portprotocolbalancednsbalanceheader-field-rule、および url コマンドで変更できなくなります。また、コンテンツ ルールの最後のサービスは削除できません。アクティブなコンテンツ ルールを変更する必要がある場合は、まずそのコンテンツ ルールを一時停止してください。


たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# active

コンテンツ ルールの一時停止

コンテンツ ルールを一時停止すると、コンテンツ ルールが非アクティブになります。コンテンツ ルールを一時停止すると、次のような結果になります。

CSS がコンテンツへのアクセスを提供できなくなる。

コンテンツへの既存のフローには影響しない。

コンテンツ ルールを一時停止するには、コンテンツ モードで suspend コマンドを使用します。次に例を示します。

(config-owner-content[arrowpoint-rule1])# suspend
 

コンテンツ ルールの削除

既存のコンテンツ ルールを削除するには、所有者モードで no content コマンドを使用します。たとえば、次のように入力します。

(config-owner[arrowpoint])# no content rule1

コンテンツ ルールからのサービスの削除

サービスを削除すると、そのサービスは、そのコンテンツ ルールが管理しているコンテンツへの要求のロード バランシングに使用するリソース プールから削除されます。サービスを削除すると、残りのサービス間で負荷のバランスがとられます。

既存のサービスをコンテンツ ルールから削除するには、所有者コンテンツ モードで remove コマンドを使用します。次に例を示します。

(config-owner-content[arrowpoint-rule1])# remove service serv1
 

プロトコルの設定

コンテンツ ルールにプロトコルを指定することで、コンテンツ ルールに関連するコンテンツへの要求に特定のプロトコルを使用するように指示できます。コンテンツには、次のプロトコルを指定できます。

any (これがデフォルトで、ルールは TCP ポートまたは UDP ポートを使用)

tcp

udp

アプリケーション タイプとして Session Initiation Protocol(SIP)を指定したが、コンテンツ ルールにプロトコルをまだ設定していない場合には、CSS によって実行設定ファイルに UDP のデフォルトの SIP プロトコルが自動的に指定されます。「アプリケーション タイプの指定」を参照してください。

コンテンツに TCP プロトコルを設定するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# protocol tcp
 

プロトコルをデフォルトの any にリセットするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no protocol

ポートの設定

ポートを指定すると、コンテンツ ルールを特定の TCP/UDP ポート番号に関連付けることができます。0~65535 の範囲のポート番号を入力します。デフォルトは 0 で、任意のポートを示します。

アプリケーション タイプとして SIP を指定したが、コンテンツ ルールにポートをまだ指定していない場合には、CSS によって実行設定ファイルにデフォルトの SIP ポート番号 5060 が自動的に指定されます。「アプリケーション タイプの指定」を参照してください。

コンテンツにポート番号を設定するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# port 80
 

ポート番号をデフォルトの 0 に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no port

ロード バランシングの設定

コンテンツ ルールにロード バランシングのアルゴリズムを指定するには、コンテンツ設定モードで balance コマンドを使用します。このコマンドには、次のオプションがあります。

balance aca ArrowPoint Content Awareness ロード バランシング アルゴリズム( 「サービスの負荷の設定」 「サーバの負荷と重みに基づいた ArrowPoint Content Awareness(ACA)の使用」参照)。ACA では、負荷、またはサーバの重みと負荷に基づいてサービス間でトラフィックのバランスを取ります。

balance destip :送信先 IP アドレス分配アルゴリズム。CSS は、同じ送信先 IP アドレスを持つすべてのクライアント要求を同じサービスに送ります。このオプションは、通常、キャッシング環境で使用します。

balance domain :ドメイン名による分配アルゴリズム。CSS は、キャッシュごとに均等にアルファベットを割り当てます。まず、最初のドットに続く最初の 4 文字のホスト タグを解析し、ドメイン名のこれらの文字を使用して、要求をどのサーバに送信すべきかを判断します。このオプションは、通常、キャッシング環境で使用します。

balance domainhash :ドメイン文字列に基づく CSS の内部ハッシュ アルゴリズム。CSS はホスト タグを解析して、ホスト名全体にわたって XOR ハッシュを実行します。次に、XOR ハッシュの値を使用して、要求の転送先のサーバを決定します。この方式では、同じホスト タグを持つ要求がすべて確実に同じサーバに送信され、キャッシュ ヒットの確率が高まります。このオプションは、通常、キャッシング環境で使用します。


no persistent コマンドとグローバルの persistent reset remap コマンド、および domainhash ロード バランシング方式を使ってコンテンツ ルールを作成すると、HTTP 1.1 接続上の HTTP GET によって直前の GET とは異なるハッシュ値が得られたときに、サーバの再マッピングが行われます。


balance leastconn :最小接続アルゴリズム。 このバランス方式は、実行中のサービスのうち、接続数が最も少ないサービスを選択します。

最小接続アルゴリズムで UDP コンテンツ ルールを使用することは推奨されません。UDP はコネクションレス型プロトコルであるため、サービス接続カウンタが増加しません。カウンタが 0 のまま変化しないため、CSS は矛盾した結果を返します。

balance roundrobin :ラウンドロビン アルゴリズム(デフォルト)。 ローカルとリモートのコンテンツ ドメイン サイト間で負荷を均等に分散してドメイン名を解決し、要求を解決します。

balance srcip :送信元 IP アドレスによる分配アルゴリズム。CSS は、同じ送信元 IP アドレスから送られたクライアント要求をすべて同じサービスに送信します。このオプションは、通常、キャッシング設定で使用します。

balance url :URL 分配アルゴリズム。 CSS は、キャッシュごとに均等にアルファベットを割り当てます。次に、ルールに一致する URL 部分に続く最初の 4 文字を解析します。たとえば、コンテンツ ルールの URL が "/news/*" に設定されている場合、"/news/" に続く 4 文字に基づいて負荷を分散させます。このオプションは、通常、キャッシング環境で使用します。

balance weightedrr :加重ラウンドロビン アルゴリズム。 CSS は、ラウンドロビンを使用しますが、サーバに設定された重みに基づいて、サービスに重み付けを行います。サーバはすべて、デフォルトで重み 1 に設定されています。サーバの重みを設定するには、所有者コンテンツ モードで add service weight コマンドを使用します。

balance urlhash :URL 文字列に基づく CSS の内部ハッシュ アルゴリズム。CSS は URL を解析し、その URL 全体に XOR ハッシュを適用します。次に、XOR ハッシュの値を使用して、要求の転送先のサーバを決定します。この方式では、同じ URL に対する要求がすべて確実に同じサーバに送信され、キャッシュ ヒットの確率が高まります。このオプションは、通常、キャッシング環境で使用します。


no persistent コマンドとグローバルの persistent reset remap コマンド、および urlhash ロード バランシング方式を使ってコンテンツ ルールを作成すると、HTTP 1.1 接続上の HTTP GET によって直前の GET とは異なるハッシュ値が得られたときに、サーバの再マッピングが行われます。



) レイヤ 5 コンテンツ ルールは、RFC-2518 の CONNECT、GET、HEAD、POST、PUSH、PUT の各 HTTP メソッドをサポートします。また、透過キャッシュ環境では、CSS は RFC-2518 拡張メソッドを認識して宛先サーバに直接転送しますが、ロード バランシングは行いません。RFC-2518 拡張メソッドには、OPTIONS、TRACE および PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE があります。RFC-2518 拡張メソッドをサポートするように CSS を設定する方法については、「HTTP メソッド解析の設定」を参照してください。


たとえば、 weightedrr ロード バランシングを指定するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# balance weightedrr
 

バランス タイプをデフォルトのラウンドロビン方式に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no balance

DNS バランス タイプの設定

ドメイン名を IP アドレスに変換する要求に対する解決方法を選択するには、
dnsbalance
コマンドを使用します。このコンテンツ モードのコマンドのシンタックスおよびオプションは、次のとおりです。

dnsbalance preferlocal :要求をローカル VIP アドレスに解決する。すべてのローカル システムでその負荷しきい値を超えている場合、最小負荷のリモート システムの VIP アドレスが、そのドメイン名の解決先アドレスとして選択されます。

dnsbalance roundrobin :ローカルおよびリモートのコンテンツ ドメイン サイト間でドメイン名を解決することで負荷を均等に分散し、要求を解決する。ローカルの負荷しきい値を超えたサイトは使用されません。

dnsbalance leastloaded :要求は、すべてのローカル ドメイン サイトまたはリモート ドメイン サイトのうち、負荷が最小のサイトに結び付けられる。CSS は最初に負荷の値を比較します。ドメイン サイト間の負荷の差が 50 以内である場合は、応答時間が比較されます。応答時間が最も短いサイトが、最小負荷サイトとみなされます。

dnsbalance useownerdnsbalance :所有者に割り当てられた DNS ロード バランシング方式を使用して要求を解決する。これは、コンテンツ ルールのデフォルトの方式です。所有者方式を設定しない場合は、デフォルトの所有者の DNS ロード バランシング方式であるラウンドロビンが使用されます。所有者の DNS バランシング方式を設定する方法については、 「所有者の設定」 を参照してください。

次に例を示します。

(config-owner-content[arrowpoint-rule1])# dnsbalance roundrobin
 

DNS バランス タイプを、所有者方式を使用するデフォルト設定に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no dnsbalance

ホットリストの設定

CSS では、コンテンツ ルールにホットリスト アトリビュートを設定することができます。コンテンツ ルールにホットリスト アトリビュートを定義すると、最も頻繁にアクセスされるコンテンツがどれかを判断できます。この情報をもとに、複製する必要のあるコンテンツを正確に判断することができます。ユーザが定義した期間内に要求が最も多かったコンテンツ(ホット コンテンツ)をリストするホット リストを定義するには、 hotlist コマンドを使用します。


) replication-store および replication-cache を動作させるには、ホットリストを設定して有効にする必要があります。


設定所有者コンテンツ モードで、特定のコンテンツのホットリストについて、次のアトリビュートを設定することができます。

hotlist :ホットリストを有効にする。特定のコンテンツ ルールのホットリストを有効にするには、その所有者コンテンツ モードで hotlist コマンドを使用します。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# hotlist
 

ホットリストを無効にするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no hotlist
 

hotlist interval :ホットリストの更新間隔を設定する。間隔には分単位で 1~60 を入力します。デフォルトは 1 です。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# hotlist interval 10
 

ホットリストの更新間隔をデフォルトの 1 に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no hotlist interval
 

hotlist size :ホットリストのサイズを設定する。このルール用に保持するエントリの合計数を 1~100 の値で入力します。デフォルトは 10 です。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# hotlist size 10
 

ホットリストのサイズをデフォルトの 10 に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no hotlist size
 

hotlist threshold :ホットリストのしきい値を設定する。0~65535 の整数を入力してしきい値を指定します。このしきい値を超えると、コンテンツは頻繁にアクセスされている(ホット)とみなされます。デフォルトは 0 です。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# hotlist threshold 9
 

ホットリストのしきい値をデフォルトの 0 に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no hotlist threshold
 

hotlist hitcount :ホットリストのタイプをヒット カウントに設定する。ヒット カウントは、コンテンツへのアクセス回数です。次に使用例を示します。

(config-owner-content[arrowpoint-rule1])# hotlist type hitcount
 

ホットリストのタイプをデフォルト設定の hitcount に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no hotlist type
 

ホットリスト情報を表示するには、 show domain hotlist コマンドを使用します。 表 10-4 に、 show domain hotlist コマンドで表示されるフィールドについて説明します。

 

表 10-4 show domain hotlist コマンドの出力フィールド

フィールド
説明

Hotlist Enabled/Disabled

ドメイン ホットリストの有効または無効。ドメイン ホットリストはデフォルトで無効に設定されています。

Size

ホットリストにリストするドメインの最大エントリ数の設定値。範囲は 1~100 です。デフォルトは 10 です。

Interval

ドメイン ホットリストを更新して、新しいリストを開始する間隔(分)の設定値。範囲は 1~60 です。デフォルトは 1 です。

Threshold

間隔あたりのドメインのヒット数として設定されたしきい値。このしきい値を超えると、ドメインは頻繁にアクセスされている(ホット)とみなされ、リストに追加されます。しきい値の範囲は 0~65535 です。デフォルトは 0(しきい値は無効)です。

# Hot Domains

ホット ドメインの合計数

Hits

ホット ドメインのヒット数

Domain

Hits フィールドに対応するホット ドメインの名前

ドメイン ホットリストの設定

ドメイン ホットリストには、ユーザが定義した期間内にアクセス数が最も多いドメインがリストされます。ドメイン ホットリストを有効にして、そのパラメータを設定するには、 domain コマンドを使用します。このコマンドのシンタックスおよびオプションは、次のとおりです。

domain hotlist :ドメイン ホットリストを有効にする。ドメイン ホットリストはデフォルトで無効に設定されています。

domain hotlist interval minutes :ドメイン ホットリストを更新して新しいリストを開始する間隔を設定する。更新間隔には 1~60 分を入力します。デフォルトは 1 分です。

domain hotlist size max_entries :ホットリストにリストするドメインの最大エントリ数を設定する。エントリの最大数には 1~100 の数値を入力します。デフォルトは 10 です。

domain hotlist threshold number :しきい値を設定する。しきい値は、間隔あたりのドメインのアクセス数であり、このしきい値を超えたドメインが頻繁にアクセスされている(ホット)とみなされ、リストに追加されます。しきい値には 0~65535 の数値を入力します。デフォルトは 0(しきい値は無効)です。

ドメイン ホットリストを有効にするには、次のように入力します。

(config)# domain hotlist
 

ドメイン ホットリストを無効にするには、次のように入力します。

(config)# no domain hotlist
 

ドメイン ホットリストとその設定を表示するには、 show domain hotlist コマンドを使用します( 表 10-4 を参照)。

HTTP メソッド解析の設定

CSS は HTTP 要求をコンテンツ ルールに照合できるように、Request パケットを解析してトークンにします。この解析では、Request-Line フィールドと、いくつかのヘッダー フィールドが評価されます。パケット内の Request-Line フィールドは、パケットの解析方法を決めるために役立ちます。Request-Line フィールドに含まれるメソッド トークンによって、Request-URI フィールドの解釈方法が決まります。

HTTP パケット内の情報を解析してトークンにした後、CSS はこれらのトークンを、要求のロード バランシング方法を定義しているコンテンツ ルールの基準と照合します。アクティブなレイヤ 5 コンテンツ ルールが、HTTP 要求のトークンの照合対象になります。一致が見つかると、CSS はそのトークンを含むパケットを、設定されているルールに従って転送します。レイヤ 5 ルールとの一致が見つからない場合、CSS はトークンをレイヤ 4 ルールと照合し、さらに一致がなければレイヤ 3 ルールと照合します。

デフォルトでは、レイヤ 5 コンテンツ ルールは、CONNECT、GET、HEAD、POST、PUT の各 HTTP メソッドをサポートしています。転送のルールが設定されている場合を除き、CSS は透過キャッシュ環境において OPTIONS、TRACE、PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE の各 HTTP メソッドを認識し、宛先サーバに直接転送します(ロード バランシングは行いません)。

CSS による解析と照合は、RFC-2518 で定義されているすべての拡張メソッド(RFC-2616 を含む)を対象にするように設定できます。また、ユーザ定義メソッドを設定することも可能です。詳細については、次の各項を参照してください。

RFC-2518 拡張メソッド解析の設定

ユーザ定義メソッドの設定

HTTP メソッド解析の設定および状態の表示


) CSS には、RFC-2518 のメソッドと、Outlook Web Access(OWA)に必要なカスタム メソッドの設定用スクリプトが付属しています。setup_owa_methods スクリプトは RFC-2518 メソッドを有効化し、POLL、SEARCH、SUBSCRIBE、BMOVE、BCOPY、BDELETE、BPROPPATCH の各ユーザ定義メソッドを設定します。remove_owa_methods スクリプトは RFC-2518 メソッドを無効化し、
setup_owa_methods スクリプトで設定された OWA メソッドを削除します。


RFC-2518 拡張メソッド解析の設定

デフォルトでは、CSS は CONNECT、GET、HEAD、POST、PUT の各 HTTP メソッドの解析をサポートしています。また、CSS を OPTIONS、TRACE、
PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE の各 RFC-2518 拡張メソッドの解析と処理に対応するようにも設定できます。

RFC-2518 の全メソッドのサポートを有効にすると、CSS はレイヤ 5 ルールとの照合で Request-URI フィールドを解析するようになります。Request-URI フィールドのコンテンツが絶対 URI または絶対パスの形式に適合していなければ、CSS は次に最も適したワイルドカード ルール("/*")と照合します。合致するものが存在しなければ、次にレイヤ 4 ルール、続いてレイヤ 3 ルールとの照合が試みられます。

RFC-2518 で定義されている拡張メソッドのサポートを有効化するには、次のように入力します。

(config)# http-method parse RFC2518-methods
 

RFC-2518 で定義されている拡張メソッドのサポートを無効化するには、次のように入力します。

(config)# no http-method parse RFC2518-methods
 

ユーザ定義メソッドの設定

独自開発した Web アプリケーション用のメソッドの解析が必要であれば、CSS でユーザ定義メソッドを最大 16 個まで設定できます。ユーザ定義メソッドを設定するには、 http-method parse user-defined-method コマンドを使用します。グローバル設定モードのコマンドのシンタックスは次のとおりです。

http-method parse user-defined-method METHOD_NAME
{ uri [ wildcard | authority | url ]}

変数とオプションは、次のとおりです。

METHOD_NAME :Request-URI フィールドを処理するメソッドの名前。3~15 文字の英数字文字列を引用符で囲まないで指定します。ハイフン(-)とアンダースコア(_)も使用できます。英字は大文字で入力してください。制御文字、特殊文字、および空白文字は使用できません。特殊文字とは、"("、")"、"<"、">"、"@"、","、";"、":"、"\"、"""、"/"、"["、"]"、"?"、"="、"{"、"}"、空白文字(SP)、およびタブ(HT)のことです。

RFC-2616 で定義されているサポート対象の HTTP メソッド、RFC-2518 で定義されている拡張メソッド、および既存のユーザ定義メソッドと重複するメソッド名は使用できません。

uri :(オプション)メソッドに適用されるリソースの種類を、Request-URI フィールド内で指定できます。メソッドはデフォルトでは、絶対 URI または絶対パス形式で指定されたリソースを処理します。要求がプロキシ宛ての場合は、絶対 URI 形式にする必要があります。プロキシは要求を転送するか、要求されたリソースを有効なキャッシュから取り込み、応答を返します。次に指定例を示します。

GET http://www.test3.org/pub/www/Test.html HTTP/1.1
 

絶対パスは、本来の宛先サーバやゲートウェイ上のリソースを指定します。URI の絶対パスは Request-URI で送信され、URI のネットワーク上の場所(ホスト名)は Host header フィールドで送信されます。

GET /index.html HTTP/1.1
Host:www.test3.org
 

url :Request-URI フィールドの値が、絶対 URI または絶対パスであることを示します。このキーワードがデフォルト リソースです。

wildcard :Request-URI フィールドにワイルドカード文字(*)、絶対 URI、または絶対パスが含まれることを示します。ワイルドカード文字は、要求が特定のリソースではなくサーバ自体に該当することを示します。ワイルドカード文字を使用できるのは、使用されるメソッドが必ずしも特定のリソースに適用されるとは限らない場合だけです。次に指定例を示します。

OPTIONS * HTTP/1.1
 

ユーザ定義メソッドをワイルドカード URI を使って設定する場合は、CSS がこのユーザ定義メソッドをルールと照合するメソッド名を含む要求行があるヘッダーフィールド グループを使ってレイヤ 5 ルール(url "/*")を設定する必要があります。

authority :Request-URI フィールドの値がホスト名形式であることを示します。ホスト名形式で指定されたリソースを使用するのは、CONNECT メソッドだけです。次に指定例を示します。

CONNECT server.cisco.com:80 HTTP/1.1
 

たとえば、TREE という名前のユーザ定義メソッドを、Request-URI フィールドにワイルドカードを指定して設定する場合は、次のように入力します。

(config)# http-method parse user-defined-method TREE uri wildcard
 

) 既存のユーザ定義メソッドの URI リソースを変更する場合は、そのメソッドをいったん削除して再設定します。


ユーザ定義メソッドを削除するには、 no http-method parse user-defined-method コマンドを使用します。たとえば、次のように入力します。

(config)# no http-method parse user-defined-method TREE
 

HTTP メソッド解析の設定および状態の表示

CSS 上の HTTP メソッド解析の設定と処理状態を表示するには、
show http-methods コマンドを使用します。次に例を示します。

(config)# show http-methods
 

表 10-5 に、 show http-methods コマンドの各出力フィールドと、その説明を示します。

 

表 10-5 show http-methods コマンドの出力フィールド

フィールド
説明

HTTP Method Processing Summary

RFC-2518 Methods Full Processing Support:

RFC-2518 メソッドの処理状態。値は次のとおりです。

enabled :CSS はすべての RFC-2518 メソッドを処理し、コンテンツ ルールとの照合を試みる。

disabled :CSS は RFC-2518 で定義されている CONNECT、GET、HEAD、POST、PUT の各 HTTP メソッドを処理する。OPTIONS、TRACE、
PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE の各メソッドは CSS で認識されますが、透過キャッシュ アプリケーションにそのまま転送されます。この動作がデフォルトです。

User-defined methods:

ユーザ定義メソッドの数

Method Processing Detail:

Method Name

要求行に含まれているメソッド名。RFC-2518、
RFC-2616、ユーザ定義のいずれのメソッド名も指定できます。

URI Format:

CSS で処理される有効な URI の形式。値は次のとおりです。

wildcard :ワイルドカード文字(*)、絶対 URI 形式、または絶対パス形式

url :絶対 URI 形式または絶対パス形式

authority :ホスト名形式

Defined-In

メソッドと URI 形式を定義している文書。値は次のとおりです。

RFC-2616 :RFC-2616 で定義されているメソッドと URI 形式

RFC-2518 :RFC-2518 で定義されているメソッドと URI 形式

Custom :ユーザ側で定義したメソッドと URI 形式

Hit Counter

CSS でメソッドの一致が検出された回数。すべてのヒット カウンタの値をクリアするには、グローバル設定モードで http-method statistics clear コマンドを使用します。

拡張子修飾子リストの設定

拡張子修飾子リスト(EQL)はファイル拡張子のリストであり、このリストにより拡張子に基づいてコンテンツ ルールとの照合を行うことができます。EQL を有効にするには、レイヤ 5 コンテンツ ルールの URL の一部として EQL を関連付けます。 eql コマンドを使用すると、EQL の設定モードにアクセスして拡張子修飾子リストを設定することができます。作成する拡張子のリストを識別する名前を入力します。スペースを含まない 1~31 文字のテキスト文字列を引用符で囲まずに入力します。

次に例を示します。

(config)# eql graphics
(config-eql[graphics])#
 

EQL を削除するには、設定モードで no eql コマンドを使用します。たとえば、次のように入力します。

(config)# no eql graphics
 

EQL の作成後、そのリストに対して次のアトリビュートを設定することができます。

description :EQL の説明を記述する。64 文字以内のテキスト文字列を引用符で囲んで入力します。次に例を示します。

(config-eql[graphics])# description “This EQL specifies graphic file extensions”
 

extension name :CSS が照合するコンテンツの拡張子名を指定する。1~7 文字のテキスト文字列を入力します。サービスの EQL を設定する際には、必ず静的コンテンツの拡張子(.avi、.gif、.jpg など)を入力してください。動的コンテンツの拡張子(.asp、.html など)は入力しないでください。拡張子はどのような順序で入力しても構いません。

次に例を示します。

(config-eql[graphics])# extension pcx
 

必要に応じて、拡張子のタイプを表す説明を指定することもできます。64 文字以内のテキスト文字列を引用符で囲んで入力します。次に例を示します。

(config-eql[graphics])# extension gif “This is a graphics file”
 

EQL から拡張子を削除するには、 no extension コマンドを使用します。次に例を示します。

(config-eql[graphics])# no extension gif

URL での EQL の指定

サーバは、所有者コンテンツ ルールに指定された URL に基づいて選択されます。コンテンツへの要求が、事前に定義した EQL に含まれる拡張子に一致する場合に、CSS がサービスにアクセスできるようにするには、コンテンツに URL と EQL 名を指定します。

URL には、252 文字以内のテキスト文字列を引用符で囲んで指定し、直後に eql 、続いて EQL 名を入力します。この最大 252 文字の URL 文字列内で指定する個々のパスは、いずれも 32 文字以下でなければなりません。個々の URL パスは、2 つのスラッシュ(//)で囲まれた一連の文字で構成されます。


) URL に EQL を使用する場合、URL にファイルの拡張子を指定しないでください。ファイルの拡張子を指定すると、エラー メッセージが返されます。たとえば、url "/*.txt" eql graphics というコマンドを入力すると、エラー メッセージが返されます。コマンド url "/*" eql graphics は有効です。


次に有効な入力例を示します。

(config-owner-content[arrowpoint.com-products.html])# url “/*” eql graphics
 

下記の例では、一致するコンテンツ要求をすべて正しいサービスに送信することができます。

パス名 ( /customers/products )

EQL ( graphics ) にリストされた拡張子

(config-owner-content[arrowpoint.com-products.html])# url “/customers/products/*” eql graphics
 

コンテンツ ルールに設定された EQL 名および拡張子を表示するには、 show rule コマンドを使用します。 show rule コマンドとその出力については、 「コンテンツ ルールの設定」 を参照してください。

EQL の拡張子と説明の表示

既存の EQL 名のリストを表示するには、 eql ? コマンドを入力します。

次に入力例を示します。

(config)# eql ?
 

特定の EQL に設定されている拡張子(説明も含む)を表示するには、 show eql コマンドと EQL 名を入力します。次に入力例を示します。

(config)# show eql graphics
 

表 10-6 に、 show eql コマンドで表示されるフィールドについて説明します。

 

表 10-6 show eql コマンドの出力フィールド

フィールド
説明

EQL

EQL 名とその説明(設定されている場合)

Extensions

EQL 名に関連付けられたコンテンツ要求の拡張子とその説明(設定されている場合)

URL 修飾子リストの設定

URQL 設定モードでは、Uniform Resource Locator Qualifier List(URQL; URL 修飾子リスト)を設定することができます。URQL は、コンテンツの URL のグループであり、1 つ以上のコンテンツ ルールに関連付けます。CSS は、このリストを使用してサービスに送信する要求を識別します。例として、すべてのストリーミング ビデオ要求を複数の高性能サーバで処理する場合を考えます。そのコンテンツの複数の URL を含む URQL を 1 つ作成し、その URQL をコンテンツ ルールに関連付けます。これにより、それらのストリーミング ビデオの URL への要求がすべて、コンテンツ ルールで指定した高性能サーバ群に送信されます。URL をグループ化する URQL を作成すると、URL ごとに個別のコンテンツ ルールを作成する必要がなくなります。


) 同じコンテンツ ルール内で、url urqlapplication ssl の両方を指定することはできません。サブスクライバ サービスで URQL を指定することはできません。


URQL の設定については、次の各項を参照してください。

URQL の作成

URQL での URL の設定

URQL での URL のドメイン名の指定

コンテンツ ルールへの URQL の追加

URQL の説明の記述

URQL のアクティブ化

URQL の一時停止

startup-config ファイル内の URQL 設定

URQL の表示

URQL 設定のクイック スタート

表 10-7 に示すクイックスタートの手順を使用して、URQL を設定します。それぞれの手順には、作業に必要となる CLI コマンドも示しています。それぞれの機能の詳細については、この手順に続く各項を参照してください。

 

表 10-7 URQL 設定のクイック スタート

作業とコマンドの例

1. URQL を作成します。

(config)# urql videos
(config-urql[videos)#

2. 必要に応じて、URQL の説明を記述します。

(config-urql[videos])# description “cooking streaming video”

3. 次の方法で、URQL でグループ化する URL を設定します。

a. URL エントリを指定します。

(config-urql[videos])# url 10
 

b. URL を定義します。

config-urql[videos])# url 10 url “/cooking/cookies.avi”
 

c. 必要に応じて、URQL の説明を記述します。

(config-urql[videos])# url 10 description “making cookies”
 

4. URQL 内の URL のドメイン名を指定します。たとえば、次のように指定します。

(config-urql[videos])# domain “www.arrowpoint.com”

5. owner-content プロンプトで url コマンドを使用して、URQL をそのコンテンツ ルールに追加します。

(config-owner-content[chefsbest-recipes])# url urql videos

表 10-7 に示した各コマンドを実行すると、次のような実行設定が得られます。

!**************************** URQL ****************************
urql videos
description "cooking streaming video"
url 10
url 10 url "/cooking/cookies.avi"
url 10 description "making cookies"
domain "www.arrowpoint.com"
!*************************** OWNER ***************************
owner chefsbest
address "200 Beaver Brook Road, Boxborough, MA 01719"
content recipes
vip address 192.1.1.100
protocol tcp
port 80
url "urql videos"
add service server1
active
 

URQL の作成

URQL 設定モードにアクセスするには、 urql コマンドを使用します。プロンプトは、(config-urql [name]) に変わります。URQL モードでこのコマンドを使用して、他の URQL にアクセスすることもできます。

作成する URQL の名前または既存の URQL の名前を入力します。名前は、スペースを含まない 31 文字以内のテキスト文字列を引用符で囲まずに入力します。URQL を作成する場合、URQL モードで activate コマンドを使用してこのリストを有効にしない限り、この URQL は無効のままです。既存の URQL 名のリストを表示するには、次のコマンドを入力します。

(config)# urql ?
 

次に例を示します。

(config)# urql videos
(config-urql[videos)#
 

既存の URQL を削除するには、グローバル設定モードで次のコマンドを入力します。

(config) no urql videos
 

URQL を作成したら、続いてその URQL に含める URL を設定します。以降の項では、上記作業の実行方法について説明します。

URQL での URL の設定

url コマンドを使用して、URQL に入れたいコンテンツ要求の URL を追加し、必要に応じて説明を記述します。URQL での URL の設定方法については、次の各項で説明します。

URL エントリの指定

URL の定義

URL の説明の記述


) URL の定義、説明の記述、または URL のコンテンツ ルールへの関連付けを行う前に、URL エントリを作成する必要があります。


URL エントリの指定

URQL で URL エントリを指定するには、1~1000 の URL 番号を入力します。たとえば、次のように入力します。

(config-urql[videos])# url 10
 

URQL から URL エントリを削除するには、 no url コマンドを使用します。次に入力例を示します。

(config-urql[videos])# no url 10
 

URQL で追加の URL エントリを指定するには、 url コマンドを再入力します。次に例を示します。

(config-urql[videos])# url 20
(config-urql[videos])# url 30
(config-urql[videos])# url 40

URL の定義

指定したエントリに URL を定義するには、 url コマンドを使用します。URL は 252 文字以内のテキスト文字列を引用符で囲んで入力します。この最大 252 文字の URL 文字列内で指定する個々のパスは、いずれも 32 文字以下でなければなりません。個々の URL パスは、2 つのスラッシュ(//)で囲まれた一連の文字で構成されます。また、ピリオド(.)に続く拡張子部分の長さは 7 文字までです。

URL は、URL GET 要求と正確に一致する必要があります。URQL の URL エントリには、ワイルドカード、不完全な URL パス、および末尾の「/」文字を含めることはできません。適切な入力例を次に示します。

(config-urql[videos])# url 10 url “/cooking/cookies.avi”
 

エントリから URL を削除するには、 no url number url コマンドを使用します。エントリの URL を再定義する場合は、まずこのコマンドを使用して、割り当て済みの URL を削除します。次に入力例を示します。

(config-urql[videos])# no url 10 url
 

エントリの URL の定義を続けるには、 url entry url コマンドを再入力します。次に例を示します。

(config-urql[videos])# url 20 url “/cooking/fudge.avi”
(config-urql[videos])# url 30 url “/cooking/pie.avi”
(config-urql[videos])# url 40 url “/cooking/cake.avi”

URL の説明の記述

必要に応じて、URL の説明を記述することができます。64 文字以内のテキスト文字列を引用符で囲んで入力します。たとえば、次のように入力します。

(config-urql[videos])# url 10 description “making cookies”
 

URL の説明を削除するには、次のように入力します。

(config-urql[videos])# no url 10 description

URQL での URL のドメイン名の指定

domain コマンドを使用して、URQL で URL のドメイン名または IP アドレスを指定します。ドメイン名は、1~63 文字のニーモニック ホスト名形式
(www.arrowpoint.com など)で入力します。IP アドレスには、そのドメイン名の有効なアドレス(192.168.11.1 など)を入力します。


) URQL を有効にする前に、ドメインを割り当てる必要があります。既存の URQL ドメイン アドレスを変更するには、URQL を中断してからドメインを変更してください。


たとえば、次のように入力します。

(config-urql[videos])# domain “www.arrowpoint.com”
 

次の入力も有効です。

(config-urql[videos])# domain “192.168.11.1”

コンテンツ ルールへの URQL の追加

URQL を作成して設定したら、 url urql コマンドを使用して、設定済みのコンテンツ ルールにこのリストを追加します。URQL は、1 ルールにつき 1 つだけ割り当てることができます。また、コンテンツ ルールには、URL または URQL のいずれかを割り当てることができます。URQL のリストを表示するには、 urql ? コマンドを使用します。


) 同じコンテンツ ルール内で、url urqlapplication ssl の両方を指定することはできません。同じコンテンツ ルール内で、url urql とサブスクライバ サービスの両方を指定することはできません。


次に例を示します。

(config-owner-content[chefsbest-recipes])# url urql videos
 

コンテンツ ルールから URQL を削除するには、次のように入力します。

(config-owner-content[chefsbest-recipes])# no url urql
 

コンテンツ ルールに設定された URL を表示するには、そのコンテンツ ルールに対して show rule コマンドを入力します。 show rule コマンドとその出力については、 「コンテンツ ルールの設定」 を参照してください。

URQL の説明の記述

description コマンドを使用すると、URQL の説明を記述することができます。説明は、64 文字以内のテキスト文字列を引用符で囲んで入力します。

たとえば、次のように入力します。

(config-urql[videos])# description “cooking streaming video”
 

URQL の説明を削除するには、次のように入力します。

(config-urql[videos])# no description

URQL のアクティブ化

一時停止中の URQL をアクティブにするには、 active コマンドを使用します。URQL を作成しても、 active コマンドを使用して有効化しない限り、その URQL は一時停止のままです。


) URQL をアクティブにする前に、URL にドメインを割り当てる必要があります。この章の「URQL での URL のドメイン名の指定」を参照してください。


次に例を示します。

(config-urql[videos])# active

URQL の一時停止

現在割り当てられているすべてのコンテンツ ルールの URQL を一時停止にするには、 suspend コマンドを使用します。たとえば、次のように入力します。

(config-urql[videos])# suspend
 

URQL を再度アクティブにするには、 (config-urql) active コマンドを使用します。

startup-config ファイル内の URQL 設定

次の例は、startup-config ファイル内の URQL 設定を示しています。

!**************************** URQL **************************
urql excellence1
url 10
url 30
url 30 url “/arrowpoint.gif”
domain “192.168.128.109”
url 10 url “/”
urql excellence2
url 10
url 10 url “/poweredby.gif”
domain “192.168.128.109”

URQL の表示

URQL のリストを表示するには、次のように入力します。

(config)# urql ?
 

設定済みの URQL をすべて表示するには、次のように入力します。

(config)# show urql
 

特定の URQL を表示するには、次のように入力します。

(config)# show urql videos
 

表 10-8 に、 show urql コマンドで表示されるフィールドについて説明します。

 

表 10-8 show urql コマンドの出力フィールド

フィールド
説明

Name

URQL の名前

Description

URQL に設定されている説明

Domain

URQL に関連付けられている URL のドメイン名またはアドレス

Create Type

作成タイプ(static または dynamic)

State

URQL の状態(Active または Suspended)

Rules Associated

URQL に関連付けられたルールの数

表 10-9 に、指定した URQL の表示に含まれるその他のフィールドについて説明します。

 

表 10-9 指定の URQL のその他のフィールド

フィールド
説明

URQL Table Domain

URQL に関連付けられている URL のドメイン名またはアドレス

Number of entries configured

URQL の URL エントリの数

URL

URL

Description

URL に関連付けられている説明

Create Type

作成タイプ(static または dynamic)

State

URQL の状態(Active または Suspended)

CSD Entries

Content Server Database(CSD; コンテンツ サーバ データベース)エントリの数

Uniform Resource Locator(URL)の指定

コンテンツの Uniform Resource Locator(URL)を指定して、コンテンツ要求がルールに一致したときに CSS がリモート サービスにアクセスできるようにするには、 url コマンドを使用します。URL は、252 文字以内のテキスト文字列を引用符で囲んで入力します。この最大 252 文字の URL 文字列内で指定する個々のパスは、いずれも 32 文字以下でなければなりません。個々の URL パスは、ホスト名の先頭文字を示す 2 つのスラッシュ(//)と、ホスト名の末尾文字を示す 1 つのスラッシュ(/)で囲まれた一連の文字で構成されます。また、ピリオド(.)に続く拡張子部分の長さは 7 文字までです。


) URL 文字列にはパラメータ文字(?、#)は含めないでください。これらのパラメータ文字が検出されると、CSS はその位置を URL の終端と解釈します。


コンテンツ ルールの URL を変更するには、 no url コマンドを使用して最初に現在の URL を削除する必要があります。

url コンテンツ モードのコマンドのシンタックスおよびオプションは、次のとおりです。

url "/ url_name " :コンテンツの URL を指定する。 252 文字以内のテキスト文字列を引用符で囲んで入力します。 url_name コンテンツの URL になります。252 文字以内のテキスト文字列を引用符で囲んで入力します。URL の先頭にはスラッシュ(/)を入れる必要があります(たとえば、
"/announcements/prize.html")。

ドメイン名を指定する場合は、URL の先頭にスラッシュを 2 本(//)入れます。たとえば、"//www.arrowpoint.com/*" と記述することによって、ルールは、HTTP ホスト タグにドメイン名 www.arrowpoint.com がある HTTP トラフィックと一致します。

通常、ポート 80 を使用するトラフィックについては、ドメイン名にポート番号を付ける必要はありません。80 番以外のポートを使用する場合は、その番号をドメイン名に付加します。ドメイン名とポート番号はコロン(:)で区切ります。次に例を示します。

(config-owner-content[arrowpoint-rule1])# url “//www.arrowpoint.com:8080/*”
 

Secure Socket Layer(SSL)のセッション ID をベースにしたスティッキを使用するには、URL を /* に設定します。さらに、 (config-owner-content) port コマンドでポートを 443 に指定し、 (config-owner-content) advanced-balance ssl コマンドでスティッキを有効にします。次に、SSL アプリケーションのタイプを指定します。

ワイルドカード操作を指定して、ワイルドカードのマッチングを行うことができます。ワイルドカードのマッチングを指定するには、「*」文字を使用します。ディレクトリは 8 つまで指定できます。各ディレクトリ名は 32 文字までで、URL 全体で 252 文字まで指定できます。1 つの URL に指定できるワイルドカードは 1 つだけです。

次は、サポートされるワイルドカードの例です。

/*.html :拡張子が .html の要求にすべて一致する。

/announcements/* :ディレクトリ announcements のファイルに対する要求すべてに一致する。

/announcements/*.html :ディレクトリ announcements にあり、拡張子が .html のファイルに対する要求に一致する。

/announcements/new/*.jpg :ディレクトリ announcements/new にあり、拡張子が .jpg のファイルに対する要求すべてに一致する。

url "/ url_path /*" eql eql_name :指定した 拡張子修飾子リスト(EQL)にファイル拡張子が定義されているコンテンツ ファイルに URL を指定する。 url_path は、EQL にファイル拡張子が定義されているコンテンツ ファイルへのパスです。テキスト文字列を引用符で囲んで入力します。また、次の文字も含める必要があります。

引用符で囲むパスの先頭にスラッシュ(/)を入れる。キャッシング環境では、 url_path の先頭にスラッシュを 2 本(//)入れることで、ドメイン コンテンツ ルールを設定することができます。

引用符で囲むパスの末尾にスラッシュとアスタリスク(/*)を入れる。

たとえば、"/announcements/new/*" のように指定します。

eql_name は EQL の名前です。EQL のリストを表示するには、 eql ? コマンドを使用します。

url "/ url_path /*" dql dql_name { eql_name } :指定したドメイン修飾子リスト(DQL)内でドメイン名が定義されているコンテンツ ファイルの URL を指定する。 URL に、ドメイン名とともに DQL は使用できません。DQL 名の後ろに EQL を指定して、DQL の一致基準の 1 つとしてファイル拡張子を指定することができます。

url_path 変数は、DQL にドメインが定義されているコンテンツ ファイルへのパスです。テキスト文字列を引用符で囲んで入力します。また、次の文字も含める必要があります。

引用符で囲むパスの先頭にスラッシュ(/)を入れる。キャッシング環境では、 url_path の先頭にスラッシュを 2 本(//)入れることで、ドメイン コンテンツ ルールを設定することができます。

引用符で囲むパスの先頭にスラッシュを 2 本(//)入れる。

dql_name 変数は DQL の名前です。DQL のリストを表示するには、 dql ? コマンドを使用します。

url urql urql_name :URL のグループからなる URL 修飾子リスト(URQL)をコンテンツ ルールに指定する。 url urql application ssl application sip 、またはサブスクライバ サービスを、同じコンテンツ ルールに指定することはできません。

urql_name 変数は URQL の名前です。URQL は、1 ルールにつき 1 つだけ割り当てることができます。URQL のリストを表示するには、 urql ? コマンドを入力します。


) キャッシング環境では、url_name または url_path の先頭にスラッシュを 2 本(//)入れることで、ドメイン コンテンツ ルールを設定することができます。このようなルールは、HTTP ホスト タグに指定のドメイン名がある HTTP トラフィックに一致します。


たとえば、ディレクトリ announcements に存在する、拡張子が .html のコンテンツに対する要求すべてに一致する URL を指定するには、次のように入力します。

(config-owner-content[arrowpoint-products.html])# url "/announcements/*.html"
 

URL を削除するには、次のように入力します。

(config-owner-content[arrowpoint-products.html])# no url
 

URL から URQL を削除するには、次のように入力します。

(config-owner-content[arrowpoint-products.html])# no url urql
 

コンテンツ ルールに設定された URL を表示するには、そのコンテンツ ルールに対して show rule コマンドを入力します。

URL での拡張子修飾子リストの指定

サーバは、所有者コンテンツ ルールに指定された URL に基づいて選択されます。コンテンツへの要求が、事前に定義した EQL に含まれる拡張子に一致する場合に、CSS がサービスにアクセスできるようにするには、コンテンツに URL と EQL 名を指定します。EQL の作成については、「拡張子修飾子リストの設定」の項を参照してください。

URL には、252 文字以内のテキスト文字列を引用符で囲んで指定し、直後に eql 、続いて EQL 名を入力します。この最大 252 文字の URL 文字列内で指定する個々のパスは、いずれも 32 文字以下でなければなりません。個々の URL パスは、2 つのスラッシュ(//)で囲まれた一連の文字で構成されます。


) URL に EQL を使用する場合、URL にファイルの拡張子を指定しないでください。ファイルの拡張子を指定すると、エラー メッセージが返されます。たとえば、url "/*.txt" eql Cacheable というコマンドを入力すると、エラー メッセージが返されます。この場合は、url "/*" eql Cacheable というコマンドを使用してください。


次に例を示します。

(config-owner-content[arrowpoint-products.html])# url "/*" eql graphics
 

下記の例では、次のパス名と拡張子に一致するコンテンツへの要求をすべて正しいサービスに送信することができます。

パス名(/customers/products)

EQL(graphics)にリストされている拡張子

(config-owner-content[arrowpoint-products.html])# url "/customers/products/*" eql graphics
 

コンテンツ ルールの EQL を表示するには、 show rule コマンドを使用します。

一度に解析するパケットの数の指定

一部の環境では、URL、クッキー文字列、または他の HTTP ヘッダー情報が複数のパケットにまたがっている場合があります。 このような環境では、レイヤ 5 の情報を得るために 20 までのパケットを解析してから、ロード バランシングの判断を行うことができます。デフォルトでは、CSS は 6 つのパケットを解析します。

ロード バランシングの判断は、一致が見つかるとただちに行われるので、設定した数のパケットをすべて解析する必要はありません。 複数のパケットを解析すると接続の遅延は必然的に長くなるため、複数のパケットにわたる長い文字列はパフォーマンスに影響を与えます。

spanning-packets コマンドを使用して、HTTP ヘッダーの終了文字列の検索単位となるパケット数を設定することができます。パケットの数を変更するには、1~20 の数値を入力します。デフォルト値は 6 です。たとえば、10 までのパケットを設定するには、次のように入力します。

(config)# spanning-packets 10
 

複数パケットの数をデフォルト値の 6 に戻すには、次のように入力します。

(config)# no spanning-packets

負荷しきい値の指定

サービスの負荷メトリックがこのしきい値を超えると、そのローカル サービスは使用できなくなり、リモート サービスにリダイレクトされます。リモート サービスを定義するには、サービス モードで type redirect コマンドを使用します( 「サービスの設定」 「サービス タイプの指定」 を参照)。

コンテンツ ルールに、各ローカル サービスのアベイラビリティについて正規化された負荷しきい値を設定するには、 load-threshold コマンドを使用します。 負荷しきい値は 2~254 の整数で入力します。デフォルトは 254 です。この値はサービスの上限しきい値です。この値を超えるとサービスは使用できなくなります。サービスの負荷を表示するには、 show service コマンドを使用します。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# load-threshold 100
 

負荷しきい値をデフォルト値の 254 にリセットするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no load-threshold

CSS の Ping 応答決定へのサービス組み込み

デフォルトで、CSS は、コンテンツ ルールのローカル サービスに alive の状態のサービスがある場合、コンテンツ ルールに設定された Virtual IP(VIP; 仮想 IP)アドレスへの ping 要求に応答します。リモート サービス、たとえばタイプがリダイレクトのサービスを VIP アドレスへの ping 要求に応答する決定に組み込むには、 vip-ping-response local-remote コマンドを使用します。たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# vip-ping-response local-remote
 

CSS を、Ping 応答決定にローカル サービスだけを考慮するデフォルト動作にリセットするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# vip-ping-response local
 

TCP フローのリセット拒否の許可

CSS のデフォルトの動作では、要求されたコンテンツのフローが到達不能になった宛先 IP アドレスにマッピングされている場合、クライアントへの TCP RST(リセット)フレーム送信が無効化されます。 ただし、 flow-reset-reject コマンドを使用すれば、CSS フロー マネージャ サブシステムによる TCP RST フレームの送信を有効化することが可能です。 flow-reset-reject コマンドは、要求が処理されない場合に、CSS クライアントがハングアップしたり、要求を再送信したりしないようにします。また、このコマンドを使用すると、UDP フローでは、UDP フローのフロー キャッシュが消去されて、必要に応じて、次の要求が別の IP アドレスに再マッピングされるようにし、以前にマッピングされた IP アドレスを使用しないようにすることができます。 flow-reset-reject コマンドは、コンテンツ ルールごとに適用されます。

CSS が TCP RST フレームを送信できるようにするには、次のように入力します。

(config-owner-content[rule1])# flow-reset-reject
 

CSS を、TCP RST フレームを送信しないデフォルト状態に戻すには、次のように入力します。

(config-owner-content[rule1])# no flow-reset-reject

持続性、再マッピング、およびリダイレクションの設定

固定接続の存続期間中に、CSS は、コンテンツ ルール、ロード バランシング、およびサービスのアベイラビリティに基づいて、クライアントの接続をいつ新しいサービスに移動させる必要があるかを判断しなければなりません。状況によって、クライアントの接続を移動する必要がない場合と、移動が必須になる場合があります。ここでは、これを判断するように、CSS を設定する方法について説明します。判断基準は次のとおりです。

コンテンツ ルールの持続性

バイパスの持続性

HTTP リダイレクション

サービスの再マッピング

コンテンツ ルールの持続性の設定

CSS は、クライアントからコンテンツへの要求を受信すると、コンテンツ ルールに要求が一致するかどうかをチェックして、要求の処理に最適のサービスを決定します。要求がコンテンツ ルールに一致すると、CSS はコンテンツ ルールに指定された最適なサービスとクライアントの接続を確立します。新しいコンテンツ要求が次の条件を満たす限り、CSS はデフォルトで、そのフロー セッションの期間中、同じ接続にクライアントを保持します。

現在のサービスを指定した同一のコンテンツ ルールに一致する。

現在のサービスを含む新しいコンテンツ ルールに一致する。これは、そのコンテンツ ルールに現在のサービスと異なる最適のサービスが指定されている場合も含みます。

この CSS の動作は、コンテンツ ルールの持続性と呼ばれます。透過キャッシュ(コンテンツを事前に取り込んでいる)、またはミラー化されたコンテンツ サーバを使用している場合、各サービスで同一のコンテンツが利用できるので、この方式は効果的に機能します。

上記の基準を満たす場合に限りサーバとの固定接続を維持するには、コンテンツ設定モードで persistent コマンドを使用します。デフォルトでは、持続性は有効に設定されています。持続性を無効にすると、同じルールの、より適切なサービスに接続を移動するか、またはキャッシュ バイパス機能(EQL バイパスまたはフェールオーバー バイパス)を使用することができます。

次に例を示します。

(config-owner-content[arrowpoint-rule1])# persistent
 

次のような場合、コンテンツ ルールに no persistent コマンドを使用します。

プロキシ キャッシュを使用する際のドメインまたはドメイン ハッシュのバランス方式

透過キャッシュを使用する際の URL または URL ハッシュのバランス方式

透過キャッシュを使用する際のバイパスによるフェールオーバー方式

透過キャッシュの EQL バイパス

コンテンツ ルールへのソーリー サーバの追加


advanced-balance arrowpoint-cookie コマンドを使用してコンテンツ ルールに ArrowPoint クッキーを設定する際に、CSS が固定 HTTP 接続で ArrowPoint クッキーなしの次の GET を受信した場合には、CSS は実行設定内の持続性の設定をすべて無視し、バックエンド接続を新しいサーバに再マップしてから新しい ArrowPoint クッキーを挿入します。


持続性を無効にするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no persistent

) 固定接続上のコンテンツ要求が、現在のサービスを含まない新しいコンテンツ ルールに一致する場合、または持続性が無効にされており、コンテンツ ルールにより適切なサービスが設定されている場合は、CSS は persistence reset コマンドの設定に基づいて(設定されている場合)、現在の接続を新しい最適なサービスにリダイレクトまたは再マッピングします。persistence reset コマンドを設定しない場合は、デフォルトで HTTP リダイレクトが行われます。HTTP リダイレクションの詳細については、この章で後述する「HTTP リダイレクションとサービスの再マッピングの設定」を参照してください。


バイパスの持続性の設定

CSS がサービスをバイパスする場合(たとえば、透過キャッシュが停止しており、フェールオーバー バイパスが設定されている場合)で、同一の TCP 接続からの次のコンテンツ要求が、停止している透過キャッシュを含むコンテンツ ルールに一致するときは、バイパスしていたキャッシュがオンラインに戻った場合でも、デフォルトで、継続してそのキャッシュをバイパスします。このような場合、コンテンツ要求は通常、元のサーバに送信されます。この動作をバイパスの持続性と呼びます。

bypass persistence グローバル設定コマンドを persistence reset コマンドと併せて使用すると、バイパスされた接続をリダイレクトまたは再マッピングするように設定することができます。

bypass persistence コマンドを使用すると、コンテンツ要求がコンテンツ ルールに一致してもそれ以前の要求でバイパスが行われていた場合に、CSS が再マッピングとリダイレクションのいずれかの操作を使って、バイパスされたサービスをいつリセットするかを決定することができます。このグローバル コマンドはすべてのフローに影響を与えます。デフォルトで、バイパスの持続性は有効に設定されています。

たとえば、次のように入力します。

(config)# bypass persistence disable
 

この場合、CSS は persistence reset コマンドの設定に従って、再マッピングまたはリダイレクションを使用して、接続をリセットします。

(config)# bypass persistence enable
 

この場合、CSS は再マッピングまたはリダイレクションを使用して接続をリセットせずに、サービスを継続してバイパスします。

HTTP リダイレクションとサービスの再マッピングの設定

さまざまなコンテンツを複数のサーバに置く必要がある場合(たとえば、サーバのディスク スペース節約、ロード バランシング上の理由、プロキシ キャッシュの使用時など)、コンテンツ ルールの持続性は役立ちません。そのような場合は、この章の「コンテンツ ルールの持続性の設定」で前述したとおり、no persistent コマンドを使用して持続性を無効にできます。

現在のサービスで利用できないコンテンツへの要求を受信した場合、CSS はサービスへの現在の接続をリセットして、要求されたコンテンツのある別のサービス(たとえば、他のプロキシ キャッシュや、元のサーバ)への新しい接続を確立する必要があります。この処理は、次のいずれかの方法で行うことができます。

リダイレクション:クライアントから CSS への(フロントエンド)接続と、CSS からサービスへの(バックエンド)接続を両方リセットし、要求されたコンテンツのある最適なサービスへのフローを新しく確立する HTTP の手法

サービスの再マッピング:現在のサービスへのバックエンド接続だけをリセットして、要求されたコンテンツのある最適なサービスへのバックエンド接続を新しく確立する手法。この手法は、フロントエンド接続をリセットして再度確立する必要がないので、リダイレクションよりも速く、効率的です。サービスの再マッピングでは、ポート番号が重複しないように、ポート マッピングを厳密に管理します。


) サービスの再マッピングは、ステートレス冗長フェールオーバー
redundancy-l4-stateless コマンド)と互換性がありません。サービスの再マッピングにより CSS はポート マッピングを行うことができます。これにより、すべてのフローの送信元ポートが NAT 変換されます。ステートレス冗長フェールオーバーでは、CSS は送信元ポートを NAT 変換できません。ステートレス冗長フェールオーバーの詳細については、『Cisco Content Services Switch Redundancy Configuration Guide』を参照してください。


接続をリセットして新しいバックエンド サービスにするために、HTTP リダイレクションまたはバックエンドの再マッピングを行うには、コンテンツ ルールの no persistent コマンドに、 グローバル設定モードの persistence reset コマンドを組み合わせて使用します。persistence reset グローバル コマンドは、リダイレクションまたは再マッピングを必要とするすべてのフロー設定に影響を与えます。


no persistent コマンドとグローバルの persistent reset remap コマンド、および urlhash(または domainhash)ロード バランシング方式を使ってコンテンツ ルールを作成すると、HTTP 1.1 接続上の HTTP GET によって直前の GET とは異なるハッシュ値が得られたときに、サーバの再マッピングが行われます。


たとえば、リダイレクションを有効にするには、次のように入力します。

(config)# persistence reset redirect
 

また、サービスの再マッピングを有効にするには、次のように入力します。

(config)# persistence reset remap

) リダイレクト タイプのサービスを選択している場合、再マッピングは使用できません。 「サービスの設定」「サービス タイプの指定」を参照してください。


トポロジが、サーバに対し ECMP を使用し、サービスに設定されたサーバ ポート NAT を使用する CSS 11800 から構成される場合、パケットが適切に処理されるように、次のいずれかの作業を行います。

persistence reset remap コマンドを使用して、サービスの再マッピングを有効にします。

add destination service コマンドを使用して、コンテンツ ルールでサービスのソース グループを作成します。


advanced-balance arrowpoint-cookie コマンドを使用してコンテンツ ルールに ArrowPoint クッキーを設定する際に、CSS が固定 HTTP 接続で ArrowPoint クッキーなしの次の GET を受信した場合には、CSS は実行設定内の持続性の設定をすべて無視し、バックエンド接続を新しいサーバに再マップしてから新しい ArrowPoint クッキーを挿入します。


コンテンツへの要求のリダイレクション

コンテンツ ルールに HTTP のステータス コード 302(オブジェクトの移動)を設定して、ルールが管理するコンテンツの代替場所を指定するには、 redirect コマンドを使用します。このコマンドは、次のような場合に使用します。

後続の要求に対して、現在のアドレスでコンテンツを利用できないようにする場合

要求元に URL を返信する場合。HTTP 要求に redirect を強制するには、コンテンツ ルールに URL を追加する必要があります。たとえば、url "/*" を追加します。URL はスペースを含まない 252 文字以内のテキスト文字列を引用符で囲んで入力します。


) コンテンツにステータス コード 404(メッセージのドロップ)も指定した場合、コード 302 が優先されます。

リダイレクト専用のコンテンツ ルールには、サービスは設定しないでください。


次に例を示します。

(config-owner-content[arrowpoint-rule1])# redirect "//www.arrowpoint.com/newlocation.html"
 

リダイレクト先の URL を削除するには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no redirect
 

HTTP 302 リダイレクト メッセージへの TCP FIN フラグまたは RST フラグの設定

CSS は HTTP 302 リダイレクト メッセージを送信するときに、デフォルトでは最初の接続で FIN フラグを送信し、固定接続の存続期間中の後続要求では RST フラグを送信します。ただし、クライアントに送信するパケットに Microsoft IE ブラウザへのリダイレクト メッセージが含まれている場合には、このデフォルトのフラグ設定はブラウザに適さないことがあります。リダイレクト メッセージとともに送信するフラグを指定するには、グローバル設定モードで
http-redirect-option コマンドを使用します。このコマンドのシンタックスは次のとおりです。

http-redirect-option [ fin-rst | fin-fin | rst-rst ]

各キーワードの意味を次に示します。

fin-rst :デフォルトの動作。CSS は最初の接続で FIN フラグを送信し、固定接続の存続期間中の後続要求では RST フラグを送信します。

fin-fin :CSS は常に FIN フラグを送信します。

rst-rst :CSS は常に RST フラグを送信します。

たとえば、302 リダイレクト メッセージとともに、常に FIN フラグが送信されるように設定するには、次のように入力します。

(config)# http-redirect-option fin-fin
 

デフォルトの動作にリセットするには、次のように入力します。

(config)# http-redirect-option fin-rst
 

HTTP リダイレクト メッセージのフラグ設定は、 show http-redirect-option コマンドで確認できます。次に例を示します。

(config)# show http-redirect-option
HTTP Redirect Option: fin-rst
 
 

持続性の設定の表示

persistence reset と bypass persistence の設定内容を表示するには、show remap コマンドを使用します。このコマンドは、RMON、URQL、VLAN 設定モード以外のすべてのモードで使用できます。

表 10-10 に、 show remap コマンドで表示されるフィールドについて説明します。

 

表 10-10 show remap コマンドの出力フィールド

フィールド
説明

Group SFP Port Map Info

このフィールドは、現在使用されていません。

Persistence Reset Method

接続を新しいバックエンド サービスにリセットするときに使用され、設定された持続性をリセットする方式。次の方式があります。

redirect :接続をリセットして新しいバックエンド サービスに接続するときに、HTTP リダイレクションが行われる。HTTP リダイレクションが起きると接続の両端がリセットされる。

remap :接続をリセットして新しいバックエンド サービスに接続するときに、バックエンドの再マッピング操作が行われる。

Bypass Persistence

バイパス持続性の設定。指定可能な設定は次のとおりです。

disable :コンテンツ要求がコンテンツ ルールに一致するが、それ以前の要求でバイパスが行われていた場合に、CSS は再マッピングと HTTP リダイレクションのいずれかの操作を使って、サービスのバイパスをリセットする。

enable :CSS は再マッピングまたはリダイレクションを使用して接続をリセットせずに、サービスを継続してバイパスする。デフォルトで、バイパスの持続性は有効に設定されています。

フェールオーバーの定義


) CSS は、アクティブ-バックアップ VIP 冗長と仮想インターフェイス冗長を持つ環境にある Cisco CSS 11500 シリーズのピアで Adaptive Session Redundancy(ASR)をサポートします。これにより、既存フローのステートフル フェールオーバーが可能になります。ASR の詳細については、『Cisco Content Services Switch Global Server Load-Balancing Configuration Guide』を参照してください。


サービスに障害がある場合や一時停止した場合のコンテンツ要求の処理方法を定義するには、 failover コマンドを使用します。この設定を使用するには、各サービスにキープアライブが設定されていることを確認してください。つまり、キープアライブのタイプを none に設定しないでください(キープアライブのデフォルトは ICMP)。CSS は、キープアライブの設定を使用してサービスをモニタし、サーバの状態とアベイラビリティを判断します。

failover コマンドは、次のキャッシュのロード バランシング タイプに適用されます。

balance domain

balance url

balance srcip

balance destip

balance domainhash

balance urlhash


remove service コマンドを使用してサービスを削除すると、残りのサービスのバランスが取リ直されます。CSS はフェールオーバーの設定を使用しません。


このコマンドには、次のオプションがあります。

failover bypass 障害が発生したサービスをすべてバイパスして、コンテンツ要求を本来の宛先サーバに直接送信する。このオプションは、プロキシ キャッシュ構成や透過キャッシュ構成で、障害が発生したキャッシュをバイパスし、コンテンツが存在するサーバにコンテンツ要求を直接送信する場合に使用します。

failover linear (デフォルト):コンテンツ要求を残りのサービス間で均等に配分する。

failover next :障害が発生したサービスの次のキャッシュ サービスへコンテンツ要求を送信する。CSS は、サービスの設定順序を参照して、コンテンツ要求のリダイレクト先のサービスを選択します。

たとえば、次のように入力します。

(config-owner-content[arrowpoint-rule1])# failover bypass
 

デフォルト設定の failover linear に戻すには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# no failover
 

図 10-2 に、 failover next に設定された 3 つのキャッシュ サービスを示します。ServerB に障害が発生すると、ServerB のコンテンツ要求は、コンテンツ ルールで ServerB の次に設定されている ServerC に送信されます。

図 10-2 failover next に設定された ServerB

 

図 10-3 に示すように、ServerC に障害が発生すると、ServerC の次にはサービスが何も設定されていないので、ServerC 宛てのコンテンツ要求は ServerA に送信されます。

図 10-3 failover next に設定された ServerC

 

図 10-4 には、フェールオーバーが linear に設定された 3 つのキャッシュ サービスを示します。ServerB を一時停止した場合や、ServerB に障害が発生した場合、CSS は残りのサービスの間で再度負荷のバランスはとりません。ServerB のキャッシュの負荷は、ServerA と ServerC の間で均等に分散されます。

図 10-4図 10-5 では、負荷バランスをアルファベットで示しています。

図 10-4 failover linear に設定されたサービスの一時停止または障害

 

図 10-5 も、failover linear に設定された 3 つのキャッシュ サービスを示していますが、この例では、所有者コンテンツ モードで remove service コマンドを使用して ServerB を削除しています。サービスを削除した場合はフェールオーバーの設定が適用されないため、CSS は残りのサービス間で再度負荷のバランスをとります。

図 10-5 failover linear に設定されたサービスの削除

 

アプリケーション タイプの指定

CSS は、アプリケーション タイプによってデータ ストリームを正しく解釈し、コンテンツ ルールとの照合および解析を行います。アプリケーション タイプを指定しないと、データ ストリームのパケットは拒否されます。標準外のポートには、アプリケーション タイプを必ず定義してください。コンテンツ ルールに関連付けるアプリケーションのタイプを指定するには、 application コマンドを使用します。

レイヤ 5 コンテンツ ルールを HTTP 以外のアプリケーションに設定する場合は、適切な application のタイプを使用してレイヤ 5 ルールを有効にします。

レイヤ 5 コンテンツ ルールは、RFC-2518 の CONNECT、GET、HEAD、POST、PUSH、PUT の各 HTTP メソッドをサポートします。また、透過キャッシュ環境では、CSS は RFC-2518 拡張メソッドを認識して宛先サーバに直接転送しますが、ロード バランシングは行いません。RFC-2518 拡張メソッドには、OPTIONS、TRACE および PROPFIND、PROPPATCH、MKCOL、MOVE、LOCK、UNLOCK、COPY、DELETE があります。RFC-2518 拡張メソッドをサポートするように CSS を設定する方法については、「HTTP メソッド解析の設定」を参照してください。

application コマンドでは、次のアプリケーション タイプを指定することができます。

bypass :コンテンツ ルールの照合をバイパスして、要求を本来の宛先サーバに直接送信する。

ftp-control :FTP データ ストリームを処理する。FTP 接続のコンテンツ ルールを、標準とは異なる FTP 制御ポートやデータ ポートを使用可能にするように設定する方法については、「FTP 接続のコンテンツ ルールの設定」および「FTP で標準以外のポートを使用するための CSS の設定」を参照してください。

http (デフォルト):HTTP データ ストリームを処理する。

realaudio-control : RealAudio Control データ ストリームを処理する。

ssl : Secure Sockets Layer(SSL)プロトコルのデータ ストリームを処理する。

sip :Process Session Initiation Protocol(SIP) UDP 制御パケットを処理する。CLI で application sip と入力したが、プロトコルとポートをまだ設定していない場合には、CSS によって実行設定ファイルにプロトコルとして UDP、ポート番号として 5060 が自動的に指定されます。


url urql と一緒に application ssl または application sip を、同じコンテンツ ルールに設定することはできません。


ssl アプリケーション タイプは、常に ssl 拡張ロード バランシング方式と共に設定してください。 application コマンドと advanced-balance コマンドの両方を共に設定して、SSL セッション ID を正しく解釈し、その ID に基づきクライアントをサーバに固定することが重要です。詳細については、 「コンテンツ ルールへの スティッキ パラメータの設定」 「スティッキ コンテンツへの拡張ロード バランシング方式の指定」を参照してください。

アプリケーション タイプを削除するには、次のコマンドを入力します。

(config-owner-content[arrowpoint-rule1])# no application

FTP 接続のコンテンツ ルールの設定

クライアントが Port(アクティブ)モードの FTP 経由で接続する場合は、コンテンツ ルールを ftp-control アプリケーション タイプで設定する必要があります。このアプリケーション タイプでは、CSS は指定されたポートに着信する FTP 要求だけを処理します。

(config-owner-content[arrowpoint-rule1])# application ftp-control
 

次の例は、コンテンツ ルール ftp_rule の実行設定の一部です。このコンテンツ ルールでは、CSS は ポート 21 に着信する FTP 要求を処理します。

!************************** OWNER **************************
owner arrowpoint
content ftp_rule
vip address 192.168.3.6
protocol tcp
port 21
application ftp-control
add service serv1
add service serv2
add service serv3
active
 

また、制御チャネルはサーバによって開始される新しいフローであるため、ソース グループも設定する必要があります。ソース グループの設定には、コンテンツ ルールと同じ VIP アドレスを使用します。FTP 接続のソース グループを設定する方法については、 「サービスのソース グループの設定」 「FTP 接続のためのソース グループの設定」を参照してください。

FTP 制御チャネルは、アイドル状態のまま 10 分が経過すると CSS によって切断されます。また、ファイル転送の実行中も、転送開始から 10 分間が超過した時点でチャネルは切断されます。このアイドル タイムアウトはアクティブ FTP だけが対象であり、PASV FTP には適用されません。

所有者コンテンツ モードで、関連するコンテンツ ルールを対象に
flow-timeout-multiplier コマンドを実行すれば、FTP ファイル転送が完了するまでの予想時間に合わせて、タイムアウトの長さを設定できます。CSS は、このコマンドで指定された値を基に、アイドル状態のフローを切断するまでの待機時間(秒単位)を決定します。具体的には、指定した値に係数 16 を乗じ、その結果が待機時間になります。指定できる値は 0~65533 の範囲内の整数です。

たとえば、タイムアウトを 16 分(960 秒)に設定するには、次のコマンドを入力します。

(config-owner-content[cisco-rule1])# flow-timeout-multiplier 60

FTP で標準以外のポートを使用するための CSS の設定

CSS で FTP 接続を使用する場合、デフォルトでは標準の FTP ポート(制御ポート:21、データ ポート:20)を使用する必要があります。CSS を通過する FTP データ接続のデータ ポートは固定され、NAT 変換は行われません。

ただし、 ftp non-standards-ports コマンドを使用すれば、FTP の制御接続とデータ接続が標準(ポート 20 と21)以外のポートを使用するように CSS を設定できます。この場合、CSS を通過する FTP データ接続のデータ ポートは固定されません。

次に例を示します。

(config)# ftp non-standard-ports
 

ftp non-standards-ports コマンドを使用して標準以外の FTP ポートを使用可能にするように設定する場合、コンテンツ ルールに、必ず application ftp-control コマンドを追加する必要があります。


FTP 接続に標準以外の制御ポートとデータ ポートの使用を許可しないデフォルト状態に戻すには、このコマンドを no 形式で実行します。次に例を示します。

(config)# no ftp non-standard-ports
 

コンテンツ要求による透過キャッシュのバイパスの許可

区切り文字の「#」と「?」は、その直後の引数にコンテンツが依存していることを示します。サーバが返したコンテンツは、コンテンツ要求自体に依存しており、キャッシュ不能とみなされるので、このコンテンツ要求は本来の宛先サーバに送られます。

コンテンツ要求で特殊な区切り文字が検出されたときに、その要求に透過キャッシュをバイパスさせるには、 param-bypass コマンドを使用します。このコマンドには、次のオプションがあります。

param-bypass disable (デフォルト):特殊な区切り文字を含むコンテンツ要求は、透過キャッシュをバイパスしない。

param-bypass enable :特殊な区切り文字を含むコンテンツ要求が透過キャッシュをバイパスし、本来の宛先サーバに転送される。

たとえば、 param-bypass コマンドを有効にするには、次のように入力します。

(config-owner-content[arrowpoint-rule1])# param-bypass enable

コンテンツの表示

show content コマンドによって、CSS の Content Service Database(CSD; コンテンツ サービス データベース)のコンテンツ エントリを表示することができます。このコマンドは、すべてのモードで使用可能です。

CSS 11503 または CSS 11506 の特定モジュールを対象に、特定のコンテンツ エントリのコンテンツを表示するには、次のように show content コマンドを入力します。

show content slot_number { start-index index_number }

変数とオプションは、次のとおりです。

slot_number :CSS 11503 または CSS 11506 のシャーシの特定スロットにあるモジュールのコンテンツを表示する。CSS 11503 の場合、選択可能な値は 1~3 です。CSS 11506 の場合、選択可能な値は 1~6 です。スロット番号を指定しない場合、CSS のスロット 1 にある SCM のコンテンツ エントリが表示されます。

start-index index_number index_number パラメータで指定した番号以降のコンテンツ エントリが表示される。この変数は、ブラウズを開始する CSS のコンテンツの場所を定義します。指定したインデックス番号から、64 KB までの情報を受信できます。情報をさらに表示するには、最後に表示されたインデックスを指定して show content コマンドを再実行します。インデックス番号を指定するには、0~4095 の数値を入力します。開始インデックスを指定しないと、0 のコンテンツ エントリから表示されます。

CSS 11501、11503、または CSS 11506 のコンテンツ サービス データベースにあるコンテンツ エントリをすべて表示するには、オプションや変数なしで show content コマンドを使用します。

たとえば、CSS 11503 シャーシのスロット 2 にあるモジュールのコンテンツを、インデックス 150 から表示するには、次のように入力します。

(config)# show content slot 2 start-index 150
 

表 10-11 に、 show content コマンドで表示されるフィールドについて説明します。


show content コマンドの出力では、URQL エントリはアスタリスク(*)で表示されます。


 

表 10-11 show content コマンドの出力フィールド

フィールド
説明

Pieces of Content for Slot

モジュールがあるシャーシのスロット番号

Subslot

セッション プロセッサがあるモジュールのスロット番号

Total Content

コンテンツの合計エントリ数

Index

CSD 内で認識されているコンテンツを表す一意のインデックス

<address>

コンテンツの IP アドレス

Protocol

コンテンツの IP プロトコル

Port

コンテンツのプロトコル ポート

Best Effort

このコンテンツの QoS クラス。このフィールドは、CSS では現在使用していません。

Streamed

コンテンツがストリーミング メディア(ビデオやオーディオ)かどうかを指定します。このフィールドは、CSS では現在使用していません。

URL

コンテンツの URL

Domain

コンテンツのドメイン名

コンテンツ ルールの表示

特定のコンテンツ ルールの情報、または現在 CSS に設定されているすべてのコンテンツ ルールの情報を表示するには、 show rule コマンドを使用します。コンテンツ設定モードで show rule コマンドを使用すると、現在のルールの情報だけが表示されます。他のコンテンツ ルールの所有者とコンテンツ ルール名は指定できません。

次の show rule コマンドは、ユーザ、スーパーユーザ、グローバル設定、所有者、およびコンテンツ モードから実行できます。


) 次のコマンドの所有者変数とコンテンツ ルール変数は、コンテンツ設定モードでは使用できません。


show rule :現在 CSS に設定されているすべての所有者とコンテンツ ルールを表示する。

show rule-summary :所有者のコンテンツ情報の要約を表示する。

show rule owner_name :指定した所有者のコンテンツについて、show rule コマンドと同じ情報を表示する。

show rule owner_name content_rule_name :show rule コマンドと同じ情報(特定の所有者とコンテンツについてだけ)を表示する。

show rule owner_name content_rule_name acl :指定したコンテンツ ルールの ACL アトリビュートを表示する。

show rule owner_name content_rule_name all :指定したコンテンツ ルールのすべてのアトリビュートを表示する。

show rule owner_name content_rule_name dns :指定したコンテンツ ルールの DNS アトリビュートを表示する。

show rule owner_name content_rule_name header-field :指定したコンテンツ ルールのヘッダー フィールド アトリビュートを表示する。

show rule owner_name content_rule_name hot-list :指定したコンテンツ ルールのホットリスト アトリビュートを表示する。

show rule owner_name content_rule_name services :指定したコンテンツ ルールのサービスを表示する。

show rule owner_name content_rule_name statistics :指定したコンテンツ ルールの統計情報を表示する。

show rule owner_name content_rule_name sticky :指定したコンテンツ ルールのスティッキ アトリビュートを表示する。

コンテンツ ルール情報をすべて表示するには、次のように入力します。

# show rule
 

すべてのコンテンツ ルールの要約を表示するには、次のように入力します。

# show rule-summary
 

所有者のすべてのルール アトリビュートを表示するには、次のように入力します。

# show rule owner content_rule all

CntRuleName および OwnerName フィールドには、設定されているデータの先頭 16 文字が表示されます。URL フィールドには、設定されているデータの先頭 10 文字が表示されます。


表 10-12 に、 show rule コマンドで表示されるフィールドについて説明します。

 

表 10-12 show rule コマンドの出力フィールド

フィールド
説明

Name

コンテンツ ルールの名前

Owner

ルールの所有者

Author

ルールの作成者(ローカル CSS またはリモート CSS ピア)

Index

CSS がルールに割り当てた一意のインデックス。この番号はインデックスが作成された順に割り当てられます。

State

ルールの状態(active または suspend)

Type

ルールに関連付けられているアプリケーション タイプ。次の値があります。

bypass :コンテンツ ルールの照合をバイパスして要求を本来の宛先サーバに直接送信する。

http (デフォルト):HTTP データ ストリームを処理する。

ftp-control :FTP データ ストリームを処理する。

realaudio-control :RealAudio Control データ ストリームを処理する。

ssl :Secure Socket Layer(SSL)プロトコルのデータ ストリームを処理する。

L3

送信先 IP アドレス

L4

送信先のプロトコルとポート

URL

コンテンツの URL

URQL

関連付けられている URL 修飾子リストの名前

EQL

関連付けられている EQL の名前

DQL

関連付けられている DQL の名前

Header Field Group

関連付けられているヘッダーフィールド グループの名前

Total Bytes

コンテンツ ルールへの合計バイト数

Total Frames

コンテンツ ルールへの合計フレーム数

Total Redirects

コンテンツ ルール別合計リダイレクト数( redirect コマンドがコンテンツ ルールに対して設定されている場合)。このフィールドの値は、コンテンツ要求が代替場所にリダイレクトされるたびに増加します。

Total Rejects

コンテンツ ルール別合計拒否数。このフィールドは、コンテンツ ルールのサービスがすべて使用できない場合に増加します。

Overload Rejects

ルールでは利用可能なサービスだが、過負荷のためにコンテンツ ルールで拒否されたサービスの合計数

Balance

コンテンツ ルールのロード バランシング アルゴリズム。次の値があります。

ACA :ArrowPoint Content Awareness(ACA)アルゴリズム。CSS はコンテンツ要求の頻度とサーバのキャッシュ サイズとの相関関係を使って、そのサーバのキャッシュ ヒット率を高めます。

destip :送信先 IP アドレスによる分配アルゴリズム。CSS は、同じ送信先 IP アドレスを持つすべてのクライアント要求を同じサービスに送ります。

domain :ドメイン名による分配アルゴリズム。CSS は要求 URI のドメイン名を使用して、クライアント要求を適切なサービスに送ります。

domainhash :ドメイン文字列に基づく、CSS の内部ハッシュ アルゴリズム。CSS はこのアルゴリズムを使用して、ドメイン文字列全体に対してハッシュをとります。CSS はこのハッシュ結果を使用してサーバを選択します。

leastconn :最小接続数によるアルゴリズム。CSS は、実行中のサービスのうち、最も接続数が少ないサービスを選択します。

roundrobin :ラウンドロビン アルゴリズム(デフォルト)。

srcip :送信元 IP アドレスによる分配アルゴリズム。CSS は、同じ送信元 IP アドレスを持つすべてのクライアント要求を同じサービスに送ります。

url :URL による分配アルゴリズム。CSS は、リダイレクト URL でその URL(先頭のスラッシュは除外)を使用して、クライアント要求を適切なサービスに送ります。

urlhash :URL 文字列に基づく、CSS の内部ハッシュ アルゴリズム。CSS はこのアルゴリズムを使用して、URL 文字列全体に対してハッシュをとります。CSS はこのハッシュ結果を使用してサーバを選択します。

Balance(続き)

weightedrr :加重ラウンドロビン アルゴリズム。CSS は、ラウンドロビン アルゴリズムを使用しますが、それぞれのサービスに重み付けします。サービスをルールに追加するときに、サービスの重みを設定できます。

Advanced Balance

コンテンツ ルールに適用する拡張ロード バランシングの方式(スティッキ性を含む)。次の値があります。

none :ルールに対して拡張バランシングを無効にする。これはデフォルト設定です。

arrowpoint-cookie :コンテンツ ルールで、ArrowPoint で生成されたクッキー内にある、選択されたサーバの一意のサービス識別子情報に基づいて、クライアントをサーバに固定できるようにする。


arrowpoint-cookie expiration コマンドと
advanced-balance arrowpoint-cookie コマンドを設定すると CSS の CPU 使用率が急激に上昇し、パフォーマンスの低下につながる恐れがあります。


cookies :コンテンツ ルールで、HTTP クッキー ヘッダー内にある設定済みの文字列に基づいて、クライアントをサーバに固定できるようにする。このオプションを使用する場合は、コンテンツ ルールでポートを指定する必要があります。これによって、CSS はその接続をスプーフします。

cookieurl :advanced-balance cookies と同じだが、HTTP パケット内でクッキー ヘッダーが見つからない場合、このタイプのフェールオーバーでは、同じ文字列基準に基づき、URL 拡張子(URL の「?」の後の部分)を検索する。このオプションを、すべてのレイヤ 5 HTTP コンテンツ ルールで使用します。

Advanced Balance(続き)

sticky-srcip :コンテンツ ルールで、クライアントの IP アドレスに基づいてクライアントをサーバに固定できるようにする。これは、レイヤ 3 のスティッキ性とも呼ばれます。このオプションは、レイヤ 3、4、または 5 のコンテンツ ルールで使用できます。

sticky-srcip-dstport :コンテンツ ルールで、クライアントの IP アドレスとサーバの宛先ポート番号の両方に基づいて、クライアントをサーバに固定できるようにする。これは、レイヤ 4 のスティッキ性とも呼ばれます。このオプションは、レイヤ 4 またはレイヤ 5 のコンテンツ ルールで使用できます。

ssl :コンテンツ ルールで、サーバが割り当てた Secure Socket Layer(SSL)バージョン 3 のセッション ID に基づいて、クライアントをサーバに固定できるようにする。コンテンツ ルールのアプリケーション タイプは、SSL にする必要があります。このオプションを使用する場合は、コンテンツ ルールでポートを指定する必要があります。これによって、CSS はその接続をスプーフします。

url :コンテンツ ルールで、HTTP 要求の URL 内にある設定済みの文字列に基づいて、クライアントをサーバに固定できるようにする。このオプションを使用する場合は、コンテンツ ルールでポートを指定する必要があります。これによって、CSS はその接続をスプーフします。

Sticky Mask

スティッキに使用するサブネット マスク。デフォルトは 255.255.255.255 です。

Sticky Inactivity Timeout

コンテンツ ルールによるスティッキ接続の最大継続時間。この時間が経過するとスティッキ接続がタイムアウトになり、CSS は対応するスティッキ テーブル内のエントリを削除します。範囲は 0~65535 分です。デフォルト値は 0 で、この機能が無効であることを示します。

Sticky No Cookie Found Action

CSS が、クライアント要求内にクッキー ヘッダーまたは指定したクッキー文字列を見つけられないときに、スティッキ クッキーのコンテンツ ルールに対して実行する必要があるアクション。次の値があります。

loadbalance :クライアント要求内でクッキーが見つからない場合、CSS は設定済みのバランス方式を使用する。これがデフォルト設定です。

redirect "URL" :クライアント要求内でクッキーが見つからない場合、CSS は指定された URL 文字列にクライアント要求をリダイレクトする。このオプションを使用する場合は、リダイレクト URL も指定する必要があります。リダイレクト URL は、0~64 文字のテキスト文字列を引用符で囲んで入力します。

reject :クライアント要求内にクッキーが見つからない場合、CSS はクライアント要求を拒否する。

service name :クライアント要求内にクッキーが見つからない場合、CSS は指定されたサーバにクッキーなしのクライアント要求を送信する。

Sticky Server Down Failover

スティッキ文字列は見つかったが、関連のサービスに障害が発生した場合または一時停止の場合に CSS が実行しなければならないアクション。次の値があります。

Balance :このフェールオーバー方式では、設定済みのロード バランシング方式に基づいてサービスを使用する(デフォルト)。

Redirect :このフェールオーバー方式では、現在設定されているリダイレクト文字列に基づいてサービスを使用する。リダイレクト文字列を設定していない場合は、ロード バランシング方式を使用します。

Reject :このフェールオーバー方式では、コンテンツ要求を拒否する。

Sticky-srcip :このフェールオーバー方式では、クライアントの IP アドレスに基づいてサービスを使用する。これは、スティッキ設定に依存します。

Sticky-srcip-dstport :このフェイルオーバー方式では、クライアントの IP アドレスとサーバの宛先ポートに基づいてサービスを使用する。これは、スティッキ設定に依存します。

ArrowPoint Cookie Path

ArrowPoint クッキーを送信するパス名。クッキーのデフォルト パスは、「/」です。

ArrowPoint Cookie Expiration

ArrowPoint クッキーに関連付けられている時間と比較される有効期限。有効期限を設定しない場合、クッキーはクライアントがブラウザを終了すると同時に期限が切れます。

ArrowPoint Cookie CSS/Browser Expired

ブラウザが有効期限に基づいて ArrowPoint クッキーを失効させることができるように、arrowpoint-cookie
browser-expire コマンドを有効にしているかどうかを示します。このコマンドが有効である場合、フィールドには「CSS」の代わりに「Browser」と表示されます。デフォルトは「CSS」です。

ArrowPoint Cookie Service

クッキーの有効期限が新しいクッキーの送信前に失効した場合に、 arrowpoint-cookie expire-services コマンドを発行して、サービス情報を失効させるどうかを指定します。デフォルトでは、クッキーの期限が切れると、CSS は期限の切れたクッキーからのサーバ情報を持つ新しいクッキーを送信します。

ArrowPoint Cookie Advanced

advanced-balance arrowpoint-cookie コマンドを発行して、ArrowPoint で生成されたクッキーに含まれている選択されたサーバの一意なサービス ID に基づき、コンテンツ ルールがクライアントをサーバに固定できるようにするかどうかを指定します。

ArrowPoint Cookie Format

ArrowPoint クッキーの有効期限の形式について、RFC 2822 に準拠した形式を有効にするか無効にするかを指定します。 arrowpoint-cookie rfc2822-compliant コマンドは、
ArrowPoint クッキーの有効期限のシンタックスを RFC 2822 準拠に設定します。このコマンドを使用すると、
arrowpoint-cookie の有効期限のシンタックスは、曜日が 3 文字だけで表され(たとえば「Tues」ではなく「Tue」)、月の初めの文字だけが大文字(たとえば「JAN」ではなく「Jan」)になります。

String Match Criteria

文字列結果を求めるための文字列基準と、その文字列結果が示す宛先サーバを選択する方式。文字列結果は、設定されているスティッキ タイプに従って、クッキー ヘッダー、URL、または URL 拡張子のいずれかに存在するスティッキ文字列になります。次のフィールドを参照してください。

String Range

クライアントから送られたクッキー、URL、URL 拡張子内の開始バイト位置と終了バイト位置。バイトの範囲を指定すると、CSS はその範囲内にある情報だけを処理します。

範囲は 1~1999 です。デフォルトの開始バイトの位置は 1 です。

範囲は 2~2000 です。デフォルトの終了バイトの位置は 100 です。

String Prefix

スティッキ範囲内の文字列プレフィックス。文字列プレフィックスを設定しない場合、文字列はスティッキ タイプに応じて、クッキー、URL、または URL 拡張子の先頭から有効になります。文字列プレフィックスが設定されているが、スティッキの範囲内で指定されていない場合、ロード バランシング方式はデフォルトのラウンドロビン方式になります。デフォルトはプレフィックスなしです(””)。

String Eos-Char

スティッキ文字列の区切り文字として使用される ASCII 文字

String Ascii-Conversion

文字列に処理を適用する前に、特定のスティッキ文字列範囲内でのエスケープした特殊文字の ASCII 変換を有効または無効にするかを指定します。デフォルトでは、ACSII 変換は有効です。

String Skip-Len

文字列結果を検索する際に、スキップするプレフィックスの後のバイト数。デフォルトは 0 です。範囲は 0~64 です。

String Process-Len

string prefix コマンドで指定されたプレフィックスと、 string skip-length で指定されたスキップ バイトの後に位置する、文字列操作の対象バイトの長さ。範囲は 0~64 です。デフォルトは 0 です。

String Operation

文字列結果の宛先サーバを選択する方式。文字列結果は、文字列基準コマンドの設定によって決まります。次の値があります。

match-service-cookie :スティッキ文字列内のサービス クッキーを照合してサーバを選択する。これはデフォルト設定です。一致するものがない場合は、設定されたロード バランシング方式(ラウンドロビンなど)を使用してサーバが選択されます。これは、デフォルトの方式です。

hash-a :ハッシュ文字列に基本ハッシュ アルゴリズムを適用して、ハッシュ キーを生成する。

hash-crc32 :ハッシュ文字列に CRC32 アルゴリズムを適用して、ハッシュ キーを生成する。

hash-xor :ハッシュ文字列の各バイトに XOR(排他的 OR)を適用して、最終的なハッシュ キーを取得する。

Location-Cookie

ロケーション クッキー文字列の形式(NAME=VALUE)

Location-Cookie Expiration

ロケーション クッキーの有効期限の日付と時刻。この値はクライアント ブラウザに対し、クッキーの有効期限がいつ切れるかを指示します。

Cookie-Domain

ロケーション クッキーのドメイン名。クッキー ドメイン名を設定することで、ブラウザは、指定したドメイン名で終わるサイトにクッキーを返送できるようになります。

Redirect

ルールに一致するとクライアントに送信される HTTP 302 リダイレクト メッセージに使用するテキスト

Persistence

サーバとの固定接続を維持するかどうかを指定します。デフォルトでは、持続性は有効に設定されています。

Param-Bypass

CSS が要求内で特殊な区切り文字を検出したときに、コンテンツ要求が透過キャッシュをバイパスするかどうかを指定します。区切り文字として「#」と「?」が使用されている場合、これらの区切り文字に続く引数にコンテンツが依存しています。デフォルトでは、バイパスは無効です。

Session Redundancy

ASR がルールで有効か無効かを示します。ASR の詳細については、『 Cisco Content Services Switch Redundancy
Configuration Guide
』を参照してください。

Redund Glb Index

所有者コンテンツ設定モードで redundant-index コマンドを使用してコンテンツ ルールに割り当てた ASR の一意のグローバル インデックス値

IP Redundancy

ルールで IP の冗長性が設定された場合の、その状態。設定できる値は、Master、Backup または Down です。IP の冗長性が設定されていない場合、状態は Not Redundant になります。

Flow Timeout Multiplier

フローのアイドル状態が継続しうる最大時間(秒単位)。この時間が経過すると、CSS は flow-timeout-multiplier コマンドによる設定に従って、そのフローのリソースを再要求します。 flow-timeout-multiplier コマンドの詳細については、 「フロー パラメータとポート マッピング パラメータの設定」 を参照してください。

Rule Services

次のような設定情報や統計情報を提供するコンテンツ ルールのサービスです。

Local Load Threshold

コンテンツ ルールの各ローカル サービスのアベイラビリティに基づいて正規化された負荷しきい値。サービス負荷のメトリックがこのしきい値を超えると、そのローカル サービスは使用できなくなり、リモート サービスへリダイレクトされます。範囲は 2~254 です。デフォルトは 254(最大負荷)です。値 255は、サービスがダウンしていることを表します。

PrimarySorryServer

コンテンツ ルールの他のすべてのサービスが利用できないときに使用されるプライマリ サービス

SecondSorryServer

コンテンツ ルールの他のすべてのサービスが利用できないときに使用されるセカンダリ サービス

Name

サービスの名前

Hits

サービスのコンテンツ ヒット数

Wgt

コンテンツ ルールで ACA、加重ラウンドロビン、および SASP または DFP ロード バランシング方式を設定しているときに使用されるサービスの重み。重みが大きいサービスには、より多くの要求がリダイレクトされます。重みの数値の前に付加した文字には次の意味があります。

A = SASP から通知された重み

D = DFP から報告された重み

R = 所有者コンテンツ モードで add service weight コマンドを使用してサーバに設定された重み

S = サービス モードで weight コマンドを使用してサーバに設定された重み

State

サービスの状態

Ld

サービス負荷。範囲は 2~255 です。255 は、サービスが利用できないことを示します。

KAlive

サービスのキープアライブ タイプ

Conn

現在サービスにマッピングされている接続の数

DNS

CSS DNS リゾルバが、DNS クライアントの問い合せに対する応答としてそのサービスを選択した回数

DNS Names

ドメイン ネーム システムの名前

DNS TTL

存続可能時間(秒)。この値は、問い合せに対する IP アドレスの応答を DNS クライアントが記憶している期間を決定します。

DNS Balance

CSS によるドメイン名要求の IP アドレスへの解決先。次の値があります。

leastloaded :要求を、すべてのローカル ドメイン サイトまたはリモート ドメイン サイトのうち負荷が最小のサイトに解決する。CSS は最初に負荷の値を比較します。ドメイン サイト間の負荷の差が 50 以内である場合は、応答時間が比較されます。応答時間が最も短いサイトが、最小負荷サイトとみなされます。

Preferlocal :要求をローカル VIP アドレスに解決する。すべてのローカル システムでその負荷しきい値を超えている場合、最小負荷のリモート システムの VIP アドレスが、そのドメイン名の解決先アドレスとして選択されます。

roundrobin :ローカルとリモートのコンテンツ ドメイン サイト間で負荷を均等に分散してドメイン名を解決し、要求を解決する。ローカルの負荷しきい値を超えたサイトは使用されません。

useownerdnsbalance :所有者に割り当てられた DNS ロード バランシング方式を使用して要求を解決する。これは、コンテンツ ルールのデフォルトの方式です。所有者方式を設定しない場合は、デフォルトの所有者の DNS ロード バランシング方式であるラウンドロビンが使用されます。

Hotlist

ホットリストをイネーブルにするかどうかを指定します。

Size

ルールに保持されているホットリスト エントリの合計数。範囲は 1~100 です。デフォルトは 10 です。

Type

ホットリストのタイプ。現在、CSS ではヒット カウント ホットリスト タイプだけをサポートします。これが、デフォルトの設定です。ヒット カウントは、コンテンツがアクセスされた回数です。

Threshold

間隔あたりのヒット カウントのしきい値。この値を下回るヒット数のコンテンツはホットではないとみなされます。範囲は 0~65535 です。デフォルトは 0 です。

Interval

ホットリストを更新する間隔(分)。範囲は 1~60 です。デフォルトは 1 です。

Associated ACLs

コンテンツ ルールに関連付けられた ACL

TCP RST Client If Service Unreachable

フローが、到達不可能になったサービスにマッピングされている場合、CSS のフロー管理サブシステムが TCP RST(リセット)フレームを送信できるように、 flow-reset-reject コマンドを有効にしているかどうかを示す。デフォルトでは、 flow-reset-reject コマンドは無効です。

コンテンツ ルールでのカウンタのクリア

CSS では、次のカウンタをクリアできます。

すべてのコンテンツ ルール、または現在のコンテンツ ルールだけに関連するカウンタ

コンテンツ ルールの単一のサービス、またはすべてのサービスに関連するカウンタ

zero コマンドとそのオプションを使用すると、コンテンツ ルールのカウンタやコンテンツ ルールに関連するサービスをクリアし、カウンタをゼロに設定できます。

ここでは、次の内容について説明します。

コンテンツ ルールのカウンタのクリア

コンテンツ ルールでのサービス統計情報カウンタのクリア

コンテンツ ルールのカウンタのクリア

すべてのコンテンツ ルールのカウンタをゼロにリセットするには、 zero all コマンドを使用します。 show summary コマンドの出力では、リセットされたカウンタの統計情報はゼロになっています。


zero コマンドをオプションなしで入力すると、現在のコンテンツ ルールのカウンタだけがゼロに設定されます。


次にコマンドの使用例を示します。

(config-owner-content[rule1])# zero all

コンテンツ ルールでのサービス統計情報カウンタのクリア

コンテンツ ルールに関連するすべての CSS サービスのサービス統計情報カウンタをクリアするには、 zero コマンドを使用します。コンテンツ ルールに関連する特定のサービスのサービス統計情報カウンタをクリアするには、 zero コマンドとそのサービスの名前を使用します。この場合、指定したサービスのカウンタだけがゼロにリセットされます。

show service コマンドの出力で、リセットされたカウンタの統計情報はゼロになります。

次の zero コマンドはコンテンツ モードで実行できます。

zero total-connections :指定したコンテンツ ルールに関連するすべてのサービスで Total Connections カウンタをゼロに設定する。

zero total-reused-connections :指定したコンテンツ ルールに関連するすべてのサービスで Total Reused Connections カウンタをゼロに設定する。

zero state-transitions :指定したコンテンツ ルールに関連するすべてのサービスで State Transitions カウンタをゼロに設定する。

次の zero コマンドはコンテンツ モードで実行できます。

zero total-connections service service_name :コンテンツ ルールに関連するサービスのうち、指定したサービスだけを対象に、Total Connections カウンタをゼロに設定する。

zero total-reused-connections service service_name :コンテンツ ルールに関連するサービスのうち、指定したサービスだけを対象に、Total Reused
Connections カウンタをゼロに設定する。

zero state-transitions service service_name コンテンツ ルールに関連するサービスのうち、指定したサービスだけを対象に、State Transitions カウンタをゼロに設定する。

たとえば、指定したコンテンツ ルールに関連するすべてのサービスでカウンタをクリアするには、次のように入力します。

(config-owner-content[rule1])# zero total-connections
 

たとえば、コンテンツ ルールの特定のサービスでカウンタをクリアするには、次のように入力します。

(config-owner-content[rule1])# zero total-connections service serv1

以降の内容について

コンテンツ ルールを作成すると、そのコンテンツ ルールに対するスティッキ パラメータを設定できます。スティッキ パラメータの設定の詳細については、 「コンテンツ ルールへの スティッキ パラメータの設定」 を参照してください。