I dette nummer vil jeg vise og forklare nogle af forviklingerne ved at opsætte en CMS-server i failover-klyngetilstand.
ТеорияGenerelt er der tre typer CMS-serverimplementering:
- Enkelt kombineret(Enkelt kombineret), dvs. dette er en server, hvor alle de nødvendige tjenester kører. I de fleste tilfælde er denne type implementering kun egnet til intern klientadgang og i mindre miljøer, hvor skalerbarheden og redundansbegrænsningerne for en enkelt server ikke er et kritisk problem, eller i situationer, hvor CMS'et kun udfører visse funktioner, såsom ad hoc konferencer om Cisco UCM.
Omtrentlig arbejdsplan:
- Enkelt Split(Single Split) udvider den tidligere implementeringstype ved at tilføje en separat server til ekstern adgang. I legacy-implementeringer betød dette implementering af en CMS-server i et demilitariseret netværkssegment (DMZ), hvor eksterne klienter kunne få adgang til det, og en CMS-server i netværkskernen, hvor interne klienter kunne få adgang til CMS'et. Denne særlige implementeringsmodel er nu ved at blive afløst af den såkaldte type Enkelt kant, som består af servere Cisco Expressway, som enten har eller vil have mange af de samme Firewall-bypass-funktioner, så klienter ikke behøver at tilføje en dedikeret Edge CMS-server.
Omtrentlig arbejdsplan:
- Skalerbar og modstandsdygtig(Skalerbar og fejltolerant) Denne type inkluderer redundans for hver komponent, hvilket gør det muligt for systemet at vokse med dine behov til dets maksimale kapacitet og samtidig give redundans i tilfælde af fejl. Den bruger også Single Edge-konceptet til at give sikker ekstern adgang. Det er den type, vi vil se på i denne episode. Hvis vi forstår, hvordan man implementerer denne type klynge, vil vi ikke kun forstå andre typer implementeringer, men vi vil også være i stand til at forstå, hvordan man opretter klynger af CMS-servere for at imødekomme potentiel vækst i efterspørgslen.
Før du går videre til implementering, skal du forstå nogle grundlæggende ting, nemlig
Vigtigste CMS-softwarekomponenter:
- Database: Giver dig mulighed for at kombinere nogle konfigurationer, såsom opkaldsplan, brugerrum og brugerne selv. Understøtter kun clustering for høj tilgængelighed (single master).
- Ring til Bridge: en tjeneste til lyd- og videokonferencer, der giver fuld kontrol over styring og behandling af opkald og multimedieprocesser. Understøtter clustering for høj tilgængelighed og skalerbarhed.
- XMPP-server: ansvarlig for registrering og autentificering af klienter ved hjælp af Cisco Meeting Application og/eller WebRTC(kommunikation i realtid eller blot i browseren), samt interkomponent signalering. Kan kun grupperes for høj tilgængelighed.
- Web Bridge: Giver klientadgang til WebRTC.
- Loadbalancer: Giver et enkelt forbindelsespunkt til Cisco Meeting Apps i Single Split-tilstand. Lytter til den eksterne grænseflade og port for indgående forbindelser. På samme måde accepterer belastningsbalanceren indgående TLS-forbindelser fra XMPP-serveren, hvorigennem den kan skifte TCP-forbindelser fra eksterne klienter.
I vores scenarie vil det ikke være nødvendigt. - TURN server: Giver Firewall-bypass-teknologi, der tillader
placere vores CMS bag en firewall eller NAT for at forbinde eksterne klienter ved hjælp af Cisco Meeting App eller SIP-enheder. I vores scenarie vil det ikke være nødvendigt. - Webadministrator: Administrativ grænseflade og API-adgang, herunder til særlige Unified CM-konferencer.
Konfigurationstilstande
I modsætning til de fleste andre Cisco-produkter understøtter Cisco Meeting Server tre konfigurationsmetoder for at imødekomme enhver form for implementering.
- Kommandolinje (CLI): Kommandolinjegrænseflade kendt som MMP til indledende konfiguration og certifikatopgaver.
- Web administrator: Primært til CallBridge-relaterede konfigurationer, især ved opsætning af en enkelt ikke-klynget server.
- REST-API: Bruges til de mest komplekse konfigurationsopgaver og klyngede databaserelaterede opgaver.
Ud over ovenstående anvendes protokollen SFTP til at overføre filer – normalt licenser, certifikater eller logfiler – til og fra CMS-serveren.
I implementeringsvejledninger fra Cisco står der på hvidt og engelsk, at klyngen skal implementeres mindst tre servere (knudepunkter) i forbindelse med databaser. Fordi Kun med et ulige antal noder vil mekanismen til at vælge en ny Database Master fungere, og generelt har Database Master en forbindelse til det meste af CMS serverdatabasen.
Og som praksis viser, er to servere (noder) virkelig ikke helt nok. Udvælgelsesmekanismen fungerer, når Master genstartes, Slave-serveren bliver først Master efter den genstartede server er hentet frem. Men hvis Master-serveren pludselig går ud i en klynge af to servere, bliver Slave-serveren ikke Master, og hvis Slaven går ud, vil den resterende Master-server blive Slave.
Men i forbindelse med XMPP ville det virkelig være nødvendigt at samle en klynge af tre servere, fordi hvis du f.eks. deaktiverer XMPP-tjenesten på en af de servere, hvor XMMP er i Leader-status, så forbliver XMPP på den resterende server i Follower-status, og CallBridge-forbindelser til XMPP vil falde af, fordi CallBridge opretter udelukkende forbindelse til XMPP med Leader-status. Og det er kritisk, fordi... ikke et eneste opkald går igennem.
Også i de samme implementeringsvejledninger demonstreres en klynge med én XMPP-server.
Og under hensyntagen til ovenstående bliver det klart hvorfor: det virker, fordi det er i failover-tilstand.
I vores tilfælde vil XMPP-serveren være til stede på alle tre noder.
Det antages, at alle tre af vores servere er oppe.
DNS optegnelser
Før du begynder at konfigurere servere, skal du oprette DNS-poster А и SRV typer:
Bemærk venligst, at der i vores DNS-registreringer er to domæner example.com og conf.example.com. Eksempel.com er et domæne, som alle Cisco Unified Communication Manager-abonnenter kan bruge til deres URI'er, som højst sandsynligt er til stede i din infrastruktur eller sandsynligvis vil være til stede. Eller example.com matcher det samme domæne, som brugerne bruger til deres e-mailadresser. Eller Jabber-klienten på din bærbare computer kan have en URI [e-mail beskyttet]. Domæne conf.example.com er det domæne, der vil blive konfigureret til Cisco Meeting Server-brugere. Domænet for Cisco Meeting Server vil være conf.example.com, så for den samme Jabber-bruger skal bruger@-URI'en bruges til at logge på Cisco Meeting Serverconf.example.com.
Grundlæggende konfiguration
Alle indstillinger beskrevet nedenfor vises på én server, men de skal udføres på hver server i klyngen.
QoS
Siden CMS genererer realtid trafik følsom over for forsinkelser og pakketab, i de fleste tilfælde anbefales det at konfigurere servicekvalitet (QoS). For at opnå dette understøtter CMS'et tagging af pakker med de Differentiated Services Codes (DSCP'er), det genererer. Selvom DSCP-baseret trafikprioritering afhænger af, hvordan trafikken behandles af netværkskomponenterne i din infrastruktur, vil vi i vores tilfælde konfigurere vores CMS med typisk DSCP-prioritering baseret på QoS best practices.
På hver server vil vi indtaste disse kommandoer
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ASåledes blev al videotrafik markeret AF41 (DSCP 0x22), al stemmetrafik blev markeret EF (DSCP 0x2E), andre typer lav latency trafik såsom SIP og XMPP bruger AF31 (DSCP 0x1A).
Vi tjekker:
NTP
Network Time Protocol (NTP) er vigtig ikke kun for at give nøjagtige tidsstempler for opkald og konferencer, men også for at verificere certifikater.
Tilføj NTP-servere til din infrastruktur med en kommando som f.eks
ntp server add <server>
I vores tilfælde er der to sådanne servere, så der vil være to hold.
Vi tjekker:
Og indstil tidszonen for vores server
DNS
Vi tilføjer DNS-servere til CMS'et med en kommando som:
dns add forwardzone <domain-name> <server ip>
I vores tilfælde er der to sådanne servere, så der vil være to hold.
Vi tjekker:
Konfiguration af netværksgrænseflade
Vi konfigurerer grænsefladen med en kommando som:
ipv4 <interface> add <address>/<prefix length> <gateway>
Vi tjekker:
Servernavn (værtsnavn)
Vi indstiller servernavnet med en kommando som:
hostname <name>
Og vi genstarter.
Dette fuldender den grundlæggende konfiguration.
Certificeringer
ТеорияCisco Meeting Server kræver krypteret kommunikation mellem forskellige komponenter, og som følge heraf kræves X.509-certifikater til alle CMS-implementeringer. De er med til at sikre, at tjenesterne/serveren har tillid til andre servere/tjenester.
Hver tjeneste kræver et certifikat, men oprettelse af separate certifikater for hver tjeneste kan føre til forvirring og unødvendig kompleksitet. Heldigvis kan vi generere et certifikats offentlig-private nøglepar og derefter genbruge dem på tværs af flere tjenester. I vores tilfælde vil det samme certifikat blive brugt til Call Bridge, XMPP Server, Web Bridge og Web Admin. Du skal således oprette et par offentlige og private certifikatnøgler for hver server i klyngen.
Database clustering har dog nogle særlige certifikatkrav og kræver derfor sine egne certifikater, der er forskellige fra de andre tjenesters. CMS bruger et servercertifikat, som ligner de certifikater, der bruges af andre servere, men der er også et klientcertifikat, der bruges til databaseforbindelser. Databasecertifikater bruges til både autentificering og kryptering. I stedet for at give klienten et brugernavn og en adgangskode til at oprette forbindelse til databasen, præsenterer den et klientcertifikat, som serveren har tillid til. Hver server i databaseklyngen vil bruge det samme offentlige og private nøglepar. Dette giver alle servere i klyngen mulighed for at kryptere data på en sådan måde, at de kun kan dekrypteres af andre servere, der også deler det samme nøglepar.
For at redundans skal fungere, skal databaseklynger bestå af minimum 3 servere, men ikke mere end 5, med en maksimal rundturstid på 200 ms mellem alle klyngemedlemmer. Denne grænse er mere restriktiv end for Call Bridge-klynger, så den er ofte den begrænsende faktor i geografisk distribuerede implementeringer.
Databaserollen for et CMS har en række unikke krav. I modsætning til andre roller kræver det et klient- og servercertifikat, hvor klientcertifikatet har et specifikt CN-felt, der præsenteres for serveren.
CMS'et bruger en postgres-database med en master og flere fuldstændig identiske replikaer. Der er kun én primær database ad gangen ("databaseserveren"). De resterende medlemmer af klyngen er replikaer eller "databaseklienter".
En databaseklynge kræver et dedikeret servercertifikat og et klientcertifikat. De skal være underskrevet af certifikater, normalt en intern privat certifikatmyndighed. Fordi ethvert medlem af databaseklyngen kan blive master, skal databaseserveren og klientcertifikatparrene (som indeholder de offentlige og private nøgler) kopieres til alle servere, så de kan antage identiteten af klienten eller databaseserveren. Derudover skal CA-rodcertifikatet indlæses for at sikre, at klient- og servercertifikaterne kan verificeres.
Så vi opretter en anmodning om et certifikat, der vil blive brugt af alle servertjenester undtagen databasen (der vil være en separat anmodning om dette) med en kommando som:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
I CN skriver vi det generelle navn på vores servere. For eksempel hvis værtsnavnene på vores servere server01, server02, server03, så vil CN være server.example.com
Vi gør det samme på de resterende to servere med den forskel, at kommandoerne vil indeholde de tilsvarende "værtsnavne"
Vi genererer to anmodninger om certifikater, der vil blive brugt af databasetjenesten med kommandoer som:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresгде dbclusterserver и dbclusterklient navne på vores anmodninger og fremtidige certifikater, værtsnavn1(2)(3) navnene på de tilsvarende servere.
Vi udfører kun denne procedure på én server (!), og vi uploader certifikaterne og de tilsvarende .key-filer til andre servere.
Aktiver klientcertifikattilstand i AD CS
Du skal også flette certifikaterne for hver server til én fil.På *NIX:
cat server01.cer server02.cer server03.cer > server.cerPå Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Og upload til hver server:
1. "Individuelt" servercertifikat.
2. Rodcertifikat (sammen med eventuelle mellemliggende).
3. Certifikater til databasen ("server" og "klient") og filer med filtypenavnet .key, som blev genereret ved oprettelse af en anmodning om "server" og "klient" databasecertifikater. Disse filer skal være ens på alle servere.
4. Fil over alle tre "individuelle" certifikater.
Som et resultat bør du få noget som dette filbillede på hver server.
Databaseklynge
Nu hvor du har alle certifikaterne uploadet til CMS-serverne, kan du konfigurere og aktivere databaseklynger mellem de tre noder. Det første trin er at vælge en server som masterknudepunktet for databaseklyngen og konfigurere den fuldstændigt.
Master Database
Det første trin i opsætning af databasereplikering er at angive de certifikater, der skal bruges til databasen. Dette gøres ved hjælp af en kommando som:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Lad os nu fortælle CMS'et, hvilken grænseflade der skal bruges til databaseklyngning med kommandoen:
database cluster localnode aDerefter initialiserer vi klyngedatabasen på hovedserveren med kommandoen:
database cluster initialize
Klientdatabasenoder
Vi gør den samme procedure, kun i stedet for kommandoen initialisering af databaseklynge indtast en kommando som:
database cluster join <ip address existing master>hvor ip-adresse eksisterende master-ip-adresse på CMS-serveren, som klyngen blev initialiseret på, blot Master.
Vi tjekker, hvordan vores databaseklynge fungerer på alle servere med kommandoen:
database cluster status
Vi gør det samme på den resterende tredje server.
Som et resultat viser det sig, at vores første server er Mesteren, resten er slaver.
Web Admin Service
Aktiver webadministratortjenesten:
webadmin listen a 445Port 445 blev valgt, fordi port 443 bruges til brugeradgang til webklienten
Vi konfigurerer Web Admin-tjenesten med certifikatfiler med en kommando som:
webadmin certs <keyfile> <certificatefile> <ca bundle>Og aktiver Web Admin med kommandoen:
webadmin enable
Hvis alt er godt, vil vi modtage SUCCES-linjer, der indikerer, at Web Admin er korrekt konfigureret til netværket og certifikatet. Vi kontrollerer tjenestens funktionalitet ved hjælp af en webbrowser og indtaster webadministratorens adresse, for eksempel: : 445
Ring til Bridge Cluster
Call Bridge er den eneste service, der findes i enhver CMS-implementering. Call Bridge er den vigtigste konferencemekanisme. Det giver også et SIP-interface, så opkald kan dirigeres til eller fra det af for eksempel en Cisco Unified CM.
Kommandoerne beskrevet nedenfor skal udføres på hver server med de relevante certifikater.
So:
Vi forbinder certifikater med Call Bridge-tjenesten med en kommando som:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Vi binder CallBridge-tjenester til den grænseflade, vi har brug for, med kommandoen:
callbridge listen aOg genstart tjenesten med kommandoen:
callbridge restart
Nu hvor vi har konfigureret vores opkaldsbroer, kan vi konfigurere opkaldsbroklynger. Call Bridge-klynger er forskellig fra database- eller XMPP-klynger. Call Bridge Cluster kan understøtte fra 2 til 8 noder uden nogen begrænsninger. Det giver ikke kun redundans, men også belastningsbalancering, så konferencer aktivt kan distribueres på tværs af Call Bridge-servere ved hjælp af intelligent opkaldsdistribution. CMS'et har yderligere funktioner, Call Bridge-grupper og relaterede funktioner, som kan bruges til yderligere administration.
Opkaldsbroklynger konfigureres primært via webadministrationsgrænsefladen
Proceduren beskrevet nedenfor skal udføres på hver server i klyngen.
således
1. Gå gennem internettet til Konfiguration > Klynge.
2. In Call Bridge-identitet Indtast callbridge[01,02,03] som et unikt navn, der svarer til servernavnet. Disse navne er vilkårlige, men skal være unikke for denne klynge. De er beskrivende, fordi de angiver, at de er server-id'er [01,02,03].
3.B Klyngede kaldebroer indtast webadministratorens webadresser på vores servere i klyngen, [01,02,03].example.com:445 i feltet Adresse. Sørg for at angive porten. Du kan lade Peer-link SIP-domænet være tomt.
4. Tilføj et certifikat til CallBridge-trusten for hver server, hvis fil indeholder alle certifikaterne fra vores servere, som vi flettede ind i denne fil helt i begyndelsen med en kommando som:
callbridge trust cluster <trusted cluster certificate bundle>Og genstart tjenesten med kommandoen:
callbridge restart
Som et resultat bør du på hver server få dette billede:
XMPP-klynge
XMPP-tjenesten i CMS'et bruges til at håndtere al registrering og autentificering for Cisco Meeting Apps (CMA), inklusive CMA WebRTC-webklienten. Selve Call Bridge fungerer også som en XMPP-klient til godkendelsesformål og skal derfor konfigureres som andre klienter. XMPP-fejltolerance er en funktion, der er blevet understøttet i produktionsmiljøer siden version 2.1
Kommandoerne beskrevet nedenfor skal udføres på hver server med de relevante certifikater.
So:
Vi forbinder certifikater med XMPP-tjenesten med en kommando som:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Definer derefter lyttegrænsefladen med kommandoen:
xmpp listen aXMPP-tjenesten kræver et unikt domæne. Dette er login for brugere. Med andre ord, når en bruger forsøger at logge ind ved hjælp af CMA-appen (eller gennem WebRTC-klienten), indtaster de bruger-ID@logindomæne. I vores tilfælde vil det være brugerid@conf.example.com. Hvorfor er det ikke bare example.com? I vores særlige implementering valgte vi vores Unified CM-domæne, som Jabber-brugere vil bruge i Unified CM som example.com, så vi havde brug for et andet domæne til CMS-brugere til at dirigere opkald til og fra CMS'et gennem SIP-domæner.
Konfigurer et XMPP-domæne ved hjælp af en kommando som:
xmpp domain <domain>Og aktiver XMPP-tjenesten med kommandoen:
xmpp enableI XMPP-tjenesten skal du oprette legitimationsoplysninger for hver Call Bridge, der vil blive brugt, når du registrerer dig med XMPP-tjenesten. Disse navne er vilkårlige (og er ikke relateret til de unikke navne, du har konfigureret til opkaldsbroklyngning). Du skal tilføje tre opkaldsbroer på én XMPP-server og derefter indtaste disse legitimationsoplysninger på andre XMPP-servere i klyngen, fordi denne konfiguration ikke passer ind i klyngedatabasen. Senere vil vi konfigurere hver opkaldsbro til at bruge dette navn og denne hemmelighed til at registrere med XMPP-tjenesten.
Nu skal vi konfigurere XMPP-tjenesten på den første server med tre Call Bridges callbridge01, callbridge02 og callbridge03. Hver konto vil blive tildelt tilfældige adgangskoder. De vil senere blive indtastet på andre Call Bridge-servere for at logge på denne XMPP-server. Indtast følgende kommandoer:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Som et resultat kontrollerer vi, hvad der skete med kommandoen:
xmpp callbridge list
Præcis det samme billede skulle vises på de resterende servere efter trinene beskrevet nedenfor.
Dernæst tilføjer vi nøjagtig de samme indstillinger på de resterende to servere, kun med kommandoerne
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Vi tilføjer Secret meget omhyggeligt, så der for eksempel ikke er ekstra mellemrum i den.
Som et resultat bør hver server have det samme billede:
Dernæst på alle servere i klyngen specificerer vi i tillid filen, der indeholder alle tre certifikater, oprettet tidligere med en kommando som denne:
xmpp cluster trust <trust bundle>Vi aktiverer xmpp klyngetilstand på alle klyngeservere med kommandoen:
xmpp cluster enablePå klyngens første server starter vi oprettelsen af en xmpp-klynge med kommandoen:
xmpp cluster initializePå andre servere skal du tilføje en klynge til xmpp med en kommando som:
xmpp cluster join <ip address head xmpp server>Vi kontrollerer på hver server succesen med at oprette en XMPP-klynge på hver server med kommandoerne:
xmpp status
xmpp cluster statusFørste server:
Anden server:
Tredje server:
Tilslutning af Call Bridge til XMPP
Nu hvor XMPP-klyngen kører, skal du konfigurere Call Bridge-tjenesterne til at oprette forbindelse til XMPP-klyngen. Denne konfiguration udføres via webadministratoren.
På hver server skal du gå til Konfiguration > Generelt og i feltet Unikt Call Bridge-navn skriv unikke navne svarende til serverens Call Bridge callbridge[01,02,03]... I marken Domæne conf.example.ru og tilsvarende adgangskoder, du kan spionere på dem
på enhver server i klyngen med kommandoen:
xmpp callbridge list
Lad feltet "Server" være tomt Callbridge vil udføre et DNS SRV-opslag for _xmpp-component._tcp.conf.example.comfor at finde en tilgængelig XMPP-server. IP-adresserne til at forbinde callbridges til XMPP kan variere på hver server, det afhænger af hvilke værdier der returneres til registreringsanmodningen _xmpp-component._tcp.conf.example.com callbridge, hvilket igen afhænger af prioritetsindstillingerne for en given DNS-post.
Gå derefter til Status > Generelt for at bekræfte, om Call Bride-tjenesten er forbundet med XMPP-tjenesten.
Web Bridge
På hver server i klyngen skal du aktivere Web Bridge-tjenesten med kommandoen:
webbridge listen a:443Vi konfigurerer Web Bridge-tjenesten med certifikatfiler med en kommando som:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge understøtter HTTPS. Den vil omdirigere HTTP til HTTPS, hvis den er konfigureret til at bruge "http-redirect".
For at aktivere HTTP-omdirigering skal du bruge følgende kommando:
webbridge http-redirect enableFor at lade Call Bridge vide, at Web Bridge kan stole på forbindelser fra Call Bridge, skal du bruge kommandoen:
webbridge trust <certfile>hvor dette er en fil, der indeholder alle tre certifikater fra hver server i klyngen.
Dette billede bør være på hver server i klyngen.
Nu skal vi oprette en bruger med rollen "appadmin", vi har brug for den, så vi kan konfigurere vores klynge(!), og ikke hver server i klyngen separat, på denne måde vil indstillingerne blive anvendt ligeligt på hver server på trods af faktum, at de vil blive lavet én gang.
For yderligere opsætning vil vi bruge .
For godkendelse skal du vælge Grundlæggende i sektionen Autorisation
For at sende kommandoer korrekt til CMS-serveren skal du indstille den nødvendige kodning
Vi angiver Webbridge med kommandoen POST med parameter url og mening
I selve webbridgen angiver vi de nødvendige parametre: gæsteadgang, beskyttet adgang osv.
Ring til brogrupper
Som standard gør CMS'et ikke altid den mest effektive brug af de tilgængelige konferenceressourcer.
For eksempel, for et møde med tre deltagere, kan hver deltager ende på tre forskellige Call Bridges. For at disse tre deltagere kan kommunikere med hinanden, vil Call Bridges automatisk etablere forbindelser mellem alle servere og klienter i samme Space, så det hele ser ud som om alle klienter er på samme server. Desværre er ulempen ved dette, at en enkelt 3-personers konference nu vil forbruge 9 medieporte. Dette er naturligvis en ineffektiv brug af ressourcer. Derudover, når en opkaldsbro virkelig er overbelastet, er standardmekanismen at fortsætte med at acceptere opkald og levere reduceret kvalitetsservice til alle abonnenter på den opkaldsbro.
Disse problemer løses ved hjælp af Call Bridge Group-funktionen. Denne funktion blev introduceret i version 2.1 af Cisco Meeting Server-softwaren og er blevet udvidet til at understøtte belastningsbalancering for både indgående og udgående Cisco Meeting App-opkald (CMA), inklusive WebRTC-deltagere.
For at løse genforbindelsesproblemet er der indført tre konfigurerbare belastningsgrænser for hver opkaldsbro:
LoadLimit — dette er den maksimale numeriske belastning for en bestemt opkaldsbro. Hver platform har en anbefalet belastningsgrænse, såsom 96000 for CMS1000 og 1.25 GHz pr. vCPU for den virtuelle maskine. Forskellige opkald bruger en vis mængde ressourcer afhængigt af deltagerens opløsning og billedhastighed.
NewConferenceLoadLimitBasisPoints (standard 50% loadLimit) - indstiller serverbelastningsgrænsen, hvorefter nye konferencer afvises.
Eksisterende KonferenceLoadLimitBasisPoints (standard 80% af loadLimit) - serverbelastningsværdien, hvorefter deltagere, der deltager i en eksisterende konference, vil blive afvist.
Selvom denne funktion er designet til opkaldsfordeling og belastningsbalancering, kan andre grupper såsom TURN-servere, webbroservere og optagere også tildeles til opkaldsbrogrupper, så de også kan grupperes korrekt til optimal brug. Hvis nogle af disse objekter ikke er tildelt en opkaldsgruppe, antages de at være tilgængelige for alle servere uden nogen særlig prioritet.
Disse parametre konfigureres her: :445/api/v1/system/configuration/cluster
Dernæst angiver vi for hver callbridge, hvilken callbridge-gruppe den tilhører:
Første callbridge
Anden callbridge
Tredje callbridge
Således konfigurerede vi Call Brdige-gruppen til mere effektivt at bruge ressourcerne i Cisco Meeting Server-klyngen.
Import af brugere fra Active Directory
Web Admin-tjenesten har en LDAP-konfigurationssektion, men den giver ikke komplekse konfigurationsmuligheder, og oplysningerne gemmes ikke i klyngedatabasen, så konfigurationen skal foretages, enten manuelt på hver server via webgrænsefladen eller via API'en, og så vi "tre gange "Stå ikke op", vil vi stadig indstille dataene via API'en.
Bruger URL til at få adgang :445/api/v1/ldapServers opretter et LDAP-serverobjekt, der specificerer parametre som:
- Server IP
- portnummer
- brugernavn
- adgangskode
- sikker
Sikker - vælg sand eller falsk afhængig af porten, 389 - ikke sikker, 636 - beskyttet.
Tilknytning af LDAP-kildeparametre til attributter i Cisco Meeting Server.
LDAP-tilknytningen kortlægger attributterne i LDAP-biblioteket til attributterne i CMS'et. De faktiske egenskaber:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskrivelse af attributterJID repræsenterer brugerens login-id i CMS'et. Da dette er en Microsoft Active Directory LDAP-server, knyttes CMS JID til sAMAccountName i LDAP, som i det væsentlige er brugerens Active Directory-login-id. Bemærk også, at du tager sAMAccountName og tilføjer domænet conf.pod6.cms.lab til slutningen af det, fordi dette er det login, dine brugere vil bruge til at logge ind på CMS.
nameMapping matcher det, der er indeholdt i Active Directory displayName-feltet, med brugerens CMS-navnfelt.
coSpaceNameMapping opretter et CMS-rumnavn baseret på feltet displayName. Denne attribut er sammen med coSpaceUriMapping-attributten, hvad der kræves for at skabe et space for hver bruger.
coSpaceUriMapping definerer brugerdelen af URI'en, der er knyttet til brugerens personlige rum. Nogle domæner kan konfigureres til at blive ringet op i rummet. Hvis brugerdelen matcher dette felt for et af disse domæner, vil opkaldet blive dirigeret til den pågældende brugers område.
coSpaceSecondaryUriMapping definerer en anden URI for at nå rummet. Dette kan bruges til at tilføje et numerisk alias til at dirigere opkald til den importerede brugers plads som et alternativ til den alfanumeriske URI, der er defineret i parameteren coSpaceUriMapping.
LDAP-serveren og LDAP-tilknytningen er konfigureret. Nu skal du linke dem sammen ved at oprette en LDAP-kilde.
Bruger URL til at få adgang :445/api/v1/ldapSource opret et LDAP-kildeobjekt, der specificerer parametre som:
- server
- kortlægning
- baseDn
- filtrere
Nu hvor LDAP-konfigurationen er færdig, kan du udføre den manuelle synkronisering.
Vi gør dette enten i webgrænsefladen på hver server ved at klikke Synkroniser nu sektion Active Directory
eller via API'et med kommandoen POST bruge URL for at få adgang :445/api/v1/ldapSyncs
Ad hoc konferencer
Hvad er det?I det traditionelle koncept er en konference, når to deltagere taler med hinanden, og en af deltagerne (ved hjælp af en enhed, der er registreret med Unified CM) trykker på knappen "Konference", ringer til den anden person, og efter at have talt med denne tredjepart , trykker på knappen "Konference" igen for at deltage i alle deltagere i trepartskonferencen.
Det, der adskiller en Ad-Hoc-konference fra en planlagt konference i et CMS, er, at en Ad-Hoc-konference ikke kun er et SIP-opkald til CMS'et. Når initiativtageren til konferencen klikker på knappen Konference endnu en gang for at invitere alle til det samme møde, skal Unified CM foretage et API-kald til CMS'et for at oprette en on-the-fly-konference, hvortil alle opkald derefter overføres. Alt dette sker ubemærket af deltagerne.
Det betyder, at Unified CM skal konfigurere API-legitimationsoplysningerne og WebAdmin-adressen/porten for tjenesten samt SIP-trunken direkte til CMS-serveren for at fortsætte opkaldet.
Om nødvendigt kan CUCM dynamisk oprette et mellemrum i CMS'et, så hvert opkald kan nå CMS'et og matche den indgående opkaldsregel, der er beregnet til mellemrum.
Integration med CUCM konfigureret på samme måde som beskrevet i artiklen bortset fra, at på Cisco UCM skal du oprette tre trunks til CMS'et, tre konferencebroer, i SIP-sikkerhedsprofilen angive tre emnenavne, rutegrupper, rutelister, medieressourcegrupper og medieressourcegruppelister og tilføje et par routingregler til Cisco Meeting Server.
SIP sikkerhedsprofil:
Trunks:
Hver stamme ser ens ud:
Konferencebroen
Hver konferencebro ser ens ud:
Rutegruppe
Ruteliste
Medieressourcegruppe
Medieressourcegruppeliste
Opkaldsregler
I modsætning til mere avancerede opkaldsstyringssystemer såsom Unified CM eller Expressway, slår CMS kun domænet op i feltet SIP Request-URI for nye opkald. Så hvis SIP INVITE er til en slurk: [e-mail beskyttet]CMS'et bekymrer sig kun om domain.com. CMS følger disse regler for at bestemme, hvor et opkald skal dirigeres:
1. CMS'et forsøger først at matche SIP-domænet med domænerne, der er konfigureret i reglerne for indgående opkald. Disse opkald kan derefter dirigeres til ("målrettede") rum eller specifikke brugere, interne IVR'er eller direkte integrerede Microsoft Lync/Skype for Business-destinationer (S4B).
2. Hvis der ikke er overensstemmelse i reglerne for indgående opkald, vil CMS forsøge at matche domænet, der er konfigureret i viderestillingstabellen. Hvis der opnås et match, kan reglen eksplicit afvise opkaldet eller viderestille opkaldet. På nuværende tidspunkt kan CMS'et omskrive domænet, hvilket nogle gange er nyttigt til at kalde Lync-domæner. Du kan også vælge at bestå kast, hvilket betyder, at ingen af felterne vil blive ændret yderligere, eller bruge en intern CMS-opkaldsplan. Hvis der ikke er overensstemmelse i reglerne for viderestilling af opkald, er standarden at afvise opkaldet. Husk på, at selvom opkaldet er "viderestillet", er mediet stadig bundet til CMS'et, hvilket betyder, at det vil være i signal- og medietrafikstien.
Så er det kun viderestillede opkald, der er underlagt reglerne for udgående opkald. Disse indstillinger bestemmer de destinationer, som opkald sendes til, trunktypen (uanset om det er et nyt Lync-opkald eller et standard SIP-opkald) og eventuelle konverteringer, der kan udføres, hvis omstilling ikke er valgt i reglen for viderestilling af opkald.
Her er den faktiske log over, hvad der sker under en ad-hoc-konference
Skærmbilledet viser det dårligt (jeg ved ikke, hvordan man gør det bedre), så jeg vil skrive loggen sådan her:
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:12Selve ad hoc-konferencen:
Regler for indgående opkald
Konfiguration af parametrene for indgående opkald er nødvendig for at kunne modtage et opkald i CMS. Som du så i LDAP-opsætningen, blev alle brugere importeret med domænet conf.pod6.cms.lab. Så du vil som minimum have opkald til dette domæne for at målrette mellemrum. Du skal også opsætte regler for alt, hvad der er beregnet til det fuldt kvalificerede domænenavn (og måske endda IP-adressen) på hver af CMS-serverne. Vores eksterne opkaldskontrol, Unified CM, vil konfigurere SIP-trunks dedikeret til hver af CMS-serverne individuelt. Afhængigt af om destinationen for disse SIP-trunks er en IP-adresse eller serverens FQDN vil bestemme, om CMS'et skal konfigureres til at acceptere opkald dirigeret til dens IP-adresse eller FQDN.
Det domæne, der har den højeste prioritet for indgående regel, bruges som domæne for eventuelle brugerrum. Når brugere synkroniserer via LDAP, opretter CMS'et automatisk mellemrum, men kun brugerdelen af URI'en (coSpaceUriMapping), for eksempel user.space. En del Den fulde URI genereres baseret på denne regel. Faktisk, hvis du skulle logge på Web Bridge på dette tidspunkt, ville du se, at Space URI'en ikke har et domæne. Ved at indstille denne regel som højeste prioritet, indstiller du domænet for de genererede mellemrum konf.eksempel.com.
Regler for udgående opkald
For at tillade brugere at foretage udgående opkald til Unified CM-klyngen, skal du konfigurere udgående regler. Domænet for endepunkter, der er registreret hos Unified CM, såsom Jabber, er example.com. Opkald til dette domæne skal dirigeres som standard SIP-opkald til Unified CM-opkaldsbehandlingsknuder. Hovedserveren er cucm-01.example.com, og den ekstra server er cucm-02.example.com.
Den første regel beskriver den enkleste routing af opkald mellem klyngeservere.
Field Lokal fra domæne er ansvarlig for, hvad der vil blive vist i den opkaldendes SIP-URI for den person, der bliver ringet op efter "@"-symbolet. Hvis vi lader det stå tomt, vil der efter "@"-symbolet være CUCM's IP-adresse, som dette opkald går igennem. Hvis vi angiver et domæne, vil der efter "@"-symbolet faktisk være et domæne. Dette er nødvendigt for at kunne ringe tilbage, ellers vil det ikke være muligt at ringe tilbage via SIP-URI navn@ip-adresse.
Ring, når det er angivet Lokal fra domæne
Ring hvornår IKKE angivet Lokal fra domæne
Sørg for eksplicit at angive Krypteret eller Ukrypteret for udgående opkald, for intet virker med Auto-parameteren.
Indspilning
Videokonferencer optages af optageserveren. Optager er nøjagtig det samme som Cisco Meeting Server. Optageren kræver ikke installation af nogen licenser. Der kræves optagelseslicenser for servere, der kører CallBridge-tjenester, dvs. en optagelseslicens er påkrævet og skal anvendes på CallBridge-komponenten og ikke på serveren, der kører Recorder. Optageren opfører sig som en XMPP-klient (Extensible Messaging and Presence Protocol), så XMPP-serveren skal være aktiveret på serveren, der hoster CallBridge.
Fordi Vi har en klynge, og licensen skal "strækkes" på tværs af alle tre servere i klyngen. Derefter skal du blot indsætte din personlige konto i de licenser, vi tilknytter (tilføje) MAC-adresserne på a-grænsefladerne på alle CMS-servere, der er inkluderet i klyngen.
Og dette er billedet, der burde være på hver server i klyngen
Generelt er der flere scenarier for at placere Recorder, men vi vil holde os til dette:
Før du opsætter Recorder, skal du forberede et sted, hvor videokonferencerne rent faktisk vil blive optaget. Faktisk her , hvordan man opsætter al optagelse. Jeg fokuserer på vigtige punkter og detaljer:
1. Det er bedre at smide certifikatet fra den første server i klyngen.
2. Fejlen "Recorder unavailable" kan forekomme, fordi det forkerte certifikat er angivet i Recorder Trust.
3. Skrivning fungerer muligvis ikke, hvis NFS-biblioteket, der er angivet til optagelse, ikke er rodmappen.
Nogle gange er der behov for automatisk at optage en konference for en bestemt bruger eller et specifikt område.
Til dette oprettes to CallProfiler:
Med optagelse deaktiveret
Og med automatisk optagefunktion
Dernæst "vedhæfter" vi en CallProfile med en automatisk optagefunktion til den nødvendige plads.
I CMS er det så etableret, at hvis en CallProfil eksplicit er knyttet til ethvert rum eller rum, så virker denne CallProfil kun i forhold til disse specifikke rum. Og hvis CallProfile ikke er bundet til noget space, så anvendes den som standard på de spaces, som ingen CallProfil eksplicit er bundet til.
Næste gang vil jeg prøve at beskrive, hvordan CMS'et tilgås uden for organisationens interne netværk.
Kilder:
Kilde: www.habr.com