V tej številki bom prikazal in razložil nekaj zapletenosti nastavitve strežnika CMS v načinu samodejne gruče.
TeorijaNa splošno obstajajo tri vrste uvedbe strežnika CMS:
- Enojna kombinirana(Enojno kombinirano), t.j. to je en strežnik, na katerem tečejo vse potrebne storitve. V večini primerov je ta vrsta uvedbe primerna le za notranji dostop odjemalcev in v manjših okoljih, kjer omejitve razširljivosti in redundance posameznega strežnika niso kritična težava, ali v situacijah, ko CMS izvaja le določene funkcije, kot je ad hoc konference o Cisco UCM.
Približna shema dela:
- Samski Split(Single Split) razširja prejšnjo vrsto uvedbe z dodajanjem ločenega strežnika za zunanji dostop. Pri podedovanih uvedbah je to pomenilo uvedbo strežnika CMS v demilitariziranem omrežnem segmentu (DMZ), kjer so zunanji odjemalci lahko dostopali do njega, in enega strežnika CMS v jedru omrežja, kjer so notranji odjemalci lahko dostopali do CMS. Ta posebni model uvajanja je zdaj nadomeščen s tako imenovanim tipom Single Edge, ki ga sestavljajo strežniki Cisco Expressway, ki imajo ali bodo imeli veliko enakih zmožnosti obhoda požarnega zidu, tako da strankam ni treba dodati namenskega robnega strežnika CMS.
Približna shema dela:
- Razširljiv in odporen(Razširljiv in odporen na napake) Ta vrsta vključuje redundanco za vsako komponento, kar omogoča sistemu, da raste z vašimi potrebami do svoje največje zmogljivosti, hkrati pa zagotavlja redundanco v primeru okvare. Uporablja tudi koncept Single Edge za zagotavljanje varnega zunanjega dostopa. To je vrsta, ki si jo bomo ogledali v tej epizodi. Če razumemo, kako razmestiti to vrsto gruče, ne bomo razumeli samo drugih vrst uvedb, ampak bomo lahko tudi razumeli, kako ustvariti gruče strežnikov CMS, da se prilagodimo potencialni rasti povpraševanja.
Preden nadaljujete z uvajanjem, morate razumeti nekaj osnovnih stvari, in sicer
Glavne komponente programske opreme CMS:
- Baze podatkov: Omogoča kombiniranje nekaterih konfiguracij, kot so klicni načrt, uporabniški prostori in uporabniki sami. Podpira združevanje v gruče samo za visoko razpoložljivost (en master).
- Pokliči Bridge: storitev za avdio in video konference, ki omogoča popoln nadzor nad upravljanjem in obdelavo klicev ter multimedijskih procesov. Podpira združevanje v gruče za visoko razpoložljivost in razširljivost.
- strežnik XMPP: odgovoren za registracijo in avtentikacijo strank, ki uporabljajo aplikacijo Cisco Meeting in/ali WebRTC(komunikacija v realnem času ali preprosto v brskalniku), kot tudi medkomponentno signalizacijo. Lahko jih združite v gruče samo za visoko razpoložljivost.
- Spletni most: Omogoča odjemalcu dostop do WebRTC.
- Izravnalnik obremenitve: Zagotavlja eno samo povezovalno točko za aplikacije Cisco Meeting v načinu Single Split. Posluša zunanji vmesnik in vrata za dohodne povezave. Prav tako izravnalnik obremenitve sprejema dohodne povezave TLS s strežnika XMPP, prek katerih lahko preklaplja povezave TCP zunanjih odjemalcev.
V našem scenariju to ne bo potrebno. - TURN strežnik: Zagotavlja tehnologijo obvoda požarnega zidu, ki omogoča
postavimo naš CMS za požarni zid ali NAT, da povežemo zunanje odjemalce z uporabo aplikacije Cisco Meeting App ali naprav SIP. V našem scenariju to ne bo potrebno. - Spletni skrbnik: Administrativni vmesnik in dostop do API-ja, vključno za posebne konference Unified CM.
Načini konfiguracije
Za razliko od večine drugih izdelkov Cisco, Cisco Meeting Server podpira tri konfiguracijske metode za prilagoditev kateri koli vrsti uvajanja.
- Ukazna vrstica (CLI): vmesnik ukazne vrstice, znan kot MMP, za začetno konfiguracijo in opravila potrdil.
- Spletni skrbnik: Predvsem za konfiguracije, povezane s CallBridge, zlasti pri nastavitvi enega samega strežnika brez gruč.
- REST API: Uporablja se za najbolj zapletene konfiguracijske naloge in naloge, povezane z zbirko podatkov v gručah.
Poleg naštetega se uporablja še protokol SFTP za prenos datotek—običajno licenc, potrdil ali dnevnikov—v strežnik CMS in iz njega.
V navodilih za uvajanje podjetja Cisco je v beli in angleščini napisano, da je treba gručo namestiti vsaj tri strežniki (vozlišča) v kontekstu baz podatkov. Ker Le pri lihem številu vozlišč bo deloval mehanizem za izbiro novega Database Master, na splošno pa ima Database Master povezavo z večino baze podatkov strežnika CMS.
In kot kaže praksa, dva strežnika (vozlišča) res nista dovolj. Izbirni mehanizem deluje, ko se glavni znova zažene, podrejeni strežnik postane glavni šele, ko se ponovno zažene strežnik. Če pa v gruči dveh strežnikov glavni strežnik nenadoma ugasne, potem podrejeni strežnik ne postane glavni, in če podrejeni ugasne, bo preostali glavni strežnik postal podrejeni.
Toda v kontekstu XMPP bi bilo res treba sestaviti gručo treh strežnikov, ker če na primer onemogočite storitev XMPP na enem od strežnikov, v katerem je XMMP v statusu Leader, bo na preostalem strežniku XMPP ostal v statusu Follower in povezave CallBridge z XMPP bodo padle, ker CallBridge se povezuje izključno na XMPP s statusom Leader. In to je kritično, ker ... niti en klic ne bo potekal.
Tudi v istih vodnikih za uvajanje je prikazana gruča z enim strežnikom XMPP.
In ob upoštevanju zgoraj navedenega postane jasno, zakaj: deluje, ker je v samodejnem načinu.
V našem primeru bo strežnik XMPP prisoten na vseh treh vozliščih.
Predvidevamo, da vsi trije naši strežniki delujejo.
DNS zapisi
Preden začnete nastavljati strežnike, morate ustvariti zapise DNS А и SRV vrste:
Upoštevajte, da sta v naših zapisih DNS dve domeni example.com in conf.example.com. Example.com je domena, ki jo lahko vsi naročniki Cisco Unified Communication Manager uporabljajo za svoje URI-je, ki je najverjetneje prisotna v vaši infrastrukturi ali bo verjetno prisotna. Ali pa se example.com ujema z isto domeno, ki jo uporabniki uporabljajo za svoje e-poštne naslove. Lahko pa ima odjemalec Jabber na vašem prenosniku URI [e-pošta zaščitena]. Domena conf.example.com je domena, ki bo konfigurirana za uporabnike strežnika Cisco Meeting Server. Domena strežnika za srečanja Cisco bo conf.example.com, tako da bi za istega uporabnika Jabber morali uporabiti URI uporabnik@ za prijavo v strežnik za srečanja Ciscoconf.example.com.
Osnovna konfiguracija
Vse spodaj opisane nastavitve so prikazane na enem strežniku, vendar jih je treba narediti na vsakem strežniku v gruči.
QoS
Ker CMS ustvarja v realnem času promet občutljiv na zakasnitve in izgubo paketov, je v večini primerov priporočljivo konfigurirati kakovost storitve (QoS). Da bi to dosegel, CMS podpira označevanje paketov s kodami diferenciranih storitev (DSCP), ki jih ustvari. Čeprav je določanje prednosti prometa na podlagi DSCP odvisno od tega, kako promet obdelujejo omrežne komponente vaše infrastrukture, bomo v našem primeru naš CMS konfigurirali s tipičnim določanjem prednosti DSCP na podlagi najboljših praks QoS.
Na vsakem strežniku bomo vnesli te ukaze
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ATako je bil ves video promet označen z AF41 (DSCP 0x22), ves govorni promet z oznako EF (DSCP 0x2E), druge vrste prometa z nizko zakasnitvijo, kot sta SIP in XMPP, uporabljajo AF31 (DSCP 0x1A).
Preverjamo:
NTP
Omrežni časovni protokol (NTP) ni pomemben samo za zagotavljanje natančnih časovnih žigov klicev in konferenc, ampak tudi za preverjanje potrdil.
Dodajte strežnike NTP svoji infrastrukturi z ukazom, kot je
ntp server add <server>
V našem primeru sta takšna strežnika dva, torej bosta dve ekipi.
Preverjamo:
In nastavite časovni pas za naš strežnik
DNS
Strežnike DNS dodamo v CMS z ukazom, kot je:
dns add forwardzone <domain-name> <server ip>
V našem primeru sta takšna strežnika dva, torej bosta dve ekipi.
Preverjamo:
Konfiguracija omrežnega vmesnika
Vmesnik konfiguriramo z ukazom, kot je:
ipv4 <interface> add <address>/<prefix length> <gateway>
Preverjamo:
Ime strežnika (ime gostitelja)
Ime strežnika nastavimo z ukazom, kot je:
hostname <name>
In ponovno zaženemo.
S tem je osnovna konfiguracija zaključena.
Potrdila
TeorijaCisco Meeting Server zahteva šifrirano komunikacijo med različnimi komponentami, zato so potrdila X.509 potrebna za vse uvedbe CMS. Pomagajo zagotoviti, da storitvam/strežniku zaupajo drugi strežniki/storitve.
Vsaka storitev zahteva potrdilo, vendar lahko ustvarjanje ločenih potrdil za vsako storitev povzroči zmedo in nepotrebno zapletenost. Na srečo lahko ustvarimo par javno-zasebnih ključev potrdila in jih nato ponovno uporabimo v več storitvah. V našem primeru bo isto potrdilo uporabljeno za Call Bridge, XMPP Server, Web Bridge in Web Admin. Zato morate ustvariti par javnih in zasebnih ključev potrdila za vsak strežnik v gruči.
Vendar pa ima združevanje baz podatkov v gruče nekaj posebnih zahtev za potrdila in zato zahteva lastna potrdila, ki se razlikujejo od potrdil drugih storitev. CMS uporablja potrdilo strežnika, ki je podobno potrdilom, ki jih uporabljajo drugi strežniki, obstaja pa tudi potrdilo odjemalca, ki se uporablja za povezave z bazo podatkov. Certifikati baz podatkov se uporabljajo za avtentikacijo in šifriranje. Namesto da bi odjemalcu zagotovil uporabniško ime in geslo za povezavo z bazo podatkov, predstavi potrdilo odjemalca, ki mu strežnik zaupa. Vsak strežnik v gruči baze podatkov bo uporabljal isti par javnih in zasebnih ključev. To vsem strežnikom v gruči omogoča šifriranje podatkov na tak način, da jih lahko dešifrirajo samo drugi strežniki, ki prav tako delijo isti par ključev.
Da redundanca deluje, morajo biti gruče baz podatkov sestavljene iz najmanj 3 strežnikov, vendar ne več kot 5, z največjim povratnim časom 200 ms med katerim koli članom gruče. Ta omejitev je bolj restriktivna kot pri združevanju v gruče Call Bridge, zato je pogosto omejevalni dejavnik pri geografsko porazdeljenih uvedbah.
Vloga zbirke podatkov za CMS ima številne edinstvene zahteve. Za razliko od drugih vlog zahteva potrdilo odjemalca in strežnika, pri čemer ima potrdilo odjemalca posebno polje CN, ki je predstavljeno strežniku.
CMS uporablja bazo postgres z enim masterjem in več popolnoma enakimi replikami. Naenkrat obstaja le ena primarna zbirka podatkov (»strežnik baze podatkov«). Preostali člani gruče so replike ali "odjemalci baze podatkov".
Gruča baze podatkov zahteva potrdilo namenskega strežnika in potrdilo odjemalca. Podpisani morajo biti s certifikati, običajno internega zasebnega overitelja potrdil. Ker lahko kateri koli član gruče baze podatkov postane glavni, je treba pare potrdil strežnika baze podatkov in odjemalca (ki vsebujejo javne in zasebne ključe) prekopirati v vse strežnike, tako da lahko prevzamejo identiteto odjemalca ali strežnika baze podatkov. Poleg tega mora biti naloženo korensko potrdilo CA, da se zagotovi preverjanje potrdil odjemalca in strežnika.
Ustvarimo torej zahtevo za potrdilo, ki ga bodo uporabljale vse strežniške storitve razen baze podatkov (za to bo ločena zahteva) z ukazom, kot je:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
V CN pišemo splošno ime naših strežnikov. Na primer, če imena gostiteljev naših strežnikov server01, server02, server03, potem bo CN server.example.com
Enako naredimo na preostalih dveh strežnikih s to razliko, da bodo ukazi vsebovali ustrezna “imena gostiteljev”
Ustvarimo dve zahtevi za potrdila, ki jih bo uporabila storitev baze podatkov z ukazi, kot so:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresče dbclusterserver и dbclusterclient imena naših zahtev in prihodnjih potrdil, ime gostitelja1(2)(3) imena ustreznih strežnikov.
Ta postopek izvedemo samo na enem strežniku (!), na druge strežnike pa bomo naložili certifikate in pripadajoče datoteke .key.
Omogoči način potrdila odjemalca v AD CS
Prav tako morate združiti potrdila za vsak strežnik v eno datoteko.Na *NIX:
cat server01.cer server02.cer server03.cer > server.cerV sistemu Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
In naložite na vsak strežnik:
1. “Individualno” potrdilo strežnika.
2. Korensko potrdilo (skupaj z vmesnimi, če obstajajo).
3. Potrdila za bazo podatkov (»strežnik« in »odjemalec«) in datoteke s končnico .key, ki so bile generirane pri kreiranju zahteve za potrdila baze podatkov »strežnik« in »odjemalec«. Te datoteke morajo biti enake na vseh strežnikih.
4. Datoteka vseh treh »posameznih« potrdil.
Posledično bi morali na vsakem strežniku dobiti nekaj podobnega tej sliki datoteke.
Grozd baz podatkov
Zdaj, ko imate vsa potrdila naložena na strežnike CMS, lahko konfigurirate in omogočite združevanje baze podatkov v gruče v treh vozliščih. Prvi korak je, da izberete en strežnik kot glavno vozlišče gruče baze podatkov in ga v celoti konfigurirate.
Glavna zbirka podatkov
Prvi korak pri nastavljanju replikacije baze podatkov je določitev potrdil, ki bodo uporabljena za bazo podatkov. To se naredi z ukazom, kot je:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Zdaj pa CMS povejmo, kateri vmesnik naj uporabi za združevanje baze podatkov v gruče z ukazom:
database cluster localnode aNato inicializiramo bazo podatkov gruče na glavnem strežniku z ukazom:
database cluster initialize
Vozlišča baze podatkov odjemalca
Naredimo enak postopek, le namesto ukaza inicializacija gruče baze podatkov vnesite ukaz, kot je:
database cluster join <ip address existing master>kjer ip address obstoječi glavni naslov ip strežnika CMS, na katerem je bila inicializirana gruča, preprosto Master.
Kako deluje naša gruča baze podatkov preverimo na vseh strežnikih z ukazom:
database cluster status
Enako naredimo na preostalem tretjem strežniku.
Posledično se izkaže, da je naš prvi strežnik glavni, ostali pa sužnji.
Spletna skrbniška storitev
Omogočite storitev spletnega skrbnika:
webadmin listen a 445Vrata 445 so bila izbrana, ker se vrata 443 uporabljajo za uporabniški dostop do spletnega odjemalca
Storitev Web Admin konfiguriramo z datotekami potrdil z ukazom, kot je:
webadmin certs <keyfile> <certificatefile> <ca bundle>In omogočite spletnega skrbnika z ukazom:
webadmin enable
Če je vse v redu, bomo prejeli vrstice SUCCESS, ki kažejo, da je spletni skrbnik pravilno konfiguriran za omrežje in potrdilo. Delovanje storitve preverimo s spletnim brskalnikom in vnesemo naslov spletnega skrbnika, npr. : 445
Pokličite Bridge Cluster
Call Bridge je edina storitev, ki je prisotna v vsaki uvedbi CMS. Call Bridge je glavni konferenčni mehanizem. Zagotavlja tudi vmesnik SIP, tako da lahko klice nanj ali iz njega usmeri na primer Cisco Unified CM.
Spodaj opisane ukaze je treba izvesti na vsakem strežniku z ustreznimi certifikati.
Torej:
Certifikate povežemo s storitvijo Call Bridge z ukazom, kot je:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Storitve CallBridge povežemo z vmesnikom, ki ga potrebujemo, z ukazom:
callbridge listen aIn znova zaženite storitev z ukazom:
callbridge restart
Zdaj, ko imamo konfigurirane klicne mostove, lahko konfiguriramo združevanje klicnih mostov v gruče. Združevanje v gruče Call Bridge se razlikuje od združevanja v baze podatkov ali XMPP. Cluster Call Bridge lahko podpira od 2 do 8 vozlišč brez kakršnih koli omejitev. Ne zagotavlja le redundance, ampak tudi uravnoteženje obremenitve, tako da se lahko konference aktivno porazdelijo po strežnikih Call Bridge z uporabo inteligentne distribucije klicev. CMS ima dodatne funkcije, skupine Call Bridge in povezane funkcije, ki jih je mogoče uporabiti za nadaljnje upravljanje.
Gručenje klicnega mostu je konfigurirano predvsem prek spletnega skrbniškega vmesnika
Spodaj opisani postopek je treba izvesti na vsakem strežniku v gruči.
Torej,
1. Po spletu pojdite na Configuration > Cluster.
2. V Call Bridge identiteta Kot edinstveno ime vnesite callbridge[01,02,03], ki ustreza imenu strežnika. Ta imena so poljubna, vendar morajo biti edinstvena za to gručo. Po naravi so opisni, ker kažejo, da so identifikatorji strežnika [01,02,03].
3.B Clustered Call Bridges vnesite URL-je spletnega skrbnika naših strežnikov v gruči, [01,02,03].example.com:445 v polju Naslov. Ne pozabite določiti vrat. Domeno SIP Peer link lahko pustite prazno.
4. V CallBridge trust vsakega strežnika, katerega datoteka vsebuje vsa potrdila naših strežnikov, ki smo jih na samem začetku združili v to datoteko, dodamo potrdilo z ukazom tipa:
callbridge trust cluster <trusted cluster certificate bundle>In znova zaženite storitev z ukazom:
callbridge restart
Posledično bi morali na vsakem strežniku dobiti to sliko:
Grozd XMPP
Storitev XMPP v CMS se uporablja za obdelavo vseh registracij in preverjanj pristnosti za aplikacije Cisco Meeting Apps (CMA), vključno s spletnim odjemalcem CMA WebRTC. Sam Call Bridge deluje tudi kot odjemalec XMPP za namene preverjanja pristnosti in ga je zato treba konfigurirati kot druge odjemalce. Toleranca napak XMPP je funkcija, ki je v produkcijskih okoljih podprta od različice 2.1
Spodaj opisane ukaze je treba izvesti na vsakem strežniku z ustreznimi certifikati.
Torej:
Potrdila povežemo s storitvijo XMPP z ukazom, kot je:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Nato definirajte vmesnik za poslušanje z ukazom:
xmpp listen aStoritev XMPP zahteva edinstveno domeno. To je prijava za uporabnike. Z drugimi besedami, ko se uporabnik poskuša prijaviti z aplikacijo CMA (ali prek odjemalca WebRTC), vnese userID@logindomain. V našem primeru bo to userid@conf.example.com. Zakaj ni samo example.com? Pri naši posebni uvedbi smo izbrali našo domeno Unified CM, ki jo bodo uporabniki Jabberja uporabljali v Unified CM kot example.com, zato smo potrebovali drugo domeno za uporabnike CMS za usmerjanje klicev v in iz CMS prek domen SIP.
Nastavite domeno XMPP z ukazom, kot je:
xmpp domain <domain>In omogočite storitev XMPP z ukazom:
xmpp enableV storitvi XMPP morate ustvariti poverilnice za vsak klicni most, ki bo uporabljen pri registraciji v storitvi XMPP. Ta imena so poljubna (in niso povezana z enoličnimi imeni, ki ste jih konfigurirali za združevanje klicnih mostov). Dodati morate tri klicne mostove na en strežnik XMPP in nato te poverilnice vnesti v druge strežnike XMPP v gruči, ker ta konfiguracija ne ustreza zbirki podatkov gruče. Kasneje bomo konfigurirali vsak klicni most za uporabo tega imena in skrivnosti za registracijo v storitvi XMPP.
Zdaj moramo konfigurirati storitev XMPP na prvem strežniku s tremi klicnimi mostovi callbridge01, callbridge02 in callbridge03. Vsakemu računu bodo dodeljena naključna gesla. Pozneje bodo vneseni v druge strežnike Call Bridge za prijavo v ta strežnik XMPP. Vnesite naslednje ukaze:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Posledično preverimo, kaj se je zgodilo z ukazom:
xmpp callbridge list
Po spodaj opisanih korakih bi se morala na preostalih strežnikih prikazati popolnoma enaka slika.
Nato dodamo popolnoma enake nastavitve na preostalih dveh strežnikih, le z ukazi
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Skrivnost dodajamo zelo previdno, tako da na primer v njem ni dodatnih presledkov.
Posledično bi moral imeti vsak strežnik enako sliko:
Nato na vseh strežnikih v gruči zaupamo datoteko, ki vsebuje vsa tri potrdila, ustvarjena prej z ukazom, kot je ta:
xmpp cluster trust <trust bundle>Način gruče xmpp omogočimo na vseh strežnikih gruče z ukazom:
xmpp cluster enableNa prvem strežniku gruče sprožimo izdelavo gruče xmpp z ukazom:
xmpp cluster initializeNa drugih strežnikih dodajte gručo v xmpp z ukazom, kot je:
xmpp cluster join <ip address head xmpp server>Na vsakem strežniku preverimo uspešnost ustvarjanja gruče XMPP na posameznem strežniku z ukazi:
xmpp status
xmpp cluster statusPrvi strežnik:
Drugi strežnik:
Tretji strežnik:
Povezovanje Call Bridge z XMPP
Zdaj, ko gruča XMPP deluje, morate konfigurirati storitve Call Bridge za povezavo z gručo XMPP. To konfiguracijo opravi spletni skrbnik.
Na vsakem strežniku pojdite na Konfiguracija > Splošno in v polju Edinstveno ime Call Bridge napišite edinstvena imena, ki ustrezajo strežniku Call Bridge klicni most[01,02,03]... Na terenu Domena conf.example.ru in ustrezna gesla, lahko vohunite za njimi
na katerem koli strežniku v gruči z ukazom:
xmpp callbridge list
Polje »Strežnik« pustite prazno Klicni most bo izvedel iskanje DNS SRV za _xmpp-component._tcp.conf.example.comza iskanje razpoložljivega strežnika XMPP. Naslovi IP za povezovanje klicnih mostov z XMPP se lahko razlikujejo na vsakem strežniku, odvisno od tega, katere vrednosti so vrnjene v zahtevo za zapis _xmpp-component._tcp.conf.example.com callbridge, kar pa je odvisno od prioritetnih nastavitev za dani zapis DNS.
Nato pojdite na Status > Splošno, da preverite, ali je storitev Call Bride uspešno povezana s storitvijo XMPP.
Spletni most
Na vsakem strežniku v gruči omogočite storitev Web Bridge z ukazom:
webbridge listen a:443Storitev Web Bridge konfiguriramo z datotekami potrdil z ukazom, kot je:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge podpira HTTPS. Preusmeri HTTP na HTTPS, če je konfiguriran za uporabo "http-redirect".
Če želite omogočiti preusmeritev HTTP, uporabite naslednji ukaz:
webbridge http-redirect enableČe želite Call Bridge vedeti, da Web Bridge lahko zaupa povezavam iz Call Bridgea, uporabite ukaz:
webbridge trust <certfile>kjer je to datoteka, ki vsebuje vsa tri potrdila iz vsakega strežnika v gruči.
Ta slika mora biti na vsakem strežniku v gruči.
Sedaj moramo ustvariti uporabnika z vlogo “appadmin”, potrebujemo ga, da lahko konfiguriramo našo gručo(!), in ne vsakega strežnika v gruči posebej, na ta način bodo nastavitve uporabljene enako za vsak strežnik kljub dejstvo, da bodo narejeni enkrat.
Za nadaljnjo nastavitev bomo uporabili .
Za avtorizacijo izberite Osnovno v razdelku Avtorizacija
Za pravilno pošiljanje ukazov strežniku CMS morate nastaviti zahtevano kodiranje
Z ukazom določimo Webbridge POST s parametrom url in vrednost
V samem spletnem mostu navedemo zahtevane parametre: gostujoči dostop, zaščiten dostop itd.
Pokličite premostitvene skupine
Privzeto CMS ne uporablja vedno najbolj učinkovito konferenčnih virov, ki so mu na voljo.
Na primer, za sestanek s tremi udeleženci lahko vsak udeleženec konča na treh različnih klicnih mostovih. Da bi ti trije udeleženci lahko komunicirali med seboj, bodo Call Bridges samodejno vzpostavili povezave med vsemi strežniki in odjemalci v istem prostoru, tako da bo videti, kot da so vsi odjemalci na istem strežniku. Na žalost je slaba stran tega, da bo ena konferenca s tremi osebami zdaj porabila 3 medijskih vrat. To je očitno neučinkovita poraba virov. Poleg tega, ko je klicni most resnično preobremenjen, je privzeti mehanizem še naprej sprejemati klice in zagotavljati storitev zmanjšane kakovosti za vse naročnike tega klicnega mostu.
Te težave se rešijo s funkcijo Call Bridge Group. Ta funkcija je bila predstavljena v različici 2.1 programske opreme Cisco Meeting Server in je bila razširjena tako, da podpira uravnoteženje obremenitve za dohodne in odhodne klice aplikacije Cisco Meeting App (CMA), vključno z udeleženci WebRTC.
Da bi rešili težavo s ponovno povezavo, so bile za vsak klicni most uvedene tri nastavljive omejitve obremenitve:
LoadLimit — to je največja številčna obremenitev za določen klicni most. Vsaka platforma ima priporočeno omejitev obremenitve, na primer 96000 za CMS1000 in 1.25 GHz na vCPE za virtualni stroj. Različni klici porabijo določeno količino virov, odvisno od ločljivosti in hitrosti sličic udeleženca.
NewConferenceLoadLimitBasisPoints (privzeto 50% loadLimit) - nastavi omejitev obremenitve strežnika, po kateri so nove konference zavrnjene.
ExistingConferenceLoadLimitBasisPoints (privzeto 80 % loadLimit) – vrednost obremenitve strežnika, po kateri bodo udeleženci, ki se pridružijo obstoječi konferenci, zavrnjeni.
Čeprav je bila ta funkcija zasnovana za distribucijo klicev in uravnoteženje obremenitve, je mogoče skupinam klicnih mostov dodeliti tudi druge skupine, kot so strežniki TURN, strežniki Web Bridge in snemalniki, tako da jih je mogoče tudi pravilno združiti v skupine za optimalno uporabo. Če kateri koli od teh objektov ni dodeljen klicni skupini, se domneva, da so na voljo vsem strežnikom brez posebne prioritete.
Ti parametri so konfigurirani tukaj: :445/api/v1/system/configuration/cluster
Nato vsakemu klicnemu mostu navedemo, kateri skupini klicnih mostov pripada:
Prvi klicni most
Drugi klicni most
Tretji klicni most
Tako smo skupino Call Brdige konfigurirali za učinkovitejšo uporabo virov gruče Cisco Meeting Server.
Uvoz uporabnikov iz imenika Active Directory
Storitev Web Admin ima razdelek za konfiguracijo LDAP, vendar ne ponuja zapletenih konfiguracijskih možnosti in informacije niso shranjene v zbirki podatkov gruče, zato bo treba konfiguracijo opraviti ročno na vsakem strežniku prek spletnega vmesnika ali prek API, in tako, da bomo »trikrat »Ne vstani« bomo še vedno nastavljali podatke preko API-ja.
Uporaba URL-ja za dostop :445/api/v1/ldapServers ustvari objekt strežnika LDAP, ki podaja parametre, kot so:
- IP strežnika
- številko vrat
- uporabniško ime
- geslo
- zavarovanje
Varno - izberite true ali false, odvisno od vrat, 389 - ni varno, 636 - zaščiteno.
Preslikava izvornih parametrov LDAP v atribute v strežniku za srečanja Cisco.
Preslikava LDAP preslika atribute v imeniku LDAP v atribute v CMS. Dejanski atributi:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Opis atributovJID predstavlja ID za prijavo uporabnika v CMS. Ker je to strežnik LDAP Microsoft Active Directory, se CMS JID preslika v sAMAccountName v LDAP, kar je v bistvu ID uporabnika za prijavo v Active Directory. Upoštevajte tudi, da vzamete sAMAccountName in dodate domeno conf.pod6.cms.lab na konec, ker je to prijava, ki jo bodo vaši uporabniki uporabljali za prijavo v CMS.
nameMapping ujema tisto, kar je v polju displayName imenika Active Directory, z uporabniškim poljem imena CMS.
coSpaceNameMapping ustvari ime prostora CMS na podlagi polja displayName. Ta atribut je skupaj z atributom coSpaceUriMapping tisto, kar je potrebno za ustvarjanje prostora za vsakega uporabnika.
coSpaceUriMapping definira uporabniški del URI-ja, ki je povezan z uporabnikovim osebnim prostorom. Nekatere domene je mogoče konfigurirati za klicanje v prostor. Če se uporabniški del ujema s tem poljem za eno od teh domen, bo klic usmerjen v prostor tega uporabnika.
coSpaceSecondaryUriMapping definira drugi URI za doseganje prostora. To lahko uporabite za dodajanje številskega vzdevka za usmerjanje klicev v prostor uvoženega uporabnika kot alternativo alfanumeričnemu URI-ju, definiranemu v parametru coSpaceUriMapping.
Strežnik LDAP in preslikava LDAP sta konfigurirana. Zdaj jih morate povezati z ustvarjanjem vira LDAP.
Uporaba URL-ja za dostop :445/api/v1/ldapSource ustvari objekt LDAP Source, ki določa parametre, kot so:
- strežnik
- kartiranje
- baseDn
- filter
Zdaj, ko je konfiguracija LDAP končana, lahko izvedete ročno sinhronizacijo.
To storimo bodisi v spletnem vmesniku posameznega strežnika s klikom Sinhronizirajte zdaj oddelek Active Directory
ali prek API-ja z ukazom POST z uporabo URL-ja za dostop :445/api/v1/ldapSyncs
Ad-hoc konference
Kaj je to?V tradicionalnem konceptu je konferenca, ko se dva udeleženca pogovarjata drug z drugim in eden od udeležencev (z napravo, registrirano pri Unified CM) pritisne gumb "Konferenca", pokliče drugo osebo in po pogovoru s to tretjo osebo , ponovno pritisne gumb "Konferenca", da se pridruži vsem udeležencem v tristranski konferenci.
Kar razlikuje Ad-Hoc konferenco od načrtovane konference v CMS je to, da Ad-Hoc konferenca ni le klic SIP v CMS. Ko pobudnik konference drugič klikne gumb Konferenca, da povabi vse na isti sestanek, mora Unified CM opraviti klic API-ja v CMS, da ustvari sprotno konferenco, na katero se nato prenesejo vsi klici. Vse to se zgodi neopaženo za udeležence.
To pomeni, da mora Unified CM za nadaljevanje klica konfigurirati poverilnice API-ja in naslov/vrata spletnega skrbnika storitve ter SIP Trunk neposredno na strežnik CMS.
Po potrebi lahko CUCM dinamično ustvari prostor v CMS, tako da lahko vsak klic doseže CMS in se ujema s pravilom dohodnega klica, ki je namenjeno presledkom.
Integracija s CUCM konfiguriran na enak način, kot je opisano v članku le da morate na Cisco UCM ustvariti tri trunke za CMS, tri konferenčne mostove, v varnostnem profilu SIP določiti tri imena subjektov, skupine poti, sezname poti, skupine medijskih virov in sezname skupin medijskih virov ter dodati nekaj pravil usmerjanja na Cisco Meeting Server.
Varnostni profil SIP:
Prtljažniki:
Vsako deblo je videti enako:
Konferenčni most
Vsak konferenčni most je videti enako:
Skupina poti
Seznam poti
Media Resource Group
Seznam skupin medijskih virov
Pravila klicev
Za razliko od naprednejših sistemov za upravljanje klicev, kot sta Unified CM ali Expressway, CMS za nove klice poišče samo domeno v polju SIP Request-URI. Torej, če je SIP INVITE za požirek: [e-pošta zaščitena]CMS skrbi samo za domain.com. CMS upošteva ta pravila, da določi, kam usmeriti klic:
1. CMS najprej poskuša uskladiti domeno SIP z domenami, konfiguriranimi v pravilih za dohodne klice. Te klice je nato mogoče usmeriti v (»ciljane«) prostore ali določene uporabnike, notranje IVR-je ali neposredno integrirane destinacije Microsoft Lync/Skype for Business (S4B).
2. Če v pravilih za dohodne klice ni ujemanja, bo CMS poskušal ujemati domeno, konfigurirano v tabeli za posredovanje klicev. Če pride do ujemanja, lahko pravilo izrecno zavrne klic ali posreduje klic. V tem času lahko CMS prepiše domeno, kar je včasih uporabno za klicanje domen Lync. Izberete lahko tudi pass throw, kar pomeni, da nobeno od polj ne bo dodatno spremenjeno, ali pa uporabite notranji klicni načrt CMS. Če v pravilih za posredovanje klicev ni ujemanja, je privzeto zavrnjen klic. Upoštevajte, da je v CMS, čeprav je klic "posredovan", medij še vedno vezan na CMS, kar pomeni, da bo na poti signalizacije in medijskega prometa.
Potem samo za posredovane klice veljajo pravila za odhodne klice. Te nastavitve določajo cilje, kamor so klici poslani, vrsto priključka (ali gre za nov klic Lync ali standardni klic SIP) in vse pretvorbe, ki jih je mogoče izvesti, če prenos ni izbran v pravilu za posredovanje klicev.
Tukaj je dejanski dnevnik dogajanja med Ad-Hoc konferenco
Posnetek zaslona ga slabo prikazuje (ne vem, kako bi ga izboljšal), zato bom dnevnik zapisal takole:
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:12Sama Ad-Hoc konferenca:
Pravila za dohodne klice
Konfiguracija parametrov dohodnih klicev je potrebna, da lahko sprejmete klic v CMS. Kot ste videli pri nastavitvi LDAP, so bili vsi uporabniki uvoženi z domeno conf.pod6.cms.lab. Torej želite, da klici v to domeno ciljajo vsaj na prostore. Prav tako boste morali nastaviti pravila za vse, kar je namenjeno popolnoma kvalificiranemu imenu domene (in morda celo naslovu IP) vsakega od strežnikov CMS. Naš zunanji nadzor klicev, Unified CM, bo konfiguriral SIP trunke, namenjene vsakemu od strežnikov CMS posebej. Odvisno od tega, ali je cilj teh kanalov SIP naslov IP ali FQDN strežnika, se bo določilo, ali mora biti CMS konfiguriran za sprejemanje klicev, usmerjenih na njegov naslov IP ali FQDN.
Domena z vhodnim pravilom najvišje prioritete se uporablja kot domena za vse uporabniške prostore. Ko se uporabniki sinhronizirajo prek LDAP, CMS samodejno ustvari presledke, vendar le uporabniški del URI (coSpaceUriMapping), na primer user.space. del Celoten URI se ustvari na podlagi tega pravila. Pravzaprav, če bi se na tej točki prijavili v Web Bridge, bi videli, da Space URI nima domene. Če to pravilo nastavite kot najvišjo prioriteto, nastavite domeno za ustvarjene prostore konf.example.com.
Pravila za odhodne klice
Če želite uporabnikom omogočiti odhodne klice v gručo Unified CM, morate konfigurirati izhodna pravila. Domena končnih točk, registriranih pri Unified CM, kot je Jabber, je example.com. Klici v to domeno morajo biti usmerjeni kot standardni klici SIP v vozlišča za obdelavo klicev Unified CM. Glavni strežnik je cucm-01.example.com, dodatni pa cucm-02.example.com.
Prvo pravilo opisuje najenostavnejše usmerjanje klicev med strežniki gruče.
Polje Lokalno iz domene je odgovoren za to, kaj bo prikazano v klicateljevem SIP-URI za klicano osebo za simbolom "@". Če pustimo prazno, bo za simbolom "@" IP naslov CUCM, prek katerega poteka ta klic. Če določimo domeno, bo za simbolom "@" dejansko domena. To je potrebno za možnost povratnega klica, sicer povratni klic prek SIP-URI ime@ip-naslov ne bo mogoč.
Pokličite, ko je navedeno Lokalno iz domene
Pokliči kdaj NE označeno Lokalno iz domene
Prepričajte se, da ste za odhodne klice izrecno določili Encrypted ali Unencrypted, ker nič ne deluje s parametrom Auto.
Snemanje
Videokonference snema strežnik Record. Snemalnik je popolnoma enak Cisco Meeting Server. Snemalnik ne zahteva namestitve nobenih licenc. Licence za snemanje so potrebne za strežnike, ki izvajajo storitve CallBridge, tj. potrebna je licenca za snemanje, ki jo je treba uporabiti za komponento CallBridge in ne za strežnik, v katerem se izvaja snemalnik. Snemalnik se obnaša kot odjemalec XMPP (Extensible Messaging and Presence Protocol), zato mora biti strežnik XMPP omogočen na strežniku, ki gosti CallBridge.
Ker Imamo gručo in licenco je treba "raztegniti" na vse tri strežnike v gruči. Nato preprosto v vašem osebnem računu v licencah povežemo (dodamo) MAC naslove a-vmesnikov vseh CMS strežnikov, vključenih v gručo.
In to je slika, ki bi morala biti na vsakem strežniku v gruči
Na splošno obstaja več scenarijev za postavitev Snemalnika, vendar se bomo držali tega:
Preden nastavite Snemalnik, morate pripraviti prostor, kjer se bodo videokonference dejansko snemale. Pravzaprav tukaj , kako nastaviti vse snemanje. Osredotočam se na pomembne točke in podrobnosti:
1. Certifikat je bolje prenesti s prvega strežnika v gruči.
2. Napaka »Snemalnik ni na voljo« se lahko pojavi, ker je v zaupanju snemalnika navedeno napačno potrdilo.
3. Zapisovanje morda ne bo delovalo, če imenik NFS, določen za snemanje, ni korenski imenik.
Včasih je treba samodejno posneti konferenco enega določenega uporabnika ali prostora.
Za to se ustvarita dva profila klicev:
Z onemogočenim snemanjem
In s funkcijo samodejnega snemanja
Nato na zahtevani prostor »pripnemo« CallProfile s funkcijo samodejnega snemanja.
V CMS je tako uveljavljeno, da če je CallProfile izrecno vezan na kateri koli prostor ali prostor, potem ta CallProfile deluje samo v povezavi s temi posebnimi prostori. In če CallProfile ni vezan na noben prostor, potem se privzeto uporabi za tiste prostore, na katere ni izrecno vezan noben CallProfile.
Naslednjič bom poskušal opisati, kako se do CMS dostopa izven notranjega omrežja organizacije.
Vir:
Vir: www.habr.com