Cisco Internet Streamer CDS 2.0-2.2 Software コンフィギュレーション ガイド
製品概要
製品概要
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

製品概要

概要

インジェストおよび配布

プリフェッチ インジェスト

ダイナミック インジェスト

ハイブリッド インジェスト

ライブ ストリームのインジェストおよびスプリット

配信

3-Screen Session Shifting

管理

のアーキテクチャ

製品概要

この章では、Cisco Internet StreamerContent Delivery System(CDS)の概要について説明します。この章で説明する内容は次のとおりです。

「概要」

「Content Delivery Systemのアーキテクチャ」

概要

Cisco Content Delivery System (CDS; コンテント デリバリ システム)は、相互に連携してさまざまなクライアント デバイスにマルチフォーマット コンテンツを配信する Content Delivery Application(CDA; コンテント デリバリ アプリケーション)を稼働する Content Delivery Engine(CDE; コンテント デリバリ エンジン)の分散ネットワークです。Releases 2.0-2.2でサポートされるクライアント デバイスは、Personal Computer(PC; パーソナル コンピュータ)や Personal Digital Assistant(PDA; 携帯情報端末)などの Wi-Fi 対応モバイル デバイスです。

CDS は、コンテント デリバリ ネットワーク内でコンテンツの配布を加速するさまざまなメカニズムをサポートしています。CDS は、サービス プロバイダーがエンターテイメント級のコンテンツをインジェストして加入者にストリーミングできるエンドツーエンドのソリューションを提供します。

CDS の機能は、次の 4 つの領域があります。

インジェスト

配布

配信

管理

CDS 内の各 CDE は、CDE 上で稼働している CDA が決定した 1 つ以上の機能を担当します。 表1-1 に、CDA 名とインターネット ストリーミング コンテント デリバリ システム マネージャ(CDSM)のデバイス名の関係をまとめています。

 

表1-1 CDA の機能および CDSM への マッピング

CDA 名
機能
CDSM デバイス名

インターネット ストリーマ(+ Content Acquirer)

インジェスト、配布、および配信

Service Engine(SE)

サービス ルータ

配信のクライアント要求のリダイレクト

サービス ルータ(SR)

インターネット ストリーミング コンテント デリバリ システム マネージャ

管理

CDSM

Service Engineは、Content Acquirer およびインターネット ストリーマとして、あるいはインターネット ストリーマとしてのみ機能できます。

図1-1 に CDS ネットワークの主な要素を示します。コンテンツの CDS 内でのインジェストから配布、およびクライアント デバイスまでの配信というコンテンツのフロー方法は、各コンテンツ オリジン用に定義されているコンテンツ デリバリ サービスによって規定されます。デリバリ サービスとは、Content Delivery System Manager(CDSM; コンテント デリバリ システム マネージャ)を使用して定義する設定のことであり、コンテンツをどのようにインジェストおよび配布して、どのコンテンツをクライアント デバイスへ配信するかを規定する設定パラメータから構成されます。次に主なデリバリ サービス定義パラメータのいくつかを示します。

送信元サーバ

サービス ルーティング ドメイン名

デリバリ サービスに参加するService Engine

Content Acquirer として指定されたService Engine

Content Acquirer は、各デリバリ サービス内の 1 つのService Engineでのみアクティブになります。

図1-1 Cisco CDS の概要図

 

次のセクションでは、CDS の要素について簡単に説明します。詳細については、「Content Delivery Systemのアーキテクチャ」を参照してください。

インジェストおよび配布

デリバリ サービス用の Content Acquirer として指定されているService Engineは、インジェスト デバイスです。Cisco Internet Streamer CDS Releases 2.0-2.2 は、次の方式のコンテンツ インジェストをサポートします。

プリフェッチ インジェスト

ダイナミック インジェスト

ハイブリッド インジェスト

ライブ ストリーム インジェストおよびスプリット

CDS 内でのコンテンツの配布は、使用されているインジェスト方式によって決まります。


) プリフェッチされるコンテンツの最大推奨アイテム数は、200,000 です。


プリフェッチ インジェスト

Content Acquirer は、XML フォーマットのマニフェスト ファイルの形式でバックオフィスからメタデータを受信し、ファイル内の情報を使って、Content Acquirer 上のストレージにコンテンツをプルします。コンテンツは、異なるプロトコルを使用してインジェストできます。ローカル ファイル(Service Engineにコピーされるファイル)に加え、サポートされるプロトコルは File Transfer Protocol (FTP; ファイル転送プロトコル)、Hyper Text Transfer Protocol(HTTP)、Hyper Text Transfer Protocol Security(HTTPS)、Common Internet File System(CIFS)です。その後、インジェストされたコンテンツは、コンテンツ デリバリ サービス内のすべてのService Engineに配布されます。コンテンツは、設定可能な時間が経過するまで、あるいはコンテンツ エントリがマニフェスト ファイルから削除されるまで、各Service Engineのハードディスクに格納されます。これは、 コンテンツ ピニング と呼ばれます。

マニフェスト ファイルを使用して、コンテンツのインジェスト、または事前取得されたコンテンツのストリーミングに適用する種々のポリシーを指定できます。たとえば、ポリシーでは、コンテンツの有効期限、およびユーザに対してコンテンツを使用可能にしておくタイム ウィンドウなどを設定することができます。

ダイナミック インジェスト

コンテンツは、ダイナミックに CDS にインジェストできます。ダイナミック インジェストは、クライアントから要求されたコンテンツをService Engineのインターネット ストリーマ アプリケーションがローカルのハードディスク ストレージで見つけられなかった場合にトリガーされます。コンテンツ デリバリ サービスに参加しているすべてのService Engineは、オリジン サーバから始まりクライアント要求に応じるService Engineで終端するコンテンツ配布トンネルを形成するために連携します。コンテンツがこのトンネルをフローするとき、参加しているService Engineはコンテンツのコピーをキャッシュします。同じコンテンツに対するその後の要求には、CDS ネットワークから応じます。この方式でインジェストおよび配布されたコンテンツは、クライアントから頻繁に要求がない場合には削除されます。

インターネット ストリーミング CDSM は、このインジェスト方式をマニフェスト ファイルに埋め込まれている命令によってではなく内部で管理し、ストレージを自動的に管理します。また、インターネット ストリーミング CDSM は、インジェストされたコンテンツをService Engineからダイナミックに削除する機能を提供します。コンテンツは URL によって識別されます。URL はコンテンツの削除にも使用されます。

ハイブリッド インジェスト

ハイブリット インジェスト方式は、プリフェッチ インジェスト方式とダイナミック インジェスト方式の機能を組み合わせることで、非常に優れたソリューションを提供します。マニフェスト ファイルで定義されているコンテンツに関するメタデータおよび制御情報は、コンテンツ デリバリ サービスに参加しているすべてのService Engineに伝播およびピニングされます。ただし、コンテンツはプリフェッチされません。インジェストは、コンテンツに対するユーザ要求が行われると実行されます。この方式を使用してService Engineにキャッシュされたコンテンツは、ダイナミック インジェスト方式と同じ削除ルールに従います。伝播されたメタデータは、コンテンツをストリーミングするための明示的な制御やポリシーを指定するのに使用できます。

ライブ ストリームのインジェストおよびスプリット

ライブ ストリーム インジェスト方式は、ライブ コンテンツ フィードをコンテンツ デリバリ サービスに参加するすべてのService Engineに配布し、非常に多くの視聴者へコンテンツを配信する規模にまで拡大するのに役立ちます。この方式では、インターネット ストリーマ アプリケーションのライブ ストリーム スプリット機能を利用し、コンテンツ デリバリ サービス内のすべてのService Engineに 1 対 多のスプリットを行うことでアクセスを最適化します。インターネット ストリーミング CDSM は、ライブ プログラムのストリーミングをスケジュールするのに必要なインターフェイスを提供します。高度な手法を使用して、ライブ ストリーミングのパフォーマンスを向上させます。

配信

サービス ルータは、コンテンツに対するクライアント要求を処理し、プロキシミティ、負荷、およびヘルス状態に基づいて配信に最適なService Engineを決定します。

最適なService Engineが決まると、次のメカニズムのいずれかを使ってクライアント デバイスにコンテンツを配信します。

HTTP を使用したスタティック コンテンツ ダウンロード ― ユーザに表示可能になる前に、クライアント デバイスがコンテンツをダウンロードします。

HTTP を使用したプログレッシブ コンテンツ ダウンロード ― 完全にダウンロードされる前に、コンテンツが部分的にユーザに表示されます。

HTTP、Real Time Management Protocol(RTMP)、Real Time Streaming Protocol(RTSP)、または Real time Transport Protocol(RTP)を使用したコンテンツ ストリーミング ― クライアント デバイスにコンテンツがストリーミングされ、Service Engineがフィードバックを収集してストリーミングを微調整できます。また、高度なエラーリカバリも実行できます。これはクライアント デバイスへのビデオ コンテンツのストリーミングに、非常によく使われる方式です。

表1-2 に、CDS によってサポートされるコンテンツ タイプとフォーマット、コンテンツ トランスポート プロトコル、およびクライアント タイプを示します。

 

表1-2 サポートされるコンテンツ タイプ

コンテンツ タイプ
およびフォーマット
トランスポート
プロトコル
一般的なクライアント タイプ
アクセス ネットワーク タイプ

Windows メディア
(WMA、WMV、ASF、その他)VC-1

RTP、RTSP、HTTP

PC:Windows Media Player 9、10、11
Windows Media Player 9 for Mac
Windows Pocket PC 2002/2003 を実行する PDA:Windows Media Player 9
Windows Mobile 5 を実行する PDA:Windows Media Player 10

有線
Wi-Fi
携帯電話

QuickTime(MOV)、ヒント(3GP)ファイル

RTP、RTSP、HTTP

PC:QuickTime Player、QuickTime Pro 6 または 7、RealPlayer 10 または 11(3GP のみ)、VLC player
Mac:QuickTime Player、QuickTime Pro 6 または 7、RealPlayer 10 for Mac OS X(3GP のみ)
モバイル:RealPlayer(Nokia N シリーズ電話上[3GP のみ])、PackerVideo プレーヤー

有線
Wi-Fi
携帯電話

その他のハイパーテキスト ファイルおよび画像ファイル(HTML、JPEG など)

HTTP

ブラウザおよびその他の HTTP クライアント

有線
Wi-Fi
携帯電話

MPEG(MP1、MP2、MP4)

RTP、RTSP

MPEG クライアント


) Flash Media Streaming の場合、MPEG-4 に対応しているプレーヤーは、Adobe Flash Media Player 9 Update 3、Adobe Media Player、および Adobe Air のみです。1


有線

Adobe Flash
(SWF、FLV、MP3)

RTMP、HTTP

Adobe Flash Player 9 for Windows、Mac OS、および Linux

有線
Wi-Fi
携帯電話

H.264 2

RTMP、HTTP

H.264 クライアント


) Flash Media Streaming の場合、H.264 に対応しているプレーヤーは、Adobe Flash Media Player 9 Update 3、Adobe Media Player、および Adobe Air のみです。


有線

1.リリース 2.2 では、Flash Media Streaming Engine の MPEG-4 がサポートされています。

2.リリース 2.2 では、Flash Media Streaming Engine の H.264 がサポートされています。


) Real Time Messaging Protocol(RTMP)は、Flash Media ストリーミング機能の一部で、Releases 2.0-2.2に含まれます。


3-Screen Session Shifting


) 3-Screen Session Shifting はリリース 2.2 の機能で、Windows Media Engine および Movie Streamer Engine の Real Time Streaming Protocol(RTSP)ストリーミングをサポートしています。


3-Screen Session Shifting 機能は、各種コンテンツ ストリーミング エンジンのユーザ インターフェイスを統一し、さまざまなクライアント デバイスに対するユーザ セッションの送受信動作を円滑にします。この機能により、中断した特定のデバイスのストリーミング セッションを、異なるデバイスで再開できます。3-Screen Session Shifting 機能は、クライアント検出およびフォーマット選択に役立ちます。また、TV CDS とも連動します。

3-Screen Session Shifting は、コンテンツ管理およびコード変換システムと連動する 3 つの XML ファイルとリンクした配信サービス設定で統合されており、デバイスタイプ マッピングとコンテンツ フォーマット マッピングを取得します。この機能は権限サービスと動作して、ユーザ ID を取得します。さらにユーザ ID をキーとして使用し、ユーザ セッションを保存します。

特定のユーザ セッションを、1 つのクライアント デバイスから他のデバイスへシフトする場合、登録者 ID、コンテンツ ID、最終再生時間が必要です。

サービス ルータは、セッション シフティングに対して中央集中型のセッション マネージャとして動作し、セッション データベースを維持します。セッション データベースは、オペレータが生成する XML ファイルの 3 画面マップ(Content マップ、Subscriber マップ、Profile マップ)によって伝播されます。各 XML ファイルの XML スキーマは、必要に応じて入手できます。オペレータは、配信サービス ベースでセッション シフティングを有効にできます。また、各配信サービスの TV ストリーマ IP アドレスとポートも設定できます。それ以外にも、セッション データベースを持つサービス ルータを特定する必要もあります。

Content マップは、TV CDS と Internet Streamer CDS 上で同義のコンテンツを収集します。同様に、Subscriber マップは、TV CDS と Internet Streamer CDS 間で異なる ID を使用しているユーザの関連付けに使用されます。


) Windows Media Engine の Fast Cache 機能は、セッション シフティングでサポートされていません。


3 Screen Web Service インフラストラクチャ


) リリース 2.2 では、Web ベースのプログラミング API をサポートしています。これらの API は、REpresentational State Transfer(REST)アーキテクチャに基づいています。詳細については、付録 D「Session Shifting ファイルの作成と操作」を参照してください。リリース 2.2 の場合、Web Service インフラストラクチャでサポートされているアプリケーションは、3-Screen Session Shifting のみです。


このリリースで サポートされている Web Service インフラストラクチャ機能は、次の 4 つです。

Content Manager

Subscriber Manager

Profile Manager

Stream Session Event Manager

Content Manager

Content Manager は、セッション シフティング時の 3 画面コンテンツの管理を円滑にします。コンテンツ リストは、追加時または削除時に Web Service インターフェイスに提供されます。提供されたコンテンツは、ブラウザ プラグラムを使用したり、URL を直接入力することで見ることができます。ContentList XML ファイルの スキーマは、必要に応じて入手できます。

Subscriber Manager

Subscriber Manager は、セッション シフティング時の 3 画面ユーザの管理を円滑にします。登録者リストは、追加時または削除時に Web Service インターフェイスに提供されます。提供された登録者は、ブラウザ プラグラムを使用したり、URL を直接入力することで見ることができます。SubscriberList XML ファイルの スキーマは、必要に応じて入手できます。

Profile Manager

Profile Manager は、セッション シフティング時の 異なるクライアント デバイスやプレーヤー タイプの管理を円滑にします。これは、 Capability Exchange と呼ばれます。Capability Exchange は、グループ内で、論理 URL を特定のコンテンツ フォーマットにマッピングするプロセスを参照します。プロファイル グループは、類似した特長を持つ(サポート ファイルのフォーマットや要求される解像度、帯域幅など)複数のクライアントを 1 つにまとめたものです。プロファイル リストは、追加時または削除時に Web Service インターフェイスに提供されます。提供されたプロファイルは、ブラウザ プラグラムを使用したり、URL を直接入力することで見ることができます。ProfileList XML ファイルの スキーマは、必要に応じて入手できます。

Stream Session Event Manager

Stream Session Event Manager は、特定のコンテンツと登録者のペアから最終再生時間を作成したり、復旧したりできます。StreamSessionEvent XML ファイルの スキーマは、必要に応じて入手できます。

管理

ブラウザベースのセキュアなユーザ インターフェイスであるインターネット ストリーミング CDSM は、管理者が CDS ネットワーク全体を管理および監視できる集中システム管理デバイスです。CDS 内のすべてのデバイス、Service Engineおよびサービス ルータが、インターネット ストリーミング CDSM に登録されます。

Service Engineをユーザ定義のデバイス グループに整理することができ、管理者は複数のデバイスに同時に設定の変更を適用したり、その他のグループ操作を実行したりできます。1 つのデバイスは、複数のデバイス グループに属すことができます。

またインターネット ストリーミング CDSM は、デバイス グループにソフトウェア イメージ アップグレードを適用する自動化ワークフローを提供できます。

Content Delivery Systemのアーキテクチャ

CDS は、インターネット ストリーミング CDSM、1 つ以上のService Engine、および1 つのサービス ルータで構成されます。完全な冗長性を確保するために CDS に CDSM とサービス ルータを追加する場合があります。Service Engineは、CDS 内でのコンテンツのインジェスト、コンテンツの配布、およびクライアント デバイスへのコンテンツの配信を処理します。サービス ルータは、クライアント要求を処理し、最適なService Engineにクライアントをリダイレクトします。インターネット ストリーミング CDSM は、CDS、デリバリ サービス、および CDS 内のすべてのデバイスを管理および監視します。

ここでは、次の内容について説明します。

「Service Engine」

「サービス ルータ」

「コンテント デリバリ システム マネージャ」

「復元力および冗長性」

Service Engine

各Service Engineは、Content Acquirer およびインターネット ストリーマとして、あるいは単にインターネット ストリーマとして機能できます。Service Engineのさまざまなデリバリ サービスへの割り当てに基づいて、機能をサポートする適切なセットのアプリケーションがイネーブルになります。たとえば、Content Acquirer のロールは、デリバリ サービスごとに 1 つのService Engineにのみ割り当てられます。さらに、デリバリ サービスで Content Acquirer として割り当てられたService Engineは、インターネット ストリーマの機能も兼ねます。

Content Acquirer およびインターネット ストリーマの両方のアプリケーションは、CDS 内で保管および配布の機能を持ちます。これらの機能には、次が含まれます。

コンテンツおよびメタデータの物理的なストレージの管理。コンテンツ の URL は、コンテンツの取得、削除、およびアップデートのために物理的なファイル パスに変換されます。

ダイナミックにインジェストされたコンテンツの管理および頻繁にアクセスされないコンテンツの定期的な置換。コンテンツの置換は、高度なコンテンツ置換アルゴリズムによって実行されます。このアルゴリズムでは、サイズ、アクセス頻度、およびその他の属性に応じてコンテンツに「重み」が付けられ、削除する必要があるコンテンツのリストが作成されます。

事前取得されたコンテンツのインジェスト、および同じデリバリ サービス内の他のService Engineへ配布するために行う事前取得されたコンテンツの取得。

CDS トポロジ全体およびすべてのデリバリ サービスに関する情報のメンテナンス。これには、事前取得されたコンテンツ、ダイナミック コンテンツ、およびライブ ストリーム コンテンツの配布に使用する同じデリバリ サービス内のService Engineのリストの維持も含まれます。

コンテンツ、トポロジ、およびデリバリ サービス情報に関するメタデータを保管および配布するデータベースのメンテナンス。

デリバリ サービス単位でのコンテンツの配布。デリバリ サービスごとにコンテンツのフロー パスが異なる場合があります。

Content Acquirer

すべてのデリバリ サービスには、すべてのService Engineに常駐する CDA である、Content Acquirer が必要です。Service Engineがデリバリ サービス内で Content Acquirer として指定されていると、Content Acquirer CDA がアクティブになります。Content Acquirer には、次のような機能と能力があります。

HTTP、HTTPS、FTP、または CIFS(ダイナミック インジェストがサポートしているのは HTTP のみ)を使用して、コンテンツ オリジン サーバからコンテンツをフェッチする。

コンテンツ オリジン サーバからコンテンツをインジェストするために NT LAN Manager(NTLM)認証および基本認証をサポートする。

マニフェスト ファイルおよび送信元 サーバによって返された情報に従って、事前取得された各コンテンツのメタデータを作成および配布する。

Content Acquirer は、コンテンツをインジェストしてメタデータを配布すると、メタデータのデータベース レコードを作成して、コンテンツが配布可能であることを示すマーク付けをします。他のすべてのタイプのインジェスト(ダイナミック、ハイブリッド、およびライブ ストリーム)も Content Acquirer によって処理されます。

インターネット ストリーマ

デリバリ サービスに参加しているすべてのインターネット ストリーマは、内部のルーティング モジュールによって選択された フォワーダ と呼ばれるピア インターネット ストリーマからメタデータをプルします。デリバリ サービスに参加している各インターネット ストリーマは、フォワーダ インターネット ストリーマを持ちます。Content Acquirer は、配布階層の最上位のフォワーダです。プリフェッチ インジェストの場合、デリバリ サービス内の各インターネット ストリーマがメタデータ レコードを検索し、そのフォワーダからコンテンツをフェッチします。ライブ コンテンツまたはキャッシュされたコンテンツのメタデータについては、メタデータだけが配布されます。

ライブ コンテンツおよびキャッシュされたコンテンツのメタデータに関連付けられたコンテンツは、ダイナミック インジェスト メカニズムが用いられる、指定プロトコル エンジンによってフェッチされます。事前取得されたコンテンツ以外の要求がインターネット ストリーマに届くと、プロトコル エンジン アプリケーションは、コンテンツ取得に使用できる一連のアップストリーム インターネット ストリーマに関する情報を取得します。ダイナミック インジェストの場合、インターネット ストリーマは、キャッシュ ルーティング機能を使って自らをキャッシング プロキシの階層として編成し、ネイティブ プロトコルのキャッシュ フィルを実行します。ライブ ストリーム スプリットを使用して、インターネット ストリーマをライブ ストリーミング階層に編成し、単一の着信ライブ ストリームを複数のクライアントにストリーミングします。ライブ ストリームは、外部サーバまたはインジェストされたコンテンツをソースとすることができます。Windows Media Engine、Movie Streamer Engine、および Flash Media Streaming Engine がライブ ストリーム スプリットをサポートしています。

インターネット ストリーマは、サービス コントロールを使用して、コンテンツの着信要求をフィルタリングおよび制御します。サービス ルールおよび PacketCable Multimedia(PCMM)の Quality of Service(QoS; サービス品質)コントロールは、インターネット ストリーミング CDSM のサービス コントロール オプションの下でカプセル化されている機能の一部です。

インターネット ストリーマは、同じデリバリ サービスに参加しているサービス ルータにキープアライブ情報と負荷情報を送信します。この情報は、要求を処理するのに最適なインターネット ストリーマを選択するためにサービス ルータが使用します。

インターネット ストリーマ機能は、プロトコル エンジン アプリケーションのセットとして実装されます。プロトコル エンジン アプリケーションは、次のとおりです。

Web エンジン

Windows Media Engine

Movie Streamer Engine

Flash Media Streaming Engine

Web エンジン

サービス ルータによってService Engineにリダイレクトされるすべての HTTP クライアント要求は、Web エンジンによって処理されます。Web エンジンは要求を受け取ると最善の判断を下し、要求を処理するか、またはService Engine内の別のコンポーネントに要求を転送します。Web エンジンは、HTTP を使用して、CDS にローカルに保管されているコンテンツ、またはアップストリーム プロキシや送信元サーバのコンテンツから要求に応じることができます。

Service Engineに到達するすべての HTTP クライアント要求は、サービス ルータがリダイレクトした要求、あるいは直接のプロキシ要求のいずれかである可能性があります。

Web エンジンは、コンテンツの HTTP 要求を受信すると、コンテンツを Windows Media Engine によってストリーミングする必要があるのか決定します。そうである場合は、Windows Media Engine に要求を渡し、そうでない場合は Web エンジンが要求を処理します。

ポリシー サーバの統合

ポリシー制御サーバ(サードパーティ製の PCMM 準拠システム)は、ブロードバンド ネットワーク上を配信されるマルチメディア データの帯域幅を保証します。Web エンジンは、Internet Content Adaptation Protocol(ICAP)または HTTP を使用してポリシー サーバと通信し、各クライアント セッションの QoS 属性、およびアクセスを拒否すべきかどうかを設定および監視します。

Web エンジンは、ICAP を使用して、このクライアントへの帯域予約の割り当て許可、またはアクセス拒否を決定します。ポリシー サーバは、Web ポータルが作成したクッキーおよびクライアントの IP アドレスを使用して決定を行い、それに応じて Web エンジンに応答します。

Web エンジンは、HTTP を使用して、ポリシー サーバに要求の開始とティアダウンを伝えます。帯域予約は、ダウロードが開始されたときに実行され、ダウンロードが完了すると、Web エンジンがポリシー サーバにティアダウン メッセージを送信します。

Web エンジンは、PCMM を使用してポリシー サーバとやり取りし、認証されたクライアントからのコンテンツ要求に保証帯域幅を割り当てます。PCMM 統合により、コンテンツの条件付きアクセス保護に加え、セッションに QoS を付与できるようになります。

Web エンジンは、ポリシー サーバから許可を受け取ると、URL 署名を生成し、要求された URL にそれをアペンドします。次に、その新しい URL を .asx ファイルに埋め込み、クライアントにそのファイルを返送します。このファイルは、RTSP と HTTP オプションを持つ署名 URL から構成されます。RTSP および HTTP ストリーミングの場合、Windows Media Engine は帯域幅の保証についてポリシー サーバと通信します。RTSP および HTTP ストリーミングが失敗すると、クライアント デバイスはファイルの HTTP プログレッシブ ダウンロードを開始します。Web エンジンは、HTTP プログレッシブ ダウンロード要求の QoS を処理します。

署名 URL では、セキュリティが強化されます。URL 署名の生成は、URL 署名を生成するコンポーネントと URL 署名を検証するコンポーネントとの間の共有秘密鍵をベースにします。URL 署名は、Web エンジン、Service Engineにとって外部の別のコンポーネント、または Web ポータルによって生成できます。

キャッシュ フィル動作

Web エンジンはService Engine内のストレージ機能とインターフェイスし、コンテンツが現在ローカルにあるのか、あるいはアップストリーム Service Engineまたは送信元サーバのいずれかからコンテンツをフェッチする必要があるのかを判別します。

Web エンジンは、キャッシュ フィル動作を要求するためにアップストリームService Engineと通信します。このやり取りは、HTTP ベースで行われます。このキャッシュ フィル動作はオンデマンドであり、そのためコンテンツがローカルに保管されていない場合にだけ実行されます。アップストリーム Service Engineは、階層キャッシュ ルーティング モジュールを使用してダイナミックに選択するか、インターネット ストリーミング CDSM によってスタティックに設定できます。階層キャッシュ ルータは、アライブになっており、要求に応じる準備が整い、そしてデリバリ サービスの一部となっているアップストリーム Service Engineのリストを作成します。Web エンジンがこれらのService Engineの 1 つでコンテンツを見つけられなかった場合は、コンテンツは送信元サーバから取得されます。

Web エンジンは、コンテンツがローカルに見つかった場合、あるいはキャッシュ フィル動作によって取得または保管された場合は、次の条件に基づいてコンテンツを配信します。

コンテンツの鮮度 ― 事前取得されたコンテンツの鮮度は、デリバリ サービス設定でコンテンツに対して設定されている Time to Live(TTL; 存続可能時間)値に依存します。TTL では、コンテンツの鮮度がチェックされるペースを指定します。キャッシュされたコンテンツ、つまりダイナミック インジェストまたはハイブリット インジェスト方式でインジェストされたコンテンツの鮮度に関するチェックは、RFC 2616 に準拠して Web エンジンが実行します。期限満了となったキャッシュされたコンテンツについては、ローカル コピーが削除され、新しいコンテンツがインジェストされます。

データ転送速度 ― コンテンツを送信する速度は、デリバリ単位で設定できます。デフォルトでは、LAN 帯域幅が使用されます。

コンテンツの完全性 ― 事前取得されたコンテンツは、全体として CDS 内にローカルに保管されます。キャッシュされたコンテンツの場合、コンテンツが完全でないケースは 2 つあります。

コンテンツをキャッシュするプロセスで、Web エンジンのプロセスが停止したか、Service Engineに障害が発生している。この場合、後続の要求によってキャッシュ フィルが再開されます。

別の要求によってキャッシュされているプロセス内にコンテンツが存在する。この場合、後続の要求にはキャッシュされたコンテンツから応じます。

認証

Web エンジンは、パススルー モードの認証をサポートします。これにより、送信元サーバが認証をネゴシエーションし、Web エンジンがクライアント デバイスと送信元サーバ間で要求と応答を渡します。認証が必要なコンテンツは、Service Engineによってキャッシュされません。そのため、認証されたコンテンツのすべての要求はオリジン サーバから取得されます。

サービス ルール

クライアント要求が特定のパターンに一致した場合に Web エンジンがどのように対応するかを規定するサービス ルールを設定できます。パターンとして、ドメインまたはホスト名、特定のヘッダー情報、要求の送信元 IP アドレス、または Universal Resource Identifier(URI)を指定できます。対応動作としては、要求を許可またブロックする、URL 署名を生成または検証する、ICAP 要求をポリシー サーバに送信する、または URL を再書き込みまたはリダイレクトするなどが考えられます。

Windows Media Engine

Windows Media Engine は、デジタル メディア ファイルを作成し、インターネット全体に配布および再生する一連のストリーミング ソリューションである Windows Media Technology(WMT)を使用します。WMT には、次のアプリケーションが含まれます。

Windows Media Player ― エンドユーザ アプリケーション

Windows Media Server ― サーバおよび配布アプリケーション

Windows Media Encoder ― 配布用のメディア ファイルのエンコード

Windows Media Codec ― ライブ コンテンツとオンデマンド コンテンツに適用される圧縮アルゴリズム

Windows Media Rights Manager(WMRM) ― コンテンツの暗号化とユーザ権限の管理

Windows Media Engine は Windows Media コンテンツをストリーミングし、サーバおよびプロキシの両方として機能することができます。事前取得されたコンテンツを Windows Media Player にストリーミングし、クライアント要求のプロキシとして機能し、ライブ ストリームを複数のライブ ストリームにスプリットし、リモート サーバから要求されたコンテンツをキャッシュします。

Windows Media Engine は、ローカルに保管されている、事前取得またはキャッシュされたコンテンツ用の Windows Media Server として機能します。RTSP および HTTP によって要求に応じます。Windows Media Engine は、Service Engine上のストレージ機能についてチェックしてコンテンツがローカルに保管されているかどうかを確認し、コンテンツが見つからなかった場合には Windows Media Proxy として機能します。

WMT プロキシは、Web エンジンにおけるキャッシュ フィル動作のように機能します。次の 2 つのオプションがあります。

階層キャッシング プロキシ ― Windows Media Engine は、コンテンツがローカルで見つからない場合、送信元サーバからコンテンツをプルする前にまずアップストリーム Service Engineをチェックします。

スタティック キャッシング プロキシ ― 管理者がService Engineをアップストリーム プロキシとしてスタティックに設定します。

WMT プロキシは、RTSP および HTTP 経由でストリーミング要求を受け入れて応じます。

Fast Start

Fast Start では、要求されたコンテンツのビット レートよりも高速に Windows Media Player のバッファにデータが直接提供されます。バッファが埋まると、事前取得されたコンテンツ、キャッシュされたコンテンツ、またはライブ コンテンツが、コンテンツ ストリーム フォーマットによって定義されているビット レートでストリーミングされます。Fast Start は、ダイナミックにインジェストされたコンテンツには適用されません。MMS-over-HTTP または RTSP を使用してユニキャスト ストリームに接続されている Windows Media 9 Player だけが、Fast Start を使用できます。Fast Start 機能は、ユニキャスト ストリームに接続されているクライアントだけが使用します。ライブ コンテンツの場合は、Windows Media Engine がコンテンツをバッファに数秒間保持する必要があります。このバッファは、最初に発生したクライアント要求と同じストリームを要求する後続クライアントへの Fast Start パケットに応じるために使用されます。最初のクライアントがプロセスをトリガーし、後続クライアントが Fast Start のメリットを享受します。

Fast Cache

Fast Cache により、クライアントは表示が始まる前に、本来よりもコンテンツのはるかに多くをバッファできるようになります。Fast Cache は、TCP でのみサポートされます。RTP ではサポートされません。Windows Media Engine は、ストリーム フォーマットで指定されているデータ レートよりずっと高速にコンテンツをストリーミングします。たとえば、Fast Cache を使用すると、Windows Media Engine は 128 Kbps(キロビット/秒)のストリームを 700 Kbps で送信できます。これによってクライアントは、再生品質にほとんど影響を受けることなく、さまざまなネットワーク条件に対応できるようになります。事前取得されたコンテンツまたはキャッシュされたコンテンツに対する MMS-over-HTTP 要求および RTSP 要求だけが Fast Cache をサポートします。速度は、クライアントの最大レートおよび設定された Fast Cache レートのいずれか低い方になります。

Fast Stream Start

最初にクライアントがライブ ストリームを要求する場合には、コンテンツの再生が始まるまでの待機時間が最大限になることがよくあります。ユーザの待機時間が長くなる理由は、ソースからライブ ストリームをプルするのに完全な RTSP または HTTP ネゴシエーションが必要になるからです。また、コンテンツが要求されたときに、プレーヤーのバッファを埋めるのに十分なストリーム データがエッジ Service Engineにバッファされていない場合にも遅延が起こることがあります。バッファが埋まっていないと、クライアントに送信される一部のデータが Fast Start レートではなく、リニアなストリーム レートで送信される可能性があります。Fast Stream Start を使用している場合にライブ ストリームがプライミングされたり、スケジュールしてプルされたりすると、クライアントがストリームを要求する前に、ライブ ユニキャストの送信ストリームが送信元サーバからService Engineにプルされます。ストリームの最初の要求が送出される時点で、ストリームがすでにデリバリ サービス内にあります。

ライブ ストリーム スプリット

ライブ ストリーム スプリットとは、送信元サーバからの単一のライブ ストリームをスプリットして複数のストリームにわたって共有するプロセスで、各ストリームはストリームを要求したクライアントに応じます。ストリームを要求したクライアントが接続解除した場合には、要求しているすべてのクライアントが接続解除するまで、後続の要求クライアントに対して Windows Media Engine が応じます。すでにローカルに保管されているコンテンツを使用するライブ ストリーム スプリットは、送信元サーバからのコンテンツを使用する方法より一般的に優れています。なぜなら、通常Service Engineは、要求しているクライアントにより近い場所にあり、結果として送信元サーバまでのネットワーク帯域幅が開放されるからです。

ライブ ストリーム スプリットは、設定、機能およびネットワークの制限に応じて、ユニキャストまたはマルチキャストにできます。Windows Media Engine は、次のように組み合わされた IP マルチキャストまたはユニキャスト送信により Windows Media コンテンツを受信および配信できます。

ユニキャスト(受信)とマルチキャスト(配信)

マルチキャスト(受信)とユニキャスト(配信)

ユニキャスト(受信)とユニキャスト(配信)

マルチキャスト(受信)とユニキャスト(配信)

マルチキャスト(配信)

Windows Media Engine は、マルチキャスト ストリームをクライアント デバイスに配信するために、マルチキャスト ステーションとして機能できます。ストリームのソースとしては、マルチキャスト、ユニキャスト、またはローカル ファイルのいずれも可能です。ステーションは、スケジュールしたり、継続的にしたり、あるいは一度だけ再生するようにできます。コンテンツは、ライブまたは再ブロードキャストのいずれかが可能です。Windows Media Engine は、マルチキャスト IP アドレス、ポート、TTL などのセッション情報が含まれる Windows Media Station ファイル(.nsc)を作成します。クライアントは、HTTP を使用してその .nsc ファイルを要求します。クライアントは、ファイルをダウロードするとすぐにそのファイルを解析し、マルチキャスト ストリームを受信するために Internet Group Management Protocol(IGMP; インターネット グループ管理プロトコル)参加を送信します。クライアントは、ストリームを開始および停止できますが、一時停止、早送り、あるいは巻き戻しはできません。マルチキャスト ロギングは、マルチキャスト ステーションを設定する場合の設定可能なオプションです。マルチキャスト ロギングがイネーブルになっている場合、Windows Media Player は統計情報を自動的に収集し、HTTP POST 要求方式を使ってマルチキャスト ロギング URL に送信します。統計情報の収集は、リモート サーバまたはService Engine自身のいずれかによって行うことができます。

ユニキャスト(配信)

Windows Media Engine は、要求クライアントに、ライブ ストリーム、事前取得/キャッシュされたコンテンツ、あるいはダイナミック インジェストからのコンテンツを配信するブロードキャスト パブリッシング ポイントとして機能できます。ストリームのソースとしては、マルチキャスト、ユニキャスト、またはローカル ファイルのいずれも可能です。また、複数のクライアントが同じコンテンツを要求している場合、Windows Media Engine はライブ ストリーム スプリットも実行できます。ストリームのソースが Video On Demand(VOD; ビデオ オン デマンド)ファイルであっても、TV 番組と同様のエクスペリエンスをシミュレートするのにブロードキャスト エイリアスを使用できます。クライアントは、ストリームを開始および停止できますが、一時停止、早送り、あるいは巻き戻しはできません。ブロードキャスト エイリアスが設定されている場合、クライアントは Windows Media Server として動作している Windows Media Engine に要求を送り、Windows Media Engine は着信ストリームが存在するかを確認します。着信ストリームが存在する場合は、Windows Media Engine はストリームを結合して、新しいクライアントに対してストリームをスプリットします。この要求がこのストリームに対する最初のクライアント要求であるなら、Windows Media Engine は要求を送信元サーバに送信してから、新しいクライアントに応じます。

認証

Windows Media Engine は、パススルー認証をサポートします。パススルー モードでは、次の認証メカニズムがサポートされます。

匿名

NTLM

ネゴシエーション(Kerberos)

ダイジェスト アクセス認証

パススルー認証では、送信元サーバがクライアントを認証できるように、Windows Media Engine によってクライアントと送信元サーバ間にトンネルが設定されます。

帯域幅管理

Windows Media コンテンツの帯域幅管理は、着信および発信の帯域幅、セッション ビット レート、および Fast Start 最大帯域幅を設定することによって制御できます。さらに、ライブ ストリーミングの場合は、担当のコンテンツ オリジン サーバを指定して、着信コンテンツが帯域幅チェックを超えてハイデマンドのシナリオをサポートするようにできます。Windows Media 帯域幅管理機能について、 表1-3 で説明します。

 

表1-3 帯域幅管理機能

帯域幅管理
説明

着信帯域幅

アップストリーム Service Engineまたは送信元サーバからService Engineへ着信する Windows Media コンテンツの帯域幅。

発信帯域幅

Service Engine からエンドユーザーへ Windows Media コンテンツをストリーミングするための帯域幅。

着信セッション ビット レート

送信元サーバまたはアップストリーム Service EngineからService Engineへ配信可能なセッションごとの最大ビット レート。

発信セッション ビット レート

クライアントへ配信可能なセッションごとの最大ビット レート。

着信帯域幅バイパス リスト

ブロードキャストまたはマルチキャスト ライブ コンテンツの着信帯域幅チェックをバイパスできるように指定されたホストのリスト。

Fast Start 最大帯域幅

Fast Start を使用して各プレーヤーのパケットに応じているときに、プレーヤーごとに許可される最大帯域幅。Fast Start 機能が使用する帯域幅を最初から増やしてしまうと、多くのプレーヤーが同時にストリームに接続した場合にネットワークが過負荷状態になる可能性があります。Fast Start 機能に起因するネットワーク輻輳のリスクを軽減するには、Fast Start 機能が各プレーヤーへのストリーミングに使用する帯域幅の量を制限します。

ポリシー サーバの統合

Windows Media Engine は、HTTP および RTSP を使用して、ポリシー サーバに開始、停止、一時停止のメッセージを送信します。

Movie Streamer Engine


) リリース 2.0 の Movie Streamer Engine では、ライブ ストリーミング コンテンツ、事前取得されたコンテンツ、キャッシュされたコンテンツ、およびダイナミックにキャッシュされたコンテンツは、デモの状態でした。
リリース 2.1 より、ライブ ストリーミングは完全な製品版として提供されます。事前取得されたコンテンツ、キャッシュされたコンテンツ、およびダイナミックにキャッシュされたコンテンツは、デモの状態のままです。
Movie Streamer Engine のライブ ストリーミング パフォーマンスの詳細については、リリース 2.1 のパフォーマンス情報を参照してください。


Movie Streamer Engine は、業界標準の RTP および RTSP を使用して、インターネットおよびモバイル ネットワーク経由でクライアントにヒント MPEG-4 ファイル、ヒント 3GPP ファイル、およびヒント MOV ファイルを配信するオープン ソースの標準ベースのストリーミング サーバです。ヒント ファイルには、ストリーミング サーバにストリーミング用のコンテンツをどのようにパッケージするかを指示するパケット情報が格納されたヒント トラックが含まれます。

Movie Streamer Engine は、Third Generation Partnership Project(3GPP)ストリーミング ファイル(.3gp)をサポートする RTSP ストリーミング エンジンです。3GPP のサポートにより、マルチメディア対応の携帯電話にブロードバンド モバイル ネットワーク経由でリッチ マルチメディア コンテンツを提供できます。


) Movie Streamer Engine のストリーミング性能は、ムービー ファイル フォーマットやストリーム転送タイプによって異なります。コーデック タイプには影響を受けません。Movie Streamer は、RTSP や RTP でメディア ストリームを取得できるクライアント プレーヤーであればすべてサポートします。ただし、クライアント プレーヤーは、ストリームを正確にレンダリングするための正しいコーデックを保有している必要があります。


Movie Streamer Engine は、サーバおよびプロキシの両方として機能できます。事前取得されたコンテンツまたは RTSP キャッシュされたコンテンツを RTSP クライアントにストリーミングし、クライアント要求のプロキシとして機能し、ライブ ストリームを複数のライブ ストリームにスプリットし、リモート サーバから要求されたコンテンツをキャッシュします。

RTSP 要求が Movie Streamer に着信したあとで、RTSP 要求の URI は、モバイル機能交換の結果を反映するように変更されます。Movie Streamer は、Service Engine上のストレージ機能についてチェックしてコンテンツがローカルに保管されているかどうかを確認します。コンテンツが見つからない場合、あるいは RTSP キャッシュされたコンテンツ バージョンの鮮度検証が必要な場合は、Movie Streamer が Movie Streamer プロキシとして機能します。

RTSP キャッシュされたコンテンツのバージョンを検証する場合は、Movie Streamer プロキシが送信元サーバに DESCRIBE 要求を転送し、Last-Modified-Time ヘッダーを含んだ応答を要求します。Last-Modified-Time がキャッシュされたバージョンに一致した場合は、キャッシュされたコンテンツを Movie Streamer がストリーミングします。そうでない場合は、RTSP ネゴシエーションのために、Movie Streamer プロキシが送信元サーバに要求を転送します。そのあとで、クライアント セッションとサーバ セッションが生成されます。

サーバ セッションは、コンテンツをフェッチしてローカルでキャッシュするために、送信元サーバへの接続を担当します。サーバ セッションによって、メディア キャッシュ ファイルおよびリニア ヒント ファイルが作成されます。

クライアント セッションは、ローカルにキャッシュされたファイルのクライアントへのストリーミングを担当します。

クライアント セッションとサーバ セッションは別々になっています。それは、同じ URL に対して複数のサーバ セッションを生成して、異なる開始ポイントから、またはより高速に、あるいはその両方でコンテンツをキャッシュできるようにするためです。これにより、コンテンツをフェッチするスピードが向上します。クライアント セッションは、サーバ セッションが書き込みを行っているキャッシュ コンテンツからストリーミングを開始します。

Movie Streamer プロキシは、Web エンジンおよび Windows Media Engine におけるキャッシュ フィル動作のように機能します。次の 2 つのオプションがあります。

1. 階層キャッシング プロキシ ― Movie Streamer は、ローカルでコンテンツが見つからない場合、送信元サーバからコンテンツをプルする前にまずアップストリーム Service Engineをチェックします。

2. スタティック キャッシング プロキシ ― 管理者がService Engineをアップストリーム プロキシとしてスタティックに設定します。

Movie Streamer は、キャッシングを実行できない特定の条件のために、基本的なパススルー プロキシ モードをサポートしています。このような条件の例として、Service Engineのディスク スペースに空きがなくなった場合などがありますが、これには限定されません。

転送タイプ

事前取得されたコンテンツは、非高速化方式または高速化方式で配信できます。事前取得されていないコンテンツ(プロキシ コンテンツまたはキャッシュされたコンテンツ)は、常に高速化方式で配信されます。コンテンツは、次のメカニズムのいずれかを使ってクライアント デバイスに配信されます。

Non-Accelerated ― この方式は、同時ストリーミングと全体のスループットが制限されていますが、多数の転送フォーマットに対応しています。非高速化方式は、次の転送フォーマットに対応しています。

UDP の RTP

信頼性のある UDP

TCP にインターリーブされた RTSP/RTP

Accelerated ― この方式は、UDP の RTP のみに対応しています。コンテンツは、Movie Streamer Linear Hinter によって再利用されます。Liner Hinter の処理は、管理者によって手動で開始することもできますし、コンテンツの最初の要求によってダイナミックに開始させることもできます。

処理のトリガーになった最初の要求は非高速化方式でサービスされているため、Movie Streamer Linear Hinter の処理にしばらく時間がかかる場合があります。それ以降の要求はすべて高速化方式でサービスされます。

プロキシやキャッシングにはすべて高速化方式が必要なため、プロキシやキャッシングが必要なコンテンツに対する最初のクライアント要求には遅延が生じます。

ライブ ストリーム

Movie Streamer Engine は、インターネット ストリーミング CDSM で作成したプログラムのマルチキャスト参照 URL(アナウンス URL)をサポートしています。マルチキャスト参照 URL は、http:// Service Engine IP address / Program ID .sdp という形式であり、ライブ プログラム サービスを提供している Movie Streamers によって解決されます。

QuickTime ライブには、通常トラックごとに UDP ソケット ペア(RTP と RTCP 用)があり、クライアント セッションごとに一般に 2 つのトラック(オーディオとビデオ)があります。


) ライブ スプリッティングには、次の規則が適用されます。

1. ユニキャスト ストリーミングの場合、クライアント要求は RTSP で送信する必要がある。

2. マルチキャスト ストリーミングの場合、クライアント要求は HTTP で送信する必要がある。


 

認証

Movie Streamer Engine は、次の認証モードをサポートします。

基本

ダイジェスト

URL 署名

リリース 2.2 では、Movie Streamer コンテンツの URL 署名がサポートされています。詳細については、「Flash Media Streaming」セクションに記述されている「URL 署名」を参照してください。

Flash Media Streaming Engine


) フラッシュ メディア ストリーミングは、リリース 2.1 およびリリース 2.2 の機能です。


Flash Media Streaming Engine により、CDS プラットフォームに Adobe Flash Media Server テクノロジーが組み込まれます。Flash Media Streaming Engine は、ActionScript を使用して開発した VOD(事前取得されたコンテンツ、ダイナミック インジェスト コンテンツ、またはハイブリッド インジェスト コンテンツ)やライブ ストリーミングのような Flash Media Server アプリケーションをホスティングできます。

VOD コンテンツのクライアント要求を受信すると、エッジ サービス エンジンは、次の処理を行います。

コンテンツが存在する場合、エッジ サービス エンジンは、RTMP を使用してそれをストリーミングします。

コンテンツが存在しない場合、エッジ サービス エンジンは HTTP を使用してコンテンツ元のサーバからコンテンツを取得し、RTMP でサービスします。

コンテンツ元にクライアント情報は送信されません。VOD ストリーミングでは、エッジとコンテンツ元のサーバ間にクライアントごとのコントロール接続はありません。

HTTP 要求

Flash Media Streaming は、単純な Flash Video(FLV)ファイルからより複雑な Small Web Format(SW)ファイルまで、すべての Flash アプリケーションを対象とします。サービス ルータによってサービス エンジンにリダイレクトされる SWF ファイルの HTTP クライアント要求は Web エンジンによって処理されます。Web エンジンは、HTTP を使用して、CDS にローカルに保管されているコンテンツまたは任意のアップストリーム Service Engineや送信元サーバのコンテンツから要求に応じます。詳細については、「Web エンジン」 を参照してください。

RTMP 要求

SWF ファイルは、Adobe Flash Player で実行されるコンパイル済みのアプリケーションであり、FLV ファイル、MPEG4(H.264)、または MP3 ファイルへの Real Time Media Protocol(RTMP)コールを含む場合があります。URL 要求の形式をとる RTMP コールは、サービス ルータによってサービス エンジンにルーティングされます。

Flash Media Streaming は、ポート 1935 だけで RTMP および RTMPE をサポートします。RTMPE は、Adobe のセキュアな Flash ストリーミング テクノロジーです。Flash Media Streaming では、暗号化された RTMP(RTMPE)がデフォルトで有効になっており、証明書管理を必要としないで暗号化された接続経由でストリームを送信できます。


) サービス ルータは、RTMP リダイレクションを使用して、ロードバランシングおよび復元力に基づいて決定した最適なService Engineにクライアントの Flash Player を誘導します。RTMP リダイレクションは、Adobe Flash Player 9 によってのみサポートされます。それ以前の Flash Player はすべて RTMP リダイレクションをサポートしません。



) VOD ストリームの場合、SWF ファイルのすべての RTMP コールは、次の形式にする必要があります。
rtmp://rfqdn/vod/path/foo.flv
この形式で、rfqdn はサービス ルータのルーティング ドメイン名、vod は必要なディレクトリ、および path は標準の URL 指定に準拠するコンテンツ ファイルのディレクトリ パスです。


事前取得されたコンテンツおよびキャッシュされたコンテンツについては、Flash Media Streaming Engine はポート 1935 で RTMP を使用して、CDS にローカルに保管されているコンテンツによって要求に応じます。ローカルで見つからないコンテンツについては、Flash Media Streaming Engine が Web エンジンと通信を行います。次に、Web エンジンがアップストリーム サービス エンジンと通信してキャッシュ フィル動作を要求します。「キャッシュ フィル動作」を参照してください。このやり取りでは、HTTP が使用されます。Web エンジンがコンテンツを取得するプロセスが開始されたら、Flash Media Streaming Engine は RTMP を使用してコンテンツのストリーミングを開始します。

次に説明するのは、RTMP クライアント要求のために HTTP を使用してコンテンツをキャッシングする場合の特性についてです。

1. キャッシュされたコンテンツに関しては、送信元サーバ ベースのキャッシュ検証が依然として有効です。

2. クライアント側の Web エンジン ルールは、RTMP クライアント要求についてバイパスされます。

3. 送信元サーバからの HTTP ヘッダーに "no-cache" 属性セットが含まれている場合は、コンテンツはキャッシュされず、RTMP をストリーミングするために透過的なプロキシが実行されます。

4. HTTP から RTMP への透過的なプロキシがサポートされています。引き続き HTTP プロキシ モードでコンテンツがフェッチされている間に、Flash Media Streaming Engine が RTMP ストリーミングを開始します。

コンテンツがキャッシュされない HTTP 設定では、依然として RTMP 要求を求めます。Flash Media Streaming Engine は、次のような場合に複数の HTTP ベースの範囲要求を使用します。

Flash Media Streaming プロキシ

Flash Media Streaming Engine は、送信元サーバまたはプロキシ サーバとして機能しながらコンテンツを配信できます。送信元サーバの設定またはサービス エンジンの Web エンジンの設定が原因でコンテンツをキャッシュできない場合に、Flash Media Streaming Engine はプロキシ サーバとして機能します。コンテンツのクライアント要求で HTTP または RTMP のいずれが使用された場合でも、コンテンツは HTTP を使用してインジェストおよび配布されます。

ユニキャスト ストリーミング

Flash Media Streaming Engine は、ユニキャスト フラッシュ ストリーミングをサポートします。

URL 署名


) リリース 2.2 では、Flash Media Streaming コンテンツの URL 署名がサポートされています。


Flash Media Streaming は署名された URL をサポートすることで、セキュリティを強化しました。URL 署名の生成は、URL 署名を生成するコンポーネントと URL 署名を検証するコンポーネントとの間の共有秘密鍵をベースにします。URL 署名は、サービス エンジン、Service Engineにとって外部の別のコンポーネント、または Web ポータルによって生成できます。

URL 署名の詳細については、「URL 署名の設定」を参照してください。

コーデック

リリース 2.1 でサポートされている Flash Media Streaming のコーデックは、On2 VP6 です。On2 VP6 以外に、リリース 2.2 でサポートされている Flash Media Streaming のコーデックを 表1-4 に示します。

 

表1-4 CDS リリース 2.2 でサポートされている Flash Media Streaming のコーデック

規格
説明

ISO/IEC 14496-3

AAC+、HE-AAC としても知られている MPEG-4 Part 3。AAC Main、AAC LC、SBR 同様、継続した音声信号のコーディングに対する圧縮コーデックのセットで、一部 (AAC)を拡張しています。

ISO/IEC 14496-10

H.264/AVC としても知られている Advanced Video Coding(AVC)。

すべてのアプリケーション レベル(Base [BP]、Main [MP]、High [HiP]、High 10 [Hi10P]、High 4:2:2 Profile [Hi422P])がサポートされます。

この規格は、技術的には ITU-T H.264 規格と同じです。

ISO/IEC 14496-12

ISO ベースのメディア ファイル フォーマット。1 つの音声トラック(ISO/IEC 14496-3 [AACPlus] または MP3)と 1 つのビデオ トラック(ISO/IEC 14496-10 [H.264 or AVC] または VP6)を含むメディア コンテンツを保存します。

3GPP TS 26.245

Timed Text Format 規格。

ライブ ストリーム


) Flash Media Streaming を使用したライブ ストリーミングは、リリース 2.2 の機能です。


Flash Media Streaming は、ダイナミック プロキシによる RTMPを使用して、ライブ コンテンツをストリーミングします。ライブ プログラムまたは再ブロードキャスト プログラムの設定は不要です。最初のクライアントがライブ ストリーミング コンテンツを要求すると、ストリームが作成されます。システムの負荷にもよりますが、ライブ ストリーミング数に制限はありません。ライブ ストリーミングは配信コンテンツ ルーティングを使用して、複数のサービス エンジンにストリームを配信します。

ライブ コンテンツのクライアント要求を受信すると、エッジ サービス エンジンは、次の処理を行います。

ライブ ストリーミングがすでに存在する場合、エッジ サービス エンジンはその新しいクライアントを既存のストリーミングに接続します。コンテンツ元のサーバにはメッセージを送信しません。また、接続も確立しません。

ライブ ストリーミングが存在しない場合、CDS はコンテンツ元のサーバに接続を確立し、ストリーミングを取得します。コンテンツ元にクライアント情報は送信されません。

VOD ストリーミングでは、エッジとコンテンツ元のサーバ間にクライアントごとのコントロール接続はありません。

Flash Media Streaming では、事前取得されたコンテンツ、キャッシュされたコンテンツ、ダイナミックにキャッシュされたコンテンツ、ライブ コンテンツに配信サービスを使用できます。Flash Media Streaming は、ダイナミック プロキシを使用してライブ コンテンツをストリーミングするため、コンテンツの保存にディスク容量を使用しません。Content Origin サーバとして指定されているサービス エンジンが、ライブ コンテンツをストリーミングしている配信サービスに割り当てられていない場合、ライブ コンテンツのストリーミング時に Content Origin サーバとして動作します。

アップストリームのライブ スプリッティング接続が失敗した場合、Flash Media Streaming Engine は自動的にコンテンツ元のサーバに再度接続しようとします。このフェールオーバーによって、クライアント側で新たに再試行することはありません。ビデオの再生が継続されたあと、クライアントはバッファの続きを見ます。この機能は、クライアントへストリーミングしているサービス エンジンに障害が発生した場合、フェールオーバーを実行しません。主な利点は、CDS インフラストラクチャの弾力性の強化にあります。言い換えれば、サービス エンジンに障害が発生した場合、ダウンストリームのサービス エンジンは自動的にコンテンツ元のサーバに接続します。

Adobe Flash Media Encoder は、Content Origin サーバとして動作しているすべての Adobe Flash Media Server にストリーミングを配信できます。クライアントは RFQDN を使用してライブ コンテンツを取得します。クライアントからの「ストリーム名」の要求は、最初 CDS の origin_appinst_streamname にマッピングされます。2 つの異なる配信サービスで使用されている同名の 2 つのストリームは区別されます。


) SWF ファイルのライブ コンテンツを要求するすべての RTMP は、次の形式にする必要があります。
rtmp://rfqdn/live/path/foo.flv
この形式で、rfqdn はサービス ルータのルーティング ドメイン名、live は必要なディレクトリ、および path は標準の URL の仕様に準拠するコンテンツ ファイルのディレクトリ パスです。


Flash Media Streaming は、ライブ ストリーム スプリッティングをサポートしています。ライブ ストリーム スプリッティングの詳細については、「ライブ ストリーム スプリット」を参照してください。

サービス ルータ

サービス ルータは、クライアント デバイスからの要求を調停して、要求を最適なService Engineにリダイレクトします。そして、デバイスの負荷を監視し、自動的なロード バランシングを行います。

サービス ルータは、送信元サーバの Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)のルーティングされた要求を解決する Domain Name System(DNS; ドメイン ネーム システム)コンテンツ サーバです。つまり、そのドメインのあらゆる DNS クエリーに対してサービス ルータが応答します。サービス ルータは、次の 2 つのシナリオに基づいてService Engineを選択します。

クライアントがサービス プロバイダーのネットワークに直接接続している(オンネット)。

クライアントがホーム ネットワーク外でローミングを使用している(オフネット)。

クライアントがサービス プロバイダーのネットワークに接続されている場合には、要求された FQDN、クライアントの IP アドレス、およびService Engineの即応性に基づいてService Engineが選択されます。サービス ルータは、クライアントの送信元 IP アドレスを カバレッジ ゾーン ファイル と呼ばれる、Service Engineに割り当てられているアドレス範囲のテーブルと比較します。カバレッジ ゾーン ファイルは、各クライアントの IP アドレスに基づいて、クライアントからService Engineまでのプロキシミティの情報を提供します。

クライアントがサービス プロバイダーのネットワークに接続されておらず、ロケーションベースのルーティングがイネーブルになっている場合には、そのクライアントに最も近く位置しているService Engineが選択されます。サービス ルータは、クライアントの地理的な位置を把握するためにGeolocation サーバを使用して、クライアントとService Engineの間の地理的な距離を計算します。距離に基づいて、最も近いService Engineが選択されます。

サービス ルータ ワークフロー

サービス プロバイダーのネットワークに接続されているクライアントのサービス ルータ ワークフローは、次のとおりです。

1. クライアントが、ルーティングされた FQDN の DNS クエリーをローカルの DNS サーバに送信します。

2. DNS サーバは、サービス ルータの IP アドレスを返します。

3. クライアントが、サービス ルータに HTTP要求 または RTSP 要求を発行します。

4. サービス ルータが、カバレッジ ゾーン ファイルにクライアントのサブネットを見つけた場合には、次が実行されます。

a. サービス ルータが適切なService Engineを選択し、プロトコル固有のリダイレクションを実行する。

b. クライアントが、Service Engineに HTTP要求 または RTSP 要求を発行する。

c. Service Engineがコンテンツに応じる。

サービス ルータがクライアントのサブネットをカバレッジ ゾーン ファイルで見つけられず、ロケーションベースのルーティングがイネーブルになっている場合には、次が実行されます。

a. サービス ルータがGeolocation サーバと通信し、クライアントの IP アドレスの地理的な座標を取得する。

b. クライアントとService Engine間の距離が計算され、クライアントに最も近いService Engineが選択される。

c. サービス ルータが最も近いService Engineへのプロトコル固有のリダイレクションを実行する。

d. クライアントが、Service Engineに HTTP要求 または RTSP 要求を発行する。

e. Service Engineがコンテンツに応じる。

サービス ルータがインターネット ストリーミング CDSM に登録されると、CDSM は登録されているすべてのデバイスにサービス ルータの IP アドレスを伝播します。Service Engineは、サービス ルータに定期的にキープアライブ メッセージを送信します。キープアライブ メッセージは、ディスクの状態、インターネット ストリーマ アプリケーションのイネーブルの有無、およびService Engine上のインターネット ストリーマ アプリケーションの負荷に関する情報から構成されます。サービス ルータは、ルートを生成するためにService Engineの負荷およびアベイラビリティに関する情報を使用します。

サービス ルータのフェールオーバーをサポートするために、インターネット ストリーマ CDS には複数のサービス ルータを含めることができます。フェールオーバーに従って、同じルーティングされた FQDN に対して複数のサービス ルータがあるように DNS サーバを設定する必要があります。


) すべての FQDN の DNS エントリをサービス ルータに委任する必要があります。DNS サーバのデータベース ファイルで、サービス ルータにルーティングされる FQDN ごとにネーム サーバ レコードを入力する必要があります。


カバレッジ ゾーン ファイル

Service Engineは、インターネット ストリーミング CDSM に登録される時点でデフォルトのカバレッジ ゾーン ファイルが割り当てられます。CDSM がService Engineのインターフェイス IP アドレスを使用してこのファイルを作成します。デフォルトのカバレッジ ゾーン ファイルを割り当てずに、カバレッジ ゾーン ファイルを使ってカスタム カバレッジ ゾーンを作成できます。

カバレッジ ゾーン ファイルは、各クライアントの IP アドレス範囲のカバレッジ ゾーン エントリ、その範囲に対応するService Engine、Service Engineの緯度と経度、およびメトリック値が含まれる XML ファイルです。カバレッジ ゾーン ファイルは URL による参照が可能であり、インターネット ストリーミング CDSM へインポートしたりローカル マシンからアップロードしたりできます。カバレッジ ゾーン ファイルは、特定のサービス ルータのデフォルト、または CDS ネットワーク内のすべてのサービス ルータのデフォルトとして設定できます。

クライアントがコンテンツを要求すると、サービス ルータはクライアントの IP アドレスをチェックして、その IP アドレスが含まれるカバレッジ ゾーンを見つけます。次にサービス ルータが、このカバレッジ ゾーンに応じるService Engineを選択します。特定の IP アドレスが複数のカバレッジ ゾーンに存在する場合は、より範囲が明確なものが選択されます。カバレッジ ゾーン データで一致が見つからず、サービス ルータでロケーション ベースのルーティングがイネーブルになっている場合には、サービス ルータがクライアントに最も近い最適なService Engineを検索します。サービス ルータが要求をリダイレクトできない場合には、サービス ルータがクライアントにエラー応答を送信します。

カバレッジ ゾーンは、1 つ以上のService Engineに関連付けられます。各Service Engineは、独自のカバレッジ ゾーンを持つか、またはService Engineが複数のカバレッジ ゾーンに関連付けられて、重複したカバレッジ ゾーンを持つことができます。図1-2では、すべてのService Engineがカバレッジ ゾーン 1 に応じ、Service Engine 1 がカバレッジ ゾーン 1 のサブセットであるカバレッジ ゾーン 2 に特定的に関連付けられています。

図1-2 カバレッジ ゾーンの例

 

複数のService Engineが 1 つのカバレッジ ゾーンに応じている場合には、すべてのService Engineがルーティング テーブルに格納されます。カバレッジ ゾーン ファイルに含まれるメトリック値は、クライアントとService Engineのプロキシミティを示します。1 つのカバレッジ ゾーンに応じる複数のService Engineが同じサブネット上にあり、同じメトリック値を持ち、負荷ベースのルーティングがイネーブルになっていない場合、サービス ルータはラウンドロビン ルーティングを使用してクライアントをリダイレクトします。負荷ベースのルーティングがイネーブルになっている場合は、Service Engineの負荷を使用して、クライアントをリダイレクトするのに最適なService Engineが決定されます。

ルーティング方式

サービス ルータは、最適なサービス エンジンを選択します。これは、送信元サーバと要求されたドメインのサービス エンジンと一致するデリバリ サービスに、Service Engineが参加しているかどうか、そしてクライアントのネットワーク領域に応じるようにService Engineが割り当てられているかどうかに基づきService Engineます。

サービス ルータは、次の 4 つの方式を使用します。

簡素化されたハイブリッド ルーティング(ラウンドロビン ベースのルーティング)

負荷ベースのルーティング(負荷が最も少ないもの)

ラストリゾート ルーティング(すべてのService Engineに過負荷がかかる)

ロケーション ベースのルーティング(オフネット クライアント)

サービス アウェア ルーティング

コンテンツ ベース ルーティング


) リリース 2.2 では、サービス ルータとサービス エンジン間のキープアライブ メッセージが 2323 ポートで送受信されます。ただし、リリース 2.2 ソフトウェアは、キープアライブ メッセージに 2323 ポートを使用しない旧リリースのソフトウェアとも連動します。ファイアウォールがサービス エンジンとサービス ルータ間に設定されている場合、2323/UDP ポートは、キープアライブ メッセージを通すためにオープンにしておく必要があります。


簡素化されたハイブリッド ルーティング

サービス ルータは、簡素化されたハイブリッド ルーティングを使用して要求をService Engineにルーティングします。簡素化されたハイブリッド ルーティングでは、複数のService Engineがクライアント ネットワーク領域に応じている場合は、ラウンドロビン方式でService Engineが選択されます。

負荷ベースのルーティング


) これは、リリース 2.0 およびリリース 2.1 の機能です。


負荷ベースのルーティングがイネーブルになっている場合は、ラウンドロビン方式でService Engineを選択するのではなく、Service Engineのキャパシティおよび負荷に応じてルーティングを決定します。デフォルトでは、このルーティング方式がイネーブルになっています。

Service Engineの負荷は、プロセッサ使用、メモリの使用状況、ディスクの使用状況、現時点で応じられている Windows Media ストリームの数などのさまざまなパラメータによって決定されます。現在の負荷は、Service Engineに設定されているしきい値と比較されます。しきい値を超えると、Service Engineはルーティング テーブルから除外されます。

ラストリゾート ルーティング

ラストリゾート ルーティングを適用できるのは、負荷ベースのルーティングがイネーブルになっているときに、すべてのService Engineがしきい値を超えるか、ドメインのすべてのService Engineがオフラインになっている場合です。サービス ルータは、クライアント ネットワーク領域に応じているすべてのService Engineが過負荷である場合に、設定可能な代替のドメインに要求をリダイレクトできます。

ラストリゾート ルーティングは、Service Engineが過負荷または無効になったときにダイナミックに機能します。オリジナル ホスト ドメインの 1 つ以上のService Engineの負荷がしきい値を下回った場合、あるいはService Engineが再度アクティブになった場合には、新しい要求がオリジナルのホスト ドメインに自動的にルーティングされます。

ラストリゾート ドメインが設定されていない場合に、サービス エンジンのしきい値を超えると、要求は送信元サーバにリダイレクトされます。

ラストリゾート ルーティングは、MMS-over-HTTP など、RTSP クライアントおよび HTTP クライアントからの要求をサポートします。

ロケーションベースのルーティング

ロケーション ベースのルーティングは、オフネット クライアントに使用されます。オフネット クライアントは、サービス プロバイダーのネットワークに直接接続されていないクライアントです。ロケーション ベースのルーティングは、負荷ベースのルーティングと連携するように設計されています。両方がイネーブルになっていると、サービス ルータは、まずカバレッジ ゾーン ファイルでクライアントの IP アドレスを検索します。サブネットの一致がない場合は、クライアントの地理的なロケーションがカバレッジ ゾーン ファイルにリストされているService Engineの地理的なロケーションと比較され、最も近くにあり、最も負荷が少ないService Engineが選択されます。クライアントの地理上の検索は、ユーザがホーム ネットワークの外でローミングを使用しているときに使用されます。

サービス ルータは、オフネット クライアントにルーティングを提供するために、IPアドレスを地理的なロケーションにマッピングする Geolocation サーバと通信します。冗長性を確保するために、プライマリとセカンダリの Geolocation サーバを使用するようにインターネット ストリーミング CDSM を設定できます。

Geolocation サーバは、オフネット クライアントの緯度と経度によってクライアントの地理的なロケーションを特定します。サービス ルータは、デリバリ サービスに参加しているService Engineのロケーションとクライアントのロケーションを比較し、コンテンツに応じるのに最適なService Engineを選択します。

サービス アウェア ルーティング


) これはリリース 2.2 の機能です。サービス アウェア ルーティングは常に有効になっており、設定を変更することはできません。


サービス アウェア ルーティングは、サービス エンジンへ要求をリダイレクトします。サービス エンジンは、サービス ルータが、必要なプロトコル エンジンに対応しており、その必要なプロトコル エンジンが正常に機能し、自身で設定したしきい値を越えていない必要があります。詳細については、「サービス モニタしきい値の設定」 を参照してください。

要求がサービス ルータに到達すると、サービス ルータは URI からハッシュを生成します。最初に、サービス ルータはサービス アウェア ルーティングに基づき、その要求のサービスに最適なサービス エンジンのリストを生成します。次に、サービス ルータ はハッシュに基づいてリストの順番を再編し、最適なサービス エンジンを選択します。同じ URI で生成されたハッシュは等しいため、通常は同じサービス エンジンが選択されます。サービス エンジンが過負荷の状態である場合、リスト内で次のサービス エンジンが選択されます。


) サービス アウェア ルーティングの場合、サービス エンジンで実行されている一部のサービスはプロトコル ベースです。プロトコル エンジンに関連付けられたプロトコル ベースのサービスがサービス エンジンで停止すると、サービス ルータは、そのコンテンツ タイプの要求をサービスできる可能性があるサービス エンジン リストから、そのサービス エンジンを除外します。サービス ルータは、要求のユーザ エージェントに基づいて、要求をサービスするプロトコル エンジンを特定します。たとえば、ある Windows Media Engine 関連のサービスが停止した場合でも、サービス エンジンは Web エンジンの要求を続けてサービスできます。ただし、Web エンジン コンテンツの要求が Windows Media Player から送信されている場合、サービス ルータは、その要求をサービスできる可能性があるサービス エンジン リストから、そのサービス エンジンを除外します。



) サービス アウェア ルーティングでは、すべてのサービス エンジンのしきい値を超えた場合、サービス エンジンはクライアント要求を Content Origin サーバにリダイレクトします(代替ドメインが設定されていない場合)。代替ドメインが設定されている場合、代替ドメインが優先します。管理ライブ URL では、Content Origin サーバがライブ プログラムの配信元と一致しない場合、それ以上のことは実行されません。それ以上のことを実行する場合、Content Origin サーバのホストを設定し、ライブ プログラムの配信元と一致させる必要があります。さらに、Content Origin サーバのストリーム名をライブ プログラム名と同一にする必要があります。


コンテンツ ベース ルーティング


) これはリリース 2.2 の機能です。


コンテンツ ベース ルーティングの場合、サービス ルータは URI に基づいて要求をリダイレクトします。サービス エンジンのしきい値内であれば、同じ URI の要求は、同じサービス エンジンへリダイレクトされます。

コンテンツの冗長コピー数は、コンテンツ ベース ルーティングで設定できます。冗長コピー数が複数に設定されていれば、複数のサービス エンジンに同じコンテンツを保存できます。冗長性をもたせることで、キャッシュのヒット率を最大限活用できます。冗長コピー数を複数に設定すると、同じ URI ハッシュの要求に複数のサービス エンジンが抽出されます。

コンテンツ ベース ルーティングはヒット率を最大限活用できるため、キャッシュ、事前取得、およびライブ プログラムの要求に適しています。

要求のリダイレクション

サービス ルータは、次のリダイレクションをサポートします。

HTTP ASX リダイレクション

要求ファイルが .asx 拡張子を持つ場合に使用します。このリダイレクション方式は、Windows Media テクノロジーに使用します。

HTTP 302 リダイレクション

プロトコルが HTTP で、ファイル拡張子が .asx でない場合に使用します。これは、ネイティブの HTTP リダイレクションです。

RTSP 302 リダイレクション

プロトコルが RTSP で、クライアントが QuickTime または Windows Media の場合に使用します。これは、ネイティブの RTSP リダイレクションです。

RTMP 302 リダイレクション

プロトコルが RTMP で、クライアントが Adobe Flash Player、Adobe Media Play、または Adobe Flash Lite Player の場合に使用します。

コンテント デリバリ システム マネージャ

インターネット ストリーミング CDSM は、ブラウザベースのユーザ インターフェイスです。管理者は、インターネット ストリーミング CDSM を使用して、デリバリ サービスおよびシスコ コンテント デリバリ システム(CDS)内のデバイスを設定、管理、監視できます。インターネット ストリーミング CDSM とのバックオフィス統合用の Application Programming Interface(API; アプリケーション プログラミング インターフェイス)が提供されます。

Authentication, Authorization, and Accounting(AAA; 認証、認可、アカウンティング)

インターネット ストリーミング CDSM では、HTTPS を使用して管理者のセッションを保護します。インターネット ストリーミング CDSM を使用することにより、複数のユーザが管理操作を実行できます。管理者は、特定のユーザが CDS を監視するための表示のみ権限、または監視機能に加えて設定変更が可能な全権限のいずれかを持つように設定できます。

ユーザ アカウントおよびユーザ グループをインターネット ストリーミング CDSM に追加して、設定情報へアクセスするロールおよび権限を付与できます。また、オブジェクトを分離またはグループ化して、限られたユーザ グループにアクセス権を付与することも可能です。

使用可能なら、Remote Authentication Dial-In User Service(RADIUS)サーバを使用するようにユーザ認証を設定できます。そうでない場合は、インターネット ストリーミング CDSM が独自の認証サーバを提供します。

CDS 全体のポリシーおよびステータス情報が、インターネット ストリーミング CDSM 上のリレーショナル データベースに保持されます。この情報は、CDS ネットワークのすべてのデバイに伝播されて同期されます。

ネットワーク管理プロセスの一環として、管理者はバックアップおよび復元などの基本的な管理操作をインターネット ストリーミング CDSM データベース上で実行できます。

デバイス マネジメント

インターネット ストリーミング CDSM は、変更が送信された時点で、選択したデバイスまたはデバイス グループにデバイスの設定変更を送信できます。デバイスは、CDSM に対してローカルで行われた設定変更を送信することも、定期的なステータス情報を提供することもできます。

デバイスをユーザ定義のデバイス グループにまとめ、管理者が複数のデバイスに同時に設定の変更を適用したり、その他のグループ操作を実行したりできます。各デバイスは複数のデバイス グループに属すことができるので、これにより管理者の管理オーバヘッドが軽減されます。デバイス グループよって管理のインスタンスを 1 つにできるので、各デバイスに同じ手順を繰り返す必要がなくなります。

またインターネット ストリーミング CDSM は、デバイス グループのデバイスにソフトウェア アップグレードを適用する自動化ワークフローを提供できます。

CDS における高度なストレージの活用方法

ストレージが複数のサービス エンジンに渡る場合は、個々のサービス エンジンのサービスが全体のコンテンツの一部のみですむように仮想的に分割されます。サービス エンジンのローカル ストレージや RAM は、配信サービスを集約する役割を果たします。1 つの場所により多くのサービス エンジンを追加することで、CDS ストレージのリニア スケーラビリティを確保できます。これにより、サービス エンジンに関連した「ロングテール」の使用例の要求にも対応できます。ロングテールは、多くの小規模の市場を合計すると、少数の大規模な市場に匹敵するか、それ以上の価値があるという理論です。ロングテール配信は、トラフィックの発生頻度が極端に低いものでも期待以上の結果をもたらす場合があります。

ストレージをより活用すると、次のような利点があります。

全体のシステム パフォーマンスの向上

メモリ キャッシュのヒット率の向上

人気の高いコンテンツに障害や高負荷が発生した場合に確実に対応できる。カスタマーの 1 つのサービス エンジンに、4.5 TB 以上のライブ コンテンツ、事前取得されたコンテンツ、キャッシュされたコンテンツがある場合に効果的です。

コンテンツ配信が弾力性を持ち、ステートレスになります。1 つのサービス エンジンへマップされたすべてのコンテンツの負荷が増加した場合、管理者が作業しなくても自動的に他のサービス エンジンへその負荷が分散されます。

デリバリ サービス管理

インターネット ストリーミング CDSM では、デリバリ サービスの設定および監視が提供され、それによりコンテンツのインジェスト、保管、キャッシュ、および公開方法が定義されます。インターネット ストリーミング CDSM は、Service Engineにデリバリ サービスに関する情報と、どのService Engineがデリバリ サービスに参加しているかについての情報を提供します。

デリバリ サービスを定義するには、インターネット ストリーミング CDSM の使用に加え、 マニフェスト ファイル と呼ばれる XML ファイルも使用できます。マニフェスト ファイルと API は、バックオフィス統合の基盤として役立ちます。マニフェスト ファイルの詳細については、「マニフェスト ファイル」を参照してください。

復元力および冗長性

完全な冗長性を備え、シングル ポイント障害が排除されるように設計された CDS には、冗長性のあるインターネット ストリーミング CDSM とサービス ルータが含まれます。Service Engine上で実行される Content Acquirer とインターネット ストリーマ アプリケーションの冗長性のメカニズムは異なる動きをします。

Content Acquirer の冗長性

Content Acquirerでプライマリ障害が発生すると、フェールオーバー メカニズムによりバックアップ Content Acquirer の選出がサポートされます。フェールオーバーでは、プライマリとバックアップの両方の Content Acquirer がデリバリ サービスのルート ロケーションに存在している必要があります。

ライブ プログラム

Content Acquirer が送信元サーバからマルチキャスト ストリームとしてライブ プログラムを受信する場合、プライマリに障害が発生すると、バックアップ Content Acquirerがすぐにそのプログラムのストリーミングのコントロールを引き継ぎ、プログラムは中断することなく続行されます。このプロセスは、エンドユーザには透過的なものです。プライマリ Content Acquirer がオンラインに戻ると、アクティブなセカンダリ Content Acquirer からライブ ストリームを受信し、ライブ プログラムが終了するか再開されるまでは、フォール バック(プライマリ ステータスの回復)しません。

Content Acquirer が送信元サーバからユニキャスト ストリームとしてプログラムを受信した場合には、フェールオーバー メカニズムはサポートされません。プログラムの再生中にプライマリ Content Acquirer に障害が発生した場合は、そのプログラムを表示していたユーザがそのプログラムを再要求する必要があります。

インターネット ストリーマの冗長性

インターネット ストリーマ アプリケーションを実行していた Service Engine に障害が発生すると、サービス ルータは、Service Engine からのキープアライブ メッセージの受信を停止します。新しい要求が着信すると、サービス ルータは要求をそのService Engineにはリダイレクトせず、同じデリバリ サービス内の別のService Engineにリダイレクトします。障害のあったService Engine上の既存のセッションはすべて終了し、影響を受けるエンドユーザはコンテンツを再要求する必要があります。

サービス ルータの冗長性

CDS ネットワークが、複数のサービス ルータを使用するように設計されている場合、すべてのサービス ルータが CDS 内のすべてのService Engineを認識します。DNS サーバは複数のサービス ルータを使用するように設定する必要があり、フェールオーバーは DNS サーバによって処理されます。

インターネット ストリーミング CDSM の冗長性

インターネット ストリーミング CDSM は、2 つの別々のロール(プライマリとスタンバイ)で動作します。プライマリ ロールがデフォルトです。CDS ネットワークではプライマリを 1 つのみアクティブにできますが、任意の数のインターネット ストリーミング CDSM をスタンバイとして稼働して、冗長性およびフェールオーバーの機能を実現できます。

プライマリとスタンバイ CDSM は、同じバージョンのソフトウェアを実行する必要があります。最初にスタンバイ CDSM をアップグレードしてから、プライマリ CDSM をアップグレードすることを推奨します。

インターネット ストリーミング CDSM 設計の基本方針では、管理デバイスはサービス デリバリ パスには決して置きません。CDSM に障害が発生しても、残りの CDS は稼働を続行できます。エンドユーザに配信されるサービスはどれも CDSM の障害の影響を受けずに、すべてのコンテンツのインジェストが続行されます。唯一のマイナスの影響は、管理者が設定を変更できない、または CDS を監視できないことです。CDSM への接続に障害があることに気付いたら、管理者はすぐにスタンバイ CDSM をアクティブにできます。スタンバイ CDSM をプライマリ CDSM にする方法については、「スタンバイ CDSM からプライマリ CDSM への変更」を参照してください。