U ovom broju ću pokazati i objasniti neke od zamršenosti postavljanja CMS servera u režimu klastera za prelazak sa greškom.
TeorijaGeneralno, postoje tri tipa implementacije CMS servera:
- Single Combined(Pojedinačno kombinovano), tj. ovo je jedan server na kojem rade svi potrebni servisi. U većini slučajeva, ova vrsta implementacije je prikladna samo za interni pristup klijenta iu manjim okruženjima gdje ograničenja skalabilnosti i redundantnosti jednog poslužitelja nisu kritični problem, ili u situacijama kada CMS obavlja samo određene funkcije, kao što je ad hoc konferencije o Cisco UCM.
Okvirna šema rada:
- Single Split(Single Split) proširuje prethodni tip implementacije dodavanjem zasebnog servera za vanjski pristup. U naslijeđenim implementacijama, to je značilo postavljanje CMS servera u demilitarizirani mrežni segment (DMZ) gdje bi mu vanjski klijenti mogli pristupiti i jednog CMS servera u jezgru mreže gdje bi interni klijenti mogli pristupiti CMS-u. Ovaj konkretni model implementacije sada je zamijenjen tzv Single Edge, koji se sastoji od servera Cisco Expressway, koji imaju ili će imati mnoge od istih mogućnosti zaobilaženja zaštitnog zida tako da klijenti ne moraju da dodaju namjenski rubni CMS server.
Okvirna šema rada:
- Skalabilan i otporan(Skalabilan i otporan na greške) Ovaj tip uključuje redundantnost za svaku komponentu, omogućavajući sistemu da raste s vašim potrebama do svog maksimalnog kapaciteta, istovremeno pružajući redundantnost u slučaju kvara. Takođe koristi koncept Single Edge da obezbedi siguran eksterni pristup. Ovo je tip koji ćemo pogledati u ovoj epizodi. Ako razumijemo kako da implementiramo ovu vrstu klastera, ne samo da ćemo razumjeti druge tipove implementacije, već ćemo također moći razumjeti kako kreirati klastere CMS servera kako bi se prilagodili potencijalnom rastu potražnje.
Prije nego što pređete na implementaciju, morate razumjeti neke osnovne stvari, naime
Glavne komponente CMS softvera:
- baza podataka: Omogućava vam kombiniranje nekih konfiguracija, kao što su plan biranja, korisnički prostori i sami korisnici. Podržava grupisanje za visoku dostupnost (samo jedan master).
- Call Bridge: usluga za audio i video konferencije koja pruža potpunu kontrolu nad upravljanjem i obradom poziva i multimedijalnih procesa. Podržava grupisanje za visoku dostupnost i skalabilnost.
- XMPP server: odgovoran za registraciju i autentifikaciju klijenata koji koriste Cisco Meeting aplikaciju i/ili WebRTC(komunikacija u realnom vremenu ili jednostavno u pretraživaču), kao i interkomponentna signalizacija. Može se grupirati samo radi visoke dostupnosti.
- Web Bridge: Omogućava pristup klijentu WebRTC-u.
- Loadbalancer: Obezbeđuje jednu tačku veze za Cisco Meeting aplikacije u režimu jedne podele. Sluša eksterni interfejs i port za dolazne veze. Jednako tako, balansator opterećenja prihvata dolazne TLS veze sa XMPP servera, preko kojih može da prebaci TCP veze sa eksternih klijenata.
U našem scenariju to neće biti potrebno. - TURN server: Pruža tehnologiju zaobilaženja zaštitnog zida koja omogućava
postavite naš CMS iza zaštitnog zida ili NAT-a da povežete eksterne klijente koristeći Cisco Meeting aplikaciju ili SIP uređaje. U našem scenariju to neće biti potrebno. - Web Admin: Administrativno sučelje i pristup API-ju, uključujući za posebne Unified CM konferencije.
Načini konfiguracije
Za razliku od većine drugih Cisco proizvoda, Cisco Meeting Server podržava tri metode konfiguracije kako bi se prilagodio bilo kojoj vrsti implementacije.
- Komandna linija (CLI): Sučelje komandne linije poznato kao MMP za početnu konfiguraciju i zadatke certifikata.
- Web Administrator: Prvenstveno za konfiguracije vezane za CallBridge, posebno kada se postavlja jedan server koji nije klaster.
- REST API: Koristi se za najsloženije zadatke konfiguracije i zadatke vezane za klastersku bazu podataka.
Pored navedenog, koristi se i protokol SFTP za prenos datoteka—obično licenci, sertifikata ili evidencija—na i sa CMS servera.
U vodičima za implementaciju iz Cisco-a piše na bijelom i engleskom da klaster treba biti raspoređen najmanje tri serveri (čvorovi) u kontekstu baza podataka. Jer Samo sa neparnim brojem čvorova će funkcionirati mehanizam za odabir novog Master baze podataka, a generalno Database Master ima vezu sa većinom baze podataka CMS servera.
I kao što praksa pokazuje, dva servera (čvora) zaista nisu dovoljna. Mehanizam odabira radi kada se Master ponovo pokrene, Slave server postaje Master tek nakon što se ponovo pokrene server. Međutim, ako se u grupi od dva servera glavni server iznenada ugasi, tada Slave server neće postati Master, a ako se Slave ugasi, tada će preostali Master server postati Slave.
Ali u kontekstu XMPP-a, zaista bi bilo potrebno sastaviti klaster od tri servera, jer ako, na primjer, onemogućite uslugu XMPP na jednom od servera na kojima je XMMP u statusu Leader, tada će na preostalom serveru XMPP ostati u statusu Follower i CallBridge veze sa XMPP-om će pasti, jer CallBridge se povezuje isključivo na XMPP sa Leader statusom. A ovo je kritično, jer... ni jedan poziv neće proći.
Takođe u istim vodičima za implementaciju je prikazan klaster sa jednim XMPP serverom.
A uzimajući u obzir gore navedeno, postaje jasno zašto: radi jer je u režimu prelaska sa greške.
U našem slučaju, XMPP server će biti prisutan na sva tri čvora.
Pretpostavlja se da su sva tri naša servera uključena.
DNS zapisi
Pre nego što počnete da podešavate servere, potrebno je da kreirate DNS zapise А и SRV vrste:
Imajte na umu da u našim DNS zapisima postoje dvije domene example.com i conf.example.com. Example.com je domen koji svi pretplatnici Cisco Unified Communication Managera mogu koristiti za svoje URI-je, koji je najvjerovatnije prisutan u vašoj infrastrukturi ili će vjerovatno biti prisutan. Ili example.com odgovara istoj domeni koju korisnici koriste za svoje adrese e-pošte. Ili Jabber klijent na vašem laptopu može imati URI [email zaštićen]. Domain conf.example.com je domena koja će biti konfigurisana za korisnike Cisco Meeting Servera. Domena Cisco Meeting Servera će biti conf.example.com, tako da bi se za istog korisnika Jabber-a, user@ URI trebao koristiti za prijavu na Cisco Meeting Serverconf.example.com.
Osnovna konfiguracija
Sve dole opisane postavke su prikazane na jednom serveru, ali ih je potrebno izvršiti na svakom serveru u klasteru.
QoS
Pošto CMS generiše u realnom vremenu saobraćaj osjetljiv na kašnjenja i gubitak paketa, u većini slučajeva se preporučuje konfiguriranje kvalitete usluge (QoS). Da bi se to postiglo, CMS podržava označavanje paketa sa kodovima diferenciranih usluga (DSCP) koje generiše. Iako određivanje prioriteta saobraćaja zasnovano na DSCP-u ovisi o tome kako promet obrađuju mrežne komponente vaše infrastrukture, u našem slučaju ćemo konfigurirati naš CMS s tipičnim DSCP prioritetom na temelju najbolje prakse QoS-a.
Na svakom serveru ćemo unijeti ove komande
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ATako je sav video saobraćaj bio označen kao AF41 (DSCP 0x22), sav govorni saobraćaj je imao oznaku EF (DSCP 0x2E), ostali tipovi saobraćaja male latencije kao što su SIP i XMPP koriste AF31 (DSCP 0x1A).
Provjeravamo:
NTP
Network Time Protocol (NTP) je važan ne samo za pružanje tačnih vremenskih oznaka za pozive i konferencije, već i za verifikaciju sertifikata.
Dodajte NTP servere svojoj infrastrukturi komandom poput
ntp server add <server>
U našem slučaju postoje dva takva servera, tako da će biti dva tima.
Provjeravamo:
I postavite vremensku zonu za naš server
DNS
Dodamo DNS servere u CMS naredbom poput:
dns add forwardzone <domain-name> <server ip>
U našem slučaju postoje dva takva servera, tako da će biti dva tima.
Provjeravamo:
Konfiguracija mrežnog interfejsa
Interfejs konfigurišemo naredbom kao što je:
ipv4 <interface> add <address>/<prefix length> <gateway>
Provjeravamo:
Ime servera (ime hosta)
Ime servera postavljamo naredbom poput:
hostname <name>
I ponovo pokrećemo.
Ovim je završena osnovna konfiguracija.
Sertifikati
TeorijaCisco Meeting Server zahteva šifrovanu komunikaciju između različitih komponenti, i kao rezultat, X.509 sertifikati su potrebni za sve CMS implementacije. Oni pomažu da se osigura da drugi serveri/usluge imaju povjerenja u usluge/serveru.
Svaka usluga zahtijeva certifikat, ali kreiranje zasebnih certifikata za svaku uslugu može dovesti do zabune i nepotrebne složenosti. Srećom, možemo generirati par javno-privatnih ključeva certifikata i zatim ih ponovo koristiti na više servisa. U našem slučaju, isti certifikat će se koristiti za Call Bridge, XMPP Server, Web Bridge i Web Admin. Stoga morate kreirati par javnih i privatnih ključeva certifikata za svaki poslužitelj u klasteru.
Grupiranje baza podataka, međutim, ima neke posebne zahtjeve za certifikate i stoga zahtijeva vlastite certifikate koji se razlikuju od onih drugih servisa. CMS koristi sertifikat servera, koji je sličan sertifikatima koje koriste drugi serveri, ali postoji i sertifikat klijenta koji se koristi za povezivanje baze podataka. Certifikati baze podataka se koriste i za autentifikaciju i za šifriranje. Umjesto pružanja korisničkog imena i lozinke za klijenta da se poveže na bazu podataka, on predstavlja klijentski certifikat kojem server vjeruje. Svaki server u klasteru baze podataka će koristiti isti javni i privatni par ključeva. Ovo omogućava svim serverima u klasteru da šifriraju podatke na takav način da ih mogu dešifrirati samo drugi serveri koji također dijele isti par ključeva.
Da bi redundantnost radila, klasteri baze podataka moraju se sastojati od najmanje 3 servera, ali ne više od 5, s maksimalnim povratnim vremenom od 200 ms između bilo kojeg člana klastera. Ovo ograničenje je restriktivnije nego za Call Bridge klasterisanje, tako da je često ograničavajući faktor u geografski distribuiranim implementacijama.
Uloga baze podataka za CMS ima niz jedinstvenih zahtjeva. Za razliku od drugih uloga, zahtijeva certifikat klijenta i servera, gdje certifikat klijenta ima specifično CN polje koje se prikazuje serveru.
CMS koristi postgres bazu podataka sa jednim masterom i nekoliko potpuno identičnih replika. Postoji samo jedna primarna baza podataka („server baze podataka“). Preostali članovi klastera su replike ili "klijenti baze podataka".
Klaster baze podataka zahtijeva certifikat namjenskog servera i certifikat klijenta. Moraju biti potpisani certifikatima, obično internim privatnim certifikatom. Budući da svaki član klastera baze podataka može postati glavni, parovi certifikata poslužitelja baze podataka i klijenta (koji sadrže javne i privatne ključeve) moraju se kopirati na sve poslužitelje tako da mogu preuzeti identitet klijenta ili poslužitelja baze podataka. Dodatno, CA root certifikat mora biti učitan kako bi se osiguralo da se certifikati klijenta i poslužitelja mogu provjeriti.
Dakle, kreiramo zahtjev za certifikat koji će koristiti svi serverski servisi osim baze podataka (za ovo će postojati poseban zahtjev) sa naredbom poput:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
U CN pišemo opšte ime naših servera. Na primjer, ako su imena hosta naših servera server01, server02, server03, tada će CN biti server.example.com
Isto radimo i na preostala dva servera s tom razlikom što će naredbe sadržavati odgovarajuća “hostnames”
Generiramo dva zahtjeva za certifikate koje će koristiti usluga baze podataka sa naredbama kao što su:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresgdje dbclusterserver и dbclusterclient nazive naših zahtjeva i budućih certifikata, ime hosta1(2)(3) imena odgovarajućih servera.
Ovu proceduru izvodimo samo na jednom serveru (!), a sertifikate i odgovarajuće .key fajlove učitaćemo na druge servere.
Omogućite način rada certifikata klijenta u AD CS-u
Također morate spojiti certifikate za svaki server u jednu datoteku.Na *NIX:
cat server01.cer server02.cer server03.cer > server.cerNa Windows/DOS-u:
copy server01.cer + server02.cer + server03.cer server.cer
I otpremite na svaki server:
1. “Individualni” serverski certifikat.
2. Root certifikat (zajedno sa srednjim, ako ih ima).
3. Certifikati za bazu podataka (“server” i “client”) i datoteke sa ekstenzijom .key, koji su generirani prilikom kreiranja zahtjeva za certifikate baze podataka “server” i “client”. Ove datoteke moraju biti iste na svim serverima.
4. Fajl sva tri “pojedinačna” certifikata.
Kao rezultat, trebali biste dobiti nešto poput ove slike datoteke na svakom serveru.
Klaster baze podataka
Sada kada imate sve sertifikate otpremljene na CMS servere, možete konfigurisati i omogućiti grupisanje baze podataka između tri čvora. Prvi korak je odabrati jedan server kao glavni čvor klastera baze podataka i potpuno ga konfigurirati.
Glavna baza podataka
Prvi korak u postavljanju replikacije baze podataka je specificiranje certifikata koji će se koristiti za bazu podataka. Ovo se radi pomoću naredbe kao što je:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Recimo sada CMS-u koji interfejs da koristi za grupisanje baze podataka naredbom:
database cluster localnode aZatim inicijaliziramo bazu podataka klastera na glavnom serveru naredbom:
database cluster initialize
Čvorovi baze podataka klijenta
Radimo istu proceduru, samo umjesto komande inicijalizirati klaster baze podataka unesite komandu poput:
database cluster join <ip address existing master>gdje je ip adresa postojeća glavna ip adresa CMS servera na kojem je klaster inicijaliziran, jednostavno Master.
Provjeravamo kako naš klaster baze podataka radi na svim serverima naredbom:
database cluster status
Isto radimo na preostalom trećem serveru.
Kao rezultat toga, ispada da je naš prvi server Master, ostali su Slave.
Web Admin Service
Omogućite uslugu web administratora:
webadmin listen a 445Port 445 je odabran jer se port 443 koristi za pristup korisnika web klijentu
Konfiguriramo uslugu Web Admin s datotekama certifikata naredbom kao što je:
webadmin certs <keyfile> <certificatefile> <ca bundle>I omogućite Web Admin naredbom:
webadmin enable
Ako je sve u redu, dobićemo USPJEŠNE linije koje pokazuju da je Web Admin ispravno konfiguriran za mrežu i certifikat. Provjeravamo funkcionalnost usluge pomoću web preglednika i unosimo adresu web administratora, na primjer: : 445
Pozovite Bridge Cluster
Call Bridge je jedina usluga prisutna u svakoj CMS implementaciji. Call Bridge je glavni konferencijski mehanizam. Takođe obezbeđuje SIP interfejs tako da pozivi mogu da budu preusmereni na njega ili sa njega pomoću, na primer, Cisco Unified CM-a.
Naredbe opisane u nastavku moraju se izvršiti na svakom serveru s odgovarajućim certifikatima.
Dakle:
Certifikate povezujemo sa uslugom Call Bridge naredbom kao što je:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]CallBridge usluge vezujemo za interfejs koji nam je potreban naredbom:
callbridge listen aI ponovo pokrenite servis naredbom:
callbridge restart
Sada kada smo konfigurisali mostove poziva, možemo konfigurisati klasterisanje mostova poziva. Clustering Bridge poziva se razlikuje od klastera baze podataka ili XMPP. Call Bridge Cluster može podržati od 2 do 8 čvorova bez ikakvih ograničenja. Obezbeđuje ne samo redundantnost, već i balansiranje opterećenja tako da se konferencije mogu aktivno distribuirati preko Call Bridge servera koristeći inteligentnu distribuciju poziva. CMS ima dodatne funkcije, Call Bridge grupe i povezane funkcije koje se mogu koristiti za dalje upravljanje.
Grupiranje premošćavanja poziva se prvenstveno konfiguriše preko interfejsa web administratora
Dolje opisana procedura mora se provesti na svakom serveru u klasteru.
Tako
1. Idite kroz web do Konfiguracija > Klaster.
2.In Pozovi Bridge identitet Kao jedinstveno ime, unesite callbridge[01,02,03] koji odgovara imenu servera. Ova imena su proizvoljna, ali moraju biti jedinstvena za ovaj klaster. Oni su deskriptivne prirode jer ukazuju na to da su identifikatori servera [01,02,03].
3.B Clustered Call Bridges unesite URL-ove web administratora naših servera u klasteru, [01,02,03].example.com:445, u polju Adresa. Obavezno navedite port. Možete ostaviti Peer link SIP domen prazan.
4. Dodajte certifikat CallBridge trustu svakog servera, u čijoj se datoteci nalaze svi certifikati naših servera, koje smo na samom početku spojili u ovaj fajl, naredbom poput:
callbridge trust cluster <trusted cluster certificate bundle>I ponovo pokrenite servis naredbom:
callbridge restart
Kao rezultat, na svakom serveru bi trebali dobiti ovu sliku:
XMPP klaster
XMPP usluga u CMS-u se koristi za rukovanje svim registracijama i autentifikacijom za Cisco Meeting Apps (CMA), uključujući CMA WebRTC web klijent. Sam Call Bridge također djeluje kao XMPP klijent u svrhu provjere autentičnosti i stoga mora biti konfiguriran kao i drugi klijenti. XMPP tolerancija grešaka je karakteristika koja je podržana u proizvodnim okruženjima od verzije 2.1
Naredbe opisane u nastavku moraju se izvršiti na svakom serveru s odgovarajućim certifikatima.
Dakle:
Certifikate povezujemo sa XMPP uslugom naredbom kao što je:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Zatim definišite interfejs za slušanje naredbom:
xmpp listen aXMPP usluga zahtijeva jedinstvenu domenu. Ovo je prijava za korisnike. Drugim riječima, kada se korisnik pokuša prijaviti pomoću 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šoj konkretnoj implementaciji, odabrali smo našu Unified CM domenu koju će Jabber korisnici koristiti u Unified CM-u kao example.com, tako da nam je bila potrebna druga domena za korisnike CMS-a za usmjeravanje poziva na i iz CMS-a preko SIP domena.
Postavite XMPP domenu koristeći naredbu kao što je:
xmpp domain <domain>I omogućite XMPP servis naredbom:
xmpp enableU usluzi XMPP morate kreirati vjerodajnice za svaki Call Bridge koji će se koristiti prilikom registracije na XMPP servisu. Ova imena su proizvoljna (i nisu povezana sa jedinstvenim imenima koja ste konfigurisali za klasterisanje premošćavanja poziva). Morate dodati tri premošćavanja poziva na jednom XMPP poslužitelju, a zatim unijeti te vjerodajnice na druge XMPP poslužitelje u klasteru jer se ova konfiguracija ne uklapa u bazu podataka klastera. Kasnije ćemo konfigurirati svaki Call Bridge da koristi ovo ime i tajnu za registraciju na XMPP servisu.
Sada treba da konfigurišemo XMPP uslugu na prvom serveru sa tri mosta poziva callbridge01, callbridge02 i callbridge03. Svakom računu će biti dodijeljene nasumične lozinke. Oni će kasnije biti uneti na druge Call Bridge servere za prijavu na ovaj XMPP server. Unesite sljedeće naredbe:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Kao rezultat, provjeravamo šta se dogodilo sa naredbom:
xmpp callbridge list
Potpuno ista slika bi se trebala pojaviti na preostalim serverima nakon dolje opisanih koraka.
Zatim dodajemo potpuno ista podešavanja na preostala dva servera, samo sa komandama
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Secret dodajemo vrlo pažljivo tako da, na primjer, nema dodatnih mjesta u njoj.
Kao rezultat, svaki server bi trebao imati istu sliku:
Zatim, na svim serverima u klasteru, navodimo u povjerenju datoteku koja sadrži sva tri certifikata, kreirana ranije naredbom poput ove:
xmpp cluster trust <trust bundle>Omogućavamo xmpp režim klastera na svim serverima klastera naredbom:
xmpp cluster enableNa prvom serveru klastera iniciramo kreiranje xmpp klastera naredbom:
xmpp cluster initializeNa drugim serverima dodajte klaster u xmpp naredbom kao što je:
xmpp cluster join <ip address head xmpp server>Na svakom serveru provjeravamo uspješnost kreiranja XMPP klastera na svakom serveru pomoću naredbi:
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 da konfigurišete usluge Call Bridge da se povežu na XMPP klaster. Ova konfiguracija se vrši preko web administratora.
Na svakom serveru idite na Konfiguracija > Općenito i u polje Jedinstveno ime za premošćavanje poziva napišite jedinstvena imena koja odgovaraju serverskom Call Bridgeu pozivni most[01,02,03]. V pole područje conf.example.ru i odgovarajuće lozinke, možete ih špijunirati
na bilo kom serveru u klasteru sa naredbom:
xmpp callbridge list
Ostavite polje „Server“ prazno Callbridge će izvršiti DNS SRV traženje za _xmpp-component._tcp.conf.example.comda biste pronašli dostupni XMPP server. IP adrese za povezivanje pozivnih mostova na XMPP mogu se razlikovati na svakom serveru, ovisi koje vrijednosti se vraćaju na zahtjev za snimanje _xmpp-component._tcp.conf.example.com callbridge, što zauzvrat zavisi od podešavanja prioriteta za dati DNS zapis.
Zatim idite na Status > Općenito da biste provjerili je li usluga Call Bride uspješno povezana na XMPP uslugu.
Web Bridge
Na svakom serveru u klasteru omogućite uslugu Web Bridge naredbom:
webbridge listen a:443Konfigurišemo uslugu Web Bridge sa fajlovima sertifikata naredbom kao što je:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge podržava HTTPS. Preusmjerit će HTTP na HTTPS ako je konfiguriran da koristi "http-redirect".
Da biste omogućili HTTP preusmjeravanje, koristite sljedeću naredbu:
webbridge http-redirect enableDa biste obavijestili Call Bridge da Web Bridge može vjerovati vezama sa Call Bridgea, koristite naredbu:
webbridge trust <certfile>gdje je ovo datoteka koja sadrži sva tri certifikata sa svakog servera u klasteru.
Ova slika bi trebala biti na svakom serveru u klasteru.
Sada treba da kreiramo korisnika sa ulogom “apppadmin”, potrebno nam je da možemo da konfigurišemo naš klaster(!), a ne svaki server u klasteru posebno, na ovaj način će se postavke podjednako primeniti na svaki server uprkos činjenica da će biti napravljeni jednom.
Za dalje podešavanje ćemo koristiti .
Za autorizaciju odaberite Osnovno u odjeljku Autorizacija
Da biste ispravno poslali komande CMS serveru, potrebno je da postavite potrebno kodiranje
Naredbom specificiramo Webbridge POST sa parametrom url i značenje
U samom webbridgeu navodimo potrebne parametre: pristup gostu, zaštićeni pristup itd.
Pozovite Bridge grupe
Podrazumevano, CMS ne koristi uvijek najefikasnije korištenje konferencijskih resursa koji su mu dostupni.
Na primjer, za sastanak sa tri učesnika, svaki učesnik može završiti na tri različita mosta poziva. Kako bi ova tri učesnika međusobno komunicirala, Call Bridges će automatski uspostaviti veze između svih servera i klijenata u istom prostoru, tako da sve izgleda kao da su svi klijenti na istom serveru. Nažalost, loša strana ovoga je što će jedna konferencija od 3 osobe sada trošiti 9 medijskih portova. Ovo je očigledno neefikasna upotreba resursa. Pored toga, kada je Call Bridge zaista preopterećen, podrazumevani mehanizam je da nastavi da prihvata pozive i pruža uslugu smanjenog kvaliteta svim pretplatnicima tog Call Bridgea.
Ovi problemi se rješavaju pomoću funkcije Call Bridge Group. Ova funkcija je predstavljena u verziji 2.1 softvera Cisco Meeting Server i proširena je da podrži balansiranje opterećenja za dolazne i odlazne pozive Cisco Meeting App (CMA), uključujući učesnike WebRTC.
Da bi se riješio problem ponovnog povezivanja, uvedena su tri konfigurabilna ograničenja opterećenja za svaki pozivni most:
LoadLimit — ovo je maksimalno brojčano opterećenje za određeni Call Bridge. Svaka platforma ima preporučeno ograničenje opterećenja, kao što je 96000 za CMS1000 i 1.25 GHz po vCPU-u za virtuelnu mašinu. Različiti pozivi troše određenu količinu resursa u zavisnosti od rezolucije i broja kadrova učesnika.
NewConferenceLoadLimitBasisPoints (podrazumevano 50% loadLimit) - postavlja ograničenje opterećenja servera, nakon čega se nove konferencije odbijaju.
ExistingConferenceLoadLimitBasisPoints (podrazumevano 80% od loadLimit) - vrednost opterećenja servera nakon koje će učesnici koji se pridruže postojećoj konferenciji biti odbijeni.
Iako je ova funkcija dizajnirana za distribuciju poziva i balansiranje opterećenja, druge grupe kao što su TURN serveri, Web Bridge serveri i snimači također se mogu dodijeliti grupama za premošćavanje poziva tako da se mogu pravilno grupisati za optimalnu upotrebu. Ako bilo koji od ovih objekata nije dodijeljen grupi poziva, pretpostavlja se da su dostupni svim poslužiteljima bez ikakvog posebnog prioriteta.
Ovi parametri su konfigurisani ovdje: :445/api/v1/system/configuration/cluster
Zatim svakom pozivnom mostu ukazujemo kojoj pozivnoj grupi pripada:
Prvi pozivni most
Drugi pozivni most
Treći pozivni most
Stoga smo konfigurisali Call Brdige grupu da efikasnije koristi resurse Cisco Meeting Server klastera.
Uvoz korisnika iz Active Directory
Usluga Web Admin ima odjeljak za LDAP konfiguraciju, ali ne pruža složene opcije konfiguracije, a informacije se ne pohranjuju u bazu podataka klastera, tako da će konfiguracija morati da se izvrši, bilo ručno na svakom serveru preko Web interfejsa, ili putem API, a kako bismo „tri puta „Ne ustaj“ i dalje ćemo postaviti podatke preko API-ja.
Korištenje URL-a za pristup :445/api/v1/ldapServers kreiraju objekt LDAP servera, specificirajući parametre kao što su:
- IP servera
- broj porta
- korisničko ime
- lozinka
- osigurati
Sigurno - odaberite tačno ili netačno ovisno o portu, 389 - nije sigurno, 636 - zaštićeno.
Mapiranje LDAP izvornih parametara u atribute u Cisco Meeting Serveru.
LDAP mapiranje mapira atribute u LDAP direktoriju u atribute u CMS-u. Stvarni atributi:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Opis atributaIADB predstavlja ID za prijavu korisnika u CMS. Pošto je ovo Microsoft Active Directory LDAP server, CMS JID se mapira na sAMAccountName u LDAP-u, što je u suštini ID za prijavu na Active Directory korisnika. Također imajte na umu da uzmete sAMAccountName i dodate domenu conf.pod6.cms.lab na kraj jer je to login koji će vaši korisnici koristiti za prijavu na CMS.
nameMapping odgovara onome što je sadržano u polju Active Directory displayName sa korisničkim poljem CMS imena.
coSpaceNameMapping kreira ime CMS prostora na osnovu polja displayName. Ovaj atribut, zajedno sa atributom coSpaceUriMapping, je ono što je potrebno za kreiranje prostora za svakog korisnika.
coSpaceUriMapping definira korisnički dio URI-ja koji je povezan s ličnim prostorom korisnika. Neki domeni se mogu konfigurirati za pozivanje u prostor. Ako korisnički dio odgovara ovom polju za jednu od ovih domena, poziv će biti usmjeren na prostor tog korisnika.
coSpaceSecondaryUriMapping definira drugi URI za dostizanje prostora. Ovo se može koristiti za dodavanje numeričkog pseudonima za usmjeravanje poziva u prostor uvezenog korisnika kao alternativu alfanumeričkom URI-ju definiranom u parametru coSpaceUriMapping.
LDAP server i LDAP mapiranje su konfigurirani. Sada ih trebate povezati zajedno kreiranjem LDAP izvora.
Korištenje URL-a za pristup :445/api/v1/ldapSource kreira LDAP izvorni objekt, specificirajući parametre kao što su:
- server
- kartografija
- baseDn
- Filter
Sada kada je LDAP konfiguracija završena, možete izvršiti operaciju ručne sinhronizacije.
To radimo ili u web interfejsu svakog servera klikom Sinhroniziraj sada U poglavlju Aktivni direktorij
ili preko API-ja sa naredbom POST koristeći URL za pristup :445/api/v1/ldapSyncs
Ad-hoc konferencije
Šta je to?U tradicionalnom konceptu, konferencija je kada dva učesnika razgovaraju jedan s drugim, a jedan od učesnika (pomoću uređaja registrovanog na Unified CM) pritisne dugme „Konferencija“, pozove drugu osobu i nakon razgovora sa tom trećom stranom , ponovo pritisnete dugme "Konferencija" da biste se pridružili svim učesnicima u tripartitnoj konferenciji.
Ono što Ad-Hoc konferenciju razlikuje od zakazane konferencije u CMS-u je to što Ad-Hoc konferencija nije samo SIP poziv u CMS. Kada inicijator konferencije klikne dugme Konferencija po drugi put da bi pozvao sve na isti sastanak, Unified CM mora uputiti API poziv CMS-u kako bi kreirao konferenciju u hodu na koju se zatim prebacuju svi pozivi. Sve se to dešava neprimijećeno od strane učesnika.
To znači da Unified CM mora konfigurirati API vjerodajnice i WebAdmin adresu/port usluge, kao i SIP Trunk direktno na CMS server da nastavi poziv.
Ako je potrebno, CUCM može dinamički kreirati prostor u CMS-u tako da svaki poziv može doći do CMS-a i uskladiti pravilo dolaznog poziva koje je namijenjeno za prostore.
Integracija sa CUCM konfigurisan na isti način kao što je opisano u članku osim što na Cisco UCM-u morate kreirati tri trank-a za CMS, tri konferencijska mosta, u SIP sigurnosnom profilu navesti tri imena subjekata, grupe ruta, liste ruta, grupe resursa medija i liste grupa resursa medija i dodati nekoliko pravila rutiranja na Cisco Meeting Server.
SIP sigurnosni profil:
Trunks:
Svaki prtljažnik izgleda isto:
Conference Bridge
Svaki konferencijski most izgleda isto:
Route Group
Lista ruta
Grupa medijskih resursa
Lista grupa medijskih resursa
Pravila poziva
Za razliku od naprednijih sistema za upravljanje pozivima kao što su Unified CM ili Expressway, CMS traži samo domen u polju SIP Request-URI za nove pozive. Dakle, ako je SIP INVITE za gutljaj: [email zaštićen]CMS brine samo o domeni.com. CMS slijedi ova pravila kako bi odredio kamo usmjeriti poziv:
1. CMS prvo pokušava da uskladi SIP domen sa domenima konfigurisanim u pravilima dolaznog poziva. Ovi pozivi se zatim mogu usmjeriti na („ciljane“) prostore ili određene korisnike, interne IVR-ove ili direktno integrirana odredišta Microsoft Lync/Skype for Business (S4B).
2. Ako nema podudaranja u pravilima dolaznog poziva, CMS će pokušati uskladiti domenu konfiguriranu u tabeli prosljeđivanja poziva. Ako je napravljeno podudaranje, pravilo može eksplicitno odbiti poziv ili proslijediti poziv. U ovom trenutku, CMS može prepisati domen, što je ponekad korisno za pozivanje Lync domena. Također možete odabrati da prođete bacanje, što znači da nijedno od polja neće biti dalje modificirano, ili koristiti interni CMS plan biranja. Ako nema podudaranja u pravilima prosljeđivanja poziva, zadana postavka je odbijanje poziva. Imajte na umu da je u CMS-u, iako je poziv "proslijeđen", medij i dalje vezan za CMS, što znači da će biti na putu signalizacije i medijskog prometa.
Tada samo proslijeđeni pozivi podliježu pravilima za odlazne pozive. Ove postavke određuju odredišta na koja se šalju pozivi, tip magistralnog kanala (bilo da je to novi Lync poziv ili standardni SIP poziv) i sve konverzije koje se mogu izvršiti ako prijenos nije odabran u pravilu prosljeđivanja poziva.
Evo stvarnog dnevnika onoga što se dešava tokom Ad-Hoc konferencije
Snimak ekrana to slabo pokazuje (ne znam kako da ga poboljšam), pa ću zapisnik napisati ovako:
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 konferencija:
Pravila dolaznih poziva
Konfigurisanje parametara dolaznih poziva je neophodno da biste mogli da primite poziv u CMS-u. Kao što ste videli u LDAP podešavanju, svi korisnici su uvezeni sa domenom conf.pod6.cms.lab. Dakle, u najmanju ruku, želite da pozivi ovoj domeni ciljaju prostore. Također ćete morati postaviti pravila za sve što je namijenjeno za potpuno kvalificirano ime domene (a možda čak i IP adresu) svakog od CMS servera. Naša eksterna kontrola poziva, Unified CM, će konfigurisati SIP trankove namenjene svakom od CMS servera pojedinačno. U zavisnosti od toga da li je odredište ovih SIP trankova IP adresa ili FQDN servera će odrediti da li CMS treba da bude konfigurisan da prihvata pozive usmerene na njegovu IP adresu ili FQDN.
Domena koja ima ulazno pravilo najvišeg prioriteta koristi se kao domena za sve korisničke prostore. Kada se korisnici sinkroniziraju putem LDAP-a, CMS automatski kreira razmake, ali samo korisnički dio URI-ja (coSpaceUriMapping), na primjer, user.space. dio Puni URI se generiše na osnovu ovog pravila. U stvari, ako biste se u ovom trenutku prijavili na Web Bridge, vidjeli biste da Space URI nema domen. Postavljanjem ovog pravila kao najvišeg prioriteta, postavljate domenu za generirane prostore konf.example.com.
Pravila odlaznih poziva
Da biste omogućili korisnicima da upućuju odlazne pozive u Unified CM klaster, morate konfigurirati odlazna pravila. Domen krajnjih tačaka registrovanih u Unified CM-u, kao što je Jabber, je example.com. Pozivi na ovu domenu treba da se usmjeravaju kao standardni SIP pozivi u čvorove za obradu Unified CM poziva. Glavni server je cucm-01.example.com, a dodatni je cucm-02.example.com.
Prvo pravilo opisuje najjednostavnije usmjeravanje poziva između servera klastera.
polje Lokalno sa domene je odgovoran za ono što će biti prikazano u SIP-URI pozivaoca za osobu koja se poziva iza simbola "@". Ako ga ostavimo praznim, onda će iza simbola “@” biti CUCM-ova IP adresa kroz koju ovaj poziv prolazi. Ako navedemo domen, onda će iza simbola “@” zapravo postojati domen. Ovo je neophodno da biste mogli uzvratiti poziv, u suprotnom neće biti moguće uzvratiti poziv preko SIP-URI ime@ip-adresa.
Pozovite kada je navedeno Lokalno sa domene
Zovi kada NE naznačeno Lokalno sa domene
Obavezno izričito navedite Šifrirano ili Nešifrirano za odlazne pozive, jer ništa ne radi s parametrom Auto.
snimanje
Video konferencije snima server za snimanje. Snimač je potpuno isti kao Cisco Meeting Server. Recorder ne zahtijeva instalaciju bilo koje licence. Licence za snimanje su potrebne za servere koji koriste CallBridge usluge, tj. potrebna je licenca za snimanje i mora se primijeniti na komponentu CallBridge, a ne na server na kojem radi Recorder. Snimač se ponaša kao klijent Extensible Messaging and Presence Protocol (XMPP), tako da XMPP server mora biti omogućen na serveru koji hostuje CallBridge.
Jer Imamo klaster i licencu treba "rastegnuti" na sva tri servera u klasteru. Zatim jednostavno u vašem ličnom nalogu u licencama povezujemo (dodajemo) MAC adrese a-interfejsa svih CMS servera uključenih u klaster.
A ovo je slika koja bi trebala biti na svakom serveru u klasteru
Općenito, postoji nekoliko scenarija za postavljanje Snimača, ali ćemo se držati ovog:
Prije postavljanja Snimača, potrebno je pripremiti mjesto gdje će se video konferencije zapravo snimati. Zapravo ovdje , kako podesiti sva snimanja. Fokusiram se na važne tačke i detalje:
1. Bolje je ubaciti certifikat sa prvog servera u klasteru.
2. Greška “Recorder nedostupan” može se pojaviti jer je pogrešan certifikat naveden u Recorder Trust.
3. Pisanje možda neće raditi ako NFS direktorij naveden za snimanje nije korijenski direktorij.
Ponekad postoji potreba za automatskim snimanjem konferencije jednog određenog korisnika ili prostora.
Za to se kreiraju dva CallProfila:
Sa onemogućenim snimanjem
I sa funkcijom automatskog snimanja
Zatim "prikačimo" CallProfile sa funkcijom automatskog snimanja na traženi prostor.
U CMS-u je tako utvrđeno da ako je CallProfile eksplicitno vezan za bilo koji prostor ili prostor, onda ovaj CallProfile radi samo u odnosu na te specifične prostore. A ako CallProfile nije vezan ni za jedan prostor, tada se po defaultu primjenjuje na one prostore za koje nijedan CallProfile nije eksplicitno vezan.
Sljedeći put ću pokušati opisati kako se CMS-u pristupa izvan interne mreže organizacije.
Izvori:
izvor: www.habr.com