I den hÀr utgÄvan kommer jag att visa och förklara nÄgra finjusteringar av CMS-serverinstÀllningen i en felresistent klusterkonfiguration.
TeoriDet finns tre typer av distributioner av CMS-servrar:
- Single Combined(Ensam kombinerad), dvs. en server dÀr alla nödvÀndiga tjÀnster körs. I de flesta fall tillÀmpas denna typ av distribution endast för interna kunders Ätkomst och i smÄ miljöer dÀr begrÀnsningar i skalbarhet och redundans för en enda server inte Àr ett kritiskt problem, eller i situationer dÀr CMS endast utför specifika funktioner, sÄsom specialkonferenser pÄ Cisco UCM.
En ungefÀrlig arbetsdiagram:
- Single Split(Ensam delad) bygger vidare pÄ den tidigare distributionsmodellen genom att lÀgga till en separat server för extern Ätkomst. I Àldre distributioner betydde detta att distribuera CMS-servern i ett demilitariserat nÀtverkssegment (DMZ), dÀr externa kunder kan fÄ tillgÄng till den, och en CMS-server i kÀrnnÀtverket, dÀr interna kunder fÄr Ätkomst till CMS. Denna specifika distributionsmodell ersÀtts nu av den sÄ kallade typen Single Edge, som bestÄr av servrar Cisco Expressway, som antingen har eller kommer att ha mÄnga av brandvÀggsöverskridande funktionerna, vilket gör att kunderna inte behöver lÀgga till en dedikerad grÀnsserver för CMS.
En ungefÀrlig arbetsdiagram:
- Scalable and Resilient(Skalbar och felresistent) denna typ inkluderar redundans för varje komponent, vilket gör att systemet kan vÀxa med dina behov Ànda upp till maximal kapacitet, samtidigt som det ger redundans vid fel. Det anvÀnder ocksÄ konceptet Single Edge för att sÀkerstÀlla sÀker extern Ätkomst. Det Àr denna typ vi kommer att titta pÄ i det hÀr avsnittet. Om vi förstÄr hur man distribuerar ett kluster av denna typ, kommer vi inte bara att förstÄ andra typer av distributioner, utan ocksÄ förstÄ hur man skapar kluster av CMS-servrar med hÀnsyn till potentiell tillvÀxt av behov.
Innan vi gÄr vidare till distributionen mÄste vi förstÄ nÄgra grundlÀggande saker, nÀmligen
GrundlÀggande programvarukomponenter för CMS:
- Databas: gör det möjligt att kombinera vissa konfigurationer, sÄsom abonnentgrupp, anvÀndarutrymmen och sjÀlva anvÀndarna. Stöder klustring endast för hög tillgÀnglighet (en mÀstare).
- Call Bridge: en tjÀnst för ljud- och videokonferenser som ger full kontroll över hantering och bearbetning av samtal och multimediaprocesser. Stöder klustring för hög tillgÀnglighet och skalbarhet.
- XMPP-server: ansvarar för registrering och autentisering av klienter som anvÀnder Cisco Meeting Application och/eller WebRTC (real-tidskommunikation, eller helt enkelt i webblÀsaren), samt mellan komponenters signalering. Kan endast klustras för hög tillgÀnglighet.
- Web Bridge: ger klienter tillgÄng till WebRTC.
- Loadbalancer: tillhandahÄller en enda anslutningspunkt för applikationer av Cisco Meeting App i lÀge för Single Split. Lyssnar pÄ det externa grÀnssnittet och porten för inkommande anslutningar. Loadbalancern accepterar pÄ lika villkor inkommande TLS-anslutningar frÄn XMPP-servern, genom vilka den kan vÀxla TCP-anslutningar frÄn externa klienter.
I vÄrt scenario behövs den inte. - TURN-server: tillhandahÄller teknik för att kringgÄ brandvÀggar, vilket gör det möjligt
att exponera vÄr CMS bakom en brandvÀgg eller NAT för att ansluta externa klienter som anvÀnder Cisco Meeting App eller SIP-enheter. I vÄrt scenario behövs den inte. - Web Admin: administrativt grÀnssnitt och tillgÄng till API:et, inklusive för speciella konferenser Unified CM.
KonfigurationslÀgen
Till skillnad frÄn de flesta andra Cisco-produkter stöder Cisco Meeting Server tre metoder för konfiguration som möjliggör implementering av alla typer av deployment.
- Kommandorad (CLI): kommandoradsgrÀnssnitt, kÀnt som MMP, för initial konfiguration och certifikat.
- Webbadministratör: frÀmst för konfiguration relaterad till CallBridge, sÀrskilt vid konfiguration av en icke-klustrad server.
- REST API: anvÀnds för de mest komplexa konfigurationsuppgifterna och uppgifter relaterade till klusterdatabasen.
Förutom ovanstĂ„ende anvĂ€nds protokollet SFTP för att överföra filer â vanligtvis licenser, certifikat eller loggar â till och frĂ„n CMS-servern.
I Cisco:s deploymentsguider stÄr det klart och tydligt pÄ engelska att klustret mÄste implementeras med minst tre servrar (noder) i kontexten av databaser. Eftersom endast med ett ojÀmnt antal noder fungerar mekanismen för att vÀlja en ny databas-master, och överhuvudtaget har databas-masteren kontakt med större delen av databasen pÄ CMS-servern.
Och som erfarenheten visar Àr tvÄ servrar (noder) faktiskt inte tillrÀckliga. Valmekanismen aktiveras vid omstart av Master-servern, och Slave-servern blir en Master enbart efter att den omstartade servern har höjts. Om Master-servern i en kluster med tvÄ servrar plötsligt "slÀcks", sÄ blir Slave-servern aldrig Master, men om Slave-servern "slÀcks", sÄ kommer den kvarvarande Master-servern att bli Slave.
I sammanhanget XMPP behöver man faktiskt samla en kluster av tre servrar, eftersom om man till exempel stÀnger av XMPP-tjÀnsten pÄ en av servrarna dÀr XMMP Àr i ledarstatus, sÄ kommer XMPP pÄ den ÄterstÄende servern förbli i följandestatus, och anslutningar frÄn CallBridge till XMPP kommer att avbrytas, eftersom CallBridge enbart ansluter till XMPP i ledarstatus. Detta Àr kritiskt, eftersom inget samtal kommer att gÄ igenom.
Ăven i dessa deployment-guider demonstreras en kluster med en enda XMPP-server.
Med beaktande av ovanstÄende blir det tydligt varför: det fungerar eftersom det Àr i failover-lÀge.
I vÄrt fall kommer XMPP-servern att finnas pÄ alla tre noder.
Det antas att alla tre vÄra servrar Àr uppe.
DNS-poster
Innan man börjar konfigurera servrarna mÄste man skapa DNS-poster A och SRV typer:
Observera att det finns tvÄ domÀner i vÄra DNS-poster: example.com och conf.example.com. Example.com Àr den domÀn som alla abonnenter av Cisco Unified Communication Manager kan anvÀnda för sina URI:er, som förmodligen finns i din infrastruktur eller med hög sannolikhet kommer att finnas. Eller sÄ motsvarar domÀn example.com den domÀn som anvÀndarna anvÀnder för sina e-postadresser. Eller sÄ kan Jabber-klienten pÄ din laptop ha URI user@example.com. DomÀnen conf.example.com Àr den domÀn som kommer att konfigureras för anvÀndarna av Cisco Meeting Server. DomÀnen för Cisco Meeting Server kommer att vara conf.example.com, sÄ för samma Jabber-anvÀndare som loggar in pÄ Cisco Meeting Server mÄste man anvÀnda URI user@conf.example.com.
Grundkonfiguration
Alla instÀllningar som beskrivs nedan visas pÄ en server, men de mÄste genomföras pÄ var och en av serverna i klustret.
QoS.
Eftersom CMS genererar real-time Trafik som Ă€r kĂ€nslig för fördröjning och paketförlust bör i de flesta fall konfigureras med kvalitetsservice (QoS). För detta Ă€ndamĂ„l stödjer CMS mĂ€rkning av paket med differentierade tjĂ€nstekoder (DSCP), som den genererar. Ăven om prioritering av trafik baserat pĂ„ DSCP beror pĂ„ hur trafiken hanteras av nĂ€tverkskomponenterna i din infrastruktur, kommer vi i vĂ„rt fall att konfigurera vĂ„rt CMS med en typisk distribution av DSCP-prioriteter baserat pĂ„ branschstandardernas bĂ€sta praxis.
Vi kommer att köra följande kommandon pÄ varje server
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1APÄ sÄ sÀtt har all video trafik mÀrkts med AF41 (DSCP 0x22), all rösttrafik har mÀrkts med EF (DSCP 0x2E), och andra typer av lÄg-latens trafik, sÄsom SIP och XMPP, anvÀnder AF31 (DSCP 0x1A).
Kontrollerar:
NTP
NÀtverkstidsprotokollet (NTP) Àr viktigt inte bara för att sÀkerstÀlla exakta tidsstÀmplar för samtal och konferenser, utan ocksÄ för att verifiera certifikat.
Vi lÀgger till NTP-servrarna i din infrastruktur med kommandot:
ntp server add I vÄrt fall finns det tvÄ sÄdana servrar, sÄ vi kommer att ha tvÄ kommandon.
Kontrollerar:
Och vi anger tidszonen för vÄr server.
DNS
DNS-servrar i CMS lÀgger vi till med kommandot:
dns add forwardzone I vÄrt fall finns det tvÄ sÄdana servrar, sÄ vi kommer att ha tvÄ kommandon.
Kontrollerar:
Konfiguration av nÀtverksgrÀnssnittet
Vi konfigurerar grÀnssnittet med kommandot:
ipv4 add / Kontrollerar:
Servernamn (Hostname)
Vi anger servernamnet med kommandot:
hostname Och vi startar om.
SÄ hÀr avslutas den grundlÀggande konfigurationen.
Certificates
TeoriCisco Meeting Server krÀver krypterad kommunikation mellan olika komponenter, och dÀrmed krÀvs X.509-certifikat för alla CMS-installationer. De hjÀlper till att sÀkerstÀlla förtroende för tjÀnster/servern gentemot andra servrar/tjÀnster.
Varje tjÀnst krÀver ett certifikat, men att skapa separata certifikat för varje tjÀnst kan leda till förvirring och onödig komplexitet. Lyckligtvis kan vi generera ett par publika och privata certifikatnycklar och sedan ÄteranvÀnda dem för flera tjÀnster. I vÄrt fall kommer samma certifikat att anvÀndas för Call Bridge, XMPP-servern, Web Bridge och Web Admin. SÄledes behöver vi skapa ett par öppna och stÀngda nycklar för varje server i klustret.
Databasklustering har dock vissa specifika krav pÄ certifikat och krÀver dÀrför sina egna certifikat som skiljer sig frÄn certifikaten för andra tjÀnster. CMS anvÀnder ett servercertifikat som liknar certifikaten som anvÀnds av andra servrar, men det finns ocksÄ ett klientcertifikat som anvÀnds för anslutningar till databasen. Databascertifikat anvÀnds bÄde för autentisering och kryptering. IstÀllet för att tillhandahÄlla anvÀndarnamn och lösenord för att ansluta klienten till databasen, presenteras klientcertifikatet som servern litar pÄ. Varje server i databasklustret kommer att anvÀnda samma par av offentliga och privata nycklar. Detta gör att alla servrar i klustret kan kryptera data pÄ ett sÀtt som endast kan dekrypteras av andra servrar som ocksÄ anvÀnder samma nyckelpar.
För att redundans ska fungera mÄste databaskluster bestÄ av minst 3 servrar men högst 5, med en maximal fördröjningstid pÄ 200 ms i bÄda riktningarna mellan alla medlemmar i klustret. Denna grÀns Àr mer restriktiv Àn för Call Bridge-klustering, sÄ den Àr ofta en begrÀnsande faktor i geografiskt distribuerade distributioner.
Databasens roll för CMS har en rad unika krav. Till skillnad frÄn andra roller krÀver den bÄde ett klient- och servercertifikat, dÀr klientcertifikatet har ett specifikt CN-fÀlt som presenteras för servern.
CMS anvÀnder en postgres-databas med en huvuddatabas och flera helt identiska repliker. Vid varje given tidpunkt finns det endast en huvuddatabas ("databasserver"). De övriga medlemmarna i klustret Àr repliker eller "databasklienter."
För databasklustret krÀvs ett dedikerat servercertifikat och ett klientcertifikat. Dessa mÄste vara signerade av certifikat, vanligtvis ett internt privat certifikatutfÀrdande organ. Eftersom nÄgon av medlemmarna i databasklustret kan bli huvud, mÄste paren av databasens servercertifikat och klientcertifikat (som innehÄller offentliga och privata nycklar) kopieras till alla servrar sÄ att de kan acceptera identiteten hos klienten eller databasservern. Dessutom mÄste roten av CA-certifikatet laddas för att sÀkerstÀlla att klient- och servercertifikaten kan verifieras.
SÄ, vi formar en begÀran för certifikatet som kommer att anvÀndas av alla servertjÀnster förutom databas (för detta kommer det att vara en separat begÀran) med kommandot:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
I CN anger vi det generiska namnet pÄ vÄra servrar. Till exempel, om hostname:arna pÄ vÄra servrar server01, server02, server03, sÄ blir CN server.example.com
Samma sak gör vi pÄ de ÄterstÄende tvÄ servrarna med den skillnaden att kommandona kommer att ha motsvarande "hostname:ar".
Vi formar tvÄ begÀrningar för certifikat som kommer att anvÀndas av databasens tjÀnst med kommandon som:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresw dbclusterserver och dbclusterclient namnen pÄ vÄra förfrÄgningar och framtida certifikat, hostname1(2)(3) namnen pÄ de motsvarande servrarna.
Denna procedur utförs endast pÄ en server(!), och certifikaten och motsvarande .key-filer kommer att laddas upp pÄ andra servrar.
Aktivering av klientcertifikatlÀge i AD CS
Vi behöver ocksÄ slÄ samman certifikaten till en fil för varje server.I *NIX:
cat server01.cer server02.cer server03.cer > server.cerI Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer Och ladda upp till varje server:
1. "Individuellt" servercertifikat.
2. Rotcertifikat (tillsammans med mellanliggande om sÄdana finns).
3. Certifikat för databasen ("server" och "klient") och filer med .key-Àndelse som skapades vid skapandet av begÀran för "server" och "klient" databascertifikat. Dessa filer mÄste vara desamma pÄ alla servrar.
4. Filen med alla tre "individuella" certifikaten.
Resultatet ska bli ungefÀr sÄ hÀr pÄ varje server.
Databas Kluster
Nu nÀr du har laddat upp alla certifikat pÄ CMS-servrarna kan du konfigurera och aktivera databasklustring mellan tre noder. Det första steget Àr att vÀlja en server som huvudnod för databasklustret och konfigurera den helt.
Master Database
Det första steget i att konfigurera databashantering Àr att ange certifikat som ska anvÀndas för databasen. Detta görs med ett kommando av följande typ:
database cluster certsNu anger vi för CMS vilken grÀnssnitt som ska anvÀndas för databasernas klustring med kommandot:
database cluster localnode aDÀrefter initierar vi databasens kluster pÄ huvudservern med kommandot:
database cluster initialize
Client Database Nodes
Vi gör samma procedur, men istÀllet för kommandot database cluster initialize anger vi ett kommando av följande typ:
database cluster joindÀr ip address existing master Àr IP-adressen till CMS-servern dÀr klustret initierades, helt enkelt Master1.
Vi kontrollerar hur vÄrt databaskluster fungerar pÄ alla servrar med kommandot:
database cluster status
Det samma gör vi ocksÄ pÄ den kvarstÄende tredje servern.
Resultatet blir att vÄr första server Àr Master, medan de andra Àr Slaves.
Web Admin Service
Vi aktiverar webbadministratörtjÀnsten:
webadmin listen a 445Port 445 valdes eftersom port 443 anvÀnds för anvÀndartillgÄng i webklienten.
Vi konfigurerar Web Admin-tjÀnsten med certifikatfiler med kommandot av följande typ:
webadmin certsOch aktiverar Web Admin med kommandot:
webadmin enable 
Om allt gÄr bra, fÄr vi SUCCESS-rader som anger att Web Admin har konfigurerats korrekt för nÀtverket och certifikatet. Vi testar tjÀnstens funktionalitet med en webblÀsare och skriver in adressen till webbadministratören, till exempel: :445
Call Bridge Cluster
Call Bridge Àr den enda tjÀnsten som finns i varje CMS-distribution. Call Bridge Àr den primÀra mekanismen för konferenskommunikation. Den tillhandahÄller ocksÄ ett SIP-grÀnssnitt sÄ att samtal kan dirigeras till eller frÄn den, till exempel Cisco Unified CM.
Kommandona som beskrivs nedan mÄste utföras pÄ varje server med motsvarande certifikat.
SĂ„:
Vi kopplar certifikaten till Call Bridge-tjÀnsten med ett kommando av följande typ:
callbridge certs []Vi kopplar CallBridge-tjÀnsterna till det grÀnssnitt vi behöver med kommandot:
callbridge listen aOch vi startar om tjÀnsten med kommandot:
callbridge restart 
Nu nÀr vi har konfigurerat Call Bridges kan vi stÀlla in klusterbildning för Call Bridge. Klusterbildning för Call Bridge skiljer sig frÄn klusterbildning för databaser eller XMPP. Call Bridge-klustret kan stödja mellan 2 och 8 noder utan nÄgra begrÀnsningar. Det erbjuder inte bara redundans utan ocksÄ lastbalansering, vilket gör att konferenser kan distribueras aktivt mellan Call Bridge-servrar med hjÀlp av intelligent samtalsfördelning. CMS har ytterligare funktioner, Call Bridge-grupper och relaterade funktioner som kan anvÀndas för vidare hantering.
Klusterbildningen av Call Bridge konfigureras frÀmst via webbadministrationsgrÀnssnittet.
Proceduren som beskrivs nedan mÄste utföras pÄ varje server i klustret.
SĂ„,
1. Logga in via webben pÄ Configuration > Cluster.
2. I Call Bridge identity ange det unika namnet callbridge[01,02,03] motsvarande serverns namn. Dessa namn Àr godtyckliga men mÄste vara unika för detta kluster. De Àr beskrivande eftersom de indikerar att det Àr identifierare för servrarna [01,02,03].
3. I Clustered Call Bridges anger vi URL:erna till webbadministrationen för vÄra servrar i klustret, [01,02,03].example.com:445, i fÀltet Adress. Se till att ange port. Du kan lÀmna Peer link SIP domain tom.
4. LÀgg till certifikatet för Call Bridge frÄn varje server, filen som innehÄller alla certifikat frÄn vÄra servrar som vi sammanfört i denna fil frÄn början, med kommandot:
callbridge trust clusterOch vi startar om tjÀnsten med kommandot:
callbridge restart 
Som ett resultat ska varje server nu se ut sÄ hÀr:
XMPP Cluster
XMPP-tjÀnsten i CMS anvÀnds för att hantera all registrering och autentisering för Cisco Meeting Apps (CMA), inklusive CMA WebRTC webbklienten. Call Bridge fungerar ocksÄ som en XMPP-klient för autentiseringssyften och mÄste dÀrför konfigureras som andra klienter. Fel tolerans för XMPP Àr en funktion som stöds i produktionsmiljöer frÄn version 2.1.
Kommandona som beskrivs nedan mÄste utföras pÄ varje server med motsvarande certifikat.
SĂ„:
Vi kopplar certifikaten till XMPP-tjÀnsten med kommandot:
xmpp certs []Definiera sedan lyssningsgrÀnssnittet med kommandot:
xmpp listen aFör XMPP-tjÀnsten krÀvs en unik domÀn. Detta Àr inloggningen för anvÀndare. Med andra ord, nÀr en anvÀndare försöker logga in via CMA-applikationen (eller via WebRTC-klienten), anger de userID@logindomain. I vÄrt fall blir det userid@conf.example.com. Varför Àr det inte bara example.com? I vÄr specifika installation valde vi vÄr Unified CM-domÀn, som Jabber-anvÀndare kommer att anvÀnda i Unified CM, som example.com, sÄ vi behöver en annan domÀn för CMS-anvÀndare för att dirigera samtal till och frÄn CMS via SIP-domÀner.
StÀll in XMPP-domÀnen med kommandot:
xmpp domainOch vi aktiverar XMPP-tjÀnsten med kommandot:
xmpp enableI XMPP-tjÀnsten mÄste du skapa inloggningsuppgifter för varje Call Bridge som kommer att anvÀndas vid registrering i XMPP-tjÀnsten. Dessa namn Àr godtyckliga (och inte kopplade till de unika namn du har stÀllt in för klustring av Call Bridges). PÄ en XMPP-server mÄste tre Call Bridges lÀggas till, och sedan mata in dessa uppgifter pÄ andra XMPP-servrar i klustret, eftersom den hÀr konfigurationen inte placeras i klustrets databas. Senare kommer vi att stÀlla in varje Call Bridge för att anvÀnda detta namn och hemlighet för registrering i XMPP-tjÀnsten.
Nu behöver vi konfigurera XMPP-tjÀnsten pÄ den första servern med tre Call Bridges callbridge01, callbridge02 och callbridge03. Varje konto fÄr slumpmÀssiga lösenord. Senare kommer dessa att matas in pÄ andra Call Bridge-servrar för att logga in pÄ denna XMPP-server. Vi matar in följande kommandon:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Som ett resultat kontrollerar vi vad som har gjorts med kommandot:
xmpp callbridge list 
Exakt samma bild bör finnas pÄ de andra servrarna efter de ÄtgÀrder som beskrivs nedan.
Vidare lÀgger vi till exakt samma instÀllningar pÄ de ÄterstÄende tvÄ servrarna, bara med kommandon
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Hemligheten lÀggs till mycket försiktigt, sÄ att inga oönskade mellanslag tillsluts av misstag.
Som ett resultat ska varje server visa samma bild:
Vidare pÄ alla kluster-servrar anger vi i förtroende en fil som innehÄller alla tre certifikat, skapad tidigare med kommandot:
xmpp cluster trustVi aktiverar XMPP-klustermod under alla kluster-servrar med kommandot:
xmpp cluster enablePÄ den första servern i klustret initierar vi skapandet av xmpp-kluster med kommandot:
xmpp cluster initializePÄ de övriga servrarna lÀgger vi till i xmpp-klustret med kommandot:
xmpp cluster joinVi kontrollerar pÄ varje server framgÄngen för skapandet av XMPP-klustret med kommandona:
xmpp status
xmpp cluster statusFörsta servern:
Andra servern:
Tredje servern:
Anslutning av Call Bridge till XMPP
Nu nÀr XMPP-klustret Àr igÄng mÄste vi konfigurera Call Bridge-tjÀnster för att ansluta till XMPP-klustret. Denna konfiguration görs via webbadministratören.
Vi gÄr in pÄ varje server under Configuration > General och i fÀltet Unique Call Bridge name anger vi server-specifika unika namn för Call Bridge callbridge[01,02,03]. I fÀltet DomÀn conf.example.ru och motsvarande lösenord, som kan ses
pÄ vilket som helst av klustrets servrar med kommandot:
xmpp callbridge list 
FÀltet "Server" lÀmnas tomt, Callbridge kommer att utföra en DNS SRV-sökning för _xmpp-component._tcp.conf.example.com, för att hitta en tillgÀnglig XMPP-server. IP-adresserna för Callbridge-anslutningar till XMPP kan skilja sig pÄ varje server, beroende pÄ vilka vÀrden som returneras vid förfrÄgan om posten _xmpp-component._tcp.conf.example.com till Callbridge, vilket i sin tur beror pÄ prioriteringsinstÀllningarna för denna DNS-post.
DÀrefter gÄr vi till Status > General för att sÀkerstÀlla att Call Bride-tjÀnsten har anslutit framgÄngsrikt till XMPP-tjÀnsten.
Web Bridge
PÄ varje server i klustret aktiverar vi Web Bridge-tjÀnsten med kommandot:
webbridge listen a:443Vi konfigurerar Web Bridge-tjÀnsten med certifikatfilskommandon av typen:
webbridge certsWeb Bridge stöder HTTPS. Den kommer att omdirigera HTTP till HTTPS om den Àr instÀlld för att anvÀnda "http-redirect".
För att aktivera HTTP-omdirigering, anvÀnd följande kommando:
webbridge http-redirect enableFör att Call Bridge ska kunna indikera att Web Bridge kan lita pÄ anslutningar frÄn Call Bridge, anvÀnd kommandot:
webbridge trustdÀr detta Àr filen som innehÄller alla tre certifikaten frÄn varje server i klustret.
SÄdan ska bilden se ut pÄ varje server i klustret.
Nu behöver vi skapa en anvÀndare med rollen "appadmin", vilket vi behöver för att kunna konfigurera vÄrt kluster(!), och inte varje server i klustret separat, sÄ att instÀllningarna kommer att tillÀmpas enhetligt pÄ varje server, nÀr de görs en gÄng.
För vidare konfiguration kommer vi att anvÀnda .
För autentisering vÀljer vi Basic i avsnittet Authorzation
För att korrekt skicka kommandon till CMS-servrar mÄste rÀtt teckenkodning anges
Vi anger Webbridge med kommandot POST med parametern url och vÀrdet
I sjĂ€lva webbridgeâen anger vi nödvĂ€ndiga parametrar: gĂ€stĂ„tkomst, sĂ€ker Ă„tkomst och annat.
Call Bridge Groups
Som standard anvÀnder CMS inte alltid de tillgÀngliga resurserna för konferenssamtal pÄ ett maximalt effektivt sÀtt.
Till exempel, för ett möte med tre deltagare kan varje deltagare befinna sig pĂ„ tre olika Call Bridgeâar. För att dessa tre deltagare ska kunna kommunicera med varandra kommer Call Bridgeâarna automatiskt att etablera anslutningar mellan alla servrar och klienter i samma Space, sĂ„ att allt ser ut som om alla klienter Ă€r pĂ„ samma server. TyvĂ€rr Ă€r nackdelen med detta att en konferens med tre personer nu kommer att konsumera 9 media-portar. Detta Ă€r uppenbarligen en ineffektiv anvĂ€ndning av resurser. Dessutom, nĂ€r Call Bridge verkligen Ă€r överbelastad, Ă€r standardmekanismen att fortsĂ€tta ta emot samtal och tillhandahĂ„lla tjĂ€nster av nedsatt kvalitet till alla abonnenter pĂ„ denna Call Bridge.
Dessa problem löses genom funktionen Call Bridge Group. Denna funktion introducerades i version 2.1 av programvaran Cisco Meeting Server och har utvidgats för att stödja lastbalansering bÄde för inkommande och utgÄende samtal, Cisco Meeting App (CMA), inklusive deltagare frÄn WebRTC.
För att lösa problemet med Äteranslutning har tre justerbara belastningsgrÀnser införts för varje Call Bridge:
LoadLimit â Ă€r den maximala numeriska belastningen för en specifik Call Bridge. Varje plattform har en rekommenderad belastningsgrĂ€ns, som till exempel 96000 för CMS1000 och 1,25 GHz per virtuell processor för en virtuell maskin. Olika samtal förbrukar en viss mĂ€ngd resurser beroende pĂ„ deltagarens upplösning och bildfrekvens.
NewConferenceLoadLimitBasisPoints (standard 50% loadLimit) â stĂ€ller in serverns belastningsgrĂ€ns, efter vilken nya konferenser avvisas.
ExistingConferenceLoadLimitBasisPoints (standard 80% av loadLimit) â belastningsvĂ€rdet för servern, efter vilket deltagare som ansluter till en befintlig konferens kommer att avvisas.
Ăven om den hĂ€r funktionen Ă€r utformad för att fördela samtal och last, kan Ă€ven andra enheter, sĂ„som TURN-servrar, Web Bridge-servrar och inspelningsenheter, tilldelas till Call Bridge-grupper sĂ„ att de ocksĂ„ kan grupperas korrekt för optimal anvĂ€ndning. Om nĂ„gon av dessa objekt inte Ă€r tilldelade en samtalsgrupp, antas de vara tillgĂ€ngliga för alla servrar utan nĂ„got sĂ€rskilt prioritetsförhĂ„llande.
Dessa instÀllningar konfigureras hÀr: :445/api/v1/system/configuration/cluster
DÀrefter anger vi vilken callbridge som tillhör vilken callbridge-grupp:
Första callbridge
Andra callbridge
Tredje callbridge
PÄ sÄ sÀtt har vi konfigurerat Call Bridge-gruppen för att optimera resursanvÀndningen pÄ Cisco Meeting Server.
Importera anvÀndare frÄn Active Directory
Web Admin-tjÀnsten har ett avsnitt för LDAP-konfiguration, men det erbjuder inte avancerade instÀllningar, och informationen sparas inte i klusterdatabasen, sÄ konfigurationen mÄste göras antingen manuellt pÄ varje server genom webgrÀnssnittet eller via API. För att vi ska slippa göra detta tre gÄnger kommer vi trots allt att ange uppgifterna via API.
Genom att anvÀnda URL-adressen för Ätkomst :445/api/v1/ldapServers skapar vi ett LDAP-serverobjekt och anger parametrar som:
- IP-adress för servern
- portnummer
- anvÀndarnamn
- lösenord
- sÀker
SĂ€ker â true eller false vĂ€ljs beroende pĂ„ port, 389 Ă€r osĂ€ker, 636 Ă€r sĂ€ker.
Kopplar LDAP-kÀllparametrar till attribut i Cisco Meeting Server.
LDAP-mapping matchar attribut i LDAP-katalogen med attribut i CMS. De faktiska attributen Àr:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskrivning av attributenJID representerar anvÀndarens inloggningsidentifierare i CMS. Eftersom detta Àr en Microsoft Active Directory LDAP-server, matchas CMS JID med sAMAccountName i LDAP, vilket i grunden Àr inloggningsidentifieraren för anvÀndaren i Active Directory. Observera ocksÄ att du tar sAMAccountName och lÀgger till domÀnen conf.pod6.cms.lab i slutet, eftersom det Àr den inloggning som dina anvÀndare kommer att anvÀnda för att logga in i CMS.
nameMapping matchar det som finns i fÀltet Active Directory displayName med CMS-anvÀndarens namn.
coSpaceNameMapping skapar namnet pÄ CMS-space baserat pÄ fÀltet displayName. Detta attribut tillsammans med attributet coSpaceUriMapping Àr det som krÀvs för att skapa ett space för varje anvÀndare.
coSpaceUriMapping definierar den anvÀndardel av URI som Àr kopplad till anvÀndarens utrymme. Vissa domÀner kan konfigureras för att sÀtta i utrymmet. Om anvÀndardelen överensstÀmmer med detta fÀlt för nÄgon av dessa domÀner, kommer anropet att skickas till detta anvÀndarutrymme.
coSpaceSecondaryUriMapping definierar en andra URI för att nÄ utrymmet. Detta kan anvÀndas för att lÀgga till ett numeriskt alias för att styra anrop till det importerade anvÀndarutrymmet som ett alternativ till den alfanumeriska URI som definieras i coSpaceUriMapping-parametern.
LDAP-server och LDAP-mappning Àr konfigurerade. Nu behöver de kopplas samman genom att skapa en LDAP-kÀlla.
Genom att anvÀnda URL-adressen för Ätkomst :445/api/v1/ldapSource skapar vi ett LDAP Source-objekt och angiverar parametrar sÄsom:
- server
- mapping
- baseDn
- filter
Nu nÀr LDAP-installationen Àr klar kan vi utföra en manuell synkronisering.
Vi gör detta antingen i webgrÀnssnittet för varje server genom att trycka pÄ Sync now i avsnittet Active Directory
eller via API med kommandot POST anvÀnda URL-adressen för att fÄ tillgÄng till :445/api/v1/ldapSyncs
Ad-Hoc konferenser
Vad Àr detta?I det traditionella begreppet Àr en konferens nÀr tvÄ deltagare pratar med varandra, och en av deltagarna (som anvÀnder en enhet registrerad i Unified CM) trycker pÄ "Konferens"-knappen, ringer en annan person och efter att ha pratat med denna tredje part trycker pÄ "Konferens"-knappen igen för att gÄ med alla deltagare i trepartskonferensen.
Ad-Hoc konferensen skiljer sig frÄn den schemalagda konferensen i CMS genom att Ad-Hoc konferensen inte bara Àr ett SIP-anrop till CMS. NÀr konferensinitiativet trycker pÄ "Konferens"-knappen en andra gÄng för att bjuda in alla till samma möte, mÄste Unified CM göra ett API-anrop till CMS för att skapa konferensen "on the fly", till vilken alla samtal sedan dirigeras. Allt detta sker osynligt för deltagarna.
Detta innebÀr att Unified CM mÄste konfigurera API-referenser och adress/port för WebAdmin-tjÀnsten, samt SIP-trunk direkt till CMS-servern för att fortsÀtta anropet.
Vid behov kan CUCM dynamiskt skapa utrymmen i CMS sÄ att varje samtal kan nÄ CMS och matcha regeln för inkommande samtal som Àr avsedd för utrymmena.
Integration med CUCM konfigureras pÄ samma sÀtt som beskrivs i artikeln Med undantag för att tre trunkar mÄste skapas för CMS pÄ Cisco UCM, tre Conference Bridges, i SIP Security Profile ange tre Subject Names, Route Group, Route List, Media Resource Group och Media Resource Group List, och i Cisco Meeting Server behöver nÄgra routingregler lÀggas till.
SIP Security Profile:
Trunkar:
Varje trunk ser likadan ut:
Conference Bridge
Varje Conference Bridge ser likadan ut:
Route Group
Route List
Media Resource Group
Media Resource Group List
Ringsregler
Till skillnad frÄn mer avancerade samtalshanteringssystem, sÄsom Unified CM eller Expressway, granskar CMS nya samtal endast domÀnen i SIP Request-URI-fÀltet. Om SIP INVITE Àr avsett för sip:user@domain.com, bryr sig CMS endast om domain.com. CMS följer dessa regler för att avgöra vart samtalet ska riktas:
1. Först försöker CMS matcha SIP-domÀnen med domÀner som Àr konfigurerade i regelsystemet för inkommande samtal. Dessa samtal kan sedan riktas till ('mÄl') utrymmen eller specifika anvÀndare, interna IVR-system eller direkt integrerade mottagare Microsoft Lync/Skype för företag (S4B).
2. Om det inte finns nÄgon matchning i regelsystemet för inkommande samtal, försöker CMS matcha domÀnen som Àr konfigurerad i samtalsomdirigeringstabellen. Om en matchning görs kan regeln uttryckligen avvisa samtalet eller omdirigera samtalet. Vid detta tillfÀlle kan CMS omskriva domÀnen, vilket ibland Àr anvÀndbart för samtal till Lync-domÀner. Du kan ocksÄ vÀlja pass throw, vilket betyder att inga fÀlt kommer att Àndras ytterligare, eller anvÀnda CMS interna abonnentgrupper. Om det inte finns nÄgon matchning i reglerna för samtalsomdirigering anvÀnds som standard avvisning av samtalet. TÀnk pÄ att Àven om samtalet "omdirigeras" i CMS, sÄ Àr multimediatrafik fortfarande kopplad till CMS, vilket betyder att det kommer att vara i signalerings- och multimediatrafikflödet.
DÄ Àr det endast omdirigerade samtal som lyder under reglerna för utgÄende samtal. Dessa alternativ anger mottagarna dit samtal ska skickas, typ av anslutningslinje (om det Àr ett nytt Lync-samtal eller ett standard SIP) och eventuella omvandlingar som kan göras om ingen överföring har valts i regeln för samtalsomdirigering.
HÀr Àr sjÀlva loggen för vad som hÀnder under en Ad-Hoc konferens
PÄ skÀrmdumpen syns det dÄligt (vet inte hur jag ska göra bÀttre), sÄ jag skriver loggen sÄ hÀr:
Info 127.0.0.1:35870: API-anvÀndare "api" skapade nytt utrymme 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info anropet skapades men kunde inte hitta coSpace -- försöker hÀmta frÄn databasen
Info API "001036270012" Utrymme GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 Anrops GUID: 93bfb890-646c-4364-8795-9587bfdc55ba Anropskorrelator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 Intern G
Info 127.0.0.1:35872: API-anvÀndare "api" skapade nytt anrop 93bfb890-646c-4364-8795-9587bfdc55ba
Info anrop 7: inkommande SIP-anrop frÄn "sip:672@172.x.x.x" till lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-anropsben bc0be45e-ce8f-411c-be04-594e0220c38e i anrop 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-anrop 93bfb890-646c-4364-8795-9587bfdc55ba)
Info konferens 434f88d0-8441-41e1-b6ee-6d1c63b5b098 har kontroll/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info konferens 434f88d0-8441-41e1-b6ee-6d1c63b5b098 heter "001036270012"
Info anrop 7: konfigurerad - API-anropsben bc0be45e-ce8f-411c-be04-594e0220c38e med SIP-anrops-ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info anrop 7: stÀller in UDT RTP-session för DTLS (kombinerad media och kontroll)
Info konferens "001036270012": oÄtskyddade anropsben nu nÀrvarande
Info deltagare "672@172.x.x.x" gick med i utrymme 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltagare "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) gick med i konferens 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info anrop 8: inkommande SIP-anrop frÄn "sip:690@172.x.x.x" till lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-anropsben db61b242-1c6f-49bd-8339-091f62f5777a i anrop 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-anrop 93bfb890-646c-4364-8795-9587bfdc55ba)
Info anrop 8: konfigurerad - API-anropsben db61b242-1c6f-49bd-8339-091f62f5777a med SIP-anrops-ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info anrop 8: stÀller in UDT RTP-session för DTLS (kombinerad media och kontroll)
Info anrop 9: inkommande SIP-anrop frÄn "sip:673@172.x.x.x" till lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-anropsben 37a6e86d-d457-47cf-be24-1dbe20ccf98a i anrop 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-anrop 93bfb890-646c-4364-8795-9587bfdc55ba)
Info anrop 9: konfigurerad - API-anropsben 37a6e86d-d457-47cf-be24-1dbe20ccf98a med SIP-anrops-ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info anrop 9: stÀller in UDT RTP-session för DTLS (kombinerad media och kontroll)
Info anrop 8: kompenserar för att det fjÀrrade slutet inte matchar payload-typer
Info deltagare "690@172.x.x.x" gick med i utrymme 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltagare "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) gick med i konferens 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info anrop 7: kompenserar för att det fjÀrrade slutet inte matchar payload-typer
Info anrop 8: icke-matching payload-typer lÀge 1/0
Info anrop 8: svarar pÄ erbjudande i icke-matching payload-typer lÀge
Info anrop 8: uppföljande erbjudande för enstaka codec mottaget
Info anrop 8: icke-matching payload-typer lÀge 1/0
Info anrop 8: svarar pÄ erbjudande i icke-matching payload-typer lÀge
Info anrop 8: skickar svar pÄ enstaka codec ytterligare erbjudande
Info anrop 9: kompenserar för att det fjÀrrade slutet inte matchar payload-typer
Info deltagare "673@172.x.x.x" gick med i utrymme 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltagare "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) gick med i konferens 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info anrop 9: BFCP (klientroll) nu aktiv
Info anrop 9: skickar BFCP hello som klient efter att ha mottagit hello nÀr BFCP inte var aktiv
Info anrop 9: BFCP (klientroll) nu aktiv
Info anrop 7: avslutar; avlÀgsen SIP-teardown - ansluten i 0:13
Info anrop 7: förstör API-anropsben bc0be45e-ce8f-411c-be04-594e0220c38e
Info deltagare "672@x.x.x" lÀmnade utrymme 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info anrop 9: pÄ hÄll
Info anrop 9: icke-matching payload-typer lÀge 1/0
Info anrop 9: svarar pÄ erbjudande i icke-matching payload-typer lÀge
Info anrop 8: pÄ hÄll
Info anrop 8: uppföljande erbjudande för enstaka codec mottaget
Info anrop 8: icke-matching payload-typer lÀge 1/0
Info anrop 8: svarar pÄ erbjudande i icke-matching payload-typer lÀge
Info anrop 8: skickar svar pÄ enstaka codec ytterligare erbjudande
Info anrop 9: avslutar; avlÀgsen SIP-teardown - ansluten i 0:12SjÀlva Ad-Hoc konferensen:
Regler för inkommande samtal
InstÀllning av parametrar för inkommande samtal Àr nödvÀndig för att möjliggöra mottagande av samtal i CMS. Som du har sett i LDAP-instÀllningen har alla anvÀndare importerats med domÀnen conf.pod6.cms.lab. DÀrför vill du Ätminstone att samtal till denna domÀn Àr avsedda för utrymmen. Du mÄste ocksÄ stÀlla in regler för allt som Àr avsett för det fullstÀndiga domÀnnamnet (och kanske till och med för IP-adressen) för varje av CMS-servrarna. I vÄr externa samtalskontroll, Unified CM, kommer SIP-trunkar att konfigureras för varje CMS-server individuellt. Beroende pÄ om destinationen för dessa SIP-trunkar Àr en IP-adress eller det fullstÀndiga domÀnnamnet för servern kommer att avgöra om CMS mÄste konfigureras för att ta emot samtal som Àr riktade till dess IP-adress eller fullstÀndiga domÀnnamn.
DomÀnen med regeln för inkommande trafik med högst prioritet anvÀnds som domÀn för alla anvÀndarutrymmen. NÀr anvÀndare synkroniseras via LDAP, skapar CMS automatiskt utrymmen, men endast den anvÀndardel av URI (coSpaceUriMapping), till exempel user.space. Delen av den fullstÀndiga URI skapas baserat pÄ denna regel. Faktiskt, om du skulle logga in pÄ Web Bridge vid det hÀr steget skulle du se att utrymmets URI inte har nÄgot domÀn. Genom att ange denna regel som högsta prioritet sÀtter du domÀnen för de genererade utrymmena som conf.example.com.
Regler för utgÄende samtal
För att tillÄta anvÀndare att göra utgÄende samtal till Unified CM-klustret mÄste regler för utgÄende anslutningar konfigureras. DomÀnen för slutpunkterna som Àr registrerade i Unified CM, sÄsom Jabber, Àr example.com. Samtal till denna domÀn bör dirigeras som standard SIP-samtal till behandlingsnoderna i Unified CM. Som primÀr server fungerar cucm-01.example.com och som sekundÀr cucm-02.example.com.
Den första regeln beskriver den enklaste samtalsruttningen mellan servrarna i klustret.
FÀltet Local from domain ansvarar för vad som kommer att visas i SIP-URI:n för den som ringer nÀr de ringer efter symbolen «@». Om vi lÀmnar det tomt, kommer det efter symbolen «@» att vara IP-adressen för CUCM genom vilken samtalet gÄr. Om vi anger en domÀn kommer domÀnen att visas efter symbolen «@». Detta behövs för att möjliggöra att ringa tillbaka, annars skulle det vara omöjligt att ringa tillbaka pÄ SIP-URI namn@ip-adress.
Samtal nÀr det anges Local from domain
Samtal nÀr INTE Àr angivet Local from domain
Se till att ange Entcrypted eller Unencrypted för utgÄende samtal, för med parametern Auto fungerar ingenting.
Inspelning
Inspelning av videokonferenser görs av Record-servern. Recorder Àr exakt samma som Cisco Meeting Server. Recorder krÀver inga licenser pÄ sig sjÀlv. Licenser för inspelning krÀvs för servrar pÄ vilka CallBridge-tjÀnsterna körs, dvs. licensen Recording mÄste tillÀmpas pÄ CallBridge-komponenten, och inte pÄ servern dÀr Recorder körs. Recorder fungerar som en klient för det utbyggda protokollet för meddelandeutbyte och nÀrvaro (XMPP), sÄ XMPP-servern mÄste vara aktiverad pÄ servern dÀr CallBridge Àr placerad.
Eftersom vi har en kluster och licensen mÄste "strÀckas" över alla tre servrar i klustret. SÄ i vÄrt personliga konto associerar vi (lÀgger till) MAC-adresserna för a-grÀnssnitten pÄ alla CMS-servrar som ingÄr i klustret.
Och sÄ hÀr bör det se ut pÄ varje server i klustret
Det finns faktiskt flera scenarier för placering av Recorder, men vi kommer att hÄlla oss till följande:
Innan du konfigurerar Recorder behöver du förbereda en plats dit videokonferenserna kommer att spelas in. SÄ hÀr , hur man konfigurerar hela inspelningen. Jag kommer att fokusera pÄ viktiga ögonblick och detaljer:
1. Det Àr bÀttre att anvÀnda certifikatet frÄn den första servern i klustret.
2. Felet "Recorder unavailable" kan uppstÄ pÄ grund av att fel certifikat angivits i Recorder Trust.
3. Inspelningen kanske inte fungerar om en icke-root katalog har angetts i NFS för inspelning.
Ibland finns det behov av att automatiskt spela in konferensen för en specifik anvÀndare eller ett space.
För detta skapas tvÄ CallProfile:
Med avstÀngd inspelningsfunktion
Och med automatisk inspelningsfunktion
DÀrefter "kopplas" CallProfile med automatisk inspelningsfunktion till det önskade space:t.
I CMS Àr det sÄ att om en CallProfile Àr tydligt kopplad till nÄgot eller nÄgra space, sÄ fungerar den hÀr CallProfile endast för dessa specifika space. Om CallProfile inte Àr kopplad till nÄgot space, sÄ tillÀmpas den som standard pÄ de space dÀr ingen CallProfile Àr specifikt kopplad.
NÀsta gÄng ska jag försöka beskriva pÄ vilka sÀtt man fÄr Ätkomst till CMS utanför organisationens interna nÀtverk.
KĂ€llor:
KĂ€lla: habr.com
