Lógica de equilibrio de carga en Cisco Meeting Server

Introducción

Este documento describe la lógica de equilibrio de carga de Cisco Meeting Server (CMS) (antes producto Acano) que se describe en el informe técnico de balance de carga. Este documento visualiza este proceso en un diagrama de flujo y va con más detalle en el algoritmo de selección.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• componente Call Bridge de Cisco Meeting Server (y agrupación en clúster)
• Configuración de la API de Cisco Meeting Server

Componentes Utilizados

La información de este documento se basa en Cisco Meeting Server, versión 2.4.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

¿Qué es el algoritmo de equilibrio de carga del CMS?

El equilibrio de carga se ha introducido en la versión 2.1 de CMS para hacer un uso eficiente de los recursos de conferencia. Intenta minimizar el número de llamadas de distribución entre los Call Bridges que alojan el mismo espacio. Este mecanismo se basa en el encabezado Sustituir del protocolo de inicio de sesión (SIP) y es compatible con Cisco Unified Communications Manager (CUCM) como control de llamada. También es compatible con Expressway versión X8.11 (o posterior), en combinación con una CMS versión 2.4 o posterior. Las llamadas de CMA (tanto de tipo cliente grueso como de tipo WebRTC) se pueden equilibrar de carga también desde la versión 2.3 de CMS en adelante.

Nota: El equilibrio de carga de las llamadas de Lync/Skype no se admite en ninguna versión de CMS en este momento y, por lo tanto, este diagrama de flujo no se aplica.

Nota: La lógica de equilibrio de carga sólo se aplica a las llamadas a espacios CMS y, por lo tanto, no a las llamadas de gateway (llamadas P2P) o a las llamadas de inicio dual en este momento.

El proceso de balanceo de carga se resalta en el informe técnico en la sección Cómo el balanceo de carga utiliza la configuración en Configuración de Call Bridges para el balanceo de carga de llamadas entrantes. Se muestra en formato de texto y se muestra aquí en el diagrama de flujo (descarga ).

El diagrama de flujo utiliza algunas abreviaturas y terminología:

• CB = Puente de llamada
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  (de forma predeterminada, ConferenceLoadLimitBasisPoints existente es igual a 8000, que corresponde al 80%)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (de forma predeterminada, el newConferenceLoadLimitBasisPoints es igual a 5000, que corresponde al 50%)

Si se hace referencia a MediaProcessingLoad, se ve con respecto a ese Call Bridge concreto en el que ha finalizado la llamada. Este valor de carga se puede verificar con una API GET en /system/load en tiempo real y proporciona una representación de la carga real procesada por este Call Bridge en ese momento.

Si finaliza la llamada en el cuadro situado más abajo a la derecha, la llamada se redirige al servidor con la prioridad más alta. Puede ser el servidor Call Bridge en sí mismo u otro servidor dentro del Call Bridge Group en el que se realizó la llamada. En caso de que no se tome ninguna decisión en función de la carga y de si el espacio ya está activo en un Call Bridge, hay un empate con varios Call Bridges. En ese caso, la decisión final se toma en función de la preferencia predeterminada de Call Bridge asignada a cada espacio. Esta preferencia de Call Bridge se asigna a la creación del espacio automáticamente y no se puede configurar ya que se basa en los valores hash de varios atributos. Esto da como resultado una distribución par (aleatoria) para diferentes espacios en todos los Call Bridges.

Para ver la preferencia Call Bridge para un espacio en particular, tendría que verificar esto en el registro de eventos CMS como se muestra en estos ejemplos.

Ejemplos del Algoritmo de Balanceo de Carga

Esta sección contiene ejemplos de escenarios posibles y cómo el registro de eventos del CMS donde se desembarcó la llamada muestra el proceso de balanceo de carga como se describe en el diagrama de flujo.

Para estos ejemplos, se utilizó una configuración de laboratorio con un grupo de Call Bridge formado por tres Call Bridges. Las configuraciones ConferenceLoadLimitBasisPoints y newConferenceLoadLimitBasisPoints existentes se establecieron en sus valores predeterminados correspondientes al 80% y el 50% respectivamente del valor loadLimit.

Para verificar el MediaProcessingLoad actual en un Call Bridge determinado, puede navegar a https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load e iniciar sesión con una API o una cuenta de administrador como se muestra en la imagen.

Ejemplo 1: Sin carga en cualquier Call Bridge

En este ejemplo, no hay llamadas activas en ninguno de los Call Bridges. Por lo tanto, MediaProcessingLoad de todos los servidores es igual a cero.

Cuando realiza una llamada a uno de los Call Bridges (cluster1 aquí) (con el balanceo de carga habilitado en los dispositivos CMS y de control de llamadas), puede ver el registro de eventos en el Call Bridge donde se produjo la llamada:

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

en el que puede ver las líneas de consulta de reemplazo para cada uno de los Call Bridges en su Call Bridge Group que muestran el algoritmo de balanceo de carga que se divide en tres secciones:

• priority: la preferencia Call Bridge de ese espacio
• nivel de carga: el nivel de carga de ese Call Bridge en ese momento en el tiempo
• conferencia se está ejecutando - booleano si el espacio está activo en ese Call Bridge

Como en ese momento no se realizó ninguna llamada en el sistema, no hay carga en ninguno de los sistemas (todos 0) y la conferencia no se está ejecutando en ningún lugar (todos 0). A este respecto, la decisión final se toma sobre la base de la preferencia de Call Bridge del espacio. Se prefiere una prioridad más baja y, por lo tanto, la llamada se reemplaza aquí por Call Bridge denominado cluster3 como se ve en la línea de reemplazo de llamada.

En Call Bridge cluster3, puede ver las líneas de registro de eventos que indican esta llamada de reemplazo (así como de qué Call Bridge vino (cluster1 aquí) y el mismo ID de conferencia e ID de llamada):

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)

En caso de que la llamada ya se haya desembarcado en el Call Bridge con el valor de prioridad más bajo (cluster3 aquí para este espacio), puede ver las mismas líneas de consulta de reemplazo en el registro de eventos, pero ahora indica que utiliza el servidor local y que no hay línea de llamada en reemplazo:

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)

Ejemplo 2: Participantes que ya se encuentran en el espacio del grupo Call Bridge

En este ejemplo, el espacio ya está activo dentro del grupo de Call Bridge como terminal 1060@steven.lab llamado al espacio como se muestra en el ejemplo 1.

Hay dos situaciones en este caso:

1. El Call Bridge que aloja este espacio tiene una carga inferior al umbral de conferencia existente y, por lo tanto, puede aceptar la llamada.

2. El Call Bridge que aloja este espacio tiene una carga mayor que el umbral de conferencia existente y, por lo tanto, CMS intenta reemplazar la llamada a otro Call Bridge.

Escenario 1. Espacio activo y carga inferior al umbral de conferencia existente (80%)

En caso de que la llamada se desembarcara en un Call Bridge donde el espacio aún no estaba activo, el registro de eventos muestra ahora que el espacio está activo en Call Bridge con el nombre cluster3. Como el espacio está activo allí y la carga en ese servidor es menor que el umbral existente (nivel de carga: 0), se reemplaza la llamada.

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 conferencia se está ejecutando da preferencia a la prioridad en primer lugar, de modo que si hubiera habido varios candidatos con un nivel de carga bajo el umbral de conferencia existente, se reduciría a la preferencia Call Bridge según el valor de prioridad. Sin embargo, ese no es el caso aquí.

Situación hipotética 2. Espacio activo y carga superior al umbral de conferencia existente (80%)

En este caso, la llamada no se reemplaza por ese Call Bridge, sino que busca otro Call Bridge dentro del grupo que todavía tenga algunos recursos disponibles. Primero, verifica si hay Call Bridges con una carga inferior al 50% (nuevo umbral de conferencia) y carga esos primero. Si no hay ninguno por debajo de este umbral, verifica si todavía hay disponible por debajo del 80% (umbral de conferencia existente).

Si la carga en Call Bridge cluster3 se verifica después de las llamadas de los ejemplos 1 y 2 (escenario 1), muestra una carga de 2000.

Suponga que el loadLimit para ese clúster de Call Bridge3 se estableció en 2250 (como ejemplo), entonces este Call Bridge supera el umbral de conferencia existente ya que se calcula como 0.80 * 2250 = 1800

Todavía hay dos casos que diferenciar en este escenario.

Caso 1: Varios servidores del grupo aún con un umbral de conferencia inferior al nuevo (50%)

Los otros dos servidores del grupo no tienen ninguna llamada manejada todavía, por lo que la carga sigue en 0 y por lo tanto ambos podrían manejar la llamada. La decisión final se toma así en base a la preferencia Call Bridge para este espacio. Como Call Bridge cluster3 ya está completo, los sistemas eligen la prioridad más baja de cluster1 y cluster2 que es cluster1 en este caso.

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)

Observe que el nivel de carga: 2 en el Call Bridge del cluster3 indica que se superó el umbral de conferencia existente, por lo que aunque el espacio estaba activo allí la llamada no se balancea la carga en ese servidor. En su lugar, observa la prioridad de espacio más baja de los otros Call Bridges con un nivel de carga: 0 (que significa un uso inferior al 50%), que es cluster1 en este caso.

Caso 2: Solo un servidor en un grupo con un umbral de conferencia inferior al nuevo (50%) o un umbral de conferencia existente (80%)

Después de la última llamada (y de las llamadas a otro espacio para el clúster 2), se vieron las cargas descritas en los Call Bridges:

• clúster 1 - 1200
• clúster 2 - 400
• clúster 3 - 4000

Suponga ahora que el loadLimit establecido en el Call Bridge de cluster1 sería 1300, entonces este Call Bridge está por encima del nuevo umbral de conferencia ya que se calcula como 0.50 * 1300 = 650 así como sobre el umbral de conferencia existente de 0.80 * 1300 = 1040.

En el caso de que una nueva llamada WebRTC llegue ahora al clúster 3 de Call Bridge para ese mismo espacio, el espacio está activo tanto en el clúster 1 como en el clúster 3, pero ambos superan el umbral de conferencia existente y, por lo tanto, busca otro servidor bajo el nuevo umbral de conferencia (50%) o el umbral de conferencia existente (80%). En este caso, sólo el cluster2 seguiría estando por debajo del umbral de conferencia existente, pero ya está por encima del nuevo umbral de conferencia debido a otra llamada a otro espacio manejado en el 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)

Clúster2 se ha configurado con un valor loadLimit de 600 aquí. Con 400 como carga actual antes de la entrada de la nueva llamada, supera el nuevo umbral de conferencia de 0.5 * 600 = 300, pero sigue estando por debajo del límite de conferencia existente de 0.8 * 600 = 480. Esto se muestra en la consulta de reemplazo como nivel de carga: 1 (en lugar de 2 cuando el Call Bridge supera el umbral del 80%).

Ejemplo 3: Inicio de llamada en Call Bridge sobre el umbral de conferencia existente

En este caso, el algoritmo de balanceo de carga no se produce, ya que sería mejor enviar una respuesta 488 al dispositivo de control de llamadas que luego puede decidir intentar rutear la llamada a un Call Bridge diferente dentro del grupo (que puede estar por debajo del límite del 80%) o incluso enrutarla a un grupo diferente de Call Bridge si el grupo actual está sin recursos (como opción de reserva).

El registro de eventos no muestra esta parte de forma explícita con mucho detalle, ya que solo informa que se pasó por encima de la capacidad:

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 vez que la llamada se envía a un Call Bridge diferente que puede manejar la carga (cluster2 por ejemplo), se muestra el mismo algoritmo de balanceo de carga:

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: En caso de llamadas de gateway, el CMS devuelve un mensaje de error SIP 486 en su lugar. De forma predeterminada, CUCM detiene el ruteo según el parámetro de servicio de Detener ruteo en el indicador Ocupado del usuario, por lo que es posible que desee cambiar esta configuración para permitir el repliegue de las llamadas de gateway a los otros callbridges.