Cisco Meeting Server 2.5.2. Cluster in schaalbare en veerkrachtige modus met videoconferentie-opnamefunctie

In dit nummer zal ik enkele fijne kneepjes van het opzetten van een CMS-server in failoverclustermodus laten zien en uitleggen.


ТеорияOver het algemeen zijn er drie soorten CMS-serverimplementaties:

• Enkel gecombineerd(Enkel gecombineerd), d.w.z. dit is één server waarop alle benodigde services draaien. In de meeste gevallen is dit type implementatie alleen geschikt voor interne clienttoegang en in kleinere omgevingen waar de schaalbaarheid en redundantiebeperkingen van een enkele server geen kritisch probleem zijn, of in situaties waarin het CMS alleen bepaalde functies uitvoert, zoals ad hoc conferenties over Cisco UCM.

  Geschat werkschema:
  

• Enkele splitsing(Single Split) breidt het vorige implementatietype uit door een aparte server toe te voegen voor externe toegang. Bij oudere implementaties betekende dit het inzetten van een CMS-server in een gedemilitariseerd netwerksegment (DMZ) waar externe clients toegang toe hadden, en één CMS-server in de netwerkkern waar interne clients toegang hadden tot het CMS. Dit specifieke implementatiemodel wordt nu vervangen door het zogenaamde type Enkele rand, dat uit servers bestaat Cisco-snelweg, die veel van dezelfde Firewall-bypass-mogelijkheden hebben of zullen hebben, zodat clients geen speciale Edge CMS-server hoeven toe te voegen.

  Geschat werkschema:
  

• Schaalbaar en veerkrachtig(Schaalbaar en fouttolerant) Dit type omvat redundantie voor elk onderdeel, waardoor het systeem met uw behoeften kan meegroeien tot de maximale capaciteit, terwijl er redundantie wordt geboden in geval van een storing. Het maakt ook gebruik van het Single Edge-concept om veilige externe toegang te bieden. Dit is het type waar we in deze aflevering naar zullen kijken. Als we begrijpen hoe we dit type cluster moeten inzetten, zullen we niet alleen andere soorten implementaties begrijpen, maar zullen we ook kunnen begrijpen hoe we clusters van CMS-servers kunnen creëren om tegemoet te komen aan de potentiële groei van de vraag.

Voordat u doorgaat met de implementatie, moet u enkele basiszaken begrijpen, namelijk

Belangrijkste CMS-softwarecomponenten:

• Database: Hiermee kunt u bepaalde configuraties combineren, zoals belplan, gebruikersruimten en gebruikers zelf. Ondersteunt alleen clustering voor hoge beschikbaarheid (single master).
• Belbrug: een dienst voor audio- en videoconferenties die volledige controle biedt over het beheer en de verwerking van oproepen en multimediaprocessen. Ondersteunt clustering voor hoge beschikbaarheid en schaalbaarheid.
• XMPP-server: verantwoordelijk voor registratie en authenticatie van klanten met behulp van de Cisco Meeting Application en/of WebRTC(real-time communicatie, of gewoon in de browser), evenals intercomponentsignalering. Kan alleen worden geclusterd voor hoge beschikbaarheid.
• Webbrug: Biedt clienttoegang tot WebRTC.
• Loadbalancer: Biedt één verbindingspunt voor Cisco Meeting Apps in Single Split-modus. Luistert naar de externe interface en poort voor inkomende verbindingen. Op dezelfde manier accepteert de load balancer inkomende TLS-verbindingen van de XMPP-server, waardoor hij TCP-verbindingen van externe clients kan schakelen.
  In ons scenario zal dit niet nodig zijn.
• TURN-server: Biedt firewall-bypasstechnologie die dit mogelijk maakt
  plaats ons CMS achter een firewall of NAT om externe clients te verbinden via Cisco Meeting App of SIP-apparaten. In ons scenario zal dit niet nodig zijn.
• Webbeheerder: Administratieve interface en API-toegang, ook voor speciale Unified CM-conferenties.

Configuratiemodi

In tegenstelling tot de meeste andere Cisco-producten ondersteunt Cisco Meeting Server drie configuratiemethoden voor elk type implementatie.

• Commandoregel (CLI): Commandoregelinterface bekend als MMP voor initiële configuratie- en certificaattaken.
• Webbeheerder: voornamelijk voor CallBridge-gerelateerde configuraties, vooral bij het opzetten van een enkele niet-geclusterde server.
• REST API: Gebruikt voor de meest complexe configuratietaken en geclusterde databasegerelateerde taken.

In aanvulling op het bovenstaande wordt het protocol gebruikt SFTP om bestanden (meestal licenties, certificaten of logbestanden) over te dragen van en naar de CMS-server.

In implementatiehandleidingen van Cisco staat in het wit en Engels geschreven dat het cluster moet worden geïmplementeerd minstens drie servers (knooppunten) in de context van databases. Omdat Alleen met een oneven aantal knooppunten zal het mechanisme voor het selecteren van een nieuwe Database Master werken, en over het algemeen heeft de Database Master een verbinding met het grootste deel van de CMS-serverdatabase.

En zoals de praktijk laat zien, zijn twee servers (knooppunten) echt niet genoeg. Het selectiemechanisme werkt wanneer de Master opnieuw wordt opgestart; de Slave-server wordt pas Master nadat de opnieuw opgestarte server is opgestart. Als in een cluster van twee servers echter de Master-server plotseling uitvalt, wordt de Slave-server niet de Master, en als de Slave uitvalt, wordt de resterende Master-server de Slave.

Maar in de context van XMPP zou het echt nodig zijn om een ​​cluster van drie servers samen te stellen, omdat als u bijvoorbeeld de XMPP-service uitschakelt op een van de servers waarop XMMP de status Leider heeft, dan zal XMPP op de resterende server de status Volger behouden en zullen de CallBridge-verbindingen met XMPP verbroken worden, omdat CallBridge maakt uitsluitend verbinding met XMPP met Leader-status. En dit is van cruciaal belang, omdat... geen enkel gesprek komt door.

Ook wordt in dezelfde implementatiehandleidingen een cluster met één XMPP-server gedemonstreerd.

En als we het bovenstaande in ogenschouw nemen, wordt het duidelijk waarom: het werkt omdat het zich in de failover-modus bevindt.

In ons geval zal de XMPP-server op alle drie de knooppunten aanwezig zijn.

Er wordt aangenomen dat alle drie onze servers actief zijn.

DNS-records

Voordat u begint met het instellen van servers, moet u DNS-records maken А и SRV soorten:

Houd er rekening mee dat er in onze DNS-records twee domeinen zijn: example.com en conf.voorbeeld.com. Voorbeeld.com is een domein dat alle Cisco Unified Communication Manager-abonnees kunnen gebruiken voor hun URI's, dat hoogstwaarschijnlijk aanwezig is in uw infrastructuur of waarschijnlijk aanwezig zal zijn. Of example.com komt overeen met hetzelfde domein dat gebruikers gebruiken voor hun e-mailadressen. Of de Jabber-client op uw laptop heeft mogelijk een URI [e-mail beveiligd]. Domein conf.example.com is het domein dat wordt geconfigureerd voor Cisco Meeting Server-gebruikers. Het domein van de Cisco Meeting Server zal zijn conf.example.com, dus voor dezelfde Jabber-gebruiker moet de URI gebruiker@ worden gebruikt om in te loggen op Cisco Meeting Serverconf.voorbeeld.com.

Basisconfiguratie

Alle hieronder beschreven instellingen worden op één server weergegeven, maar moeten op elke server in het cluster worden uitgevoerd.

QoS

Omdat het CMS genereert real-time verkeer dat gevoelig is voor vertragingen en pakketverlies, wordt in de meeste gevallen aanbevolen om Quality of Service (QoS) te configureren. Om dit te bereiken ondersteunt het CMS het taggen van pakketten met de Differentiated Services Codes (DSCP's) die het genereert. Hoewel DSCP-gebaseerde verkeersprioritering afhangt van hoe het verkeer wordt verwerkt door de netwerkcomponenten van uw infrastructuur, zullen we in ons geval ons CMS configureren met typische DSCP-prioritering op basis van QoS best practices.

Op elke server zullen we deze commando's invoeren

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Al het videoverkeer werd dus gemarkeerd met AF41 (DSCP 0x22), al het spraakverkeer werd gemarkeerd met EF (DSCP 0x2E), andere typen verkeer met lage latentie, zoals SIP en XMPP, gebruiken AF31 (DSCP 0x1A).

controleren:

NTP

Network Time Protocol (NTP) is niet alleen belangrijk voor het verstrekken van nauwkeurige tijdstempels van oproepen en conferenties, maar ook voor het verifiëren van certificaten.

Voeg NTP-servers toe aan uw infrastructuur met een opdracht als

ntp server add <server>

In ons geval zijn er twee van dergelijke servers, dus er zullen twee teams zijn.
controleren:

En stel de tijdzone voor onze server in

DNS

We voegen DNS-servers toe aan het CMS met een commando als:

dns add forwardzone <domain-name> <server ip>

In ons geval zijn er twee van dergelijke servers, dus er zullen twee teams zijn.
controleren:

Netwerkinterfaceconfiguratie

We configureren de interface met een commando als:

ipv4 <interface> add <address>/<prefix length> <gateway>

controleren:

Servernaam (hostnaam)

We stellen de servernaam in met een commando als:

hostname <name>

En we herstarten.


Hiermee is de basisconfiguratie voltooid.

Certificaten

ТеорияCisco Meeting Server vereist gecodeerde communicatie tussen verschillende componenten, en als gevolg daarvan zijn X.509-certificaten vereist voor alle CMS-implementaties. Ze helpen ervoor te zorgen dat de services/server wordt vertrouwd door andere servers/services.

Voor elke service is een certificaat vereist, maar het aanmaken van afzonderlijke certificaten voor elke service kan tot verwarring en onnodige complexiteit leiden. Gelukkig kunnen we het publiek-private sleutelpaar van een certificaat genereren en deze vervolgens voor meerdere services hergebruiken. In ons geval wordt hetzelfde certificaat gebruikt voor Call Bridge, XMPP Server, Web Bridge en Web Admin. U moet dus voor elke server in het cluster een paar openbare en privécertificaatsleutels maken.

Databaseclustering kent echter enkele speciale certificaatvereisten en vereist daarom eigen certificaten die verschillen van die van de andere diensten. CMS maakt gebruik van een servercertificaat, dat vergelijkbaar is met de certificaten die door andere servers worden gebruikt, maar er wordt ook een clientcertificaat gebruikt voor databaseverbindingen. Databasecertificaten worden gebruikt voor zowel authenticatie als encryptie. In plaats van een gebruikersnaam en wachtwoord op te geven waarmee de client verbinding kan maken met de database, presenteert het een clientcertificaat dat door de server wordt vertrouwd. Elke server in het databasecluster gebruikt hetzelfde publieke en private sleutelpaar. Hierdoor kunnen alle servers in het cluster gegevens zodanig versleutelen dat deze alleen kunnen worden ontsleuteld door andere servers die ook hetzelfde sleutelpaar delen.

Om redundantie te laten werken, moeten databaseclusters uit minimaal 3 servers bestaan, maar niet meer dan 5, met een maximale retourtijd van 200 ms tussen alle clusterleden. Deze limiet is restrictiever dan voor Call Bridge-clustering en is dus vaak de beperkende factor bij geografisch verspreide implementaties.

De databaserol voor een CMS kent een aantal unieke vereisten. In tegenstelling tot andere rollen vereist het een client- en servercertificaat, waarbij het clientcertificaat een specifiek CN-veld heeft dat aan de server wordt gepresenteerd.

Het CMS maakt gebruik van een postgres-database met één master en meerdere volledig identieke replica's. Er is slechts één primaire database tegelijk (de “databaseserver”). De overige leden van het cluster zijn replica's of "databaseclients".

Voor een databasecluster zijn een dedicated servercertificaat en een clientcertificaat vereist. Ze moeten worden ondertekend door certificaten, meestal een interne particuliere certificeringsinstantie. Omdat elk lid van het databasecluster de master kan worden, moeten de databaseserver- en clientcertificaatparen (die de publieke en private sleutels bevatten) naar alle servers worden gekopieerd, zodat ze de identiteit van de client of databaseserver kunnen aannemen. Bovendien moet het CA-rootcertificaat worden geladen om ervoor te zorgen dat de client- en servercertificaten kunnen worden geverifieerd.

We maken dus een verzoek aan voor een certificaat dat door alle serverdiensten behalve de database zal worden gebruikt (er zal hiervoor een afzonderlijk verzoek zijn) met een commando als:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

In CN schrijven we de algemene naam van onze servers. Bijvoorbeeld als de hostnamen van onze servers server01, server02, server03, dan zal CN dat zijn server.voorbeeld.com

We doen hetzelfde op de overige twee servers, met het verschil dat de opdrachten de overeenkomstige “hostnamen” zullen bevatten

We genereren twee aanvragen voor certificaten die door de databaseservice worden gebruikt met opdrachten als:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

waar dbclusterserver и dbclusterclient namen van onze verzoeken en toekomstige certificaten, hostnaam1(2)(3) namen van de overeenkomstige servers.

We voeren deze procedure slechts op één server (!) uit, en we zullen de certificaten en bijbehorende .key-bestanden naar andere servers uploaden.

Schakel de clientcertificaatmodus in AD CS in

U moet ook de certificaten voor elke server samenvoegen in één bestand.Op *NIX:

cat server01.cer server02.cer server03.cer > server.cer

Op Windows/DOS:

copy server01.cer + server02.cer + server03.cer  server.cer

En upload naar elke server:
1. “Individueel” servercertificaat.
2. Basiscertificaat (samen met eventuele tussenliggende certificaten).
3. Certificaten voor de database (“server” en “client”) en bestanden met de extensie .key, die zijn gegenereerd bij het aanmaken van een aanvraag voor de databasecertificaten “server” en “client”. Deze bestanden moeten op alle servers hetzelfde zijn.
4. Bestand van alle drie de “individuele” certificaten.

Als gevolg hiervan zou u op elke server zoiets als deze bestandsafbeelding moeten krijgen.

Databasecluster

Nu alle certificaten naar de CMS-servers zijn geüpload, kunt u databaseclustering tussen de drie knooppunten configureren en inschakelen. De eerste stap is het selecteren van één server als hoofdknooppunt van het databasecluster en deze volledig configureren.

Hoofddatabase

De eerste stap bij het instellen van databasereplicatie is het opgeven van de certificaten die voor de database worden gebruikt. Dit gebeurt met behulp van een commando als:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Laten we nu de CMS vertellen welke interface moet worden gebruikt voor databaseclustering met de opdracht:

database cluster localnode a

Vervolgens initialiseren we de clusterdatabase op de hoofdserver met het commando:

database cluster initialize

Clientdatabaseknooppunten

We doen dezelfde procedure, alleen in plaats van de opdracht databasecluster initialiseren voer een commando in zoals:

database cluster join <ip address existing master>

waar ip-adres het bestaande master-IP-adres van de CMS-server waarop het cluster is geïnitialiseerd, eenvoudigweg Master.

Hoe ons databasecluster op alle servers werkt, controleren we met het commando:

database cluster status

We doen hetzelfde op de resterende derde server.

Als resultaat blijkt dat onze eerste server de Master is, de rest zijn Slaven.

Webbeheerservice

Schakel de webbeheerdersservice in:

webadmin listen a 445

Er is gekozen voor poort 445 omdat poort 443 wordt gebruikt voor gebruikerstoegang tot de webclient

We configureren de Web Admin-service met certificaatbestanden met een commando als:

webadmin certs <keyfile> <certificatefile> <ca bundle>

En schakel Web Admin in met het commando:

webadmin enable

Als alles goed is, ontvangen we SUCCESS-regels die aangeven dat Web Admin correct is geconfigureerd voor het netwerk en het certificaat. We controleren de functionaliteit van de dienst met behulp van een webbrowser en voeren het adres van de webbeheerder in, bijvoorbeeld: cms.voorbeeld.com: 445

Oproepbrugcluster

Call Bridge is de enige service die in elke CMS-implementatie aanwezig is. Call Bridge is het belangrijkste conferentiemechanisme. Ook is er een SIP-interface aanwezig, zodat gesprekken er naartoe of vandaan kunnen worden gerouteerd door bijvoorbeeld een Cisco Unified CM.

De hieronder beschreven opdrachten moeten op elke server met de juiste certificaten worden uitgevoerd.
Dus:

We koppelen certificaten aan de Call Bridge-service met een commando als:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

We binden CallBridge-services aan de interface die we nodig hebben met de opdracht:

callbridge listen a

En start de service opnieuw met het commando:

callbridge restart

Nu we onze Call Bridges hebben geconfigureerd, kunnen we Call Bridge-clustering configureren. Call Bridge-clustering verschilt van database- of XMPP-clustering. Call Bridge Cluster kan zonder enige beperking 2 tot 8 knooppunten ondersteunen. Het biedt niet alleen redundantie, maar ook taakverdeling, zodat conferenties actief kunnen worden gedistribueerd over Call Bridge-servers met behulp van intelligente oproepverdeling. Het CMS beschikt over extra functies, Call Bridge-groepen en gerelateerde functies die kunnen worden gebruikt voor verder beheer.

Clustering van oproepbruggen wordt voornamelijk geconfigureerd via de webbeheerinterface
De hieronder beschreven procedure moet op elke server in het cluster worden uitgevoerd.
aldus

1. Ga via internet naar Configuratie > Cluster.
2. in Call Bridge-identiteit Voer als unieke naam callbridge[01,02,03] in, overeenkomend met de servernaam. Deze namen zijn willekeurig, maar moeten uniek zijn voor dit cluster. Ze zijn beschrijvend van aard omdat ze aangeven dat het server-ID's zijn [01,02,03].
3.B Geclusterde oproepbruggen voer de webbeheerder-URL's van onze servers in het cluster in, cms[01,02,03].example.com:445, in het adresveld. Zorg ervoor dat u de poort specificeert. U kunt het Peerlink SIP-domein leeg laten.
4. Voeg een certificaat toe aan de CallBridge-vertrouwensrelatie van elke server, waarvan het bestand alle certificaten van onze servers bevat, die we helemaal aan het begin in dit bestand hebben samengevoegd, met een commando als:

callbridge trust cluster <trusted cluster certificate bundle>

En start de service opnieuw met het commando:

callbridge restart

Als gevolg hiervan zou u op elke server deze afbeelding moeten krijgen:

XMPP-cluster

De XMPP-service in het CMS wordt gebruikt voor het afhandelen van alle registratie en authenticatie voor Cisco Meeting Apps (CMA), inclusief de CMA WebRTC-webclient. De Call Bridge zelf fungeert ook als XMPP-client voor authenticatiedoeleinden en moet daarom net als andere clients worden geconfigureerd. XMPP-fouttolerantie is een functie die sinds versie 2.1 in productieomgevingen wordt ondersteund

De hieronder beschreven opdrachten moeten op elke server met de juiste certificaten worden uitgevoerd.
Dus:

We koppelen certificaten aan de XMPP-service met een commando als:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Definieer vervolgens de luisterinterface met het commando:

xmpp listen a

Voor de XMPP-service is een uniek domein vereist. Dit is de login voor gebruikers. Met andere woorden: wanneer een gebruiker probeert in te loggen met de CMA-app (of via de WebRTC-client), voert hij userID@logindomain in. In ons geval zal dit userid@ zijnconf.voorbeeld.com. Waarom is het niet gewoon voorbeeld.com? In onze specifieke implementatie hebben we ons Unified CM-domein geselecteerd dat Jabber-gebruikers in Unified CM zullen gebruiken als example.com, dus hadden we een ander domein nodig voor CMS-gebruikers om oproepen van en naar het CMS te routeren via SIP-domeinen.

Stel een XMPP-domein in met behulp van een opdracht als:

xmpp domain <domain>

En schakel de XMPP-service in met de opdracht:

xmpp enable

In de XMPP-service moet u referenties aanmaken voor elke Call Bridge die zal worden gebruikt bij registratie bij de XMPP-service. Deze namen zijn willekeurig (en houden geen verband met de unieke namen die u hebt geconfigureerd voor clustering van oproepbruggen). U moet drie oproepbruggen toevoegen op één XMPP-server en deze referenties vervolgens invoeren op andere XMPP-servers in het cluster, omdat deze configuratie niet in de clusterdatabase past. Later zullen we elke Call Bridge configureren om deze naam en geheim te gebruiken om zich te registreren bij de XMPP-service.

Nu moeten we de XMPP-service op de eerste server configureren met drie Call Bridges callbridge01, callbridge02 en callbridge03. Aan elk account worden willekeurige wachtwoorden toegewezen. Ze worden later ingevoerd op andere Call Bridge-servers om in te loggen op deze XMPP-server. Voer de volgende opdrachten in:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

Als gevolg hiervan controleren we wat er is gebeurd met de opdracht:

xmpp callbridge list

Precies dezelfde afbeelding zou op de overige servers moeten verschijnen na de hieronder beschreven stappen.

Vervolgens voegen we exact dezelfde instellingen toe op de overige twee servers, alleen met de opdrachten

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Wij voegen Secret heel zorgvuldig toe, zodat er bijvoorbeeld geen extra spaties in zitten.


Als gevolg hiervan zou elke server dezelfde afbeelding moeten hebben:

Vervolgens specificeren we op alle servers in het cluster in vertrouwen het bestand dat alle drie de certificaten bevat, eerder gemaakt met een opdracht als deze:

xmpp cluster trust <trust bundle>

We schakelen de xmpp-clustermodus in op alle clusterservers met de opdracht:

xmpp cluster enable

Op de eerste server van het cluster starten we de creatie van een xmpp-cluster met de opdracht:

xmpp cluster initialize

Op andere servers voegt u een cluster toe aan xmpp met een opdracht als:

xmpp cluster join <ip address head xmpp server>

We controleren op elke server het succes van het maken van een XMPP-cluster op elke server met de opdrachten:

xmpp status
xmpp cluster status

Eerste server:

Tweede server:

Derde server:

Gespreksbrug verbinden met XMPP

Nu het XMPP-cluster actief is, moet u de Call Bridge-services configureren om verbinding te maken met het XMPP-cluster. Deze configuratie wordt uitgevoerd via de webbeheerder.

Ga op elke server naar Configuratie > Algemeen en in het veld Unieke Call Bridge-naam schrijf unieke namen die overeenkomen met de server Call Bridge belbrug[01,02,03]. оле Domein conf.voorbeeld.ru en bijbehorende wachtwoorden, kunt u ze bespioneren
op elke server in het cluster met de opdracht:

xmpp callbridge list

Laat het veld “Server” leeg Belbrug zal een DNS SRV-zoekopdracht uitvoeren voor _xmpp-component._tcp.conf.example.comom een ​​beschikbare XMPP-server te vinden. De IP-adressen voor het verbinden van callbridges met XMPP kunnen per server verschillen, het hangt af van welke waarden worden geretourneerd aan het recordverzoek _xmpp-component._tcp.conf.example.com callbridge, die op zijn beurt afhangt van de prioriteitsinstellingen voor een bepaald DNS-record.

Ga vervolgens naar Status > Algemeen om te verifiëren of de Call Bride-service succesvol is verbonden met de XMPP-service.

Webbrug

Schakel op elke server in het cluster de Web Bridge-service in met de opdracht:

webbridge listen a:443

We configureren de Web Bridge-service met certificaatbestanden met een commando als:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Webbridge ondersteunt HTTPS. Het zal HTTP omleiden naar HTTPS als het geconfigureerd is om "http-redirect" te gebruiken.
Om HTTP-omleiding in te schakelen, gebruikt u de volgende opdracht:

webbridge http-redirect enable

Om Call Bridge te laten weten dat Web Bridge verbindingen van Call Bridge kan vertrouwen, gebruikt u de opdracht:

webbridge trust <certfile>

waarbij dit een bestand is dat alle drie de certificaten van elke server in het cluster bevat.

Deze afbeelding zou op elke server in het cluster moeten staan.


Nu moeten we een gebruiker aanmaken met de rol “appadmin”, we hebben deze nodig zodat we ons cluster(!) kunnen configureren, en niet elke server in het cluster afzonderlijk. Op deze manier worden de instellingen gelijkelijk op elke server toegepast, ondanks de feit dat ze ooit gemaakt zullen worden.


Voor verdere instellingen zullen we gebruiken Postbode.

Voor autorisatie selecteert u Basis in het gedeelte Autorisatie

Om opdrachten correct naar de CMS-server te verzenden, moet u de vereiste codering instellen

We specificeren Webbridge met het commando POST met parameters url en betekenis cms.voorbeeld.com



In de webbridge zelf geven we de benodigde parameters aan: gasttoegang, beveiligde toegang, etc.

Bruggroepen bellen

Standaard maakt het CMS niet altijd het meest efficiënte gebruik van de beschikbare vergadermiddelen.

Bij een vergadering met drie deelnemers kan elke deelnemer bijvoorbeeld op drie verschillende Belbruggen terechtkomen. Om deze drie deelnemers met elkaar te laten communiceren, zal Call Bridges automatisch verbindingen tot stand brengen tussen alle servers en clients in dezelfde Space, zodat het lijkt alsof alle clients zich op dezelfde server bevinden. Helaas is het nadeel hiervan dat een enkele conferentie voor drie personen nu negen mediapoorten verbruikt. Dit is duidelijk een inefficiënt gebruik van hulpbronnen. Wanneer een Call Bridge echt overbelast is, is het standaardmechanisme bovendien het blijven accepteren van oproepen en het bieden van een verminderde kwaliteit van de dienstverlening aan alle abonnees van die Call Bridge.

Deze problemen worden opgelost met behulp van de functie Call Bridge Group. Deze functie is geïntroduceerd in versie 2.1 van Cisco Meeting Server-software en is uitgebreid ter ondersteuning van taakverdeling voor zowel inkomende als uitgaande Cisco Meeting App (CMA)-gesprekken, inclusief WebRTC-deelnemers.

Om het herverbindingsprobleem op te lossen, zijn er voor elke Call Bridge drie configureerbare belastingslimieten geïntroduceerd:

Laadlimiet — dit is de maximale numerieke belasting voor een bepaalde oproepbrug. Elk platform heeft een aanbevolen belastingslimiet, zoals 96000 voor de CMS1000 en 1.25 GHz per vCPU voor de virtuele machine. Verschillende oproepen verbruiken een bepaalde hoeveelheid bronnen, afhankelijk van de resolutie en framesnelheid van de deelnemer.
NieuweConferenceLoadLimitBasisPoints (standaard 50% loadLimit) - stelt de serverbelastingslimiet in, waarna nieuwe conferenties worden afgewezen.
BestaandeConferenceLoadLimitBasisPoints (standaard 80% van loadLimit) - de serverbelastingswaarde waarna deelnemers aan een bestaande conferentie worden afgewezen.

Hoewel deze functie is ontworpen voor oproepverdeling en taakverdeling, kunnen ook andere groepen zoals TURN-servers, Webbridge-servers en recorders worden toegewezen aan Call Bridge-groepen, zodat deze ook op de juiste manier kunnen worden gegroepeerd voor optimaal gebruik. Als een van deze objecten niet aan een oproepgroep is toegewezen, wordt aangenomen dat deze zonder enige prioriteit beschikbaar zijn voor alle servers.

Deze parameters worden hier geconfigureerd: cms.voorbeeld.com:445/api/v1/system/configuration/cluster

Vervolgens geven we aan elke callbridge aan tot welke callbridge-groep deze behoort:

Eerste belbrug

Tweede belbrug

Derde belbrug


Daarom hebben we de Call Brdige-groep geconfigureerd om efficiënter gebruik te maken van de bronnen van het Cisco Meeting Server-cluster.

Gebruikers importeren uit Active Directory

De Web Admin-service heeft een LDAP-configuratiegedeelte, maar biedt geen complexe configuratie-opties, en de informatie wordt niet opgeslagen in de clusterdatabase, dus de configuratie zal moeten worden uitgevoerd, hetzij handmatig op elke server via de webinterface, hetzij via de API, en zodat we “drie keer “niet opstaan” zullen we de gegevens alsnog via de API instellen.

URL gebruiken om toegang te krijgen cms01.voorbeeld.com:445/api/v1/ldapServers maakt een LDAP Server-object, waarbij parameters worden opgegeven zoals:

• Server IP
• poortnummer
• gebruikersnaam
• wachtwoord
• beveiligen

Veilig - selecteer waar of onwaar, afhankelijk van de poort, 389 - niet beveiligd, 636 - beschermd.


LDAP-bronparameters toewijzen aan kenmerken in Cisco Meeting Server.
De LDAP-toewijzing wijst de kenmerken in de LDAP-directory toe aan de kenmerken in de CMS. De werkelijke kenmerken:

• jidMapping
• naamMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Beschrijving van attributenIADB vertegenwoordigt de login-ID van de gebruiker in het CMS. Omdat dit een Microsoft Active Directory LDAP-server is, wordt de CMS JID toegewezen aan de sAMAccountName in LDAP, wat in wezen de Active Directory-aanmeldings-ID van de gebruiker is. Houd er ook rekening mee dat u sAMAccountName gebruikt en het domein conf.pod6.cms.lab aan het einde ervan toevoegt, omdat dit de login is die uw gebruikers zullen gebruiken om in te loggen op het CMS.

naamMapping komt overeen met wat er in het Active Directory displayName-veld staat met het CMS-naamveld van de gebruiker.

coSpaceNameMapping maakt een CMS-ruimtenaam op basis van het displayName-veld. Dit attribuut, samen met het coSpaceUriMapping attribuut, is wat nodig is om voor elke gebruiker een ruimte te creëren.

coSpaceUriMapping definieert het gebruikersgedeelte van de URI die is gekoppeld aan de persoonlijke ruimte van de gebruiker. Sommige domeinen kunnen worden geconfigureerd om naar de ruimte te worden gebeld. Als het gebruikersgedeelte overeenkomt met dit veld voor een van deze domeinen, wordt de oproep doorgestuurd naar de ruimte van die gebruiker.

coSpaceSecondaryUriMapping definieert een tweede URI om de ruimte te bereiken. Dit kan worden gebruikt om een ​​numerieke alias toe te voegen voor het routeren van oproepen naar de geïmporteerde gebruikersruimte als alternatief voor de alfanumerieke URI die is gedefinieerd in de parameter coSpaceUriMapping.

De LDAP-server en LDAP-toewijzing zijn geconfigureerd. Nu moet u ze aan elkaar koppelen door een LDAP-bron te maken.

URL gebruiken om toegang te krijgen cms01.voorbeeld.com:445/api/v1/ldapSource maak een LDAP-bronobject, waarbij u parameters opgeeft zoals:

• server
• in kaart brengen
• basisDn
• filter

Nu de LDAP-configuratie voltooid is, kunt u de handmatige synchronisatiebewerking uitvoeren.

We doen dit ofwel in de webinterface van elke server door te klikken Synchroniseer nu sectie Active Directory


of via de API met het commando POST URL gebruiken om toegang te krijgen cms01.voorbeeld.com:445/api/v1/ldapSyncs

Ad-hocconferenties

Wat is dit?In het traditionele concept is er sprake van een conferentie wanneer twee deelnemers met elkaar praten, en een van de deelnemers (met behulp van een apparaat dat is geregistreerd bij Unified CM) op de knop "Conferentie" drukt, de andere persoon belt en na met die derde partij te hebben gesproken , drukt u nogmaals op de knop "Conferentie" om alle deelnemers aan de tripartiete conferentie bij te wonen.

Wat een ad-hocconferentie onderscheidt van een geplande conferentie in een CMS, is dat een ad-hocconferentie niet zomaar een SIP-oproep naar een CMS is. Wanneer de initiatiefnemer van de conferentie een tweede keer op de knop Conferentie klikt om iedereen uit te nodigen voor dezelfde vergadering, moet Unified CM een API-aanroep naar het CMS doen om een ​​directe conferentie te creëren waarnaar alle oproepen vervolgens worden doorverbonden. Dit alles gebeurt ongemerkt door de deelnemers.

Dit betekent dat Unified CM de API-referenties en het WebAdmin-adres/-poort van de service, evenals de SIP Trunk, rechtstreeks naar de CMS-server moet configureren om het gesprek voort te zetten.

Indien nodig kan CUCM dynamisch een spatie in het CMS creëren, zodat elke oproep het CMS kan bereiken en kan voldoen aan de inkomende oproepregel die bedoeld is voor spaties.

Integratie met CUCM op dezelfde manier geconfigureerd als beschreven in het artikel vroeger behalve dat u op Cisco UCM drie trunks voor de CMS en drie Conference Bridges moet maken, in het SIP-beveiligingsprofiel drie onderwerpnamen, routegroepen, routelijsten, mediabrongroepen en mediabrongroeplijsten moet opgeven en een paar routeringsregels moet toevoegen naar Cisco Meeting Server.

SIP-beveiligingsprofiel:


Trunks:


Elke kofferbak ziet er hetzelfde uit:




Conferentiebrug


Elke Conference Bridge ziet er hetzelfde uit:


Routegroep


Routelijst


Mediabrongroep


Lijst met mediabrongroepen

Oproepregels

In tegenstelling tot meer geavanceerde oproepbeheersystemen zoals Unified CM of Expressway, zoekt CMS alleen het domein op in het SIP Request-URI-veld voor nieuwe oproepen. Dus als SIP INVITE voor een slokje is: [e-mail beveiligd]Het CMS geeft alleen om domein.com. CMS volgt deze regels om te bepalen waar een oproep naartoe moet worden gerouteerd:

1. De CMS probeert eerst het SIP-domein te matchen met de domeinen die zijn geconfigureerd in de regels voor inkomende oproepen. Deze oproepen kunnen vervolgens worden gerouteerd naar (“gerichte”) ruimtes of specifieke gebruikers, interne IVR’s of direct geïntegreerde Microsoft Lync/Skype for Business (S4B)-bestemmingen.
2. Als de regels voor inkomende gesprekken niet overeenkomen, probeert CMS het domein te matchen dat is geconfigureerd in de tabel voor het doorschakelen van gesprekken. Als er een match is, kan de regel de oproep expliciet weigeren of doorsturen. Op dit moment kan het CMS het domein herschrijven, wat soms handig is voor het aanroepen van Lync-domeinen. U kunt er ook voor kiezen om 'pass throw' te gebruiken, waardoor geen van de velden verder wordt aangepast, of om een ​​intern CMS-kiesplan te gebruiken. Als de regels voor het doorsturen van oproepen niet overeenkomen, wordt de oproep standaard afgewezen. Houd er rekening mee dat de media in het CMS, hoewel de oproep wordt "doorgestuurd", nog steeds gebonden zijn aan de CMS, wat betekent dat deze zich in het signaal- en mediaverkeerspad bevinden.
Dan vallen alleen doorgeschakelde oproepen onder de uitgaande oproepregels. Deze instellingen bepalen de bestemmingen waarnaar oproepen worden verzonden, het trunktype (of het nu een nieuwe Lync-oproep of een standaard SIP-oproep is) en eventuele conversies die kunnen worden uitgevoerd als doorverbinden niet is geselecteerd in de doorschakelregel.

Hier is het feitelijke logboek van wat er gebeurt tijdens een ad-hocconferentie

De schermafbeelding laat het slecht zien (ik weet niet hoe ik het beter kan maken), dus ik zal het log als volgt schrijven:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

De Ad-Hoc-conferentie zelf:


Regels voor inkomende oproepen
Het configureren van de parameters van inkomende oproepen is noodzakelijk om een ​​oproep in het CMS te kunnen ontvangen. Zoals u bij de LDAP-installatie zag, werden alle gebruikers geïmporteerd met het domein conf.pod6.cms.lab. U wilt dus op zijn minst dat oproepen naar dit domein gericht zijn op ruimtes. U zult ook regels moeten opstellen voor alles wat bedoeld is voor de volledig gekwalificeerde domeinnaam (en misschien zelfs het IP-adres) van elk van de CMS-servers. Onze externe oproepcontrole, Unified CM, configureert SIP-trunks die specifiek zijn bedoeld voor elk van de CMS-servers afzonderlijk. Afhankelijk van het feit of de bestemming van deze SIP-trunks een IP-adres is of de FQDN van de server, zal bepalen of het CMS moet worden geconfigureerd om oproepen te accepteren die naar het IP-adres of de FQDN zijn gericht.

Het domein met de binnenkomende regel met de hoogste prioriteit wordt gebruikt als domein voor alle gebruikersruimten. Wanneer gebruikers via LDAP synchroniseren, maakt het CMS automatisch spaties aan, maar alleen het gebruikersgedeelte van de URI (coSpaceUriMapping), bijvoorbeeld user.space. Deel domein Op basis van deze regel wordt de volledige URI gegenereerd. Als u zich nu bij Web Bridge zou aanmelden, zou u zien dat de Space-URI geen domein heeft. Door deze regel als de hoogste prioriteit in te stellen, stelt u het domein in voor de gegenereerde ruimtes conf.voorbeeld.com.


Regels voor uitgaande gesprekken

Om gebruikers toe te staan ​​uitgaande gesprekken te voeren naar het Unified CM-cluster, moet u uitgaande regels configureren. Het domein van eindpunten die zijn geregistreerd bij Unified CM, zoals Jabber, is example.com. Oproepen naar dit domein moeten als standaard SIP-oproepen worden gerouteerd naar Unified CM-oproepverwerkingsknooppunten. De hoofdserver is cucm-01.example.com en de extra server is cucm-02.example.com.

De eerste regel beschrijft de eenvoudigste routering van oproepen tussen clusterservers.

Veld Lokaal vanaf domein is verantwoordelijk voor wat er wordt weergegeven in de SIP-URI van de beller voor de persoon die wordt gebeld na het “@”-symbool. Als we het leeg laten, staat na het “@”-symbool het IP-adres van de CUCM waar deze oproep doorheen gaat. Als we een domein opgeven, staat er na het “@”-symbool daadwerkelijk een domein. Dit is nodig om terug te kunnen bellen, anders is het niet mogelijk om terug te bellen via SIP-URI naam@ip-adres.

Bel wanneer aangegeven Lokaal vanaf domein


Bel wanneer NIET aangeduid Lokaal vanaf domein


Zorg ervoor dat u expliciet Versleuteld of Niet-versleuteld opgeeft voor uitgaande oproepen, omdat niets werkt met de parameter Auto.

Opnemen

Videoconferenties worden opgenomen door de Record-server. Recorder is precies hetzelfde als Cisco Meeting Server. Recorder vereist geen installatie van licenties. Opnamelicenties zijn vereist voor servers waarop CallBridge-services draaien, d.w.z. Er is een opnamelicentie vereist die moet worden toegepast op de CallBridge-component, en niet op de server waarop Recorder draait. Recorder gedraagt ​​zich als een XMPP-client (Extensible Messaging and Presence Protocol), dus de XMPP-server moet zijn ingeschakeld op de server die CallBridge host.

Omdat We hebben een cluster en de licentie moet worden “uitgerekt” over alle drie de servers in het cluster. Vervolgens koppelen (toevoegen) wij eenvoudigweg in uw persoonlijke account in de licenties de MAC-adressen van de a-interfaces van alle CMS-servers die in het cluster zijn opgenomen.

En dit is de afbeelding die op elke server in het cluster zou moeten staan

Over het algemeen zijn er verschillende scenario’s voor het plaatsen van Recorder, maar wij houden ons hieraan:


Voordat u Recorder instelt, moet u een plaats voorbereiden waar de videoconferenties daadwerkelijk worden opgenomen. Eigenlijk hier link, hoe u alle opnames instelt. Ik concentreer me op belangrijke punten en details:

1. Het is beter om het certificaat van de eerste server in het cluster te verwijderen.
2. De fout 'Recorder niet beschikbaar' kan optreden omdat het verkeerde certificaat is opgegeven in de Recorder Trust.
3. Schrijven werkt mogelijk niet als de voor opname opgegeven NFS-map niet de hoofdmap is.

Soms is het nodig om automatisch een conferentie van één specifieke gebruiker of ruimte op te nemen.

Hiervoor worden twee CallProfiles aangemaakt:
Met opname uitgeschakeld


En met automatische opnamefunctie


Vervolgens “koppelen” wij een BelProfiel met automatische opnamefunctie aan de gewenste ruimte.


In CMS is het zo vastgelegd dat als een CallProfile expliciet aan een ruimte of ruimte is gekoppeld, dit CallProfile alleen werkt in relatie tot deze specifieke ruimtes. En als het CallProfile niet aan een spatie is gebonden, wordt het standaard toegepast op die ruimtes waaraan geen CallProfile expliciet is gebonden.

De volgende keer zal ik proberen te beschrijven hoe het CMS wordt benaderd buiten het interne netwerk van de organisatie.

Bronnen:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

Bron: www.habr.com