Cisco Meeting Server 2.5.2. Cluster în modul scalabil și rezistent cu funcție de înregistrare a conferințelor video

În această ediție, voi arăta și voi explica unele dintre complexitățile instalării unui server CMS în modul cluster de failover.


ТеорияÎn general, există trei tipuri de implementare a serverului CMS:

• Singur combinat(Singur combinat), adică acesta este un server pe care rulează toate serviciile necesare. În cele mai multe cazuri, acest tip de implementare este potrivit doar pentru accesul clientului intern și în medii mai mici în care limitările de scalabilitate și redundanță ale unui singur server nu sunt o problemă critică sau în situațiile în care CMS îndeplinește doar anumite funcții, cum ar fi ad-hoc conferințe despre Cisco UCM.

  Schema aproximativă de lucru:
  

• Single Split(Single Split) extinde tipul de implementare anterior prin adăugarea unui server separat pentru acces extern. În implementările vechi, aceasta însemna implementarea unui server CMS într-un segment de rețea demilitarizat (DMZ) unde clienții externi îl puteau accesa și a unui server CMS în nucleul rețelei unde clienții interni puteau accesa CMS. Acest model special de implementare este acum înlocuit de așa-numitul tip O singură margine, care constă din servere Cisco Expressway, care fie au sau vor avea multe dintre aceleași capacități de ocolire a firewall-ului, astfel încât clienții să nu fie nevoie să adauge un server CMS edge dedicat.

  Schema aproximativă de lucru:
  

• Scalabil și rezistent(Scalabil și tolerant la erori) Acest tip include redundanță pentru fiecare componentă, permițând sistemului să crească odată cu nevoile dumneavoastră la capacitatea sa maximă, oferind în același timp redundanță în caz de defecțiune. De asemenea, utilizează conceptul Single Edge pentru a oferi acces extern securizat. Acesta este tipul pe care îl vom privi în acest episod. Dacă înțelegem cum să implementăm acest tip de cluster, nu vom înțelege doar alte tipuri de implementări, dar vom putea înțelege și cum să creăm clustere de servere CMS pentru a face față creșterii potențiale a cererii.

Înainte de a trece la implementare, trebuie să înțelegeți câteva lucruri de bază, și anume

Principalele componente software CMS:

• Baza de date: Vă permite să combinați unele configurații, cum ar fi planul de apelare, spațiile utilizatorilor și utilizatorii înșiși. Acceptă clustering numai pentru disponibilitate ridicată (single master).
• Call Bridge: un serviciu pentru conferințe audio și video care oferă control deplin asupra gestionării și procesării apelurilor și proceselor multimedia. Suportă clustering pentru disponibilitate și scalabilitate ridicate.
• Server XMPP: responsabil pentru înregistrarea și autentificarea clienților care utilizează aplicația Cisco Meeting și/sau WebRTC(comunicare în timp real sau pur și simplu în browser), precum și semnalizarea intercomponentă. Poate fi grupat numai pentru disponibilitate ridicată.
• Web Bridge: Oferă acces client la WebRTC.
• Echilibrarea greutății: Oferă un singur punct de conectare pentru aplicațiile Cisco Meeting în modul Single Split. Ascultă interfața externă și portul pentru conexiunile de intrare. De asemenea, echilibratorul de încărcare acceptă conexiuni TLS de intrare de la serverul XMPP, prin care poate comuta conexiunile TCP de la clienți externi.
  În scenariul nostru nu va fi nevoie.
• TURN server: Oferă tehnologie de ocolire a firewall-ului care permite
  plasați CMS-ul nostru în spatele unui firewall sau NAT pentru a conecta clienți externi folosind aplicația Cisco Meeting sau dispozitivele SIP. În scenariul nostru nu va fi nevoie.
• Administrator web: Interfață administrativă și acces API, inclusiv pentru conferințe speciale Unified CM.

Moduri de configurare

Spre deosebire de majoritatea altor produse Cisco, Cisco Meeting Server acceptă trei metode de configurare pentru a găzdui orice tip de implementare.

• Linie de comandă (CLI): interfață de linie de comandă cunoscută sub numele de MMP pentru configurarea inițială și sarcinile de certificat.
• Administrator Web: În primul rând pentru configurațiile legate de CallBridge, în special atunci când configurați un singur server fără cluster.
• API-ul REST: Folosit pentru cele mai complexe sarcini de configurare și sarcini legate de bazele de date grupate.

Pe lângă cele de mai sus, se folosește protocolul SFTP pentru a transfera fișiere – de obicei licențe, certificate sau jurnale – către și de la serverul CMS.

În ghidurile de implementare de la Cisco este scris în alb și engleză că clusterul trebuie să fie implementat cel putin trei servere (noduri) în contextul bazelor de date. Deoarece Doar cu un număr impar de noduri va funcționa mecanismul de selectare a unui nou Database Master și, în general, Database Master are o conexiune cu majoritatea bazei de date a serverului CMS.

Și după cum arată practica, două servere (noduri) nu sunt într-adevăr suficiente. Mecanismul de selecție funcționează atunci când Master este repornit, serverul Slave devine Master numai după ce serverul repornit este deschis. Cu toate acestea, dacă într-un grup de două servere serverul Master se stinge brusc, atunci serverul Slave nu va deveni Master, iar dacă Slave se stinge, atunci serverul Master rămas va deveni Slave.

Dar în contextul XMPP, ar fi într-adevăr necesar să se asambleze un cluster de trei servere, deoarece dacă, de exemplu, dezactivați serviciul XMPP pe unul dintre serverele în care XMMP este în starea Leader, atunci pe serverul rămas XMPP va rămâne în starea Follower și conexiunile CallBridge la XMPP vor cădea, deoarece CallBridge se conectează exclusiv la XMPP cu statut Leader. Și acest lucru este critic, pentru că... nu va trece nici un apel.

De asemenea, în aceleași ghiduri de implementare este demonstrat un cluster cu un server XMPP.

Și ținând cont de cele de mai sus, devine clar de ce: funcționează pentru că este în modul failover.

În cazul nostru, serverul XMPP va fi prezent pe toate cele trei noduri.

Se presupune că toate cele trei servere sunt activate.

înregistrări DNS

Înainte de a începe configurarea serverelor, trebuie să creați înregistrări DNS А и SRV tipuri:

Vă rugăm să rețineți că în înregistrările noastre DNS există două domenii example.com și conf.exemplu.com. Example.com este un domeniu pe care toți abonații Cisco Unified Communication Manager îl pot folosi pentru URI-urile lor, care este cel mai probabil prezent în infrastructura dvs. sau este posibil să fie prezent. Sau example.com se potrivește cu același domeniu pe care utilizatorii îl folosesc pentru adresele lor de e-mail. Sau clientul Jabber de pe laptopul dvs. poate avea un URI [e-mail protejat]. Domeniu conf.example.com este domeniul care va fi configurat pentru utilizatorii Cisco Meeting Server. Domeniul Cisco Meeting Server va fi conf.example.com, deci pentru același utilizator Jabber, user@ URI ar trebui utilizat pentru a vă conecta la Cisco Meeting Serverconf.exemplu.com.

Configurație de bază

Toate setările descrise mai jos sunt afișate pe un singur server, dar trebuie făcute pe fiecare server din cluster.

QoS

Din moment ce CMS generează în timp real trafic sensibil la întârzieri și pierderi de pachete, în majoritatea cazurilor se recomandă configurarea calității serviciului (QoS). Pentru a realiza acest lucru, CMS acceptă etichetarea pachetelor cu codurile de servicii diferențiate (DSCP) pe care le generează. Deși prioritizarea traficului bazată pe DSCP depinde de modul în care traficul este procesat de componentele de rețea ale infrastructurii dvs., în cazul nostru vom configura CMS-ul nostru cu prioritizarea DSCP tipică pe baza celor mai bune practici QoS.

Pe fiecare server vom introduce aceste comenzi

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

Astfel, tot traficul video a fost marcat AF41 (DSCP 0x22), tot traficul de voce a fost marcat EF (DSCP 0x2E), alte tipuri de trafic cu latență scăzută precum SIP și XMPP folosesc AF31 (DSCP 0x1A).

Verificăm:

NTP

Network Time Protocol (NTP) este important nu numai pentru furnizarea de marcaje temporale precise ale apelurilor și conferințelor, ci și pentru verificarea certificatelor.

Adăugați servere NTP la infrastructura dvs. cu o comandă de genul

ntp server add <server>

În cazul nostru, există două astfel de servere, deci vor fi două echipe.
Verificăm:

Și setați fusul orar pentru serverul nostru

DNS

Adăugăm servere DNS la CMS cu o comandă ca:

dns add forwardzone <domain-name> <server ip>

În cazul nostru, există două astfel de servere, deci vor fi două echipe.
Verificăm:

Configurarea interfeței de rețea

Configuram interfata cu o comanda de genul:

ipv4 <interface> add <address>/<prefix length> <gateway>

Verificăm:

Nume server (nume gazdă)

Setăm numele serverului cu o comandă ca:

hostname <name>

Și repornim.


Aceasta completează configurația de bază.

certificări

ТеорияCisco Meeting Server necesită comunicare criptată între diferite componente și, ca urmare, certificatele X.509 sunt necesare pentru toate implementările CMS. Acestea ajută la asigurarea că serviciile/serverul este de încredere de către alte servere/servicii.

Fiecare serviciu necesită un certificat, dar crearea de certificate separate pentru fiecare serviciu poate duce la confuzie și la complexitate inutilă. Din fericire, putem genera perechea de chei public-privată a unui certificat și apoi le putem reutiliza în mai multe servicii. În cazul nostru, același certificat va fi folosit pentru Call Bridge, XMPP Server, Web Bridge și Web Admin. Astfel, trebuie să creați o pereche de chei de certificat publice și private pentru fiecare server din cluster.

Cu toate acestea, gruparea bazelor de date are anumite cerințe speciale de certificat și, prin urmare, necesită propriile certificate care sunt diferite de cele ale celorlalte servicii. CMS folosește un certificat de server, care este similar cu certificatele utilizate de alte servere, dar există și un certificat de client utilizat pentru conexiunile la baze de date. Certificatele bazelor de date sunt folosite atât pentru autentificare, cât și pentru criptare. În loc să furnizeze un nume de utilizator și o parolă pentru ca clientul să se conecteze la baza de date, acesta prezintă un certificat de client care este de încredere de către server. Fiecare server din clusterul de baze de date va folosi aceeași pereche de chei publice și private. Acest lucru permite tuturor serverelor din cluster să cripteze datele în așa fel încât să poată fi decriptate numai de către alte servere care împărtășesc aceeași pereche de chei.

Pentru ca redundanța să funcționeze, clusterele de baze de date trebuie să fie formate din minim 3 servere, dar nu mai mult de 5, cu un timp maxim de călătorie dus-întors de 200 ms între oricare dintre membrii clusterului. Această limită este mai restrictivă decât pentru clustering Call Bridge, deci este adesea factorul limitativ în implementările distribuite geografic.

Rolul bazei de date pentru un CMS are o serie de cerințe unice. Spre deosebire de alte roluri, necesită un certificat de client și server, în care certificatul de client are un câmp CN specific care este prezentat serverului.

CMS folosește o bază de date postgres cu un master și mai multe replici complet identice. Există o singură bază de date primară la un moment dat („serverul bazei de date”). Membrii rămași ai clusterului sunt replici sau „clienți baze de date”.

Un cluster de baze de date necesită un certificat de server dedicat și un certificat de client. Acestea trebuie să fie semnate prin certificate, de obicei o autoritate de certificare privată internă. Deoarece orice membru al clusterului de baze de date poate deveni master, perechile de certificate de server de bază de date și client (conținând cheile publice și private) trebuie copiate pe toate serverele, astfel încât acestea să își poată asuma identitatea clientului sau a serverului de bază de date. În plus, certificatul rădăcină CA trebuie să fie încărcat pentru a se asigura că certificatele client și server pot fi verificate.

Deci, creăm o solicitare pentru un certificat care va fi folosit de toate serviciile serverului, cu excepția bazei de date (va exista o cerere separată pentru aceasta) cu o comandă de genul:

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

În CN scriem numele general al serverelor noastre. De exemplu, dacă numele de gazdă ale serverelor noastre server01, server02, server03, atunci va fi CN server.example.com

Facem același lucru pe celelalte două servere, cu diferența că comenzile vor conține „numele de gazdă” corespunzătoare

Generăm două solicitări de certificate care vor fi utilizate de serviciul de bază de date cu comenzi precum:

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

pki csr dbclusterclient CN:postgres

unde dbclusterserver и dbclusterclient numele cererilor noastre și viitoarele certificate, nume gazdă1(2)(3) numele serverelor corespunzătoare.

Efectuăm această procedură doar pe un singur server (!), și vom încărca certificatele și fișierele .key corespunzătoare pe alte servere.

Activați modul certificat client în AD CS

De asemenea, trebuie să îmbinați certificatele pentru fiecare server într-un singur fișier.Pe *NIX:

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

Pe Windows/DOS:

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

Și încărcați pe fiecare server:
1. Certificat de server „individual”.
2. Certificat rădăcină (împreună cu cele intermediare, dacă există).
3. Certificate pentru baza de date („server” și „client”) și fișiere cu extensia .key, care au fost generate la crearea unei cereri pentru certificatele bazei de date „server” și „client”. Aceste fișiere trebuie să fie aceleași pe toate serverele.
4. Dosarul tuturor celor trei certificate „individuale”.

Ca rezultat, ar trebui să obțineți ceva ca această imagine de fișier pe fiecare server.

Cluster de baze de date

Acum că aveți toate certificatele încărcate pe serverele CMS, puteți configura și activa gruparea bazelor de date între cele trei noduri. Primul pas este să selectați un server ca nod principal al clusterului de baze de date și să îl configurați complet.

Baza de date master

Primul pas în configurarea replicării bazei de date este să specificați certificatele care vor fi utilizate pentru baza de date. Acest lucru se face folosind o comandă ca:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Acum să spunem CMS-ului ce interfață să folosească pentru gruparea bazei de date cu comanda:

database cluster localnode a

Apoi inițializam baza de date cluster pe serverul principal cu comanda:

database cluster initialize

Nodurile bazei de date client

Facem aceeași procedură, doar în loc de comandă inițializarea clusterului bazei de date introduceți o comandă ca:

database cluster join <ip address existing master>

unde adresa ip adresa IP master existentă a serverului CMS pe care a fost inițializat clusterul, pur și simplu Master.

Verificăm cum funcționează clusterul nostru de baze de date pe toate serverele cu comanda:

database cluster status

Facem același lucru pe cel de-al treilea server rămas.

Ca urmare, se dovedește că primul nostru server este Master, restul sunt Sclavi.

Serviciul de administrare web

Activați serviciul de administrator web:

webadmin listen a 445

Portul 445 a fost ales deoarece portul 443 este folosit pentru accesul utilizatorului la clientul web

Configuram serviciul Web Admin cu fișiere de certificat cu o comandă ca:

webadmin certs <keyfile> <certificatefile> <ca bundle>

Și activați Web Admin cu comanda:

webadmin enable

Dacă totul este bine, vom primi linii SUCCES care indică faptul că Web Admin este configurat corect pentru rețea și certificat. Verificăm funcționalitatea serviciului folosind un browser web și introducem adresa administratorului web, de exemplu: cms.example.com: 445

Call Bridge Cluster

Call Bridge este singurul serviciu prezent în fiecare implementare CMS. Call Bridge este principalul mecanism de conferință. De asemenea, oferă o interfață SIP, astfel încât apelurile să poată fi direcționate către sau de la aceasta de, de exemplu, un Cisco Unified CM.

Comenzile descrise mai jos trebuie executate pe fiecare server cu certificatele corespunzătoare.
Deci:

Asociem certificatele cu serviciul Call Bridge cu o comandă ca:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Legăm serviciile CallBridge la interfața de care avem nevoie cu comanda:

callbridge listen a

Și reporniți serviciul cu comanda:

callbridge restart

Acum că avem Call Bridge-urile configurate, putem configura clustering Call Bridge. Clusteringul Call Bridge este diferit de clusteringul bazei de date sau XMPP. Call Bridge Cluster poate suporta de la 2 la 8 noduri fără nicio restricție. Acesta oferă nu numai redundanță, ci și echilibrare a sarcinii, astfel încât conferințele să poată fi distribuite în mod activ pe serverele Call Bridge folosind distribuția inteligentă a apelurilor. CMS-ul are funcții suplimentare, grupuri Call Bridge și caracteristici conexe care pot fi utilizate pentru management ulterioar.

Clustering bridge-ul de apeluri este configurat în primul rând prin interfața de administrare web
Procedura descrisă mai jos trebuie efectuată pe fiecare server din cluster.
Astfel,

1. Accesați web la Configurare > Cluster.
2. În Identitatea Call Bridge Ca nume unic, introduceți callbridge[01,02,03] corespunzător numelui serverului. Aceste nume sunt arbitrare, dar trebuie să fie unice pentru acest cluster. Ele sunt de natură descriptivă deoarece indică faptul că sunt identificatori de server [01,02,03].
3.B Poduri de apel în cluster introduceți adresele URL ale administratorului web ale serverelor noastre din cluster, CMS[01,02,03].example.com:445, în câmpul Adresă. Asigurați-vă că specificați portul. Puteți lăsa domeniul SIP peer link gol.
4. Adăugați un certificat la încrederea CallBridge a fiecărui server, al cărui fișier conține toate certificatele serverelor noastre, pe care le-am îmbinat în acest fișier la început, cu o comandă ca:

callbridge trust cluster <trusted cluster certificate bundle>

Și reporniți serviciul cu comanda:

callbridge restart

Ca rezultat, pe fiecare server ar trebui să obțineți această imagine:

Cluster XMPP

Serviciul XMPP din CMS este utilizat pentru a gestiona toate înregistrările și autentificarea pentru Cisco Meeting Apps (CMA), inclusiv clientul web CMA WebRTC. Call Bridge-ul în sine acționează și ca un client XMPP în scopuri de autentificare și, prin urmare, trebuie configurat ca și alți clienți. Toleranța la erori XMPP este o caracteristică care a fost acceptată în mediile de producție începând cu versiunea 2.1

Comenzile descrise mai jos trebuie executate pe fiecare server cu certificatele corespunzătoare.
Deci:

Asociem certificatele cu serviciul XMPP cu o comandă ca:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Apoi definiți interfața de ascultare cu comanda:

xmpp listen a

Serviciul XMPP necesită un domeniu unic. Aceasta este autentificarea pentru utilizatori. Cu alte cuvinte, atunci când un utilizator încearcă să se autentifice folosind aplicația CMA (sau prin clientul WebRTC), acesta introduce userID@logindomain. În cazul nostru, va fi userid@conf.exemplu.com. De ce nu este doar example.com? În implementarea noastră specială, am selectat domeniul nostru Unified CM pe care utilizatorii Jabber îl vor folosi în Unified CM ca example.com, așa că aveam nevoie de un domeniu diferit pentru utilizatorii CMS pentru a direcționa apelurile către și de la CMS prin domeniile SIP.

Configurați un domeniu XMPP folosind o comandă ca:

xmpp domain <domain>

Și activați serviciul XMPP cu comanda:

xmpp enable

În serviciul XMPP, trebuie să creați acreditări pentru fiecare Call Bridge care va fi utilizat la înregistrarea la serviciul XMPP. Aceste nume sunt arbitrare (și nu au legătură cu numele unice pe care le-ați configurat pentru clustering bridge bridge). Trebuie să adăugați trei punți de apel pe un server XMPP și apoi să introduceți acele acreditări pe alte servere XMPP din cluster, deoarece această configurație nu se încadrează în baza de date a clusterului. Mai târziu vom configura fiecare Call Bridge să folosească acest nume și secret pentru a se înregistra la serviciul XMPP.

Acum trebuie să configuram serviciul XMPP pe primul server cu trei Call Bridge-uri callbridge01, callbridge02 și callbridge03. Fiecărui cont i se vor atribui parole aleatorii. Acestea vor fi introduse ulterior pe alte servere Call Bridge pentru a se conecta la acest server XMPP. Introduceți următoarele comenzi:

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

Ca rezultat, verificăm ce s-a întâmplat cu comanda:

xmpp callbridge list

Exact aceeași imagine ar trebui să apară pe serverele rămase după pașii descriși mai jos.

În continuare, adăugăm exact aceleași setări pe celelalte două servere, doar cu comenzile

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

Adăugăm Secret foarte atent, astfel încât, de exemplu, să nu existe spații suplimentare în el.


Ca rezultat, fiecare server ar trebui să aibă aceeași imagine:

Apoi, pe toate serverele din cluster, specificăm în încredere fișierul care conține toate cele trei certificate, creat anterior cu o comandă ca aceasta:

xmpp cluster trust <trust bundle>

Activem modul cluster xmpp pe toate serverele cluster cu comanda:

xmpp cluster enable

Pe primul server al clusterului, inițiam crearea unui cluster xmpp cu comanda:

xmpp cluster initialize

Pe alte servere, adăugați un cluster la xmpp cu o comandă ca:

xmpp cluster join <ip address head xmpp server>

Verificăm pe fiecare server succesul creării unui cluster XMPP pe fiecare server cu comenzile:

xmpp status
xmpp cluster status

Primul server:

Al doilea server:

Al treilea server:

Conectarea Call Bridge la XMPP

Acum, când clusterul XMPP rulează, trebuie să configurați serviciile Call Bridge pentru a vă conecta la clusterul XMPP. Această configurare se face prin intermediul administratorului web.

Pe fiecare server, accesați Configurare > General și în câmp Nume unic Call Bridge scrieți nume unice corespunzătoare serverului Call Bridge callbridge[01,02,03]... În câmp domeniu conf.example.ru și parolele corespunzătoare, le puteți spiona
pe orice server din cluster cu comanda:

xmpp callbridge list

Lăsați câmpul „Server” gol Callbridge va efectua o căutare DNS SRV pentru _xmpp-component._tcp.conf.example.compentru a găsi un server XMPP disponibil. Adresele IP pentru conectarea callbridge-urilor la XMPP pot diferi pe fiecare server, depinde de ce valori sunt returnate la cererea de înregistrare _xmpp-component._tcp.conf.example.com callbridge, care, la rândul său, depinde de setările de prioritate pentru o anumită înregistrare DNS.

Apoi, accesați Stare > General pentru a verifica dacă serviciul Call Bride este conectat cu succes la serviciul XMPP.

Web Bridge

Pe fiecare server din cluster, activați serviciul Web Bridge cu comanda:

webbridge listen a:443

Configuram serviciul Web Bridge cu fișiere de certificat cu o comandă ca:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge acceptă HTTPS. Acesta va redirecționa HTTP către HTTPS dacă este configurat să folosească „http-redirect”.
Pentru a activa redirecționarea HTTP, utilizați următoarea comandă:

webbridge http-redirect enable

Pentru a informa Call Bridge că Web Bridge poate avea încredere în conexiunile de la Call Bridge, utilizați comanda:

webbridge trust <certfile>

unde acesta este un fișier care conține toate cele trei certificate de la fiecare server din cluster.

Această imagine ar trebui să fie pe fiecare server din cluster.


Acum trebuie să creăm un utilizator cu rolul „appadmin”, avem nevoie de el pentru a ne putea configura clusterul(!), și nu fiecare server din cluster separat, în acest fel setările vor fi aplicate în mod egal fiecărui server în ciuda faptul că vor fi făcute o dată.


Pentru configurarea ulterioară vom folosi poștaș.

Pentru autorizare, selectați De bază în secțiunea Autorizare

Pentru a trimite corect comenzi către serverul CMS, trebuie să setați codificarea necesară

Specificăm Webbridge cu comanda POST cu parametru url și sens cms.example.com



În webbridge-ul propriu-zis, indicăm parametrii necesari: acces invitat, acces protejat etc.

Grupuri de poduri de apeluri

În mod implicit, CMS nu folosește întotdeauna cât mai eficient resursele de conferință disponibile.

De exemplu, pentru o întâlnire cu trei participanți, fiecare participant poate ajunge pe trei Call Bridge-uri diferite. Pentru ca acești trei participanți să comunice între ei, Call Bridges va stabili automat conexiuni între toate serverele și clienții din același spațiu, astfel încât totul să arate ca și cum toți clienții sunt pe același server. Din păcate, dezavantajul acestui lucru este că o singură conferință de 3 persoane va consuma acum 9 porturi media. Aceasta este evident o utilizare ineficientă a resurselor. În plus, atunci când un Call Bridge este cu adevărat supraîncărcat, mecanismul implicit este să continue să accepte apeluri și să ofere servicii de calitate redusă tuturor abonaților acelui Call Bridge.

Aceste probleme sunt rezolvate folosind funcția Call Bridge Group. Această caracteristică a fost introdusă în versiunea 2.1 a software-ului Cisco Meeting Server și a fost extinsă pentru a suporta echilibrarea încărcăturii atât pentru apelurile Cisco Meeting App (CMA) de intrare, cât și pentru cele de ieșire, inclusiv participanții WebRTC.

Pentru a rezolva problema de reconectare, au fost introduse trei limite de sarcină configurabile pentru fiecare Call Bridge:

LoadLimit — aceasta este sarcina numerică maximă pentru un anumit Call Bridge. Fiecare platformă are o limită de încărcare recomandată, cum ar fi 96000 pentru CMS1000 și 1.25 GHz per vCPU pentru mașina virtuală. Apelurile diferite consumă o anumită cantitate de resurse în funcție de rezoluția și rata de cadre a participantului.
NewConferenceLoadLimitBasisPoints (implicit 50% loadLimit) - setează limita de încărcare a serverului, după care noile conferințe sunt respinse.
ExistingConferenceLoadLimitBasisPoints (implicit 80% din loadLimit) - valoarea de încărcare a serverului după care participanții care se alătură unei conferințe existente vor fi respinși.

În timp ce această caracteristică a fost concepută pentru distribuția apelurilor și echilibrarea încărcăturii, alte grupuri, cum ar fi serverele TURN, serverele Web Bridge și înregistratoarele pot fi, de asemenea, alocate Grupurilor Call Bridge, astfel încât acestea să poată fi, de asemenea, grupate corespunzător pentru o utilizare optimă. Dacă oricare dintre aceste obiecte nu este atribuit unui grup de apeluri, se presupune că ele sunt disponibile pentru toate serverele fără nicio prioritate specială.

Acești parametri sunt configurați aici: cms.example.com:445/api/v1/system/configuration/cluster

În continuare, indicăm fiecărui callbridge cărui grup de callbridge îi aparține:

Primul callbridge

Al doilea callbridge

Al treilea callbridge


Astfel, am configurat grupul Call Brdge pentru a utiliza mai eficient resursele clusterului Cisco Meeting Server.

Importul utilizatorilor din Active Directory

Serviciul Web Admin are o secțiune de configurare LDAP, dar nu oferă opțiuni complexe de configurare, iar informațiile nu sunt stocate în baza de date a clusterului, așa că configurarea va trebui făcută, fie manual pe fiecare server prin interfața Web, fie prin intermediul API-ul și pentru ca „de trei ori „Nu te trezi”, vom seta în continuare datele prin API.

Folosind URL-ul pentru acces cms01.example.com:445/api/v1/ldapServers creează un obiect Server LDAP, specificând parametri precum:

• IP server
• numarul portului
• Nume de utilizator
• parolă
• sigur

Securizat - selectați adevărat sau fals în funcție de port, 389 - nesecurizat, 636 - protejat.


Maparea parametrilor sursei LDAP la atribute în Cisco Meeting Server.
Maparea LDAP mapează atributele din directorul LDAP cu atributele din CMS. Atributele reale:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Descrierea atributelorJID reprezintă ID-ul de conectare al utilizatorului în CMS. Deoarece acesta este un server LDAP Microsoft Active Directory, JID-ul CMS se mapează la sAMAccountName din LDAP, care este în esență ID-ul de conectare la Active Directory al utilizatorului. De asemenea, rețineți că luați sAMAccountName și adăugați domeniul conf.pod6.cms.lab la sfârșitul acestuia, deoarece acesta este login-ul pe care îl vor folosi utilizatorii dvs. pentru a se conecta la CMS.

nameMapping potrivește ceea ce este conținut în câmpul displayName Active Directory cu câmpul numelui CMS al utilizatorului.

coSpaceNameMapping creează un nume de spațiu CMS pe baza câmpului displayName. Acest atribut, împreună cu atributul coSpaceUriMapping, este ceea ce este necesar pentru a crea un spațiu pentru fiecare utilizator.

coSpaceUriMapping definește partea utilizatorului din URI asociată cu spațiul personal al utilizatorului. Unele domenii pot fi configurate pentru a fi apelate în spațiu. Dacă partea utilizator se potrivește cu acest câmp pentru unul dintre aceste domenii, apelul va fi direcționat către spațiul utilizatorului respectiv.

coSpaceSecondaryUriMapping definește un al doilea URI pentru a ajunge la spațiu. Acesta poate fi folosit pentru a adăuga un alias numeric pentru rutarea apelurilor către spațiul utilizatorului importat ca alternativă la URI alfanumeric definit în parametrul coSpaceUriMapping.

Serverul LDAP și maparea LDAP sunt configurate. Acum trebuie să le legați împreună prin crearea unei surse LDAP.

Folosind URL-ul pentru acces cms01.example.com:445/api/v1/ldapSource creează un obiect sursă LDAP, specificând parametri precum:

• serverul
• cartografiere
• bazaDn
• filtru

Acum că configurarea LDAP este completă, puteți efectua operația de sincronizare manuală.

Facem acest lucru fie în interfața Web a fiecărui server făcând clic Sincronizează acum În capitol Active Directory


sau prin API cu comanda POST folosind URL-ul pentru a accesa cms01.example.com:445/api/v1/ldapSyncs

Conferințe ad-hoc

Ce este asta?În conceptul tradițional, o conferință este atunci când doi participanți vorbesc între ei, iar unul dintre participanți (folosind un dispozitiv înregistrat cu Unified CM) apasă butonul „Conferință”, sună cealaltă persoană și, după ce vorbește cu acea terță parte , apăsați din nou butonul „Conferință” pentru a vă alătura tuturor participanților la conferința tripartită.

Ceea ce diferențiază o conferință Ad-Hoc de o conferință programată într-un CMS este că o conferință Ad-Hoc nu este doar un apel SIP către un CMS. Când inițiatorul conferinței dă clic a doua oară pe butonul Conferință pentru a invita pe toți la aceeași întâlnire, Unified CM trebuie să efectueze un apel API către CMS pentru a crea o conferință din mers la care sunt apoi transferate toate apelurile. Toate acestea se întâmplă neobservate de participanți.

Aceasta înseamnă că Unified CM trebuie să configureze acreditările API și adresa/portul WebAdmin al serviciului, precum și trunchiul SIP direct la serverul CMS pentru a continua apelul.

Dacă este necesar, CUCM poate crea în mod dinamic un spațiu în CMS, astfel încât fiecare apel să poată ajunge la CMS și să se potrivească cu regula apelului de intrare care este destinat spațiilor.

Integrare cu CUCM configurat în același mod ca cel descris în articol mai devreme cu excepția faptului că pe Cisco UCM trebuie să creați trei trunchiuri pentru CMS, trei poduri de conferință, în Profilul de securitate SIP specificați trei nume de subiecte, grupuri de rute, liste de rute, grupuri de resurse media și liste de grupuri de resurse media și adăugați câteva reguli de rutare la Cisco Meeting Server.

Profil de securitate SIP:


Trunchiuri:


Fiecare portbagaj arată la fel:




Podul conferinței


Fiecare pod de conferință arată la fel:


Grup de rute


Lista rutelor


Grupul de resurse media


Lista grupurilor de resurse media

Reguli de apel

Spre deosebire de sistemele mai avansate de gestionare a apelurilor, cum ar fi Unified CM sau Expressway, CMS caută doar domeniul în câmpul SIP Request-URI pentru apeluri noi. Deci, dacă SIP INVITE este pentru sip: [e-mail protejat]CMS-ului îi pasă doar de domain.com. CMS urmează aceste reguli pentru a determina unde să direcționeze un apel:

1. CMS încearcă mai întâi să potrivească domeniul SIP cu domeniile configurate în regulile pentru apeluri de intrare. Aceste apeluri pot fi apoi direcționate către spații (“țintite”) sau către anumiți utilizatori, IVR-uri interne sau destinații integrate direct Microsoft Lync/Skype for Business (S4B).
2. Dacă nu există nicio potrivire în regulile de apel de intrare, CMS va încerca să se potrivească cu domeniul configurat în tabelul de redirecționare a apelurilor. Dacă se realizează o potrivire, regula poate respinge în mod explicit apelul sau poate redirecționa apelul. În acest moment, CMS-ul poate rescrie domeniul, ceea ce este uneori util pentru apelarea domeniilor Lync. De asemenea, puteți alege să treceți aruncarea, ceea ce înseamnă că niciunul dintre câmpuri nu va fi modificat în continuare sau să utilizați un plan de apelare CMS intern. Dacă nu există nicio potrivire în regulile de redirecționare a apelurilor, implicit este respingerea apelului. Rețineți că în CMS, deși apelul este „redirecționat”, media este în continuare legată de CMS, ceea ce înseamnă că va fi pe calea de semnalizare și trafic media.
Atunci numai apelurile redirecționate sunt supuse regulilor privind apelurile de ieșire. Aceste setări determină destinațiile în care sunt trimise apelurile, tipul trunchiului (fie că este un nou apel Lync sau un apel SIP standard) și orice conversie care poate fi efectuată dacă transferul nu este selectat în regula de redirecționare a apelurilor.

Iată jurnalul real al ceea ce se întâmplă în timpul unei conferințe ad-hoc

Captura de ecran o arată prost (nu știu cum să o fac mai bună), așa că voi scrie jurnalul astfel:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

Conferința ad-hoc în sine:


Reguli pentru apelurile primite
Configurarea parametrilor apelurilor primite este necesară pentru a putea primi un apel în CMS. După cum ați văzut în configurarea LDAP, toți utilizatorii au fost importați cu domeniul conf.pod6.cms.lab. Deci, cel puțin, doriți ca apelurile către acest domeniu să vizeze spații. De asemenea, va trebui să configurați reguli pentru tot ceea ce este destinat pentru numele de domeniu complet calificat (și poate chiar adresa IP) al fiecăruia dintre serverele CMS. Controlul nostru extern al apelurilor, Unified CM, va configura trunchiuri SIP dedicate fiecărui server CMS în mod individual. În funcție de dacă destinația acestor trunchiuri SIP este o adresă IP sau FQDN-ul serverului va determina dacă CMS-ul trebuie configurat pentru a accepta apeluri direcționate către adresa sa IP sau FQDN.

Domeniul care are regula de intrare cu cea mai mare prioritate este utilizat ca domeniu pentru orice spații utilizator. Când utilizatorii se sincronizează prin LDAP, CMS creează automat spații, dar numai partea utilizator a URI (coSpaceUriMapping), de exemplu, user.space. Parte domeniu URI-ul complet este generat pe baza acestei reguli. De fapt, dacă ar fi să vă conectați la Web Bridge în acest moment, veți vedea că URI-ul Space nu are un domeniu. Setând această regulă ca cea mai mare prioritate, setați domeniul pentru spațiile generate conf.exemplu.com.


Reguli pentru apeluri de ieșire

Pentru a permite utilizatorilor să efectueze apeluri de ieșire către clusterul Unified CM, trebuie să configurați regulile de ieșire. Domeniul punctelor finale înregistrate cu Unified CM, cum ar fi Jabber, este example.com. Apelurile către acest domeniu ar trebui direcționate ca apeluri SIP standard către nodurile de procesare a apelurilor Unified CM. Serverul principal este cucm-01.example.com, iar serverul suplimentar este cucm-02.example.com.

Prima regulă descrie cea mai simplă rutare a apelurilor între serverele cluster.

Câmp Local din domeniu este responsabil pentru ceea ce va fi afișat în SIP-URI al apelantului pentru persoana apelată după simbolul „@”. Dacă îl lăsăm gol, atunci după simbolul „@” va apărea adresa IP a CUCM prin care trece acest apel. Dacă specificăm un domeniu, atunci după simbolul „@” va fi de fapt un domeniu. Acest lucru este necesar pentru a putea apela înapoi, altfel nu va fi posibil să apelați înapoi prin SIP-URI nume@adresă-ip.

Sună când este indicat Local din domeniu


Sună când NU indicat Local din domeniu


Asigurați-vă că specificați în mod explicit Criptat sau Necriptat pentru apelurile efectuate, deoarece nimic nu funcționează cu parametrul Auto.

Înregistrare

Conferințele video sunt înregistrate de serverul de înregistrare. Recorderul este exact același cu Cisco Meeting Server. Recorderul nu necesită instalarea niciunei licențe. Licențele de înregistrare sunt necesare pentru serverele care rulează serviciile CallBridge, de ex. este necesară o licență de înregistrare și trebuie aplicată la componenta CallBridge și nu la serverul care rulează Recorder. Recorderul se comportă ca un client XMPP (Extensible Messaging and Presence Protocol), astfel încât serverul XMPP trebuie să fie activat pe serverul care găzduiește CallBridge.

Deoarece Avem un cluster și licența trebuie să fie „întinsă” pe toate cele trei servere din cluster. Apoi pur și simplu în contul tău personal în licențe asociem (adăugăm) adresele MAC ale interfețelor a tuturor serverelor CMS incluse în cluster.

Și aceasta este imaginea care ar trebui să fie pe fiecare server din cluster

În general, există mai multe scenarii pentru plasarea Recorderului, dar ne vom menține la aceasta:


Înainte de a configura Recorder, trebuie să pregătiți un loc unde vor fi de fapt înregistrate videoconferințele. De fapt aici legătură, cum să configurați toate Înregistrările. Mă concentrez pe puncte și detalii importante:

1. Este mai bine să strecurați certificatul de la primul server din cluster.
2. Eroarea „Recorder unavailable” poate apărea deoarece certificatul greșit este specificat în Recorder Trust.
3. Este posibil ca scrierea să nu funcționeze dacă directorul NFS specificat pentru înregistrare nu este directorul rădăcină.

Uneori este nevoie să înregistrați automat o conferință a unui anumit utilizator sau spațiu.

Pentru aceasta, sunt create două CallProfiles:
Cu înregistrarea dezactivată


Și cu funcție de înregistrare automată


Apoi, „atașăm” un CallProfile cu funcție de înregistrare automată la spațiul necesar.


În CMS este stabilit astfel încât, dacă un CallProfile este legat în mod explicit de orice spațiu sau spațiu, atunci acest CallProfile funcționează numai în legătură cu aceste spații specifice. Și dacă CallProfile nu este legat de niciun spațiu, atunci în mod implicit este aplicat acelor spații la care niciun CallProfile nu este legat în mod explicit.

Data viitoare voi încerca să descriu cum este accesat CMS-ul în afara rețelei interne a organizației.

Surse:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

Sursa: www.habr.com