Explicação e solução alternativa no CSCvt73723 - sessões vazando do servidor WebRTC após uma grande quantidade de sessões colocadas no servidor

Introdução

Este documento descreve a detecção e a solução do bug da Cisco ID CSCvt73723 sobre sessões de vazamento do servidor WebRTC após uma grande quantidade de sessões colocadas no servidor. Isso pode eventualmente fazer com que os usuários não consigam fazer login ou ingressar como convidados no WebBridge.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Meeting Server (CMS) (componente CallBridge e WebBridge)

Componentes Utilizados

As informações neste documento são baseadas no Cisco Meeting Server e, em particular, em torno do componente WebBridge 2 / CMA WebRTC. Este documento não se aplica ao novo componente do aplicativo Web Web WebBridge 3 / CMS que foi introduzido na versão 2.9.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

CSCvt73723 - Sessões vazando do servidor WebRTC após uma grande quantidade de sessões colocadas no servidor

Como você identifica esse bug?

Do ponto de vista do usuário final, o sintoma é que eles atingiram o limite rígido e nenhum outro usuário pode ingressar em uma reunião. Nos registros, a localização das estatísticas de webbridge (conforme este FAQ) está atingindo 149 e NÃO implica necessariamente que todas as sessões vazadas. Isso significa apenas que o Web Bridge atingiu seu limite rígido e nenhuma conexão nova é permitida.

"webbridge": INFORMAÇÕES : [DEBUGGING] Estatísticas 149, c:3477, d:3170

Calcular quantas dessas sessões são vazadas é um pouco mais complicado e pode ser feito se você NÃO estiver usando o cliente de desktop CMA ou o cliente iOS. A partir da versão 2.8, o Call Bridge relata a cada 5 minutos o número de sessões de CMA (CMA WebRTC + CMA desktop client + CMA iOS client). Observe que isso é relatado como o "CMA": "X/Y" onde X é o número atual de sessões de CMA ativas e Y é o pico nos últimos 5 minutos.

INFORMAÇÕES : STATS: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}}

O fato de um Call Bridge reportar 14 sessões atuais não significa que o Web Bridge co-localizado também esteja reportando 14 sessões. Esse mapeamento é de 1:1 em um único servidor combinado, mas em uma implantação em cluster, uma sessão de Web Bridge pode instanciar uma chamada em uma Call Bridge diferente (especialmente quando o balanceamento de carga está habilitado - o que é por padrão para o CMA).

Portanto, para calcular o número total de sessões vazadas em uma implantação, você precisa das sessões ativas combinadas de TODAS as estatísticas de Web Bridge e compare isso com as estatísticas combinadas de CMA Call Bridge que são relatadas.

Como você pode evitar esse problema?

Dependendo da frequência com que sua implantação atinge essa situação (uma vez a cada dois dias ou uma vez a cada duas semanas), você deve ser avisado para reiniciar a(s) Web Bridge(s) que elimina(m) as sessões vazadas e redefine a contagem de sessões ativas para 0. Compreensivelmente isso pode ser tedioso se isso se torna uma tarefa diária, por isso, esta tarefa pode ser facilitada com um script disponível de acordo com o bloco de código.

################################################################
#### 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)
################################################################

O script requer algumas pequenas edições (as credenciais na linha 29-30 e os endereços IP das Web Bridges na implantação na linha 27) e deveSÓ ser executado quando não houver carga esperada ou durante uma janela de manutenção. O script não verifica se há sessões ativas e simplesmente executa o comando 'webbridge restart' em todos os servidores listados, o que encerra qualquer sessão WebRTC ativa.

Para automatizar esse script, é possível configurá-lo em um trabalho cron ou em um PC com Windows 10 com o Agendador de Tarefas. Supondo que o PC Win 10 tenha o Python 3.4+ instalado, eles podem seguir estas etapas:

    1. Abrir o Agendador de Tarefas

    2. Selecione 'Criar Tarefa Básica...'

    2.1 Insira um nome/descrição para esta tarefa

    2.2 Selecione a frequência e as horas em que deseja executar esta tarefa (recomendado apenas para horários fora do pico, mostrado aqui para todos os sábados às 2h)

    2.3 Ação a ser executada, selecione: 'Iniciar um programa'

    2.4 Ação:

    * Programa/Script:  C:\<caminho para python.exe>

    (se você não souber o caminho para python.exe, ele poderá ser encontrado acessando cmd e digitando: python -c "import sys; print(sys.executable)")

    * Adicionar argumentos (opcional): webbridge_restart.py (ou nome do script python)

    * Início em (opcional): C:\<caminho para webbridge_restart.py>

Observe que o computador que está executando o trabalho cron deve ser capaz de acessar o MMP dos servidores CMS configurados. Depois que o script é executado, ele cria um arquivo webbridge_restart_logs.txt que contém detalhes sobre as reinicializações de diferentes WebBridges, bem como quaisquer falhas potenciais. Um exemplo é mostrado com uma conexão bem-sucedida com 10.48.79.194 e uma falha com 127.0.0.1 (como sendo o endereço de loopback do PC na verdade).

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

Como testar se o script funciona bem?

Se você tiver o Python instalado no PC a partir do qual deseja executar o script, poderá executá-lo manualmente primeiro com as próximas etapas:

1. Abra o cmd e navegue até o local do script com o comando 'cd'
   
   
   
   
2. Execute o arquivo python com o comando 'python webbridge_restart.py'
   
   
   
   
3. Caso você veja um erro indicando que o módulo 'paramiko' não está instalado, você precisa instalar alguma biblioteca extra com o comando 'pip install paramiko'
   
   
   
   
4. Depois de concluído, você pode executar o script novamente com 'python webbridge_restart.py' (OBSERVAÇÃO: isso reinicia a webbridge e faz com que as conexões atuais do WebRTC sejam desconectadas)
   
   Se ele tiver sido executado com êxito, você poderá verificar o resultado no arquivo webbridge_restart_logs.txt.

Para quando está prevista a sua correção?

Este não é um bug novo e não há planos de corrigir isso no Web Bridge 2 / CMA WebRTC. O novo aplicativo Web Web Bridge 3 / CMS (disponível a partir da versão 2.9) não é afetado por este erro, pois foi completamente redesenhado. Os clientes que são fortemente afetados por isso devem considerar a mudança para o novo aplicativo da Web do CMS (embora observe que isso ainda não é paridade de recursos com o Web Bridge 2 na versão 2.9. Verifique as notas de versão do aplicativo Web do CMS 2.9 e do cms para obter detalhes completos sobre isso.)

Informações Relacionadas

• Notas de defeito: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723
• Notas de versão: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html
• FAQ
  • https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html