Cisco ACNS ソフトウェア アップグレード/メンテナンス ガイド Release 5.x
ACNS ソフトウェア アップグレードの 概要
ACNS ソフトウェア アップグレードの概要
発行日;2012/01/15 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

ACNS ソフトウェア アップグレードの概要

ソフトウェアをアップグレードする前に必要な準備

アップグレード、ダウングレード、および相互運用性に関する考慮事項

アップグレード オプション

ダウングレード オプション

相互運用性に関する要件

ACNS 5.5 ソフトウェア機能の相互運用性に関する問題

Windows メディア ストリーミングに関するプロトコル サポートの変更

アップグレード時に削除される MMS の設定

混在型ネットワークにおけるマルチキャスト ステーション NSC 参照 URL の設定

バージョンの異なる Windows メディア サーバが混在する場合

Windows メディアの管理対象ライブ プログラム

Windows メディア サービス ストリーミング メディアの取得

MMS の WCCP トランスペラレント リダイレクション

Windows Media Encoder またはバージョンが混在する Windows Media Player を使用する場合

MMS ベース ストリーミングから ACNS 5.5 ソフトウェアの HTTP または RTSP ベース ストリーミングへの移行

Windows メディア サービス ライセンス キーの相互運用性に関する問題

Content Distribution Manager の相互運用性に関する問題

ACNS 5.4 ソフトウェア機能の相互運用性に関する問題

Content Distribution Manager

コンテンツ取得のためのクッキー サポート

ACNS 5.4.x ソフトウェアにアップグレードした場合の Websense の問題

ACNS 5.4.x ソフトウェアからダウングレードした場合の Websense の問題

ACNS 5.3 ソフトウェア機能の相互運用性に関する問題

無効なカスタム ログ フォーマット ストリング

SmartFilter プラグインのバージョン

アップグレードおよびダウングレード パスの廃止

ACNS 5.2 ソフトウェア機能の相互運用性に関する問題

コンフィギュレーション ファイル フォーマットの非互換性

マルチキャスト ファイル転送

SMB ファイルの取得

ソフトウェア ドライバ サポートおよび TV 出力機能

ACNS 5.1 ソフトウェア機能の相互運用性に関する問題

コンテンツの配信

マルチキャスト クラウド

ACNS 5.0 ソフトウェア機能の相互運用性に関する問題

ACNS 5.0 にダウングレードした場合のメディア ファイル システムに関する問題

ACNS 5.0 ソフトウェアまたは ACNS 5.1 ソフトウェアにダウングレードした場合の Websense に関する問題

ACNS 4.x ソフトウェアおよび ACNS 5.x ソフトウェア機能の相互運用性に関する問題

ACNS 5.x ソフトウェアから ACNS 4.2x ソフトウェアにダウングレードする場合の問題

ACNS ソフトウェア アップグレードの概要

この章では、ソフトウェア アップグレード時の一般的なネットワーク動作について説明します。また、さまざまなソフトウェア リリース間の相互運用性に関連する個々の問題についても説明します。この章の内容は次のとおりです。

「ソフトウェアをアップグレードする前に必要な準備」

「アップグレード、ダウングレード、および相互運用性に関する考慮事項」

「ACNS 5.5 ソフトウェア機能の相互運用性に関する問題」

「ACNS 5.4 ソフトウェア機能の相互運用性に関する問題」

「ACNS 5.3 ソフトウェア機能の相互運用性に関する問題」

「ACNS 5.2 ソフトウェア機能の相互運用性に関する問題」

「ACNS 5.1 ソフトウェア機能の相互運用性に関する問題」

「ACNS 5.0 ソフトウェア機能の相互運用性に関する問題」

「ACNS 4.x ソフトウェアおよび ACNS 5.x ソフトウェア機能の相互運用性に関する問題」

ソフトウェアをアップグレードする前に必要な準備

ソフトウェアをアップグレードする前に、この章を読み、アップグレードまたはダウングレード時に発生する可能性のある問題について理解しておく必要があります。次に、現在使用しているソフトウェア リリースに対応する章を参照します。たとえば、ACNS 5.2 ソフトウェアを使用していて、ACNS 5.3 ソフトウェアにアップグレードする場合は、 第 6 章「ACNS 5.2 ソフトウェア リリースからのソフトウェア アップグレード」 を参照します。

独立型デバイスの場合は、CLI を使用して一度に 1 台ずつ、ソフトウェアをアップグレードする必要があります。独立型デバイスの場合は、 第 3 章「独立型 Content Engine のソフトウェア アップグレード」 に記載されている、アップグレードまたはダウングレード手順に従ってください。

集中管理の ACNS ネットワークの場合は、個々のデバイスに対して、またはデバイス グループに含まれている複数のデバイスに対して、ソフトウェアをアップグレードできます。Content Distribution Manager GUI またはデバイスの CLI を使用して、ソフトウェア アップグレードを実行できます。Content Distribution Manager GUI を使用する場合は、Content Distribution Manager 上で稼働中のソフトウェア リリースに対応する章を参照してください。各章に記載されている手順は、そのソフトウェア リリースの GUI インターフェイスと対応しています。GUI はリリースごとに定期的に変更されるので、Content Distribution Manager 上で稼働している ACNS リリースに対応した手順を使用する必要があります。

アップグレード、ダウングレード、および相互運用性に関する考慮事項

ACNS ネットワークは通常、順次アップグレードされるので、ネットワークはある時期、ソフトウェア バージョンの異なるノードで構成される可能性があります。ネットワークのアップグレードまたはダウングレード時には、次の動作が想定できます。

ACNS ネットワークは、展開されたソリューション内で、メジャーまたはマイナーなバージョンの相違が 1 つまでであれば、異なるバージョンが混在していても動作が維持されます。

デバイスの連携に依存する新機能が全面的に動作するのは、ACNS ネットワークのアップグレード完了後になりますが、既存の機能は影響を受けません。

アップグレード中、ノードは短時間、使用できなくなります。

アップグレード中のノードを除き、すべてのノードで動作が全面的に維持されます。他のノードの可用性は、アップグレード中も影響を受けません。

チャネルを除去するか、または disk および acquisition-distribution database cleanup EXEC コマンドを使用した場合を除き、アップグレードまたはダウングレード中もコンテンツは維持されます。

ディスク構成を変更しないかぎり、アップグレードまたはダウングレード中もすべてのログが維持されます。ディスク スペースが再構成された時点で、ログは自動的に削除されます。


) ACNS 5.2 以上のソフトウェアをサポートするのは、CE-511 および CE-566 Content Engine だけです。これらの Content Engine は、ACNS 5.1 以下の ACNS ソフトウェア リリースはサポートしません。


ACNS ネットワーク デバイスは、次の順序でアップグレードすることを強く推奨します。

1. マルチキャスト センダー Content Engine

2. マルチキャスト レシーバ Content Engine

3. 非ルート Content Engine

4. ルート Content Engine

5. Content Router

6. スタンバイ Content Distribution Manager(GUI を使用する場合にかぎり、プライマリより先にアップグレード)

7. プライマリ Content Distribution Manager


) CLI を使用して Content Distribution Manager をアップグレードする場合は、プライマリ Content
Distribution Manager を先にアップグレードしてから、スタンバイ Content Distribution Manager をアップグレードすることを推奨します( ACNS 5.1 Content Distribution Manager のアップグレードを参照)。

プライマリおよびスタンバイ Content Distribution Manager は、相互に正しくフェールオーバーできるように、完全に同一のソフトウェア リリースで動作している必要があります。


アップグレード オプション

ACNS ソフトウェア リリースに関して実行できるアップグレードは、次のとおりです。

任意の ACNS 5.1.x、ACNS 5.2.x、ACNS 5.3.x リリースから任意の ACNS 5.4.x リリース

任意の ACNS 4.2.x リリース(ACNS 4.2.1 は除く)から任意の ACNS 5.x.x リリース(ACNS 5.4.x は除く)

任意の ACNS 5.x.x リリースから任意の ACNS 5.x.x リリース(例外は次のとおり)

ACNS 5.0.x から ACNS 5.4.x に直接アップグレードすることはできません。

まず、ACNS 5.0.x ソフトウェアから ACNS 5.1.x、ACNS 5.2.x、または ACNS 5.3.x にアップグレードし、そのあとで ACNS 5.4.x にアップグレードします。


) 任意の ACNS リリースから ACNS 5.1.9 以上の ACNS 5.1 ソフトウェアまたは 5.2.1 以上の ACNS 5.2 ソフトウェアに Content Engine をアップグレードした場合、Content Engine mediafs キャッシュからキャッシュされているすべての RealMedia コンテンツが削除されます。この状況が発生するのは、これらのリリース間でメディア ファイルのフォーマットが変更されており、キャッシュされた RealMedia ストリーミング ファイルの解釈方法が影響を受けるからです。


ダウングレード オプション

ACNS ソフトウェア リリースに関して実行できるダウングレードは、次のとおりです。

ACNS 5.x.x リリース(ACNS 5.4.x は除く)から ACNS 4.2.x リリース

ダウングレード後、ACNS 5.x.x の機能は動作しません。

ACNS 5.x.x Content Engine によって取得されたコンテンツはすべて、ダウングレード後に失われます。

ACNS 5.1 リリースから ACNS 5.0.3 リリース

ダウングレード後、ACNS 5.1 固有の機能(NTLM 認証など)は動作しません。

ACNS 5.1 Content Engine によって取得された MMS コンテンツは、ダウングレード後も残り、Content Engine によって処理されますが、ACNS 5.0.3 Content Engine で MMS コンテンツを再取得することはできません。

ダウングレード後に mediafs ディスク スペースを再設定する必要があります。

ACNS 5.1 リリースから ACNS 5.0.1 リリース(推奨しない)

このダウングレードでは、CLI を使用して管理データベース テーブルを手動で作成し直す必要があります。

ダウングレード後に mediafs ディスク スペースを再設定する必要があります。

ACNS 5.2 リリースから ACNS 5.1 リリースまたは ACNS 5.0 リリース

任意の ACNS 5.x.x リリースから任意の ACNS 5.x.x リリース(例外は次のとおり)

ACNS 5.4.x から ACNS 5.0.x に直接ダウングレードすることはできません。

まず、ACNS 5.4 ソフトウェアから ACNS 5.1.x、ACNS 5.2.x、または ACNS 5.3.x にダウングレードし、そのあとで ACNS 5.0.x 以下にダウングレードします。

相互運用性に関する要件

デバイス間で適切な相互運用性を確保するには、次のアップグレード要件を満たす必要があります。

ACNS ネットワーク内のデバイス間で、メジャーまたはマイナー ソフトウェア リリースの相違が 1 つ以上あってはなりません。

Content Distribution Manager は、管理対象デバイスと同じかまたはそれ以下のソフトウェア リリースで動作している必要があります。

プライマリとスタンバイの Content Distribution Manager が両方とも、完全に同じソフトウェア リリースで動作している必要があります。

ACNS 4.x デバイスと ACNS 5.x デバイス間に相互運用性は ありません

ACNS 5.5 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.5 ソフトウェア機能の相互運用性の問題について説明します。

Windows メディア ストリーミングに関するプロトコル サポートの変更

ACNS 5.5 ソフトウェアは、サーバ間で Windows メディア コンテンツを取得または配信するための MMS プロトコルをサポートしなくなりました。MMS ベースのストリーミングを使用している場合は、先に RTSP ベースまたは HTTP ベースのストリーミングに移行してから、ACNS 5.5 ソフトウェア リリースにアップグレードする必要があります(MMS ベース ストリーミングから ACNS 5.5 ソフトウェアの HTTP または RTSP ベース ストリーミングへの移行 を参照)。

アップグレード時に削除される MMS の設定

ACNS 5.5.1 リリースからは MMS プロトコルがサポートされないので、Content Engine の CLI および Content Distribution Manager の GUI から、MMS プロトコルを設定するコマンド オプションが削除されました。以前の ACNS リリースでこれらのコマンド オプションを設定していて、ACNS 5.5.1 以上にアップグレードした場合は、MMS の設定が削除されます。以前のリリースにダウングレードしても、MMS の設定は復元されません。

ダウングレード後に MMS の設定を復元する予定がある場合は、ACNS 5.5.x にソフトウェアをアップグレードする前に、設定の保存を計画する必要があります。

Content Distribution Manager は、データベース バックアップ ファイルを自動的に作成します。次のようなファイル名で、CLI ルート ディレクトリにあります。

cms-db-03-13-2006-08-30.dump
 

ファイル名には、バックアップ作成日時が組み込まれます。たとえば、03-13-2006 はこのデータが保存された日付、8:30 は時刻です。データベース バックアップ ファイルのコピーをエクスポートしてから、Content Distribution Manager または Content Engine を ACNS ソフトウェアにアップグレードすることを推奨します。


) ACNS 5.5.1 ソフトウェア リリースで変更または削除されたコマンドの全リストについては、『Release Notes for Cisco ACNS Software, Release 5.5.1』を参照してください。


混在型ネットワークにおけるマルチキャスト ステーション NSC 参照 URL の設定

ACNS 5.5 より前のリリース(ACNS 5.3.x または ACNS 5.4.x など)が動作している Content
Distribution Manager を使用し、ACNS 5.5 ソフトウェアが動作している Content Engine を管理する場合、Content Distribution Manager は wmt multicast station-configuration グローバル コンフィギュレーション コマンドの nsc-reference オプションを認識しません。このオプションは、ACNS 5.1.1 リリースで新しく導入されました。

nsc-reference オプションを設定しないで wmt multicast station-configuration コマンドを使用し、ACNS 5.5 Content Engine を設定した場合は、Content Distribution Manager で設定を正しく処理できます。

wmt multicast station-configuration コマンドと nsc-reference オプションを使用し、ACNS 5.5 Content Engine を設定した場合は、Content Distribution Manager が設定を認識しません。

nsc-reference オプションを設定しないで wmt multicast station-configuration コマンドを使用し、ACNS 5.5 Content Engine を設定した場合、あとで Content Engine CLI からこのステーションの NSC 参照 URL を追加することによって設定を変更しようとすると、下位バージョンの Content Distribution Manager によって、次回の管理システムの更新時にマルチキャスト ステーションが削除されます。

バージョンの異なる Windows メディア サーバが混在する場合

Version 9.x より前の Windows メディア サーバは RTSP をサポートしないので、旧バージョンの Windows メディア サーバでは RTSP ソース URL を使用できません。ACNS ネットワークに RTSP をサポートしない Windows メディア サーバが含まれている場合は、Windows メディア ストリーミングのソース URL として HTTP を使用する必要があります。

Windows メディアの管理対象ライブ プログラム

ACNS 5.5 より前の ACNS リリースでは、Content Engine 間で管理対象ライブ プログラムの通信に使用するプロトコルは MMST でした。ACNS 5.5 リリースで、Content Engine 間の通信プロトコルが RTSPT に変更されました。ネットワーク内の一部の Content Engine 上で ACNS 5.5 ソフトウェアを使用していて、他の Content Engine ではそれ以前のバージョンを使用している場合、Windows メディアの管理対象ライブ プログラムが失敗します。ACNS 5.5 Content Engine が ACNS 5.4 または 5.3 の Content Engine と通信できないからです。ACNS 5.5 ソフトウェアに移行する場合は、管理対象ライブ プログラムが正しく配信されるように、Windows メディア ライブ チャネルのすべての Content Engine を ACNS 5.5 ソフトウェアにアップグレードする必要があります。

管理対象ライブ ストリーミングに関して、HTTP ユニキャスト配信(Unicast in-Unicast out)はサポートされません。サポートされるのは RTSP URL だけです。Content Distribution Manager GUI の Live Source URL フィールド( Services > Video > Programs > Live Streaming )には、HTTP または RTSP URL を指定できますが、Unicast URL Reference フィールドおよび Customized URL フィールドに指定できるのは、RTSP URL だけです。

アップグレードの前に Live Streaming ウィンドウ( Services > Video > Programs > Live Streaming )で MMS を設定した場合、その設定は ACNS 5.5 ソフトウェアにアップグレードしたあとでも変わりません。しかし、MMS から ACNS 5.5 ソフトウェアでサポートされるプロトコルのいずれかにプロトコルを変更しないかぎり、このウィンドウでソース URL を変更することはできません。

旧リリースから MMS プロトコルが組み込まれている場合、このウィンドウで設定値を変更しようとすると、Content Distribution Manager GUI からエラー メッセージが返されます。

Windows メディア サービス ストリーミング メディアの取得

以前のリリースでは、ACNS ソフトウェアは Windows メディア ストリーミング コンテンツを Content Engine で取得することをサポートしていました。ACNS 5.5 ソフトウェアでは、Content Engine は Windows メディア ストリーミング コンテンツの取得も事前配信もできません。

アップグレードの前に、Channel Content ウィンドウで、コンテンツ アイテムのソース URL として MMS URL を指定していた場合( Services > Web > Channels > Channel Content )、ACNS 5.5 ソフトウェアにアップグレードしたあとでも設定は変わりません。ただし、MMS から ACNS 5.5 ソフトウェアでサポートされるプロトコルのいずれかに、URL のプロトコルを変更しないかぎり、このウィンドウでコンテンツ アイテムを変更することはできません。

旧リリースから MMS プロトコルが組み込まれている場合、このウィンドウで設定値を変更しようとすると、Content Distribution Manager GUI からエラー メッセージが返されます。

MMS の WCCP トランスペラレント リダイレクション

ACNS 5.5 リリースでも、MMS リダイレクション用の WCCP Service 81 および Service 82 は有効です。MMS に対する WCCP リダイレクションがネットワークで設定されていて、MMS 要求が Content Engine にリダイレクトされた場合、Content Engine は要求を受け付けて、接続をただちに終了します。この動作によって、Windows メディア クライアントはその要求に関して、HTTP に強制的にロールオーバーさせられます。MMS の設定値を RTSP に明示的に再設定することを推奨します。

Windows Media Encoder またはバージョンが混在する Windows Media Player を使用する場合

Windows Media Player と Windows Media Encoder 間、または Content Engine と Windows Media Player 間の通信に関しては HTTP がサポートされますが、Content Engine 相互間の通信ではサポートされません。

Windows Media Encoder がサポートするデータ配信モードは、HTTP だけです。Windows Media Encoder は RTSP をサポートしません。ACNS ソフトウェアは、送信元として Windows Media Encoder を使用するライブ ストリームをサポートします。HTTP サポートによって、Content Engine は Windows Media Encoder と通信できます。

Version 9 以上の Windows Media Player が明示的な mmst:// または mmsu:// URL 要求を出した場合、ACNS 5.5 ソフトウェアはエラー メッセージを送信し、ストリームを再生しません。要求に mms:// URL が含まれていた場合、プレーヤーは代わりに RTSP または HTTP を使用します。

MMS プロトコルを使用してパブリッシング ポイントに接続した場合は、ロールオーバー方式によって最適な接続が確保されます。Version 9 以上の Windows Media Player で、URL に MMS URL(mms://)が指定されていた場合、Windows Media Player はメディア配信に次のプロトコルを示された順番通りに試行します。

1. RTSPU(UDP を使用する RTSP)

2. RTSPT(TCP を使用する RTSP)

3. HTTP

4. MMSU(UDP を使用する MMS)

5. MMST(TCP を使用する MMS)


) ネットワーク内でバージョンの異なる Windows Media Player が混在している場合は、すべてのバージョンの Windows Media Player で HTTP プロキシを設定し、HTTP 上で Windows メディア ストリーミングが行われるようにします。HTTP はすべてのソフトウェア バージョンでサポートされています。


MMS ベース ストリーミングから ACNS 5.5 ソフトウェアの HTTP または RTSP ベース ストリーミングへの移行

ACNS 5.5 リリースにソフトウェアをアップグレードする前に、次の作業が必要です。


ステップ 1 Content Engine で MMS 発信プロキシが有効になっている場合、次のいずれかのコマンドを使用して、RTSP 発信プロキシまたは HTTP 発信プロキシに設定を変更します。

wmt proxy outgoing http host { hostname | ipaddress } port

wmt proxy outgoing rtsp host { hostname | ipaddress } port

さらに、Windows メディアのデフォルト ポートを 1755 から 554(RTSP)またはその他のポートに変更します。

ステップ 2 Version 9 以上の Windows Media Player を使用する場合は、パブリッシング ポイントの URL を MMS ではなく、RTSP または HTTP のどちらかを使用するように変更する必要があります。

たとえば、次のような URL を使用して、sample.asf ファイルのオンデマンド パブリッシング ポイントを設定しているとします。

mms://Server/sample.asf

次のように URL を変更します。

rtsp://Server/sample.asf

または、次のように変更します。

http://Server/sample.asf

ステップ 3 すべての Windows メディア ブロードキャスト エイリアス URL を MMS から RTSP または HTTP に変更します。

ステップ 4 すべての Windows メディア マルチキャスト ステーション URL を MMS から RTSP または HTTP に変更します。

ステップ 5 MMS プロキシ対応として Windows Media Player を設定する場合は、Version 9 以上の Media Player の場合は MMS から RTSP に、それ以前のバージョンの Windows Media Player の場合は HTTP に設定を変更します。

ステップ 6 WCCP を有効にしている場合は、RTSP 透過的代行受信の設定が必要になることがあります。

ステップ 7 再生リストの URL は、アップグレード時に MMS から HTTP に変換されます。再生リストで参照されているコンテンツのストリーミングに、ポート 80 以外のポートを使用していた場合は、実際のポート番号が指定されるように、各再生リスト参照を更新する必要があります。

たとえば、5.4 リリース以下の ACNS で、ポート 8008 を使用して welcom2.asf ファイルのストリーミングを行っていた場合、URL は次のようになっています。

mms://server/welcome2.asf

Windows Media Player Version 9 で、ストリーミングに同じポートを使用する場合、URL は次のようになります。

http://server:8008/welcome2.asf


 


注意 ACNS 5.5 ソフトウェアにアップグレード後、MMS の設定値はすべて消去されます。

Windows メディア サービス ライセンス キーの相互運用性に関する問題

ACNS 5.5 リリース以上のソフトウェアで Windows メディア サービス(WMS)用に購入したライセンスは、ACNS 5.4.x リリース以下ではサポートされません。ただし、ACNS 5.4 ソフトウェアが稼働している Content Distribution Managerでは、ACNS 5.4 デバイスと ACNS 5.5 デバイスの両方に対するライセンスを設定できます。

ただし、ACNS 5.4 Content Distribution Manager は、ACNS 5.5 のライセンス キーを正しく検証できないという問題点が 1 つあります。ACNS 5.5 ソフトウェアのライセンス キーは新しいため、旧バージョンのソフトウェアでは認識されません。ACNS 5.4 Content Distribution Manager の GUI から ACNS 5.5 WMS のライセンス キーを検証すると、キーの入力が正しくないというエラー メッセージが表示されます(Content Distribution Manager GUI では、ライセンス キーの検証はオプション)( 表1-1 を参照)。

 

表1-1 Content Distribution Manager の相互運用性に関するマトリックス

Content Distribution Manager ソフトウェア
ACNS 5.4 WMS
ライセンス
ACNS 5.5 WMS
ライセンス
ACNS 5.5.x
ライセンス
ACNS 5.4

設定

検証

不可

不可

ACNS 5.5

設定

 

検証

不可

ACNS 5.4 Content Distribution Manager で ACNS 5.5 のライセンス キーを検証すべきではありません。ただし、ACNS 5.4 Content Distribution Manager からライセンス キーを送信し、ACNS 5.5 リリース用の WMS ライセンスを正しく設定することは可能です。この場合、Content Engine 上で WMT がイネーブルであることを確認するには、 show wmt EXEC コマンドを使用します。

ACNS 5.4 リリース以下のソフトウェアが稼働しているアプライアンス上で、ACNS 5.5(またはそれ以上)の WMS ライセンス キーの設定を試みると、ライセンス キーがエラーになり、そのアプライアンスでは Windows メディア サービスがイネーブルになりません。このエラーは記録され、Content Distribution Manager GUI で Devices > Device Monitoring > Logs を選択すると確認できます。

ネットワークに ACNS 5.4 デバイスと ACNS 5.5 デバイスが混在している状況で、デバイス グループ別にライセンスを設定する場合は、ライセンスが矛盾する問題を避けるために、Content Distribution Manager でソフトウェア リリースに基づいてデバイスを別々のグループに分けることを推奨します。


) ACNS 5.4 から ACNS 5.5 にソフトウェアをアップグレードした場合は、アップグレード後も、ACNS 5.4 で設定したあらゆる WMS ライセンス キーが引き続き有効です。


Content Distribution Manager の相互運用性に関する問題

ACNS 5.4 ソフトウェアが稼働している Content Distribution Manager は、一部または全部の Content Engine で ACNS 5.5 ソフトウェアが稼働している ACNS ネットワークの設定および管理用に、中央集中型のインターフェイスを提供します。

ACNS 5.5 ソフトウェアが稼働している Content Distribution Manager は、すべての Content Engine で ACNS 5.5 ソフトウェアだけが稼働している ACNS ネットワークの設定および管理用に、中央集中型のインターフェイスを提供します( 表1-2 を参照)。

 

表1-2 Content Distribution Manager の相互運用性に関するマトリックス

Content Distribution Manager ソフトウェア
ACNS 5.4.x
アプライアンス
ACNS 5.5.1
アプライアンス
それ以降の ACNS 5.5.x
アプライアンス

ACNS 5.4

ACNS 5.5

不可

ACNS 5.5 リリースにネットワークを移行させる場合は、次の要件を満たす必要があります。

Content Distribution Manager で ACNS 5.4 ソフトウェアが稼働していることを確認します。

必ず、Content Engine および Content Router を ACNS 5.5 にアップグレードしてから、Content Distribution Manager を ACNS 5.5 にアップグレードします。

必ず、ネットワークに含まれている他のすべてのアプライアンスが ACNS 5.5 ソフトウェアを使用するようになってから、最後に Content Distribution Manager を ACNS 5.5 にアップグレードします。

「MMS ベース ストリーミングから ACNS 5.5 ソフトウェアの HTTP または RTSP ベース ストリーミングへの移行」に概略が記載されている、移行手順に従います。

ACNS 5.4 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.4 ソフトウェアの相互運用性の問題について説明します。

Content Distribution Manager

ACNS 5.4 ソフトウェアで動作している Content Distribution Manager は、ACNS 5.4 以上のバージョンのソフトウェアだけが使用されている Content Engine および Content Router を管理できます。ACNS 5.1、ACNS 5.2、または ACNS 5.3 ソフトウェアで動作している Content Distribution Manager は、ACNS 5.4 ソフトウェアが使用されている Content Engine および Content Router を管理できます。管理対象のすべての ACNS デバイスを ACNS 5.4 リリースにアップグレードするまでは、Content Distribution Manager を ACNS 5.4 ソフトウェアにアップグレードしないことを推奨します。

コンテンツ取得のためのクッキー サポート

コンテンツ取得のためのクッキー サポートは、ACNS 5.4 ソフトウェアの新機能です。この機能が影響を与えるのは、ルート Content Engine だけです。クッキー サポートのためにマニフェスト ファイルを設定している場合に、ACNS 5.4 からそれ以前のリリースにダウングレードすると、ダウングレード後に、マニフェスト ファイルのアトリビュート enableCookies および authCookie について、解析エラーが発生します。

ACNS 5.4.x ソフトウェアにアップグレードした場合の Websense の問題

Cisco ACNS 5.4 ソフトウェアは、すべての Cisco Content Engine プラットフォーム上で Websense Enterprise Version 5.5 ソフトウェアをサポートします。


) ACNS 5.4 ソフトウェアに統合された Websense Enterprise Version 5.5 ソフトウェアには、512 MB 以上の RAM が必要です。デバイスの RAM を 512 MB 以上に拡張するか、または 512 MB 以上の RAM を備えた別のデバイスに統合 Websense サーバを移動させることを推奨します。


ACNS 5.3.x ソフトウェアから ACNS 5.4.x ソフトウェアにアップグレードした場合、Websense バイナリによる RADIUS および eDirectory の設定は提供されなくなります。したがって、RADIUS および eDirectory エージェントの設定に使用されていたグローバル コンフィギュレーション コマンドは、ACNS 5.4.1 ソフトウェア リリースでは非推奨になっています。

ACNS 5.3.x ソフトウェアが稼働している Content Engine 上で、CLI を使用して RADIUS および eDirectory エージェントを設定し、さらに ACNS 5.3.x ソフトウェアを ACNS 5.4.x ソフトウェアにアップグレードした場合、wsradius.ini および wsedire.ini ファイルに格納されていた RADIUS および eDirectory エージェントの設定は保存されます。ただし、Websense GUI Manager を使用して RADIUS および eDirectory エージェントに対して行った設定変更は、これら 2 つの .ini ファイルには反映されません。


) RADIUS および eDirectory エージェントの起動に使用する CLI コマンド(websense-server service radius-agent activate および websense-server service edirectory-agent activate グローバル コンフィギュレーション コマンド)および eDirectory 管理パスワードを指定するための CLI コマンド
websense-server service edirectory-agent edir-server administrative-passwd password グローバル コンフィギュレーション コマンド)は、ACNS 5.4.x ソフトウェアで維持されています。


ACNS 5.2.x ソフトウェアから ACNS 5.4.x ソフトウェアにアップグレードした場合、ACNS 5.2.x ソフトウェア リリースでは RADIUS および eDirectory エージェントがサポートされていなかったので、以前の Websense の設定を変更する必要はありません。

ACNS 5.4.x ソフトウェアからダウングレードした場合の Websense の問題

ACNS 5.4.x ソフトウェアから ACNS 5.3 ソフトウェアにダウングレードした場合は、ローカル WebsenseEnterprise ディレクトリおよびその他の Websense ファイルが削除されます。それまで Websense が使用していた既存の内部コンフィギュレーション ファイルはすべて削除され、ダウングレード以前に行われた変更はすべて失われます。

次のエラー メッセージが表示され、このダウングレードに伴う Websense の問題について通知されます。

WARNING:
Websense does not support downgrade
Hence removing /local/local1/WebsenseEnterprise
Websense will stop working after copy ftp install
 

) 旧リリースのソフトウェアでは、WebsenseEnterprise ディレクトリが削除されたことを伝えるエラー メッセージは生成されませんでした。詳細については、「ACNS 5.0 ソフトウェアまたは ACNS 5.1 ソフトウェアにダウングレードした場合の Websense に関する問題」を参照してください。


ダウングレード後に Content Engine がリロードされると、Websense が再インストールされ、内部コンフィギュレーション ファイルが新しく作成されます。Content Engine Websense サーバの設定( websense-server service policy local activate websense-server service eim activate など)がダウングレード以前にスタートアップ コンフィギュレーション ファイルに保存されていた場合は、それらの設定は再初期化されます。

ACNS 5.3 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.3 ソフトウェアの相互運用性の問題について説明します。

無効なカスタム ログ フォーマット ストリング

ACNS 5.3 以上のソフトウェアでは、無効なカスタム ログ フォーマット ストリングを設定できません。しかし、5.3 リリースより前の ACNS ソフトウェアでは、無効なカスタム ログ フォーマット ストリングの設定が可能です。ACNS 5.2 ソフトウェアから ACNS 5.3 ソフトウェアに ACNS デバイスをアップグレードしたときに、設定されていた無効なカスタム ログ フォーマットは削除されます。

SmartFilter プラグインのバージョン

Content Engine をリリースの異なる ACNS ソフトウェアにアップグレードまたはダウングレードしたときに、SmartFilter プラグインのバージョンに差異があった場合、SmartFilter データベースおよびコンフィギュレーション ファイルが削除され、デフォルトのコンフィギュレーションがロードされます。この入れ替えが行われるのは、SmartFilter ソフトウェアのバージョンが新しくなるたびに、設定の詳細が変更される可能性があるからです。SmartFilter プラグインをアップグレードまたはダウングレードするたびに、SmartFilter Administration Console から Content Engine に新しいデータベースをダウンロードする必要があります。

アップグレードおよびダウングレード パスの廃止

ACNS 5.3.1 ソフトウェア リリースでは、次のアップグレードおよびダウングレード パスが廃止されました。

ACNS 4.2 ソフトウェアから ACNS 5.3 ソフトウェアへのアップグレード

ACNS 5.3 ソフトウェアから ACNS 4.2 ソフトウェアへのダウングレード

ACNS 5.2 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.2 ソフトウェアの相互運用性の問題について説明します。

コンフィギュレーション ファイル フォーマットの非互換性

ACNS ソフトウェアには、マルチキャスト センダーおよびレシーバ Content Engine 用に、デフォルトの TIBCOSmartPGM FX コンフィギュレーション ファイルが組み込まれています。マルチキャスト センダーおよびレシーバ Content Engine は、マルチキャスト クラウドの構成を調べることによって、マルチキャストに使用するメディア(地上または衛星)を決定します。Content Engine はさらに、マルチキャスト用のメディアに対応する PGM コンフィギュレーション ファイルから、設定パラメータ値を読み取ります。

ACNS 5.2 ソフトウェアで使用するデフォルトの TIBOSmartPGM FX コンフィギュレーション ファイルは、次のとおりです。

fxd.conf.src

fxd.conf.rcv

ACNS 5.1 および ACNS 5.0 ソフトウェアでは、2 種類のファイル セットにデフォルトの PGM および FX マルチキャスト設定パラメータが保存されます。FX パラメータが一方のファイル セットに保存され、PGM パラメータがもう一方のファイル セットに保存されます。デフォルトのファイル名は、次のとおりです。

fxd.conf.src

fxd.conf.rcv

pgmfx.conf.src

pgmfx.conf.rcv


) ACNS 5.2 ソフトウェア(およびその後のリリース)と ACNS 5.1 または 5.0 ソフトウェア間では、コンフィギュレーション ファイル フォーマットに互換性がありません。ACNS 5.1 または 5.0 ソフトウェアから ACNS 5.2 ソフトウェアにアップグレードすると、/local1/multicast-expert-config/ ディレクトリに置かれている、ACNS 5.1 および 5.0 のカスタマイズしたコンフィギュレーション ファイルの名前が「_3」を付加して変更されます。ACNS 5.3 以上のソフトウェアから ACNS 5.1 または 5.0 ソフトウェアにダウングレードした場合は、ACNS 5.2 のコンフィギュレーション ファイル名が「_4」を付加して変更されます。ACNS 5.2 リリース以上のソフトウェアからアップグレードまたはダウングレードした場合は、そのあとで、カスタマイズしたコンフィギュレーション ファイルを手動で作成し直す必要があります。


Content Engine は、/local1/multicast-expert-config/ ディレクトリに参照用として、デフォルトの
TIBCOSmartPGM FX コンフィギュレーション ファイルのサンプルを格納します。これらのサンプル コンフィギュレーション ファイルのいずれかを修正し、名前を変更して、マルチキャスト センダーまたはレシーバ Content Engine に保存することができます。カスタマイズしたコンフィギュレーション ファイルを作成し、デフォルトのコンフィギュレーション ファイル名で
/local1/multicast-expert-config/ ディレクトリにコピーすると、Content Engine はデフォルトのコンフィギュレーション ファイルではなく、カスタマイズされたコンフィギュレーション ファイルを使用します。カスタマイズしたコンフィギュレーション ファイルが有効になるのは、Content Engine の再起動後です。

ACNS 5.2 ソフトウェアが稼働している Content Engine には、次のサンプル コンフィギュレーション ファイルがあります。

fxdSatellite.conf.src.sample ― 衛星ネットワークのセンダー Content Engine に使用

fxdSatellite.conf.rcv.sample ― 衛星ネットワークのレシーバ Content Engine に使用

fxdTerra.conf.src.sample ― 地上ネットワークのセンダー Content Engine に使用

fxdTerra.conf.rcv.sample ― 地上ネットワークのレシーバ Content Engine に使用

ACNS 5.1 および ACNS 5.0 ソフトウェアが稼働している Content Engine には、次のサンプル コンフィギュレーション ファイルがあります。

pgmfxSatellite.conf.src.sample

pgmfxSatellite.conf.rcv.sample

pgmfxTerra.conf.src.sample

pgmfxTerra.conf.rcv.sample

マルチキャスト ファイル転送

ACNS 5.2 ソフトウェアは、新しいマルチキャスト ファイル転送機能をサポートします。これらの新機能によって、ACNS 5.2 ネットワークにおけるマルチキャスト ファイル配信の信頼性とパフォーマンスが向上します。混合ネットワークでは、これらの拡張機能が Content Engine の相互運用性に影響を与えます。

旧リリースの ACNS(5.0 リリースおよび 5.1 リリース)では、ファイル転送セッションは欠落パケットを再送する時間に依存していました。センダーはレシーバ Content Engine からの再送信要求(NACK)ごとに、この時間内にパケットを送信しなければなりませんでした。マルチキャスト レシーバのセッション参加が遅すぎて、送信枠に収まらなかったデータ ブロックを受信できなかった場合、センダーは欠落したブロックを再送しません。レシーバはファイル全体を受信できないので、送信エラーになります。レシーバは、後続の送信セッション(カルーセル パス)で欠落ファイルが回復されるまで待機しなければなりませんでした。レシーバに可能なのは、ファイル全体を受信するか、または何も受信しないかでした。受信レートが送信レートより遅い場合、低速のレシーバは大型ファイルの受信に失敗することがよくありました。

ACNS 5.2 ソフトウェアのマルチキャスト ファイル転送拡張機能は、ファイル転送の時間枠を排除することによって、このような問題を解決します。この機能をチェックポイントといいます。チェックポイントによって、センダーは転送ファイルをブロックに分割し、転送セッションが終了するまで、ありとあらゆるブロックを再送信できます。レシーバは転送セッション中いつでも、欠落したブロックの再送信を要求できます。レシーバ Content Engine はさらに、転送ブロックをどのような順番でも受信できます。長時間にわたってデータ送信を行うことができるので、ほとんどの状況で、レシーバは欠落したデータ ブロックを回復し、正常に転送を完了できます。データ損失に対するファイル転送の抵抗力が強化されます。

この機能によって、マルチキャスト レシーバが遅れて転送セッションに参加した場合の問題も解決されます。めったにないことですが、レシーバの参加が遅く、センダーが非常に大きいファイルをほとんど全部マルチキャストしてしまったような場合でも、レシーバはデータを受信できます。レシーバが欠落したすべてのブロックについて、再送信を要求することもできます。レシーバが転送中にオフラインになり、再起動した場合でも、受信済みのブロックの再送信を要求することなく、欠落データを回復できます。

このような拡張機能が原因で、ACNS 5.2 ソフトウェアを使用しているレシーバは、ACNS 5.0 または 5.1 ソフトウェアを使用しているセンダーとは対話 できません 。ACNS 5.2 のマルチキャスト レシーバは、ACNS 5.0 または 5.1 のマルチキャスト センダーから送られたファイルを無視します。ただし、ソフトウェアによって下位のソフトウェア バージョンが検出され、チェックポイント機能がオフにされるので、ACNS 5.2 のマルチキャスト センダーは、ACNS 5.0 または 5.1 のマルチキャスト レシーバとの相互運用が可能です。先にマルチキャスト センダーを ACNS 5.2 ソフトウェアにアップグレードしてから、レシーバを ACNS 5.2 ソフトウェアにアップグレードすることを推奨します。

SMB ファイルの取得

ACNS 5.2 ソフトウェアから ACNS 5.1 ソフトウェアに、ルート Content Engine をダウングレードすると、一部のチャネルが使用不能になり、一部のコンテンツが取得できません。この問題が発生するのは、マニフェスト ファイルの URL が Server Message Block(SMB)URL で、パス フォーマットが Universal Naming Convension(UNC)(\host\share\file など)の場合、または src または start-url アトリビュートのどちらかで指定されているアイテムまたはクロール タスクが UNC パス フォーマットの場合です。

ACNS 5.1 ソフトウェアは SMB ファイルの取得をサポートしないので、ACNS 5.1 ソフトウェアが稼働しているルート Content Engine は、SMB 共有からマニフェスト ファイルを取り出したり、コンテンツを取得したりできません。

この問題を回避するには、ACNS 5.2 ソフトウェアから ACNS 5.1 ソフトウェアにルート Content Engine をダウングレードする前に、またはダウングレードしたあとで、次の作業を行います。

Content Distribution Manager GUI の Channel configuration ウィンドウで、Manifest URL フィールドから SMB URL を削除し、サポート対象プロトコル(HTTP、FTP、または HTTPS)を指定した URL を使用します。


) ACNS 5.1 Content Distribution Manager GUI から、Channels > Channels > Edit Channel を選択します。
ACNS 5.2 Content Distribution Manager GUI からは、Content > Channels > Edit Channel > Channel Content を選択します。


UNC フォーマットのパスが設定されているコンテンツ アイテムおよびクロール タスクを削除することによって、マニフェスト ファイルを編集します。

acquirer start-channel EXEC コマンドを使用することによって、チャネル取得を開始し、回避策が有効であることを確認します。

ソフトウェア ドライバ サポートおよび TV 出力機能

TV 出力サービスは、ハードウェア デコーダを介して事前配信された MPEG コンテンツのローカル再生をサポートします。ハードウェア デコーダは、デジタル情報をアナログの TV 信号に変換します。TV 出力サービスが機能するのは、Content Engine にサポート対象の MPEG ハードウェア デコーダが装備されている場合だけです。Content Distribution Manager に登録された Content Engine 上で TV 出力サービスを使用できるようにするには、 tvout enable グローバル コンフィギュレーション コマンドを使用します。


) 事前配信のコンテンツがサポートされるのは、登録済み Content Engine 上に限られます。独立型の Content Engine(すなわち、Content Distribution Manager に登録されていなくて、Content Engine の GUI または CLI で管理および監視される Content Engine)上ではサポートされません。したがって、独立型 Content Engine では、事前配信のコンテンツを伴う TV 出力サービスはサポートされません。


TV 出力サービスに関連する変更事項は、次のとおりです。

ACNS 5.2.3 ソフトウェアでは、ACNS TV 出力機能が新しい Vela II Revision D および Revision E MPEG ハードウェア デコーダ カードを装備した CE-510 および CE-565 モデルで有効になりました(ACNS 5.2.1 ソフトウェアでは、これらのカードにこの機能は動作しませんでした)。

ACNS 5.2.3 ソフトウェアには、より新しいドライバ ソフトウェアが組み込まれています。この新しいドライバ ソフトウェアは、従来の Vela II Revision A カードとともに、新しい Vela II Revision D および Revision E カードもサポートします。

ACNS 5.2.3 以上のソフトウェアでは、 show hardware EXEC コマンドの出力に、Content Engine に装備されている TV 出力ハードウェアのバージョンが表示されます。次に示す show hardware コマンドの出力例では、該当する情報が太字になっています。このコマンド出力の「rev 3」は、TV 出力ハードウェアに、新しい Revision 3 MPEG デコーダの PCI 部品が使用されていることを意味します。Vela II Revision D および Revision E カードには、Revision 3 の部品が使用されています。

Content Engine # show hardware
.
.
.
Total 1 CPU.
1024 Mbytes of Physical memory.
1 CD ROM drive (CD-224E)
1 AV card (Vela II)
2 GigabitEthernet interfaces
1 Console interface
2 USB interfaces [Not supported in this version of software]
 
The following PCI cards were found:
PCI-Slot-1 MPEG-Decoder-AV [1105:8476 (Sigma Designs, Inc.) (rev 3)]
PCI-Slot-2 SCSI
Manufactured As: Pre-FCS 565 [867383Z]
.
.
.
 

) Revision D または Revision E カードでの TV 出力サービスをサポートするには、Content Engine で新しいドライバ ソフトウェアが動作していなければなりません。ACNS 5.2.3 ソフトウェアには、旧バージョンのドライバではなく、この新しいドライバ ソフトウェアが組み込まれています。


ACNS 5.0.17 ソフトウェア、ACNS 5.1.11 ソフトウェア、または ACNS 5.2.1 以上のソフトウェアでは、Content Engine に組み込まれている TV 出力ハードウェアをサポートしないバージョンの ACNS ソフトウェアが Content Engine 上で動作している場合に、 show hardware EXEC コマンドの出力からそのことがわかります。次の出力例は、Content Engine に Vela II 音声ビデオ(AV)カードがあり、それが Content Engine 上で稼働している ACNS ソフトウェアのバージョンではサポートされないことを示しています。次の show hardware コマンドの出力例では、該当する情報が太字になっています。

Content Engine # show hardware
.
CPU 0 is GenuineIntel Intel(R) Celeron(R) CPU 1.70GHz (rev 1) running at 1699MHz
.
Total 1 CPU.
1024 Mbytes of Physical memory.
1 CD ROM drive (CD-224E)
1 AV card (Vela II) [***Revision not supported in this version of software***]
2 GigabitEthernet interfaces
1 Console interface
2 USB interfaces [Not supported in this version of software]
 
The following PCI cards were found:
.
.
.
 

ACNS 5.0.17 ソフトウェア、ACNS 5.1.11 ソフトウェア、または ACNS 5.2.1 以上のソフトウェアでは、Content Engine に組み込まれている TV 出力ハードウェアをサポートしないバージョンの ACNS ソフトウェアが Content Engine 上で動作している場合に、 show tvout EXEC コマンドの出力からもそのことがわかります。次の show tvout コマンドの出力例では、該当する情報が太字になっています。

Content Engine # show tvout
.
.
.
TV-out model: ce565-002 (sigma)
[***Hardware revision level not supported in this version of software***]
 
TV-out service is not enabled
TV-out signal: ntsc
 
TV-out service is not running
.
.
.

ACNS 5.1 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.1 ソフトウェアの相互運用性の問題について説明します。

コンテンツの配信

ACNS 5.0.1、5.0.3、および 5.1 ソフトウェアが稼働し、ルート Content Engine、フォワーダ、レシーバ、マルチキャスト センダーなど、さまざまな役割を果たしている Content Engine は、すべてのリリースに共通する基本機能を組み合わせて、相互に連動する場合があります。フォワーダ チェーンが、ACNS 5.1 ソフトウェアが動作している Content Engine から ACNS 5.0 ソフトウェアが動作している Content Engine に、そこからさらに ACNS 5.1 ソフトウェアが動作している別の Content Engine にコンテンツを渡した場合、3 番めの Content Engine までチェーン全体で ACNS 5.1 ソフトウェアの機能が維持されます。

たとえば、上位バージョンのフォワーダから下位バージョンのレシーバにコンテンツを送信する場合、余分なデータベース カラムは、メタデータ フィールドで名前/値のペアに変換されて送信されます。下位バージョンのレシーバはメタデータを無視しますが、データベースにはそのままメタデータを書き込んでレシーバへ渡し、チェーンの先へ送ります。チェーンの先のレシーバで上位バージョンのソフトウェアが動作している場合は、メタデータとそのメタデータに伴う機能が拾い上げられます。

ただし、新しいリリースで使用できる機能は、古いリリースが稼働している他の Content Engine に対しては動作しません。たとえば、マルチキャスト バックアップ センダー(ACNS 5.1 リリースの機能)は、ACNS 5.0 ソフトウェアが稼働しているマルチキャスト レシーバに対して動作しません。

マルチキャスト バックアップ センダーが機能するのは、プライマリ センダーがダウンしていることをレシーバが検出し、バックアップ センダーにマルチキャスト ファイルの再送信を開始させる NACK を送信した場合だけです。ネットワークに ACNS 5.1 マルチキャスト レシーバが含まれていない場合は、マルチキャスト バックアップ センダーが存在していても、バックアップ センダーがアクティブになることはできません。

同様に、インテリジェント カルーセル機能はマルチキャスト レシーバに依存して、マルチキャスト センダーにファイル要求を送信します。このような要求を行えるのは、ACNS 5.1 ソフトウェアを使用しているレシーバだけです。ただし、混合ネットワークでは、ACNS 5.0 ソフトウェアを使用しているレシーバ Content Engine で、ACNS 5.1 ソフトウェアが動作しているレシーバが要求したファイル送信を受信できます。


) ACNS 5.1 の相互運用性に伴うもう 1 つの問題について、「ACNS 5.0 ソフトウェアまたは ACNS 5.1 ソフトウェアにダウングレードした場合の Websense に関する問題」も参照してください。


マルチキャスト クラウド

ACNS 5.1.x より前の ACNS ソフトウェア リリースは、ACNS 5.1.x ソフトウェアで採用され、今後のリリースでサポートされる、マルチキャスト クラウド機能の一部をサポートしません。バージョンの異なる ACNS ソフトウェアがネットワークに混在している場合は、マルチキャスト センダーの相互運用性について、次の補足事項を考慮する必要があります。

条件 1:ACNS ネットワークは、マルチキャスト対応チャネルに加入した Content Engine に対して、マルチキャスト配信を行うように設定されています。マルチキャスト センダーおよびレシーバ Content Engine では、バージョンの異なる ACNS ソフトウェアが稼働しています。すべての Conten Engine がマルチキャスト対応として正しく設定されています。Content Distribution Manager では、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが稼働しています。

現象:

バックアップ センダーへのフェールオーバーをサポートするのは、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが稼働しているセンダーだけです。NACK(否定応答)を送信できるのは、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが稼働しているレシーバだけです。

プライマリ センダーとバックアップ センダーの両方が活発に同じファイルを送信した場合、レシーバ Content Engine は 2 つのセンダーのうちの一方をロックアウトして、最初のセンダーからファイル コピーを 1 つだけ受信します。


) 事例 1 ~ 6 では、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが稼働している Content Distribution Manager を使用しているものとします。


事例 1.1:プライマリ センダーは ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。バックアップ センダーはレシーバーと同様、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。

バックアップ センダーはプライマリ センダーがアクティブではないと判断し、設定されているフェールオーバー時間の経過後、アクティブになります。

プライマリ センダーはカルーセル パスおよびマルチキャスト送信帯域幅の設定に従って、定期的にマルチキャスト ファイルを送信します。

レシーバはプライマリ センダーに対して NACK の送信を試みますが、NACK エラーを受信したので、バックアップ センダーへの NACK 送信を開始します。バックアップ センダーは NACK に応答します。

事例 1.2:プライマリ センダーとバックアップ センダーの両方で、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。レシーバは ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。

プライマリ センダーとバックアップ センダー間のフェールオーバーは機能しますが、プライマリ センダーとバックアップ センダーのどちらも、レシーバから NACK 応答を受信しません。

プライマリ センダーは NACK を受信しなくても、コンテンツの最初のカルーセル パスを送るので、レシーバは迅速にグループに参加した場合、コンテンツを取得できることもあります。迅速にグループに参加しなかったレシーバは、コンテンツを取得できません。

事例 1.3:プライマリ センダーとレシーバはどちらも、ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。バックアップ センダーは、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。

バックアップ センダーはプライマリ センダーがアクティブではないと判断し、設定されているフェールオーバー猶予期間の経過後、アクティブになります。バックアップ センダーはマルチキャストを送信する前に、レシーバからの NACK 応答を待ち続けますが、レシーバは NACK を送信できません。

プライマリ センダーはカルーセル パスおよびマルチキャスト送信帯域幅の設定に従って、定期的にマルチキャスト ファイルを送信します。

レシーバは、プライマリ センダーからコンテンツを取得できるはずです。

条件 2:Content Distribution Manager から警告メッセージが出されることもありますが、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが稼働している Content Distribution Manager に Content Engine が登録されていて、Content Engine で ACNS 5.1.x より前の ACNS ソフトウェアが稼働している場合、Content Engine をバックアップ センダーとして設定できます。事例 4 ~ 6 では、このような状況におけるバックアップ センダーの動作について説明します。

現象:Content Distribution Manager は古いソフトウェア バージョンが動作している Content Engine に、関連設定情報および設定変更を送信しません。その結果、Content Engine は自身をマルチキャスト バックアップ センダーとして確立できません。この状況は、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアが動作しているバックアップ センダーが、Content Engine の CLI を使用して古いソフトウェア バージョンにダウングレードされた場合にも発生することがあります。

事例 2.1:プライマリ センダーとバックアップ センダーはどちらも、ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。レシーバは、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。

レシーバは、プライマリ センダーとバックアップ センダーに対して、NACK の送信を交互に試みますが、成功しません。

プライマリ センダーはカルーセルおよびマルチキャスト送信帯域幅の設定に従って、定期的にマルチキャスト ファイルを送信します。

事例 2.2:プライマリ センダーとレシーバで、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。バックアップ センダーでは ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。

プライマリ センダーは、設定されているフェールオーバー猶予期間の経過後、バックアップ センダーをアクティブとして認識しません。

レシーバが NACK を正常に送信できるのは、プライマリ センダーに対してだけです。プライマリ センダーで失敗した場合、レシーバはバックアップ センダーに NACK を送信し、予期した NACK エラーを受信すると、プライマリ センダーに対して再試行します。レシーバは、プライマリ センダーが再びアクティブになるまで、両方のセンダーに交互に NACK を送信します。

事例 2.3:プライマリ センダーは、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。バックアップ センダーとレシーバは両方とも、ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。

プライマリ センダーは、バックアップ センダーをアクティブとして認識しないので、設定されているフェールオーバー猶予期間の経過後、プライマリ センダーがアクティブになります。プライマリ センダーは NACK を受信しなくても、コンテンツの最初のカルーセル パスを送信します。複数のカルーセル パスが設定されている場合は、プライマリ センダーはその後、レシーバの NACK を待ち、さらにカルーセル パスを開始します。

レシーバがプライマリ センダーまたはバックアップ センダーに NACK を送信することはありません。

条件 3:Content Distribution Manager は、ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。ACNS 5.1.x より前のソフトウェア リリースでは、1 つのマルチキャスト クラウドに設定できるセンダーは 1 つだけです。

事例 3.1:センダーは、ACNS 5.1.x リリース 以上の ACNS 5.x ソフトウェアを使用しています。レシーバは ACNS 5.1.x より前のソフトウェア リリースを使用しています。

センダーは ACNS 5.1.x ソフトウェアが稼働しているプライマリ センダーと同様に動作します。したがって、NACK がなくてもカルーセル パスを開始できるので、1 回めのコンテンツを送信します。ただし、レシーバが NACK を送信できないので、センダーがカルーセル パスを継続することはできません。

事例 3.2:センダーとレシーバの両方で、ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。

センダーはカルーセル パスを実行でき、レシーバーは欠落コンテンツに関して NACK を送信できますが、バックアップ センダーまたは NACK インターバル乗数の設定はサポートされません。

事例 3.3:センダーは ACNS 5.1.x より前の ACNS ソフトウェア リリースを使用しています。レシーバーは ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアを使用しています。

センダーはレシーバがコンテンツを取得できるように、カルーセル パスおよびマルチキャスト送信帯域幅の設定に従って、定期的にマルチキャスト ファイルを送信します。

レシーバはセンダーに対して NACK の送信を試み、失敗と再試行を繰り返します。

事例 1.1 ~ 3.3 の回避策:センダーとレシーバの両方を ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアにアップグレードします。センダーを先にアップグレードしてから、レシーバをアップグレードします。

事例 3.1 限定の回避策:

センダー Content Engine 上で distribution multicast resend EXEC コマンドを使用し、手動でマルチキャスト カルーセル パスを開始します。

センダーとレシーバの両方を ACNS 5.1.x リリース以上の ACNS 5.x ソフトウェアにアップグレードします。センダーを先にアップグレードしてから、レシーバをアップグレードします。

ACNS 5.0 ソフトウェア機能の相互運用性に関する問題

ここでは、ACNS 5.0 ソフトウェアの相互運用性の問題について説明します。

ACNS 5.0 にダウングレードした場合のメディア ファイル システムに関する問題

ACNS 5.1 以上のソフトウェアでメディア ファイル システム(mediafs)を設定し、その後、ACNS 5.0 ソフトウェアにダウングレードすると、mediafs ディスク スペースの割り当てが失われ、ACNS ネットワーク ファイル システム(cdnfs)のディスク スペースに戻ります(mediafs は、2 種類 [RTSP および WMT] のストリーミング プロトコルで取得される、オンデマンド コンテンツに使用されます。cdnfs は、ACNS ネットワークにおいて、事前配信のコンテンツに使用されます)。

この状況が発生するのは、ACNS 5.1 ソフトウェアで行われた設計変更が原因です。ACNS 5.0 ソフトウェアはこの変更に対応していないので、ディスク スペースは mediafs ではなく cdnfs に割り当てられるようになります。

この問題を回避するには、次の手順に従ってください。


ステップ 1 ACNS 5.0 ソフトウェアへのダウングレード後、CLI( disk config EXEC コマンド)または GUI を使用して、mediafs ディスク スペースを割り当てます。

Content Distribution Manager に登録されている Content Engine には、Content Distribution Manager の GUI を使用します。独立型の Content Engine(すなわち、Content Distribution Manager に登録されておらず、Content Engine の GUI または CLI を使用して管理する Content Engine)には、Content Engine の GUI を使用します。

ステップ 2 Content Engine をリブートすることにより、設定変更を有効にします。


 

ACNS 5.0 ソフトウェアまたは ACNS 5.1 ソフトウェアにダウングレードした場合の Websense に関する問題

Content Engine 上でローカル(内部)Websense サーバがイネーブルの場合に、ACNS 5.2.x ソフトウェアから ACNS 5.0 ソフトウェアまたは ACNS 5.1 ソフトウェアにダウングレードすると、Content Engine から Websense Enterprise ディレクトリが削除され、ローカル Websense サーバが機能しなくなります。ACNS 5.2.x ソフトウェアは、Websense Enterprise ディレクトリの削除を伝えるエラー メッセージを作成しないので、注意してください。

ACNS 5.2.x ソフトウェアから ACNS 5.1 または ACNS 5.0 ソフトウェアへのダウングレード時にこの問題を回避するには、次の手順に従ってください。


ステップ 1 Content Engine 上のローカル(内部)Websense サーバをディセーブルにします。

ステップ 2 Content Engine 上の Websense サービスを非アクティブにします。

ステップ 3 Content Engine に ACNS 5.1 ソフトウェアまたは ACNS 5.0 ソフトウェア ダウングレード イメージをインストールします。


 

ACNS 4.x ソフトウェアおよび ACNS 5.x ソフトウェア機能の相互運用性に関する問題

Cisco ACNS 5.x ソフトウェアでは、ACNS 4.2 ソフトウェアの機能が大幅に変更されています。ACNS 4.2 ソフトウェアと比較した ACNS 5.x ソフトウェアの変更点は、次のとおりです。

Content Distribution Manager にはコンテンツが保存されなくなりました。

コンテンツの取得と配信の方式が変更されました。

コンテンツの要求に使用される URL の形式が大きく異なります。

ルーティングとリダイレクトの処理が異なります。

旧リリースの ACNS ソフトウェアから ACNS 5.x ソフトウェアにアップグレードするには、ACNS 4.2 以上のバージョンの ACNS 4.x ソフトウェアが稼働している必要があります。ACNS 4.1.3 ソフトウェアまたはそれ以前のリリースを実行している場合は、ソフトウェアをいったん ACNS 4.2 にアップグレードしてから、ACNS 5.x ソフトウェアにアップグレードします。これにより、事前配信済みのコンテンツが確実に保持されます( 第 9 章「ACNS 4.x ソフトウェアから ACNS 5.x ソフトウェアへの移行」 を参照)。

Cache ソフトウェアまたは E-CDN ソフトウェアが動作している場合は、先に ACNS 4.2 ソフトウェアにアップグレードしてから、ACNS 5.x ソフトウェアにアップグレードします。アップグレード手順については、次の URL にアクセスし、『 Cisco ACNS Software Maintenance and Troubleshooting Guide 』をオンラインで参照してください。

http://www.cisco.com/en/US/products/sw/conntsw/ps491/prod_maintenance_guides_list.html


) Internet CDN(ICDN)ソフトウェアから ACNS ソフトウェアへのアップグレードはサポートされません



) ACNS 4.2 ソフトウェアから ACNS 5.x ソフトウェアにアップグレードすると、すべての ecdnfs ファイル システムが cdnfs ファイル システムに自動的に変更されます。ファイルは、管理者が特に削除しないかぎり、削除されません。


ACNS 5.x ソフトウェアから ACNS 4.2x ソフトウェアにダウングレードする場合の問題

Cisco ACNS 5.x ソフトウェアと ACNS 4.2 ソフトウェアでは、機能に関して大きな相違があります。ACNS 5.x リリースから ACNS 4.x リリースにダウングレードする場合の注意事項は、次のとおりです。

ダウングレード後、ACNS 5.x.x の機能は動作しません。

ACNS 5.x.x Content Engine によって取得されたコンテンツはすべて、ダウングレード後に失われます。

ダウングレードには次のファイルを使用します。

ACNS-5.x.x.x.x-TO-4.2.x-K9.bin ソフトウェア ファイル。 x は現在のバージョンに対応します。

acns4_cdm_ip.meta

このダウングレード メタ ファイルは、ACNS 4.2 Content Distribution Manager にデバイスを登録し、ダウングレード用のソフトウェア(.bin)ファイルを指示します。