U ovom ću izdanju pokazati i objasniti neke od zamršenosti postavljanja CMS poslužitelja u failover cluster modu.
teorijaOpćenito, postoje tri vrste postavljanja CMS poslužitelja:
- Jednostruki kombinirani(Jednostruko kombinirano), tj. ovo je jedan poslužitelj na kojem rade svi potrebni servisi. U većini slučajeva, ova vrsta implementacije prikladna je samo za interni klijentski pristup i u manjim okruženjima gdje skalabilnost i ograničenja redundantnosti jednog poslužitelja nisu ključni problem ili u situacijama kada CMS obavlja samo određene funkcije, kao što je ad hoc konferencije o Cisco UCM-u.
Približna shema rada:
- Samac Split(Single Split) proširuje prethodnu vrstu postavljanja dodavanjem zasebnog poslužitelja za vanjski pristup. U naslijeđenim implementacijama to je značilo implementaciju CMS poslužitelja u demilitariziranom mrežnom segmentu (DMZ) gdje su mu vanjski klijenti mogli pristupiti, i jednog CMS poslužitelja u jezgri mreže gdje su interni klijenti mogli pristupiti CMS-u. Ovaj poseban model postavljanja sada je zamijenjen tzv Single Edge, koji se sastoji od poslužitelja Cisco brza cesta, koji imaju ili će imati mnogo istih mogućnosti zaobilaženja vatrozida tako da klijenti ne moraju dodavati namjenski rubni CMS poslužitelj.
Približna shema rada:
- Skalabilan i otporan(Skalabilan i tolerantan na greške) Ovaj tip uključuje redundanciju za svaku komponentu, dopuštajući sustavu da raste s vašim potrebama do svog maksimalnog kapaciteta, dok istovremeno pruža redundanciju u slučaju kvara. Također koristi koncept Single Edge za pružanje sigurnog vanjskog pristupa. Ovo je tip koji ćemo pogledati u ovoj epizodi. Ako razumijemo kako implementirati ovu vrstu klastera, ne samo da ćemo razumjeti druge vrste implementacija, već ćemo također moći razumjeti kako stvoriti klastere CMS poslužitelja kako bi se prilagodili potencijalnom rastu potražnje.
Prije nego što prijeđete na implementaciju, trebate razumjeti neke osnovne stvari, naime
Glavne komponente CMS softvera:
- Baza podataka: Omogućuje vam kombiniranje nekih konfiguracija, kao što su plan biranja, korisnički prostori i sami korisnici. Podržava grupiranje samo za visoku dostupnost (jedan glavni).
- Nazovi most: usluga za audio i video konferencije koja omogućuje potpunu kontrolu nad upravljanjem i obradom poziva i multimedijskih procesa. Podržava klasteriranje za visoku dostupnost i skalabilnost.
- XMPP poslužitelj: odgovoran za registraciju i autentifikaciju klijenata koji koriste Cisco aplikaciju za sastanke i/ili WebRTC(komunikacija u stvarnom vremenu ili jednostavno u pregledniku), kao i međukomponentna signalizacija. Može se grupirati samo za visoku dostupnost.
- Web most: Omogućuje klijentski pristup WebRTC-u.
- Balancer opterećenja: Omogućuje jednu točku povezivanja za Cisco aplikacije za sastanke u načinu rada s jednim dijeljenjem. Sluša vanjsko sučelje i port za dolazne veze. Jednako tako, balanser opterećenja prihvaća dolazne TLS veze s XMPP poslužitelja, preko kojih može prebacivati TCP veze s vanjskih klijenata.
U našem scenariju to neće biti potrebno. - TURN poslužitelj: Omogućuje tehnologiju zaobilaženja vatrozida koja omogućuje
postaviti naš CMS iza vatrozida ili NAT-a za povezivanje vanjskih klijenata pomoću aplikacije Cisco Meeting App ili SIP uređaja. U našem scenariju to neće biti potrebno. - Web Administrator: Administrativno sučelje i API pristup, 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 za bilo koju vrstu postavljanja.
- Naredbeni redak (CLI): Sučelje naredbenog retka poznato kao MMP za početnu konfiguraciju i zadatke certifikata.
- Web administrator: Primarno za konfiguracije povezane s CallBridgeom, posebno pri postavljanju jednog poslužitelja bez klastera.
- REST API: Koristi se za najsloženije konfiguracijske zadatke i zadatke povezane s klasteriranom bazom podataka.
Osim navedenog koristi se i protokol SFTP za prijenos datoteka—obično licenci, certifikata ili zapisa—na i sa CMS poslužitelja.
U Ciscovim vodičima za implementaciju bijelo i engleski piše da se klaster mora implementirati najmanje tri poslužitelji (čvorovi) u kontekstu baza podataka. Jer Samo s neparnim brojem čvorova funkcionirat će mehanizam za odabir novog Database Mastera, a općenito Database Master ima vezu s većinom baze podataka CMS poslužitelja.
I kao što praksa pokazuje, dva poslužitelja (čvora) stvarno nisu dovoljna. Mehanizam odabira radi kada se Master ponovno pokrene, Slave poslužitelj postaje Master tek nakon ponovnog pokretanja poslužitelja. Međutim, ako se u klasteru od dva poslužitelja glavni poslužitelj iznenada ugasi, tada podređeni poslužitelj neće postati glavni, a ako se podređeni ugasi, tada će preostali glavni poslužitelj postati podređeni.
Ali u kontekstu XMPP-a, stvarno bi bilo potrebno sastaviti klaster od tri poslužitelja, jer ako, na primjer, onemogućite XMPP uslugu na jednom od poslužitelja u kojima je XMMP u statusu Leader, tada će na preostalom poslužitelju XMPP ostati u statusu Follower i CallBridge veze s XMPP-om će pasti, jer CallBridge se povezuje isključivo na XMPP sa statusom Leader. A ovo je kritično, jer... niti jedan poziv neće proći.
Također, u istim vodičima za implementaciju demonstriran je klaster s jednim XMPP poslužiteljem.
I uzimajući u obzir gore navedeno, postaje jasno zašto: radi jer je u failover modu.
U našem slučaju, XMPP poslužitelj bit će prisutan na sva tri čvora.
Pretpostavlja se da sva tri naša poslužitelja rade.
DNS zapisi
Prije nego počnete postavljati poslužitelje, morate stvoriti 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 domena koju svi pretplatnici Cisco Unified Communication Managera mogu koristiti za svoje URI-je, koja je najvjerojatnije prisutna u vašoj infrastrukturi ili će vjerojatno biti prisutna. Ili example.com odgovara istoj domeni koju korisnici koriste za svoje adrese e-pošte. Ili Jabber klijent na vašem prijenosnom računalu može imati URI [e-pošta zaštićena]. Domena conf.example.com je domena koja će biti konfigurirana za korisnike Cisco poslužitelja za sastanke. Domena Cisco poslužitelja za sastanke bit će conf.example.com, tako da bi se za istog Jabber korisnika, user@ URI trebao koristiti za prijavu na Cisco Meeting Serverconf.example.com.
Osnovna konfiguracija
Sve dolje opisane postavke prikazane su na jednom poslužitelju, ali ih je potrebno izvršiti na svakom poslužitelju u klasteru.
QoS
Budući da CMS generira stvarnom vremenu promet osjetljiv na kašnjenja i gubitak paketa, u većini slučajeva preporuča se konfigurirati kvalitetu usluge (QoS). Kako bi se to postiglo, CMS podržava označavanje paketa s kodovima diferenciranih usluga (DSCP) koje generira. Iako određivanje prioriteta prometa temeljeno na DSCP-u ovisi o tome kako promet obrađuju mrežne komponente vaše infrastrukture, u našem slučaju konfigurirat ćemo naš CMS s tipičnim određivanjem prioriteta DSCP-a na temelju najboljih praksi QoS-a.
Na svakom poslužitelju unijet ćemo ove naredbe
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 promet označen AF41 (DSCP 0x22), sav glasovni promet označen je EF (DSCP 0x2E), ostale vrste prometa niske latencije kao što su SIP i XMPP koriste AF31 (DSCP 0x1A).
Provjeravamo:
NTP
Mrežni vremenski protokol (NTP) važan je ne samo za pružanje točnih vremenskih oznaka poziva i konferencija, već i za provjeru certifikata.
Dodajte NTP poslužitelje svojoj infrastrukturi naredbom poput
ntp server add <server>
U našem slučaju postoje dva takva poslužitelja, pa će postojati dva tima.
Provjeravamo:
I postavite vremensku zonu za naš poslužitelj
DNS
DNS poslužitelje dodajemo CMS-u naredbom poput:
dns add forwardzone <domain-name> <server ip>
U našem slučaju postoje dva takva poslužitelja, pa će postojati dva tima.
Provjeravamo:
Konfiguracija mrežnog sučelja
Sučelje konfiguriramo naredbom poput:
ipv4 <interface> add <address>/<prefix length> <gateway>
Provjeravamo:
Naziv poslužitelja (Hostname)
Имя сервера задаём командой вида:
hostname <name>
I ponovno se pokrećemo.
Ovo dovršava osnovnu konfiguraciju.
Sertifikati
teorijaCisco Meeting Server zahtijeva šifriranu komunikaciju između različitih komponenti, i kao rezultat toga, X.509 certifikati su potrebni za sve implementacije CMS-a. Oni pomažu osigurati da usluge/poslužitelj imaju povjerenje drugih poslužitelja/usluga.
Svaka usluga zahtijeva certifikat, ali stvaranje 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 ponovno upotrijebiti na više usluga. U našem slučaju, isti će se certifikat koristiti za Call Bridge, XMPP poslužitelj, Web Bridge i Web Admin. Stoga morate stvoriti par javnih i privatnih ključeva certifikata za svaki poslužitelj u klasteru.
Klasteriranje baze podataka, međutim, ima neke posebne zahtjeve za certifikate i stoga zahtijeva vlastite certifikate koji se razlikuju od onih drugih usluga. CMS koristi certifikat poslužitelja, koji je sličan certifikatima koje koriste drugi poslužitelji, ali postoji i certifikat klijenta koji se koristi za veze s bazom podataka. Certifikati baze podataka koriste se i za provjeru autentičnosti i za šifriranje. Umjesto pružanja korisničkog imena i lozinke za povezivanje klijenta s bazom podataka, predstavlja klijentski certifikat kojem poslužitelj vjeruje. Svaki poslužitelj u klasteru baze podataka koristit će isti par javnih i privatnih ključeva. To omogućuje svim poslužiteljima u klasteru šifriranje podataka na takav način da ih mogu dešifrirati samo drugi poslužitelji koji također dijele isti par ključeva.
Da bi redundantnost radila, klasteri baze podataka moraju se sastojati od najmanje 3 poslužitelja, ali ne više od 5, s maksimalnim povratnim vremenom od 200 ms između bilo kojeg člana klastera. Ovo je ograničenje restriktivnije nego za klasteriranje Call Bridgea, pa je često ograničavajući čimbenik u geografski raspodijeljenim implementacijama.
Uloga baze podataka za CMS ima niz jedinstvenih zahtjeva. Za razliku od drugih uloga, zahtijeva certifikat klijenta i poslužitelja, pri čemu certifikat klijenta ima specifično CN polje koje se prikazuje poslužitelju.
CMS koristi postgres bazu podataka s jednim masterom i nekoliko potpuno identičnih replika. Postoji samo jedna primarna baza podataka u jednom trenutku ("poslužitelj baze podataka"). Preostali članovi klastera su replike ili "klijenti baze podataka".
Klaster baze podataka zahtijeva namjenski certifikat poslužitelja i certifikat klijenta. Moraju biti potpisani certifikatima, obično internim privatnim autoritetom za certifikate. Budući da bilo koji č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. Osim toga, mora se učitati korijenski certifikat CA kako bi se osiguralo da se certifikati klijenta i poslužitelja mogu provjeriti.
Dakle, kreiramo zahtjev za certifikat koji će koristiti sve usluge poslužitelja osim baze podataka (za to će postojati poseban zahtjev) s 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ći naziv naših poslužitelja. Na primjer, ako imena hostova naših poslužitelja poslužitelj01, poslužitelj02, poslužitelj03, tada će CN biti server.example.com
Isto radimo na preostala dva poslužitelja s tom razlikom što će naredbe sadržavati odgovarajuća “hostnames”
Generiramo dva zahtjeva za certifikate koje će koristiti usluga baze podataka s naredbama poput:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresgdje dbclusterserver и dbclusterclient imena naših zahtjeva i budućih certifikata, ime hosta1(2)(3) imena odgovarajućih poslužitelja.
Ovu proceduru provodimo samo na jednom poslužitelju (!), a certifikate i odgovarajuće .key datoteke ćemo učitati na druge poslužitelje.
Omogućite način rada certifikata klijenta u AD CS-u
Također trebate spojiti certifikate za svaki poslužitelj u jednu datoteku.Na *NIX:
cat server01.cer server02.cer server03.cer > server.cerU sustavu Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
I prenesite na svaki poslužitelj:
1. “Individualni” certifikat poslužitelja.
2. Korijenski certifikat (zajedno s posrednim, ako ih ima).
3. Certifikati za bazu podataka (“poslužitelj” i “klijent”) i datoteke s nastavkom .key, koje su generirane prilikom kreiranja zahtjeva za certifikate baze podataka “poslužitelj” i “klijent”. Te datoteke moraju biti iste na svim poslužiteljima.
4. Datoteka sva tri "pojedinačna" certifikata.
Kao rezultat, trebali biste dobiti nešto poput ove slike datoteke na svakom poslužitelju.
Klaster baze podataka
Sada kada ste sve certifikate učitali na CMS poslužitelje, možete konfigurirati i omogućiti grupiranje 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 određivanje certifikata koji će se koristiti za bazu podataka. To se radi pomoću naredbe poput:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Recimo sada CMS-u koje sučelje da koristi za klasteriranje baze podataka pomoću naredbe:
database cluster localnode aZatim inicijaliziramo bazu podataka klastera na glavnom poslužitelju naredbom:
database cluster initialize
Čvorovi klijentske baze podataka
Radimo isti postupak, samo umjesto naredbe inicijalizirati klaster baze podataka unesite naredbu poput:
database cluster join <ip address existing master>gdje ip adresa postojeća glavna IP adresa CMS poslužitelja na kojem je klaster inicijaliziran, jednostavno Master.
Kako naš klaster baze podataka radi na svim poslužiteljima provjeravamo naredbom:
database cluster status
Isto radimo na preostalom trećem poslužitelju.
Kao rezultat toga, ispada da je naš prvi poslužitelj glavni, a ostali su robovi.
Usluga web administratora
Omogućite uslugu web administratora:
webadmin listen a 445Port 445 je odabran jer se port 443 koristi za korisnički pristup web klijentu
Konfiguriramo uslugu Web Admin s datotekama certifikata pomoću naredbe poput:
webadmin certs <keyfile> <certificatefile> <ca bundle>I omogućite Web Admin naredbom:
webadmin enable
Ako je sve u redu, primit ćemo retke SUCCESS koji pokazuju da je Web Admin ispravno konfiguriran za mrežu i certifikat. Funkcionalnost usluge provjeravamo putem web preglednika i unosom adrese web administratora, npr.: : 445
Nazovi Bridge Cluster
Call Bridge jedina je usluga prisutna u svakoj implementaciji CMS-a. Call Bridge glavni je konferencijski mehanizam. Također pruža SIP sučelje tako da se pozivi mogu preusmjeravati na ili s njega putem, na primjer, Cisco Unified CM-a.
Dolje opisane naredbe moraju se izvršiti na svakom poslužitelju s odgovarajućim certifikatima.
Dakle:
Povezujemo certifikate s uslugom Call Bridge naredbom poput:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]CallBridge usluge povezujemo sa sučeljem koje nam je potrebno pomoću naredbe:
callbridge listen aI ponovno pokrenite uslugu naredbom:
callbridge restart
Sada kada imamo konfigurirane pozivne mostove, možemo konfigurirati grupiranje pozivnih mostova. Grupiranje Call Bridge-a razlikuje se od klasteriranja baze podataka ili XMPP-a. Call Bridge Cluster može podržati od 2 do 8 čvorova bez ikakvih ograničenja. Omogućuje ne samo redundanciju, već i balansiranje opterećenja tako da se konferencije mogu aktivno distribuirati preko Call Bridge poslužitelja koristeći inteligentnu distribuciju poziva. CMS ima dodatne značajke, Call Bridge grupe i srodne značajke koje se mogu koristiti za daljnje upravljanje.
Grupiranje premosnika poziva primarno se konfigurira putem sučelja web-administratora
Postupak opisan u nastavku mora se provesti na svakom poslužitelju u klasteru.
Dakle,
1. Idite putem interneta na Konfiguracija > Klaster.
2.U Call Bridge identitet Kao jedinstveni naziv unesite callbridge[01,02,03] koji odgovara nazivu poslužitelja. Ova imena su proizvoljna, ali moraju biti jedinstvena za ovaj klaster. Opisne su prirode jer pokazuju da su identifikatori poslužitelja [01,02,03].
3.B Clustered Call Bridges unesite URL-ove web administratora naših poslužitelja u klasteru, [01,02,03].example.com:445, u polju Adresa. Obavezno navedite port. Možete ostaviti Peer link SIP domenu praznom.
4. Dodajte certifikat u CallBridge trust svakog poslužitelja čija datoteka sadrži sve certifikate naših poslužitelja koje smo na samom početku spojili u ovu datoteku naredbom poput:
callbridge trust cluster <trusted cluster certificate bundle>I ponovno pokrenite uslugu naredbom:
callbridge restart
Kao rezultat, na svakom poslužitelju trebali biste dobiti ovu sliku:
XMPP klaster
Usluga XMPP u CMS-u koristi se za obradu svih registracija i autentifikacije za Cisco Meeting Apps (CMA), uključujući CMA WebRTC web klijent. Sam Call Bridge također djeluje kao XMPP klijent za potrebe provjere autentičnosti i stoga se mora konfigurirati kao i drugi klijenti. XMPP tolerancija grešaka je značajka koja je podržana u proizvodnim okruženjima od verzije 2.1
Dolje opisane naredbe moraju se izvršiti na svakom poslužitelju s odgovarajućim certifikatima.
Dakle:
Povezujemo certifikate s uslugom XMPP naredbom poput:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Zatim definirajte sučelje za slušanje naredbom:
xmpp listen aUsluga XMPP 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), on upisuje userID@logindomain. U našem slučaju to će biti userid@conf.example.com. Zašto nije samo example.com? U našoj posebnoj implementaciji odabrali smo našu Unified CM domenu koju će korisnici Jabbera koristiti u Unified CM-u kao example.com, pa nam je bila potrebna druga domena za korisnike CMS-a za usmjeravanje poziva prema i od CMS-a kroz SIP domene.
Postavite XMPP domenu pomoću naredbe poput:
xmpp domain <domain>I omogućite XMPP uslugu naredbom:
xmpp enableU usluzi XMPP morate stvoriti vjerodajnice za svaki Call Bridge koji će se koristiti prilikom registracije na uslugu XMPP. Ova su imena proizvoljna (i nisu povezana s jedinstvenim nazivima koje ste konfigurirali za grupiranje premosnika poziva). Morate dodati tri mosta poziva na jedan XMPP poslužitelj i zatim unijeti te vjerodajnice na druge XMPP poslužitelje u klasteru jer ova konfiguracija ne odgovara bazi podataka klastera. Kasnije ćemo konfigurirati svaki Call Bridge da koristi ovo ime i tajnu za registraciju na XMPP uslugu.
Sada trebamo konfigurirati XMPP uslugu na prvom poslužitelju s tri Call Bridgea callbridge01, callbridge02 i callbridge03. Svakom će računu biti dodijeljene nasumične lozinke. Oni će kasnije biti uneseni na druge Call Bridge poslužitelje za prijavu na ovaj XMPP poslužitelj. Unesite sljedeće naredbe:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Kao rezultat, provjeravamo što se dogodilo s naredbom:
xmpp callbridge list
Potpuno ista slika trebala bi se pojaviti na preostalim poslužiteljima nakon dolje opisanih koraka.
Zatim dodajemo potpuno iste postavke na preostala dva poslužitelja, samo s naredbama
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Tajnu dodajemo vrlo pažljivo kako, na primjer, u njoj nema suvišnih razmaka.
Kao rezultat, svaki poslužitelj bi trebao imati istu sliku:
Zatim, na svim poslužiteljima u klasteru, specificiramo u povjerenju datoteku koja sadrži sva tri certifikata, kreirana ranije s naredbom poput ove:
xmpp cluster trust <trust bundle>Omogućujemo xmpp način klastera na svim poslužiteljima klastera naredbom:
xmpp cluster enableNa prvom poslužitelju klastera iniciramo izradu xmpp klastera naredbom:
xmpp cluster initializeNa drugim poslužiteljima dodajte klaster u xmpp naredbom poput:
xmpp cluster join <ip address head xmpp server>Na svakom poslužitelju provjeravamo uspješnost stvaranja XMPP klastera na svakom poslužitelju pomoću naredbi:
xmpp status
xmpp cluster statusPrvi poslužitelj:
Drugi poslužitelj:
Treći poslužitelj:
Povezivanje Call Bridgea na XMPP
Sada kada je XMPP klaster pokrenut, trebate konfigurirati usluge Call Bridge za povezivanje s XMPP klasterom. Ova konfiguracija se vrši putem web administratora.
Na svakom poslužitelju idite na Konfiguracija > Općenito i na polje Jedinstveni naziv Call Bridge-a napišite jedinstvena imena Call Bridgea koja odgovaraju poslužitelju pozivni most[01,02,03]... Na terenu Domena conf.example.ru i odgovarajuće lozinke, možete ih špijunirati
na bilo kojem poslužitelju u klasteru naredbom:
xmpp callbridge list
Ostavite polje "Poslužitelj" prazno Pozivni most izvršit će DNS SRV traženje za _xmpp-component._tcp.conf.example.comkako biste pronašli dostupni XMPP poslužitelj. IP adrese za povezivanje mostova poziva na XMPP mogu se razlikovati na svakom poslužitelju, ovisi o tome koje se vrijednosti vraćaju na zahtjev za zapisom _xmpp-component._tcp.conf.example.com callbridge, što zauzvrat ovisi o postavkama prioriteta za određeni DNS zapis.
Zatim idite na Status > Općenito kako biste provjerili je li usluga Call Bride uspješno povezana s uslugom XMPP.
Web most
Na svakom poslužitelju u klasteru omogućite uslugu Web Bridge naredbom:
webbridge listen a:443Uslugu Web Bridge konfiguriramo s datotekama certifikata pomoću naredbe poput:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge podržava HTTPS. Preusmjerit će HTTP na HTTPS ako je konfiguriran za korištenje "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 iz Call Bridgea, koristite naredbu:
webbridge trust <certfile>gdje je ovo datoteka koja sadrži sva tri certifikata sa svakog poslužitelja u klasteru.
Ova bi slika trebala biti na svakom poslužitelju u klasteru.
Sada moramo kreirati korisnika s ulogom “appadmin”, to nam treba kako bismo mogli konfigurirati naš klaster(!), a ne svaki poslužitelj u klasteru zasebno, na taj način će se postavke jednako primjenjivati na svaki poslužitelj unatoč činjenica da će se jednom napraviti.
Za daljnje postavljanje koristit ćemo .
Za autorizaciju odaberite Osnovno u odjeljku Autorizacija
Za ispravno slanje naredbi CMS poslužitelju potrebno je postaviti potrebno kodiranje
Naredbom specificiramo Webbridge POST s parametrom uRL i značenje
U samom webbridgeu navodimo potrebne parametre: pristup gosta, zaštićeni pristup itd.
Nazovite Grupe za premošćivanje
Prema zadanim postavkama, CMS ne koristi uvijek na najučinkovitiji način resurse konferencije koji su mu dostupni.
Na primjer, za sastanak s tri sudionika, svaki sudionik može završiti na tri različita Call Bridgea. Kako bi ova tri sudionika 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, nedostatak ovoga je da će jedna konferencija s 3 osobe sada zauzeti 9 medijskih priključaka. Ovdje se očito radi o neučinkovitom korištenju resursa. Osim toga, kada je Call Bridge doista preopterećen, zadani mehanizam je nastavak prihvaćanja poziva i pružanje usluge smanjene kvalitete svim pretplatnicima tog Call Bridge-a.
Ovi se problemi rješavaju pomoću značajke Call Bridge Group. Ova je značajka uvedena u verziji 2.1 softvera Cisco Meeting Server i proširena je tako da podržava uravnoteženje opterećenja za dolazne i odlazne pozive Cisco Meeting App (CMA), uključujući WebRTC sudionike.
Kako bi se riješio problem ponovnog povezivanja, uvedena su tri konfigurabilna ograničenja opterećenja za svaki pozivni most:
LoadLimit — ovo je maksimalno numeričko opterećenje za određeni pozivni most. Svaka platforma ima preporučeno ograničenje opterećenja, kao što je 96000 za CMS1000 i 1.25 GHz po vCPU-u za virtualni stroj. Različiti pozivi troše određenu količinu resursa ovisno o razlučivosti i broju sličica u sekundi sudionika.
NewConferenceLoadLimitBasisPoints (zadano 50% loadLimit) - postavlja ograničenje opterećenja poslužitelja, nakon čega se nove konferencije odbijaju.
ExistingConferenceLoadLimitBasisPoints (zadano 80% loadLimit) - vrijednost opterećenja poslužitelja nakon koje će sudionici koji se pridruže postojećoj konferenciji biti odbijeni.
Iako je ova značajka dizajnirana za distribuciju poziva i uravnoteženje opterećenja, druge grupe kao što su TURN poslužitelji, poslužitelji za web-most i snimači također se mogu dodijeliti grupama za premošćivanje poziva tako da se mogu pravilno grupirati 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.
Ovdje se konfiguriraju ovi parametri: :445/api/v1/sustav/konfiguracija/klaster
Zatim svakom pozivnom mostu ukazujemo kojoj grupi pozivnog mosta pripada:
Prvi pozivni most
Drugi pozivni most
Treći pozivni most
Stoga smo konfigurirali Call Brdige grupu za učinkovitije korištenje resursa klastera Cisco Meeting Servera.
Uvoz korisnika iz aktivnog imenika
Usluga Web Admin ima odjeljak konfiguracije LDAP-a, ali ne pruža složene opcije konfiguracije, a informacije nisu pohranjene u bazi podataka klastera, tako da će se konfiguracija morati obaviti, ili ručno na svakom poslužitelju putem web sučelja ili putem API, a tako da mi “tri puta “Ne diži se” i dalje ćemo postavljati podatke preko API-ja.
Korištenje URL-a za pristup :445/api/v1/ldapServers kreiraju objekt LDAP poslužitelja, navodeći parametre kao što su:
- IP poslužitelja
- broj porta
- Korisničko ime
- lozinka
- siguran
Sigurno - odaberite istinito ili lažno ovisno o portu, 389 - nije sigurno, 636 - zaštićeno.
Mapiranje parametara LDAP izvora u atribute u Cisco poslužitelju za sastanke.
LDAP mapiranje preslikava atribute u LDAP direktoriju u atribute u CMS-u. Stvarni atributi:
- jidMapping
- nameMapping
- koSpaceNameMapping
- koSpaceUriMapping
- coSpaceSecondaryUriMapping
Opis atributaJID predstavlja korisnički ID za prijavu u CMS. Budući da je ovo Microsoft Active Directory LDAP poslužitelj, CMS JID se preslikava na sAMAccountName u LDAP-u, što je u biti korisnički ID za prijavu u Active Directory. Također imajte na umu da uzmete sAMAccountName i dodate domenu conf.pod6.cms.lab na kraj jer je to prijava koju će vaši korisnici koristiti za prijavu na CMS.
nameMapping odgovara onome što je sadržano u polju displayName aktivnog imenika s poljem CMS imena korisnika.
koSpaceNameMapping stvara naziv CMS prostora na temelju polja displayName. Ovaj je atribut, zajedno s atributom coSpaceUriMapping, ono što je potrebno za stvaranje prostora za svakog korisnika.
koSpaceUriMapping definira korisnički dio URI-ja povezan s osobnim prostorom korisnika. Neke se domene mogu konfigurirati za pozivanje u svemir. 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 dosezanje 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 poslužitelj i LDAP mapiranje su konfigurirani. Sada ih trebate povezati stvaranjem LDAP izvora.
Korištenje URL-a za pristup :445/api/v1/ldapSource kreira LDAP izvorni objekt, navodeći parametre kao što su:
- server
- kartografija
- bazaDn
- filtriranje
Sada kada je LDAP konfiguracija dovršena, možete izvesti ručnu operaciju sinkronizacije.
To činimo ili u web sučelju svakog poslužitelja klikom Sinkroniziraj odmah odjeljak Active Directory
ili putem API-ja s naredbom POST koristeći URL za pristup :445/api/v1/ldapSyncs
Ad-Hoc konferencije
Što je ovo?U tradicionalnom konceptu konferencija je kada dva sudionika razgovaraju jedan s drugim, a jedan od sudionika (koristeći uređaj registriran na Unified CM) pritisne tipku "Konferencija", pozove drugu osobu i nakon razgovora s tom trećom stranom , ponovno pritišće gumb "Konferencija" za pridruživanje svim sudionicima u trojnoj konferenciji.
Ono što Ad-Hoc konferenciju razlikuje od zakazane konferencije u CMS-u je to što Ad-Hoc konferencija nije samo SIP poziv prema CMS-u. Kada inicijator konferencije klikne gumb Konferencija drugi put kako bi pozvao sve na isti sastanak, Unified CM mora uputiti API poziv CMS-u kako bi stvorio on-the-fly konferenciju na koju se zatim prenose svi pozivi. Sve se to događa nezapaženo od strane sudionika.
To znači da Unified CM mora konfigurirati API vjerodajnice i WebAdmin adresu/port usluge kao i SIP Trunk izravno na CMS poslužitelj kako bi nastavio poziv.
Ako je potrebno, CUCM može dinamički stvoriti 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 s CUCM-om konfiguriran na isti način kao što je opisano u članku osim što na Cisco UCM-u trebate stvoriti tri spojna mjesta za CMS, tri konferencijska mosta, u SIP sigurnosnom profilu navesti tri naziva subjekta, grupe ruta, popise ruta, grupe medijskih resursa i popise grupa medijskih resursa i dodati nekoliko pravila usmjeravanja na Cisco poslužitelj za sastanke.
SIP sigurnosni profil:
Debla:
Svako deblo izgleda isto:
Konferencijski most
Svaki konferencijski most izgleda isto:
Grupa ruta
Popis ruta
Grupa za medijske resurse
Popis grupe medijskih izvora
Pravila poziva
Za razliku od naprednijih sustava za upravljanje pozivima kao što su Unified CM ili Expressway, CMS traži samo domenu u polju SIP Request-URI za nove pozive. Dakle, ako je SIP INVITE za gutljaj: [e-pošta zaštićena]CMS brine samo o domain.com. CMS slijedi ova pravila kako bi odredio kamo usmjeriti poziv:
1. CMS prvo pokušava spojiti SIP domenu s domenama konfiguriranim u pravilima za dolazne pozive. Ti se pozivi zatim mogu preusmjeriti na ("ciljane") prostore ili određene korisnike, interne IVR-ove ili izravno integrirana Microsoft Lync/Skype for Business (S4B) odredišta.
2. Ako nema podudaranja u pravilima dolaznog poziva, CMS će pokušati pronaći domenu konfiguriranu u tablici prosljeđivanja poziva. Ako se uspostavi podudaranje, pravilo može eksplicitno odbiti poziv ili proslijediti poziv. U ovom trenutku CMS može prepisati domenu, što je ponekad korisno za pozivanje Lync domena. Također možete odabrati pass throw, što znači da niti jedno polje neće biti dodatno modificirano, ili koristiti interni CMS plan biranja. Ako nema podudaranja u pravilima za prosljeđivanje poziva, zadana je postavka da se poziv odbije. 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 u signalizaciji i putu medijskog prometa.
Tada samo proslijeđeni pozivi podliježu pravilima odlaznih poziva. Ove postavke određuju odredišta na koja se šalju pozivi, vrstu priključka (bilo da se radi o novom Lync pozivu ili standardnom SIP pozivu) i sve pretvorbe koje se mogu izvesti ako prijenos nije odabran u pravilu za prosljeđivanje poziva.
Ovdje je stvarni dnevnik onoga što se događa tijekom Ad-Hoc konferencije
Snimka zaslona to loše prikazuje (ne znam kako to poboljšati), pa ću dnevnik 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
Konfiguracija parametara dolaznih poziva neophodna je kako biste mogli primiti poziv u CMS. Kao što ste vidjeli u postavkama LDAP-a, svi su korisnici uvezeni s domenom conf.pod6.cms.lab. Dakle, minimalno želite da pozivi na ovu domenu ciljaju prostore. Također ćete morati postaviti pravila za sve što je namijenjeno za potpuno kvalificirani naziv domene (a možda čak i IP adresu) svakog od CMS poslužitelja. Naša vanjska kontrola poziva, Unified CM, konfigurirat će SIP spojeve namijenjene svakom od CMS poslužitelja pojedinačno. Ovisno o tome je li odredište ovih SIP kanala IP adresa ili FQDN poslužitelja, odredit će treba li CMS biti konfiguriran za prihvaćanje poziva usmjerenih 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 stvara razmake, ali samo korisnički dio URI-ja (coSpaceUriMapping), na primjer, user.space. Dio Puni URI generira se na temelju ovog pravila. Zapravo, ako biste se u ovom trenutku prijavili na Web Bridge, vidjeli biste da Space URI nema domenu. Postavljanjem ovog pravila kao najvišeg prioriteta, postavljate domenu za generirane prostore konf.primjer.com.
Pravila odlaznih poziva
Da biste korisnicima omogućili odlazne pozive prema Unified CM klasteru, morate konfigurirati odlazna pravila. Domena krajnjih točaka registriranih s Unified CM-om, kao što je Jabber, je example.com. Pozivi prema ovoj domeni trebali bi se usmjeravati kao standardni SIP pozivi prema Unified CM čvorovima za obradu poziva. Glavni poslužitelj je cucm-01.example.com, a dodatni poslužitelj je cucm-02.example.com.
Prvo pravilo opisuje najjednostavnije usmjeravanje poziva između poslužitelja klastera.
Polje Lokalno iz domene je odgovoran za ono što će biti prikazano u pozivateljevom SIP-URI-ju za osobu koju se zove nakon simbola "@". Ako ga ostavimo praznim, tada će iza simbola “@” biti IP adresa CUCM-a kroz koji ovaj poziv prolazi. Ako navedemo domenu, tada će iza simbola “@” zapravo biti domena. Ovo je neophodno kako biste mogli uzvratiti poziv, inače neće biti moguće uzvratiti poziv putem SIP-URI-ja ime@ip-adresa.
Nazovite kada je naznačeno Lokalno iz domene
Nazovi kada NE naznačeno Lokalno iz domene
Svakako izričito navedite Šifrirano ili Nešifrirano za odlazne pozive, jer ništa ne radi s Automatski parametrom.
Snimanje
Videokonferencije snima Record server. Snimač je potpuno isti kao Cisco poslužitelj za sastanke. Snimač ne zahtijeva instalaciju licenci. Licence za snimanje potrebne su za poslužitelje koji pokreću CallBridge usluge, tj. potrebna je licenca za snimanje i mora se primijeniti na komponentu CallBridge, a ne na poslužitelj koji pokreće Snimač. Snimač se ponaša kao klijent Extensible Messaging and Presence Protocol (XMPP), tako da XMPP poslužitelj mora biti omogućen na poslužitelju koji hostira CallBridge.
Jer Imamo klaster i licencu treba "razvući" na sva tri servera u klasteru. Tada jednostavno u vašem osobnom računu u licencama pridružujemo (dodajemo) MAC adrese a-sučelja svih CMS poslužitelja uključenih u klaster.
A ovo je slika koja bi trebala biti na svakom poslužitelju u klasteru
Općenito, postoji nekoliko scenarija za postavljanje Snimača, ali mi ćemo se držati ovoga:
Prije postavljanja Snimača potrebno je pripremiti mjesto na kojem će se stvarno snimati videokonferencije. Zapravo ovdje , kako postaviti sve Snimanje. Fokusiram se na važne točke i detalje:
1. Bolje je ubaciti certifikat s prvog poslužitelja u klasteru.
2. Pogreška "Zapisivač nedostupan" može se pojaviti jer je pogrešan certifikat naveden u Povjerenju za snimanje.
3. Zapisivanje 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 profila poziva:
С отключенной функцией записи
I s funkcijom automatskog snimanja
Zatim na željeni prostor “pričvršćujemo” CallProfile s funkcijom automatskog snimanja.
U CMS-u je tako utvrđeno da ako je CallProfile izričito vezan za bilo koji prostor ili prostor, tada taj CallProfile radi samo u odnosu na te specifične prostore. A ako CallProfile nije vezan ni za jedan prostor, tada se prema zadanim postavkama primjenjuje na one prostore na koje nijedan CallProfile nije izričito vezan.
Sljedeći put ću pokušati opisati kako se CMS-u pristupa izvan unutarnje mreže organizacije.
Izvori:
Izvor: www.habr.com