Lógica del Equilibrio de carga en Cisco que encuentra el servidor

Introducción

Este documento describe la lógica del Equilibrio de carga de Cisco que resuelve el servidor (CMS) (antes producto de Acano) que se cubre en el White Paper del Equilibrio de carga. Este documento visualiza este proceso en un organigrama y va más detalladamente en el algoritmo de selección.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco que hace frente al componente del Bridge de la llamada del servidor (y a agrupar de él)
• Cisco que hace frente a la configuración del servidor API

Componentes Utilizados

La información en este documento se basa en Cisco que resuelve el servidor en la versión 2.4.x.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

¿Cuál es el algoritmo del Equilibrio de carga de CMS?

El Equilibrio de carga se ha introducido en la versión 2.1 de CMS para hacer el uso eficiente de los recursos de conferencia. Intenta minimizar el número de llamadas de la distribución entre los Bridges de la llamada que reciben el mismo espacio. Este mecanismo se basa en la encabezado de los reemplaces en el Session Initiation Protocol (SIP) y se soporta en el administrador de las Comunicaciones unificadas de Cisco (CUCM) como el Control de llamadas. También se soporta con Expressway en una versión de X8.11 (o más alto), conjuntamente con una Versión CMS de 2.4 o más alto. Las llamadas de CMA (cliente grueso y tipo de WebRTC) pueden ser carga equilibrada también de la Versión CMS 2.3 hacia adelante.

Note: El Equilibrio de carga de las llamadas de Lync/de Skype no se soporta en ninguna Versión CMS en este momento a tiempo y este organigrama no se aplica así.

Note: La lógica del Equilibrio de carga solicita solamente las llamadas a los espacios de CMS y así no para las llamadas del gateway (llamadas P2P) o el dual-hogar llama en este momento a tiempo.

El proceso del Equilibrio de carga se resalta en el White Paper en la sección cómo el Equilibrio de carga utiliza las configuraciones bajo configurar los Bridges de la llamada para las llamadas entrantes del Equilibrio de carga. Se muestra en el formato de texto y se visualiza aquí en el organigrama (descarga).

El organigrama hace uso de ciertas abreviaturas y terminología:

• CB = Bridge de la llamada
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  (por abandono los existingConferenceLoadLimitBasisPoints igualan 8000, que corresponde hasta el 80%)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (por abandono los newConferenceLoadLimitBasisPoints igualan 5000, que corresponde hasta el 50%)

Si se refiere MediaProcessingLoad, se ve con respecto a ese Bridge determinado de la llamada donde la llamada ha aterrizado. Este valor de carga se puede verificar con un API GET en /system/load en el tiempo real y da una representación de la carga real procesada por este Bridge de la llamada en ese momento a tiempo.

Si usted termina para arriba para su llamada en el cuadro de derecha más bajo, reorienta la llamada al servidor con la prioridad más alta. Éste puede ser el servidor sí mismo del Bridge de la llamada u otro servidor dentro del Grupo de Bridge de la llamada en quien la llamada aterrizó. En caso de que no se tome ninguna decisión basado en la carga y si el espacio es activo ya en un Bridge de la llamada, hay un lazo con los Bridges de las varias llamadas. En ese caso, se toma la decisión final basado en la preferencia predeterminada del Bridge de la llamada que se asigna a cada espacio. Esta preferencia del Bridge de la llamada se afecta un aparato en la creación del espacio automáticamente y no es configurable mientras que se basa en los valores de troceo de varios atributos. Esto da lugar incluso a una distribución (al azar) para diversos espacios a través de todos los Bridges de la llamada.

Para ver la preferencia del Bridge de la llamada para un espacio determinado, usted necesitaría verificar esto en el registro de acontecimientos de CMS como se muestra en los ejemplos.

Ejemplos del algoritmo del Equilibrio de carga

Usted puede revisar en esta sección un par de ejemplos de los escenarios posibles y cómo el registro de acontecimientos de CMS donde la llamada aterrizada muestra el proceso del Equilibrio de carga según lo cubierto en el organigrama.

Por estos ejemplos, una configuración de laboratorio fue utilizada con un Grupo de Bridge de la llamada de tres Bridges de la llamada. Los existingConferenceLoadLimitBasisPoints y las configuraciones de los newConferenceLoadLimitBasisPoints fueron fijados a sus valores predeterminados correspondiente al 80% y al 50% respectivamente del valor del loadLimit.

Para marcar el MediaProcessingLoad actual en un Bridge determinado de la llamada, usted puede apenas hojear a https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load y iniciar sesión con un API o una cuenta de administración según lo visualizado en la imagen.

Ejemplo 1: Ninguna carga en cualquier Bridge de la llamada

En este ejemplo, no hay llamadas activas en los Bridges uces de los de la llamada. Así el MediaProcessingLoad de todos los iguales cero de los servidores.

Cuando usted pone una llamada a uno de los Bridges de la llamada (cluster1 aquí) (con el Equilibrio de carga habilitado en CMS y los dispositivos de Control de llamadas), usted puede ver el inicio del evento el Bridge de la llamada donde la llamada aterrizó:

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 cuál usted puede ver las líneas de la interrogación del reemplazo para cada uno de los Bridges de la llamada en su Grupo de Bridge de la llamada que nos muestran el algoritmo del Equilibrio de carga cuál se divide en tres secciones:

• prioridad - la preferencia del Bridge de la llamada de ese espacio
• carga llana - la carga llana de ese Bridge de la llamada en ese momento a tiempo
• la conferencia se está ejecutando - boleana si el espacio es activo en ese Bridge de la llamada

Pues no se puso ningunas llamadas en aquel momento en el sistema, no hay carga en los sistemas uces de los (el 0) y la conferencia no se está ejecutando dondequiera (el 0). En eso se hacen los respetos, la decisión final basado en la preferencia del Bridge de la llamada del espacio. Se prefiere una prioridad baja y la llamada se substituye así aquí para llamar cluster3 nombrado Bridge según lo considerado por la línea de reemplazo de la llamada.

En el Bridge cluster3 de la llamada, usted puede ver las líneas de registro de acontecimientos que indican esta llamada de reemplazo (así como que llaman el Bridge vino de (cluster1 aquí) y el mismo ID de conferencia y 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 aterrizara ya en el Bridge de la llamada con el valor de prioridad más bajo (cluster3 aquí para este espacio), después usted puede todavía ver lo mismo substituir las líneas de la interrogación en el registro de acontecimientos pero indica ahora que utiliza al servidor local y no hay línea de reemplazo de la llamada:

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: Ya participantes en el espacio en el Grupo de Bridge de la llamada

En este ejemplo, el espacio es ya activo dentro del Grupo de Bridge de la llamada como punto final 1060@steven.lab llamado en el espacio como se muestra en el ejemplo 1.

Hay dos situaciones en este caso:

1. El Bridge de la llamada que recibe este espacio tiene una carga más bajo que el umbral existente de la conferencia y puede así validar la llamada.

2. El Bridge de la llamada que recibe este espacio tiene una carga más arriba que el umbral existente de la conferencia y CMS intenta así substituir la llamada a otro Bridge de la llamada.

Espacio activo del escenario 1. y un umbral que existente más bajo de la conferencia de la carga (los 80%)

En caso de que la llamada aterrizara en un Bridge de la llamada donde no estaba todavía active el espacio, el registro de acontecimientos muestra ahora que el espacio es activo en el Bridge de la llamada con el nombre cluster3. Pues el espacio es activo allí y la carga en ese servidor es más baja que el umbral existente (carga llana: se substituye 0), 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 está ejecutando la preferencia de las tomas a la prioridad primero tan si hubiera habido candidatos múltiples con una carga llana bajo umbral existente de la conferencia, después bajaría a la preferencia del Bridge de la llamada según el valor de prioridad. Sin embargo, ése no es el caso aquí.

Espacio del Active del escenario 2. y umbral más arriba que existente de la conferencia de la carga (los 80%)

En este caso, la llamada no se substituye por ese Bridge de la llamada sino que busca bastante otro Bridge de la llamada dentro del grupo que todavía tiene algunos recursos disponibles. Primero, marca si hay Bridges de la llamada con una carga más baja el de 50% (nuevo umbral de la conferencia) y carga esos primero. Si no hay ninguno bajo este umbral, marca si hay los 80% inferiores todavía disponibles (umbral existente de la conferencia).

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

Asuma, eso que el loadLimit para ese Bridge cluster3 de la llamada fue fijado a 2250 (apenas como un ejemplo), después este Bridge de la llamada está sobre el umbral existente de la conferencia tanto como se calcula como 0.80 * 2250 = 1800

Hay dos casos todavía para hacer la diferenciación en este escenario.

Caso 1: Los servidores múltiples en el grupo todavía con una carga bajan que el nuevo umbral de la conferencia (los 50%)

Los otros dos servidores en el grupo no tienen ninguna llamadas todavía dirigieron así que la carga todavía está en 0 y ella podrían ambas manejar así la llamada. La decisión del final se toma así basado en la preferencia del Bridge de la llamada por este espacio. Pues el Bridge cluster3 de la llamada es ya lleno, los sistemas escogen la prioridad más baja fuera de cluster1 y de cluster2 que sea 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)

Note que el nivel de la carga: 2 en el Bridge de la llamada cluster3 indica que pasó el umbral existente de la conferencia, así que aunque el espacio era activo allí la llamada no es carga equilibrada a ese servidor. En lugar, mira la prioridad más baja del espacio de los otros Bridges de la llamada con un nivel de la carga: 0 (significando más bajo el uso de 50%), que es cluster1 en este caso.

Caso 2: Solamente un servidor en un grupo con umbral más bajo de la conferencia de la carga que un nuevo (el 50%) o el umbral existente de la conferencia (el 80%)

Después de que la última llamada (y las llamadas al otro espacio a cluster2), las cargas descritas fueran consideradas en los Bridges de la llamada:

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

Asuma ahora que el loadLimit como fija en el Bridge de la llamada cluster1 sería 1300, después este Bridge de la llamada está sobre el nuevo umbral de la conferencia tanto como se calcula como 0.50 * 1300 = 650 así como sobre el umbral existente de la conferencia de 0.80 * 1300 = 1040.

En caso de que una nueva llamada de WebRTC ahora viniera adentro en el Bridge cluster3 de la llamada para ese mismo espacio, el espacio es activo ambos en cluster1 y cluster3 pero ambos están sobre el umbral existente de la conferencia y busca así otro servidor bajo el nuevo umbral de la conferencia (el 50%) o umbral existente de la conferencia (el 80%). En este caso, solamente cluster2 todavía estaría bajo umbral existente de la conferencia, pero está sobre el nuevo umbral de la conferencia ya debido a otra llamada a otro espacio manejado en el Bridge de la llamada cluster2.

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 se ha configurado con un valor del loadLimit de 600 aquí. Con 400 como la carga actual antes de que viniera la nueva llamada adentro, él está sobre el nuevo umbral de la conferencia de 0.5 * 600 = 300 pero él todavía está bajo límite existente de la conferencia de 0.8 * 600 = 480. Así esto aparece en la interrogación del reemplazo como nivel de la carga: 1 (en vez de 2 cuando el Bridge de la llamada está sobre el umbral del 80%).

Ejemplo 3: Aterrizaje de la llamada en el Bridge de la llamada sobre el umbral existente de la conferencia

En este caso, el algoritmo del Equilibrio de carga no ocurre pues sería mejor enviar una respuesta 488 de nuevo al dispositivo de Control de llamadas que puede entonces decidir a intentar rutear la llamada a un diverso Bridge de la llamada dentro del grupo (que puede estar bajo límite del 80%) o incluso rutearlo a un diverso Grupo de Bridge de la llamada si el grupo actual está fuera de los recursos (como opción de repliegue).

El registro de acontecimientos no muestra explícitamente que esta parte en mucho detalle como ella apenas señala que pasó 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

Se muestra la llamada se envía una vez a un diverso Bridge de la llamada que pueda manejar la carga (cluster2 por ejemplo), el mismo algoritmo del Equilibrio 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)

Note: En caso de las llamadas del gateway, CMS devuelve un mensaje de error de 486 SORBOS en lugar de otro. Por abandono CUCM para la encaminamiento según el parámetro de servicio de la encaminamiento de la parada en el indicador del usuario ocupado así que usted puede querer cambiar esta configuración para permitir el retraso para las llamadas del gateway a sus otros callbridges.