CMS 클러스터에서 maxPeerVideoStreams 매개 변수를 사용하는 경우 예상되는 동작

다운로드 옵션

PDF (362.6 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (172.9 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (137.5 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2020년 10월 28일

문서 ID:215666

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 CMS(Cisco Meeting Server) 클러스터에서 사용할 경우 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 서버와는 관련이 없습니다.

maxPeerVideoStreams가 설정되지 않은 경우 CMS의 기본 동작은 다른 CMS 서버로 분산형 통화를 통해 최대 4개의 비디오 스트림을 전송하는 것입니다. 이는 CMS 2.3 이전의 동작입니다. CMS 2.3 이상을 사용하면 이제 해당 동작을 변경하고 CMS를 구성하여 분산된 통화를 4개 대신 최대 9개의 비디오 스트림을 전송할 수 있습니다.

이 매개변수의 중요성은 큰 회의, 많은 수의 참가자를 호스팅하고 AllEqual 레이아웃을 사용하여 더욱 명확해지고 단일 참가자 화면에 최대 25개의 창을 표시할 수 있습니다.이 경우 컨퍼런스가 두 개의 CMS 서버(예: CMS1 및 CMS2)에 배포되고 이 컨퍼런스를 위해 각 CMS 서버에 4명 이상의 참가자가 호스팅되는 경우(5 이상), CMS1에서 호스팅되는 참가자는 로컬 CMS(CMS1 호스트)에서 호스팅되는 다른 모든 로컬 참가자의 비디오 외에 CMS2에서 호스팅되는 원격 참가자의 최대 4명의 비디오만 볼 수 있습니다. 현재 8명의 활성 참가자가 있습니다.CMS2에서 호스팅되는 참가자도 마찬가지입니다. CMS1에 10명의 활성 참가자가 있는 경우에도 CMS1에서 호스팅되는 원격 참가자의 최대 4명의 비디오 및 동일한 CMS2에서 호스팅되는 다른 참가자의 비디오만 볼 수 있습니다.

참고:maxPeerVideoStreams는 여전히 베타(미리 보기) 기능입니다.

구축 및 시나리오 예

이 문서의 정보는 다음 구축 예를 기반으로 합니다.

두 서버, CMS1 및 CMS2의 CMS 클러스터
해당 서버에 구성된 로드 제한은 해당 통화 분배가 시작된 후 17건의 통화를 허용합니다.
CMS 서버에 대한 CUCM Route Group이 순환 배포로 구성되어 있습니다.
AllEqual 레이아웃이 사용됨 또는 5x5는 최대 참가자 창(25개)을 허용합니다.
30명의 참가자가 space1에 참여하며, 이는 CMS1에서 우선 순위(로드 밸런싱)를 가집니다.

1.maxPeerVideoStreams가 로드 밸런싱이 활성화된 상태에서 4로 설정

로드 밸런싱이 활성화되고 space1의 우선순위가 CMS1에 있으므로, 처음 17명의 참가자는 전체 용량에 도달할 때까지 CMS1에 참여합니다.예정된 참가자 18명이 CMS2에 가입하고 분산형 통화가 생성됨

최대PeerVideoStreams가 로드 밸런싱이 활성화된 상태에서 4로 설정

CMS1(1 - 17), CMS2(18 - 30)에 17명의 참가자 및 13명의 참가자
참가자 1 - 17은 CMS 2의 참가자 4명 외에 CMS 1의 다른 16명의 로컬 참가자를 볼 수 있으며, 참가자 1 - 17명의 화면에 총 20명의 참가자가 표시됩니다.
참가자 18 - 30명은 CMS2의 다른 12명의 로컬 참가자를 볼 수 있으며, CMS1의 참가자는 4명에 불과하며, 총 16명의 참가자가 18 - 30명의 참가자의 화면에 표시됩니다.
요약:CMS1 호스팅 참가자는 20명의 참가자를 볼 수 있으며, CMS2 호스팅 참가자는 화면에서 16명의 참가자를 볼 수 있습니다.

2 .maxPeerVideoStreams가 로드 밸런싱이 비활성화된 상태에서 4로 설정

부하 균형이 활성화되지 않으므로 참가자는 두 번째 통화에서 시작하는 두 CMS 서버 모두에서 회의에 참가합니다.이는 CUCM Route Group이 순환으로 설정되었기 때문입니다. 즉 통화가 두 CMS 서버로 순차적으로 전송됩니다.1번 통화가 CMS1로 전송되고, 2번 통화가 CMS2로 전송되고, 3번 통화가 CMS1로 전송되고, 4번 통화가 CMS2로 전송됩니다.
즉, 각 CallBridge에서 호스팅되는 15명의 참가자를 찾을 것으로 예상되며, CMS1에 15명의 참가자와 CMS2에 15명의 참가자가 참가합니다.

maxPeerVideoStreams가 로드 밸런싱이 비활성화되어 4로 설정되었습니다.

CMS1 참가자는 CMS2의 참가자 4명 외에 CMS1의 다른 14명의 로컬 참가자를 볼 수 있으며, 총 18명의 참가자가 CMS1 참가자의 화면에 표시됩니다.
CMS2의 참가자는 CMS1의 4명의 참가자와 CMS2의 다른 14명의 로컬 참가자를 볼 수 있으며, 총 18명의 참가자가 CMS2 참가자의 화면에 표시됩니다.
요약:CMS1 참가자 및 CMS2 참가자 모두 화면에서 18명의 참가자를 볼 수 있습니다.

3 .loadBalancing이 활성화된 상태에서 maxPeerVideoStreams를 9로 설정

부하 균형이 활성화되고 space1의 우선 순위는 CMS1에 있으므로 참가자는 CMS1에서 전체 용량에 도달할 때까지 참가합니다.예정된 참가자 18명이 CMS2에 가입하고 분산형 통화가 생성됨

loadBalancing이 활성화된 상태에서 maxPeerVideoStreams를 9로 설정

CMS1(1 - 17), CMS2(18 - 30)에 17명의 참가자 및 13명의 참가자
참가자 1 - 17은 CMS 2의 참가자 9명 외에 CMS 1의 다른 16명의 로컬 참가자를 볼 수 있으며, 총 25명의 참가자가 참가자 1 - 17명의 화면에 표시됩니다.
참가자 18 - 30명은 CMS1의 참가자 9명 외에 CMS2의 다른 12명의 로컬 참가자를 볼 수 있으며, 총 21명이 참가자 18 - 30명의 화면에 표시됩니다.
요약:CMS1 참가자는 25명의 참가자를 볼 수 있으며, CMS2 참가자는 화면에서 21명의 참가자를 볼 수 있습니다.

4.maxPeerVideoStreams가 로드 밸런싱이 비활성화된 상태로 9로 설정

부하 균형이 활성화되지 않으므로 참가자는 두 번째 통화에서 시작하는 두 CMS 서버 모두에서 회의에 참가합니다.이는 CUCM Route Group이 순환으로 설정되었기 때문입니다. 즉 통화가 두 CMS 서버로 순차적으로 전송됩니다.1번 통화가 CMS1로 전송되고, 2번 통화가 CMS2로 전송되고, 3번 통화가 CMS1로 전송되고, 4번 통화가 CMS2로 전송됩니다.
즉, 각 CallBridge에서 호스팅되는 15명의 참가자를 찾을 것으로 예상됩니다. 15명의 참가자가 CMS1에 있고 15명의 참가자가 CMS2에 있습니다.

maxPeerVideoStreams가 로드 밸런싱이 비활성화된 상태로 9로 설정되었습니다.

CMS1 참가자는 CMS2의 9명의 참가자와 함께 CMS1의 다른 14명의 로컬 참가자를 볼 수 있으며, 총 23명의 참가자가 CMS1 참가자의 화면에 표시됩니다.
CMS2의 참가자는 CMS1의 9명의 참가자와 함께 CMS2의 다른 14명의 로컬 참가자를 볼 수 있으며, 총 23명의 참가자가 CMS2 참가자의 화면에 표시됩니다.
요약:CMS1 참가자 및 CMS2 참가자 모두 화면에서 23명의 참가자를 볼 수 있습니다.

문제 해결

현재 이 구성에 대해 사용 가능한 특정 문제 해결 정보가 없습니다.

로그 분석에 Collaboration Solutions Analysis 툴을 사용할 수 있습니다.