Cisco Unified MeetingPlace プランニング ガイド
Cisco Unified MeetingPlace Release 7.0 システムの冗長性の計画
Cisco Unified MeetingPlace Release 7.0 システムの冗長性の計画
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 1MB) | フィードバック

目次

Cisco Unified MeetingPlace Release 7.0 システムの冗長性の計画

アプリケーション サーバのフェールオーバー オプションについて

アプリケーション サーバの冗長性のしくみ

アプリケーション サーバ冗長性の要件

アプリケーション サーバのサイト間フェールオーバーの設定について

サイト内フェールオーバーの制限と要件

アプリケーション サーバのディレクトリ サービスによるサイト間フェールオーバーの設定について

Web サーバのロード バランシング オプションについて

Cisco Unified MeetingPlace アプリケーション サーバと Web サーバの通信の方法について

Web 会議 クラスタ

Web 会議 ロード バランシングとフェールオーバー機能

内部クラスタと外部クラスタによるロード バランシング動作

堅牢な Cisco Unified MeetingPlace Web 会議システムの推奨事項

会議コンソールのフェールオーバー時のエンドユーザ エクスペリエンス

メディア サーバのフェールオーバー オプションについて

メディア サーバの冗長性のしくみ

音声ブレードのフェールオーバー メカニズム

ビデオ ブレードのフェールオーバー メカニズム

Cisco Unified MeetingPlace Release 7.0 システムの冗長性の計画

この章は、さまざまなシステム コンポーネントの冗長性について説明し、Cisco Unified MeetingPlace Release 7.0 システムのロード バランシングやフェールオーバーなどの冗長性を設定する必要があるかどうかを判断するために役立ちます。

「アプリケーション サーバのフェールオーバー オプションについて」

「Web サーバのロード バランシング オプションについて」

「メディア サーバのフェールオーバー オプションについて」

関連トピック

冗長性、フェールオーバー、ロード バランシングをサポートするように Cisco Unified MeetingPlace Release 7.0 をインストールする方法については、『 Installation and Upgrade Guide for Cisco Unified MeetingPlace Release 7.0 』( http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_installation_guides_list.html )を参照してください。

Cisco Unified MeetingPlace システムの冗長性、フェールオーバー、ロード バランシングの設定については、『 Configuration Guide for Cisco Unified MeetingPlace Release 7.0 』( http://www.cisco.com/en/US/docs/voice_ip_comm/meetingplace/7x/english/books/admin_guides/configuration_guide_7_0.html )または管理者インターフェイスのオンライン ヘルプを参照してください。

アプリケーション サーバのフェールオーバー オプションについて

この項の情報を使用して、Cisco Unified MeetingPlace システムに必要なアプリケーション サーバのフェールオーバーの種類を決定します。

「アプリケーション サーバの冗長性のしくみ」

「アプリケーション サーバ冗長性の要件」

「アプリケーション サーバのサイト間フェールオーバーの設定について」

「アプリケーション サーバのディレクトリ サービスによるサイト間フェールオーバーの設定について」

アプリケーション サーバの冗長性のしくみ

アプリケーション サーバの冗長性では、アクティブとスタンバイの 2 つのアプリケーション サーバを 1 つの論理サイトの一部として展開します。常に 1 つだけのアプリケーション サーバがアクティブになります 。アクティブなアプリケーション サーバはすべてのプロセスおよびサブシステムを実行し、スタンバイ アプリケーション サーバはデータベースと Apache Tomcat プロセスおよびサブシステムのみを実行します。

各アプリケーション サーバは、ユーザ、グループ、会議に関する情報を格納する Informix データベースを備えています。システムは Informix Enterprise Replication(ER)機能を使用して、一方のアプリケーション サーバのデータベースの変更を、他方のアプリケーション サーバのデータベースに自動的に転送します。

アクティブなアプリケーション サーバで障害が発生した場合は、スタンバイ アプリケーション サーバをアクティブにし、以前のアクティブ アプリケーション サーバをスタンバイ モードにすることができます。サイト内の各アプリケーション サーバはノードと呼ばれます。

展開に、メディア サーバの 1 対 1 の冗長性が含まれる場合、メディア サーバをアクティブなアプリケーション サーバに関連付け、冗長メディア サーバをスタンバイ アプリケーション サーバに関連付けます。プライマリおよびスタンバイ アプリケーション サーバが共通のメディア サーバを共有する場合、メディア サーバを両方のアプリケーション サーバに追加します。

2 つのいずれかの方法で、システムのアプリケーション サーバの冗長性を設定できます。

両方のデータベースを同時に変更できないようにするサイト内フェールオーバーを使用する。「アプリケーション サーバのサイト間フェールオーバーの設定について」を参照してください。

両方のデータベースを同時に変更できるサイト間フェールオーバーを使用する。「アプリケーション サーバのディレクトリ サービスによるサイト間フェールオーバーの設定について」を参照してください。


) Cisco Unified MeetingPlace は、サイト内フェールオーバーとサイト間フェールオーバーの組み合わせをサポートしていません。


アプリケーション サーバ冗長性の要件

スタンバイ アプリケーション サーバには独自の一連のライセンスが必要です。アクティブ アプリケーション サーバに使用するライセンスは、スタンバイ アプリケーション サーバで機能しません。

両方のアプリケーション サーバ セット間およびアプリケーション サーバと Web サーバ間で、時間を同期させる必要があります。

アクティブ アプリケーション サーバとスタンバイ アプリケーション サーバは、次の 2 つの条件が満たされていれば、異なる物理的な場所に配置できます。

共に同じ VLAN 上に構成されている。

専用のフェールオーバー メディア サーバがある。

フェールオーバーには 250 kbps の帯域幅が必要です。

他のサーバに複製されるデータの取得の遅延に影響するレイテンシの最小要件はありません。

ネットワークは 60 秒ごとに、2 つの複製するデータベース間でハートビートを送信します。応答がない場合、ネットワークは応答のなかったデータベースを ping します。データベースがまだ応答しない場合、システムはハートビートによってデータベースが復旧したことが検出されるまで、すべてのデータをバッファします。次に、ネットワークは以前に応答していなかったデータベースに更新された情報を送信します。

アプリケーション サーバのサイト間フェールオーバーの設定について

この展開では、ユーザ、グループ、会議に関連するデータを共有する 2 つのアプリケーション サーバまたはノードを含む 1 つのサイトがあります。ただし、アクティブにできるアプリケーション サーバは常に 1 つだけです。サイトあたり最大 2 つのアプリケーション サーバを使用できます。

システムは 2 つのデータベース間でデータを復元します。システムはユーザ、グループ、会議情報を格納するデータベース テーブルへの同時変更を許可しません。

2 つのアプリケーション サーバ間でネットワークの切断が発生し、両方のアプリケーション サーバのデータベースで特定のレコードが変更された場合、システムは更新タイムスタンプを使用して、競合を解決します。接続が復元されると、最新の更新が両方のサーバに転送されます。

図 3-1 サイト内フェールオーバー

サイト内フェールオーバーの制限と要件

2 つのアプリケーション サーバ間で時間を同期させる必要があります。これは、両方のアプリケーション サーバでデータの同じ部分が同時に変更された場合の競合を解決するために必要です。

フェールオーバー展開の場合、プライマリ アプリケーション サーバとスタンバイ アプリケーション サーバは、データベース複製目的で、TCP ポート 2008 を使用して通信します。システムは、サーバ間の TCP ポート 2008 での通信を許可する必要があります。

次のホスト名と IP アドレスを割り当てます。

ノード 1 eth0 とノード 2 eth0:ノード 1 とノード 2 の両方で、eth0 ネットワーク インターフェイスに同じホスト名と IP アドレスを使用します。例:meetings.example.com、10.0.0.1

ノード 1 eth0:1:この仮想ネットワーク インターフェイスには一意のホスト名と IP アドレスを使用します。例:meetings1.example.com、10.0.0.2

ノード 2 eth0:1:この仮想ネットワーク インターフェイスには一意のホスト名と IP アドレスを使用します。例:meetings2.example.com、10.0.0.3

ドメイン ネーム システム(DNS)サーバに 3 つすべてのホスト名と IP アドレスのペアが設定されていることを確認します。

アプリケーション サーバのディレクトリ サービスによるサイト間フェールオーバーの設定について

この展開により、2 つの異なるサイトにある 2 つの同時にアクティブなインターコネクトされたアプリケーション サーバまたはノードを使用できます。この構成は、アプリケーション サーバで、同じ一連のユーザ プロファイル(LDAP サーバからの)とユーザ グループを使用する必要がある場合に便利です。

一方のアプリケーション サーバが Cisco Unified Communications Manager を通じて、LDAP サーバからユーザ データを取得し、次にデータベースの複製により、アプリケーション サーバが同期されます。

ユーザ プロファイルとユーザ グループの同期以外に、アプリケーション サーバは独立しており、異なる Web サーバに関連付けられます。アプリケーション サーバに接続しているユーザには、ユーザ プロファイルとユーザ グループを除いて、異なる設定データ(会議など)が表示されます。この展開により、ユーザは、一方のサーバで障害が発生した場合に、他方のサーバで予約不要の会議を実施できます。この構成は、一般に RSNA(予約不要シングル ナンバー アクセス)展開で使用します。

図 3-2 サイト間フェールオーバー

Web サーバのロード バランシング オプションについて

Cisco Unified MeetingPlace Web 会議 のロード バランシングでは、Web サーバのクラスタを利用して、アクティブな会議の負荷を分散させることで、展開でサポートできる会議の数とサイズを拡大できます。さらに、これにより、会議にフェールオーバ機能も提供します。一方の Cisco Unified MeetingPlace Web サーバが使用できないか、到達不能の場合に、会議参加者は、接続が中断されたときに実行中の会議に現在接続している場合でも、他方の Web サーバに再接続できます。

Web サーバあたりの Web 会議の負荷の量は、Web サーバ管理ページから表示できます。この情報は、内部 Web サーバにのみ表示されます。

クラスタを使用して、Cisco Unified MeetingPlace システムの Web 会議部分のロード バランスを行うことをお勧めします。Cisco Unified MeetingPlace ロード バランシング Web サーバ クラスタでは、すべてのユーザが指定された Cisco Unified MeetingPlace Web サーバを経由して、Cisco Unified MeetingPlace システムに入る必要があります。ロード バランシング Web サーバ クラスタ展開では、指定した Cisco Unified MeetingPlace Web サーバにのみ選択した認証方法を設定する必要があります。クラスタの他のすべての Web サーバはデフォルトの認証方法の MeetingPlace Web フォーム認証を使用します。ただし、フェールオーバー戦略として、クラスタの他の Web サーバを、同じ認証方法を使用するように設定する必要がある場合は、そのようにできます。使用する認証方法の種類によっては、この設定により、望ましくない System Security Officer(SSO; システム セキュリティ オフィサ)の動作が発生する可能性があります。

たとえば、HTTP 基本認証または Windows 統合認証を設定する場合、Cisco Unified MeetingPlace によって、Web サーバのリダイレクトが発生するたびに、ログイン資格情報の入力が求められます。これは、DNS の変更により、アクティブ Web サーバにトラフィックがリダイレクトされるたびに、認証設定のホスト名を変更することになるためです。LDAP または MeetingPlace 認証を設定する場合、Web 会議のリダイレクト時に、ユーザはログイン資格情報の再入力を求められます。

この項の情報を使用して、Cisco Unified MeetingPlace システムの Web 会議部分に必要なロード バランシング設定を決定します。

「Cisco Unified MeetingPlace アプリケーション サーバと Web サーバの通信の方法について」

「Web 会議 クラスタ」

「Web 会議 ロード バランシングとフェールオーバー機能」

「内部クラスタと外部クラスタによるロード バランシング動作」

「堅牢な Cisco Unified MeetingPlace Web 会議システムの推奨事項」

「会議コンソールのフェールオーバー時のエンドユーザ エクスペリエンス」

Cisco Unified MeetingPlace アプリケーション サーバと Web サーバの通信の方法について

Cisco Unified MeetingPlace レプリケーション サービスはローカル Web サーバのデータベースと Cisco Unified MeetingPlace アプリケーション サーバのデータベースを自動的に同期させて、会議、ユーザ プロファイル、ユーザ グループ情報を更新します。次の操作がデフォルトで実行されます。

同期は 60 秒ごとに行われます。

ユーザ プロファイルの更新間隔は 20 日ごとに更新します。

グループ更新間隔は 20 日ごとに更新します。

会議情報は 60 秒ごとに更新します。

レプリケーション サービスは Cisco Unified MeetingPlace アプリケーション サーバの添付と記録物をコピーし、複製されたファイルを Cisco Unified MeetingPlace Web サーバに保存します。これらのファイルのポインタがデータベースに作成されます。レプリケーション サービスはネイティブ Cisco Unified MeetingPlace 音声(.mp4)形式で音声ファイルをダウンロードします。音声ファイルのダウンロード後、レプリケーション サービスは音声サービスによる会話のジョブをキューに入れます。

さらに、レプリケーション サービスは、アプリケーション サーバから、ビデオ端末ユーザ プロファイル情報を複製します。デフォルトで、この複製は 7 日ごとに行われます。

システムの障害発生時には、レプリケーション サービスの更新および削除操作を手動で起動できます。レプリケーション サービスへの変更が有効になるまで最大 20 分かかります。レプリケーション サービスの起動方法については、『 Configuration Guide for Cisco Unified MeetingPlace Release 7.0 』( http://www.cisco.com/en/US/docs/voice_ip_comm/meetingplace/7x/english/books/admin_guides/configuration_guide_7_0.html )または管理者インターフェイスのオンライン ヘルプを参照してください。

Web 会議 クラスタ

Cisco Unified MeetingPlace を使用して、最大 3 つの Web サーバをクラスタに設定でき、クラスタを内部または外部として設定できます。システムでは内部クラスタと外部クラスタを使用できます。

内部クラスタ :企業のプライベート ネットワーク内のファイアウォールの背後に、すべての Web サーバを配置します。一般に内部クラスタのすべての Web サーバにはフルアクセス Cisco Unified MeetingPlace インターフェイスが表示されます。

外部クラスタ :DMZ 内などの企業のプライベート ネットワークとインターネット間にすべての Web サーバを配置します。セキュリティ向上のため、外部クラスタのすべての Web サーバには一般に、参加専用の Cisco Unified MeetingPlace インターフェイスが表示されます。

Cisco Unified MeetingPlace Web サーバは SQL データベースを使用して、プロファイルおよび会議情報を保存します。Cisco Unified MeetingPlace Web サーバ クラスタを展開する場合、内部クラスタと外部クラスタで、個別の SGL データベースを使用する必要があります。ただし、2 つのデータベースに同一のグローバル一意識別子(GUID)が必要です。Cisco Unified MeetingPlace Web サーバのフェールオーバーの設定の詳細については、『 Configuration Guide for Cisco Unified MeetingPlace Release 7.0 』( http://www.cisco.com/en/US/docs/voice_ip_comm/meetingplace/7x/english/books/admin_guides/configuration_guide_7_0.html )または管理者インターフェイスのオンライン ヘルプを参照してください。

ロード バランシングは共有のストレージ場所に影響しません。クラスタのすべてのサーバは同じ共有のストレージ場所を使用します。

Web 会議では、図 3-3図 3-4図 3-5 に示すように、3 つの可能なロード バランシング設定をサポートします。

図 3-3 1 つのクラスタ設定

 

1

Cisco Unified MeetingPlace システム

2

Cisco Unified MeetingPlace Web サーバ クラスタ:内部クラスタまたは外部クラスタを指定できます。

3

SQL サーバ:クラスタのすべての Web サーバは同じ SQL Server に接続する必要があります。

--

図 3-4 混合構成:Web サーバの内部クラスタと外部クラスタ

 

1

Cisco Unified MeetingPlace システム

2

Web サーバの内部クラスタ

3

SQL サーバ:内部クラスタのすべての Web サーバは同じ SQL サーバに接続する必要があります。

4

Web サーバの外部クラスタ

5

SQL サーバ:外部クラスタのすべての Web サーバは同じ SQL サーバに接続する必要があります。

--

図 3-5 混合構成:1 つの Web サーバと Web サーバのクラスタ

 

1

Cisco Unified MeetingPlace システム

2

Web サーバのクラスタ:内部クラスタまたは外部クラスタを設定できます。

3

SQL サーバ:クラスタのすべての Web サーバは同じ SQL サーバに接続する必要があります。

4

単一 Web サーバ:内部 Web サーバまたは外部 Web サーバを指定できます。

5

SQL サーバ:単一の Web サーバは個別の SQL サーバに接続する必要があります。

--

Web 会議 ロード バランシングとフェールオーバー機能

各 Web サーバは、元のサーバと第 2 サーバの 2 つの個別のロード バランシング コンポーネントから構成されます。会議は元のサーバでホストされます。参加者は会議に参加する際に、第 2 サーバに接続します。これらのコンポーネントは、次のように対話して、ロード バランシングとフェールオーバー機能を提供します。

会議が開始されると、指定した Web サーバ(会議通知に示される Web サーバ)が、現在のアクティブな会議の負荷に基づいて、プライマリおよびバックアップの元のサーバを会議室に割り当てます。

参加者が会議に参加すると、その時点で各第 2 サーバに現在接続している参加者数に基づいて、参加者がクラスタの第 2 サーバにロード バランスされます。第 2 サーバは、内部で会議をホストしている元のサーバとの接続を確立します。

会議室の起動時に、サーバによって、各クライアントに、プライマリおよびバックアップの元のサーバ情報が与えられます。クライアントの設定は必要ありません。

図 3-6 に、Web サーバのクラスタによるロード バランシング トポロジの例を示します。会議は、それぞれの会議の負荷に基づいて、クラスタの 3 つの元のサーバに分散されます。参加者は、それぞれの参加者の負荷に基づいて、クラスタの 3 つの第 2 サーバに分散されます。参加者は、必ずしも参加している会議をホストする元の Web サーバに対応する第 2 サーバに接続されるとは限りません。

図 3-6 Web 会議 会議と参加者のロード バランシング

内部クラスタと外部クラスタによるロード バランシング動作

すべてのユーザが Cisco Unified MeetingPlace Web 会議に参加するには、ブラウザを開き、Cisco Unified MeetingPlace Web 会議ホーム ページからサインインします。最初の会議参加者が Web 会議に参加しようとすると、システムは、[外部 Web 参加者を許可] パラメータをチェックして、会議を内部 Web サーバで開催するか、外部 Web サーバで開催するかを判断します。このパラメータは Cisco Unified MeetingPlace システムに外部サイトまたはクラスタが設定されている場合にのみ表示されます。

表 3-1 に、ロードバランシング設定オプションのロードバランシング動作について説明します。

 

表 3-1 Cisco Unified MeetingPlace Web 会議 のロード バランシング動作

設定
動作

[外部 Web 参加者を許可] を [いいえ] に設定

この会議は内部参加者専用に予約されます。最初の参加者が会議コンソールを起動すると、指定された Web サーバが、内部クラスタで現在アクティブな会議が最も少ない Web サーバに Web 会議セッションを誘導します。この新しい Web サーバが会議をホストするようになります。後続の参加者は、Web 会議の参加時にいずれかの内部 Web サーバに誘導されます。

[外部 Web 参加者を許可] を [はい] に設定

この会議は、外部参加者、つまりファイアウォールの外側から参加する参加者がアクセスできます。

最初の参加者が外部 Web サーバから Web 会議に参加しようとすると、指定された Web サーバが、外部クラスタで現在アクティブな会議が最も少ない Web サーバに Web 会議セッションを誘導します。この新しい Web サーバが会議をホストするようになります。後続の参加者は、Web 会議の参加時にいずれかの外部 Web サーバに誘導されます。

最初の参加者が内部 Web サーバから Web 会議に参加しようとすると、Cisco Unified MeetingPlace は外部 Web サーバが関連付けられているかどうかを判断します。それらの情報は、Web サーバのプロパティの管理ページの [DMZ Web サーバ] フィールドにあります。

[DMZ Web サーバ] フィールドにエントリがある場合、Cisco Unified MeetingPlace は会議をその外部サーバにリダイレクトします。Web サーバ、指定された Cisco Unified MeetingPlace 外部 Web サーバは、外部クラスタで現在アクティブな会議が最も少ない Web サーバに Web 会議セッションを誘導します。この Web サーバ(元のサーバ)が会議を所有(ホスト)するようになります。後続の参加者は、Web 会議の参加時にいずれかの外部 Web サーバ(第 2 サーバ)に誘導されます。

Cisco Unified MeetingPlace が [DMZ Web サーバ] フィールドにエントリを見つけられなかった場合、負荷が最も少ない内部 Web サーバに会議がリダイレクトされます。後続のすべての会議参加者が、Web 会議用の内部 Web サーバに誘導されます。

内部ユーザは内部会議にも外部会議にも参加できます。会議が外部として指定されている場合、内部 Web サーバにログインした内部ユーザは、外部 Web サーバにリダイレクトされます。

外部ユーザは外部 Web サーバの外部会議にのみ参加できます。

堅牢な Cisco Unified MeetingPlace Web 会議システムの推奨事項

冗長性とフェールオーバーを備えた堅牢なシステムを確保するには、Web 会議の展開に次を含めることをお勧めします。

内部 Web クラスタ

外部 Web クラスタ

各クラスタ専用のリモート SQL サーバシステム

適切なサイズの RAID アレイを備えたリモートのストレージ場所と包括的なバックアップ ポリシー

会議コンソールのフェールオーバー時のエンドユーザ エクスペリエンス

冗長性とフェールオーバー用に設定されたシステムでフェールオーバーが発生すると、次の動作が行われます。

1. ユーザが接続している Web サーバが応答を停止します(たとえば、Web サーバの電源が切断されるか、Web 会議 サービスが終了します)。

2. その Web サーバの第 2 サーバに接続しているユーザは、会議への接続が失われます。

3. 各会議コンソール クライアントは自動的にユーザを第 2 サーバに再接続しようとします。この試みが失敗すると、会議コンソールはその会議のバックアップとして指定された第 2 サーバに接続を試みます(クライアントが初めて会議に接続すると、Web サーバは割り当てられたプライマリおよびバックアップ第 2 サーバ情報を各クライアントに送信します)。

メディア サーバのフェールオーバー オプションについて

「メディア サーバの冗長性のしくみ」

「音声ブレードのフェールオーバー メカニズム」

「ビデオ ブレードのフェールオーバー メカニズム」

メディア サーバの冗長性のしくみ

メディア サーバは、会議数ではなく、リソースの使用状況に基づいてロード バランシングを行います。システムが新しい会議の要求を受け取ると、メディア サーバはすべての音声ブレードをチェックし、現在転送している負荷が最も軽い音声ブレードを選択して会議を作成します。

メディア サーバで障害が発生すると、システムは自動的にフェールオーバーを実行するため、手動の設定は必要ありません。

メディア サーバの冗長性について、次のオプションから選択できます。

アプリケーション サーバに追加の音声ブレードを設定する。これがビデオの展開の場合、音声ブレードには独自のビデオ ブレードが必要です。

スタンバイ アプリケーション サーバに接続されているスタンバイ メディア サーバを使用する。スタンバイ メディア サーバはプライマリ メディア サーバより小さくてもかまいません。

これらの 2 つのオプションは相互に排他的ではありません。両方をお勧めします。単一のブレード(音声ブレードまたはビデオ ブレード)で障害が発生した場合、アプリケーション サーバはアラームを生成し、自動的に新しいコールを追加のブレードに割り当てます。メディア サーバ全体で障害が発生した場合、スタンバイ システムを使用します。

冗長の音声およびビデオ ブレードに、音声およびビデオ ポート ライセンスは必要ありません。

音声ブレードのフェールオーバー メカニズム

音声ブレードのフェールオーバー メカニズムは次のようになります。

1. アプリケーション サーバはアクティブな音声ブレードのリストを保持します。

2. 音声ブレードで障害が発生すると、数秒後にタイム アウトし、アプリケーション サーバによって、アクティブな音声ブレードのリストからそのブレードが削除されます。


) アプリケーション サーバは、障害の発生した音声ブレードと、ネットワークの問題のために通信できない音声ブレードを区別できません。


3. アプリケーション サーバは、アラーム「Audio Blade is down: <IP address> (音声ブレードがダウンしています:<IP address>)」を生成します。ここで <IP address> は障害の発生した音声ブレードの IP アドレスです。

4. アプリケーション サーバは障害の発生した音声ブレードの既存のすべてのコールを破棄します。

5. 障害の発生した音声ブレードでホストされていた会議に、新しい発信者が参加すると、アプリケーション サーバは別の音声ブレードで会議を再開し、発信者が参加できるようにします。

ビデオ ブレードのフェールオーバー メカニズム

ビデオ ブレードのフェールオーバー メカニズムは次のようになります。

1. アプリケーション サーバは、そのビデオ ブレードでホストされている会議から、ただちにビデオを破棄し、会議を音声のみに切り替えます。

2. その会議への新しいコールには、ビデオが提供されません。

3. アプリケーション サーバは、アラーム「Video Blade is down: <IP address> (ビデオ ブレードがダウンしています:<IP address>)」を生成します。ここで <IP address> は障害の発生したビデオ ブレードの IP アドレスです。

4. アプリケーション サーバは、ビデオを必要とするすべての新しい会議を、別のビデオ ブレードが使用できる場合にそれに割り当てます。使用できるビデオ リソースがない場合、アプリケーション サーバは音声専用で会議を開始します。