Cisco Meeting Server의 로드 밸런싱 로직

소개

이 문서에서는 로드 밸런싱 백서에서 다룬 Cisco Meeting Server(CMS)(이전의 Acano 제품)의 로드 밸런싱 논리에 대해 설명합니다. 이 문서에서는 이 프로세스를 순서도로 시각화하고 선택 알고리즘에 대해 자세히 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco Meeting Server Call Bridge 구성 요소(및 클러스터링)
• Cisco Meeting Server API 컨피그레이션

사용되는 구성 요소

이 문서의 정보는 Cisco Meeting Server 버전 2.4.x를 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

CMS의 로드 밸런싱 알고리즘은 무엇입니까?

컨퍼런스 리소스를 효율적으로 활용하기 위해 CMS 버전 2.1에 로드 밸런싱이 도입되었습니다. 동일한 공간을 호스트하는 통화 브리지 간의 배포 통화 수를 최소화하려고 시도합니다. 이 메커니즘은 SIP(Session Initiation Protocol)의 Replaces 헤더를 기반으로 하며 CUCM(Cisco Unified Communications Manager)에서 통화 제어로 지원됩니다. CMS 버전 2.4 이상과 함께 Expressway 버전 X8.11 이상에서도 지원됩니다. CMA 통화(씩 클라이언트 및 WebRTC 유형 모두)는 CMS 버전 2.3 이상에서도 로드 밸런싱이 가능합니다.

참고: 현재 CMS 버전에서는 Lync/Skype 통화의 로드 밸런싱이 지원되지 않으므로 이 순서도가 적용되지 않습니다.

참고: 로드 밸런싱 로직은 CMS 공간에 대한 통화에만 적용되므로 현재 시점에서 게이트웨이 통화(P2P 통화) 또는 듀얼 홈 통화에는 적용되지 않습니다.

부하 균형 프로세스는 백서 "부하 균형이 수신 통화의 부하 균형을 위해 통화 브리지 구성"의 설정을 사용하는 방법" 단원에 강조 표시되어 있습니다. 텍스트 형식으로 표시되며 여기 순서도(다운로드)에 시각화됩니다.

순서도는 몇 가지 약어와 용어를 사용합니다.

• CB = 통화 브리지
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasis * loadLimit
  (기본적으로 existingConferenceLoadLimitBasisPoints는 8000이며 80%에 해당합니다.)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  기본적으로 newConferenceLoadLimitBasisPoints는 5000이며 50%에 해당합니다.

MediaProcessingLoad가 참조되는 경우 통화가 연결된 특정 통화 브리지와 관련하여 표시됩니다. 이 로드 값은 API GET on /system/load를 통해 실시간으로 확인할 수 있으며 해당 시점의 이 호출 브리지에서 처리한 실제 로드를 나타냅니다.

맨 오른쪽 아래 상자에서 통화가 끝나면 가장 우선순위가 높은 서버로 통화를 재전송합니다. 이 서버는 Call Bridge 서버 자체 또는 통화가 연결된 Call Bridge 그룹 내의 다른 서버일 수 있습니다. 로드 및 해당 공간이 이미 통화 브리지에서 활성 상태인지 여부에 따라 결정되지 않는 경우 여러 통화 브리지와 연관이 있습니다. 이 경우 각 스페이스에 할당된 기본 통화 브리지 기본 설정에 따라 최종 결정이 내려집니다. 이 통화 브리지 기본 설정은 공간을 자동으로 생성할 때 할당되며 여러 특성의 해시 값을 기반으로 하므로 구성할 수 없습니다. 따라서 모든 통화 브리지에서 서로 다른 공간에 대해 균일한(무작위) 분포가 형성됩니다.

특정 공간에 대한 통화 브리지 기본 설정을 보려면 다음 예에 표시된 대로 CMS 이벤트 로그에서 이를 확인해야 합니다.

로드 밸런싱 알고리즘의 예

이 섹션에는 가능한 시나리오의 예와 통화가 연결된 CMS의 이벤트 로그에서 순서도에서 다루는 로드 밸런싱 프로세스를 표시하는 방법이 포함되어 있습니다.

이 예에서는 3개의 통화 브리지로 구성된 통화 브리지 그룹과 함께 랩 설정을 사용했습니다. 기존 ConferenceLoadLimitBasisPoints 및 newConferenceLoadLimitBasisPoints 구성은 loadLimit 값의 80% 및 50%에 해당하는 기본값으로 설정되었습니다.

특정 호출 브리지에서 현재 MediaProcessingLoad를 확인하려면 https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load로 이동한 다음 그림에 표시된 대로 API 또는 관리자 계정으로 로그인할 수 있습니다.

예 1: 통화 브리지에 로드 없음

이 예에서는 통화 브리지에서 활성화된 통화가 없습니다. 따라서 모든 서버의 MediaProcessingLoad는 0입니다.

CMS 및 통화 제어 장치 모두에서 로드 밸런싱이 활성화된 상태에서 통화 브리지 중 하나(여기 cluster1)에 전화를 걸면 통화가 연결된 통화 브리지에서 이벤트 로그를 볼 수 있습니다.

2018-12-29  10:51:29.490  Info     call 75: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  10:51:29.565  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  10:51:29.712  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'
2018-12-29  10:51:29.876  Info     call 75: ending; remote SIP cancel (remote cancel) - not connected after 0:00

에서는 세 가지 섹션으로 분할된 로드 밸런싱 알고리즘을 보여 주는 통화 브리지 그룹의 각 통화 브리지에 대한 대체 쿼리 행을 볼 수 있습니다.

• priority - 해당 공간의 Call Bridge 기본 설정
• 로드 레벨 - 해당 시점의 해당 통화 브리지의 로드 레벨
• conference is running - 공간이 해당 통화 브리지에서 활성 상태인지 여부를 나타내는 부울

그 때 시스템에 통화가 연결되지 않았으므로 시스템에 로드가 없고(모두 0) 전화회의가 아무 곳에서도 실행되지 않습니다(모두 0). 이와 관련하여 최종 결정은 스페이스의 Call Bridge(통화 브리지) 기본 설정에 따라 결정됩니다. 우선 순위가 낮은 것이 바람직하므로 여기서는 통화 교체 라인에서 볼 수 있는 cluster3이라는 Call Bridge로 통화가 교체됩니다.

Call Bridge cluster3에서는 이 대체 통화를 나타내는 이벤트 로그 라인과 어떤 Call Bridge에서 걸려왔는지(여기서는 cluster1), 동일한 컨퍼런스 ID 및 통화 ID를 나타내는 이벤트 로그 라인을 볼 수 있습니다.

2018-12-29  10:51:29.784  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' from server 'cluster1' into conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93
2018-12-29  10:51:29.787  Info     call 193: outgoing SIP call to "1060@steven.lab" from space "Steven Janssens's space"
2018-12-29  10:51:29.792  Info     call 193: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  10:51:29.909  Info     call 193: compensating for far end not matching payload types
2018-12-29  10:51:29.911  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

통화가 이미 가장 낮은 우선순위 값(이 스페이스의 경우 cluster3)으로 통화 브리지에 연결된 경우, 이벤트 로그에서 동일한 대체 쿼리 행을 계속 볼 수 있지만 로컬 서버를 사용하므로 대체 통화 선이 없음을 나타냅니다.

2018-12-29  11:05:25.202  Info     call 194: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:05:25.233  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.376  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.380  Info     call 194: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  11:05:25.404  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

예 2: 통화 브리지 그룹의 스페이스에 이미 있는 참가자

이 예에서는 example 1에 표시된 것처럼 이 공간에 엔드포인트 1060@steven.lab이 호출되면서 이 공간은 통화 브리지 그룹 내에서 이미 활성화되어 있습니다.

이 경우에는 두 가지 상황이 있습니다.

1. 이 공간을 호스트하는 통화 브리지의 부하가 기존 전화회의 임계값보다 낮으므로 통화를 수락할 수 있습니다.

2. 이 공간을 호스트하는 통화 브리지의 로드가 기존 전화회의 임계값보다 높으므로 CMS가 통화를 다른 통화 브리지로 대체하려고 시도합니다.

시나리오 1. 기존 전화회의 임계값보다 낮은 활성 공간 및 부하(80%)

공간이 아직 활성화되지 않은 통화 브리지에 통화가 연결된 경우, 이제 이벤트 로그에 이름이 cluster3인 통화 브리지에서 공간이 활성 상태임을 표시합니다. 공간이 활성 상태이고 해당 서버의 부하가 기존 임계값(부하 수준: 0)보다 낮으므로 통화가 교체됩니다.

2018-12-29  11:48:17.419  Info     call 82: incoming SIP call from "sip:800999@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:48:17.477  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replacing call '4c28197eaebba178@10.10.2.250' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'

전화회의가 실행되면 우선 순위에 우선 순위를 먼저 적용하므로, 기존 전화회의 임계값보다 부하 수준이 낮은 여러 후보가 있을 경우 우선 순위 값에 따라 통화 브리지 기본 설정으로 내려갑니다. 그러나 여기서는 그렇지 않습니다.

시나리오 2. 기존 전화회의 임계값보다 높은 활성 공간 및 부하(80%)

이 경우 통화가 해당 통화 브리지로 대체되는 것이 아니라 일부 리소스를 여전히 사용할 수 있는 그룹 내의 다른 통화 브리지를 찾습니다. 먼저, 로드가 50%보다 낮은 통화 브리지가 있는지(새 전화회의 임계값) 확인하고 해당 통화 브리지를 먼저 로드합니다. 이 임계값에 미달되는 항목이 없는 경우 80%(기존 전화회의 임계값) 미만으로 계속 사용 가능한지 확인합니다.

예 1 및 2(시나리오 1)의 호출 후 Call Bridge cluster3의 로드를 선택하면 2000의 로드가 표시됩니다.

해당 통화 브리지 클러스터3에 대한 loadLimit이 2250으로 설정되었다고 가정합니다(예:). 그러면 이 통화 브리지는 0.80 * 2250 = 1800으로 계산된 기존 전화회의 임계값을 초과합니다

이 시나리오에서는 아직 두 가지 차별화 사례가 존재한다.

사례 1: 그룹의 여러 서버가 여전히 새 컨퍼런스 임계값보다 낮은 로드(50%)

그룹의 다른 두 서버는 여전히 처리된 통화를 가지고 있지 않으므로 로드가 여전히 0이므로 두 서버 모두 통화를 처리할 수 있습니다. 따라서 이 영역에 대한 통화 브리지 기본 설정에 따라 최종 결정이 내려집니다. Call Bridge cluster3이 이미 가득 차서 시스템은 cluster1과 cluster2 중 가장 낮은 우선 순위인 cluster1을 선택합니다. 이 경우 cluster1이 사용됩니다.

2018-12-29  12:11:03.211  Info     call 86: incoming encrypted SIP audio call from "sip:2001@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:11:03.263  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.405  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.415  Info     call 86: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:11:03.434  Info     participant "2001@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

cluster3 통화 브리지의 로드 레벨 2는 기존 전화회의 임계값을 초과했음을 나타내므로, 공간이 활성 상태였음에도 통화가 해당 서버에 대해 로드 밸런싱되지 않습니다. 그 대신 로드 레벨이 0(사용률이 50%보다 낮음)인 다른 통화 브리지의 가장 낮은 공간 우선순위를 살펴봅니다(이 경우 cluster1).

사례 2: 새 전화회의 임계값(50%) 또는 기존 전화회의 임계값(80%)보다 낮은 로드가 있는 그룹의 서버 1대만

마지막 통화(그리고 cluster2에 대한 다른 공간 호출) 후, 콜 브리지에 설명된 로드가 표시되었습니다.

• 클러스터 1 - 1200
• 클러스터 2 - 400
• 클러스터 3 - 4000

이제 cluster1 통화 브리지에 설정된 loadLimit이 1300이라고 가정하면 이 통화 브리지는 0.50 * 1300 = 650으로 계산되고 기존 회의 임계값인 0.80 * 1300 = 1040을 초과하여 계산된 새 회의 임계값을 초과합니다.

동일한 공간에 대해 이제 Call Bridge cluster3에서 새 WebRTC 통화가 발생할 경우, 이 공간은 cluster1과 cluster3 모두에서 활성 상태이지만 둘 다 기존 전화회의 임계값을 초과하므로 새 전화회의 임계값(50%) 또는 기존 전화회의 임계값(80%)에서 다른 서버를 찾습니다. 이 경우 cluster2만 기존 전화회의 임계값 아래에 있지만 cluster2 통화 브리지에서 처리된 다른 스페이스에 대한 다른 통화로 인해 이미 새 전화회의 임계값을 초과합니다.

2018-12-29  12:45:33.162  Info     instantiating user "guest1685904798@cluster.steven.lab"
2018-12-29  12:45:33.162  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster2' (priority: 2, load level: 1, conference is running: 0)

여기서 Cluster2가 loadLimit 값 600으로 설정되었습니다. 새 통화가 들어오기 전의 현재 로드가 400인 경우 새 전화회의 임계값인 0.5 * 600 = 300을 초과하지만, 기존 전화회의 제한값인 0.8 * 600 = 480에는 계속 미달합니다. 따라서 이 값은 대체 쿼리에서 로드 레벨 1(통화 브리지가 80% 임계값을 초과하는 경우 2 대신)로 표시됩니다.

예 3: 기존 전화회의 임계값을 통한 통화 브리지의 통화 연결

이 경우, 488 응답을 다시 통화 제어 장치로 보내는 것이 좋습니다. 그러면 그룹 내의 다른 통화 브리지(80% 제한 미만)로 통화를 라우팅하도록 결정하거나 현재 그룹이 리소스가 부족한 경우 다른 통화 브리지 그룹으로 라우팅하도록(대체 옵션) 결정할 수 있습니다. 따라서 로드 밸런싱 알고리즘은 수행되지 않습니다.

이벤트 로그에는 용량이 초과되었다는 보고만 있을 뿐이므로 이 부분이 자세히 표시되지 않습니다.

2018-12-29  12:49:13.352  Info     call 88: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.399  Info     call 88: ending; local teardown, system participant limit reached - not connected after 0:00

통화를 로드를 처리할 수 있는 다른 통화 브리지(예: cluster2)로 전송하면 동일한 로드 밸런싱 알고리즘이 표시됩니다.

2018-12-29  12:49:13.434  Info     call 624: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.475  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.618  Info     call 624: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:49:13.621  Info     call 624: starting DTLS UDT media negotiation (as initiator)
2018-12-29  12:49:13.640  Info     participant "2020@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

참고: 게이트웨이 통화의 경우 CMS에서 486 SIP 오류 메시지를 대신 반환합니다. 기본적으로 CUCM은 Stop Routing on User Busy Flag의 Service Parameter에 따라 라우팅을 중지하므로 이 설정을 변경하여 다른 callbridge에 대한 게이트웨이 호출의 대체를 허용할 수 있습니다.