ProHoster > Blog > Administrimi > Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në këtë episod do t'ju tregoj dhe shpjegoj disa nuanca të konfigurimit të serverit CMS në mënyrën e një klasteri të qëndrueshëm.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

TeoriaNë thelb, ekzistojnë tre lloje të implementimit të serverit CMS:

  • Single Combined(E njĂ«jtĂ« e kombinuar), qĂ« do tĂ« thotĂ« se Ă«shtĂ« njĂ« server i vetĂ«m ku janĂ« aktivizuar tĂ« gjithĂ« shĂ«rbimet e nevojshme. NĂ« shumicĂ«n e rasteve, ky lloj implementimi Ă«shtĂ« i aplikueshĂ«m vetĂ«m pĂ«r qasje nga klientĂ«t e brendshĂ«m dhe nĂ« ambiente tĂ« vogla, ku kufizimet e shkallĂ«zueshmĂ«risĂ« dhe tepĂ«rsinĂ« e njĂ« serveri tĂ« vetĂ«m nuk janĂ« njĂ« problem kritik, ose nĂ« situatat kur CMS kryen vetĂ«m funksione tĂ« caktuara, si konferencat e specializuara nĂ« Cisco UCM.

    Diagrami përkatës i funksionimit:
    Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

  • Single Split(E njĂ«jtĂ« e ndarĂ«) zgjeron llojin e mĂ«parshĂ«m tĂ« implementimit duke shtuar njĂ« server tĂ« veçantĂ« pĂ«r qasje tĂ« jashtme. NĂ« implementimet e vjetra, kjo do tĂ« thoshte qĂ« serveri CMS do tĂ« implementohej nĂ« njĂ« segment demilitarizuar tĂ« rrjetit (DMZ), ku klientĂ«t e jashtĂ«m mund tĂ« aksesonin, dhe njĂ« server CMS nĂ« bĂ«rthamĂ«n e rrjetit, ku klientĂ«t e brendshĂ«m aksesojnĂ« CMS. Ky model specifik i implementimit tani po zĂ«vendĂ«sohet nga lloji i quajtur Single Edge, i cili pĂ«rbĂ«het nga serverĂ«t Cisco Expressway, tĂ« cilĂ«t kanĂ« ose do tĂ« kenĂ« shumĂ« nga funksionalitetet pĂ«rtej Firewall-it, kĂ«shtu qĂ« klientĂ«t nuk kanĂ« nevojĂ« tĂ« shtojnĂ« njĂ« server tĂ« dedikuar tĂ« pĂ«rzgjedhur CMS.

    Diagrami përkatës i funksionimit:
    Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

  • Scalable and Resilient(I shkallĂ«zuar dhe i qĂ«ndrueshĂ«m) ky lloj pĂ«rfshin tepĂ«rsinĂ« pĂ«r çdo komponent, duke lejuar qĂ« sistemi tĂ« rritet me nevojat tuaja deri nĂ« kapacitetin maksimal, duke siguruar gjithashtu tepĂ«rsinĂ« nĂ« rast dĂ«shtimi. Ai gjithashtu pĂ«rdor konceptin e Single Edge pĂ«r tĂ« siguruar qasje tĂ« sigurt tĂ« jashtme. Ky Ă«shtĂ« lloji qĂ« do tĂ« shqyrtojmĂ« nĂ« kĂ«tĂ« episod. NĂ«se kuptojmĂ« si tĂ« implementojmĂ« njĂ« klaster tĂ« kĂ«tij lloji, ne jo vetĂ«m qĂ« do tĂ« kuptojmĂ« llojet e tjera tĂ« implementimeve, por gjithashtu do tĂ« jemi tĂ« aftĂ« tĂ« kuptojmĂ« si tĂ« krijojmĂ« klasterĂ« serverĂ«sh CMS me parasysh rritjen e mundshme tĂ« nevojave.

Para se të kalojmë në implementim, duhet të kuptojmë disa gjëra bazike, saktësisht

Pjesët kryesore softuerike të CMS:

  • Baza e tĂ« dhĂ«nave: lejon tĂ« bashkohen disa konfigurime, si grupi i abonentĂ«ve, hapĂ«sirat e pĂ«rdoruesve dhe pĂ«rdoruesit e vetĂ«. MbĂ«shtet klasterizimin vetĂ«m pĂ«r dispozita tĂ« lartĂ« (njĂ« master).
  • Call Bridge: shĂ«rbimi pĂ«r audio- dhe videokonferencat, qĂ« merr pĂ«rsipĂ«r kontrollin e plotĂ« mbi menaxhimin dhe pĂ«rpunimin e thirrjeve dhe proceseve multimedia. MbĂ«shtet klasterizimin pĂ«r lartĂ« dispozitash dhe shkallĂ«zim.
  • XMPP server: Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r regjistrimin dhe autenticitetin e klientĂ«ve qĂ« pĂ«rdorin aplikacionin Cisco Meeting Application dhe/ose WebRTC (komunikim nĂ« kohĂ« reale, ose thjesht nĂ« shfletues), si dhe sinjalizimin midis komponentĂ«ve. Mund tĂ« klasterizohet vetĂ«m pĂ«r qĂ«llime tĂ« lartĂ« disponueshmĂ«rie.
  • Web Bridge: ofron qasje pĂ«r klientĂ«t nĂ« WebRTC.
  • Loadbalancer: siguron njĂ« pikĂ« tĂ« vetme lidhjeje pĂ«r aplikacionet Cisco Meeting App nĂ« mĂ«nyrĂ«n Single Split. DĂ«gjon ndĂ«rfaqen dhe portin e jashtĂ«m pĂ«r lidhjet e ardhshme. NĂ« mĂ«nyrĂ« tĂ« barabartĂ«, balancuesi i ngarkesĂ«s pranon lidhjet e ardhshme TLS nga serveri XMPP, pĂ«rmes tĂ« cilave ai mund tĂ« kalojĂ« lidhjet TCP nga klientĂ«t e jashtĂ«m.
    Në skenarin tonë, ai nuk do të jetë i nevojshëm.
  • TURN server: siguron teknologjinĂ« pĂ«r kalimin e Firewall-it, duke lejuar
    të nxjerrim CMS-tonë përtej Firewall-it ose NAT-it për t'u lidhur me klientët e jashtëm që përdorin Cisco Meeting App ose pajisjet SIP. Në skenarin tonë, ai nuk do të jetë i nevojshëm.
  • Web Admin: ndĂ«rfaqja administrative dhe qasja nĂ« API, duke pĂ«rfshirĂ« pĂ«r konferencat speciale Unified CM.

Metodat e konfigurimit

Ndryshe nga shumica e produkteve të tjera Cisco, Cisco Meeting Server mbështet tri metoda konfigurimi, duke lejuar implementimin e çdo lloji implementimi.

  • Komanda e linjĂ«s (CLI): NdĂ«rfaqja e komandĂ«s, e njohur si MMP, pĂ«r detyrat fillestare tĂ« konfigurimit dhe certifikatave.
  • Web Admin: kryesisht pĂ«r konfigurimin qĂ« lidhet me CallBridge, veçanĂ«risht gjatĂ« konfigurimit tĂ« njĂ« serveri tĂ« vetĂ«m qĂ« nuk Ă«shtĂ« klasterizuar.
  • REST API: pĂ«rdoret pĂ«r detyrat mĂ« komplekse tĂ« konfigurimit dhe detyrat qĂ« lidhen me bazĂ«n e tĂ« dhĂ«nave tĂ« klasterizimit.

Përveç përmendurave më sipër, përdoret protokolli SFTP për transferimin e skedarëve - zakonisht licencave, certifikatave ose regjistrave - në serverin CMS dhe nga ai.

Në udhëzimet për implementim nga Cisco thuhet qartë që klasteri duhet të implementohet minimum prej tre serverësh (nodosh) në kontekstin e bazave të të dhënave. Sepse vetëm me një numër të çuditshëm nodosh 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 shumicën e bazës së të dhënave të serverit CMS.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Si praktikisht tregon, dy serverë (noda) nuk janë të mjaftueshëm. Mekanizmi i zgjedhjes funksionon gjatë rinisjes së Master-it; serveri Slave bëhet Master vetëm pas ngarkimit të serverit të rinisur. Megjithatë, nëse në një grup me dy serverë, serveri Master papritmas "përdoret", serveri Slave nuk do të bëhet Master, dhe nëse Slave "përdoret", serveri Master do të bëhet Slave.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Megjithatë, në kontekstin e XMPP, me siguri duhet të krijoni një grup me tre serverë, pasi, për shembull, nëse 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 Follower, dhe lidhjet e CallBridge nuk do të funksionojnë, pasi CallBridge lidhet ekskluzivisht me XMPP-në në statusin Lider. Dhe kjo është kritikale, pasi asnjë telefonatë nuk do të kalojë.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Po ashtu, në këto udhëzime për implementimin është demonstruar një grup me një server XMPP.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Dhe me marrjen parasysh të përmendur më sipër, bëhet e qartë pse: funksionon në mënyrë të sigurt për shkak të modit failover.

Në rastin tonë, serveri XMPP do të jetë prezent në të tri nodat.

Supozimi është që të gjitha tre serverët tanë janë ngarkuar.

Rekordet DNS

Para se të filloni konfigurimin e serverëve, është e nevojshme të krijoni rekordet DNS. Dhe dhe SRV tipet:

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Vini re se në rekordet tona DNS ka 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ë për tu pranishëm. Ose domeni example.com përputhet 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 që 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 tu kyçur në Cisco Meeting Server do të duhet të përdorni URI user@conf.example.com.

Konfigurimi bazik

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

QoS

Duke qenë se CMS krijon trafik në kohë reale , të ndjeshëm ndaj vonesave dhe humbjes së paketave, në shumicën e rasteve rekomandohet të konfiguroni cilësinë e shërbimit (QoS). Për këtë CMS mbështet shënimin e paketave me kodet e shërbimeve të diferencuara (DSCP) që ai krijon. Edhe pse prioritetizimi i trafikës në bazë të DSCP varet nga mënyra se si përpunohen trafiku nga komponentët rrjetë të infrastrukturës tuaj, në rastin tonë do ta konfiguroni CMS-në me një shpërndarje tipike të prioriteteve DSCP sipas praktikave më të mira të QoS.

Në secilin server do të japim 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, të gjithë trafiku i videos do të jetë i shënuar AF41 (DSCP 0x22), të gjithë trafiku i zërit do të jetë i shënuar EF (DSCP 0x2E), lloje të tjera të trafikëve me vonesë të ulët, si SIP dhe XMPP, përdorin AF31 (DSCP 0x1A).

Po kontrollojmë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

NTP

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

Shto serverët NTP në infrastrukturën tuaj me komandën

ntp server add

Në rastin tonë, ka dy të tillë serverë, prandaj do të ketë dy komanda.
Po kontrollojmë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Dhe caktojmë zonën e kohës për serverin tonë.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

DNS

Serverët DNS në CMS shtohen me komandën:

dns add forwardzone

Në rastin tonë, ka dy të tillë serverë, prandaj do të ketë dy komanda.
Po kontrollojmë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Konfigurimi i interfacit rrjetor

Konfigurojmë interfacin me komandën:

ipv4  add 
/

Po kontrollojmë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Emri i serverit (Hostname)

Emrin e serverit e caktuar me komandën:

hostname

Dhe rinisim.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Me këtë, konfigurimi bazik ka përfunduar.

Certifikatat

TeoriaCisco Meeting Server kërkon komunikim të kriptuar midis komponenteve të ndryshme, dhe si rezultat, certifikatat X.509 kërkohen për të gjitha implementimet CMS. Ato ndihmojnë për të siguruar besimin në shërbime/server për serverë/shërbime 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ë çojë në konfuzion dhe ndërlikim të panevojshëm. Fatmirësisht, mund të krijojmë një çift çelesh të hapur dhe të mbyllur të certifikatës dhe pastaj t'i përdorim ato për shërbime të shumta. Në rastin tonë, të njëjtën certifikatë do ta përdorim për Call Bridge, serverin XMPP, Web Bridge dhe Web Admin. Kështu, ndihmoni të krijoni një çift çelesh të hapur dhe të mbyllur të certifikatës në secilin server në grup.

Klasterizimi i bazĂ«s sĂ« tĂ« dhĂ«nave ka disa kĂ«rkesa tĂ« veçanta pĂ«r certifikatat, prandaj kĂ«rkon certifikata tĂ« saj, tĂ« ndryshme nga ato tĂ« shĂ«rbimeve tĂ« tjera. CMS pĂ«rdor certifikatĂ«n e serverit, e cila Ă«shtĂ« e ngjashme me certifikatĂ«t e pĂ«rdorura nga servera tĂ« tjerĂ«, por ka gjithashtu njĂ« certifikatĂ« klienti, e cila pĂ«rdoret pĂ«r lidhjet me bazĂ«n e tĂ« dhĂ«nave. Certifikatat e bazĂ«s sĂ« tĂ« dhĂ«nave pĂ«rdoren si pĂ«r autentifikim ashtu edhe pĂ«r enkriptim. NĂ« vend qĂ« tĂ« ofrohet njĂ« emĂ«r pĂ«rdoruesi dhe njĂ« fjalĂ«kalim pĂ«r lidhjen e klientit me bazĂ«n e tĂ« dhĂ«nave, ai paraqet certifikatĂ«n e klientit, tĂ« cilĂ«s serveri i beson. Çdo server nĂ« klasterin e bazĂ«s sĂ« tĂ« dhĂ«nave do tĂ« pĂ«rdorĂ« tĂ« njĂ«jtĂ«n çift çelesh tĂ« hapur dhe tĂ« mbyllur. Kjo lejon qĂ« tĂ« gjithĂ« serverat nĂ« klaster tĂ« enkriptojnĂ« tĂ« dhĂ«nat nĂ« njĂ« mĂ«nyrĂ« qĂ« ato tĂ« jenĂ« tĂ« dekriptuara vetĂ«m nga serverat e tjerĂ« qĂ« gjithashtu pĂ«rdorin tĂ« njĂ«jtĂ«n çift çelesh.

Për të funksionuar rezervimi, klasteret 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ë kohës së kalimit të sinjalit në të dy drejtimet prej 200 ms midis çdo anëtari të klasterit. Ky kufizim është më i ashpër se për klasterizimin 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, ajo kërkon certifikatën e klientit dhe të serverit, ku certifikata e klientit ka një fushë të caktuar CN, e cila i paraqitet serverit.

CMS përdor bazën e të dhënave postgres me një server kryesor dhe disa replika të plotë të 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ë klasterit janë replika ose 'klientë të bazës së të dhënave'.

Për klasterin e bazës së të dhënave kërkohen certifikata të serverit të dedikuar dhe certifikata të klientit. Këto duhet të jenë të nënshkruara nga certifikatat, zakonisht nga një autoritet i brendshëm privat të certifikimit. Duke pasur parasysh që çdo anëtar i klasterit të bazës së të dhënave mund të bëhet kryesor, çiftet e certifikatave të serverit të bazës së të dhënave dhe klientit (të cilat përmbajnë çelësa të hapur dhe të mbyllur) duhet të kopjohen në të gjithë serverat, në mënyrë që ata të mund të pranojnë identitetin e klientit ose serverit të bazës së të dhënave. Për më tepër, certifikata rrënjore CA duhet të ngarkohet për të garantuar se certifikatat e klientit dhe serverit mund të verifikohen.

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

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ë janë server01, server02, server03, atëherë CN do të jetë server.example.com

I njëjti proces përfshihet në dy serverat e tjerë me diferencën se komandat do të përmbajnë 'hostname' përkatëse.

Formulojmë dy kërkesa për certifikatat, të cilat do të përdoren nga shërbimi database me komandat:

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

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

pki csr dbclusterclient CN:postgres

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

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

Aktivizimi i modalitetit të certifikatës së klientit në AD CSCisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Gjithashtu duhet të bashkohen në një skedar certifikatat për secilin 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. 'Certifikatën e veçantë' të serverit.
2. Certifikatën rrënjore (së bashku me ato ndërmjetëse nëse ka të tilla).
3. Certifikatat për bazën e të dhënave ('serveri' dhe 'klienti') dhe skedarët me zgjerim .key, të cilat janë formuar gjatë krijimit të kërkesës për 'certifikatën e serverit' dhe 'certifikatën e klientit' të bazës së të dhënave. Këta skedarë duhet të jenë të njëjtë në të gjithë serverat.
4. Skedari i të tri 'certifikatave të veçanta'.

Në përfundim, duhet të kemi një pamje të tillë skedarësh në çdo server.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Klusteri i Bazës së të Dhënave

Tani, kur keni të gjitha certifikatat e ngarkuara në serverët 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 plotësisht atë.

Baza e të Dhënave Kryesore

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

certifikatat e klasterit të bazës së të dhënave <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Tani do të specifikojmë CMS, cilin ndërfaqe të përdorim për klasterizimin e bazave të të dhënave me komandën:

klasteri i bazës së të dhënave localnode a

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

klasteri i bazës së të dhënave inicializo

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Nodet e Bazës së Klientit

Kryejmë të njëjtën procedurë, vetëm se në vend të komandës klasteri i bazës së të dhënave inicializo shkruajmë komandën në formatin:

klasteri i bazës së të dhënave bashkohu <adresa ip e master ekzistues>

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

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

klasteri i bazës së të dhënave status

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Të njëjtën gjë e bëjmë edhe në serverin e tretë.

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

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Shërbimi Web Admin

Aktivizojmë shërbimin e administratorit web:

webadmin dëgjo a 445

Porti 445 është zgjedhur sepse porti 443 përdoret për aksesin e përdoruesve në klientin web

Konfigurojmë shërbimin Web Admin me skedarët e certifikatëve me komandën:

webadmin certs <skedari i çelësit> <skedari i certifikatës> <paketa ca>

Dhe aktivizojmë Web Admin me komandën:

webadmin aktivizo

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Nëse gjithçka shkon mirë, do të marrim rreshta SUCCESS, ku tregohet se Web Admin është konfiguruar saktë për rrjetin dhe certifikatën. Kontrollojmë funksionalitetin e shërbimit me një shfletues web dhe shkruajmë adresën e administratorit web, për shembull: cms.example.com:445

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Klasteri i Call Bridge

Call Bridge është shërbimi i vetëm që është i pranishëm në çdo implementim CMS. Call Bridge është mekanizmi kryesor për konferencat. Ai gjithashtu siguron një ndërfaqe SIP, kështu që thirrjet mund të rruhen për në të ose nga ai, për shembull, me 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:

callbridge certs <skedari i çelësit> <skedari i certifikatës>[<paketa e certifikatave>]

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

callbridge dëgjo a

Dhe rinitojmë shërbimin me komandën:

callbridge rinitizo

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Tani që kemi konfiguruar Call Bridge, mund të konfigurojmë klasterizimin e Call Bridge. Klasterizimi i Call Bridge ndryshon nga klasterizimi i bazave të të dhënave ose XMPP. Klasteri i Call Bridge mund të mbështesë nga 2 deri në 8 nyje pa asnjë kufizim. Ai siguron jo vetëm redundancë, por edhe shpërndarje ngarkese, duke lejuar që konferencat të shpërndahen aktivisht mes serverëve Call Bridge përmes shpërndarjes inteligjente të thirrjeve. CMS ka funksione të tjera, grupe Call Bridge dhe funksione të lidhura që mund të përdoren për menaxhim të mëtejshëm.

Klasterizimi i Call Bridge konfigurohet kryesisht përmes ndërfaqes së administratorit web.
Procedura e përshkruar më poshtë duhet të zbatohet në çdo server të klasterit.
Pra,

1. Hyni përmes web në Configuration > Cluster.
2. Në identitetin e Call Bridge si emër unik shkruajmë 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ë një karakter përshkrues, pasi tregojnë se këto janë identifikues të serverëve [01,02,03].
3. Në Call Bridges të Klasterizuar shkruajmë URL-të e administratorit web të serverëve tanë në klaster, cms[01,02,03].example.com:445, në fushën Address. Sigurohuni që të specifikoni portin. Mund ta lini Peerin lidhjen e domenit SIP bosh.
4. Shtoni në besim CallBridge të çdo serveri certifikatën, skedari i të cilit përmban të gjitha certifikatat e serverëve tanë, që i kemi bashkuar në këtë skedar në fillim, me komandën:

callbridge trust cluster <paketa e besueshme e certifikatave të klasterit>

Dhe rinitojmë shërbimin me komandën:

callbridge rinitizo

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Si rezultat, në secilin server duhet të ketë një pamje të tillë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të 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 web CMA WebRTC. Call Bridge gjithashtu vepron si klient XMPP për qëllime autentifikimi dhe, prandaj, duhet të konfigurohet si klientët e tjerë. Redundanca XMPP është një funksion që mbështetet në mjediset produksionale që nga versioni 2.1.

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

Lidhim certifikatat me shërbimin XMPP me komandën:

xmpp certs <skedari i çelësit> <skedari i certifikatës>[<paketa e certifikatave>]

Më pas përcaktoni ndërfaqen për të dëgjuar me komandën:

xmpp dëgjo a

Për shërbimin XMPP kërkohet një domen unik. Ky është identifikimi për përdoruesit. Në të tjerat, kur përdoruesi përpiqet të hyjë në sistem me aplikacionin CMA (ose përmes klientit WebRTC), ai shkruan userID@logindomain. Në rastin tonë, do të jetë userid@conf.example.com. Pse kjo nuk është thjesht example.com? Në implementimin tonë konkret ne zgjodhëm domenin tonë Unified CM, që përdoruesit e Jabber do të përdorin në Unified CM, si example.com, kështu që na nevojitet një domen tjetër për përdoruesit CMS, për të rruar thirrjet në CMS dhe nga CMS përmes domenesh SIP.

Konfiguroni domenin XMPP me komandën:

xmpp domain <domen>

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

xmpp enable

Në shërbimin XMPP, është e nevojshme të krijoni akreditive për secilën Call Bridge që do të përdoren për regjistrim në shërbimin XMPP. Këto emra janë të rastësishëm (dhe nuk janë të lidhur me emrat unikë që keni konfiguruar për grumbullimin e urave të thirrjeve). Në një server XMPP, nevojitet të shtoni tre ura thirrjesh dhe më pas të futni këto akreditive në serverët e tjerë XMPP në grumbull, pasi kjo konfigurim nuk mund të vendoset në bazën e të dhënave të grumbullit. Më vonë, ne do ta konfigurim secilën Call Bridge për të përdorur këtë emër dhe sekret për regjistrim në shërbimin XMPP.

Tani na nevojitet tĂ« konfiguroni shĂ«rbimin XMPP nĂ« serverin e parĂ« me tre Call Bridges callbridge01, callbridge02 dhe callbridge03. Çdo llogari do t'i caktohen fjalĂ«kalime tĂ« rastĂ«sishme. MĂ« vonĂ« ato do tĂ« futen nĂ« serverĂ«t e tjerĂ« Call Bridge pĂ«r t'u lidhur me kĂ«tĂ« server XMPP. Futni komandat e mĂ«poshtme:

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

Në fund kontrolloni çfarë është krijuar me komandën:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
I njëjti imazh duhet të jetë në serverët e tjerë pas veprimeve të përshkruara më poshtë.

Më pas, shtojmë në dy serverët e mbetur saktësisht të njëjtat cilësime, vetëm me komandat

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

Sekretin e shtojmë shumë kujdesshëm, në mënyrë që të mos përfshihen hapësira të panevojshme.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në fund, në çdo server duhet të ketë një pamje identike:

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Më pas, në të gjithë serverët e grumbullit, tregojmë një skedartë besimi që përmban të tria certifikatat, të krijuara më parë me komandën e tipit:

xmpp cluster trust

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

xmpp cluster enable

Në serverin e parë të grumbullit, iniciojmë krijimin e grumbullit xmpp me komandën:

xmpp cluster initialize

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

xmpp cluster join

Kontrolloni në çdo server suksesin e krijimit të grumbullit XMPP me komandat:

xmpp status
xmpp cluster status

Serveri i parë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Serveri i dytë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Serveri i tretë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Lidhja e Call Bridge me XMPP

Tani, kur grumbulli XMPP është aktivizuar, është e nevojshme të konfigurohen shërbimet Call Bridge për t'u lidhur me grumbullin XMPP. Kjo konfigurim bëhet përmes administratorit të internetit.

Hyni në çdo server në Configuration > General dhe në fushën Emri unik i Call Bridge shkruani emrat unikë të Call Bridge që i përkasin serverit callbridge[01,02,03]. Në fushën Domen conf.example.ru dhe fjalëkalimet përkatëse, mund t'i shihni
në çdo server të grumbullit me komandën:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Fusha "Server" e lëmë bosh, Callbridge do të realizojë një kërkesë 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-ave me XMPP mund të ndryshojnë në çdo server, kjo varet nga çfarë vlerash kthehet në kërkesën për regjistrin _xmpp-component._tcp.conf.example.com te callbridge, që nga ana e saj varet nga cilësimet e prioriteteve për këtë regjistër DNS.

Më pas, kalojmë në Status > General, për të siguruar që shërbimi Call Bride u lidh me shërbimin XMPP.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Web Bridge

Në çdo server të grumbullit aktivizuam shërbimin Web Bridge me komandën:

webbridge listen a:443

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

webbridge certs

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

webbridge http-redirect enable

Për të bërë të ditur Call Bridge që Web Bridge-i mund të besojë në lidhjet nga Call Bridge, përdorni komandën:

webbridge trust

ku ky është skedari që përmban të tria certifikatat nga çdo server në grumbull.

Kjo pamje duhet të jetë në çdo server të grumbullit.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Tani na nevojitet të krijojmë një përdorues me rolin "appadmin", i cili është i nevojshëm për të konfiguruar grumbullin tonë (!), dhe jo secilin server të grumbullit veç e veç, kështu që cilësimet do të aplikohen njësoj në çdo server, megjithëse do të realizohen një herë.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Për konfigurime të mëtejshme, do të përdorim Postman.

Për autorizimin, zgjidhni Basic në seksionin Autorization

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Për të dërguar komandat në serverët CMS në mënyrë korrekte, duhen vendosur kodimet e nevojshme

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

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

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në vetë webbridge-in, shënojmë parametrat e nevojshëm: qasje për mysafirë, qasje të sigurt, etj.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Grupet e Call Bridge

Nga e para, CMS nuk e përdor gjithmonë në mënyrën më efikase burimin që ka për lidhjet konferencuese.

Për shembull, për një takim me tre pjesëmarrës, çdo pjesëmarrës mund të ndodhet në tre Call Bridge të ndryshëm. Për të lejuar që këta tre pjesëmarrës të komunikojnë me njëri-tjetrin, Call Bridge-at automatikisht do të krijojnë lidhje mes të gjithë serverëve dhe klientëve në të njëjtin Space, duke krijuar përshtypjen se të gjithë klientët janë në një server. Fatkeqësisht, një mangësi e kësaj është se një konferencë me 3 njerëz tani do të përdorë 9 porta media. Kjo, natyrisht, është një shfrytëzim i parregullt i burimeve. Për më tepër, kur Call Bridge është vërtet i ngarkuar, mekanizmi nga default është që të vazhdojë të pranojë thirrje 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 përmes funksionit 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 si për thirrjet e ardhshme ashtu edhe për ato që dalin, përfshirë aplikacionin Cisco Meeting (CMA), duke përfshirë pjesëmarrësit WebRTC.

Për të zgjidhur problemin e rilidhjes, janë vendosur tre kufizime të personalizuara të ngarkesës për çdo Call Bridge:

LoadLimit — Ă«shtĂ« ngarkesa maksimale numerike pĂ«r njĂ« Call Bridge tĂ« caktuar. Çdo platformĂ« ka njĂ« kufi tĂ« rekomanduar ngarkese, si pĂ«r shembull 96000 pĂ«r CMS1000 dhe 1.25 GHz pĂ«r procesorin virtual pĂ«r makinĂ«n virtuale. Thirrje tĂ« ndryshme konsumojnĂ« njĂ« sasi tĂ« caktuar burimesh nĂ« varĂ«si tĂ« zgjidhjes dhe frekuencĂ«s sĂ« kornizĂ«s sĂ« pjesĂ«marrĂ«sve.
NewConferenceLoadLimitBasisPoints (nĂ« mĂ«nyrĂ« default 50% loadLimit) — pĂ«rcakton kufirin e ngarkesĂ«s pĂ«r serverin, pas tĂ« cilit konferencat e reja refuzohen.
ExistingConferenceLoadLimitBasisPoints (nĂ« mĂ«nyrĂ« default 80% tĂ« loadLimit) — vlera e ngarkesĂ«s pĂ«r serverin, pas tĂ« cilit pjesĂ«marrĂ«sit qĂ« bashkohen nĂ« njĂ« konferencĂ« ekzistuese do tĂ« refuzohen.

Ndërsa ky funksion u zhvillua për të shpërndarë thirrjet dhe për të shpërndarë ngarkesën, grupe të tjera, të tilla si serverët TURN, serverët Web Bridge dhe pajisjet e regjistrimit, gjithashtu mund të caktohen për Call Bridge Groups, kështu që ata gjithashtu mund të grupohen si duhet për përdorim optimal. Nëse ndonjë prej këtyre objekteve nuk është emëruar grupit të thirrjeve, supozohet se ato janë të disponueshme për të gjithë serverët pa ndonjë privilegj të caktuar.

Këto parametra janë të konfigurueshëm këtu: cms.example.com:445/api/v1/system/configuration/cluster

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Më pas, specifikojmë secilës callbridge në cilin grup callbridge i përket:

Callbridge i parë
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Callbridge i dytë
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Callbridge i tretë
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në këtë mënyrë kemi konfiguruar grupin Call Bridge për një përdorim më efikas të burimeve në klusterin Cisco Meeting Server.

Importimi i përdoruesve nga Active Directory

Shërbimi Web Admin ka një seksion konfigurimi LDAP, por ai nuk ofron opsione komplekse konfigurimi, dhe informacioni nuk ruhet në bazën e të dhënave të klasterit, kështu që konfigurimi duhet të bëhet, ose manualisht në çdo server përmes ndërfaqes Web, ose përmes API, dhe për të mos e bërë 'tre herë të ngrihemi' të dhënat do të vendosen përmes API.

Duke përdorur URL-në për qasje cms01.example.com:445/api/v1/ldapServers krijojmë një objekt LDAP Server duke specifikuar parametra të tillë si:

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

Sigurt — true ose false pĂ«rzgjidhni nĂ« varĂ«si tĂ« portit, 389 — i pasigurt, 636 — i sigurt.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Duke e mapuar parametrat LDAP të burimit në atributet në Cisco Meeting Server.
Mapping LDAP përputh atributet në katalogun LDAP me atributet në CMS. Vetë atributet:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Përshkrimi i AtributeveJID përfaqëson identifikuesin e hyrjes së përdoruesit në CMS. Siç është një server LDAP Microsoft Active Directory, JID CMS përputhet me sAMAccountName në LDAP, i cili esencialisht është identifikuesi i hyrjes për përdoruesin në Active Directory. Gjithashtu, vini re se merrni sAMAccountName dhe shtoni domenin conf.pod6.cms.lab në fund, sepse ky është logini që përdoruesit tuaj do të përdorin për t'u regjistruar në CMS.

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

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

coSpaceUriMapping përcakton pjesën e përdoruesit të URI e lidhur me space-in personal të përdoruesit. Disa domenë mund të konfigurohen për të thirrur në një space. Nëse pjesa e përdoruesit përputhet me këtë fushë për njërin nga këto domainë, thirrja do të drejtohet në space-in e atij përdoruesi.

coSpaceSecondaryUriMapping përcakton një URI të dytë për të arritur në hapësirë. Kjo mund të përdoret për të shtuar një pseudonim numerik për ridrejtimin e thirrjeve në hapësirën e përdoruesit të importuar si një alternativë për URI-në alfanumerike të përcaktuar në parametrin coSpaceUriMapping.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Serveri LDAP dhe mapimi LDAP janë konfiguruar. Tani është e nevojshme të lidhni 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ë kryejmë operacionin e sinkronizimit manual.

Këtë e bëjmë në web-interfalcën e çdo serveri duke klikuar Sync now në seksionin Active Directory
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

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

Konferencat Ad-Hoc

ÇfarĂ« Ă«shtĂ« kjo?NĂ« konceptin tradicional, njĂ« konferencĂ« Ă«shtĂ« kur dy pjesĂ«marrĂ«s flasin 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 pas bisedĂ«s me kĂ«tĂ« palĂ« tĂ« tretĂ« pĂ«rsĂ«ri shtyp butonin “KonferencĂ«â€ pĂ«r t'u bashkuar me tĂ« gjithĂ« pjesĂ«marrĂ«sit e konferencĂ«s me tre palĂ«.

Konferenca Ad-Hoc dallon nga konferenca e planifikuar nĂ« CMS, pasi qĂ« Konferenca Ad-Hoc 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Ă« bĂ«jĂ« njĂ« thirrje API pĂ«r CMS pĂ«r tĂ« krijuar njĂ« konferencĂ« 'nĂ« flakĂ«', nĂ« tĂ« cilĂ«n pastaj dĂ«rgohen tĂ« gjitha thirrjet. E gjithĂ« kjo 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 WebAdmin të shërbimit, si dhe SIP-Trunk direkt në serverin CMS për të vazhduar thirrjen.

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

Integrimi me CUCM konfigurohet siç është përshkruar në artikullin më parë përveç se në Cisco UCM duhet të krijoni tre trunka për CMS, tre Konferencë Bridge, në profilin e Sigurisë SIP të specifikoni tre emra Subjekt, Grupin e Rrugëve, Listën e Rrugëve, Grupin e Burimeve Multimediatike dhe Listën e Grupit të Burimeve Multimediatike, dhe në Cisco Meeting Server të shtoni pak rregulla të rrugës.

Profili i Sigurisë SIP:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Trunkat:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Çdo trunk duket njĂ«soj:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Konferencë Bridge
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Çdo KonferencĂ« Bridge duket njĂ«soj:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Grupi i Rrugëve
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Lista e Rrugëve
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Grupi i Burimeve Multimediatike
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Lista e Burimeve Multimediatike
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Rregullat e thirrjeve

Kundrejt sistemeve më të sofistikuara të menaxhimit të thirrjeve, siç janë Unified CM ose Expressway, për thirrjet e reja CMS shqyrton domenin 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 duhet të drejtojë thirrjen:

1. Në fillim, CMS përpiqet të përputhë domenin SIP me domenet e konfiguruara në rregullat e përpunimit të thirrjeve të ardhshme. Pastaj këto thirrje mund të dërgohen në ('target') hapësira ose përdorues të veçantë, IVR të brendshëm ose drejtpërdrejt adresat e integruara Microsoft Lync/Skype për biznes (S4B).
2. Nëse nuk ka përputhje në rregullat e përpunimit të thirrjeve të ardhshme, CMS do të përpiqet të përputhë domenin e konfiguruar në tabelën e redirektimit të thirrjeve. Nëse përputhja vendoset, rregulli mund të refuzojë në mënyrë të qartë thirrjen ose ta redirektojë atë. Në këtë kohë, CMS mund të rishkruajë domenin, që ndonjëherë është e dobishme për thirrjet në domenet Lync. Ju gjithashtu mund të zgjidhni kalimin, që do të thotë se asnjë nga fushat nuk do të ndryshohet më shumë, ose të përdorni grupin e abonentëve të brendshëm të CMS. Nëse nuk ka përputhje në rregullat e redirektimit të thirrjeve, standardi është refuzimi i thirrjes. Kini parasysh se në CMS, megjithëse thirrja është 'e redirektuar', multimedia është ende e lidhur me CMS, që do të thotë se ajo do të jetë në rrugën e sinjalizimit dhe trafikut multimedia.
Vetëm thirrjet e redirektuara i nënshtrohen rregullave të thirrjeve të dala. Këto opcione përcaktojnë adresat ku dërgohen thirrjet, llojin e linjës së lidhjes (qoftë një thirrje të re Lync apo një SIP standard) dhe çdo transformim që mund të kryhet nëse në rregullin e redirektimit të thirrjeve nuk është zgjedhur transmetimi.

Këtu është logu i saktë të asaj që ndodh gjatë një Konference Ad-Hoc

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në screenshot duket keq (nuk e di si ta bëj më mirë), prandaj do ta shkruaj logun kështu:

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

Info	telefonata e krijuar dështoi për të gjetur coSpace -- duke u përpjekur të rikuperojë nga baza e të dhënave

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: Përdoruesi API "api" krijoi telefonatën e re 93bfb890-646c-4364-8795-9587bfdc55ba

Info	telefonata 7: telefonatë SIP e ardhshme nga "sip:672@172.x.x.x" në URI lokale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e në telefonatën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

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

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

Info	telefonata 7: e konfiguruar - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e me SIP call ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	telefonata 7: po vendoset sesioni UDT RTP për DTLS (media dhe kontroll të kombinuara)
Info	konferenca "001036270012": këmbë të pa encryptuara tani janë të pranishme

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

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

Info	telefonata 8: telefonatë SIP e ardhshme nga "sip:690@172.x.x.x" në URI lokale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a në telefonatën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	telefonata 8: e konfiguruar - API call leg db61b242-1c6f-49bd-8339-091f62f5777a me SIP call ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	telefonata 8: po vendoset sesioni UDT RTP për DTLS (media dhe kontroll të kombinuara)

Info	telefonata 9: telefonatë SIP e ardhshme nga "sip:673@172.x.x.x" në URI lokale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a në telefonatën 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	telefonata 9: e konfiguruar - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a me SIP call ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	telefonata 9: po vendoset sesioni UDT RTP për DTLS (media dhe kontroll të kombinuara)
Info	telefonata 8: kompensimi për fundin e largët që nuk përputhet me tipet e ngarkesës

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

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

Info	telefonata 7: kompensimi për fundin e largët që nuk përputhet me tipet e ngarkesës
Info	telefonata 8: modaliteti i tipave të ngarkesës që nuk përputhen 1/0
Info	telefonata 8: po përgjigjem ofertës në modalitetin e tipave të ngarkesës që nuk përputhen
Info	telefonata 8: oferta e vetme e kodekëve është pranuar
Info	telefonata 8: modaliteti i tipave të ngarkesës që nuk përputhen 1/0
Info	telefonata 8: po përgjigjem ofertës në modalitetin e tipave të ngarkesës që nuk përputhen
Info	telefonata 8: duke dërguar përgjigjen në ofertën e mëtejshme me një kodek të vetëm
Info	telefonata 9: kompensimi për fundin e largët që nuk përputhet me tipet e ngarkesës

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

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

Info	telefonata 9: BFCP (roli i klientit) tani është aktiv
Info	telefonata 9: po dërgohet përshëndetje BFCP si klient pas marrjes së përshëndetjes kur BFCP nuk ishte aktiv
Info	telefonata 9: BFCP (roli i klientit) tani është aktiv
Info	telefonata 7: përfundimi; SIP-i i largët u shkatërrua - i lidhur për 0:13
Info	telefonata 7: shkatërrimi i API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	ndërhyrësi "672@x.x.x" la hapësirën 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	telefonata 9: në pritje
Info	telefonata 9: modaliteti i tipave të ngarkesës që nuk përputhen 1/0
Info	telefonata 9: po përgjigjem ofertës në modalitetin e tipave të ngarkesës që nuk përputhen
Info	telefonata 8: në pritje
Info	telefonata 8: oferta e vetme e kodekëve është pranuar
Info	telefonata 8: modaliteti i tipave të ngarkesës që nuk përputhen 1/0
Info	telefonata 8: po përgjigjem ofertës në modalitetin e tipave të ngarkesës që nuk përputhen
Info	telefonata 8: duke dërguar përgjigjen në ofertën e mëtejshme me një kodek të vetëm
Info	telefonata 9: përfundimi; SIP-i i largët u shkatërrua - i lidhur për 0:12

Konferenca Ad-Hoc vetë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Rregullat e telefonatave të ardhshme
Konfigurimi i parametrave të telefonatave të ardhshme është i nevojshëm për të pranuar telefonata në CMS. Siç e keni parë në konfigurimin LDAP, të gjithë përdoruesit u importuan me domenin conf.pod6.cms.lab. Prandaj, të paktën, dëshironi që telefonatat në këtë domain të drejtohen për hapësirat. Ju gjithashtu do të duhet të vendosni rregulla për gjithçka që është e destinuar për emrin e plotë të domenit (dhe ndoshta edhe për adresën IP) të secilit nga serverët CMS. Në kontrollin tonë të jashtëm të telefonatave, Unified CM, do të konfigurohen lidhjet SIP, të destinuara për secilin nga serverët CMS individualisht. Në varësi të asaj nëse përcaktimi i këtyre lidhjeve SIP është një adresë IP, ose emri i plotë i serverit do të përcaktojë nëse duhet të konfigurohet CMS për të pranuar telefonatat e drejtuara në adresën e tij IP ose emrin e plotë të domenit.

Domeni që ka rregullin e trafikut të ardhshëm me prioritetin më të lartë përcaktohet si domeni për çdo hapësirë përdoruesi. Kur përdoruesit sinkronizohen përmes LDAP, CMS krijon automatikisht hapësira, por vetëm pjesa përdoruese e URI (coSpaceUriMapping), për shembull, user.space. Pjesa domain e plotë e URI krijohet në bazë të këtij rregulli. Në të vërtetë, nëse do të hynit në Web Bridge në këtë fazë, do të shihnit se URI i Hapësirës nuk ka domen. Duke vendosur këtë rregull si prioritetin më të lartë, ju vendosni domenin për hapësirat e gjeneruara si conf.example.com.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Rregullat e telefonatave të jashtme

Për të lejuar përdoruesit të bëjnë telefonata të jashtme në klasterin Unified CM, është e nevojshme të konfigurohen rregullat e lidhjeve të telefonatave të jashtme. Domeni i pikave të regjistruara në Unified CM, si Jabber, është example.com. Telefonatat në këtë domain duhet të direccionohen si telefonata standarde SIP në nodet e përpunimit të telefonatave Unified CM. Si serveri kryesor është cucm-01.example.com, si shtesë cucm-02.example.com.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave
Rregulli i parë përshkruan ruterin më të thjeshtë të telefonatave midis serverëve të klasterit.

Fusha Local from domain përcakton se çfarë do të shfaqet në SIP-URI të thirrësit për atë që po thirret pas simbolit «@». Nëse e lëmë bosh, pas simbolit «@» do të jetë ip-adresa e CUCM-së përmes së cilës kalon kjo thirrje. Nëse përcaktojmë një domain, atëherë pas simbolit «@» do të jetë në të vërtetë domaini. Kjo është e nevojshme për të pasur mundësinë për të kthyer telefonat, përndryshe nuk do të jetë e mundur të rikthehemi në SIP-URI emri@ip-adresa.

Thirrja kur është e caktuar Local from domain
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Thirrja kur NË Ă«shtĂ« nĂ«nvizuar Local from domain
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Sigurohuni të përcaktoni qartë Encrypted ose Unencrypted do të jenë thirrje të dalshme, sepse me parametrin Auto nuk funksionon asgjë.

Regjistrimi

Regjistrimi i video-konferencave bëhet nga serveri Record. Recorder-i është në të vërtetë një Cisco Meeting Server. Recorder-i nuk kërkon që të instalohet asnjë licencë mbi të. 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 aplikuar për komponentin CallBridge, jo për serverin ku është aktivizuar Recorder-i. Recorder-i funksionon si një klient i protokollit të shkëmbimit të mesazheve dhe pranishmërisë (XMPP), prandaj serveri XMPP duhet të aktivizohet në serverin ku është vendosur CallBridge.

Duke qenë se kemi një grumbull dhe licencën duhet ta «shtrijmë» në të tre serverët e grumbullit. Pra, thjesht në kabinetin personal në licenca asociojmë (shtojmë) adresat MAC të ndërfaqeve a të të gjitha serverëve CMS që bëjnë pjesë në grumbull.

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Dhe kjo është pamja që duhet të jetë në secilin server të grumbullit

Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në të vërtetë, ekzistojnë disa skenarë për vendosjen e Recorder-it, por do të mbetemi në këtë:
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Para se të konfigurojmë Recorder-in, është e nevojshme të përgatitemi një vend ku do të regjistrohen video-konferencat. Kjo është link, si të konfigurojmë tërë regjistrimin. Do të theksoj disa pika dhe detaje të rëndësishme:

1. Certifikata është më mirë të ofrohet nga serveri i parë në grumbull.
2. Gabimi «Recorder unavailable» mund të ndodhë për shkak se nuk është e saktë certifikata e caktuar në Recorder Trust.
3. Regjistrimi mund të mos shkojë, nëse për regjistrim është caktuar një katalog i parëndësishëm në NFS.

Nganjëherë lind nevoja për të regjistruar automatikisht një konferencë të një përdoruesi ose të një hapësire të veçantë.

Për këtë krijohen dy CallProfile:
Me funksionin e regjistrimit të çaktivizuar
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Dhe me funksionin automatik të regjistrimit
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Më pas, për hapësirën e nevojshme, «lidhet» CallProfile me funksionin automatik të regjistrimit.
Cisco Meeting Server 2.5.2. Kluster në modalitetin e Shkallëzueshëm dhe Rezistent me funksionin e regjistrimit të videokonferencave

Në CMS është vendosur që nëse CallProfile është qartë tërhequr për ndonjë hapësirë ose hapësira, atëherë ky CallProfile punon vetëm për këto hapësira specifike. Nëse CallProfile nuk është tërhequr për asnjë hapësirë, atëherë në mënyrë të paracaktuar aplikohët për ato hapësira për të cilat asnjë CallProfile nuk është tërhequr qartë.

Herën tjetër do të përpiqem të përshkruaj se si arrihet qasje në CMS jashtë rrjetit të brendshëm të organizatës.

Burimet:

Burimi: habr.com

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