中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.4
ACNS ネットワークのコンテンツ要求 ルーティング設定
ACNS ネットワークのコンテンツ要求ルーティング設定
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

ACNS ネットワークのコンテンツ要求ルーティング設定

WCCP 透過ルーティングの設定

WCCP サービスの概要

動的 WCCP リダイレクト サービスの概要

HTTPS の WCCP サービスの概要

WCCP カスタム Web キャッシュ サービスの概要

Content Engine の WCCP 一般設定

クライアントの IP スプーフィングの概要

WCCP スロー スタートの概要

WCCP クリーン シャットダウンの概要

Content Engine の WCCP のサービス設定

負荷分散の概要

WCCP ルータ リストの作成

Content Engine の WCCP ルータ リストの変更

Content Engine の WCCP ルータ リストの表示

デバイス グループ内の Content Engine への一意のルータ リストの割り当て

Content Engine の WCCP ポート リストの設定

Content Engine の WCCP サービス マスクの設定

WCCP 透過ルーティング バイパス オプションの設定

認証トラフィックのバイパス設定

WCCP バイパスの設定

WCCP バイパス リスト エントリの作成

ルータ上での WCCP のイネーブル化

Web キャッシング用の基本的な WCCP ルータ設定

クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

Web キャッシュ サービス用の Content Engine の設定 ― クライアントと Content Engine が同一サブネット上にある場合

Web キャッシュ サービス用のルータの設定 ― クライアントと Content Engine が同一サブネット上にある場合

設定例 ― クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

Web キャッシュ サービス用の Content Engine の設定 ― クライアントと Content Engine が異なるサブネット上にある場合

Web キャッシュ サービス用のルータの設定 ― クライアントと Content Engine が異なるサブネット上にある場合

設定例 ― クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

直接プロキシ ルーティングの設定

プロキシ自動設定ファイル サーバの使用

PAC ファイル テンプレートの作成

PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当て

PAC ファイル サーバとしての Content Engine の設定

クライアント プロキシ自動設定の設定

Content Router またはルーティング Content Engine を使用したコンテンツ要求ルーティングの設定

カバレッジ ゾーンとカバレッジ ゾーン ファイル

カバレッジ ゾーン ファイルの登録

カバレッジ ゾーンの選択

デフォルト カバレッジ ゾーンの使用

ユーザ定義カバレッジ ゾーンの登録と適用

カバレッジ ゾーン ファイルの例

シナリオ 1:NAT ファイアウォールがない場合

シナリオ 2:NAT ファイアウォールの背後に Content Engine がある場合

シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

ルーティング Content Engine としての Content Engine の設定

Content Router を使用した動的コンテンツ ルーティングの設定

動的コンテンツ ルーティングのイネーブル化

カバレッジ ゾーン ファイルの動的コンテンツ ルーティングに対する Content Engine のメトリック値の変更

Content Router を使用した負荷ベースのコンテンツ ルーティングの設定

Content Router の負荷ベースのルーティングのイネーブル化

負荷ベース ルーティングに対するContent Engine のスレッシュホールド制限の設定

Content Router の設定に関するトラブルシューティング

次の作業

ACNS ネットワークのコンテンツ要求ルーティング設定

Cisco ACNS 5.4 ソフトウェアは、要求を処理する 3 つの方式をサポートし、コンテンツをエンド ユーザに配信します。この章では、コンテンツ要求を処理する各方式について説明します。この章の構成は次のとおりです。

「WCCP 透過ルーティングの設定」

「直接プロキシ ルーティングの設定」

「Content Router またはルーティング Content Engine を使用したコンテンツ要求ルーティングの設定」

「Content Router の設定に関するトラブルシューティング」

「次の作業」


) この章で使用される CLI(コマンドライン インターフェイス)コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference』Release 5.4を参照してください。


図4-1 に、3 つの要求処理方式の設定に関する基本作業を示します。

図4-1 ルーティング方式の選択

 

WCCP 透過ルーティングの設定

この WCCP 透過ルーティング方式では、オリジン サーバへのコンテンツの要求は WCCP 対応ルータによって代行受信されます。WCCP 対応ルータは、要求されたコンテンツを保存している Content Engine に、その要求を透過的にリダイレクトします。このタイプの透過リダイレクトでは、ルータを通過するトラフィックの任意のポートでトラフィックを代行受信できます。WCCP に組み込まれているフェールセーフ メカニズムにより、要求の代行受信はエンド ユーザには透過的に行われます。

WCCP 対応ルータを使用するには、インターネットに接続されたインターフェイス上で IP アドレスを設定します。このインターフェイスは、Content Engine に接続されている必要があります。Content Engine と WCCP 対応ルータは、ファイアウォールで分離できません。ファイアウォールはオリジン Web サーバ向けのパケット トラフィックのみ処理し、サーバに代わって Content Engine によりクライアントに送信されるパケット トラフィックは処理しません。

Web キャッシュ サービス(WCCP バージョン 1 サービス)を実行するように設定できるルータは 1 つのみです。WCCP バージョン 1 を Content Engine で使用するには、指定のホーム ルータが Content Engine をポイントする必要があります。

ただし、WCCP バージョン 2 を使用すると、Content Engine クラスタと呼ばれる一連の Content Engine を複数のルータに接続することができます。この機能により、Content Engine を多数のインターフェイスに接続する場合に、インスタンスに対して冗長性とさらに分散されたアーキテクチャが提供されます。また、WCCP バージョン 2 はキャッシュ クラスタにおけるトラフィックの負荷を分散し、耐障害性とフェールセーフの動作を確保します。Content Engine がキャッシュ クラスタに追加されるか、キャッシュ クラスタから削除されると、WCCP 対応ルータまたはスイッチがそのリダイレクト マップを動的に調整して現在使用可能なキャッシュを反映させます。

Content Engine は WCCP バージョン 2 で動作している場合、リブート後にクリーン シャットダウンを実行して WCCP バージョン 1 をイネーブルにするか、WCCP バージョン 2 をディセーブルにします。クリーン シャットダウンを実行すると、TCP 接続の失敗が回避されます(WCCP クリーン シャットダウンの概要を参照)。

図4-2 に、WCCP 透過代行受信の方式を使用してコンテンツ要求をルーティングする方法を示します。

図4-2 WCCP を使用した要求代行受信

 

1. ユーザがブラウザから Web ページを要求します。

2. WCCP 対応ルータがその要求を代行受信し、TCP 宛先ポート番号に基づいてその要求を Content Engine に透過的にリダイレクトするかどうかを決定します。どの要求をリダイレクトするかを制御するために、アクセス リストが使用されます。

3. 要求されたコンテンツが Content Engine に保存されていない場合、Content Engine はオリジン サーバと別の TCP 接続を確立してコンテンツを取得します(図4-2 の 3a)。コンテンツが Content Engine に返され、保存されます(図4-2 の 3b)。

4. Content Engine がクライアントにコンテンツを送信します。それ以降に同じコンテンツに対する要求があると、Content Engine はローカル ストレージから透過的にその要求を処理します。

WCCP はまた非対称パケット フローも処理でき、WCCP サービス グループで使用されているルータ数(クラスタ内の最大 32 台の Content Engine と通信している最大 32 台のルータ)に関係なく、Web サーバと Content Engine との一貫性のあるマッピングを常に保持しています。

WCCP 対応ルータを透過モードでの要求ルーティング代行受信に対して使用すると、次のような利点があります。

エンド ユーザによる設定が不要 ― ユーザはブラウザに Content Engine をポイント先として指定する必要はありません。

フェールセーフ ― Content Engine は、自動的に耐障害性とフェールセーフ機能が設定されます。Content Engine の障害によりエンド ユーザに対してサービスが拒否されることはありません。

スケーラブル ― 複数の Content Engine を配置することによって、キャッシュ サービスを拡張できます。

自動バイパス ― エンド ユーザの認証が必要なサイト、または標準の HTTP に準拠していないサイトは、自動的に透過 Content Engine をバイパスします。

WCCP サービスの概要

WCCP はサービス グループの概念を使用して、クラスタ内の WCCP 対応ルータと WCCP 対応 Content Engine に対するキャッシング関連サービスを定義します。サービス グループは、サービス グループ番号により識別されます。WCCP サービス グループ番号ごとに、ルータ リスト、1 つのポート リスト(最大 8 つのポートを含む)、アプリケーション タイプ、ハッシュ パラメータ、パスワード、および重み付け(負荷分散用)を指定します。

表4-1 に、サービス グループ番号と、WCCP 対応ルータでサポートされるサービスを示します。

 

表4-1 WCCP サービス グループ

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

0

Web キャッシュ

60

FTP

70

HTTPS

80

HTTP、RTSP

81

MMST

82

MMSU

90 ~ 97

動的またはユーザ設定可能

98

カスタム

99

リバース プロキシ


表4-1 にリストされているすべてのサービス グループ番号に WCCP バージョン 2 が必要です。ただし、Web キャッシュ サービス(サービス グループ 0)を除きます。


WCCP 対応 Content Engine は、要求 URL のスタイルに応じたさまざまなインターネット プロトコルをサポートします。WCCP 対応 Content Engine がサーバ スタイルの URL を受信した場合は、HTTP プロトコルと RTSP プロトコルだけがサポートされます(RTSP ユーザ エージェント条件を満たしている場合)。WCCP 対応 Content Engine がプロキシ スタイルの URL を受信した場合は、HTTP、HTTPS、FTP(ファイル転送プロトコル)、およびRTSP プロトコルがサポートされます(概当するプロキシ サービスが Content Engine で設定されている場合)。プロキシ スタイルの要求 URL にはプロトコルとホスト名が含まれますが、サーバ スタイルの要求 URL には含まれません。RTSP プロトコルは、サーバ スタイルとプロキシ スタイルの両方の要求に対してサポートされます。

プロキシ スタイルの要求の場合、Content Engine は、FTP、HTTPS、HTTP、Microsoft Media Server(MMS)、RTSP の各プロキシ モードに対して、それぞれ最大 8 つの着信ポートをサポートします。着信プロキシ ポートは、透過モード サービスで使用されているポートと同じものにすることができます。着信プロキシ ポートは、Content Engine または Content Engine ファーム内の他の Content Engine 上で実行されている WCCP サービスを停止しなくても変更することができます。

Content Engine の WCCP実装では、現在、すべての WCCP サービスに適用されるグローバル設定(たとえば、ヒーリング パラメータ、スロー スタート)が可能です。複数サービス モデルではこの設定は変更されず、適用された設定値は WCCP システム全体でグローバルのままです(Content Engine の WCCP 一般設定を参照)。

動的 WCCP リダイレクト サービスの概要

1 台の Content Engine で最大 8 つのユーザ設定が可能なように、または動的 WCCP リダイレクト サービス(サービス グループ番号 90 ~ 97)を処理するように Content Engine を設定できます。ただし、これらのサービスがルータ上でも設定されている必要があります。

8 つの動的サービスでそれぞれ最大数の 8 つのポートを使用する場合、透過リダイレクションに指定できる最大ポート数は 64 です。図4-3 では、左側の 2 台の Content Engine は、ポート 80 を通る HTTP トラフィックだけを処理し、サービス グループ 90 のメンバーとして定義されています。右側の 2 台の Content Engine は、MMS 要求だけを処理し、サービス グループ 91 のメンバーとして定義されます。

図4-3 WCCP サービス グループの機能

 

HTTPS の WCCP サービスの概要

HTTPS トラフィックの WCCP サービス(サービス番号 70)は、対応するルータに、ポート 443 の TCP トラフィック(ポート 443 はデフォルト ポート)を代行受信し、それを Content Engine に転送するように指示します。このサービスには通常の WCCP サービスにはない特別なフィルタリング機能があります。この機能は、すべてのトラフィックを関連アプリケーションにリダイレクトするのではなく、受け入れリストを使用してトラフィックを選択してアプリケーションにリダイレクトします。受け入れリストとは、宛先 IP アドレスのリストです。クライアント要求内の宛先サーバの IP アドレスがこのリスト内の宛先 IP アドレスのいずれかと一致した場合、WCCP は HTTPS トラフィックを適切な待ち受けアプリケーションにリダイレクトします。その他すべてのトラフィックは、対応するルータにリダイレクトされます(通常のバイパス動作)。指定の送信元からのトラフィックが Content Engine をバイパスするようにバイパス リストで設定されている場合、トラフィックは代行受信されず、オリジン サーバに直接渡されます。アドレスが受け入れリストとバイパス リストの両方に存在する場合、Content Engine はトラフィックを WCCP 対応ルータまたはスイッチに戻し、あたかも Content Engine が存在しなかったかのようにパケットの転送をルータまたはスイッチに通知できます。

HTTPS フィルタリング機能を実行するには、Content Distribution Manager GUI の Accept all HTTPS traffic チェックボックス( Request Routing > WCCP > General Settings )にチェックマークを付けて、すべての HTTPS トラフィックを Content Engine で代行受信します。対応する宛先 HTTPS サーバが Content Engine で設定されている場合、Content Engine はクライアントと SSL 接続をネゴシエートし、HTTPS 要求を処理することができます。設定されていない場合は、HTTPS トラフィックは Content Engine 経由でトンネリングされます(Content Engine はクライアントからのトラフィックをフィルタリング以外は、変更をすることなくサーバに渡します)。SmartFilter ソフトウェアまたは Websense フィルタリング サーバが Content Engine でイネーブルになっている場合、Content Engine はトンネリングされる HTTPS トラフィックに対応する URL をフィルタリング サーバに送信します。フィルタリング サーバはトラフィックをブロックするか渡すかを決定します。トラフィックをブロックする必要がある場合、クライアントとの接続に最も近い Content Engine の提供は行われず、その要求は処理されません。

WCCP カスタム Web キャッシュ サービスの概要

カスタム Web キャッシュ サービス(サービス番号 98)により、Content Engine は WCCP バージョン 2 リダイレクト サービスをシスコ ルータのユーザが指定する番号のポートで自動的に確立します。その後、Content Engine はそのポート上のすべての HTTP 要求に対して透過 Web キャッシングを実行します。一方、ポート 80 の透過 Web キャッシングは中断せずに続行します。カスタム Web キャッシングでは、ルータでサービス 98 がイネーブルでなければなりません。WCCP バージョン 1 はカスタム Web キャッシングをサポートしません。

WCCP がイネーブルでない場合、または Web クライアントのブラウザでレガシー プロキシ サーバの使用が設定されていた場合は、ポート 80 以外のポート上の透過キャッシングは Content Engine により実行できます。

Content Engine の WCCP 一般設定

WCCP を使用するには、Content Engine を適切に設定する必要があります。Content Engine で WCCP 対応ルータを使用したエッジ代行受信を設定する際には、次の設定ガイドラインに従ってください。

Content Engine 上のソフトウェアのバージョンは、ルータ上にインストールされているバージョンと互換性がなければなりません。

Content Engine では、パケットを暗号化も圧縮もしてはなりません。また Network Address Translation ファイアウォールが存在する場合、Content Engine はそのファイアウォール内の一部でなければなりません。

Web キャッシュ リダイレクト対応のインターフェイスを超えて、サーバへのルート上に Content Engine を配置すると、IP ルート キャッシュにエントリが読み込まれません。

WCCP 対応ルータを使用するには、インターネットに接続されたルータのインターフェイス上で IP アドレスを設定します。このインターフェイスは、ネットワーク上の Content Engine が認識できなければなりません。


) ACNS 5.x ソフトウェアでは、現在、WCCP バージョン 2 の使用を推奨しています。ただし、WCCP バージョン 1 も引き続きサポートされています。


Content Engine で一般的な WCCP を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイス タイプがすべて一覧で表示されます。

ステップ 2 WCCP の一般設定を指定したい Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Request Routing > WCCP > General Settings の順に選択します。WCCP Configuration Settings for Content Engine ウィンドウが表示されます。 表4-2 では、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示しています。

ステップ 5 WCCP バージョン ドロップダウン リストから、Content Engine で使用する WCCP のバージョンを選択します。

Web コンテンツの透過キャッシングは、WCCP の両方のバージョンで可能です。WCCP バージョン 2 をイネーブルにする前に、WCCP バージョン 1 をディセーブルにする必要はありません。また、WCCP バージョン 1 をイネーブルにする前に、WCCP バージョン 2 をディセーブルにする必要もありません。WCCP 環境で使用されるルータは、Content Engine 上で設定済みの WCCP バージョンをサポートするソフトウェア バージョンを実行していることを確認してください。

ステップ 6 Home Router IP Address フィールドで、WCCP バージョン 1 ルータを設定する IP アドレスを指定します。WCCP バージョン 1 を Content Engine で使用するには、Content Engine に指定ホーム ルータをポイントさせます。これは IP デフォルト ゲートウェイのアドレスである可能性もあります。


) WCCP バージョン 1 がルータでイネーブルであることを確認してください。


ステップ 7 TCP フローへの影響や、Content Engine の起動または新しいトラフィックの再割り当ての際の Content Engine の過負荷を防ぐために、 Enable Flow Redirection チェックボックスにチェックマークを付けます。

この設定は WCCP バージョン 2 のみで有効です。この機能には、処理能力とそのデータ量に合わせて、Content Engine が管理できるようなスロー スタート設定にすることもできます。

ステップ 8 Content Engine が透過リダイレクトのプロセス中にオリジン Web サーバでの認証用にクライアントの IP アドレスを送信できるようにするには、 Spoofing Client IP チェックボックスにチェックマークを付けます。IP スプーフィングの詳細は、「クライアントの IP スプーフィングの概要」を参照してください。

ステップ 9 Content Engine 上でスロー スタート機能をイネーブルにするには、 Slow Start チェックボックスにチェックマークを付けます。WCCP スロー スタート機能の詳細は、「WCCP スロー スタートの概要」を参照してください。

ステップ 10 Shutdown Delay フィールドで、Content Engine が WCCP のクリーン シャットダウンを実行するまで待機する最大時間(秒数)を指定します。WCCP シャットダウンの遅延の詳細は、「WCCP クリーン シャットダウンの概要」を参照してください。

ステップ 11 デフォルトで Content Engine がすべての HTTPS トラフィックを受信できるようにするには、 Accept all HTTPS traffic チェックボックスにチェックマークを付けます。このチェックボックスにチェックマークを付けないと、Content Engine は HTTPS サーバが設定されている場合のみトラフィックを受信します。HTTPS トラフィックのキャッシングに対する WCCP サービスの詳細は、「HTTPS の WCCP サービスの概要」を参照してください。

ステップ 12 この設定値を保存するには、 Submit をクリックします。

 

表4-2 WCCP 一般設定

GUI パラメータ
機能
CLI コマンド

WCCP Version

WCCP バージョン 1 または 2 をイネーブルにします。

wccp version { 1 | 2 }

Home Router IP Address

WCCP バージョン 1 のルータを設定する IP アドレス。

wccp home-router ipaddress

Enable Flow Redirection

TCP フローを損なわれないようにします。

wccp flow-redirect enable

Spoofing Client IP

Content Engine が透過リダイレクションのプロセス中にオリジン Web サーバでの認証用にクライアントの IP アドレスを送信できるようにします。

wccp spoof-client-ip enable

Slow Start

スロー スタート機能をイネーブルにします。

wccp slow-start enable

Shutdown Delay

Content Engine が WCCP のクリーン シャットダウンを実行するまで待機する最大時間(秒数)。

wccp shutdown max-wait seconds

Accept all HTTPS traffic

Content Engine がデフォルトですべての HTTPS トラフィックを受信できるようにします。

wccp https-cache accept-all


 

クライアントの IP スプーフィングの概要

透過キャッシングでは、Content Engine がオリジン Web サーバと交信する際、要求を行うためにクライアントの IP アドレスではなく Content Engine 自体の IP アドレスを使用します。IP スプーフィングを使用すると、透過リダイレクト プロセスを通じて Content Engine はオリジン Web サーバでの認証用にクライアントの IP アドレスを送信できます。

Content Engine が IP スプーフィングを使用せずに通常の WCCP キャッシングを実行している場合、Content Engine 自体の IP アドレスを使用してオリジン サーバに接続します。ルータは要求内で Content Engine 自体の送信元 IP アドレスを使用した Content Engine からの要求を識別し、その要求を WAN に転送します。ルータは LAN 上のクライアントからの要求を Content Engine に転送します。

Content Engine は IP スプーフィングが設定されている場合、Content Engine 自体の IP アドレスではなくクライアントの IP アドレスを使用してオリジン サーバに接続します。この時点では、ルータは Content Engine からの要求を識別できません。これは、要求の送信元 IP アドレスが Content Engine のアドレスではないためです。Content Engine のこのような要求が未解決のまま Content Engine に戻されるのを防ぐには、Content Engine が接続している WCCP 対応ルータ インターフェイスに ip wccp redirect exclude in コマンドを適用する必要があります。

ip wccp redirect exclude in コマンドを使用すると、WCCP 対応ルータはこのインターフェイスに着信する要求を代行受信しません。クライアント要求を代行受信するには、クライアントと WAN に接続されているインターフェイスで ip wccp redirect out コマンドを設定する必要があります。

WCCP スロー スタートの概要

Content Engine のクラスタ内では、装置が追加または削除されると、TCP 接続が他の Content Engine にリダイレクトされます。Content Engine への新しいトラフィックの再割り当てが速すぎたり、Content Engine が突然ファット パイプに導入された場合、Content Engine が過負荷になることがあります。

WCCP スロー スタート機能は次のタスクを実行して、Content Engine がオンラインになったり、新しいトラフィックが割り当てられたりした場合に過負荷になるのを防ぎます。

WCCP 2 がイネーブルで Content Engine がクラスタ内に導入される場合の TCP フローの保護

WCCP 2 がディセーブルで Content Engine をクラスタ外に移動する場合の TCP フローの保護

ブート時 Content Engine に全負荷を割り当てず、徐々に増やしていく形での Content Engine への負荷割り当て

スロー スタートは次の場合のみ適用できます。

サーバ ファームに Content Engine がない場合の初期ブートアップ

全負荷を処理できないでいるクラスタに新規に Content Engine が追加される場合(たとえば、クラスタから削除されるバケットがある場合)

上記以外の場合は、スロー スタートは必要ありません。Content Engine ではただちにトラフィックが割り当てられます。

WCCP クリーン シャットダウンの概要

TCP 接続の中断を防ぐために、Content Engine はリロード後または WCCP バージョンの変更後にクリーン シャットダウンを実行します。すべての接続の処理が完了するか、設定されている最大待機時間が経過するまで、Content Engine はリブートしません。

クリーン シャットダウン時、Content Engine は処理中のフローを引き続き処理しますが、新しいフローのバイパスを開始します。フロー数がゼロになると、主要の Content Engine がその Content Engine のバケットを他の Content Engine に割り当てることにより、その Content Engine はクラスタから離脱します。Content Engine が故障したり、WCCP のクリーン シャットダウンを実行せずにリブートすると、TCP 接続が損なわれる可能性があります。クリーン シャットダウンは、シャットダウン中に中断することが可能です。

Content Engine の WCCP のサービス設定

WCCP サービスを設定するには、4 種類の値を設定する必要があります。

WCCP サービス

動的サービスの設定

負荷分散のハッシュ

その他の設定

Content Engine の WCCP サービスを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧で表示されます。

ステップ 2 WCCP のサービスを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Request Routing > WCCP > Services の順に選択します。WCCP Service Settings for Content Engine ウィンドウが表示されます。


) このウィンドウには、WCCP General Settings ウィンドウで選択した内容に応じて、Content Engine の設定または関連デバイス グループの設定が表示されます。


ステップ 4 タスクバーの Create New WCCP Service Setting アイコンをクリックして、新規サービスの作成、ルータ リストの設定、WCCP バージョン 2 の動的サービスとポートの関連付けを行います。Creating New WCCP Service ウィンドウが表示されます。

最大 17 個のサービスを設定できます。17 個のサービスがすでに定義されている場合は、タスクバーにこのアイコンは表示されません。


) 特定の WCCP サービスの設定値は、そのサービスがルータ リストに関連付けられている場合のみ設定できます。


ステップ 5 WCCP Service セクションで、次の手順を実行します。

a. Service Type ドロップダウン リストから、WCCP サービス タイプを選択します(サービス タイプの説明については、 表4-3 を参照)。

 

表4-3 WCCP サービス タイプ

サービス タイプ
サービスの説明
CLI コマンド

DNS

WCCP 対応ルータが DNS パケットを代行受信し、ブーメラン サーバにリダイレクトできるようにします。その後、ブーメラン サーバが代行受信されたパケットを受け入れて処理し、パケットを要求ストリームに再挿入します。

wccp dns

FTP Native

WCCP バージョン 2 を使用した FTP トラフィックの透過代行受信を可能にします。

wccp ftp-native

HTTPS

HTTPS サーバとして設定されている Content Engine への WCCP フローのリダイレクトを可能にします。

wccp https

RTSP

WCCP バージョン 2 の Real-Time Streaming Protocol(RTSP)の透過代行受信を設定します。

wccp rtsp

Windows Media

WCCP バージョン 2 の Windows Media キャッシング サービスをイネーブルにします。

wccp wmt

Windows Media RTSPU

Windows Media RTSPU(ポート 5005)の透過代行受信をイネーブルにします。

wccp wmt-rtspu

Reverse Proxy

WCCP バージョン 2 のリバース プロキシ サービスをイネーブルにします。WCCP リバース プロキシがイネーブルの場合、ルータは送信元 IP アドレス(クライアントのブラウザ IP アドレスなど)に基づいてクラスタ内で負荷分散を行います。

wccp reverse-proxy

WebCache

WCCP バージョン 2 での Web キャッシュ サービスをイネーブルにします。ルータは Web キャッシュ サービスを使用して、宛先 IP アドレス(Web サーバの IP アドレスなど)に基づいて Content Engine クラスタ内でトラフィックの負荷を分散します。

wccp web-cache

Custom WebCache

Content Engine が 80 以外のポート上でリダイレクトされた HTTP トラフィックを受信できるようにします。

wccp custom-web-cache

Dynamic Service Number(90~97)

Content Engine で最大 8 つの動的 WCCP リダイレクト サービスを可能にします。

wccp service-number

b. Router List のドロップダウン リストから 1 つを選択し、WCCP サービスとルータ リストを対応させます。

設定されているルータ リストのみドロップダウン リストに表示されます。ルータ リストは New WCCP Service ウィンドウのリンクから設定、変更、または表示できます。ルータ リストの詳細については、以下を参照してください。

「WCCP ルータ リストの作成」

「Content Engine の WCCP ルータ リストの変更」

「Content Engine の WCCP ルータ リストの表示」

ステップ 6 Dynamic Service Settings セクションで、次の手順を実行します。このセクションにある設定値は、動的 Web キャッシュ サービスにのみ設定できます。

a. Port List ドロップダウン リストから、ポートを特定の WCCP バージョン 2 の動的サービスと関連付けるポート リスト番号を選択します。設定されているポート リストがすべて表示されます。ポートはユーザ設定可能な Web キャッシュ サービス(90~97)にのみ関連付けることができます。その他のサービスでは、Port List ドロップダウン リストは使用できません。

b. WCCP バージョン 2 動的サービスのポート リストを設定する場合、またはポート リストがない場合は、 New Port List ボタンをクリックします。WCCP Port List Settings ウィンドウが表示されます。ポート リストの作成に関する詳細は、「Content Engine の WCCP ポート リストの設定」を参照してください。

c. ポート番号を設定されているポート リストに追加または削除するには、 Edit Port List ボタンをクリックします。ポート リストの変更に関する詳細は、「Content Engine の WCCP ポート リストの変更」を参照してください。

d. Application ドロップダウン リストから、代行受信されたトラフィックがリダイレクトされる Content Engine で動作するアプリケーションを選択します。ドロップダウン リストのオプションについては、 表4-4 を参照してください。

 

表4-4 アプリケーションのオプション

オプション
説明

cache

トラフィックを Content Engine で動作するキャッシング アプリケーションにリダイレクトします。

https-cache

トラフィックを Content Engine で動作する HTTPS キャッシング アプリケーションにリダイレクトします。

streaming

トラフィックを Content Engine で動作するストリーミング メディア アプリケーションにリダイレクトします。

e. トラフィックのリダイレクトのために送信元ポートを照合するには、 Match Source Port チェックボックスにチェックマークを付けます。

ステップ 7 Load Balancing Hash セクションで、次の手順を実行します。負荷分散のハッシュ割り当て方式は、FTP、リバース プロキシ、および WCCP バージョン 2 の Web キャッシュ サービスに対しては定義できません(負荷分散の概要を参照)。

a. 宛先 IP アドレスの負荷分散ハッシュを定義するには、 Destination IP チェックボックスにチェックマークを付けます。このハッシュ割り当て方式は、次の WCCP バージョン 2 サービスでデフォルトです。

RTSP

Windows Media

Windows Media RTSPU

カスタム Web キャッシュ

動的サービス

b. 送信元 IP アドレスの負荷分散ハッシュを定義するには、 Source IP チェックボックスにチェックマークを付けます。このハッシュ割り当て方式は、HTTPS キャッシュ サービスでデフォルトです。

c. 宛先ポートの負荷分散ハッシュを定義するには、 Destination Port チェックボックスにチェックマークを付けます。

d. 送信元ポートの負荷分散ハッシュを定義するには、 Source Port チェックボックスにチェックマークを付けます。このハッシュ割り当て方式は、DNS サービスでデフォルトです。

ステップ 8 Other Settings セクションで、次の手順を実行します。

a. WCCP で設定した割り当て方式だけ使用するには、 Use Selected Assignment Method チェックボックスにチェックマークを付けます。この設定は、DNS、FTP ネイティブ、HTTPS キャッシュ、リバース プロキシ、カスタム Web キャッシュ、Web キャッシュ、および Windows Media サービスの場合にのみ設定できます。適用する場合、ハッシュ割り当てとマスク割り当ての 2 つの負荷分散方式のいずれかを使用できます。

b. Content Engine に WCCP バージョン 2 対応のスイッチまたはルータとのレイヤ 2 接続があり、そのデバイスにレイヤ 2 リダイレクトが設定されている場合に、Content Engine でそのデバイスから透過的にリダイレクトされたトラフィックを受信できるようにするには、 Layer2 Redirection チェックボックスにチェックマークを付けます。

c. Password フィールドで、クラスタ内の Content Engine と指定されたサービスのルータ間でのトラフィック保護に使用するパスワードを指定します。クラスタ内の他の Content Engine とルータを同じパスワードを使用してイネーブルにしてください。

パスワードは最大 8 文字です。Confirm Password フィールドに、同じパスワードをもう一度入力します。

d. Weight フィールドで、Content Engine にリダイレクトされる総負荷に対するパーセンテージを示す重み付けパラメータを指定します(たとえば、30 の重みの Content Engine は総負荷の 30% を受信します)。Content Engine クラスタ内の重み付けパラメータの合計が 100 を超えると、各 Content Engine の負荷のパーセンテージはその重み付けパラメータが示す総合計に対するパーセンテージとして再計算されます。

e. Port フィールドで、リダイレクトされた HTTP トラフィックを受け入れる 80 以外のポート番号を指定します(カスタム Web キャッシュ サービスにのみ設定可能)(WCCP カスタム Web キャッシュ サービスの概要を参照)。

ステップ 9 Content Engine の割り当てにマスク方式を使用するには、 Use Mask Assignment チェックボックスにチェックマークを付けます。

ステップ 10 WCCP サービス マスクを新規に作成するには、 Create Mask ボタンをクリックします。サービス マスクの作成に関する詳細は、「Content Engine の WCCP サービス マスクの設定」を参照してください。

ステップ 11 設定されているサービス マスクを変更または削除するには、 Edit Mask ボタンをクリックします。サービス マスクの変更に関する詳細は、「Content Engine の WCCP サービス マスクの変更」を参照してください。

ステップ 12 設定されているサービス マスクをすべて表示するには、 View Masks Configured for All Services ボタンをクリックします。サービス マスクの表示に関する詳細は、「Content Engine の WCCP サービス マスクの表示」を参照してください。


 

負荷分散の概要

WCCP バージョン 2 には各 Content Engine にかかる負荷を調整する機能があり、使用可能なリソースを効率的に使用できると同時に、クライアントに高品質のサービスを提供できます。負荷分散により、Content Engine に割り当てられているハッシュ バケットを調整して、過負荷状態の Content Engine から容量に余裕のある他の Content Engine に負荷を移動することができます。

ハッシュ割り当て方式では、ハッシュ パラメータにより異なるサービス グループ間でトラフィックを負荷分散する方法を指定します。特に、ハッシュは1つの項目セットから他の項目セットに項目をマップします。たとえば、宛先 IP アドレスまたは宛先ポートを WCCP 対応ルータのサービス グループ内の各 Content Engine にマップして負荷分散を行うのと同じです。負荷分散方式は、Content Engine ファームごとに 1 つだけ使用できます。

WCCP ルータ リストの作成

WCCP バージョン 2 サービスで使用する場合、ルータ リストは 8 種類まで作成できます。また、リストごとに最大 32 の IP アドレスを追加できます。たとえば、WCCP バージョン 2 の Web キャッシュ サービスにルータ リストを指定し、同時にルータまたは Content Engine のグループを再設定せずにリバース プロキシに別のルータ リストを指定できます。ルータ リストは、少なくとも 1 つの IP アドレスを含む必要があります。

WCCP ルータ リストを作成する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウへ移動します(Content Engine の WCCP のサービス設定を参照)。

ステップ 2 WCCP バージョン 2 用のルータ リストを新規に作成するには、 New Router List ボタンをクリックします。Creating New WCCP Router ウィンドウが表示されます。

ステップ 3 Router IP Address フィールドで、リストに追加するルータの IP アドレスを指定します。少なくとも 1 つの IP アドレスを入力する必要があります。適切に指定しないと、送信時にエラー メッセージが表示されます。

追加される IP アドレスは、ルータ リスト内で一意でなければなりません。適切に指定しないと、送信時にエラー メッセージが表示されます。

ステップ 4 Add をクリックして、IP アドレスをリストに追加します。このリストには特定のサービスの場合に、この Content Engine にトラフィックをリダイレクトするすべてのルータの IP アドレスが示されています。異なるルータが異なるサービスに使用される場合は、複数のルータ リストを作成する必要があります。

ウィンドウの内容が更新され、アドレスが番号順に表示されます。この順序は、IP アドレスを入力した順序とは異なる場合があります。IP アドレスは設定が保存されるまでレッドで表示されます。

ステップ 5 Submit をクリックして、ルータ リストまたはルータ IP アドレスの変更内容を保存します。WCCP Service ウィンドウに戻ります。


 

Content Engine の WCCP ルータ リストの変更

ルータ リストへの IP アドレスの追加や削除、またはルータ リスト自体の削除手順は、次のとおりです。


ステップ 1 Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウで、List Number ドロップダウン リストからルータ リスト番号を選択します。

ステップ 2 Edit Router List ボタンをクリックします。Modifying WCCP Router List ウィンドウが表示されます。

ステップ 3 ルータをルータ リストに追加するには、Router IP Address フィールドにルータの IP アドレスを入力して Add ボタンをクリックします。

ステップ 4 ルータの IP アドレスを変更するには、変更する IP アドレスの横にある Edit IP Address アイコンをクリックします。IP アドレスが Router IP Address フィールドに表示されます。IP アドレスを変更したら、Edit ボタンをクリックして変更した IP アドレスをリストに追加します。ウィンドウの内容が更新され、変更した IP アドレスは設定が保存されるまでパープルで表示されます。


) Router IP Address フィールドの横には Edit ボタンまたは Add ボタンが表示されます。Add ボタンの場合は、新規 IP アドレスをリストに追加できます。Edit ボタンと Add ボタンは切り替わります。


ステップ 5 この設定値を保存するには、 Submit をクリックします。ウィンドウの内容が更新され、設定が保存されます。

ステップ 6 ルータ リストから IP アドレスを削除する手順は、次のとおりです。

a. 表示されている IP アドレスの横にある Delete IP Address アイコンをクリックします。ウィンドウの内容が更新され、削除した IP アドレスは設定が保存されるまで取り消し線付きのレッドで表示されます。

b. この設定値を保存するには、 Submit をクリックします。ウィンドウの内容が更新され、削除した IP アドレスが表示されなくなります。

ステップ 7 ルータ リストを削除する手順は、次のとおりです。

a. Modifying WCCP Router ウィンドウで、タスクバーから Delete Router List アイコンをクリックします。ルータ リストの設定を完全に削除するかどうかを確認するダイアログ ボックスが表示されます。


) ルータ リストを削除すると、このルータ リストを使用するように設定されていた
WCCP バージョン 2 サービスも削除されます。設定されているルータ リストを削除する前に、必要に応じて、WCCP サービスが別のルータ リストに関連付けられているか確認してください。


b. 内容を確認したら、 OK をクリックします。選択されたルータ リストと関連付けられていたサービスが削除されます。


 

Content Engine の WCCP ルータ リストの表示

WCCP バージョン 2 の動的サービス用に設定されているルータ リストをすべて表示する手順は、次のとおりです。


ステップ 1 WCCP バージョン 2 の動的サービス用に設定されているルータ リストをすべて表示するには、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウから View All Router List ボタンをクリックします。WCCP Router List Configurations for Content Engine ウィンドウが表示されます。

List Number カラムに、設定されているルータ リスト番号がすべて表示されます。Router IP Addresses カラムに、ルータ リストに追加された IP アドレスが表示されます。このウィンドウから、次の作業を行えます。

前のウィンドウに戻る。

既存のルータ リストを編集する。

ルータ リストを新規作成する。

ステップ 2 Creating New WCCP Service ウィンドウに戻るには、Content Distribution Manager GUI タスクバーから Back (矢印アイコン)をクリックします。

ステップ 3 このウィンドウで新規ルータ リストを設定し、IP アドレスを追加するには、タスクバーから Create New WCCP Router List Configuration アイコンをクリックします。Creating New WCCP Router List ウィンドウが表示されます。

ステップ 4 既存のルータ リストを編集するには、編集するルータ リストの横にある Edit WCCP Router List Configuration アイコンをクリックします。Modifying WCCP Router ウィンドウが表示されます。IP アドレスの追加、更新、または削除を行うことができます。


 

デバイス グループ内の Content Engine への一意のルータ リストの割り当て

デバイス グループに、異なる支店のロケーションにあるデバイスが含まれている場合、そのデバイスは同一のルータ リストを共有できません。ACNS 5.4 ソフトウェアでは、Content Distribution Manager GUI Device Groups の設定エリアにある 1 つのウィンドウから、デバイス グループ内のすべてのデバイスのルータ リストを作成できます。一意のルータ リストをデバイス グループ内の Content Engine に割り当てる作業を 1 つのウィンドウで実行できるため、異なるロケーションのデバイスに対するルータ リストを設定するために複数のウィンドウを起動したりする必要がなくなります。

デバイス グループのデバイスに対するルータ リストで作業する場合、次の手順に従います。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。

ステップ 2 作業するデバイス グループの横にある Edit アイコンをクリックします。

ステップ 3 Contents ペイン内で、 Request Processing > WCCP > Services の順に選択します。Modifying WCCP Service ウィンドウが表示されます。

ステップ 4 特定のデバイスに対するルータ リストを編集するには、Modifying WCCP Router List ウィンドウに移動します。

View All Router Lists ボタンをクリックしたあと、ルータ リストの Edit アイコンをクリックします。

または、ドロップダウン メニューからルータ リスト番号を選択し、 Edit Router List ボタンをクリックします。

Modifying WCCP Router List ウィンドウが表示されます(図4-4 を参照)。

図4-4 Modifying WCCP Router List ウィンドウ

 

ステップ 5 Device Specific Router Lists の項目の下で、一意のルータ リストを割り当てる Content Engine 名の横の Edit アイコンをクリックします。Creating new Router List for Device ウィンドウが表示されます。


) 適切な Device Specific Router Lists セクションを表示するには、正しいデバイス グループに対する Modifying WCCP Router List ウィンドウにいる必要があります。


ステップ 6 デバイスのルータ リストからルータを追加または削除するには、Add Router フィールドに IP アドレスを入力し、 Add Router ボタンまたは Remove Router ボタンをクリックします。

ステップ 7 この設定値を保存するには、 Submit をクリックします。


 

Content Engine の WCCP ポート リストの設定

最大 8 つのポートをそれぞれ使用している 8 つのカスタム サービスでは、透過リダイレクトに指定できるポートの最大数は 64 です。

レガシー カスタム Web キャッシュとリバース プロキシ サービス(サービス番号 98 と 99)では、それぞれ 1 つのポートのみ設定できます。レガシー サービスを 1 つだけ設定すると、透過リダイレクト ポートの合計の最大数は 57 となります。レガシー サービスを 2 つ設定すると、合計の最大ポート数は 50 となります。

HTTP を受信するすべてのポートは同じ WCCP サービスのメンバーとして設定され、次の特性を共有します。

Creating New WCCP Service ウィンドウを使用して設定したものと同じハッシュまたはマスク パラメータを持ちます。

個々のポート上のサービスは、個別に停止または開始できません(WCCP バージョン 2 の制約事項)。

ファーム内の Content Engine では、次の制約事項が適用されます。

同じ WCCP サービスを使用するすべての Content Engine には、同じポート リストと同じハッシュまたはマスク パラメータを設定する必要があります。

同じ WCCP サービスを使用するファームに加わろうとする Content Engine が、異なるポート リストあるいは異なるハッシュまたは異なるマスク パラメータを使用している場合、その Content Engine はルータによって拒否されます。

特定の WCCP サービス用のポート リストを変更するには、関係しているすべての Content Engine 上で WCCP サービスを停止し、すべて新しいパラメータを指定して再開する必要があります。

Content Engine の WCCP ポート リストを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧で表示されます。

ステップ 2 WCCP ポート リストを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Request Routing > WCCP > Services の順に選択します。WCCP Service Settings for Content Engine ウィンドウが表示されます。

ステップ 5 タスクバーから Create New WCCP Service Setting アイコンをクリックして、新規サービス用のルータ リストを設定します。Creating New WCCP Service ウィンドウが表示されます。

または、ルータ リストを設定する既存の WCCP サービスの横にある Edit WCCP Service Setting アイコンをクリックします。Modifying WCCP Service ウィンドウが表示されます。

ステップ 6 WCCP Service セクションで、Service Type ドロップダウン リストから WCCP 動的リダイレクト サービスを選択します。

ステップ 7 Dynamic Service Settings セクションで、 New Port List ボタンをクリックして、WCCP バージョン 2 動的サービスにポートを関連付けるためのポート リスト番号を設定します。WCCP Port List Settings ウィンドウが表示されます。

ステップ 8 ポート リストに対する Ports カラムで、リストに追加するポート番号を指定します。各リストには最大 8 つのポート番号を設定できます。

追加された各ポート番号は、設定されているすべてのポート リストで一意でなければなりません。適切に指定しないと、送信時にエラー メッセージが表示されます。

ポート リストでは、Ports カラムにある一連のフィールドにポート番号を必ずしも間を空けずに入力する必要はありません。フィールド間にある空白のフィールドは送信時に削除され、次回ウィンドウを表示する際には、追加されたすべてのポート番号が並べ替えられ、昇順で表示されます。

ステップ 9 この設定値を保存するには、 Submit をクリックします。以前に表示していたウィンドウに応じて、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウが表示されます。


 

Content Engine の WCCP ポート リストの変更

ポート リストを変更する手順は、次のとおりです。


ステップ 1 Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウから、 Edit Port List ボタンをクリックして、WCCP バージョン 2 動的サービス用のポート リストを設定します。WCCP Port List Settings ウィンドウが表示されます。

ステップ 2 ポート リストのポート番号を変更する手順は、次のとおりです。

a. ポート リスト番号を選択し、その行の Ports カラムで変更するポート番号を編集します。

b. この設定値を保存するには、 Submit をクリックします。表示していたウィンドウに応じて、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウが表示されます。

ステップ 3 ポート リストを削除する手順は、次のとおりです。

a. 削除するポート リストの横にある Clear List チェックボックスにチェックマークを付けます。追加されたポート番号はポート リストから削除されます。

b. この設定値を保存するには、 Submit をクリックします。以前に表示していたウィンドウに応じて、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウが表示されます。


 

Content Engine の WCCP サービス マスクの設定

最大 16 個の WCCP サービス マスクを設定できます。FTP サービスの場合、IP マスクのみ設定可能なため、ポート マスクのフィールドは入力不可となります。

ビット マスクは 16 進数で指定します。指定されているビット マスク全体で 8 ビット以上を指定することはできません。たとえば、3 つのマスクを適切に使用する場合は、0xF(4 ビット)、0x1(1 ビット)、0x3(2 ビット)の合計 7 ビットとなります。この場合、0x0 以外の追加マスクを設定することはできません。設定すると、エラー メッセージが表示されます。

4 つのマスクを使用する場合は、0xA(2 ビット)、0x7(3 ビット)、0x8(1 ビット)、0x1(1 ビット)の合計 7 ビットなどとなります。

Content Engine に設定されている WCCP サービス用の WCCP サービス マスクを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧で表示されます。

ステップ 2 WCCP サービス マスクを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペイン内で、 Request Routing > WCCP > Services の順に選択します。WCCP Service Settings for Content Engine ウィンドウが表示されます。

ステップ 5 タスクバーから Create New WCCP Service Setting アイコンをクリックして、新規サービス用のルータ リストを設定します。Creating New WCCP Service ウィンドウが表示されます。

または、ルータ リストを設定する既存の WCCP サービスの横にある Edit WCCP Service Setting アイコンをクリックします。Modifying WCCP Service ウィンドウが表示されます。

ステップ 6 WCCP Service セクションで、Service Type ドロップダウン リストから WCCP サービスを選択します。

ステップ 7 Other Settings セクションで、Use Mask Assignment チェックボックスの横にある Create Mask ボタンをクリックして、サービス マスクを設定し、それを WCCP バージョン 2 サービスに関連付けます。Creating New WCCP Service Mask ウィンドウが表示されます。

ステップ 8 Service Type ドロップダウン リストから、WCCP サービス タイプを選択します。 表4-5 に、これらのサービス タイプについての説明を示します。

 

表4-5 WCCP サービス タイプ

サービス タイプ
説明

DNS

WCCP 対応ルータが DNS パケットを代行受信し、ブーメラン サーバにリダイレクトできるようにします。その後、ブーメラン サーバが代行受信されたパケットを受け入れて処理し、パケットを要求ストリームに再挿入します。

FTP Native

WCCP バージョン 2 を使用した FTP トラフィックの透過代行受信を可能にします。

HTTPS

HTTPS サーバとして設定されている Content Engine への WCCP フローのリダイレクトを可能にします。

RTSP

WCCP バージョン 2 の Real-Time Streaming Protocol(RTSP)の透過代行受信を設定します。

Windows Media

WCCP バージョン 2 の Windows Media キャッシング サービスをイネーブルにします。

Windows Media RTSPU

Windows Media RTSPU(ポート 5005)の透過代行受信をイネーブルにします。

Reverse Proxy

WCCP バージョン 2 リバース プロキシ サービスをイネーブルにします。WCCP リバース プロキシがイネーブルの場合、ルータは送信元 IP アドレス(クライアントのブラウザ IP アドレスなど)に基づいてクラスタ内で負荷分散を行います。

Web cache

WCCP バージョン 2 での Web キャッシュ サービスをイネーブルにします。ルータは Web キャッシュ サービスを使用して、宛先 IP アドレス(Web サーバの IP アドレスなど)に基づいて Content Engine クラスタ内でトラフィックの負荷を分散します。

Custom web cache

Content Engine が 80 以外のポート上でリダイレクトされた HTTP トラフィックを受信できるようにします。

Dynamic Service Number(90~97)

Content Engine で最大 8 つの動的 WCCP リダイレクト サービスをイネーブルにします。

ステップ 9 Source IP Mask フィールドで、パケットの送信元 IP アドレスとの照合に使用する 16 進数の IP アドレス マスク(0xFE000000 など)を指定します。範囲は 0x00000000 ~ 0xFE000000 です。デフォルトは 0x00000000 です。

ステップ 10 Source Port Mask フィールドで、パケットの送信元ポート番号との照合に使用する 16 進数のポート マスク(0xFE00 など)を指定します。ポート マスクの範囲は、0x00 ~ 0xFE です。デフォルトは 0x0 です。

ステップ 11 Destination IP Mask フィールドで、パケットの宛先 IP アドレスとの照合に使用する 16 進数の IP アドレス マスク(0xFE000000 など)を指定します。範囲は 0x00000000 ~ 0xFE000000 です。デフォルトは 0x00001741 です。

ステップ 12 Destination Port Mask フィールドで、パケットの宛先ポート番号との照合に使用する 16 進数のポート マスク(0xFE00 など)を指定します。ポート マスクの範囲は、0x00 ~ 0xFE です。デフォルトは 0x0 です。

ステップ 13 この設定値を保存するには、 Submit をクリックします。以前に表示していたウィンドウに応じて、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウが表示されます。


 

Content Engine の WCCP サービス マスクの変更

Content Engine に設定されている WCCP サービスのサービス マスクを変更する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧で表示されます。

ステップ 2 WCCP サービス マスクを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペイン内で、 Request Routing > WCCP > Services の順に選択します。WCCP Service Settings for Content Engine ウィンドウが表示されます。

ステップ 5 タスクバーから Create New WCCP Service Setting アイコンをクリックして、新規サービス用のルータ リストを設定します。Creating New WCCP Service ウィンドウが表示されます。

または、ルータ リストを設定する既存の WCCP サービスの横にある Edit WCCP Service Setting アイコンをクリックします。Modifying WCCP Service ウィンドウが表示されます。

ステップ 6 WCCP Service セクションで、Service Type ドロップダウン リストから WCCP サービスを選択します

ステップ 7 Other Settings セクションで、Use Mask Assignment チェックボックスの横にある Edit Mask ボタンをクリックして、サービス マスクを変更し、それを WCCP バージョン 2 サービスに関連付けます。Modifying WCCP Service Mask ウィンドウが表示されます。

サービス マスクがすでに WCCP サービス用に設定されている場合は、Edit Mask ボタンは Create Mask ボタンに切り替わります。

ステップ 8 Service Type ドロップダウン リストから、WCCP サービス タイプを選択します。サービス タイプの説明については、 表4-5 を参照してください。

ステップ 9 Source IP Mask フィールドで、パケットの送信元 IP アドレスとの照合に使用する 16 進数の IP アドレス マスク(0xFE000000 など)を指定します。範囲は 0x00000000 ~ 0xFE000000 です。デフォルトは 0x00000000 です。

ステップ 10 Source Port Mask フィールドで、パケットの送信元ポート番号との照合に使用する 16 進数のポート マスク(0xFE00 など)を指定します。ポート マスクの範囲は、0x00 ~ 0xFE です。デフォルトは 0x0 です。

ステップ 11 Destination IP Mask フィールドで、パケットの宛先 IP アドレスとの照合に使用する 16 進数の IP アドレス マスク(0xFE000000 など)を指定します。範囲は 0x00000000 ~ 0xFE000000 です。デフォルトは 0x00001741 です。

ステップ 12 Destination Port Mask フィールドで、パケットの宛先ポート番号との照合に使用する 16 進数のポート マスク(0xFC00 など)を指定します。ポート マスクの範囲は、0x0 ~ 0xFE です。デフォルトは 0x0 です。

ステップ 13 この設定値を保存するには、 Submit をクリックします。以前に表示していたウィンドウに応じて、Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウが表示されます。


 

サービス マスクを削除する手順は、次のとおりです。


ステップ 1 WCCP Service Mask Settings for Content Engine ウィンドウから、マスク設定を変更する既存の WCCP サービス マスクの横にある Edit WCCP Service Mask Setting アイコンをクリックします。Modifying WCCP Service Mask ウィンドウが表示されます。

ステップ 2 タスクバーから Delete WCCP Service Mask アイコンをクリックします。サービス マスクの設定を完全に削除するかどうかを確認するダイアログ ボックスが表示されます。

ステップ 3 OK をクリックして実行します。WCCP Service Mask Settings for Content Engine ウィンドウが表示されます。


 

Content Engine の WCCP サービス マスクの表示

WCCP サービス用に設定されているマスクをすべて表示する手順は、次のとおりです。


ステップ 1 Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウから、 View Masks Configured for All Services ボタンをクリックして、設定されている WCCP サービス用サービス マスクをすべて表示します。WCCP Service Mask Settings for Content Engine ウィンドウが表示されます。パケットの送信元 IP アドレス、送信元ポート番号、宛先 IP アドレス、または宛先ポート番号との照合のためにマスクが設定されたすべてのサービスが表示されます。

ステップ 2 Creating New WCCP Service ウィンドウまたは Modifying WCCP Service ウィンドウに戻るには、タスクバーから Back (左矢印)アイコンをクリックします。

ステップ 3 新規サービス マスクを設定するには、タスクバーから Create New WCCP Service Mask Setting アイコンをクリックします。Creating New WCCP Service Mask ウィンドウが表示されます。

あるいは、マスク設定を変更する既存の WCCP サービス マスクの横にある Edit WCCP Service Mask Setting アイコンをクリックします。Modifying WCCP Service Mask ウィンドウが表示されます。


 

WCCP 透過ルーティング バイパス オプションの設定

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

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

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

図4-5 過負荷バイパス

 

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

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

認証トラフィックのバイパス設定

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


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


WCCP バイパスの設定

WCCP バイパスを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。Device Group ウィンドウが表示されます(または、 Devices > Devices の順に選択します)。

ステップ 2 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Request Routing > WCCP > Bypass の順に選択します。WCCP Bypass Settings ウィンドウが表示されます(図4-6 を参照)。 表4-7 では、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

図4-6 WCCP Bypass Settings ウィンドウ

 

ステップ 5 Content Engine がクライアントから着信する要求をバイパスできるようにするには、 Bypass Enable チェックボックスにチェックマークを付けます。

ステップ 6 認証バイパスをイネーブルにするには、 Authentication Bypass チェックボックスにチェックマークを付けます。


) IP 認証上の理由から、一部の Web サイトでは、Content Engine がクライアントの代理として直接接続することを許可していません。キャッシュの透過性を保ち、サービスの中断を防ぐために、Content Engine は認証トラフィックのバイパス機能により、選択されたクライアント/サーバのペアに対して、ダイナミック アクセス リストを自動的に生成します。認証バイパス トリガーは、ACNS ネットワーク環境のアップストリームとダウンストリームにも伝播されます。


ステップ 7 Bypass Gateway フィールドで、Content Engine がバイパスされたパケットを設定されたリダイレクト スイッチにレイヤ 2 リダイレクトによって戻すために、バイパス ゲートウェイの IP アドレスを指定します。バイパス ゲートウェイが設定されていない場合、バイパス パケットはパケットを送信した送信元の MAC アドレスに転送されます。

ステップ 8 Bypass entry expiration time フィールドに、アイドル状態のクライアント/サーバのペアをバイパス アクセス リストに置いておく時間(分単位)を入力します。デフォルト値は 20 分です。

ステップ 9 Error Handling ドロップダウン リストから、エラーを処理する方法を transparent reset-connection send-cache-error から選択します( 表4-6 を参照)。

 

表4-6 エラー処理のオプション

オプション
説明

Transparent

Content Engine はクライアントにエラーを送信しませんが、サーバへのクライアント接続をバイパスします。

Send-cache-error

Content Engine は、クライアントにエラー ページを送信します。

Reset-connection

Content Engine はエラーを指定せずに、TCP 接続をリセットします。

ステップ 10 トラフィックのバイパスをイネーブルにするには、 Load Bypass Enable チェックボックスにチェックマークを付けます。

ステップ 11 Interval between bypassing buckets フィールドに、あるバケットをバイパスしてから次のバケットをバイパスするまでの時間を秒単位で指定します。デフォルト値は 4 秒です

Content Engine に過大なトラフィックが発生したときに、バイパス オプションがイネーブルになっていると、Content Engine は過負荷状態が解消されるまでトラフィックを一度に 1 バケットずつバイパスします。


) バケットは、Content Engine ファーム内の各 Content Engine に割り当てられたハッシュのサブセクションとして指定されます。この環境に Content Engine が 1 台だけ存在する場合は、256 のバケットが Content Engine に割り当てられます。


ステップ 12 Time that a bucket is bypassed フィールドに、Content Engine をバイパス モードのままにして、バイパスされた負荷を受け入れない時間(分単位)を入力します。デフォルトは 10 分です。

ステップ 13 Time interval between buckets coming back フィールドに、各バケットを受け入れる間隔を入力します。デフォルト値は 2 秒です

バイパス モードに割り当てられた時間間隔が過ぎると、Content Engine はバイパスされたトラフィックの受け入れを一度に 1 バケットずつ開始します。

ステップ 14 この設定値を保存するには、 Submit をクリックします。

デフォルトまたはデバイス グループの設定を適用したあとに、保存が必要な保留されている変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横にレッドで表示されます。以前の設定に戻すには、Reset をクリックしてください。Reset ボタンが表示されるのは、デフォルトの設定値またはデバイス グループの設定値を適用して現在のデバイス設定を変更したにもかかわらず、設定がまだ送信されていない場合だけです。

 

表4-7 WCCP バイパス設定

GUI パラメータ
機能
CLI コマンド

Bypass Enable

Content Engine がクライアントから着信する要求をバイパスできるようにします。

--

Authentication Bypass

認証バイパスの使用をイネーブルにして、クライアント/サーバのペアのダイナミック アクセス リストを生成します。

bypass auth-traffic enable

Bypass Gateway

バイパス ゲートウェイの IP アドレス。

bypass gateway ipaddress

Bypass entry expiration time

アイドル状態のクライアント/サーバのペアをバイパス アクセス リストに置いておく時間(分単位)。デフォルト値は 20 分です。

bypass timer minutes

Error Handling

エラーを処理する方法を指定します。

error-handling { reset-connection | send-cache-error | transparent }

Load Bypass Enable

トラフィックのバイパスをイネーブルにします。

bypass load enable

Interval between bypassing buckets

あるバケットをバイパスしてから次のバケットをバイパスするまでの時間(秒単位)。デフォルト値は 4 秒です。

bypass load in-interval seconds

Time that a bucket is bypassed

Content Engine でバイパスされた負荷を受け入れない時間(分単位)。

bypass load time-interval minutes

Time interval between buckets coming back

Content Engine がバイパスされたトラフィックの受け入れを再開したあとに、各バケットを受け入れる間隔(秒単位)。

bypass load out-interval seconds

 


 

WCCP バイパス リスト エントリの作成

Content Engine は認証バイパスを使用して、クライアント/サーバのペアのダイナミック アクセス リストを生成できます。Content Distribution Manager GUI を使用して、このリストを生成する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。Device Group ウィンドウが表示されます(または、 Device > Devices の順に選択します)。

ステップ 2 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Request Routing > WCCP > Bypass List の順に選択します。

ステップ 5 Create New WCCP Bypass List アイコンをクリックします。Creating new WCCP Bypass List ウィンドウが表示されます。

ステップ 6 Client Address フィールドに、クライアントの IP アドレスを入力します。

ステップ 7 Server Address フィールドに、サーバの IP アドレスを入力します。

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


 

CLI から WCCP バイパス リスト エントリを作成するには、次のグローバル コンフィギュレーション コマンドを使用します。

bypass static { clientip [ serverip | any-server ] | any-client serverip }

ルータ上での WCCP のイネーブル化

インターフェイスが WCCP バージョン 2 を使用して Web トラフィックを Content Engine にリダイレクトできるようにするには、ルータ上でグローバル コンフィギュレーション モードから次のタスクを実行してください。

 

コマンド
目的

ステップ 1

Router(config)# ip wccp enable

ルータが WCCP を使用できるようにします。

ステップ 2

Router(config)# ip wccp redirect-list [ number | name ]

(任意)リダイレクト アクセス リストを指定します。このアクセス リストと一致するパケットだけがリダイレクトされます。このコマンドを設定しない場合、すべてのパケットがリダイレクトされます。

ステップ 3

Router(config)# interface type number

インターフェイス コンフィギュレーション モードに入ります。

ステップ 4

Router(config-if)# ip web-cache redirect

Web トラフィックを Content Engine にリダイレクトするように、インターネットに接続されているインターフェイスを設定します。

ステップ 5

Router(config-if)# ip route-cache same-interface

(任意)クライアントと Content Engine が同じネットワーク上にある場合、インターフェイス上で高速スイッチング パスを使用するようにルータを設定します。

ステップ 6

Router(config-if)# end

設定モードを終了します。

ステップ 7

Router(config)# copy running-config startup-config

設定を保存します。

Web キャッシング用の基本的な WCCP ルータ設定

ルータと Content Engine 上で WCCP のサポートをイネーブルにすると、これらのデバイスは通信を行い、設定されているサービスを配信します。これらのサービスは、個々の Content Engine の電源をオフにするなどの方法で Content Engine をディセーブルにするのではなく、ルータ上で WCCP のサポートをディセーブルにすることにより、一時的に停止できます(たとえば、ルータ上で WCCP のサポートをディセーブルにするには、 no ip wccp ルータ コマンドを使用)。

また、多くの WCCP バージョン 2 サービスには、適切な wccp グローバル コンフィギュレーション コマンドの設定も必要です。詳細は、『Cisco ACNS Software Command Reference』Release 5.x、および ACNS ソフトウェアのリリース ノートを参照してください。

クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

このシナリオでは、Content Engine と要求側クライアントが同一サブネット上にあるものとします(図4-7 を参照)。

WCCP バージョン 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的にリダイレクトします。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックをリダイレクトします。

図4-7 クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

 

Web キャッシュ サービス用の Content Engine の設定 ― クライアントと Content Engine が同一サブネット上にある場合

Content Engine を Web キャッシュ サービス用に設定するには、ACNS ソフトウェアにログイン中に、グローバル コンフィギュレーション モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

ContentEngine(config)# wccp version 2

Content Engine が WCCP バージョン 2 を実行していることを確認します。

ステップ 2

ContentEngine(config)# wccp router-list 1 10.10.10.1

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

ステップ 3

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

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに通知します。

ステップ 4

ContentEngine(config)# exit

グローバル コンフィギュレーション モードを終了します。

ステップ 5

ContentEngine# copy running-config startup-config

実行コンフィギュレーションを不揮発性メモリに書き込みます。

Web キャッシュ サービス用のルータの設定 ― クライアントと Content Engine が同一サブネット上にある場合

ルータを Web キャッシュ サービス用に設定するには、ルータにログイン中に、グローバル コンフィギュレーション モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

Router(config)# ip wccp web-cache

Web キャッシュ サービスを実行するようにルータに指示します。

ステップ 2

Router(config)# interface Ethernet0

設定するルータ インターフェイスを指定します。この場合、Ethernet0 が Content Engine とクライアントを接続するルータインターフェイスです。

ステップ 3

Router(config-if)# ip route-cache same-interface

リダイレクトされるパケットの高速スイッチングをイネーブルにします。パケットは、受信インターフェイスを使用して送信されます。このコマンドを使用しない場合、ルータは高速スイッチング キャッシュを使用しません。パケットはプロセスによってスイッチングされ、速度はかなり遅くなります。

ステップ 4

Router(config)# interface Serial0

設定するルータ インターフェイスを指定します。この場合、Serial0 がインターネットとのルータ インターフェイスです。

ステップ 5

Router(config-if)# ip wccp web-cache redirect out

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。この場合、ルータは 1 つです。Web キャッシュ トラフィックは、TCP ポート 80 トラフィックとして定義されます。

ステップ 6

Router(config-if)# exit

インターフェイス コンフィギュレーション モードを終了します。

設定例 ― クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

次の例では、図4-7で示されているトポロジーで、Content Engine とルータを Web キャッシュ サービス用に設定しています。

Content Engine

hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cu.net
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
. . .
 

WCCP 対応ルータ

Building configuration...
 
Current configuration:
!
version 12.0
!
hostname WCCP-Router
!
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
ip route-cache same-interface
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end

クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

このシナリオでは、Content Engine と要求側クライアントが異なるサブネット上に配置されているものとします(図4-8 を参照)。

WCCP バージョン 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的にリダイレクトします。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックをリダイレクトします。

図4-8 Content Engine とクライアントが異なるサブネット上にある場合の Web キャッシュ サービス

 

Web キャッシュ サービス用の Content Engine の設定 ― クライアントと Content Engine が異なるサブネット上にある場合

Content Engine を Web キャッシュ サービス用に設定するには、ACNS ソフトウェアにログイン中に、グローバル コンフィギュレーション モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

ContentEngine(config)# wccp version 2

Content Engine が WCCP バージョン 2 を実行していることを確認します。

ステップ 2

ContentEngine(config)# wccp router-list 1 10.10.20.1

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

ステップ 3

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

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに通知します。

ステップ 4

ContentEngine(config)# exit

グローバル コンフィギュレーション モードを終了します。

ステップ 5

ContentEngine# copy running-config startup-config

実行コンフィギュレーションを不揮発性メモリに書き込みます。

Web キャッシュ サービス用のルータの設定 ― クライアントと Content Engine が異なるサブネット上にある場合

ルータを Web キャッシュ サービス用に設定するには、ルータにログイン中に、グローバル コンフィギュレーション モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

Router(config)# ip wccp web-cache

Web キャッシュ サービスを実行するようにルータに指示します。

ステップ 2

Router(config)# interface Serial0

設定するルータ インターフェイスを指定します。この場合、Serial0 がインターネットとのルータ インターフェイスです。

ステップ 3

Router(config-if)# ip wccp web-cache redirect out

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。この場合、ルータは 1 つです。Web キャッシュ トラフィックは、ポート 80 上の HTTP パケットとして定義されます。

ステップ 4

Router(config-if)# exit

インターフェイス コンフィギュレーション モードを終了します。

設定例 ― クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

次の例では、図4-8で示されているトポロジーで、Content Engine とルータを Web キャッシュ サービス用に設定しています。

Content Engine の設定

. . .
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cisco.com
!
exec-timeout 20
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
...

WCCP 対応ルータの設定

Building configuration...
 
Current configuration:
!
hostname WCCP-Router
!
!
ip subnet-zero
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
!
interface Ethernet1
ip address 10.10.20.1 255.255.255.0
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end
 

直接プロキシ ルーティングの設定

プロキシ設定では、エンド ユーザのブラウザに Content Engine の IP アドレスを設定する必要があります。したがって、プロキシ スタイルの要求は、クライアントが Content Engine へのルーティングを明示的に指定したあと、Content Engine に着信するようになります。

プロキシ自動設定ファイル サーバの使用

Cisco ACNS 5.4 ソフトウェアは、動的なプロキシ自動設定(PAC)をサポートしています。この機能は直接プロキシ ルーティング形式で、ブラウザは PAC ファイル テンプレートという特別なファイルからプロキシの IP アドレスとポート設定情報を動的に取得できます。PAC 機能は、Microsoft Internet Explorer と Netscape Communicator の両ブラウザでサポートされています。ブラウザの自動プロキシ設定は手動で行う必要があります。

PAC 機能は、Content Distribution Manager を使用して設定され(PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当てを参照)、PAC ファイル サーバとしてイネーブルになっている Content Engine が少なくとも 1 台必要です(PAC ファイル サーバとしての Content Engine の設定を参照)。PAC ファイル サーバは、PAC ファイル テンプレートの指示に基づいて、コンテンツを要求しているクライアントに最も近いプロキシ Content Engine を動的に選択します(PAC ファイル テンプレートの作成を参照)。

動的な PAC ルーティングでは、次の機能をサポートしています。

複数の PAC ファイルが使用できます。

ユーザは事前設定された名前だけではなく、PAC ファイルの名前を指定できます。

PAC ファイル サーバは、カバレッジ ゾーン情報および要求側の送信元 IP アドレスに基づいて、一連の最も近いプロキシを動的に PAC ファイル テンプレートに追加します。

Content Engine 自体が PAC ファイル テンプレートを取得するのではなく、Content Distribution Manager が PAC ファイル テンプレートを取得し、PAC ファイル サーバである Content Engine にそれらのテンプレートを配信します。


) この新しい機能は、ACNS 5.0 ソフトウェアでサポートされている proxy-auto-config EXEC コマンドの拡張機能ではなく、その機能に置き換わるものでもありません。いずれの機能も、ACNS 5.4 ソフトウェアでサポートされています。


PAC ファイル テンプレートの作成

システム管理者はワークステーション上で PAC ファイル テンプレートを作成し、Content Distribution Manager が URL にアクセスできる場所にそのテンプレートを置きます。次に、管理者は Content Distribution Manager GUI で PAC ファイル テンプレートの URL を登録し、それにカバレッジ ゾーン ファイルを割り当てます。

PAC ファイル サーバが動的情報を生成し、挿入する事前定義マクロを管理者が入力すると、このテンプレートは完全な PAC ファイルになります。最も近いプロキシは、カバレッジ ゾーン ファイルに含まれているメトリックによって決定されます。

Content Distribution Manager はテンプレートを取得し、すべての PAC ファイル サーバに配信します。PAC ファイル サーバである Content Engine ごとに、管理者は PAC ファイル要求に使用するポートも設定する必要があります。通常、ポート 80 が使用されます。

ポートを設定するには、CLI で http proxy incoming port グローバル コンフィギュレーション コマンドを使用します(デフォルトはありません)。別の方法として、Content Distribution Manager を使用して、HTTP Connection Settings ウィンドウ( Devices > Devices > Applications > Web > HTTP > HTTP Connections )で、着信プロキシ ポートを設定することもできます。

管理者は、目的のサーバを含めて、PAC ファイルの URL をエンド ユーザに提供します。ユーザは、この URL を使用するようにブラウザを設定する必要があります。ブラウザは、最初に起動されると、その URL を要求します。PAC ファイル サーバは、すべての ACNS ソフトウェア マクロを、ローカル カバレッジ ゾーンからの現在の情報(存在する場合)、および要求側の送信元 IP アドレスに基づくデフォルトのカバレッジ ゾーンからの現在の情報で動的に置き換えます。完成した PAC ファイルは、要求側クライアントに返されます。

エンド ユーザが NAT デバイスの背後に存在し、エンド ユーザを IP アドレスに基づいて別のプロキシに転送したい場合、これらのユーザが使用する PAC ファイル サーバもその NAT デバイスの背後に存在する必要があります。この理由は、NAT の背後に配置されていない PAC ファイル サーバは、エンド ユーザの送信元 IP アドレスではなく、NAT デバイスの送信元 IP アドレスを持つ、NAT の背後のユーザに対する PAC 要求を受け取るからです。

次の 3 つのマクロが定義されています。

CE_NAME_n

CE_IPADDR_n

NEAREST_PROXIES_n

ここで、 n は 1 ~ 5 の値です。

CE_NAME_n の場合、PAC ファイル サーバは n 番めに近いプロキシの名前を代入します。CE_IPADDR_n の場合、PAC ファイル サーバは n 番めに近いプロキシの IP アドレスを代入します。n 番めに近いプロキシがない場合、PAC ファイル サーバはマクロの代わりに空のストリング "" を使用します。PAC テンプレートの作成者は、PAC ファイル テンプレートの作成時にこの点に注意する必要があります。

NEAREST_PROXIES_n マクロの場合、PAC ファイル サーバは、最も近い n 個までのプロキシの代わりに、ストリング PROXY <ip address>; を使用します。ここで、<ip address> は、プロキシの IP アドレスです。テンプレートの作成者がマクロにポート番号を組み込む場合、このポート番号は各プロキシ IP アドレスに追加されます。

たとえば、NEAREST_PROXIES_2:8080 は、「PROXY 192.30.120.12:8080; PROXY 168.10.10.1:8080;」のようなストリングに展開されます。 n が、使用できるプロキシ数より大きい場合、PAC ファイル サーバは、 n プロキシより少ない数字を代わりに使用します。たとえば、NEAREST_PROXIES_2 は、「PROXY 192.30.120.12;」または最も近いプロキシがない場合は "" になります。PAC テンプレートの作成者は、PAC ファイル テンプレートの作成時にこの点にも注意する必要があります。

PAC ファイルの例

CE1 はサブネット 10.1.1.0/24 を処理し、CE2 はサブネット 10.1.2.0/24 を処理することを前提とします。サブネット 10.1.1.0/24 上のクライアントはすべて最も近いプロキシである CE1 に転送され、サブネット 10.1.2.0/24 上のクライアントはすべて最も近いプロキシである CE2 に転送されます。

PAC ファイル テンプレートは次のようになります。

Function FindProxyForURL(url, host)
{
//handle plain host names
if (isPlainHostName(host) {
return “DIRECT”;
 
//handle exception list
if (myIpAddress() == "10.1.1.2") {
return “DIRECT”;
}
 
//handle special domain list
if (shExpMatch(host, "specialdomain.com”)) {
return “PROXY specialDomainProxy.foo.com”;
}
 
//handle direct domain list
if (shExpMatch(host, "directdomain.com”)) {
return “DIRECT”;
}
 
//closest proxies + defaults
p1 = CE_NAME_1;
p2 = CE_NAME_2;
if (p1 != “”) {
p1 = “PROXY “ + p1 + “.proxy.foo.com:8080; ”;
}
if (p2 != “”) {
p2 = “PROXY “ + p2 + “.proxy.foo.com:8080; ”;
}
return p1 + p2 + “DIRECT”;
}
 

カバレッジ ゾーン ファイルは次のようになります。

<?xml version="1.0"?>
<CDNNetwork>
<!--No coverage zone file from CDM is available-->
<!--Default coverage zones, if any, follow this comment-->
<coverageZone>
<network>10.1.1.0/24</network>
<CE>CE1</CE>
<metric>20</metric>
</coverageZone>
<coverageZone>
<network>10.1.2.0/24</network>
<CE>CE2</CE>
<metric>20</metric>
</coverageZone>
</CDNNetwork>
 

クライアントの送信元 IP アドレスが 10.1.1.20 の場合、次のような proxy.pac ファイルが作成されます。

function FindProxyForURL(url, host)
{
//handle plain host names
if (isPlainHostName(host) {
return “DIRECT”;
 
//handle exception list
if (myIpAddress() == "10.1.1.2") {
return “DIRECT”;
}
 
//handle special domain list
if (shExpMatch(host, "specialdomain.com”)) {
return “PROXY specialDomainProxy.foo.com”;
}
 
//handle direct domain list
if (shExpMatch(host, "directdomain.com”)) {
return “DIRECT”;
}
 
//closest proxies + defaults
p1 = “CE1”;
p2 = “CE2”;
if (p1 != “”) {
p1 = “PROXY “ + p1 + “.proxy.foo.com:8080; ”;
}
if (p2 != “”) {
p2 = “PROXY “ + p2 + “.proxy.foo.com:8080; ”;
}
return p1 + p2 + “DIRECT”;
}

PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当て

PAC ファイル テンプレートを登録し、カバレッジ ゾーン情報を割り当てる手順は、次のとおりです。


ステップ 1 Content Distribution Manger GUI から、 System > Configuration > Routing > PAC File Registration の順に選択します。PAC File Registration ウィンドウが表示されます。

ステップ 2 Create New PAC File アイコンをクリックします。Registering New PAC File ウィンドウが表示されます。

ステップ 3 ファイルのインポート方法を選択します。

Upload ― このアップロード方法を使用すると、 PC からアクセス可能なロケーションから、ブラウザ機能を使用して PAC ファイルをアップロードできます。

Import ― このインポート方法を使用すると、PAC ファイルを外部の HTTP、HTTPS、FTP、または CIFS サーバからインポートできます(図4-9 を参照)。

図4-9 Registering New PAC File ウィンドウ ― Import 方法

 

Upload(アップロード)方法に関連するフィールドの説明については 表4-8 を、Import(インポート)方法に関連するフィールドの説明については 表4-9 を参照してください。

 

表4-8 PAC ファイルの Upload 方法

プロパティ
説明

File Import Method

ファイルのインポート方法を設定します。 Upload を選択して、カバレッジ ゾーン ファイルをアップロードするために必要なフィールドを表示します。

PAC File Upload

PAC ファイルへのローカル ディレクトリ パス。 Browse ボタンを使用すると、ファイルを特定しやすくなります。

Destination Filename

PAC ファイル サーバに配信される PAC ファイルの名前。このフィールドにはローカル ディレクトリ パスからファイル名が自動的に入力されます。


) この宛先ファイル名をもつ PAC ファイルは、PAC ファイル サーバ上の/state/pacFile ディレクトリにコピーされます。


 

End User Request URL

PAC ファイル サーバから PAC ファイルを取得するためにブラウザの設定にエンド ユーザが使用する URL。


) ファイルの取得に 80 以外のポート番号を使用する場合、そのポート番号を URL で指定する必要があります。たとえば、ポート 8080 を使用する場合、URL は次のようになります。http://10.5.1.151:8080/sample.pac


Coverage Zone File

最も近いプロキシを算出するために使用されるカバレッジ ゾーン ファイル。

Use the default Coverage Zone

このチェックボックスにチェックマークが付いている場合は、デフォルトのカバレッジ ゾーンに基づいて最も近いプロキシを算出します。


) ドロップダウン リストから 1 つのカバレッジ ゾーン ファイルだけが選択された場合、指定されたカバレッジ ゾーン ファイルの情報を使用して、最も近いプロキシが算出されます。Use the default Coverage Zone チェックボックスだけにチェックマークが付いている場合、デフォルトのカバレッジ ゾーンだけを使用して、最も近いプロキシが算出されます。カバレッジ ゾーン ファイルが指定され、かつ Use the default Coverage Zone チェックボックスにチェックマークが付いている場合は、カバレッジ ゾーン ファイルとデフォルトのカバレッジ ゾーンを組み合わせた情報を使用して、最も近いプロキシが算出されます。


 

 

表4-9 PAC ファイルの Import 方法

プロパティ
説明

File Import Method

ファイルのインポート方法を設定します。 Import を選択して、PAC ファイルをインポートするために必要なフィールドを表示します。

PAC File URL

PAC ファイルにアクセスできるオリジン URL のフルパス(PAC ファイル名を含む)。

Destination File Name

PAC ファイル サーバに配信される PAC ファイルの名前。


) この宛先ファイル名を持つ PAC ファイルは、PAC ファイル サーバ上の/state/pacFile ディレクトリにコピーされます。


 

End User Request URL

PAC ファイル サーバから PAC ファイルを取得するためにブラウザの設定にエンド ユーザが使用する URL。


) ファイルの取得に 80 以外のポート番号を使用する場合、そのポート番号を URL で指定する必要があります。たとえば、ポート 8080 を使用する場合、URL は次のようになります。http://10.5.1.151:8080/sample.pac


 

Coverage Zone File

最も近いプロキシを算出するために使用されるカバレッジ ゾーン ファイル。

Use the default Coverage Zone

このチェックボックスにチェックマークが付いている場合は、デフォルトのカバレッジ ゾーンに基づいて最も近いプロキシを算出します。


) 1 つのカバレッジ ゾーン ファイルだけが指定された場合、指定されたカバレッジ ゾーン ファイルの情報を使用して、最も近いプロキシが算出されます。デフォルトのカバレッジ ゾーンだけが指定された場合、デフォルトのカバレッジ ゾーンだけを使用して、最も近いプロキシが算出されます。カバレッジ ゾーン ファイルが指定され、かつデフォルトのカバレッジ ゾーンのチェックボックスにチェックマークが付いている場合は、カバレッジ ゾーン ファイルとデフォルトのカバレッジ ゾーンを組み合わせた情報を使用して、最も近いプロキシが算出されます。


 

Update Interval (minutes)

PAC ファイルの URL にある PAC ファイルに加えられた変更を Content Distribution Manager が調べる頻度。デフォルト値は 10 分です。

UserName

PAC ファイルを取得するために認証されるユーザの名前。

Password

PAC ファイルにアクセスするためのユーザ パスワード。

NTLM user Domain

NTLM 認証用の NTLM ユーザのドメイン名。

Disable Basic Authentication

このチェックボックスにチェックマークを付けると、Windows NT LAN Manager(NTLM)ヘッダーが削除されず、基本認証方式にフォールバックしません。

このチェックボックスにチェックマークを付けないと、NTLM 認証ヘッダーが削除され、基本認証方式にフォールバックします。ユーザ名とパスワードの情報は、基本認証ヘッダーを持つクリア テキストでオリジン サーバに渡されます。

ステップ 4 この設定値を保存するには、 Submit をクリックします。


 

PAC ファイル サーバとしての Content Engine の設定

PAC ファイル サーバは、PAC ファイル サーバの状況、カバレッジ ゾーン情報、一般的な PAC 情報、および PAC テンプレート情報に加えられた変更を検出します。PAC ファイル サーバは、動的な PAC ファイルを正しく配信できるように、必要に応じて情報を更新します。また、PAC ファイル テンプレートとカバレッジ ゾーン ファイルを既知のロケーションにインストールします。管理者は、任意の数の Content Engine を PAC ファイル サーバとして設定できます。

PAC ファイル サーバとして Content Engine を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 PAC ファイル サーバとして設定する Content Engine の名前の横にある Edit アイコンをクリックします。Devices Home ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Device Activation をクリックします。Device Activation ウィンドウが表示されます(図4-10 を参照)。

図4-10 Device Activation for Content Engine ウィンドウ

 

ステップ 5 Request Routing セクションで、 Enable PAC File Server チェックボックスにチェックマークを付けます。

ステップ 6 Submit をクリックして、変更を保存します。


 

クライアント プロキシ自動設定の設定

ACNS 5.x ソフトウェアは、プロキシ自動設定ファイル(.pac ファイル)をサポートしています。ブラウザの自動設定 URL フィールドに Content Engine の IP アドレス、着信ポート番号、ファイル ディレクトリ、および .pac ファイル名を設定すると、ブラウザは、プロキシ IP アドレスおよびポート設定情報を、プロキシ自動設定ファイルから入手します。


) 自動設定ファイルをディスク/local1 または/local2 にダウンロードする前に、これら 2 つのディスク ロケーションを sysfs ボリュームとして設定する必要があります。


プロキシ自動設定機能は、Microsoft Internet Explorer と Netscape の両方のブラウザでサポートされています。ブラウザの自動プロキシ設定は、手動で行う必要があります。

次に、ブラウザのプロキシ自動設定の URL フィールドに入力する URL 構文の例を示します。

http://ContentEngine-IPaddress:portnumber/proxy.pac


) プロキシ着信ポートについては、プロキシ着信設定に指定されているポート番号を使用します。 たとえば、ポート 8080 が指定されている場合は、前述の例で 8080 をポート番号として使用します。


プロキシ自動設定を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。デバイス グループを作成した場合は、Device Group ウィンドウが表示されます(または、 Devices > Devices の順に選択します)。

ステップ 2 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 3 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 4 Contents ペインから、 Request Routing > Client Proxy Autoconfiguration の順に選択します。Client Proxy Auto Configuration Settings ウィンドウが表示されます(図4-11 を参照)。

図4-11 Client Proxy Auto Configuration Settings ウィンドウ

 

ステップ 5 プロキシ自動設定をイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。

ステップ 6 .pac ファイルをリモート FTP サーバからダウンロードする場合は、Remote FTP Server Host Name フィールドにホスト名または IP アドレスを入力します。

ステップ 7 Remote File フィールドに、リモート FTP サーバでアクセスする自動設定ファイルの名前を入力します。

ステップ 8 Username フィールドに、FTP サーバへのアクセスに必要なユーザ名または ID を入力します。

ステップ 9 Password フィールドに、リモート FTP サーバ上のファイルへのアクセスに必要なパスワードを入力します。

ステップ 10 Confirm Password に、パスワードを再度入力します。

ステップ 11 この設定値を保存するには、 Submit をクリックします。


 

Content Router またはルーティング Content Engine を使用したコンテンツ要求ルーティングの設定

このルーティング方式では、シスコの Content Router またはルーティング Content Engine が必要です。Content Router またはルーティング Content Engine は、HTTP または RTSP リダイレクトを使用して、目的のコンテンツをクライアントに配信するのに最適であると Content Router またはルーティング Content Engine が判断した Content Engine に要求をルーティングします。この判断は、要求された FQDN、クライアントの IP アドレス、および Content Engine の応答性に基づいて行われます。Content Router は、クライアントのエンドシステムの送信元 IP アドレスを、Content Engine に割り当てられているアドレス範囲テーブル(カバレッジ ゾーン)と比較します。次に Content Router またはルーティング Content Engine は、選択された Content Engine をポイントするリダイレクト応答をクライアントに送信します。Content Engine は、あとで、コンテンツを送信するプロキシ キャッシング サーバとして設定したり、事前配信されたコンテンツを配信するように設定したりできます。

プロキシ キャッシングを Content Engine で設定するには、 第 8 章「キャッシング サービスの設定」 を参照してください。事前配信されたコンテンツの配信をネットワークで設定するには、 第 5 章「ACNS ネットワークのコンテンツ配信設定」 を参照してください。


) ここでの説明における Content Router には、ルーティング Content Engine も含まれます。「ルーティング Content Engine としての Content Engine の設定」を参照してください。


Content Router の要求ルーティングは、次のように動作します。

1. クライアントがローカル Domain Name System(DNS; ドメイン ネーム システム)プロキシ サーバに対して、ドメイン名の IP アドレスを要求する DNS クエリーを送信します。

2. ローカル DNS プロキシが、その DNS クエリーをネームサーバに送信し、ドメイン名を IP アドレスに解決します。

3. 解決プロセスが、最終的に Content Router で終わります。Content Router の IP アドレスがローカル DNS プロキシ サーバに返されます。

4. ローカル DNS プロキシ サーバが、Content Router の IP アドレスをクライアントに返します。

5. クライアントが、目的のコンテンツに対する要求を Content Router に送信します。

6. Content Router が、DNS ドメイン名をポイントするリダイレクト応答を返し、DNS ドメイン名を最も近い Content Engine の IP アドレスに解決します。

7. クライアントが、コンテンツの要求を最適な Content Engine に送信します。

8. 最適な Content Engine が、クライアントにコンテンツを送信します。

Content Router の要求ルーティングを正常に機能させるには、次の情報を設定する必要があります。

カバレッジ ゾーン

Content Router は、カバレッジ ゾーンに基づいて、クライアントのエンドシステムに最も近い Content Engine を選択します(次の「カバレッジ ゾーンとカバレッジ ゾーン ファイル」を参照)。

Web サイトの割り当て

Content Engine が提供できるコンテンツは、その Content Engine が割り当てられている Web サイトのコンテンツだけです。Content Engine は、チャネルを使用して Web サイトに割り当てられます( Content Engine のチャネルへの追加と削除を参照)。

DNS サーバ

DNS のすべての Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)のエントリは、Content Router に委任される必要があります。DNS サーバのゾーン データベース ファイルでは、Content Router に FQDN を委任するネーム サーバ(NS)レコードを入力し、その後 DNS サーバを再起動する必要があります。

次の例では、FQDN www.cisco.com を bali-cr という名前の Content Router に委任しています。

www.cisco.com IN NS bali-cr

DNS サーバで NS レコードを設定した場合、FQDN およびそのすべてのサブドメインに対する要求はすべて、既存の DNS サーバではなく、Content Router に送信されます。Content Router は、FQDN に対する DNS クエリーを自動的に解決します。

カバレッジ ゾーンとカバレッジ ゾーン ファイル

カバレッジ ゾーンは、エンドシステムの IP アドレスを Content Engine へマッピングしたものです。Content Router は、Content Engine の IP アドレスを使用して、エンドシステムの IP アドレスを Content Engine にマップする静的リダイレクト テーブルを作成し、エンドシステムと Content Engine との近接性についての情報を提供します。エンド ユーザがコンテンツを要求すると、Content Router はエンド ユーザの IP アドレスを調べて、その IP アドレスが含まれるカバレッジ ゾーンを特定します。次に Content Router は、このカバレッジ ゾーンを処理する Content Engine を選択します。IP アドレスが複数のカバレッジ ゾーン内にある場合、より範囲が限定されているカバレッジ ゾーンが選択されます。たとえば、IP アドレス 172.1.1.1 は、カバレッジ ゾーン 172.0.0.0/8 ではなく、172.1.0.0/16 のデータを使用します。カバレッジ ゾーン データで一致しない場合、要求はリダイレクトされません。Content Router はエラー応答を送り返し、コンテンツは提供できません。

1 つのカバレッジ ゾーンを、1 つまたは複数の Content Engine に関連付けることができます。各 Content Engine が固有のカバレッジ ゾーンを持つか、Content Engine を複数のカバレッジ ゾーンに関連付け、カバレッジ ゾーンをオーバーラップさせることができます。ACNS 5.x ソフトウェアでは、カバレッジ ゾーンは Content Distribution Manager または Content Router に関連付けることはできません。

1 つのカバレッジ ゾーンが複数の Content Engine によって処理される場合、最小のメトリック値を持つ Content Engine が、ルーティング テーブルに置かれます。メトリック値( 表4-10 を参照)は、Content Engine とエンド ユーザとの近接性を示します。1 つのカバレッジ ゾーンにある複数の Content Engine が同じサブネット上にあり、同じメトリック値を持つ場合、Content Router はラウンドロビン方式でクライアントへのリダイレクトを実行します。

Content Engine が Content Distribution Manager に登録されると、その Content Engine に割り当てられる IP アドレスとサブネット マスクによって決定される、デフォルトのカバレッジ ゾーンが割り当てられます。デフォルトのカバレッジ ゾーン設定の割り当ては解除することができます。ネットワーク管理者は、カバレッジ ゾーン ファイルにカバレッジ ゾーンを定義することによって、独自のカスタム カバレッジ ゾーンを作成して割り当てることができます。

カバレッジ ゾーン ファイルは、ユーザ定義のカバレッジ ゾーンの指定に使用される XML ファイルです。ファイル内の各カバレッジ ゾーン エントリには、IP アドレスの範囲、このサブネットを処理する Content Engine の名前、メトリック値、および 1 つまたは複数の任意のエージェント フィールド(このエントリが特定のルーティング Content Engine 用に指定されている場合)を指定します。このファイルには、カバレッジ ゾーンの情報のほかにも、文書化のための 2 つの任意の要素があります。カバレッジ ゾーン ファイルのバージョンを指定する改訂値と、カスタマー名です。

カバレッジ ゾーン ファイルは、任意の ASCII テキスト編集ツールを使用して作成できます。1 つのテキスト形式のカバレッジ ゾーン ファイルを使用して、ACNS ネットワークのすべてのカバレッジ ゾーンを定義できます。

表4-10 に、カバレッジ ゾーン ファイルの要素の定義を示します。

 

表4-10 カバレッジ ゾーン ファイルの要素

要素
説明

ネットワーク

IP アドレス

カバレッジ ゾーンの IP アドレス範囲。

Content Engine

Content Engine 名

ネットワーク要素で指定されたカバレッジ ゾーンを処理する Content Engine を指定します。これには、1 つまたは複数の要素を指定できます。

メトリック

整数

Content Engine とエンド ユーザとの近接性を示す値。この値が小さいほど、Content Engine とエンド ユーザが近くなります。

エージェント

ルーティング Content Engine の名前

ルーティング Content Engine として機能する Content Engine を指定するフィールド(任意)。このフィールドを指定しないと、カバレッジ ゾーン エントリはシステムに登録されているすべての Content Router に対して指定されます。

カバレッジ ゾーン ファイルの登録

システム管理者は、Content Distribution Manager または個々のデバイスがアクセスできる URL に、カバレッジ ゾーン ファイルを置きます。次に管理者は、Content Distribution Manager GUI にカバレッジ ゾーン ファイルの URL を登録します。カバレッジ ゾーン ファイルは、ACNS ネットワーク全体にグローバルに適用することも、ACNS ネットワーク内の特定の Content Router やルーティング Content Engine にローカルに適用することもできます。カバレッジ ゾーン ファイルをグローバルにすると、カバレッジ ゾーン ファイルが割り当てられていない各 Content Router またはルーティング Content Engine がそのファイルを読み取って、解析します。カバレッジ ゾーンが特定の Content Router またはルーティング Content Engine の設定に指定されている場合、その Content Router またはルーティング Content Engine だけに適用されます。

カバレッジ ゾーンの選択

次の 2 つのタイプのカバレッジ ゾーンの使用を選択できます。

デフォルトのカバレッジ ゾーン

ユーザ定義のカバレッジ ゾーン

デフォルトのカバレッジ ゾーンは、同じローカル ネットワーク セグメントまたはサブネットに配置されているすべての Content Engine で構成されます。Content Distribution Manager GUI には、デフォルトのカバレッジ ゾーンを使用するかどうかを指定するチェックボックスがあります。

ユーザ定義のカバレッジ ゾーンは、カバレッジ ゾーン ファイルに指定されているすべての Content Engine で構成されます。このファイルには、ルーティング プロセスに含まれるネットワーク セグメントを定義します。このカバレッジ ゾーン ファイルは、Content Distribution Manager に登録され、その後ルーティング定義のために Content Router またはルーティング Content Engine に適用されます。


) デフォルトのカバレッジ ゾーンのメトリック値は 20 に設定されます。ユーザ定義のカバレッジ ゾーンについては特定の Content Engine が優先されるように設定する場合、カバレッジ ゾーン ファイル内のメトリック値は 19 以下の値に設定しなければなりません。デフォルトのカバレッジ ゾーンが優先されるように設定する場合、カバレッジ ゾーン ファイル内のメトリック値は 21 以上の値に設定しなければなりません。


デフォルト カバレッジ ゾーンの使用

デフォルトのカバレッジ ゾーンを使用する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 変更する Content Engine の名の横にある Edit アイコンをクリックします。Device Home ウィンドウが表示されます。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、Device Activation を選択します。Device Activation ウィンドウに、選択した Content Engine のプロパティを編集するためのフィールドが表示されます(図4-10 を参照)。

ステップ 5 Set Default Coverage Zone File チェックボックスにチェックマークを付けます。

ステップ 6 Submit をクリックします。


 

ユーザ定義カバレッジ ゾーンの登録と適用

Content Router またはルーティング Content Engine にカスタム カバレッジ ゾーンを適用するには、まず、Content Distribution Manager GUI にカバレッジ ゾーン ファイルの URL を登録する必要があります。カバレッジ ゾーン ファイルの URL を Content Distribution Manager に登録したら、次の 2 通りの方法でカバレッジ ゾーン ファイルを適用できます。

グローバル ― ACNS ネットワーク全体に配置されます。

ローカル ― 特定の Content Router またはルーティング Content Engine 上に配置されます。


) デバイスに対してローカルなカバレッジ ゾーン ファイルを適用すると、このファイルによってそのデバイスの ACNS ネットワーク全体のカバレッジ ゾーン ファイルが変更されます。


カバレッジ ゾーン ファイルを登録する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 System > Configuration の順に選択します。

ステップ 2 Contents ペインから、 Routing > Coverage Zone File Registration の順に選択します。Coverage Zone File Registration ウィンドウが表示されます。

ステップ 3 Create New Coverage Zone File アイコンをクリックします。Registering New Coverage Zone File ウィンドウが表示されます

ステップ 4 ファイルのインポート方法を選択します。

Upload ― このアップロード方法を使用すると、PC からアクセス可能なロケーションから、ブラウザ機能を使用してカバレッジ ゾーン ファイルをアップロードできます。

Import ― このインポート方法を使用すると、カバレッジ ゾーン ファイルを外部の HTTP、HTTPS、FTP、または CIFS サーバからインポートできます。

いずれかの方法を選択すると、ウィンドウが更新され、選択した方法に関連付けられている設定フィールドが表示されます。Upload(アップロード)方法に関連するフィールドの説明については 表4-11 を、Import(インポート)方法に関連するフィールドの説明については 表4-12 を参照してください。

 

表4-11 カバレッジ ゾーン ファイルの Upload 方法

プロパティ
説明

File Import Method

ファイルのインポート方法を設定します。 Upload を選択して、カバレッジ ゾーン ファイルのアップロードを設定するためのフィールドを表示します。

Coverage Zone File Upload

カバレッジ ゾーン ファイルへのローカル ディレクトリ パス。 Browse ボタンを使用すると、ファイルを特定しやすくなります。

Destination Filename

カバレッジ ゾーン ファイルの名前。このフィールドにはローカル ディレクトリ パスからファイル名が自動的に入力されます。

 

表4-12 カバレッジ ゾーン ファイルの Import 方法

プロパティ
説明

File Import Method

ファイルのインポート方法を設定します。 Import を選択して、カバレッジ ゾーン ファイルのインポートを設定するためのフィールドを表示します。

Coverage Zone File URL

カバレッジ ゾーン ファイルにアクセスできるオリジン URL のフルパス(カバレッジ ゾーン ファイル名を含む)。

Destination File Name

カバレッジ ゾーン ファイルの名前。

Update Interval (minutes)

カバレッジ ゾーン ファイルの URL にあるカバレッジ ゾーン ファイルに加えられた変更を Content Distribution Manager が調べる頻度。デフォルト値は 10 分です。

UserName

カバレッジ ゾーン ファイルを取得するために認証されるユーザの名前。

Password

カバレッジ ゾーン ファイルを取得するために使用されるユーザ パスワード。

NTLM user Domain

NTLM 認証用の NTLM ユーザのドメイン名。

Disable Basic Authentication

このチェックボックスにチェックマークを付けると、NTLM ヘッダーが削除されず、基本認証方式へフォールバックしません。

このチェックボックスにチェックマークを付けないと、NTLM 認証ヘッダーが削除され、基本認証方式にフォールバックします。ユーザ名とパスワードの情報は、基本認証ヘッダーを持つクリア テキストでオリジン サーバに渡されます。

ステップ 5 この設定値を保存するには、 Submit をクリックします。


 

カバレッジ ゾーン ファイル URL を Content Distribution Manager にて登録したあと、グローバル ルーティング設定としてこのファイルを使用できます。

グローバルなカバレッジ ゾーン ファイルを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 System > Configuration の順に選択します。

ステップ 2 Contents ペインから、 Routing > Global Routing Config の順に選択します。Set Global Coverage Zone File ウィンドウが表示されます(図4-12 を参照)。

図4-12 Set Global Coverage Zone File ウィンドウ

 

ステップ 3 Coverage Zone File ドロップダウン リストから、カバレッジ ゾーン ファイルを選択します。

ステップ 4 Keep Alive Port フィールドに、ルーティング要求を待ち受けるために ACNS ネットワーク全体で使用するポート番号を入力します。

ステップ 5 DNS 応答のタイムアウト時間(秒)を設定するには、DNS TTL フィールドに値(0~2147483647)を入力します。デフォルト値は 60 秒です

ステップ 6 Submit をクリックします。


 

ローカルで使用するカバレッジ ゾーン ファイルを個々の Contetn Router に適用する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 カバレッジ ゾーン ファイルを割り当てる Content Router の名前の横にある Edit アイコンをクリックします。

ステップ 3 コンテンツ テーブル全体を表示するために、Contents ペインの上にある Show All ボタンをクリックします。

ステップ 4 Contents ペインから、 Device Activation を選択します。Modifying Content Router ウィンドウが表示されます。

ステップ 5 Coverage Zone File ドロップダウン リストから、カバレッジ ゾーン ファイルを選択します。

ステップ 6 Submit をクリックして、そのカバレッジ ゾーン ファイルを Content Router に適用します。


 

カバレッジ ゾーン ファイルの例

以降では、異なる 4 つのシナリオを例にして、種々のカバレッジ ゾーン ファイルの使用例を示します。

シナリオ 1:NAT ファイアウォールがない場合

これは最も単純なシナリオです。この例では、企業 ent1.com は、別々のサブネット内に 2 つの Content Engine があるパブリック アドレス スペース内にあり、各 Content Engine は互いをバックアップします。Network Address Translation(NAT; ネットワーク アドレス変換)ファイアウォールはありません。両方の Content Engine は、デフォルトのカバレッジ ゾーンを使用します。この設定により、カバレッジ ゾーン ファイルのエントリ 3 とエントリ 4(例を参照)が作成され Content Router によって追加されます。

カバレッジ ゾーン ファイル内でバックアップ Content Engine を定義するには、サブネットをバックアップ Content Engine にマップし、21 以上のメトリック値を指定します(エントリ 1 とエントリ 2)。

図4-13 カバレッジ ゾーンのシナリオ 1:NAT がない場合

 

次のファイルは、シナリオ 1 のカバレッジ ゾーン ファイルの例です(図4-13 を参照)。

<?xml version="1.0" ?>
<CDNNetwork>
<revision>1.0</revision>
<customerName>ent.com</customerName>
<!-- entry 1 -->
<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanfrancisco</CE>
<metric>20</metric>
</coverageZone>
 
<!-- entry 2: backup CE for the San Francisco office -->
<coverageZone>
<network >172.29.249.0/24</network>
<CE>ent_sanjose</CE>
<metric>20</metric>
</coverageZone>
 
<!-- entry 3 -->
<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanjose</CE>
<metric>10</metric>
</coverageZone>
 
<!-- entry 4 -->
<coverageZone>
<network>172.29.249.0/24</network>
<CE>ent_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
</CDNNetwork>

シナリオ 2:NAT ファイアウォールの背後に Content Engine がある場合

企業 ent2.com では、NAT ファイアウォールの背後に 1 台の Content Engine が存在し、Content Router はパブリック インターネット上に配置されています。このパブリック IP アドレスからのすべてのコンテンツ要求はファイアウォールの背後にある Content Engine(ent2_sanfrancisco)によって処理されます。NAT の背後にあるエンドシステムからのすべてのコンテンツ要求は、同じパブリック IP アドレスを持っているため、カバレッジ ゾーン ファイルには、このパブリック IP アドレスを Content Engine ent2_sanfrancisco にマップするエントリが 1 つあります。Modifying Content Engine ウィンドウの General Configuration セクション(図13-3 を参照)にある、Set Default Coverage Zone File チェックボックスのチェックマークを外す必要があります。これは、サブネット 10.1.1.0/24 がプライベート ネットワークであり、Content Router はそのサブネットを認識できないからです。

図4-14 カバレッジ ゾーンのシナリオ 2:NAT ファイアウォールの背後にある場合

 

次のカバレッジ ゾーン ファイルは、図4-14 に対する例です。

<?xml version="1.0" ?>
<!-- CZ for ent2.com -->
 
<CDNNetwork>
<coverageZone>
<network>171.29.250.1/32</network>
<CE>ent2_sanfrancisco</CE>
<metric> 10 </metric>
</coverageZone>
</CDNNetwork>
 

シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

このシナリオでは、企業 ent3.com には NAT ファイアウォールの背後に複数のサブネットがあり、各サブネットには 1 台の Content Engine があります。この場合、NAT ファイアウォール内には少なくとも 1 台のルーティング Content Engine が必要です。ルーティング Content Engine として機能するように Content Engine を設定し直す方法については、「Content Engine のプロパティの変更」を参照してください。ルーティング Content Engine は、ルーティング プロセスにより、コンテンツ要求ルーティングを実行できます。Content Router は、ファイアウォールの背後からのコンテンツ要求をすべてルーティング Content Engine にリダイレクトし、その後このルーティング Content Engine が 2 回めのリダイレクトを実行します。

この例では、ent3_sanjose1 がルーティング Content Engine です。NAT ファイアウォールの背後からのコンテンツ要求をすべて ent3_sanjose1 にマップするように、カバレッジ ゾーン エントリ(CZ entry 1)を定義する必要があります。また、ルーティング Content Engine である ent3_sanjose1 のカバレッジ ゾーン エントリを、10.1.1.0/24 からのすべての要求をそのルーティング Content Engine 自体にマップし(CZ entry 2)、10.1.2.0/24 からの要求を ent3_sanjose2 にマップするようにも(CZ entry 3)定義する必要があります。

図4-15 シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

 

次のカバレッジ ゾーン ファイルは、図4-15 に対する例です。

<?xml version="1.0" ?>
<!-- CZ for ent3.com -->
<CDNNetwork>
<customerName>ent3.com</customerName>
<!-- CZ entry 1 -->
<coverageZone>
<network>171.29.1.1/32</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
</coverageZone>
 
<!-- CZ for routing CE -->
<!-- CZ entry 2 -->
<coverageZone>
<network>10.1.1.0/24</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
<agent> ent3_sanjose1</agent>
</coverageZone>
 
<!-- CZ entry 3 -->
<coverageZone>
<network>10.1.2.0/24</network>
<CE>
ent3_sanjose2
</CE>
<metric> 10 </metric>
<agent>ent3_sanjose1</agent>
</coverageZone>
 

シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

企業 ent4.com は、複数のパブリック IP アドレスを持つ NAT ファイアウォールの背後にあります。NAT ファイアウォールの背後からのコンテンツ要求はすべて、これらのパブリック IP アドレスのいずれかになります。したがって、これらのパブリック IP アドレスごとに 1 つのカバレッジ ゾーン データ エントリが必要です。これらのパブリック IP アドレスは NAT ファイアウォールの背後にある Content Engine にマップされます。

図4-16 シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

 

次のカバレッジ ゾーン ファイルは、図4-16 に対する例です。

<?xml version="1.0" ?>
<!-- CZ for ent4.com -->
<CDNNetwork>
<coverageZone>
<network>171.29.10.1/32</network>
<CE>ent4_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
 
<!-- CZ for ent4.com -->
<coverageZone>
<network>171.29.10.2/32</network>
<CE>ent4_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
</CDNNetwork>

ルーティング Content Engine としての Content Engine の設定

Content Engine 上でルーティング機能を有効にすると、この Content Engine がコンテンツ要求のリダイレクトも行うことができるようになります。ルーティング Content Engine が必要になるのは、NAT ファイアウォールの背後にあるクライアントからのコンテンツ要求を処理できるように複数の Content Engine が同じ NAT ファイアウォールの背後に配置される場合です。この場合、まず Content Router はコンテンツの配信に最適な Content Engine ではなく、ルーティング Content Engine にコンテンツ要求をリダイレクトします。次にルーティング Content Engine は 2 回めのリダイレクトを実行して、コンテンツの処理に最適な Content Engine を特定します。ルーティング Content Engine の必要性を示す例については、「シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合」 を参照してください。

Content Engine をルーティング Content Engine 用に設定する方法については、「Content Engine のプロパティの変更」 を参照してください。

Content Router を使用した動的コンテンツ ルーティングの設定

ACNS ソフトウェアのこれまでのリリースでは、Content Router は、静的なカバレッジ ゾーン ファイルを使用して、Content Engine とクライアントのエンド システム間の適切なルーティング パスを設定していました。

カバレッジ ゾーンは、クライアントのエンドシステムの IP アドレスを Content Engine へマップしたものです。Content Router は、Content Engine の IP アドレスを使用して、エンドシステムの IP アドレスを Content Engine にマップする静的リダイレクト テーブルを作成し、エンドシステムと Content Engine との近接性についての情報を提供します。クライアントがコンテンツを要求すると、Content Router はクライアントの IP アドレスを調べて、その IP アドレスが含まれるカバレッジ ゾーンを特定します。次に Content Router は、このカバレッジ ゾーンを処理する Content Engine を選択します。

ACNS ネットワーク環境によっては、Content Engine の IP アドレスを断続的に変更させ、カバレッジ ゾーンを静的にする代わりに動的にしている場合もあります。このような場合、Content Router は静的なルーティング テーブルを作成できないため、コンテンツに対するルーティングを正常に行えなくなります。

次の条件に当てはまる場合、Content Rounter の静的なカバレッジ ゾーン テーブルを使用してコンテンツを正常にルーティングすることはできません。

複数のロケーションに、複数の Content Engine が配置されている。

各ロケーションに NAT ファイアウォールがある。

1 つの Content Router がすべてのロケーションに対するサービスを行っている。

1 つのルート Content Engine がすべてのロケーションに対するサービスを行っている。

各ロケーションがインターネット接続に 2 つのアップリンク回線を使用している(冗長性確保のため)。

異なるロケーションのアップリンク回線が外部のパブリック IP アドレス プールを共有できる(異なる時間に異なるロケーションで NAT ファイアウォールが同一の IP アドレスを使用可能)。

インターネット接続に複数のアップリンクを使用している場合、同じロケーションのクライアントおよび Content Engine からのコンテンツ要求が、異なる外部 IP アドレスで Content Router に送信される可能性があります。静的カバレッジ ゾーン ファイルを使用している Content Router では、異なるロケーション間で同じ IP アドレス プールを共有できません。

ACNS 5.3.3 以降のソフトウェア リリースでは、Content Router は Content Engine のカバレッジ ゾーンの変更を検出し、動的にルーティング テーブルを調整できます。

動的コンテンツ ルーティングのイネーブル化

動的コンテンツ ルーティングを設定する各 Content Router に対し、動的コンテンツ ルーティングが静的コンテンツ ルーティングに優先して使用されるように指定する必要があります。

動的コンテンツ ルーティングを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定する Content Router の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Device Activation を選択します。Device Activation ウィンドウが表示されます。

ステップ 4 動的コンテンツ ルーティングが静的コンテンツ ルーティングより優先されるように指定するには、 Dynamic Content Routing チェック ボックスにチェック マークをつけます。

ステップ 5 Content Router の設定を保存するには、 Submit をクリックします。


 

カバレッジ ゾーン ファイルの動的コンテンツ ルーティングに対する Content Engine のメトリック値の変更

ACNS 5.3.3 以降のソフトウェア リリースでは、カバレッジ ゾーン ファイルに定義されたタグによって、ルーティング テーブルで特定の Content Engine に優先度を割り当てているメトリックを変更できます。この任意のタグのことを <dynamic> タグといいます。

<dynamic> タグおよび要素を持つカバレッジ ゾーン ファイルが Content Router に割り当てられると、次の処理が実行されます。

Content Router の動的コンテンツ ルーティングがイネーブルの場合、Content Router は <dynamic> タグ内の指定に従い、<coverageZone> タグの指定を無視します。

動的コンテンツ ルーティングがイネーブルでない場合、Content Router は <dynamic> タグの指定を無視し、<coverageZone> タグの指定に従います。

<dynamic> タグはスタンドアロン タグで、<coverageZone> タグのサブ要素としては定義されていません。サブ要素の <CE> および <metric> は、<dynamic> タグ内に定義する必要があります。 表4-13 に、タグの構成要素を示します。

 

表4-13 動的コンテンツ ルーティングのカバレッジ ゾーン ファイルの構成要素

タグの名前
要素
説明

<dynamic>

<CE> 1

Content Engine 名

メトリック値を適用する Content Engine を指定します。<dynamic> タグには、複数の Content Engine 名を指定できます。

<metric> 1

数字

Content Engine とエンド ユーザとの近接性を示す値。この値が小さいほど、Content Engine が優先される度合が大きくなります。

メトリックを指定しない場合、デフォルト値として 10 が適用されます。

1.この要素は必須です。

次に、カバレッジ ゾーン ファイルにおける <dynamic> タグの使用方法を示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<dynamic>
<CE>hostname_of_ce</CE>-----------> NOTE: The tag is <CE> and not <ce>.
<metric>number</metric>
</dynamic>
</ACNSNetwork>
 

次に、<coverageZone> タグのサブ要素として指定された <dynamic> タグを含む、無効なカバレッジ ゾーン ファイルを示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<coverageZone>
<dynamic>
<CE>hostname_of_ce</CE>
<metric>number</metric>
</dynamic>
</coverageZone>
</ACNSNetwork>
 

次に、<dynamic> タグと <coverageZone> タグを両方含むカバレッジ ゾーン ファイルの例を示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<coverageZone>
<network>a.b.c.d/mask</network>
<CE>hostname_of CE</CE>
<metric>0</metric>
</coverageZone>
<dynamic>
<CE>name_of_ce</CE>
<metric>number</metric>
</dynamic>
</ACNSNetwork>
 

次に、<dynamic> タグを複数含むカバレッジ ゾーン ファイルの例を示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<dynamic>
<CE>hostname_of_ce1</CE>
<metric>number</metric>
</dynamic>
<dynamic>
<CE>hostname_of_ce2</CE>
<metric>number</metric>
</dynamic>
</ACNSNetwork>
 

次に、<dynamic> タグに複数の Content Engine 名が指定されているカバレッジ ゾーン ファイルの例を示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<dynamic>
<CE>hostname_of_ce1</CE>
<CE>hostname_of_ce2</CE>
<CE>hostname_of_ce3</CE>
<metric>number</metric>
</dynamic>
</ACNSNetwork>
 

たとえば、同一のクライアント ベースを持つ複数の Content Engine に優先順を指定する必要がある場合、カバレッジ ゾーン ファイルで <dynamic> タグを使用します。次に、ce1 のメトリック値を ce2 の値より小さくすることにより、ce1 の優先度を ce2 より高くする例を示します。

<?xml version="1.0"?>
<ACNSNetwork>
<revision>1.0</revision>
<dynamic>
<CE>hostname_of_ce1</CE>
<metric>20</metric>
</dynamic>
<dynamic>
<CE>hostname_of_ce2</CE>
<metric>30</metric>
</dynamic>
</ACNSNetwork>
 

Content Router を使用した負荷ベースのコンテンツ ルーティングの設定

負荷ベースのコンテンツ ルーティングがイネーブルで、なおかつルーティング テーブル内のすべての Content Engine のメトリック値(重み値)がすべて同じ場合、Content Router は平均 CPU 負荷が一番低い Content Engine にクライアント要求をリダイレクトします。

異なる重み値が定義されている複数の Content Engine がある場合、CPU の負荷、ディスク使用率、WMT ストリーム カウントのスレッシュホールドによる制限を設定し、Content Router が、スレッシュホールドを超えていない優先順位が 2 番めの Content Engine にクライアント要求をリダイレクトするようにできます。

設定されたスレッシュホールドが超過すると、Content Router にメッセージが送信されます。ルーティングを決定する場合、Content Router のアルゴリズムにより、重みを割り当てられた Content Engine の現在の負荷と、設定されたスレッシュホールドを比較します。

Content Router の負荷ベースのルーティングのイネーブル化

Content Router による負荷ベースのルーティングをイネーブルにするには、次の手順に従います。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 負荷ベースのルーティングを設定する Content Router の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Device Activation を選択します。Modifying Content Router ウィンドウが表示されます。

ステップ 4 負荷ベースのルーティングをイネーブルにするには、 Least Loaded チェックボックスにチェックマークを付けます。

ステップ 5 この設定値を保存するには、 Submit をクリックします。


 

Content Router による負荷ベースのルーティングを CLI からイネーブルにするには、 contentrouting leastloaded Content Router グローバル コンフィギュレーション コマンドを使用します。

負荷ベース ルーティングに対するContent Engine のスレッシュホールド制限の設定

Content Engine のスレッシュホールド制限を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices (または Devices > Device Groups )の順に選択します。

ステップ 2 設定する Content Engine またはデバイス グループの横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 General Settings > Notification and Tracking > Service Monitor の順に選択します。Service Monitor Settings for Content Engine ウィンドウが表示されます(図4-17 を参照)。 表4-14 では、このウィンドウ内のフィールドについての説明と、対応する CLI コマンドを示します。

図4-17 Service Monitor Settings ウィンドウ

 

ステップ 4 Content Engine の CPU 負荷を監視するには、次のようにサービス モニタを設定します。

Content Engine から CPU 負荷情報を収集できるようにするには、 Enable チェックボックスにチェックマークを付けます。

Content Engine の過負荷を決定する値を設定するには、Threshold フィールドに値(1~100)を入力します。スレッシュホールドは、許容する CPU 使用率で、総 CPU 使用率に対する割合です。

2 つの連続したサンプリング期間の間隔(秒)を設定する場合、Sample Period フィールドに値(1~60)を入力します。サンプリング期間は、Content Engine と Content Router が Content Engine の負荷情報を含むキープアライブを交換する期間のことです。

負荷情報を算出するために Content Engine が使用する最新のサンプル値の数を設定するには、Number of Samples フィールドに数値(1~120)を入力します。

ステップ 5 Content Engine のディスク負荷を監視するには、次のようにサービス モニタを設定します。

Content Engine からディスクの処理情報を収集できるようにするには、 Enable チェックボックスにチェックマークを付けます。ディスク サービス モニタがイネーブルの場合、Content Engine は秒当たりのディスク I/O 処理のサンプリングを行います。さらにその数字は Content Engine の負荷情報に使用するための値に変換されます。

2 つの連続したサンプリング期間の間隔(秒)を設定する場合、Sample Period フィールドに値(1~60)を入力します。

負荷情報を算出するために Content Engine が使用する最新のサンプル値の数を設定するには、Number of Samples フィールドに数値(1~120)を入力します。

ステップ 6 WMT ストリームの負荷を監視するには、次のようにサービス モニタを設定します。

Content Engine から WMT ストリーム カウント情報を収集できるようにするには、 Enable チェックボックスにチェックマークを付けます。

WMT ストリームの最大許容値を設定するには、Threshold フィールドに値(1~100)を入力します。この値は Content Engine が設定またはライセンスされているストリーム率です。

2 つの連続したサンプリング期間の間隔(秒)を設定する場合、Sample Period フィールドに値(1~60)を入力します。

負荷情報を算出するために Content Engine が使用する最新のサンプル値の数を設定するには、Number of Samples フィールドに数値(1~120)を入力します。

ステップ 7 この設定値を保存するには、 Submit をクリックします。

 

表4-14 サービス モニタの設定

GUI パラメータ
機能
CLI コマンド

CPU Settings

Enable

Content Router に Content Engine から CPU 負荷情報を収集させます。

contentrouting servicemonitor type cpu

Threshold

Content Engine が過負荷かどうかを決定する値。範囲は 1~100 です。デフォルトは 80% です。

contentrouting servicemonitor threshold cpu percentage

Sample Period

2 つの連続したサンプリングの間隔(秒)。範囲は 1~60 です。デフォルトは 5 秒です。

contentrouting servicemonitor sampleperiod cpu seconds

Number of Samples

平均の算出時に使用される最新のサンプル値の数。範囲は 1~120 です。デフォルトは 60 です。

contentrouting servicemonitor numberofsamples cpu number

Disk Settings

Enable

Content Router に Content Engine からディスクの処理情報を収集させます。

contentrouting servicemonitor type disk

Sample Period

2 つの連続したサンプリングの間隔(秒)。範囲は 1~60 です。デフォルトは 5 秒です。

contentrouting servicemonitor sampleperiod disk seconds

Number of Samples

平均の算出時に使用される最新のサンプル値の数。範囲は 1~120 です。デフォルトは 60 です。

contentrouting servicemonitor numberofsamples disk number

WMT Settings

Enable

Content Router に Content Engine からストリーム カウント情報を収集させます。

contentrouting servicemonitor type wmt

Threshold

Content Engine が設定またはライセンスされているストリーム率。範囲は 1~100 です。デフォルトは 90% です。

contentrouting servicemonitor threshold wmt percentage

Sample Period

2 つの連続したサンプリングの間隔(秒)。範囲は 1~60 です。デフォルトは 5 秒です。

contentrouting servicemonitor sampleperiod wmt seconds

 


 

Content Router の設定に関するトラブルシューティング

要求を正しくリダイレクトするために必要な Content Router の設定が数多くあるため、設定が完全でないと Content Router からコンテンツ要求エラーが返されることがあります。次に、トラブルシューティングの際に注意する点を示します。

DNS 委任

要求されたドメインは、親ドメインに対して信頼できる DNS サーバで Content Router に委任されていますか。Content Router の DNS 名は、正引きで名前解決できなければなりません。ドメインの委任については、システム管理者に確認してください。

Content Router のルーティング プロパティ

Content Router はアクティブになっていますか。Content Router のアクティブ化については、「Content Distribution Manager GUI を使用したデバイスのアクティブ化」を参照してください。

デフォルト カバレッジ ゾーンが Content Engine に対して設定されていますか。または ACNS ネットワーク全体のカバレッジ ゾーン ファイルまたはローカル カバレッジ ゾーン ファイルが、Content Router またはルーティング Content Engine に対して設定されていますか。カバレッジ ゾーン ファイルの設定については「カバレッジ ゾーン ファイルの登録」を、デフォルト カバレッジ ゾーンの設定については「デフォルト カバレッジ ゾーンの使用」を参照してください。

カバレッジ ゾーン エントリがルーティング Content Engine に対して設定されている場合、「agent」フィールドにはルーティング Content Engine の名前が指定されていますか。カバレッジ ゾーン ファイルの「agent」フィールドの説明については「カバレッジ ゾーンとカバレッジ ゾーン ファイル」を、ルーティング Content Engine のカバレッジ ゾーン エントリの例については「シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合」を参照してください。

エンド システムからのコンテンツ要求は、デフォルト カバレッジ ゾーンまたはカバレッジ ゾーン ファイルに基づいて、カバレッジ ゾーン内の Content Engine によって処理されていますか。この Content Engine は、コンテンツを提供する Content Engine です。クライアントへコンテンツを提供する Content Engine の選択方法については、第 4 章の「 Content Router またはルーティング Content Engine を使用したコンテンツ要求ルーティングの設定 」にある「カバレッジ ゾーンとカバレッジ ゾーン ファイル」を参照してください。

コンテンツを提供する Content Engine はアクティブになっていますか。Content Engine のアクティブ化については、「Content Distribution Manager GUI を使用したデバイスのアクティブ化」を参照してください。

要求されたドメインに対してチャネルが作成されていて、コンテンツを提供する Content Engine がこのチャネルに割り当てられていますか。「チャネルの作成と変更」を参照してください。

コンテンツを提供する Content Engine は稼働していますか。Content Engine のステータスを確認するには、CLI の show statistics content-routing ce cename コマンドを使用します(『Cisco ACNS Software Command Reference』Release 5.1 を参照)。

Content Engine 上に事前配信されているコンテンツ

コンテンツを提供する Content Engine に関連付けられたチャネルにマニフェスト ファイルが割り当てられていますか。「マニフェスト ファイルによる動作」を参照してください。

マニフェスト ファイルには Content Distribution Manager からアクセスできますか。「チャネルの作成と変更」を参照してください。

マニフェスト ファイルに構文エラーはありませんか。「マニフェスト ファイルの構造と構文」を参照してください。

要求されたコンテンツはマニフェスト ファイル内で指定されていますか。「単一コンテンツ項目の指定」を参照してください。

要求されたコンテンツがストリーミング メディアの場合、正しいライセンス キーを指定してアプリケーション サーバがイネーブルになっていますか。「RealProxy のイネーブル化」「RealSubscriber のイネーブル化」、および 「Cisco Streaming Engine のイネーブル化」を参照してください。

ストリーミング メディア オブジェクトを保存する場合は、mediafs 用のディスク スペース、非ストリーミング コンテンツを保存する場合は、cdnfs 用のディスク スペースが設定されていますか。「ディスク スペースの設定」を参照してください。

Content Engine は要求されたコンテンツを正常に取得しましたか。「Spider スクリプトを使用した Web サイト コンテンツのリスト」を参照してください。

次の作業

ACNS ネットワークで要求ルーティングのインフラストラクチャを設定し終わると、コンテンツのクライアント要求は最適な Content Engine にルーティングされます。これで Content Engine によるコンテンツの処理を設定できるようになります。Content Engine はプロキシ キャッシング サーバとしてコンテンツを提供するように設定できます。あるいは、事前配信されたコンテンツを配信するようにも設定できます。プロキシ キャッシングするために Content Engine を設定するには、 第 8 章「キャッシング サービスの設定」 を参照してください。

ネットワークで事前配信されたコンテンツの配信を設定する場合は、次の作業を行います。

ロケーション ツリーの構築

Content Engine のロケーションへの割り当て

コンテンツ プロバイダーのディレクトリの作成

コンテンツ プロバイダーごとの Web サイトの定義

チャネルの作成

Content Engine の各チャネルへの割り当て

ルート Content Engine の各チャネルへの割り当て

これらの作業を行うには、次の 第 5 章「ACNS ネットワークのコンテンツ配信設定」 に進んでください。