U ovom izdanju ću pokazati i objasniti neke nijanse postavljanja CMS servera u režimu otporne klase.
TeorijaOpćenito, postoje tri vrste rasporeda CMS servera:
- Single Combined(Jedinstveni kombinirani), tj. to je jedan server na kojem su pokrenute sve potrebne usluge. U većini slučajeva, ova vrsta rasporeda primjenjuju se samo za pristup unutarnjih klijenata i u malim okruženjima, gdje su ograničenja skalabilnosti i redundantnosti jednog servera neproblematična ili u situacijama gdje CMS obavlja samo određene funkcije, poput posebnih konferencija na Cisco UCM.
Približna shema rada:
- Single Split(Jedinstveno podijeljeno) proširuje prethodnu vrstu rasporeda dodajući zaseban server za vanjski pristup. U zastarjelim rasporedima to je značilo raspoređivanje CMS servera u demilitariziranoj zoni (DMZ), gdje bi vanjski klijenti mogli dobiti pristup, a jednog CMS servera u jezgru mreže, gdje pristupaju CMS unutarnji klijenti. Ova konkretna model rasporeda sada se zamjenjuje takozvanim tipom Single Edge, koji se sastoji od servera Cisco Expressway, koji ili imaju ili će imati mnoge od mogućnosti zaobiđanja vatrozida, tako da klijentima nije potrebno dodavati poseban granični server CMS.
Približna shema rada:
- Scalable and Resilient(Skalabilan i otporan) ova vrste uključuje redundanciju za svaki komponent, što omogućava sustavu da raste s vašim potrebama do maksimalnog kapaciteta, osiguravajući istovremeno redundanciju u slučaju kvara. Također koristi koncept Single Edge za osiguranje sigurnog vanjskog pristupa. Ovo je tip koji ćemo razmotriti u ovom izdanju. Ako razumijemo kako rasporediti klaster ove vrste, ne samo da ćemo razumjeti druge vrste rasporeda, nego i kako stvoriti klastere CMS servera uzimajući u obzir potencijalni rast potreba.
Prije nego što pređemo na raspoređivanje, potrebno je razumjeti neke osnovne stvari, a to su
Osnovni softverski sastavni dijelovi CMS:
- Baza podataka: omogućava kombiniranje određenih konfiguracija, kao što su korisničke grupe, prostori korisnika i sami korisnici. Podržava klasterizaciju samo za visoku dostupnost (jedan majstor).
- Call Bridge: usluga za audio- i videokonferencije koja omogućava potpunu kontrolu nad upravljanjem i obradom poziva i multimedijskim procesima. Podržava klasterizaciju za visoku dostupnost i skalabilnost.
- XMPP server: odgovara za registraciju i autentifikaciju klijenata koji koriste Cisco Meeting Application i\/ili WebRTC (real-time communication, ili jednostavno u pregledniku), kao i međukomponentno signaliziranje. Može se klasterizirati samo za visoku dostupnost.
- Web Bridge: omogućava pristup klijentima u WebRTC.
- Loadbalancer: osigurava jedinstvenu tačku povezivanja za aplikacije Cisco Meeting App u režimu Single Split. Osluškuje vanjsko sučelje i port za dolazne konekcije. Na jednak način, balansirnik opterećenja prihvaća dolazne TLS konekcije sa XMPP servera, putem kojih može prebacivati TCP konekcije od vanjskih klijenata.
U našem scenariju on neće biti potreban. - TURN server: osigurava tehnologiju zaobilaženja Firewall-a, omogućujući
izlaganje našeg CMS-a iza Firewall-a ili NAT-a za povezivanje vanjskih klijenata koji koriste Cisco Meeting App ili SIP uređaje. U našem scenariju on neće biti potreban. - Web Admin: administrativno sučelje i pristup API-ju, uključujući za specijalne konferencije Unified CM.
Načini konfiguracije
Za razliku od većine drugih proizvoda Cisco, Cisco Meeting Server podržava tri metode podešavanja, omogućavajući razmeštaj bilo koje vrste razmeštanja.
- Komandna linija (CLI): Sučelje komandne linije, poznato kao MMP, za zadatke inicijalne konfiguracije i certifikata.
- Web administrator: prvenstveno za konfiguraciju vezanu za CallBridge, posebno prilikom podešavanja jednog neklasteriziranog servera.
- REST API: koristi se za najsloženije zadatke podešavanja i zadatke vezane uz klastersku bazu podataka.
Osim gore navedenog, koristi se protokol SFTP za prenos datoteka — obično licenci, certifikata ili dnevnika — na CMS server i sa njega.
U vodičima za implementaciju od Cisco-a piše crno na belo da klaster treba rasporediti minimum od tri servera (nodova) u kontekstu baza podataka. Budući da samo sa neparnim brojem čvorova funkcioniše mehanizam izbora novog Master-a baze podataka, a uopšte Master baze podataka ima vezu sa većinom baze podataka CMS servera.
Kao što praksa pokazuje, dva servera (nodova) zapravo nisu dovoljna. Mehanizam odabira se aktivira prilikom ponovnog pokretanja Master servera; Slave server postaje Master isključivo nakon podizanja rebootanog servera. Međutim, ako u klasteru od dva servera Master server iznenada 'padne', Slave server neće postati Master. Ako 'padne' Slave, preostali Master server će postati Slave.
U kontekstu XMPP-a, potrebno je formirati klaster od tri servera, jer, na primjer, ako se XMPP usluga na jednom od servera sa statusom Lider isključi, preostali server će ostati u statusu Pratilac, a veza CallBridgea s XMPP će se prekinuti, jer se CallBridge povezuje isključivo s XMPP serverom sa statusom Lider. To je kritično, jer nijedan poziv neće proći.
Također, u ovim uputama za implementaciju demonstrira se klaster s jednim XMPP serverom.
S obzirom na prethodno rečeno, jasno je zašto: radi zato što je u režimu failover.
U našem slučaju, XMPP server će biti prisutan na sve tri nodove.
Pretpostavlja se da su sva tri naša servera podignuta.
DNS zapisi
Prije nego što pristupimo konfiguraciji servera, potrebno je osnovati DNS zapise. A i SRV tipova:
Napomena, da u našim DNS zapisima postoje dva domena example.com i conf.example.com. Example.com je domena koju mogu koristiti svi korisnici Cisco Unified Communication Managera, koji se vjerojatno nalazi u vašoj infrastrukturi ili će se s visokom vjerojatnošću pojaviti. Ili domen example.com odgovara istoj domeni koju korisnici koriste za svoje adrese e-pošte. Ili klijent Jabber na vašem prijenosnom računalu može imati URI user@example.com. Domen conf.example.com je domena koja će biti postavljena za korisnike Cisco Meeting Servera. Domen Cisco Meeting Servera bit će conf.example.com, tako da će za istog korisnika Jabber za pristup Cisco Meeting Serveru biti potrebno koristiti URI user@conf.example.com.
Osnovna konfiguracija
Sve postavke opisane u nastavku prikazane su na jednom serveru, ali ih je potrebno provesti na svakom serveru u klasteru.
QoS
Budući da CMS generira real-time Promet koji je osjetljiv na kašnjenje i gubitak paketa, u većini slučajeva preporučuje se postavljanje kvalitete usluge (QoS). Za to CMS podržava označavanje paketa s kodovima diferenciranih usluga (DSCP) koje generira. Iako prioritizacija prometa na temelju DSCP ovisi o tome kako se promet obrađuje mrežnim komponentama vaše infrastrukture, u našem slučaju postavit ćemo naš CMS s tipičnom raspodjelom prioriteta DSCP temeljenom na najboljim praksama QoS.
Na svakom poslužitelju unosimo ove naredbe
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ANa taj način, sav video promet označen je AF41 (DSCP 0x22), sav glasovni promet označen je EF (DSCP 0x2E), a ostale vrste prometa s niskim kašnjenjem, poput SIP-a i XMPP-a, koriste AF31 (DSCP 0x1A).
Provjeravamo:
NTP
Protokol vremena (NTP) važan je ne samo za osiguranje točnih vremenskih oznaka poziva i konferencija, već i za provjeru certifikata.
Dodajemo NTP poslužitelje u vašu infrastrukturu naredbom:
ntp server add U našem slučaju takva su dva poslužitelja, stoga će biti dvije naredbe.
Provjeravamo:
I postavljamo vremensku zonu za naš poslužitelj.
DNS
DNS poslužitelje u CMS dodajemo naredbom:
dns add forwardzone U našem slučaju takva su dva poslužitelja, stoga će biti dvije naredbe.
Provjeravamo:
Konfiguracija mrežnog sučelja
Konfiguriramo sučelje naredbom:
ipv4 add / Provjeravamo:
Ime poslužitelja (Hostname)
Ime poslužitelja postavljamo naredbom:
hostname I ponovno pokrećemo.
Time je osnovna konfiguracija završena.
Certifikati
TeorijaCisco Meeting Server zahtijeva šifriranu komunikaciju između različitih komponenti, i kao rezultat, X.509 certifikati su potrebni za sve implementacije CMS-a. Pomažu u osiguravanju povjerenja prema uslugama/poslužitelju od strane drugih poslužitelja/usluga.
Za svaku uslugu potreban je certifikat, međutim, stvaranje odvojenih certifikata za svaku uslugu može dovesti do zbrke i dodatnih složenosti. Srećom, možemo generirati par javnog i privatnog ključa certifikata, a zatim ih ponovno koristiti za više usluga. U našem slučaju, isti certifikat koristit će se za Call Bridge, XMPP poslužitelj, Web Bridge i Web Admin. Tako da je potrebno stvoriti par javnog i privatnog ključa certifikata za svaki poslužitelj u klasteru.
Klasterizacija baze podataka, međutim, ima neke specifične zahtjeve za certifikatima i stoga zahtijeva svoje vlastite certifikate, različite od certifikata drugih usluga. CMS koristi certifikat servera, koji je sličan certifikatima koje koriste drugi serveri, ali postoji i klijentski certifikat koji se koristi za veze s bazom podataka. Certifikati baze podataka koriste se kako za autentifikaciju, tako i za enkripciju. Umjesto da za povezivanje klijenta s bazom podataka daje korisničko ime i lozinku, predstavlja klijentski certifikat kojem server vjeruje. Svaki server u klasteru baze podataka koristi istu par javnog i privatnog ključa. Ovo omogućava svim serverima u klasteru da enkriptuju podatke tako da ih mogu dekriptovati samo drugi serveri koji također koriste istu par ključeva.
Kako bi rezervacija radila, klasteri baza podataka moraju se sastojati od najmanje 3 servera, ali ne više od 5, s maksimalnim vremenom prolaska signala u oba smjera od 200 ms između bilo koja dva člana klastera. Ova granica je stroža nego kod klasterizacije Call Bridge, stoga često predstavlja ograničavajući faktor u geografskim raspodijeljenim implementacijama.
Uloga baze podataka za CMS ima niz jedinstvenih zahtjeva. Za razliku od drugih uloga, zahtijeva klijentski i server certifikat, pri čemu klijentski certifikat ima određeno polje CN, koje se predstavlja serveru.
CMS koristi postgres bazu podataka s jednim glavnim i nekoliko potpuno identičnih replika. U svakom trenutku postoji samo jedna glavna baza podataka ("server baze podataka"). Ostali članovi klastera su replike ili "klijenti baze podataka".
Za klaster baze podataka potrebni su certifikat posvećenog servera i certifikat klijenta. Oni moraju biti potpisani certifikatima, obično unutarnjim privatnim centrom za certifikaciju. Budući da bilo koji član klastera baze podataka može postati glavni, parovi certifikata servera baze podataka i klijenta (koji sadrže javni i privatni ključ) moraju biti kopirani na sve servere kako bi mogli prihvatiti identitet klijenta ili servera baze podataka. Dodatno, korijenski certifikat CA mora biti učitan kako bi se osiguralo da se certifikati klijenta i servera mogu provjeriti.
Dakle, formiramo zahtjev za certifikat koji će koristiti sve usluge servera osim baze podataka (za to će biti zaseban zahtjev) naredbom u obliku:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
U CN pišemo općenito ime naših servera. Na primjer, ako su hostname'ovi naših servera server01, server02, server03, tada će CN biti server.example.com
Isto radimo na preostala dva servera s tom razlikom što će u naredbama biti odgovarajući "hostname'ovi".
Formiramo dva zahtjeva za certifikatima koji će koristiti usluga baze podataka naredbama u obliku:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresgdje dbclusterserver i dbclusterclient imena naših zahtjeva i budućih certifikata, hostname1(2)(3) imena odgovarajućih servera.
Ovu proceduru izvodimo samo na jednom serveru(!), a certifikate i odgovarajuće .key datoteke učitat ćemo na druge servere.
Uključivanje načina klijentskog certifikata u AD CS
Također je potrebno spojiti u jednu datoteku certifikate za svaki serverU *NIX:
cat server01.cer server02.cer server03.cer > server.cerU Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer I učitati na svaki server:
1. "Individualni" certifikat servera.
2. Korijenski certifikat (zajedno s međucertifikatima ako ih ima).
3. Certifikate za bazu podataka ("serverni" i "klijentski") i datoteke s ekstenzijom .key, koje su se formirale prilikom stvaranja zahtjeva za "serverni" i "klijentski" certifikat baze podataka. Ove datoteke moraju biti iste na svim serverima.
4. Datoteku svih tri "individualna" certifikata.
Na kraju bi trebala izgledati otprilike ovako datotska slika na svakom serveru.
Klaster baze podataka
Sada kada ste sve certifikate prenijeli na CMS poslužitelje, možete konfigurirati i uključiti klasterizaciju baze podataka između tri čvora. Prvi korak je odabrati jedan poslužitelj kao glavni čvor klastera baze podataka i potpuno ga konfigurirati.
Glavna baza podataka
Prvi korak u postavljanju replikacije baze podataka je odabir certifikata koji će se koristiti za bazu podataka. To se radi putem naredbe u obliku:
database cluster certsSada ćemo CMS-u navesti koji će sučelje koristiti za klasterizaciju baza podataka naredbom:
database cluster localnode aZatim inicijaliziramo bazu podataka klastera na glavnom poslužitelju naredbom:
database cluster initialize
Klijentski čvorovi baza podataka
Izvodimo istu proceduru, samo umjesto naredbe database cluster initialize input command like:
database cluster joingdje je ip address existing master IP adresa CMS poslužitelja na kojem je izvršena inicijalizacija klastera, jednostavno rečeno, Master.
Provjeravamo kako naš klaster baze podataka radi na svim poslužiteljima naredbom:
database cluster status
Isto radimo i na preostalom trećem poslužitelju.
Na kraju, to znači da naš prvi poslužitelj postaje Master, a ostali Slave.
Usluga za upravljanje putem weba
Uključujemo uslugu web administracije:
webadmin listen a 445Port 445 je odabran jer se port 443 koristi za pristup korisnika putem web klijenta.
Konfiguriramo Web Admin uslugu s datotekama certifikata naredbom u obliku:
webadmin certsI uključujemo Web Admin naredbom:
webadmin enable 
Ako je sve u redu, dobit ćemo linije SUCCESS u kojima je navedeno da je Web Admin ispravno konfiguriran za mrežu i certifikat. Provjeravamo funkcionalnost usluge putem web preglednika i unosimo adresu web administracije, na primjer: :445
Call Bridge klaster
Call Bridge je jedina usluga prisutna u svakom razmještaju CMS-a. Call Bridge je glavni mehanizam konferencijskog povezivanja. Također pruža SIP sučelje, tako da se pozivi mogu usmjeravati njemu ili iz njega, primjerice preko Cisco Unified CM-a.
Navedene naredbe trebate izvršiti na svakom poslužitelju s odgovarajućim certifikatima.
Dakle:
Povezujemo certifikate s uslugom Call Bridge naredbom u obliku:
callbridge certs []Povezujemo usluge CallBridge s traženim sučeljem naredbom:
callbridge listen aI ponovno pokrećemo uslugu pomoću komande:
callbridge restart 
Sada kada su naši Call Bridge-ovi postavljeni, možemo konfigurirati klasterizaciju Call Bridge-a. Klasterizacija Call Bridge-a razlikuje se od klasterizacije baze podataka ili XMPP-a. Call Bridge Cluster može podržavati od 2 do 8 čvorova bez ikakvih ograničenja. Pruža ne samo redundantnost, već i raspodelu opterećenja, omogućavajući aktivno raspoređivanje konferencija između Call Bridge servera putem inteligentne raspodele poziva. CMS ima dodatne funkcije, grupe Call Bridge i povezane funkcije koje se mogu koristiti za daljnje upravljanje.
Klasterizacija Call Bridge-a se uglavnom konfigurira putem web administrativnog sučelja.
Postupak opisan u nastavku treba izvršiti na svakom serveru u klasteru.
Dakle,
1. Prijavite se putem weba na Configuration > Cluster.
2. U Call Bridge identity navedite jedinstveno ime callbridge[01,02,03] koje odgovara imenu servera. Ova imena su proizvoljna, ali moraju biti jedinstvena za ovaj klaster. Opisna su jer označavaju da su ovo identifikatori servera [01,02,03].
3. U Clustered Call Bridges unesite URL-ove web administrativnog sučelja naših servera u klasteru, [01,02,03].example.com:445, u polje Address. Obavezno navedite port. Možete ostaviti Peer link SIP domain praznim.
4. Dodajte u poverenje CallBridge-u svaki server sertifikat, datoteku koja sadrži sve sertifikate naših servera koje smo spojili u ovu datoteku na samom početku, pomoću komande:
callbridge trust clusterI ponovno pokrećemo uslugu pomoću komande:
callbridge restart 
Na kraju, na svakom serveru bi trebao izgledati ovako:
XMPP Cluster
XMPP usluga u CMS-u koristi se za obradu celokupne registracije i autentifikacije za Cisco Meeting Apps (CMA), uključujući web-klijent CMA WebRTC. Sam Call Bridge takođe deluje kao XMPP klijent u svrhe autentifikacije i stoga mora biti konfigurisan kao i drugi klijenti. Otpornost XMPP-a je funkcija koja se podržava u proizvodnim okruženjima počevši od verzije 2.1.
Navedene naredbe trebate izvršiti na svakom poslužitelju s odgovarajućim certifikatima.
Dakle:
Povezujemo sertifikate sa XMPP uslugom pomoću komande:
xmpp certs []Zatim odredite slušajući interfejs komandom:
xmpp listen aZa XMPP uslugu potreban je jedinstveni domen. To je prijava za korisnike. Drugim riječima, kada korisnik pokušava da se prijavi putem CMA aplikacije (ili putem WebRTC klijenta), unosi userID@logindomain. U našem slučaju to će biti userid@conf.example.com. Zašto to nije samo example.com? U našem konkretnom razmještaju odabrali smo naš domen Unified CM, koji će korisnici Jabbera koristiti u Unified CM-u, kao example.com, pa nam je potreban drugi domen za korisnike CMS-a, kako bismo usmjerili pozive u CMS i iz CMS-a preko SIP domena.
Postavite XMPP domen s komandom koja izgleda ovako:
xmpp domainI aktiviramo XMPP uslugu komandom:
xmpp enableU XMPP usluzi potrebno je kreirati vjerodajnice za svaki Call Bridge, koje će se koristiti za registraciju u XMPP uslugu. Ova imena su proizvoljna (i nisu povezana s jedinstvenim imenima koje ste postavili za clustering Call Bridgova). Na jednom XMPP serveru potrebno je dodati tri Call Bridga, a zatim unijeti te vjerodajnice na drugim XMPP serverima u klasteru, budući da ova konfiguracija nije pohranjena u klaster bazi podataka. Kasnije ćemo svakoj Call Bridge postaviti korištenje ovog imena i tajne za registraciju u XMPP uslugu.
Sada trebamo postaviti XMPP uslugu na prvom serveru s tri Call Bridga callbridge01, callbridge02 i callbridge03. Svakoj računu bit će dodijeljene nasumične lozinke. Kasnije će biti unesene na drugim Call Bridge serverima za ulazak na ovaj XMPP server. Unosimo sljedeće komande:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Na kraju provjeravamo šta smo dobili komandom:
xmpp callbridge list 
Upravo ovakav scenario trebao bi biti na ostalim serverima nakon postupaka opisanih u nastavku.
Dalje dodajemo na preostala dva servera potpuno iste postavke, samo s komandom
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Tajnu dodajemo vrlo pažljivo, kako ne bismo slučajno unijeli dodatne razmake.
Na kraju, na svakom serveru trebala bi biti ovakva ista situacija:
Dalje, na svim serverima klastera, označavamo u povjerenju datoteku koja sadrži sve tri certifikate, ranije kreiranu komandom koja izgleda ovako:
xmpp cluster trustAktiviramo xmpp klaster mod na svim serverima klastera komandom:
xmpp cluster enableNa prvom serveru klastera iniciramo stvaranje xmpp klastera komandnom:
xmpp cluster initializeNa ostalim serverima dodajemo u xmpp klaster komandom:
xmpp cluster joinProvjeravamo na svakom serveru uspješnost stvaranja XMPP klastera na svakom serveru komandama:
xmpp status
xmpp cluster statusPrvi server:
Drugi server:
Treći server:
Povezivanje Call Bridge-a na XMPP
Sada kada je XMPP klaster pokrenut, potrebno je konfigurirati usluge Call Bridge za povezivanje s XMPP klasterom. Ova konfiguracija se vrši putem web administratora.
Ulazimo na svakom serveru u Configuration > General i u polje Unique Call Bridge name upisujemo odgovarajuće serveru jedinstvene nazive Call Bridge callbridge[01,02,03]. U polje Domena conf.example.ru i odgovarajuće lozinke, koje se mogu pogledati
na bilo kojem serveru klastera komandom:
xmpp callbridge list 
Polje «Server» ostavljamo praznim, Callbridge izvršit će pretragu DNS SRV za _xmpp-component._tcp.conf.example.com, kako bi pronašao dostupni XMPP server. IP adrese povezivanja callbridge-a mogu se razlikovati na svakom serveru, to ovisi o tome koje vrijednosti se vraćaju na zahtjev za zapisom _xmpp-component._tcp.conf.example.com callbridge-u, što zauzvrat ovisi o postavkama prioriteta za ovaj DNS zapis.
Zatim prelazimo u Status > General, kako bismo se uvjerili da li je usluga Call Bridge uspješno povezana s uslugom XMPP.
Web Bridge
Na svakom serveru klastera uključujemo uslugu Web Bridge komandom:
webbridge listen a:443Konfiguriramo Web Bridge uslugu s datotekama certifikata komandom:
webbridge certsWeb Bridge podržava HTTPS. Preusmjerit će HTTP na HTTPS ako je konfiguriran za korištenje ‘http-redirect’.
Da biste omogućili preusmjeravanje HTTP-a, koristite sljedeću komandu:
webbridge http-redirect enableDa bi Call Bridge dao do znanja da Web Bridge može vjerovati vezama iz Call Bridge, koristite komandu:
webbridge trustgdje je to datoteka koja sadrži sve tri certifikata sa svakog servera u klasteru.
Ovakva slika treba biti na svakom serveru klastera.
Sada trebamo stvoriti korisnika s ulogom «appadmin», on nam je potreban kako bismo mogli konfigurirati naš klaster(!), a ne svaki server klastera pojedinačno, tako da će se postavke primjenjivati jednako na svaki server, a bit će izvršene samo jednom.
Za daljnju konfiguraciju koristit ćemo .
Za autorizaciju odabiremo Basic u odjeljku Authorization
Za ispravno slanje naredbi na CMS poslužitelje, potrebno je postaviti odgovarajuću kodiranje.
Specifikujemo Webbridge pomoću naredbe. POST s parametrom url i vrijednosti.
U samom webbridgeu navodimo potrebne parametre: javni pristup, zaštićeni pristup i ostalo.
Call Bridge Grupe
Prema zadanim postavkama, CMS ne koristi uvijek najučinkovitije dostupne resurse konferencijske veze.
Na primjer, za sastanak s tri sudionika, svaki sudionik može biti na tri različita Call Bridgea. Da bi se ta tri sudionika mogla međusobno povezati, Call Bridgeovi automatski uspostavljaju veze između svih poslužitelja i klijenata unutar istog prostora, kako bi to izgledalo kao da su svi klijenti na istom poslužitelju. Nažalost, mana ovog pristupa je što će jedna konferencija od 3 osobe sada koristiti 9 medija portova. Ovo je očigledno neučinkovita upotreba resursa. Osim toga, kada je Call Bridge zaista preopterećen, zadani mehanizam je da nastavi primati pozive i pružati usluge smanjenog kvaliteta svim pretplatnicima tog Call Bridgea.
Ovi problemi se rješavaju uz pomoć funkcije Call Bridge Group. Ova funkcija uvedena je u verziji 2.1 softvera Cisco Meeting Server i proširena je za podršku ravnomjernog opterećenja za dolazne i odlazne pozive, Cisco Meeting App (CMA), uključujući sudionike WebRTC.
Kako bi se riješio problem ponovnog povezivanja, uvedena su tri prilagodljiva ograničenja opterećenja za svaki Call Bridge:
LoadLimit — to je maksimalno numeričko opterećenje za određeni Call Bridge. Svaka platforma ima preporučenu granicu opterećenja, na primjer 96000 za CMS1000 i 1.25 GHz po virtualnom procesoru za virtualnu mašinu. Različiti pozivi troše određenu količinu resursa ovisno o razlučivosti i brzini kadra sudionika.
NewConferenceLoadLimitBasisPoints (prema zadanim postavkama 50% loadLimit) — postavlja granicu opterećenja poslužitelja nakon koje se nove konferencije odbacuju.
ExistingConferenceLoadLimitBasisPoints (prema zadanim postavkama 80% od loadLimit) — vrijednost opterećenja poslužitelja nakon koje će sudionici koji se pridružuju postojećoj konferenciji biti odbijeni.
Iako je ova funkcija razvijena za raspodjelu poziva i opterećenja, druge grupe, poput TURN servera, Web Bridge servera i uređaja za snimanje, također se mogu dodijeliti Call Bridge grupama kako bi se pravilno grupirali za optimalnu upotrebu. Ako nijedan od tih objekata nije dodijeljen grupi poziva, pretpostavlja se da su dostupni svim serverima bez ikakvog posebnog prioriteta.
Ove opcije se podešavaju ovdje: :445/api/v1/system/configuration/cluster
Nakon toga navodimo kojem callbridge-u pripada koja callbridge grupa:
Prvi callbridge
Drugi callbridge
Treći callbridge
Na taj način smo konfigurirali Call Bridge grupu za efikasniju upotrebu resursa Cisco Meeting Server-a.
Uvoz korisnika iz Active Directory
Web Admin usluga ima sekciju za LDAP konfiguraciju, ali ne pruža složene opcije konfiguracije, a informacije se ne pohranjuju u klaster bazi podataka, pa će se konfiguracija morati raditi ili ručno na svakom serveru putem web sučelja, ili putem API-a, i kako bismo izbjegli višekratne korake, podatke ćemo unijeti putem API-a.
Koristeći URL za pristup :445/api/v1/ldapServers kreiramo objekat LDAP server-a, specificirajući parametre kao što su:
- IP adresa servera
- broj porta
- korisničko ime
- lozinka
- sigurno
Sigurno — true ili false biramo u zavisnosti od porta, 389 — nezaštićen, 636 — zaštićen.
Mapiramo LDAP parametre izvora na atribute u Cisco Meeting Server-u.
Mapiranje LDAP usklađuje atribute u LDAP direktoriju s atributima u CMS-u. Uglavnom atributi:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Opis atributaJID predstavlja identifikator prijave korisnika u CMS-u. Budući da je ovo LDAP server Microsoft Active Directory, JID CMS-a se usklađuje s sAMAccountName u LDAP-u, koji je u osnovi identifikator prijave korisnika u Active Directory-u. Također imajte na umu da uzimate sAMAccountName i dodajete domenu conf.pod6.cms.lab na njegov kraj, jer je to prijava koju će vaši korisnici koristiti za ulazak u CMS.
nameMapping uskladjuje ono što se nalazi u polju Active Directory displayName s poljem imenom korisnika CMS-a.
coSpaceNameMapping stvara ime prostora CMS-a na temelju polja displayName. Ovaj atribut zajedno s atributom coSpaceUriMapping je ono što je potrebno za kreiranje prostora za svakog korisnika.
coSpaceUriMapping definira korisnički dio URI povezan s osobnim prostorom korisnika. Neki domeni mogu biti konfigurirani za odlazak u prostor. Ako se korisnički dio podudara s ovim poljem za jednu od tih domena, poziv će biti usmjeren u prostor tog korisnika.
coSpaceSecondaryUriMapping definira drugi URI za postizanje prostora. Može se koristiti za dodavanje numeričkog pseudonima za usmjeravanje poziva u prostor uvezenog korisnika kao zamjenu za alfanumerički URI definiran u parametru coSpaceUriMapping.
LDAP poslužitelj i LDAP mapiranje su postavljeni. Sada je potrebno povezati ih zajedno stvarajući LDAP izvor.
Koristeći URL za pristup :445/api/v1/ldapSource kreiramo objekt LDAP Source, navodeći takve parametre kao:
- Poslužitelj
- mapping
- baseDn
- filter
Sada kada je LDAP konfiguracija završena, možemo izvršiti operaciju ručne sinhronizacije.
To radimo ili putem web sučelja svakog poslužitelja pritiskom na Sinkroniziraj sada u odjeljku Active Directory
ili putem API-ja naredbom POST koristeći URL adresu za pristup :445/api/v1/ldapSyncs
Ad-Hoc konferencije
Što je to?U tradicionalnom smislu, konferencija je kada dvoje sudionika razgovaraju jedni s drugima, a jedan od sudionika (koristeći uređaj registriran u Unified CM) pritisne gumb 'Konferencija', zove drugu osobu i nakon razgovora s tom trećom stranom ponovno pritisne gumb 'Konferencija' kako bi se pridružio svim sudionicima trostruke konferencije.
Ad-Hoc konferencija razlikuje se od zakazane konferencije u CMS-u jer Ad-Hoc konferencija nije samo SIP poziv za CMS. Kada inicijator konferencije drugi put pritisne gumb 'Konferencija' kako bi pozvao sve na isto okupljanje, Unified CM mora izvršiti API poziv za CMS kako bi stvorio konferenciju 'u hodu', na koju se zatim prebacuju svi pozivi. Sve se to događa neprimjetno za sudionike.
To znači da Unified CM mora konfigurirati API vjerodajnice i adresu / port WebAdmin usluge, kao i SIP-Trunk izravno na CMS poslužitelju da bi nastavio poziv.
Po potrebi, CUCM može dinamički stvoriti prostor u CMS-u kako bi svi pozivi mogli doći do CMS-a i odgovarati pravilima dolaznih poziva koja su namijenjena prostorima.
Integracija s CUCM postavlja se na isti način kao što je opisano u članku s izuzetkom što je potrebno kreirati tri trunk-a za CMS na Cisco UCM, tri Conference Bridge-a, u SIP Security Profile navesti tri Subject Name-a, Route Group, Route List, Media Resource Group i Media Resource Group List, a u Cisco Meeting Server-u malo dodati pravila usmjeravanja.
SIP Security Profile:
Trunk-ovi:
Svaki trunk izgleda identično:
Conference Bridge
Svaki Conference Bridge izgleda identično:
Route Group
Route List
Media Resource Group
Media Resource Group List
Pravila poziva
Za razliku od naprednijih sustava upravljanja pozivima, kao što su Unified CM ili Expressway, za nove pozive CMS pregledava domenu samo u polju SIP Request-URI. Dakle, ako je SIP INVITE namijenjen za sip:user@domain.com, CMS se brine samo za domain.com. CMS se ovim pravilima vodi pri određivanju gdje usmjeriti poziv:
1. Prvo, CMS pokušava uskladiti SIP domenu s domenama postavljenim u pravilima za obradu dolaznih poziva. Tada se ti pozivi mogu usmjeriti u („ciljne“) prostore ili specificiranim korisnicima, unutarnjem IVR-u ili izravnim integriranim adresatima Microsoft Lync/Skype za posao (S4B).
2. Ako u pravilima za obradu dolaznih poziva nema podudaranja, CMS će pokušati uskladiti domenu postavljenu u tablici za preusmjeravanje poziva. Ako se usklađivanje uspostavi, pravilo može izričito odbiti poziv ili preusmjeriti poziv. U ovom trenutku, CMS može prepraviti domenu, što je ponekad korisno za pozive u domene Lync. Također možete odabrati pass throw, što znači da nijedno polje neće biti dodatno izmijenjeno, ili koristiti unutarnju pretplatničku grupu CMS-a. Ako u pravilima za preusmjeravanje poziva nema podudaranja, prema zadanim postavkama koristi se odbijanje poziva. Imajte na umu da u CMS-u, iako je poziv „preusmjeren“, multimedija se još uvijek veže za CMS, što znači da će se nalaziti u putu signalizacije i multimedijalnog prometa.
Tada samo preusmjereni pozivi podliježu pravilima odlaznih poziva. Ove opcije određuju primatelje, gdje slati pozive, tip veze (bilo da je u pitanju novi Lync poziv ili standardni SIP) i sve transformacije koje se mogu izvršiti ako u pravilima za preusmjeravanje poziva nije odabrano prosljeđivanje.
Evo samog loga onoga što se događa pri Ad-Hoc konferenciji
Na screenshotu se slabo vidi (ne znam kako to bolje prikazati), pa ću log napisati ovako:
Info 127.0.0.1:35870: API korisnik "api" stvorio novi prostor 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info neuspjeh poziva create - nije moguće pronaći coSpace -- pokušava se dohvatiti iz baze podataka
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 Interni G
Info 127.0.0.1:35872: API korisnik "api" stvorio novi poziv 93bfb890-646c-4364-8795-9587bfdc55ba
Info poziv 7: dolazni SIP poziv od "sip:672@172.x.x.x" na lokalni URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API call leg bc0be45e-ce8f-411c-be04-594e0220c38e u pozivu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API poziv 93bfb890-646c-4364-8795-9587bfdc55ba)
Info konferencija 434f88d0-8441-41e1-b6ee-6d1c63b5b098 ima kontrolu/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info konferencija 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nazvana "001036270012"
Info poziv 7: konfiguriran - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e s SIP call ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info poziv 7: postavljanje UDT RTP sesije za DTLS (kombinirani mediji i kontrola)
Info konferencija "001036270012": nekriptirane pozivne noge su sada prisutne
Info učesnik "672@172.x.x.x" pridružio se prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info učesnik "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) pridružio se konferenciji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 putem SIP-a
Info poziv 8: dolazni SIP poziv od "sip:690@172.x.x.x" na lokalni URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API call leg db61b242-1c6f-49bd-8339-091f62f5777a u pozivu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API poziv 93bfb890-646c-4364-8795-9587bfdc55ba)
Info poziv 8: konfiguriran - API call leg db61b242-1c6f-49bd-8339-091f62f5777a s SIP call ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info poziv 8: postavljanje UDT RTP sesije za DTLS (kombinirani mediji i kontrola)
Info poziv 9: dolazni SIP poziv od "sip:673@172.x.x.x" na lokalni URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a u pozivu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API poziv 93bfb890-646c-4364-8795-9587bfdc55ba)
Info poziv 9: konfiguriran - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a s SIP call ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info poziv 9: postavljanje UDT RTP sesije za DTLS (kombinirani mediji i kontrola)
Info poziv 8: nadoknađivanje dalekog kraja koji ne odgovara vrstama tereta
Info učesnik "690@172.x.x.x" pridružio se prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info učesnik "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) pridružio se konferenciji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 putem SIP-a
Info poziv 7: nadoknađivanje dalekog kraja koji ne odgovara vrstama tereta
Info poziv 8: neprilagođene vrste tereta način 1/0
Info poziv 8: odgovaranje na ponudu u neprilagođenim vrstama tereta načinu
Info poziv 8: primljena usvojena ponuda s jednim codec-om
Info poziv 8: neprilagođene vrste tereta način 1/0
Info poziv 8: odgovaranje na ponudu u neprilagođenim vrstama tereta načinu
Info poziv 8: slanje odgovora na dodatnu ponudu s jednim codec-om
Info poziv 9: nadoknađivanje dalekog kraja koji ne odgovara vrstama tereta
Info učesnik "673@172.x.x.x" pridružio se prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info učesnik "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) pridružio se konferenciji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 putem SIP-a
Info poziv 9: BFCP (uloga klijenta) sada aktivna
Info poziv 9: slanje BFCP pozdrava kao klijent nakon primitka pozdrava kada BFCP nije aktivan
Info poziv 9: BFCP (uloga klijenta) sada aktivna
Info poziv 7: završava; udaljeni SIP završava - povezan 0:13
Info poziv 7: uništavanje API call leg bc0be45e-ce8f-411c-be04-594e0220c38e
Info učesnik "672@x.x.x" napustio prostor 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info poziv 9: na čekanju
Info poziv 9: neprilagođene vrste tereta način 1/0
Info poziv 9: odgovaranje na ponudu u neprilagođenim vrstama tereta načinu
Info poziv 8: na čekanju
Info poziv 8: primljena usvojena ponuda s jednim codec-om
Info poziv 8: neprilagođene vrste tereta način 1/0
Info poziv 8: odgovaranje na ponudu u neprilagođenim vrstama tereta načinu
Info poziv 8: slanje odgovora na dodatnu ponudu s jednim codec-om
Info poziv 9: završava; udaljeni SIP završava - povezan 0:12Ad-Hoc konferencija:
Pravila dolaznih poziva
Postavljanje parametara dolaznih poziva je nužno za mogućnost primanja poziva u CMS-u. Kao što ste vidjeli u postavci LDAP, svi korisnici su uvezeni s domenom conf.pod6.cms.lab. Stoga, najmanje, želite da pozivi u ovu domenu budu namijenjeni prostorima. Također, trebate postaviti pravila za sve što je namijenjeno punom imenu domene (i možda čak i za IP adresu) svakog od CMS servera. U našoj vanjskoj kontroli poziva, Unified CM će imati postavljene SIP trunkove, namijenjene svakoj od CMS servera pojedinačno. Ovisno o tome da li je odredište ovih SIP trunkova IP adresa ili potpuno ime servera, odredit će se treba li CMS postaviti za primanje poziva koji su upućeni na njegovu IP adresu ili potpuno ime domene.
Domena koja ima pravilo dolaznog prometa s najvišim prioritetom koristi se kao domena za sve korisničke prostore. Kada se korisnici sinkroniziraju putem LDAP-a, CMS automatski stvara prostore, ali samo korisnički dio URI-a (coSpaceUriMapping), primjerice, user.space. Dio potpunog URI-a se stvara na temelju ovog pravila. U stvarnosti, da ste se prijavili u Web Bridge u ovoj fazi, vidjeli biste da prostor URI nema domenu. Postavljanjem ovog pravila kao najvišeg prioriteta, definirate domenu za generirane prostore kao conf.example.com.
Pravila odlaznih poziva
Kako bi korisnicima omogućili odlazne pozive u Unified CM klaster, potrebno je postaviti pravila odlaznih veza. Domenama krajnjih tačaka registriranih u Unified CM, poput Jabbera, je example.com. Pozivi u ovu domenu trebaju biti upućeni kao standardni SIP pozivi na čvora za obradu poziva Unified CM. Glavni server je cucm-01.example.com, a dodatni cucm-02.example.com.
Prvo pravilo opisuje najjednostavnije usmjeravanje poziva između servera klastera.
Polje Local from domain odgovara za to što će se prikazivati u SIP-URI pozivatelja kod onoga kome se zove nakon simbola „@“. Ako ga ostavimo praznim, nakon simbola „@“ će biti IP adresa CUCM-a preko kojeg ovaj poziv prolazi. Ako navedemo domen, nakon simbola „@“ će biti domena. To je potrebno kako bismo imali mogućnost da se pozovemo natrag, inače se ne može nazvati natrag po SIP-URI ime@ip-adresa.
Poziv kada je naveden Local from domain
Poziv kada NE navedeno Local from domain
Obavezno jasno navedite Encrypted ili Unencrypted za odlazne pozive, jer s parametrom Auto ništa ne funkcioniše.
Snimi
Snimanje videokonferencija vrši Record-server. Recorder predstavlja isti onaj Cisco Meeting Server. Recorder ne zahtijeva instalaciju nikakvih licenci. Licence za snimanje su potrebne poslužiteljima na kojima su pokrenute usluge CallBridge, tj. licenca za Snimanje je potrebna i treba se primijeniti na komponentu CallBridge, a ne na poslužitelj na kojem je pokrenut Recorder. Recorder se ponaša kao klijent proširene protokola razmjene poruka i prisutnosti (XMPP), stoga XMPP poslužitelj mora biti omogućen na poslužitelju na kojem se nalazi CallBridge.
Budući da imamo klaster i licencu treba „rasporediti“ na sve tri poslužitelja klastera. Samo u osobnom računu u licencama povezujemo (dodajemo) MAC adrese a-interface svih CMS poslužitelja uključenih u klaster.
I ovakva slika treba biti na svakom poslužitelju klastera
Uopće postoji nekoliko scenarija za postavljanje Recordera, ali ćemo se pridržavati ovog:
Prije nego što počnete konfigurirati Recorder, potrebno je pripremiti mjesto gdje će se zapravo snimati videokonferencije. Dakle, ovo je , kako konfigurirati cijelo Snimanje. Fokusirat ću se na važne momente i detalje:
1. Bolje je dati sertifikat s prvog poslužitelja u klasteru.
2. Greška „Recorder unavailable“ može se pojaviti zato što je u Recorder Trust naveden pogrešan sertifikat.
3. Snimanje možda neće raditi ako za snimanje nije navedena korijenska mapa u NFS-u.
Ponekad se javlja potreba za automatskim snimanjem konferencije jednog određenog korisnika ili prostora.
Za to se kreiraju dva CallProfilea:
S isključenom funkcijom snimanja
I s automatskom funkcijom snimanja
Nakon toga 'priključujemo' CallProfile s automatskom funkcijom snimanja na željeni prostor.
U CMS-u je pravilo da ako je CallProfile izričito povezan s bilo kojim prostorom ili prostorima, tada taj CallProfile radi isključivo za te specifične prostore. A ako CallProfile nije povezan s nijednim prostorom, onda se prema zadanim postavkama primjenjuje na one prostore za koje nijedan CallProfile nije izričito povezan.
Sljedeći put ću pokušati opisati na koji se način može pristupiti CMS-u izvan unutarnje mreže organizacije.
Izvori:
Izvor: habr.com
