この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco TV CDS のさまざまなネットワーク トポロジ、CDS サーバのさまざまなネットワーク接続、CDS ワーク フロー、およびネットワーク設定の考慮事項について説明します。この章で説明する内容は、次のとおりです。
• 「概要」
TV CDS により、ケーブル オペレータおよびマルチプル サービス オペレータ(MSO)は、既存の次世代のデジタル STB で既存の光ファイバ/同軸ハイブリッド(HFC)ネットワーク上のコンシューマ カスタマーに VOD および MediaX サービスを提供できるようになります。TV CDS ソリューションは、ヘッドエンドから HFC ネットワークが終端する配線ハブまでギガビット イーサネット(GE)転送ネットワークを使用します。
TV CDS は単一のサーバ実装から複数のサーバまでシームレスに拡大します。拡大の継続にともなって、TV CDS ではオペレータがコンテンツの取り込みと管理を集中化したままで、サブスクライバの集中に対処するために分散サーバを設置できます。
Stream Group は Cisco Cache Control Protocol(CCP)経由でサブスクライバの近くに分散され、中央の Vault の場所にリンクを戻すことができます。Cisco CCP は自動的にカスタマー エッジ デバイスで要求された新しいコンテンツを、最大 250 ミリ秒の遅延内で適切なエッジの場所に確実に転送します。その結果、ほとんどのコンテンツが中央の Vault の場所に格納されていても、すべてのコンテンツが各エッジ サイトにローカルに見えます。
TV CDS は、ネットワーク トポロジ、ビジネス管理システム(BMS)、およびストリーミング モードに関してさまざまな設定を提供します。
Vault および Streamer を使用する TV CDS では、MPEG-2 トランスポート ストリーム(TS)ビデオは、関連付けられたトリックモード ファイルとともに Vault に保存されます。コンテンツは、ギガビット イーサネット ネットワーク上の CCP を使用して、必要に応じて Vault から Streamer に転送されます。コンテンツは Streamer からユニキャスト送信されてギガビット イーサネットまたは非同期シリアル インターフェイス(ASI)上の直交振幅変調(QAM)デバイスに配信され、次に HFC プラントで変調されてサブスクライバ セットトップ ボックス(STB)で表示されます。
小規模ネットワーク用として、シスコでは CDS を単一サーバにパッケージする Integrated Streamer-Vault(ISV)により、コンテンツ ライブラリは大きいが、ストリーム数は小さい VOD サービスに対するソリューションを提供します。
ISV を使用する TV CDS では、MPEG-2 TS ビデオは、関連付けられたトリックモードファイルとともに ISV サーバに保存されます。コンテンツはギガビット イーサネット ネットワーク上で ISV からユニキャスト送信されて QAM デバイスに配信され、HFC プラントで変調されてサブスクライバ STB で表示されます。
大規模ネットワーク用として、シスコでは仮想ビデオ インフラストラクチャ(VVI)で Caching Node を使用する CDS を提供します。VVI では、Caching Node が Streamer の仲介フィル ソースとなるため、Vault から分散トラフィックの大部分が取り除かれます。
TV VVI では、MPEG-2 TS ビデオは、関連付けられたトリックモード ファイルとともに Vault に保存されます。コンテンツは、ギガビット イーサネット ネットワーク上の CCP を使用して必要に応じて Vault から Caching Node に転送されます。コンテンツは、ギガビット イーサネット ネットワーク上の CCP を使用して、またはギガビット イーサネット ネットワーク上の HTTP を使用して、必要に応じて Caching Node から Streamer に配信されます。コンテンツはギガビット イーサネット ネットワーク上で Streamer からユニキャスト送信されて QAM デバイスに配信され、次に HFC プラントで変調されてサブスクライバ STB で表示されます。
TV CDS(Vault および Streamer、または ISV を使用する)および TV VVI(Vault、Caching Node、および Streamer を使用する)では、集中型、非集中型、およびハイブリッド ギガビット イーサネット ネットワーク設計をサポートします。Vault と Streamer の使用により、ストレージがストリーミングから分離されるため、ストリーミング要件は必要に応じて満たすことができ、またストリーミングは複数の場所間で集中化または分散化できます。Caching Node により、コンテンツの取り込みおよび保存がコンテンツの配信から分離されるため、柔軟性とネットワーク効率が高くなります。
TV CDS トポロジと TV VVI トポロジは、システム オペレータの発展するニーズに合わせて変更できます。非集中化の必要性が明確になった場合、サービスを中断することなく Streamer または Vault をリモート ハブに移動できます。VVI では、ネットワーク設計にさらなる柔軟性を提供します。Vault は国内ネットワークの中央に配置することができ、また使用する AMS または BMS に応じてコンテンツを市場(市、州、またはより広い地域)別に分類できます。Caching Node は中央に配置できます。または、Streamer の配置された地域ネットワーク付近に分散できます。ネットワーク設計で Caching Node を使用すると、ネットワーク バックボーンから分散トラフィックが取り除かれます。
(注) 1 台のサーバが Vault および Streamer 機能を持つ ISV を使用するときは、可能なトポロジのみが集中化されます。
集中型トポロジでは、Vault および Streamer サーバの両方が、単一のビデオ ヘッドエンドまたはリモート ハブのいずれかに配置されます。これは、非常に小さな起動システムや大量の帯域幅を使用できる場合などの特定の状況では適切なソリューションです。集中型トポロジには、1 箇所の物理的な場所に装置を配置することで、運用コストを削減する利点があります。図 6-1 に、Vault と Streamer の集中型トポロジについて説明します。
図 6-1 Vault と Streamer を使用する集中型トポロジ
図 6-2 に、ISV の集中型トポロジについて説明します。
図 6-3 に、VVI の集中型トポロジについて説明します。
図 6-3 Caching Node を使用する集中型トポロジ
非集中型トポロジは、ヘッドエンド サイトと複数のハブ サイト間のハブ アンド スポーク トポロジです。Vault サーバはヘッドエンドに配置され、Streamer サーバはハブ サイトにあります。VVI の場合、非集中型トポロジでは、Vault はヘッドエンドに配置され、Caching Node は中間サイトに、また Streamer はハブ サイトに配置される 3 段のアプローチを提供します。非集中型トポロジは、サブスクライバの近くの Streamer Group 分散で適切に機能します。非集中型トポロジには、必要となる長距離ファイバ転送帯域幅の量を通常 10 分の 1 以下に減らす利点があります。図 6-4 に、非集中型トポロジについて説明します。
図 6-5 に、Caching Node を使用する非集中型トポロジについて説明します。
ハイブリッド トポロジでは、Vault サーバとバックアップ Streamer サーバはヘッドエンドに配置され、アクティブ Streamer はリモート ハブ サイトにあります。リモート ハブ サイトがダウンすると、ヘッドエンドにある Streamer が引き継ぎます。ハイブリッド トポロジは、実装されているシステムのニーズに基づいて、集中型および非集中型トポロジの利点を混ぜ合わせます。図 6-6 に、ハイブリッド トポロジについて説明します。
図 6-7 に、Caching Node を使用するハイブリッド トポロジについて説明します。
図 6-7 Caching Node を使用するハイブリッド トポロジ
TV VVI では、集中および分割ドメインの 2 種類の管理が提供されます。
CDS では、Streamer は他のグループの Streamer と通信できません。VVI では、他のグループの Streamer 同士は必要に応じて互いに通信できます。
すべての Vault、Streamer および Caching Node はアレイ ID、グループ ID とサーバ ID で識別されます。CDSM GUI では、アレイ ID は、同じシステムの一部であるサーバを識別します。グループ ID は、同じグループ(Vault Group、Cache Group、および Stream Group)の一部であるサーバを識別します。また、サーバ ID はサーバを識別する一意の番号です。 表 6-1 に、CDSM GUI ID の名前と、setupfile および .arroyorc ファイル内の CServer 名とのマッピングを示します。
|
|
---|---|
(注) VVI は、RTSP 環境、ならびに Shared Content Store 機能および CCP Streamer を使用する ISA 環境で使用できます。
集中管理では、1 つの Virtual Video Infrastructure Manager(VVIM)を使用して、VVI の Vault、Caching Node、および Streamer を管理します。
分割ドメイン管理では、1 つの VVIM を使用して Vault および Caching Node のドメインを管理し、別のマネージャである Stream Manager を使用して Streamer の各ドメインを管理します。Stream Manager はポート 80 経由で VVIM と通信します。ポート 80 が通信のために開いていない場合、マネージャは相互に通信できず、設定を VVIM からダウンロードされた情報から Stream Manager にアップロードする必要があります。
Caching Node と Streamer 間の通信に HTTP を使用する Split-Domain VVI、および RTSP 環境で CCP を使用する Split-Domain VVI では、各ドメインのデータベースは別々です。各データベースに保存されている情報は、他のドメインのサーバと共有されません。
Caching Node と Streamer 間の通信に CCP を使用する Split-Domain VVI のある ISA 環境では、データベースが Vault/Cache ドメインと Stream ドメイン内のすべてのサーバ間で複製されます。VVI では、CCP Streamer を使用する場合に異なる Cache Group と Stream Group 間の相互通信が可能なため、サーバ ID およびグループ ID はシステム全体で一意である必要があります。
(注) 分割ドメイン管理は、Shared Content Store 機能および CCP Streamer を使用する RTSP 環境および ISA 環境でサポートされます。
コンテンツは Vault アレイに取り込まれて保存されます。Vault アレイは 2 つ以上の Vault Group で構成され、さらに Vault Group はイーサネット ネットワークの複数の場所にわたって共存または分散されている 2 つ以上の Vault で構成されます。コンテンツの取り込みは、サブスクライバ要求に基づいて、また、スケジュールまたは barker チャネル コンテンツに基づいて、バックオフィスによって開始されます。オペレータが開始する手動取り込み機能もオプションとして提供されています。
(注) リリース 2.2.1 では、30 GB の大きさのコンテンツ ファイルの取り込み、トリックプレイ作成、およびストリーミングをサポートするための DVD アセットとビデオ アセットを区別する機能をサポートします。コンテンツ ファイルは、複数の日にまたがることができます。
コンテンツが Vault に取り込まれると、必要なトリックモード ファイルが作成されます。次に、コンテンツおよびトリックモード ファイルは、同じ Vault 内または Vault アレイ全体にミラーリングされます。コンテンツの複製は、Vault に障害が発生した場合のデータ リカバリを可能にします。
コンテンツは、サブスクライバの VOD コンテンツの要求を満たすための Streamer からのキャッシュフィル コールへの応答として、Vault アレイから Streamer アレイに配信されます。また、コンテンツは、スケジュールされたまたは barker ストリーム コンテンツの実行への応答としてネットワーク全体に配信されます。
VVI が導入されると、コンテンツは Streamer からのキャッシュフィル コールへの応答として Vault Group から Cache Group に配信されます。Caching Node については、「Caching Node のワーク フロー」 で詳しく説明します。
Streamer アレイ内には、1 つ以上の Stream Group があります。この項では、Stream Group がサブスクライバ STB にストリームを配信する方法について説明します。
(注) すべてのサーバを異なるサブネットワークに配置することができます。ただし、バックオフィスの制限により、外部化された IP アドレスは同じサブネットワークにあるサーバ間で移行するように制限されます。これはインタラクティブ サービス アーキテクチャ(ISA)環境のコンテンツ ストア サーバは同一サブネットにある Vault 間のみを移行でき、Setup および Control サーバは同一サブネットにある Streamer 間のみを移行できることを意味します。
Stream Group は、指定された QAM デバイス、続いて特定のサービス グループを扱うように設計された Streamer の設定可能なグループです。セッション設定および制御の観点から、Stream Group には次の 3 種類の論理サーバがあります。
Setup および Control サーバはプライマリおよびバックアップ サーバの両方を持ちます。バックアップ サーバは単に状態を維持するのに対し、プライマリ サーバはすべてのメッセージを処理します。プライマリ サーバが到達不能な場合、バックアップ サーバが制御を引き継ぎ、別のバックアップ サーバを作成します。したがって、設定および制御のためにプライマリおよびバックアップ サーバのペアが常にあります。Play サーバにはバックアップ サーバがありません。ただし、Control サーバは既存の Play サーバに障害が発生した場合に新しい Play サーバを選択します。
(注) プライマリおよびバックアップ サーバの両方を持つ機能は Stream Group の Streamer の数によって異なります。
Setup および Control サーバ IP アドレスは設定可能です。ISA 環境では、Setup IP アドレスは、Stream Master IP アドレスと同じです。RTSP の場合、Setup サーバおよび Control サーバは同じサーバである必要があります。ISA および RTSP の両方の環境で、Stream Service は Stream Group の Streamer を Setup サーバに選択し、別の Streamer(同じ Streamer の場合もあり)を Control サーバに選択します。
Setup サーバとして指定された Streamer はバックオフィスとインターフェイスし、宛先サービス グループに割り当てられている適切な Stream Group に設定メッセージを転送します。バックオフィス サーバと共存する Stream Group の 1 つの Streamer は、プライマリ Setup サーバとして割り当てられます。Setup サーバはバックオフィスから設定要求を受信し、サービス グループをマッピングします。
Setup サーバは、Control サーバの IP アドレスを返し、STB はこれに続く制御メッセージをこの IP アドレスに発行します。
Control サーバは、特定の Streamer に要求を割り当て、ストリームの状態(たとえば、コンテンツの接合境界、メンテナンスの浸透、またはサーバ障害)の変化に基づいて Streamer 間でダイナミックにストリームを移行します。Stream Group の 1 台のサーバがプライマリ Control サーバとして割り当てられます。Control サーバは ISA 環境の Lightweight ストリーム制御プロトコル(LSCP)プロキシおよび RTSP 環境のリアルタイム ストリーミング プロトコル(RTSP)プロキシを実行します。
バックオフィスから受信したすべての設定メッセージそれぞれに対して CCP メッセージが生成されて Control サーバに送信されます。初期設定要求内で Control サーバは設定パラメータを受信しますが、Play サーバを選択しません。STB からの制御メッセージが受信されると、Control サーバは Stream Group 内の Play サーバ候補からパフォーマンス情報(たとえば、サーバ ロード)を取得し、最適な候補に CCP メッセージを送信します。後続の制御メッセージは、STB からであろうと Setup サーバからであろうと、選択された Play サーバに転送されます。
Play サーバは、ストリームの再生に割り当てられた Streamer です。この Streamer は、コンテンツを RAM、ローカル ディスク、または Vault のいずれかに取得して、ストリームのサービスの配信を確実に保証します。Stream Group の各 Streamer は Play サーバになる可能性のある候補です。
Cache Group は指定された Stream Group にコンテンツを配信する Caching Node の設定可能なグループです。コンテンツ要求が Streamer によって受信されると、Streamer はまずコンテンツがローカル(同一 Stream Group の DRAM、ディスク キャッシュ、および Streamer など)に保存されているかどうかを確認します。Streamer のコンテンツは常に最も一般的なコンテンツのため、ユーザ要求は通常ローカル ストレージから配信されます。
Streamer はローカルに見つからないコンテンツに対してリモート サーバにキャッシュフィル コールを送信します。リモート サーバは、他の Stream Group の Streamer、Cache Group の Caching Node、または Vault Group の Vault である可能性があります(Vault Redundancy がイネーブルである必要があります)。選択されたキャッシュフィル ソースが、別の Streamer、Caching Node、または Vault のいずれであるかは、ネットワーク容量とフィルソース容量(ディスクおよびメモリ)、およびサーバのそのグループに設定された優先順位に基づいています。Caching Node は、コンテンツが現在キャッシュされていないことを示すメッセージで要求に対して応答できますが、Caching Node が問い合わせできるフィル ソースは他にも存在します(他の Cache Group の Caching Node、および Vault)。
Caching Node は Vault との通信に CCP を使用し、Streamer との通信には CCP または HTTP を使用します。
(注) RTSP 環境は VVI の場合 HTTP だけをサポートするのに対し、ISA 環境は CCP だけをサポートします。
HTTP は、Caching Node と Streamer 間の通信に使用できます。HTTP Streamer は、フィル ソースを検索してコンテンツをプルするためにプロキシと通信します。
検索サービスは、Caching Node と Vault のグループのプロキシとして機能します。サービスには、Caching Node でホストされる可用性の高い仮想 IP アドレスを使用してアクセスします。仮想 IP アドレスは、フィル ポート(Locate Port)にバインドされています。
HTTP Streamer は、プロキシ サービス(検索サービスのあるサーバ)への HTTP GET 要求によってコンテンツを要求します。プロキシ サーバは拡張 CCP を使用して、自身のストレージとピアのフィル ソース(同じグループのサーバ)にコンテンツがあるか確認します。コンテンツがある場合、最適なソースが容量に基づいて選択され、リダイレクト応答が選択したサーバに送信されます。コンテンツがない場合、キャッシュフィル要求がリモート サーバに送信されます。
HTTP Streamer にコンテンツを送信するために最適なサーバが選択されると、そのサーバの単一のキャッシュフィル ポートがコンテンツの HTTP 転送用に選択されます。これは、コンテンツを配信するために潜在的にすべてのキャッシュフィル ポートを使用できる CCP の転送とは異なります。
Locate Port サービスは復元力に関して Setup および Control サーバに似ています。Locate Port サービスのプライマリ サーバには、インターフェイスにバインドされた Locate Port IP アドレスがあります。バックアップ サーバは、プライマリに障害が発生した場合はプライマリになります。
ピア Caching Node は HTTP Locate Port Service をホストする機能に関してピア Caching Node 間でアドバタイズします。これには、プライマリ、バックアップ、使用可能、および使用不可の状態が含まれます。使用可能とは、Caching Node が必要に応じてプライマリまたはバックアップになれることを意味します。使用不可とは、サーバがサービスをホストできないことを意味します。HTTP Locate Port の場合、これはサービスに使用可能なネットワーク ポートがないことを通常意味します。
Caching Node の専用ネットワーク ポートは、HTTP Locate Port サービスにだけ使用されます。プライマリ サーバは専用ネットワーク ポートのリンク ステータスに基づいてサービス可用性を決定します。ネットワーク ポートがリンク ステータスを失うとサービスのフェールオーバーが発生します。リンクが再確立されると、サーバは使用可能になります。
CCP Streamer は CCP を Caching Node との通信に使用します。HTTP Streamer の Locate Port に割り当てられたプロキシ アドレスは使用しません。CCP Streamer は、フィル ソース全体で locate 要求をロード バランシングします。
Streamer または Caching Node はプロキシ サーバから locate-and-request メッセージを送信します。プロキシ サーバは、要求を満たすために最適なソースにメッセージを送信します。
コンテンツを必要とする Streamer または Caching Node は、最初にピア ソース(同じグループ内のサーバ)に照会します。Streamer はローカル Streamer にも照会し、コンテンツが見つからない場合は、次にリモート ソースへの要求が送信されます。リモート ソースは優先順位のリストに基づいて照会されます。ソースはグループ化され、優先順位が各グループに割り当てられます。
Vault は次の 3 つの異なる方式を使用してコンテンツを取り込みます。
• UDP 上での MPEG-2 トランスポート ストリームのライブ キャプチャ
FTP プルでは、元のコンテンツは FTP サーバ(キャッチャー)に一定期間保持され、正常に取り込みが完了するまで取り込みを再開するメカニズムがあります。
FTP プッシュでは、ライブ(ブロードキャスト)フィードを処理してデータを Vault にプッシュするデバイスによってデータのウィンドウのみがバッファされます。
TV CDS は、Tandberg OpenStream などのビジネス管理システム(BMS)で使用されるインタラクティブ サービス アーキテクチャ(ISA)、および ARRIS nABLE などの BMS で使用される RTSP、ならびに ISA と RTSP の両方を組み合わせた環境と統合します。BMS は TV CDS のロールおよび責任を決定します。
nABLE BMS は、nABLE 本社(HQ)およびリアルタイム(RT)コンポーネントと CDS 間の通信に、ハイパーテキスト転送プロトコル(HTTP)上の Extensible Markup Language(XML)および RTSP を組み合わせて使用します。HQ は、XML/HTTP を使用して Vault サーバにファイル関連要求を伝達し、またサーバ ステータス情報要求を Streamer および Vault サーバの両方に伝達します。RT は、複数の交換可能な VOD フロー(RTSP または DSM-CC)のセッション設定を確立するために RTSP 経由で Streamer サーバと通信します。
(注) 現在、nABLE BMS との統合のための CDS 設定は、Cisco フィールド エンジニアによって行われます。CDS の nABLE BMS との統合の詳細については、シスコのテクニカル サポート担当者にお問い合わせください。
図 6-8 に、CDS が nABLE BMS と統合する方法について説明します。
Vault および Streamer を使用する TV CDS、ISV を使用する TV CDS、および Caching Node を使用する TV VVI のネットワーク接続はすべて異なるネットワーク接続です。 表 6-2 に、各 CDS サーバに必要な異なるインターフェイスを示します。インターフェイスは次の項で説明します。図 6-9 に、Vault および Streamer を使用する TV CDS について説明します。図 6-10 に、ISV を使用する TV CDS について説明します。図 6-11 に、Caching Node を使用する TV VVI について説明します。
|
|
|
|
|
---|---|---|---|---|
1 ~ 41 |
||||
(注) 表 6-2 に、各 CDS サーバに必須のインターフェイスを示します。HTTP Streamer を VVI で使用する場合、各 Caching Node には、Locate インターフェイスに指定された 1 台のインターフェイスが必要です。Stream Control はオプションのインターフェイス機能です。詳細については、「インターフェイスの設定」を参照してください。
図 6-9に、Vault および Streamer で構成される CDS のさまざまな論理ネットワークを示します。取り込みネットワークは FTP ステージング サーバまたは FTP キャッチャー経由でコンテンツ ソースからコンテンツを受信し、コンテンツは Vault によって取り込まれます。管理ネットワークは CDSM と BMS 間の通信、ならびに Vault、Streamer QAM デバイス、および STB との通信で構成されます。キャッシュ ネットワークは Streamer および Vault で構成されます。
図 6-9 Vault および Streamer ネットワーク接続
図 6-10 に、ISV で構成される CDS のさまざまな論理ネットワークを示します。取り込みネットワークは FTP ステージング サーバまたは FTP キャッチャー経由でコンテンツ ソースからコンテンツを受信し、コンテンツは ISV によって取り込まれます。管理ネットワークは CDSM と BMS 間の通信、ならびに ISV、QAM デバイス、および STB との通信で構成されます。
図 6-11 に、VVI のさまざまな論理ネットワークを示します。取り込みネットワークは FTP ステージング サーバまたは FTP キャッチャー経由でコンテンツ ソースからコンテンツを受信し、ここでコンテンツは Vault によって取り込まれます。管理ネットワークは CDSM と BMS 間の通信、ならびに Vault、Streamer、Caching Node、QAM デバイス、および STB との通信で構成されます。
取り込みインターフェイスは 1 Gbps の最大レートでコンテンツ プロバイダーからの FTP トラフィックを取り込みます。Vault サーバが BMS から管理インターフェイスを使用してコンテンツに関する URL 情報を受信すると、取り込みインターフェイスは、(1)FTP クライアントとして動作することで FTP トラフィックを受信するか、(2)FTP サーバとして動作する要求を受け取り次第ライブ データを受信します。
スイッチング ファブリック全体のすべての取り込みトラフィックを隔離するためにレイヤ 2 のパケット転送を使用するときは、ポートベース VLAN の使用を推奨します。
管理インターフェイスは、SNMP 経由でネットワーク管理システム(NMS)と、ISA コマンドと RTSP 経由で BMS と通信し、また、同じアレイ内のすべての Vault、Caching Node と Streamer とも通信します。同じアレイのサーバ間で共有される情報は次のとおりです。
管理トラフィックは少量です。ただし、レイヤ 2 パケット転送を使用するときは、重要な管理通信を確実に配信するためにポートベース VLAN を使用することを推奨します。
CCP はキャッシュ インターフェイスを Vault、Caching Node、および Streamer で使用して同じアレイのサーバに次のデータを送信します。
• すべての CDS サーバ間で交換されるパフォーマンスの最適化に使用する情報を含むメッセージ
(注) すべての Cisco CDS サーバはスイッチ ファブリックを介して接続されます。同じアレイにあるすべての Vault、Caching Node、および Streamer は、キャッシュ インターフェイスを介してハートビート メッセージを交換するため、キャッシュ トラフィックの配信に関与するスイッチ間の帯域幅が十分なことを確認すること、また、すべてのキャッシュ インターフェイス上で同じ集約トラフィック量をサポートしていることが重要です。
Streamer サーバのキャッシュ/ストリーム インターフェイスはキャッシュおよびストリーミング トラフィックの両方に使用できます。各トラフィック タイプに指定されているインターフェイスの数は設定可能です。インターフェイスがキャッシュおよびストリーミング トラフィックの両方に設定されている場合、キャッシュ トラフィックが他のインターフェイスで送信できるのであれば、高帯域幅ストリーム トラフィックが優先されます。
レイヤ 2 パケット転送をキャッシュおよびストリーム トラフィックに使用するときは、ポートベース VLAN の使用を推奨します。
ストリーミング インターフェイスは、QAM デバイスを経由して MPEG-2 トランスポート ストリームで構成されるストリーミング トラフィックを STB に配信します。
インターフェイスがストリームおよびキャッシュ トラフィックの両方に設定されており、ジャンボ フレームがキャッシュ トラフィックに対してイネーブルであるにもかかわらず、ジャンボ フレーム機能がストリーム トラフィックに対してイネーブルでない場合は、キャッシュ トラフィックがジャンボ フレームを使用するにもかかわらず、ストリーム トラフィックは 1500 バイトのパケットを使用します。