CMSクラスタでmaxPeerVideoStreamsパラメータを使用した場合の予期される動作
内容
概要
このドキュメントでは、Cisco Meeting Server(CMS)クラスタで使用されるパラメータmaxPeerVideoStreamsの予想される動作について説明します。
このパラメータについては、『アドミニストレータクイックリファレンスガイド』で説明しています。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Meeting Server Call Bridgeコンポーネント（およびそのクラスタリング）
- Cisco Meeting Server APIの設定
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- CMS 2.9.x
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
maxPeerVideoStreamsパラメータとは何ですか。また、いつ有効になりますか。
maxPeerVideoStreamsパラメータは、CMSバージョン2.3で初めて導入されました。このパラメータは、CMSサーバが別のCMSサーバに分散コールを送信できる参加者ビデオストリームの数を制御します。各CMSサーバに個別に設定する必要があります。maxPeerVideoStreamsパラメータは、各CallBridgeに4人以上の参加者がいる場合に、大規模で分散された会議に有効です。
maxPeerVideoStreamsが設定されていない場合、CMSのデフォルトの動作では、CMS 2.3より前の動作である分散コールを介して最大4つのビデオストリームを送信します。CMS 2.3以降では、動作を変更し、分散コールに9の最大ビデオストリームをを送信可能しますわずか4です
このパラメータの重要性は、大規模な会議、多数の参加者をホストし、AllEqualレイアウトを使用することで明確になります。このレイアウトにより、1人の参加者の画面に最大25個のペインを表示できます。この場合、会議が2台のCMSサーバ（CMS1とCMS2など）に分散され、この会議の各CMSサーバに4人以上の参加者がホストされている場合（5以上）、CMS1でホストされている参加者は、ローカルにホストされている他のすべての参加者からのビデオもを参照できますCMS(CMS1)サーバホスト。CMS2に現在8人のアクティブな参加者がいる場合でも同様です。CMS2でホストされる参加者も同様です。CMS1にホストされるリモート参加者の最大4人の参加者のビデオと、CMS1に10人のアクティブな参加者がある他の参加者のビデオのみを表示できます。
導入例とシナリオ
このドキュメントの情報は、次の導入例に基づいています。
- CMS1とCMS2の2つのサーバのCMSクラスタ
- これらのサーバに設定されたLoadlimitでは、コールの分配が開始された後、17コールを許可します
- CMSサーバーのCUCMルートグループが循環配布で構成されています
- AllEqualレイアウトを使用します(5x5)。これは、最大25の参加者ペインを許可します
- 30名の参加者がspace1に参加しています。CMS1で（ロードバランシング用）が優先されます
1. maxPeerVideoStreamsが4に設定され、loadBalancingが有効
- loadbalancingが有効でspace1の優先度が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人の参加者に加えて、CMS1の参加者の画面には合計18人の参加者が表示されます
- CMS2の参加者は、CMS2の他の14人のローカル参加者を参照できます。また、CMS1の4人の参加者に加えて、CMS2の参加者の画面には合計18人の参加者が表示されます
- ここまでの内容をまとめます。CMS1参加者とCMS2参加者の両方が画面に18名の参加者を表示
を選択します。maxPeerVideoStreamsが9に設定され、loadBalancingが有効
- loadbalancingが有効で、space1の優先度がCMS1上にあるため、参加者はCMS1の最大容量に達するまで参加します。次の参加者18がCMS2に参加し、分散コールが作成されます
maxPeerVideoStreamsが9に設定され、loadBalancingが有効
- CMS1には17名(1 ～ 17)、CMS2には13名(18 ～ 30)の参加者がいます
- 参加者1 ～ 17は、CMS1からのその他の16名のローカル参加者を参照できます。また、CMS2からの9名の参加者に加え、参加者1 ～ 17の画面には合計25名の参加者が表示されます
- 参加者18～30はCMS2の他の12名のローカル参加者を見ることができ、CMS1の9名の参加者に加えて、参加者18～30の画面には合計21名の参加者が表示されます
- ここまでの内容をまとめます。CMS1参加者には25名、CMS2参加者には21名が画面に表示されます
4.maxPeerVideoStreamsが9に設定され、loadBalancingが無効になっている
- ロードバランシングが有効になっていないため、参加者は2番目のコールから開始して両方のCMSサーバの会議に参加します。これは、CUCMルートグループが循環に設定されているため、コールが両方のCMSサーバに順番に送信されるためです。コール1はCMS1に送信され、コール2はCMS2に送信され、コール3はCMS1に送信され、コール4はCMS2に送信されます
- つまり、各CallBridgeでホストされる参加者が15人あることが予想されます。CMS1には参加者が15人、CMS2には参加者が15人です
maxPeerVideoStreamsが9に設定され、ロードバランシングが無効になっている
- CMS1の参加者は、CMS1の他の14人のローカル参加者を参照できます。また、CMS2の9人の参加者に加えて、CMS1の参加者の画面には合計23人の参加者が表示されます
- CMS2の参加者は、CMS2の他の14人のローカル参加者を参照できます。また、CMS1の9人の参加者に加え、CMS2の参加者の画面には合計23人の参加者が表示されます
- ここまでの内容をまとめます。CMS1参加者とCMS2参加者の両方が画面に23名の参加者を表示
トラブルシュート
現在、この設定に使用できる特定のトラブルシューティング情報はありません。
Collaboration Solutions Analyzerツールを使用してログを分析できます。
フィードバック