ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3
スタンドアロン Content Engine の 配置シナリオ
スタンドアロン Content Engine の配置シナリオ
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

スタンドアロン Content Engine の配置シナリオ

配置するサービスの決定

非透過モードでのキャッシングおよびストリーミング サービスの配置

非透過フォワード プロキシ キャッシングの概要

非透過モード サービスの着信プロキシ ポートの設定

SSL トンネリングおよび非透過キャッシングの配置

透過モードでのキャッシングおよびストリーミング サービスの配置

透過フォワード プロキシ キャッシングの概要

レイヤ 4 スイッチを使用した透過リダイレクションおよびフォワード プロキシ キャッシング

WCCP ルータを使用した透過リダイレクションおよびフォワード プロキシ キャッシング

透過リバース プロキシ キャッシングの概要

例 1 : WCCP 透過リダイレクションを使用したリバース プロキシ キャッシングの配置

例 2 : レイヤ 4 スイッチングを使用したリバース プロキシ キャッシングの配置

拡張透過キャッシング機能の使用方法

スタンドアロン Content Engine へのストリーミング メディア サービスの配置

フィルタリングおよびアクセス制御サービス

スタンドアロン Content Engine の配置シナリオ

この章では、企業環境およびサービス プロバイダー環境で、スタンドアロン Content Engine を配置するための簡単なシナリオのいくつかを説明します。この章の構成は、次のとおりです。

「配置するサービスの決定」

「非透過モードでのキャッシングおよびストリーミング サービスの配置」

「透過モードでのキャッシングおよびストリーミング サービスの配置」

「スタンドアロン Content Engine へのストリーミング メディア サービスの配置」

「フィルタリングおよびアクセス制御サービス」


) Content Engine を Content Distribution Manager に登録されるデバイスとして配置する方法については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。


配置するサービスの決定

ネットワークのエッジにコンテンツをプッシュして、コンテンツ配信を高速化し、WAN 帯域幅の使用量を最適化します。これを実行するために使用されるメカニズムは、「コンテンツ キャッシング」と呼ばれます。また、コンテンツ キャッシングは、「ネットワーク キャッシング」とも呼ばれます。Web のクライアントとインターネットの間にあるインライン デバイスというContent Engine の特別なポジションのおかげで、Content Engine をネットワーク キャッシュとして容易に設定することができます。頻繁にアクセスされるインターネット コンテンツは、各ロケーションの Content Engine でローカルにキャッシュし配信するため、帯域幅の使用量と Web 待ち時間が大幅に減少します。


) ACNS ソフトウェアは、既存のプロキシ インフラストラクチャと統合するために、FTP、HTTPS、HTTP 1.0、および HTTP 1.1 を含む、多数のプロキシ プロトコルをサポートします。サポートされるネットワーク プロトコルについては、表B-1 を参照してください。


Content Engine で配置可能なサポートされるサービスのタイプは、Content Engine へ要求するルーティングの方式によって異なります。コンテンツ要求は、クライアントから直接(直接プロキシ ルーティング)あるいは WCCP ルータまたはレイヤ 4 CSS スイッチ(透過リダイレクト)を経由して Content Engine にルーティングします。


) 直接プロキシ ルーティングまたは透過リダイレクトが、クライアント要求をスタンドアロン
Content Engine に転送する場合にサポートされるキャッシングおよびストリーミング サービスのリストについては、表1-5表1-6を参照してください。


直接プロキシ ルーティング方式 が最も簡単で、最も単純なルーティング方式です。直接プロキシ ルーティングでは、クライアント デスクトップ(クライアント ブラウザとメディア プレーヤー)を設定して、そのコンテンツ要求をプロキシ サーバとして機能する特定の Content Engine に直接送信する必要があります。クライアントの要求はクライアントのプロキシ サーバとして設定されている Content Engine に直接送られます。このルーティング方式は、ユーザ デスクトップが厳密に制御される場合に通常使用されます。

透過リダイレクト方式 の場合、ネットワーク トポロジおよびトラフィック パターンを理解している必要があります。組織は、一般的に、透過リダイレクト方式を使用しようとします。これはクライアント デスクトップの設定をまったく変更する必要がないからです。

しかし、直接プロキシ ルーティングを使用するためにクライアント デスクトップに変更が必要になっても、従来の要件のために、直接プロキシ ルーティングの使用が必要な場合もあります。営業所で必要な WCCP ルータまたはスイッチへの変更が許可されないために、組織は特定のサービス(たとえば、HTTPS プロキシ キャッシング)に対して、直接プロキシ ルーティングを使用することが必要なケースもあります。

ここでは、次のとおり、ACNS 5.x ソフトウェアを実行しているスタンドアロン Content Engine によりサポートされる、ルーティング方式ならびに関連するキャッシングおよびストリーミング サービスについて説明します。

「非透過モードでのキャッシングおよびストリーミング サービスの配置」

「透過モードでのキャッシングおよびストリーミング サービスの配置」


) スタンドアロン Content Engine は、直接プロキシ ルーティングおよび WCCP ルーティングまたはレイヤ 4 スイッチングを経由する透過リダイレクトをサポートします。ただし、ルーティング方式としてコンテンツ ルーティングを使用する場合には、Content Engine を Content Distribution Manager に登録する必要があります。スタンドアロン Content Engine は Content Distribution Manager に登録されていないので、コンテンツ ルーティングをサポートできません。コンテンツ ルーティングに関する情報は、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。


非透過モードでのキャッシングおよびストリーミング サービスの配置

直接プロキシ ルーティング方式の場合、スタンドアロン Content Engine は、Web コンテンツを要求するすべてのブラウザまたはメディア プレーヤーの宛先になります。そのような要求は proxy-style 要求と呼ばれます。proxy-style の要求は、Content Engine と同じ宛先 IP アドレスが付加されて着信します。その要求は Web のクライアントにより直接 Content Engine(フォワード プロキシ サーバ)に明確にルート指定されます。

非透過フォワード プロキシ キャッシングの概要

直接プロキシ ルーティングを使用してコンテンツ要求を Content Engine にルーティングする配置の場合(図3-1 を参照)、Content Engine は Web クライアントの代わりにコンテンツを取得する最適化されたネットワーク ゲートウェイ デバイスとして動作します。

要求されたコンテンツがすでに Content Engine のローカル ストレージにある場合(キャッシュ ヒット)、Content Engine はそのコンテンツを Web クライアントに送信します。

要求されたコンテンツがまだ Content Engine のローカル ストレージにない場合(キャッシュ ミス)、Content Engine はオリジン サーバから要求されたコンテンツを取得しコンテンツをキャッシングできる場合には、そのコンテンツのローカル コピーを保存し、その後要求されたコンテンツを Web クライアントに送信します。Content Engine は、これ以降同じコンテンツに対する要求があった場合、ローカル ストレージからコンテンツを配信します。

図3-1 スタンドアロン Content Engine を使用した非透過フォワード プロキシ キャッシング

 

通常、直接プロキシ ルーティングはサービス プロバイダー環境ではなく、企業環境で実装されています。このタイプのキャッシングはクライアント デスクトップの変更が必要になるからです。直接プロキシ ルーティングでは、明示的にクライアント ブラウザおよびメディア プレーヤーを設定し、これらのクライアントでフォワード(非透過)プロキシとして機能している Content Engine を指定する必要があります。このトピックの詳細は、「直接プロキシ ルーティングを使用可能にするクライアント ブラウザとメディア プレーヤーの設定」を参照してください。

非透過(プロキシ)キャッシング サービスをスタンドアロン Content Engine に配置すると、次のような大きな利点があります。

エンド ユーザのゲートウェイ デバイスの役割をするContent Engine で、ユーザ グループのインターネット アクセスを規制できる。

すべてのインターネット要求は、プロキシ キャッシュ(Content Engine)が発信元のように見え、そしてそれは内部ネットワークのアドレッシングを見えなくします。

頻繁に要求されるキャッシング可能なコンテンツをローカルにキャッシングするため、WAN 帯域幅が節約され、Web クライアントへのコンテンツ配信が高速化される。

ACNS 5.2 ソフトウェアでは、Setup ユーティリティがスタンドアロン Content Engine の基本コンフィギュレーション(デバイス ネットワークの設定、ディスク設定、および一般に使用される一連のキャッシング サービス)をスピードアップするために追加されました。この基本コンフィギュレーションには、使用される一連の キャッシング サービスも含まれます。Setup ユーティリティで設定できるキャッシング サービスのリストについては、 表4-2 を参照してください。

非透過モード サービスの着信プロキシ ポートの設定

プロキシ モードで、フォワード プロキシ サーバとして機能している Content Engine は、FTP、HTTPS、HTTP、MMS、および RTSP 要求を待ち受ける着信ポートを最大 8 つまでサポートします。「プロキシ ポート」という用語は、Content Engine が「プロキシ スタイル」の要求を受信し、要求されたコンテンツをクライアントへ送り返すポートを指すために使用されます。着信プロキシポートは、透過モード サービスによって使用されているものと同じポートにすることができます(たとえば、HTTP 透過キャッシングなど)。Content Engine で実行中の WCCP サービスをいずれも停止することなく、Content Engine の着信 プロキシ ポートを変更できます。

非透過モード サービス(たとえば、HTTP プロキシ キャッシング、FTP-over-HTTP プロキシ キャッシング、RealMedia プロキシ キャッシング、および WMT プロキシ キャッシング)の設定の一部として、次の作業をする必要があります。

クライアント ブラウザまたはメディア プレーヤーを設定して、Content Engine の着信プロキシ ポートへの要求を転送する。

Content Engine を設定して、クライアント要求を着信プロキシ ポート上で待ち受ける。

スタンドアロン Content Engine は、着信プロキシ ポートがクライアント ブラウザとメディア プレーヤー、および Content Engine 上で設定されている場合、クライアント ブラウザまたはメディア プレーヤーから直接、非透過(プロキシ スタイル)要求を受け入れます。

クライアント ブラウザまたはメディア プレーヤーを特定の Content Engine に指定する方法については、表3-1 を参照してください。

 

表3-1 コンテンツ要求の直接プロキシ ルーティングをサポートする、クライアント ブラウザおよびメディア プレーヤーの設定

非透過キャッシング
詳細

HTTP プロキシ キャッシング

「クライアント ブラウザへの直接スタンドアロン Content Engine 指定」

WMT MMS 要求の WMT プロキシ キャッシング

「WMT MMS 要求に対して Windows Media Player が 直接スタンドアロン Content Engine を指し示すようにするための設定」

WMT RTSP 要求の WMT プロキシ キャッシング

「WMT RTSP 要求に対して Windows Media 9 Player が 直接スタンドアロン Content Engine を指し示すようにするための設定」

RealMedia プロキシ キャッシング

「RealMedia Player が直接スタンドアロン Content Engine を指し示すようにするための設定」

http https ftp 、および rtsp のグローバル設定コマンドの proxy incoming オプションは、プロトコルごとに最大 8 つのポートをサポートします。着信プロキシ ポートは、コマンドラインの 1 行または複数行で最大 8 つまで指定できます。HTTP、FTP、HTTPS、MMS、および RTSP プロトコルのプロキシ スタイル要求は、同一着信プロキシ ポートで受信でます。


) 透過要求とプロキシ スタイル要求は、同一ポートで処理できます。


次の例では、クライアント ブラウザから HTTP、HTTPS、および FTP-over-HTTP のプロキシ要求を直接ポート 81、8080、および 8081 上で受け入れるように、Content Engine を設定する方法を示しています。

ContentEngine(confg)# http proxy incoming 81 8080 8081
ContentEngine(config)# https proxy incoming 81 8080 8081
ContentEngine(config)# ftp-over-http proxy incoming 81 8080 8081
 

ACNS 5.3.1 ソフトウェア リリースで、 ftp キーワードは ftp-over-http ftp-native キーワードで置き換えられました。これは FTP-over-HTTP キャッシングと FTP ネイティブ キャッシングを明確に区別するためです。結果的に、ACNS 5.3.1 ソフトウェア リリースでは、 ftp proxy incoming グローバル設定コマンドは ftp-over-http proxying incoming および ftp-native proxy incoming グローバル設定コマンドで置き換えられました。ACNS 5.3.1 ソフトウェア リリースで追加された ftp-native proxy incoming コマンドは、非透過 FTP ネイティブ キャッシングをサポートするために、FTP クライアントからの FTP ネイティブ要求のための着信ポートを設定するために使用されます。非透過 FTP ネイティブ キャッシングに関するこれ以上の情報は、「非透過 FTP ネイティブ キャッシングの設定」を参照してください。

次の例では、特定のポートで着信 WMT トラフィックを待ち受けるスタンドアロン Content Engine の着信プロキシ ポートを設定する方法を示しています。これらの WMT 要求は、Content Engine を直接指定するように設定されているクライアントの Windows Media Player から Content Engine(非透過フォワード プロキシ)に直接送信されています。デフォルトの WMT ポートは 1755 で、有効なポート番号は、1 ~ 65535 です。

ContentEngine(config)# wmt port incoming portnumber
 

次の例では、特定のポートで着信 RTSP トラフィックを待ち受けするスタンドアロン Content Engine の着信プロキシ ポートを設定する方法を示しています。これらの RTSP 要求は、Content Engine を直接指定するように設定されているクライアントのメディア プレーヤーから Content Engine(非透過フォワード プロキシ)に直接送信されています。デフォルトの RTSP ポートは 554 で、有効なポート番号は、1 ~ 65535 です。

ContentEngine(config)# rtsp port incoming portnumber
 

HTTP、HTTPS、FTP、RTSP、および MMS の着信プロキシ サービスを無効にするには、 no protocol proxy incoming グローバル設定コマンド(たとえば、 no wmt proxy incoming グローバル設定コマンドなど)を使用します。プロキシ モードでポートを追加または除去するには、新規にコマンドを入力して、使用するすべてのポートを指定してください。

SSL トンネリングおよび非透過キャッシングの配置

SSL トンネリング プロトコルを使用して、プロキシ サーバをエンド ユーザとオリジン サーバ間のトンネルとして動作させることができます。クライアントは、HTTP 要求で SSL トンネルを要求します。これにより、Content Engine は https:// url 形式の CONNECT メソッド要求を処理し、HTTP を介した SSL トンネリングが可能となります。


ヒント ブラウザでプロキシが明示的に設定されている場合のみ、ブラウザは HTTPS-over-HTTP 要求を開始します。ブラウザでプロキシが明示的に設定されていない場合、ブラウザは HTTP-over-SSL 接続を開始します。これは TCP ポート 443 上で行われるので Content Engine がACNS 5.1.5 ソフトウェアまたはそれ以降を実効している場合に限り、その要求は Content Engine により代行受信されます。

ポート 443 上の SSL はエンドツーエンドの暗号化を使用するので、クライアントとオリジン サーバの間の透過デバイスにはランダム バイトのストリーム以外何も見えません。


透過モードでのキャッシングおよびストリーミング サービスの配置

ACNS 5.x ソフトウェアでは、WCCP ルータおよびレイヤ 4 スイッチから透過的にリダイレクトされたコンテンツ要求を、スタンドアロン Content Engine は、処理することができます。透過リダイレクトの場合、スタンドアロン Content Engine は、Web クライアントまたは Web サーバ(たとえば、本社のサーバ ファーム内の Web サーバ)に対して透過(見えない)プロキシとして機能します。Content Engine が Web クライアントのプロキシとして動作する場合、それは透過フォワード プロキシ サーバです。Web サーバのプロキシとして動作する場合、Content Engine は透過リバース プロキシ サーバです。

透過フォワード プロキシ キャッシングの概要

スタンドアロン Content Engine を透過キャッシュ(透過フォワード フォワード プロキシ サーバ)として配置する場合、Content Engine を Web クライアントとオリジン サーバの間のユーザ グループの近くに置きます。透過キャッシュは次のとおり、すべての出トラフィックの通過が保証されたネットワーク トラフィックのパスにある次の場所のひとつに置かれます。

ネットワーク エッジ(営業所)

インターネット エッジ(地域本部または本社)

透過リダイレクションの場合、Web クライアントはコンテンツを直接送信先(オリジン サーバ)から要求します。しかし、これらの要求はネットワーク出力ポイントで透過的に代行受信されます。ネットワーク デバイス(WCCP ルータまたはレイヤ 4 Cisco Content Services Switch[CSS] スイッチ)は、これらの要求を透過的に代行受信し、これらのクライアントの透過キャッシング エンジンとして機能している、スタンドアロン Content Engine にリダイレクトします。図3-2 では、WCCP ルータを使用した透過フォワード プロキシ キャッシングの例を示しています。

図3-2 スタンドアロン Content Engine と WCCP ルータを使用した透過フォワード プロキシ キャッシング

 


) レイヤ 4 スイッチまたは WCCP 対応ルータを使用するフォワード プロキシ キャッシングの実装方法に関する詳細については、「透過リバース プロキシ キャッシングの概要」 および 「透過リバース プロキシ キャッシングの概要」 を参照してください。


スタンドアロン Content Engine は、WCCP Version 2 をサポートするか、またはレイヤ 4 CSS スイッチと相互運用して、コンテンツ トラフィックの透過的受信、フォールト トレランス、およびスケーラブルなクラスタを含む、基本レベルの透過性を実現できます。

Content Engine は、クライアントおよびネットワーク オペレーションに対し透過的なので、スタンドアロン Content Engine を階層的に複数のネットワーク ロケーションに容易に配置できます。たとえば、ISP は、インターネットのアクセスが集中するメイン ポイントに スタンドアロン Content Engine(Content Engine A)を配置すると、要求されたコンテンツがインターネットを経由することなく、このメイン ポイントから取得できるため、すべての Point of Presence(POP)利便性を享受できます。

特定の Web クライアントに対しサービスを改善するために、ISP は各 POPにスタンドアロン Content Engine(Content Engine B、C、および D)を配置します。この場合、クライアントがインターネットにアクセスすると、要求はまず、POP の Content Engine にリダイレクトされます。この POP Content Engine(Content Engine B、C、および D)が、ローカル ストレージからの要求に応じられない場合、オリジン サーバに通常の Web 要求を行います。この要求は、アップストリームに送信され、Content Engine A にリダイレクトされます。要求が Content Engine A で満たされると、インターネットのメイン アクセス リンク上のトラフィックは回避されオリジン サーバへの要求が減少し、クライアントへのネットワーク応答時間が短くなります。企業ネットワークでも、同じようにこの階層化透過アーキテクチャが適用できます。

透過キャッシングの配置には、ネットワーク トポロジおよびトラフィック パターンの理解が必要ですが、スタンドアロン Content Engine で透過モード サービスを配置すると、次のような大きな利点があります。

エンド ユーザの設定が不要:デスクトップ設定を変更する必要がない。

フェールセーフ オペレーション:キャッシュは、自動的にフォールト トレラントかつフェールセーフになる。キャッシュに障害があっても、サービスが拒否されない。

スケーラビリティ:複数のキャッシュを配置することにより、キャッシュ サービスを拡張できる(キャッシュ クラスタまたは階層化キャッシュ)。

自動バイパス:エンド ユーザの認証が必要なサイト、または HTTP 標準に適合しないサイトは、自動的に透過キャッシュをバイパスする。

レイヤ 4 スイッチを使用した透過リダイレクションおよびフォワード プロキシ キャッシング

透過リダイレクションにレイヤ 4 スイッチングを使用する場合、レイヤ 4 CSS スイッチは透過的にコンテンツ要求を代行受信し、Content Engine にリダイレクトします。CCS スイッチを経由した透過代行受信では、ユーザは、オリジン サーバに対する要求が、レイヤ 4 CCS スイッチで Content Engine にリダイレクトされることに気付きません。レイヤ 4 CSS スイッチを設定して、動的に要求を分析して、要求されたコンテンツがキャッシングできるかどうかの判断を可能にします。要求されたコンテンツをキャッシングできない場合、レイヤ 4 CSS スイッチは直接、オリジン サーバにその要求を送信します。要求されたコンテンツがキャッシングできる場合、レイヤ 4 CSS スイッチはその要求を Content Engine に送信します。Content Engine は、次のいずれかの方法で要求されたコンテンツをクライアントに送ります。ローカル コピーがある場合は、そのコピーを送り、新しいコンテンツに対する要求である場合は、その要求をオリジン Web サーバに送信します。

レイヤ 4 スイッチングがコンテンツ要求を透過的にスタンドアロン Content Engine にリダイレクトするために使用され、TCP SYN パケットがレイヤ 4 リダイレクション機能がオンになっているレイヤ 4 CSS を経由して通過する場合、パケットはスイッチに接続している Content Engine に進路変更されます。この場合、レイヤ 4 CSS スイッチは、TCP SYN パケットの MAC アドレスを変更し、ゲートウェイまたはオリジン サーバへ出力しないように、MAC アドレスは Content Engine のアドレスに変更されます。そして、レイヤ 4 CSS スイッチはパケットを Content Engine に送信します。これらすべてのアクションはハードウェア内で行われます。

Content Engine は、パケットの IP アドレスが Content Engine のアドレスではない場合でも、受信する要求を受け入れるようにしておきます。そして Content Engine は、WCCP でリダイレクトされるパケットの処理方法と同様、TCP SYN パケットを処理します。

スタンドアロン Content Engine およびレイヤ 4 CSS の透過フォワード プロキシ キャッシングの機能は、次のとおりです。

1. ユーザ(Web クライアント)がブラウザから Web ページを要求します。

2. レイヤ 4 CCS スイッチは、その要求を分析し、要求されたコンテンツがキャッシュ可能であるかどうかを判断します。要求されたコンテンツがキャッシュできる場合、レイヤ 4 CCS スイッチは要求を Content Engine に透過的に送信します。


) すべての Content Engine で透過キャッシングが設定できない場合、レイヤ 4 CSS スイッチは、すべてのクライアント要求をオリジン Web サーバに送信します。


3. Content Engine が、要求されたコンテンツをすでに ローカル キャッシュに保存している場合、要求されたコンテンツをクライアントに送ります。

4. Content Engine に要求されたコンテンツがない場合、次のイベントが発生します。

a. Content Engine は、コンテンツを取得するために オリジン Web サーバと別個の TCP 接続をセットアップします。

b. コンテンツが Content Engine に送られ、保存されます。

5. Content Engine が、要求されたコンテンツを Web クライアントに送信します。これ以降同一コンテンツに対する要求があった場合、Content Engine はローカル ストレージ(キャッシュ)から透過的にその要求を処理します。

WCCP ルータを使用した透過リダイレクションおよびフォワード プロキシ キャッシング

透過キャッシング サービスには、適正に設定されているルータが必要です。ルータは WCCP Version 1 または Version 2 をサポートする Cisco IOS ソフトウェアのバージョンを実行している必要があります。ルータ上でキャッシング サポートが有効になり、Content Engine 上で WCCP サポートが有効になっているデバイスは、設定済みのサービスを使用して通信し配信します。WCCP 対応ルータを使用するには、インターネットに接続されているインターフェイスに IP アドレスが設定されている必要があります。またインターフェイスが、ネットワーク上の Content Engine から見えなければなりません。


ヒント キャッシング サービスを中断するには、個々の Content Engine の電源を切断したり、それ以外の方法で無効にするのではなく、ルータ上でキャッシング サポートを無効にします(たとえば、キャッシングを無効にするには、no ip wccp ルータ コマンドを使用します)。


WCCP を使用すると、ルータは透過的に要求を目的のホスト サイトではなく、Content Engine 上の指定された TCP ポートにリダイレクトします。

WCCP は、WCCP 対応ルータと Content Engine の間の GRE(Generic Routing Encapsulation)トンネル内の UDP ポート 2048 上で動作します。WCCP 対応ルータが IP パケットを受信すると、ルータは、受信したパケットが Content Engine に送信すべき要求かどうか判断します。

WCCP Version 1 のルータは、IP ヘッダー内のプロトコル フィールドに TCP が存在するか調べます。次に、TCP ヘッダー内の宛先ポートに 80 が存在するかも調べます。パケットに TCP と 80 の両方が含まれている場合、そのパケットは Content Engine にリダイレクトされます。WCCP Version 1 の場合、TCP ポート 80 を宛先とする Web キャッシュ情報だけを Content Engine にリダイレクトできますが、多くのアプリケーションでは、他のポートを宛先とするパケットもリダイレクトする必要があります。たとえば、プロキシ Web キャッシュ処理、FTP プロキシ キャッシング、ポート 80 以外の Web キャッシング、RealAudio、およびビデオなどのアプリケーションです。

ルータが WCCP Version 1 ではなく WCCP Version 2 用に設定されている場合は、ルータはポート 80 以外に TCP ポートの Content Engine にトラフィックをリダイレクトするように設定することができます。たとえば、ルータおよび Content Engine の カスタム Web キャッシュ サービス(サービス 98)を設定する場合、ルータは HTTP トラフィックをポート 80 以外のポートの Content Engine にリダイレクトします。そして Content Engine は、これらのリダイレクトされた HTTP 要求のコンテンツをキャッシュするように設定します。このタイプのキャッシングは、WCCP を使用した HTTP 透過キャッシングと呼ばれています。

透過要求とは、ルータから Content Engine にリダイレクトされた要求です。透過要求内の URL のスタイルは、通常、サーバ スタイルです。ただし、別のプロキシ サーバ宛ての要求を Content Engine が代行受信するときは、プロキシ スタイルの場合があります。サーバスタイルの要求には、プロトコルとホスト名が含まれません。ただし RTSP 要求では、サーバスタイルの URL とプロキシスタイルの URL との相異はありません。サーバ スタイルの URL を受信する場合、サポートされるのは HTTP と RTSP だけです(RTSP ユーザ エージェント基準に適合する場合)。プロキシ スタイルの URL を受信した場合、HTTP、HTTPS、FTP、および RTSP がサポートされます(それぞれのプロキシ サービスが設定されている場合)。

リダイレクション方式の WCCP を設定するには、次のタスクを実行する必要があります。

1. 「ルータ上での WCCP サービスの設定」 で説明されているように、ルータの WCCP リダイレクションを有効にします。

2. スタンドアロン Content Engine 上で WCCP を有効にします。WCCP 対応ルータおよび Content Engine でサポートし、特定の WCCP サービス(たとえば、Web キャッシュ サービスなど)を設定します。

このトピックに関する詳細は、「WCCP 透過リダイレクションのスタンドアロン Content Engine の設定」を参照してください。


) サポートされる WCCP サービスの完全なリストについては、表B-3を参照してください。


透過リバース プロキシ キャッシングの概要

応答時間の短縮、サービス アベイラビリティの最大化を図り、過剰な URL ヒット数、または過剰な帯域幅要求にも対応できるようにするには、Content Engine を、Web サイト サーバ ファームの前方に配置できます。この配置は、ファイアウォールやサーバからトラフィックの負荷を軽減して、Web サイト全体のインフラストラクチャを最適化します。このタイプの配置方法は、Web サーバの高速化、またはリバース プロキシと呼ばれます。このように配置された Content Engine は、リバース プロキシ キャッシュと呼ばれています。これは、この Content Engine がトランザクションの相手側の、オリジン サーバの手前で動作するからです。

コンテンツに対する着信要求をオリジン サーバ(サーバ ファームのサーバ)が処理するのではなく、Content Engine(リバース プロキシ サーバ)がこれらの要求を透過的に処理することにより、Web トラフィックは大幅に減少します。リバース プロキシ サーバは、サーバ ファームの拡張に有効です。

リバース プロキシ キャッシュ設定では、プロキシ サーバはインターネット上でルーティング可能な IP アドレスを使用して設定します。クライアントは、ドメイン名の DNS 解決に基づいて、プロキシ サーバに接続されます。リバース プロキシ サーバは、クライアントからはあたかも Web サーバのように見えます。

ACNS 5.x ソフトウェアは、2 つのタイプのデバイス(WCCP Version 2 対応のルータまたはレイヤ 4 CSS スイッチ)で、トラフィックのリダイレクトまたは代行受信を可能にし、リバース プロキシ キャッシングを実行します。図3-3 では、対応ルータを使用した一般的なリバース プロキシ キャッシング配置を示しています。このタイプの配置の場合、Content Engine は WCCP Version 2 対応ルータと相互運用して、Web サーバ環境内でリバース プロキシ サービス(サービス 99)を提供します。Content Engine は、Web サーバ ファームの直前に配置されます。透過および非透過フォワード プロキシ サーバとは異なり、リバース プロキシ サーバは、サーバ ファームの代わりに要求を代理処理して、サーバ ファーム内のサーバからのコンテンツのみをキャッシュします。

図3-3 スタンドアロン Content Engine と WCCP Version 2 ルータを使用したリバース プロキシ キャッシング

 


) ルータ上のリダイレクト リスト、または Content Engine 上のスタティック バイパス リストを使用すると、フローが代行受信をバイパスできるようになります。これらのリストは、送信元および宛先の IP アドレスに基づいた基準を使用します。

WCCP ルータまたはレイヤ 4 スイッチをそれぞれ使用したリバース プロキシ キャッシングの実装方法の詳細については、「例 1 : WCCP 透過リダイレクションを使用したリバース プロキシ キャッシングの配置」 および「例 2 : レイヤ 4 スイッチングを使用したリバース プロキシ キャッシングの配置」 を参照してください。


図3-3 では、インターネットに接続されているルータ インターフェイスの IP アドレスは 192.168.1.1 です。Web サーバ B 宛の HTTP 要求はすべて、172.16.21.1 のルータ インターフェイスにルーティングされます。このインターフェイスで HTTP 要求を受信すると、ルータはこの要求を透過的に代行受信し、IP アドレス 172.16.20.23 の Content Engine にリダイレクトします。このように、Content Engine は論理的に Web サーバ B の手前に配置され、Web サーバの HTTP トラフィックの負荷を軽減します。オリジン サーバのコンテンツを要求している Web クライアントは、リバース プロキシ モードで機能する Content Engine のスタティックな Web ページを受け取ります。これによって、HTTP トラフィックの処理からバック エンド インフラストラクチャが解放されます。

スタンドアロン Content Engine にリバース プロキシ キャッシングを配備する重要な利点は、次のとおりです。

サーバ ファームからスタティック イメージの処理の負担を軽減することで、Web サーバの拡張の代替方法を提供する。

Content Engine を地理的に分散した地域に配置して、これらの区域にコンテンツを複製することができる。

クライアントの設定を変更する必要がまったくない(クライアント ブラウザを設定して、リバース プロキシ サーバとして機能している Content Engine を指定する必要がない)。

例 1 : WCCP 透過リダイレクションを使用したリバース プロキシ キャッシングの配置

次の例では、WCCP 透過リダイレクション(レイヤ 4 スイッチングとは反対)を使用したリバース プロキシ キャッシング サービスの配置方法を示しています。


ステップ 1 スタンドアロン Content Engine 上で WCCP Version 2 を有効にします。(WCCP Version 1 はリバース プロキシ サービスをサポートしていません)

ContentEngine(config)# wccp version 2
 

ステップ 2 ルータ リストを設定します。

ContentEngine(config)# wccp router-list 1 172.16.20.1
 

ステップ 3 リバース プロキシ サービスを実行するように Content Engine に指示します(サービス 99)。

ContentEngine(config)# wccp reverse-proxy router-list-num 1
 

ステップ 4 グローバル設定モードを終了します。

ContentEngine(config)# exit
 

ステップ 5 リバース プロキシ サービスを実行するようにルータに指示します(サービス 99)。

Router(config)# ip wccp 99
 

ステップ 6 以下の手順を実行して、オリジナル サーバに向けてアウトプット リダイレクションを使用するリバース プロキシ サービスを設定します。

a. 設定するルータ インターフェイスを指定します。この例では、イーサネット 0/1 が Web サーバに対するルータ インターフェイスです。

Router(config)# interface Ethernet 0/1
 

b. 指定されたインターフェイス宛ての TCP ポート 80 トラフィックを、リバース プロキシ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。この例では、ルータは 1 つだけです。

Router(config-if)# ip wccp 99 redirect out
 

ステップ 7 以下の手順を実行して、スタンドアロン Content Engine に向けてインプット リダイレクションを使用する reverse-proxy サービスを設定します。

a. 設定するルータ インターフェイスを指定します。この例では、s0/0 がインターネットに対するルータ インターフェイスです。

Router(config)# interface s0/0
 

b. 指定されたインターフェイスで受信される TCP ポート 80 トラフィックを、リバース プロキシ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。

Router(config-if)# ip wccp 99 redirect in
 

ステップ 8 インターフェイス設定モードを終了します。

Router(config-if)# exit
 


 

例 2 : レイヤ 4 スイッチングを使用したリバース プロキシ キャッシングの配置

レイヤ 4 スイッチに基づく リバース プロキシ キャッシングの場合、スタンドアロン Content Engine はレイヤ 4 CSS スイッチと相互運用して、Web サーバ環境内でリバース プロキシ サービスを提供します。この場合、一連の Content Engine は、ローカル キャッシュを使用して Web サーバを高速化します。レイヤ 4 CSS スイッチは、仮想 IP アドレス(たとえば、200.200.200.1)を持つ、負荷バランシング スイッチです。この仮想 IP アドレスは、一般に(サーバからの情報を要求する Web クライアント)公開される Web サーバの IP アドレスです。クライアント要求は最初にレイヤ 4 スイッチに着信し、スイッチにはレイヤ 4 リダイレクション機能があるので、その要求は、レイヤ 4 スイッチに接続された Content Engine(リバース プロキシ サーバ)にリダイレクトされます。要求がキャッシュ ヒットする場合、Content Engine が要求を満たします。要求がキャッシュ ミスする場合、Content Engine は要求をバック エンドの Web サーバに送信し、その結果をキャッシュして、要求されたコンテンツをクライアントに送信します。

リバース プロキシ キャッシングの場合、Content Engine は一般からも透過的で、通常、クライアントは Content Engine(リバース プロキシ サーバ)の存在に気付きません。


) ここで示されているソリューション例は、特定の Web サーバおよび特定の構成でのみ機能します。


次の例では、レイヤ 4 CSS スイッチ(CS150)およびスタンドアロン Content Engine(ce1)に基づくリバース プロキシ キャッシングの設定方法に関するシナリオを示します。


ステップ 1 必要に応じて、負荷バイパス機能をディセーブルにして、確実に Content Engine が要求に対応できるようにします。

ce1(config)# no bypass load enable
 

ステップ 2 レイヤ 4 スイッチを使用したトラフィックのリダイレクトを受け入れるように Content Engine を設定します。

ce1(config)# http l4-switch enable
 

ステップ 3 レイヤ 4 スイッチをリバース プロキシ キャッシング用に設定します。

設定を変更するには、レイヤ 4 スイッチを設定モードにする必要があります。


) レイヤ 4 CSS スイッチを使用したキャッシングの詳細については、『CSS Advanced Configuration Guide』を参照してください。


a. CSS スイッチの所有者を指定します。

CS150(config)# owner cisco
 

b. 現在の所有者に対するリバース プロキシ ルールを作成します。

CS150(config-owner[cisco])# content RPCRule
Create content RPCRule>, [y/n]:y
 

c. リバース プロキシ ルールにサービスを追加します。この場合、スタンドアロン Content Engine(ce1)がサービスとしてリバース プロキシ ルールに追加されます。

CS150(config-owner-content[RPCRule])# add service ce1
 

d. 仮想 IP アドレスを CSS スイッチに割り当てます。

CS150(config-owner-content[cisco-RPCRule])# vip address 200.200.200.1
 

e. サービス プロトコルとして TCP を指定します。

CS150(config-owner-content[cisco-RPCRule])# protocol tcp
 

f. トラフィックに対する要求がポート 80 に到達するように指定します。

CS150(config-owner-content[cisco-RPCRule])# port 80
 

g. キャッシング可能なコンテンツを定義します。

CS150(config-owner-content[cisco-RPCRule])# url "/*" eql Cacheable
 

ステップ 4 CSS スイッチで設定モードを終了します。

CS150(config-owner-content[cisco-RPCRule])# exit

 


 

拡張透過キャッシング機能の使用方法

透過ネットワーク キャッシングの基本原則の 1 つは、Content Engine がエンド ユーザに対して常に透過的でなければなりません。また、透過キャッシング ソリューションが原因でネットワークに何らかの障害が発生したり、副次的に障害を引き起こしたりしないようにする必要があります。

ACNS ソフトウェアでは、クライアント ブラウザが動作しない場合や、Web サーバが HTTP に準拠していない場合でも、WCCP 対応ルータと各種先進テクノロジー等で Content Engine の透過性を確保します。このトピックの詳細は、「スタンドアロン Content Engine の WCCP サービスの設定」を参照してください。

スタンドアロン Content Engine へのストリーミング メディア サービスの配置

ストリーミングとは、すべてのメディア パケットを受信し終わる前に、コンテンツにアクセスまたはコンテンツを表示できる技術です。キャッシングではコンテンツをアクセス可能にする前にコンテンツ全体を受信しておく必要があります。ビデオ オン デマンド(VOD)など、ライブ コンテンツまたはオンデマンド コンテンツとして、ストリーミング メディアを配信できます。

Cisco ACNS ソフトウェアは、数種類の形式のストリーミング メディア ソリューションをサポートしていて、その中には WMT(Microsoft Windows Media Technologies)ソリューション、RealNetworks RealMedia ソリューションなどが含まれています。サポートされているストリーミング メディアのリストは、 表1-3 を参照してください。配置できるストリーミング メディア ソリューションのタイプは、Content Engine が Content Distribution Manager に登録されているか(登録された Content Engine)、またはスタンドアロン Content Engine によって異なります。登録された Content Engines で、 表1-3 にリストされているすべてのソリューションがサポートされます。WMT および RealMedia ソリューションだけがスタンドアロン Content Engine でサポートされます。たとえば、RTSP ベースの Cisco Streaming Engine および Apple QuickTime ソリューションは、スタンドアロン Content Engine でサポートされていません。

スタンドアロン Content Engine に RealMedia ストリーミング サービスを配置する方法については、「スタンドアロン Content Engine の RealMedia サービスの設定」を参照してください。スタンドアロン Content Engine に WMT ストリーミング サービスを配置する方法については、「スタンドアロン Content Engine 上の WMT ストリーミング メディア サービスの設定」を参照してください。

Content Distribution Manager に登録されている Content Engine のためのストリーミング メディア サービスを設定する方法については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。

フィルタリングおよびアクセス制御サービス

スタンドアロン Content Engine にキャッシングおよびストリーミング サービスを設定した後、特定のコンテンツ サービスを設定することができます(たとえば、ルール処理や URL フィルタリング)。ここでは、ユーザのインターネット アクセスを制御するためにスタンドアロン Content Engine を設定する方法の例を示します。この例では、会社が企業のキャッシング エンジンとしてスタンドアロン Content Engine を配置したいと考えているとします。この会社には、さらに、コンテンツ要求の処理について次の特別な要件があるとします。

スタンドアロン Content Engine は、インターネットのアクセスを選択したサブネットのユーザだけに許可し、インターネットのアクセスを特定の Web サイトに限定する必要がある。

スタンドアロン Content Engine は、許可されたサブネットの特定のユーザが許可された Web サイトへアクセスすることをブロックする必要がある。

スタンドアロン Content Engine は、他のすべてのユーザに対して、インターネットへのアクセスをブロックし、ユーザに Web サイトへのアクセス要求は拒否されたことを通知するカスタム メッセージを表示する必要がある。

サイトとユーザは少数のため、会社はサードパーティ製の フィルタリング ソリューション(たとえば、SmartFilter 製品)を実装したいとは考えていない。

この例では、ACNS 5.x ソフトウェアを実行するスタンドアロン Content Engine を使用して、上記要件を満たすソリューションを実装する方法を示しています。


ステップ 1 スタンドアロン Content Engine 上でルール処理を有効にします。

ContentEngine(config)# rule enable
 

ステップ 2 許可されたサブネットに属する選択したユーザが、通常許可されているサイトにアクセスすることをブロックします。この場合、Content Engine は、サブネット 192.168.1.50 およびドメイン .foo\com に属するユーザが通常許可されているサイトにアクセスすることをブロックします。

ContentEngine(config)# rule action block pattern-list 2 protocol all
ContentEngine(config)# rule pattern-list 2 group-type and
ContentEngine(config)# rule pattern-list 2 src-ip 192.168.1.50 255.255.255.0
ContentEngine(config)# rule pattern-list 2 domain .*foo\.com
 

ステップ 3 Content Engine がブロックしたユーザに対して表示するカスタム メッセージを定義します。

a. カスタム メッセージ ファイルを保持するには、local1 または local2 の下に別個のディレクトリを作成してください。

b. ブロッキング メッセージを含む block.html という名前の HTML ファイルを作成します。カスタム メッセージの HTML ページに関連したすべての内蔵グラフィックスを、block.html ファイルと同じディレクトリに必ずコピーしてください 。次の例では、block.html ファイルを示しています。

<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE>
<p>
<H1>
<CENTER><B><I><BLINK>
<FONT COLOR="#800000">P</FONT>
<FONT COLOR="#FF00FF">R</FONT>
<FONT COLOR="#00FFFF">A</FONT>
<FONT COLOR="#FFFF00">D</FONT>
<FONT COLOR="#800000">E</FONT>
<FONT COLOR="#FF00FF">E</FONT>
<FONT COLOR="#00FFFF">P</FONT>
<FONT COLOR="#FF8040">'</FONT>
<FONT COLOR="#FFFF00">S</FONT>
</BLINK>
<FONT COLOR ="#0080FF">Blocked Page</FONT>
</I></B></CENTER>
</H1>
<p>
<p>
<IMG src="/content/engine/blocking/url/my.gif">
<p>
This page is blocked by the Content Engine.
<p>
 

ステップ 4 ブロックされたユーザにカスタム メッセージを送るように Content Engine を設定します。ディレクトリ(dirname) block.html ファイルを指定します。

ContentEngine(config)# url-filter http custom-message dirname
 

この例では、Content Engine がブロックされたサイトへの要求を代行受信したとき、block.html ファイルは次のカスタム メッセージを表示します。

This page is blocked by the Content Engine
 

ステップ 5 Content Engine を設定して、badurl.lst ファイルにリストされている URL に対するクライアントの要求を拒否するように設定します。または、goodurl.lstファイルにリストされている URL に対する要求だけを実行するように設定します。URL リストは、HTTP、HTTPS、および FTP の形式の要求、および MMS や RTSP などのストリーミング メディア プロトコルの要求に適用できます。次の例では特定の HTTP URL を許可し、他のすべての URL を除外する方法を示しています。

c. goodurl.lst と名付けた平文テキスト ファイルを作成します。

d. goodurl.lst ファイルに、独占的に許可したい URL を入力します。goodurl.lst ファイル内の URL のリストは、 http://www.domain.com/ 形式で入力し、改行キーで区切ります。

e. goodurl.lstファイルを、Content Engine の /local1 sysfs ディレクトリにコピーします。


) good リストを保持するために、local1 の下に別個のディレクトリ(たとえば、/local1/filtered_urls)を作成するようにお勧めします。


ステップ 6 Content Engine は goodurl.lst のファイル名を指し示します。

ContentEngine(config)# url-filter http good-sites-allow file local/local1/goodurl.lst
 

ステップ 7 good URL に対するアクセスのみを許可するように Content Engine を設定します。

ContentEngine(config)# url-filter http good-sites-allow enable
 

スタンドアロン Content Engine で URL フィルタリングおよびルールを設定する方法の詳細については、「スタンドアロン Content Engine 上でのコンテンツ事前ローディングと URL フィルタリングの設定」および「スタンドアロン Content Engine の Rules Template の設定」を参照してください。