Logica di bilanciamento del carico su Cisco Meeting Server

Introduzione

Questo documento descrive la logica di bilanciamento del carico di Cisco Meeting Server (CMS) (in precedenza prodotto Acano) descritta nel white paper sul bilanciamento del carico. In questo documento il processo viene visualizzato in un diagramma di flusso e vengono fornite informazioni più dettagliate sull'algoritmo di selezione.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Componente Call Bridge di Cisco Meeting Server (e relativo clustering)
• Configurazione API Cisco Meeting Server

Componenti usati

Per la stesura del documento, è stato usato Cisco Meeting Server versione 2.4.x.

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.

Che cos'è l'algoritmo di bilanciamento del carico del CMS?

Il bilanciamento del carico è stato introdotto nella versione 2.1 del CMS per utilizzare in modo efficiente le risorse di conferenza. Tenta di ridurre al minimo il numero di chiamate di distribuzione tra i bridge di chiamate che ospitano lo stesso spazio. Questo meccanismo è basato sull'intestazione Replace in Session Initiation Protocol (SIP) ed è supportato in Cisco Unified Communications Manager (CUCM) come controllo delle chiamate. È inoltre supportato con Expressway versione X8.11 (o successiva), in combinazione con CMS versione 2.4 o successiva. Le chiamate CMA (sia di tipo thick client che WebRTC) possono essere bilanciate dal carico a partire dalla versione 2.3 di CMS.

Nota: il bilanciamento del carico delle chiamate Lync/Skype non è supportato in nessuna versione CMS in questo momento, quindi questo diagramma di flusso non è applicabile.

Nota: la logica di bilanciamento del carico si applica solo per le chiamate agli spazi CMS e quindi non per le chiamate gateway (chiamate P2P) o dual-home in questo momento.

Il processo di bilanciamento del carico è evidenziato nel white paper nella sezione Modalità di utilizzo delle impostazioni in Configurazione dei bridge di chiamata per il bilanciamento del carico delle chiamate in arrivo. Viene visualizzato in formato testo ed è visualizzato qui nel diagramma di flusso (scarica ).

Il diagramma di flusso utilizza alcune abbreviazioni e terminologia:

• CB = ponte di chiamata
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  (per impostazione predefinita, existingConferenceLoadLimitBasePoints è uguale a 8000, che corrisponde all'80%)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (per impostazione predefinita, newConferenceLoadLimitBasisPoints è uguale a 5000, che corrisponde al 50%)

Se si fa riferimento a MediaProcessingLoad, questo viene visualizzato in relazione a quel particolare bridge di chiamate in cui la chiamata è arrivata. Questo valore di carico può essere verificato con un API GET on /system/load in tempo reale e fornisce una rappresentazione del carico effettivo elaborato da questo Call Bridge in quel momento.

Se si termina la chiamata nella casella in basso a destra, la chiamata viene reindirizzata al server con la priorità più alta. Può trattarsi del server del bridge di chiamate stesso o di un altro server all'interno del gruppo del bridge di chiamate in cui è terminata la chiamata. Se non viene presa alcuna decisione in base al carico e se lo spazio è già attivo su un bridge di chiamate, esiste un legame con più bridge di chiamate. In tal caso, la decisione finale viene presa in base alla preferenza predefinita di Call Bridge assegnata a ogni spazio. Questa preferenza di bridge di chiamate viene allocata automaticamente al momento della creazione dello spazio e non è configurabile in quanto si basa sui valori hash di diversi attributi. Il risultato è una distribuzione uniforme (casuale) per spazi diversi su tutti i bridge di chiamate.

Per visualizzare la preferenza Bridge di chiamata per uno spazio specifico, è necessario verificarla nel registro eventi del CMS, come illustrato in questi esempi.

Esempi di algoritmo di bilanciamento del carico

Questa sezione contiene esempi di possibili scenari e illustra come il registro eventi del CMS in cui è arrivata la chiamata mostri il processo di bilanciamento del carico descritto nel diagramma di flusso.

Per questi esempi, è stata utilizzata una configurazione lab con un gruppo di bridge di chiamata composto da tre bridge di chiamata. Le configurazioni existingConferenceLoadLimitBasisPoints e newConferenceLoadLimitBasisPoints sono state impostate sui valori predefiniti corrispondenti rispettivamente all'80% e al 50% del valore loadLimit.

Per controllare l'attuale MediaProcessingLoad su un determinato bridge di chiamate, è possibile passare a https://<ip-or-fqdn-of-callbridge>:<porta-webadmin>/api/v1/system/load ed eseguire l'accesso con un account API o amministratore come mostrato nella figura.

Esempio 1: nessun carico su qualsiasi bridge di chiamate

In questo esempio non sono presenti chiamate attive in nessuno dei bridge di chiamate. Di conseguenza, MediaProcessingLoad di tutti i server è uguale a zero.

Quando si effettua una chiamata a uno dei ponti di chiamata (cluster1 qui) (con bilanciamento del carico abilitato sia sul CMS che sui dispositivi di controllo delle chiamate), è possibile visualizzare il registro eventi sul ponte di chiamata in cui la chiamata è arrivata:

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

in cui è possibile visualizzare le righe della query di sostituzione per ognuno dei bridge di chiamata del gruppo di bridge di chiamata che mostrano l'algoritmo di bilanciamento del carico suddiviso in tre sezioni:

• priorità - la preferenza Ponte di chiamata di quello spazio
• livello di carico: il livello di carico del bridge di chiamate in quel momento
• conferenza in esecuzione - valore booleano che indica se lo spazio è attivo sul bridge di chiamate

Poiché in quel momento non sono state effettuate chiamate nel sistema, non vi è alcun carico su nessuno dei sistemi (tutti 0) e la conferenza non è in esecuzione da nessuna parte (tutti 0). A questo proposito, la decisione finale è presa in base alla preferenza Call Bridge dello spazio. Viene preferita una priorità più bassa e pertanto la chiamata viene sostituita qui al Call Bridge denominato cluster3, come rilevato dalla linea di chiamata sostitutiva.

In Call Bridge cluster3, è possibile visualizzare le righe del registro eventi che indicano questa chiamata di sostituzione, oltre al bridge di chiamate da cui proviene (cluster1 qui) e gli stessi ID conferenza e ID chiamata:

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)

Se la chiamata è già arrivata sul bridge di chiamate con il valore di priorità più basso (cluster3 qui per questo spazio), è ancora possibile visualizzare le stesse righe di query di sostituzione nel registro eventi, ma indica ora che utilizza il server locale e non è presente alcuna riga di chiamata di sostituzione:

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)

Esempio 2: partecipanti già presenti nello spazio nel gruppo di bridge di chiamate

In questo esempio, lo spazio è già attivo all'interno del Gruppo di bridge di chiamate come endpoint 1060@steven.lab chiamato nello spazio, come mostrato nell'esempio 1.

Esistono due situazioni in questo caso:

1. Il bridge di chiamate che ospita questo spazio ha un carico inferiore alla soglia di conferenza esistente e pertanto è in grado di accettare la chiamata.

2. Il bridge di chiamate che ospita questo spazio ha un carico superiore alla soglia di conferenza esistente e quindi il CMS tenta di sostituire la chiamata a un altro bridge di chiamate.

Scenario 1. Spazio attivo e carico inferiore alla soglia conferenza esistente (80%)

Se la chiamata è arrivata su un bridge di chiamate in cui lo spazio non era ancora attivo, il registro eventi indica ora che lo spazio è attivo su un bridge di chiamate con nome cluster3. Poiché lo spazio è attivo e il carico sul server è inferiore alla soglia esistente (livello di carico: 0), la chiamata viene sostituita.

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'

La conferenza in esecuzione ha la priorità sulla priorità, quindi se ci fossero stati più candidati con un livello di carico inferiore alla soglia della conferenza esistente, allora si ridurrebbe alla preferenza Ponte di chiamata in base al valore di priorità. Tuttavia, ciò non avviene nel caso di specie.

Scenario 2. Spazio attivo e carico superiori alla soglia conferenza esistente (80%)

In questo caso, la chiamata non viene sostituita con il bridge di chiamate ma cerca un altro bridge di chiamate all'interno del gruppo che disponga di alcune risorse ancora disponibili. In primo luogo, verifica se sono presenti ponti di chiamata con un carico inferiore al 50% (nuova soglia conferenza) e carica prima questi ponti. Se non ve ne sono sotto questa soglia, verifica se vi sono ancora disponibili al di sotto dell'80% (soglia conferenza esistente).

Se il carico sul cluster 3 di Call Bridge viene controllato dopo le chiamate degli esempi 1 e 2 (scenario 1), viene visualizzato un carico di 2000.

Si supponga che il valore di loadLimit per il cluster 3 del bridge di chiamate sia stato impostato su 2250 (solo come esempio) e che il bridge di chiamate sia superiore alla soglia di conferenza esistente calcolata come 0,80 * 2250 = 1800

Ci sono due casi ancora da differenziare in questo scenario.

Caso 1: più server nel gruppo ancora con un carico inferiore alla nuova soglia conferenza (50%)

Per gli altri due server del gruppo non è ancora stata gestita alcuna chiamata, quindi il carico è ancora pari a 0 e quindi entrambi potrebbero gestire la chiamata. La decisione finale viene quindi presa in base alla preferenza di Call Bridge per questo spazio. Poiché il cluster 3 con bridging di chiamata è già pieno, i sistemi sceglieranno la priorità più bassa tra cluster1 e cluster2, che in questo caso è 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)

Si noti che il livello di carico: 2 sul Call Bridge di cluster3 indica che è stato superato la soglia di conferenza esistente, quindi anche se lo spazio era attivo in quel punto, la chiamata non è bilanciata dal carico a quel server. Analizza invece la priorità di spazio più bassa degli altri bridge di chiamate con un livello di carico: 0 (che indica un utilizzo inferiore al 50%), che in questo caso è cluster1.

Caso 2: solo un server in un gruppo con un carico inferiore alla nuova soglia conferenza (50%) o alla soglia conferenza esistente (80%)

Dopo l'ultima chiamata (e le chiamate ad altro spazio per cluster2), i carichi descritti sono stati rilevati sui ponti di chiamata:

• cluster 1 - 1200
• cluster 2 - 400
• cluster 3 - 4000

Si supponga ora che il valore di loadLimit impostato sul bridge di chiamate cluster1 sia 1300 e che questo bridge di chiamate superi la nuova soglia della conferenza, in quanto viene calcolata come 0,50 * 1300 = 650 e oltre la soglia della conferenza esistente di 0,80 * 1300 = 1040.

Nel caso in cui venga effettuata una nuova chiamata WebRTC su Call Bridge cluster3 per lo stesso spazio, lo spazio è attivo sia su cluster1 che su cluster3, ma entrambi superano la soglia di conferenza esistente e quindi cerca un altro server al di sotto della nuova soglia di conferenza (50%) o della soglia di conferenza esistente (80%). In questo caso, solo cluster2 sarebbe ancora al di sotto della soglia conferenza esistente, ma è già al di sopra della nuova soglia conferenza a causa di un'altra chiamata a un altro spazio gestito in Cluster2 Call Bridge.

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 è stato impostato con un valore loadLimit di 600 in questo punto. Con 400 come carico corrente prima dell'arrivo della nuova chiamata, è stata superata la nuova soglia della conferenza di 0,5 * 600 = 300 ma è ancora inferiore al limite della conferenza esistente di 0,8 * 600 = 480. Di conseguenza, nella query di sostituzione viene visualizzato come livello di carico: 1 (anziché 2 quando il bridge di chiamate supera la soglia dell'80%).

Esempio 3: atterraggio della chiamata sul ponte di chiamata oltre la soglia di conferenza esistente

In questo caso, l'algoritmo di bilanciamento del carico non ha luogo in quanto sarebbe meglio inviare una risposta 488 al dispositivo di controllo delle chiamate che può decidere di instradare la chiamata a un altro Call Bridge all'interno del gruppo (che può essere al di sotto del limite dell'80%) o di instradarla a un gruppo Call Bridge diverso se il gruppo corrente ha esaurito le risorse (come opzione di fallback).

Il registro eventi non mostra esplicitamente questa parte in modo dettagliato, in quanto riporta semplicemente che ha superato la capacità:

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

Una volta inviata la chiamata a un bridge di chiamate diverso in grado di gestire il carico (ad esempio cluster2), viene visualizzato lo stesso algoritmo di bilanciamento del carico:

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)

Nota: in caso di chiamate al gateway, il CMS restituisce un messaggio di errore SIP 486. Per impostazione predefinita, CUCM interrompe il routing in base al parametro Service di Stop Routing su flag User Busy. È quindi possibile modificare questa impostazione per consentire il fallback per le chiamate del gateway agli altri bridge di chiamate.