在CMS群集中使用maxPeerVideoStreams引數時的預期行為

簡介

本文描述在思科會議伺服器(CMS)群集中使用引數maxPeerVideoStreams時的預期行為。 

管理員快速參考指南中提到了此引數。 

必要條件

需求

思科建議您瞭解以下主題：

• Cisco Meeting Server Call Bridge元件（及其集群）
• Cisco Meeting Server API配置

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• CMS 2.9.x

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

什麼是maxPeerVideoStreams引數？它何時生效？

maxPeerVideoStreams引數首次引入CMS版本2.3。此引數控制CMS伺服器可通過分散式呼叫向其他CMS伺服器傳送多少參與影片流。需要在每個CMS伺服器上單獨設定。 當每個CallBridge上的參與者超過4個時，maxPeerVideoStreams引數對於大型分散式會議有效。

註:maxPeerVideoStreams只與包含兩台或多台伺服器的CMS集群相關，與單個CMS伺服器無關。 

如果未設定maxPeerVideoStreams，則CMS的預設行為是通過分散式呼叫向其他CMS伺服器傳送最多4個影片流，這是CMS 2.3之前的行為。在CMS 2.3及更高版本中，現在可以更改該行為並配置CMS以通過分散式呼叫傳送最多9個影片流，而不是僅傳送4個影片流。

通過大型會議、託管大量參與者以及使用AllEqual布局（允許單個參與者螢幕上最多顯示25個窗格），此引數的重要性變得更為明顯。在這種情況下，如果會議分佈在兩台CMS伺服器（例如CMS1和CMS2）上，並且在該會議的每個CMS伺服器上託管超過4個參與者（5個或更多），則託管在CMS1上的參與者只能看到來自託管在CMS2上的遠端參與者的最多4個參與者的影片，以及來自託管在其本地CMS(CMS1)伺服器主機上的所有其他本地參與者的影片，即使CMS2當前有8個活動參與者也是如此。這同樣適用於CMS2上託管的參與者 — 即使CMS1有10個活動參與者，它們也只能看到來自CMS1上託管的遠端參與者的最多4個參與者的影片和同一CMS2上託管的其它參與者的影片。

註:maxPeerVideoStreams仍是beta（預覽）功能。 

部署和方案示例

本檔案中的資訊是根據以下範例部署：

• CMS集群，包含兩個伺服器：CMS1和CMS2
• 在這些伺服器上配置的Loadlimit允許在呼叫分配啟動後進行17次呼叫
• 為CMS伺服器配置的CUCM路由組具有循環分布
• 使用AllEqual佈局（即5x5），這是為了允許最大可能的參與者窗格，即25
• 30個參與者正在加入space1，它在CMS1上具有優先順序（用於負載平衡）

1. maxPeerVideoStreams設定為4，同時啟用負載均衡

• 由於啟用了loadbalancing，並且space1的優先順序在CMS1上，因此前17個參與者將加入CMS1，直到達到其完全容量。即將到來的參與者18加入CMS2並建立分散式呼叫

maxPeerVideoStreams設定為4，且啟用了負載均衡

• CMS1有17名參與者(1 - 17),CMS2有13名參與者(18 - 30)  
• 參與者1 - 17會看到來自CMS1的其他16個本地參與者，除了來自CMS2的僅4個參與者之外，總共20個參與者顯示在參與者1 - 17的螢幕上
• 參與者18 - 30會看到來自CMS2的其他12個本地參與者，除了來自CMS1的僅4個參與者之外，總共16個參與者顯示在參與者18 - 30的螢幕上
• 總而言之：CMS1託管的參與者可看到20個參與者，CMS2託管的參與者可在他們的螢幕上看到16個參與者

2. maxPeerVideoStreams設定為4，同時禁用負載均衡

• 由於loadbalancing未啟用，因此參與者從第二次呼叫開始在兩個CMS伺服器上加入會議。這是因為CUCM路由組設定為circular，這意味著呼叫按順序傳送到兩個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上加入直到達到其完全容量。即將到來的參與者18加入CMS2並建立分散式呼叫

maxPeerVideoStreams設定為9，同時啟用負載均衡

• CMS1有17名參與者(1 - 17),CMS2有13名參與者(18 - 30)  
• 參加者1-17見來自CMS1的其他16名本地參與者，除了CMS2的9名參與者之外，共有25名參與者顯示在參加者1-17的螢幕上
• 參與者18 - 30會見CMS2中的其他12名本地參與者，除了CMS1中的9名參與者之外，共有21名參與者顯示在參與者18 - 30的螢幕上
• 簡而言之：CMS1參與者可看到25個參與者，CMS2參與者可在螢幕上看到21個參與者

4. maxPeerVideoStreams設定為9，同時禁用負載均衡

• 由於loadbalancing未啟用，因此參與者從第二次呼叫開始在兩個CMS伺服器上加入會議。這是因為CUCM路由組設定為circular，這意味著呼叫按順序傳送到兩個CMS伺服器。呼叫1傳送到CMS1，呼叫2傳送到CMS2，呼叫3傳送到CMS1，呼叫4傳送到CMS2
• 這意味著預計在每個CallBridge上託管的參與者有15名，其中15名在CMS1上，15名在CMS2上

maxPeerVideoStreams設定為9，同時禁用負載平衡

• CMS1上的參與者會看到來自CMS1的其他14個本地參與者，除了CMS2的9個參與者之外，CMS1參與者的螢幕上還顯示總共23個參與者
• CMS2上的參與者會看到來自CMS2的其他14個本地參與者，除了CMS1的9個參與者之外，CMS2參與者的螢幕上還顯示總共23個參與者
• 總而言之：CMS1參與者和CMS2參與者均在其螢幕上看到23個參與者

疑難排解

目前尚無適用於此組態的具體疑難排解資訊。

您可以使用Collaboration Solutions Analyzer工具進行日誌分析。

相關資訊

• 思科會議伺服器上的負載平衡邏輯
• CMS配置文檔
• CMS API和MMP程式設計指南