Logica voor taakverdeling op Cisco Meeting Server

Inleiding

Dit document beschrijft de loadbalanceringslogica van Cisco Meeting Server (CMS) (voorheen Acano-product) die in het witboek taakverdeling wordt besproken. Dit document visualiseert dit proces in een stroomschema en gaat meer in detail over het selectiealgoritme.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Meeting Server Call Bridge-component (en clustering daarvan)
• Cisco Meeting Server API-configuratie

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Meeting Server, versie 2.4.x.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Wat is het taakverdelingsalgoritme van het CMS?

Taakverdeling is geïntroduceerd in versie 2.1 van CMS om efficiënt gebruik te maken van conferentiemiddelen. Het probeert om het aantal distributiegesprekken tussen de Call Bridges die dezelfde ruimte hosten te minimaliseren. Dit mechanisme is gebaseerd op de Vervanging van de header in Session Initiation Protocol (SIP) en wordt ondersteund in Cisco Unified Communications Manager (CUCM) als gespreksbeheer. Het wordt ook ondersteund met Expressway versie X8.11 (of hoger), in combinatie met een CMS versie 2.4 of hoger. CMA-oproepen (zowel dikke client als WebRTC-type) kunnen vanaf CMS versie 2.3 ook worden gebalanceerd.

Opmerking: taakverdeling van Lync/Skype-gesprekken wordt momenteel in geen enkele CMS-versie ondersteund en dit stroomschema is dus niet van toepassing.

Opmerking: de logica voor taakverdeling is alleen van toepassing op oproepen naar CMS-ruimtes en dus niet op gatewaygesprekken (P2P-gesprekken) of dual-home-gesprekken op dit moment.

Het proces voor taakverdeling wordt gemarkeerd in het witboek in de sectie Hoe taakverdeling de instellingen gebruikt onder Gespreksbruggen configureren voor inkomende oproepen voor taakverdeling. Het wordt in tekstformaat weergegeven en wordt hier in het stroomschema (download) weergegeven.

Het stroomschema maakt gebruik van enkele afkortingen en terminologie:

• CB = Call Bridge
• BestaandeConferenceLoadLimit = bestaandeConferenceLoadLimitBasisPoints * loadLimit
  (standaard is de bestaande ConferenceLoadLimitBasisPoints gelijk aan 8000, wat overeenkomt met 80%)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (standaard is de nieuwe ConferenceLoadLimitBasisPoints gelijk aan 5000, wat overeenkomt met 50%)

Als MediaProcessingLoad wordt vermeld, wordt het gezien in verband met die bepaalde Call Bridge waar de oproep is geland. Deze belastingswaarde kan worden geverifieerd met een API GET op /system/load in real-time en geeft een weergave van de werkelijke belasting die op dat moment door deze Call Bridge wordt verwerkt.

Als u uw vraag in de lagere meest rechtse doos beëindigt, richt het de vraag aan de server met de hoogste prioriteit opnieuw. Dit kan de Call Bridge-server zelf zijn of een andere server binnen de Call Bridge Group waarop de oproep is geland. Als er geen beslissing wordt genomen op basis van de lading en of de ruimte al actief is op een Call Bridge, is er een koppeling met meerdere Call Bridges. In dat geval wordt de uiteindelijke beslissing genomen op basis van de standaard Call Bridge-voorkeur die aan elke ruimte is toegewezen. Deze voorkeur van de Brug van Vraag wordt toegewezen bij de verwezenlijking van de ruimte automatisch en is niet configureerbaar aangezien het op de knoeiboelwaarden van verscheidene eigenschappen gebaseerd is. Dit resulteert in een gelijke (willekeurige) verdeling voor verschillende ruimtes over alle Call Bridges.

Om de Call Bridge-voorkeur voor een bepaalde ruimte te zien, moet u dit verifiëren in het CMS-gebeurtenissenlogboek zoals in deze voorbeelden wordt getoond.

Voorbeelden van het algoritme voor taakverdeling

Deze sectie bevat voorbeelden van mogelijke scenario's en hoe het gebeurtenislogboek van CMS waar de vraag landde het proces van de lastverdeling toont zoals die in het stroomschema wordt behandeld.

Voor deze voorbeelden werd een lab setup gebruikt met een Call Bridge Group van drie Call Bridges. De bestaande configuraties van ConferenceLoadLimitBasisPoints en newConferenceLoadLimitBasisPoints zijn ingesteld op hun standaardwaarden die respectievelijk overeenkomen met 80% en 50% van de loadLimit waarde.

Om de huidige MediaProcessingLoad op een bepaalde Call Bridge te controleren, kunt u bladeren naar https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load en inloggen met een API- of admin-account zoals op het beeld wordt weergegeven.

Voorbeeld 1: geen lading op een Call Bridge

In dit voorbeeld, zijn er geen vraag actief bij om het even welke Oproepbruggen. De MediaProcessingLoad van alle servers is dus gelijk aan nul.

Wanneer u een oproep plaatst naar een van de Call Bridges (cluster1 hier) (waarbij taakverdeling is ingeschakeld op zowel de CMS- als de Call Control-apparaten), kunt u de gebeurtenisaanmelding zien op de Call Bridge waar de oproep is geland:

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

waarin u de vervangt query lijnen voor elk van de Call Bridges in uw Call Bridge Group kunt zien die ons het load balancing algoritme tonen dat is opgesplitst in drie secties:

• prioriteit - de voorkeur van Call Bridge van die ruimte
• belastingsniveau - het belastingsniveau van die Call Bridge op dat moment
• conferentie wordt uitgevoerd - boolean of de ruimte actief is op die Call Bridge

Aangezien er op dat moment geen oproepen in het systeem zijn geplaatst, is er geen belasting op een van de systemen (alle 0) en de conferentie loopt niet ergens (alle 0). In dat opzicht wordt de uiteindelijke beslissing genomen op basis van de Call Bridge-voorkeur van de ruimte. Een lagere prioriteit heeft de voorkeur en daarom wordt de oproep hier vervangen om Call Bridge met de naam cluster3 te gebruiken, zoals gezien door de vervangende oproeplijn.

Op Call Bridge cluster3 kunt u de gebeurtenislogregels zien die deze vervangende oproep aangeven (en ook van welke Call Bridge het afkomstig is (cluster1 hier) en dezelfde conferentie-ID en call-ID):

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)

Indien de oproep al op de Call Bridge is geland met de laagste prioriteitswaarde (cluster3 hier voor deze ruimte), dan kunt u nog steeds dezelfde vervangt query lijnen in het gebeurtenislogboek zien, maar het geeft nu aan dat het de lokale server gebruikt en er geen vervangende call line is:

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)

Voorbeeld 2: reeds deelnemers aan de ruimte in de Call Bridge Group

In dit voorbeeld is de ruimte al actief binnen de Call Bridge Group als eindpunt 1060@steven.lab in de ruimte opgeroepen zoals in voorbeeld 1.

Er zijn twee situaties in dit geval:

1. De Call Bridge die deze ruimte host, heeft een lading die lager is dan de bestaande conferentiedrempel en kan dus de oproep accepteren.

2. De Call Bridge die deze ruimte host, heeft een belasting die hoger is dan de bestaande conferentiedrempel en dus probeert CMS de oproep naar een andere Call Bridge te vervangen.

Scenario 1. Actieve ruimte en lading lager dan bestaande vergaderdrempel (80%)

Indien de oproep is geland op een Call Bridge waar de ruimte nog niet actief was, laat het gebeurtenissenlogboek nu zien dat de ruimte actief is op Call Bridge met de naam cluster3. Aangezien de ruimte daar actief is en de lading op die server lager is dan de bestaande drempel (ladingsniveau: 0), wordt de vraag vervangen.

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'

De conferentie loopt neemt de voorkeur aan de prioriteit eerst, dus als er meerdere kandidaten met een belastingsniveau onder de bestaande conferentiedrempel zouden zijn geweest, dan zou het neerkomen op de Call Bridge-voorkeur volgens de prioriteitswaarde. Dat is hier echter niet het geval.

Scenario 2. Actieve ruimte en lading hoger dan bestaande vergaderdrempel (80%)

In dit geval wordt de oproep niet vervangen door die Call Bridge, maar wordt er in plaats daarvan gezocht naar een andere Call Bridge binnen de groep die nog over bepaalde bronnen beschikt. Eerst, controleert het als er Call Bridges met een lading lager dan 50% (nieuwe conferentiedrempel) zijn en laadt die eerst. Als er geen onder deze drempel zijn, controleert het of er nog steeds onder 80% (bestaande conferentiedrempel) beschikbaar zijn.

Als de lading op Call Bridge cluster3 wordt gecontroleerd na de aanroepen van voorbeelden 1 en 2 (scenario 1), toont het een lading van 2000.

Stel dat de loadLimit voor dat Call Bridge-cluster3 is ingesteld op 2250 (alleen als voorbeeld), dan wordt deze Call Bridge boven de bestaande conferentiedrempel geplaatst, aangezien dat wordt berekend als 0,80 * 2250 = 1800

Er zijn in dit scenario nog twee gevallen die differentiatie behoeven.

Case 1: Meerdere servers in de groep nog steeds met een lading lager dan nieuwe vergaderdrempel (50%)

De andere twee servers in de groep hebben geen gesprekken nog behandeld zodat de lading nog op 0 is en zij konden allebei de vraag behandelen. De eindbeslissing wordt dus gemaakt op basis van de Call Bridge-voorkeur voor deze ruimte. Aangezien Call Bridge cluster3 al vol is, kiezen de systemen de laagste prioriteit uit cluster1 en cluster2, in dit geval 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)

Merk op dat het ladingsniveau: 2 op de cluster3 Call Bridge aangeeft dat het over de bestaande conferentiedrempel ging, dus ook al was de ruimte daar actief, de oproep is niet in balans met die server. In plaats daarvan kijkt het naar de laagste ruimteprioriteit van de andere Call Bridges met een belastingsniveau: 0 (wat lager dan 50% gebruik betekent), wat in dit geval cluster1 is.

Geval 2: slechts één server in een groep met een lading die lager is dan de nieuwe vergaderdrempel (50%) of de bestaande vergaderdrempel (80%)

Na de laatste oproep (en oproepen naar andere ruimte naar cluster2) werden de beschreven ladingen gezien op de Call Bridges:

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

Stel nu dat de loadLimit zoals ingesteld op cluster1 Call Bridge 1300 zou zijn, dan is deze Call Bridge over de nieuwe conferentiedrempel aangezien die wordt berekend als 0,50 * 1300 = 650 en over de bestaande conferentiedrempel van 0,80 * 1300 = 1040.

Mocht er een nieuwe Webex-oproep binnenkomen op Call Bridge cluster3 voor dezelfde ruimte, dan is de ruimte actief op zowel cluster1 als cluster3, maar beide zijn boven de bestaande conferentiedrempel en zoekt dus naar een andere server onder de nieuwe conferentiedrempel (50%) of bestaande conferentiedrempel (80%). In dit geval zou alleen cluster2 nog onder de bestaande conferentiedrempel liggen, maar het is al boven de nieuwe conferentiedrempel vanwege een andere oproep naar een andere ruimte die op cluster2 Call Bridge wordt afgehandeld.

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 is ingesteld met een loadLimit waarde van 600 hier. Met 400 als de huidige lading vóór de nieuwe vraag kwam in, het is over de nieuwe conferentiedrempel van 0.5 * 600 = 300 maar het is nog onder de bestaande conferentielimiet van 0.8 * 600 = 480. Dus dit verschijnt in de replace query als ladingsniveau: 1 (in plaats van 2 als de Call Bridge boven de 80%-drempel ligt).

Voorbeeld 3: Call Landing op Call Bridge over de bestaande vergaderdrempel

In dit geval vindt het algoritme voor taakverdeling niet plaats, omdat het beter zou zijn om een 488-respons terug te sturen naar het Call Control-apparaat dat vervolgens kan beslissen om te proberen de oproep te routeren naar een andere Call Bridge binnen de groep (die onder de 80%-limiet kan liggen) of om de oproep zelfs naar een andere Call Bridge-groep te routeren als de huidige groep niet over middelen beschikt (als een fallback-optie).

Het gebeurtenissenlogboek toont dit deel niet expliciet in veel detail omdat het alleen meldt dat het over de capaciteit ging:

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

Zodra de oproep is verzonden naar een andere Call Bridge die de lading kan verwerken (bijvoorbeeld cluster2), wordt hetzelfde taakverdelingsalgoritme weergegeven:

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)

Opmerking: in het geval van gateway-oproepen geeft CMS in plaats daarvan een 486 SIP-foutbericht terug. Standaard stopt CUCM de routing volgens de Service Parameter van Stop Routing op User Busy Flag zodat u deze instelling kunt wijzigen om fallback voor gatewayoproepen naar uw andere callbridges toe te staan.