CMSクラスタでmaxPeerVideoStreamsパラメータを使用する場合の予想される動作

はじめに

このドキュメントでは、Cisco Meeting Server(CMS)クラスタでパラメータmaxPeerVideoStreamsを使用する場合に予想される動作について説明します。 

このパラメータについては、『管理者クイックリファレンスガイド』を参照してください。 

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Meeting Server Call Bridgeコンポーネント（およびそのクラスタリング）
• Cisco Meeting Server APIの設定

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• CMS 2.9.x（2015年9月）

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

maxPeerVideoStreamsパラメータとは何ですか。また、いつから有効になりますか。

maxPeerVideoStreamsパラメータは、CMSバージョン2.3で初めて導入されました。このパラメータは、CMSサーバが別のCMSサーバに分散コールで送信できる参加者ビデオストリームの数を制御します。各CMSサーバに個別に設定する必要があります。 maxPeerVideoStreamsパラメータは、各CallBridgeに4人以上の参加者がいる大規模な分散型の会議に有効です。

注:maxPeerVideoStreamsは2つ以上のサーバで構成されるCMSクラスタでのみ使用でき、1台のCMSサーバでは使用できません。 

maxPeerVideoStreamsが設定されていない場合、CMSのデフォルトの動作では、他のCMSサーバへの分散型コールで最大4つのビデオストリームを送信します。これは、CMS 2.3より前の動作でした。CMS 2.3以降では、この動作を変更し、CMSを設定して最大9つのビデオストリームを分散コール経由で送信するように設定できるようになりました。この設定は4つだけのストリームではありません。

このパラメータの重要性は、大規模な会議や多数の参加者のホスティング、AllEqualレイアウトの使用によって明確になります。このレイアウトでは、1人の参加者の画面に最大25のペインを表示できます。この場合、会議が2台のCMSサーバ（CMS1とCMS2など）に分散され、この会議の各CMSサーバで4人以上の参加者がホストされている場合（5人以上）、CMS2にホストされている参加者は、ローカルCMS(CMS1)サーバホストでホストされている他のすべてのローカル参加者のビデオに加えて、CMS1でホストされている参加者は最大4人のビデオしか表示できません。CMS2でホストされている参加者も同様です。CMS1にアクティブな参加者が10人いる場合でも、CMS1でホストされているリモート参加者の最大4人のビデオと、同じCMS2でホストされている他の参加者のビデオのみを表示できます。

注:maxPeerVideoStreamsは引き続きベータ（プレビュー）機能です。 

導入例とシナリオ

このドキュメントの情報は、次の導入例に基づいています。

• 2台のサーバ（CMS1とCMS2）のCMSクラスタ
• これらのサーバに設定されたLoadlimitは、そのコール分配が開始された後、17コールを許可します
• CMSサーバのCUCMルートグループが循環分散で設定されている
• AllEqualレイアウトが使用されます(5x5)。これは、参加者ペインの最大数である25を許可するためです
• 30人の参加者がspace1に参加しています。このスペースは、CMS1上でプライオリティ（ロードバランシング用）を設定しています

1. maxPeerVideoStreamsを4に設定し、loadBalancingを有効にする

• ロードバランシングが有効で、space1の優先順位がCMS1にあるため、CMS1が最大容量に達するまで、最初の17人の参加者がCMS1に参加します。次の参加者18がCMS2に参加し、分散コールが作成されます

ロードバランシングが有効なmaxPeerVideoStreamsを4に設定する

• CMS1には17人(1 ～ 17)、CMS2には13人(18 ～ 30)の参加者がいます  
• 参加者1 ～ 17には、CMS1の他の16人のローカル参加者が表示されます。CMS2の参加者は4人のみですが、参加者1 ～ 17の画面には合計20人の参加者が表示されます
• 参加者18～30名にはCMS2の他の12名のローカル参加者が表示され、CMS1の4名の参加者に加えて、参加者18～30名の画面には合計16名の参加者が表示されます
• 要約すると、CMS1ホストの参加者には20人の参加者が、CMS2ホストの参加者には16人の参加者が画面に表示されます

2. maxPeerVideoStreamsを4に設定し、loadBalancingを無効にする

• ロードバランシングが有効になっていないため、参加者は2番目のコールから開始して、両方のCMSサーバで会議に参加します。これは、CUCMルートグループが循環に設定されているためです。つまり、コールは両方のCMSサーバに順次送信されます。コール1はCMS1に送信され、コール2はCMS2に送信され、コール3はCMS1に送信され、コール4はCMS2に送信されます
• これは、各CallBridgeで15人の参加者がホストされることを意味します。CMS1では15人、CMS2では15人の参加者がホストされます

maxPeerVideoStreamsを4に設定し、ロードバランシングを無効にする

• CMS1の参加者には、CMS1の他の14人のローカル参加者が表示されます。CMS2の参加者4人に加えて、合計18人の参加者がCMS1参加者の画面に表示されます
• CMS2の参加者には、CMS2の他の14人のローカル参加者が表示されます。CMS1の参加者4人に加えて、合計18人の参加者がCMS2参加者の画面に表示されます
• 要約すると、CMS1の参加者とCMS2の参加者の両方の画面に18人の参加者が表示されます

3. maxPeerVideoStreamsを9に設定し、loadBalancingを有効にする

• ロードバランシングが有効で、space1の優先度がCMS1にあるため、参加者はCMS1が最大容量に達するまでCMS1に参加します。次の参加者18がCMS2に参加し、分散コールが作成されます

loadBalancingが有効な場合、maxPeerVideoStreamsは9に設定されます

• CMS1には17人(1 ～ 17)、CMS2には13人(18 ～ 30)の参加者がいます  
• 参加者1～17人はCMS1の他の16人のローカル参加者を見ることができ、9人のCMS2参加者に加えて、合計25人の参加者が参加者1～17の画面に表示されます
• 参加者18～30名はCMS2の他の12名のローカル参加者を見ることができ、9名のCMS1参加者に加えて、合計21名の参加者が18～30名の参加者の画面に表示されます
• 要約すると、CMS1の参加者には25人、CMS2の参加者には21人の参加者が画面に表示されます

4. maxPeerVideoStreamsを9に設定し、loadBalancingを無効にする

• ロードバランシングが有効になっていないため、参加者は2番目のコールから開始して、両方のCMSサーバで会議に参加します。これは、CUCMルートグループが循環に設定されているためです。つまり、コールは両方のCMSサーバに順次送信されます。コール1はCMS1に送信され、コール2はCMS2に送信され、コール3はCMS1に送信され、コール4はCMS2に送信されます
• これは、各CallBridgeで15人の参加者がホストされることを意味します。15人の参加者はCMS1で、15人の参加者はCMS2でホストされます

maxPeerVideoStreamsを9に設定し、ロードバランシングを無効にする

• CMS1の参加者には、CMS1の他の14人のローカル参加者が表示されます。CMS2の参加者9人に加えて、合計23人の参加者がCMS1参加者の画面に表示されます
• CMS2の参加者には、CMS2の他の14人のローカル参加者が表示されます。CMS1の参加者9人に加えて、合計23人の参加者がCMS2の参加者の画面に表示されます
• 要約すると、CMS1の参加者とCMS2の参加者の両方の画面に23人の参加者が表示されます

トラブルシュート

現在のところ、この設定に関する具体的なトラブルシューティング情報はありません。

ログ分析には、Collaboration Solutions Analyzerツールを使用できます。

関連情報

• Cisco Meeting Serverのロードバランシングロジック
• CMS設定ドキュメント
• CMS APIおよびMMPプログラミングガイド