I denne utgaven vil jeg vise og forklare noen av vanskelighetene ved å sette opp en CMS-server i failover-klyngemodus.
ТеорияGenerelt er det tre typer CMS-serverdistribusjon:
- Enkel kombinert(Single kombinert), dvs. dette er en server der alle nødvendige tjenester kjører. I de fleste tilfeller er denne typen distribusjon kun egnet for intern klienttilgang og i mindre miljøer der skalerbarheten og redundansbegrensningene til en enkelt server ikke er et kritisk problem, eller i situasjoner der CMS bare utfører visse funksjoner, for eksempel ad hoc konferanser om Cisco UCM.
Omtrentlig arbeidsplan:
- Enkel splitt(Single Split) utvider den forrige distribusjonstypen ved å legge til en separat server for ekstern tilgang. I eldre distribusjoner betydde dette å distribuere en CMS-server i et demilitarisert nettverkssegment (DMZ) hvor eksterne klienter kunne få tilgang til den, og en CMS-server i nettverkskjernen hvor interne klienter kunne få tilgang til CMS. Denne spesielle distribusjonsmodellen blir nå erstattet av den såkalte typen Enkelt kant, som består av servere Cisco Expressway, som enten har eller vil ha mange av de samme brannmur-omgå-funksjonene slik at klienter ikke trenger å legge til en dedikert edge CMS-server.
Omtrentlig arbeidsplan:
- Skalerbar og spenstig(Skalerbar og feiltolerant) Denne typen inkluderer redundans for hver komponent, slik at systemet kan vokse med dine behov til maksimal kapasitet samtidig som det gir redundans i tilfelle feil. Den bruker også Single Edge-konseptet for å gi sikker ekstern tilgang. Dette er typen vi skal se på i denne episoden. Hvis vi forstår hvordan vi distribuerer denne typen klynge, vil vi ikke bare forstå andre typer distribusjoner, men vi vil også kunne forstå hvordan vi lager klynger av CMS-servere for å imøtekomme potensiell vekst i etterspørselen.
Før du går videre til distribusjon, må du forstå noen grunnleggende ting, nemlig
Hoved CMS-programvarekomponenter:
- Database: Lar deg kombinere noen konfigurasjoner, for eksempel nummerplan, brukerområder og brukerne selv. Støtter kun gruppering for høy tilgjengelighet (single master).
- Ring Bridge: en tjeneste for lyd- og videokonferanser som gir full kontroll over styring og behandling av samtaler og multimedieprosesser. Støtter clustering for høy tilgjengelighet og skalerbarhet.
- XMPP-server: ansvarlig for registrering og autentisering av klienter som bruker Cisco Meeting Application og/eller WebRTC(sanntidskommunikasjon, eller ganske enkelt i nettleseren), samt interkomponentsignalering. Kan kun grupperes for høy tilgjengelighet.
- Web Bridge: Gir klienttilgang til WebRTC.
- Lastbalanser: Gir ett enkelt tilkoblingspunkt for Cisco Meeting Apps i Single Split-modus. Lytter til det eksterne grensesnittet og porten for innkommende tilkoblinger. På samme måte godtar lastbalanseren innkommende TLS-tilkoblinger fra XMPP-serveren, som den kan bytte TCP-tilkoblinger fra eksterne klienter gjennom.
I vårt scenario vil det ikke være nødvendig. - TURN server: Gir brannmur-bypass-teknologi som tillater
Plasser CMS-systemet vårt bak en brannmur eller NAT for å koble til eksterne klienter ved hjelp av Cisco Meeting App eller SIP-enheter. I vårt scenario vil det ikke være nødvendig. - Nettadmin: Administrativt grensesnitt og API-tilgang, inkludert for spesielle Unified CM-konferanser.
Konfigurasjonsmoduser
I motsetning til de fleste andre Cisco-produkter, støtter Cisco Meeting Server tre konfigurasjonsmetoder for å imøtekomme alle typer distribusjon.
- Kommandolinje (CLI): Kommandolinjegrensesnitt kjent som MMP for innledende konfigurasjon og sertifikatoppgaver.
- Nettadministrator: Primært for CallBridge-relaterte konfigurasjoner, spesielt når du setter opp en enkelt ikke-klynget server.
- REST API: Brukes til de mest komplekse konfigurasjonsoppgavene og grupperte databaserelaterte oppgaver.
I tillegg til ovennevnte brukes protokollen SFTP for å overføre filer – vanligvis lisenser, sertifikater eller logger – til og fra CMS-serveren.
I distribusjonsguider fra Cisco står det skrevet på hvitt og engelsk at klyngen må distribueres minst tre servere (noder) i sammenheng med databaser. Fordi Bare med et oddetall noder vil mekanismen for å velge en ny Database Master fungere, og generelt har Database Master en forbindelse med det meste av CMS serverdatabasen.
Og som praksis viser, er to servere (noder) egentlig ikke helt nok. Valgmekanismen fungerer når masteren startes på nytt, slaveserveren blir master først etter at den omstartede serveren er hentet frem. Imidlertid, hvis Master-serveren plutselig går ut i en klynge med to servere, vil ikke Slave-serveren bli Master, og hvis Slaven går ut, vil den gjenværende Master-serveren bli Slave.
Men i forbindelse med XMPP ville det virkelig være nødvendig å sette sammen en klynge med tre servere, fordi hvis du for eksempel deaktiverer XMPP-tjenesten på en av serverne der XMMP er i Leader-status, vil XMPP på den gjenværende serveren forbli i Follower-status og CallBridge-tilkoblinger til XMPP vil falle av, fordi CallBridge kobles eksklusivt til XMPP med lederstatus. Og dette er kritisk, fordi... ikke en eneste samtale går gjennom.
Også i de samme distribusjonsguidene vises en klynge med én XMPP-server.
Og tatt i betraktning det ovennevnte, blir det klart hvorfor: det fungerer fordi det er i failover-modus.
I vårt tilfelle vil XMPP-serveren være til stede på alle tre nodene.
Det antas at alle tre serverne våre er oppe.
DNS-poster
Før du begynner å sette opp servere, må du opprette DNS-poster А и SRV typer:
Vær oppmerksom på at i våre DNS-poster er det to domener example.com og conf.example.com. Eksempel.com er et domene som alle Cisco Unified Communication Manager-abonnenter kan bruke for sine URIer, som mest sannsynlig er tilstede i infrastrukturen din eller sannsynligvis vil være tilstede. Eller example.com samsvarer med det samme domenet som brukere bruker for e-postadressene sine. Eller Jabber-klienten på den bærbare datamaskinen kan ha en URI [e-postbeskyttet]. Domene conf.example.com er domenet som skal konfigureres for Cisco Meeting Server-brukere. Domenet til Cisco Meeting Server vil være conf.example.com, så for den samme Jabber-brukeren må user@-URI-en brukes for å logge på Cisco Meeting Serverconf.example.com.
Grunnleggende konfigurasjon
Alle innstillingene beskrevet nedenfor vises på én server, men de må gjøres på hver server i klyngen.
QoS
Siden CMS genererer sanntids trafikk følsom for forsinkelser og pakketap, i de fleste tilfeller anbefales det å konfigurere tjenestekvalitet (QoS). For å oppnå dette støtter CMS tagging av pakker med Differentiated Services Codes (DSCPs) den genererer. Selv om DSCP-basert trafikkprioritering avhenger av hvordan trafikken behandles av nettverkskomponentene i infrastrukturen din, vil vi i vårt tilfelle konfigurere vårt CMS med typisk DSCP-prioritering basert på QoS beste praksis.
På hver server vil vi legge inn disse kommandoene
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ADermed ble all videotrafikk merket AF41 (DSCP 0x22), all taletrafikk ble merket EF (DSCP 0x2E), andre typer trafikk med lav latens som SIP og XMPP bruker AF31 (DSCP 0x1A).
Vi sjekker:
NTP
Network Time Protocol (NTP) er viktig ikke bare for å gi nøyaktige tidsstempler for samtaler og konferanser, men også for å bekrefte sertifikater.
Legg til NTP-servere til infrastrukturen din med en kommando som
ntp server add <server>
I vårt tilfelle er det to slike servere, så det blir to lag.
Vi sjekker:
Og angi tidssonen for serveren vår
DNS
Vi legger til DNS-servere til CMS med en kommando som:
dns add forwardzone <domain-name> <server ip>
I vårt tilfelle er det to slike servere, så det blir to lag.
Vi sjekker:
Konfigurasjon av nettverksgrensesnitt
Vi konfigurerer grensesnittet med en kommando som:
ipv4 <interface> add <address>/<prefix length> <gateway>
Vi sjekker:
Servernavn (vertsnavn)
Vi setter servernavnet med en kommando som:
hostname <name>
Og vi starter på nytt.
Dette fullfører den grunnleggende konfigurasjonen.
Sertifikater
ТеорияCisco Meeting Server krever kryptert kommunikasjon mellom ulike komponenter, og som et resultat kreves X.509-sertifikater for alle CMS-distribusjoner. De bidrar til å sikre at tjenestene/serveren er klarert av andre servere/tjenester.
Hver tjeneste krever et sertifikat, men å opprette separate sertifikater for hver tjeneste kan føre til forvirring og unødvendig kompleksitet. Heldigvis kan vi generere et sertifikats offentlig-private nøkkelpar og deretter gjenbruke dem på tvers av flere tjenester. I vårt tilfelle vil det samme sertifikatet bli brukt for Call Bridge, XMPP Server, Web Bridge og Web Admin. Dermed må du opprette et par offentlige og private sertifikatnøkler for hver server i klyngen.
Databaseclustering har imidlertid noen spesielle sertifikatkrav og krever derfor egne sertifikater som er forskjellige fra de andre tjenestene. CMS bruker et serversertifikat, som ligner på sertifikatene som brukes av andre servere, men det finnes også et klientsertifikat som brukes for databasetilkoblinger. Databasesertifikater brukes til både autentisering og kryptering. I stedet for å oppgi et brukernavn og passord for klienten for å koble til databasen, presenterer den et klientsertifikat som er klarert av serveren. Hver server i databaseklyngen vil bruke det samme offentlige og private nøkkelparet. Dette gjør at alle servere i klyngen kan kryptere data på en slik måte at de kun kan dekrypteres av andre servere som også deler samme nøkkelpar.
For at redundans skal fungere, må databaseklynger bestå av minimum 3 servere, men ikke mer enn 5, med en maksimal tur-retur-tid på 200 ms mellom alle klyngemedlemmer. Denne grensen er mer restriktiv enn for Call Bridge-klynger, så den er ofte den begrensende faktoren i geografisk distribuerte distribusjoner.
Databaserollen for et CMS har en rekke unike krav. I motsetning til andre roller, krever det et klient- og serversertifikat, hvor klientsertifikatet har et spesifikt CN-felt som presenteres for serveren.
CMS-en bruker en postgres-database med én master og flere helt identiske kopier. Det er bare én primær database om gangen ("databaseserveren"). De gjenværende medlemmene av klyngen er replikaer eller "databaseklienter".
En databaseklynge krever et dedikert serversertifikat og et klientsertifikat. De må signeres av sertifikater, vanligvis en intern privat sertifiseringsinstans. Fordi ethvert medlem av databaseklyngen kan bli master, må databaseserveren og klientsertifikatparene (som inneholder de offentlige og private nøklene) kopieres til alle servere slik at de kan anta identiteten til klienten eller databasetjeneren. I tillegg må CA-rotsertifikatet lastes for å sikre at klient- og serversertifikatet kan verifiseres.
Så vi oppretter en forespørsel om et sertifikat som vil bli brukt av alle servertjenester unntatt databasen (det vil være en egen forespørsel 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 navnet på serverne våre. For eksempel hvis vertsnavnene til våre servere server01, server02, server03, da blir CN server.example.com
Vi gjør det samme på de resterende to serverne med den forskjellen at kommandoene vil inneholde de tilsvarende "vertsnavnene"
Vi genererer to forespørsler om sertifikater som vil bli brukt av databasetjenesten med kommandoer som:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresder dbclusterserver и dbclusterklient navn på våre forespørsler og fremtidige sertifikater, vertsnavn1(2)(3) navnene på de tilsvarende serverne.
Vi utfører denne prosedyren kun på én server (!), og vi vil laste opp sertifikatene og tilsvarende .key-filer til andre servere.
Aktiver klientsertifikatmodus i AD CS
Du må også slå sammen sertifikatene 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 last opp til hver server:
1. "Individuelt" serversertifikat.
2. Rotsertifikat (sammen med mellomliggende, hvis noen).
3. Sertifikater for databasen («server» og «klient») og filer med .key-utvidelsen, som ble generert ved opprettelse av en forespørsel om «server»- og «klient»-databasesertifikatene. Disse filene må være like på alle servere.
4. Fil over alle tre "individuelle" sertifikater.
Som et resultat bør du få noe som dette filbildet på hver server.
Databaseklynge
Nå som du har lastet opp alle sertifikatene til CMS-serverne, kan du konfigurere og aktivere databaseklynger mellom de tre nodene. Det første trinnet er å velge én server som hovednoden for databaseklyngen og konfigurere den fullstendig.
Hoveddatabase
Det første trinnet i å sette opp databasereplikering er å spesifisere sertifikatene som skal brukes for databasen. Dette gjøres ved å bruke en kommando som:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>La oss nå fortelle CMS hvilket grensesnitt som skal brukes for databaseklynger med kommandoen:
database cluster localnode aDeretter initialiserer vi klyngedatabasen på hovedserveren med kommandoen:
database cluster initialize
Klientdatabasenoder
Vi gjør samme prosedyre, bare i stedet for kommandoen initialisering av databaseklynge skriv inn en kommando som:
database cluster join <ip address existing master>hvor ip-adresse eksisterende master-ip-adresse til CMS-serveren som klyngen ble initialisert på, ganske enkelt Master.
Vi sjekker hvordan databaseklyngen vår fungerer på alle servere med kommandoen:
database cluster status
Vi gjør det samme på den gjenværende tredje serveren.
Som et resultat viser det seg at vår første server er Mesteren, resten er Slaver.
Nettadministrasjonstjeneste
Aktiver nettadministratortjenesten:
webadmin listen a 445Port 445 ble valgt fordi port 443 brukes for brukertilgang til webklienten
Vi konfigurerer Web Admin-tjenesten med sertifikatfiler med en kommando som:
webadmin certs <keyfile> <certificatefile> <ca bundle>Og aktiver Web Admin med kommandoen:
webadmin enable
Hvis alt er bra, vil vi motta SUKSESS-linjer som indikerer at Web Admin er riktig konfigurert for nettverket og sertifikatet. Vi sjekker funksjonaliteten til tjenesten ved hjelp av en nettleser og skriver inn adressen til nettadministratoren, for eksempel: : 445
Ring Bridge Cluster
Call Bridge er den eneste tjenesten som finnes i hver CMS-distribusjon. Call Bridge er den viktigste konferansemekanismen. Den gir også et SIP-grensesnitt slik at samtaler kan rutes til eller fra det av for eksempel en Cisco Unified CM.
Kommandoene beskrevet nedenfor må utføres på hver server med de riktige sertifikatene.
Så:
Vi knytter sertifikater til Call Bridge-tjenesten med en kommando som:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Vi binder CallBridge-tjenester til grensesnittet vi trenger med kommandoen:
callbridge listen aOg start tjenesten på nytt med kommandoen:
callbridge restart
Nå som vi har konfigurert Call Bridges, kan vi konfigurere Call Bridge-klynger. Call Bridge-klynger er forskjellig fra database- eller XMPP-klynger. Call Bridge Cluster kan støtte fra 2 til 8 noder uten noen begrensninger. Det gir ikke bare redundans, men også lastbalansering slik at konferanser aktivt kan distribueres på tvers av Call Bridge-servere ved hjelp av intelligent samtaledistribusjon. CMS har tilleggsfunksjoner, Call Bridge-grupper og relaterte funksjoner som kan brukes til videre administrasjon.
Samtalebroklynger konfigureres primært gjennom webadministrasjonsgrensesnittet
Prosedyren beskrevet nedenfor må utføres på hver server i klyngen.
således
1. Gå gjennom nettet til Konfigurasjon > Klynge.
2. Inn Call Bridge-identitet Som et unikt navn, skriv inn callbridge[01,02,03] som tilsvarer servernavnet. Disse navnene er vilkårlige, men må være unike for denne klyngen. De er beskrivende av natur fordi de indikerer at de er serveridentifikatorer [01,02,03].
3.B Klyngede anropsbroer skriv inn nettadministrator-URLene til serverne våre i klyngen, [01,02,03].example.com:445, i adressefeltet. Sørg for å spesifisere porten. Du kan la Peer link SIP-domene stå tomt.
4. Legg til et sertifikat til CallBridge-tilliten til hver server, hvis fil inneholder alle sertifikatene til serverne våre, som vi slo sammen med denne filen helt i begynnelsen, med en kommando som:
callbridge trust cluster <trusted cluster certificate bundle>Og start tjenesten på nytt med kommandoen:
callbridge restart
Som et resultat bør du få dette bildet på hver server:
XMPP-klynge
XMPP-tjenesten i CMS brukes til å håndtere all registrering og autentisering for Cisco Meeting Apps (CMA), inkludert CMA WebRTC-webklienten. Selve Call Bridge fungerer også som en XMPP-klient for autentiseringsformål og må derfor konfigureres som andre klienter. XMPP-feiltoleranse er en funksjon som har blitt støttet i produksjonsmiljøer siden versjon 2.1
Kommandoene beskrevet nedenfor må utføres på hver server med de riktige sertifikatene.
Så:
Vi knytter sertifikater til XMPP-tjenesten med en kommando som:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Definer deretter lyttegrensesnittet med kommandoen:
xmpp listen aXMPP-tjenesten krever et unikt domene. Dette er innloggingen for brukere. Med andre ord, når en bruker prøver å logge på ved hjelp av CMA-appen (eller gjennom WebRTC-klienten), skriver de inn brukerID@logindomene. I vårt tilfelle vil det være brukerid@conf.example.com. Hvorfor er det ikke bare example.com? I vår spesielle distribusjon valgte vi vårt Unified CM-domene som Jabber-brukere vil bruke i Unified CM som example.com, så vi trengte et annet domene for CMS-brukere for å rute anrop til og fra CMS gjennom SIP-domener.
Sett opp et XMPP-domene ved å bruke en kommando som:
xmpp domain <domain>Og aktiver XMPP-tjenesten med kommandoen:
xmpp enableI XMPP-tjenesten må du opprette legitimasjon for hver Call Bridge som skal brukes når du registrerer deg med XMPP-tjenesten. Disse navnene er vilkårlige (og er ikke relatert til de unike navnene du konfigurerte for anropsbroklynger). Du må legge til tre anropsbroer på én XMPP-server og deretter angi disse legitimasjonene på andre XMPP-servere i klyngen fordi denne konfigurasjonen ikke passer inn i klyngedatabasen. Senere vil vi konfigurere hver Call Bridge til å bruke dette navnet og hemmeligheten for å registrere deg med XMPP-tjenesten.
Nå må vi konfigurere XMPP-tjenesten på den første serveren med tre Call Bridges callbridge01, callbridge02 og callbridge03. Hver konto vil bli tildelt tilfeldige passord. De vil senere bli lagt inn på andre Call Bridge-servere for å logge på denne XMPP-serveren. Skriv inn følgende kommandoer:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Som et resultat sjekker vi hva som skjedde med kommandoen:
xmpp callbridge list
Nøyaktig det samme bildet skal vises på de gjenværende serverne etter trinnene beskrevet nedenfor.
Deretter legger vi til nøyaktig de samme innstillingene på de resterende to serverne, bare med kommandoene
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Vi legger til Secret veldig nøye slik at det for eksempel ikke er ekstra mellomrom i den.
Som et resultat bør hver server ha det samme bildet:
Deretter, på alle servere i klyngen, spesifiserer vi i tillit filen som inneholder alle tre sertifikatene, opprettet tidligere med en kommando som denne:
xmpp cluster trust <trust bundle>Vi aktiverer xmpp klyngemodus på alle klyngeservere med kommandoen:
xmpp cluster enablePå den første serveren til klyngen starter vi opprettelsen av en xmpp-klynge med kommandoen:
xmpp cluster initializePå andre servere, legg til en klynge til xmpp med en kommando som:
xmpp cluster join <ip address head xmpp server>Vi sjekker på hver server suksessen med å lage en XMPP-klynge på hver server med kommandoene:
xmpp status
xmpp cluster statusFørste server:
Andre server:
Tredje server:
Kobler Call Bridge til XMPP
Nå som XMPP-klyngen kjører, må du konfigurere Call Bridge-tjenestene for å koble til XMPP-klyngen. Denne konfigurasjonen gjøres gjennom nettadministratoren.
På hver server går du til Konfigurasjon > Generelt og i feltet Unikt Call Bridge-navn skriv unike navn som tilsvarer serveren Call Bridge callbridge[01,02,03]... I feltet Domene conf.example.ru og tilsvarende passord, kan du spionere på dem
på hvilken som helst server i klyngen med kommandoen:
xmpp callbridge list
La "Server"-feltet stå tomt Callbridge vil utføre et DNS SRV-oppslag for _xmpp-component._tcp.conf.example.comfor å finne en tilgjengelig XMPP-server. IP-adressene for å koble callbridges til XMPP kan variere på hver server, det avhenger av hvilke verdier som returneres til rekordforespørselen _xmpp-component._tcp.conf.example.com callbridge, som igjen avhenger av prioritetsinnstillingene for en gitt DNS-post.
Deretter går du til Status > Generelt for å bekrefte om Call Bride-tjenesten er koblet til XMPP-tjenesten.
Web Bridge
På hver server i klyngen aktiverer du Web Bridge-tjenesten med kommandoen:
webbridge listen a:443Vi konfigurerer Web Bridge-tjenesten med sertifikatfiler med en kommando som:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge støtter HTTPS. Den vil omdirigere HTTP til HTTPS hvis den er konfigurert til å bruke "http-redirect".
For å aktivere HTTP-omdirigering, bruk følgende kommando:
webbridge http-redirect enableFor å fortelle Call Bridge at Web Bridge kan stole på tilkoblinger fra Call Bridge, bruk kommandoen:
webbridge trust <certfile>hvor dette er en fil som inneholder alle tre sertifikatene fra hver server i klyngen.
Dette bildet bør være på hver server i klyngen.
Nå må vi opprette en bruker med rollen "appadmin", vi trenger den slik at vi kan konfigurere klyngen vår(!), og ikke hver server i klyngen separat, på denne måten vil innstillingene bli brukt likt på hver server til tross for faktum at de vil bli laget en gang.
For videre oppsett vil vi bruke .
For autorisasjon, velg Grunnleggende i Autorisasjonsdelen
For å sende kommandoer til CMS-serveren på riktig måte, må du angi den nødvendige kodingen
Vi spesifiserer Webbridge med kommandoen POST med parameter url og mening
I selve nettbroen angir vi de nødvendige parameterne: gjestetilgang, beskyttet tilgang osv.
Ring Bridge-grupper
Som standard gjør CMS ikke alltid den mest effektive bruken av konferanseressursene som er tilgjengelige for den.
For eksempel, for et møte med tre deltakere, kan hver deltaker havne på tre forskjellige anropsbroer. For at disse tre deltakerne skal kunne kommunisere med hverandre, vil Call Bridges automatisk etablere forbindelser mellom alle servere og klienter i samme Space, slik at det hele ser ut som om alle klienter er på samme server. Dessverre er ulempen med dette at en enkelt 3-personers konferanse nå vil forbruke 9 medieporter. Dette er åpenbart en ineffektiv ressursbruk. I tillegg, når en anropsbro virkelig er overbelastet, er standardmekanismen å fortsette å akseptere anrop og gi redusert kvalitetstjeneste til alle abonnenter på den anropsbroen.
Disse problemene løses ved å bruke funksjonen Call Bridge Group. Denne funksjonen ble introdusert i versjon 2.1 av Cisco Meeting Server-programvaren og har blitt utvidet til å støtte lastbalansering for både innkommende og utgående Cisco Meeting App (CMA)-anrop, inkludert WebRTC-deltakere.
For å løse tilkoblingsproblemet er det innført tre konfigurerbare belastningsgrenser for hver anropsbro:
LoadLimit — dette er den maksimale numeriske belastningen for en bestemt anropsbro. Hver plattform har en anbefalt belastningsgrense, for eksempel 96000 for CMS1000 og 1.25 GHz per vCPU for den virtuelle maskinen. Ulike samtaler bruker en viss mengde ressurser avhengig av oppløsningen og bildefrekvensen til deltakeren.
NewConferenceLoadLimitBasisPoints (standard 50% loadLimit) - setter serverbelastningsgrensen, hvoretter nye konferanser avvises.
Eksisterende ConferenceLoadLimitBasisPoints (standard 80 % av loadLimit) - serverens belastningsverdi etter at deltakere som blir med i en eksisterende konferanse vil bli avvist.
Selv om denne funksjonen ble designet for samtalefordeling og lastbalansering, kan andre grupper som TURN-servere, Web Bridge-servere og opptakere også tilordnes til Call Bridge-grupper slik at de også kan grupperes riktig for optimal bruk. Hvis noen av disse objektene ikke er tilordnet en samtalegruppe, antas de å være tilgjengelig for alle servere uten noen spesiell prioritet.
Disse parameterne konfigureres her: :445/api/v1/system/configuration/cluster
Deretter indikerer vi for hver callbridge hvilken callbridge-gruppe den tilhører:
Første callbridge
Andre anropsbro
Tredje anropsbro
Dermed konfigurerte vi Call Brdige-gruppen til å bruke ressursene til Cisco Meeting Server-klyngen mer effektivt.
Importere brukere fra Active Directory
Web Admin-tjenesten har en LDAP-konfigurasjonsdel, men den gir ikke komplekse konfigurasjonsalternativer, og informasjonen lagres ikke i klyngedatabasen, så konfigurasjonen må gjøres, enten manuelt på hver server via webgrensesnittet, eller gjennom API, og slik at vi "tre ganger "Ikke stå opp" vil vi fortsatt sette dataene via API.
Bruker URL for å få tilgang :445/api/v1/ldapServers oppretter et LDAP Server-objekt, og spesifiserer parametere som:
- Server IP
- portnummer
- Brukernavn
- passord
- sikre
Sikker - velg sann eller usann avhengig av porten, 389 - ikke sikker, 636 - beskyttet.
Tilordne LDAP-kildeparametere til attributter i Cisco Meeting Server.
LDAP-tilordningen tilordner attributtene i LDAP-katalogen til attributtene i CMS. De faktiske egenskapene:
- jidMapping
- navnekartlegging
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskrivelse av attributterIADB representerer brukerens påloggings-ID i CMS. Siden dette er en Microsoft Active Directory LDAP-server, tilordnes CMS JID til sAMAccountName i LDAP, som i hovedsak er brukerens Active Directory-påloggings-ID. Vær også oppmerksom på at du tar sAMAccountName og legger til domenet conf.pod6.cms.lab på slutten av det fordi dette er påloggingen brukerne vil bruke for å logge på CMS.
navnekartlegging samsvarer med det som finnes i Active Directory displayName-feltet med brukerens CMS-navnfelt.
coSpaceNameMapping oppretter et CMS-romnavn basert på displayName-feltet. Dette attributtet, sammen med coSpaceUriMapping-attributtet, er det som kreves for å opprette en plass for hver bruker.
coSpaceUriMapping definerer brukerdelen av URI-en knyttet til brukerens personlige område. Noen domener kan konfigureres til å ringes inn i rommet. Hvis brukerdelen samsvarer med dette feltet for ett av disse domenene, vil anropet bli dirigert til brukerens område.
coSpaceSecondaryUriMapping definerer en andre URI for å nå plass. Dette kan brukes til å legge til et numerisk alias for å rute anrop til den importerte brukerens plass som et alternativ til den alfanumeriske URIen som er definert i coSpaceUriMapping-parameteren.
LDAP-serveren og LDAP-tilordningen er konfigurert. Nå må du koble dem sammen ved å opprette en LDAP-kilde.
Bruker URL for å få tilgang :445/api/v1/ldapSource opprette et LDAP-kildeobjekt, og spesifisere parametere som:
- server
- kartlegging
- baseDn
- filtrere
Nå som LDAP-konfigurasjonen er fullført, kan du utføre manuell synkronisering.
Vi gjør dette enten i nettgrensesnittet til hver server ved å klikke Synkroniser nå seksjon Active Directory
eller via API med kommandoen POST bruker URL for å få tilgang :445/api/v1/ldapSyncs
Ad-hoc konferanser
Hva er dette?I det tradisjonelle konseptet er en konferanse når to deltakere snakker med hverandre, og en av deltakerne (ved å bruke en enhet registrert med Unified CM) trykker på "Konferanse"-knappen, ringer den andre personen og etter å ha snakket med den tredjeparten , trykker på "Konferanse"-knappen igjen for å bli med alle deltakerne i trepartskonferansen.
Det som skiller en Ad-Hoc-konferanse fra en planlagt konferanse i et CMS er at en Ad-Hoc-konferanse ikke bare er en SIP-samtale til CMS. Når konferanseinitiatoren klikker på Konferanse-knappen en gang til for å invitere alle til det samme møtet, må Unified CM foreta et API-anrop til CMS for å opprette en on-the-fly-konferanse som alle samtaler deretter overføres til. Alt dette skjer ubemerket av deltakerne.
Dette betyr at Unified CM må konfigurere API-legitimasjonen og WebAdmin-adressen/porten til tjenesten samt SIP-trunken direkte til CMS-serveren for å fortsette samtalen.
Om nødvendig kan CUCM dynamisk opprette en plass i CMS slik at hver samtale kan nå CMS og matche regelen for innkommende anrop som er beregnet på mellomrom.
Integrasjon med CUCM konfigurert på samme måte som beskrevet i artikkelen bortsett fra at på Cisco UCM må du opprette tre trunker for CMS, tre konferansebroer, i SIP-sikkerhetsprofilen spesifisere tre emnenavn, rutegrupper, rutelister, mediaressursgrupper og mediaressursgruppelister, og legg til noen få rutingsregler til Cisco Meeting Server.
SIP-sikkerhetsprofil:
Trunks:
Hver stamme ser lik ut:
Konferansebro
Hver konferansebro ser lik ut:
Rutegruppe
Ruteliste
Medieressursgruppe
Medieressursgruppeliste
Samtaleregler
I motsetning til mer avanserte samtalehåndteringssystemer som Unified CM eller Expressway, ser CMS kun opp domenet i SIP Request-URI-feltet for nye samtaler. Så hvis SIP INVITE er for en slurk: [e-postbeskyttet]CMS bryr seg kun om domain.com. CMS følger disse reglene for å bestemme hvor en samtale skal rutes:
1. CMS-en prøver først å matche SIP-domenet med domenene som er konfigurert i reglene for innkommende anrop. Disse samtalene kan deretter rutes til ("målrettede") områder eller spesifikke brukere, interne IVR-er eller direkte integrerte Microsoft Lync/Skype for Business (S4B)-destinasjoner.
2. Hvis det ikke er samsvar i reglene for innkommende anrop, vil CMS prøve å matche domenet som er konfigurert i viderekoblingstabellen. Hvis det er et samsvar, kan regelen eksplisitt avvise anropet eller viderekoble anropet. På dette tidspunktet kan CMS-en skrive om domenet, noe som noen ganger er nyttig for å kalle Lync-domener. Du kan også velge å passere kast, noe som betyr at ingen av feltene vil bli ytterligere modifisert, eller bruke en intern CMS-oppringingsplan. Hvis det ikke er samsvar i reglene for viderekobling, er standard å avvise anropet. Husk at i CMS, selv om anropet er "viderekoblet", er media fortsatt bundet til CMS, noe som betyr at det vil være i signal- og medietrafikkbanen.
Da er det kun viderekoblede anrop som er underlagt reglene for utgående anrop. Disse innstillingene bestemmer destinasjonene som anrop sendes til, trunktypen (enten det er et nytt Lync-anrop eller et standard SIP-anrop), og eventuelle konverteringer som kan utføres hvis overføring ikke er valgt i regelen for viderekobling av anrop.
Her er selve loggen over hva som skjer under en ad-hoc-konferanse
Skjermbildet viser det dårlig (jeg vet ikke hvordan jeg skal gjøre det bedre), så jeg skriver loggen slik:
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-konferansen:
Regler for innkommende anrop
Konfigurering av parametere for innkommende anrop er nødvendig for å kunne motta en samtale i CMS. Som du så i LDAP-oppsettet, ble alle brukere importert med domenet conf.pod6.cms.lab. Så som et minimum vil du at anrop til dette domenet skal målrettes mot områder. Du må også sette opp regler for alt som er ment for det fullt kvalifiserte domenenavnet (og kanskje til og med IP-adressen) til hver av CMS-serverne. Vår eksterne samtalekontroll, Unified CM, vil konfigurere SIP-trunker dedikert til hver av CMS-serverne individuelt. Avhengig av om destinasjonen til disse SIP-trunkene er en IP-adresse eller serverens FQDN vil avgjøre om CMS-en må konfigureres til å akseptere anrop rettet til IP-adressen eller FQDN.
Domenet som har høyest prioritet inngående regel, brukes som domene for eventuelle brukerområder. Når brukere synkroniserer via LDAP, oppretter CMS automatisk mellomrom, men bare brukerdelen av URI (coSpaceUriMapping), for eksempel user.space. Del Den fullstendige URIen genereres basert på denne regelen. Faktisk, hvis du skulle logge på Web Bridge på dette tidspunktet, ville du se at Space URI ikke har et domene. Ved å angi denne regelen som høyeste prioritet, angir du domenet for de genererte områdene konf.eksempel.com.
Regler for utgående anrop
For å tillate brukere å foreta utgående anrop til Unified CM-klyngen, må du konfigurere utgående regler. Domenet til endepunkter registrert med Unified CM, for eksempel Jabber, er example.com. Anrop til dette domenet bør rutes som standard SIP-anrop til Unified CM-anropsbehandlingsnoder. Hovedserveren er cucm-01.example.com, og tilleggsserveren er cucm-02.example.com.
Den første regelen beskriver den enkleste rutingen av samtaler mellom klyngeservere.
Feltet Lokal fra domene er ansvarlig for hva som vil vises i innringerens SIP-URI for personen som blir oppringt etter "@"-symbolet. Hvis vi lar det stå tomt, vil det etter "@"-symbolet være CUCMs IP-adresse som denne samtalen går gjennom. Hvis vi spesifiserer et domene, vil det faktisk være et domene etter "@"-symbolet. Dette er nødvendig for å kunne ringe tilbake, ellers vil det ikke være mulig å ringe tilbake via SIP-URI navn@ip-adresse.
Ring når spesifisert Lokal fra domene
Ring når IKKE angitt Lokal fra domene
Pass på å spesifisere Kryptert eller Ukryptert for utgående anrop, fordi ingenting fungerer med Auto-parameteren.
Innspilling
Videokonferanser tas opp av opptaksserveren. Opptaker er nøyaktig det samme som Cisco Meeting Server. Opptakeren krever ikke installasjon av noen lisenser. Innspillingslisenser kreves for servere som kjører CallBridge-tjenester, dvs. en opptakslisens kreves og må brukes på CallBridge-komponenten, og ikke på serveren som kjører Recorder. Opptakeren oppfører seg som en XMPP-klient (Extensible Messaging and Presence Protocol), så XMPP-serveren må være aktivert på serveren som er vert for CallBridge.
Fordi Vi har en klynge og lisensen må "strekkes" over alle tre serverne i klyngen. Deretter kan du enkelt legge inn din personlige konto i lisensene vi tilknytter (legge til) MAC-adressene til a-grensesnittene til alle CMS-servere som er inkludert i klyngen.
Og dette er bildet som skal være på hver server i klyngen
Generelt er det flere scenarier for å plassere Recorder, men vi vil holde oss til dette:
Før du setter opp Recorder, må du forberede et sted hvor videokonferansene faktisk skal spilles inn. Faktisk her , hvordan sette opp alle opptak. Jeg fokuserer på viktige punkter og detaljer:
1. Det er bedre å slippe sertifikatet fra den første serveren i klyngen.
2. Feilen "Recorder utilgjengelig" kan oppstå fordi feil sertifikat er spesifisert i Recorder Trust.
3. Skriving fungerer kanskje ikke hvis NFS-katalogen som er spesifisert for opptak, ikke er rotkatalogen.
Noen ganger er det behov for å automatisk ta opp en konferanse for en bestemt bruker eller plass.
For dette opprettes to CallProfiler:
Med opptak deaktivert
Og med automatisk opptaksfunksjon
Deretter "fester" vi en CallProfile med en automatisk opptaksfunksjon til ønsket plass.
I CMS er det så etablert at hvis en CallProfil er eksplisitt knyttet til et hvilket som helst mellomrom eller plass, så fungerer denne CallProfilen kun i forhold til disse spesifikke områdene. Og hvis CallProfile ikke er bundet til noe mellomrom, blir den som standard brukt på de områdene som ingen CallProfil er eksplisitt bundet til.
Neste gang skal jeg prøve å beskrive hvordan CMS er tilgjengelig utenfor organisasjonens interne nettverk.
Kilder:
Kilde: www.habr.com