Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド
コンテンツ獲得用の ACNS ネットワー クの設定
コンテンツ獲得用の ACNS ネットワークの設定
発行日;2012/02/04 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

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

事前配信コンテンツの獲得

オリジン サーバの設定

HTTP と HTTPS の使用

FTP の使用

MMS と MMS-over-HTTP の使用

チャネルの作成

ルート Content Engine の割り当て

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

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

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

配信の優先順位

項目の優先順位

チャネルの割り当て量

更新間隔

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

パブリッシング URL の生成

再生サーバの割り当て

リトライとリフレッシュ メカニズム

結果の確認

帯域幅制御

獲得と配信用のデフォルトおよび最大帯域幅パラメータの設定

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

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

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

認証サポート

NTLM 認証を必要とするコンテンツの獲得

プロキシ サポート

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

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

マニフェスト ファイルにおける noProxy 属性の設定

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

プロキシ認証サポート

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

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

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

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

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

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

コンテンツ獲得ガイドライン

エラー コード

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

獲得機能エラー コード

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

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

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

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

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

「事前配信コンテンツの獲得」

「リトライとリフレッシュ メカニズム」

「結果の確認」

「帯域幅制御」

「認証サポート」

「プロキシ サポート」

「コンテンツ獲得ガイドライン」

「エラー コード」

事前配信コンテンツの獲得

コンテンツを獲得するように ACNS ネットワークを設定するには、次の作業を実行する必要があります。

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

2. チャネルの作成

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

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

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

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

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

オリジン サーバの設定

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

HTTP

HTTPS

FTP

MMS

MMS-HTTP

HTTP と HTTPS の使用

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

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

Microsoft IIS:Microsoft プラットフォームだけでサポートされます。

HTTP と HTTPS プロトコルの場合、マニフェスト ファイルの <item> タグを使用して、単一コンテンツ項目としてコンテンツをフェッチするか、Web サーバ ディレクトリをクロールするクロール機能を使用してコンテンツをフェッチすることができます。クロール機能を使用したい場合は、ディレクトリ インデックスを有効にし、ディレクトリに index.html、default.html、または home.html ファイルが含まれていないことを確認する必要があります。


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


FTP の使用

ルート Content Engine の獲得機能は、FTP サーバからのファイル獲得をサポートします。FTP を使用すると、マニフェスト ファイルの <item> タグを使用して、単一コンテンツ項目としてコンテンツを獲得するか、FTP サーバ ディレクトリをクロールするクロール機能を使用してコンテンツをフェッチすることができます。次の一般的な 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 server

Bulletproof FTP server

SurgeFTP

SlimFTPd

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

USER、PASS

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

PASV または PORT

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

RETR

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 ダウンロードであるかを自動的に検出し、対応するプロトコルを使用してダウンロードします。

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


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


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

チャネルの作成

チャネルは、一連のコンテンツ オブジェクトを一連の Content Engine にマップします。事前配信コンテンツを獲得し、配信する場合は、事前にチャネルを設定しておく必要があります。チャネルを作成するには、「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 と同じロケーションに、2 番目の Content Engine を指定してください。指定されたルート Content Engine が非アクティブになると、自動的にロケーション内の他の Content Engine が、一時的にルート Content Engine になります。指定されたルート Content Engine がオンラインになると、ルートとしての役目を引き継ぎ、一時的にルートの役目をしていた Content Engine は通常の Content Engine になります。

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

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

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

マニフェスト ファイルを作成した後、Manifest Validator ツールを使用して構文を確認してください。次に、Content Distribution Manager GUI の Creating Channel ウィンドウ(新しいチャネルの作成時)、または Modifying Channel ウィンドウで、マニフェスト URL を指定します。マニフェスト ファイルをフェッチする際に認証が必要な場合は、ユーザ名とパスワードも指定します(図 6-1 を参照)。

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

 

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

チャネルの獲得と配信に関するプロパティは、Content Distribution Manager GUI の Channels >
Channels
セクションと、マニフェスト ファイルの両方で設定されます。コンテンツの獲得と配信に関する重要な 4 つのプロパティは、配信の優先順位、項目の優先順位、チャネルの割り当て量、および更新間隔です。

配信の優先順位

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

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

 

コンテンツ獲得の優先順位は、オリジン サーバによっても異なります。別々のオリジン サーバからの要求は、並行して処理されます。同じオリジン サーバからの要求は、全体的な優先順位順に処理されます。しかし、MMS と MMS-HTTP 要求の場合は、これが当てはまりません。MMS と MMS-HTTP 要求はすべて、全体的な優先順位順に処理されます。

全体的な優先順位 = 配信の優先順位 * 10000 + 項目の優先順位

項目の優先順位

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

チャネルの割り当て量

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

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

サブスクライブされている全チャネル内の合計ディスク割り当て量は、Content Engine の cdnfs ディスク スペース割り当てを超えてはならない。「Content Distribution Manager GUI を使用したストレージ容量の更新」を参照してください。

チャネル内の使用可能な合計ディスク スペースは、ディスク割り当て量を超えてはならない。


) オーバーヘッドがあるので、使用可能なディスク スペースはファイル サイズより大きくなります。公式は次のとおりです。
使用済みディスク スペース = round_up (file-size/4096) *4096 + 4096 * 4


更新間隔

更新間隔とは、ルート Content Engine がマニフェスト ファイル自体を検査する間隔です(これは、コンテンツを検査する更新間隔ではありません)。更新間隔は、Content Distribution Manager GUI で設定します(図 6-2 を参照)。この設定については、「チャネルのマニフェスト ファイルとプロキシに関する情報の設定」を参照してください。

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

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


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

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

ステップ 3 Manifest 見出しの下にあるフィールドを使用して、チャネルのマニフェスト ファイルを識別するロケーションまたは情報を設定します(図 6-1 を参照)。

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

ステップ 4 Manifest Proxy Information 見出しの下にあるフィールドを使用して、マニフェスト プロキシ情報を設定します。

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

 

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

プロパティ
説明
マニフェスト

Manifest URL

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

Quota*1

このチャネルに対する事前配信コンテンツ用の最大コンテンツ ストレージ サイズ(メガバイト単位)(マニフェスト URL が指定される場合、このフィールドへの入力は必須です)。

Update Interval*

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

Weak Certificate Verification

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


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


 

Manifest Username

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


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


 

Manifest Password

ユーザのパスワード。

Confirm Password

パスワードの確認。

マニフェスト プロキシ情報
 

Disable All Proxy

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

Proxy Hostname

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

Proxy Port

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

Disable basic authentication

基本認証方式にフォールバックするための NTLM ヘッダーの削除を禁止します。

Proxy Username

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

Proxy Password

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

Confirm Password

プロキシからの認証を受けるために、確認用に同じパスワードを再入力します。

Proxy NTLM domain name

プロキシで設定されている NTLM 認証を受けるための NTLM ユーザ ドメイン名。

1.* = 入力必須フィールド。その他のフィールドはすべてオプションです。

パブリッシング URL の生成

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

スキーム

ドメイン名

パス

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

スキーム

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

スキームは、再生サーバのタイプによって決まります。再生サーバとスキームとの直接マッピングは、次のとおりです。

 

再生サーバ
スキーム

HTTP

HTTP

Real

RTSP

WMT

MMS

QTSS

RTSP

ドメイン名

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

マニフェスト ファイルを通じて獲得されるコンテンツはすべて、Content Distribution Manager GUI(Channels > Web Sites の順に選択)の website Origin Server FQDN フィールド(WCCP ルーティングの場合)、または Request Routed FQDN フィールド(Content Router の場合)に入力されたドメイン名で公開されます。

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

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

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

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

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

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

パス

通常、パブリッシング URL のパスは、相対的な src 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/"
/>

再生サーバの割り当て

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

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

ACNS 5.x ソフトウェアは、ACNS ネットワーク上で、HTTP、HTTPS、WMT、および RTSP(RealMedia and QuickTime Streaming Server[QTSS])の事前配信コンテンツ タイプを再生する再生サーバをサポートします。

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

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

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

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

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

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

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

ACNS 5.1 ソフトウェアでは、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>
 
Because there is no playserver specified in the manifest file for the .rm extension, the built-in rule matches it to the Real playserver. Also http and https playservers are automatically added, if the built-in playserver table is used.
 
The tvout playserver is a special playserver. All pre-positioned content is allowed to be played back by tvout. But if you want to exclude the content from being played back by other playservers, you can specify the tvout playserver. ACNS software does not allow other playservers to play the content once a playserver has been specified.
 

 

リトライとリフレッシュ メカニズム

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

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

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

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

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

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

ttl > 0 である場合、 ttl 分ごとに再検査する。マニフェスト ファイルが再解析されるとき、または Content Distribution Manager GUI で Refetch ボタンをクリックするとき、獲得機能がコンテンツを再検査します。

ttl = 0 である場合、一度だけ獲得する。獲得機能が再検査するのは、マニフェスト ファイルが再解析されるとき、または Content Distribution Manager GUI で Refetch ボタンをクリックするときだけです。

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

結果の確認

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

 

表 6-2 コンテンツ獲得用の show コマンド

コマンド
説明

show acquirer channel

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

show acquirer progress

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

show acquirer progress streams

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

show statistics acquirer

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

show statistics acquirer job-list

獲得タスクのリストを表示します。

show statistics acquirer error

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


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


 

show statistics replication

複製状況を表示します。

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

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

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

コンテンツ獲得の進行状況を調べるには、show acquirer progress コマンドを使用します。ある特定のチャネルの進行状況を取得するには、特定のチャネル 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 コマンドまたは show statistics acquirer channel-name コマンドを使用します。次の例では、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 コマンドまたは show statistics acquirer errors channel-name コマンドを使用します。次の例では、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 Services を使用する 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 コマンドを使用します。このコマンドを使用すると、ストリーミング コンテンツを獲得しているチャネルの詳細な情報がわかります。次の例では、最初の 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 コマンドを使用して、獲得機能のデバッグ レベルを上げることができます。ログは
local1/errorlog/acquirer-errorlog.current に書き込まれています。MMS プロトコルを介した獲得のログは、local1/errorlog/acquirer-mms-errorlog.current に書き込まれています。

帯域幅制御

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

獲得と配信用のデフォルトおよび最大帯域幅パラメータの設定

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

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

しかし、ある Content Engine にデフォルトの帯域幅が指定されていても、その設定値はデバイス グループの設定値に書き換えられてしまう場合があります。このような書き換えは、その Content Engine があるデバイス グループのメンバーとしてすでに登録されている場合に起こります。

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


ステップ 1 Content Distribution Manager GUI で、Devices > Content Engines の順に選択します。Content Engines ウィンドウが表示されます。

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

ステップ 3 Contents ペインで、CDN Settings > Acquisition & Distribution Default Bandwidth の順に選択します。Default and Max Bandwidth for Content Engine ウィンドウが表示されます。


) デバイス グループ設定が適用されない場合、タスクバー内の Remove Device Settings(Trash)アイコンをクリックすると、デバイスに設定されたパラメータを削除できます。デバイスの出荷時のデフォルト設定を適用する場合は、タスクバー内の Apply Defaults アイコンをクリックできます。

デバイスが関連付けられているデバイス グループから設定が適用された場合、それに応じてタスクバー内の項目が変わります。デバイス グループの設定を変更するには、タスクバー内の Override Group Settings アイコンをクリックします。このウィンドウに表示されるパラメータで設定された 1 つまたは複数のデバイス グループにデバイスが関連付けられる場合、そのデバイスに適用する設定をもつデバイス グループの名前を選択できます。


ステップ 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 > Content Engines の順に選択します。Content Engines ウィンドウが表示されます。

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

ステップ 3 Contents ペインで、CDN Settings > Acquisition & Distribution Default Bandwidth の順に選択します。Default and Max Bandwidth for Content Engine ウィンドウが表示されます。

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

表示オプションの名前をクリックすると、帯域幅グラフに適用したい表示のタイプを選択できます。帯域幅タイプ、デバイス グループ、または曜日別にグラフを表示できます。表示オプションとその説明については、 表 6-3 を参照してください。

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

 

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

項目
説明

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 > Content Engines の順に選択します。Content Engines ウィンドウが表示されます。

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

ステップ 3 Contents ペインで、 CDN Settings > Acquisition & Distribution Bandwidth の順に選択します。
Bandwidth Setting for Content Engine ウィンドウが表示されます。

ステップ 4 Bandwidth Setting ウィンドウでは、Aggregate Settings Yes オプションがデフォルトで選択されています。これは、Content Engine とそれに割り当てられたデバイス グループの帯域幅設定が、このウィンドウに表示されることを指定します。Content Engine のみの帯域幅設定を適用し、表示するには、 No オプション ボタンをクリックしてください。

ステップ 5 タスクバー内の Create New Bandwidth Setting アイコンをクリックします。Create New A&D
Bandwidth Settings ウィンドウが表示されます(図 6-3 を参照)。

図 6-3 Create New A&D Bandwidth Settings ウィンドウ

 

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

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

 

表 6-4 獲得と配信用帯域幅パラメータの設定

フィールド
説明

Bandwidth Type

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

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

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

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 獲得が設定される場合、ストリーミング コンテンツは、ファイルの再生期間中、大量の帯域幅を消費します。十分な長さの時間に対して十分な帯域幅が使用可能であることを確認する必要があります。マルチ ビット レート ストリーム(MBR)の場合、必要な帯域幅は、ストリームにエンコーディングされるすべてのビット レートの合計です。

 

認証サポート

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

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


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


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

NTLM 認証を必要とするコンテンツの獲得

ACNS 5.x ソフトウェアでは、基本認証実行後、ルート Content Engine は HTTP オリジン サーバからコンテンツを獲得できます。しかし、多くの場合、オリジン サーバは NTLM 認証だけをサポートしています。ACNS 5.1 ソフトウェアは、認証機能を拡張して、獲得機能が NTLM クライアントの役目をして、NTLM 対応のオリジン サーバと通信できるようにします。


) Content Engine の獲得機能は、NTLM Version 1 だけをサポートします。


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

user :ユーザ アカウント

password :パスワード

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

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

disableBasicAuth :(オプション属性)必要に応じて、基本認証をディセーブルにします。ユーザ名とパスワードを確認するために常に NTLM 認証を使用し、基本認証は使用したくない場合、この属性を true に設定します。この属性を省略する場合、デフォルトは false です。

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

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

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

プロキシ サポート

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


) ACNS 5.1 ソフトウェアでは、プロキシ サーバを通じたコンテンツ獲得は、HTTP 要求に対してしかサポートされません。HTTPS、FTP、MMS、または MMS-HTTP 要求に対してはサポートされません。


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

プロキシ サーバの設定には、Content Engine CLI を使用する方法と、マニフェスト ファイルを使用する方法の 2 通りがあります。コンテンツのキャッシングとコンテンツの事前配信の両方にプロキシを使用するように、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」というメッセージが表示されます。


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 コマンドを使用してください。次に例を示します。

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 にプロキシが設定されている場合、マニフェスト ファイル内の 1 行目の <item> は、そのプロキシを使用します。しかし、マニフェスト ファイル内の 2 ~ 4 行目の <item> と <crawler> タスクはプロキシを使用しないことを示しています。noProxy="1" は、2 ~ 4 行目の <item> と <crawler> タスクに対して、データをオリジン サーバから直接フェッチすることを指定します。

<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 の Creating New Channel ウィンドウまたは Modifying Channel ウィンドウで設定できます。これらが設定されると、マニフェスト ファイルに対する要求は、Content Distribution Manager GUI で指定されるプロキシ サーバを通して行われます。


) Channel ウィンドウからのプロキシ設定は、マニフェスト ファイルをフェッチすることだけに適用されます。コンテンツ獲得には適用されません。


マニフェスト ファイルが、プロキシを必要とするオリジン サーバに置かれている場合、Content
Distribution Manager GUI の Creating New Channel または Modifying Channel ウィンドウの Manifest Proxy Information セクションに表示されるフィールドに、プロキシの名前または IP アドレス、およびプロキシ ポートを指定する必要があります(図 6-1 を参照)。CLI の http proxy outgoing host コマンドから設定されるプロキシを使用できないオリジン サーバ上に、マニフェスト ファイルが置かれている場合、 Disable All Proxy チェックボックスにチェックマークを付ける必要があります。

Disable All Proxy チェックボックスにチェックマークが付いている場合、Proxy Hostname フィールドと Proxy Port フィールドの値は上書きされます。

プロキシ認証サポート

獲得機能は、プロキシ認証に 2 つのタイプの認証方式(基本プロキシ認証と NTLM プロキシ認証)をサポートします。

プロキシ サーバからマニフェスト ファイルをフェッチするために認証が必要な場合、Content Distribution Manager GUI で認証情報を指定できます。

マニフェスト ファイル内で指定されたプロキシ サーバから、事前配信コンテンツをフェッチするために認証が必要な場合、マニフェスト ファイル内で認証情報を指定する必要があります(「マニフェスト ファイルを使用したプロキシ認証の設定」を参照)。

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

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

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


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

ステップ 2 チャネルの名前の横にある Edit アイコンをクリックするか、タスクバー内の Create New Channel アイコンをクリックして、Creating new Channel ウィンドウまたは Modifying Channel ウィンドウを表示します。

ステップ 3 Manifest Proxy Information 見出しの下の該当するフィールドに、認証情報を入力します。図 6-1 では、認証情報を入力するフィールドを示しています。 表 6-5 では、これらのフィールドについて説明しています。

 

表 6-5 マニフェスト プロキシ情報

フィールド
説明

Disable All Proxy

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

Proxy Hostname

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

Proxy Port

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

Disable basic authentication

基本認証方式にフォールバックするための NTLM ヘッダーの削除を禁止します。

Proxy Username

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

Proxy Password

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

Confirm Password

プロキシからの認証を受けるために、確認用に同じパスワードを再入力します。

Proxy NTLM domain name

プロキシで設定されている NTLM 認証を受けるための NTLM ユーザ ドメイン名。

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


 

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

マニフェスト ファイルの <proxyServer> タグ内で指定されたプロキシが、認証情報を必要とする場合、マニフェスト ファイル内の次の属性を使用して、認証情報を指定できます。

user :ユーザ アカウント

password :パスワード

ntlmUserDomain :NTLM ユーザ ドメイン名。このフィールドは、NTLM 認証方式に必要です。

disableBasicAuth :(オプション属性)必要に応じて、基本認証をディセーブルにします。ユーザ名とパスワードを確認するために常に NTLM 認証を使用し、基本認証は使用したくない場合、この属性を true に設定します。この属性を省略する場合、デフォルトは false です。

プロキシ サーバに認証情報を指定するには、<proxyServer> タグで上記の属性を指定し、 proxyServer 属性を使用して <proxyServer> タグを <host>、<item>、<item-group>、または <crawler> タグに関連付けます。詳細は、「マニフェスト ファイルの作成」 を参照してください。

次に例を示します。

<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 send 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 を使用したプロキシ認証の設定

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

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

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


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

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

ステップ 3 Contents ペインで、 HTTP/S > 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 チェックボックスにチェックマークを付けます。

ステップ 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 コマンドを使用してください。

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

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

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

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


ステップ 1 Devices > Content Engines の順に選択します。Content Engines ウィンドウが表示されます。

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

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

図 6-4 Acquirer WCCP Proxy Authentication

 

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

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

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

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

ステップ 8 Disable basic authentication チェックボックスにチェックマークを付けて、基本認証方式へのフォールバックのための NTLM ヘッダーの削除を不許可にします。

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

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

何らかの変更を加えたのに保存していないとき、「Click Submit to Save」メッセージが現在の設定項目の横に赤で表示されます。また、 Reset をクリックすると、以前に設定されていたウィンドウの設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定を変更したにもかかわらず、設定がまだサブミット(送信)されていない場合だけです。

ステップ 10 デバイスの設定を削除するには、タスクバー内の Remove Device Settings アイコンをクリックして、設定を削除します。このアイコンが表示されるのは、Content Engine のパラメータを設定した場合だけです。

ステップ 11 デバイスの出荷時のデフォルト設定を復元するには、タスクバー内の Apply Defaults アイコンをクリックします。

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

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

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


 

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
 

コンテンツ獲得ガイドライン

ACNS ネットワークにおけるコンテンツ獲得には、次のガイドラインが適用されます。

特殊文字

RFC 標準に従って、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 ウィンドウ( Channels > Channels > Basic Settings > 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 に 1 組の引用符(")またはパーセント記号(%)が含まれている場合、ASCII コードに等価な文字を使用してこの特殊文字をエスケープする必要があります。その他の特殊文字についても、標準 RFC 2396 要件に従って URL をエスケープしてください。

リダイレクト サポート

単一項目 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 ディレクティブを有効であると認めません。

組み込みタグとオブジェクトのサポート

HTML ファイルに組み込みタグまたはオブジェクト タグが含まれている場合、獲得機能はそのファイルを解析し、 src 属性および filename 属性からファイル リンクを取得し、これらのファイルをフェッチします。

.asx ファイルのクロール

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

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

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

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

セキュア FTP

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

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

HTML ファイルに Javascript または VBScript(Microsoft の Visual Basic Scripting Edition は、Visual Basic の機能縮小版です)が含まれているときに、スクリプト コードにリンクがある場合、獲得機能は、リンクをたどるためのスクリプト コードの解析を行いません。

Cookie サポート

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

エラー コード

ここでは、コンテンツを複製する場合のエラー コードについて説明します。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 ‘cache' 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 bi t 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