Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
キャッシング プロトコルの設定
キャッシング プロトコルの設定
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

キャッシング プロトコルの設定

FTP 接続の設定

ContentEngine GUI を使用した FTP 接続パラメータの設定

CLI コマンドを使用した FTP 接続パラメータの設定

CLI コマンドを使用した FTP 接続の設定例

FTP キャッシュ新鮮度の設定

ContentEngine GUI を使用した FTP キャッシュ オブジェクト新鮮度の設定

CLI コマンドを使用した FTP キャッシュ オブジェクト新鮮度の設定

HTTP および HTTPS 接続パラメータの設定

HTTP 接続パラメータの設定

ContentEngine GUI を使用した HTTP 接続設定

CLI コマンドを使用する HTTP 接続設定

HTTP キャッシュ新鮮度パラメータの設定

ContentEngine GUI を使用した HTTP キャッシュ オブジェクト新鮮度の設定

認証済み HTTP キャッシュの設定

ContentEngine GUI を使用した認証済み HTTP キャッシュの設定

CLI コマンドを使用する認証済み HTTP キャッシュパラメータの設定

拡張 HTTP キャッシュ認証の設定

HTTP Range 要求のキャッシング設定

Range 要求でのオブジェクト全体のキャッシング

HTTP Cache On Abort の設定

永続的接続の設定

永続的接続のイネーブル化

永続的接続のディセーブル化

ヒーリング モードのイネーブル化

HTTPS 関連パラメータの設定

使用方法のガイドラインおよび例

CLI コマンドを使用した HTTPS 関連パラメータの設定

HTTPS プロキシ パラメータ設定を行う CLI の例

ContentEngine GUI を使用した HTTPS プロキシの設定

HTTPS キャッシング用の証明書と鍵の設定

HTTP および HTTPS 発信プロキシの除外設定

ContentEngine GUI を使用した HTTP および HTTPS 発信プロキシの除外パラメータ設定

CLI コマンドを使用した HTTP および HTTPS 発信プロキシの除外パラメータ設定

Content Engine セキュリティ

HTTPS 統計レポーティング

HTTPS トランザクションのロギング

HTTPS TCP キープアライブ

TFTP サーバおよびゲートウェイの設定

ローカルに配置する Content Engine 上での TFTP サービスおよびゲートウェイの使用

TFTP サーバおよびゲートウェイのイネーブル化

TFTP サーバおよびゲートウェイの設定

TFTP サーバおよびゲートウェイの設定例

ICP パラメータの設定

ICP クライアント パラメータの設定

ContentEngine GUI を使用した ICP クライアントのパラメータ設定

CLI コマンドを使用した ICP クライアントのパラメータ設定

ICP サーバのパラメータ設定

ContentEngine GUI を使用した ICP クライアントのパラメータ設定

CLI コマンドを使用した ICP クライアントのパラメータ設定

WCCP のパラメータ設定

Content Engine 上での WCCP のイネーブル化

Content Engine 上での WCCP 2 サービスのイネーブル化

ContentEngine GUI を使用した Content Engine 上での WCCP 2 サービスのイネーブル化

CLI コマンドを使用した WCCP Version 2 サービスの設定

WCCP 透過キャッシュ オプションの設定

認証トラフィックの設定

WCCP バイパスのパラメータ設定

ContentEngine GUI を使用した WCCP バイパスの設定

CLI コマンドを使用した WCCP バイパスの設定

キャッシング プロトコルの設定

この章では、ローカルに配置する Content Engine に対して、FTP、HTTP、HTTPS、ICP、WCCPなどのキャッシング プロトコルを設定する方法について説明します。

「FTP 接続の設定」

「HTTP および HTTPS 接続パラメータの設定」

「TFTP サーバおよびゲートウェイの設定」

「ICP パラメータの設定」

「WCCP のパラメータ設定」


) この章で使用される CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


FTP 接続の設定

Content Engine は、プロキシ モードに設定されているときに、HTTP 転送によるFTP スタイルの要求を処理できます。Content Engine は FTP 要求をクライアントから受信すると、Content Engine 自体のキャッシュを検索して要求を処理します。オブジェクトがキャッシュにない場合、Content Engine は、アップストリームの FTP プロキシ サーバからオブジェクトをフェッチするか(このプロキシ サーバが設定されている場合)、またはオリジン FTP サーバからオブジェクトをフェッチします。

ACNS 5.1 ソフトウェアは、Content Engine 上の FTP ネイティブ キャッシングもサポートします。Content Engine GUI または CLI を使用して、ローカルに配置する Content Engine 上に FTP 接続パラメータを設定することもできます。


) FTP over HTTP およびネイティブ FTP のサポートの詳細は、「FTP およびキャッシング」 を参照してください。FTP プロキシの設定例については、「FTP プロキシの設定例」を参照してください。


Content Engine GUI を使用した FTP 接続パラメータの設定

ローカルに配置する Content Engine 上に FTP 接続パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > FTP Proxy の順に選択します。FTP Proxy ウィンドウが表示されます(図 9-1 を参照)。

図 9-1 FTP Proxy ウィンドウ

 

ステップ 2 Content Engine が特定のポートで FTP プロキシの要求を受け入れるように設定するには、 Enable Incoming FTP Proxy On オプション ボタンをクリックします。

ステップ 3 Incoming FTP Proxy Port List フィールドに、FTP プロキシ サーバが要求を受信するときに使用するポート番号を入力します。

ステップ 4 Content Engine がすべての FTP キャッシュ ミス トラフィックを親キャッシュに(ICP または WCCP を使用せずに)送信するように設定するには、 Enable Outgoing FTP Proxy On オプション ボタンをクリックします。

ステップ 5 Outgoing Proxy Address フィールドに、発信 FTP プロキシの IP アドレスを入力します。

ステップ 6 Outgoing FTP Proxy Port フィールドに、ステップ 5 で指定した発信プロキシ アドレスに対応するポート番号を入力します。

ステップ 7 匿名 FTP アクセス時に使用するパスワードを入力します。このフィールドに何も入力されていない場合、このフィールドはデフォルトの値に戻されます。デフォルトのパスワード文字列は anonymous@hostname です。

ステップ 8 Update をクリックして設定を保存します。


 

CLI コマンドを使用した FTP 接続パラメータの設定

ローカルに配置する Content Engine 上で、 ftp proxy コマンドを使用して FTP 接続パラメータを設定することもできます。 表 9-1 では、FTP 接続の設定パラメータについて説明します。これらのパラメータは、Content Engine GUI(図 9-1)に表示され、対応する CLI コマンドを提供します。

 

表 9-1 FTP 接続設定の GUI フィールド

Content Engine GUI
フィールド
説明
CLI コマンド

Enable Incoming FTP Proxy

ポート 80 以外のポートに着信する FTP 要求も受け入れるように、Content Engine を設定する。

ftp proxy incoming

Incoming FTP Proxy Port List

プロキシ サーバまたは Content Engine が FTP 要求を受信するために使用するポート番号。この番号の範囲は 1 ~ 65535 です。最大 8 ポートまで指定できます。

ftp proxy incoming portnumber

Enable Outgoing FTP Proxy

FTP キャッシュ ミスの要求トラフィックを受信するように、発信プロキシ サーバ、または別の Content Engine を設定する(ICP または WCCP を使用しない)。

ftp proxy outgoing

Outgoing FTP Proxy Address

複数の発信プロキシ サーバを設定する。発信 FTP プロキシ サーバのホスト名または IP アドレスを入力します。

ftp proxy outgoing host { hostname | ipaddress }

Outgoing FTP Proxy Port

発信 FTP プロキシのホスト名に対応するポート番号。

ftp proxy outgoing host { hostname | ipaddress } ports 1-65535

Anonymous Password

匿名 FTP アクセス時に使用するパスワード。デフォルトのパスワード ストリングは anonymous@hostname です。

ftp {proxy active-mode enable | anonymous-pswd passwd | incoming ports | outgoing host { hostname | ip-address } port}

CLI コマンドを使用した FTP 接続の設定例

表 9-2 では、ローカルに配置する Content Engine 上で CLI を使用して FTP 接続を設定する例の一部を示しています。

 

表 9-2 ローカルの Content Engine で FTP 接続設定を行う CLI の例

目的
コマンド

Content Engine のポート 8080、8081、9090 上で着信 FTP プロキシを設定します。最大 8 つまでの着信プロキシ ポートを同一コマンド ラインで設定できます。

ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

前例で入力されたリストから、1 つの FTP プロキシ ポートを除去します。ポート 8080 および 9090 は、引き続き Content Engine の FTP プロキシ ポートとして残ります。

ContentEngine(config)# no ftp proxy incoming 8081
 
 

Content Engine 上の FTP プロキシ ポートすべてを使用不可にします。

ContentEngine(config)# no ftp proxy incoming

IP アドレス 172.31.76.76 をもつアップストリームの FTP プロキシをポート 8888 上で設定します。

ContentEngine(config)# ftp proxy outgoing host 172.31.76.76 8888

FTP サーバと交信するときに Content Engine が使用する匿名パスワード ストリングを指定します。デフォルトのパスワード ストリングは anonymous@hostname です。

ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostname

ポート 8080、8081、および 9090 上で着信 FTP プロキシを設定します。同じコマンド行で、最大 8 つまでの着信プロキシ ポートを設定します。

ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

前例で入力されたリストから、1 つの FTP プロキシ ポートを除去します。ポート 8080 および 9090 は、引き続き FTP プロキシ ポートのままです。

ContentEngine(config)# no ftp proxy incoming 8081
 

すべての FTP プロキシ ポートを使用可能にします。

ContentEngine(config)# no ftp proxy incoming
 

IP アドレス 172.16.76.76 をもつアップストリームの FTP プロキシをポート 8888 上で設定します。

ContentEngine(config)# ftp proxy outgoing host 172.16.76.76 8888

FTP キャッシュ新鮮度の設定

ACNS 5.x ソフトウェアは、HTTP オブジェクト、および FTP オブジェクトの新鮮度とキャッシュ ヒット率とのバランスを取るように調整することができます。ACNS ソフトウェアのデフォルト パラメータに重み付けをして、キャッシュ ヒット率の最大化よりも新鮮度の高いコンテンツの確保を優先しています。この方法を採用することで古いコンテンツをサービスしてキャッシュ ヒット率を上げるという望ましくない状況を避けています。

FTP キャッシュ新鮮度のパラメータを設定するときは、次の点に注意してください。

キャッシュに保存できる FTP オブジェクト、または HTTP オブジェクトの最大サイズを指定できます。FTP オブジェクトと HTTP オブジェクトの最大制限サイズは、どちらも 204,799 キロバイトです。設定可能な上限を超えるサイズのオブジェクトは、Content Engine に保存されなくなります。

経過時間乗数(age multiplier)の値を設定して、Content Engine がオリジン Web サーバに if-modified-since (MS) 要求を出す際の、オブジェクトの最長存続可能時間(Time To Live: TTL)の割合(パーセント)を制御し、オブジェクトの 新鮮度を有効にします。この値の範囲は、0 ~ 100% です。デフォルト値は、テキスト ファイルの場合は 30%、バイナリ オブジェクトの場合は 60% です。

最短および最長の存続可能時間(TTL)の値を設定して、キャッシュ内の HTTP オブジェクト、および FTP オブジェクトの存続時間を制限できます。デフォルトでは、HTTP キャッシング可能オブジェクトは、最短で 5 分間、最長で 3 ~ 7 日間(テキスト タイプのオブジェクトの場合は 3 日間、バイナリ オブジェクトの場合は 7 日間)保持されます。オブジェクトの存続時間が明示的に失効している場合は、この設定は TTL 設定に優先します。デフォルト値は、テキスト ファイルの場合は 3 日間、バイナリ オブジェクトの場合は 7 日間です。

最長 TTL に有効な値は、次のとおりです。

日単位: 1 ~ 1825

時間単位:1 ~ 43800

分単位:1 ~ 2628000

秒単位:1 ~ 157680000

HTTP オブジェクトと FTP オブジェクトの場合、最短存続可能時間を設定するには、 http min-ttl 、および ftp min-ttl グローバル設定コマンドを使用します。最長存続可能時間を設定するには、 http max-ttl 、および ftp max-ttl コマンドを使用します。

http age-multiplier グローバル設定コマンドを使用すると、Content Engine は、オブジェクトの前回の更新から経過した時間にパーセント率(%)を掛けて、おおよその期限切れ日を算出することにより、オブジェクトの存続日数を推定できます。この存続日数を過ぎると、オブジェクトは古いものと見なされ、このオブジェクトに対して以降要求があると、Content Engine によって新たに取り込みが行われます。

http cache-cookies グローバル設定コマンドを使用すると、Content Engine は、HTTP で設定されたクッキー ヘッダを利用して提供されるバイナリ オブジェクトをキャッシングすることができます。明示的な有効期限満了の情報をもたないバイナリ オブジェクトでもキャッシング可能となる場合があります。


ヒント テキスト オブジェクトとは、HTML ページを意味します。バイナリ オブジェクトとは、GIF、JPEG などのテキスト オブジェクト以外の Web オブジェクトを意味します。


Content Engine GUI または CLI を使用して、ローカルに配置するContent Engine に対して FTP キャッシュ オブジェクトの新鮮度パラメータを設定することができます。これらのパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。

Content Engine GUI を使用した FTP キャッシュ オブジェクト新鮮度の設定

ローカルに配置する Content Engine 上でキャッシュ オブジェクトの新鮮度のパラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > FTP Freshness の順に選択します。FTP Freshness ウィンドウが表示されます(図 9-2 を参照)。

図 9-2 FTP Cache Object Freshness 設定ウィンドウ

 

ステップ 2 Directory Age Multiplier フィールドに値を指定します。

この値を指定すると、Content Engine は、オブジェクトの前回の更新から経過した日数にパーセント率(%)を掛けて、おおよその期限切れ日を算出することにより、ディレクトリの存続時間を推定できます。この日付を過ぎると、オブジェクトは古いものと見なされ、このオブジェクトに対して以後要求があると、Content Engine によって新たに取り込みが行われます。有効な値は 0 ~ 100% です。この値を指定すると、Content Engine は、オブジェクトの前回の修正から経過した時間に % を掛けて、おおよその期限切れ日を算出することにより、ディレクトリの存続時間を推定できます。この日付を過ぎると、オブジェクトは古いものと見なされ、このオブジェクトに対して以後要求があると、Content Engine によって新たな検索が行われます。有効な値は 0 ~ 100% です。デフォルト値は 30 パーセントです。

ステップ 3 File Age Multiplier フィールドに値を指定します。

この値を指定すると、Content Engine は、オブジェクトの前回の修正から経過した時間に % を掛けて、おおよその期限切れ日を算出することにより、オブジェクトの存続時間を推定できます。この日付を過ぎると、オブジェクトは古いものと見なされ、以後に要求があったときは、Content Engine によって新たに検索されます。有効な値は 0 ~ 100% です。デフォルト値は 60% です。

ステップ 4 Maximum TTL フィールドに値を指定します。

使用する時間単位に応じた最大値のリストについては、 表 9-3 を参照してください。デフォルト値は、ディレクトリの場合は 3 日間、ファイル オブジェクトの場合は 7 日間です。

 

表 9-3 FTP 新鮮度を決定する TTL 値の範囲

時間単位(スケール)
範囲

1 ~ 1825

1 ~ 43800

1 ~ 2628000

1 ~ 157680000

ステップ 5 Minimum TTL フィールドの値(分)を指定します。

最小 TTL は、キャッシュ内のオブジェクトの最小存続時間です。値の範囲は、0 ~ 86400 分です。デフォルト値は 30 分です。

ステップ 6 再評価要求の処理方式を該当する Revalidate every request with origin server オプション ボタンで選択します。設定可能な上限を超えるサイズのオブジェクトは、Content Engine に保存されなくなります。有効な値は、1 ~ 1048576 KB です。

ステップ 7 Update をクリックして設定を保存します。


 

CLI コマンドを使用した FTP キャッシュ オブジェクト新鮮度の設定

表 9-4 は、Content Engine 上で FTP キャッシュ オブジェクト新鮮度のパラメータを設定する CLI の例を示しています。

 

表 9-4 ローカルの Content Engine 上で FTP キャッシュ新鮮度を設定する CLI の例

目的
コマンド

Content Engine のキャッシュに保存する HTTP および FTP オブジェクトの最大サイズを設定します。HTTP オブジェクトの最大サイズを 500 KB に設定し、FTP オブジェクトの最大サイズを 2 MB に設定します。

ContentEngine(config)# ftp object max-size 2000
ContentEngine(config)# http object max-size 500
ContentEngine(config)#

Content Engine に各 FTP 要求に対するすべてのオブジェクトを再検証するように強制します。

ContentEngine(config)# ftp reval-each-request all
 

ディレクトリ リスト オブジェクトとファイル オブジェクトに対して、キャッシュの最大存続可能時間を 3 日に設定します。

ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3

HTTP age-multiplier の設定率を、テキスト ファイルの場合は 55%、バイナリ オブジェクトの場合は 45% に設定します。この設定例の実行結果は、 show http age-mult EXEC コマンドを使用すると確認できます。

ContentEngine(config)# http age-multiplier text 55 binary 45
ContentEngine# show http age-mult
HTTP heuristic age-multipliers: text 55% binary 45%

ContentEngine#

バイナリ オブジェクトをキャッシュするように設定することで、HTTP set-cookie ヘッダや明示的な期限切れ情報をもたない場合でも、キャッシング可能にします。

http cache-cookies グローバル設定コマンドを使用して、この機能を使用可能にします。この例では、クッキー付きのバイナリ コンテンツのキャッシングを可能にします。

ContentEngine(config)# http cache-cookies
ContentEngine(config)#

HTTP age-multiplier の設定率を、テキスト ファイルの場合は 55%、バイナリ オブジェクトの場合は 45% に設定します。この設定例の実行結果は、 show http age-mult EXEC コマンドを使用すると確認できます。

ContentEngine(config)# http age-multiplier text 55 binary 45
ContentEngine# show http age-mult
HTTP heuristic age-multipliers: text 55% binary 45%

ContentEngine#

最短で 10 分間、最長で 24 時間(1 日)、HTTP オブジェクトと FTP オブジェクトをキャッシュ内に保持するように、Content Engine を設定します。

ContentEngine(config)# http min-ttl 10
ContentEngine(config)# ftp min-ttl 10
ContentEngine(config)# http max-ttl days text 1 binary 1
ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24

キャッシュ内の HTTP オブジェクトに加えた設定の変更を表示するには、 show http ttl EXEC コマンドを実行します。

ContentEngine# show http ttl
Maximum time to live in days: text 1 binary 1
Minimum time to live for all objects in minutes: 10
ContentEngine#

キャッシュ内の FTP オブジェクトに加えた設定の変更を表示するには、 show ftp EXEC コマンドを実行します。

ContentEngine# show ftp
FTP heuristic age-multipliers: directory-listing 30% file 60%
Maximum time to live in hours: directory-listing 24 file 24
Minimum time to live for all objects in minutes: 10
Incoming Proxy-Mode:
Not servicing incoming proxy mode connections.
Outgoing Proxy-Mode:
Not using outgoing proxy mode.
Passive mode of FTP transfer is enabled
Maximum size of a FTP cacheable object is 204799 KBytes
No object is revalidated on each request
ContentEngine#

HTTP および HTTPS 接続パラメータの設定

次の作業を実行すると、ローカルに配置する Content Engine の HTTP および HTTPS のパラメータを設定、変更、および表示できます。

「HTTP 接続パラメータの設定」

「HTTP キャッシュ新鮮度パラメータの設定」

「認証済み HTTP キャッシュの設定」

「拡張 HTTP キャッシュ認証の設定」

「HTTPS 関連パラメータの設定」

「HTTP および HTTPS 発信プロキシの除外設定」

HTTP 接続パラメータの設定

プロキシ スタイルの要求は、Content Engine と同じ宛先 IP アドレスが付けられて着信します。つまり、この要求は、クライアントによって明示的に Content Engine に送られたものです。Content Engine は、FTP、HTTP、HTTPS、Microsoft Media Server(MMS)、および RTSP プロキシ モードに対して、最大 8 つまでの着信ポートをサポートします。着信プロキシ ポートは、透過モード サービスによって使用されているものと同じポートにすることができます。着信プロキシ ポートは、Content Engine 上で実行されているどの WCCP サービスも停止させることなく変更が可能です。


ヒント Content Engine GUI または CLI を使用して、ローカルに配置する Content Engine 上で HTTP 接続を設定することができます。


Content Engine GUI を使用した HTTP 接続設定

ローカルに配置する Content Engine 上で HTTP 接続パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > HTTP Proxy の順に選択します。HTTP Proxy ウィンドウが表示されます(図 9-3 を参照)。

図 9-3 HTTP Proxy ウィンドウ

 

ステップ 2 ポート 80 以外のポートに対しても着信要求を受け入れるには、 Enable Incoming HTTP Proxy On オプション ボタンをクリックします。

ステップ 3 Incoming HTTP Proxy Port List フィールドに、プロキシ サーバが要求を受信するときに使用するポート番号を入力します。

ステップ 4 Content Engine がすべての HTTP キャッシュ ミス トラフィックを親キャッシュに(ICP または WCCP を使用せずに)送信するように設定するには、 Enable Outgoing HTTP Proxy On オプション ボタンをクリックします。

ステップ 5 すべての発信プロキシ サーバに障害が発生した場合に、要求をどのように処理するかを指定するには、 Use Origin Server Upon Proxy Failures オプション ボタンを使用します。使用可能にした場合、要求はユーザ要求内で指定されたオリジン サーバに送られます。これを使用不可にした場合、ユーザはエラーを受信します。

ステップ 6 1 台の発信プロキシ サーバをモニタリングする間隔を秒単位で指定するには、Interval to Monitor Proxy Servers フィールドを使用します。複数のプロキシ サーバを指定した場合、これらのサーバは、モニタリング要求の間に、この間隔分の遅れを伴って順次モニタリングされます。

ステップ 7 複数の発信プロキシ サーバを設定できます。プロキシ HTTP 要求を受け入れるために発信プロキシ サーバが使用する IP アドレスまたはホスト名、およびポート番号を入力します。 Enable チェックボックスをクリックします。サーバを削除するには、 Enable チェックボックスのチェックマークを外すか、または手作業でその IP アドレスとポートを削除します。

複数の発信プロキシ サーバを設定する目的は、プライマリ サーバに障害が発生した場合に備えてバックアップ機能を持たせるためです。すべての要求は、プライマリ発信プロキシ サーバに送られます。プライマリ サーバに障害が発生した場合、要求はリスト内の次にアクティブなプロキシ サーバに送られます。


ヒント show http proxy CLI コマンドにより、各プロキシ サーバの現在の状態が表示されます。

ステップ 8 Update をクリックして設定を保存します。


 

CLI コマンドを使用する HTTP 接続設定

ローカルに配置されている Content Engine 上で、HTTP 接続を設定するために CLI を使用することもできます。HTTP 接続を設定するには、 http proxy コマンドを使用します。 表 9-5 では、Content Engine GUI パラメータおよび対応する CLI コマンドについて説明します。これらのパラメータおよびコマンドを使用することで、HTTP 接続パラメータを設定できるようになります。

 

表 9-5 HTTP Connection Settings GUI フィールドおよび関連する CLI コマンド

Content Engine GUI フィールド
説明
CLI コマンド

Enable Incoming HTTP Proxy

ポート 80 以外のポートに着信する要求も受け入れるように Content Engine を設定する。

http proxy incoming

Incoming HTTP Proxy Port List

プロキシ サーバまたは Content Engine が要求を受信するために使用するポート番号。この番号の範囲は 1 ~ 65535 です。最大 8 つまでのポートを指定できます。

http proxy incoming portnumber

Enable Outgoing HTTP Proxy

HTTP キャッシュ ミス要求トラフィックを受信するように、発信プロキシ サーバ、または別の Content Engine を設定します(ICP または WCCP を使用しない)。

http proxy outgoing

Use Origin Server upon Proxy Failures

これを使用可能にすると、すべての発信プロキシ サーバに障害が発生した場合に、要求はオリジン サーバによって処理されます。これを使用不可にすると、すべての発信プロキシ サーバに障害が発生した場合に、ユーザはエラー メッセージを受け取ります。

http proxy outgoing origin-server

Interval to Monitor Proxy Servers

1 台の発信プロキシ サーバをモニタリングする間隔を(秒単位で)指定します。複数の発信プロキシ サーバを指定した場合、これらは順次モニタリングされます。デフォルト値は 200 秒です。

http proxy outgoing monitor

Outgoing Proxy Servers

発信プロキシ サーバのホスト名または IP アドレスを使用して、複数の発信プロキシ サーバを設定します。

http proxy outgoing host { hostname | ipaddress }

Port

発信プロキシのホスト名に対応するポート番号。

http proxy outgoing host { hostname | ipaddress } ports 1-65535

HTTP キャッシュ新鮮度パラメータの設定

ローカルに配置されている Content Engine に対して HTTP キャッシュ オブジェクトの新鮮度パラメータの設定を Content Engine GUI または CLI を使用して行うことができます。これらのパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。

Content Engine GUI を使用した HTTP キャッシュ オブジェクト新鮮度の設定

ローカルに配置する Content Engine 上で HTTP キャッシュ新鮮度のパラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Cache > HTTP Freshness の順に選択します。HTTP Freshness ウィンドウが表示されます(図 9-4 を参照)。

図 9-4 HTTP Cache Freshness 設定ウィンドウ

 

ステップ 2 Text Object Age Multiplier フィールドに値を指定します。

経過時間乗数(age multiplier)の値を指定すると、Content Engine は、オブジェクトの前回の更新から経過した時間にパーセント(%)を掛けて、おおよその期限切れ日を算出することにより、テキスト オブジェクトの存続時間を推定できます。この日付を過ぎると、オブジェクトは古いものと見なされ、このオブジェクトに対して以後要求があると、Content Engine によって新たに取り込みが行われます。有効な値の範囲は 0 ~ 100% です。デフォルト値は 30% です。

ステップ 3 Binary Object Age Multiplier フィールドに値を指定します。

この値を指定すると、Content Engine は、オブジェクトの前回の更新から経過した時間にパーセント(%)を掛けて、おおよその期限切れ日を算出することにより、オブジェクトの存続時間を推定できます。この日付を過ぎると、オブジェクトは古いものと見なされ、このオブジェクトに対して以後要求があると、Content Engine によって新たに取り込みが行われます。有効な値は 0 ~ 100% です。デフォルト値は 60% です。

ステップ 4 Maximum Time-to-Live (TTL) Scale ドロップダウン リストから値を選択します。

TTL は、推定期限切れ日に上限を設けます。オブジェクトに期限切れ日が明示的に指定されている場合は、この日付が、設定する TTL よりも優先されます。

ステップ 5 Max Text Object TTL フィールドに値を指定します。

表 9-6 では、値の有効範囲を示しています。

 

表 9-6 HTTP 新鮮度を決定する TTL 値の範囲

時間単位(スケール)
範囲

1 ~ 1825

1 ~ 43800

1 ~ 2628000

1 ~ 157680000

ステップ 6 Max Binary Object TTL フィールドに値を指定します。

使用する時間単位に応じた最大値のリストについては、 表 9-6 を参照してください。

ステップ 7 Minimum TTL フィールドの値を指定します。

最小 TTL は、キャッシュ内のオブジェクトの最小存続時間です。値の範囲は、0 ~ 86400 分です。デフォルト値は 30 分です。

ステップ 8 再評価要求の処理方式を該当する Revalidate every request with origin server オプション ボタンで選択します。

ステップ 9 オブジェクト サイズの上限をキロバイト(KB)で設定します。設定可能な上限を超えるサイズのオブジェクトは、Content Engine に保存されなくなります。デフォルトは 204800 キロバイトです。

ステップ 10 Update をクリックして設定を保存します。


 

認証済み HTTP キャッシュの設定

認証済み HTTP キャッシング機能を使用すると、基本認証および NT LAN Manager(NTLM)認証済みのコンテンツをキャッシュに保存し、セキュリティを維持しながら複数のユーザにサービスできます。認証済みオブジェクトをキャッシュに保存した場合、そのオブジェクトに対する(新しいユーザからの)以後の要求には認証が必要になります。新しいユーザの認証ヘッダーを使用して、オリジン サーバに対してキャッシュ オブジェクトの再検証が行われます。ユーザが認証を受けていない場合、サーバは 401(Unauthorized)応答を送信します。ユーザが認証を受けていて、オブジェクトが更新されていない場合は、キャッシュ オブジェクトがクライアントにサービスされます。


認証キャッシュの容量が不足して、すべての認証済みユーザを同時に保存できない場合、Content Engine は、まだタイムアウトになっていない古いエントリから削除します。


次の例では、基本認証済みコンテンツ、および NTLM 認証済みコンテンツ両方のキャッシングを可能にしています。

Console(config)# http cache-authenticated all
 
Console(config)# show http cache-authenticated all
Basic authenticated objects are cached.
NTLM authenticated objects are cached.
 

Content Engine GUI を使用した認証済み HTTP キャッシュの設定

ローカルに配置する Content Engine で、認証済み HTTP キャッシング パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Auth.Cache の順に選択します。Authenticated Cache ウィンドウが表示されます(図 9-5 を参照)。

図 9-5 Authenticated HTTP Cache 設定ウィンドウ

 

ステップ 2 Max-entries フィールドに、キャッシュで保持される最大エントリ数の値を入力します。デフォルト値は 32000 エントリです。

ステップ 3 Timeout フィールドに、最後のアクセス以降 Content Engine からキャッシュが削除されるまでの時間の長さを示す値を入力します。範囲は 1 ~ 1440 分で、デフォルト値は 480 分です。

ステップ 4 Header type ドロップダウン リストをクリックして、認証が失敗したときに要求側クライアントに送信するヘッダー タイプ メッセージを選択します。デフォルトでは、 Based on URL syntax がヘッダー タイプに指定されています。このデフォルト設定を変更するには、次のいずれかの作業を行います。

401 未認証メッセージをクライアントに送信するには、 401 を選択します。

407 プロキシ認証に必要なメッセージをクライアントに送信するには、 407 を選択します。

ステップ 5 Update をクリックして設定を保存します。


 

CLI コマンドを使用する認証済み HTTP キャッシュパラメータの設定

ローカルに配置する Content Engine 上で、CLI を使用して認証済みの HTTP キャッシュ パラメータを設定するには、 http グローバル設定コマンドを使用します。

http authentication { cache { max-entries entries | timeout minutes } | header { 401 | 407 } | realm line }

http cache-authenticated { all | basic | ntlm }

max-entries オプションにより、保持される最大数の認証キャッシュ エントリが設定されます。

timeout オプションにより、アクティブでないエントリが削除される前に認証キャッシュ内に保持される時間が設定されます。あるレコードが削除された後、制限されたインターネット コンテンツにアクセスすると、サーバは認証キャッシュがみつからないので、再度認証を受けるように要求します。

表 9-7 では、HTTP キャッシュ認証パラメータを示しています。

 

表 9-7 HTTP キャッシュ認証パラメータ

パラメータ
説明

timeout

認証キャッシュ内のレコードのタイムアウト値を設定します。

minutes

ユーザが最後にインターネットにアクセスしてエントリが作成されてから、そのエントリが認証キャッシュから削除されるまでの分単位の時間(30~1440)。削除されると、再認証が必要になります。デフォルト値は 480 分であり、最短は 30 分、最長は 1440 分(24 時間)です。

header

HTTP 要求のスタイルが、プロキシ サーバが存在しないことを示すとき、認証にどの HTTP ヘッダー(ユーザ ID およびパスワード)を使用するかを決定します。ヘッダーは HTTP 401(Unauthorized)、または HTTP 407(Proxy Authentication Required)のいずれかです。デフォルトは HTTP 401 です。

401

HTTP 401 を使用して、ユーザの信用度を照会します。

407

HTTP 407 を使用して、ユーザの信用度を照会します。

realm

基本 HTTP 要求認証に範囲ストリングを設定します。

line

認証対象となる範囲ストリング名。

cache-authenticated

認証済みの Web オブジェクトをキャッシュし、再検証します。

all

任意のスキームを使用して、Web オブジェクト キャッシュの認証を行います。

basic

基本スキーム認証を使用して、Web オブジェクト キャッシュの認証を行います。

ntlm

NTLM スキーム認証を使用して、Web オブジェクト キャッシュの認証を行います。

all

(オプション)クライアントおよびサーバをともに永続的接続に設定します。

拡張 HTTP キャッシュ認証の設定

ここでは、次の拡張 HTTP キャッシュ パラメータをローカルに配置されている Content Engine 上で設定する方法を説明します。

「HTTP Range 要求のキャッシング設定」

「Range 要求でのオブジェクト全体のキャッシング」

「HTTP Cache On Abort の設定」

「永続的接続の設定」

「ヒーリング モードのイネーブル化」

HTTP Range 要求のキャッシング設定

Content Engine は、HTTP Range 要求を処理します。この要求に含まれている Range ヘッダーは、要求された範囲が Content Engine のキャッシュ内に存在する場合、オブジェクト全体をキャッシュに要求することはなく、指定された範囲のオブジェクトだけを要求します。具体的には、Content Engine は次のプログラム記述内容で Range 要求を処理します。

lookup the object in the cache;
if object in the cache
{
check whether the requested ranges are in the cache;
if the requested ranges are in cache then serve the request from cache;
else pipe through the request;
}
else pipe through the request;
 

Web クライアントのキャッシュ内にエンティティの部分コピーがあるときに、エンティティ全体の最新のコピーをキャッシュするように要求する場合、その Web クライアントは、If-Unmodified-Since コマンドか If-Match コマンドのいずれか、または両方を使用して Range 要求ヘッダーを条件付き GET 要求と同時に使用できます。ただし、エンティティが変更されてしまったために条件が成立しない場合、クライアントは、もう 1 つ要求を出して現在のエンティティ全体を取得する必要があります。

If-Range ヘッダーを使用すると、クライアントは 2 番目の要求を省くことができます。このヘッダーの意味を一般的に表わすと、「エンティティがまだ変更されていなければ、自分の持っていないところだけを送信してください。エンティティが変更されていれば、新規のエンティティ全体をまた送信してください。」という意味になります。

If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

クライアントから If-Range 要求があると、キャッシュは次のように処理します。

lookup the object in the cache;
if (object is in the cache
AND requested ranges are in the cache;
AND entity tag given in the If-Range header
matches cached object's entity-tag){
serve partial request from the cache
} else {
connect to remote server
retrieve requested range, send data to client
}
 

If-Range ヘッダーに、エンティティ タグではなく、有効な HTTP 日付けがある場合、その HTTP 日付けは、オブジェクトがキャッシュされたときの Last-Modified 日付けと照合されます。

Web クライアント側にエンティティのエンティティ タグがなく、Last-Modified 日付けがある場合、その Web クライアントは、If-Range ヘッダー内の日付けを使用できます。If-Range ヘッダーは、必ず Range ヘッダーと一緒に使用してください。要求に Range ヘッダーが含まれていない場合、またはサーバで部分的なオペレーションしかサポートされていない場合、If-Range ヘッダーは無視してください。

If-Range ヘッダーに指定されたエンティティ タグが、エンティティの現在のエンティティ タグと一致する場合、サーバは、206(Partial content)応答を使用して、エンティティの指定された一部を戻します。エンティティ タグが一致しない場合、サーバは、200(OK)応答を使用してエンティティ全体を戻します。


) HTTP Range 要求をキャッシングするには、http cache-on-abort 機能が使用不可になっている必要があります。クライアント アプリケーションによっては、(たとえば、PDF ファイルに対する)通常の GET 要求の応答ヘッダーを受信後ただちに、サーバ接続をクローズしてしまいます。http cache-on-abort コマンドが使用可能になっている場合、そのオブジェクトに対する以後の Range 要求は、キャッシングできません。


Range 要求でのオブジェクト全体のキャッシング

ACNS 5.x ソフトウェアでは、コマンド http smart-range を使用すると、クライアントが Range 要求を出していて、そのオブジェクトがキャッシュ内に存在しない場合でも、Content Engine は HTTP 応答の全体をキャッシングできます。 このキャッシングを使用不可にするには、このコマンドの no 形式、 no http smart-range enable を使用します。

http smart-range max-start offset max-interval interval コマンドが返すバイト値は、この機能が使用可能になっているときには、Range 要求を制御します。この offset 値は、クライアントの Range 要求に指定されている最初の範囲からの最大オフセット値です。このオフセット値の範囲は、0 ~ 2147483647 バイトです。デフォルト値は 16384 バイトです。 interval 値は、クライアント要求で指定される範囲が連続する場合の最大間隔です。この値の範囲は、0 ~ 2147483647 バイトです。デフォルト値は 16384 バイトです。

Range 要求が両方の条件を満たし、キャッシュ ミスが発生した場合のみ、プロキシは、通常の要求をオリジン サーバに出し、応答を(可能ならば)キャッシングし、Range 応答をクライアントに送信します。応答がキャッシングできない場合は、応答全体がクライアントに送信されます。

HTTP Cache On Abort の設定

HTTP cache-on-abort 機能をローカルに配置する Content Engine 上で設定するために、Content Engine GUI または CLI を使用できます。

Content Engine GUI を使用した HTTP Cache On Abort の設定

HTTP cache-on-abort 機能の設定をローカルに配置する Content Engine 上で設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Cache on Abort の順に選択します。Cache on Abort ウィンドウが表示されます(図 9-6 を参照)。

図 9-6 Cache on Abort ウィンドウ

 

ステップ 2 クライアントが要求を中断した場合に、Content Engine が引き続きオブジェクトをキャッシュできるようにするには、 Enable HTTP Cache On Abort On オプション ボタンをクリックします。

ステップ 3 サーバからダウンロードするデータの残り KB 数が最小しきい値より大きい場合に、オブジェクトをキャッシュに保存するには、 Use Minimum Threshold チェックボックスにチェックマークを付けます。最小しきい値を入力します。デフォルト値は 32 KB です。

ステップ 4 サーバからダウンロードするデータの残り KB 数が最大しきい値より小さい場合に、オブジェクトをキャッシュに保存するには、 Use Maximum Threshold チェックボックスにチェックマークを付けます。Abort Maximum Threshold フィールドに最大しきい値を入力します。デフォルト値は 256 KB です。

ステップ 5 オブジェクトのダウンロード済みパーセント率(%)が入力したパーセント率(%)しきい値よりも大きい場合に、オブジェクトをキャッシュに保存するには、 Use Percentage Threshold チェックボックスにチェックマークを付けます。パーセント率(%)しきい値を入力します。デフォルト値は 80 % です。

ステップ 6 Update をクリックして設定を保存します。


 

CLI コマンドを使用した HTTP Cache-on-Abort の設定

以下は、HTTP cache-on-abort 機能をローカルに配置する Content Engine 上で設定する、CLI の使用方法の一例です。


ステップ 1 オブジェクトを Content Engine のキャッシュに常時ダウンロードするには、Content Engine をグローバル設定モードで設定します。

ContentEngine(config)# no http cache-on-abort
 

ステップ 2 cache-on-abort オプションが使用可能であるときに、デフォルトの最小しきい値を使用するように Content Engine を設定します。このしきい値は 16 KB です。

ContentEngine(config)# http cache-on-abort min 16
 

ステップ 3 Content Engine を設定して、最小しきい値が考慮されないようにします。

ContentEngine(config)# no http cache-on-abort min
 


 

HTTP cache-on-abort 機能に関する CLI コマンドの説明については、 表 9-8 を参照してください。

 

表 9-8 HTTP Cache-on-Abort 機能と関連 CLI コマンド

コマンド
説明

http cache-on-abort

ユーザ定義のしきい値を備えていて、そのしきい値により、クライアントが要求を中断したときに、Content Engine がオブジェクトのダウンロードを完了するかどうかを決定できます。オブジェクトのダウンロードが完了する前に中断される場合、そのオブジェクトは Content Engine に保存されず、ヒット率の統計にカウントもされません。クライアントがダウンロードを中断するときは、ブラウザの Stop アイコンをクリックするか、ダウンロード中にブラウザを閉じます。

http cache-on-abort コマンドが使用可能の場合、Content Engine は、選別アルゴリズムを使用して、クライアントが要求を中断した場合に引き続きキャッシュするかどうかを決定します。このコマンドが使用不可の場合、Content Engine は、クライアントが要求を中断した場合であっても、常に引き続きオブジェクトをキャッシュにダウンロードします。

http cache-on-abort min-threshold

サーバからダウンロードされる残りの KB 数が最小しきい値以下である場合、Content Engine は引き続きオブジェクトをキャッシングします。デフォルト値は 32 KB です。

http cache-on-abort max-threshold

サーバからダウンロードされる残りの KB 数が最大しきい値を超える場合、Content Engine はオブジェクトのキャッシングを続行しません。デフォルト値は 256 KB です。

http cache-on-abort percent

すでにダウンロードされたオブジェクトのパーセント率(%)がパーセント率(%)しきい値を超える場合、Content Engine は引き続きオブジェクトをキャッシングします。デフォルト値は 80% です。


) しきい値は任意の組み合せで指定できます。しきい値は、前述の説明の順に使用されます。http cache-on-abort コマンドが使用可能であり、すべての http cache-on-abort しきい値が使用不可である場合、Content Engine は、常にオブジェクトのキャッシュへのダウンロードを中断します。現在要求している同じオブジェクトが別のクライアントからも要求されていると Content Engine が判別すると、ダウンロードは中断されません。Content Engine は、使用可能に設定されているしきい値だけを適用します。


以下は、HTTP cache-on-abort 機能をローカルに配置する Content Engine 上で設定する、CLI の使用方法の一例です。


ステップ 1 オブジェクトを Content Engine のキャッシュに常時ダウンロードするには、Content Engine をグローバル設定モードで設定します。

ContentEngine(config)# no http cache-on-abort
 

ステップ 2 cache-on-abort オプションが使用可能であるときに、デフォルトの最小しきい値を使用するように Content Engine を設定します。このしきい値は 16 KB です。

ContentEngine(config)# http cache-on-abort min 16
 

ステップ 3 Content Engine を設定して、最小しきい値が考慮されないようにします。

ContentEngine(config)# no http cache-on-abort min
 


 

永続的接続の設定

Content Engines は、パフォーマンス向上のためにデフォルトで、サーバへの永続的接続を使用します。ACNS ソフトウェアの以前のリリースでは、Content Engine で永続的接続をイネーブルまたはディセーブルにするオプションは、限定的に用意されていました。たとえば、すべての要求への永続的接続、すべてのクライアントへの永続的接続要求、またはすべてのサーバへの永続的接続要求をイネーブル、あるいはディセーブルにすることしかできませんでした。特定のドメイン、IP アドレス、ポートに対する永続的接続の要求をディセーブルにするオプションはありませんでした。

ACNS 5.0.7 ソフトウェアのリリースで、 rule action no-persistent-connection グローバル設定コマンドが追加されました。このコマンドにより、特定のドメイン、発信元および宛先 IP アドレス、あるいはポートをイネーブルまたはディセーブルにすることが可能になります。このコマンドは、サーバが永続的接続をサポートしていない場合に役立ちます。

rule action no-persistent-connection グローバル設定コマンドには、次のオプションがあります。

all:すべての接続に永続的接続を使用しない。

client-only:クライアント接続だけには、永続的接続を使用しない。

server-only:サーバ接続だけには、永続的接続を使用しない。

サポートされている次のパターンから、1 つまたは複数を使用してパターン リストを作成することで、永続的接続をディセーブルにする基準を指定できます。

src-ip

dst-ip

dst-port

url-regex

domain

header-field user-agent

header-field referer

header-field request-line

表 9-9 では、 rule action no-persistent-connection コマンド用の構文を示しています。

 

表 9-9 rule action no-persistent-connection コマンドのパラメータ

パラメータ
説明

action

規則によって取るべきアクションが示されます。

no-persistent-connection

永続的接続の設定オプションを設定します。

pattern-list

パターン リストを設定します。

list_num

パターン リスト番号(1 ~ 512)

protocol

この規則と照合されるプロトコル。

http

この規則を HTTP プロトコルと照合します。

https

この規則を HTTPS プロトコルと照合します。

ftp

この規則を MMS プロトコルと照合します。

次の例では、パターンリストのパターン(パターン番号 10)をもとに、ドメイン mywebsite.com の永続的接続をディセーブルにしています。

ContentEngine(config)# rule action no-persistent-connection server-only pattern-list 10
WARNING: rule action no-persistent-connection will affect end-to-end NTLM authentication to these servers
ContentEngine(config)#
 
ContentEngin590#show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
 
Actions :
 
rule action no-persistent-connection server-only pattern-list 100 protocol all
 
Pattern-Lists :
 
rule pattern-list 100 domain mywebsite.com
ContentEngine#
 

) ローカルに配置する Content Engine に規則を設定する、Rules Template 機能の使用についての詳細は、「Rules Template の設定」を参照してください。


永続的接続のイネーブル化

ローカルに配置する Content Engine 上で永続的接続をイネーブルまたはディセーブルにするには、Content Engine GUI または CLI を使用します。

CLI を使用して、ローカルに配置する Content Engine 上で永続的接続をイネーブルにするには、 http グローバル設定コマンドを使用します。 persistent-connections オプションにより、Content Engine での永続的接続がイネーブルになります。

ContentEngine(config)# no http persistent-connections [all|client-only|server-only|timeout seconds]
 

Content Engine がタイムアウトになるまでの間、接続応答を待つ秒数を設定するには、 timeout オプションを使用します。

表 9-10 では、HTTP 永続的接続パラメータを示しています。

 

表 9-10 HTTP 永続的接続の CLI パラメータ

パラメータ
説明

persistent-connections

永続的接続の設定オプションを設定します。

all

(オプション)クライアントおよびサーバとともに永続的接続に設定します。

client-only

(オプション)クライアントのみを永続的接続に設定します。

server-only

(オプション)サーバのみを永続的接続に設定します。

timeout

(オプション)永続的接続のタイムアウト値を設定します。

seconds

永続的接続がタイムアウトになる秒数を設定します(1-86400)。

tcp-keepalive

TCP キープアライブ機能を設定します。

enable

HTTP 接続で TCP キープアライブをイネーブルにします。

ローカルに配置する Content Engine 上で、Content Engine GUI を使用して永続的接続をイネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Persist Connect を選択します。 Persistent Connections ウィンドウが表示されます(図 9-7 を参照)。

図 9-7 Persistent Connections ウィンドウ

 

ステップ 2 Persistent Connections Type ドロップダウン リストから永続的接続タイプを選択します。

ステップ 3 Connection Timeout フィールドに、Content Engine が接続をクローズする前に、アイドル状態の永続的接続をオープンにしておく秒数を入力します。デフォルト値は 600 秒です。

ステップ 4 Update をクリックして設定を保存します。


 

永続的接続のディセーブル化

すべての永続的接続、クライアントのみの永続的接続、またはサーバのみの永続的接続をディセーブルにするには、 http persistent-connections [all | client-only | server-only | timeout seconds] グローバル設定コマンドの no 形式を使用します。

ContentEngine(config)# no http persistent-connections [all|client-only|server-only|timeout seconds]
 

特定のドメイン、IP アドレス、またはポートをディセーブルにするには、 rule no-persistent-connection グローバル設定コマンドを次のように使用します。

ContentEngine(config)# rule action no-persistent-connection pattern-list list_num [protocol (http|https|ftp)]
 

ヒーリング モードのイネーブル化

Content Engine が、既存の WCCP Version 2 キャッシュ グループ(クラスタ)に追加されると、この Content Engine は、クラスタ内の別のキャッシュが以前に処理したコンテンツに対する要求を受け取る場合があります。このイベントは、「ニアミス」と呼ばれます。その理由は、その要求が以前の Content Engine に送信されていたら、キャッシュにヒットしたはずだからです。ニアミスは、Content Engine クラスタの全体的なキャッシュ ヒット率を低下させます。

ヒーリング モードにより、新たに追加された Content Engine は、キャッシュ ミス イベント時に、クラスタ内の他のすべてのキャッシュを照会して、キャッシュ オブジェクトを取得できるようになります。オブジェクトがクラスタ内に見つからない場合、Content Engine は、発信プロキシ サーバ、またはオリジン サーバを通じて要求を処理します。ヒーリング モードの Content Engine は、ヒーリング クライアントと呼ばれます。クラスタ内で、ヒーリング クライアントの要求に応答するキャッシュは、ヒーリング サーバと呼ばれます。


) ヒーリング モードは、要求が透過的に Content Engine にリダイレクトされるときのみ、ヒーリング クライアント上で起動されます。要求がプロキシ モードの Content Engine に送信されるときは、ヒーリング モードは起動されません。


Content Engine ファームにある 1 台の Content Engine が、そのクラスタにある他の複数の Content Engines からキャッシュ オブジェクトを照会および取得できるようにするには、その 1 台の Content Engine 上でヒーリング モードをイネーブルにする必要があります。

ヒーリング モードをイネーブルにするときは、次のガイドラインに注意してください。

ローカルに配置する Content Engine でヒーリング モードをイネーブルにするために、Content Engine GUI または CLI を使用することができます。

WCCP バケットの再配信後、Content Engine はキャッシュを他の Content Engine から、キャッシュ ミスの度に移そうとします。Content Engine が目的のオブジェクトそのものを取り出すまでに近接のContent Engine からの応答を待つ最大秒数を設定できます。デフォルト値はゼロ秒です。

最大遅延または最大ミス数の値がゼロである場合、またはヒーリング モードに対して 1 ~ 65535 に設定されている http ポート値がない場合、ヒーリング モードはディセーブルになります。

Content Engine GUI を使用したヒーリング モードのイネーブル化

クラスタリング パラメータ(WCCP サービス クラスタに関連するパラメータ)をローカルに配置する Content Engine 上で設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 WCCP > Clustering の順に選択します。Clustering ウィンドウが表示されます(図 9-8 を参照)。

図 9-8 Clustering ウィンドウ

 

ステップ 2 Max delay in healing mode フィールドに、ヒーリング Content Engine が 1 つのヒーリング Content Engine 応答を待つ時間の最大値を秒数で入力します。

ステップ 3 Disable healing mode after フィールドに、Content Engine の近隣キャッシュにミスがないかを問い合わせを行う回数を指定します。この回数は Content Engine が、キャッシュによって「何も認識されてない」と判断し、キャッシュに対してオブジェクトを要求しなくなるまで問い合わせを行う回数です。デフォルト値はゼロ(0)ミスです。

ステップ 4 Http port for healing mode フィールドに、ヒーリング Content Engine からの要求がそのクラスタ内の他の Content Engine に送信されるときに使用する HTTP ポート番号を入力します。HTTP ヒーリング ポートのデフォルト ポート値は 80 です。この値は 1 ~ 65535 の範囲で指定できます。

ステップ 5 Update をクリックして設定を保存します。


 

CLI コマンドを使用したヒーリング モードのイネーブル化

CLI を使用して、ローカルに配置する Content Engine でヒーリング モードをイネーブルにするには、 http グローバル設定コマンドを使用します。

http cluster {heal-port number | http-port number | max-delay seconds | misses number }

表 9-11 では、http cluster コマンド パラメータを示しています。

 

表 9-11 ヒーリング モード CLI パラメータ

パラメータ
説明

cluster

キャッシュ クラスタ オプションを設定します。

heal-port

ヒーリング要求に対するヒーリング サーバのリスニング ポート番号。

number

ヒーリング サーバのリスニング ポート番号(1 ~ 65535)。デフォルトは、14333 です。

http-port

ヒーリング サーバの HTTP 要求転送ポート番号。

number

HTTP 要求転送ポート番号(1 ~ 65535)。デフォルトは、80 です。

max-delay

応答を待つ最大時間。

seconds

最大遅延の秒数(0 ~ 10)。

misses

ヒーリング モードの持続期間(ミス数)

number

ヒーリング モードがディセーブルになるまでの合計ミス数(0 ~ 999)。

http cluster コマンドにより、ヒーリング モード パラメータが変更されます。 http cluster http-port コマンド により、ヒーリング Content Engine からの要求が、クラスタ内の他の Content Engine に送信されるときに使用されるポート番号が指定されます。


) デフォルトのポート番号は、80 です。デフォルトの 80 以外のポートを設定することを選択する場合は、設定されるポートが、サーバ ファーム内のヒーリング サーバ上で http proxy incomingコマンドで指定されるポートと一致することを確認する必要があります。一致しない場合は、ヒーリング クライアントはヒーリング サーバからオブジェクトを取り出すことができません。


http cluster heal-port コマンドにより、ヒーリング クライアントがヒーリング クエリーを送信するときに使用するポート番号、およびヒーリング サーバがヒーリング要求を送信するときに使用するポート番号が指定されます。デフォルトのポート番号は 14333 です。このデフォルトのポート番号を変更する場合、クラスタ内のすべての Content Engine が同じポート番号を使用していることを確認してください。 http cluster misses コマンドは、前回のヒーリング モードのヒット応答以後、ヒーリング プロセスがディセーブルになるまでの間に、ヒーリング Content Engine がクラスタから受け取ることができるミス数の最大値を指定します。デフォルト値はゼロミスです。 http cluster max-delay コマンドは、ヒーリング要求をミスと見なす 前に、ヒーリング Content Engine がクラスタからのヒーリング応答を待つ、 最大時間を秒数で指定します。

ヒーリング クライアントを使用可能にするには、少なくとも max-delay オプションと misses オプションを設定する必要があります。 http-port のデフォルト ポート番号は 80 です。デフォルト ポートを使用する場合は、 http-port を設定する必要はありません。 heal-port のデフォルト ポート番号は 14333 です。

ヒーリング クライアントをディセーブルにするには、少なくとも misses max-delay のいずれかをゼロに設定する必要があります。または、このコマンドの no 形式を使用することもできます。次に例を示します。

http cluster misses 0

no http cluster misses

http max-delay 0

no http cluster max-delay

HTTPS 関連パラメータの設定

Cisco ACNS 5.x ソフトウェアは、次の 2 つのシナリオで HTTPS をサポートします。

Web クライアントが、Content Engine を HTTPS プロキシ サーバとして使用するように設定されているとき、その Web クライアントから送信された HTTPS 要求を Content Engine が受信する。

透過モードに設定された Content Engine が、Web クライアントから別の HTTPS プロキシ サーバに送信された要求を代行受信する。

いずれの場合も、Content Engine はオリジン サーバへの接続(直接、または別のプロキシ サーバ経由)を確立し、Web クライアントとオリジン サーバが、Content Engine 経由で Secure Socket Layer(SSL)トンネルをセットアップできるようにします。

Content Engine を HTTPS サーバとして設定すると、Content Engine はキャッシング HTTPS プロキシとして機能します。これにより、Content Engine は、HTTPS プロトコルを通して転送されるコンテンツを指定した HTTPS サーバにキャッシングすることができます。


) HTTPS プロキシ要求をサポートするには、DNS サーバを設定(「DNS キャッシング ネーム サービス用の DNS サーバの設定」 で説明されているように)する必要があります。


使用方法のガイドラインおよび例

HTTPS キャッシング用に Content Engine を設定するときは、次のガイドラインに注意してください。

Content Engine を HTTPS プロキシ モードで作動するように設定することで、Content Engine は、HTTPS プロキシ サーバを使用するように設定された、Web クライアントが送信する HTTPS 要求をサービスすることができます。

デフォルトでは、HTTPS サーバは使用不可になっています。HTTPS サーバが使用可能な場合、次のデフォルト値が適用されます。

protocol version: sslv23-tlsv1

serverauth: enabled

serverauth ignore: none

session cache size: 10000

session cache timeout: 3600

certgroup serverauth: many common public CAs

https server グローバル設定コマンドを使用して Content Engine が設定済みであることを前提とする HTTPS サーバに証明書を割り当てて、鍵をそのサーバと関連付けることができます。Content Engine は、HTTPS サーバに要求を出す HTTPS クライアントに証明書を提示します。

外部ソースから証明書のインポート、または既存の証明書の削除を行うには、 https cert EXEC コマンドを使用して、所定の名前を付けて証明書を作成します。

https certgroup EXEC コマンドを使用すると、証明書グループの作成、除去、または形成が可能になります。証明書グループは、ルート認証局(Certificate Authority)からエンド エンティティまでの信頼関係チェーンを示すために形成されます。エンド エンティティの証明書を除く証明書グループ内の各証明書は、そのチェーン内で次の証明書に署名し、その証明書を信頼します。エンド エンティティの証明書は、証明書グループ内でこの証明書につながるすべての証明書が信頼できる場合のみ信頼されます。証明書グループは、HTTPS サーバを単一の証明書と同様に提示するために使用できますが、それ以外にもクライアントがすべての証明書をローカルで持つ必要がないという利点があります。証明書グループはまた、サーバの証明書を証明書グループと比較して HTTPS サーバを検証および認証するためにも使用できます。

Content Engine を設定して、Content Engine がオリジン HTTPS サーバとして機能することが可能になる SSL 証明書と鍵のセットを使用するには、 https server name cert コマンドおよび https server name key コマンドを使用します。Content Engine は、クライアントからの HTTPS トラフィックをデコードして、キャッシングや要求処理など、通常の HTTP サーバとして動作します。Content Engine は、キャッシュ ミス(またはキャッシュ 検証)時に、オリジン サーバへの HTTPS 接続を開始して、複数のオリジン サーバからコンテンツをフェッチします。

表 9-12 では、HTTPS プロキシ機能に関連した CLI コマンドを示しています。CLI コマンドの入力順序は重要ではありません。

 

表 9-12 HTTPS プロキシ機能および関連 CLI コマンド

HTTPS プロキシ機能
関連 CLI コマンド(省略構文)

最大 8 つまでの着信プロキシ ポートをサポートする。

https proxy incoming ports 1-65535, ports, . . .

同一ポート上で WCCP サービスと HTTPS 着信プロキシを設定する。
プロキシ ポートを透過サービスと共用する。

https proxy incoming ports 1-65535
wccp custom-web-cache . . .

すべての宛先 HTTPS ポートへの不要アクセスを拒否する。

no https destination-port allow 443 563
https destination-port deny all

HTTPS プロキシのグローバル除外オプションを使用して、発信 HTTPS プロキシ サーバを設定する。

proxy-protocols outgoing-proxy exclude list word
https proxy outgoing host { hostname | ip_address } port 1-65535

デフォルトの発信 HTTPS プロキシを、使用可能な場合は、使用する。

proxy-protocols transparent default-server

元の要求にある発信 HTTPS プロキシ サーバを使用する。

proxy-protocols transparent original-proxy

キャッシュ ミスの間に、発信クライアントに対して着信 HTTPS 要求を送り返す。

proxy-protocols transparent reset

HTTPS プロキシ サーバとして機能する Content Engine は、最大 8 つまでのポートをサポートします。Content Engine は、ポートを透過モード サービスおよび HTTP と共用できます。プロキシ モードでは、Content Engine は、 https proxy incoming コマンドを使用して指定されたポート上で HTTPS 要求を受け入れ、処理します。他のプロキシ モード ポート上の HTTPS 要求 はすべて、Content Engine 上のエラー処理設定値に従って拒否されます。透過モードでは、別の HTTPS プロキシ サーバに対するすべての HTTPS プロキシ スタイルの要求が、受け入れられます。Content Engine は、 proxy-protocols transparent コマンドに従って、透過的に受信されたこれらの要求を処理します。

https proxy outgoing host コマンドを使用して、Content Engine が HTTPS 発信プロキシを使用するように設定されている場合、着信 HTTPS 要求はすべて、この発信プロキシに送信されます。
proxy-protocols outgoing-proxy exclude
コマンドは、HTTPS を含めて、すべてのプロキシ サーバ プロトコルに有効なグローバル プロキシ除外ドメインを指定します。

発信プロキシ サーバが設定されている場合、Content Engine は次のロジックを適用します。

宛先サーバがグローバル除外オプションによって指定されている場合、宛先サーバに直接進む。

宛先サーバがグローバル除外オプションによって指定されず、要求が HTTP である場合、宛先サーバに直接進む。

宛先サーバがグローバル除外オプションによって指定されない場合、発信プロキシ サーバに進む。

Content Engine が別のプロキシ サーバに対するプロキシ要求を代行受信し、HTTPS に対応するように設定された発信プロキシがないときに、 proxy-protocols transparent default-server コマンドが起動されると、Content Engine はその要求を、クライアントが意図したプロキシ サーバではなく、宛先サーバに直接アドレス指定します。ただし、Content Engine 上で proxy-protocols transparent reset コマンドが設定され、キャッシュ ミスが発生した場合は、クライアントが送信し透過的に代行受信されたすべての要求は、クライアントに戻され、要求されたオブジェクトは、配信されません。

CLI コマンドを使用した HTTPS 関連パラメータの設定

CLI を使用して HTTPS 関連パラメータをローカルに配置する Content Engine 上で設定する手順は、次のとおりです。


ステップ 1 グローバル設定モードで Content Engine CLI にアクセスします。

ステップ 2 Content Engine 上で HTTPS 関連パラメータを設定するには、 https コマンドを使用します。

https destination-port allow { ports | all }

https destination-port deny { ports | all }

https proxy incoming ports

https proxy outgoing host {{ hostname | ip-address } port }

https server name { cert cert_name | certgroup { chain cert_name | serverauth } | enable | host { hostname | ip-address } | key { keyname | password password } | protocol-version { sslv2-only | sslv23-tlsv1 | sslv3-only | tlsv1-only } | serverauth { enable | ignore { cert-not-yet-valid | domain-name | expired-date | invalid-ca } | session-cache { size size | timeout timeout }}

https tcp-rw-timeout timeout

表 9-13 では、 https server CLI コマンドに関するパラメータを示しています。

 

表 9-13 https server CLI コマンドのパラメータ

パラメータ
説明

destination-port

宛先ポートの制限。

Web クライアントが HTTPS サーバ以外のサーバに HTTPS トンネルを作成しないようにするために、宛先ポートを制限できます。この制限は個別のポートまたはすべてのポートに適用できます。制限規則に矛盾がある場合には、個別のポート設定が「all」規則よりも優先し、「allow」規則が「deny」規則よりも優先します。

宛先ポートに対して HTTPS トラフィックを許可または拒否する制限を設定することを強くお勧めします。デフォルトの設定では、期待するレベルのセキュリティを確保できない場合があります。

allow

特定のポートへの HTTPS トラフィックを許可します。HTTPS を許可する個別の宛先ポートのリストを指定します。すべてのポートへのアクセスを許可する場合は、 all と入力します。デフォルトでは、ポート 443 および 563 だけが許可されます。

ports

ポート番号(1 ~ 65535)。最大 8 つまでのポートを設定できます。

all

すべてのポートを指定します。

deny

特定のポートへの HTTPS トラフィックを拒否します。デフォルトでは、ポート番号が 1024 未満のポートは拒否されます。

ports

ポート番号(1 ~ 65535)。最大 8 つまでのポートを設定できます。

all

すべてのポートを指定します。

proxy

プロキシ モードに対する構成パラメータを設定します。

incoming

着信プロキシ モード要求に対する構成を設定します。

ports

HTTPS 要求を受信するポート番号(1 ~ 65535)。最大 8 つまでのポートを設定できます。

outgoing

発信要求を別のプロキシ サーバに転送するように構成を設定します。

host

発信 HTTPS プロキシ サーバの使用をイネーブルにします。

hostname

発信プロキシ サーバのホスト名。

ip-address

発信プロキシ サーバの IP アドレス。

port

発信プロキシ サーバのポート番号(1 ~ 65535)。

server

HTTPS サーバに対するキャッシング構成パラメータを設定します。

name

HTTPS サーバ名。

cert

HTTPS サーバにアクセスする証明書を設定します。

cert_name

証明書の名前。

certgroup

HTTPS サーバにアクセスするために、必要な証明書チェーンおよび認証を設定します。

chain

HTTPS サーバにアクセスするために必要な証明書チェーンを設定します。

chain_name

証明書チェーンの名前。

serverauth

HTTPS サーバにアクセスするために必要な証明書チェーンおよび認証を設定します。

enable

HTTPS サーバを使用するキャッシングをイネーブルにします。

host

HTTPS サーバを設定します。

hostname

HTTPS サーバのホスト名。

ip-address

HTTPS サーバの IP アドレス。

key

HTTPS サーバにアクセスするために使用する秘密鍵を設定します。

key_name

秘密鍵の名前を設定します。

password

秘密鍵ファイルを解読するのに必要なパスワードを設定します。

protocol-version

Web クライアントと HTTPS サーバ間の通信に使用するプロトコル バージョンを設定します。

sslv2-only

Secure Socket Layer(SSL)Version 2 プロトコルのみの使用と識別を設定します。

sslv23-tlsv1

SSL Version 2 または Version 3 および Transport Layer Security(TLS)Version 1 プロトコルの使用および識別を設定します。

sslv3-only

SSL Version 3 プロトコルのみの使用および識別を設定します。

tlsv1-only

TLS Version 1 プロトコルのみの使用および識別を設定します。

serverauth

HTTP サーバ認証コマンドを設定します。

enable

HTTPS サーバ認証をイネーブルにします。

ignore

HTTPS サーバ認証での特定のエラーを無視します。

cert-not-yet-valid

証明書が有効になる前に使用されたことで発生するエラーを無視します。

domain-name

ドメイン名の不一致によるエラーを無視します。

expired-date

証明書の有効期限切れによるエラーを無視します。

invalid-ca

認識されない Certificate Authority(CA;認証局)によるエラーを無視します。

session-cache

SSL キャッシング パラメータを設定します。

size

SSL キャッシング エントリ数を設定します(0 ~ 20000)。

timeout

SSL キャッシュ タイムアウトの秒数(0 ~ 86400)を設定します。

tcp-rw-timeout

timeout パラメータによって指定された時間内に、Content Engine に HTTPS TCP キープアライブ メッセージを送信するように強制します。

timeout

Content Engine が HTTPS TCP キープアライブ メッセージを送信するときに、送信する時間の最大間隔を設定します。

デフォルトは、次のとおりです。

destination-port allow ports : 443 および 563

https destination-port deny ports : 1024 未満のポート番号

https tcp-rw-timeout timeout : 5 分


ヒント 特定の要求したコンテンツをキャッシュする場合、要求先のサイトに適した証明書と鍵を Content Engine にインポートし、Content Engine にこれらサイトをキャッシュするように指示します。ローカルに配置する Content Engines に対してこの作業を実行するには、「HTTPS キャッシング用の証明書と鍵の設定」 で説明されているように CLI を使用します。

HTTPS プロキシ パラメータ設定を行う CLI の例

次の例では、Content Engine を HTTPS プロキシ サーバとして設定し、ポート 8081 上で HTTPS 要求を受け入れるようにする方法を示します。HTTPS プロトコルでは 1 つのポートだけがサポートされます。

ContentEngine(config)# https proxy incoming 8081
 

次の例では、ポート 8880 で HTTPS 要求を発信プロキシ サーバ (10.1.1.1) に転送するように、Content Engine が設定されます。

ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880
 

次の例では、ドメイン名以外が発信プロキシ サーバに転送されます。

ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.com
ContentEngine(config)# proxy-protocols transparent default-server
 

次の例では、ローカルに配置する Content Engine 上にあるすべての HTTPS 関連情報を表示するために、 show https all コマンドが使用されています。

ContentEngine# show https all
Incoming HTTPS proxy:
Incoming Proxy-Mode:
Not servicing incoming proxy mode connections.
Outgoing HTTPS proxy:
Not using outgoing proxy mode.
Destination port restrictions:
Allow 443 563
HTTPS caching certificate information:
HTTPS caching certificate group information:
HTTPS caching private key information:
Display all https server caching information:
ContentEngine#

次の例では、HTTPS サーバをイネーブルにした状態で Content Engine 上で入力された show running-configuration コマンドによる出力を示しています。

ContentEngine# show running-config
!
!
wccp router-list 1 10.77.157.217
wccp https-cache router-list-num 1 password ****
wccp version 2
!
https server UNI certgroup chain uni-group
 

Content Engine GUI を使用した HTTPS プロキシの設定

ローカルに配置する Content Engine 上で HTTPS プロキシを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > HTTPS Proxy の順に選択します。HTTPS Proxy ウィンドウが表示されます(図 9-9 を参照)。

図 9-9 HTTPS Proxy ウィンドウ

 

ステップ 2 Content Engine が、1 つまたは複数のポート上でプロキシ スタイルの HTTPS 要求を受け入れるように設定するには、 Enable Incoming HTTPS Proxy On オプション ボタンをクリックします。

ステップ 3 Incoming HTTPS Proxy Port リストに、プロキシ サーバが要求を受信するときに使用するポート番号を入力します。HTTPS プロキシは、最大 8 つまでの着信ポートをサポートします。ポート番号は、1 ~ 65535 の範囲で指定可能です。


) HTTPS プロキシ要求をサポートするには、DNS サーバを設定(「DNS キャッシング ネーム サービス用の DNS サーバの設定」 で説明されているように)する必要があります。


ステップ 4 発信プロキシ オプションをイネーブルまたはディセーブルにするには、 Enable Outgoing HTTPS Proxy オプション ボタンを使用します。

すべての HTTPS トラフィックを親キャッシュ(ICP または WCCP を使用せずに)に送るように Content Engine を設定するには、 Enable Outgoing HTTPS Proxy On オプション ボタンを選択します。

Content Engine から親キャッシュへのすべての HTTPS トラフィック送信をディセーブルにするには、 Enable Outgoing HTTPS Proxy Off オプション ボタンを選択します。

ステップ 5 Outgoing HTTPS Proxy Address フィールドに、発信プロキシ サーバの IP アドレスを入力します。

ステップ 6 Outgoing HTTPS Proxy Port フィールドに、発信プロキシ サーバがプロキシ HTTPS 要求を受け入れるために使用するポート番号を入力します。

ステップ 7 個別のポート、またはすべての宛先ポートに対する制限を指定します。

Web クライアントが HTTPS サーバ以外のサーバに HTTPS トンネルを作成しないようにするために、宛先ポートを制限できます。この制限は個別のポートまたはすべてのポートに適用できます。制限規則に矛盾がある場合には、個別のポート設定が「all」規則よりも優先し、「allow」規則が「deny」規則よりも優先します。

宛先ポートに対して HTTPS トラフィックを許可または拒否する制限を設定することを強くお勧めします。デフォルトの設定では、期待するレベルのセキュリティを確保できないことがあります。


注意 注意: Destination Ports allow または deny ポリシーが設定されていない場合、Content Engine によって、期待するレベルのセキュリティを確保できないことがあります。

HTTPS を許可する個別の宛先ポートのリストを入力するには、 List of Destination Ports allowed フィールドを使用します。デフォルトでは、ポート 443 および 563 だけが許可されます。すべてのポートへのアクセスを許可する場合は、 all と入力します。

HTTPS を拒否する個別の宛先ポートのリストを指定するには、 List of Destination Ports denied フィールドを使用します。デフォルトでは、ポート番号が 1024 未満のポートは拒否されます。すべてのポートへのアクセスを拒否する場合は、 all と入力します。

ステップ 8 Update をクリックして設定を保存します。


) 特定の要求されコンテンツをキャッシュする場合、要求先のサイトに適した証明書と鍵を Content Engine にインポートし、Content Engine にこれらのサイトのコンテンツをキャッシュするよう指示します。Content Engine の適切な証明書と鍵を設定するための CLI の使用方法については、「HTTPS キャッシング用の証明書と鍵の設定」 を参照してください。



 

HTTPS キャッシング用の証明書と鍵の設定

ACNS 5.1 ソフトウェアでは、HTTPS キャッシング用の証明書と秘密鍵を設定するためには、CLI を使用する必要がありますが、Content Engine GUI は現在、この設定をサポートしていません。

Content Engine を HTTPS サーバとして使用するときに、証明書および秘密鍵の作成、除去、およびインポートを行うには、 https EXEC コマンドを使用します。

https {cert cert-name {add-cert | create | remove} | certgroup cert-name {create | import | remove} | key key_name {create | import | remove}}

表 9-14 では、 https コマンドに関するパラメータを示しています。

 

表 9-14 https EXEC コマンドのパラメータ

パラメータ
説明

cert

証明書の作成、削除、およびインポートを可能にします。

cert-name

証明書の名前を指定します。

add-cert

外部ソースから証明書を追加します。

create

証明書に名前を定義します。

remove

所定の名前を持つ証明書を削除します。

certgroup

証明書グループの追加または削除を可能にします。

cert-name

証明書グループの名前を指定します。

import

証明書グループに対して証明書のチェーンを追加します。

create

指定した名前で証明書グループを作成します。

remove

指定した名前で証明書グループを削除します。

key

秘密鍵の作成、削除、およびインポートを可能にします。

key_name

公開また秘密鍵ペアの名前を指定します。

create

秘密鍵に名前を定義します。

import

外部ソースから秘密鍵をインポートします。

remove

所定の名前を持つ鍵を削除します。

HTTP および HTTPS 発信プロキシの除外設定

透過キャッシング モード時には、Content Engine は、別のプロキシに送信された要求を代行受信して、これらの要求を次の 2 つの宛先のいずれかに送信できます。

デフォルト サーバ:これがデフォルト オプションです。Content Engine は、Web サーバ自体からオブジェクトを取得するか、または指定のプロトコルに対して発信プロキシを使用するように設定されている場合は、要求を発信プロキシに転送します。このシナリオでは、クライアント ブラウザの設定は無視され、サーバからのオブジェクトの取得には、Content Engine の設定が使用されます。

オリジナル プロキシ:Content Engine は、クライアントが要求の宛先として当初にアドレス指定したプロキシに要求を転送します。このプロキシは、指定のプロトコルに対して Content Engine 自体に設定されている発信プロキシとは異なる可能性があります。

ACNS 5 x ソフトウェアには、プロキシ転送からグローバルに除外される単一のドメイン名、ホスト名、または IP アドレスを管理者が指定するためのオプションもあります。ドメインは、スペースで区切った ASCII 文字列として入力します。IP アドレスにはワイルドカード文字 *(アスタリスク)を使用できます(例: 172.16.*.*)。ワイルドカード文字を含む宛先を指定した要求は、Content Engine プロキシ、およびフェールオーバー プロキシをバイパスします。

Content Engine が別のプロキシ サーバに対するプロキシ要求を代行受信し、HTTPS 用に設定された発信プロキシがないときに、 proxy-protocols transparent default-server コマンドが起動される場合、Content Engine はその要求を、クライアントが意図したプロキシ サーバではなく、宛先サーバに直接アドレス指定します。ただし、Content Engine 上で proxy-protocols transparent reset コマンドが設定され、キャッシュ ミスが発生した場合は、クライアントが送信し透過的に代行受信されたすべての要求は、クライアントに戻され、要求されたオブジェクトは、配信されません。

Content Engine GUI を使用した HTTP および HTTPS 発信プロキシの除外パラメータ設定

ローカルに配置する Content Engine 上でプロキシ プロトコルのパラメータを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Proxy Protocols の順に選択します。Proxy Protocols ウィンドウが表示されます(図 9-10 を参照)。

図 9-10 Proxy Protocol ウィンドウ

 


) Proxy Protocols ウィンドウには、Content Engine によってサポートされているプロトコルに適用される設定が含まれています。


ステップ 2 Default server または Original Proxy オプション ボタンをクリックします。これらの選択項目の説明は、表 9-15 を参照してください。

ステップ 3 発信 HTTP および HTTPS プロキシ除外機能を Content Engine 上でイネーブルにするには、次のステップを実行してください。

a. 発信 HTTP および HTTPS プロキシ除外機能を Content Engine 上でイネーブルにするには、 Do not use Outgoing Proxy for the following domains ボックスにチェックマークを付けます。

b. Do not use Outgoing Proxy for the following domains フィールドに、発信プロキシ サーバをバイパスして直接接続できるすべてのドメイン名を入力します。たとえば、 cisco.com と入力すると、Content Engine が cisco.com から Web ページを取得しようとする度に、設定された発信プロキシ サーバはバイパスされます。ドメイン名の代わりに IP アドレスを指定することもできます。IP アドレスにはワイルドカード文字 *(アスタリスク)を使用できます(例: 174.12.*.*)。リスト内のローカル ドメインは、 Return キーを押して区切る必要があります。

ステップ 4 Update をクリックして設定を保存します。


 

CLI コマンドを使用した HTTP および HTTPS 発信プロキシの除外パラメータ設定

ローカルに配置するContent Engine 上で、CLI を使用して、HTTP および HTTPS 発信プロキシ除外パラメータ(プロキシ プロトコル)を設定することができます。

表 9-15 では、プロキシ機能に関連した主要な Content Engine GUI パラメータと CLI コマンドを示しています。CLI コマンドの入力順序は、重要ではありません。

 

表 9-15 プロキシ プロトコルの主要パラメータ

主要パラメータ
説明
コマンド

Default server

Content Engine は、Web サーバ自体からオブジェクトを取得します。このオプションを使用すると、発信プロキシ サーバが設定されている場合に、プロキシ スタイルの要求を発信プロキシ サーバに送信できます。

proxy-protocols transparent default-server

Original proxy

Content Engine は、クライアントが要求の宛先として指定したオリジナルのプロキシに要求を転送します。

proxy-protocols transparent original-proxy

Do not use Outgoing Proxy for the following domains

ここに指定したドメイン名、ホスト名、または IP アドレスが、プロキシ転送から除外されます。

proxy-protocols outgoing proxy-exclude

プロキシ転送から除外されるドメイン名、ホスト名、または IP アドレスを指定するには、 proxy-protocols グローバル設定コマンドを使用します。outgoing-proxy exclude リストを選択的にオフにするか、または透過的に受信されたプロキシ スタイルの要求を Content Engine が処理するように強制するには、このコマンドの no 形式を使用します。

proxy-protocols outgoing-proxy exclude {enable | list word}

proxy-protocols transparent {default-server | original-proxy | reset}

表 9-16 では、 proxy-protocols コマンドに関するパラメータについて説明しています。

 

表 9-16 proxy-protocols CLI コマンドのパラメータ

パラメータ
説明

outgoing-proxy exclude

グローバルの発信プロキシ除外基準を設定します。

enable

グローバルの発信プロキシ例外をイネーブルにします。

list

グローバルの発信プロキシ除外リストを設定します。

word

プロキシ転送(64 個のリスト エントリをサポート)から除外するドメイン名、ホスト名、または IP アドレス。

transparent

プロキシ要求に対して透過モードの動作を設定します。

default-server

設定されている場合、Content Engine を使用してオリジン サーバまたは発信サーバに送信されます。

original-proxy

元の要求にある目的のプロキシ サーバを使用します。

reset

着信接続をリセットします。

proxy-protocols outgoing-proxy exclude list オプションを使用すると、システム管理者は、プロキシ転送からグローバルに除外される単一ドメイン名、ホスト名、または IP アドレスを指定できます。ドメイン名は ASCII 文字列として入力します。IP アドレスにはワイルドカード文字 *(アスタリスク)を使用できます(例: 174.12.*.*)。コマンドラインごとに 1 つの除外項目しか入力できません。複数の除外項目を指定するには、連続した複数のコマンドラインを入力してください。

proxy-protocols transparent default-server グローバル設定コマンドを入力すると、Content Engine は、代行受信した HTTP、HTTPS、および FTP のプロキシ スタイル要求を、対応する発信プロキシ サーバ(設定されている場合)に転送します。指定プロトコルに対応するように発信プロキシ サーバが設定されていない場合、要求は Content Engine とオリジン サーバによって処理されます。

proxy-protocols transparent original-proxy オプションは、Web クライアントが別のプロキシ サーバに送信した要求であるにもかかわらず、透過モードの Content Engine によって代行受信され、目的のプロキシ サーバに転送されるように指定します。

proxy-protocols transparent reset オプションは、Web クライアントが別のプロキシ サーバに送信した要求であるにもかかわらず、透過モードの Content Engine によって代行受信され、キャッシュ ミス時に Web クライアントに送り返されるように指定します。要求されたオブジェクトは配信されません。

Content Engine セキュリティ

要求が Content Engine を経由しているとき、いずれかの宛先 HTTPS ポートに不要なアクセスがされないようにするには、次の一連のコマンドを使用します。

no https destination-port allow 443 563

https destination-port deny all

これらの一連のコマンドは、1024 より上、および 1024 より下のすべてのポートへのアクセスを拒否します。ポート 443、およびポート 563(標準の HTTPS ポート)に対しては、 no https destination-port allow 443 563 コマンドを使用して、明示的にアクセスを拒否する必要があります。


ヒント TCP パケットおよび UDP パケットは、使用するアプリケーションによって定義されるポート番号を使用します。通常、ポート範囲 0 ~ 255 は、FTP などの標準的に使用する一般的なアプリケーションに使用され、ポート範囲 256 ~ 1023 は、各会社がリリースしている独自のアプリケーションに使用されます。たとえば FTP はポート 21 を使用し、Telnet はポート 23 を使用します。1024 ~ 65,536 のポート番号には、制約がありません。したがって、いずれかのポート番号を介したアクセスを特別に拒否する場合に、最適な番号として使用できます。


たとえば Content Engine 上でこれらのコマンドが設定され、 banking.wellsfargo.com のポート xxx へのアクセス要求が、この Content Engine にリダイレクトされたとき、banking.wellsfargo.com のポート xxx への接続は、拒否されます。この設定は、要求が Content Engine にリダイレクトされる透過的な配置シナリオ、またはユーザがその要求を直接 Content engine に送信する HTTPS プロキシ サーバ モードのいずれかで有効です。

HTTPS 統計レポーティング

接続統計だけが報告されます。要求と応答はセキュア トンネルを介して送信されるので、Content Engine は、送信された要求の数や要求ごとのバイト数を確認できません。したがって HTTPS の場合、要求と transaction per second(TPS)の統計情報は、入手できません。

HTTPS トランザクションのロギング

Content Engine は、Squid 構文に従って、HTTPS トランザクションをトランザクション ログに記録します。1 回の HTTPS 接続に対して、多数のトランザクションが実行されますが、ログ エントリは 1 回の接続ごとに 1 つ作成されます。Content Engine は、SSL トンネルを介して送付されたオブジェクトを認識せず、HTTPS サーバ名だけを認識します。

HTTPS TCP キープアライブ

キープアライブ メッセージが Content Engine によってクライアントまたはエッジ Content Engine に送信されない場合、接続はクローズされています。ACNS ソフトウェア リリース 5.1 では、https tcp-rw-timeout グローバル設定コマンドを使用して、Content Engine がキープアライブ メッセージを送信するように強制することができます。HTTPS TCP キープアライブ機能がイネーブルのとき、Content Engine は、TCP キープアライブ タイムアウト、TCP キープアライブ プローブ カウント、および TCP キープアライブ プローブ インターバルなどのキープアライブ 構成パラメータを使用して、TCP キープアライブをアイドル HTTPS TCP 接続で送信します。

最大読み取り・書き込みタイムアウトを 3600 秒(つまり、HTTPS キープアライブが送信される指定期間)に設定するには、https tcp-rw-timeout timeout コマンドを使用します。HTTPS 接続の場合、デフォルトのタイムアウト値は 5 分です。


) 特定の要求したコンテンツをキャッシュする場合、要求先のサイトの正式な証明書と鍵を Content Engine にインポートし、Content Engine にこれらのサイトのコンテンツをキャッシングするように指示します。


TFTP サーバおよびゲートウェイの設定

TFTP ゲートウェイ機能が ACNS ソフトウェア リリース 5.1 に追加されました。この新機能は、TFTP ネイティブ プロトコルを使用するネットワーキング デバイスが要求したコンテンツ ファイルを Content Engine が、配信する方式を提供します。Content Engines は、現在 TFTP から HTTP または FTP への変換を実行するため、システム管理者は TFTP 要求を処理するために専用の TFTP サーバを設定および管理する必要がなくなりました。この機能により、Content Engine は、クライアントからの TFTP ネイティブ要求をフロント エンドで受け入れ、その要求を HTTP または FTP プロトコルを使用してバック エンドで処理します。そのため、この機能は TFTP ゲートウェイと呼ばれます。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ設定、IP フォンの構成ファイルなどが含まれています。要求したファイルが Content Engine には存在しない場合、Content Engine はそのファイルをオリジン サーバから即座にキャッシュします。ACNS キャッシング システムは、そのデバイスに代わってファイルをインターネットから取得し、該当デバイスに転送します。この後、他のデバイスが同じファイルを要求する場合でも、Content Engine のキャッシュが使用されます。

ローカルに配置する Content Engine 上での TFTP サービスおよびゲートウェイの使用

ローカルに配置する Content Engine 上で TFTP サービスおよびゲートウェイを設定するには、 tftp-server コマンドを使用します。このとき TFTP 要求に応答するコンテンツをサービスする方法は、2 つあります。

ローカル コンテンツをサービスする:これを行うには、Content Engine 上でローカル ディレクトリを設定し、TFTP サーバをイネーブルにする。このトピックに関する詳細は、次項(「ローカル コンテンツのサービス」)を参照してください。

リモート サーバからコンテンツをサービスする:これを行うには、Content Engine 上で TFTP ゲートウェイ機能を設定する。このトピックに関する詳細は、「TFTP ゲートウェイを使用したリモート サーバからのコンテンツ サービス」を参照してください。

TFTP サーバおよびゲートウェイがイネーブルのときに、TFTP 要求に完全なパス名が指定されていない場合、Content Engine は、デフォルトのローカル ディレクトリ内でファイルを検索して、その TFTP 要求に応答します。完全なパス名が指定されている場合、Content Engine はそのパス名に部分的に一致するローカル ディレクトリ内でファイルを検索します。ファイルが見つからない場合、Content Engine は、HTTP または FTP プロトコルを使用して、その要求をキャッシュ アプリケーションに転送します。ファイルがリモート サーバで見つかった場合、Content Engine はそのファイルをキャッシュして、要求を出したクライアントに送信します。Content Engine は、それ以後そのファイルの要求に対して、ローカル キャッシュから応答します。ファイルが見つからない場合、Content Engine は「File not found」(ファイルが見つかりません)メッセージを出して応答します。

デフォルトでは、TFTP サービスはディセーブルとなっており、TFTP サーバへのアクセスは拒否されます。

TFTP サーバに割り当てられているデフォルトのローカル ディレクトリは、 /tftpboot です。ただし、このディレクトリはデフォルトでは、存在しないので mkdir コマンドを使用して作成する必要があります。

TFTP タイムアウト値は 5 秒に固定されており、再試行回数は 5 回で固定されています。これらの値は変更できません。

ローカル コンテンツのサービス

ローカル コンテンツの要求に応答する手順は、次のとおりです。

1. inetd enable tftp グローバル コマンドを使用して、TFTP サービスをイネーブルにします。

2. ローカルに配置する Content Engine 上で、ローカル TFTP ディレクトリを次のように設定します。

a. mkdir コマンドを使用して、ローカル ディレクトリを作成する。

b. tftp-server dir コマンドを使用して、TFTP サーバに対するローカル ディレクトリを識別します。

1 つまたは複数のローカル ディレクトリを識別するために、tftp-server dir コマンドを使用するときは、最初に識別されたディレクトリがデフォルトのディレクトリになります。識別しようとする各ディレクトリに対して、tftp-server dir コマンドを入力します。

TFTP サーバは、そのデフォルト ディレクトリ内で、完全修飾パス名を使用せずにファイルを検索します。TFTP サーバが他のローカル ディレクトリ内でもファイルを検索するのは、TFTP 要求が明示的にそのディレクトリを識別している場合だけです。

どのローカル ディレクトリも指定してない場合、 /tftpboot が自動的にデフォルト ディレクトリとして割り当てられます。ただし、その場合でも、TFTP サーバが要求をサービス可能になる前に、 mkdir コマンドを使用して /tftpboot ディレクトリを作成する必要があります。

TFTP ゲートウェイを使用したリモート サーバからのコンテンツ サービス

リモート サーバからコンテンツをサービス設定するには、TFTP サーバをイネーブルにして、TFTP ゲートウェイ(ローカルに配置する Content Engine)が要求を送信するリモート サーバも識別する必要があります。要求されたファイルがContent Engine のローカル ディレクトリ内に見つからないとき、Content Engine が要求を送信するサーバを識別するには、 tftp-server gw proto コマンドを使用します。このトピックに関する詳細は、 「TFTP サーバおよびゲートウェイの設定」 を参照してください。


) TFTP サーバおよびゲートウェイの動作に関する基本的な情報は、「TFTP サーバおよびゲートウェイの動作」を参照してください。Content Engine を TFTP サーバおよびゲートウェイとして稼働させるように設定する方法については、「TFTP サーバおよびゲートウェイの設定」を参照してください。


TFTP サーバおよびゲートウェイのイネーブル化

ローカルに配置する Content Engine 上で TFTP サーバまたはゲートウェイをイネーブルにする手順は、次のとおりです。

1. inetd enable tftp グローバル設定コマンドを使用して、TFTP サービスをイネーブルにします。

2. ip access-list グローバル設定コマンドを使用して、TFTP サービスへのアクセスを許可するアクセス リストを定義します。

3. tftp-server access-list コマンドを使用して、前述のアクセス リストを TFTP アプリケーションに適用します。

4. tftp-server コマンドの各種オプションを使用して、TFTP サーバを設定します。詳細は、次の項を参照してください。


) Content Engine は、透過的な TFTP 要求をサポートしていません。Content Engine は、Content Engine のホスト名または IP アドレスを明示的に含む要求を受け入れるのみです。


TFTP サーバおよびゲートウェイの設定

TFTP サーバは、ファイルに対して完全なディレクトリ パスを識別できないような要求を受け取ると、デフォルトのローカル ディレクトリ内でファイルを検索します。どのローカル ディレクトリも指定していない場合、デフォルト ディレクトリは /tftpboot です。このディレクトリはデフォルト ディレクトリとして自動的に割り当てられていますが、その場合でも mkdir コマンドを使用して、このディレクトリ(または TFTP サーバに割り当てたその他ディレクトリ)を作成する必要があります。

1 つまたは複数のローカル ディレクトリを識別するために、tftp-server dir コマンドを使用するときは、最初に識別されたディレクトリがデフォルトのディレクトリになります。識別しようとする各ディレクトリに対して、tftp-server dir コマンドを 1 回ずつ入力します。

TFTP サーバで他のローカル ディレクトリ内もファイルを検索するのは、TFTP 要求で明示的に特定のディレクトリを指定している場合に限られます。

TFTP サーバおよびゲートウェイの設定をローカルに配置する Content Engine で行うには、 tftp-server グローバル設定コマンドを使用して、次のステップを実行します。


ステップ 1 tftp-server dir コマンドを使用すると、Content Engine は TFTP 要求に完全なパス名が含まれていない場合に備えて、要求されたファイルを検索する 1 つまたは複数のローカル ディレクトリを指定することができます。

tftp-server dir ディレクトリ

たとえば、次のコマンドを実行すると、Content Engine は、TFTP 要求を実行するために、2 つのディレクトリを設定できます。

ContentEngine(config)# mkdir /local/mydir
ContentEngine(config)# mkdir /local/clients
ContentEngine(config)# tftp-server dir /local/mydir
ContentEngine(config)# tftp-server dir /local/clients
 

最初に指定されたディレクトリ /local1/mydir が、デフォルトのディレクトリと見なされます。

ステップ 2 tftp-server access-list コマンドを使用して、TFTP サーバおよびゲートウェイにアクセスを許可する IP ACL を識別します。

tftp-server access-list { acl - num | acl-n ame}

たとえば、TFTP アクセスが許可されるか、または拒否されるかを判別するには、アクセス リスト 1 を検査するように Content Engine を設定します。

ContentEngine(config)# tftp-server access-list 1
 

ステップ 3 tftp-server gw proto グローバル設定コマンドを使用して、Content Engine 上で TFTP ゲートウェイ機能をイネーブルにします。

Content Engine は要求されたファイルがローカル ディレクトリ内で見つからないときに、要求を転送する HTTP および FTP サーバを識別するために、tftp-server gw proto コマンドを使用します。 このコマンドの入力時には、プロトコル(FTP または HTTP)、サーバのホスト名または IP アドレス、および各サーバにアクセスするときに必要な認証情報を確認してください。tftp-server gw proto コマンドを 2 回入力して、プライマリとバックアップの HTTP または FTP サーバを設定できます。サーバをプライマリ(優先度 = 1)にするか、またはバックアップ(優先度 = 2)にするかを指定するには、priority オプションを使用します。

tftp-server gw proto { ftp | http} server { hostname | ip_address } [ name name passwd password] [ path directory ] pri priority

表 9-17 では、 tftp-server gw proto コマンドのパラメータを示しています。

 

表 9-17 tftp-server gw proto CLI コマンドのパラメータ

パラメータ
説明

gw

Content Engine にゲートウェイ機能を設定します。

proto

要求されたファイルがローカル ディレクトリ内で見つからないときに、TFTP の要求転送先であるオリジン サーバへのアクセスに使用されるプロトコルを設定します。

ftp

FTP プロトコルを使用して、オリジン サーバにアクセスします。

http

HTTP プロトコルを使用して、オリジン サーバにアクセスします。

server

オリジン サーバを設定します。

hostname

オリジン サーバのホスト名。

ip-address

オリジン サーバの IP アドレス。

name

(オプション)オリジン サーバへの認証に使用されるユーザ名を設定します。

name

(オプション)オリジン サーバへの認証に使用されるユーザ名。

passwd

(オプション)オリジン サーバへの認証に使用されるパスワードを設定します。

password

(オプション)オリジン サーバへの認証に使用されるパスワード。

pri

オリジン サーバに優先度を設定します。

priority

オリジン サーバの優先度(1 または 2)。

path

(オプション)オリジン サーバ上でファイルを検索するためのパス名を設定します。

directory

(オプション)オリジン サーバ上でファイルを検索するためのパス名。

ゲートウェイ機能をイネーブルにし、TFTP 要求が転送される特定のサーバを識別するには、 tftp-server gw proto コマンドを使用します。このコマンドの入力時には、プロトコル(FTP または HTTP)、サーバのホスト名または IP アドレス、および各サーバにアクセスするときに必要な認証情報を確認してください。tftp-server gw proto コマンドを 2 回入力して、プライマリとバックアップの HTTP または FTP サーバを設定できます。サーバをプライマリ(優先度 = 1)にするか、またはバックアップ(優先度 = 2)にするかを指定するには、priority オプションを使用します。


 

TFTP サーバおよびゲートウェイの設定例

ここでは、ローカルに配置する Content Engine 上で TFTP サーバおよびゲートウェイを設定する例をいくつか示します。

例 1

次のコマンドを実行すると、Content Engine 上で TFTP サーバがイネーブルになります。

ContentEngine(config) inetd enable tftp
 

例 2

次のコマンドを実行すると、192.168.1.0 のサブネットワーク上で FTP クライアントが TFTP サービスにアクセスすることを許可するアクセス リストが定義されます。

ContentEngine(config)# ip access-list standard 1
ContentEngine(config-std-nacl)# ip access-list permit 192.168.1.0 0.0.0.255
ContentEngine(config-std-nacl)# exit
 

例 3

次のコマンドを実行すると、Content Engine は、TFTP 要求を実現するために、2 つのローカル ディレクトリを設定します。

ContentEngine(config)# tftp-server dir /local1/mydir
ContentEngine(config)# tftp-server dir /local1/clients
 

最初に指定されたディレクトリ /local1/mydir が、デフォルトのディレクトリと見なされます。

例 4

次のコマンドを実行すると、TFTP サービスへのアクセスを許可する IP アクセス リストが識別されます。

ContentEngine(config)# tftp-server access-list 1
 

例 5

次のコマンドを実行すると、Content Engine 上で TFTP ゲートウェイ機能がイネーブルになり、Content Engine がローカル ディレクトリ内でファイルを見つけられないときに、要求の転送先となる FTP サーバが識別されます。またこのコマンドにより、オリジン サーバへの認証に使用されるユーザ名およびパスワードが設定されます。

ContentEngine(config)# tftp-server gw proto ftp 192.168.100.1 pri 1 path /myremotedir name myuser passwd mypassword
 

ディレクトリ名 /myremotedir はリモート サーバからファイルを取得するために Content Engine 上のキャッシング アプリケーションが送信する URL で使用されます。この例の設定を使用して生成された URL は、次のようになります。

ftp://myuser:mypasswd@192.168.100.1/myremotedir/ requested-file-name

ICP パラメータの設定

Internet Cache Protocol (ICP) は、Content Engine 間での通信、および従来のプロキシ プロトコルとの相互運用性のサポートに使用される Lightweight メッセージ形式です。ICP は、Content Engine ファーム内の近隣キャッシュに存在する URL についての情報を交換するために使用されます。Content Engine は、ICP の照会と応答をやり取りして情報を収集し、その情報を使用して、オブジェクトの取得先として最適な場所を選択します。

ICP は従来、キャッシュ クラスタ全体のサイズを単一の装置以上に拡張するために使用されていましたが、最近では ICP は、キャッシュ クラスタ ソリューションのスケーリング手段として適していないことが判明しています。現在は、トラフィックを透過ネットワーク キャッシュ クラスタに向けて送信する手段が使われているので、キャッシュを配置するために ICP を使用する必要性は、ほとんどなくなりました。

ICPv2 プロトコルは、次の 2 つの標準文書として文書化されています。

RFC 2186: Internet Cache Protocol (ICP), version 2

RFC 2187: Application of Internet Cache Protocol (ICP), version 2


) ICP サーバ(近隣キャッシュからの要求に対してサービスを提供する)、および ICP クライアント(要求を近隣キャッシュに送信する)の両方として動作するための機能がサポートされています。


Content Engine GUI または CLI を使用して、ローカルに配置する Content Engine 上の ICP パラメータを設定することができます。

ICP クライアント パラメータの設定

ICP クライアント機能を使用して必要なオブジェクトをインターネットから取得する前に、ICP 照会を生成するように Content Engine ファームを設定できます。

ICP 機能を使用して、親および子の関係にある Content Engine を階層的に構成できます。Content Engine の階層内で、ICP の親は、基本的に ICP の子より 1 階層上にあります。

Content Engine は、親または子のいずれにも設定できます。キャッシュ ミス時に、親の Content Engine はデータを取得できますが、子の Content Engine はデータを取得できず、代わりに要求を親の Content Engine に転送します。

Content Engine GUI を使用した ICP クライアントのパラメータ設定

ローカルに配置する Content Engine 上で ICP クライアント機能を設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > ICP Client の順に選択します。ICP Client ウィンドウが表示されます(図 9-11 を参照)。

図 9-11 ICP Client 設定ウィンドウ

 

ステップ 2 Enable ICP Client On オプション ボタンをクリックして、ICP クライアント クエリーをイネーブルにします。

ステップ 3 Max wait for replies フィールドに、ICP 応答に対するタイムアウト期間を秒数で指定します。範囲は 1 ~ 30 秒で、デフォルトは 2 秒です。

ステップ 4 Remove from wait-list フィールドに、応答しない ICP サーバをリストから削除する前に、各 Content Engine が ICP サーバに試行する数(失敗数)を指定します。範囲は 0 ~ 100 で、デフォルト値は 20 回の失敗です。

ステップ 5 Do not IPC these Domains フィールドに、ICP クエリーから除外するドメインを入力します。ここにリストされているドメインから要求されたオブジェクトは、ICP 要求を生成しません。

ステップ 6 Update をクリックして設定を保存します。

ステップ 7 このウィンドウを使用して、ICP サーバを追加する手順は、次のとおりです。

a. ICP サーバの IP アドレスまたはホスト名を入力します。

b. この ICP サーバを親キャッシュにする( Parent チェックボックスにチェックマークを入れる)か、または 子キャッシュにする( Parent チェックボックスのチェックマークを外す)かを選択します。キャッシュ ミス時に親キャッシュはデータを取得するのに対し、子キャッシュはデータを取得しません。

c. ICP クエリーがこのキャッシュに送信される ICP ポートを入力します。範囲は 1 ~ 65535 で、デフォルト ポートは 3130 です。

d. プロキシ スタイルの要求が転送される HTTP ポートを入力します。範囲は 1 ~ 65535 で、デフォルト ポートは 3128 です。

e. 特定のドメインをまとめて、この Content Engine に送信される ICP 要求を制限する場合は、Use only for these domains フィールドにこれらのドメインを入力します。ICP 要求を制限しない場合、すべての ICP 要求(ローカル ドメインとして指定されている ICP 要求を除く)がこの ICP サーバに転送されます。

ステップ 8 入力が完了したら、 Update を再度クリックします。

ICP Client ウィンドウが更新されて、このウィンドウには、追加したばかりの ICP サーバが表示されます。


 

CLI コマンドを使用した ICP クライアントのパラメータ設定

ローカルに配置する Content Engine 上で ICP サーバと ICP クライアント機能を確立および設定するには、 icp グローバル設定コマンドを使用します。ICP 機能をイネーブルにせずに行われた設定は、削除されるまでその構成内に保存されます。

CLI グローバル設定コマンドを使用して ICP クライアントを設定するには、 表 9-18 を参照してください。

 

表 9-18 ICP クライアント CLI コマンドの要約

コマンド
説明

icp client enable

クライアント ICP をイネーブルにします。

icp client add-remote-server

リモート ICP クライアント サーバを追加します。

icp client exclude

ローカル ドメインを ICP キャッシング サービスから除外します。

icp client max-fail

応答しない ICP サーバをリストから削除する前に、各 Content Engine が ICP サーバに対して試行する数(失敗数)を設定します。

icp client max-wait

Content Engine が要求されたデータをインターネットから直接取得する前に待つ時間を設定します。

icp client modify-remote-server

リストにある ICP サーバを変更します。

次の例では、ICP の親と子は特定のドメイン セットに制限されます。

ContentEngine(config)# icp client add-remote-server 172.16.0.0 parent icp-port 3130 http-port 3128 domain_x.com domain_y.com domain_z.com
 
ContentEngine(config)# icp client add-remote-server 172.16.0.0 sibling icp-port 3130 http-port 3128 domain_a.com domain_b.com domain_c.com
 
ContentEngine(config)# icp client enable
Icp Client started
 

ICP サーバのパラメータ設定

ローカルに配置する Content Engine を ICP サーバとして機能するように設定することも可能です。このように設定すると、Content Engine は、階層内の ICP 親クライアントと子クライアントに対して ICP メッセージのマルチキャストを行い、Content Engine の階層を探査できます。

Content Engine GUI を使用した ICP クライアントのパラメータ設定

ローカルに配置する Content Engine を ICP サーバとして機能するように設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching> ICP Server の順に選択します。ICP Server ウィンドウが表示されます(図 9-12 を参照)。

図 9-12 ICP Server Settings ウィンドウ

 

ステップ 2 Enable ICP Client On オプションボタンにチェックマークを付けて、ICP サーバ クエリーをイネーブルにします。

ステップ 3 ICP Port フィールドに、Content Engine が ICP 要求を受信する ICP ポート番号を指定します。範囲は 1 ~ 65535 で、デフォルトはポート 3130 です。

ステップ 4 HTTP Port フィールドに、Content Engine が ICP により生成された要求を受信するポートを指定します。範囲は 1 ~ 65535 で、デフォルトはポート 3128 です。

ステップ 5 Update をクリックして設定を保存します。

ステップ 6 このウィンドウを使用して、有効な ICP クライアントの追加、削除、または変更の手順は、次のとおりです。

a. ICP クライアントの IP アドレスまたはホスト名を入力します。

b. Content Engine を指定した ICP クライアントに対して親サーバとして機能するように設定するには、Fetch Misses カラムの下にあるチェックボックスにチェックマークを付けます。Content Engine がクライアントの要求を満たすことができない場合、Content Engine は、要求を別のサーバまたはインターネットに転送します。

c. Content Engine を子サーバとして機能するように設定するには、Fetch Misses カラムの下にあるチェックボックスのチェックマークを外します。Content Engine がクライアントの要求を満たすことができないとき、Content Engine は失敗した応答をクライアントに戻します。

ステップ 7 入力が完了したら、 Update を再度クリックします。

ICP Client ウィンドウが更新されて、このウィンドウには、追加したばかりの ICP クライアントが表示されます。


 

CLI コマンドを使用した ICP クライアントのパラメータ設定

ローカルに配置する Content Engine の ICP サーバと ICP クライアント機能を確立および設定するには、 icp グローバル設定コマンドを使用します。ICP 機能をイネーブルにしないで行われた設定は、削除されるまでその構成内に保存されます。

CLI グローバル設定コマンドを使用して ICP サーバのパラメータを設定するには、 表 9-19 を参照してください。

 

表 9-19 ICP サーバ CLI コマンドの要約

コマンド
説明

icp server enable

サーバ ICP を使用可能にします。

icp server http-port

ICP によって生成された要求を受信する HTTP プロキシ ポートを設定します。範囲は 0 ~ 65535 です。デフォルトのポート番号は 3128 です。

icp server port

ICP 要求を受信する Content Engine 上の ICP サーバ ポートを設定します。範囲は 0 ~ 65535 です。デフォルトのポート番号は 3130 です。

icp server remote-client

リストにある ICP クライアントを変更します。

WCCP のパラメータ設定

ここでは、Content Engine 上で透過的なキャッシング サービスを使用可能にするために Content Engine 上で WCCP パラメータを設定する方法について説明します。


) WCCP を介した透過的キャッシングに関する情報は、「透過キャッシング」を参照してください。WCCP Version 1 および Version 2 についての詳細は、付録 B「Web Cache Communication Protocol Version 1」および付録 C「Web Cache Communication Protocol Version 2」をそれぞれ参照してください。


Content Engine 上での WCCP のイネーブル化

ローカルに配置する Content Engine 上で WCCP Version 1 または Version 2 をイネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 WCCP > Enable WCCP の順に選択します。Enable WCCP ウィンドウが表示されます(図 9-13 を参照)。

図 9-13 Enable WCCP ウィンドウ

 

ステップ 2 この Content Engine 上で実行させる WCCP サービスを決定した上で、イネーブルにしたい Content Engine での WCCP のバージョンを選択します。

WCCP Version 1 をイネーブルにするには、 Version 1 オプション ボタンをクリックします。

WCCP Version 2 をイネーブルにするには、 Version 2 オプション ボタンをクリックします。

Content Engine は、Version 1 および Version 2 でサポートされている Web キャッシュ サービス(サービス グループ 0)以外に、 表 9-20 にリストされているキャッシュ関連サービスをサポートするには、WCCP Version 2 を実行する必要があります。

 

表 9-20 WCCP サービス グループ

サービス グループ番号
サービスの説明

0

Web キャッシュ

50

ブーメラン

80

HTTP、RTSP

81

MMST

82

MMSU

90 ~ 97

ユーザが設定可能

98

カスタム

99

リバース プロキシ


表 9-20リストされているすべてのサービス グループ番号を実行するには、WCCP Version 2 が必要です(ただし、Web キャッシュ サービス(サービス グループ 0)を除きます)。ACNS 5.1 ソフトウェア リリースでは、DNS WCCP 透過代行受信(WCCP Service ID 53)が追加されました。WCCP Version 1 および Version 2 についての詳細は、付録 B「Web Cache Communication Protocol Version 1」および付録 C「Web Cache Communication Protocol Version 2」をそれぞれ参照してください。


ステップ 3 Version 1 オプション ボタンを選択した場合、次のステップを実行します。

a. Home Router フィールドに、指定したホーム ルータの IP アドレスを入力します。この IP アドレスもデフォルト ゲートウェイのアドレスになることがあります。

b. Update をクリックして、Content Engine 上で WWCP Version 1 の設定を保存します。


ヒント WCCP Version 1 では、1 台のルータが 1 つのクラスタを処理し、そのルータがクラスタのデフォルト ホーム ルータになります。WCCP Version 1 を使用した Web キャッシング サービスのイネーブル化の方法については、付録 B「Web Cache Communication Protocol Version 1」を参照してください。


ステップ 4 Version 2 オプション ボタンを選択した場合、次のステップを実行します。

a. Wait for Clean shutdown フィールドに、すべての WCCP Version 2 の接続が解除されている間、Content Engine が待機する最大時間を指定します。 reload コマンド発行時に、Content Engine は、すべての接続が処理されるか、あるいは指定された待機時間が経過するまではリブートしません。有効値は 0 ~ 1 日(86400 秒)です。デフォルト値は 2 分(120 秒)です。

b. この Content Engine および各種の WCCP 対応ルータでサポートされる特定の WCCP サービスをサポートするために使用されるルータのリストを作成するには、Routers Lists を使用します。Router Lists フィールドに、各ルータの IP アドレスまたはマルチキャスト アドレスを入力します。ここでのルータは、特定のサービスに対してトラフィックをこのキャッシュにリダイレクトするルータです。各種サービスに対して複数の異なるルータを使用する場合、複数の Router List を作成する必要があります。各サービスに対して指定された Router List を Content Engine GUI Web Caching、Reverse Proxy、Custom Web Cache または WCCP Service ウィンドウでも指定する必要があります。

c. Port Lists を使用して、サポートされる各 WCCP サービスに対するポート リストを作成します。


ヒント Version 2 では、一般的な WCCP サービス(90 ~ 97 の番号が付いた)が用意されています。これらのサービスは複数のポート(各 WCCP サービスにつき、最大 8 つまでのポート)をサポートします。これらのサービスを設定するには、使用する各 WCCP に対して 1 つのポート リストを作成する必要があります。1 つのポート リストには、最大 8 つまでのポートを含めることができます。

d. Update をクリックして、WCCP Version 2 の設定を保存します。

Content Engine 上で WCCP Version 2 をイネーブルにし、Router Lists を定義した後、特定のWCCP サービスをサポートする Content Engine および WCCP 対応のルータ上で、その特定のサービスをイネーブルにしてください。このサービスをサポートするために、Web キャッシング サービス(WCCP サービスの 1 つ)をイネーブルにし、特定の Router List を設定する例については、次の項(Content Engine 上での WCCP 2 サービスのイネーブル化)を参照してください。

WCCP Version 2 も Router Lists にリストされているルータ上でイネーブルにする必要があります。WCCP のバージョンがこれらのルータで使用可能でない場合、「CLI コマンドを使用した WCCP Version 2 サービスの設定」で説明されているステップを実行して、各ルータ上で WCCP をイネーブルにしてください。指定した WCCP サービスを特定の Router List にリストされている、そのサービスに関連付けられた WCCP Version 2 ルータ上でイネーブルにすることも必要です。


 

Content Engine 上での WCCP 2 サービスのイネーブル化

WCCP Version 2 を Content Engine 上でイネーブルにし、WCCP 対応ルータのリストを定義(「Content Engine 上での WCCP のイネーブル化」で説明されているように)した後、特定の WCCP サービスを Content Engine でイネーブルにして、その WCCP サービスをサポートしているルータのリストを表示する必要があります。


) WCCP Version 2 サービスのリストについては、表C-1を参照してください。


ここでは、WCCP Version 2 を使用する Web キャッシング サービスをイネーブルにして、このサービスをサポートするために複数のルータを使用できるようにする方法を例として説明します。各種 WCCP サービスの運用についての情報は、「透過キャッシング」を参照してください。

Content Engine GUI を使用した Content Engine 上での WCCP 2 サービスのイネーブル化

ローカルに配置する Content Engine 上で Web キャッシング サービスを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 WCCP > Web Cache の順に選択します。Web Cache ウィンドウが表示されます(図 9-14 を参照)。

図 9-14 Web Cache ウィンドウ

 

ステップ 2 Enable On ボタンをクリックして、この Content Engine 上の Web キャッシュ サービスをイネーブルにします。

ステップ 3 Router List ドロップダウン リストから、このサービスと関連付けるルータ リストの数を選択します。

ステップ 4 Password フィールドに、サービス内の認証に使用する秘密情報を許可するパスワードを入力します。何らかの秘密情報を使用して Content Engine をイネーブルにするには、パスワードをこのフィールドに入力します。


ヒント 同一環境内にあるすべてのルータおよびキャッシュは、必ず同じ秘密情報で設定してください。

ステップ 5 Weight フィールドを使用して、手作業で負荷分散を制御できるようにします。0 ~ 100 までの値を指定できます。各 Content Engine に割り当てられたこの値は、リダイレクトされる負荷のパーセンテージ(負荷が 30 の場合、総負荷量の 30% を受け取る)を表します。ただし、1 つのキャッシュ クラスタ内に割り当てられているすべての負荷値の合計が 100 を超える場合、この合計値をもとに負荷の割り当てが行われます。

ステップ 6 次の読み取り専用フィールド内の情報に注意してください。

Service ID フィールドは読み取り専用で、使用中の WCCP サービスのタイプを指定します。この場合、Service IC は web-cache です。この値が、そのルータで有効になっていることが必要です。

Port フィールドには、すべてのトラフィックがキャッシュにリダイレクトされる発信ポートの宛先が示されています。この場合は、ポート 80 です。

Hashing フィールドにより、トラフィックが複数のキャッシュ間でどのように負荷分散が行われるかが指定されます。この場合、Destination IP によって指定されます。

Protocol フィールドでは、キャッシュにリダイレクトされるトラフィックのタイプが指定されます。この場合、Web キャッシュに使用されるプロトコルは HTTP です。

ステップ 7 レイヤ 2 リダイレクトによるパケット転送をイネーブルにする場合は、 L2 Redirect Yes ボックスにチェックマークを付けます。

ステップ 8 Update をクリックします。


 

これで、Content Engine での Web キャッシング サービスはイネーブルになりました。次のステップでは、指定したルータのリストでそのサービスをイネーブルにします。この作業を実行するには、次の項で説明されているように CLI を使用してください。

CLI コマンドを使用した WCCP Version 2 サービスの設定

ルータをはじめ、Content Engine で WCCP Version 2 サービスをイネーブルにするために、CLI を使用することができます。ルータ上で WCCP Version 2 サービスをイネーブルにするには、 CLI を使用する必要があります。Content Engine 上で WCCP をイネーブルにするには、 wccp グローバル設定コマンドを使用します。ルータ上で WCCP をイネーブルにするには、 ip wccp グローバル設定コマンドを使用します。

次の例は、クライアントおよび Content Engine が同一のサブネット上にあるとき、ルータと Content Engine を Web キャッシュ サービス用に設定するための CLI の使用方法を示しています。

 

目的
コマンド

ステップ 1

WCCP Version 2 がすべてのルータでイネーブルになっていることを確認します。

ルータ リスト内の各ルータから、次のように入力します。

Router(config)# ip wccp version 2

ステップ 2

ルータ上で Web キャッシュ サービスを設定します。

Router(config)# ip wccp web-cache

ステップ 3

Content Engine 上で WCCP 2 をイネーブルにします。

ContentEngine(config)# wccp version 2

ステップ 4

Content Engine 上で Web キャッシュ サービスを設定します。

対象の Web キャッシュ サービスに対するルータ リストを設定します。

ContentEngine(config)# wccp router-list 1 10.10.10.1
 

Content Engine 上で Web キャッシュ サービスを設定し、そのサービスを作成したルータ リスト(たとえば、ルータ リスト 1)と関連付けます。このコマンドはまた、この Content Engine が Web キャッシュ サービスを受け入れていることを指定されたルータ リスト内のルータに通知します。

ContentEngine(config)# wccp web-cache router-list-num 1

ステップ 5

Web キャッシュ サービスをステップ 2 で作成したルータ リストと関連付けて、レイヤ 2 リダイレクト オプションを割り当てます。マスク アサイメント方式が指定されていない場合は、負荷分散方式のデフォルトはハッシュアサイメントです。

ContentEngine(config)# wccp web-cache router-list-num 1 l2-redirect

ステップ 6

グローバル設定モードを終了します。

ContentEngine(config)# exit

ステップ 7

実行中の設定を不揮発性メモリに書き込みます。

ContentEngine# write memory

WCCP 透過キャッシュ オプションの設定

透過的なネットワーク要求のリダイレクト、およびキャッシングを行うソリューションの基本原則の 1 つは、Content Engine がエンド ユーザに対して常に透過的でなければならないということです。ACNS ネットワ―ク環境の透過キャッシング ソリューションが原因で、ネットワークに何らかの障害、または副次的な障害が発生したり、副作用が発生したりしないようにする必要があります。

Web ブラウザが動作しない場合や、Web サーバが HTTP に準拠していない場合でも、Cisco ACNS 透過キャッシング ソリューションは、WCCP 対応のルータと各種の高度な技法を使用して、Content Engine の透過性を確保します。

Content Engine に過大なトラフィックが発生した場合は、Content Engine は、過負荷バイパス機能を使用して過負荷トラフィックを再ルーティングできます。Content Engine が過負荷状態になったときに bypass load コマンド が使用可能になっていると、Content Engine は以後の要求を拒否し、オリジン サーバに要求を転送します。それでも負荷が高すぎる場合は、サーバにバイパスされるトラフィックの量が増え、Content Engine が負荷を処理できるようになるまでバイパスが続けられます。あるバケットがバイパスされてから次のバケットがバイパスされるまでの時間間隔は、 out-interval オプションを使用して設定します。デフォルトは 4 秒です(図 9-15 を参照)。

図 9-15 過負荷バイパス

 

最初のバケットのバイパスが発生した後、Content Engine がバイパスされたバケットへのサービスを再度開始するには、ある一定時間が経過する必要があります。この間隔の期間は、 time-interval オプションによって設定します。デフォルトは 10 分です。

バイパスされたトラフィックのサービスを Content Engine が再度開始する際に、最初は 1 つのバイパス バケットからサービスを開始します。それ以上の負荷がかかっても処理できる場合には、Content Engine はバイパス バケットをもう 1 つ引き取り、以後も同様に行います。あるバケットを引き取ってから次のバケットを引き取るまでの時間間隔は、 in-interval オプションによって設定します。デフォルトは 60 秒です。

認証トラフィックの設定

IP 認証上の理由から、ある種の Web サイトでは、Content Engine はクライアントの代理として直接接続することができません。キャッシュの透過性を確保し、サービスの中断を防ぐために、Content Engine は認証トラフィックのバイパスを使用して、選択されたクライアント/サーバの組のために、ダイナミック アクセス リストを自動的に生成できます。階層キャッシングを行っている場合は、認証バイパス トリガーは、アップストリームとダウンストリームにも伝搬されます。


) バイパス機能は、WCCP Version 2 がローカル ネットワーク内で使用可能になっているときにだけ使用できます。


WCCP バイパスのパラメータ設定

Content Engine に過大なトラフィックが発生したときに、バイパス オプションが使用可能になっていると、Content Engine は、過負荷状態が解消されるまでトラフィックを一度に 1 バケットずつバイパスします。バケットは、Content Engine ファーム内の各 Content Engine に割り当てられたハッシュのサブセクションとして定義されます。この環境に Content Engine が 1 台だけ存在する場合は、256 のバケットが Content Engine に割り当てられます。

Content Engine GUI または CLI を使用して、ローカルに配置する Content Engine 上で WCCP のバイパス パラメータを設定することができます。


ヒント WCCP バイパスは、WCCP v2 設定に対してのみ設定可能です。


Content Engine GUI を使用した WCCP バイパスの設定

ローカルに配置する Content Engine 上で WCCP バイパスを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Bypass の順に選択します。Bypass ウィンドウが表示されます(図 9-16 を参照)。

図 9-16 WCCP Bypass 設定ウィンドウ

 

ステップ 2 トラフィックのバイパスを使用可能にするには、 Load Bypass Enable オプション ボタンにチェックマークを付けます。

ステップ 3 Time interval between bypassing buckets フィールドに、バケットをバイパスする間隔の値(秒単位)を指定します。

Content Engine に過大なトラフィックが発生したときに、バイパス オプションが使用可能になっていると、Content Engine は、過負荷状態が解消されるまでトラフィックを一度に 1 バケットずつバイパスします。このフィールドは、あるバケットをバイパスしてから次のバケットをバイパスするまでの時間を指定します。デフォルト値は 4 秒です。

ステップ 4 Time that a bucket is bypassed フィールドに値(分単位)を指定します。

バケットがバイパスされた後、このフィールドに指定した時間は、Content Engine はバイパス モードのままになり、バイパスされた負荷を引き取りません。デフォルト値は 10 分です。

ステップ 5 Time interval between buckets coming back フィールドに、バケットが戻ってくる間隔を値(秒数)で指定します。

バイパス モードに割り当てられた時間間隔が経過した後、Content Engine は、バイパスされたトラフィックの引き取りを一度に 1 バケットずつ開始します。各バケットを引き取る間隔を秒単位で指定します。デフォルト値は 2 秒です。

ステップ 6 WCCP バイパス機能をイネーブルにするには、 Authentication Bypass On オプション ボタンにチェックマークを付けます。


ヒント ある種の Web サイトでは、Content Engine はクライアントの代理として直接接続することができません。トラフィックのバイパス時にサービスが中断されないように、Content Engine は認証バイパスを使用してこれらのクライアント/サーバの組のために、ダイナミック アクセス リストを生成できます。認証バイパス トリガーは、ACNS ネットワーク環境内でアップストリームとダウンストリームにも伝搬されます。


ステップ 7 Bypass entry Expiration Time フィールドに、値(分単位)を指定します。

この値は、アイドル状態のクライアント/サーバの組がバイパス アクセス リストに残る時間を示します。デフォルト値は 20 分です。

ステップ 8 Update をクリックして設定を保存します。


 

CLI コマンドを使用した WCCP バイパスの設定

透過エラー処理とダイナミック認証バイパスをイネーブルにし、スタティック バイパス リストを設定するには、 bypass グローバル設定コマンドを使用します。バイパス機能をディセーブルにする場合は、このコマンドの no 形式を使用します。

bypass {auth-traffic enable | gateway ipaddress | load { enable | in-interval seconds | out-interval seconds | time-interval minutes } | static {clientip | any-client} {serverip | any-server} | timer minutes }

過負荷 バイパス

Content Engine に過大なトラフィックが発生した場合は、Content Engine は、過負荷バイパス機能を使用して過負荷トラフィックを再ルーティングできます。Content Engine が過負荷状態になったときに、 bypass load コマンドが使用可能になっていると、Content Engine はバケットをバイパスします。それでも負荷が高すぎる場合は、さらにバケットがバイパスされ、Content Engine が負荷を処理できるようになるまでバイパスが続けられます。あるバケットがバイパスされてから次のバケットがバイパスされるまでの時間間隔は、 out-interval オプションを使用して設定します。デフォルトは 4 秒です。

最初のバケットのバイパスが発生した後、Content Engine がバイパスされたバケットへのサービスを再度開始するには、ある程度の時間が経過する必要があります。この間隔の期間は、 time-interval オプションによって設定します。デフォルトは 10 分です。

バイパスされたトラフィックのサービスを Content Engine が再度開始する際に、最初は 1 つのバイパス バケットからサービスを開始します。それ以上の負荷がかかっても処理できる場合には、Content Engine はバイパス バケットをもう 1 つ引き取り、以後も同様に行います。あるバケットを引き取ってから次のバケットを引き取るまでの時間間隔は、 in-interval オプションによって設定します。デフォルトは 60 秒です。

スタティック バイパス

bypass static コマンドは、指定された送信元からのトラフィックが Content Engine をバイパスできるようにします。その場合のトラフィック送信元のタイプは、次のとおりです。

特定の Web クライアントから、特定の Web サーバへ

特定の Web クライアントから、任意の Web サーバへ

任意の Web クライアントから、特定の Web サーバへ

送信元フィールドおよび宛先フィールドには、ワイルドカードを使用できません。

すべてのスタティック設定リストをクリアするには、 bypass static コマンドの no 形式を使用します。