Spiegazione e soluzione di CSCvt73723 - Sessioni di perdita del server WebRTC dopo un elevato numero di sessioni inserite nel server

Introduzione

Questo documento descrive il rilevamento e la soluzione per risolvere i problemi relativi all'ID bug Cisco CSCvt73723 intorno alle sessioni di perdita di dati del server WebRTC dopo l'inserimento di un grande numero di sessioni sul server. Ciò potrebbe impedire agli utenti di accedere o partecipare come guest sul WebBridge.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

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

Componenti usati

Le informazioni fornite in questo documento si basano su Cisco Meeting Server e in particolare sul componente WebBridge 2/CMA WebRTC. Questo documento non è valido per il nuovo componente WebBridge 3/CMS Web App introdotto nella versione 2.9.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

CSCvt73723 - Il server WebRTC perde sessioni dopo l'inserimento di un numero elevato di sessioni sul server

Come si identifica questo bug?

Dal punto di vista dell'utente finale, il sintomo è che una volta raggiunto il limite massimo, nessun altro utente può unirsi a una riunione. Nei log, individuare le statistiche di webbridge (come da questa FAQ) che raggiungono 149 NON implica necessariamente che si tratti di tutte sessioni perse. Ciò significa che il Web Bridge ha raggiunto il limite massimo e non sono consentite nuove connessioni.

"webbridge": INFORMAZIONI : [DEBUGGING] Statistiche 149, c:3477, d:3170

Il calcolo del numero di sessioni perse è un po' più complesso e può essere eseguito se NON si utilizza il client desktop CMA o il client iOS. Dalla versione 2.8, il bridge di chiamate segnala ogni 5 minuti il numero di sessioni CMA (CMA WebRTC + client desktop CMA + client CMA iOS). Questa condizione viene indicata come "CMA": "X/Y" dove X è il numero corrente di sessioni CMA attive e Y è il picco degli ultimi 5 minuti.

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

Solo perché un bridge di chiamate segnala 14 sessioni correnti non significa che anche il bridge di Web che si trova nello stesso luogo segnala 14 sessioni. Questo mapping è 1:1 su un singolo server combinato, ma in una distribuzione cluster una sessione di Web Bridge può creare un'istanza di una chiamata su un Call Bridge diverso (in particolare quando è abilitato il bilanciamento del carico, che è l'impostazione predefinita per CMA).

Pertanto, per calcolare il numero totale di sessioni perse in una distribuzione, è necessario combinare le sessioni attive di TUTTE le statistiche di Web Bridge e confrontarle con le statistiche combinate di Call Bridge CMA riportate.

Come è possibile evitare questo problema?

A seconda della frequenza con cui la distribuzione si scontra con questa situazione (una volta ogni due giorni o una volta ogni due settimane), è necessario riavviare i bridge Web, eliminando le sessioni perse e reimpostando il conteggio delle sessioni attive su 0. Comprensibilmente questo può essere noioso se questo diventa un lavoro quotidiano, quindi perché questa attività può essere facilitata con uno script disponibile come per il blocco di codice.

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

Lo script richiede alcune piccole modifiche (le credenziali alla riga 29-30 e gli indirizzi IP dei Web Bridge nella distribuzione alla riga 27) e deve essere eseguito SOLO quando non è previsto alcun carico o durante un intervento di manutenzione. Lo script non verifica le sessioni attive ed esegue semplicemente il comando 'webbridge restart' su tutti i server elencati, che termina qualsiasi sessione WebRTC attiva.

Per automatizzare questo script, è possibile impostare un lavoro cron o su un PC Windows 10 con l'Utilità di pianificazione. Supponendo che sul PC Win 10 sia installato Python 3.4+, è possibile eseguire la procedura seguente:

    1. Apri Utilità di pianificazione

    2. Selezionare 'Crea attività di base...'

    2.1 Inserire un nome / una descrizione per questa attività

    2.2 Selezionare la frequenza e l'ora in cui si desidera eseguire l'attività (consigliata solo per gli orari di minore attività, qui mostrati per ogni sabato alle 2)

    2.3 Azione da eseguire, selezionare: 'Avvia un programma'

    2.4 Azione:

    * Programma/Script:  C:\<percorso di python.exe>

    se non si conosce il percorso di python.exe, è possibile individuarlo tramite cmd e digitando: python -c "importa sys; print(sys.executable)")

    * Aggiungere argomenti (facoltativo): webbridge_restart.py (o nome dello script python)

    * Inizio (facoltativo): C:\<percorso di webbridge_restart.py>

Notare che il computer che esegue il processo cron deve essere in grado di accedere al protocollo MMP dei server CMS configurati. Dopo l'esecuzione dello script, viene creato un file webbridge_restart_logs.txt contenente dettagli sui riavvii dei diversi WebBridge e sugli eventuali errori potenziali. Viene mostrato un esempio con una connessione riuscita a 10.48.79.194 e una non riuscita a 127.0.0.1 (come l'indirizzo di loopback del 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

Come verificare che lo script funzioni correttamente?

Se Python ha installato il PC da cui si intendeva eseguire lo script, è possibile eseguirlo manualmente con i passaggi seguenti:

1. Aprire il comando cmd e individuare la posizione dello script con il comando 'cd'
   
   
   
   
2. Eseguire il file python con il comando 'python webbridge_restart.py'
   
   
   
   
3. Se viene visualizzato un errore che indica che il modulo 'paramiko' non è installato, è necessario installare una libreria aggiuntiva con il comando 'pip install paramiko'
   
   
   
   
4. Una volta completato, è possibile eseguire nuovamente lo script con 'python webbridge_restart.py' (NOTA: in questo modo il webbridge viene riavviato e le connessioni WebRTC correnti vengono disconnesse)
   
   Se l'operazione ha avuto esito positivo, è possibile verificarne il risultato nel file webbridge_restart_logs.txt.

Quando è prevista la risoluzione di questo problema?

Non si tratta di un nuovo bug e non è prevista la correzione del problema sul Web Bridge 2/CMA WebRTC. La nuova app Web Bridge 3 / CMS (disponibile a partire dalla versione 2.9) non è interessata da questo bug in quanto è stata completamente riprogettata. I clienti che sono stati pesantemente colpiti da questo deve prendere in considerazione il passaggio alla nuova app Web CMS (anche se questa non è ancora la parità di funzionalità con Web Bridge 2 nella versione 2.9. Per informazioni dettagliate su questo argomento, vedere le note di rilascio di CMS 2.9 e CMS Web App.)

Informazioni correlate

• Note sui difetti: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723
• Note sulla versione: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html
• Domande frequenti
  • https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html