Logique d'équilibrage de charge sur Cisco Meeting Server

Introduction

Ce document décrit la logique d'équilibrage de charge de Cisco Meeting Server (CMS) (anciennement produit Acano) qui est couverte sur le livre blanc d'équilibrage de charge. Ce document visualise ce processus dans un organigramme et va plus en détail sur l'algorithme de sélection.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Composant Cisco Meeting Server Call Bridge (et mise en grappe de celui-ci)
• Configuration de l'API Cisco Meeting Server

Composants utilisés

Les informations contenues dans ce document sont basées sur Cisco Meeting Server, version 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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Quel est l’algorithme d’équilibrage de charge du CMS ?

L'équilibrage de charge a été introduit dans la version 2.1 de CMS afin d'optimiser l'utilisation des ressources de conférence. Il tente de réduire le nombre d'appels de distribution entre les ponts d'appel qui hébergent le même espace. Ce mécanisme est basé sur l'en-tête de remplacement dans le protocole SIP (Session Initiation Protocol) et est pris en charge dans Cisco Unified Communications Manager (CUCM) comme contrôle d'appel. Il est également pris en charge avec Expressway version X8.11 (ou ultérieure), en combinaison avec CMS version 2.4 ou ultérieure. Les appels CMA (client épais et type WebRTC) peuvent également être équilibrés à partir de la version 2.3 de CMS.

Remarque : l'équilibrage de charge des appels Lync/Skype n'est actuellement pris en charge dans aucune version de CMS. Par conséquent, ce diagramme ne s'applique pas.

Remarque : la logique d'équilibrage de charge s'applique uniquement aux appels vers les espaces CMS et donc pas aux appels de passerelle (appels P2P) ni aux appels à domicile double à ce moment.

Le processus d'équilibrage de charge est mis en évidence dans le livre blanc dans la section Comment l'équilibrage de charge utilise les paramètres sous Configuration des ponts d'appels pour l'équilibrage de charge des appels entrants. Il est affiché au format texte et est visualisé ici dans l'organigramme (télécharger ).

L'organigramme utilise certaines abréviations et certains termes :

• CB = pont d'appel
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  (par défaut, la valeur de l'attribut existingConferenceLoadLimitBasisPoints est égale à 8 000, ce qui correspond à 80 %)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (par défaut, newConferenceLoadLimitBasisPoints est égal à 5 000, ce qui correspond à 50 %)

Si MediaProcessingLoad est référencé, il est vu en ce qui concerne ce pont d'appel particulier où l'appel a atterri. Cette valeur de charge peut être vérifiée avec une API GET sur /system/load en temps réel et donne une représentation de la charge réelle traitée par ce pont d'appel à ce moment.

Si vous terminez votre appel dans la zone la plus à droite, il redirige l'appel vers le serveur ayant la priorité la plus élevée. Il peut s'agir du serveur Pont d'appels lui-même ou d'un autre serveur du groupe Pont d'appels sur lequel l'appel a été reçu. Si aucune décision n'est prise en fonction de la charge et si l'espace est déjà actif sur un pont d'appel, il y a un lien avec plusieurs ponts d'appel. Dans ce cas, la décision finale est prise en fonction de la préférence de pont d'appel par défaut qui est attribuée à chaque espace. Cette préférence de pont d'appel est allouée à la création de l'espace automatiquement et n'est pas configurable car elle est basée sur les valeurs de hachage de plusieurs attributs. Il en résulte une distribution uniforme (aléatoire) pour différents espaces sur tous les ponts d'appel.

Pour afficher la préférence Call Bridge pour un espace particulier, vous devez vérifier cela dans le journal des événements CMS, comme indiqué dans ces exemples.

Exemples d'algorithme d'équilibrage de charge

Cette section contient des exemples de scénarios possibles et montre comment le journal des événements du CMS où l'appel a été reçu indique le processus d'équilibrage de charge tel que décrit dans l'organigramme.

Pour ces exemples, une configuration de travaux pratiques a été utilisée avec un groupe de ponts d’appels de trois ponts d’appels. Les configurations existingConferenceLoadLimitBasisPoints et newConferenceLoadLimitBasisPoints ont été définies sur leurs valeurs par défaut correspondant respectivement à 80 % et 50 % de la valeur loadLimit.

Afin de vérifier le MediaProcessingLoad actuel sur un pont d'appel particulier, vous pouvez naviguer vers https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load et vous connecter avec une API ou un compte admin comme affiché sur l'image.

Exemple 1 : aucune charge sur un pont d'appel

Dans cet exemple, aucun appel n'est actif au niveau des ponts d'appels. Par conséquent, MediaProcessingLoad de tous les serveurs est égal à zéro.

Lorsque vous passez un appel vers l'un des ponts d'appel (cluster1 ici) (avec l'équilibrage de charge activé sur le CMS et les périphériques de contrôle d'appel), vous pouvez voir le journal des événements sur le pont d'appel où l'appel a atterri :

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

dans laquelle vous pouvez voir les lignes de requête de remplacement pour chacun des ponts d'appel dans votre groupe de ponts d'appel qui nous montrent l'algorithme d'équilibrage de charge qui est divisé en trois sections :

• priority - Préférence de pont d'appel de cet espace
• niveau de charge - le niveau de charge de ce pont d'appel à ce moment précis
• conference is running - valeur booléenne indiquant si l'espace est actif sur ce pont d'appel

Comme aucun appel n'a été passé à ce moment-là dans le système, il n'y a aucune charge sur aucun des systèmes (tous 0) et la conférence ne s'exécute nulle part (tous 0). À cet égard, la décision finale est prise en fonction de la préférence Call Bridge de l'espace. Une priorité inférieure est préférable et l'appel est donc remplacé ici par le pont d'appel nommé cluster3 comme indiqué par la ligne d'appel de remplacement.

Sur le cluster Call Bridge3, vous pouvez voir les lignes du journal des événements qui indiquent cet appel de remplacement (ainsi que le pont d'appel d'où il provient (cluster1 ici) et les mêmes ID de conférence et d'appel) :

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)

Si l'appel a déjà atterri sur le pont d'appel avec la valeur de priorité la plus basse (cluster3 ici pour cet espace), alors vous pouvez toujours voir les mêmes lignes de requête de remplacement dans le journal des événements mais il indique maintenant qu'il utilise le serveur local et qu'il n'y a pas de ligne d'appel de remplacement :

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)

Exemple 2 : Participants déjà présents sur l'espace du groupe Pont d'appels

Dans cet exemple, l'espace est déjà actif au sein du groupe de ponts d'appel en tant que point de terminaison 1060@steven.lab appelé dans l'espace comme illustré dans l'exemple 1.

Il y a deux situations dans ce cas :

1. Le pont d'appel qui héberge cet espace a une charge inférieure au seuil de conférence existant et peut donc accepter l'appel.

2. Le pont d'appel qui héberge cet espace a une charge supérieure au seuil de conférence existant et CMS tente donc de remplacer l'appel vers un autre pont d'appel.

Scénario 1. Espace actif et charge inférieurs au seuil de conférence existant (80 %)

Si l'appel a atterri sur un pont d'appel où l'espace n'était pas encore actif, le journal des événements indique maintenant que l'espace est actif sur le pont d'appel avec le nom cluster3. Comme l'espace est actif et que la charge sur ce serveur est inférieure au seuil existant (niveau de charge : 0), l'appel est remplacé.

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 conférence est en cours d'exécution prend la préférence sur la priorité en premier. Ainsi, s'il y avait eu plusieurs candidats avec un niveau de charge inférieur au seuil de conférence existant, alors il reviendrait à la préférence Pont d'appels selon la valeur de priorité. Mais ce n'est pas le cas ici.

Scénario 2. Espace actif et charge supérieurs au seuil de conférence existant (80 %)

Dans ce cas, l'appel n'est pas remplacé par ce pont d'appel, mais il recherche un autre pont d'appel au sein du groupe qui dispose encore de certaines ressources. Tout d'abord, il vérifie s'il existe des ponts d'appel avec une charge inférieure à 50 % (nouveau seuil de conférence) et charge ceux-ci en premier. S'il n'y en a pas sous ce seuil, il vérifie s'il y a toujours des disponibilités sous 80 % (seuil de conférence existant).

Si la charge sur le cluster Call Bridge3 est vérifiée après les appels des exemples 1 et 2 (scénario 1), elle affiche une charge de 2 000.

Supposons que loadLimit pour ce cluster de ponts d'appel3 a été défini sur 2250 (juste à titre d'exemple), alors ce pont d'appel dépasse le seuil de conférence existant, calculé comme 0,80 * 2250 = 1800

Il reste deux cas à différencier dans ce scénario.

Cas 1 : plusieurs serveurs du groupe avec une charge inférieure au nouveau seuil de conférence (50 %)

Les deux autres serveurs du groupe n'ont toujours aucun appel traité, donc la charge est toujours à 0 et ils peuvent donc tous les deux traiter l'appel. La décision finale est donc prise en fonction de la préférence de pont d'appel pour cet espace. Comme le cluster3 Call Bridge est déjà plein, les systèmes choisissent la priorité la plus basse parmi le cluster1 et le cluster2, qui est le cluster1 dans ce cas.

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)

Notez que le niveau de charge : 2 sur le pont d'appel de cluster3 indique qu'il a dépassé le seuil de conférence existant. Ainsi, même si l'espace était actif à cet endroit, la charge de l'appel n'est pas équilibrée vers ce serveur. Au lieu de cela, il recherche la priorité d'espace la plus basse des autres ponts d'appel avec un niveau de charge : 0 (ce qui signifie une utilisation inférieure à 50 %), qui est cluster1 dans ce cas.

Cas 2 : un seul serveur dans un groupe avec une charge inférieure au nouveau seuil de conférence (50 %) ou au seuil de conférence existant (80 %)

Après le dernier appel (et les appels vers un autre espace vers cluster2), les charges décrites ont été vues sur les ponts d'appel :

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

Supposons maintenant que loadLimit défini sur cluster1 Call Bridge serait 1300, ce pont d'appel dépasse alors le nouveau seuil de conférence calculé comme 0,50 * 1300 = 650 ainsi que le seuil de conférence existant de 0,80 * 1300 = 1040.

Dans le cas où un nouvel appel WebRTC arriverait maintenant sur le cluster3 Call Bridge pour ce même espace, l'espace est actif à la fois sur le cluster1 et le cluster3, mais les deux sont au-dessus du seuil de conférence existant et il recherche donc un autre serveur sous le nouveau seuil de conférence (50 %) ou le seuil de conférence existant (80 %). Dans ce cas, seul le cluster2 serait toujours sous le seuil de conférence existant, mais il est déjà au-dessus du nouveau seuil de conférence en raison d'un autre appel vers un autre espace géré sur le pont d'appel du 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 a été configuré avec une valeur loadLimit de 600 ici. Avec 400 comme charge actuelle avant l'arrivée du nouvel appel, il est au-dessus du nouveau seuil de conférence de 0,5 * 600 = 300 mais il est toujours sous la limite de conférence existante de 0,8 * 600 = 480. Ceci apparaît donc dans la requête de remplacement comme niveau de charge : 1 (au lieu de 2 lorsque le pont d'appel est au-dessus du seuil de 80 %).

Exemple 3 : Pont de renvoi d'appel sur le pont d'appel sur le seuil de conférence existant

Dans ce cas, l'algorithme d'équilibrage de charge n'a pas lieu car il serait préférable de renvoyer une Réponse 488 au dispositif de contrôle d'appel qui peut alors décider d'essayer d'acheminer l'appel vers un pont d'appel différent au sein du groupe (qui peut être sous la limite de 80%) ou même de l'acheminer vers un groupe de pont d'appel différent si le groupe actuel est à court de ressources (comme option de secours).

Le journal des événements n'affiche pas explicitement cette partie en détail, car il indique simplement qu'elle a dépassé sa 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

Une fois que l'appel est envoyé à un pont d'appel différent qui peut gérer la charge (cluster2 par exemple), le même algorithme d'équilibrage de charge est affiché :

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)

Remarque : en cas d'appels de passerelle, le CMS renvoie un message d'erreur SIP 486 à la place. Par défaut, CUCM arrête le routage selon le paramètre de service de l'indicateur Arrêter le routage si l'utilisateur est occupé afin que vous puissiez vouloir modifier ce paramètre pour permettre la reprise pour les appels de passerelle vers vos autres ponts d'appel.