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

目次

概要

ACNS 5.1 ソリューションの概要

ACNS ネットワークの概要

中央側で管理する ContentEngine の配置例

ローカル側での ContentEngine の配置例

コンテンツの概要

コンテンツのタイプ

コンテンツ配信

コンテンツ サービス

フィルタリングとアクセス制御を使用したコンテンツ キャッシング サービス

ユーザ認証とコンテンツ フィルタリング

IP パケット フィルタリングおよびアクセス制御

ContentEngine のローカル側への配置シナリオ

透過キャッシング

WCCP 対応のルータを経由した透過的キャッシング

CCS スイッチを経由した透過キャッシング

透過キャッシュ配置の利点

非透過キャッシング

非透過キャッシング配置の利点

リバース プロキシ キャッシング

リバース プロキシ配置の利点

概要

この章では、Cisco Application Content Networking System(ACNS)ソリューションの概要を説明します。また、エンタープライズ環境、およびサービス プロバイダー環境で、キャッシング エンジンとして Content Engine をローカル側に配置するさまざまなシナリオも説明します。

この章の構成は、次のとおりです。

「ACNS 5.1 ソリューションの概要」

「フィルタリングとアクセス制御を使用したコンテンツ キャッシング サービス」

「Content Engine のローカル側への配置シナリオ」


) このマニュアルは、ローカル側に配置され、ACNS 5.x ソフトウェアを実行する Content Engine を設定、管理、および監視する管理者を対象にしています。まず、Content Engine をローカル側に配置するデバイスとして設定するには、自動登録機能をオフにして、Content Engine が Content Distribution Manager に自動的に登録されないようにします。これにより、Content Engine の GUI または CLI を使用して、Content Engine をローカル側に配置するデバイスとして個別に管理できます。Content Engine の GUI を使用して、ローカル側に配置する Content Engine をブラウザ経由でリモート側で設定、管理、および監視できます。また、Content Engine CLI を使用して、ローカル側に配置する Content Engine をコンソール接続、またはターミナル エミュレーション モニタによって設定、管理、および監視できます。

Content Engine をローカル側に配置するデバイスとして初期設定するには、「デバイス ネットワーク パラメータの設定」を参照してください。中央側で管理された ACNS ネットワーク デバイスとして Content Engine を配置、および管理するために Content Engine を使用する方法については、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。


ACNS 5.1 ソリューションの概要

E コマース、Eラーニング、知識共有、企業内通信などの e-business アプリケーションの出現につれ、ネットワークに制御不能なボトルネックが生じてしまうことがあります。ACNS ソリューションは、企業およびインターネット サービス プロバイダー(ISP)において、ネットワークがボトルネックにより、制御不能にならないようにし、数多くのメディア ファイルをエンド ユーザに効率的に配信するのに役立ちます。ACNS ソリューションには、実用性とインストレーションの容易性が組み込まれているため、高品質のストリーミング ビデオなどの、インパクトのある広帯域幅のリッチ メディアを短時間で配信できます。また配信における管理作業は、最少限に抑えられています。

ネットワークにボトルネックが生じないように、ACNS ソフトウェアでは、複数のコンテンツ ルーティング方式を使用し、Content Engine が複数の方法でキャッシュにコンテンツを記録できるようにしています。ACNS ソフトウェアを組み込んでいる Cisco Content Engine は、頻繁にアクセスされるコンテンツを透過的またはプロキシ スタイルでキャッシングし、要求されたコンテンツをローカル側で処理することにより、インターネットやイントラネットを経由して遠方のサーバにアクセスする必要をなくして、迅速にコンテンツ配信をします。

Content Engine は、ハイパーテキスト転送プロトコル(HTTP)や、ファイル転送プロトコル(FTP)のトラフィックなどのコンテンツをキャッシングすることにより、WANリンクを通過する冗長ネットワーク トラフィックを最少限に抑えます。その結果、WAN 帯域幅コストが削減されるか、あるいはコストの増加が緩やかになります。この帯域幅が最適化されることにより、追加ユーザまたは追加トラフィックに使用できるネットワーク容量が増加し、また音声などの新規サービス用のネットワーク容量も増加します。

ACNS ネットワークの概要

表 1-1 で示しているように、Cisco ACNS ネットワークの構成には、最低 1 台の Content Delivery Manager、1 台または複数の Content Engine、および 1 台または複数の Content Router (オプション)が必要です。

 

表 1-1 ACNS ネットワーク デバイスのタイプ

デバイス
説明

Content Distribution Manager

コンテンツおよびデバイスの集中管理を行います。ACNS 5.1 ネットワークでは、Content Distribution Manager がコンテンツの獲得と配信の両方を管理し、中央側で管理される個々の Content Engine 上のポリシー パラメータ、および設定値の管理も行います。

Content Distribution Manager GUI を使用すると、ネットワーク管理者は、配信するコンテンツ内容とその配信先を指定できます。また、ネットワーク管理者は、Content Distribution Manager を使用して中央サイトからネットワーク ノードをモニタしたり、ノード グループに変更(たとえば、ソフトウェアのアップグレード)を適用したりできます。

Content Engine

クライアントが要求するコンテンツを処理します。また、Content Engine は、コンテンツ要求のルーティング、およびコンテンツのチャネル配信でも重要な機能を分担します。

ACNS ネットワークで Content Engine を配置するには、次の方法があります。

インターネット ネットワーク上のファイアウォールの内側に配置する。

企業ネットワークのエッジに配置する。

Content Engine は、中央サイトから Content Distribution Manager を使用して中央側で管理するか、ローカル側でスタンドアロン コンテンツ キャッシュとして個別に管理できます。Content Engine をローカル側で管理するには、Content Distribution Manager ではなく、ACNS ネットワーク ソフトウェア CLI、またはContent Engine GUI を使用します。

このマニュアルは、ローカル側での Content Engine の設定および管理を中心に説明します。中央側での Content Engine の設定および管理については、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。

Content Router

クライアントのコンテンツ要求を、そのコンテンツを保存している最も近い Content Engine に転送します。


) ACNS ソフトウェアのデバイス モードを使用して、デバイスを Content Distribution Manager、Content Engine、または Content Router として機能するように指定します。


中央側で管理する Content Engine の配置例

図 1-1 では、企業の中央側で管理する Content Engine の一般的な配置を示します。この例では、企業のデータ センターの Content Distribution Manager が中央側で管理している Content Engine が、各営業所に配置されています。Content Distribution Manager は、中央の情報技術(IT)スタッフが管理します。データ センターには Content Router を配置することもできます。

企業のエッジにある営業所は、低速リンク(64 kbps またはそれ以下)を使用して企業のデータ センターに接続します。さらに、同じ地域内の営業所は、地域本部のデータ センターに接続し、さらに限定帯域リンクを使用して本社に接続できます。

図 1-1 中央側で管理する Content Engine の企業内での一般的な配置例

 


) 中央側での Content Engine の配置および管理については、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。


ローカル側での Content Engine の配置例

図 1-2 では、ACNS 5.x をインストールした Content Engine を企業内に配置する一般的な例を示します。この例では、3 台の Content Engine(Content Engine A、B、および C)が、中央サイト、地域サイト、および小規模の営業所にローカル キャッシング エンジンとして配置されています。すべての Content Engine は、Content Engine の GUI または CLI を使用してローカル側で管理されます。

図 1-2 ローカル側で管理する Content Engine の企業内での一般的な配置例

 

図 1-3 では、ローカル側で管理される Content Engine の ISP での配置例を示しています。この例では、ISP は、Content Engine を階層的に複数のネットワーク ロケーションに配置します。Content Engine(Content Engine A)は、ISP がインターネットへアクセスするメイン ポイント(main point)に配置されます。要求されたコンテンツがインターネットを経由することなく、このメイン ポイントから得られるので、ISP のすべての Point of Presence(POP)は、利益を受けます。

図 1-3 ローカル側で管理される Content Engine の ISP での一般的な配置例

 

ネットワーク キャッシングには、次の利点があります。

応答時間の短縮

ネットワーク帯域幅の節約

コストの低減

ネットワーク リソースの最適使用

管理者は、ACNS 5.1 ソフトウェアを使用して、ローカル側の Content Engine 上の特定のインターフェイスへのアクセスも管理できます。このトピックの詳細は、「IP パケット フィルタリングおよびアクセス制御」を参照してください。

コンテンツの概要

コンテンツとは、ACNS ネットワーク上の基本エレメントであり、ACNS ネットワークが処理するすべてのデータのことです。コンテンツは、ファイルまたはメディア ストリームの形であり、オンデマンド、事前ロード、事前配信、またはライブに分類されます。

コンテンツのタイプ

コンテンツは、その獲得、配信、またはサービスの方法に基づいて分類されます。 表 1-1 では、ACNS 5.1 ネットワークで配信できる各種のコンテンツ タイプを説明します。


) 「クライアント」という用語は、コンテンツまたは情報を要求するデバイスを示すために使用されます。たとえば、このマニュアルでは、ブラウザを使用して情報を要求するエンド ユーザは、「Web クライアント」と呼ばれます。


 

表 1-2 ACNS ネットワークで配信されるコンテンツ タイプ

コンテンツ タイプ
説明

オンデマンド

ユーザの要求(クライアントによる要求)によって獲得、キャッシング、および配信されるコンテンツ。クライアントが最初にコンテンツを要求すると、コンテンツはオリジン Web サーバから取り出され、最適の Content Engine を経由してクライアントに提供されます。この Content Engine は、そのコンテンツの保存またはキャッシングも行います。

事前ロード

Content Engine の管理者が、ユーザのコンテンツ要求を予測して特定のコンテンツの取得をスケジュールすることにより、検索され、個別の Content Engine に保存されたコンテンツ。HTTP または FTP を使用して特定のコンテンツ項目を事前ロードするように、Content Engine を設定できます。Web サイトは、いくつかのリンク レベルまで下がってスキャンされ、コンテンツが検索されます。ネットワーク使用状況を良好な状態に管理するために、帯域幅の限界を指定して事前ロード コンテンツを設定できます。ローカル側に配置する Content Engine の事前ロード コンテンツの詳細は、「コンテンツ事前ローディングの設定」を参照してください。

事前配信

ACNS ネットワーク管理者がユーザの要求を予測して、コンテンツの獲得および配信を設定することにより、中央側で管理されている Content Engine のネットワークから取得および配信されるコンテンツ。このコンテンツは、中央側で管理された ACNS ネットワーク環境で、Content Engine に保存されるコンテンツを配信する手段として使用されます。帯域帯を消費するコンテンツ オブジェクト(たとえば、Java アプレット、Macromedia Flash アニメーション、Shockwave プログラムやその他のファイル形式)は、オフピーク時に Content Engine に配信されるように管理され、スケジュールされます。事前配信コンテンツの管理の詳細は、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。

ライブ

オリジン サーバからブロードキャストされるコンテンツ ストリーム(一般的には、ストリーミング メディア)。(このコンテンツは、衛星放送または地上放送のどちらかのソースからライブ ストリーミング ブロードキャストとして獲得されます。) ACNS 管理者は、ライブ マルチメディア ストリームの取得に関連したポリシー(たとえば、プログラムをリストする URL (再生リスト)、最大ビット レートなど)、および配信ポリシー(たとえば、優先順位、スケジュール、最大帯域幅)を設定します。


ヒント 事前配信コンテンツは、中央側で管理する ACNS ネットワーク環境に関連付けられます。一方、キャッシュの事前ロードは、Content Engine 単位で設定され、一般に、中央側で管理される ACNS には関連付けられていません。


コンテンツ配信

表 1-3 では、ACNS 5.1 ネットワークでコンテンツを配信するために使用できる配信タイプを説明します。

 

表 1-3 ACNS ネットワークでのコンテンツ配信タイプ

コンテンツ配信タイプ
説明

プル

Content Engine は、要求されたコンテンツをローカル キャッシュに保存していないので、リモート オリジン サーバからそのコンテンツを取得(プル)します。

このプル配信方式は、Content Engine が透過、プロキシ、またはリバース プロキシのいずれかのモードで動作し、要求されたコンテンツがローカル キャッシュにない場合(キャッシュ ミス)に使用されます。Content Engine は、要求されたコンテンツをオリジン Web サーバから取得し、そのコンテンツをローカル キャッシュに保存してから、要求したユーザ(Web クライアント)にそのコンテンツを配信します。それ以降に、このコンテンツに対してユーザの要求がある場合、Content Engine は、そのコンテンツをオリジン Web サーバから再度取得するのではなく、ローカル キャッシュからエンド ユーザ(Web クライアント)にそのコンテンツを配信します。

事前ロード

Content Engine の管理者が、ユーザのコンテンツ要求を予測して、コンテンツの取得をスケジュールしたので、そのコンテンツが個別の Content Engine に事前ロードされます。

事前配信

ACNS ネットワーク管理がユーザの要求を予測して、コンテンツの獲得および配信を設定しているので、コンテンツは、中央側で管理された Content Engine のネットワーク経由で取得および配信されます。

コンテンツ サービス

ACNS 5.1 ネットワークでは、1 つのソフトウェア ベースに、2 つのタイプのコンテンツ サービスを組み合わせます。 表 1-4 では、2 つのタイプのコンテンツ サービスを説明します。

 

表 1-4 ACNS ネットワークでのコンテンツ サービスのタイプ

コンテンツ サービスのタイプ
説明

コンテンツの事前配信

営業所管理者は、ユーザ要求を予測して、特定の時刻に Content Engine に「プッシュ」するコンテンツ オブジェクトのグループを指定できます。たとえば、管理者は、オフピーク時(深夜)に遠隔地の営業所の Content Engine にプッシュするコンテンツ オブジェクトのグループを指定できます。中央側で管理される ACNS ネットワークでの事前配信コンテンツの詳細は、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。

フィルタリングとアクセス制御を使用したコンテンツ キャッシング

コンテンツ キャッシングは、情報をローカル側に保存し、格納します。最近要求されたコンテンツのコピーは、Web クライアント(コンテンツを要求しているエンド ユーザ)に対して位置的に最も近いロケーションにある Content Engine に一時保存されます。したがって、コンテンツは、クライアントが再度同じコンテンツを要求した場合にすぐに再利用できます。ACNS 5.x ソフトウェアがインストールされている Content Engine では、フィルタリングとアクセス制御を使用したコンテンツ キャッシングもサポートしています。

このトピックの詳細は、「フィルタリングとアクセス制御を使用したコンテンツ キャッシング サービス」を参照してください。

Cisco ACNS ソフトウェアにより、次のインターフェイスを使用して、コンテンツ サービスを管理できます。

中央側で管理された ACNS ネットワークの Content Distribution Manager。これは、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』に説明されています。

このマニュアルに説明されている、ローカル側に配置する Content Engine の Content Engine の GUI または CLI。


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


フィルタリングとアクセス制御を使用したコンテンツ キャッシング サービス

インターネット ユーザにとって、Web ページがブラウザにロードされるまで待たされるほどいらいらさせられるものはありません。Web コンテンツの配信が遅くなる一因には、いくつかの要素、たとえばインターネット輻輳、Web サーバーの過負荷、低速な WAN アクセス回線などがあります。低速な Web アクセス、および遅延を解消するためのコスト効率のよい解決策の 1 つは、コンテンツをインターネットのエッジに「プッシュ」し、エンド ユーザの近くに保存することです。

シスコの Content Engine および WCCP 対応ルータを組み合せると、コンテンツをネットワークのエッジにプッシュすることで、コンテンツ配信を高速化し、WAN 帯域幅の使用量を最適化する強力なソリューションになります。これを実行するために使用されるメカニズムは、「コンテンツ キャッシング」と呼ばれます。また、コンテンツ キャッシングは、「ネットワーク キャッシング」とも呼ばれます。

Content Engine は、まるでエンド ユーザ(Web クライアント)とインターネット間の「インライン」デバイスとして特別に位置づけられているので、ネットワーク キャッシュとして容易に設定できます。頻繁にアクセスされるインターネット コンテンツは、各ロケーションの Content Engine がローカルにキャッシュ、および配信するので、帯域幅の使用量と Web 遅延が大幅に減小します。図 1-4 を参照してください。

図 1-4 ネットワーク キャッシングの利点

 

ネットワーク キャッシングにより、企業およびサービス プロバイダーは、次の利点が得られます。

応答時間の短縮

インターネット輻輳の減少

ネットワーク帯域幅の節約

ネットワーク リソースの最適使用


ヒント オブジェクトはキャッシュされますが、ページはキャッシュされません。このトピックの詳細は、「キャッシング可能なコンテンツ」を参照してください。


Content Engine は、フィルタリングおよびアクセス制御を使用したネットワーク キャッシングを行うように設定できます。

ユーザ認証とコンテンツ フィルタリング

Content Engine は、多数の認証サービスとコンテンツ フィルタリング サービスを行うように設定できます。Content Engine は、要求を受信すると、次のタスクを実行します。

Webクライアントを認証し、ユーザ名とパスワードを入力するようにクライアントに要求して、authentication, authorization, and accounting(AAA; 認証、許可、アカウンティング) サーバに照会し、そのクライアントが、Web にアクセスする許可を得ているかどうかを確認する。

要求をフィルタ(Websense や SmartFilter など)を通し、要求されたオブジェクトが好ましくないコンテンツでないことを確認する。


) ACNS 5.1 ソフトウェアでは、サードパーティ製ソフトウェアを使用して、コンテンツのフィルタリングを実行します。サポートされているフィルタリング ソフトウェアには、Websense、N2H2、および SmartFilter などがあります。


コンテンツを設定済みのルールと照合し、特定のヘッダーへの再書き込み、要求の転送、またはその他の方法による要求の処理を行う。

要求されたコンテンツがすでに Content Engine のキャッシュ内に存在しているかどうかを確認する。キャッシュ内に存在する場合、Content Engine は、オリジン サーバからではなく、自身から直接オブジェクトを送信して、インターネットを使用する帯域幅を節約します。

要求されたコンテンツがキャッシュ内に存在しない場合、クライアントに代わって Contene Engine がインターネットからそのコンテンツを取得し、必要に応じて以降の使用に備えてコンテンツをキャッシュに保存する。

この機能は、一般に「プロキシ」機能と呼ばれます。Cisco ACNS 5.1 ソフトウェアでは、すべての Web アクセス プロトコル(HTTP を含む)、およびすべてのストリーミング プロトコルをサポートして、Content Engine のプロキシ機能をサポートしています。

図 1-5 に示すように、ログインおよび設定の権限は、Content Engine のローカル データベース、またはリモート側のいずれかのサードパーティ製データベース(TACAC+ データベースまたは RADIUS データベース)から取得できます。

図 1-5 認証データベースおよびローカル側に配置された ACNS Content Engine

 

たとえば、BigCorp Enterprise が、次のポリシー、セキュリティ、および経費節減の目標を確実に実現したいものとします。

正社員だけが Web にアクセスする。

社員は、企業ネットワークを通じて好ましくないコンテンツにアクセスできない。

「Code Red」などのウィルスが企業ネットワーク内で広がるのを防ぐ。

企業の ISP への毎月の支払いを減らす。

BigCorp Enterprise は、ネットワークのエッジに Content Engine を配置して、ここから企業ネットワークがインターネットとのインターフェイスをもつようにし、遠隔地の営業所にも Content Engine を配置すれば、前述の目標をすべて実現できます。Content Engine は、エンド ユーザからのコンテンツ要求を代行受信し、前述のポリシーを実施できます。


) ユーザ認証および認証の設定の詳細は、「認証および許可の設定」を参照してください。
Rules Template およびコンテンツ フィルタリングの詳細は、「Rules Template の設定」「URL フィルタリングの設定」を参照してください。


IP パケット フィルタリングおよびアクセス制御

ACNS 5.1 ソフトウェアをインストールした Content Engine は、IP パケット フィルタリングもサポートしています。これにより、Content Engine 上の特定のインターフェイス(サービス)へのアクセスが管理されます。ルータおよびスイッチと同様に、管理者は Telnet、SSH、および Content Engine GUI を通じた IT ソース サブネットへのアクセスを管理できます。管理者は、Content Engine 上の特定のインターフェイスを IP パケットが通過することを許可するかどうかを指定する、IP アクセス コントロール リスト(ACL)を設定できます。

たとえば、管理者は IP ACL を使用して、Content Engine 上のコンテンツ配信および管理サービスへのアクセスを管理できます。図 1-6 で示すように、このアクセス管理機能を実行するために、管理者は Content Engine 上で 2 つの別個のインターフェイスを定義しています。

企業のすべての従業員がアクセスできるコンテンツ サービス用のパブリック インターフェイス。

企業の IT スタッフのみがアクセスできる管理サービス(たとえば、Telnet、SSH [Secure Shell]、SNMP [Simple Network Management Protocol]、HTTPS [Hypertext Transfer Protocol Secure]、および TFTP [Trivial File Transfer Protocol])用の別のインターフェイス(プライベート インターフェイス)。

図 1-6 Content Engine 上の特定のインターフェイスへの IP パケット フィルタリング アクセス

 


) ACL は、個々のデバイスのみに定義されます。ACNS ネットワーク経由で、またはデバイス グループで ACL を一括管理することはできません。


ローカル側に配置する Content Engine での IP ACL の設定の詳細は、「IP アクセス コントロール リストの作成および管理」を参照してください。

Content Engine のローカル側への配置シナリオ

Content Engine は、次の 3 つの基本的な設定のいずれかで、ローカルに管理される ACNS ネットワーク デバイスとして、配置できます。

透過キャッシング

非透過(プロキシ)キャッシング

リバース プロキシ キャッシング


) 中央側で管理される ACNS ネットワーク デバイスとして Content Engine を配置するには、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。


Cisco ACNS ソフトウェアは、既存のプロキシ インフラストラクチャと統合するために、FTP、HTTPS、HTTP 1.0、および HTTP 1.1 を含む、多数のプロキシ プロトコルをサポートします。ACNS システム管理者は、Rules Template 機能を使用して、プロキシ ポリシーを作成し、トラフィックが代理処理される方法を管理します。

Cisco Content Engine を Web サイトの前面に配置して(リバース プロキシ)、コンテンツに対する着信要求を透過的にキャッシングし、オリジン Web サーバが実行するトラフィックと TCP 接続メンテナンスを大きく減少させることができます。

透過キャッシング

透過キャッシングでは、Content Engine の存在はユーザに気付かれることはありません。ユーザ(Web クライアント)は、ブラウザにオリジン サーバの URL を入力して、ソース(オリジン Web サーバ)に直接コンテンツ(Web オブジェクト)を要求します。この要求は、WCCP 対応ルータまたはレイヤ 4 CCS スイッチによって代行受信されます。

Content Engine は、WCCP Version 2 をサポートするか、または Cisco Content Services Switch(CSS) 11000 シリーズ スイッチと相互動作することにより、次の基本レベルの透過性を実現できます。

コンテンツ トラフィックの透過的受信

フォールト トレランス

スケーラブルなクラスタ作成


) Cisco CCS 11000 シリーズ スイッチは、これ以降 CCS スイッチと記述します。


これらの高度な透過キャッシング サービスの詳細は、「拡張透過キャッシング機能」を参照してください。

WCCP 対応のルータを経由した透過的キャッシング

図 1-7 では、WCCP 対応ルータおよび Content Engineを使用した透過キャッシングの動作を示します。

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

2. WCCP 対応ルータは、その要求を分析し、TCP 宛先ポート番号に基づいて、その要求を透過的に Content Engine に宛先変更するかどうかを決定します。

3. その要求が Content Engine に透過的に転送されると、次の動作が発生します。

a. Content Engine が要求されたコンテンツを保存していない場合、Content Engine はコンテンツを取得するために、オリジン Web サーバとの TCP 接続を個別にセットアップします。

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

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

図 1-7 WCCP 対応のルータを経由した透過キャッシング

 


ヒント WCCP は、非対称パケット フローも処理できます。また WCCP は、WCCP サービス グループで使用されるスイッチまたはルータの数(最高 32 台のルータまたはスイッチが、クラスタ内の最高 32 個のキャッシュと通信します)に関係なく、Web サーバからキャッシュへの一貫したマッピング情報を常に保持しています。


CCS スイッチを経由した透過キャッシング

レイヤ 4 CCS スイッチを経由した透過キャッシングでは、ユーザは、オリジン サーバに対する要求が、CCS スイッチにより Content Engine に宛先変更されることに気付くことはありません。CCS スイッチを設定して、CCS スイッチが動的に要求を分析し、要求されたコンテンツをキャッシングできるかどうかを判断するようにできます。キャッシングができない場合、CSS スイッチは直接、オリジン Web サーバにその要求を送信します。要求されたコンテンツがキャッシングできる場合、CCS スイッチは直接その要求を Content Engine に送信します。Content Engine は、ローカル コピーがある場合は、要求されたコンテンツをユーザに送り、そのコンテンツに対する新しい要求である場合は、その要求をオリジン Web サーバに送信します。

Content Engine には、スタティック データ(つまり、HTML、Audio Video Interleaved [AVI]、Joint Photographic Experts Group [JPEG]、または Graphics Interchange Format [GIF] のファイル)が保存されます。コンテンツがキャッシングの対象になる要求では、その要求は URL に基づいて複数の Content Engine に負荷を分散できます。実稼働の環境では、要求を処理するための負荷は、ドメイン名に基づいて分散される場合もあります。

図 1-8 では、CCS スイッチおよび Content Engine を使用した透過キャッシングの動作を示します。

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

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


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


3. Content Engine に要求されたコンテンツがない場合、次の動作が発生します。

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

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

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

図 1-8 CSS 11000 シリーズ スイッチを使用した透過キャッシングのネットワーク

 

透過キャッシュ配置の利点

透過モードでキャッシュを配置する場合、次のような大きな利点があります。

エンド ユーザによる設定が不要:ユーザは、Content Engine をポイントする必要がない。

フェールセーフ オペレーション:キャッシュは、自動的にフォールト トレラントかつフェールセーフになる。キャッシュの障害により、エンド ユーザに対してサービスが拒否されることはない。

スケーラビリティ:複数のキャッシュを配置することにより、キャッシュ サービスを拡張できる。

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


) 透過キャッシングの詳細は、「透過キャッシング」を参照してください。


非透過キャッシング

非透過(プロキシスタイル)キャッシングでは、ユーザ(Web クライアント)は Content Engine にすべての要求を明示的に送信し、Content Engine は、Web クライアントのプロキシの役割を果たします。

図 1-9 では、Content Engine がプロキシ モードでコンテンツをキャッシュする方法を示します。

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

2. Content Engine に要求されたコンテンツがない場合(キャッシュ ミス)、次の動作が発生します。

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

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

3. Content Engine が、コンテンツをユーザに送ります。

4. 以後、同じコンテンツに対して、同じユーザまたは別のユーザから要求があるときは、この要求は、Content Engine 自体のローカル ストレージから透過的に処理されます(キャッシュ ヒット)。

図 1-9 プロキシ モードで Content Engine を使用する Web キャッシング

 


ヒント 非透過キャッシングでは、Content Engine を指定するように Web クライアントを明示的に設定する必要があります。多数のクライアントをサポートする複数の Content Engine を使用しているときは、.pac ファイルを使用して、ブラウザ クライアントのすべてを設定できます。1 つの .pac ファイルを使用して、各種組織内のすべてのブラウザを設定する方法については、「ブラウザの自動設定」を参照してください。


非透過(プロキシスタイル)キャッシングの詳細は、「プロキシ モードの動作」を参照してください。

非透過キャッシング配置の利点

非透過(明示プロキシ)の配置では、Content Engine は、ユーザ グループの代わりに要求を代理処理するプロキシ キャッシュの役割をします。これらの配置のタイプでは、Content Engine は、ユーザ(クライアント)グループの代わりに Web ページを取得し、保存するために最適化された、ネットワーク ゲートウェイ デバイスとして機能します。

Content Engine は、ブラウザが開始したすべてのコンテンツ要求の宛先となるため、ユーザがインターネットからコンテンツを取得する前に、すべてのユーザのインターネット接続要求は、ポリシー ガイドラインに合致している必要があります。

非透過(明示プロキシ)モードで Content Engine を配置すると、次のような大きな利点がいくつかあります。

プロキシがゲートウェイ デバイスであるため、インターネット アクセスを規制できる。

すべてのインターネット要求は、プロキシ キャッシュ(Content Engine)から発信されるように見えるので、内部ネットワーク アドレッシングを隠蔽できる。

頻繁に要求されるキャッシング可能なコンテンツをキャッシングする。


) Content Engine をプロキシ キャッシング エンジンとして配置するには、「プロキシ型キャッシング」を参照してください。


リバース プロキシ キャッシング

リバース プロキシ キャッシング モードでは、Content Engine は、オリジン Webサーバのプロキシの役割をします。

図 1-10 では、Content Engine がリバース プロキシ モードでコンテンツをキャッシュする方法を示します。

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

2. WCCP 対応のルータがこの要求を代行受信し、これを Content Engine に転送します。

3. 要求されたコンテンツが Content Engine にない(キャッシュ ミスである)場合、Content Engine は、コンテンツを取得するために、オリジン Web サーバとの接続をセットアップします。

4. コンテンツの提供者側にある Content Engine は、オリジン Web サーバに対するリバース プロキシのように作動し、要求されたコンテンツを配信しようとします。

5. リバース プロキシ モードにある Content Engine が、このコンテンツを保存していない場合は、この Content Engine は、オリジン Web サーバとの接続をセットアップして、要求されたオリジナル コンテンツを取得します。

6. コンテンツが、企業側にある Content Engine に送られ、保存されます。

7. 企業側にある Content Engine が、コンテンツを Web クライアントに送信します。

以後、同じコンテンツに対して、同じユーザまたは別のユーザから要求があるときは、この要求は Content Engine 自体のローカル ストレージから透過的に処理されます(キャッシュ ヒット)。

図 1-10 リバース プロキシ モードで稼働する Content Engine

 


) リバース プロキシ キャッシングの詳細は、「リバース プロキシ キャッシングの概要」を参照してください。


リバース プロキシ配置の利点

リバース プロキシ配置では、Content Engine は、オリジン Web サーバから頻繁に使用されるページ、または静的ページをオフロードして、Web サーバのパフォーマンスを高速化します。オリジン Web サーバにオブジェクトを要求するユーザは、オリジン サーバから受け取るのではなく、リバース プロキシ モードで稼働する Content Engine から静的ペ-ジを受け取ります。

リバース プロキシ モードで Content Engine を配置すると、次のような大きな利点がいくつかあります。

Web サーバ拡張の代替手段を提供する。

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


) Content Engine をリバース プロキシ キャッシング エンジンとして配置するには、「リバース プロキシ キャッシング」を参照してください。