ProHoster > Blog > Administrim > Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në këtë episod do të tregoj dhe shpjegoj disa nuanca të konfigurimit të CMS serverit në modin e një klasteri që ofron qëndrueshmëri.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

TeoriaNë përgjithësi, ekzistojnë tre tipe të shpërndarjes së CMS serverit:

  • Single Combined(I kombinuar i vetĂ«m), dmth, Ă«shtĂ« njĂ« server ku janĂ« tĂ« drejtuara tĂ« gjitha shĂ«rbimet e nevojshme. NĂ« shumicĂ«n e rasteve, ky tip shpĂ«rndarjeje aplikohet vetĂ«m pĂ«r aksesin e klientĂ«ve tĂ« brendshĂ«m dhe nĂ« mjedise tĂ« vogla, ku kufizimet e shkallĂ«zueshmĂ«risĂ« dhe tepricĂ«s sĂ« njĂ« serveri nuk janĂ« njĂ« problem kritik, ose nĂ« situata kur CMS kryen vetĂ«m funksione tĂ« caktuara, si konferencat speciale nĂ« Cisco UCM.

    Schema e përgjithshme e funksionimit:
    Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

  • Single Split(I ndarĂ« i vetĂ«m) zgjeron tipin e mĂ«parshĂ«m tĂ« shpĂ«rndarjes, duke shtuar njĂ« server tĂ« veçantĂ« pĂ«r aksesin e jashtĂ«m. NĂ« shpĂ«rndarjet e vjetra, kjo do tĂ« thoshte shpĂ«rndarjen e serverit CMS nĂ« segmentin e demilitarizuar tĂ« rrjetit (DMZ), ku klientĂ«t e jashtĂ«m mund tĂ« merrnin akses, dhe njĂ« server CMS nĂ« zemrĂ«n e rrjetit, ku klientĂ«t e brendshĂ«m merrnin akses nĂ« CMS. Ky model i veçantĂ« shpĂ«rndarjeje tani zĂ«vendĂ«sohet nga tipi i quajtur Single Edge, i cili pĂ«rbĂ«het nga serverĂ«t Cisco Expressway, tĂ« cilĂ«t ose kanĂ«, ose do tĂ« kenĂ« shumĂ« nga mundĂ«sitĂ« pĂ«r tĂ« anashkaluar Firewall-in, duke e bĂ«rĂ« tĂ« panevojshme shtimin e njĂ« serveri tĂ« dedikuar CMS nĂ« skaj.

    Schema e përgjithshme e funksionimit:
    Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

  • Scalable and Resilient(I shkallĂ«zuar dhe me qĂ«ndrueshmĂ«ri) ky tip pĂ«rfshin tepricĂ«n pĂ«r çdo komponent, duke lejuar qĂ« sistemi tĂ« rritet sipas nevojave tuaja deri nĂ« kapacitetin maksimal, ndĂ«rkohĂ« qĂ« siguron tepricĂ« nĂ« rast dĂ«shtimi. Ai gjithashtu pĂ«rdor konceptin e Single Edge pĂ«r tĂ« siguruar akses tĂ« sigurt tĂ« jashtĂ«m. Ky Ă«shtĂ« tipi qĂ« do tĂ« shqyrtojmĂ« nĂ« kĂ«tĂ« episod. NĂ«se kuptojmĂ« si tĂ« shpĂ«rndajmĂ« njĂ« klaster tĂ« kĂ«tij tipi, ne jo vetĂ«m qĂ« do tĂ« kuptojmĂ« tipet e tjera tĂ« shpĂ«rndarjes, por gjithashtu do tĂ« dimĂ« si tĂ« krijojmĂ« klastere tĂ« serverĂ«ve CMS duke pasur parasysh rritjen potenciale tĂ« nevojave.

Para se të vazhdojmë me shpërndarjen, është e rëndësishme të kuptojmë disa gjëra themelore, përkatësisht

Komponentët kryesorë software të CMS:

  • Baza e tĂ« dhĂ«nave: lejon kombinimin e disa konfigurimeve, si grupet e abonentĂ«ve, hapĂ«sirat e pĂ«rdoruesve dhe vetĂ« pĂ«rdoruesit. MbĂ«shtet klasterizimin vetĂ«m pĂ«r disponueshmĂ«ri tĂ« lartĂ« (njĂ« master).
  • Call Bridge: shĂ«rbimi pĂ«r audio dhe video konferences, qĂ« ofron kontrollin e plotĂ« mbi menaxhimin dhe pĂ«rpunimin e thirrjeve dhe proceseve multimediale. PĂ«rkrah klasterizimin pĂ«r disponueshmĂ«ri dhe shkallĂ«zim tĂ« lartĂ«.
  • Server XMPP: pĂ«rgjigjet pĂ«r regjistrimin dhe autentifikimin e klientĂ«ve qĂ« pĂ«rdorin aplikacionin Cisco Meeting Application dhe/ose WebRTC (komunikim nĂ« kohĂ« reale, ose thjesht nĂ« shfletues), si dhe sinjalizimin ndĂ«rkomponent. Mund tĂ« klasterizohet vetĂ«m pĂ«r disponueshmĂ«ri tĂ« lartĂ«.
  • Web Bridge: ofron akses pĂ«r klientĂ«t nĂ« WebRTC.
  • Loadbalancer: siguron njĂ« pikĂ« tĂ« vetme lidhjeje pĂ«r aplikacionet Cisco Meeting App nĂ« modin Single Split. E dĂ«gjon ndĂ«rfaqen publike dhe portin pĂ«r lidhje qĂ« vijnĂ«. Po ashtu, balancuesi i ngarkesave pranon lidhjet e TLS qĂ« vijnĂ« nga serveri XMPP, pĂ«rmes tĂ« cilave mund tĂ« kalojĂ« lidhjet TCP nga klientĂ«t e jashtĂ«m.
    Në skenarin tonë, nuk do të nevojitet.
  • TURN server: ofron teknologjinĂ« pĂ«r tĂ« anashkaluar Firewall-in, e cila lejon
    të vendosim CMS-në tonë pas Firewall-it ose NAT-it për lidhjen e klientëve të jashtëm që përdorin Cisco Meeting App apo pajisje SIP. Në skenarin tonë, nuk do të nevojitet.
  • Web Admin: ndĂ«rfaqja administrative dhe aksesi nĂ« API, pĂ«rfshirĂ« pĂ«r konferencat speciale Unified CM.

Modet e konfigurimit

Në kundërshtim me shumicën e produkteve të tjera Cisco, Cisco Meeting Server mbështet tri metoda konfigurimi, të cilat lejojnë implementimin e çdo lloji të përdorimit.

  • Konsola e komandave (CLI): NdĂ«rfaqja e komandave, e njohur si MMP, pĂ«r detyrat e konfigurimit fillestar dhe certifikatave.
  • Web Administrator: kryesisht pĂ«r konfigurimin qĂ« lidhet me CallBridge, sidomos gjatĂ« konfigurimit tĂ« njĂ« serveri tĂ« vetĂ«m tĂ« pa klasterizuar.
  • REST API: pĂ«rdoret pĂ«r detyrat mĂ« tĂ« komplikuara tĂ« konfigurimit dhe detyrat qĂ« lidhen me bazĂ«n e tĂ« dhĂ«nave klasterike.

PĂ«rveç asaj qĂ« u pĂ«rmend mĂ« sipĂ«r, pĂ«rdoret protokolli SFTP pĂ«r transferimin e skedarĂ«ve – zakonisht licencave, certifikatave ose ditarĂ«ve – pĂ«r nĂ« serverin CMS dhe nga ai.

Në udhëzimet e implementimit nga Cisco është shkruar ngjarshëm se klasteri duhet të vendoset minimum prej tre serverësh (nodash) në kontekstin e bazave të të dhënave. Sepse vetëm me numër të çtë nodash do të funksionojë mekanizmi për zgjedhjen e një Master-i të ri të bazës së të dhënave, dhe në përgjithësi Master-i i bazës së të dhënave ka lidhje me pjesën më të madhe të bazës së të dhënave të serverit CMS.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Dhe siç tregon praktika, dy serverë (nody) në të vërtetë nuk janë mjaftueshëm. Mekanizmi i zgjedhjes funksionon kur rindez Masterin, kurse serveri Slave bëhet Master vetëm pasi të ngrihet serveri i rindezur. Megjithatë, nëse në klasterin me dy serverë, serveri Master papritur "shkëputet", atëherë serveri Slave nuk do të bëhet Master, dhe nëse "shkëputet" Slave, atëherë edhe serveri Master i mbetur do të bëhet Slave.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në kontekstin e XMPP, vërtet është e nevojshme të krijohet një klaster me tre serverë, sepse nëse për shembull, ndalon shërbimin XMPP në një nga serverët ku XMPP është në statusin Lider, atëherë në serverin e mbetur XMPP do të mbetet në statusin Pasues dhe lidhjet CallBridge me XMPP do të ndërpriten, sepse CallBridge lidhet vetëm me XMPP në statusin Lider. Kjo është kritikale, sepse asnjë telefonatë nuk do të kalojë.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Po ashtu, në këto udhëzues të vendosjes demonstrohet një klaster me një server XMPP.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Dhe me këtë në konsideratë bëhet e qartë pse: funksionon, sepse në modalitetin failover.

Në rastin tonë, serveri XMPP do të jetë i pranishëm në të tre nodet.

Kuptohet se të tre serverët tanë janë të ngritur.

Rekordet DNS

Para se të filloni konfigurimin e serverëve, është e nevojshme të krijoni rekorde DNS A dhe SRV tipa:

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Vini re se në regjistrat tanë DNS janë të pranishëm dy domene example.com dhe conf.example.com. Example.com është domeni që mund ta përdorin të gjithë abonentët e Cisco Unified Communication Manager, i cili me siguri është i pranishëm në infrastrukturën tuaj ose ka një probabilitet të lartë që do të jetë. Ose domeni example.com korrespondon me të njëjtin domen që përdoruesit përdorin për adresat e tyre të postës elektronike. Ose klienti Jabber në laptopin tuaj mund të ketë URI user@example.com. Domeni conf.example.com është ai domen i cili do të konfigurohet për përdoruesit e Cisco Meeting Server. Domeni i Cisco Meeting Server do të jetë conf.example.com, prandaj për të njëjtin përdorues Jabber për të hyrë në Cisco Meeting Server do të duhet të përdorë URI user@conf.example.com.

Konfigurimi bazë

Të gjitha konfigurimet e përshkruara më poshtë janë treguar në një server, por duhet të realizohen në çdo server të klasterit.

QoS

Duke qenë se CMS gjeneron real-time Trafiku që është i ndjeshëm ndaj vonesave dhe humbjeve të paketave, në shumicën e rasteve rekomandohet të konfigurohet cilësia e shërbimit (QoS). Për këtë, CMS mbështet etiketimin e paketave me kodet e shërbimeve të diferencuara (DSCP), të cilat ai i gjeneron. Megjithatë, prioritizimi i trafikut bazuar në DSCP varet nga mënyra se si trafiku përpunohet nga komponentët rrjetë të infrastrukturës suaj, në rastin tonë do ta konfigurojmë CMS-in tonë me një shpërndarje tipike të prioriteteve DSCP bazuar në praktikat më të mira QoS.

Në çdo server do të futim këto komanda

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Kështu, e gjithë trafiku video është etiketuar AF41 (DSCP 0x22), e gjithë trafiku vozitës është etiketuar EF (DSCP 0x2E), llojet e tjera të trafikut me vonesë të ulët, si SIP dhe XMPP, përdorin AF31 (DSCP 0x1A).

Po kontrollojmë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

NTP

Protokolli rrjetor i kohës (NTP) është i rëndësishëm jo vetëm për të siguruar vula të sakta të kohës për thirrjet dhe konferencat, por gjithashtu për verifikimin e certifikatave.

Shtojmë serverët NTP të infrastrukturës tuaj me komandën si më poshtë

ntp server add

Në rastin tonë, ka dy serverë të tillë, prandaj do të ketë dy komanda.
Po kontrollojmë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Dhe vendosim zonën e kohës për serverin tonë
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

DNS

Serverët DNS në CMS i shtojmë me komandën si më poshtë:

dns add forwardzone

Në rastin tonë, ka dy serverë të tillë, prandaj do të ketë dy komanda.
Po kontrollojmë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Konfigurimi i ndërfaqes rrjetë

Konfigurojmë ndërfaqen me komandën si më poshtë:

ipv4  add 
 /

Po kontrollojmë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Emri i serverit (Hostname)

Emrin e serverit e caktuam me komandën si më poshtë:

hostname

Dhe e rinisim.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Me këtë përfundon konfigurimi bazë.

Certifikatat

TeoriaCisco Meeting Server kërkon lidhje të kriptuar midis komponentëve të ndryshëm, dhe si rezultat, certifikatat X.509 janë të nevojshme për të gjitha zbatimet e CMS. Ato ndihmojnë në sigurimin e besueshmërisë së shërbimeve/serverit ndaj serverëve/shërbimeve të tjera.

Për çdo shërbim kërkohet një certifikat, megjithatë krijimi i certifikatave të veçanta për çdo shërbim mund të shkaktojë ngatërrim dhe kompleksitet të tepruar. Fatmirësisht, ne mund të gjenerojmë një çift çelësi privat dhe publik të certifikatës, dhe pastaj t'i përdorim ato për disa shërbime. Në rastin tonë, e njëjta certifikatë do të përdoret për Call Bridge, serverin XMPP, Web Bridge dhe Web Admin. Kështu, është e nevojshme të krijohet një çift çelësi privat dhe publik për çdo server në klaster.

Klasifikimi i bazĂ«s sĂ« tĂ« dhĂ«nave ka disa kĂ«rkesa tĂ« veçanta pĂ«r çertifikatat dhe, pĂ«r pasojĂ«, nevojiten çertifikata tĂ« veçanta pĂ«r kĂ«tĂ« qĂ«llim, tĂ« ndryshme nga ato tĂ« shĂ«rbimeve tĂ« tjera. CMS pĂ«rdor njĂ« çertifikatĂ« serveri qĂ« ngjan me çertifikatat e pĂ«rdorura nga serverat e tjerĂ«, por ka gjithashtu njĂ« çertifikatĂ« klienti qĂ« pĂ«rdoret pĂ«r lidhjet me bazĂ«n e tĂ« dhĂ«nave. Çertifikatat e bazĂ«s sĂ« tĂ« dhĂ«nave pĂ«rdoren si pĂ«r autentifikimin ashtu edhe pĂ«r enkriptimin. NĂ« vend qĂ« tĂ« ofrojĂ« emrin e pĂ«rdoruesit dhe fjalĂ«kalimin pĂ«r tĂ« lidhur klientin me bazĂ«n e tĂ« dhĂ«nave, ai paraqet çertifikatĂ«n e klientit, pĂ«r tĂ« cilĂ«n serveri ka besim. Çdo server nĂ« klasĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave do tĂ« pĂ«rdorĂ« tĂ« njĂ«jtĂ«n çift çelĂ«sash publik dhe privat. Kjo lejon tĂ« gjitha serverat nĂ« klasĂ« tĂ« enkriptojnĂ« tĂ« dhĂ«nat nĂ« njĂ« mĂ«nyrĂ« qĂ« ato mund tĂ« dekruptohen vetĂ«m nga serverat e tjerĂ« qĂ« gjithashtu pĂ«rdorin tĂ« njĂ«jtĂ«n çift çelĂ«sash.

Për të funksionuar rezervimi, klasat e bazës së të dhënave duhet të përbëhen nga të paktën 3 servera, por jo më shumë se 5, me një maksimum të vonesës së sinjalit në të dy drejtimet prej 200 ms midis çdo anëtari të klasës. Ky kufizim është më i rreptë se ai për klasifikimin e Call Bridge, prandaj shpesh është një faktor kufizues në shpërndarjet gjeografike.

Roli i bazës së të dhënave për CMS ka një sërë kërkesash unike. Ndryshe nga rolet e tjera, ai kërkon një çertifikatë klienti dhe një çertifikatë serveri, ku çertifikata e klientit ka një fushë të caktuar CN që paraqitet për serverin.

CMS përdor një bazë të dhënash Postgres me një server kryesor dhe disa replika krejtësisht identike. Në çdo moment, ekziston vetëm një bazë të dhënash kryesore ("serveri i bazës së të dhënave"). Anëtarët e tjerë të klasës janë replika ose "klientë të bazës së të dhënave".

Për një klaster të bazës së të dhënave, nevojiten një certifikatë për serverin e përkushtuar dhe një certifikatë për klientin. Ato duhet të jenë të nënshkruara nga certifikata, zakonisht nga një qendër të certifikimit të brendshme. Duke qenë se çdo anëtar i klasterit të bazës së të dhënave mund të bëhet kryesor, çiftet e certifikatave të serverit dhe klientit të bazës së të dhënave (të cilat përmbajnë çelësin publik dhe të fshehtë) duhet të kopjohen në të gjitha serverët, në mënyrë që ata të mund të pranojnë identitetin e klientit ose të serverit të bazës së të dhënave. Për më tepër, certifikata rrënjë e CA duhet të ngarkohet për të garantuar që certifikatat e klientit dhe serverit mund të verifikohen.

Pra, formulojmë një kërkesë për certifikatën që do të përdoret nga të gjitha shërbimet e serverit, përveç database (për këtë do të ketë një kërkesë të veçantë), me komandën si:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

Në CN shkruajmë emrin e përgjithshëm të serverëve tanë. Për shembull, nëse hostname-t e serverëve tanë server01, server02, server03, atëherë CN do të jetë server.example.com

Po ashtu bëjmë në dy serverët e mbetur me përjashtimin se komandat do të kenë "hostname-t" përkatës.

Formulojmë dy kërkesa për certifikatat që do të përdoren nga shërbimi i database me komandat si:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

pki csr dbclusterclient CN:postgres

ku dbclusterserver dhe dbclusterclient emrat e kërkesave tona dhe certifikatave të ardhshme, hostname1(2)(3) emrat e serverëve përkatës.

Këtë procedurë e kryejmë vetëm në një server (!), ndërsa sertifikatat dhe skedarët përkatës .key do t'i ngarkojmë në serverët e tjerë.

Aktivizimi i modit të certifikatës së klientit në AD CSCisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Duhet gjithashtu të bashkohen në një skedar certifikatat për çdo serverNë *NIX:

cat server01.cer server02.cer server03.cer > server.cer

NĂ« Windows/DOS:

copy server01.cer + server02.cer + server03.cer server.cer

Dhe ngarko në çdo server:
1. Certifikata "e veçantë" e serverit.
2. Certifikata rrënjë (së bashku me ato ndërmjetëse nëse ka).
3. Certifikatat për bazën e të dhënave ("server" dhe "klient") dhe skedarët me zgjerim .key, të cilat janë krijuar gjatë formimit të kërkesës për certifikatën "server" dhe "klient" të bazës së të dhënave. Këta skedarë duhet të jenë të njëjtë në të gjitha serverët.
4. Skedari i të tre certifikatave "të veçanta".

Si përfundim, duhet të kemi një pamje të tillë skedari në çdo server.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Database Cluster

Tani tani, kur keni ngarkuar të gjithë certifikat drejtof në serverat CMS, mund të konfiguroni dhe aktivizoni klasterizimin e bazës së të dhënave midis tre nyjeve. Hapi i parë është të zgjidhni një server si nyjën kryesore të klasterit të bazës së të dhënave dhe ta konfiguroni atë plotësisht.

Baza Kryesore e Të Dhënave

Hapi i parë në konfigurimin e replikimit të bazës së të dhënave është të tregoni certifikat që do të përdoren për bazën e të dhënave. Kjo bëhet me komandën e formës:

database cluster certs

Tani le të tregojmë CMS se cila ndërfaqe duhet të përdoret për klasterizimin e bazës së të dhënave me komandën:

database cluster localnode a

Pastaj inicializojmë bazën e të dhënave të klasterit në serverin kryesor me komandën:

database cluster initialize

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Nyjet e Baza e Të Dhënave Klient

Përmbushim të njëjtën procedurë, vetëm se në vend të komandës database cluster initialize vendosim komandën e formës:

database cluster join

ku adresa ip ekzistuese master është adresa IP e serverit CMS në të cilin u krye inicializimi i klasterit, thjesht Master.

Kontrollojmë si funksionon klasteri ynë i bazës së të dhënave në të gjitha serverat me komandën:

database cluster status

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Po e njëjtën gjë bëjmë edhe në serverin e tretë të mbetur.

Si rezultat, serveri ynë i parë është Master, ndërsa të tjerët janë Slave.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Shërbimi i Administratës së Webit

Aktivizojmë shërbimin e administratorit të uebit:

webadmin listen a 445

Porti 445 u zgjodh sepse porti 443 përdoret për qasje nga përdoruesit në klientin web.

Konfigurojmë shërbimin e Web Admin me skedarët e certifikatave me komandën e formës:

webadmin certs

Dhe aktivizojmë Web Admin me komandën:

webadmin enable

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Nëse gjithçka shkon mirë, do të marrim rreshta SUKSES, ku tregohet se Web Admin është konfiguruar saktë për rrjetin dhe certifikatën. Kontrollojmë funksionimin e shërbimit me ndihmën e shfletuesit të internetit dhe vendosim adresën e administratorit të webit, për shembull: cms.example.com:445

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Klasteri i Kalimeve të Thirrjes

Kalimi i Thirrjeve është shërbimi i vetëm që është i pranishëm në çdo distribucion të CMS. Kalimi i Thirrjeve është mekanizmi kryesor i konferencës. Ai gjithashtu ofron ndërfaqen SIP, në mënyrë që thirrjet të mund të drejtoshin ose të merren prej tij, për shembull Cisco Unified CM.

Komandat e përshkruara më poshtë duhet të ekzekutohen në secilin server me certifikatat përkatëse.
Pra:

Lidhim certifikatat me shërbimin Call Bridge me komandën e formës:

callbridge certs  []

Lidhim shërbimet CallBridge me ndërfaqen që na nevojitet me komandën:

callbridge listen a

Dhe rinisni shërbimin me komandën:

callbridge restart

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Tani, kur kemi konfiguruar Call Bridges, mund të konfigurojmë klasterizimin e Call Bridge. Klasterizimi i Call Bridge ndryshon nga klasterizimi i bazës së të dhënave ose XMPP. Klasteri i Call Bridge mund të mbështesë nga 2 deri në 8 nyje pa ndonjë kufizim. Ai ofron jo vetëm redundantësi, por edhe shpërndarje të ngarkesës, duke lejuar që konferencat të shpërndahen aktivisht midis serverëve të Call Bridge me ndihmën e shpërndarjes inteligjente të thirrjeve. CMS ka funksione shtesë, grupe Call Bridge dhe funksionalitete të lidhura që mund të përdoren për menaxhim të mëtejshëm.

Klasterizimi i Bridge të thirrjeve konfigurën kryesisht përmes ndërfaqes së administratës në internet
Procedurën e përshkruar më poshtë duhet ta realizoni në çdo server të klasterit.
Pra,

1. Hyni përmes web në Configuration > Cluster.
2. Në Identitetin e Call Bridge si emër unik shkruani callbridge[01,02,03] përkatësisht emrit të serverit. Këto emra janë të rastësishëm, por duhet të jenë unikë për këtë klaster. Ata kanë natyrë përshkruese, pasi tregojnë se këto janë identifikuesit e serverëve [01,02,03].
3. Në Call Bridges të Klasterizuar shkruani URL-të e administratës në internet të serverëve tanë në klaster, cms[01,02,03].example.com:445, në fushën Address. Sigurohuni të specifikoni portin. Mund ta lini domenin e lidhjes SIP të zbrazët.
4. Shtoni në besnik për CallBridge çdo serverin me certifikatën, skedari i së cilës përmban të gjitha certifikatat e serverëve tanë, të cilat i kemi bashkuar në këtë skedare në fillim, me komandën e tillë:

callbridge trust cluster

Dhe rinisni shërbimin me komandën:

callbridge restart

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në përfundim, në çdo server duhet të duket kështu:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Klasteri XMPP

Shërbimi XMPP në CMS përdoret për të përpunuar të gjithë regjistrimin dhe autentifikimin për Cisco Meeting Apps (CMA), duke përfshirë klientin në internet CMA WebRTC. Vetë Call Bridge gjithashtu vepron si një klient XMPP për qëllime autentifikimi dhe prandaj duhet të konfigurohet si klientët e tjerë. Ruanja e XMPP është një funksion që mbështetet në mjediset e prodhimit që nga versioni 2.1.

Komandat e përshkruara më poshtë duhet të ekzekutohen në secilin server me certifikatat përkatëse.
Pra:

Lidhni certifikatat me shërbimin XMPP me komandën e tillë:

xmpp certs  []

Pastaj, përcaktoni ndërfaqen e dëgjimit me komandën:

xmpp listen a

Për shërbimin XMPP kërkohet një domain unik. Ky është përdoruesi për përdoruesit. Në terma të thjeshtë, kur një përdorues përpiqet të hyjë në sistem me aplikacionin CMA (ose përmes klientit WebRTC), ai hyn me userID@logindomain. Në rastin tonë, ky do të jetë userid@conf.example.com. Pse nuk është thjesht example.com? Në implementimin tonë specifik, ne zgjodhëm domainin tonë Unified CM, të cilin përdoruesit Jabber do ta përdorin në Unified CM si example.com, prandaj na nevoitet një domain tjetër për përdoruesit CMS, për të dërguar thirrjet në CMS dhe nga CMS përmes domainëve SIP.

Konfiguroni domainin XMPP duke përdorur komandën si:

xmpp domain

Dhe aktivizojmë shërbimin XMPP me komandën:

xmpp enable

Në shërbimin XMPP duhet të krijoni kredenciale për çdo Call Bridge, të cilat do të përdoren për regjistrimin në shërbimin XMPP. Këto emra janë të rastësishëm (dhe nuk lidhen me emrat unikë që keni konfiguruar për grumbullimin e urave të thirrjes). Në një server XMPP duhet të shtoni tri ura thirrjesh, pastaj të futni këto kredenciale në serverët e tjerë XMPP në grumbull, pasi kjo konfigurim nuk vendoset në bazën e të dhënave të grumbullit. Më vonë ne do ta konfigurojmë çdo Call Bridge për të përdorur këtë emër dhe sekret për regjistrimin në shërbimin XMPP.

Tani na nevojitet tĂ« konfiguroni shĂ«rbimin XMPP nĂ« serverin e parĂ« me tre Call Bridge tĂ« quajtur callbridge01, callbridge02 dhe callbridge03. Çdo llogari do tĂ« caktohet njĂ« fjalĂ«kalim tĂ« rastĂ«sishĂ«m. MĂ« vonĂ« ato do tĂ« futen nĂ« serverĂ«t e tjerĂ« Call Bridge pĂ«r hyrje nĂ« kĂ«tĂ« server XMPP. Futni komandat e mĂ«poshtme:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

Në fund kontrolloni se çfarë rezultati keni me komandën:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
I njëjti rezultat duhet të jetë në serverët e tjerë pas veprimeve të përshkruara më poshtë.

Më pas, shtoni në dy serverët e mbetur të njëjtat konfigurime, vetëm me komandat

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Secret duhet të shtohet shumë kujdesshëm, për të mos përfshirë ndonjë hapësirë shtesë aksidentalisht.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në përfundim, në çdo server duhet të ketë të njëjtin rezultat:

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Më pas, në të gjithë serverët e grumbullit, tregoni një skedar të besueshëm që përmban të tri certifikatat, të krijuara më parë me komandën si:

xmpp cluster trust

Aktivizoni modin e grumbullit xmpp në të gjithë serverët e grumbullit me komandën:

xmpp cluster enable

Në serverin e parë të klasterit, nisim krijimin e klasterit xmpp me komandën:

xmpp cluster initialize

Në serverët e tjerë, shtojmë në klasterin xmpp me komandën:

xmpp cluster join

Kontrollojmë në çdo server suksesin e krijimit të klasterit XMPP me komandat:

xmpp status
xmpp cluster status

Serveri i parë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Serveri i dytë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Serveri i tretë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Lidhja e Call Bridge me XMPP

Tani, kur klasteri XMPP është i aktivizuar, është e nevojshme të konfigurojmë shërbimet Call Bridge për t'u lidhur me klasterin XMPP. Kjo konfigurim kryhet përmes administratorit të uebit.

Hyjmë në çdo server në Configuration > General dhe në fushën Emri unik i Call Bridge shkruajmë emrat unikë të Call Bridge përkatës për serverin callbridge[01,02,03]. Në fushën Domain conf.example.ru dhe fjalëkalimet përkatëse, mund t'i shohim
në çdo server të klasterit me komandën:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Fusha 'Server' e lëmë bosh, Callbridge do të kryejë kërkimin DNS SRV për _xmpp-component._tcp.conf.example.com, për të gjetur serverin e disponueshëm XMPP. Adresat IP të lidhjes së callbridge-ve me XMPP mund të ndryshojnë në çdo server, kjo varet nga vlerat që kthehen nga kërkesa për regjistrimin _xmpp-component._tcp.conf.example.com callbridge, që nga ana e saj varet nga konfigurimi i prioriteteve për këtë regjistrim DNS.

Më pas kalojmë në Status > General, për të siguruar se shërbimi Call Bridge është lidhur me shërbimin XMPP.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Web Bridge

Në çdo server të klasterit, aktivizojmë shërbimin Web Bridge me komandën:

webbridge listen a:443

Konfigurojmë shërbimin Web Bridge me skedarët e certifikatat me komandën:

webbridge certs

Web Bridge mbështet HTTPS. Ai do të ridrejtojë HTTP në HTTPS, nëse është i konfiguruar për të përdorur 'http-redirect'.
Për të aktivizuar ridrejtimin HTTP, përdorni komandën e mëposhtme:

webbridge http-redirect enable

Për të bërë të ditur Call Bridge se Web Bridge mund të besohet për lidhjet nga Call Bridge, përdorni komandën:

webbridge trust

ku ky është skedari, që përmban të gjitha tre certifikatat nga çdo server në klaster.

Kjo pamje duhet të jetë në çdo server të klasterit.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Tani na nevojitet të krijojmë një përdorues me rolin 'appadmin', që na nevojitet për të konfiguruar klasterin tonë(!), dhe jo çdo server të klasterit veçmas, në këtë mënyrë cilësimet do të aplikohen njësoj në çdo server ndërkohë që do të kryhen një herë.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Për konfigurim të mëtejshëm, do të përdorim Postman.

Për autorizimin zgjidhim Basic në seksionin Autorization

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Për dërgimin e saktë të komandave në serverët CMS, duhet të vendosni kodimin e duhur.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Specifikoni Webbridge me komandën. POST me parametrin url dhe vlerën cms.example.com

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në webbridge, specifikoni parametrat e nevojshëm: akses i hapur, akses i siguruar dhe të tjera.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Grupet e Call Bridge

Në default, CMS nuk e përdor gjithmonë në mënyrë maksimale burimin e disponueshëm të konferencës.

Për shembull, për një takim me tre pjesëmarrës, secili mund të jetë në tre Call Bridge të ndryshëm. Që këta tre pjesëmarrës të mund të flasin me njëri-tjetrin, Call Bridge do të krijojnë automatikisht lidhje mes të gjithë serverëve dhe klientëve në të njëjtën Space, duke e bërë të duket siç po ulet çdo klient në një server të vetëm. Fatkeqësisht, disavantazhi i këtij procesi është se një konferencë me 3 persona tani do të konsumojë 9 porte mediatike. Kjo, natyrisht, është një përdorim joefektiv i burimeve. Për më tepër, kur Call Bridge është në ngarkesë të madhe, mekanizmi i paracaktuar është që të vazhdojë të pranojë thirrjet dhe të ofrojë shërbime me cilësi të ulët për të gjithë abonentët e këtij Call Bridge.

Këto probleme zgjidhen me funksionin Call Bridge Group. Ky funksion u prezantua në versionin 2.1 të softuerit Cisco Meeting Server dhe u zgjerua për të mbështetur balancimin e ngarkesës për thirrjet hyrëse dhe dalëse, Cisco Meeting App (CMA), duke përfshirë pjesëmarrësit WebRTC.

Për të zgjidhur problemin e ri-lidhjes, u përfshinë tre kufij të personalizueshëm të ngarkesës për çdo Call Bridge:

LoadLimit — Ă«shtĂ« kufiri maksimal i ngarkesĂ«s numerike pĂ«r njĂ« Call Bridge tĂ« caktuar. Çdo platformĂ« ka njĂ« vlerĂ« maksimale rekomanduese pĂ«r ngarkesĂ«n, si pĂ«r shembull 96000 pĂ«r CMS1000 dhe 1.25 GHz pĂ«r procesorin virtual pĂ«r makinat virtuale. Thirrje tĂ« ndryshme konsumojnĂ« njĂ« sasi tĂ« caktuar burimesh nĂ« varĂ«si tĂ« resolucioni dhe frekuencĂ«s sĂ« kuadrit tĂ« pjesĂ«marrĂ«sit.
NewConferenceLoadLimitBasisPoints (nĂ« default 50% loadLimit) — vendos kufirin e ngarkesĂ«s sĂ« serverit, pas sĂ« cilĂ«s konferencat e reja refuzohen.
ExistingConferenceLoadLimitBasisPoints (nĂ« default 80% tĂ« loadLimit) — vlera e ngarkesĂ«s sĂ« serverit, pas sĂ« cilĂ«s pjesĂ«marrĂ«sit qĂ« bashkohen me njĂ« konferencĂ« ekzistuese do tĂ« refuzohen.

Ndërsa kjo funksion ishte zhvilluar për të shpërndarë thirrjet dhe ngarkesën, grupe të tjera, siç janë serverat TURN, serverat Web Bridge dhe pajisjet e regjistrimit, gjithashtu mund të emërohen në Grupet e Call Bridge, kështu që ato gjithashtu mund të grupohen siç duhet për përdorim optimal. Nëse ndonjë nga këto objekte nuk është emëruar në grupin e thirrjeve, supozohet se ato janë të arritshme për të gjithë serverat pa ndonjë prioritet të caktuar.

Këto parametra konfigurohen këtu: cms.example.com:445/api/v1/system/configuration/cluster

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Më pas tregojmë secilit callbridge se në cilin grup callbridge i përket:

Callbridge i parë
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Callbridge i dytë
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Callbridge i tretë
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Kështu kemi konfiguruar grupin e Call Bridge për përdorim më efikas të burimeve të klasterit Cisco Meeting Server.

Importimi i përdoruesve nga Active Directory

Shërbimi Web Admin ka një seksion konfigurimi LDAP, por nuk ofron parametrat e ndërlikuar të konfigurimit dhe informacioni nuk ruhet në bazën e të dhënave të klasterit, kështu që konfigurimi do të duhet të bëhet ose manualisht në secilin server përmes Web-interfacet, ose përmes API, dhe për të mos u ngritur dy herë, ne do t'i dërgojmë të dhënat përmes API.

Duke përdorur URL-në për qasje cms01.example.com:445/api/v1/ldapServers krijojmë objektin e Serverit LDAP, duke specifikuar parametrat si:

  • IP-adresa e serverit
  • numri i portit
  • emri i pĂ«rdoruesit
  • fjalĂ«kalimi
  • sigurt

Siguria — true ose false, zgjidhni nĂ« varĂ«si tĂ« portit, 389 — i pa mbrojtur, 636 — i mbrojtur.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Përfaqësoni parametrat LDAP të burimit në atribute në Cisco Meeting Server.
Përfaqësimi LDAP lidh atributet në katalogun LDAP me atributet në CMS. Atributet janë:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Përshkrimi i atributeveJID paraqet identifikuesin e hyrjes së përdoruesit në CMS. Pasi ky është një server LDAP Microsoft Active Directory, JID CMS lidhet me sAMAccountName në LDAP, i cili në thelb është identifikuesi i hyrjes në Active Directory të përdoruesit. Vini re gjithashtu se merrni sAMAccountName dhe i shtoni domenin conf.pod6.cms.lab në fund, sepse ky është logini që përdoruesit tuaj do të përdorin për të hyrë në CMS.

nameMapping lidhet me atë që ndodhet në fushën e displayName në Active Directory, me fushën e emrit të përdoruesit CMS.

coSpaceNameMapping krijon emrin e space-it CMS bazuar në fushën displayName. Ky atribut, së bashku me atributin coSpaceUriMapping, janë ato që nevojiten për të krijuar një space për çdo përdorues.

coSpaceUriMapping përcakton pjesën përdoruese të URI-së, e lidhur me hapësirën personale të përdoruesit. Disa domain mund të konfigurohen për të vendosur në hapësirë. Nëse pjesa përdoruese përputhet me këtë fushë për një nga këto domain, kërkesa do të drejtohet në hapësirën e këtij përdoruesi.

coSpaceSecondaryUriMapping përcakton URI-në e dytë për të arritur hapësirën. Kjo mund të përdoret për të shtuar një pseudonim numerik për rrugëzimin e thirrjeve në hapësirën e përdoruesit të importuar si një alternativë për URI-në alfabeto-numerike, e cila përcaktohet në parametrin coSpaceUriMapping.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Serveri LDAP dhe përputhja LDAP janë konfiguruar. Tani është e nevojshme t'i lidhim ato së bashku, duke krijuar një burim LDAP.

Duke përdorur URL-në për qasje cms01.example.com:445/api/v1/ldapSource krijojmë objektin LDAP Source, duke specifikuar parametra të tillë si:

  • server
  • mapping
  • baseDn
  • filter

Tani, kur konfigurimi LDAP është përfunduar, mund të kryhet operacioni i sinkronizimit manual.

Bëjmë këtë ose në ndërfaqen Web të çdo serveri duke klikuar Sinkronizo tani në seksionin Active Directory
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

ose përmes API me komandën POST duke përdorur URL-në për të hyrë cms01.example.com:445/api/v1/ldapSyncs

Konferencat Ad-Hoc

ÇfarĂ« Ă«shtĂ« kjo?NĂ« kuptimin tradicional, njĂ« konferencĂ« Ă«shtĂ« kur dy pjesĂ«marrĂ«s bisedojnĂ« me njĂ«ri-tjetrin, dhe njĂ« nga pjesĂ«marrĂ«sit (duke pĂ«rdorur njĂ« pajisje tĂ« regjistruar nĂ« Unified CM) shtyp butonin 'KonferencĂ«', thĂ«rret njĂ« person tjetĂ«r dhe pasi flet me kĂ«tĂ« palĂ« tĂ« tretĂ«, shtyp pĂ«rsĂ«ri butonin 'KonferencĂ«', pĂ«r t'u bashkuar me tĂ« gjithĂ« pjesĂ«marrĂ«sit nĂ« konferencĂ«n me tri palĂ«.

Konferenca Ad-Hoc dallohet nga konferenca e planifikuar në CMS në atë që ajo nuk është thjesht një thirrje SIP për CMS. Kur iniciatori i konferencës shtyp butonin 'Konferencë' për herë të dytë për të ftuar të gjithë në të njëjtin takim, Unified CM duhet të kryejë një thirrje API për CMS, për të krijuar një konferencë 'në flakë', në të cilën më pas transferohen të gjitha thirrjet. E gjitha ndodh pa u vënë re nga pjesëmarrësit.

Kjo do të thotë se Unified CM duhet të konfigurojë kredencialet API dhe adresën / portin e shërbimit WebAdmin, si dhe SIP-Trunk direkt në serverin CMS për të vazhduar thirrjen.

Nëse është e nevojshme, CUCM mund të krijojë dinamikisht hapësira në CMS, në mënyrë që çdo thirrje të arrijë në CMS dhe të përputhet me rregullin e thirrjeve hyrëse, i cili është për hapësirat.

Integrimi me CUCM konfigurohet ashtu siç përshkruhet në artikull më parë përveç se duhet të krijoni tre trunk-e për Cisco UCM për CMS, tre Conference Bridge, në SIP Security Profile të specifikoni tre Subject Name, Route Group, Route List, Media Resource Group dhe Media Resource Group List, dhe gjithashtu duhet të shtoni disa rregulla routing në Cisco Meeting Server.

SIP Security Profile:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Trunk-et:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Çdo trunk duket njĂ«soj:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Conference Bridge
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Çdo Conference Bridge duket njĂ«soj:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Route Group
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Route List
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Media Resource Group
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Media Resource Group List
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Rregullat e thirrjeve

Ndryshe nga sistemet më të avancuara të menaxhimit të thirrjeve, si Unified CM ose Expressway, për thirrjet e reja, CMS shqyrton domain-in vetëm në fushën SIP Request-URI. Pra, nëse SIP INVITE është për sip:user@domain.com, CMS merret vetëm me domain.com. CMS ndjek këto rregulla për të përcaktuar se ku ta drejtojë thirrjen:

1. Së pari, CMS përpiqet të përputhë domain-in SIP me domain-et e konfiguruara në rregullat e trajtimit të thirrjeve të ardhshme. Kështu që, këto thirrje mund të drejtohen në hapësira "të synuara" ose tek përdorues të veçantë, IVR të brendshëm apo drejtpërdrejt te destinatarët e integruar të Microsoft Lync/Skype për biznes (S4B).
2. Nëse nuk ka përputhje në rregullat e trajtimit të thirrjeve të ardhshme, CMS do të përpiqet të përputhë domain-in e konfiguruar në tabelën e ridrejtimit të thirrjeve. Nëse përputhja është e vendosur, rregulli mund ta refuzojë drejtpërdrejt thirrjen ose ta ridrejtojë atë. Në këtë kohë, CMS mund të rishkruajë domain-in, çka ndonjëherë është e dobishme për thirrjet në domain-et Lync. Ju gjithashtu mund të zgjidhni pass throw, që do të thotë se asnjë nga fushat nuk do të ndryshohet më tej, ose përdorni grupin e abonentëve të brendshëm të CMS. Nëse nuk ka përputhje në rregullat e ridrejtimit të thirrjeve, rregulli default është të refuzohet thirrja. Kini parasysh se në CMS, megjithëse thirrja është "e ridrejtuar", multimedia akoma lidhet me CMS, që do të thotë se ajo do të jetë në rrugën e sinjalizimit dhe trafikut multimedia.
Kështu, vetëm thirrjet e ridrejtuara i nënshtrohen rregullave të thirrjeve të daljes. Këta parametra përcaktojnë destinatarët ku dërgojnë thirrjet, llojin e linjës së lidhjes (qoftë një thirrje e re Lync ose SIP standarde) dhe çdo transformim që mund të bëhet nëse në rregullin e ridrejtimit të thirrjeve nuk është zgjedhur kalimi.

Ja logu i saktë të asaj që ndodh gjatë një konference Ad-Hoc

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në ekran është e vështirë të shihet (nuk di si ta bëj më mirë), prandaj do ta shkruaj logun kështu:

Info	127.0.0.1:35870: Përdoruesi i API-së "api" krijoi hapësirën e re 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	thirrja e krijimit dështoi për të gjetur coSpace -- duke provuar të rikuperoj nga databaza

Info	API "001036270012" GUID-i i Hapësirës: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> GUID-i i Thirrjes: 93bfb890-646c-4364-8795-9587bfdc55ba <--> GUID-i i Korrelatorit të Thirrjes: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> G

Info	127.0.0.1:35872: Përdoruesi i API-së "api" krijoi thirrjen e re 93bfb890-646c-4364-8795-9587bfdc55ba

Info	thirrja 7: thirrje SIP që po vjen nga "sip:672@172.x.x.x" për URI-në lokale "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Info	API thirrja e këmbës bc0be45e-ce8f-411c-be04-594e0220c38e në thirrjen 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API thirrja 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	konferenca 434f88d0-8441-41e1-b6ee-6d1c63b5b098 ka kontrolle/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	konferenca 434f88d0-8441-41e1-b6ee-6d1c63b5b098 e quajtur "001036270012"

Info	thirrja 7: e konfiguruar - API thirrja e këmbës bc0be45e-ce8f-411c-be04-594e0220c38e me ID-në e thirrjes SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	thirrja 7: duke vendosur seancën UDT RTP për DTLS (media e kombinuar dhe kontrolli)
Info	konferenca "001036270012": këmbët e thirrjes pa enkriptim tani janë të pranishme

Info	pjesëmarrësi "672@172.x.x.x" u bashkua me hapësirën 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	pjesëmarrësi "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) u bashkua me konferencën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 përmes SIP

Info	thirrja 8: thirrje SIP që po vjen nga "sip:690@172.x.x.x" për URI-në lokale "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Info	API thirrja e këmbës db61b242-1c6f-49bd-8339-091f62f5777a në thirrjen 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API thirrja 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	thirrja 8: e konfiguruar - API thirrja e këmbës db61b242-1c6f-49bd-8339-091f62f5777a me ID-në e thirrjes SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	thirrja 8: duke vendosur seancën UDT RTP për DTLS (media e kombinuar dhe kontrolli)

Info	thirrja 9: thirrje SIP që po vjen nga "sip:673@172.x.x.x" për URI-në lokale "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Info	API thirrja e këmbës 37a6e86d-d457-47cf-be24-1dbe20ccf98a në thirrjen 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API thirrja 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	thirrja 9: e konfiguruar - API thirrja e këmbës 37a6e86d-d457-47cf-be24-1dbe20ccf98a me ID-në e thirrjes SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	thirrja 9: duke vendosur seancën UDT RTP për DTLS (media e kombinuar dhe kontrolli)
Info	thirrja 8: kompensimi për anën e largët që nuk përputhet me llojet e ngarkesës

Info	pjesëmarrësi "690@172.x.x.x" u bashkua me hapësirën 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	pjesëmarrësi "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) u bashkua me konferencën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 përmes SIP

Info	thirrja 7: kompensimi për anën e largët që nuk përputhet me llojet e ngarkesës
Info	thirrja 8: llojet e ngarkesës që nuk përputhen moda 1\/0
Info	thirrja 8: duke përgjigjur ofertës në modën e llojeve të ngarkesës që nuk përputhen
Info	thirrja 8: ofertë e vetme codec që ndjek
Info	thirrja 8: llojet e ngarkesës që nuk përputhen moda 1\/0
Info	thirrja 8: duke përgjigjur ofertës në modën e llojeve të ngarkesës që nuk përputhen
Info	thirrja 8: duke dërguar përgjigje për ofertën e kodekëve të shtuar
Info	thirrja 9: kompensimi për anën e largët që nuk përputhet me llojet e ngarkesës

Info	pjesëmarrësi "673@172.x.x.x" u bashkua me hapësirën 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	pjesëmarrësi "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) u bashkua me konferencën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 përmes SIP

Info	thirrja 9: BFCP (roli i klientit) tani aktiv
Info	thirrja 9: duke dërguar përshëndetje BFCP si klient pas pranimit të përshëndetjes kur BFCP nuk ishte aktiv
Info	thirrja 9: BFCP (roli i klientit) tani aktiv
Info	thirrja 7: përfundimi; SIP i largët - i lidhur për 0:13
Info	thirrja 7: shkatërrimi i API thirrjes së këmbës bc0be45e-ce8f-411c-be04-594e0220c38e

Info	pjesëmarrësi "672@x.x.x" u largua nga hapësira 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	thirrja 9: në pritje
Info	thirrja 9: llojet e ngarkesës që nuk përputhen moda 1\/0
Info	thirrja 9: duke përgjigjur ofertës në modën e llojeve të ngarkesës që nuk përputhen
Info	thirrja 8: në pritje
Info	thirrja 8: ofertë e vetme codec që ndjek
Info	thirrja 8: llojet e ngarkesës që nuk përputhen moda 1\/0
Info	thirrja 8: duke përgjigjur ofertës në modën e llojeve të ngarkesës që nuk përputhen
Info	thirrja 8: duke dërguar përgjigje për ofertën e kodekëve të shtuar
Info	thirrja 9: përfundimi; SIP i largët - i lidhur për 0:12

Konferenca Ad-Hoc vetë
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Rregullat e thirrjeve të ardhshme
Konfigurimi i parametrave të thirrjeve të ardhshme është i nevojshëm për të mundësuar pranimin e thirrjeve në CMS. Siç e keni parë në konfigurimin e LDAP, të gjithë përdoruesit janë importuar me domenin conf.pod6.cms.lab. Prandaj, së paku, dëshironi që thirrjet në këtë domen të editorit të dërgojnë në hapësira. Ju gjithashtu do t'ju nevojitet të vendosni rregulla për gjithçka që është e destinuar për emrin e plotë të domenit (dhe ndoshta madje edhe për adresën IP) të secilit nga serverët CMS. Në kontrollin tonë të jashtëm të thirrjeve, Unified CM, do të konfigurohen degë SIP të destinuara për secilin nga serverët CMS individualisht. Në varësi të faktit nëse qëllimi i këtyre degëve SIP është adresa IP, ose emri i plotë i domenit të serverit do të përcaktojë nëse CMS duhet të konfigurohet për të pranuar thirrje të dërguara në adresën e tij IP ose emrin e plotë të domenit.

Domeni, i cili ka rregullin e ardhshëm të trafik të ardhshëm me prioritet të lartë, përdoret si domen për çdo hapësirë të përdoruesve. Kur përdoruesit sinkronizohen përmes LDAP, CMS automatikisht krijon hapësira, por vetëm pjesën e përdoruesit të URI-së (coSpaceUriMapping), për shembull, user.space. Pjesa domain e URI-së së plotë krijohet në bazë të këtij rregulli. Në fakt, nëse do të hynit në Web Bridge në këtë fazë, do të shihni se URI-ja e Hapësirës nuk ka domen. Duke e vendosur këtë rregull si prioritet më të lartë, përcaktoni domenin për hapësirat e gjeneruara si conf.example.com.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Rregullat e thirrjeve në dalje

Për të lejuar përdoruesit të bëjnë thirrje në dalje në klasterin Unified CM, është e nevojshme të konfigurohen rregullat e lidhjeve në dalje. Domeni i pikave të fundit të regjistruara në Unified CM, siç është Jabber, është example.com. Thirrjet në këtë domen duhet të dërgohen si thirrje SIP standarde në nyjat e përpunimit të thirrjeve Unified CM. Si server kryesor funksionon cucm-01.example.com, si server shtesë cucm-02.example.com.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave
Rregulli i parë përshkruan ruterin më të thjeshtë të thirrjeve midis serverëve të klasterit.

Fusha Vendor nga domeni përcakton se çfarë do të shfaqet në SIP-URI të telefonuesit tek ai që merr thirrjen pas simbolit "@". Nëse e lëmë bosh, pas simbolit "@" do të jetë adresa IP e CUCM-it përmes të cilit kalon kjo thirrje. Nëse specifikojmë një domen, atëherë pas simbolit "@" do të jetë në fakt domeni. Kjo është e nevojshme për të pasur mundësinë për t'u kthyer në një thirrje, përndryshe nuk do të jetë e mundur të rikthehesh në SIP-URI formati emri@adresa IP.

Thirrja kur është specifikuar Vendor nga domeni
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Thirrja kur NUK citohet Vendor nga domeni
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Sigurohuni që të specifikoni qartë Encrypted ose Unencrypted për t'u ndihmuar që thirrjet dalëse të funksionojnë, pasi me parametrin Auto nuk funksionon asgjë.

Regjistrimi

Regjistrimi i videokonferencave bëhet përmes serverit Record. Recorder-i është njësoj si Cisco Meeting Server. Recorder nuk kërkon instalimin e ndonjë licencë. Licencat për regjistrim kërkohen për serverët mbi të cilët janë të aktivizuara shërbimet CallBridge, pra licenca Recording është e nevojshme dhe duhet të aplikohet te komponenti CallBridge, dhe jo te serveri ku është aktivizuar Recorder. Recorder-i funksionon si klient i protokollit të shërbimit të mesazheve dhe pranishmërisë (XMPP), prandaj serveri XMPP duhet të jetë i aktivizuar në serverin ku ndodhet CallBridge.

Duke qenë se kemi një grumbull dhe licenca duhet 'shtrirë' në të gjitha tre serverat e grumbullit. Pra thjesht në kabinetin personal, në licenca, asociojmë (shtojmë) adresat MAC të interfaces a-të të të gjithë serverëve CMS që bëjnë pjesë në grumbull.

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Dhe një pamje e tillë duhet të jetë në çdo server të grumbullit

Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në të vërtetë, ka disa skenarë për vendosjen e Recorder-it, por ne do të ndjekim këtë:
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Para se të filloni konfigurimin e Recorder-it, duhet të përgatisni një vend ku do të regjistrohen videokonferencat. Pra ja këtu link, si të konfigurohet e gjithë regjistrimi. Do t'i kushtoj vëmendje pikave dhe detajeve të rëndësishme:

1. Certifikata është më e këshillueshme të ofrohet nga serveri i parë në grumbull.
2. Gabimi 'Recorder unavailable' mund të ndodhë sepse është ofruar një certificatë e gabuar në Recorder Trust.
3. Regjistrimi mund të mos funksionojë, nëse nuk është specifikuar katalogu rrënjor në NFS për regjistrim.

Ndonjëherë ka nevojë për të regjistruar automatikisht konferencën e një përdoruesi ose hapësire specifike.

Për këtë krijohen dy CallProfile:
Me funksionin e regjistrimit të çaktivizuar
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Dhe me funksionin automatik të regjistrimit
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Më pas, te hapësira e nevojshme 'lidhim' CallProfile me funksionin automatik të regjistrimit.
Cisco Meeting Server 2.5.2. Grupe në modin e Shkallëzueshëm dhe të Qëndrueshëm me funksionin për regjistrimin e videokonferencave

Në CMS është një rregull që nëse CallProfile është qartë i lidhur me ndonjë hapësirë apo hapësira, atëherë ky CallProfile funksionon vetëm për këto hapësira specifike. Nëse CallProfile nuk është i lidhur me asnjë hapësirë, atëherë ai nuk zbatohet për ato hapësira për të cilat nuk është qartësisht i lidhur asnjë CallProfile.

Herën tjetër do të përpiqem të përshkruaj se cilat janë mënyrat për të aksesuar CMS jashtë rrjetit të brendshëm të organizatës.

Burimet:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster