Cisco MediaSense 設計ガイド リリース 11.0(1)
High Availability
High Availability

High Availability

録音サーバの冗長性:新規録音

MediaSense クラスタは、最大 5 台のサーバを含むことができ、各サーバが特定数までの同時コールを録音できます。 方法は、Unified Communications Manager コールと Unified Border Element コールとで若干異なります。

概念的には、フェーズが 2 つあります。 まず、コールのコントローラ(Unified Communications Manager または Unified Border Element)が MediaSense サーバ(パイロット サーバ)を選択して初期インビテーションを送信します。 第 2 に、パイロット サーバは、コールを処理する別のサーバ(ホーム サーバ)にインビテーションをリダイレクトします。 どのサーバも任意のコールに対してパイロット サーバとして動作することができるため、第 1 フェーズは初期インビテーションの失敗のシングル ポイントを防ぐように設計されています。

第 2 フェーズで、MediaSense サーバは、コール コントローラからのアクティブなサポートなしで、相互に負荷分散ができます。 このアルゴリズムでは、クラスタ内のすべての録音サーバの状態を認識し、障害のあるサーバおよび致命的なディスク容量不足や他の問題のある状態のサーバに録音を転送しません。 任意の 1 つのコールに関連付けられた 2 つのメディア ストリームが同じサーバで録音されることも保証します。

Unified Communications Manager は、インビテーションを各サーバに順次、ラウンド ビン方式で送信するように設定します。 これによって、すべての録音サーバに初期 SIP インビテーション プリファレンスが均等に分散されることを保証し、1 台のサーバが大量のインビテーションを受信する状況を回避できます。 Unified Border Element はラウンド ロビン方式による分散化をサポートしていないため、代わりに、常に特定の 1 台の MediaSense サーバに招待を送信するように設定し、第 2 および場合により第 3 のサーバを優先度の低い代替サーバとして設定します。 拡張サーバはどの時点でも処理負荷が低いため、可能な場合はプライマリまたはセカンダリのサーバよりも拡張サーバにパイロット サーバの役割を持たせることをお勧めします。

録音サーバがダウンしていたり、そのネットワーク接続が切断されている場合は、コール コントローラの SIP インビテーションに応答できません。 この場合の Unified Communications Manager と Unified Border Element 用の SIP 処理では、通常、プリファレンス リスト内の次のサーバにインビテーションを送信します。 ただし、コール コントローラは、少なくとも 1 回のタイムアウト時間が経過するまで待機してから他のサーバを試行する必要があります。

プライマリ メディア パスが確立されて初めて Unified Communications Manager および Unified Border Element に録音サーバが関わるため、このような処理では、結果として録音ができるようにまでに、非常に時間がかかる場合があります。 (Unified Communications Manager は、制限時間を設定して、それを過ぎても録音が始まらない場合は、試行を停止します)。

その結果、Unified Communications Manager が応答しない録音サーバを選択すると、当該のコールが録音されない可能性が高くなります。 Unified Border Element には制限時間はありません。そのため、これらのコールも録音されますが、コールの初期セグメントの相当部分がクリッピングされます。

録音サーバの障害によって録音が失われる可能性を減らすため、MediaSense は Unified Communications Manager および Unified Border Element と連携して SIP Options Ping と呼ばれる機能をサポートします。 この機能によって、コール コントローラは、定期的に各録音サーバをプローブし、コールが録音可能状態になるまで待たずに、録音サーバが動作中であることを確認できます。 コール コントローラは、MediaSense サーバが動作していないことを認識すると、ラウンド ロビン、つまり録音サーバの順序リスト内の該当のサーバをスキップします。 ただし、単一ノード配置の場合は、 SIP Options Ping は推奨されません。 これは有効でないばかりでなく、不要な障害回復遅延を招く可能性さえあります。

MediaSense ユーザ ガイド』には、SIP OPTIONS Ping 機能、およびその他の Unified Border Element と Unified Communications Manager の SIP パラメータ設定手順が記載されています。

サイジングの観点からは、1 台のサーバに障害が発生しても、想定されるすべての同時コールをキャプチャできる十分な容量があり、録音セッションを保存するための十分なストレージ領域があるように、必ず十分な録音ポートをプロビジョニングしてください。

録音サーバの冗長性:進行中の録音

録音サーバで障害が発生すると、そのサーバ上で録音中のすべてのコールの状態が ACTIVE から ERROR に変更され、内容は破棄されます。


(注)  


コールの失敗の検出とその後のエラーに対する状態変更は、しばらくの間、行われない場合があります(1、2 時間程度)。


進行中の録音を継続したり、代替サーバに転送する機能は現在ありません。

録音サーバの冗長性:保存済み録音

録音が終了した後、MediaSense はそれを録音した同じサーバ上に保持します。 そのサーバが稼動停止した場合、(それらに関する情報がまだメタデータ中で検索できる場合でも)どの録音の再生、変換、ダウンロードもできません。

メタデータ データベースの冗長性

プライマリ サーバとセカンダリ サーバ(この項の「データベース サーバ」)は、それぞれメタデータと設定データのデータベースを維持します。 それぞれが、MediaSense API を実装しており、サブスクライブしたクライアントにイベントを発行する機能があります。 導入後は、2 つのデータベース サーバは完全に対称的です。いずれか片方に対する書き込みが、もう片方にも同じく反映されるように、データベースの完全なレプリケーションが行われます。 クライアントはどちらかのサーバ宛てに HTTP API 要求を送信し、他方のサーバを障害の場合のフォールバックとして使用します。

データベース サーバの障害

プライマリ サーバかセカンダリ サーバに障害が発生した場合でも、正常稼動している方のサーバは使用可能な状態になっています。 障害の発生したサーバがサービスに復帰すると、ユーザの介入なしでデータ レプリケーション機能が自動的にキャッチアップ処理を開始します。

停止時間の長さと発生したチャーンの量によって、キャッチアップの処理に時間がかかる可能性があります。 実際の所要時間は、多くの要因によって異なります。ただし、テストでは 150,000 録音セッションの転送に約 1 時間かかっています。

障害が長時間続くと、システムはアラームを発してレプリケーションを完全に無効にし、障害が発生したサーバが回復すると再確立します。

リカバリ期間中には、2 台のサーバ間で不規則な動作や不整合が生じる可能性があります。 キャッチアップ処理が完了するまでは、リカバリ中のサーバに依存して API オペレーションを行わないでください。 リカバリ中のサーバの状態は、CLI コマンドを使用して判定できます。

イベントの冗長性

イベントは、特定の処理がサーバで実行された場合に個々のデータベース サーバによって生成されます。 たとえば、録音サーバが録音を開始するとき、データベース サーバの 1 つでセッション レコードを開始します。 データベースの更新はピアに複製されますが、その 1 台のデータベース サーバのみがイベントを生成します。 このアクションは、すべてのイベント タイプ(録音セッション イベントからディスク ストレージのしきい値イベントまで)に適用されます。

クライアントは最初に希望するセッションが生成されるサーバを事前に知ることはできません。各クライアントは、確実にすべてのイベントを受信するためには、両方のデータベースにサブスクライブする必要があります(2 つのサブスクリプションで同じターゲット URI を指定する場合があります)。

MediaSense は、各データベース サーバが他方のデータベース サーバによって生成されるイベントにサブスクライブしてイベントをサブスクライブ元に転送するための機能も提供しています(イベント本体には、転送イベントを識別するためのフラグが含まれています)。 この機能は MediaSense 管理機能で有効にします。 転送が有効になっている場合、クライアントは 1 台のデータベース サーバにサブスクライブするだけですみますが、信頼性が損なわれる可能性があります。 選択したデータベース サーバがダウンした場合、クライアントはイベントの受信漏れを防ぐため、代替のサーバに速やかにサブスクライブする必要があります。 この問題は、特にクライアントがこのような受信漏れを検出する信頼できる方法が、定期的にサブスクリプションの確認要求を発行する以外にないことを考慮すれば、過小評価すべきではありません。

クライアントがイベントを受信した場合、そのイベントに関連付けられたデータベースの更新がイベントを生成したサーバ上のデータベースにすでにコミットされているという暗黙保証があります。 API クエリーを実行する必要のあるクライアントは、イベントを生成したデータベース サーバに対して照会していることを保証するためにイベントの転送フラグを調べる必要があります。

イベントのサブスクリプションは MediaSense サーバを再起動すると維持されません。

アップロードされたビデオ再生の冗長性

着信録音コールの分散に使用されるロード バランシングと冗長性操作は、着信ビデオ再生コールを分散するために使用されるものとよく似ています。 コールはパイロット ノードに到達し、ホーム ノードにすぐにリダイレクトされます。 MediaSense は、ノードの少なくとも 1 つがビデオを再生できる限り、アップロードされたビデオを再生できます。

通常、クラスタ内のすべてのノードが要求を処理でき、アップロードされたビデオはすべてのノードに配布されます。 ただし、1 つのノードで配布中または処理フェーズ中にエラーが発生したり、これらの処理の実行時にあるノードが他よりも遅くなる可能性があります。 したがって、着信メディア再生コールは、稼働中の使用可能な容量があり、適切な着信コール処理ルールによって選定された特定のビデオを再生する準備ができているノードにリダイレクトされます。

ビデオ再生の要求スロットリングは、音声録音の要求スロットリングにもよく似ています。 音声録音の試行のように、MediaSense は着信ビデオ再生要求を RTSP 再生およびモニタリング要求よりも高い優先順位で処理します。 RTSP 再生およびモニタリング要求は、録音およびビデオ再生要求の場合より低い容量のスロットリングしきい値に従いますが、録音およびビデオ再生要求が他のノードにリダイレクトされている間に特定のノードが RTSP 要求を受け入れることができます。

アップロードされたビデオの再生時の Unified Communications Manager の障害

アップロードされたビデオを MediaSense が再生しているときに Unified Communications Manager で障害が発生した場合、メディア ストリームはアクティブのままですが、SIP シグナリングは使用できません。 SIP シグナリングがない場合、エンドポイント デバイスが切断されたときに MediaSense がそれを知る方法はありません。したがって、ビデオの再生を最後まで実行してから終了し、すべてのリソースを解放します。

ただし、繰り返し再生に設定されたビデオの場合は(着信コールの処理ルールでそのように設定されている場合)、再生が終了しないことがあります。 そのような場合のために Unified Communications Manager は、MediaSense にセッションのキープアライブ メッセージをデフォルトで 30 分ごとに 2 回送信します。 MediaSense はこの 2 回の連続したタイマーを受信しなかった場合、Unified Communications Manager に障害が発生したと判断し、再生を終了してすべてのリソースを解放します。

このため、Unified Communications Manager の障害発生後、最大で 30 分間、ビデオの繰り返し再生が実行中のままになる場合があります。 MediaSense は、新しい着信コールおよびストリーミング要求を受け入れ可能かどうかを判断する場合、それらのメディア ストリーミング リソースが使用中、または使用できないとみなします。

30 分という数値は、Unified Communications Manager のサービス パラメータのデフォルトであり、変更可能です。

MediaSense クラスタの冗長性

MediaSense クラスタ内の個別のノードは、1 台のノードに障害が発生した場合、クラスタ内の残りのノードが自動的にそれに参加するように機能します(使用可能な容量がある場合)。 MediaSense クラスタは、クラスタ全体の障害発生時にはクラスタ間で相互に役割を引き継ぐように設定することもできます。 使用可能な汎用トポロジが 2 つありますが、そのどちらの場合もクラスタ間のロード バランシングは行われません。 それらは、クラスタ フェイルオーバーの要件を満たすための厳密なホット スタンバイ配置です。 たとえば、片方のクラスタが容量限度に達したときに、コールをもう 1 つのクラスタで引き継ぐことはできません。

図 1. スペア容量付きリング

このトポロジでは、複数のクラスタがフェイルオーバー リング上に配置されます。 通常、クラスタ A で処理することになっているすべてのコールは、クラスタ A によって処理されます。クラスタ B およびクラスタ C の場合も同様です。ただし、コール コントローラ(Unified Border Element または Unified Communications Manager)は、通常のターゲットである MediaSense クラスタへのコールの録音を送信できないときには、リングの次のサーバに送信するよう設定されます。 この場合、クラスタ A のコールはクラスタ B に、クラスタ B のコールはクラスタ C に、クラスタ C のコールはクラスタ A に転送されます。このコール転送では、各クラスタを、自身の負荷に加えて先行するクラスタでの負荷に対応できる十分な余剰容量でプロビジョニングする必要があります。 フェールオーバーする コールをリング上の次のクラスタにではなく残りのクラスタすべてに分配するように設定することは可能ですが複雑になります。

図 2. スペア クラスタ

このトポロジでは、予備のクラスタ全体が 1 つプロビジョニングされますが、これは他のクラスタの 1 つで障害が発生した場合以外には使用されません。 この図のクラスタ D が予備です。クラスタ A、B、C はクラスタ D にフェールオーバーするように設定されています。

設定の方法

この 2 つのフェールオーバー トポロジは同じ手法を使用します。 これらの場合、SIP Options Ping(またはそれがないこと)に依存して、1 つのクラスタ全体がダウンしたときにコール コントローラにそれを認識させます。 この手法は、Unified Border Element ダイヤル ピアおよび Unified Communications Manager によって制御される分岐の場合に機能しますが、設定は両者の間で若干異なります。

Unified Border Element ダイヤル ピア分岐の場合、各 Unified Border Element は、録音を同じクラスタ内の 2 つの別々のノードに分岐させ、指定のフェールオーバー クラスタ内の 2 つの別々のノードにフォローされるように設定する必要があります。 通常、まずインビテーションはすべて第 1 クラスタ内のターゲット ノードに行き、そのノードが、クラスタ内のすべてのノードに均等にロード バランシングされるようにします。 最初のターゲット ノードがダウンすると、SIP Options Ping に対する応答を停止します。 その後、Unified Border Element はそのノードへのインビテーションの送信を停止し、代わりに第 1 クラスタ内の 2 番目のターゲット ノードに送信します。 そしてこのノードは、インビテーションがクラスタ内の残りすべてのノードに均等に行くようにします。

クラスタ全体の障害が発生した場合、最初の 2 ノードの両方が SIP Options Ping への応答を停止します。 Unified Border Element は指定されたフェールオーバー クラスタ内にある 3 番目のターゲット ノードにインビテーションを送信し始めます。

いずれかのノードがオンラインに戻ると、それが SIP Options Png に再度応答し始め、Unified Border Element は再びそのノードにインビテーションを送信するようになり、効果的に通常の動作に復帰します。


(注)  


録音プロファイルをラウンド ロビン方式で設定しても(つまり、連続したインビテーションを連続的に設定した各ノードに送信し、順序の最後のノードの次には最初のノードに送信する)クラスタ フェイルオーバーの実行には役立ちませんが、Unified Communications Manager のトップダウン アプローチが使用できます。 最初の 2 つの送信先を 1 番目のクラスタ内のノードに指定し、2 番目のクラスタ内の ノードを 2 つ続けて指定するように設定できます。 これで、フェールオーバーとリカバリが Unified Border Element のシナリオと同様に行われます。

バックアップ、復元、アーカイブ

MediaSense では、組み込み型のシステム レベルのバックアップと復元機能は提供されません。代わりに、システム、メタデータ、およびメディア ディスクに対し VM バックアップ方式を使用することができます。 ただし、予測不可能なパフォーマンスへの影響を考慮して、VMware 仮想マシンのスナップショット機能は、ソフトウェア アップグレード プロセスの一部として使用する以外は MediaSense で使用しないでください。


(注)  


VM バックアップを MediaSense に使用する場合は、VM はノードごとでしかバックアップされませんが、MediaSense はクラスタ モデルで機能することを理解しておくことが重要です。

そのため、拡張ノードをバックアップするときは、メタデータはプライマリおよびセカンダリ ノードに保存されているので、そのノード上の録音に関するメタデータのいずれもキャプチャされません。 同様に、プライマリ ノードをバックアップする場合は、そのプライマリ ノードに物理的に存在する録音のみをキャプチャすることになります。


他の正常な復元シナリオと同様に、そのノードの最後のバックアップまでにキャプチャされた情報のみを回復できます(最後のバックアップの後にキャプチャされた情報は失われます)。 MediaSense では、そのノードの最後のバックアップ以降にそのノードでキャプチャされた録音は失われますが、メタデータは失われません。 プライマリまたはセカンダリ ノードに保存されているメタデータはそのまま残ります(復元中のプライマリまたはセカンダリ ノードであっても)。

個々の記録されたセッション レベルでは、2 つのオプションが使用可能です。 1 つ目は、MediaSense が提供するアーカイブ機能です。これにより、設定した経過時間よりも古いすべての録音がメタデータと一緒にユーザが選択した SFTP ロケーションに mp4 形式で自動的に送信されます。 MediaSense は、2 分間の平均通話時間に基づき、十分なネットワーク帯域幅が使用できると仮定して、1 日に 1 つのノードにつき最大約 14,000 のセッションをアーカイブできます。 平均セッション時間を長くするとアーカイブの速度が遅くなります。

2 つ目は、録音を明示的に mp4 または wav 形式に変換し、選択した場所にダウンロードすることによって、個々の録音を選択的に保存することができます。 これは、どの録音をいつアーカイブするかを決定するためのビジネスに適切な選択方式を適用できるカスタム MediaSense API クライアントの制御下で実現されます。

MediaSense ノードのバックアップ

MediaSense ノードをバックアップするには、次の手順を使用します。

はじめる前に OVF にエクスポートする前にすべての CD/DVD/フロッピーが仮想マシンから切断されていることを確認します。 仮想マシンは、VMware インストール/アップグレード ツールに接続してはいけません。
手順
    ステップ 1   VMware vSphere クライアントで、vCenter Server の IP アドレスまたはホスト名を使用して、ルート ユーザ名およびパスワード クレデンシャルを入力し、VMware vSphere Hypervisor 5.1 サーバにログインして接続します。 [vSphere Client] ウィンドウが表示されます。
    ステップ 2   バックアップを実行する仮想マシンの電源をオフにします。 これには、次の 2 つの方法があります。
    • 仮想マシンを右クリックし、[Power] > [Power Off] を選択します。
    • メニュー バーで、[Inventory] > [Virtual Machine] > [Power] > [Power Off] を選択します。
    確認メッセージが表示されます。
    ステップ 3   [Yes] をクリックします。 選択した仮想マシンの電源がオフになります。
    ステップ 4   メニュー バーで、[File] > [Export] > [Export OVF Template] を選択します。 [Export OVF Template] 画面が表示されます。
    ステップ 5   [Export OVF Template] 画面で、次の手順を実行します。
    1. デフォルトでは、システムに選択した仮想マシンの名前が表示されます。

      (注)      仮想マシンの名前をメモしておくことを推奨します。

    2. [Directory] テキスト ボックスに、バックアップを実行するフォルダまたはディレクトリのパスを入力します。 [Browse] アイコンをクリックすることで場所を確認できます。
    3. [Format] ドロップダウン リストから、[Folder of Files (OVF)] を選択します。
    4. [Description] テキスト ボックスに、バックアップの説明を入力します。
    5. [OK] をクリックして、バックアップを続行します。
    [Exporting] ダイアログ ボックスが表示され、バックアップの進行状況の割合が表示されます。

    次の作業

    バックアップを指定した場所に保存した後、仮想マシンを復元できます。

    バックアップからの MediaSense ノードの復元

    バックアップから MediaSense ノードを復元するには、この手順を使用します。

    はじめる前に

    仮想マシンを復元する前に、復元元のバックアップを 1 つ作成する必要があります。

    手順
      ステップ 1   VMware vSphere クライアントで、vCenter Server の IP アドレスまたはホスト名を使用して、ルート ユーザ名およびパスワード クレデンシャルを入力し、VMware vSphere Hypervisor 5.1 サーバにログインして接続します。 [vSphere Client] ウィンドウが表示されます。
      ステップ 2   [File] > [Deploy OVF Template] の順に選択します。 [Deploy OVF Template] が表示されます。
      ステップ 3   MediaSense の復元元のパスを入力するか参照して [Next] をクリックします。 選択した OVF テンプレートの詳細が表示されます。
      ステップ 4   配置済みテンプレートの名前と場所を入力し、[Next] をクリックします。

      (注)      名前はインベントリ フォルダ内で一意にする必要があります。

      ステップ 5   仮想マシン ファイルの保存場所を選択し、[Next] をクリックします。
      ステップ 6   保存する仮想ディスクの形式を選択し、[Next] をクリックします。 導入設定が表示されます。
      ステップ 7   [Finish] をクリックして展開を開始します。 [Deploying Test] 画面が表示され、展開の進捗が表示されます。

      ネットワークの冗長性と NAT

      ネットワークの冗長性機能(NIC チーミングなど)は、ハードウェア レベルで提供されてハイパーバイザによって管理される場合があります。 MediaSense 自体は、ネットワークの冗長性に関与することはなく、まったくそれを認識しません。

      ネットワーク アドレス変換(NAT)は、MediaSense の検索と再生アプリケーションを実行するデスクトップなどの API クライアント マシンを含むいかなるピア デバイスと MediaSense との間でも使用できません。 任意の MediaSense ノードは 1 つの IP アドレスによってのみ認識できます。 さまざまな API 応答とリダイレクトには内部メディア リソースにアクセスするための完全な URL が含まれます。 クライアントが認識していない IP アドレスを使用するように埋め込んだ URL は正常に機能しません。