Yn dit nûmer sil ik guon fan 'e kompleksjes sjen litte en ferklearje fan it ynstellen fan in CMS-tsjinner yn failover-klustermodus.
TeoryYn 't algemien binne d'r trije soarten CMS-tsjinner-ynset:
- Single kombinearre(Single kombinearre), d.w.s. dit is ien tsjinner wêrop alle nedige tsjinsten rinne. Yn 'e measte gefallen is dit type ynset allinich geskikt foar ynterne kliïnt tagong en yn lytsere omjouwings wêr't de skalberens en redundânsjebeheiningen fan in inkele tsjinner gjin kritysk probleem binne, of yn situaasjes wêr't it CMS allinich bepaalde funksjes útfiert, lykas ad hoc konferinsjes oer Cisco UCM.
Approximate skema fan wurk:
- Single Split(Single Split) wreidet it foarige ynsettype út troch in aparte tsjinner ta te foegjen foar eksterne tagong. Yn legacy ynset betsjutte dit it ynsetten fan in CMS-tsjinner yn in demilitarisearre netwurksegment (DMZ) wêr't eksterne kliïnten tagong koenen, en ien CMS-tsjinner yn 'e netwurkkearn wêr't ynterne kliïnten tagong koenen krije ta de CMS. Dit bysûndere ynsetmodel wurdt no ferfongen troch it saneamde type Single Edge, dy't bestiet út tsjinners Cisco Expressway.
Approximate skema fan wurk:
- Scalable en Resilient(Skaalber en fouttolerant) Dit type omfettet oerstalligens foar elke komponint, wêrtroch it systeem kin groeie mei jo behoeften nei syn maksimale kapasiteit, wylst it oerstallich leveret yn gefal fan mislearring. It brûkt ek it Single Edge-konsept om feilige eksterne tagong te jaan. Dit is it type dat wy sille sjen yn dizze ôflevering. As wy begripe hoe't jo dit soarte kluster ynsette, sille wy net allinich oare soarten ynset begripe, mar wy sille ek kinne begripe hoe't jo klusters fan CMS-tsjinners kinne oanmeitsje om potinsjele groei yn fraach te foldwaan.
Foardat jo trochgean mei ynset, moatte jo wat basis dingen begripe, nammentlik
Main CMS software komponinten:
- Databank: Hjirmei kinne jo guon konfiguraasjes kombinearje, lykas kiesplan, brûkersromten en brûkers sels. Unterstützt allinich klustering foar hege beskikberens (single master).
- Call Bridge: in tsjinst foar audio- en fideokonferinsjes dy't folsleine kontrôle leveret oer it behear en ferwurkjen fan petearen en multimediaprosessen. Unterstützt klustering foar hege beskikberens en skalberens.
- XMPP tsjinner: ferantwurdlik foar registraasje en autentikaasje fan kliïnten mei help fan de Cisco Meeting Application en/of WebRTC(realtime kommunikaasje, of gewoan yn 'e browser), likegoed as intercomponent signaling. Kin allinnich wurde klustere foar hege beskikberens.
- Web Bridge: Biedt klant tagong ta WebRTC.
- Loadbalancer: Jout in inkele ferbining punt foar Cisco Meeting Apps yn Single Split modus. Harket nei de eksterne ynterface en haven foar ynkommende ferbinings. Likegoed aksepteart de loadbalancer ynkommende TLS-ferbiningen fan 'e XMPP-tsjinner, wêrtroch it TCP-ferbiningen kin wikselje fan eksterne kliïnten.
Yn ús senario sil it net nedich wêze. - TURN tsjinner: Biedt Firewall bypass technology dat makket it mooglik
pleats ús CMS efter in Firewall of NAT om eksterne kliïnten te ferbinen mei Cisco Meeting App of SIP-apparaten. Yn ús senario sil it net nedich wêze. - Web Admin: Bestjoerlike ynterface en API-tagong, ynklusyf foar spesjale Unified CM-konferinsjes.
Konfiguraasje Modes
Oars as de measte oare Cisco-produkten, stipet Cisco Meeting Server trije konfiguraasjemetoaden om elk type ynset te foldwaan.
- Kommandorigel (CLI): Kommandorigelynterface bekend as MMP foar earste konfiguraasje- en sertifikaattaken.
- Webbehearder: Foaral foar CallBridge-relatearre konfiguraasjes, benammen by it ynstellen fan in inkele net-klustere tsjinner.
- REST API: Wurdt brûkt foar de meast komplekse konfiguraasjetaken en klustere databankrelatearre taken.
Neist it boppesteande wurdt it protokol brûkt SFTP om bestannen oer te bringen - normaal lisinsjes, sertifikaten of logs - nei en fan 'e CMS-tsjinner.
Yn ynsetgidsen fan Cisco stiet yn wyt en Ingelsk dat it kluster ynset wurde moat op syn minst trije tsjinners (knooppunten) yn 'e kontekst fan databases. Omdat Allinnich mei in ûneven oantal knopen sil it meganisme foar it selektearjen fan in nije Database Master wurkje, en yn 't algemien hat de Database Master in ferbining mei de measte fan' e CMS-tsjinnerdatabase.
En as praktyk toant, binne twa servers (knooppunten) echt net genôch. It seleksjemeganisme wurket as de Master opnij wurdt opstart, de Slave-tsjinner wurdt allinich Master nei't de opnij opstarte tsjinner opbrocht is. As lykwols yn in kluster fan twa tsjinners de Master-tsjinner ynienen útgiet, dan sil de Slave-tsjinner net de Master wurde, en as de Slave útgiet, dan sil de oerbleaune Master-tsjinner de Slave wurde.
Mar yn 'e kontekst fan XMPP soe it echt nedich wêze om in kluster fan trije servers te sammeljen, om't as jo bygelyks de XMPP-tsjinst útskeakelje op ien fan 'e servers wêryn XMMP yn Leader-status is, dan sil XMPP op' e oerbleaune tsjinner yn Follower-status bliuwe en CallBridge-ferbiningen nei XMPP falle ôf, om't CallBridge ferbynt eksklusyf mei XMPP mei Leader-status. En dit is kritysk, om't ... net ien oprop sil gean troch.
Ek yn deselde ynsetgidsen wurdt in kluster mei ien XMPP-tsjinner oantoand.
En mei it each op it boppesteande wurdt it dúdlik wêrom: it wurket om't it yn failover-modus is.
Yn ús gefal sil de XMPP-tsjinner oanwêzich wêze op alle trije knooppunten.
It wurdt oannommen dat alle trije fan ús tsjinners binne up.
DNS records
Foardat jo begjinne mei it ynstellen fan servers, moatte jo DNS-records oanmeitsje А и SRV soarten:
Tink derom dat yn ús DNS-records d'r twa domeinen binne example.com en conf.example.com. Example.com is in domein dat alle Cisco Unified Communication Manager-abonnees kinne brûke foar har URI's, dy't nei alle gedachten oanwêzich is yn jo ynfrastruktuer of wierskynlik oanwêzich is. Of example.com komt oerien mei itselde domein dat brûkers brûke foar har e-mailadressen. Of de Jabber-client op jo laptop kin in URI hawwe [e-post beskerme]. Domein conf.example.com is it domein dat sil wurde konfigurearre foar Cisco Meeting Server brûkers. It domein fan 'e Cisco Meeting Server sil wêze conf.example.com, dus foar deselde Jabber-brûker soe de brûker@ URI moatte wurde brûkt om oan te melden by Cisco Meeting Serverconf.example.com.
Basis konfiguraasje
Alle hjirûnder beskreaune ynstellingen wurde werjûn op ien tsjinner, mar se moatte dien wurde op elke tsjinner yn it kluster.
QoS
Sûnt de CMS generearret Echt-tiid ferkear gefoelich foar fertraging en pakket ferlies, yn de measte gefallen is it oan te rieden om te konfigurearjen kwaliteit fan tsjinst (QoS). Om dit te berikken, stipet de CMS taggingpakketten mei de Differentiated Services Codes (DSCP's) dy't it genereart. Hoewol DSCP-basearre ferkearsprioritearring hinget ôf fan hoe't it ferkear ferwurke wurdt troch de netwurkkomponinten fan jo ynfrastruktuer, yn ús gefal sille wy ús CMS konfigurearje mei typyske DSCP-prioritearring basearre op QoS best practices.
Op elke tsjinner sille wy dizze kommando's ynfiere
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ASa waard alle fideoferkear markearre AF41 (DSCP 0x22), alle stimferkear waard markearre EF (DSCP 0x2E), oare soarten ferkearsferkear mei lege latency lykas SIP en XMPP brûke AF31 (DSCP 0x1A).
Wy kontrolearje:
NTP
Network Time Protocol (NTP) is wichtich net allinich foar it leverjen fan krekte tiidstempels fan petearen en konferinsjes, mar ek foar it ferifiearjen fan sertifikaten.
Foegje NTP-tsjinners ta oan jo ynfrastruktuer mei in kommando lykas
ntp server add <server>
Yn ús gefal binne d'r twa fan sokke tsjinners, dus d'r sille twa teams wêze.
Wy kontrolearje:
En set de tiidsône foar ús tsjinner yn
DNS
Wy foegje DNS-tsjinners ta oan it CMS mei in kommando lykas:
dns add forwardzone <domain-name> <server ip>
Yn ús gefal binne d'r twa fan sokke tsjinners, dus d'r sille twa teams wêze.
Wy kontrolearje:
Netwurk ynterface konfiguraasje
Wy konfigurearje de ynterface mei in kommando lykas:
ipv4 <interface> add <address>/<prefix length> <gateway>
Wy kontrolearje:
Tsjinnernamme (Hostnamme)
Wy sette de servernamme yn mei in kommando lykas:
hostname <name>
En wy rebootje.
Dit foltôget de basiskonfiguraasje.
Sertifikaten
TeoryCisco Meeting Server fereasket fersifere kommunikaasje tusken ferskate komponinten, en as gefolch binne X.509-sertifikaten nedich foar alle CMS-ynset. Se helpe derfoar te soargjen dat de tsjinsten / tsjinner wurdt fertroud troch oare tsjinners / tsjinsten.
Elke tsjinst fereasket in sertifikaat, mar it meitsjen fan aparte sertifikaten foar elke tsjinst kin liede ta betizing en ûnnedige kompleksiteit. Gelokkich kinne wy it publyk-privee kaaipaar fan in sertifikaat generearje en se dan opnij brûke oer meardere tsjinsten. Yn ús gefal sil itselde sertifikaat brûkt wurde foar Call Bridge, XMPP Server, Web Bridge en Web Admin. Sa moatte jo in pear iepenbiere en privee sertifikaatkaaien meitsje foar elke server yn it kluster.
Databankklustering hat lykwols wat spesjale sertifikaateasken en fereasket dêrom eigen sertifikaten dy't ferskille fan dy fan 'e oare tsjinsten. CMS brûkt in tsjinner sertifikaat, dat is gelyk oan de sertifikaten brûkt troch oare tsjinners, mar der is ek in kliïnt sertifikaat brûkt foar database ferbinings. Databanksertifikaten wurde brûkt foar sawol autentikaasje as fersifering. Ynstee fan it jaan fan in brûkersnamme en wachtwurd foar de kliïnt om te ferbinen mei de databank, presintearret it in kliïntsertifikaat dat fertroud wurdt troch de tsjinner. Elke tsjinner yn it databankkluster sil itselde iepenbiere en privee kaaipear brûke. Hjirmei kinne alle servers yn it kluster gegevens op sa'n manier fersiferje dat se allinich ûntsifere wurde kinne troch oare servers dy't ek itselde kaaipaar diele.
Om oerstalligens te wurkjen moatte databankklusters bestean út minimaal 3 tsjinners, mar net mear as 5, mei in maksimale rûnreistiid fan 200 ms tusken alle klusterleden. Dizze limyt is beheiner as foar Call Bridge-klustering, dus it is faaks de beheinende faktor yn geografysk ferspraat ynset.
De databankrol foar in CMS hat in oantal unike easken. Oars as oare rollen fereasket it in kliïnt- en serversertifikaat, wêrby't it kliïntsertifikaat in spesifyk CN-fjild hat dat wurdt presintearre oan de tsjinner.
De CMS brûkt in postgres-database mei ien master en ferskate folslein identike replika's. D'r is mar ien primêre databank tagelyk (de "databanktsjinner"). De oerbleaune leden fan it kluster binne replika's as "databasekliïnten".
In databankkluster fereasket in tawijd serversertifikaat en in kliïntsertifikaat. Se moatte wurde tekene troch sertifikaten, meastentiids in ynterne privee sertifikaatautoriteit. Om't elk lid fan 'e databankkluster de master wurde kin, moatte de databaseserver- en kliïntsertifikaatpearen (mei de publike en partikuliere kaaien) kopiearre wurde nei alle servers sadat se de identiteit fan 'e client of databanktsjinner kinne oannimme. Derneist moat it CA-rootsertifikaat laden wurde om te soargjen dat de kliïnt- en serversertifikaten kinne wurde ferifiearre.
Dat, wy meitsje in fersyk foar in sertifikaat dat sil wurde brûkt troch alle servertsjinsten útsein de databank (d'r sil in apart fersyk foar wêze) mei in kommando lykas:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Yn CN skriuwe wy de algemiene namme fan ús servers. Bygelyks, as de hostnammen fan ús servers tsjinner 01, tsjinner 02, tsjinner 03, dan sil CN wêze server.example.com
Wy dogge itselde op 'e oerbleaune twa servers mei it ferskil dat de kommando's de oerienkommende "hostnammen" sille befetsje
Wy generearje twa oanfragen foar sertifikaten dy't sille wurde brûkt troch de databanktsjinst mei kommando's lykas:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreswêr dbclusterserver и dbclusterclient nammen fan ús oanfragen en takomstige sertifikaten, hostnamme1(2)(3) nammen fan de oerienkommende tsjinners.
Wy fiere dizze proseduere allinnich op ien tsjinner (!), En wy sille uploade de sertifikaten en oerienkommende .key triemmen oan oare tsjinners.
Aktivearje client sertifikaat modus yn AD CS
Jo moatte ek de sertifikaten foar elke server gearfoegje yn ien bestân.Op *NIX:
cat server01.cer server02.cer server03.cer > server.cerOp Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
En upload nei elke server:
1. "Yndividueel" tsjinner sertifikaat.
2. Root sertifikaat (tegearre mei tuskenlizzende, as ien).
3. Sertifikaten foar de databank ("server" en "client") en bestannen mei de .key-útwreiding, dy't waarden oanmakke by it meitsjen fan in fersyk foar de "server" en "client" databanksertifikaten. Dizze bestannen moatte itselde wêze op alle servers.
4. Triem fan alle trije "yndividuele" sertifikaten.
As resultaat moatte jo sa'n bestânôfbylding krije op elke server.
Databank Cluster
No't jo alle sertifikaten hawwe uploaden nei de CMS-tsjinners, kinne jo database-klustering tusken de trije knopen ynstelle en ynskeakelje. De earste stap is om ien tsjinner te selektearjen as de masterknooppunt fan it databankkluster en it folslein te konfigurearjen.
Master Database
De earste stap by it ynstellen fan database-replikaasje is om de sertifikaten oan te jaan dy't sille wurde brûkt foar de databank. Dit wurdt dien mei in kommando lykas:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Litte wy no de CMS fertelle hokker ynterface te brûken foar database-klusterjen mei it kommando:
database cluster localnode aDan inisjalisearje wy de klusterdatabase op 'e haadtsjinner mei it kommando:
database cluster initialize
Client Database Nodes
Wy dogge deselde proseduere, allinich ynstee fan it kommando database kluster inisjalisearje fier in kommando yn lykas:
database cluster join <ip address existing master>wêr ip adres besteande master ip adres fan de CMS tsjinner dêr't it kluster waard inisjalisearre, gewoan Master.
Wy kontrolearje hoe't ús databankkluster wurket op alle servers mei it kommando:
database cluster status
Wy dogge itselde op 'e oerbleaune tredde tsjinner.
As gefolch, it docht bliken dat ús earste tsjinner is de Master, de rest binne Slaven.
Web Admin Service
Aktivearje de tsjinst foar webbehearder:
webadmin listen a 445Poarte 445 waard keazen om't poarte 443 brûkt wurdt foar brûkers tagong ta de webclient
Wy konfigurearje de Web Admin-tsjinst mei sertifikaatbestannen mei in kommando lykas:
webadmin certs <keyfile> <certificatefile> <ca bundle>En ynskeakelje Web Admin mei it kommando:
webadmin enable
As alles goed is, sille wy SUCCESS-rigels ûntfange dy't oanjaan dat Web Admin goed is ynsteld foar it netwurk en sertifikaat. Wy kontrolearje de funksjonaliteit fan 'e tsjinst mei in webblêder en fier it adres fan' e webbehearder yn, bygelyks: : 445
Call Bridge Cluster
Call Bridge is de ienige tsjinst oanwêzich yn elke CMS-ynset. Call Bridge is it wichtichste konferinsjemeganisme. It jout ek in SIP ynterface sadat petearen kinne wurde trochstjoerd nei of fan it troch bygelyks in Cisco Unified CM.
De hjirûnder beskreaune kommando's moatte wurde útfierd op elke server mei de passende sertifikaten.
Dus:
Wy assosjearje sertifikaten mei de Call Bridge-tsjinst mei in kommando lykas:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Wy bine CallBridge-tsjinsten oan de ynterface dy't wy nedich binne mei it kommando:
callbridge listen aEn start de tsjinst opnij mei it kommando:
callbridge restart
No't wy ús Call Bridges konfigureare hawwe, kinne wy Call Bridge-klustering konfigurearje. Call Bridge-klustering is oars as database- as XMPP-klustering. Call Bridge Cluster kin stypje fan 2 oant 8 knopen sûnder beheiningen. It soarget net allinnich oerstallich, mar ek load balancing sadat konferinsjes kinne wurde aktyf ferdield oer Call Bridge tsjinners mei help fan yntelliginte oprop distribúsje. It CMS hat ekstra funksjes, Call Bridge-groepen en relatearre funksjes dy't brûkt wurde kinne foar fierdere behear.
Opropbrêge-klustering wurdt primêr konfigureare fia de webadmin-ynterface
De hjirûnder beskreaune proseduere moat wurde útfierd op elke server yn it kluster.
En sa,
1. Gean fia it web nei Konfiguraasje> Cluster.
2.In Call Bridge identiteit Fier as unike namme callbridge[01,02,03] yn dy't oerienkomt mei de servernamme. Dizze nammen binne willekeurich, mar moatte unyk wêze foar dit kluster. Se binne beskriuwend fan aard om't se oanjaan dat se serveridentifikatoren binne [01,02,03].
3.B Clustered Call Bridges Fier de webbehearder URL's fan ús servers yn yn it kluster, [01,02,03].example.com:445, yn it adresfjild. Soargje derfoar dat jo de haven oantsjutte. Jo kinne Peer link SIP-domein leech litte.
4. Foegje in sertifikaat ta oan it CallBridge-trust fan elke server, wêrfan it bestân alle sertifikaten fan ús servers befettet, dy't wy oan it begjin yn dit bestân fusearre hawwe, mei in kommando lykas:
callbridge trust cluster <trusted cluster certificate bundle>En start de tsjinst opnij mei it kommando:
callbridge restart
As resultaat moatte jo op elke server dizze foto krije:
XMPP Cluster
De XMPP-tsjinst yn 'e CMS wurdt brûkt om alle registraasje en autentikaasje te behanneljen foar Cisco Meeting Apps (CMA), ynklusyf de CMA WebRTC-webkliïnt. De Call Bridge sels fungearret ek as in XMPP-kliïnt foar autentikaasjedoelen en moat dêrom wurde konfigureare as oare kliïnten. XMPP-fouttolerânsje is in funksje dy't sûnt ferzje 2.1 is stipe yn produksjeomjouwings
De hjirûnder beskreaune kommando's moatte wurde útfierd op elke server mei de passende sertifikaten.
Dus:
Wy assosjearje sertifikaten mei de XMPP-tsjinst mei in kommando lykas:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Definiearje dan de harkerynterface mei it kommando:
xmpp listen aDe XMPP-tsjinst fereasket in unyk domein. Dit is de oanmelding foar brûkers. Mei oare wurden, as in brûker besiket oan te melden mei de CMA-app (of fia de WebRTC-kliïnt), fiere se userID@logindomein yn. Yn ús gefal sil it userid@ wêzeconf.example.com. Wêrom is it net gewoan example.com? Yn ús bysûndere ynset hawwe wy ús Unified CM-domein selekteare dat Jabber-brûkers sille brûke yn Unified CM as example.com, dus wy hiene in oar domein nedich foar CMS-brûkers om petearen nei en fan 'e CMS te routeren fia SIP-domeinen.
Stel in XMPP-domein yn mei in kommando lykas:
xmpp domain <domain>En ynskeakelje de XMPP-tsjinst mei it kommando:
xmpp enableYn 'e XMPP-tsjinst moatte jo bewiisbrieven oanmeitsje foar elke Call Bridge dy't sil wurde brûkt by registraasje by de XMPP-tsjinst. Dizze nammen binne willekeurich (en binne net besibbe oan de unike nammen dy't jo ynsteld hawwe foar opropbrêgeklustering). Jo moatte trije opropbrêgen taheakje op ien XMPP-tsjinner en dan dy referinsjes op oare XMPP-tsjinners yn it kluster ynfiere, om't dizze konfiguraasje net past yn 'e klusterdatabase. Letter sille wy elke Call Bridge konfigurearje om dizze namme en geheim te brûken om te registrearjen by de XMPP-tsjinst.
No moatte wy de XMPP-tsjinst konfigurearje op 'e earste server mei trije Call Bridges callbridge01, callbridge02 en callbridge03. Elk akkount sil willekeurige wachtwurden wurde tawiisd. Se sille letter wurde ynfierd op oare Call Bridge-tsjinners om oan te melden by dizze XMPP-tsjinner. Fier de folgjende kommando's yn:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03As resultaat kontrolearje wy wat der bard is mei it kommando:
xmpp callbridge list
Krekt deselde ôfbylding moat ferskine op 'e oerbleaune servers nei de stappen hjirûnder beskreaun.
Dêrnei foegje wy krekt deselde ynstellings ta op de oerbleaune twa servers, allinich mei de kommando's
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Wy foegje Geheim hiel foarsichtich ta sadat der bygelyks gjin ekstra spaasjes yn sitte.
As resultaat moat elke server deselde ôfbylding hawwe:
Folgjende, op alle servers yn it kluster, spesifisearje wy yn fertrouwen it bestân dat alle trije sertifikaten befettet, earder makke mei in kommando lykas dit:
xmpp cluster trust <trust bundle>Wy aktivearje xmpp-klustermodus op alle klusterservers mei it kommando:
xmpp cluster enableOp de earste tsjinner fan it kluster begjinne wy it meitsjen fan in xmpp-kluster mei it kommando:
xmpp cluster initializeFoegje op oare servers in kluster ta oan xmpp mei in kommando lykas:
xmpp cluster join <ip address head xmpp server>Wy kontrolearje op elke server it sukses fan it meitsjen fan in XMPP-kluster op elke server mei de kommando's:
xmpp status
xmpp cluster statusEarste tsjinner:
Twadde tsjinner:
Tredde tsjinner:
Call Bridge ferbine mei XMPP
No't it XMPP-kluster rint, moatte jo de Call Bridge-tsjinsten ynstelle om te ferbinen mei it XMPP-kluster. Dizze konfiguraasje wurdt dien fia de webadmin.
Gean op elke tsjinner nei Konfiguraasje> Algemien en yn it fjild Unike Call Bridge namme skriuw unike nammen dy't oerienkomme mei de tsjinner Call Bridge callbridge[01,02,03]... Yn fjild domein conf.example.ru en byhearrende wachtwurden, kinne jo bispiede op harren
op elke server yn it kluster mei it kommando:
xmpp callbridge list
Lit it fjild "Tsjinner" leech Callbridge sil in DNS SRV sykje foar _xmpp-component._tcp.conf.example.comom in beskikbere XMPP-tsjinner te finen. De IP-adressen foar it ferbinen fan callbridges nei XMPP kinne ferskille op elke server, it hinget ôf fan hokker wearden wurde weromjûn oan it rekordfersyk _xmpp-component._tcp.conf.example.com callbridge, dy't op syn beurt hinget ôf fan de prioriteit ynstellings foar in opjûne DNS record.
Gean dan nei Status> Algemien om te kontrolearjen oft de tsjinst Call Bride mei súkses ferbûn is mei de XMPP-tsjinst.
Web Bridge
Op elke server yn it kluster, ynskeakelje de Web Bridge-tsjinst mei it kommando:
webbridge listen a:443Wy konfigurearje de Web Bridge-tsjinst mei sertifikaatbestannen mei in kommando lykas:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge stipet HTTPS. It sil HTTP omliede nei HTTPS as ynsteld om "http-redirect" te brûken.
Om HTTP-omlieding yn te skeakeljen, brûk it folgjende kommando:
webbridge http-redirect enableOm Call Bridge te litten witte dat Web Bridge ferbiningen fan Call Bridge kin fertrouwe, brûk it kommando:
webbridge trust <certfile>wêr't dit in bestân is mei alle trije sertifikaten fan elke tsjinner yn it kluster.
Dizze foto moat op elke server yn it kluster stean.
No moatte wy in brûker meitsje mei de rol "appadmin", wy hawwe it nedich sadat wy ús kluster(!) kinne konfigurearje, en net elke tsjinner yn it kluster apart, op dizze manier wurde de ynstellings lykwols op elke tsjinner tapast nettsjinsteande de feit dat se sille wurde makke ien kear.
Foar fierdere opset sille wy brûke .
Foar autorisaasje, selektearje Basis yn 'e Autorisaasje seksje
Om kommando's korrekt nei de CMS-tsjinner te stjoeren, moatte jo de fereaske kodearring ynstelle
Wy spesifisearje Webbridge mei it kommando PEAL mei parameter url en betsjutting
Yn 'e webbridge sels jouwe wy de fereaske parameters oan: gast tagong, beskerme tagong, ensfh.
Call Bridge Groups
Standert makket it CMS net altyd it effisjintste gebrûk fan de beskikbere konferinsjeboarnen.
Bygelyks, foar in gearkomste mei trije dielnimmers kin elke dielnimmer op trije ferskillende Call Bridges einigje. Om dizze trije dielnimmers mei-inoar te kommunisearjen, sil Call Bridges automatysk ferbiningen meitsje tusken alle tsjinners en kliïnten yn deselde romte, sadat it allegear liket as binne alle kliïnten op deselde tsjinner. Spitigernôch is it neidiel hjirfan dat in inkele konferinsje fan 3 persoanen no 9 mediaports sil konsumearje. Dit is fansels in net effisjint gebrûk fan middels. Derneist, as in Call Bridge wirklik oerladen is, is it standertmeganisme om troch te gean mei it akseptearjen fan petearen en leverjen fan fermindere kwaliteitstsjinst oan alle abonnees fan dy Call Bridge.
Dizze problemen wurde oplost mei de funksje Call Bridge Group. Dizze funksje waard yntrodusearre yn ferzje 2.1 fan Cisco Meeting Server software en is útwreide om load balancing te stypjen foar sawol ynkommende as útgeande Cisco Meeting App (CMA) petearen, ynklusyf WebRTC dielnimmers.
Om it probleem fan 'e opnij ferbining op te lossen, binne trije ynstelbere loadgrinzen yntrodusearre foar elke Call Bridge:
LoadLimit - dit is de maksimale numerike lading foar in bepaalde Call Bridge. Elk platfoarm hat in oanrikkemandearre loadlimyt, lykas 96000 foar de CMS1000 en 1.25 GHz per vCPU foar de firtuele masine. Ferskillende oproppen konsumearje in bepaalde hoemannichte boarnen ôfhinklik fan 'e resolúsje en framerate fan' e dielnimmer.
NewConferenceLoadLimitBasisPoints (standert 50% loadLimit) - stelt de tsjinner load limyt, wêrnei't nije konferinsjes wurde ôfwiisd.
Besteande ConferenceLoadLimitBasisPoints (standert 80% fan loadLimit) - de tsjinner load wearde wêrnei't dielnimmers dy't meidwaan oan in besteande konferinsje wurde ôfwiisd.
Wylst dizze funksje is ûntwurpen foar oprop distribúsje en load balancing, kinne oare groepen lykas TURN Servers, Web Bridge Servers en Recorders ek wurde tawiisd oan Call Bridge Groups sadat se ek kinne wurde goed groepearre foar optimaal gebrûk. As ien fan dizze objekten binne net tawiisd oan in oprop groep, se wurde oannommen dat se beskikber binne foar alle tsjinners sûnder in bepaalde prioriteit.
Dizze parameters wurde hjir konfigureare: :445/api/v1/system/configuration/cluster
Dêrnei jouwe wy oan elke callbridge oan hokker callbridge-groep it heart:
Earste callbridge
Twadde callbridge
Tredde callbridge
Sa hawwe wy de Call Brdige-groep konfigureare om de boarnen fan it Cisco Meeting Server-kluster effisjinter te brûken.
Brûkers ymportearje fan Active Directory
De Web Admin tsjinst hat in LDAP konfiguraasje seksje, mar it jout gjin komplekse konfiguraasje opsjes, en de ynformaasje wurdt net opslein yn de kluster databank, dus konfiguraasje sil dien wurde moatte, itsij mei de hân op elke tsjinner fia de web ynterface, of fia de API, en sadat wy "trije kear "Net opstean" sille wy noch ynstelle de gegevens fia de API.
URL brûke om tagong te krijen :445/api/v1/ldapServers meitsje in LDAP-tsjinner-objekt, mei parameters oantsjutte lykas:
- Server IP
- havennûmer
- Brûkersnamme
- wachtwurd
- feilich
Feilich - selektearje wier of falsk ôfhinklik fan de haven, 389 - net feilich, 636 - beskerme.
Mapping LDAP boarne parameters oan attributen yn Cisco Meeting Server.
De LDAP-mapping mapt de attributen yn 'e LDAP-map nei de attributen yn' e CMS. Eigentlike eigenskippen:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskriuwing fan attributenIADB fertsjintwurdiget de oanmeld-ID fan de brûker yn it CMS. Om't dit in Microsoft Active Directory LDAP-tsjinner is, wurdt de CMS JID yn kaart brocht oan de sAMAccountName yn LDAP, wat yn essinsje de Active Directory-oanmeldings-ID fan de brûker is. Tink derom ek dat jo sAMAccountName nimme en it domein conf.pod6.cms.lab taheakje oan 'e ein dêrfan, om't dit de oanmelding is dy't jo brûkers sille brûke om oan te melden by it CMS.
nameMapping komt oerien mei wat is befette yn it Active Directory displayName-fjild mei it CMS-nammefjild fan de brûker.
coSpaceNameMapping makket in CMS romte namme basearre op it displayName fjild. Dit attribút, tegearre mei it coSpaceUriMapping-attribút, is wat nedich is om in romte foar elke brûker te meitsjen.
coSpaceUriMapping definiearret it brûkersdiel fan 'e URI ferbûn mei de persoanlike romte fan 'e brûker. Guon domeinen kinne wurde konfigureare om yn romte te draaien. As it brûker diel oerienkomt mei dit fjild foar ien fan dizze domeinen, wurdt de oprop rjochte op de romte fan dy brûker.
coSpaceSecondaryUriMapping definiearret in twadde URI om romte te berikken. Dit kin brûkt wurde om in numerike alias ta te foegjen foar it trochstjoeren fan oproppen nei de romte fan 'e ymporteare brûker as alternatyf foar de alfanumerike URI definieare yn' e parameter coSpaceUriMapping.
De LDAP-tsjinner en LDAP-mapping binne konfigureare. No moatte jo se mei-inoar keppelje troch in LDAP-boarne te meitsjen.
URL brûke om tagong te krijen :445/api/v1/ldapSource meitsje in LDAP-boarne-objekt, mei parameters oantsjutte lykas:
- tsjinner
- mappen
- baseDn
- filter
No't de LDAP-konfiguraasje kompleet is, kinne jo de manuele syngronisaasjeoperaasje útfiere.
Wy dogge dit of yn 'e webynterface fan elke server troch te klikken No syngronisearje section Active Directory
of fia de API mei it kommando PEAL URL brûke om tagong te krijen :445/api/v1/ldapSyncs
Ad-hoc konferinsjes
Wat is dit?Yn it tradisjonele konsept is in konferinsje as twa dielnimmers mei-inoar prate, en ien fan 'e dielnimmers (mei in apparaat registrearre by Unified CM) drukt op de knop "Konferinsje", ropt de oare persoan, en nei it praten mei dy tredde partij , drukt nochris op de knop "Konferinsje" om mei te dwaan oan alle dielnimmers oan de trijedielige konferinsje.
Wat in Ad-Hoc-konferinsje ûnderskiedt fan in plande konferinsje yn in CMS is dat in Ad-Hoc-konferinsje net allinich in SIP-oprop nei in CMS is. As de inisjatyfnimmer fan 'e konferinsje in twadde kear op de konferinsjeknop klikt om elkenien foar deselde gearkomste út te noegjen, moat Unified CM in API-oprop meitsje nei it CMS om in konferinsje te meitsjen dy't ûnderweis is wêrnei alle petearen dan wurde oerdroegen. Dit alles bart ûngemurken troch de dielnimmers.
Dit betsjut dat Unified CM de API-bewizen en WebAdmin-adres/poarte fan 'e tsjinst moat konfigurearje, lykas de SIP-trunk direkt nei de CMS-tsjinner om de oprop troch te gean.
As it nedich is, kin CUCM dynamysk in romte meitsje yn 'e CMS, sadat elke oprop de CMS kin berikke en oerienkomt mei de ynkommende opropregel dy't bedoeld is foar spaasjes.
Yntegraasje mei CUCM ynsteld op deselde wize as beskreaun yn it artikel útsein dat jo op Cisco UCM trije stammen moatte oanmeitsje foar de CMS, trije konferinsjebrêgen, yn it SIP-befeiligingsprofyl spesifisearje trije ûnderwerpnammen, rûtegroepen, rûtelisten, mediaresursgroepen en mediaresursgroeplisten, en foegje in pear routingregels ta. oan Cisco Meeting Server.
SIP Security Profile:
Trunks:
Elke romp sjocht der itselde út:
Konferinsje Bridge
Elke Conference Bridge sjocht der itselde út:
Rûtegroep
Rûte List
Media Resource Group
Media Resource Group List
Call Rules
Oars as mear avansearre opropbehearsystemen lykas Unified CM of Expressway, sjocht CMS allinich it domein op yn it SIP Request-URI-fjild foar nije oproppen. Dus as SIP INVITE foar slok is: [e-post beskerme]De CMS soarget allinich oer domain.com. CMS folget dizze regels om te bepalen wêr't jo in oprop moatte router:
1. De CMS besiket earst it SIP-domein te passen mei de domeinen dy't yn 'e ynkommende opropregels konfigureare binne. Dizze oproppen kinne dan wurde trochstjoerd nei ("rjochte") romten of spesifike brûkers, ynterne IVR's, of direkt yntegreare Microsoft Lync/Skype for Business (S4B) bestimmingen.
2. As d'r gjin oerienkomst is yn 'e ynkommende opropregels, sil CMS besykje te passen oan it domein dat konfigureare is yn' e oprop trochstjoertabel. As der in wedstriid wurdt makke, kin de regel de oprop eksplisyt ôfwize of de oprop trochstjoere. Op dit stuit kin de CMS it domein opnij skriuwe, wat soms nuttich is foar it oproppen fan Lync-domeinen. Jo kinne ek kieze foar in pass throw, wat betsjut dat gjin fan 'e fjilden wurdt fierder wizige, of brûk in ynterne CMS dial plan. As d'r gjin oerienkomst is yn 'e regels foar trochstjoeren fan oprop, is de standert om de oprop te wegerjen. Hâld der rekken mei dat yn 'e CMS, hoewol de oprop "trochstjoerd" is, de media noch altyd bûn is oan de CMS, wat betsjut dat it yn it sinjaal- en mediaferkearpaad sil wêze.
Dan binne allinich trochstjoerde petearen ûnderwurpen oan de regels foar útgeande oprop. Dizze ynstellings bepale de bestimmingen wêr't petearen wurde ferstjoerd, it trunktype (of it no in nije Lync-oprop of in standert SIP-oprop is), en alle konversaasjes dy't kinne wurde útfierd as oerdracht net selektearre is yn 'e regel foar trochstjoering fan oprop.
Hjir is it eigentlike logboek fan wat der bart tidens in Ad-Hoc-konferinsje
De skermôfbylding lit it min sjen (ik wit net hoe ik it better meitsje moat), dus ik skriuw it log sa:
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:12De ad-hoc konferinsje sels:
Regels foar ynkommende oprop
It konfigurearjen fan de parameters fan ynkommende petearen is nedich om in oprop yn 'e CMS te ûntfangen. Lykas jo seagen yn 'e LDAP-opset, waarden alle brûkers ymportearre mei it domein conf.pod6.cms.lab. Dus op syn minst wolle jo oproppen nei dit domein om romten te rjochtsjen. Jo moatte ek regels ynstelle foar alles dat bedoeld is foar de folslein kwalifisearre domeinnamme (en miskien sels it IP-adres) fan elk fan 'e CMS-tsjinners. Us eksterne opropkontrôle, Unified CM, sil SIP-trunken konfigurearje wijd oan elk fan 'e CMS-tsjinners yndividueel. Ofhinklik fan oft de bestimming fan dizze SIP-trunken in IP-adres is of de FQDN fan de tsjinner sil bepale oft de CMS moat wurde konfigureare om petearen te akseptearjen dy't rjochte binne op syn IP-adres of FQDN.
It domein dat de ynkommende regel hat mei de heechste prioriteit wurdt brûkt as it domein foar alle brûkersromten. As brûkers syngronisearje fia LDAP, makket de CMS automatysk romten, mar allinich it brûker diel fan 'e URI (coSpaceUriMapping), bygelyks user.space. Diel De folsleine URI wurdt generearre basearre op dizze regel. Yn feite, as jo op dit punt ynlogge by Web Bridge, soene jo sjen dat de Space URI gjin domein hat. Troch dizze regel as de heechste prioriteit yn te stellen, stelle jo it domein yn foar de generearre spaasjes conf.example.com.
Regels foar útgeande oprop
Om brûkers útgeande oproppen te meitsjen nei it Unified CM-kluster, moatte jo útgeande regels ynstelle. It domein fan einpunten registrearre by Unified CM, lykas Jabber, is example.com. Oproppen nei dit domein moatte wurde trochstjoerd as standert SIP-oproppen nei Unified CM-opropferwurkingsknooppunten. De haadtsjinner is cucm-01.example.com, en de ekstra is cucm-02.example.com.
De earste regel beskriuwt de ienfâldichste routing fan petearen tusken klusterservers.
fjild Lokaal fan domein is ferantwurdlik foar wat sil werjûn wurde yn de SIP-URI fan de beller foar de persoan dy't wurdt neamd nei it "@" symboal. As wy it leech litte, dan sil d'r nei it symboal "@" it IP-adres fan 'e CUCM wêze wêr't dizze oprop troch giet. As wy in domein spesifisearje, dan sil nei it symboal "@" eins in domein wêze. Dit is nedich om werombelle te kinnen, oars kin net werombelle wurde fia SIP-URI namme@ip-adres.
Skilje as oanjûn Lokaal fan domein
Skilje wannear NOT oantsjutte Lokaal fan domein
Soargje derfoar dat jo fersifere of net fersifere eksplisyt spesifisearje foar útgeande oproppen, om't neat wurket mei de Auto-parameter.
Opname
Fideokonferinsjes wurde opnommen troch de Record-tsjinner. Recorder is krekt itselde as Cisco Meeting Server. Recorder fereasket gjin ynstallaasje fan lisinsjes. Opnamelisinsjes binne nedich foar tsjinners dy't CallBridge-tsjinsten útfiere, d.w.s. in opname lisinsje is nedich en moat tapast wurde op de CallBridge komponint, en net op de tsjinner running Recorder. Recorder gedraacht as in XMPP-kliïnt (Extensible Messaging and Presence Protocol), sadat de XMPP-tsjinner moat ynskeakele wurde op de tsjinner dy't CallBridge host.
Omdat Wy hawwe in kluster en de lisinsje moat wurde "stretched" oer alle trije servers yn it kluster. Dan gewoan yn jo persoanlike akkount yn 'e lisinsjes dy't wy assosjearje (taheakje) de MAC-adressen fan' e a-ynterfaces fan alle CMS-tsjinners opnommen yn it kluster.
En dit is de foto dy't op elke server yn it kluster moat wêze
Yn 't algemien binne d'r ferskate senario's foar it pleatsen fan Recorder, mar wy sille dit hâlde:
Foardat jo Recorder ynstelle, moatte jo in plak tariede wêr't de fideokonferinsjes werklik wurde opnommen. Eins hjir , hoe't jo alle Recording ynstelle. Ik rjochtsje my op wichtige punten en details:
1. It is better om it sertifikaat te slipjen fan 'e earste tsjinner yn it kluster.
2. De flater "Recorder net beskikber" kin foarkomme om't it ferkearde sertifikaat oanjûn is yn 'e Recorder Trust.
3. Skriuwen kin net wurkje as de NFS triemtafel oantsjutte foar opname is net de woartel triemtafel.
Soms is it nedich om automatysk in konferinsje fan ien spesifike brûker of romte op te nimmen.
Hjirfoar wurde twa CallProfiles makke:
Mei opname útskeakele
En mei automatyske opnamefunksje
Folgjende, "heakje" wy in CallProfile mei in automatyske opname funksje oan de fereaske romte.
Yn CMS is it sa fêststeld dat as in CallProfile eksplisyt ferbûn is oan elke romte of romte, dan wurket dit CallProfile allinich yn relaasje ta dizze spesifike romten. En as it CallProfile net bûn is oan in romte, dan wurdt it standert tapast op dy romten dêr't gjin CallProfile eksplisyt oan bûn is.
Folgjende kear sil ik besykje te beskriuwen hoe't de CMS tagong wurdt bûten it ynterne netwurk fan 'e organisaasje.
Boarne:
Boarne: www.habr.com