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

目次

概要

ACNS ソフトウェア ソリューションの概要

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

スタンドアロンの Content Engine について

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

スタンドアロン Content Engine の機能概要

スタンドアロン Content Engine を使用するプロキシ サービス

フォワード プロキシ キャッシング

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

スタンドアロン Content Engine を使用するキャッシングとストリーミング サービス

キャッシングおよびストリーミングのサポート対象プロトコル

スタンドアロン Content Engine のサポート対象 Web クライアント

直接プロキシ ルーティングのサポート対象キャッシングとストリーミング サービス

透過リダイレクションのサポート対象キャッシングとストリーミング サービス

スタンドアロン Content Engine を使用したフィルタリングとアクセス制御

スタンドアロン Content Engine を使用した認証、許可、およびアカウンティング

スタンドアロン Content Engine を使用したモニタリング機能とトラブルシューティング機能

概要

この章では、Cisco Application and Content Networking System(ACNS)ソリューションの概要について説明します。この章の内容は、次のとおりです。

「ACNS ソフトウェア ソリューションの概要」

「スタンドアロン Content Engine の機能概要」


) このマニュアルで使用している「スタンドアロン Content Engine」という用語は、Content Engine をスタンドアロン デバイスとして設定、管理、およびモニタできるように、ACNS 管理者が意図的に Content Distribution Manager に登録していない Content Engine を意味します(存在する場合)。このマニュアルでは、ACNS 5.4.x ソフトウェアを実行しているスタンドアロン Content Engine の配置、管理、モニタに関する内容だけを扱っています。複数のスタンドアロン Content Engine を配置できます(たとえば、スタンドアロン Content Engine をクラスタ構成で配置できます)。スタンドアロン Content Engine を設定するには、Content Engine の CLI(コマンドライン インターフェイス)、Content Engine の GUI(グラフィカル ユーザ インターフェイス)、または ACNS 5.2.1 ソフトウェア リリースで導入された Setup ユーティリティを使用します。

Content Distribution Manager に登録された Content Engine を配置、管理、モニタする方法については、『Cisco ACNS Software Configuration Guide for Centrally Managed Deployments』Release 5.4を参照してください。


ACNS ソフトウェア ソリューションの概要

e-コマース、e-ラーニング、知識共有、企業通信などの e-business アプリケーションが出現するにつれ、ネットワークのトラフィック フローに制御不能なボトルネックが発生することがあります。ACNS ソリューションにより、企業およびインターネット サービス プロバイダー(ISP)は、制御不能なボトルネックからネットワークを保護し、エンド ユーザに豊富なメディア ファイルを効率的に配信できるようになります。手頃な値段で容易にインストレーションできるように設計されたACNS ソリューションでは、高品質ストリーミング ビデオなど、広帯域を必要とする影響力の高いメディアを、最小限の管理で迅速に配置できます。ストリーミングとは、すべてのメディア パケットを受信し終わる前に、コンテンツにアクセスまたはコンテンツを表示できる技術です。これに対し、キャッシングの場合、コンテンツにアクセスする前にコンテンツ全体を受信する必要があります。

ACNS ソフトウェアは、複数のコンテンツ ルーティング方式をサポートしているので、複数の方法で Content Engine にコンテンツをキャッシュできます。ACNS ソフトウェアを組み込んだ Content Engine は、頻繁にアクセスされるコンテンツを透過的またはプロキシ スタイルでキャッシングし、コンテンツ要求を、インターネットまたはイントラネット経由で遠隔地のサーバに送信するのではなくローカル側で満たすことにより、コンテンツ配信を高速化します。

コンテンツをローカル側にキャッシュすることで、Content Engine は WAN リンク上で重複転送されるネットワーク トラフィックを最小限に抑えます。その結果、WAN の帯域幅コストを削減したり、コスト増加を抑制できます。この帯域幅の最適化により、追加ユーザまたは追加トラフィックに使用できるネットワーク容量が増加し、また Voice over IP(VoIP)などの新規サービス用のネットワーク容量も増加します。

たとえば、企業は 1 台または複数の Content Engine を各営業所に配置し、各 Content Engine のアクセス コントロールとフィルタリングを設定した後、これらの Content Engine にコンテンツをプッシュできます。各営業所の Content Engine は特定のポリシーを使用して、コンテンツ要求を拒否するか、受け入れるかを判断します。コンテンツに対するアクセスが受け入れられると、Content Engine は、そのコンテンツのコピーがローカルにキャッシュされているかどうかをチェックします。コンテンツがすでにローカル キャッシュに保管されている場合、Content Engine はクライアントにキャッシュされているコンテンツを送信します。それ以外の場合は、コンテンツをソース(オリジン サーバ)から取得し、コンテンツをキャッシュし、このキャッシュされたコンテンツをクライアントに送信します。Content Engine は、これ以降クライアントから同一コンテンツを要求されると、Content Engine はオリジン サーバから再度コンテンツを取得するのではなく、クライアントにキャッシュされたコンテンツを送信します。配置例については、図1-1 を参照してください。

図1-1 営業所におけるスタンドアロン Content Engine の大規模な配置例

 

この配置例では、クライアントの要求は、Cisco Web Cache Communication Protocol(WCCP)を実行しているルータにより、営業所の Content Engine に透過的にリダイレクトされています。その他のルーティング方式として、レイヤ 4 Cisco Content Services Switch [CSS] スイッチを使用した透過的なリダイレクション、または、直接プロキシ ルーティング(Web クライアントが要求を直接 Content Engine に送信するように明示的に設定)があります。


) Setup ユーティリティを使用すると、Content Engine を迅速に起動し、一般的に使用されるキャッシング サービスのセット(表4-2を参照)をすぐに実行できます。


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

表1-1 に、3 つのタイプの ACNS ネットワーク デバイスを示します。

 

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

デバイス
説明
詳細

Content Distribution Manager

ACNS 5.x ネットワーク デバイス(Content Distribution Manager に登録した Content Router、Content Engine)、コンテンツの獲得と配信、およびサービスの設定とモニタリングを含む、中央集中型のコンテンツおよびデバイス管理ステーションです。個別に管理するのではなく、グループとして中央でデバイス(Content Engine および Content Router)を管理できます。

Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照

Content Engine

要求されたコンテンツをクライアントに提供します。Content Engine は、次のいずれかの方法で配置できます。

スタンドアロン Content Engineとして(このマニュアルで説明する方法)

または

Content Distribution Manager に登録する Content Engineとして(『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照)

スタンドアロン Content Engine の概要については、「スタンドアロンの Content Engine について」を参照

Content Router

コンテンツ要求を、クライアントに最も近い登録済み Content Engine にリダイレクトします。このタイプの要求のリダイレクションを、 コンテンツ ルーティング と呼びます。コンテンツ ルーティングでは、Content Engine が Content Distribution Manager に登録されている必要があります。スタンドアロン Content Engine は、コンテンツ ルーティングをサポートしていません。

Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照


) ACNS デバイスを Content Distribution Manager、Content Engine、または Content Router のどの機能として動作させるかは、ACNS ソフトウェア デバイス モードで決定します。デバイス モードを指定するには、device mode グローバル コンフィギュレーション コマンドを使用します。デフォルトのデバイス モードは、Content Engine です。


次の配置例に示すように、ACNS 5.x ネットワークを運用する場合、3 タイプすべての ACNS ネットワーク デバイスが存在している必要はありません。

配置 A:単一のスタンドアロン Content Engine(Content Distribution Manager および Content Router は使用しない)

配置 B:複数のスタンドアロン Content Engine(Content Distribution Manager および Content Router は使用しない)

配置 C:単一の Content Distribution Manager と、Content Distribution Manager に登録済みの複数の Content Engine(Content Router は使用しない)

配置 D:単一のContent Distribution Manager、Content Distribution Manager に登録済みの複数の Content Engine、および 1 台または複数の Content Router

スタンドアロンの Content Engine について

Content Engine は ローカル ネットワーク上のエンド ユーザ(Web クライアント)の近くにある Content Engine にコンテンツを保存し、配信することにより、すべてのHTTP で配信可能なストリーミング メディア形式のコンテンツ配信を高速化します。 Web クライアント とは、ブラウザまたはメディア プレーヤーを使用してコンテンツまたは情報を要求するエンド ユーザを意味します。サポート対象の Web クライアントの詳細は、「スタンドアロン Content Engine のサポート対象 Web クライアント」 を参照してください。

スタンドアロン Content Engine は、次のいずれかの方法で配置できます。

社内ネットワーク上の企業ファイアウォールの内側に配置

企業ネットワークのエッジに(営業所)に配置


) 複数のスタンドアロン Content Engine を配置できます(たとえば、スタンドアロン Content Engine をクラスタ構成で配置できます)。


スタンドアロン Content Engine は、次のタイプのクライアントからのコンテンツ要求を処理します。

Web ブラウザ(Microsoft Internet Explorer など)

ストリーミング メディア プレーヤー(Windows Media Player、RealMedia Player [ RealPlayer および RealOne Player ] など)。

クライアントからのコンテンツ要求は、次の 1 つまたは複数の方法でスタンドアロン Content Engine にルーティングできます。

直接プロキシ ルーティング。クライアントのブラウザおよびメディア プレーヤーが、非透過フォワード プロキシ サーバとして動作しているコンテンツ エンジンに、要求を直接送信するように設定します。

透過リダイレクション(ルータおよびスイッチが Web 要求を透過的に代行受信し、Content Engine に転送して検査および処理します)。

Cisco WCCP ルーティング

レイヤ 4 スイッチング

透過リダイレクションでは、WCCP 対応ルータまたはレイヤ 4 スイッチは、クライアントの要求を透過的に代行受信し、宛先のサーバではなく Content Engine に要求をリダイレクトします。Content Engine は、宛先サーバのように機能し、要求に応答し、クライアントとの接続を確立します。実際には Content Engine と接続しますが、クライアント側では宛先サーバとの接続が確立されたように見えます。透過リダイレクションの詳細は、「透過モードでのキャッシングおよびストリーミング サービスの配置」 を参照してください。

単一の環境で、1 つまたは複数のルーティング方式を使用できます。たとえば、スタンドアロン Content Engine を設定して、HTTP、FTP-over-HTTP 要求には直接プロキシ ルーティングを使用し、Windows Media Technologies(WMT)要求には透過リダイレクションを使用することができます。Content Engine がサポートするコンテンツ サービスのタイプは、コンテンツ要求をスタンドアロン Content Engine に送信するときのルーティング方式によって決まります。詳細は、「スタンドアロン Content Engine を使用するキャッシングとストリーミング サービス」 を参照してください。


) スタンドアロン Content Engine では、コンテンツ ルーティングはサポートされません。コンテンツ ルーティングを使用する場合は、Content Distribution Manager に Content Engine を登録する必要があります。コンテンツ ルーティングの詳細は、『Cisco ACNS Software Configuration Guide for Centrally Managed Deployments』Release 5.4を参照してください。


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

コンテンツはACNS ネットワーク上の基本要素で、ACNS ネットワークが処理する全データを意味します。コンテンツは、ファイルまたはメディア ストリームで、オンデマンド、事前ロード、事前配信、またはライブで配信できます。コンテンツは、コンテンツの取得、配信、または提供の方法に基づいて分類されます。

表1-2 に、ACNS 5.x ネットワークで配信できる各種のコンテンツ タイプを示します。


事前配信されるコンテンツは、Content Distribution Manager に登録されている Content Engine でのみサポートされます。事前配信されるコンテンツは、スタンドアロン Content Engine ではサポートされませんが、事前ロード コンテンツはスタンドアロン Content Engine でサポートされます。


 

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

コンテンツのタイプ
説明

オンデマンド

ユーザ リクエスト(クライアントが発行した要求)によって取得、キャッシング、および配信されるコンテンツ(図1-1 を参照)。このキャッシング タイプは、 デマンドプル キャッシング と呼ばれています。デマンドプル キャッシングは、透過モード(Content Engine が透過リダイレクションにより要求を受信)または非透過モード(Content Engine が Web クライアントから要求を直接受信)のスタンドアロン Content Engine 上に設定できます。

HTTP 経由で取得し、キャッシュされたコンテンツは、Content Engine のキャッシュ ファイル システム(cfs)ストレージ パーティションに保管されます。2 つのストリーミング プロトコル(WMT および RTSP)により取得し、キャッシュされたコンテンツは、Content Engine のメディア ファイル システム(mediafs)ストレージ パーティションに保管されます。

事前ロード

ユーザのコンテンツ要求を予測し、特定のコンテンツの取得をスケジューリングすることによって取得され、スタンドアロン Content Engine に保管されるコンテンツ。次のタイプのコンテンツは、スタンドアロン Content Engine に事前にロードされます。HTTP URL、FTP-over-HTTP URL、および MMS URL(WMT ストリーミング メディア ファイル)。事前にロードされたオブジェクトには、設定済みのすべての HTTP、FTP-over-HTTP、および MMS のパラメータとルールが適用されます。事前ロードの実行中に、スタンドアロン Content Engine は、コンテンツを取得するために、Web サイトのリンク レベルをスキャンし、特定のコンテンツを取得し、ローカルに保存します。Content Engine は、このコンテンツに対する要求を受信すると、ローカル ストレージからコンテンツを配信します。これにより、WAN 帯域幅を節約し、さらに Web クライアントへのコンテンツ配信を高速化できます。

スタンドアロン Content Engine のコンテンツの事前ロードの詳細は、「スタンドアロン Content Engine の事前コンテンツ ロードの設定」 を参照してください。

事前配信

ACNS ネットワーク管理者が、ユーザのリクエストを予測し、Content Distribution Manager に登録済みの Content Engine にコンテンツの取得と配信を設定することにより、これらの Content Engine ネットワークから取得され、配信されるコンテンツ。

中央管理された ACNS ネットワーク環境で、Content Engine に保管するコンテンツを配信する手段として使用されます。帯域帯を消費するコンテンツ オブジェクト(たとえば、Java アプレット、Macromedia Flash アニメーション、Shockwave プログラムやその他のファイル形式)は、オフピーク時に Content Engine に配信されるように管理され、スケジュールされます。

事前配信コンテンツの管理方法については、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

ライブ

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

WMT ライブ ストリームを配信するスタンドアロン Content Engine の設定方法については、「WMT ライブ ストリームを配信するためのスタンドアロン Content Engine の設定」 を参照してください。

この章の後半では、スタンドアロン Content Engine の配置についてのみ説明します。Content Engine がサポートしているルーティング方式およびコンテンツ サービスは、Content Engine がスタンドアロンで稼働しているか、Content Distribution Manager に登録されているかにより異なります。Content Distribution Manager に登録する Content Engine の詳細については、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

スタンドアロン Content Engine の機能概要

ここでは、スタンドアロン Content Engine の配置の概要について説明します。内容は次のとおりです。

「スタンドアロン Content Engine を使用するプロキシ サービス」

「スタンドアロン Content Engine を使用するキャッシングとストリーミング サービス」

「スタンドアロン Content Engine を使用したフィルタリングとアクセス制御」

「スタンドアロン Content Engine を使用したモニタリング機能とトラブルシューティング機能」

配置例のシナリオは、 第 3 章「スタンドアロン Content Engine の配置シナリオ」 を参照してください。

スタンドアロン Content Engine を使用するプロキシ サービス

スタンドアロン Content Engine は、次に示す重要なプロキシ サービスを提供するプロキシ サーバとして配置されます。

フォワード プロキシ キャッシング

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


) プロキシ サーバは、クライアントからのコンテンツ要求を受け入れる中間サーバです。要求されたコンテンツのコピーがプロキシ サーバのローカル ストレージ(キャッシュ)に保管されている場合、プロキシ サーバは、ローカル ストレージからコンテンツを配信します。それ以外は、オリジン サーバ、または他のプロキシ サーバに要求を転送します。プロキシ サーバは、クライアントおよびサーバの両方として機能します。コンテンツを要求した Web クライアントに対してはサーバとして動作します。また、接続先のサーバ(オリジン サーバまたは他のプロキシ サーバ[指定されたアップストリームのプロキシ サーバなど])にはクライアントとして動作します。プロキシ サーバは通常、プロキシ と呼ばれています。


フォワード プロキシ キャッシング

フォワード プロキシ キャッシングを使用すると、スタンドアロン Content Engine は Web クライアントに対して、プロキシ サーバとして動作します。Content Engine(フォワード プロキシ サーバ)は、内部クライアントがファイアウォール経由でインターネットにアクセスできるようにします。

クライアントのブラウザおよびメディア プレーヤーを明示的に設定し、コンテンツ要求を Content Engine(フォワード プロキシ サーバ)に送信する方法を、 直接プロキシ ルーティング と呼びます。直接プロキシ ルーティングは、クライアントの要求を Content Engine に送信するために使用されます。Content Engine は非透過モードなので、クライアントは要求が Content Engine に送信されていることを認識します。Content Engine は特定のポリシーとルールを使用して、クライアントが要求したインターネット コンテンツへのアクセスを受け入れるか、拒否するかを判断します。このタイプのフォワード プロキシ サービスは通常、企業環境において大規模なインターネット セキュリティ ソリューションの一部として提供されます。このサービスを実装することにより、企業のプライベート ネットワークの完全性を脅かすことなく、エンド ユーザ(Web クライアント)をファイアウォールの外側にアクセスさせることができます。

直接プロキシ ルーティング方式は、最も簡単なルーティング方式です。このルーティング方式は一般的に、ユーザのデスクトップがしっかり管理されている場合に使用されます。そのため、直接プロキシ ルーティングはサービス プロバイダー環境ではなく、一般に企業環境で使用されます。直接プロキシ ルーティングを使用してクライアントの要求を Content Engine に送信する場合のフォワード プロキシ キャッシングの配置例については、図1-2 を参照してください。直接プロキシ ルーティングを使用してクライアントの要求を Content Engine にルーティングする場合のサポート対象キャッシングとストリーミング サービスについては、 表1-5 を参照してください。直接プロキシ ルーティングを使用して、キャッシングとストリーミング サービスを運用する方法の詳細は、「非透過モードでのキャッシングおよびストリーミング サービスの配置」 を参照してください。

図1-2 直接プロキシ ルーティングを使用するフォワード プロキシ キャッシングの配置例

 

直接プロキシ ルーティングと同じ利点をもつ Content Engine を透過フォワード プロキシ サーバとして配置できますが、クライアント デスクトップの設定を変更する必要はありません。このタイプの配置では、クライアントはコンテンツ要求が Content Engine(透過フォワード プロキシ サーバ)にリダイレクトされていることを知りません。透過リダイレクション方式は、WCCP 対応ルータまたはレイヤ 4 スイッチ経由で実装できます。

透過リダイレクション方式を使用するには、ネットワーク トポロジーおよびトラフィック パターンを理解する必要がありますが、クライアント デスクトップの設定を変更する必要がないことから、企業では通常、この方法を優先します。ただし、直接プロキシ ルーティングを使用するには、従来からの要件があります。また企業が特定のサービスに対して、直接プロキシ ルーティングを使用する必要がある場合(たとえば、HTTPS プロキシ キャッシングなど)もあります。これは営業所の WCCP 対応ルータまたはスイッチの設定を変更できないからです。詳細は、「透過リバース プロキシ キャッシングの概要」 を参照してください。

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

リバース プロキシ キャッシングを使用すると、スタンドアロン Content Engine は Web サーバ ファーム内のサーバにはプロキシ サーバとして動作します。また、Web クライアントはその HTTP 要求が透過的に Content Engine(透過リバース プロキシ サーバ)にリダイレクトされていることを知りません。このような配置では、Content Engine は Web サーバ ファーム内のサーバには プロキシとして動作します。


) リバース プロキシ キャッシングとフォワード プロキシ キャッシングとの大きな違いは、リバース プロキシ キャッシングでは、Content Engine は特定のコンテンツ(Web サーバ ファーム内の Web サーバからのコンテンツなど)だけをキャッシュするのに対し、フォワード プロキシ キャッシングでは、Content Engine は必要に応じてコンテンツをキャッシュするということです。


また、リバース プロキシ キャッシングの場合には、スタンドアロン Content Engine は、外部クライアントがファイアウォール経由で内部コンテンツ(会社のイントラネット上のコンテンツなど)にアクセスできるようにします。一般に、このリバース プロキシ キャッシングは、セキュアな Web 公開をするために使用されます。リバース プロキシ キャッシュ設定では、プロキシ サーバに、インターネット上でルーティング可能な IP アドレスを設定します。Web クライアントは、ドメイン名の DNS 解決に基づいて、プロキシ サーバに対する宛先を指示されます。リバース プロキシ サーバは、Web クライアントからはオリジン Web サーバのように見えます。

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

サーバ ファームからスタティック イメージの処理の負担を軽減することで、Web サーバの拡張の代替方法を提供する。リバース プロキシ サーバにコンテンツ着信要求を透過的に処理させることにより、Web トラフィックは大幅に削減します。

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

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

リバース プロキシ キャッシングは、WCCP サービス(サービス 99)です。そのため、ルータと Content Engine は両方ともリバース プロキシ サービスを実行するように設定する必要があります。透過リダイレクションを使用してクライアント要求を Content Engine に送信する場合のサポート対象キャッシングとストリーミング サービスについては、 表1-6 を参照してください。リバース プロキシ キャッシング サービスを運用する方法の詳細は、「透過リバース プロキシ キャッシングの概要」 を参照してください。

スタンドアロン Content Engine を使用するキャッシングとストリーミング サービス

ACNS ソフトウェアは、各種のキャッシングとストリーミング メディア サービスをサポートしています。スタンドアロン Content Engine 上で設定できるサービスのタイプは、コンテンツ要求が Content Engine に対してどのようにルーティングされるかにより異なります。

表1-3 に、Microsoft Windows Media Technologies(WMT)、RealNetworks, Inc. の Real-Time Streaming Protocol(RTSP)ソリューション、Apple Computer、および Cisco Systems. Inc. について、ACNS 5.x ソフトウェアによりサポートされるストリーミング メディア ソリューションを示します。

 

表1-3 ACNS 5.x ソフトウェア ストリーミング メディア ソリューション

ソリューション
ソリューションの説明
スタンドアロン Content Engine
Content Distribution Manager に登録済みの Content Engine

Microsoft WMT

Microsoft の ストリーミング メディア ソリューション。
Microsoft 独自の Microsoft Media Server(MMS)プロトコルを使用します。

Windows Media Services 9(WNS 9)も、RTSP/RTP プロトコル(IETF 標準 RTSP プロトコルおよび独自仕様の拡張機能)をサポートしています。ACNS 5.3 ソフトウェア リリースで、WMS 9-over-RTSP のサポートが追加されました。

Content Engine に WMT プロキシおよびサーバをインストールします。Windows Media クライアントにより、ストリーミング メディア コンテンツが要求されます。

スタンドアロン Content Engine と同じ。

RealNetworks RealMedia

RealNetworks, Inc. のストリーミング メディア ソリューション。RealNetworks RTSP プロトコル(IETF 標準 RTSP プロトコルおよび独自仕様の拡張機能)を使用します。

RealProxy は、インストール可能な、唯一の RealMedia コンポーネントです。RealProxy は、RealNetworks RTSP プロトコルを使用して、RealMedia クライアント(RealPlayer および RealOne Player)にコンテンツを配信します。

すべてのRealMedia コンポーネント(RealProxy および
RealSubscriber など)を Content Engine 上にインストールできることを除いて、スタンドアロン Content Engine と同じです。これは Content Engine が Content Distribution Manager に登録されているからです。

Apple QuickTime

IETF 標準 RTSP プロトコルを使用する、Apple Computer のストリーミング メディア ソリューション。

非サポート

Cisco Streaming Engine が Content Engine 上で動作し、QuickTime 準拠のコンテンツ(MOV および MPEG-1コンテンツ)を
QuickTime クライアントに配信します。

Cisco Streaming Engine

IETF 標準 RTSP プロトコルを使用する Cisco RTSP ベースのストリーミング メディア ソリューション。

非サポート

Content Engine 上でCisco
Streaming Engine を実行し、事前配信コンテンツを配信します。

またローカル ユーザに配信する、ライブ ストリーミング サービスとビデオ オン デマンド(VOD)ストリーミング サービスに対する IP/TV 統合機能をサポートするためにも使用されます。


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


RTSP は、標準のインターネット ストリーミング制御プロトコル(RFC2326)です。RTSP は、アプリケーション レベルのプロトコルで、リアルタイム性を持つビデオやオーディオなどのストリーミング メディア データの配信を制御します。また、このプロトコルは、キャッシングおよび ACNS 環境でのストリーミングメディア プロトコルとして広く普及しています。Apple QuickTime、RealNetworks RealProxy、および Cisco Streaming Engine はすべて、RTSP をストリーミング メディア プロトコルとして使用するバックエンド RTSP サーバです。スタンドアロン Content Engine でサポートされるのは、RealProxy だけです。

RealNetworks RealProxy の機能は、RealNetworks RTSP プロトコルを使用しています。これには、IETF 標準 RTSP プロトコルに RealNetworks 独自の拡張機能が組み込まれています。RealProxy の機能を使用すると、スタンドアロン Content Engine で RealMedia 透過のプロキシ キャッシングをサポートできます。また、RealProxy を使用すると、Content Engine で、キャッシュされた VOD ファイルを RealMedia Player に転送したり、ライブ分割をサポートできます。

RealProxy 機能は、ライセンス対象の RealNetworks ソフトウェアです。この機能を Content Engine 上でイネーブルにするには、RealProxy ライセンス キーを取得する必要があります。このキーは Content Engine に付属する証明書に表示されています。ACNS 5.x ソフトウェアをダウンロードして利用する場合は、Cisco.com Web サイトから RealProxy ライセンスを購入できます。詳細は、「RealMedia サービスの設定」 を参照してください。スタンドアロン Content Engine の RTSP ストリーミング メディア サービスの詳細は、 第 8 章「スタンドアロン Content Engine の RealMedia サービスの設定」 を参照してください。

Cisco Streaming Engine を使用して、RTSP ベースのコンテンツを Content Distribution Manager に登録されている Content Engine に事前配信できます。Cisco Streaming Engine は標準 RTSP プロトコルを使用して、QuickTime 準拠のコンテンツ(MOV および MPEG-1 コンテンツなど)をクライアントに配信します。

Cisco IP/TV は、Cisco コンテンツ ネットワーキング製品ファミリーのメンバーです。Cisco IP/TV の構成は、IP/TV Program Manager、1 台または複数の IP/TV Broadcast Server、および IP/TV Viewer または QuickTime Web プラグインです。IP/TV ネットワークの中央管理プラットフォームである、IP/TV Program Managerは、レコーディング機能だけでなく、ライブ イベントと再ブロードキャスト イベントおよび VOD ファイルのスケジュールを作成したり、ポリシーを設定するためのシンプルなブラウザ インターフェイスを提供します。IP/TV Broadcast Server は、リアルタイム エンコーディング、およびライブ ビデオ、スケジュールされたビデオ、およびオンデマンド ビデオの配信を提供します。

Cisco Streaming Engine を IP/TV ソフトウェア リリース 5.1 以降と組み合わせて使用すると、ライブ ストリーミング サービスと VOD ストリーミング サービスの両方をローカル ユーザに配信できます。次に、ACNS ソフトウェア リリース 5.1 以降と Content Distribution Manager に登録済みの Content Engine を併用した場合の Cisco IP/TV ソリューション(IP/TV リリース 5.1 以降)の 2 つの例を示します。

IP/TV で作成したライブ イベントをレコーディングし、ACNS ソフトウェア リリース 5.1 以降を使用してコンテンツを配信する。

ACNS ソフトウェア リリース 5.1 以降を使用して、IP/TV ライブ イベントまたは再ブロードキャスト イベントの配信をマルチキャスト アイランドまで拡張する。 マルチキャスト アイランド とは、ユニキャスト WAN および マルチキャスト LAN を組み合わせた、マルチキャスト非対応のネットワークまたは環境のことです。

ACNS 5.1 ソフトウェアでは、4番めのデバイス モード(Program Manager)が追加され、特定のデバイスを使用して、IP/TV と ACNS ソフトウェア ネットワーク(リリース 5.1 以降)との統合をサポートできるようになりました。たとえば、Program Manager をデバイス モードとして指定することにより、Content Engine CE-565 または CE-7305 モデルを IP/TV Program Manager として設定できます。デバイス モードの変更をサポートするデバイス上で、Setup ユーティリティを起動すると、デバイス モードを指定するように要求されます。Setup ユーティリティを使用して、デバイスを Program Manager として設定するには、次のようにデバイス モードとして PM を指定します。

What is the mode of the device (CE/CR/CDM/PM) [CE]: PM
 

Cisco IP/TV および Cisco Streaming Engine は、スタンドアロン Content Engine 上ではサポートされません。Cisco Streaming Engine の配置に関する詳細は、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。IP/TV の詳細は、Cisco IP/TV 5.x の製品マニュアルを参照してください。

キャッシングおよびストリーミングのサポート対象プロトコル

Web クライアント(ブラウザまたはメディア プレーヤー)と Web サーバとの通信には、HTTP、MMS、および RTSP などの既存の標準アプリケーション レイヤ インターネット プロトコルを使用します。Content Engine は、これらのすべての Web アクセス プロトコルを使用して、Web オブジェクトを Web クライアントに配信できる必要があります。

表B-1 に、ACNS 5.4.x ソフトウェアを実行している Content Engine が Web クライアントにコンテンツを配信するために使用する、ネットワーク プロトコルを示します。 表B-2 に、スタンドアロン Content Engine でストリーミング メディア ファイルを配信する場合に使用できるストリーミング メディア プロトコル、制御チャネル、対応するデータ形式、および伝送タイプを示します。

HTTP、FTP、TFTP、HTTPS および IETF 標準 RTP/RTSP プロトコルのサポートは、ACNS ソフトウェア製品(ACNS ソフトウェア リリース 5.1 以降)の一部として組み込まれています。次の 2 つの機能をサポートするには、別途ライセンスが必要です。

Microsoft 独自の MMS プロトコルを使用する WMT 機能には、WMT のライセンスが必要です。詳細は、「スタンドアロン Content Engine での WMT RTSP ストリーミングおよびキャッシング サービスの設定」 を参照してください。

IETF 標準 RTSP プロトコルに独自の拡張機能を追加した RealNetworks RTSP プロトコルを使用する RealNetworks RealProxy 機能には、RealProxy のライセンスが必要です。詳細は、「RealMedia サービスの設定」 を参照してください。

スタンドアロン Content Engine のサポート対象 Web クライアント

表1-4 に、ACNS 5.4.x ソフトウェアを実行している、スタンドアロン Content Engine と通信できる Web クライアントを示します。

 

表1-4 スタンドアロン Content Engine のサポート対象 Web クライアント

クライアント プロトコル
クライアント

HTTP プロトコル

HTTP

HTTPS-over-HTTP

MMS-over-HTTP

Microsoft Internet Explorer、Netscape、および HTTP 1.0 または HTTP 1.1 仕様に準拠した他のすべての製品を含む、すべてのインターネット ブラウザ。

Windows Media Player Version 6.x および 7.x では、MMS-over-HTTP を使用して Content Engine にコンテンツを要求できます。

FTP-over-HTTP

FTP-ver-HTTP 要求を発行するクライアント ブラウザ(ACNS ソフトウェア リリース 5.1 以降でサポート)

ネイティブ FTP

非透過プロキシ サーバとして動作する Content Engine に FTP ネイティブ要求を発行する FTP クライアント(Reflection X クライアント、WS-FTP クライアント、Unix または DOS コマンドライン FTP プログラムなど)(ACNS ソフトウェア リリース 5.1 以降でサポート)

Trivial File Transfer Protocol(TFTP; 簡易ファイル転送プロトコル)

TFTP クライアント(ACNS ソフトウェア リリース 5.1 以降でサポート)

RealNetworks 独自の RTSP プロトコル

RealMedia Player は、このプロトコル(IETF 標準 RTSP プロトコルおよび RealNetworks 独自の拡張機能)を使用して Content Engine にコンテンツを要求します。

次のメディア プレーヤーを、まとめて RealMedia Player と呼びます。

RealNetworks, Inc. の RealPlayer(Version 8.x 以降)

RealOne Player

Microsoft 独自の RTSP プロトコル

Windows Media 9 Player は、このプロトコル(IETF 標準 RTSP プロトコルおよび Microsoft 独自の拡張機能)を TCP モードで使用し、Content Engine にコンテンツを要求します(ACNS ソフトウェア リリース 5.3.1 以降でサポート)。

MMS プロトコル

MMS-over-TCP(MMST)

MMS-over UDP(MMSU)

次のメディア プレーヤーを、まとめて WMT プレーヤー と呼びます。

Microsoft Windows Media Player(Version 6.x 以降)

Microsoft Windows Media 9 Player(ACNS ソフトウェア リリース 5.2.x 以降でサポート)

スタンドアロン Content Engine は、ライブ コンテンツまたはオンデマンド コンテンツとしてストリーミング メディア(VOD ファイルなど)を RealMedia Player および WMT プレーヤーに配信できます。スタンドアロン Content Engine は、QuickTime プレーヤーまたは Cisco IP/TV Viewer からの要求をサポートしていません。

直接プロキシ ルーティングのサポート対象キャッシングとストリーミング サービス

表1-5 に、直接プロキシ ルーティングを使用してクライアント要求をスタンドアロン Content Engine に送信する場合のサポート対象キャッシングとストリーミング サービスを示します。アスタリスク(*)は、Content Engine CLI と同様に Setup ユーティリティを使用して特定のキャッシング サービスを設定できることを示しています。

 

表1-5 直接プロキシ ルーティングでのキャッシングとストリーミング サービス

サービス
詳細
従来のキャッシング

HTTP フォワード プロキシ キャッシング*

スタンドアロン Content Engine での非透過 HTTP フォワード プロキシ キャッシングの設定

FTP-over-HTTP キャッシング

スタンドアロン Content Engine での非透過 FTP-over-HTTP キャッシングの設定

FTP ネイティブ キャッシング

非透過 FTP ネイティブ キャッシングの設定

HTTPS プロキシ キャッシング

スタンドアロン Content Engine での HTTPS キャッシングの設定

WMT キャッシングとストリーミング

WMT プロキシ キャッシング*

スタンドアロン Content Engine での WMT キャッシングのイネーブル化と設定

ライブ WMT ストリーミングのストリーミング

WMT ライブ ストリームを配信するためのスタンドアロン Content Engine の設定

事前ロード VOD ファイルのストリーミング

VOD ファイルを配信するためのスタンドアロン Content Engine の設定

RTSP キャッシングとストリーミング

RealMedia プロキシ キャッシング*

直接プロキシ ルーティングおよび RealMedia プロキシ キャッシングの設定

キャッシュされた VOD ファイルとライブ分割の RealProxy ストリーミング

RealMedia サービスの設定

透過リダイレクションのサポート対象キャッシングとストリーミング サービス

表1-6 に、スタンドアロン Content Engine が透過リダイレクションにより要求を受信する場合のサポート対象キャッシングとストリーミング サービスを示します。アスタリスク(*)は、Content Engine CLI と同様に Setup ユーティリティを使用して特定のキャッシング サービスを設定できることを示しています。

 

表1-6 透過リダイレクションでのキャッシングとストリーミング サービス

サービス
詳細
従来のキャッシング

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

スタンドアロン Content Engine での HTTP リバース プロキシ キャッシングの設定

FTP ネイティブ キャッシング

透過 FTP ネイティブ キャッシングの設定

HTTPS 透過キャッシング

スタンドアロン Content Engine での HTTPS 透過キャッシングの設定

HTTP 透過キャッシング*

スタンドアロン Content Engine での透過 HTTP フォワード プロキシ キャッシングの設定

DNS キャッシング

スタンドアロン Content Engine での DNS キャッシング サービス(サービス 53)の設定

WMT キャッシングとストリーミング

WMT 透過キャッシング*

スタンドアロン Content Engine での WMT 透過キャッシングのイネーブル化と設定

WMT ライブ ストリームのストリーミング

WMT ライブ ストリームを配信するためのスタンドアロン Content Engine の設定

事前ロード VOD ファイルのストリーミング

VOD ファイルを配信するためのスタンドアロン Content Engine の設定

RTSP キャッシングとストリーミング

RealMedia 透過キャッシング*

RTSP 透過リダイレクションおよび RealMedia 要求のキャッシングの設定

キャッシュされた VOD ファイルとライブ分割の RealProxy ストリーミング

RealMedia サービスの設定


) RealProxy は、Content Engine CLI または Setup ユーティリティを使用してイネーブルにします。RealProxy をイネーブルにすると、デフォルトの設定ファイルが適用されます。RealProxy のデフォルトの設定を変更するには、RealNetworks RealSystem Administrator GUI を使用する必要があります。RealProxy のデフォルト設定ファイルを元に戻すには、スタンドアロン Content Engine 上で Content Engine CLI を使用して、rtsp real-proxy default-configuration EXEC コマンドを入力します。詳細は、「RealMedia サービスの設定」 を参照してください。


スタンドアロン Content Engine を使用したフィルタリングとアクセス制御

スタンドアロン Content Engine の他の重要な機能は、Web コンテンツに対して、フィルタリングとアクセス制御を行うことです。Content Engine を設定して、そのローカル データベースまたは遠隔地の AAA(Authentication, Authorization, and Accounting; 認証、許可、アカウンティング)サーバを使用して、クライアント要求を認証し、許可することができます。ACNS ソフトウェア(リリース 5.2.1 以降)を使用すると、TACACS+ 経由で AAA アカウンティングも使用できます( 第 18 章「スタンドアロン Content Engine での AAA アカウンティングの設定」 を参照)。

URL フィルタリングおよび Rules Template を使用して、URL へのアクセスをブロックする、または実際のコンテンツ ストリーム(たとえば、特定のヘッダーの書き換えなど)を変更することができます。Access Control List(ACL; アクセス制御リスト)を使用すると、特定のアドレス、アドレスのグループ、またはユーザ グループにフィルタを適用できます。これらのポリシーに加え、帯域幅制限、およびクライアント要求を本当に受け入れるのかどうかを判別するリソース制御があります。


) スタンドアロン Content Engine 上でサポートされるアクセス制御およびフィルタリング サービスは、コンテンツ プロトコルによって異なります(たとえば、HTTP、HTTPS、および FTP-over-HTTP 要求ではアクセス制御がサポートされますが、ICAP がサポートされるのは HTTP および FTP-over-HTTP だけです)。ACNS 5.4.x ソフトウェアを実行しているスタンドアロン Content Engine でサポートされるアクセス制御およびフィルタリング コンテンツ サービスのリストは、表B-5 を参照してください。


ACNS ソフトウェア リリース 5.2.3 以降では、特定の HTTP および HTTPS 要求の URL フィルタリングをバイパスするように、Content Engine を設定することもできます。この機能の詳細は、「特定の HTTP および HTTPS 要求に関する URL フィルタリングをバイパスする Content Engine の設定」 を参照してください。

スタンドアロン Content Engine は、クライアントからのコンテンツ要求を受信すると、次のタスクを実行します。

Web クライアントを認証し、ユーザ名とパスワードを入力するようにクライアントに要求して、AAA サーバに照会し、そのクライアントが、Web にアクセスする許可を得ているかどうかを確認します。このタイプの認証および許可を、 コンテンツ認証 と呼びます。詳細は、「スタンドアロン Content Engine を使用した認証、許可、およびアカウンティング」 を参照してください。

要求を Websens または SmartFilter などのフィルタに通し、要求されたオブジェクトが拒否すべきコンテンツではないことを確認します。詳細は、 第 11 章「スタンドアロン Content Engine 上での事前コンテンツ ロードおよび URL フィルタリングの設定」 を参照してください。


) ACNS 5.x ソフトウェアは、サードパーティ製ソフトウェアを使用して、コンテンツのフィルタリングを実装します。サポート対象のフィルタリング ソフトウェアには、Websense、N2H2、および SmartFilter などがあります。


コンテンツを設定済みのルールと照合し、特定のヘッダーの書き換え、要求のリダイレクション、またはその他の方法による要求の処理を行います。プロトコル単位でのサポート対象のルール アクションについては、 表13-2 を参照してください。スタンドアロン Content Engine 上でのルールの設定方法については、 第 13 章「スタンドアロン Content Engine の Rules Template の設定」 を参照してください。

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

要求されたコンテンツがキャッシュ内に存在しない場合、クライアントに代わって Contene Engine がインターネットからそのコンテンツを取得し、必要に応じて以降の使用に備えてコンテンツをキャッシュします。ACNS 5.x ソフトウェアは、 表B-1 に示す Web アクセス プロトコル(HTTP を含む)およびすべてのストリーミング プロトコルをサポートすることにより、この機能をサポートします。

ACNS ソフトウェア リリース 5.1 以降を実行しているスタンドアロン Content Engine は、Content Engine 上の特定のインターフェイス(サービス)へのアクセスを制御する IP パケット フィルタリングもサポートしています。IP パケットが Content Engine 上の特定のインターフェイスを通過することを許可するかどうかを指定する、IP ACLを設定できます。たとえば、IP ACL を使用して、Content Engine 上のコンテンツ配信および管理サービスへのアクセスを制御できます。詳細は、 第 19 章「スタンドアロン Content Engine での IP アクセス制御リストの作成と管理」 を参照してください。

スタンドアロン Content Engine を使用した認証、許可、およびアカウンティング

ACNS 5.x ソフトウェアは、外部アクセス サーバ(RADIUS または TACACS+ サーバなど)を使用するユーザ、および AAA 機能付きローカル アクセス データベースを必要とするユーザに対して、AAA をサポートします。

認証 (または ログイン )は、ユーザが誰であるかを判別する動作です。ユーザ名とパスワードがチェックされます。

許可 (または 設定 )は、ユーザに何を許可するかを判別する動作です。ネットワーク上の認証されたユーザに権限を付与または拒否します。たとえば、スタンドアロン Content Engine にログインするときに、スーパーユーザ管理者アカウント(事前定義済みの admin アカウントなど)を使用すると、最高レベルのアクセス権限を持つことになり、次のような管理タスクを実行できます。

スタンドアロン Content Engine の設定

スタンドアロン Content Engine が収集した統計情報の取得

デバイスのリロード


) 一般に、認証は許可に優先されますが、必須ではありません。


アカウンティング は、システムのアカウンティングの目的で管理者ユーザのアクティビティを追跡する動作です。ACNS ソフトウェア リリース 5.2.1 以降では、TACACS+ を使用した AAA アカウンティングがサポートされます。詳細は、 第 18 章「スタンドアロン Content Engine での AAA アカウンティングの設定」 を参照してください。

ACNS 5.x 環境には、認証と許可という 2 つの主要なタイプがあります。

コンテンツ認証 ― Content Engine が配信するコンテンツへのエンド ユーザによるアクセスを制御します。詳細は、 第 10 章「スタンドアロン Content Engine のコンテンツ認証および許可の設定」 を参照してください。

管理者ログイン認証 ― モニタ、設定、またはトラブルシューティングを目的とした管理者の Content Engine へのログオン要求を処理する管理者ログイン認証方式(ローカル、RADIUS、TACACS+)を制御します。

管理者はコンソールまたは Content Engine GUI を使用して、スタンドアロン Content Engine にログインできます。これらの管理者ログイン要求を処理するために、Content Engine は指定された認証データベースをチェックし、ユーザのユーザ名とパスワードを確認し、ログイン セッション中に管理者に付与されるアクセス権を判別します。Content Engine はログイン要求を受信すると、ローカル データベースまたは遠隔地のサードパーティ製データベース(TACACS+ データベースまたは RADIUS データベース)をチェックし、ユーザ名とパスワードを確認し、管理者アクセス権を判別します。

これらの認証と許可の方式を任意に組み合わせて設定し、スタンドアロン Content Engine への管理ログイン アクセスを制御できます。

ローカル認証および許可

RADIUS

TACACS+

デフォルトでは、Content Engine は、管理ログイン要求を処理する基本方式として、ローカル ログイン認証方式を使用します。ローカル認証を 1 つまたは複数の他の認証方式とともに使用可能にし、優先順位のフラグを設定していない場合、ローカル認証が常に試行されます。コンソール接続および Telnet 接続には、異なる管理者ログイン認証方式を指定できません。詳細は、 第 17 章「スタンドアロン Content Engine での管理ログイン認証と許可の設定」 を参照してください。


) コンテンツ認証と許可は、管理ログイン認証と許可とは無関係です。


ACNS 5.4.x ソフトウェアを実行しているスタンドアロン Content Engine でサポートされるキャッシング、フィルタリング、および認証メカニズムについては、 表B-4 を参照してください。

スタンドアロン Content Engine を使用したモニタリング機能とトラブルシューティング機能

パフォーマンスを測定して、設定の調整に必要な兆候を見つけたり、Content Engine を追加導入したりするためには、Content Engine をモニタすることが重要です。ACNS 5.4.x ソフトウェアを実行しているスタンドアロン Content Engine のパフォーマンスをモニタする、各種のツールが用意されています。このツール セットには、Cisco Discovery Protocol(CDP)、SNMP(簡易ネットワーク管理プロトコル)、ACNS ソフトウェア アラームが含まれています。詳細は、「スタンドアロン Content Engine のモニタリング」 を参照してください。

Content Engine のパフォーマンスをモニタするだけでなく、トランザクションをモニタする機能もサポートされています。


トランザクションとは、クライアントによる Web リソース要求の完全な成功または失敗を意味します。ACNS 5.x ソフトウェアを実行しているスタンドアロン Content Engine では、レポートの目的で、すべてのエラーとアクセス動作を記録できます。


ACNS 5.x ソフトウェアでは、Content Engine 上の各コンテンツ サービス モジュール(HTTP モジュール、WMT サーバ、FTP プロキシ プロセス、TFTP サーバなど)によって、処理された要求のログが記録されます。ロギングできる要求のタイプは、HTTP 要求、HTTPS 要求、FTP 要求、WMT 要求、RTSP ストリーミング要求、および TFTP 要求です。

各コンテンツ転送プロトコルには、対応する show protocol-name statistics EXEC コマンドがあり、そのプロトコルでの統計情報を表示します。

Content Engine の管理者は、一般的に、Content Engine 上で行われた要求のタイプや要求によってもたらされた結果に注目します。たとえば、ストリーミング メディアが会社の収入源である場合、その会社では、どのお客様がどのコンテンツにアクセスしたかや、ユーザがどれくらいの時間コンテンツを見たか、また、その表示時の品質などをトラッキングする手段が必要になります。これらの会社では、オンデマンド コンテンツやライブ ブロードキャストの配信について課金する必要があるため、コンテンツ アクセス サービスに関するお客様への請求については、記録された情報に基づいて行う必要があります。

Content Engine によって処理される要求を記録するソフトウェア ログのことを、 トランザクション ログ と呼びます。トランザクション ログに記録される一般的なフィールドは、クライアント要求の日付と時刻、要求された URL、キャッシュ ヒットまたはキャッシュ ミス、要求のタイプ、転送されたバイト数、および送信元 IP アドレスです。

トランザクション ログは、通常、次のような目的で使用されます。

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

セキュリティ上の問題分析

コスト分析とプロビジョニング

ACNS ソフトウェア リリース 5.2.1 以降では、Windows Media Services 9 のロギングがサポートされます。Windows Media Services 9 シリーズでは、Windows Media Services Version 4.1 よりもより強固なロギング モデルが提供されています。

事前定義済み形式(たとえば、Squid、Extended Squid、または Apache)または必要なフィールドをログに追加するカスタム トランザクション ログ形式で、データをログに残すことができます。トランザクション ログのコンテンツは定期的に外部サーバに FTP を使用してエクスポートできます。また、ログ ローテーション ポリシーを設定することもできます。


) ロギング形式のタイプは、一度に 1 形式だけ有効になります。Content Engine GUI からトランザクション ロギングをイネーブルにした場合は、Squid ログ形式が使用されます。


ACNS 5.x ソフトウェアは、サニタイズド ロギングもサポートしています。サニタイズド ロギング機能をイネーブルにすると、Web リソース要求のロギングには Web クライアントの識別は含まれません(つまり不明になります)。トランザクション ログ ファイルのクライアントの IP アドレスとユーザ名は、偽装されています。詳細は、「トランザクション ログのサニタイジング」 を参照してください。

ACNS ソフトウェア リリース 5.2.1 以降では、リモート Syslog サーバに HTTP トランザクション ログ メッセージを送信できます。この機能により、リモート Syslog サーバで、HTTP 要求の認証の障害をリアルタイムでモニタできます。詳細は、「HTTP 要求認証エラーのリアルタイムでのモニタリング」 を参照してください。ACNS 5.x ソフトウェアのトランザクション ログの詳細は、「スタンドアロン Content Engine でのトランザクションのモニタリング」 を参照してください。

ACNS ソフトウェア リリース 5.2.3 以降では、Content Engine で特定の URL のパフォーマンスをモニタできます。Content Engine は、モニタ対象の各 URL について、各種の応答特性の統計情報を保持します。詳細は、「スタンドアロン Content Engine でのクリティカル ディスク ドライブのモニタリング」 を参照してください。