소개
이 문서에서는 서버에 많은 세션을 배치한 후 WebRTC 서버 유출 세션과 관련된 Cisco 버그 ID CSCvt73723의 탐지 및 해결 방법에 대해 설명합니다. 이로 인해 사용자가 WebBridge에 게스트로 로그인하거나 참가할 수 없게 될 수 있습니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- CMS(Cisco Meeting Server)(CallBridge 및 WebBridge 구성 요소)
사용되는 구성 요소
이 문서의 정보는 Cisco Meeting Server를 기반으로 하며 특히 WebBridge 2/CMA WebRTC 구성 요소에 대한 내용을 기반으로 합니다. 이 문서는 버전 2.9에 도입된 새 WebBridge 3/CMS Web App 구성 요소에 적용되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
CSCvt73723 - 서버에 많은 세션이 배치된 후 WebRTC 서버에서 세션 누수
이 버그를 어떻게 식별합니까?
최종 사용자 관점에서는 하드 제한에 도달하여 더 이상 회의에 참가할 수 없는 경우입니다. 로그에서 Webbridge 통계(이 FAQ에 따름)가 149를 기록한다고 해서 이러한 세션이 모두 유출되었다는 의미는 아닙니다. 이는 웹 브리지가 하드 제한에 도달했으며 새 연결이 허용되지 않음을 의미합니다.
"webbridge": 정보: [DEBUGGING] 통계 149, c:3477, d:3170
이 중 몇 개가 누출되는지 계산하는 것은 좀 더 복잡하며 CMA 데스크톱 클라이언트나 iOS 클라이언트를 사용하지 않는 경우 수행할 수 있습니다. 버전 2.8부터 통화 브리지는 5분마다 CMA 세션 수를 보고합니다(CMA WebRTC + CMA 데스크톱 클라이언트 + CMA iOS 클라이언트). 이는 "CMA"로 보고됩니다. "X/Y" 여기서 X는 활성 CMA 세션의 현재 수이고 Y는 최근 5분 동안의 피크입니다.
정보: 통계: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}}
통화 브리지가 14개의 현재 세션을 보고한다고 해서 공동 배치 웹 브리지도 14개의 세션을 보고하는 것은 아닙니다. 이 매핑은 단일 결합 서버에서 1:1이지만 클러스터링된 구축에서는 웹 브리지 세션이 다른 통화 브리지에서 통화를 인스턴스화할 수 있습니다(특히 로드 밸런싱이 활성화된 경우 - CMA의 경우 기본적임).
따라서 구축에서 유출된 세션의 총 수를 계산하려면 모든 웹 브리지 통계의 결합된 활성 세션이 필요하며 이를 보고된 결합된 CMA 통화 브리지 통계와 비교합니다.
어떻게 하면 이 문제를 피할 수 있을까요?
구축에서 이 상황이 발생하는 빈도에 따라(2일에 한 번 또는 2주에 한 번), Web Bridge를 다시 시작하여 유출된 세션을 지우고 활성 세션 수를 0으로 재설정하는 것이 좋습니다. 일일 작업이 되는 경우 이 작업이 지루할 수 있으므로 코드 블록에 따라 제공되는 스크립트를 사용하여 이 작업을 쉽게 수행할 수 있는 이유가 있습니다.
################################################################
#### Cisco Meeting Server ####
#### Webbridge restart ####
#### Workaround for CSCvt73723 ####
#### feedback: willwoo@cisco.com ####
################################################################
#--------------------------------------------------------------
# ---------- DISCLAIMER ----------
#--------------------------------------------------------------
# Please note this script is NOT maintained or supported by Cisco.
# This is to be run at entirely your own risk.
# This script is not intended for redistribution
# Tested with python 3.7.4
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Libraries to import ----------
#--------------------------------------------------------------
import paramiko
import time
import datetime
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Deployment parameters to change ----------
#--------------------------------------------------------------
# WB Inventory - just extend or modify the below to match your deployment requirements.
# Enter the MMP IP of the server (can differ from interface webbridge service is running)
webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}
mmp_username = "admin" # MMP username
mmp_password = "password" # MMP password
#--------------------------------------------------------------
def mmp_webbridge_restart(mmp_address,uname,pword):
conn = paramiko.SSHClient()
conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
conn.connect(mmp_address, 22, uname, pword)
stdin, stdout, stderr = conn.exec_command('webbridge restart')
time.sleep(1)
conn.close()
print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')
except Exception as error:
print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')
print_log_message(str(error))
pass
def print_log_message(message):
time_stamp = datetime.datetime.now(datetime.timezone.utc)
time_stamp = str(time_stamp)
file = open('webbridge_restart_logs.txt', 'a')
file.write(time_stamp + " " + message + "\n")
file.close()
if __name__ == '__main__':
for wb in webbridges:
mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)
################################################################
스크립트에는 약간의 수정이 필요하며(행 29-30의 자격 증명 및 행 27의 구축에서 웹 브리지의 IP 주소), 예상 로드가 없거나 유지 보수 기간 중에만 실행되어야 합니다. 스크립트는 활성 세션을 확인하지 않고 나열된 모든 서버에서 'webbridge restart' 명령을 수행하기만 하면 활성 WebRTC 세션이 종료됩니다.
이 스크립트를 자동화하기 위해 cron 작업을 설정하거나 작업 스케줄러가 있는 Windows 10 PC에서 이 스크립트를 수행할 수 있습니다. Win 10 PC에 Python 3.4+가 설치되어 있다고 가정하면 다음 단계를 수행할 수 있습니다.
1. 작업 일정 관리기 열기
2. '기본 태스크 생성...'을 선택합니다.
2.1 이 작업의 이름/설명을 입력합니다
2.2 이 작업을 실행할 빈도 및 시간을 선택합니다(사용량이 적은 시간에만 사용하는 것이 좋으며, 매주 토요일 오전 2시에 여기에 표시됨).
2.3 수행할 작업: '프로그램 시작'을 선택합니다.
2.4 조치:
* 프로그램/스크립트: C:\<python.exe 경로>
python.exe의 경로를 모르는 경우 cmd로 이동하여 다음을 입력하여 찾을 수 있습니다. python -c "import sys; print(sys.executable)")
* 인수 추가(선택 사항): webbridge_restart.py(또는 python 스크립트 이름)
* 시작 위치(선택 사항): C:\<webbridge_restart.py 경로>
cron 작업을 실행하는 컴퓨터는 구성된 CMS 서버의 MMP에 액세스할 수 있어야 합니다. 스크립트가 실행되면 다른 WebBridge의 재시작과 잠재적 실패에 대한 세부사항이 포함된 webbridge_restart_logs.txt 파일이 생성됩니다. 예를 들어, 10.48.79.194에 대한 연결이 성공하고 127.0.0.1에 대한 연결이 실패한 경우(실제로 PC의 루프백 주소인 경우)가 있습니다.
2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1
스크립트가 제대로 작동하는지 테스트하는 방법
스크립트를 실행하도록 지정한 PC에 Python이 설치되어 있는 경우 다음 단계를 통해 먼저 수동으로 실행할 수 있습니다.
- cmd를 열고 'cd' 명령을 사용하여 스크립트 위치를 찾습니다
- 'python webbridge_restart.py' 명령을 사용하여 python 파일을 실행합니다.
- 'paramiko' 모듈이 설치되지 않았음을 나타내는 오류가 표시될 경우, 'pip install paramiko' 명령을 사용하여 추가 라이브러리를 설치해야 합니다.
- 완료되면 'python webbridge_restart.py'를 사용하여 스크립트를 다시 실행할 수 있습니다(참고: 이 경우 webbridge가 다시 시작되고 현재 진행 중인 WebRTC 연결이 끊어집니다)
성공적으로 실행된 경우 webbridge_restart_logs.txt 파일에서 그 결과를 확인할 수 있습니다.
언제 고쳐질 예정인가요?
이것은 새로운 버그가 아니며 Web Bridge 2 / CMA WebRTC에서 이 문제를 해결할 계획이 없습니다. 새로운 Web Bridge 3/CMS 웹 앱(2.9 이후부터 사용 가능)은 완전히 재설계되었으므로 이 버그의 영향을 받지 않습니다. 이로 인해 큰 영향을 받는 고객은 새로운 CMS 웹 앱으로 전환하는 것을 고려해야 합니다(2.9 릴리스의 Web Bridge 2와 기능 동일성은 아직 아니지만). 자세한 내용은 CMS 2.9 및 cms 웹 앱 릴리스 노트를 참조하십시오.)
관련 정보