Cisco MediaSense 設計ガイド リリース 11.0(1)
MediaSense に固有の配置モデル
MediaSense に固有の配置モデル

MediaSense に固有の配置モデル

サポートされているサーバ モデル

MediaSense は、次のいずれかで動作している VMware ハイパーバイザ上にのみ導入できます。
  • ファイバ チャネル接続された SAN ストレージ(少なくとも最初の 2 台のディスク用)または直接接続されたハード ディスクを備えた Cisco B シリーズまたは Cisco C シリーズのサーバ

  • Cisco ISR-G2 ルータ内で動作している UCS-E モジュール

  • (記載された最低パフォーマンスを要件とする)その他のサーバ(バージョンとモデル番号については、次の「Compatibility matrix」を参照)。

C シリーズ サーバを注文する場合、バッテリ バックアップまたは Super Cap RAID コントローラのオプションを含める必要があります。 これらのいずれかがないか、運用不能の場合、書き込みキャッシュはこれらのコントローラでディセーブルになります。 書き込みキャッシュがディセーブルの場合、書き込みのスループットが大きく低下します (詳細なディスクの要件については、次の「Compatibility matrix」を参照)。

プライマリ サーバとセカンダリ サーバは、同一のハードウェアに基づいているか、少なくとも CPU 速度とディスク I/O スループットが同一の仕様である必要があります。 また、VMware ESXi の同じバージョンを使用している必要があります。 どのような非対称性も、一方のまたは他方のサーバでのデータベース遅延を引き起こします。 拡張サーバは、同一のハードウェア上で稼動している必要はありません。

サーバ タイプ

MediaSense は必要な容量と冗長性の程度に応じて、最大 5 台のラックマウント サーバまたは最大 2 つの UCS-E モジュールに展開されます (「サーバ」は仮想マシンを示し、必ずしも物理マシンではありません)。 サーバには次の 3 種類があります。

  • プライマリ(必須):すべてのデータベース操作とメディア操作をサポートします。
  • セカンダリ(オプション):すべてのデータベース操作とメディア操作をサポートします。 データベースに高可用性を提供します。
  • 拡張(オプション):メディア操作に対し追加の容量を提供しますが、データベース操作は対象外です。 拡張サーバは 7-vCPU 展開でのみ使用され、UCS-E モジュールの展開では使用されません。

次の図に、プライマリのみの導入モデルを示します。

図 1. プライマリのみの配置モデル

データベースの冗長性を必要とするカスタマーは、セカンダリ サーバを導入できます。

図 2. セカンダリ サーバの配置モデル

追加の録音容量が必要な場合は、拡張サーバを導入します。

図 3. 拡張サーバの配置モデル


(注)  


拡張サーバは完全な 7-vCPU テンプレートを使用していない展開ではサポートされません。


すべてのサーバ(UCS-E サーバを含む)は、同じインストールされたソフトウェアを実行しています。機能と容量が異なるだけです。 プライマリ サーバは常に最初にインストールされるサーバで、インストール プロセス中にプライマリ サーバと識別されます。 セカンダリおよび拡張サーバは、これらのノードの最初の Web ベースのセットアップ プロセス中に識別されます(インストールが完了した後)。

録音は最初にメディアをキャプチャしたサーバに接続されたディスクに常に保存されます。

UCS-E ベースの 2 サーバ クラスタは、同一の ISRG2 ルータでは両方のブレードとともに、または 2 台の ISRG2 ルータそれぞれでは 1 つのブレードとともに配置することができます。 後者のブレードが障害分離の観点から一般的に優先されますが、必須ではありません。 MediaSense クラスタは、UCS-E ベースまたはラックマウント サーバ ベースである必要があります。 両者を組み合せて構成することはできません。

システムの拡張

システム容量を拡張する理由は 2 つあります。より多くの同時コールを処理できるようにするためと、録音の保存期間を延長するためです。

より多くのコールに対応できるようにすることが目的の場合は、クラスタにノードを追加することができます。 各ノードは、同時アクティビティ容量(より多くのパラレル録音、モニタリング、ダウンロードおよび再生アクティビティを実行する機能)とストレージ容量の両方を追加します。 サーバはクラスタにいつでも追加できますが、クラスタからサーバを削除する機能はありません。

クラスタが最大サイズ(7 つの vCPU システムの場合は 5 ノード、その他は 2 ノード)に達した場合は、新しいクラスタを追加することが唯一のオプションです。 その場合は、ほぼ等しい数のノードを持つクラスタを配置する必要があります。 それが不可能な場合は、各クラスタにほぼ同じ数のコールが分配されるように、コール分配を設定する必要があります。この場合、容量の大きい方のクラスタは十分に活用されない状態となります。 詳細については、Unified Communications Manager Session Management Edition の展開を参照してください。

クラスタに追加したノードを削除する機能はありません。

録音の保存期間を延長するのが目的の場合は、2 つのオプションがあります。 前述のようにノードを追加するか、または、ノード 1 つにつきより多くの記憶域をプロビジョニングできます。 基盤となるハードウェアでサポートできる場合、各ノードは録音用ストレージを最大 12 TB まで処理できます。 SAN での UCS-B/C サーバではストレージ容量を簡単に処理することができますが、ダイレクト アタッチド ストレージ(DAS)を使用したサーバとローエンド UCS-E サーバでは制限があります。

クラスタ内のノードと同様に、インストール後はノードからストレージ容量を削除する機能はありません。

Unified Communications Manager Session Management Edition の展開

Unified Communications Manager Session Management Edition(Unified CM SME)環境では、特定の MediaSense クラスタで録音されるすべての電話機が同じ SME リーフ クラスタに含まれている必要があります。 異なるリーフ クラスタの電話機を録音する必要がある場合は、次に示すように別個の独立した MediaSense クラスタを展開する必要があります。

図 4. Unified CM SME の展開

この図は、MediaSense クラスタが Unified CM SME Manager クラスタではなく Unified CM SME リーフ クラスタにどのように接続される必要があるかを示します。 この図は、サポートされる配置である別個の MediaSense クラスタに接続しているリーフ クラスタも示しています。

Unified Communications Manager によって管理されるコール

Unified Communications Manager の組み込みブリッジまたはネットワークベースの録音の場合は、特定の電話機がある特定の MediaSense クラスタでのみ録音されるように MediaSense クラスタ間で電話機を分ける必要があります。その録音は別のクラスタ内のサーバによってキャプチャされることはありません。 (ただし、サイト障害などの場合に備えて、フル クラスタ フェールオーバーのオプションがあります。 High Availabilityを参照してください)。

一部の導入では、SME ネットワークで互いに結合している可能性がある複数の Unified Communications Manager クラスタが 1 つまたは少数の MediaSense クラスタを共有する必要があります。 この配置では、異なる Unified Communications Manager クラスタからの 2 つのコールが MediaSense に到達したときに xRefCi 値の同一ペアを伝送する可能性があります。 これにより、これら 2 つのコールが正しく録音されなかったり、まったく録音されない場合があります。 (このような競合の統計的確率は非常に低いので考慮する必要はありません)。 したがって、この配置は完全にサポートされます。

発信コールを特定の電話番号に行いその録音を開始するよう MediaSense に要求する startRecord API 機能をアプリケーションが使用する場合は、単一の Unified Communications Manager ノードのみをこのタイプの発信コールのコール コントローラとして設定できます。

Unified Border Element ダイヤル ピアによって管理されるコール

Unified Border Element の録音では、状況はより柔軟です。 1 つ以上の Unified Border Element システムが 1 つ以上の MediaSense クラスタに分岐されたメディアを方向付けできます。 コール識別子の衝突が発生する可能性はありません。なぜなら、MediaSense は Unified Border Element の Cisco-GUID をこの目的に使用し、その GUID はグローバルに一意なためです。

MediaSense クラスタは負荷を互いに共有しないため、Unified Border Element は録音招待とともに負荷を分散させる必要があります。 各ピアが新しい各コールでランダムに選択されるように複数の録音ダイヤル ピアを異なるクラスタに設定することで、各 Unified Border Element 内でこれを実行できます。 または、各 Unified Border Element はある特定の MediaSense クラスタのプリファレンスで設定でき、他のメカニズム(PSTN パーセンテージの割り当てなど)は異なる Unified Border Element デバイス間でコールを分配するために使用できます。

MediaSense クラスタ間にロード バランシングではなくフェールオーバーを提供することが目的の場合は、「High Availability」を参照してください。

仮想マシン構成

シスコでは、最小サイズのストレージ パーティションと必要な CPU およびメモリ予約が組み込まれた OVA 仮想マシン テンプレートを提供しています。VMWare ESXi はこれらを適用し、これらのリソースに対して他の VM が MediaSense と競合しないようにします。 ただし、ESXi はディスク スループットの最小値を適用しません。 したがって、各 MediaSense VM に指定した IOPS と帯域幅を提供できるようにディスクが設計されていることを確認する必要があります。

シスコが提供する OVA テンプレートにはドロップダウン リストが含まれており、MediaSense サーバの各リリースでサポートされる VMware 仮想マシン テンプレート オプションの 1 つを選択できます。 これらのテンプレート オプションを使用して、仮想マシンのメモリ、CPU、ディスク容量などを指定できます。 各仮想マシンのインストールを開始する際に、適切なテンプレート オプションを選択する必要があります。 実稼動においては、シスコが提供するテンプレートを使用する必要があります。 小容量のラボとして使用する場合、テンプレート オプションよりも小さい仮想機器として導入することも可能ですが、機能的に制約され、サポートされていないハードウェアで実行していることを示す警告バナーが表示されます。


(注)  


すべてのディスクは「シック」プロビジョニングされる必要があります。 シン プロビジョニングはサポートされていません。


すべての MediaSense ノードにはデフォルトで 210 GB のメディア パーティションがあります。 さらに、MediaSense vDisk を追加して、指定された限度までストレージを拡張することができます。

次の表に、付属のテンプレート オプションをまとめます。

テンプレート オプション

vCPU

メモリ

ディスク

CPU 予約

サポートされる最大合計録音容量

注意

プライマリまたはセカンダリ ノード

2

6 GB

80 GB(OS)

80 GB(DB)

210 GB(メディア)

2200 MHz

8 TB(クラスタに分散または 1 つのノードに割り当て)。

拡張ノードはサポートされていません。

3

プライマリまたはセカンダリ ノード

4

8 GB

80 GB(OS)

80 GB(DB)

210 GB(メディア)

3200 MHz

8 TB(クラスタに分散または 1 つのノードに割り当て)。

拡張ノードはサポートされていません。

2、3

プライマリまたはセカンダリ ノード

7

16 GB

80 GB(OS)

600 GB(DB)

210 GB(メディア)

15000 MHz

12 TB(各プライマリまたはセカンダリ ノード)。

2

拡張ノード

7

16 GB

80 GB(OS)

80 GB(DB)

210 GB(メディア)

10000 MHz

12 TB(各拡張ノード)。

1、2

注:

  1. すべてのラックマウント拡張サーバは、拡張テンプレート オプションを使用する必要があります。

  2. プライマリ、セカンダリ、および拡張 OVA テンプレート オプションでは、デフォルトで 210 GB 以上プロビジョニングされます。 MediaSense ソフトウェアのインストール前またはインストール後に容量を追加できます。 プロビジョニング後は、録音領域を減らすことはできません。 すべてのノードのメディア ストレージの総容量は、5 ノード クラスタでの場合は 60 テラバイト、2 ノード クラスタの場合は 24 テラバイトを超えることはできません。UCS-E 導入では、使用可能な物理ストレージの容量によってはさらに制限される場合があります。

  3. プライマリおよびセカンダリ ノードの 2 vCPU と 4 vCPU テンプレートは、UCS-E ブレードの展開に適していますが、それより大規模なシステムでも使用できます。 サポートされているほとんどの UCS-E ブレードには、VM テンプレートによる割り当てよりも多くの物理ディスク領域が用意されています。未使用の領域は、録音メディアまたはアップロード メディア用に使用できます。

メディア ストレージの代替ストレージ

ラックマウント サーバでは、録音されたデータ用に 2 つの代替ストレージが現在サポートされています。

  • 物理的に接続されたディスク
  • ファイバ チャネル接続された SAN

(注)  


ネットワーク アタッチド ストレージ(NAS)は MediaSense 構成ではサポートされておらず、SAN ストレージは UCS-E 構成ではサポートされていません。


購入したハードウェア モデルとオプションに応じて、単一ノードは最大 12 TB のストレージ(5 台のサーバ間で最大 60 TB のストレージ)を提供できます。 すべてのサーバを同数または同タイプの仮想ディスクで設定する必要はありません (詳細仕様とその他のストレージ構成要件については、「Unified Communications Manager のネットワークベースの録音」を参照してください)。

RAID の設定

この項は、UCS C シリーズ サーバのみを対象とします。

MediaSense は、データベースと OS ディスクの場合は RAID-10 で、メディア ストレージの場合は RAID-10 または RAID-5 で設定する必要があります。 RAID-5 を使用するとハードウェアを節約できます。 速度は遅くなりますが、メディア ストレージには十分高速です。 UCS C シリーズ サーバに対するすべての TRC 構成には、ESXi ハイパーバイザを含めるのに十分な大きさの内部 SD カードが含まれます。 したがって、シスコは、SD カードでの ESXi のインストールと残りのディスク ドライブでの MediaSense アプリケーションのインストールをサポートします。

RAID-10 グループは、ESXi ハイパーバイザと MediaSense アプリケーションを保持する必要があるため、一般には推奨されません。 UCS C シリーズ サーバに対するすべての TRC 構成には、ESXi を含めるのに十分な大きさの内部 SD カードが含まれます。 したがって、ESXi が SD カードにインストールされ、MediaSense アプリケーションが残りのディスク ドライブにインストールされていることが必要です。

サーバ 1 台につき複数の MediaSense 仮想マシンの配置

リリース 9.0(1)以降、MediaSense は、1 台の物理サーバで実行する唯一の仮想マシンである必要はありません。 MediaSense が必要最小限のリソースを予約できる限り、他のアプリケーションもそのサーバを共有できます。

1 つのホストに複数の MediaSense VM を導入することもできます。 ただし、その場合は、プライマリ ノードとセカンダリ ノードが同じ物理ホスト上に存在しないようにする必要があります。 たとえば、サーバが 2 台の MediaSense VM をサポートできる場合、5 ノードのクラスタを次の図のように配置することが考えられます。

図 5. 5 ノードのクラスタ

サーバが 3 台の MediaSense VM をサポートできる場合は、次の図のように配置することもできます。

図 6. 3 台の MediaSense 仮想マシン

特定のサーバ モデルが何台の MediaSense VM をサポートするかについては、UC Virtualization wiki を参照して物理 CPU コア数を指標として、判断できます。 8 物理コア以上のモデルは 1 台の MediaSense VM を、14 物理コア以上のモデルは 2 台の MediaSense VM を、20 物理コア以上のモデルは 3 台の MediaSense VM をサポートできます。

地理的な仕様

クラスタ内のすべての MediaSense サーバは単一のキャンパス ネットワーク上にある必要があります。 キャンパス ネットワークは、 MediaSense サーバの任意のペア間のラウンドトリップ遅延が 2 ミリ秒以内であるネットワークとして定義されます。 (一部のメトロポリタン エリア ネットワーク(MAN)もこの定義を満たすことがあります)

ただし、他のソリューション コンポーネントが WAN 経由で MediaSense クラスタを接続することがあり、次のような留意事項を伴います。

  • Unified Communications Manager 展開では、メディア分岐の電話機が、WAN を介して MediaSense に接続される場合があります。
  • Unified Communications Manager からの SIP トランクが、WAN 経由で MediaSense にルーティングされる場合もあり、ラウンドトリップ遅延によって、コールの録音開始時に余分なクリッピングが発生することがあります。
  • Unified Border Element と MediaSense 間の接続は、WAN 経由でルーティングされる場合がありますが、その場合のコールでは、ラウンドトリップ遅延により録音開始時に余分なクリッピングが発生することがあります。
  • Unified Communications Manager と MediaSense 間の AXL 接続が WAN 経由でルーティングされる場合があり、API ログインおよび管理者ログインに時間がかかることがあります。
  • ハイ アベイラビリティの観点から見ると、API サインインは AXL リンクと依存関係があります。 このリンクが不安定な WAN を通過する場合、API サービスへのサインインや、ライブ モニタリング、再生および録音セッションのダウンロードなどのメディア出力要求の実行に関して問題が発生する可能性があります。 これは、リモート ブランチ配置か一元化配置かに関わらず、また、Unified Border Element による導入か Unified Communications Manager による導入かに関わらず当てはまります。