Cisco MediaSense 設計ガイド リリース 11.0(1)
Scalability and Sizing
Scalability and Sizing

Scalability and Sizing

パフォーマンス

MediaSense でサポートされているキャパシティは、システムが起動時に選択するハードウェア プロファイルの機能です。 ハードウェア プロファイルは、そのノードが配置されている VM テンプレートに依存し、VM テンプレートは、どのようなハードウェアを導入するかに部分的に依存します。 (各テンプレートの詳細については、仮想マシン構成を参照してください)。 ハードウェア プロファイルでは、VM テンプレートの各タイプを使用する場合の実際のキャパシティについて説明しています。

たとえば、各 7 vCPU テンプレート ノード(大規模な実稼働環境向けの標準)の場合、MediaSense サーバは最大 12 テラバイトのディスク容量により、持続的最繁時のコール着信率 2 コール/秒で同時(200 コール)に 400 メディア ストリームまでをサポートします。 400 は、記録、ライブ モニタリング、再生、.mp4 または .wav への変換、HTTP ダウンロードに使用するすべてのストリームを表しています。これらのすべてが任意の組み合わせで発生します。 変換とダウンロードは、厳密にはストリーミング処理ではありませんが、これらもシステム リソースを同様の方法で消費し、同等の負荷を持つと見なされます。 ビデオ トラックの再生には、音声トラックの再生の 9 倍多くのリソースを使用します。 その結果、アップロードされた各ビデオの再生(1 ビデオ トラック + 1 オーディオ トラック)には 10 オーディオ トラック分の負荷が生じ、ノードあたりでは 40 同時ビデオ再生という最大キャパシティになります。

ある特定の時点に使用されているストリームの数を判定するときに、各処理の所要時間とともに単位時間あたりの発生数を予測する必要があります。 記録、ライブ モニタリング、再生には、その記録の長さと同じ時間がかかります。 ビデオ再生では、1 度だけ再生するように設定されている場合、ビデオの長さと同じ時間がかかります。 保留のためのビデオ再生は、一般に各ビデオ発信者が保留のままになっている限り存続すると推測する必要があります。 .mp4 変換、.wav 変換および HTTP ダウンロードの時間は、録音 1 分あたり約 5 秒と推測されます。

必要なサーバ数を判定するには、次のデータを評価します。

  • 必要な同時オーディオ ストリームに再生されるビデオの数の 10 倍を加算し、各ノードでサポートされるオーディオ加重メディア ストリームの数で除算した値
  • 最繁時コール着信数を各ノードの最大コール着信レートで割った数
  • 保存された録音セッションに必要な容量を各ノードの最大メディア ストレージで割った値。

必要なサーバ数は、上記の 3 つの評価値の最大値と等しくなります(切り上げ)。

VoH、ViQ およびビデオ メッセージのビデオ再生は、さらに 2\- および 4-vCPU 仮想ハードウェアでは制限を受け、使用する物理ハードウェアの種類によって異なります。 詳細については、ハードウェア プロファイルを参照してください。

著しくパフォーマンスに影響を与えるもう 1 つの要因は、進行中の MediaSense API 要求の数です。 これは、最大 10 またはそれを超えるキュー能力がある 7-vCPU システムでは一度に 15 に制限されます(この数値は小規模なシステムではさらに低下します)。 これらは、ノードあたりの数ですが、プライマリとセカンダリの両方のノードが含まれる MediaSense クラスタでは倍増する場合があります。 詳細については、システムの復元力とオーバーロード スロットリングを参照してください。

メディアの出力および変換処理(モニタリング、再生、MP4 または WAV への変換、HTTP ダウンロード)は、完全にクライアントの制御下にあります。 クライアントは、これらの処理領域で独自の制限を適用します。 その他残りの処理(通話録音およびアップロードされたメディア ファイルの再生)はクライアントによる制御の対象ではありません。 導入のサイズは全体的な録音/ビデオ再生の負荷が、クラスタ全体の必要な最大数を超えないように設定できます(適用可能な数のモニタリング、再生、および HTTP ダウンロード処理を許可する)。 録音およびビデオ再生の負荷はすべてのサーバ間でバランスが取られます (完全なバランスが常に達成されるわけではありませんが、各サーバにほとんどのディスパリティに対応できる余地があります)

ハードウェア プロファイル

MediaSense ノードをインストールすると、基盤となる仮想マシンから検出したハードウェア リソースに従ってキャパシティの予測値を調整します。 サーバがシスコ提供の OVA テンプレートの 1 つを使用してインストールされる場合、適切な CPU 数とメモリ容量が自動的にプロビジョニングされ、vCPU の数、CPU 速度、プロビジョニングされたメモリ容量からなる機能と合致するハードウェア プロファイルが選択されます。 ハードウェア プロファイルで決定されるものは次のとおりです。

  • サポートされる電話と等価なオーディオ コール数

  • サポートされる同時 API 要求数

  • サポートされる最大コール到着率

  • クラスタでサポートされる最大ノード数

  • 使用可能なメディア ストレージの最大容量

  • サポートされるビデオ再生数の上限

  • その他の内部パラメータ

不適切な OVA テンプレートを使用したり、OVA テンプレートの適用後に仮想マシンを既存のハードウェア プロファイルのどれにも正確に一致しないような構成に変更すると、サーバはサポートされていないものと見なされ、「Unsupported」カテゴリーの容量が使用されます。

より詳細な情報については、http:/​/​docwiki.cisco.com/​wiki/​Virtualization_for_Cisco_MediaSensehttp:/​/​docwiki.cisco.com/​wiki/​Virtualization_​for_​Cisco_​MediaSense [英語]で、ハードウェア プロファイルの表を参照してください。

最大セッション時間

MediaSense は、最大 8 時間までコールを録音できます。 この時間を過ぎると、一部のセッションはエラー ステータスを伴ってクローズされ、HTTP ダウンロードおよび .mp4 または .wav への変換が成功しない場合があります。

ストレージ

MediaSense は、ストレージを 2 つの目的に使用します。1 組のディスクには運用ソフトウェアとデータベースを保持し、もう 1 組のディスクはメディア ストレージ用となります。 この 2 種類のストレージには、大きく異なるパフォーマンスと容量の要件があります。 シン プロビジョニングは、どのような MediaSense ディスクでもサポートされていません。

録音済みメディア ストレージ:クラスタごとに最大 60 TB がサポートされ、5 台の各サーバに 12 TB ずつに分割されます。 これは理論上の最大値で、SAN ストレージを使用する場合にのみ実現できます。 直接接続されたディスク(DAS)を使用する場合、サーバで使用可能な物理領域に限定されます。

アップロード済みメディア ストレージ:アップロードされたメディアに要するストレージはずっと少なくなりますが、これも最大 60 TB がサポートされ、5 台の各サーバに 12 TB ずつに分割されます。

直接接続されたディスク(DAS)を使用する場合、最初の 2 台のディスク(運用ソフトウェアおよびデータベース用)は RAID 10 として設定する必要があります。

SAN を使用する場合は、ファイバ チャネルで接続された SAN だけがサポートされており、SAN は、サポート対象の SAN 製品に対するシスコの仕様に基づいて選択する必要があることに注意してください(http:/​/​www.cisco.com/​go/​swonly [英語] の『Cisco Unified Communications on the Cisco Unified Computing System』を参照)。 SAN ストレージは、各 MediaSense 仮想マシン用のディスク パフォーマンス仕様を満たすか、上回るように設計する必要があります。 これらの仕様はノード単位です。 ノードが同じ SAN を共有する場合、その SAN は、これらの仕様にノード数を掛けた値をサポートするように設計する必要があります。 次のリンク先の仕様を満たす限り、セキュリティ上の理由から、メディア ストレージ用に暗号化された SAN を使用することも可能です。

MediaSense 用ディスクのパフォーマンスに関する現在の仕様については、http:/​/​docwiki.cisco.com/​wiki/​Virtualization_​for_​Cisco_​MediaSense [英語] を参照してください。

UCS-E ルータ ブレード モジュールには固定ディスクのハードウェアが付属しており、各モジュール タイプの場合の MediaSense の拡張性の制限は、それらの実際のパフォーマンス特性に応じて設計されています。 この仕様を満たすためにディスク アレイを設計する必要はありません。 ただし、すべてのドライブは 手動で RAID-1 として設定する必要があります。

また、これらのモジュール用に、必須のダウンロード可能 .OVA テンプレートが自動的にディスクを 80 GB のドライブ 2 基と 210 GB のドライブ 1 基に分割してフォーマットします。 追加の使用可能ディスク領域を持つ、これらのモジュールに対して、使用するアプリケーションに最も適したアップロード済みメディア用、または記録メディア用の追加の領域を設定できます。

Unified Border Element の容量

Cisco 3945E ISR G2 ルータは、ボーダー エレメントとして動作し、単純なコール フローをサポートする場合に、約 1000 の同時コールに対応できます(最低 2 GB、可能であれば 4 GB のメモリを搭載している場合)。 多くの状況では、複数コールの移動がある場合、800 コールの範囲でキャパシティが低下します(シグナリング オーバーヘッドの追加による)。 また、他の ISR G2 機能(QoS、SNMP ポーリング、T1 ベースのルーティングなど)が有効になっている場合はキャパシティがさらに低下します。

必要なコール キャパシティを処理するために複数の ISR G2 ルータを導入することが必要になる場合があります。 1 つの MediaSense クラスタでは、任意の数の ISR G2 ルータからの録音を処理できます。

上記の例は、Unified Border Element のダイヤル ピア録音および Unified Communications Manager のネットワーク ベースの録音の両方に当てはまります。

ネットワーク帯域幅のプロビジョニング

通話録音用

コール アドミッション制御(CAC)がイネーブルになっている場合、分岐デバイスと録音サーバ間に、そのパス上の現在の録音、または他のメディア チャネルのメディア品質に影響が及ばないだけの十分な帯域幅が使用可能かどうかを Unified Communications Manager は自動的に推定します。 十分な帯域幅が使用可能ではないと思われる場合、Unified Communications Manager はコールを録音しません。それでも、コール自体はドロップされません。 この状況の場合、アラームは発生しません。 コールがなぜこのとき録音されなかったかを突き止める唯一の方法は、ログと CDR レコードを調べることです。

このような状況が発生しないように、十分な帯域幅をプロビジョニングすることが重要です。 要件の計算では、Unified Communications Manager の管理者は、各ストリームの逆方向が実際には使用されていない場合でも 2 つの双方向メディア ストリーム用に十分な帯域幅を含める必要があります。

帯域幅要件も使用するコーデックによって異なり、ビデオの場合は、フレーム レートと映像の解像度およびサイズによっても異なります。

ビデオ再生用

メディア接続のネゴシエーションは(MediaSense がデータの送信だけを行い、受信しない場合でも)ビデオ再生の場合双方向です。 双方向メディアを使用することは、それを想定していなかった場合の 2 倍の帯域幅をプロビジョニングすることになるため、これは重要な考慮事項です。

Unified Communications Manager のサイジングへの影響

MediaSense はいかなる CTI エンジンにも接続しないため、Unified Communications Manager CTI のスケーラビリティには影響を与えません。 ただし、MediaSense が Cisco IP Phone 組み込みブリッジ録音を使用する場合、Unified Communications Manager BHCA は各同時録音セッションごとに 2 つずつの追加コールに伴って増加します。

たとえば、デバイスの最繁時コール レートが録音なしで 6 の場合、自動録音を有効にしたときの BHCA は 18 になります。 録音を有効にした場合のデバイスの BHCA を判定するには、次の計算式を使用します。

(標準 BHCA レート + (2 * 標準 BHCA レート)

さらに詳細な情報については、http:/​/​developer.cisco.com/​web/​sip/​docs [英語] にある SIP トランクのマニュアルの「Cisco Unified CM Silent Monitoring & Recording Overview.ppt」を参照してください。