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

目次

ACNS ネットワークのコンテンツ取得設定

事前配信コンテンツの取得の準備

取得機能の概要

オリジン サーバの設定

HTTP と HTTPS の使用

FTP の使用

MMS と MMS-over-HTTP の使用

チャネルの作成

ルート Content Engine の割り当て

バックアップ ルート Content Engine の割り当て

チャネルのコンテンツ取得方法の選択

Content Distribution Manager GUI を使用した事前配信コンテンツの取得

Quick Crawl ユーティリティを使用したコンテンツ項目のチャネルへの追加

クロール タスクのチャネルへの追加

クロール タスクのコンテンツ取得ルールの設定

コンテンツ処理の詳細設定値の指定

複数のコンテンツ項目の変更

複数のコンテンツ項目の削除

外部でホストされるマニフェスト ファイルを使用した事前配信コンテンツの取得

マニフェスト ファイルの作成

チャネルの取得と配信に関するプロパティの指定

配信のプライオリティ

項目のプライオリティ

チャネルの割り当て量

マニフェスト ファイルの更新間隔

チャネルのマニフェスト ファイルとプロキシに関する情報の設定

パブリッシング URL の生成

再生サーバの割り当て

プロキシ サポート

Content Distribution Manager GUI を使用したホストとプロキシ サーバの設定

CLI を使用した HTTP プロキシ サーバの設定

マニフェスト ファイルを使用したプロキシ サーバの設定

noProxy

マニフェスト ファイルのプロキシ サーバとポートの設定

認証サポート

NTLM 認証が必要なコンテンツの取得

プロキシ認証のサポート

マニフェスト ファイルを取得するためのプロキシ認証の設定

マニフェスト ファイルを使用したプロキシ認証の設定

Content Distribution Manager GUI を使用した HTTP プロキシ認証の設定

CLI を使用したプロキシ認証の設定

Content Distribution Manager GUI を使用した WCCP プロキシ認証の設定

WCCP プロキシ認証設定の変更

CLI を使用した WCCP プロキシの認証設定

結果の確認

リトライと更新のメカニズム

チャネル コンテンツの更新

帯域幅制御

取得と配信のデフォルト帯域幅の設定

取得と配信の帯域幅設定のグラフィカル表示

スケジュール時刻の取得と配信用帯域幅パラメータの設定

ストリーミング取得用の帯域幅のスケジュール

エラー コード

ACNS 統合ネーム スペース エラー

取得機能エラー コード

MMS 固有の取得エラー コード

次の作業

ACNS ネットワークのコンテンツ取得設定

コンテンツ取得は、ACNS ネットワークにおけるコンテンツ事前配信の重要な機能です。ACNS ソフトウェアは、「チャネル」という概念を使用して、一連のコンテンツ オブジェクトを一連の Content Engine にマップします。事前配信コンテンツを ACNS ネットワーク内で取得または配信できるようにするには、事前に、ユーザが新規にチャネルを作成し、そのチャネルに Content Engine をサブスクライブし、Content Engine の中の 1 台をルート Content Engine として指定する必要があります。コンテンツのソースは、さまざまなファイル サーバまたは Web サーバに保存されています。チャネルのルート Content Engine は、これらのオリジン サーバからコンテンツ オブジェクトを取得し、チャネル内のすべての Content Engine にこのコンテンツを複製します。


) 事前配信コンテンツは、プロトコルの標準であるポート上でのみ処理されます。着信 URL にプロトコルの標準ポート(HTTP はポート 80、MMS はポート 1755 を使用)以外のポート番号が含まれている場合、Content Engine は事前配信ファイル システム(cdnfs)からコンテンツを処理しません。その代わり、Content Engine の既存の設定に応じて、Content Engine はキャッシュ ファイル システム(cfs)からコンテンツを処理するか、またはオリジン サーバからコンテンツを取得します。事前配信コンテンツを非標準のポートを使用して処理するには、マニフェスト ファイルで ignoreOriginPort 属性を true に設定します。この属性については、「item」を参照してください。


この章では、ACNS ネットワーク内で事前配信コンテンツを取得するために必要な手順の概要について説明します。この章の構成は、次のとおりです。

「事前配信コンテンツの取得の準備」

「チャネルのコンテンツ取得方法の選択」

「Content Distribution Manager GUI を使用した事前配信コンテンツの取得」

「外部でホストされるマニフェスト ファイルを使用した事前配信コンテンツの取得」

「プロキシ サポート」

「認証サポート」

「結果の確認」

「リトライと更新のメカニズム」

「帯域幅制御」

「エラー コード」

「次の作業」

事前配信コンテンツの取得の準備

事前配信コンテンツを取得するように ACNS ネットワークを準備するには、次の作業を行う必要があります。

1. オリジン サーバの設定

2. チャネルの作成

3. ルート Content Engine の割り当て

取得機能の概要

ルート Content Engine は、取得機能と呼ばれるソフトウェア エージェントを使用します。このエージェントがチャネル コンテンツを収集すると、ACNS ネットワーク内の受信側 Content Engine にチャネル コンテンツを配信することが可能になります。取得機能が保持するタスク リストは、チャネル設定の変更通知を受信すると更新されます。取得機能でサポートされている機能とサポートされていない機能を次に説明します。

SMB サーバからのファイル取得

ACNS 5.4 ソフトウェアでは、SMB プロトコルを実行する、共有フォルダを持つ Windows ファイル サーバと、Unix サーバからのファイル取得をサポートしています。取得機能は、まず、共有フォルダをルート Content Engine にマウントします。このマウント ポイントは、コンテンツが取得されるオリジン サーバとして機能します。取得機能はコンテンツを取得し、それを cdnfs ストレージ スペースに事前配信します(2 GB を超えるファイルは、SMB を使用して取得できません)。


) エクスポートされたファイルシステム(SMB または NFS)内のシンボリック リンクにターゲット ファイルへの相対パスが含まれているか、またはターゲット ファイルがエクスポートされたボリュームにコピーされる必要があります。シンボリック リンクが、ファイル サーバが Content Engine へエクスポートするボリューム以外の完全パスをポイントしている場合、Content Engine はそのファイル パスへアクセスできず、SMB 取得が失敗します。また、その際に ACNS 5.4 ソフトウェアは 404 のエラー メッセージを表示します。


Content Distribution Manager GUI では、外部でホストされるマニフェスト ファイルを取得するために SMB をサポートしています。また、Content Distribution Manager GUI のコンテンツ インポート機能では、コンテンツ項目とクロール タスクに対する SMB ファイル取得もサポートしています。

コンテンツ項目とクロール タスクを SMB サーバから事前配信するには、URL 形式 \\SMBserver\sharefolder\filepath を使用できます。完全 URL は、マニフェスト ファイルに <item> タグまたは <crawler> タグで指定できます(次の例を参照)。

<CdnManifest>
<server name=”myserver1”>
<host name="\\<SMB-Server>"/>
</server>
<item src = “<Share Folder>\<File>” server=”myserver1”/>
<item src="\\<SMB-Server>\<Share Folder>\File"/>
</CdnManifest
 

クロール ジョブに対する SMB サーバからのファイル取得は、HTML ファイルを解析するのではなくクローラーがフォルダ階層をクロールする FTP(ファイル転送プロトコル)取得と同様に動作します。

SMB プロトコルに使用するポートを URL または port 属性に指定できます。ポートを指定しない場合、デフォルト ポートは 139 です。

SMB サーバのファイル取得に対する認証は、<host> タグと <item> タグ内にある user password 、および userDomainName 属性を使用して行われます(この属性については、 item を参照)。これらの属性は、完全 URL の一部としてではなく、別に指定する必要があります。プロキシとプロキシ認証は、この機能では使用できません。


) 匿名方式の認証を使用している Windows XP 共有サーバがある場合は、ファイルの取得は失敗します(詳細については、『Release Notes for ACNS Software』Release 5.4 を参照)。


EMBED タグと OBJECT ID タグのサポート

HTML ファイルに EMBED タグまたは OBJECT ID タグが含まれている場合、取得機能はそのファイルを解析し、 src 属性と filename 属性からファイル リンクを入手し、これらのファイルを取得します。

.asx ファイルのクロール

取得機能は、.asx ファイルを解析し、その内容を取得することができます。

マニフェスト ファイル内で指定される expires 属性

expires 属性をマニフェスト ファイル内の <item> タグまたは <crawler> タグの一部として指定する場合、コンテンツが削除される時間を yyyy-mm-dd hh:mm:ss 形式で指定します。

マニフェスト ファイル内で expires 属性を指定すると、ルート Content Engine は、指定された時間にコンテンツを削除します。次にルート Content Engine は、削除イベントを受信側 Content Engine に複製します。この受信側 Content Engine も、チャネルからコンテンツを削除します。

HTML ファイル内のスクリプトの解析

HTML ファイルに JavaScript または VBScript(Microsoft の Visual Basic Scripting Edition は Visual Basic の機能縮小版)が組み込まれていて、スクリプト コードにリンクがある場合、取得機能はそのリンクをたどるためのスクリプト コードの解析を行いません。

cookie のサポート

cookie は、CGI スクリプトなどのサーバ側接続において、クライアントがサーバに接続するときに、クライアント側に接続情報を保存し、再びサーバに接続したときに、サーバがその接続情報をクライアント側から取得する汎用メカニズムです。単純で永続的なクライアント側の状態がわかることにより、Web ベースのクライアント/サーバ アプリケーションの機能が大幅に向上します。取得機能もクライアントですが、cookie をサポートしていません。

オリジン サーバの設定

コンテンツは、通常、管理対象デバイスから構成される ACNS ネットワークに含まれていないファイル サーバまたは Web サーバに保存されています。ACNS ネットワーク内でコンテンツの取得と配信を目的として保存されているコンテンツを事前配信するために、オリジン ファイル サーバまたは Web サーバは、ACNS ソフトウェアがコンテンツの取得に使用する次のプロトコルを 1 つ以上サポートする必要があります。

HTTP

HTTPS

FTP

MMS

MMS-HTTP

HTTP と HTTPS の使用

標準の Web サーバは HTTP と HTTPS のプロトコルをサポートします。ACNS ネットワークで使用するコンテンツを事前配信するために Web サーバをオリジン サーバとして設定するには、コンテンツをその Web サーバに移動するか、目的のコンテンツにアクセスするように Web サーバを設定します。次の 2 つの Web サーバが最も一般的です。

Apache ― UNIX、Linux、および Microsoft NT プラットフォーム上でサポートされます。

Microsoft IIS ― Microsoft プラットフォーム上でのみサポートされます。

HTTP および HTTPS プロトコルの場合、マニフェスト ファイルの <item> タグを使用して、単一コンテンツ項目としてコンテンツを取得するか、Web サーバ ディレクトリをクロールするクロール機能を使用してコンテンツを取得することができます。クローラーは HTML ファイルを解析するのではなく、フォルダ階層をクロールします。このため、クロール機能を使用する場合は、ディレクトリ インデックスをイネーブルにし、ディレクトリには index.html、default.html、または home.html ファイルが含まれていないことを確認する必要があります。


ヒント HTTPS コンテンツを取得する Web サーバを設定するには、SSL 証明書のインストールが必要になる場合があります。サーバで有効期限切れの証明書または自己署名証明書を使用している場合、マニフェスト ファイルの <host> タグで sslAuthType を「weak」に設定する必要があります。


リダイレクトのサポート

単一項目の HTTP リダイレクトの場合、取得機能は新しいリンクへのリダイレクトを実行して、ファイルを取得します。HTTP リダイレクトがクロール ジョブである場合、取得機能はクロール パラメータに照らして新しいリンクを検査します。たとえば、start-url の http://www.ibm.com/ http://www.cnn.com /にリダイレクトされる場合、取得機能は www.cnn.com を検査して、start-url がクロール パラメータと一致するかどうかを確認します。 externalPrefixes 属性が指定される場合を除いて、通常このリダイレクトは、デフォルトのプレフィクスと一致しないため、拒否されます。

HTTP 応答の no-cache ディレクティブ

no-cache ディレクティブは、HTTP プロトコルで使用されます。HTTP プロトコルは、ヘッダーを使用して、クライアントとサーバ間で情報をやりとりします。クライアントは要求ヘッダーを送信し、サーバは応答ヘッダーで応答します。ヘッダーは、要求されるリソースにさまざまな属性を指定します。たとえば、クライアントが次のように要求を送信するとします。

GET/index.html HTTP/1.0
Host:www.google.com
 

サーバは、次のように応答を送信します。

HTTP/1.0 200 OK
Content-Length:10
pragma:no-cache
Cache-control:no-cache
 

応答ヘッダー内の no-cache ディレクティブは、要求されるコンテンツがキャッシュ不能であることをクライアントに伝えます。HTTP サーバが、ヘッダー内の no-cache ディレクティブで要求に応答すると、取得機能は次のように動作します。

取得しようとするコンテンツが <item> タグ内で指定されていると、取得機能は no-cache ディレクティブを無視し、コンテンツを取得します。

取得しようとするコンテンツがマニフェスト ファイルの <crawler> タグ内で指定されているときに、サーバが送信した応答の応答ヘッダー内に no-cache ディレクティブが含まれている場合、取得機能はそのディレクティブを有効と認め、コンテンツの取得も、事前配信も行いません。

HTTP 応答の expires ディレクティブ

HTTP 応答ヘッダー内の expires ディレクティブは、処理するコンテンツが応答で指定された時間経過後、無効になることを示します。たとえば、応答ヘッダーに次のようなディレクティブが含まれているとします。

HTTP/1.0 200 OK
expires:<some time>
 

クライアント(この場合、取得機能)は、指定された時間経過後、コンテンツを使用しないように指示されます。expires ディレクティブが有効と認められるのは、<crawler> タグ内で指定されるコンテンツに対してだけです。マニフェスト ファイルに記述されている <item> タグを使用して設定された単一項目については、サーバによって送信された expires ディレクティブを有効であると認めません。

FTP の使用

ルート Content Engine の取得機能は、FTP サーバからのファイル取得をサポートしています。FTP を使用すると、マニフェスト ファイルの <item> タグを使用して、単一コンテンツ項目としてコンテンツを取得するか、FTP サーバ ディレクトリをクロールするクロール機能を使用してコンテンツを取得することができます。FTP による取得では、取得機能は HTML ファイルを解析するのではなく、フォルダ階層をクロールします。次の一般的な FTP サーバがサポートされています。

Microsoft IIS 4.0、5.0、6.0 ― Windows プラットフォーム用

Wu-2.6.1-18 ― Linux プラットフォーム用

FTP Server ― SunOS(バージョン 5.6)用

proFTPd ― Linux プラットフォーム用

次の Windows FTP サーバもサポートされています。

WS_FTP サーバ

Bulletproof FTP サーバ

SurgeFTP

SlimFTPd

次の FTP コマンドがサポートされている FTP サーバも使用できます。

USER、PASS

[SIZE、MDTM] または [LIST -a]

PASV または PORT

CWD ~ または CWD <SPACE> または CWD/

RETR

セキュア FTP

取得機能は、現在、セキュア FTP には対応していません。

MMS と MMS-over-HTTP の使用

ルート Content Engine は、MMS プロトコルまたは MMS-over-HTTP のいずれかを使用したストリーミング メディア ファイルの取得をサポートしています。マニフェスト ファイルでは、MMS-over-HTTP は、MMS-HTTP または単に HTTP として指定できます。

MMS プロトコルを指定すると、TCP を介したストリームの取得に MMST が使用されます。MMS-HTTP を指定すると、ソフトウェアは、MMS-over-HTTP プロトコルを使用してストリームをダウンロードします。HTTP を指定すると、ソフトウェアは、通常の HTTP ダウンロードであるか、ストリーミング MMS over HTTP ダウンロードであるかを自動的に検出し、対応するプロトコルを使用してダウンロードします。

場合によっては、ユーザは標準でない Microsoft Windows Media Technologies(WMT)非対応サーバでホストされるストリーミング コンテンツを事前配信する必要があります。MMS-HTTP プロトコルを使用してこの状態に対処するには、HTTP ダウンロードから HTTP ストリーミング ダウンロードへの自動切り替えを許可しない、非標準のオリジン サーバからの HTTP ストリーミング取得を可能にします。


) MMS-HTTP プロトコルをマニフェスト ファイルで指定できるのは、<host> タグと <item> タグを使用して単一コンテンツ項目を取得する場合だけです。


MMST プロトコルを使用してコンテンツを取得するには、ファイアウォール上でポート 1755 がオープンしていることを確認してください。MMS-HTTP の場合、HTTP ポート(通常、ポート 80)がオープンしていることを確認してください。

チャネルの作成

チャネルは、一連のコンテンツ オブジェクトを一連の Content Engine にマップします。事前配信コンテンツを取得または配信する場合は、事前にチャネルを設定しておく必要があります。チャネルを作成するには、 第 5 章「ACNS ネットワークのコンテンツ配信設定」 を参照してください。第 5 章では、次のネットワーク要素を設定してコンテンツの取得と配信用のチャネルを作成する方法を説明しています。

1. ロケーション ― ロケーションの作成と変更

2. コンテンツ プロバイダー ― コンテンツ プロバイダーの作成と変更

3. Web サイト ― Web サイトの作成と変更

4. チャネル ― チャネルの作成と変更

ルート Content Engine の割り当て

ルート Content Engine は、チャネル用のコンテンツを取得するために使用されます。1 つのチャネルには、1 つのルート Content Engine しか設定できません。オリジン サーバのコンテンツにアクセスできる十分な帯域幅をもつルート Content Engine を選択することを推奨します。

ルート Content Engine の割り当て方法については、「ルート Content Engine の指定」を参照してください。

バックアップ ルート Content Engine の割り当て

バックアップ ルート Content Engine の指定は、必須ではありません。しかし、バックアップとして、チャネルにサブスクライブされるプライマリ Content Engine と同じロケーション内にある、別の Content Engine を指定してください。指定されたルート Content Engine が非アクティブになると、自動的にロケーション内にあるもう一方の Content Engine が、一時的にルート Content Engine になります。指定されたルート Content Engine がオンラインに戻ると、ルートとしての役目を引き継ぎます。一時的にルートとして機能していた Content Engine は、通常の Content Engine になります。

コンテンツの取得時に、取得機能は大量の CPU 能力を使用します。コンテンツの取得のためには、専用のハイエンド ルート Content Engine を設定することを推奨します。ルート Content Engine は、ビデオ ファイルのストリーミング、または事前配信コンテンツを処理するために使用できます。ただし、大量のコンテンツを取得している間は、ストリーミング ビデオの品質が損なわれる可能性があります。

チャネルのコンテンツ取得方法の選択

チャネルにコンテンツの取得を設定するには、次のコンテンツ取得方法のいずれかを選択する必要があります。

外部でホストされるマニフェスト ファイルを使用してコンテンツを指定する。

マニフェスト ファイルには、コンテンツ取得パラメータの定義に使用する XML タグ、サブタグ、および属性が組み込まれます。マニフェスト ファイルを効率的に作成して使用するには、XML ベースのマニフェスト ファイルをよく理解し、XML タグの形式と構文が正しいことを確認する必要があります(外部でホストされるマニフェスト ファイルを使用した事前配信コンテンツの取得および 付録 A「マニフェスト ファイルの作成」 を参照)。

Content Distribution Manager GUI を使用してコンテンツを指定する。

Content Distribution Manager GUI は、使いやすいインターフェイスです。このインターフェイスを使用すると、マニフェスト ファイルの作成や更新をしなくてもコンテンツ項目を簡単に追加し、クロール タスクを指定できます。Content Distribution Manager GUI は、ユーザの入力をすべて自動的に検証し、バックグラウンドで構文エラーのない XML 形式のマニフェスト ファイルを生成します(Content Distribution Manager GUI を使用した事前配信コンテンツの取得を参照)。

すべてのコンテンツ項目のチャネルごとに マニフェスト ファイルは、1 つだけ作成されます。GUI で生成したマニフェスト ファイルは、任意のロケーションに保存できます。

チャネルのコンテンツ取得方法を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 コンテンツ取得方法を設定するチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。


) 事前配信コンテンツのチャネルは、Channels ウィンドウ内で「Content」タイプと表示されます。


ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel ウィンドウが表示されます。デフォルトでは、新規に作成されたチャネルのコンテンツ取得方法は、 Use GUI to specify content acquisition に設定されます(図6-1 を参照)。

図6-1 チャネルのコンテンツ取得方法 ― Content Distribution Manager GUI の使用

 

このウィンドウでは、チャネルに対してコンテンツ項目を追加し、クロール タスクを指定できます(Content Distribution Manager GUI を使用した事前配信コンテンツの取得を参照)。

ステップ 4 外部でホストされるマニフェスト ファイルを使用する手順は、次のとおりです。

a. Change Method ボタンをクリックして、コンテンツ取得方法を変更します。

b. 表示されるドロップダウン リストから、 Specify external manifest file を選択します。


) コンテンツ取得方式を Content Distribution Manager GUI を使用した方式から外部マニフェスト ファイルを使用した方式に変更すると、GUI を使用して追加したコンテンツ項目はすべて GUI から削除されます。コンテンツ項目を XML 形式で保存するには、タスクバーから Save settings locally アイコンをクリックします。新規ウィンドウに GUI で生成されたマニフェスト ファイルが表示されます。このファイルをローカル ディスクに保存します。


c. ドロップダウン リストの横にある Save ボタンをクリックします。確認するメッセージが表示されます。

d. OK をクリックします。ウィンドウの内容が更新され、マニフェスト ファイルの設定とマニフェスト プロキシ情報を定義するためのフィールドが表示されます(図6-2 を参照)。

図6-2 チャネルのコンテンツ取得方法 ― 外部マニフェスト ファイルの使用

 

このウィンドウでは、基本的なマニフェストの設定とプロキシ情報を定義できます(チャネルのマニフェスト ファイルとプロキシに関する情報の設定を参照)。


 

Content Distribution Manager GUI を使用した事前配信コンテンツの取得

ACNS 5.4 ソフトウェアでは、マニフェスト ファイルを作成しなくても、Content Distribution Manager GUI を使用して直接コンテンツ項目とクロール タスクを事前配信できます。単純なデモやシステムをセットアップする場合、または取得と配信の拡張機能の使用が不要な少数の項目を追加する場合は、この方法を使用してください。

Content Distribution Manager GUI を使用してコンテンツを事前配信する手順は、次のとおりです。


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

ステップ 2 変更するチャネルの名前の横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel ウィンドウが表示されます。

ステップ 4 コンテンツの取得方法を指定します。

a. 必要に応じて、 Change Method ボタンをクリックします。

b. ドロップダウン リストから、 Use GUI to specify content acquisition を選択します。

c. Save をクリックします。

「チャネルのコンテンツ取得方法の選択」を参照してください。

ステップ 5 コンテンツ項目とクロール タスクを追加するには、タスクバーから Add Content アイコンをクリックします。チャネルの Content Manager ウィンドウが表示されます(図6-3 を参照)。

図6-3 Content Manager ウィンドウ

 

ステップ 6 コンテンツ ソースを指定します。

a. Source URL ドロップダウン リストから、コンテンツ要求に使用するプロトコルを選択します。その次のフィールドに、オリジン サーバのドメイン名または IP アドレスを入力します。

b. 送信元の URL を単一コンテンツ項目として取得する場合は、 Single Item チェックボックスにチェックマークを付けます。

c. Web サイトをクロールしてコンテンツを取得する場合、または個別のコンテンツ項目を追加する場合は、 Single Item チェックボックスのチェックマークを外したままにします。クロール タスクについては、Web サイトをクロールするレベル数を Link Depth フィールドに入力します。

ステップ 7 コンテンツを取得するためのパラメータを設定します。

a. Define a crawl task オプション ボタンをクリックすると、さらにクロール タスクを定義してルールを適用できます。 Show optional content acquisition rules の矢印をクリックします(クロール タスクのチャネルへの追加 および クロール タスクのコンテンツ取得ルールの設定 を参照)。

b. Select individual items オプション ボタンをクリックすると、 Launch Quick Crawl ボタンをクリックしてさらにコンテンツ項目のパラメータを定義できます。このボタンをクリックすると、Quick Crawl Filter ウィンドウが表示されます(Quick Crawl ユーティリティを使用したコンテンツ項目のチャネルへの追加を参照)。

ステップ 8 コンテンツ処理時間、認証、URL 設定、コンテンツ設定などの詳細な設定を指定するには、 Show advanced settings 矢印をクリックします。ウィンドウが拡大され、詳細設定を行うことができます(コンテンツ処理の詳細設定値の指定を参照)。

ステップ 9 このコンテンツ要求を処理するには、 Submit をクリックします。 Submit をクリックすると、ローカルのマニフェスト ファイルが自動的に再解析され、変更が検出され、対応する項目が取得または削除されます。ただし、これによりチャネル内のすべてのコンテンツの再検査はトリガーされません。


 

Quick Crawl ユーティリティを使用したコンテンツ項目のチャネルへの追加

Quick Crawl は、指定された送信元 URL から Web サイトを自動的にクロールするユーティリティです。このユーティリティは、ドメイン名しかわからず、コンテンツ項目の正確なロケーションが不明の場合に使用できます。ルールに基づいた Quick Crawl フィルタを設定して、事前定義された特性をもつコンテンツだけをクロールすることができます。フィルタリングの結果は表示され、取得するコンテンツ項目を選択できます。Quick Crawl では、HTTP と HTTPS を使用する Web サイトだけをクロールできます。

Quick Crawl ユーティリティを使用して個別のコンテンツ項目を追加する手順は、次のとおりです。


ステップ 1 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 コンテンツ項目を追加するチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel ― Use GUI to Specify Content Acquisition ウィンドウが表示されます(図6-1 を参照)。

ステップ 4 タスクバーから Add Content アイコンをクリックします。チャネルの Content Manager ウィンドウが表示されます(図6-3 を参照)。

ステップ 5 Source URL ドロップダウン リストから、使用する通信プロトコル(HTTP または HTTPS)を選択します。デフォルトは HTTP です。

ステップ 6 Source URL フィールドに、ホスト サーバ(オリジン サーバ)の URL を入力して、Quick Crawl を開始するロケーションを指定します。Web ブラウザから URL をコピーして、Source URL フィールドにペーストすることができます。


) Quick Crawl に指定される値は、マニフェスト ファイルの属性とは直接関連ありません。Quick Crawl はコンテンツ URL のリストを提供し、チャネルに追加する個別のコンテンツ項目のリストとしてこのリストを使用できます。


ステップ 7 Single Item チェックボックスのチェックマークを外したままにします。

ステップ 8 Link Depth フィールドで、クロールする Web サイトのレベル数、またはクロールする FTP サーバのディレクトリのレベル数を指定します。この指定は任意です。範囲は -1 ~ 2147483636です。

Depth が -1 の場合、レベルに関する制約はありません。
Depth が 0 の場合、開始 URL のみ取得します。
Depth が 1 の場合、開始 URL とその URL から参照されるすべてのコンテンツを取得します。

別の方法として、Quick Crawl を起動後にリンク レベルを指定することもできます。

ステップ 9 Select individual items オプション ボタンをクリックして取得するコンテンツ項目を選択し、 Launch Quick Crawl ボタンをクリックして Quick Crawl ユーティリティを起動します。Quick Crawl Filter ウィンドウが表示されます。


) Quick Crawl を使用して取得される項目は、マニフェスト ファイルの <crawl> 要素とは関連ありません。これは、Quick Crawl はマニフェスト生成プログラムではないためです。Quick Crawl はオリジン サーバ上にあるグラフィック ファイル、MPEG ビデオ、RealAudio サウンド ファイルなどのコンテンツ項目やコンテンツ オブジェクトのリストを表示するだけです。これらの項目は、チャネルに追加されると、GUI で生成したマニフェスト ファイルの <item> タグに関連付けられます。


ステップ 10 Quick Crawl フィルタを設定します。このウィンドウ内のフィールドはすべて任意です。

a. MIME type フィールドで、クロールするファイルの MIME タイプを指定します。オブジェクトが取得されるのは、MIME タイプがここで指定した MIME タイプと一致する場合だけです。

b. Extension フィールドで、クロールするファイルの拡張子を指定します。オブジェクトが取得されるのは、拡張子がここで指定した拡張子と一致する場合だけです。

c. Modified After フィールドに、コンテンツを取得する場合に照合する日付を入力します。オブジェクトが取得されるのは、この日付以降に変更された場合だけです。

d. Modified Before フィールドに、コンテンツを取得する場合に照合する日付を入力します。オブジェクトが取得されるのは、この日付以前に変更された場合だけです。

別の方法として、Modified After フィールドと Modified Before フィールドの横にある Calendar アイコンをクリックして、Date Time Picker ポップアップ ウィンドウを表示します。Date Time Picker ポップアップ ウィンドウで、必要に応じて左矢印または右矢印のアイコンを使用して年を選択します。ドロップダウン リストから月を選択します。選択した月の日付をクリックします。選択された日付はブルーで強調表示されます。 Apply をクリックします。また、 Set Today をクリックすると、現在の日付に戻ります。選択された日付が、Modified After フィールドまたは Modified Before フィールドに表示されます。

e. Minimum Size フィールドで、取得するコンテンツの最小サイズを指定します。この値以上のサイズのコンテンツが取得されます。サイズの単位を MB KB Bytes から選択します。範囲は 0 ~ 2147483636です。

f. Max Size フィールドで、取得するコンテンツの最大サイズを指定します。この値以下のサイズのコンテンツが取得されます。サイズの単位を MB KB Bytes から選択します。範囲は 0 ~ 2147483636です。

g. Link Depth フィールドで、クロールする Web サイトのレベル数、またはクロールする FTP サーバのディレクトリのレベル数を指定します。範囲は -1 ~ 2147483636です。

Content Manager ウィンドウの Link Depth フィールドにレベル数を入力した場合は、そのレベル数がこのフィールドに表示されます。

h. Domain フィールドには、ステップ 6で入力した Source URLの host.domain の部分だけが表示されます。検索をドメインの特定のホストに制限する場合は、このフィールドを編集します。

i. Username フィールドに、ホスト サーバに対してセキュア ログインが必要なユーザの名前を入力します(認証が必要な Web サイト用)。

j. Password フィールドに、ホスト サーバへのアクセスに必要なユーザ アカウントのパスワードを入力します(認証が必要な Web サイト用)。

ステップ 11 Quick Crawl のフィルタ ルールの追加が終了したら、Start Quick Crawl ボタンをクリックします。Searching for Content ウィンドウが表示されます。クロールされている項目の数がプログレス バーに表示されます。指定された数の項目がクロールされるか、プログレス バーが 100% に達する前に、Show Results をクリックしてこれまでにクロールされたコンテンツ項目の URL リストを表示できます。また、Refresh Results をクリックしてプログレス バーの表示内容を更新することもできます。

指定された数の項目がクロールされると、ウィンドウの内容が更新され、Content Importer ウィンドウが表示されます(図6-4 を参照)。

図6-4 Content Importer ウィンドウ

 

このウィンドウには、関連付けられた MIME タイプ、サイズ、変更日時、URL が表示されます。

ステップ 12 取得して配信する URL のリストに追加するコンテンツ項目の横にあるチェックボックスにチェックマークを付けます。

ステップ 13 このウィンドウに表示されているコンテンツ項目をすべて Content Manager に追加するには、ウィンドウの下部にある Select All をクリックします。コンテンツ項目数が 10 を超える場合、複数のページから項目を選択しなければならない場合があります。すべての項目の選択を解除して、別の項目を選択するには、 Select None をクリックします。

ステップ 14 Content Importer ウィンドウの下部にある Add Selected ボタンをクリックして、選択されたインポートするコンテンツ項目をすべて追加します。Content Importer ウィンドウが終了し、Content Acquisition Method for Channel ― Use GUI to Specify Content Acquisition ウィンドウに追加されたコンテンツ項目がすべて表示されます。

別の方法として、 Show Filter ボタンをクリックして Quick Crawl Filter ウィンドウを表示し、フィルタ設定を変更します。


 

クロール タスクのチャネルへの追加

クローラー アプリケーションは、指定されたクロール条件と一致した Web サイトと FTP サイトを系統的かつ自動的に検索し、以後の処理のために、アクセスしたページのコピーを作成します。クローラー アプリケーションは、アクセスする URL のリストから開始し、その URL に関連するページ内のすべてのリンクを識別して、これらのリンクをアクセスする URL のリストに追加します。

このプロセスは、次の条件が 1 つまたは複数満たされると、終了します。

指定された深さまでリンクがたどられた。

最大数のオブジェクトが取得された。

最大サイズのコンテンツが取得された。

マニフェスト ファイルを使用する場合、クローラー ジョブを停止する条件として <crawler> タグに max-number 属性と max-size 属性の両方を指定でき、どちらかの条件が一致するとジョブが停止します。たとえば、クローラーがマニフェスト ファイルに指定された最大数のオブジェクトを取得すると、最大コンテンツ サイズにまだ達していない場合であっても、クローラーは停止します。

Content Distribution Manager GUI を使用する場合、両方の属性をクロール タスクに指定することはできません。ただし、 Save settings locally アイコンをクリックして GUI で生成されたマニフェスト ファイルを保存したあと、テキスト エディタや XML エディタを使用してそのファイルを変更し、他の XML タグを手動で追加できます。


) 保存したマニフェスト ファイルを変更し、そのマニフェスト ファイルを Content Distribution
Manager GUI で定義したコンテンツの代わりに使用する場合、または別のチャネルのマニフェスト ファイルを使用する場合は、Specify external manifest file 設定で(チャネルのコンテンツ取得方法の選択を参照)、そのマニフェスト ファイルをポイントする必要があります。コンテンツ取得方式を Content Distribution Manager GUI を使用した方式から外部マニフェスト ファイルを使用した方式に変更すると、GUI を使用して追加したコンテンツ項目はすべて GUI から削除されます。


Content Distribution Manager GUI を使用してクロール タスクをチャネルに追加する手順は、次のとおりです。


ステップ 1 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 クロール ジョブを設定するチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content acquisition method for channel ― Use GUI to specify content acquisition ウィンドウが表示されます。

ステップ 4 タスクバーから Add Content アイコンをクリックして、クロール ジョブを指定します。チャネルの Content Manager ウィンドウが表示されます。

ステップ 5 Source URL ドロップダウン リストから、オリジン サーバからコンテンツをクロールするために使用する通信プロトコル(HTTP、HTTPS、FTP、MMS、MMS-HTTP)を選択します。デフォルトは HTTP です。

ステップ 6 Source URL フィールドに、ホスト サーバ(オリジン サーバ)の URL を入力して、Web サイトまたは FTP サーバのクロールを開始するロケーションを指定します。Web ブラウザから右クリックして URL をコピーし、Source URL フィールドにペーストすることができます。

ここで入力される値は、<crawler> 要素の start-url 属性の完全 URL に関連付けられています。この値は、<host> 要素の proto 属性にも関連付けられています。<host> 要素の name 属性が Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)である場合、proto 属性を入力する必要はありません。

ステップ 7 Link Depth フィールドで、クロールする Web サイトのレベル数、またはクロールする FTP サーバのディレクトリのレベル数を指定します。デフォルトの深さは 10 レベルです。範囲は -1 ~ 2147483636 です。

Depth が -1 の場合、深さに関する制約はありません。
Depth が 0 の場合、開始 URL のみ取得します。
Depth が 1 の場合、開始 URL とその URL から参照されるすべてのコンテンツを取得します。

この値は、<crawler> 要素の depth 属性に関連付けられています。

ステップ 8 Define a crawl task オプション ボタンをクリックします。

ステップ 9 クロール タスクをチャネルに追加するには、Submit をクリックします。 Submit をクリックすると、ローカルのマニフェスト ファイルが自動的に再解析され、変更が検出され、対応する項目が取得または削除されます。

クロール タスクに任意のコンテンツ取得ルールを定義するには、「クロール タスクのコンテンツ取得ルールの設定」を参照してください。


 

クロール タスクのコンテンツ取得ルールの設定

コンテンツ取得ルールを設定する手順は、次のとおりです。


ステップ 1 コンテンツ取得ルールの設定領域を表示します。

a. Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

b. クロール ジョブを設定するチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

c. Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel ― Use GUI to Specify Content Acquisition ウィンドウに、このチャネルに定義されているコンテンツ項目とクロール タスクが表示されます。

d. 取得ルールを設定するクロール タスクの横にある Edit アイコンをクリックします。Content Manager ウィンドウが表示されます。

e. Show optional content acquisition rules の矢印をクリックします。コンテンツ取得ルールを設定するためのフィールドが表示されます(図6-5 を参照)。 表6-1 では、このウィンドウのフィールドについて説明し、対応するマニフェスト ファイルの属性を示しています。

図6-5 クロール タスクのコンテンツ取得ルールの設定

 

ステップ 2 MIME type フィールドで、取得するコンテンツの MIME タイプを指定します。

ステップ 3 Extension フィールドで、取得するファイルの拡張子を指定します。

ステップ 4 Time before フィールドに、コンテンツを取得する場合に照合する日時を入力します。この日時以前に変更されたファイルが取得されます。dd-mm-yyyy hh:mm:ss [TMZ] の形式を使用します。TMZ(時間帯)は任意です。デフォルトは UTC です。たとえば、5/27/2004 14:02:07 UTC と指定できます。

別の方法として、Time before フィールドと Time after フィールドの横にある Calendar アイコンをクリックして、Date Time Picker ポップアップ ウィンドウを表示します。

Date Time Picker ポップアップ ウィンドウで、必要に応じて左矢印または右矢印のアイコンを使用して年を選択します。ドロップダウン リストから月を選択します。選択した月の日付をクリックします。選択された日付はブルーで強調表示されます。別の方法として、Set Today をクリックして、現在の日時を入力します。Time フィールドに現在のシステムの時刻が表示されます。別の日時を設定するには、これらのフィールドを編集します。Apply をクリックします。

ステップ 5 Time after フィールドに、コンテンツを取得する場合に照合する日時を入力します。この日時以降に変更されたファイルが取得されます。dd-mm-yyyy hh:mm:ss [TMZ] の形式を使用します。TMZ(時間帯)は任意です。デフォルトは UTC です。

ステップ 6 Minimum size フィールドで、取得するコンテンツの最小サイズを指定します。この値以上のサイズのコンテンツが取得されます。サイズの単位を MB KB Bytes から選択します。

ステップ 7 Max size フィールドで、取得するコンテンツの最大サイズを指定します。この値以下のサイズのコンテンツが取得されます。サイズの単位を MB KB Bytes から選択します。

ステップ 8 Add をクリックして、ルールをルールのリストに追加します。エントリが追加され、カラム見出しの下に値が表示されます。


) クロール タスクごとに 10 ルールまで設定できます。


ステップ 9 コンテンツ取得ルールを変更するには、変更するルールの横にある Edit Rule アイコンをクリックします。変更が完了したら、コンテンツ取得ルールのセクションにある Update の小さいボタンをクリックして、変更内容を保存します。

ステップ 10 コンテンツ取得ルールを削除するには、削除するルールの横にある Edit Rule アイコンをクリックします。コンテンツ取得ルールのセクションにある Delete ボタンをクリックします。このルールがルールのリストから削除されます。

ステップ 11 コンテンツ取得ルールの追加と変更が完了したら、Content Manager ウィンドウの Update をクリックして、クロール タスクの設定を保存し、コンテンツ項目のリストに戻ります。

 

表6-1 クロール タスクのコンテンツ取得ルール

GUI パラメータ
機能
対応マニフェスト属性

MIME Type

取得するコンテンツの MIME タイプ。オブジェクトが取得されるのは、その MIME タイプがここで指定された MIME タイプと一致する場合だけです。

<match> mime-type

Extension

取得するコンテンツのファイル拡張子。オブジェクトが取得されるのは、その拡張子がここで指定された拡張子と一致する場合だけです。

<match> extension

Time before

ここで指定する日時以前に変更されたコンテンツが取得されます。オブジェクトが取得されるのは、最後に変更された日時がここで指定された値より前の場合だけです。dd-mm-yyyy hh:mm:ss [TMZ] の形式を使用します。TMZ(時間帯)は任意です。デフォルトは UTC です。

<match> time-before

Time after

ここで指定する日時以降に変更されたコンテンツが取得されます。オブジェクトが取得されるのは、最後に変更された日時がここで指定された値よりあとの場合だけです。dd-mm-yyyy hh:mm:ss [TMZ] の形式を使用します。TMZ(時間帯)は任意です。デフォルトは UTC です。

<match> time-after

Minimum Size

コンテンツの最小サイズ。取得されるコンテンツのサイズが、この数値(バイト、キロバイト、またはメガバイト単位)以上でなければなりません。このフィールドの範囲は 0 ~ 2147483636 です。

<match> minFileSizeInB/KB/MB

Maximum Size

コンテンツの最大サイズ。取得されるコンテンツのサイズが、この数値(バイト、キロバイト、またはメガバイト単位)以下でなければなりません。このフィールドの範囲は 0 ~ 2147483636 です。

<match> maxFileSizeInB/KB/MB

 


 

コンテンツ処理の詳細設定値の指定

Content Distribution Manager GUI から、Content Manager ウィンドウの Show advanced settings の項目の下にある次の項目を設定できます。

Content Serving Time

Authentication

URL Settings

Content Settings

これらの詳細設定値を指定すると、Content Engine でコンテンツを処理する方法を制御できます。これらの設定はマニフェスト ファイルの属性に対応し、<item> タグと <crawler> タグに関連付けられています。これらの同じ属性はマニフェスト ファイル内の <item-group> タグまたは <options> タグにも指定できるため、<item> と <crawler> のサブタグで共有できます。

コンテンツ処理の詳細設定値を指定する手順は、次のとおりです。


ステップ 1 詳細設定値を設定する領域を表示します。

a. Services > Web > Channels の順に選択します。

b. コンテンツ処理設定を指定するチャネルの名前の横にある Edit アイコンをクリックします。

c. Contents ペインから、 Channel Content を選択します。

d. 設定するコンテンツ項目またはクロール タスクの横にある Edit アイコンをクリックします。

別の方法として、 Add Content アイコンをクリックして、新規コンテンツ項目またはクロール タスクの必須設定値と合わせて任意の詳細設定値を指定します。

e. Content Manager ウィンドウで、 Show advanced settings 矢印をクリックします(図6-5 を参照)。詳細を設定するためのフィールドが表示され、矢印が Hide advanced settings 矢印になります(図6-6 および 図6-7 を参照)。 表6-2 では、このウィンドウのフィールドについて説明し、対応するマニフェスト ファイルの属性を示します。

図6-6 コンテンツ処理の詳細設定 ― ウィンドウの上部

 

図6-7 コンテンツ処理の詳細設定 ― ウィンドウの下部

 

ステップ 2 Content Serving Time セクションでは、次の項目を設定します。

a. 重要度の順序、すなわち項目の取得またはクロール ジョブの処理順序を指定するには、 High priority content チェックボックスにチェックマークを付けます。重要度が高いほど、コンテンツの取得と配信が早くなります。

b. Start serving time フィールドで、Content Engine がコンテンツの処理を開始できる日時を dd-mm-yyyy hh:mm:ss [TMZ] の形式で指定します。TMZ(時間帯)は任意です。デフォルトは UTC です。たとえば、5/27/2004 14:02:07 UTC と指定できます。処理開始日時を指定しない場合、コンテンツは Content Engine に配信されたあと、いつでも処理できます。

c. Stop serving time フィールドで、ACNS ネットワークがコンテンツの処理を一時的に停止する日時を dd-mm-yyyy hh:mm:ss [TMZ] の形式で指定します。TMZ(時間帯)は任意です。デフォルトは UTC です。処理停止時刻を指定しない場合、マニフェスト ファイルの変更またはチャネル名の変更によりコンテンツが削除されるまで、ACNS ネットワークはコンテンツを Content Engine に提供します。

別の方法として、Start serving time フィールドと Stop serving time フィールドの横にある Calendar アイコンをクリックして、Date Time Picker ポップアップ ウィンドウを表示します。Date Time Picker ポップアップ ウィンドウでは、デフォルトで現在の日時がイエローで強調表示されます。必要に応じて、左矢印または右矢印のアイコンを使用して年を選択します。ドロップダウン リストから月を選択します。選択した月の日付をクリックします。選択された日付はブルーで強調表示されます。Time フィールドに現在のシステムの時刻が表示されます。別の日時を設定するには、これらのフィールドを編集します。 Apply をクリックします。また、 Set Today をクリックすると、現在の日付に戻ります。選択された日付が、Start serving time フィールドまたは Stop serving time フィールドに表示されます。

ステップ 3 Authentication セクションでは、次の項目を設定します。

a. HTTP プロトコルを使用して有効期限切れまたは自己署名の証明書を受け入れるには、 Use weak SSL certificate チェックボックスにチェックマークを付けます。

b. コンテンツの取得時に基本認証方式にフォールバックしないようにするために Windows NT LAN Manager(NTLM)ヘッダーを削除しない場合は、 Disable basic authentication チェックボックスにチェックマークを付けます。

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

c. Username フィールドで、プロキシ認証用のユーザ名を指定します。

d. Password フィールドで、プロキシ認証用のユーザ パスワードを指定します。

e. User Domain Name フィールドで、プロキシで設定される NTLM 認証方式の NTLM ユーザ ドメイン名を指定します。

ステップ 4 URL Settings セクションでは、次の項目を設定します。

a. コンテンツ要求をオリジン サーバにリダイレクトしない場合は、 No redirect to origin server チェックボックスにチェックマークを付けます。チェックマークを付けないと、Content Engine はコンテンツがそのキャッシュにない場合に、コンテンツ要求をオリジン サーバに転送できます。

b. ACNS ソフトウェアで再生用の要求 URL にある疑問符(?)の後ろのストリングをすべて無視するには、 Ignore query string チェックボックスにチェックマークを付けます。

c. Alternate URL フィールドで、ユーザが要求したコンテンツが Content Engine に対して複製されていない場合(ACNS ネットワークにまだコンテンツがない場合)に ACNS ネットワークが要求をリダイレクトする代替 URL を指定します。

ステップ 5 Content Settings セクションでは、次の項目を設定します。

a. TTL フィールドで、コンテンツを再検証する時間を指定し、ドロップダウン リストから単位を選択します。TTL を指定しない場合、コンテンツは 1 回だけ取得され、フレッシュネスはチェックされません。

b. Retry interval フィールドで、コンテンツの取得が失敗した場合に ACNS ソフトウェアがコンテンツを再取得する間隔を指定し、ドロップダウン リストから単位を選択します。

c. Play duration フィールドで、ビデオ ファイルを再生する時間の長さを指定し、ドロップダウン リストから単位を選択します。

d. Bit rate フィールドで、コンテンツをダウンロードして再生するビット レートを指定し、ドロップダウン リストから単位を選択します。

 

表6-2 コンテンツ処理の詳細設定

GUI パラメータ
機能
対応マニフェスト属性

Content Serving Time

High priority content

コンテンツ項目またはクロール ジョブの処理順序。

priority

Start serving time

Content Engine でコンテンツの処理を開始できる日時。

serveStartTime

Stop serving time

ACNS ネットワークでコンテンツの処理を一時的に停止する日時。

serveStopTime

Authentication

Use weak SSL certificate

認証時に有効期限切れまたは自己署名の証明書を許可します。

sslAuthtype

Disable basic authentication

コンテンツの取得時に NTLM ヘッダーを削除して、基本認証方式へのフォールバックを不可能にします。

disableBasicAuth

User name

プロキシ認証用のユーザ名。

user

Password

プロキシ認証用のユーザ パスワード。

password

User Domain Name

プロキシで設定される NTLM 認証方式の NTLM ユーザ ドメイン名。

ntlmUserDomain

URL Settings

No redirect to origin server

コンテンツ要求のオリジン サーバへのリダイレクトを禁止します。

この属性はコンテンツ オブジェクト属性ごとに設定されます。すなわち、コンテンツが削除された場合、リダイレクト設定は適用されません。ただし、ソフトウェアでコンテンツを取得できない場合は、この設定が適用されます。

noRedirectToOrigin

Ignore query string

ソフトウェアは再生用の要求 URL にある疑問符(?)の後ろのストリングをすべて無視します。

ignoreQueryString

Alternate URL

ユーザが要求したコンテンツが Content Engine に対して複製されていない場合に ACNS ネットワークが要求をリダイレクトする代替 URL。

この属性は完全 URL のみをサポートし、要求されるコンテンツに適用されます。コンテンツが削除されると、この属性は適用されません。コンテンツの取得が失敗すると、この属性が適用されます。

alternateUrl

Content Settings

TTL

コンテンツを再検証する時間。

ttl

Retry interval

コンテンツの取得が失敗した場合に ACNS ソフトウェアがコンテンツを再取得する間隔。

failRetryInterval

Play duration

ビデオ ファイルを再生する時間の長さ。

playDuration

Bit rate

コンテンツをダウンロードして再生するビット レート。

bitrate

 


 

複数のコンテンツ項目の変更

複数の項目(単一項目とクロール タスク)を同じコンテンツ取得と配信のプロパティを使用して設定する必要がある場合は、それらの項目を選択し、リンク レベルとコンテンツ処理の詳細を変更できます。ただし、複数のコンテンツ項目とクロール タスクを編集している場合は、送信元 URL を変更することはできません。同様に、複数のクロール タスクに対して、クロール タスクに適用可能なコンテンツ取得ルールを変更することはできません。単一項目とクロール タスクの両方を変更するために選択した場合、すべてのクロール タスクに共通のリンク レベルを指定してもこの値は単一項目には適用されません。

複数のコンテンツ項目を変更する手順は、次のとおりです。


ステップ 1 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 変更するコンテンツ項目を持つチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel ― Use GUI to Specify Content Acquisition ウィンドウが表示されます。

ステップ 4 変更するコンテンツ項目の横にあるチェックボックスにチェックマークを付けます。

このウィンドウに表示されているコンテンツ項目をすべて選択するには、ウィンドウの下部にある All ボタンをクリックします( Rows ドロップダウン リストから、表示するコンテンツ項目数を 10、20、40、または ALL から選択できます)。

項目の選択を解除するには、 None ボタンをクリックし、別の項目を選択します。

ステップ 5 ウィンドウの下部にある Edit Selected Items ボタンをクリックして、選択されたコンテンツ項目を変更します。Channel-Content Manager ウィンドウが表示されます。デフォルトでは、このウィンドウ内のフィールドはすべて入力不可能になっています。

ステップ 6 変更するフィールドの横にある Click to override individual settings アイコンをクリックします。フィールドが編集可能になります。または、フィールドの横にある Click to revert initial settings アイコンをクリックして、設定中に元の設定に戻すこともできます。

ステップ 7 Show advanced settings 矢印をクリックし、詳細を指定します。

ステップ 8 Update をクリックして、変更した設定値を保存し、選択したコンテンツ項目に適用します。Content Acquisition Method for Channel-Use GUI to Specify Content Acquisition ウィンドウが表示されます。


 

複数のコンテンツ項目の削除

複数のコンテンツ項目を削除する手順は、次のとおりです。


ステップ 1 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 削除するコンテンツ項目を持つチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel-Use GUI to Specify Content Acquisition ウィンドウが表示されます。

ステップ 4 削除するコンテンツ項目の横にあるチェックボックスにチェックマークを付けます。

このウィンドウに表示されているコンテンツ項目をすべて選択するには、ウィンドウの下部にある All ボタンをクリックします( Rows ドロップダウン リストから、表示するコンテンツ項目数を 10、20、40、または ALL から選択できます)。

項目の選択を解除するには、 None ボタンをクリックし、別の項目を選択します。

ステップ 5 タスクバーから Delete Selected Items ボタンをクリックして、選択されたコンテンツ項目を削除します。確認するメッセージが表示されます。Content Acquisition Method for Channel-Use GUI to Specify Content Acquisition ウィンドウの内容が更新され、コンテンツ項目のリストが更新されます。


 

外部でホストされるマニフェスト ファイルを使用した事前配信コンテンツの取得

マニフェスト ファイルを使用してコンテンツを取得するように ACNS ネットワークを設定するには、次の作業を実行する必要があります。

1. マニフェスト ファイルの作成

2. チャネルの取得と配信に関するプロパティの指定

3. チャネルのマニフェスト ファイルとプロキシに関する情報の設定

4. パブリッシング URL の生成

5. 再生サーバの割り当て

マニフェスト ファイルの作成

マニフェスト ファイルの作成に関する詳細は、 付録 A「マニフェスト ファイルの作成」 を参照してください。

マニフェスト ファイルを作成したら、Manifest Validator ユーティリティを使用して構文を確認してください( Manifest Validator ユーティリティを参照)。その後、Content Distribution Manager GUI 内でマニフェスト URL を指定します。マニフェスト ファイルを取得する際に認証が必要な場合は、ユーザ名とパスワードも指定します(チャネルのマニフェスト ファイルとプロキシに関する情報の設定を参照)。

チャネルの取得と配信に関するプロパティの指定

ここでは、コンテンツの取得と配信に関して定義する必要がある次の 4 つの重要なプロパティについて説明します。

配信のプライオリティ

項目のプライオリティ

チャネルの割り当て量

更新間隔

これらのプロパティは、Content Distribution Manager GUI の Services > Web > Channels セクションまたはマニフェスト ファイル内で設定または定義します。

配信のプライオリティ

配信プライオリティの設定により、コンテンツの取得と配信の優先順位が決まります。この設定は、Content Distribution Manager GUI の Distribution Priority ドロップダウン リストから行います。配信プライオリティは、High(750)、Normal(500)、または Low(250)です。図6-8 に、Content Distribution Manager GUI で設定可能な取得と配信のプロパティ、およびマニフェストのプロパティを示します。チャネルの設定手順とフィールドの説明については、「チャネルの作成」を参照してください。

図6-8 チャネルの取得と配信に関するプロパティ

 

コンテンツ取得のプライオリティは、オリジン サーバによっても異なります。別々のオリジン サーバからの要求は、並行して処理されます。同じオリジン サーバからの要求は、全体のプライオリティに従って処理されます。ただし、Microsoft Media Server(MMS)および MMS-over-HTTP 要求の場合は、これに当てはまりません。MMS および MMS-over-HTTP 要求はすべて全体のプライオリティに従って処理されます。ここでは、全体のプライオリティ = 配信のプライオリティ× 10000 + 項目のプライオリティとなります。

項目のプライオリティ

項目のプライオリティは、マニフェスト ファイルによって決まります。マニフェスト ファイルの <item> タグ下に priority 属性が指定されている場合、この属性が項目のプライオリティとして使用されます。この属性が指定されていない場合、マニフェスト ファイルに項目が表示されている順序(インデックス番号)が項目のプライオリティとして使用されます(クロールされるページの項目プライオリティはすべて同じです。したがって、<crawler> タグ下に priority 属性を指定する必要はありません)。詳細は、「コンテンツの優先順位の指定」を参照してください。

チャネルの割り当て量

チャネルの割り当て量は、チャネルに使用できるディスク スペースです。チャネルの割り当て量は、Content Distribution Manager GUI から設定します(図6-8 を参照)。この設定については、「チャネルのマニフェスト ファイルとプロキシに関する情報の設定」を参照してください。

チャネルの割り当て量を設定する場合は、次の点に注意してください。

サブスクライブされている全チャネルの合計チャネル割り当て量は、Content Engine の cdnfs ディスク スペース割り当てを超えてはなりません。『Cisco ACNS Software Update and Maintenance Guide』にある「Updating Storage Capacity on Your Content Engines」を参照してください。

1 つのチャネル内の合計使用ディスク スペースは、Content Distribution Manager GUI の Channel Quota フィールド( Services > Web > Channels > Definition )でチャネルに割り当てたディスク スペース量を超えてはなりません。

オーバーヘッドがあるため、ファイルの使用ディスク スペース量は必ずファイルのサイズより大きくなります。ファイルに必要なディスク スペース量を計算する手順は、次のとおりです。

a. キロバイト(KB)で表された実際のファイル サイズを、固定 4 KB(4096 バイト)単位のファイル システムのブロック サイズで割り、その結果を最も近い整数に切り上げます。これにより、1 つのファイルで使用される、(完全または部分的に使用された)4 KB ブロックの数が得られます。

整数値に切り上げられた(ファイル サイズ [KB]/4096)= ファイルごとの合計ブロック数

b. 使用ファイル システム ブロックの合計数に 4 KB(4096 バイト)を掛けて、実際の消費ディスク スペースをバイト数で算出します。

ファイルごとの合計ブロック数× 4096 = 合計ディスク使用量(バイト)

c. 4 KB に 4 を掛けて、その結果を合計の消費ディスク スペースに足します(整数 4 は、内部システムの使用のための予約済みディスク スペースを表します)。

合計ディスク使用量(バイト)+(4096 バイト× 4)= ファイルごとのディスク使用量

また、ソフトウェアでは他のマイナーな内部システム機能のために十分なスペースを予約するため、チャネルの割り当て量(および事前配信のディスク スペース)として合計の消費ディスク スペースに、そのディスク スペースの 10% 程度を加えた値に設定することを推奨します。

チャネルの割り当て量(KB)=(合計のディスク使用量 [KB])+(0.1 ×合計のディスク使用量 [KB])

マニフェスト ファイルの更新間隔

更新間隔とは、ルート Content Engine がマニフェスト ファイル自体を検査する間隔です(これは、コンテンツを検査する更新間隔ではありません)。更新間隔は、Content Distribution Manager GUI から設定します(図6-9の Check Manifest フィールドを参照)。設定方法については、次のセクションを参照してください。

チャネルのマニフェスト ファイルとプロキシに関する情報の設定

マニフェスト ファイルには、チャネルを介して事前配信されるコンテンツについての情報、またはチャネルを介して配信されるライブ コンテンツおよびビデオオンデマンド(VoD)コンテンツについての情報が記述されています。

チャネルのマニフェスト ファイルとプロキシに関する情報を設定する手順は、次のとおりです。


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

ステップ 2 変更するチャネルの名前の横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。

ステップ 4 Content Acquisition Method for Channel タイトル バーが表示される画面で、チャネルのコンテンツ取得方式が Specify external manifest file(外部マニフェスト ファイルの指定)になっていることを確認します。この方式になっていない場合は、 Change Method ボタンをクリックして、ドロップダウン リストから Specify external manifest file を選択します。 Save をクリックします。ウィンドウの内容が更新され、マニフェスト設定とプロキシ情報のフィールドが表示されます。


) コンテンツ取得方式を、Content Distribution Manager GUI を使用した方式から外部でホストされるマニフェスト ファイルを使用した方式に変更すると、GUI を使用して定義したコンテンツはすべて削除されます。GUI を使用して定義したコンテンツを保存するには、タスクバーから Save settings locally アイコンをクリックします。ウィンドウに GUI で生成されたマニフェスト ファイルが表示されます。File > Save As の順に選択して、ファイルを保存します。


ステップ 5 Define Basic Manifest Settings の項目の下にあるフィールドを使用して、チャネルのマニフェスト ファイル情報を設定します。

ステップ 6 Define Basic Manifest Proxy Information の項目の下にあるフィールドを使用して、マニフェスト ファイルを取得するために取得機能のプロキシ情報を設定します。プロキシ サーバを設定すると、オリジン サーバからマニフェスト ファイルを取得する要求はプロキシ サーバを介して行われるようになります。

図6-9 を参照してください。 表6-3 では、このウィンドウ内のマニフェスト ファイルのフィールドについて説明しています。この表と GUI では、入力必須フィールドにアスタリスク(*)が付いています。

「マニフェスト ファイルのプロキシ サーバとポートの設定」、および「マニフェスト ファイルを取得するためのプロキシ認証の設定」も参照してください。

図6-9 チャネルのマニフェスト ファイルとプロキシに関する情報

 

ステップ 7 このマニフェスト ファイルの設定値を保存するには、 Submit をクリックします。マニフェスト ファイルの URL を指定しないと、何も指定していないことを示す確認メッセージが表示されます。マニフェスト ファイルの URL は、他の項目を設定したあとでも指定できます。 OK をクリックします。

 

表6-3 マニフェストのプロパティ

プロパティ
説明

Define Basic Manifest Settings

Manifest URL

チャネル用のマニフェスト ファイルのアドレス。マニフェスト URL は、適切な形式の URL にする必要があります。URL のプロトコル(FTP、HTTP、または HTTPS)が指定されない場合、HTTP が使用されます。

Check Manifest Every*

チャネルに割り当てられている Content Engine が、マニフェスト ファイルの更新がないかどうかを調べる頻度(0~52560000 分)(マニフェスト ファイルが指定される場合、このフィールドは必須)。

Weak Certificate Verification

チェックマークが付いている場合、マニフェスト ファイルに対して weak 認証確認をイネーブルにします。これが適用されるのは、HTTPS プロトコルを使用してマニフェスト ファイルを取得する場合です。


) チャネル コンテンツに対して weak 認証を使用するには、マニフェスト ファイル内で weak 認証を指定する必要があります。


 

Disable basic authentication

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

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

Manifest Username

マニフェストを取得するユーザ名。マニフェスト ユーザ名は有効な ID でなければなりません。サーバが匿名ログインを許可する場合、ユーザ ID はヌルにすることができます。


) Username フィールドと Password フィールドには、リモート ロケーションにあるマニフェスト ファイルにアクセスするために必要な保護ログイン情報を入力できます。


 

Manifest Password

ユーザのパスワード。

Confirm Password

パスワードの確認。

NTLM user domain name

オリジン サーバで設定される NTLM 認証方式でアクセスできる NTLM ユーザ ドメイン名。

Define Manifest Proxy Information

Disable All Proxy

マニフェスト ファイルを取得する発信プロキシ サーバをディセーブルにします。ルート Content Engine 上で設定されたすべての発信プロキシ サーバはバイパスされ、取得機能はオリジン サーバと直接交信します。

Proxy Hostname

取得機能がマニフェスト ファイルの取得に使用するプロキシ サーバのホスト名または IP アドレス。

Proxy Port

取得機能がマニフェスト ファイルを取得するプロキシのポート番号。範囲は 1 ~ 65535 です。

Proxy Username

マニフェスト ファイルを取得するために認証されるユーザの名前。

Proxy Password

プロキシで認証を受けるためのユーザのパスワード。

Confirm Password

プロキシで認証を受けるためのパスワードを確認のために再入力します。

Disable proxy basic authentication

このチェックボックスにチェックマークを付けると、NTLM ヘッダーが削除されず、Microsoft Internet Information Services(IIS)サーバに対して基本認証方式にフォールバックしません。

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

Proxy NTLM user domain name

プロキシで設定される NTLM 認証方式でアクセスできる NTLM ユーザ ドメイン名。

 


 

パブリッシング URL の生成

パブリッシング URL とは、ACNS ネットワーク内で事前配信コンテンツを再生する URL です。完全なパブリッシング URL は、次の 3 つの部分から構成されます。

スキーム

ドメイン名

パス

パスには、ファイル ディレクトリ パスとファイル名の両方が含まれます。再生サーバ リストにより、ACNS ネットワークのパブリッシング URL が決まります。再生サーバ リストは、マニフェスト ファイルから直接、マニフェスト ファイル内の <playServerTable> タグから、またはデフォルトの再生サーバ テーブルから生成されます。

スキーム

パブリッシング URL のスキームは、コンテンツ タイプの再生に使用されるプロトコルです。たとえば、.asf ビデオ ファイルを HTTP と WMT の両方の再生サーバで再生できる場合、このコンテンツのアクセスに 2 つの URL スキーム(HTTP と MMS)を使用できます。

スキームは再生サーバのタイプで決まります。再生サーバとスキーマは次のように直接対応付けられています。

 

再生サーバ
スキーム

HTTP

HTTP

RealMedia

RTSP

WMT

MMS

QTSS

RTSP

ドメイン名

パブリッシング URL のドメイン名は、ACNS ネットワークの設定により決まります。WCCP を使用して Content Engine にコンテンツ要求をリダイレクトする場合、要求 URL 内のドメイン名は Web サイトまたはチャネル内のオリジン サーバの FQDN です。コンテンツ ルーティングが使用される場合、コンテンツ ルーティングの FQDN(Web サイトの FQDN)がドメイン名になります。

マニフェスト ファイルを使用して取得されるコンテンツはすべて、Content Distribution Manager GUI( Services > Web > Channels > Edit channel > Edit Website)内にある website Origin Server フィールド(WCCP ルーティングの場合)、または Request Routed FQDN フィールド(Content Router の場合)に入力されたドメイン名で公開されます。

コンテンツが別のサーバから取得された場合であっても、コンテンツは Web サイトのオリジン サーバの FQDN からアクセス可能になっている必要があります。


) マニフェスト ファイルには <server> タグが含まれています。このマニフェスト タグの場合の「サーバ」とは、「取得サーバ」を指します。コンテンツ配信時に公開される Web サイト オリジン サーバ FQDN と同じである場合と、同じではない場合があります。取得サーバと Web サイトのオリジン サーバの FQDN との違いに注意してください。


requireAuth noRedirectToOrigin などのマニフェスト ファイル属性は、Web サイトのオリジン サーバを指します。 ttl user password などの属性は、取得サーバに関連付けられています。したがって、コンテンツ項目に requireAuth 属性を指定する場合、Content Distribution Manager GUI の Create New Web Site ウィンドウまたは Modifying Web Site ウィンドウ( Services > Web > Channels > Edit channel > Edit Website)で入力したオリジン サーバの FQDN が正確であり、次のことが可能であることを確認してください。

1. マニフェスト内で指定された通りにパスの要求を受け入れる。

2. この URL に対するエンド ユーザからの認証要求を受け入れる。

マニフェスト ファイル内で複数の取得サーバが指定されている場合であっても、この注意が該当します。「実」オリジン サーバは Web サイトのオリジン サーバの FQDN であるため、コンテンツが Web サイトのオリジン サーバの FQDN からアクセス可能であるとともに、Web サイトのオリジン サーバが認証要求を受け入れ可能であることを確認する必要があります。

パス

通常、パブリッシング URL のパスは、送信元の相対 URL、または <item> タグ内の src 属性です。コンテンツのクロールの場合、オリジン サーバのホスト名を基準にした相対 URL です。

マニフェスト ファイル内にある特定の属性を使用すると、パブリッシング URL のパスを変更できます。このような属性には、<item> タグ内の cdn-url 、および <crawler> タグ内と <item-group> タグ内の srcPrefix または cdnPrefix があります。これらの属性は、送信元の相対 URL をまったく新しい ACNS ネットワークの相対 URL に変換します。

次の例のコンテンツの場合、パスは index.html ではなく、default.html を使用します。

<item src="index.html" cdn-url="default.html"/>
 

相対 URL は、常にホスト名への相対パスにします。次の例では、相対 URL は sport/index.html ではなく、index.html です。

<server>
<host name="http://www.cnn.com/sport/"/>
</server>
 
<item src="index.html"/>
 

次の例では、 srcPrefix 属性と cdnPrefix 属性は、クロールされるすべてのコンテンツ オブジェクトのプレフィクスを、NBA/から ABC/に変換しています。相対 cdn-url は、ABC/* です。 start-url 属性のパスは、ABC/index.html です。

<crawler
start-url="NBA/index.html"
srcPrefix="NBA/"
cdnPrefix="ABC/"
/>
 

URL の特殊文字

RFC 2396 標準に従って、URL には特定の特殊文字を使用できません。取得するコンテンツの URL に不正文字が含まれている場合、不正な特殊文字を表す、ASCII コードと等価なエスケープ文字を使用して、その URL を書き換える必要があります。

たとえば、空白を表すエスケープ文字は %20 です。ファイル名に空白を使用する次のような不正 URL があるとします。

http://www.cnn.com/file with space

これは、次のように書き換えることができます。

http://www.cnn.com/file%20with%20space

Content Distribution Manager GUI の Channel definition ウィンドウ( Services > Web > Channels > Definition )内にある Manifest URL フィールドで URL を指定する場合、またはマニフェスト ファイルの次のタグ内で URL を指定する場合、ASCII コードと等価なエスケープ文字を使用して URL の書き換えが必要になることがあります。

<host name=>

<item src=>

<crawler start-url=>

<crawler externalPrefixes=>

<match prefix=>

ACNS ソフトウェアは、URL をエスケープするために次の規則を適用します。

URL 内の特殊文字 !# $ & ' ( ) , ; = ? には、特殊な機能があります。オリジン サーバ上のファイル名またはフォルダ名でこれらの特殊文字が使用されている場合は、URL を書き換える必要があります。

上記の特殊文字に加えて、次の文字もファイル名とフォルダ名に使用しないでください。次に示す ASCII コードと等価な文字に置き換えてください。

space ==> %20

" ==> %22

% ==> %25

< ==> %3c

> ==> %3e

[ => %5b

\ ==> %5c

] ==> %5d

^ ==> %5e

{ ==> %7b

| ==> %7c

} ==> %7d

~ ==> %7e

マニフェスト ファイルまたは HTML ファイル内の URL で「?」文字が使用されていると、その URL は拒否されます。URL に「#」文字が含まれている場合、その URL 内で「#」以降の部分が破棄されます。

マニフェスト ファイルまたは HTML ファイル内の URL でその他の特殊文字を使用する場合は、RFC 2396 の要件に従ってください。

再生サーバの割り当て

再生サーバはマニフェスト ファイル内で割り当てられます。詳細は、「再生サーバ リストの生成」を参照してください。

<playServer> タグは、事前配信コンテンツの再生に非常に重要です。このタグにはコンテンツを再生するための再生サーバのリストが含まれています。ACNS 事前配信コンテンツはすべて、ACNS ソフトウェアによってサポートされる再生サーバの 1 つを使用して、エンド ユーザに対してコンテンツを再生する必要があります。

ACNS 5.x ソフトウェアは、ACNS ネットワーク上の次の事前配信コンテンツ タイプを再生する、再生サーバをサポートします。

HTTP、HTTPS、WMT、RTSP(RealMedia および QuickTime Streaming Server [QTSS])

コンテンツ要求には、任意のプロトコルを使用できます。実際には、プロトコル情報は、コンテンツの再生にどの再生サーバが必要かを暗黙に指定します。ACNS ソフトウェアは、要求されたプロトコルが、再生サーバ テーブル内のリストと一致するかどうかを調べます。リストと一致する場合、要求は送信されます。リストと一致しない場合、要求は拒否されます。

次の方法で再生サーバ リストを生成できます。

マニフェスト ファイルを使用して、<item> タグの playServer 属性を設定する。

<playServerTable> タグを使用する。再生サーバの MIME タイプ拡張子名を設定する。

マニフェスト ファイルを使用して直接、再生サーバ リストを作成するには、<item> タグの再生サーバ リストの playServer 属性を設定します。<item> タグに playServer 属性がない場合、再生サーバ リストは、<playServerTable> タグを使用して生成されます。マニフェスト ファイル内で
<playServerTable> タグを省略した場合、組み込みのデフォルト <playServerTable> タグを使用して、再生サーバ リストが生成されます。次の例のように、複数のサーバはカンマで区切ります。

<item src="video.mpg" playServer="real,wmt"/>
 

また、<playServerTable> タグを使用して、これらのストリーミング メディア タイプをサポートする再生サーバ リストを生成することもできます。<playServerTable> タグは、MIME タイプの拡張子名に基づいて、コンテンツを再生サーバ リストにマップします。マニフェスト ファイルに <playServerTable> タグがある場合は、このタグを使用して再生サーバ リストを生成します。

<playServerTable> タグを使用して再生サーバ リストを生成するには、次の例のように、MIME タイプの拡張子名を使用して、どの再生サーバが特定の事前配信コンテンツを再生できるかを設定します。

<playServerTable>
<playServer name="real">
<contentType name="application/x-pn-realaudio"/>
<contentType name="application/vnd.rn-rmadriver"/>
<extension name="rm"/>
<extension name="ra"/>
<extension name="rp"/>
<extension name="rt"/>
<extension name="smi"/>
</playServer>
<playServer name="wmt">
<extension name="wmv"/>
<extension name="wma"/>
<extension name="wmx"/>
<extension name="asx"/>
<extension name="asf"/>
<extension name="avi"/>
</playServer>
<playServer name="http">
<contentType name="application/pdf"/>
<contentType name="application/postscript"/>
<extension name="pdf"/>
<extension name="ps"/>
</playServer>
</playServerTable>
 

<playServerTable> タグは、コンテンツ タイプごとに再生サーバ リストを生成する場合に使用されます。前述の例で注意すべきことは、PDF または PostScript の拡張子を持つファイルは、HTTP を使用してコンテンツを再生するということです。

HTTP と HTTPS はデフォルトの再生サーバです。すなわち、コンテンツに対応した再生サーバを指定するために、カスタマイズされた <playServerTable> タグ、または playServer name フィールドを使用しなかった場合、HTTP と HTTPS が playServer name フィールドに追加され、常に HTTP と HTTPS を使用してコンテンツが再生されます。

マニフェスト ファイルの <playServerTable> タグまたは playServer 属性を使用した場合、HTTP と HTTPS が再生用に自動的に許可されることはありません。この場合、特定のコンテンツの再生に HTTP または HTTPS を使用する場合は、そのプロトコルを指定する必要があります(次の例を参照)。

<CdnManifest>
 
<playServerTable>
<playServer name="wmt">
<extension name="asf"/>
</playServer>
<playServer name="tvout">
<extension name="mpg"/>
</playServer>
<playServer name="https">
<contentType name="text/html"/>
</playServer>
</playServerTable>
 
<item src="http://www.aaa.com/a.asf"/>
<item src="http://www.aaa.com/b.html"/>
<item src="http://www.aaa.com/c.mpg"/>
<item src=”http://www.aaa.com/d.jpg" playServer=”http,https”/>
<item src=”http://www.aaa.com/e.rm"/>
 
</CdnManifest>
 

この例では、次のような再生サーバ リストが生成されます。

 
a.asf: wmt: from <playServerTable> by extension
b.html: https: from <playServerTable> by contentType
c.mpg: tvout: from <playServerTable> by extension.
d.jpg : http + https: from “playServer” attribute
e.rm : real + http + https: from build-in <playServerTable>
 

マニフェスト ファイル内では .rm 拡張子に指定されている再生サーバがないため、組み込みのルールにより、この拡張子に対する再生サーバは RealMedia になります。また、組み込みのデフォルト <playServerTable> タグが使用された場合、HTTP と HTTPS 再生サーバが自動的に追加されます。

TV-Out 再生サーバは、すべての事前配信コンテンツを再生できる特別な再生サーバです。コンテンツを他の再生サーバで再生しない場合は、TV-Out 再生サーバを指定します。ACNS ソフトウェアでは、再生サーバが指定されている場合は、コンテンツを他の再生サーバで再生することはできません。

プロキシ サポート

オリジン サーバが特定のプロキシ サーバからのアクセスのみを許可するように設定されているため、ルート Content Engine がそのオリジン サーバに直接アクセスできないときは、プロキシ サーバ経由でコンテンツ取得を行うように設定できます。ルート Content Engine を使用してコンテンツを取得する場合にプロキシ サーバを使用するように設定すると、取得機能は、オリジン サーバではなく、プロキシ サーバと交信し、そのオリジン サーバに対する要求はすべてプロキシ サーバを介して行われます。


) プロキシ サーバを介したコンテンツ取得は、HTTP 要求に対してのみサポートされます。HTTPS、FTP、MMS、または MMS-over-HTTP 要求に対してはサポートされません。


透過 WCCP プロキシを使用する場合、プロキシでコンテンツの取得を設定する必要はありません。このような場合、取得機能からの HTTP 要求は、ルータによって WCCP プロキシにリダイレクトされます。しかし、HTTP 要求をプロキシ サーバにリダイレクトするルータを使用しない場合、プロキシ サーバを使用するように、Content Engine を設定する必要があります。

プロキシ サーバを設定するには、Content Distribution Manager GUI、Content Engine CLI、マニフェスト ファイルの 3 通りの方法から選択できます。コンテンツのキャッシングとコンテンツの事前配信の両方にプロキシを使用するように Content Engine を設定する必要がある場合、CLI を使用してプロキシを設定します。この CLI コマンドは、プロキシを使用するように Content Engine 全体を設定するグローバル コンフィギュレーション コマンドです。Content Engine の取得機能部分だけで、事前配信コンテンツを取得するためにプロキシを使用する必要がある場合は、マニフェスト ファイルを使用するか、または発信プロキシを指定します。マニフェスト ファイル内でプロキシ サーバを設定する場合、特定チャネルのコンテンツを取得するプロキシを使用するように取得機能を設定します。


) マニフェスト ファイル内のプロキシ設定は、CLI からのプロキシ設定より優先されます。さらに、マニフェスト ファイル内の noProxy 設定は、マニフェスト ファイル内のその他のプロキシ サーバ設定より優先されます。


また、Content Distribution Manager GUI(Creating New Channel ウィンドウまたは Modifying Channel ウィンドウ)を使用して、マニフェスト ファイルを取得するプロキシを設定することもできます。Content Distribution Manager GUI でプロキシ サーバを設定する場合、プロキシ設定は、マニフェスト ファイル自体の取得に対してのみ有効です。チャネル コンテンツの取得には有効ではありません。マニフェスト ファイルに対する要求は、プロキシ サーバを通して行われます。一方、コンテンツに対する要求は、直接、オリジン サーバへ渡されます。


ヒント プロキシ サーバを設定する場合は、事前に、ルート Content Engine がそのプロキシ サーバを ping できることを確認してください。プロキシ サーバが、設定されたポートで着信 HTTP トラフィックを受け入れるかどうかを調べるには、ルート Content Engine CLI で acquirer test-url http://proxyIP:proxyport グローバル コンフィギュレーション コマンドを使用します。ここで、コマンド内の URL は、テストされるプロキシ サーバの URL です。設定されたポートをプロキシが処理しない場合、「failed: Connection refused.」というメッセージが表示されます。


Content Distribution Manager GUI を使用したホストとプロキシ サーバの設定

Content Distribution Manager GUI を使用して、定義されているコンテンツ項目のプロキシ サーバを設定する手順は、次のとおりです。


ステップ 1 Services > Web > Channels の順に選択します。Channels ウィンドウに、ACNS ネットワーク内のすべてのチャネルが表示されます。

ステップ 2 マニフェスト ファイル項目のプロキシ サーバを設定するチャネルの横にある Edit アイコンをクリックします。Modifying Channel ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Channel Content を選択します。Content Acquisition Method for Channel-Use GUI to Specify Content Acquisition ウィンドウが表示されます。

ステップ 4 タスクバーから Manage Host and Proxy Settings アイコンをクリックして、プロキシ サーバ情報を設定します。Content Hosts ウィンドウに、作成済みのホスト URL、各ホストのコンテンツ項目数、プロキシ サーバ(設定されている場合)が表示されます。

ステップ 5 プロキシ サーバを設定するホスト URL の横にあるチェックボックスにチェックマークを付けます。複数のホスト URL を選択し、複数のプロキシ サーバを設定することもできます。

ステップ 6 Manage Proxy for Selected Hosts ボタンをクリックします。新規ウィンドウが表示されます。Defining proxy server for the following hosts の項目の下に、設定されるプロキシ サーバに対するホスト サーバのリストが表示されます。

Content Acquisition Method for Channel-Use GUI to Specify Content Acquisition ウィンドウに戻るには、 Return to Content Listing ボタンをクリックします。

ステップ 7 右側の Proxy Server specifications セクションにあるフィールドを使用して、マニフェスト ファイルを取得するために取得機能のプロキシ情報を設定します。プロキシ サーバを設定すると、オリジン サーバからマニフェスト ファイルを取得する要求はプロキシ サーバを介して行われるようになります(プロキシ サーバのプロパティを設定するためのフィールドについては、 表6-4 を参照)。

このセクションにあるフィールドを使用すると、取得機能についてプロキシ サーバを設定できます。これらのフィールドは、マニフェスト ファイルの <proxyServer> タグに指定されている属性に関連付けられています。マニフェスト ファイル内で設定されたプロキシ サーバは、マニフェスト ファイル内で指定されるすべてのホストに有効です。指定されたプロキシが失敗すると、取得機能はデフォルトでオリジン サーバと直接交信し、オブジェクトを取得しようとします。

ステップ 8 Add をクリックして、プロキシ サーバを左側の Select a proxy server セクションに追加します。フィールドを変更する必要がある場合は、 Cancel をクリックして値を消去し、指定し直します。

ステップ 9 プロキシ ホストを変更するには、Select a proxy server セクションの一番下にある Edit をクリックします。右側の Proxy Server specifications セクションの下にあるフィールドに、設定された値が表示され、これらの値を変更することができます。設定が完了したら、 Update をクリックして、変更した設定値を保存します。

ステップ 10 プロキシ ホストを削除するには、Select a proxy server セクションの一番下にある Delete をクリックします。

ステップ 11 Select a Proxy Server セクション内に、定義済みのプロキシ サーバがプロキシ ホスト名順で表示されます。

ホスト URL のプロキシ サーバを定義するには、プロキシ ホスト名を選択し(選択されたプロキシ ホストは強調表示されます)、 Save Assignment ボタンをクリックします。Content Hosts ウィンドウが表示されます。

特定のホストに対する要求をすべて直接オリジン サーバに送信して、プロキシを使用しない場合は、 Do not use proxy server を選択し、 Save Assignment ボタンをクリックします。Content Hosts ウィンドウが表示されます。

このオプションは、<host> タグ、<item> タグ、または <crawler> タグに指定される noProxy 属性に関連付けられています。noProxy= "1" と指定すると、項目とクロール タスク データが直接オリジン サーバから取得されます(詳細は、noProxy 属性の概要 を参照)。

Content Hosts ウィンドウで、プロキシ サーバを定義して割り当てるホスト URL を複数選択した場合、選択したホスト URL がすでに別のプロキシ サーバに割り当てられていると、「Hosts selected use different proxy servers.」という警告メッセージがウィンドウの一番上に表示されます。

選択したすべてのホスト URL に共通のプロキシ サーバを割り当てるには、プロキシ ホスト名を選択し(選択されたプロキシ ホストは強調表示されます)、 Save Assignment ボタンをクリックします。それ以外の場合は、 Do not change assignments を選択してホスト URL に定義されているプロキシ ホストの割り当てを保持し、 Save Assignment ボタンをクリックします。

ホスト URL のプロキシ サーバを変更したあとに割り当てを変更しない場合は、 Cancel Assignment ボタンをクリックします。Content Hosts ウィンドウが表示されます。

 

表6-4 プロキシ サーバの設定

GUI パラメータ
機能
マニフェスト属性

Proxy Hostname

取得機能がコンテンツの取得に使用するプロキシ サーバのホスト名または IP アドレス。IP アドレスではなくドメイン名を使用する場合は、設定されている DNS サーバによって名前解決できることを確認してください。

serverName

Proxy Port

取得機能がコンテンツを取得するプロキシ サーバのポート番号。範囲は 1~65535 です。

port

Disable Basic Authentication

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

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

disableBasicAuth

User Name

マニフェスト ファイルを取得するために認証されるユーザの名前。

user

Password

プロキシからの認証を受けるためのユーザのパスワード。

password

 


 

CLI を使用した HTTP プロキシ サーバの設定

CLI を使用してプロキシ サーバを設定するには、 http proxy outgoing グローバル コンフィギュレーション コマンドを使用します。これは、キャッシングと事前配信コンテンツの取得に使用するグローバル プロキシ設定です。このコマンドを使用すると、CLI を使用して発信プロキシ サーバのリストを設定できます。プロキシが設定されると、ホストに対するすべての要求はプロキシ サーバを介して行われます。グローバル プロキシ設定をリセットするには、このコマンドの no 形式を使用します(次の例を参照)。

ContentEngine(config)# http proxy outgoing ?
connection-timeout Timeout period used for probing outgoing proxy servers in microseconds
host Use Outgoing HTTP Proxy
monitor Interval at which to monitor the outgoing proxy servers
origin-server Use Origin Server if all outgoing proxies failed.
preserve-407 Preserve 407 HTTP authentication header
 
ContentEngine(config)# http proxy outgoing host ?
Hostname or A.B.C.D Hostname or IP address of outgoing proxy
 
ContentEngine(config)# http proxy outgoing host 128.107.192.24 ?
<1-65535> Port of outgoing proxy
 
ContentEngine(config)# http proxy outgoing host 128.107.192.24 80
 

取得機能がプロキシ サーバと交信できない場合、そのプロキシはディセーブルであるとみなされます。 http proxy outgoing コマンドの monitor オプションで指定された時間経過後に、取得機能はディセーブルになっているプロキシをリトライします。モニタ間隔を設定しない場合、デフォルトのリトライ間隔は 30 分です。

発信プロキシがすべて失敗したときに、取得機能を直接オリジン サーバに交信させる場合は、 origin-server キーワードを使用します(次の例を参照)。

ContentEngine(config)# http proxy outgoing origin-server
 

発信プロキシ サーバのリストが CLI で設定されていて、最初のプロキシ サーバが失敗した場合、リストに記述されている次のプロキシ サーバが試行されます(以降同様)。すべてのプロキシが失敗した場合、 http proxy outgoing origin-server コマンドの設定に応じて、取得機能はオリジン サーバにフェールオーバーします。

発信プロキシが CLI で設定されていることを確認するには、 show http proxy EXEC コマンドを使用します(次の例を参照)。

CE-507# show http proxy
Incoming Proxy-Mode:
Not servicing incoming proxy mode connections.
Outgoing Proxy-Mode:
Primary Proxy Server: 128.107.192.190 port 9090
 
Monitor Interval for Outgoing Proxy Servers is 60 seconds
 
Timeout period for probing Outgoing Proxy Servers is 300000 microseconds
 
Use of Origin Server upon Proxy Failures is disabled.
 

コンテンツがプロキシ経由で取得されているかどうかを確認するには、取得と配信のトランザクション ログを使用して、proxyUsed 行を調べます。この行には、要求に使用されるプロキシ サーバが示されます。

マニフェスト ファイルを使用したプロキシ サーバの設定

マニフェスト ファイル内の <proxyServer> タグを使用すると、取得機能のプロキシ サーバを設定できます。マニフェスト ファイル内で設定されたプロキシ サーバは、マニフェスト ファイル内で指定されるすべてのホストに有効です。指定されたプロキシが失敗すると、取得機能はデフォルトでオリジン サーバと直接交信し、オブジェクトを取得しようとします。

マニフェスト ファイル内に複数のプロキシ サーバがある場合、および異なるホストに別々のプロキシ サーバを関連付けたい場合は、<host> タグ内に proxyServer 属性を組み込む必要があります。最初の例では、<proxyServer> タグは、 proxyServer 属性(proxyServer= "172.19.226.242")を介して <host> タグに関連付けられています。この <host> タグを使用する項目はすべて、このプロキシ サーバを使用します。


) <proxyServer> タグは、マニフェスト ファイルの一番上のレベルで、<CdnManifest> タグのすぐ下に置く必要があります。他のタグのサブタグとして使用することはできません。このタグは、
proxyServer
属性を介して <host>、<item>、および <crawler> タグに関連付けられます。


<CdnManifest>
<proxyServer
serverName="172.19.226.242"
port="8080"
/>
<server name="my-devbox">
<host name="http://vista2.cisco.com"
proxyServer="172.19.226.242"
proto="http"/>
</server>
<item src=”HR/salary.htlm”/>
<item src=”HR/Holidays.html”/>
</CdnManifest>
 

次の例では、 proxyServer 属性が、<item> タグと <crawler> タグに関連付けられていることを示しています。プロキシ サーバは、2 番めの <item> タグと <crawler> タグに適用されますが、最初の <item> タグには適用されません。

<CdnManifest>
<item src=”http://www.msnbc.com/computer/jokes.html”/>
<proxyServer serverName=”128.107.192.24” port = “80”/>
<item src=”http://www.cnn.com/War/World-war-two.jpg”/>
<crawler start-url=”http://www.abc.com/War/World-war-two/index.html”/>
</CdnManifest>
 

<proxyServer> タグの serverName 属性に IP アドレスを使用する代わりに、ドメイン名を使用することもできます(次の例を参照)。

<proxyServer
serverName="spachiap-uni1"
port="8080"
/>
<server name="my-devbox">
<host name="http://128.107.150.26/nfs-obsidian/Unicorn"
proxyServer="spachiap-uni1"
proto="http"/>
</server>
 

IP アドレスではなくドメイン名を使用する場合は、そのドメインの名前が設定されている DNS サーバによって名前解決できることを確認してください。

noProxy 属性の概要

マニフェスト ファイルで、特定ホストに対するすべての要求が直接オリジン サーバへ送信され、 http proxy outgoing host コマンドで指定されたプロキシを使用しないように設定するには、 noProxy 属性を指定します。ただし、この設定は任意のプロキシが CLI で設定されている場合に限られます。

noProxy 属性は、<host>、<item>、または <crawler> タグのいずれかで指定できます。次の例では、 http proxy outgoing host コマンドを使用してルート Content Engine にプロキシを設定した場合、マニフェスト ファイル内の最初の項目はそのプロキシを使用します。ただし、2 番め以降の項目またはクロール タスクは使用しません。noProxy= "1" と指定すると、2 番めの項目とクロール タスク データが直接オリジン サーバから取得されます。

<CdnManifest>
<item src=”http://www.msnbc.com/computer/jokes.html”/>
<item src=” http://www.cnn.com/War/World-war-two.jpg
noProxy=”1”/>
<crawler start-url=”http://www.abc.com/War/World-war-two/index.html
noProxy=”1”/>
<server name=”cisco” >
<host name=”http://www.cisco.com” noProxy=”1”/>
</server>
<crawler start-url=”product/routers/”/>
</CdnManifest>
 

マニフェスト ファイルのプロキシ サーバとポートの設定

マニフェスト ファイルを取得するために使用するプロキシ サーバとポートは、Content Distribution Manager GUI の Channel Content ウィンドウで設定できます。プロキシ サーバを設定すると、マニフェスト ファイルに対する要求は、Content Distribution Manager GUI で指定されたプロキシ サーバを介して行われます。


) Channel Content ウィンドウでのプロキシ設定は、マニフェスト ファイルの取得だけに適用されます。コンテンツの取得には適用されません。


マニフェスト ファイルがプロキシを必要とするオリジン サーバに置かれている場合、Content Distribution Manager GUI の Channel Content ウィンドウの Define Manifest Proxy Information セクション内にあるフィールドに、プロキシの名前または IP アドレス、およびプロキシ ポートを指定する必要があります(図6-9 を参照。このウィンドウのフィールドについては、 表6-3 を参照)。

http proxy outgoing host CLI コマンドで設定されるプロキシを使用できないオリジン サーバ上にマニフェスト ファイルが置かれている場合、 Disable All Proxy チェックボックスにチェックマークを付ける必要があります。

Disable All Proxy チェックボックスにチェックマークを付けると、Proxy Hostname フィールドと Proxy Port フィールドの値が無視されます。


) Channel Content ウィンドウ内の Manifest Proxy Information フィールドを入力可能にするには、Manifest URL フィールドに URL を入力する必要があります。


認証サポート

取得機能は、2 つのタイプの認証方式(基本認証と NTLM 認証)をサポートします。認証情報は、取得の対象に応じて、Content Distribution Manager GUI かマニフェスト ファイルのいずれかで設定します。

オリジン サーバまたはプロキシ サーバからマニフェスト ファイルを取得するために認証が必要な場合、Content Distribution Manager GUI で認証情報を指定できます。 Services > Web > Channels の順に選択して表示される Channel Content ウィンドウから、基本認証をディセーブルにして、ユーザ名とパスワードを入力し、NTLM ユーザ ドメイン名を指定します(図6-9 では、認証情報を入力するためのフィールドを示しています。 表6-3 では、これらのフィールドについて説明しています)。


) Channel Content ウィンドウでの認証設定は、マニフェスト ファイルの取得だけに適用されます。コンテンツの取得には適用されません。


オリジン サーバまたはプロキシ サーバから事前配信コンテンツを取得するために認証が必要な場合、マニフェスト ファイルに認証情報を指定する必要があります(次の「NTLM 認証が必要なコンテンツの取得」を参照)。

NTLM 認証が必要なコンテンツの取得

ACNS 5.x ソフトウェアでは、基本認証実行後、ルート Content Engine は HTTP オリジン サーバまたはプロキシ サーバからコンテンツを取得できます。ただし、多くの場合、オリジン サーバは NTLM 認証だけをサポートしています。ACNS 5.4 ソフトウェアでは、取得機能が NTLM クライアントとして動作し、NTLM 対応のオリジン サーバと通信します。


) Content Engine の取得機能は、NTLM バージョン 1 だけをサポートします。


コンテンツを取得するために認証が必要な場合、次のマニフェスト ファイル属性を使用して、マニフェスト ファイル内で認証情報を指定する必要があります。

user ― ユーザ アカウント

password ― パスワード

NTLM 認証が必要な場合、次の 2 つの追加マニフェスト ファイル属性を指定できます。

ntlmUserDomain ― NTLM ユーザ ドメイン名。この属性は、NTLM 認証方式に必要です。

disableBasicAuth ― (任意属性)必要に応じて、基本認証をディセーブルにします。ユーザ名とパスワードを常に NTLM 認証に使用し、基本認証には使用しない場合は、この属性を true に設定します。この属性が省略されている場合、デフォルトは false です。

これらの属性は、<host>、<item>、<item-group>、および <crawler> タグで指定できます。詳細は、 付録 A「マニフェスト ファイルの作成」 を参照してください。

オリジン サーバまたはプロキシ サーバが基本認証と NTLM 認証の両方をサポートする場合、取得機能は応答確認リストから、サポートされている最初の認証方式を選択します。取得機能が使用する認証方式は、指定された認証情報によっても異なる場合があります。たとえば、IIS サーバが最初の方式として NTLM で応答し、2 番めの方式として基本認証で応答するとします。この場合、取得機能は NTLM を選択します。しかし、ntlmUserDomain 属性がマニフェスト ファイルに指定されていない場合、取得機能は基本認証を選択します。disableBasicAuth 属性が true に設定されている場合、取得機能は NTLM 認証を選択します。

ルート Content Engine CLI から取得と配信のトランザクション ログを表示すると、取得機能が使用した認証方式を判別できます。

プロキシ認証のサポート

ルート Content Engine のプロキシがルート Content Engine CLI で設定されている場合( http proxy outgoing host コマンド)、Content Distribution Manager GUI(Content Distribution Manager GUI を使用した HTTP プロキシ認証の設定を参照)、またはルート Content Engine CLI(「 CLI を使用したプロキシ認証の設定 」を参照)のいずれかから、プロキシの認証情報を設定できます。

マニフェスト ファイルを取得するためのプロキシ認証の設定

プロキシ サーバからマニフェスト ファイルを取得するために認証情報を設定する手順は、次のとおりです。


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

ステップ 2 変更するチャネルの名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Channel Content を選択します。

ステップ 4 Define Manifest Proxy Information の項目の下にある該当するフィールドに、認証情報を入力します(図6-9 では、認証情報を入力するためのフィールドを示しています。 表6-3 では、これらのフィールドについて説明しています)。

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


 

マニフェスト ファイルを使用したプロキシ認証の設定

次の例では、プロキシ サーバの認証情報を指定しています。詳細は、 付録 A「マニフェスト ファイルの作成」 を参照してください。

<CdnManifest>
<!-- specify a proxy server/port and its authentication info
this proxy supports Basic auth so only user/password is needed -->
<proxyServer serverName="128.107.192.24" port = "80"
user="johnz" password="xxx123yyy"/>
 
<!-- this item is below the proxyServer tag; it is using the above proxy -->
 
<item src="http://www.cnn.com/War/World-war-two.jpg"/>
 
<!-- specify a proxy server/port and its authentication info
this proxy requires NTLM auth, so ntlmDomainName is needed
for extra password security, users want to disable basic auth
so their user/password is not sent over the wire -->
 
<proxyServer serverName="company-proxy" port = "80"
user="johnz" password="xxx123yyy"
ntlmUserDomain="cisco-eng"
disableBasicAuth="1"/>
 
<!-- this crawler is below the proxyServer tag; it is using the proxy -->
 
<crawler start-url="http://www.abc.com/War/World-war-two/index.html"/>
</CdnManifest>
 

Content Distribution Manager GUI を使用した HTTP プロキシ認証の設定

プロキシ サーバ経由でコンテンツを受信するようにルート Content Engine が設定されている場合、ルート Content Engine 上で実行される取得機能は、オリジン サーバからコンテンツを取得する前にプロキシ サーバの認証を受ける必要があります。

http proxy outgoing host コマンドを使用して指定されたプロキシの認証情報を設定するには、Content Distribution Manager GUI の Acquirer Outgoing Proxy Authentication セクション( Devices > Devices > Applications > Web > HTTP > HTTP Connections )を使用して、プロキシの認証情報を設定できます。ACNS ソフトウェアは、複数のプロキシをサポートします。したがって、複数のプロキシに対してプロキシ認証情報を設定することもできます。


) マニフェスト ファイルで <proxyServer> タグを指定するか、Content Distribution Manager GUI の Channel Content ウィンドウ(Services > Web > Channels)で Manifest URL フィールドにプロキシ ホストの IP アドレスを入力すると、http proxy outgoing host コマンドが無視されます。


取得機能の発信プロキシ認証情報を設定する手順は、次のとおりです。


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

ステップ 2 ルート Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > HTTP Connections の順に選択します。HTTP Connection Settings for Content Engine ウィンドウが表示されます。

ステップ 4 Acquirer Outgoing Proxy Authentication の項目の下で、各行にリストされている発信プロキシに次の情報を入力します。

a. オリジン サーバからコンテンツを取得する場合には、Username フィールドに認証を受けるユーザの名前を入力します。このユーザ名は、NTLM 認証と基本認証の両方に使用されます。

b. Password フィールドに、ユーザのパスワードを入力します。確認のために、Confirm Password フィールドにパスワードを再度入力します。入力されたパスワードはアスタリスク(*)で表示されます。

c. NTLM User Domain フィールドに、ユーザのアクセス権を認証するために使用される NTLM サーバ ドメイン名を入力します。

d. NTLM ヘッダーを削除せず、基本認証方式へのフォールバックを許可しない場合は、 Disable basic authentication チェックボックスにチェックマークを付けます。

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

ステップ 5 発信プロキシの認証設定を保存するには、 Submit をクリックします。


 

CLI を使用したプロキシ認証の設定

http proxy outgoing host コマンドを使用して指定されたプロキシの認証情報を設定するには、ルート Content Engine CLI から acquirer proxy authentication outgoing コマンドを使用することもできます。次の例では、NTLM 認証を使用した非透過プロキシ サーバの認証情報(IP アドレス 192.168.1.1、ポート 8080)を示しています。

CE(config)# acquirer proxy authentication outgoing 192.168.1.1 8080 myname password password ntlm mydomain basic-auth-disable
 

) ルート Content Engine とオリジン サーバ間に透過プロキシがある場合、ルート Content Engine CLI から acquirer proxy authentication transparent コマンドを使用すると、透過プロキシの認証情報を指定できます(CLI を使用した WCCP プロキシの認証設定を参照)。


認証情報が正しく設定されたことを確認するには、 show acquirer proxy authentication EXEC コマンドを使用してください。

チェーン内に認証を必要とするプロキシが 1 つだけ存在する場合、取得機能はプロキシ チェーニングをサポートします。チェーン内に認証を必要とするプロキシが複数存在する場合、取得機能は失敗します。

Content Distribution Manager GUI を使用した WCCP プロキシ認証の設定

WCCP プロキシを使用した透過キャッシング環境では、コンテンツに対する要求は、WCCP 対応ルータによって Content Engine にリダイレクトされます。ルート Content Engine からオリジン サーバへの HTTP プロキシ スタイルの要求が、認証を必要とする WCCP プロキシによって代行受信される場合、その WCCP プロキシの認証を設定できます。

透過プロキシ環境で取得機能の WCCP プロキシ認証を設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。

ステップ 2 取得機能の WCCP プロキシ認証を設定する Content Engine の横にある Edit アイコンをクリックします。Device Home ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Prepositioning > Acquirer WCCP Proxy Authentication の順に選択します。Acquirer WCCP Proxy Authentication for Content Engine ウィンドウが表示されます(図6-10 を参照)。

図6-10 取得機能の WCCP プロキシ認証

 

ステップ 4 Enable チェックボックスにチェックマークを付けて、取得機能の透過プロキシ認証をイネーブルにします。

ステップ 5 Username フィールドに、オリジン サーバからコンテンツを取得するために認証を受けるユーザ名を入力します。このユーザ名は、NTLM 認証と基本認証の両方に使用されます。

ステップ 6 Password フィールドに、ユーザのパスワードを入力します。確認のために、Confirm Password フィールドにパスワードを再度入力します。入力されたパスワードはアスタリスク(*)で表示されます。

ステップ 7 NTLM user domain フィールドに、ユーザのアクセスを認証するために使用される NTLM サーバ ドメイン名を入力します。

ステップ 8 Disable basic authentication チェックボックスにチェックマークを付けて、NTLM ヘッダーの削除をディセーブルにします。このチェックボックスにチェックマークを付けると、NTLM ヘッダーが削除されず、基本認証方式へのフォールバックが回避されます。

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

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

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


 

WCCP プロキシ認証設定の変更

次の WCCP プロキシ認証設定を任意の順序で変更できます。

Content Engine の設定を削除するには、タスクバーから Remove Device Settings アイコンをクリックして、設定を削除します。このアイコンが表示されるのは、Content Engine がすでに設定済みの場合だけです。

Content Engine を出荷時のデフォルト設定に戻すには、タスクバーから Apply Defaults アイコンをクリックします。

Content Engine に適用されたデバイス グループ設定を出荷時のデフォルト値に変更するには、タスクバーから Override Group Settings with Defaults アイコンをクリックします。このアイコンが表示されるのは、Content Engine にデバイス グループ設定をすでに適用してある場合だけです。

Content Engine が関連付けられているデバイス グループから設定が適用された場合、タスクバーから Override Group Settings アイコンをクリックして、デバイス グループ設定を変更し、デバイスの設定を指定します。このアイコンが表示されるのは、Content Engine にデバイス グループ設定を適用した場合だけです。

取得機能の WCCP プロキシ認証設定で指定された 1 つまたは複数のデバイス グループに Content Engine が関連付けられている場合、タスクバー内にドロップダウン リストが表示されます。別のデバイス グループの設定をこの Content Engine に適用する場合は、このリストからデバイス グループ名を選択できます。

CLI を使用した WCCP プロキシの認証設定

透過 WCCP プロキシに対して認証が必要な場合、ルート Content Engine CLI から acquirer proxy authentication transparent グローバル コンフィギュレーション コマンドを使用して、認証情報を指定できます。次の例では、基本認証を使用する透過 WCCP プロキシ サーバの認証設定を示しています。ユーザ名は admin 、パスワードは default です。

CE(config)# acquirer proxy authentication transparent
CE(config)# acquirer proxy authentication transparent admin
CE(config)# acquirer proxy authentication transparent admin password
CE(config)# acquirer proxy authentication transparent admin password default

結果の確認

取得した結果を確認するには、次の show CLI コマンドを使用してください。

 

表6-5 コンテンツ取得用の show コマンド

コマンド
説明

show acquirer channel

Content Engine をルート Content Engine として使用するチャネル数を表示します。

show acquirer progress

取得の進行状況を表示します。

show acquirer progress streams

MMS ストリーミング ダウンロードの進行状況を表示します。

show statistics acquirer

コンテンツ取得の結果を表示します。すなわち、取得した項目数、および使用したディスク スペース量を表示します。

show statistics acquirer job-list

ID または名前で指定されたすべてのチャネルの単一項目とクロール ジョブに関する詳細を表示します。

show statistics acquirer error

取得に失敗したことを知らせる詳細なエラー メッセージを表示します。


) クロール ジョブの場合、最初に検出された 100 個のエラーだけが表示されます。


 

show statistics replication

複製状況を表示します。

チャネルのルート Content Engine である Content Engine に対して、取得の進行状況をモニタし、トラブルシューティングを行うには、次のコマンドを使用します。

show acquirer EXEC コマンドを使用すると、ルート Content Engine 上で取得機能が正常に進行して、デバイスがコンテンツの取得に設定どおりの帯域幅を使用していることを確認できます。次の例では、デバイスの取得機能が正常に実行されていること、およびデバイスにコンテンツの取得に使用する帯域幅を制限する設定がされていないことを示しています。

Content Engine# show acquirer
Acquirer is running OK
Current Acquisition Bandwidth:Not Limited
 

コンテンツ取得の進行状況を調べるには、show acquirer progress EXEC コマンドを使用します。特定のチャネルの進行状況を表示するには、個別のチャネル ID またはチャネル名を指定します。次の例では、取得機能がすでに 2237項目を取得したことを示しています。

ContentEngine# show acquirer progress channel-id 639
Querying Database.......
 
Acquirer progress information for channel ID:639 Channel-Name:external
-----------------------------------------------------------------
 
Acquired Single Items : 0/0
Acquired Crawl Items : 2237/2500 -- start-url=www.mtv.com//
 

特定のチャネルの詳細な取得統計情報を表示するには、show statistics acquirer channel-id EXEC コマンドまたは show statistics acquirer channel-name EXEC コマンドを使用します。次の例では、項目を取得する際に 2 つの項目にてエラーがあったことを示しています。

ContentEngine# show statistics acquirer channel-id 639
Querying Database.......
 
Statistics for Channel Channel-id :639 Channel-Name :external
---------------------------------------------------------
 
Manifest:
---------
Fetch Errors :0
Parsing Errors :0
Parsing Warnings:0
 
Acquisition:
-------------
Total Number of Acquired Objects :2237
Total Disk Used for Acquired Objects :981511280 Bytes
Total Number of Failed Objects :2
Total Number of Re-Check Failed Objects :0
 

エラーが発生した理由を表示するには、show statistics acquirer errors channel-id EXEC コマンドまたは show statistics acquirer errors channel-name EXEC コマンドを使用します。次の例では、URL の取得に問題があったため、1 つのエラーが発生したことを示しています。もう 1 つのエラーが発生した理由は、指定された URL を取得しようとしたら、Content Distribution Manager GUI で設定したチャネルのディスク割り当て量を超えてしまうということを示しています。チャネルのディスク割り当て量を増やすと、このエラーを解決できます。

Content Engine# show statistics acquirer errors channel-id 639
Querying Database.......
 
Acquisition Errors for the Channel ID:639
-------------------------------------
 
Crawl job:start-url http://www.mtv.com//
 
 
Crawl Errors
---------------
Internal Server Error(500):http://cgi.cnn.com/entries/intl-emailsubs-confirm
Exceeded Disk Quota(703):http://www.cdt.org/copyright/backgroundchart.pdf
 

Microsoft Media Server の URL に WGET または MMS テスト プログラムを使用して、Content Engine が問題の URL を取得できるかどうかを調べるには、acquirer test-url グローバル コンフィギュレーション コマンドを使用します。このコマンドは、個々の URL でネットワークの問題なのか、またはサーバ側の問題なのかを切り分けて、修正したい場合に使用します。

Content Engine# acquirer test-url http://cgi.cnn.com/entries/intl-emailsubs-confirm
--19:13:14-- http://cgi.cnn.com/entries/intl-emailsubs-confirm
=> `/dev/null'
Len - 50 , Restval - 0 , contlen - 0 , Res - 134727928Resolving cgi.cnn.com...
done.
Connecting to cgi.cnn.com[207.25.71.15]:80... connected.
HTTP request sent, awaiting response... 500 An error occurred processing your request.
(365 to go)ERROR 500:An error occurred processing your request..
 

ストリーミング メディアの取得の進行状況を表示するには、show acquirer progress streams EXEC コマンドを使用します。このコマンドを使用すると、ストリーミング コンテンツを取得しているチャネルの詳細な情報がわかります。次の例では、最初の URL の取得が 43% 完了し、2 番めの URL の取得が 98% 完了していることを示しています。

Content Engine# show acquirer progress streams
Querying Database.......
 
MMS URL = mms://172.19.224.235/MBR_Consumer_Med.wmv
MMS Bandwidth ID = 0
Stream Start Time = Mon Sep 22 19:29:44 2003
Duration Requested = 258 sec
Duration Passed = 112 sec
Percentage Complete = 43%
Requested Bandwidth = 1067 kbps
Minimum Bandwidth Required = 361 kbps
Reserved Bandwidth = 1067 kbps
Size To Be Downloaded = 34418305 bytes
Size Downloaded = 14881905 bytes
 
MMS URL = http://172.19.224.235:8080/BillGSpeech_32k.wma
MMS Bandwidth ID = 1
Stream Start Time = Mon Sep 22 19:29:44 2003
Duration Requested = 111 sec
Duration Passed = 112 sec
Percentage Complete = 98%
Requested Bandwidth = 32 kbps
Minimum Bandwidth Required = 24 kbps
Reserved Bandwidth = 32 kbps
Size To Be Downloaded = 456245 bytes
Size Downloaded = 450720 bytes
 

コンテンツ取得に関する詳しいトラブルシューティングが必要な場合、debug acquirer trace EXEC コマンドを使用して、取得機能のデバッグ レベルを上げることができます。ログは
local1/errorlog/acquirer-errorlog.current に書き込まれます。MMS プロトコルを介した取得のログは local1/errorlog/acquirer-mms-errorlog.current に書き込まれます。

リトライと更新のメカニズム

ACNS 5.x ソフトウェアは、マニフェスト ファイルで複数のリトライおよび更新メカニズムをサポートします。次のことに注意してください。

<schedule> サブ要素と <repeat> サブ要素の使用

ACNS 5.4 ソフトウェアは、マニフェスト ファイルで<schedule> と <repeat> の 2 つのサブ要素をサポートします。これらのタグを使用すると、再クロールまたは再取得の開始日時を指定でき、再クロールまたは再取得の間隔だけを指定できる ttl スキーマよりも高機能です。<schedule> 要素は、<options>、<item-group>、<item>、または <crawler> のサブタグとして指定できます。<schedule> タグと ttl 属性の両方がマニフェスト ファイルで指定された場合、<schedule> の指定が ttl より優先されます(これらのサブ要素の詳細は、 itemを参照)。

failRetryInterval 属性の使用

取得機能が <item> または <crawler> タグ内で指定されたコンテンツ項目を取得するときに(断続的なエラーなどの理由により)失敗した場合、failRetryInterval 属性で指定された時間が経過してから、取得タスク(<item> または <crawler> タグに対応する)がリトライされます。

failRetryInterval 属性が指定されていない場合、タスクをリトライするデフォルトの間隔は 5 分です(クロール ジョブの場合、タスクが失敗したとみなされるのは、まったくクロールが始まらなかった場合だけです。クロールされたページの一部だけが取得できない場合、そのタスクは成功とみなされます)。リトライ メカニズムには、次の規則が適用されます。

<item> タグで指定された単一項目タスクは、EXCEED_DISK_QUOTA エラーを除く、すべてのエラーの場合にリトライされる。

エラー ステータスが 300 ~ 500 である場合、クロール タスクは失敗とはみなされない。EXCEED_DISK_QUOTA エラーの場合も、リトライされない。

Content Distribution Manager GUI を使用してディスク割り当て量を変更すると、取得機能は自動的に通知を受け、EXCEED_DISK_QUOTA エラーを含むすべてのステータス エラー ノードをリトライする。

ttl 属性または Fetch Manifest Now ボタンの使用

項目を正常に取得した場合、および ttl 属性に正の値が指定されている場合、取得機能は、ttl 属性で指定された間隔で、コンテンツのフレッシュネスを再検査します。ttl 値が 0(ゼロ)であると、マニフェスト ファイルが更新された場合を除いて、取得機能は項目を再検査しません。ttl が負の値である場合、取得機能は項目をまったく再検査しません。更新メカニズムには、次の規則が適用されます。

ttl > 0 の場合:ttl 分ごとに再検査します。さらに、マニフェスト ファイルが再解析されマニフェスト ファイルのコンテンツ指定が変更された場合、または Content Distribution Manager GUI で Fetch Manifest Now ボタンをクリックした場合にも、取得機能はコンテンツを再検査します(次の「チャネル コンテンツの更新」を参照)。

ttl = 0 の場合:一度だけ取得します。マニフェスト ファイルが再解析されマニフェスト ファイルのコンテンツ指定が変更された場合、または Content Distribution Manager GUI で Fetch Manifest Now ボタンをクリックした場合、取得機能は再検査だけを行います。

ttl < 0 の場合:一度だけ取得します。マニフェスト ファイルが再解析される場合、または Content Distribution Manager GUI 内にある Fetch Manifest Now ボタンをクリックした場合でも、取得機能は再検査を行いません。

Content Distribution Manager GUI を使用したローカル マニフェスト ファイルの再解析

Content Distribution Manager GUI を使用してコンテンツをチャネルに追加してコンテンツを定義すると、マニフェスト ファイルが自動的に生成され、Content Distribution Manager 内にローカルに保存されます。GUI からコンテンツ定義の追加、削除、変更などを行い、 Submit ボタンまたは Update ボタンをクリックすると、ローカル マニフェスト ファイルが自動的に再解析され、変更内容が検出され、対応する項目が取得または削除されます。 Submit ボタンまたは Update ボタンをクリックしても、チャネル内のすべてのコンテンツの再検査はトリガーされません。

チャネル コンテンツの更新

チャネルに関連付けられている Content Engine にコンテンツを複製したあと、マニフェスト取得機能を使用してそのコンテンツをいつでも更新できます。たとえば、マニフェスト ファイルを変更して、新しいコンテンツをポイントしたり、古くなったコンテンツへの参照を削除した場合、そのマニフェスト ファイルを取得して、新しいチャネル コンテンツの複製を開始し、古くなったコンテンツとの関係を断つ必要があります。


) マニフェスト ファイルから削除されたコンテンツは、更新されたマニフェスト ファイルが取得されると同時に使用できなくなります。古いコンテンツは、チャネル キャッシュからただちに削除されるのではなく、新しいチャネル コンテンツをキャッシュするスペースを確保するためにいずれ削除されます。


新規または更新済みのマニフェスト ファイルを取得する手順は、次のとおりです。


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

ステップ 2 チャネルの名前の横にある Edit アイコンをクリックして、チャネルを開いて編集します。

ステップ 3 Contents ペインから Channel Content を選択します。

ステップ 4 Manifest URL フィールドがチャネルの正しいマニフェスト ファイルをポイントしていることを確認します。

ステップ 5 Fetch Manifest Now ボタンをクリックします。確認するメッセージが表示されます。

このボタンをクリックすると、ソフトウェアは、マニフェスト ファイルが更新されたかを調べ、更新されたマニフェスト ファイルがダウンロードされ、再解析されます。また、マニフェスト ファイルが更新されたかどうかにかかわらず、チャネル内のすべてのコンテンツは再検査され、更新されたコンテンツがダウンロードされます。

ステップ 6 OK をクリックして要求を実行します。


 

チャネル コンテンツを強制的に複製し、情報を更新する手順は、次のとおりです。


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

ステップ 2 変更するチャネルの名前の横にある Edit アイコンをクリックして、チャネルを開いて編集します。

ステップ 3 Contents ペインから Replication Status をクリックします。Replication Status for Channel ウィンドウが表示されます。

ステップ 4 タスクバーから Force Replication information refresh アイコンをクリックします。確認するメッセージが表示されます。

ステップ 5 OK をクリックします。要求が送信されたことが通知され、数分後に確認するようメッセージが表示されます。

ステップ 6 OK をクリックします。しばらくして、Replication Status for Channel ウィンドウが更新されます。

チャネル複製状況のデータについては、 第 11 章「コンテンツ複製状況の表示」 を参照してください。


 

帯域幅制御

帯域幅制御機能を使用すると、ルート Content Engine からエッジ Content Engine へのデータ複製に使用される、ネットワーク内の帯域幅の使用量を指定できます。一日の異なる時間帯ごとに、帯域幅の使用量を指定できます。また、毎週繰り返される週間スケジュールを設定することも可能です。ここでは、コンテンツ取得と配信に関連した帯域幅制御について説明します。帯域幅制御機能は、取得プロセス、複製プロセス、およびマルチキャスト送信側に使用可能です。

取得と配信のデフォルト帯域幅の設定

デフォルトの帯域幅をコンテンツの取得と配信に対して設定できます。デフォルトの帯域幅とは、スケジュールされた帯域幅がないときに、コンテンツの取得と配信に割り当てられる帯域幅のことです。

Content Engine がデバイス グループに割り当てられていて、その Content Engine にデフォルトの帯域幅が設定されていない場合、デバイス グループのデフォルト帯域幅が適用されます。Content Engine が複数のデバイス グループに割り当てられている場合は、複数のデバイス グループ内で最後に更新されたデフォルトの帯域幅が適用されます。

ただし、Content Engine にデフォルトの帯域幅が指定されている場合、その設定値はデバイス グループ レベルの設定より優先されます。このようなことが起こるのは、その Content Engine があるデバイス グループのメンバーである場合です。

Content Engine に対して取得と配信用にデフォルトの帯域幅を設定する手順は、次のとおりです。


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

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

ステップ 3 Contents ペインから、Prepositioning > Default Bandwidth の順に選択します。Acquisition and Distribution Default Bandwidth for Content Engine ウィンドウが表示されます(図6-11 を参照)。

図6-11 Acquisition and Distribution Default Bandwidth ウィンドウ

 

ステップ 4 Acquisition-in Bandwidth フィールドに、オリジン サーバからの着信コンテンツ取得トラフィックの帯域幅の値(kbps)を入力します。デフォルトは、1024 kbps です。

ステップ 5 Distribution-in Bandwidth フィールドに、Content Engine からの着信ユニキャスト コンテンツ配信トラフィックの帯域幅の値(kbps)を入力します。デフォルトは、56 kbps です。

ステップ 6 Minimum Nonstreaming Acquisition-in Bandwidth フィールドに、オリジン サーバからの着信非ストリーミング コンテンツ取得トラフィックの帯域幅の値(kbps)を入力します。デフォルトは、50 kbps です。

最小の非ストリーミング帯域幅とは、HTTP、HTTPS、FTP などの非ストリーミング プロトコルを使用してコンテンツを取得するために割り当てる帯域幅です。この設定は、MMS などのストリーミング プロトコルが、ある特定の状況下で使用可能なすべての帯域幅を占有してしまうときに、非ストリーミング プロトコルを使用してオリジン サーバからマニフェスト ファイルおよびその他のコンテンツ項目を取得するための帯域幅を予約する必要がある場合に役立ちます。最小の非ストリーミング帯域幅デフォルト設定を保持し、そのデフォルト値を増やす必要がある場合(たとえば、多数のストリームの同時取得が原因で、ある大きいファイルを取得できない場合)だけ、調整することを推奨します。

ステップ 7 Distribution-out Bandwidth フィールドに、ACNS ネットワーク内の各種 Content Engine への発信ユニキャスト コンテンツ配信トラフィックの帯域幅の値(kbps)を入力します。デフォルトは、128 kbps です。


) Multicast-out Bandwidth フィールドは、読み取り専用です。このフィールドには、送信側 Content Engine のマルチキャスト出力帯域幅設定値が表示されます。このフィールドの値は、Creating New Multicast Cloud ウィンドウの Default Multicast-out Bandwidth フィールドで設定されます( マルチキャスト クラウドのプロパティの設定を参照)。受信側 Content Engine の場合、このフィールドはブランクです。


ステップ 8 以前設定されたウィンドウ設定に戻すには、Reset をクリックします。Reset ボタンが表示されるのは、デフォルトまたはグループ設定を適用して現在のデバイス設定を変更したにもかかわらず、まだ Submit をクリックしていないときだけです。

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


 

取得と配信の帯域幅設定のグラフィカル表示

Content Engine に設定されたファイルの取得と配信用帯域幅設定をグラフィカルに表示することができます。グラフの縦軸は帯域幅量(kbps)を表し、横軸は曜日を表します。縦軸に表示される目盛りは、特定のタイプの帯域幅に対する帯域幅のレートに基づいて動的に決定され、必要に応じて大きくなります。曜日ごとに横軸に表示される目盛りは、1 時間単位です。各タイプの帯域幅は、固有の色で表示されます。グラフの下部にある凡例は、色と帯域幅の対応を示します。

取得と配信用の帯域幅を示すグラフを表示する手順は、次のとおりです。


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

ステップ 2 取得と配信用の帯域幅を表示する Content Engine の横にある Edit アイコンをクリックします。Device Home ウィンドウが表示されます。

ステップ 3 Contents ペインから、Prepositioning > Default Bandwidth の順に選択します。Acquisition and Distribution Default Bandwidth for Content Engine ウィンドウが表示されます(図6-11 を参照)。

ステップ 4 タスクバーから Display Graph アイコンをクリックします。Acquisition and Distribution bandwidth for Content Engine ポップアップ ウィンドウに、帯域幅グラフが表示されます。

表示オプションをクリックすると、帯域幅グラフの表示方法を選択できます。表示オプションとその説明については、 表6-6 を参照してください。

ステップ 5 設定の表示が終わったら、Close を一回クリックします。または、Refresh をクリックして、最近適用された帯域幅設定を表示することもできます。

 

表6-6 取得と配信用帯域幅グラフの表示オプション

項目
説明

View specific servers

選択された帯域幅タイプに対応する帯域幅設定を表示します。

Distribution In

着信コンテンツ配信トラフィックの帯域幅設定を表示します。

Distribution Out

発信コンテンツ配信トラフィックの帯域幅設定を表示します。

Acquisition In

着信コンテンツ取得トラフィックの帯域幅設定を表示します。

All Servers

すべての設定された帯域幅タイプの統合ビューを表示します。この表示と Full Week 表示の組み合わせがデフォルトの表示です。

View mode

詳細な複合帯域幅設定を表示します。

Show Detailed Bandwidth

Show Effective Bandwidth オプションと切り替わります。デバイスとそれに関連付けられたデバイス グループの詳細な帯域幅設定を表示します。デバイスとデバイス グループの帯域幅設定は、見やすいように異なる色で表示されます。

Show Effective Bandwidth

Show Detailed Bandwidth オプションと切り替わります。デバイスとそれに関連付けられたデバイス グループの統合または複合帯域幅設定を表示します。

Show Aggregate View

Show Non-Aggregate View オプションと切り替わります。対応するデバイス グループに設定された帯域幅設定を表示します。

Show Non-Aggregate View

Show Aggregate View オプションと切り替わります。対応するデバイス グループに設定された帯域幅設定を非表示にします。

View by day

特定の曜日、またはすべての曜日の帯域幅設定を表示します。

Sun、Mon、Tues、Wed、Thurs、Fri、Sat

対応する曜日の帯域幅設定を表示します。

Full Week

週全体の帯域幅設定を表示します。この表示と All Servers 表示の組み合わせがデフォルトの表示です。

 


 

スケジュール時刻の取得と配信用帯域幅パラメータの設定

Content Engine 上の着信トラフィックと発信トラフィックに対してデフォルトの帯域幅制限を設定できるほかに、Content Distribution Manager GUI を使用して、1 週間周期でさまざまな時間帯にそれぞれ異なる制限を設定できます。たとえば、月曜日~金曜日の午前 8:00 ~午後 8:00 には Acquisition-in の制限を 100 kbps に設定し、月曜日~金曜日の午後 8:00 ~午前 8:00、および土曜日~日曜日の全日にわたっては、この制限を 10 Mbps に高めるように設定できます。これらの設定は、指定した時刻および期間のデフォルト値より優先されます。


) 午後 8:00 ~午前 8:00 のスケジュールを設定する場合は、2 日にわたることになるので、管理者は 2 つのスケジュールを設定する必要があります。1 つは午後 8:00 ~午後 11:59(20:00 ~ 23:59)、もう 1 つは午前 12:00 ~午前 8:00(00:00 ~ 08:00)に設定します。



) 配信帯域幅の設定は、ユニキャスト配信にのみ適用されます。


特定の日時に対する配信帯域幅パラメータを設定する手順は、次のとおりです。


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

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

ステップ 3 Contents ペインから、 Prepositioning > Scheduled Bandwidth の順に選択します。Acquisition and Distribution Bandwidth Schedule for Content Engine ウィンドウが表示されます。

ステップ 4 Aggregate Settings では、 Yes オプション ボタンがデフォルトで選択されています。取得と配信用帯域幅のスケジュールが、Content Engine と関連デバイス グループに対して表示されます。デバイス グループの取得と配信用帯域幅スケジュールの設定は、変更または削除できません。この設定は読み取り専用です。Aggregate Settings の No オプション ボタンをクリックすると、Content Engine の取得と配信用帯域幅スケジュールの設定だけを表示および変更できます。関連付けられたデバイス グループの取得と配信用帯域幅スケジュールの設定は表示されません。

ステップ 5 タスクバーから Create New Bandwidth Setting アイコンをクリックします。Creating New Acquisition and Distribution Bandwidth Schedule for Content Engine ウィンドウが表示されます(図6-12 を参照)。

図6-12 Creating New Acquisition and Distribution Bandwidth Schedule ウィンドウ

 

ステップ 6 ドロップダウン リストから帯域幅のタイプを選択します(このウィンドウの各フィールドについては、 表6-7 を参照してください。すべてのフィールドが入力必須です)。

ステップ 7 帯域幅のレート、開始時刻、終了時刻、および曜日を該当するフィールドに入力します。

 

表6-7 取得と配信用帯域幅の設定

フィールド
説明

Bandwidth Type

Distribution-in ― Content Engine からの着信ユニキャスト コンテンツ配信トラフィックの帯域幅。

Distribution-out ― Content Engine への発信ユニキャスト コンテンツ配信トラフィックの帯域幅。

Acquisition-in ― オリジン サーバからの着信コンテンツ取得トラフィックの帯域幅。

Multicast-out ― Content Engine への発信マルチキャスト コンテンツ配信トラフィックの帯域幅。

Bandwidth Rate

使用できる最大の帯域幅(kbps 単位)。

Start Time

帯域幅設定の適用開始時刻。24 時間制の現地時間(hh:mm)を使用します。

End Time

帯域幅設定の適用終了時刻(hh:mm)。

Day Selection

帯域幅設定を適用する曜日。

Full Week ― 許容帯域幅設定が、週全体に適用されることを指定します。

Sun、Mon、Tue、Wed、Thu、Fri、および Sat ― 許容帯域幅設定が適用される個々の曜日を指定します。

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


 

ストリーミング取得用の帯域幅のスケジュール

MMS 取得を設定すると、ストリーミング コンテンツはファイルの再生期間中、大量の帯域幅を消費します。十分な帯域幅が長時間使用可能であることを確認する必要があります。Multi-bit Rate(MBR)ストリームの場合、必要な帯域幅はストリームに符号化されるすべてのビット レートの合計です。

エラー コード

ここでは、コンテンツを複製する場合のエラー コードを示します。Content Distribution Manager GUI 内にある Replication Status ウィンドウに、次のエラー コードが表示されます。

ACNS 統合ネーム スペース エラー

1401: Bad magic number in unified name space (UNS) meta file

1402: Unknown version in UNS meta file

1403: Bad checksum on UNS meta file

1404: Internal error - URL mismatch between caller specified URL and URL in meta file

1405: Invalid URL syntax

1406: Attempt to create URL already in UNS

1407: Insufficient space to store requested object

1408: Internal logic error in UNS server code

1409: Requested object not found in UNS

1410: Requested UNS operation not implemented

1411: Failure in underlying RPC transport

1412: Destination URL already exists

1413: Channel does not exist

1414: Writes failed to all metadata files

1415: Object is not servable

1416: Object is out of presentation time

1417: Object playback not allowed by this playback server

1418: Live object, but attributes invalid

1419: Alternate media attributes invalid

1420: Alternate media is not servable

1421: Channel would be over disk quota

1422: Cannot change channel ID

1423: Object already in specified channel

1424: Object not in specified channel

1425: Metadata operations disabled (no file systems)

1426: Channel operations disabled (no file systems)

1427: Nonobject metadata services not initialized

1428: Out of handles for nonobject metadata files

1429: Internal error loading metadata file

1430: (No error text available)

1431: Too many CDN files (cannot add to URL for file system map [UFM])

1432: Specified legacy ECDNFS file not found

1433: Bad MD5 checksum passed by caller

1434: Bad tags present in supplied attributes (OBSOLETE)

1435: Cannot resize content file migrated from ECDN

1436: UNS symlink references nonexistent URL

1437: URL is not a UNS symlink

1438: Too many levels of UNS symlinks

1439: UNS entry metafile truncated

1440: Output to be returned is too big in size

1441: URL request was made on a nondefault service port

1442: Specified legacy file not on any UNS filesystem

1443: Specified legacy file is not in the 田acheî directory

1444: Specified legacy file is referenced by a UNS entry

1445: Specified legacy file is not a .data file

1446: File open failed during ASX/SMIL rewrite operation

1447: Parse error during ASX/SMIL rewrite operation

1448: Initialization error during ASX/SMIL rewrite operation

1449: Actual Rewriting failed during ASX/SMIL rewrite operation

1450: No more file system slots

1451: Specified file system is already in use

1452: Specified file system not known to UNS

1453: Specified file system bytes in use exceeds target

1454: Cannot unuse the file system containing the symlink tree

1455: Cannot add file system because there is no local disk-based CDNFS storage

取得機能エラー コード

次のエラー コードは、HTTP、FTP、HTTPS、および MMS のコンテンツ取得に共通です。

700: Acquirer internal error

701: Manifest parser error

702: Manifest parse warning

703: Exceeded disk quota

704: No space in UNS

705: It is a folder

706: ACCEPT failed

707: Connection refused

708: Listen failed

709: Mismatched in crawling

710: No-cache instructed from server

711: Disabled by the user

712: Downloaded size mismatched with content length

713: Invalid response received from server

714: Database access error

715: Not to acquire URL with ?

716: Invalid redirect foo to foo/

717: Illegal folder for file import

718: Unable to connect to proxy server

719: URL is too long

720: HTTP metadata is too long

721: Connection closed by peer

722: Invalid content length

905: Socket timeout

906: No host

907: Zero bandwidth

908: File download aborted

909: Content expired before fetch

910: Insufficient bandwidth to download the stream

911: Live stream not supported

912: Request timed out

1000: UNS error

MMS 固有の取得エラー コード

2002: Cannot connect to remote server

2003: Remote cannot connect

2004: Requested file not found

2005: Requested remote file not found

2006: Max number of connections is reached

2007: Remote server reached max number of connections

2008: Max bandwidth limit is reached

2009: Remote server reached max bandwidth limit

2010: Max bit rate limit reached

2011: Remote server reached max bit rate limit

2012: Illegal memory address encountered

2013: Illegal memory address encountered at remote server

2015: Error creating a socket

2016: Error creating a socket at remote server

2017: Internal system error

2018: Error receiving data from server

2019: Server error at remote server

2020: Authentication failed

2021: Remote server timed out

2022: Error in stream type

2023: Remote proxy error

2024: Invalid request at remote server

2025: Stream file is corrupt

2026: Stream file is corrupt at remote server

2027: Data received is corrupt

2028: Data received is corrupt at remote server

2029: Remote access denied

2030: Remote connection refused

2031: MMS over UDP not allowed in WCCP mode

2032: MMS over UDP has been disabled

2033: MMS over TCP has been disabled

2034: MMS over TCP and UDP has been disabled

2035: MMS over HTTP has been disabled

2036: Client error at first round of handshake over MMS

2037: Client error

2038: Client request blocked

2039: Client request filtered

2041: Unknown MMS error

2042: Unknown error from remote server

2043: Max incoming bandwidth limit is reached

2044: Max incoming bit rate limit reached

2100: Generic MMS acquisition error

2101: Acquirer could not be contacted to check header

2102: Check of head result failed to match criteria

2103: Could not write stream to disk

2104: Could not open file to write

2105: Stream header could not be retrieved

2106: Remote stream was closed abnormally

2107: Header obtained from remote stream was in invalid format

2108: Remote server closed the connection

2109: Connection to remote server timed out

2110: Remote file contains no streams

2111: Could not load ASF block for indexing

2112: Specified URL could not be resolved to a remote host

2113: File size is bigger than that supported

2114: Acquirer could not be contacted to send status of download

2115: Error in forking a process

2116: Stream acquisition terminated

2117: MMS acquisition was stopped

2118: Bandwidth not available for streaming in next packet

2119: RPC exception thrown when contacting main acquirer

次の作業

この章では、次の作業を完了しました。

Content Distribution Manager GUI から直接、または 付録 A「マニフェスト ファイルの作成」 で記述されているマニフェスト ファイルを使用して、事前配信するコンテンツを定義しました。

Content Distribution Manager GUI でマニフェスト ファイルの基本設定を指定しました。これで、ルート Content Engine はマニフェスト ファイルを取得し、指定の間隔でチャネル コンテンツを更新できます。

ルート Content Engine の帯域幅を設定して、ネットワーク内の帯域幅の使用量を最適化しました。

必要に応じて、マニフェスト ファイルを取得するためのプロキシを設定しました。

マニフェスト ファイルとコンテンツの一方または両方を取得するのに必要な認証を設定しました。

次に、エンド ユーザに対してコンテンツを再生する方法を指定する必要があります。コンテンツのスケジュールまたは再ブロードキャストを行うには、 第 7 章「プログラムの作成および管理」 に進んでください。