Cisco MediaSense 設計ガイド リリース 11.0(1)
設計ガイダンス
設計ガイダンス

設計ガイダンス

プロアクティブなストレージ管理

MediaSense には、保存優先と新規録音優先の両方のストレージ保存モードがあります。 保存優先のモードでは、システムがいかなる自動プルーニングも行わないため、クライアントは、新規録音に使用できる領域を管理する必要があります。 新規録音優先のモードでは、システムが古い録音を自動プルーニングしますが、このプルーニング処理では、メタデータや非推奨の convertSession API を使用して生成された mp4 ファイルを必ずしも削除するわけではありません。 自動的にこれらの要素をクリーニングするように MediaSense を設定することもできますし、または、そのディスク容量の管理をクライアントでプロアクティブに担うこともできます。

新規録音優先のモードで、プルーニングされたメタデータを自動的に削除するように MediaSense を設定していない場合、自動プルーニングされたセッションをクライアント アプリケーションでアクティブに削除する必要があります。 クライアントは、セッションのプルーニング用の API 要求を定期的に発行するか、あるいはその代わりに、セッションのプルーニングのイベントを受信して既に不要になったものを明示的に削除することもできます。

保存のプライオリティを使用する場合は、自動プルーニングは行われず、クライアントは、新規の録音に十分なディスク領域が使用可能であることを保証する全責任を負います。

システムが新規録音優先のモードに設定され、かつプルーニングされた録音の自動削除が有効に設定されている場合に限り、クライアントはストレージ管理への関与を避けることができます。

これらのセッション管理のアクティビティは MediaSense API を使用して呼び出されます。 (詳細については、『MediaSense Developer Guide』を参照)。 プルーニングのアクティビティを定期的に実行する場合は、通常の処理への影響を最小限に抑えるため、使用率の低い期間にそれらをスケジュールします。

メディア記憶域のプロビジョニング

アプリケーション レベルで、MediaSense には 2 種類のメディア ストレージが含まれています。これらはそれぞれ独自のディレクトリの場所にあります。 録音ストレージは /recordedMedia と呼ばれるパーティション内にあり、アップロードされたビデオは /uploadedMedia と呼ばれるパーティション内にあります。 これらは、VM レベルでそれぞれ 1 ~ 16 個の仮想ディスクからなる論理パーティションです。 仮想ディスクは、(VMware ホスト設定を使用して)サーバまたは SAN の物理ディスクにマッピングされます。 物理ディスクは、RAID コントローラを使用して設定および管理されます。

物理ディスクは、後続の「互換性マトリクス」内の「ストレージ」の項に記載されている特定の速度とスループットの要件を満たす必要があります。 ESXi シン プロビジョニングは、ディスクでサポートされていません。

SIP の設定

次のガイドラインは Unified Border Element 導入に適用されます。

  • Unified Border Element 導入では、MediaSense に向かうダイヤル ピア上で SIP アーリー オファーを使用します。 これがデフォルト設定です。 Unified Communications Manager のみ、オプションなしのディレイド オファーを実行します。
  • MediaSense に向かうダイヤル ピアまたはトランクで SIP over TCP を使用します。
  • MediaSense に向かうトランクまたはダイヤル ピアに SIP Options Ping サポートを設定します(単一ノード配置の場合を除く)。 この機能は、MediaSense クラスタのフェールオーバーに対するサポートとともにマルチサーバ MediaSense 導入に対するフェールオーバーのサポートを大幅に向上させます。

電話機のコーデック設定

Unified Communications Manager 録音の場合、新しい一部の Cisco IP Phone は iLBC または iSAC というコーデックをサポートしており、Unified Communications Manager はそれらのネゴシエーションをすることがあります。 しかし、MediaSense はまだこれらのコーデックを受け入れないため、Unified Communications Manager サービス パラメータ設定で録音が有効になっているデバイスに対してそれらのコーデックを無効にする必要があります。

Jabber エンドポイントも G.722.1 と呼ばれるコーデックをサポートしていますが、これは G.722 とはまったく異なるもので、MediaSense ではサポートされていません。 Jabber エンドポイントを使用している場合、G.722.1 をコーデックの優先順位リストの一番下に移動させて選択されないようにする必要があります。

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

RTP メディアを伝送する Unified Border Element インターフェイスは、次の要件を満たすように設定する必要があります
  • 固定 1 ギガビット以上の速度

  • 全二重

  • 自動ネゴシエーションに依存しない

自動ネゴシエーションは、100 メガビットの速度が利用可能である場合に失敗することがあります。 100 メガビットの速度が正常にネゴシエートされた場合でも、大量のコール負荷を処理するには十分な速度ではありません。

MediaSense などの録音サーバは大量のネットワーク トラフィックを受信しますが、それ自体が生成するトラフィックは比較的少ないものです。 このようなトラフィックの非対称性が、ネットワーク スイッチの MAC アドレス転送テーブル エントリの飽和につながり、その結果、ネットワークでフラッディングが発生する場合があります。 ネットワーク管理者がネットワーク スイッチング装置を設定する場合には、このことを考慮する必要があります。

スケーラブルなクエリーの使用

MediaSense では、非常に柔軟な方法でメタデータを検索するための API が提供されます。 MediaSense サーバの通常の動作にほとんどまたは全く影響を与えずに多くのクエリーを実行している間に、大きな影響を及ぼすクエリーを構成することができます。 MediaSense は、同時に処理するクエリーの数を制限しますが、個々のクエリーの相対コストは考慮しません。 クエリー API を使用するお客様は、『MediaSense Developer Guide』で確認できるスケーラブルなクエリーの書き込みに関するガイドラインを確認し順守する必要があります。

HTTP ダウンロード要求の順次配信

一部のお客様は、MediaSense を長期的なアーカイブというよりもそれらのファイルの一時保管場所として扱い、HTTP ダウンロード機能を使用してすべての録音のコピーを作成します。 こうしたダウンロード要求を 1 日に 1 回などの定期的間隔でまとめて発行する場合もあります。 リソース使用の観点からは、これらの要求が時間軸上に、より均等に分散されるほうが望ましいと言えます。 たとえば、セッションの ENDED イベントを使用して、コールの録音が終了次第ダウンロードを開始するようにします。

アラーム モニタリング

管理者の注意によってアラームを上げる必要があるさまざまな状況が考えられます(システムの状態)。 これらの状態は、RTMT のアラーム ページだけでなくシステム ログでも確認できます。 RTMT を使用して、SYSLOG サーバに送信したり、指定した電子メール アドレスに電子メールを送信するようにこれらのアラームを設定できます。 MediaSense は現在 SNMP アラームをサポートしていません。

これらの方法のうち少なくとも 1 つを使用して、MediaSense サーバの状態をアクティブにモニタする必要があります。