Cisco Meeting Server 2.5.2. Cluster în modul Scalabil și Rezistent cu funcția de înregistrare a videoconferințelor

În acest episod, vă voi arăta și explica câteva subtilități ale configurării serverului CMS în modul de cluster tolerant la erori.


TeorieExistă, în general, trei tipuri de desfășurare a serverului CMS:

• Single Combined(Unitate combinată), adică este un singur server pe care sunt rulate toate serviciile necesare. În cele mai multe cazuri, acest tip de desfășurare este aplicabil doar pentru accesul clienților interni și în medii mici, unde 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, precum conferințele speciale pe Cisco UCM.

  Schema aproximativă de lucru:
  

• Single Split(Unitate împărțită) extinde tipul de desfășurare anterior, adăugând un server separat pentru accesul extern. În desfășurările vechi, aceasta însemna desfășurarea serverului CMS în segmentul demilitarizat al rețelei (DMZ), unde clienții externi ar putea avea acces la el, și un singur server CMS în nucleul rețelei, unde clienții interni au acces la CMS. Această model de desfășurare specific acum este înlocuit de așa-numitul tip Single Edge, care constă în servere Cisco Expressway, care au sau vor avea multe dintre capabilitățile de ocolire a firewall-ului, astfel încât clienții să nu fie nevoiți să adauge un server de frontieră CMS dedicat.

  Schema aproximativă de lucru:
  

• Scalable and Resilient(Scalabil și tolerant la erori) acest tip include redundanță pentru fiecare componentă, permițând sistemului să crească pe măsură ce nevoile dvs. cresc, asigurând în același timp redundanță în caz de defecțiune. De asemenea, utilizează conceptul de Single Edge pentru a asigura acces extern sigur. Acesta este tipul pe care îl vom discuta în acest episod. Dacă vom înțelege cum să desfășurăm un cluster de acest tip, nu doar că vom înțelege celelalte tipuri de desfășurare, dar vom putea înțelege și cum să creăm clustere de servere CMS având în vedere creșterea potențială a nevoilor.

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

Componentele de bază ale software-ului CMS:

• Bază de date: permite combinarea anumitor configurații, cum ar fi grupul de abonați, spațiile utilizatorilor și utilizatorii în sine. Suportă clustering-ul doar pentru înaltă disponibilitate (un singur master).
• Call Bridge: un serviciu pentru conferințe audio și video, care oferă control total asupra gestionării și procesării apelurilor și proceselor multimedia. Suportă clusterizarea pentru disponibilitate ridicată și scalabilitate.
• server XMPP: se ocupă de înregistrarea și autentificarea clienților care folosesc aplicația Cisco Meeting Application și/sau WebRTC (comunicare în timp real, sau pur și simplu în browser), precum și semnalizarea între componente. Poate fi clusterizat doar pentru disponibilitate ridicată.
• Web Bridge: oferă acces clienților în WebRTC.
• Loadbalancer: asigură un punct unic de conectare pentru aplicațiile Cisco Meeting App în modul Single Split. Ascultă interfața externă și portul pentru conexiunile în intrare. În mod egal, balanța de încărcare acceptă conexiunile TLS în intrare de la serverul XMPP, prin care poate comuta conexiunile TCP de la clienții externi.
  În scenariul nostru nu va fi necesar.
• TURN server: asigură tehnologia de ocolire a Firewall-ului, permițând
  să expunem CMS-ul nostru în afara Firewall-ului sau NAT-ului pentru a conecta clienți externi care folosesc Cisco Meeting App sau dispozitive SIP. În scenariul nostru nu va fi necesar.
• Web Admin: interfața de administrare și accesul la API, inclusiv pentru conferințele speciale Unified CM.

Moduri de configurare

Spre deosebire de majoritatea celorlalte produse Cisco, Cisco Meeting Server suportă trei metode de configurare, permițând desfășurarea oricărui tip de implementare.

• Linia de comandă (CLI): Interfața de linie de comandă, cunoscută sub numele de MMP, pentru sarcini de configurare inițială și certificate.
• Web administrator: în principal pentru configurația legată de CallBridge, mai ales la configurarea unui singur server neclusterizat.
• REST API: utilizat pentru cele mai complexe sarcini de configurare și sarcini legate de baza de date clusterizată.

În plus față de cele menționate anterior, se utilizează protocolul SFTP pentru transferul de fișiere — de obicei licențe, certificate sau jurnale — pe și de la serverul CMS.

În ghidurile de desfășurare de la Cisco este clar scris că un cluster trebuie desfășurat din minimum trei servere (noduri) în contextul bazelor de date. Deoarece doar cu un număr impar de noduri va funcționa mecanismul de alegere a unui nou Master al bazei de date, iar Master-ul bazei de date are legătură cu cea mai mare parte a bazei de date a serverului CMS.

Și, cum arată practica, două servere (noduri) nu sunt de fapt suficient de multe. Mecanismul de selectare funcționează la repornirea Master-ului, iar serverul Slave devine Master exclusiv după repornirea serverului. Totuși, dacă în clusterul cu două servere serverul Master se "stinge", serverul Slave nu devine Master, iar dacă se "stinge" Slave, atunci serverul Master rămas devine Slave.

În contextul XMPP, cu adevărat ar trebui să formăm un cluster din trei servere, deoarece, de exemplu, dacă dezactivăm serviciul XMPP pe unul dintre servere în care XMPP este în statutul Leader, pe serverul rămas XMPP va rămâne în statutul Follower și conexiunile CallBridge către XMPP se vor pierde, deoarece CallBridge se conectează exclusiv la XMPP cu statut de Leader. Acest lucru este critic, deoarece niciun apel nu va trece.

De asemenea, în aceleași ghiduri de implementare se demonstrează un cluster cu un singur server XMPP.

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

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

Se presupune că toate cele trei servere sunt pornite.

Înregistrările DNS

Înainte de a începe configurarea serverelor, trebuie să creăm înregistrările DNS Un și SRV tipuri:

Rețineți că în înregistrările noastre DNS sunt prezente două domenii example.com și conf.example.com. Example.com este domeniul pe care toți abonații Cisco Unified Communication Manager pot să-l folosească pentru URI-urile lor, care probabil este prezent în infrastructura dumneavoastră sau există o mare probabilitate să fie. Sau domeniul example.com corespunde aceluiași domeniu pe care utilizatorii îl folosesc pentru adresele lor de email. Sau clientul Jabber de pe laptopul dumneavoastră poate avea URI user@example.com. Domeniul conf.example.com este domeniul care va fi configurat pentru utilizatorii Cisco Meeting Server. Domeniul Cisco Meeting Server va fi conf.example.com, astfel încât pentru același utilizator Jabber pentru a accesa Cisco Meeting Server va trebui utilizat URI user@conf.example.com.

Configurare de bază

Toate setările descrise mai jos sunt prezentate pe un singur server, dar trebuie efectuate pe fiecare server din cluster.

QoS

Deoarece CMS generează real-time Traficul sensibil la latență și pierderea pachetelor recomandă, în cele mai multe cazuri, configurarea calității serviciului (QoS). Pentru aceasta, CMS-ul suportă etichetarea pachetelor cu coduri de servicii diferențiate (DSCP), pe care le generează. Deși prioritizarea traficului pe baza DSCP depinde de modul în care traficul este gestionat de componentele rețelei din infrastructura dumneavoastră, în cazul nostru, vom configura CMS-ul nostru cu o distribuție tipică a priorităților DSCP bazată pe cele 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 etichetat cu AF41 (DSCP 0x22), tot traficul vocal a fost etichetat cu EF (DSCP 0x2E), iar alte tipuri de trafic cu latență redusă, cum ar fi SIP și XMPP, utilizează AF31 (DSCP 0x1A).

Verificăm:

NTP

Protocolul de timp al rețelei (NTP) este important nu doar pentru a asigura marcaje temporale exacte pentru apeluri și conferințe, ci și pentru verificarea certificatelor.

Adăugăm servere NTP în infrastructura dumneavoastră cu comanda de tip

ntp server add

În cazul nostru, există două astfel de servere, așadar vor fi două comenzi.
Verificăm:

Și setăm fusul orar pentru serverul nostru

DNS

Serverele DNS în CMS se adaugă cu comanda de tip:

dns add forwardzone

În cazul nostru, există două astfel de servere, așadar vor fi două comenzi.
Verificăm:

Configurarea interfeței de rețea

Configurăm interfața cu comanda de tip:

ipv4  add 
 /

Verificăm:

Numele serverului (Hostname)

Numele serverului se setează cu comanda de tip:

hostname

Și repornim.


Astfel, configurația de bază este completă.

Certificate

TeorieCisco Meeting Server necesită o comunicare criptată între diferitele componente, iar din acest motiv, certificatele X.509 sunt necesare pentru toate implementările CMS. Acestea ajută la asigurarea încrederii între servicii/servere și alte servere/servicii.

Pentru fiecare serviciu este necesar un certificat, însă crearea de certificate separate pentru fiecare serviciu poate duce la confuzie și complicații inutile. Din fericire, putem genera o pereche de chei publice și private pentru certificat și apoi le putem reutiliza pentru mai multe servicii. În cazul nostru, același certificat va fi folosit pentru Call Bridge, serverul XMPP, Web Bridge și Web Admin. Astfel, trebuie să creăm o pereche de chei publice și private pentru fiecare server din cluster.

Clusterizarea bazei de date are însă anumite cerințe speciale pentru certificate, necesitând certificate distincte de cele ale altor servicii. CMS utilizează un certificat de server, care este similar cu certificatele folosite de alte servere, dar există de asemenea un certificat de client folosit pentru conexiunile cu baza de date. Certificatele bazei de date sunt utilizate atât pentru autentificare, cât și pentru criptare. În loc să ofere un nume de utilizator și o parolă pentru a conecta clientul la baza de date, acesta prezintă un certificat de client de care serverul are încredere. Fiecare server din clusterul bazei de date va folosi aceeași pereche de chei publice și private. Acest lucru permite tuturor serverelor din cluster să cripteze datele astfel încât acestea să poată fi decriptate doar de celelalte servere care folosesc aceeași pereche de chei.

Pentru ca rezervarea să funcționeze, clusterele de baze de date trebuie să fie compuse dintr-un minim de 3 servere, dar nu mai mult de 5, cu un timp maxim de întârziere a semnalului în ambele direcții de 200 ms între orice membri ai clusterului. Această limită este mai restrictivă decât pentru clusterizarea Call Bridge, de aceea este adesea un factor limitativ în desfășurările distribuite geografic.

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

CMS utilizează baza de date postgres cu un singur principal și mai multe replici complet identice. În fiecare moment există doar o singură bază de date principală („server de baze de date”). Ceilalți membri ai clusterului sunt replici sau „clienți ai bazei de date.”

Pentru clusterul de baze de date sunt necesare un certificat de server dedicat și un certificat de client. Acestea trebuie să fie semnate de certificate, de obicei de un centru de certificare privat intern. Deoarece oricare dintre membrii clusterului de baze de date poate deveni principal, perechile de certificate pentru serverul de baze de date și client (care conțin cheile publice și private) trebuie copiate pe toate serverele, astfel încât acestea să poată valida identitatea clientului sau serverului de baze de date. În plus, certificatul rădăcină CA trebuie încărcat pentru a asigura verificarea certificatelor clientului și serverului.

Așadar, generăm o cerere pentru certificat, care va fi utilizată de toate serviciile serverului, cu excepția serviciului de baze de date (pentru care va exista o cerere separată) cu comanda de tip:

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

În CN scriem un nume generalizat pentru serverele noastre. De exemplu, dacă hostname-urile serverelor noastre server01, server02, server03, atunci CN va fi server.example.com

Facem la fel pe celelalte două servere, cu mențiunea că comenzile vor avea „hostname-urile” corespunzătoare.

Generăm două cereri pentru certificatele care vor fi utilizate de serviciul de baze de date cu comenzile de tip:

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

pki csr dbclusterclient CN:postgres

unde dbclusterserver și dbclusterclient numele cererilor și viitoarelor certificate, hostname1(2)(3) numele serverelor corespunzătoare.

Această procedură o efectuăm doar pe un singur server(!), iar certificatele și fișierele .key corespunzătoare le vom încărca pe celelalte servere.

Activarea modului certificat de client în AD CS

De asemenea, trebuie să combinăm într-un singur fișier certificatele pentru fiecare serverÎn *NIX:

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

În Windows/DOS:

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

Și trebuie să încărcăm pe fiecare server:
1. Certificatul „individual” al serverului.
2. Certificatul rădăcină (împreună cu cele intermediare, dacă există).
3. Certificatele pentru baza de date („server” și „client”) și fișierele cu extensia .key, care s-au creat la generarea cererii pentru certificatul „server” și „client” al bazei de date. Aceste fișiere trebuie să fie identice pe toate serverele.
4. Fișierul tuturor celor trei certificate „individuale”.

În rezultat, ar trebui să avem o structură similară de fișiere pe fiecare server.

Cluster de Baze de Date

Acum, când aveți toate certificatele încărcate pe serverele CMS, puteți configura și activa clusterizarea bazei de date între cele trei noduri. Primul pas este alegerea unui server ca nod principal al clusterului de baze de date și configurarea completă a acestuia.

Baza de date principală

Primul pas în configurarea replicării bazei de date este indicarea certificatelor care vor fi utilizate pentru baza de date. Acest lucru se face printr-o comandă de forma:

database cluster certs

Acum vom indica CMS-ului ce interfață să folosească pentru clusterizarea bazelor de date prin comanda:

database cluster localnode a

Apoi, inițializăm baza de date a clusterului pe serverul principal cu comanda:

database cluster initialize

Nodurile bazei de date client

Facem aceeași procedură, doar că în loc de comanda database cluster initialize introducem comanda de forma:

database cluster join

unde ip address existing master este adresa IP a serverului CMS pe care s-a realizat inițializarea clusterului, adică Master.

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

database cluster status

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

În rezultatul final, primul nostru server este Master, iar celelalte sunt Slave.

Serviciul de administrare web

Activăm serviciul de administrare web:

webadmin listen a 445

Portul 445 a fost ales deoarece portul 443 este utilizat pentru accesul utilizatorilor în web-client.

Configurăm serviciul Web Admin cu fișierele certificat prin comanda de forma:

webadmin certs

Și activăm Web Admin cu comanda:

webadmin enable

Dacă totul este în regulă, vom obține linii SUCCESS, în care se indică că Web Admin este configurat corect pentru rețea și certificat. Verificăm funcționalitatea serviciului cu un browser web și introducem adresa web a administratorului, de exemplu: cms.example.com:445

Clusterul Call Bridge

Call Bridge este singurul serviciu prezent în fiecare desfășurare CMS. Call Bridge este mecanismul principal de conferință. De asemenea, oferă interfață SIP, astfel încât apelurile pot fi trase către el sau din el, de exemplu prin Cisco Unified CM.

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

Leagă certificatele de serviciul Call Bridge cu comanda de forma:

callbridge certs  []

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

callbridge listen a

Și restartăm serviciul cu comanda:

callbridge restart

Acum că avem configurate Call Bridge-urile, putem configura clusterizarea Call Bridge. Clusterizarea Call Bridge diferă de clusterizarea bazei de date sau XMPP. Clusterul Call Bridge poate susține între 2 și 8 noduri fără nicio limitare. Acesta oferă nu doar redundanță, ci și distribuitia sarcinii, permițând conferințelor să fie distribuite activ între serverele Call Bridge printr-o distribuție inteligentă a apelurilor. CMS dispune de funcții suplimentare, grupuri Call Bridge și funcții asociate care pot fi utilizate pentru gestionarea suplimentară.

Clusterizarea Call Bridge se configurează în principal prin intermediul interfeței web de administrare
Procedura de mai jos trebuie efectuată pe fiecare server din cluster.
Deci,

1. Accesăm prin web în Configuration > Cluster.
2. La Identitatea Call Bridge introducem numele unic callbridge[01,02,03] corespunzător numelui serverului. Aceste nume sunt arbitrare, dar trebuie să fie unice pentru acest cluster. Ele au un caracter descriptiv, deoarece indică faptul că sunt identificatorii serverelor [01,02,03].
3. La Call Bridges clusterizate introducem adresele URL ale web-ului de administrare a serverelor noastre din cluster, cms[01,02,03].example.com:445, în câmpul Address. Asigurați-vă că specificați portul. Puteți lăsa câmpul Peer link SIP domain gol.
4. Adăugați la încrederea CallBridge-ului fiecarei server certificat, fișierul acestuia conținând toate certificatele serverelor noastre, care au fost unite în acest fișier la început, cu comanda de tipul:

callbridge trust cluster

Și restartăm serviciul cu comanda:

callbridge restart

În final, pe fiecare server ar trebui să fie așa:

Cluster XMPP

Serviciul XMPP în CMS este utilizat pentru a gestiona toată înregistrarea și autentificarea pentru Cisco Meeting Apps (CMA), inclusiv clientul web CMA WebRTC. Call Bridge acționează, de asemenea, ca un client XMPP în scopuri de autentificare și, prin urmare, trebuie să fie configurat ca ceilalți clienți. Redundanța XMPP este o caracteristică care este susținută în medii 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 comanda de tipul:

xmpp certs  []

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

xmpp listen a

Pentru serviciul XMPP este nevoie de un domeniu unic. Acesta este loginul pentru utilizatori. Cu alte cuvinte, atunci când un utilizator încearcă să se conecteze prin aplicația CMA (sau prin clientul WebRTC), el introduce userID@logindomain. În cazul nostru, acesta va fi userid@conf.example.com. De ce nu doar example.com? În implementarea noastră specifică, am ales domeniul nostru Unified CM, pe care utilizatorii Jabber îl vor utiliza în Unified CM, ca example.com, așa că avem nevoie de un alt domeniu pentru utilizatorii CMS, pentru a rutea apelurile în CMS și din CMS prin domeniile SIP.

Configurați domeniul XMPP folosind o comandă de tipul:

xmpp domain

Și activăm serviciul XMPP cu comanda:

xmpp enable

În serviciul XMPP, este nevoie să creați acreditive pentru fiecare Call Bridge, care vor fi utilizate la înregistrarea în serviciul XMPP. Aceste nume sunt arbitrare (și nu sunt legate de numele unice pe care le-ați configurat pentru clusteringul podului de apeluri). Pe un singur server XMPP trebuie să adăugați trei poduri de apeluri, apoi să introduceți aceste acreditive pe celelalte servere XMPP din cluster, deoarece această configurație nu este stocată în baza de date a cluster-ului. Ulterior, vom configura fiecare Call Bridge să folosească acest nume și secret pentru a se înregistra în serviciul XMPP.

Acum trebuie să configurăm serviciul XMPP pe primul server cu cele trei Call Bridge-uri callbridge01, callbridge02 și callbridge03. Fiecărei cont îi vor fi alocate parole aleatorii. Acestea vor fi introduse mai târziu pe celelalte servere Call Bridge pentru a se conecta la acest server XMPP. Introducem următoarele comenzi:

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

În cele din urmă, verificăm ce am obținut cu comanda:

xmpp callbridge list

Exact aceeași situație ar trebui să fie și pe celelalte servere după acțiunile descrise mai jos.

Apoi, adăugăm pe celelalte două servere aceleași setări, doar cu comenzile

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

Secretul se adaugă cu multă atenție, pentru a nu avem de exemplu spații în plus.


În cele din urmă, pe fiecare server ar trebui să avem aceleași date:

Apoi, pe toate serverele din cluster, specificăm în fișierul de încredere conținând cele trei certificate, creat anterior cu comanda de tip:

xmpp cluster trust

Activăm modul xmpp cluster pe toate serverele din cluster cu comanda:

xmpp cluster enable

Pe primul server al clusterului, inițiem crearea clusterului xmpp cu comanda:

xmpp cluster initialize

Pe celelalte servere, adăugăm în clusterul xmpp cu comanda de tip:

xmpp cluster join

Verificăm pe fiecare server succesul creării clusterului XMPP 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 este pornit, trebuie să configurăm serviciile Call Bridge pentru a se conecta la clusterul XMPP. Această configurare se face prin intermediul administratorului web.

Accesăm pe fiecare server în Configuration > General și în câmpul Unique Call Bridge name introducem numele unice ale Call Bridge corespunzătoare fiecărui server callbridge[01,02,03]. În câmpul Domeniu conf.example.ru și parolele corespunzătoare, le putem verifica
pe orice server din cluster cu comanda:

xmpp callbridge list

Câmpul „Server” îl lăsăm gol, Callbridge va efectua o căutare DNS SRV pentru _xmpp-component._tcp.conf.example.com, pentru a găsi un server XMPP disponibil. Adresele IP de conectare ale callbridge-urilor la XMPP pot diferi pe fiecare server, în funcție de valorile returnate la interogarea în legătură cu înregistrarea _xmpp-component._tcp.conf.example.com callbridge-ului, ceea ce la rândul său depinde de setările priorităților pentru aceasta înregistrare DNS.

Apoi, trecem la Status > General, pentru a ne asigura că serviciul Call Bridge este conectat cu succes la serviciul XMPP.

Web Bridge

Pe fiecare server din cluster activăm serviciul Web Bridge cu comanda:

webbridge listen a:443

Configurăm serviciul Web Bridge cu fișierele de certificate folosind comanda de tip:

webbridge certs

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

webbridge http-redirect enable

Pentru a-i permite Call Bridge-ului să aibă încredere în conexiunile venite de la Call Bridge, folosiți comanda:

webbridge trust

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

Această configurație ar trebui să existe pe fiecare server din cluster.


Acum trebuie să creăm un utilizator cu rolul „appadmin”, care este necesar pentru a putea configura clusterul nostru (!), nu fiecare server din cluster separat, astfel încât setările să se aplice în mod identic pe fiecare server la finalizarea configurării lor o singură dată.


Pentru configurarea ulterioară vom folosi Postman.

Pentru autentificare alegem Basic în secțiunea Autorization

Pentru a trimite corect comenzi către serverele CMS, trebuie să setați codificarea corespunzătoare

Specificați Webbridge-urile cu comanda POST cu parametrul url și valoarea cms.example.com



În Webbridge, specificați parametrii necesari: acces gazdă, acces securizat și altele.

Call Bridge Groups

În mod implicit, CMS nu utilizează întotdeauna resursele de conferință disponibile la capacitate maximă.

De exemplu, pentru o întâlnire cu trei participanți, fiecare participant poate fi pe trei Call Bridge-uri diferite. Pentru ca acești trei participanți să comunice între ei, Call Bridge-urile vor stabili automat conexiuni între toate serverele și clienții din aceeași Space, astfel încât să pară că toți clienții sunt pe același server. Din păcate, un dezavantaj al acestui aranjament este că o conferință de 3 persoane va consuma acum 9 porți media. Aceasta este, evident, o utilizare ineficientă a resurselor. În plus, atunci când Call Bridge este într-adevăr suprasolicitat, mecanismul implicit este de a continua să accepte apeluri și să ofere servicii cu o calitate redusă tuturor abonaților acestui Call Bridge.

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

Pentru a rezolva problema reconectării, au fost introduse trei limite de încărcare configurabile pentru fiecare Call Bridge:

LoadLimit — este limita maximă numerică pentru un anumit Call Bridge. Fiecare platformă are o valoare recomandată de limită a încărcării, de exemplu 96000 pentru CMS1000 și 1,25 GHz pe procesor virtual pentru mașina virtuală. Diferitele apeluri consumă un anumit număr de resurse în funcție de rezoluție și frecvența de cadre a participantului.
NewConferenceLoadLimitBasisPoints (în mod implicit 50% din loadLimit) — stabilește limita de încărcare a serverului, după care noile conferințe sunt respinse.
ExistingConferenceLoadLimitBasisPoints (în mod 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ă funcție a fost dezvoltată pentru a distribui apelurile și a repartiza sarcina, alte grupuri, cum ar fi serverele TURN, serverele Web Bridge și dispozitivele de înregistrare, pot fi, de asemenea, alocate grupurilor Call Bridge, astfel încât acestea să poată fi grupate corect pentru utilizare optimă. Dacă vreunul dintre aceste obiecte nu este alocat unui grup de apeluri, se presupune că sunt disponibile tuturor serverelor fără vreo prioritate specifică.

Aceste opțiuni pot fi configurate aici: cms.example.com:445/api/v1/system/configuration/cluster

Apoi specificăm fiecărui callbridge la ce grup de callbridge aparține:

Primul callbridge

Al doilea callbridge

Al treilea callbridge


Astfel, am configurat grupul Call Bridge 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 aceasta nu oferă opțiuni avansate de configurare, iar informațiile nu sunt salvate în baza de date a clusterului, deci va trebui să facem configurația fie manual pe fiecare server prin interfața web, fie prin API, și pentru a nu ne ridica de trei ori, vom specifica datele prin API.

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

• Adresa IP a serverului
• numărul portului
• numele utilizatorului
• parola
• sigur

Sigur – true sau false alegem în funcție de port, 389 – nesigur, 636 – sigur.


Mapăm parametrii LDAP sursă la atribute în Cisco Meeting Server.
Maparea LDAP asociază atributele din directorul LDAP cu atributele din CMS. Atributele propriu-zise sunt:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Descrierea atributelorJID reprezintă identificatorul de autentificare al utilizatorului în CMS. Deoarece este un server LDAP Microsoft Active Directory, JID CMS este asociat cu sAMAccountName din LDAP, care este, în esență, identificatorul de autentificare al utilizatorului în Active Directory. De asemenea, rețineți că preluați sAMAccountName și adăugați domeniul conf.pod6.cms.lab la sfârșitul său, deoarece acesta este loginul pe care utilizatorii dumneavoastră îl vor folosi pentru a se autentifica în CMS.

nameMapping asociază ceea ce se conține în câmpul Active Directory displayName cu câmpul numelui utilizatorului în CMS.

coSpaceNameMapping creează numele space-ului CMS pe baza câmpului displayName. Acest atribut, împreună cu atributul coSpaceUriMapping, sunt cele necesare pentru a crea un space pentru fiecare utilizator.

coSpaceUriMapping definează partea utilizatorului a URI-ului legată de spațiul personal al utilizatorului. Unele domenii pot fi configurate pentru a fi setate în spațiu. Dacă partea utilizatorului corespunde cu acest câmp pentru unul dintre aceste domenii, apelul va fi redirecționat către spațiul acestui utilizator.

coSpaceSecondaryUriMapping definează un al doilea URI pentru a atinge spațiul. Acesta poate fi folosit pentru a adăuga un pseudonim numeric pentru rutarea apelurilor către spațiul utilizatorului importat, ca alternativă la URI-ul alfanumeric definit în parametrul coSpaceUriMapping.

Serverul LDAP și maparea LDAP sunt configurate. Acum este necesar să le legăm împreună, creând o sursă LDAP.

Folosind URL-ul pentru acces cms01.example.com:445/api/v1/ldapSource creăm obiectul LDAP Source, specificând parametrii cum ar fi:

• server
• mapping
• baseDn
• filter

Acum, când configurarea LDAP este finalizată, putem efectua operația de sincronizare manuală.

Facem acest lucru fie în interfața web a fiecărui server apăsând Sincronizați acum în secțiunea Active Directory


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

Conferințele Ad-Hoc

Ce este asta?În sensul tradițional, o conferință este atunci când doi participanți vorbesc între ei, iar unul dintre participanți (folosind un dispozitiv înregistrat în Unified CM) apasă butonul „Conferință”, apelează o altă persoană și, după ce vorbește cu acest al treilea, apasă din nou butonul „Conferință” pentru a se alătura tuturor participanților la conferința în trei.

Conferința Ad-Hoc se deosebește de conferința planificată în CMS prin faptul că conferința Ad-Hoc nu este doar un apel SIP pentru CMS. Când inițiatorul conferinței apasă din nou 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 conferința „în timp real”, la care sunt transferate toate apelurile. Totul se întâmplă transparent pentru participanți.

Aceasta înseamnă că Unified CM trebuie să configureze acreditivele API și adresa/portul WebAdmin al serviciului, precum și SIP-Trunk direct pe serverul CMS pentru a continua apelul.

Dacă este necesar, CUCM poate crea dinamic spații în CMS, astfel încât fiecare apel să poată ajunge la CMS și să se conformeze regulii apelurilor în intrare, care este destinată spațiilor.

Integrarea cu CUCM este configurată la fel cum este descris în articol anterior cu excepția faptului că pe Cisco UCM trebuie să creați trei trunk-uri pentru CMS, trei Conference Bridge-uri, în SIP Security Profile să specificați trei Subject Name-uri, Route Group, Route List, Media Resource Group și Media Resource Group List, iar în Cisco Meeting Server să adăugați câteva reguli de rutare.

SIP Security Profile:


Trunk-uri:


Fiecare trunk arată la fel:




Conference Bridge


Fiecare Conference Bridge arată la fel:


Route Group


Route List


Media Resource Group


Media Resource Group List

Reguli de apel

Spre deosebire de sistemele mai elaborate de gestionare a apelurilor, cum ar fi Unified CM sau Expressway, pentru apelurile noi CMS verifică domeniul doar în câmpul SIP Request-URI. Așadar, dacă SIP INVITE este destinat la sip: user@domain.com, CMS se ocupă doar de domain.com. CMS urmează aceste reguli pentru a determina unde să direcționeze apelul:

1. Mai întâi, CMS încearcă să potrivească domeniul SIP cu domeniile configurate în regulile de procesare a apelurilor intrante. Aceste apeluri pot fi apoi direcționate către spații ("țintă") sau utilizatori specifici, IVR interne sau direct către destinatari integrați Microsoft Lync/Skype for Business (S4B).
2. Dacă nu există potriviri în regulile de procesare a apelurilor intrante, CMS va încerca să potrivească domeniul configurat în tabela de redirecționare a apelurilor. Dacă se stabilește o potrivire, regula poate respinge explicit apelul sau redirecționa apelul. În acest moment, CMS poate rescrie domeniul, ceea ce este uneori util pentru apelurile către domeniile Lync. De asemenea, puteți alege pass throw, ceea ce înseamnă că niciunul dintre câmpuri nu va fi modificat suplimentar, sau folosi grupul de abonați intern CMS. Dacă nu există potriviri în regulile de redirecționare a apelurilor, prin default se folosește respingerea apelului. Rețineți că în CMS, deși apelul este "redirecționat", multimedia este încă legată de CMS, ceea ce înseamnă că va rămâne în calea semnalizării și a traficului multimedia.
Atunci, doar apelurile redirecționate sunt supuse regulilor de apeluri externe. Aceste opțiuni definesc destinatarii către care se va trimite apelurile, tipul de linie de conexiune (fie că este un apel nou Lync sau SIP standard) și orice transformări care pot fi efectuate, dacă în regula de redirecționare a apelurilor nu se alege transmiterea.

Iată de fapt logul a ceea ce se întâmplă în timpul conferinței Ad-Hoc

În captură se vede prost (nu știu cum să fac mai bine), așa că voi scrie logul astfel:

Info	127.0.0.1:35870: Utilizator API "api" a creat un nou spațiu 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	apelul de creare a eșuat în a găsi coSpace -- încercând să îl recupereze din baza de date

Info	API "001036270012" GUID Spațiu: 7986bb6c-af4e-488d-9190-a75f16844e44  GUID apel: 93bfb890-646c-4364-8795-9587bfdc55ba  GUID Correlator apel: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  G Intern

Info	127.0.0.1:35872: Utilizator API "api" a creat un nou apel 93bfb890-646c-4364-8795-9587bfdc55ba

Info	apel 7: apel SIP în curs de primire de la "sip:672@172.x.x.x" la URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	conferința 434f88d0-8441-41e1-b6ee-6d1c63b5b098 are control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conferința 434f88d0-8441-41e1-b6ee-6d1c63b5b098 numită "001036270012"

Info	apel 7: configurat - legătura apel API bc0be45e-ce8f-411c-be04-594e0220c38e cu ID-ul apelului SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	apel 7: configurarea sesiunii RTP UDT pentru DTLS (media și control combinate)
Info	conferința "001036270012": legăturile de apel necriptate sunt acum prezente

Info	participantul "672@172.x.x.x" a intrat în spațiul 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participantul "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) a intrat în conferința 434f88d0-8441-41e1-b6ee-6d1c63b5b098 prin SIP

Info	apel 8: apel SIP în curs de primire de la "sip:690@172.x.x.x" la URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	apel 8: configurat - legătura apel API db61b242-1c6f-49bd-8339-091f62f5777a cu ID-ul apelului SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	apel 8: configurarea sesiunii RTP UDT pentru DTLS (media și control combinate)

Info	apel 9: apel SIP în curs de primire de la "sip:673@172.x.x.x" la URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	apel 9: configurat - legătura apel API 37a6e86d-d457-47cf-be24-1dbe20ccf98a cu ID-ul apelului SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	apel 9: configurarea sesiunii RTP UDT pentru DTLS (media și control combinate)
Info	apel 8: compensare pentru tipurile de încărcătură care nu se potrivesc la capătul îndepărtat

Info	participantul "690@172.x.x.x" a intrat în spațiul 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participantul "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) a intrat în conferința 434f88d0-8441-41e1-b6ee-6d1c63b5b098 prin SIP

Info	apel 7: compensare pentru tipurile de încărcătură care nu se potrivesc la capătul îndepărtat
Info	apel 8: mod de tipuri de încărcătură care nu se potrivesc 1/0
Info	apel 8: răspuns la ofertă în modul de tipuri de încărcătură care nu se potrivesc
Info	apel 8: ofertă unică de codec de urmărire primită
Info	apel 8: mod de tipuri de încărcătură care nu se potrivesc 1/0
Info	apel 8: răspuns la ofertă în modul de tipuri de încărcătură care nu se potrivesc
Info	apel 8: trimiterea răspunsului la oferta suplimentară cu codec unic
Info	apel 9: compensare pentru tipurile de încărcătură care nu se potrivesc la capătul îndepărtat

Info	participantul "673@172.x.x.x" a intrat în spațiul 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participantul "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) a intrat în conferința 434f88d0-8441-41e1-b6ee-6d1c63b5b098 prin SIP

Info	apel 9: BFCP (rol client) acum activ
Info	apel 9: trimiterea salutului BFCP ca client după primirea salutului când BFCP nu este activ
Info	apel 9: BFCP (rol client) acum activ
Info	apel 7: finalizare; terminare SIP de la distanță - conectat timp de 0:13
Info	apel 7: distrugerea legăturii apel API bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participantul "672@x.x.x" a părăsit spațiul 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	apel 9: în așteptare
Info	apel 9: mod de tipuri de încărcătură care nu se potrivesc 1/0
Info	apel 9: răspuns la ofertă în modul de tipuri de încărcătură care nu se potrivesc
Info	apel 8: în așteptare
Info	apel 8: ofertă unică de codec de urmărire primită
Info	apel 8: mod de tipuri de încărcătură care nu se potrivesc 1/0
Info	apel 8: răspuns la ofertă în modul de tipuri de încărcătură care nu se potrivesc
Info	apel 8: trimiterea răspunsului la oferta suplimentară cu codec unic
Info	apel 9: finalizare; terminare SIP de la distanță - conectat timp de 0:12

Conferința Ad-Hoc în sine:


Regulile apelurilor primite
Configurarea parametrilor pentru apelurile primite este necesară pentru a permite primirea apelului în CMS. Așa cum ați observat în configurația LDAP, toți utilizatorii au fost importați cu domeniul conf.pod6.cms.lab. Așadar, cel puțin, doriți ca apelurile în acest domeniu să fie destinate spațiilor. Va trebui, de asemenea, să stabiliți reguli pentru tot ceea ce este destinat numelui complet de domeniu (și, poate, chiar și pentru adresa IP) a fiecărui server CMS. În controlul nostru extern al apelurilor, Unified CM, vor fi configurate magistrale SIP, destinate fiecărui server CMS în parte. În funcție de faptul că destinația acestor magistrale SIP este o adresă IP sau numele complet al serverului, va determina dacă CMS trebuie configurat pentru a accepta apeluri care sunt direcționate către adresa sa IP sau numele său complet de domeniu.

Domeniul care are regula de trafic intrant cu cea mai mare prioritate este folosit ca domeniu pentru orice spațiu personalizat. Atunci când utilizatorii se sincronizează prin LDAP, CMS creează automat spații, dar numai partea utilizatorului a URI-ului (coSpaceUriMapping), de exemplu, user.space. Partea domain completă a URI-ului este generată pe baza acestei reguli. De fapt, dacă ați intrat în Web Bridge în acest moment, ați observa că URI-ul Space nu are domeniu. Stabilind această regulă ca prioritate maximă, setați domeniul pentru spațiile generate ca conf.example.com.


Regulile apelurilor ieșite

Pentru a permite utilizatorilor să efectueze apeluri ieșite în clusterul Unified CM, este necesară configurarea regulilor de conexiuni ieșite. Domeniul terminalelor înregistrate în Unified CM, cum ar fi Jabber, este example.com. Apelurile în acest domeniu ar trebui direcționate ca apeluri SIP standard către nodurile de procesare a apelurilor Unified CM. Serverul primar este cucm-01.example.com, iar ca suplimentar cucm-02.example.com.

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

Câmp Local din domeniu responsabil pentru ceea ce va fi afișat în SIP-URI-ul apelantului de către cel care primește apelul după simbolul „@”. Dacă îl lăsăm gol, atunci după simbolul „@” va fi adresa IP a CUCM-ului prin care trece acest apel. Dacă specificăm un domeniu, atunci după simbolul „@” va fi efectiv domeniul. Acest lucru este necesar pentru a putea suna înapoi, altfel nu va fi posibil să revenim la SIP-URI nume@adresa-IP.

Apel când este specificat Local din domeniu


Apel când NU este specificat Local din domeniu


Este obligatoriu să specificați clar Encrypted sau Unencrypted, astfel vor fi apeluri ieșite, așadar cu parametrul Auto, nimic nu funcționează.

Înregistrare

Înregistrarea conferințelor video se face de către serverul Record. Recorderul este exact același Cisco Meeting Server. Recorderul nu necesită instalarea unor licențe. Licențele pentru înregistrare sunt necesare serverelor pe care sunt rulate serviciile CallBridge, adică licența Recording este necesară și trebuie aplicată componentului CallBridge, nu serverului pe care este rulat Recorderul. Recorderul se comportă ca un client al protocolului extensibil de schimb de mesaje și prezență (XMPP), astfel încât serverul XMPP trebuie să fie activat pe serverul pe care este găzduit CallBridge.

Având în vedere că avem un cluster și licența trebuie „întinsă” pe toate cele trei servere ale clusterului. Așadar, în contul personal, în licențe, asociem (adăugăm) adresele MAC ale interfețelor a-serverelor tuturor serverelor CMS care fac parte din cluster.

Și așa ar trebui să arate pe fiecare server din cluster

De fapt, există mai multe scenarii de amplasare a Recorder-ului, dar ne vom ține de următorul:


Înainte de a configura Recorderul, este necesar să pregătim un loc unde vor fi înregistrate conferințele video. Iată-l linkul, cum să configurăm întregul Recording. Voi sublinia aspectele și detaliile importante:

1. Este mai bine să folosiți certificatul de la primul server din cluster.
2. Eroarea „Recorder unavailable” poate apărea deoarece a fost specificat un certificat greșit în Recorder Trust.
3. Înregistrarea poate să nu se desfășoare dacă pentru înregistrare nu este specificat un director rădăcină în NFS.

Uneori apare necesitatea de a înregistra automat conferința unui utilizator sau spațiu specific.

Pentru aceasta se creează două CallProfile-uri:
Cu funcția de înregistrare dezactivată


Și cu funcția de înregistrare automată activată


Apoi, la spațiul dorit, „atașăm” CallProfile-ul cu funcția de înregistrare automată.


În CMS, este stabilit că, dacă un CallProfile este legat în mod explicit de anumite spații sau de un spațiu, atunci acest CallProfile funcționează doar pentru aceste spații specifice. Dacă CallProfile nu este legat de niciun spațiu, atunci, în mod implicit, se aplică spațiilor la care nu este legat niciun CallProfile.

Data viitoare voi încerca să descriu prin ce modalități se poate accesa CMS din 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: habr.com