Servidor de reunions de Cisco 2.5.2. Clúster en mode escalable i resilient amb gravació de videoconferència

En aquest número mostraré i explicaré algunes de les complexitats de la configuració d'un servidor CMS en mode de clúster de migració per error.


ТеорияEn general, hi ha tres tipus de desplegament de servidors CMS:

• Individual combinat(Combinat únic), és a dir. aquest és un servidor on s'executen tots els serveis necessaris. En la majoria dels casos, aquest tipus de desplegament només és adequat per a l'accés de client intern i en entorns més petits on les limitacions d'escalabilitat i redundància d'un sol servidor no són un problema crític, o en situacions en què el CMS només realitza determinades funcions, com ara ad hoc. conferències sobre Cisco UCM.

  Esquema de treball aproximat:
  

• Split únic(Single Split) amplia el tipus de desplegament anterior afegint un servidor independent per a l'accés extern. En els desplegaments heretats, això significava desplegar un servidor CMS en un segment de xarxa desmilitaritzat (DMZ) on els clients externs hi podien accedir i un servidor CMS al nucli de la xarxa on els clients interns podien accedir al CMS. Aquest model de desplegament en particular està sent substituït per l'anomenat tipus Única vora, que consta de servidors Autopista Cisco, que tenen o tindran moltes de les mateixes capacitats de derivació del tallafoc, de manera que els clients no necessiten afegir un servidor CMS de punta dedicat.

  Esquema de treball aproximat:
  

• Escalable i resistent(Escalable i tolerant a errors) Aquest tipus inclou redundància per a cada component, permetent que el sistema creixi amb les vostres necessitats fins a la seva màxima capacitat alhora que proporciona redundància en cas de fallada. També utilitza el concepte Single Edge per proporcionar accés extern segur. Aquest és el tipus que veurem en aquest episodi. Si entenem com desplegar aquest tipus de clúster, no només entendrem altres tipus de desplegaments, sinó que també podrem entendre com crear clústers de servidors CMS per donar cabuda al creixement potencial de la demanda.

Abans de passar al desplegament, heu d'entendre algunes coses bàsiques, és a dir

Components principals del programari CMS:

• Base de dades: us permet combinar algunes configuracions, com ara el pla de marcatge, els espais d'usuari i els mateixos usuaris. Admet agrupació en clúster només per a alta disponibilitat (mestre únic).
• Call Bridge: un servei d'àudio i videoconferència que ofereix un control total sobre la gestió i processament de trucades i processos multimèdia. Admet la agrupació en clúster per a una alta disponibilitat i escalabilitat.
• Servidor XMPP: responsable del registre i l'autenticació dels clients mitjançant l'aplicació Cisco Meeting i/o WebRTC (comunicació en temps real, o simplement al navegador), així com la senyalització intercomponent. Només es pot agrupar per alta disponibilitat.
• Web Bridge: Proporciona accés al client a WebRTC.
• Equilibrador de càrrega: Proporciona un únic punt de connexió per a les aplicacions de reunió de Cisco en mode de divisió única. Escolta la interfície externa i el port per a connexions entrants. De la mateixa manera, l'equilibrador de càrrega accepta connexions TLS entrants del servidor XMPP, a través del qual pot canviar connexions TCP des de clients externs.
  En el nostre escenari no serà necessari.
• Servidor TURN: Proporciona tecnologia de derivació del tallafoc que permet
  col·loqueu el nostre CMS darrere d'un tallafoc o NAT per connectar clients externs mitjançant l'aplicació Cisco Meeting o dispositius SIP. En el nostre escenari no serà necessari.
• Administrador web: Interfície administrativa i accés a API, inclòs per a conferències especials de Unified CM.

Modes de configuració

A diferència de la majoria de productes de Cisco, Cisco Meeting Server admet tres mètodes de configuració per adaptar-se a qualsevol tipus de desplegament.

• Línia d'ordres (CLI): Interfície de línia d'ordres coneguda com MMP per a tasques de configuració inicial i certificat.
• Administrador web: principalment per a configuracions relacionades amb CallBridge, especialment quan es configura un únic servidor sense clúster.
• REST API: S'utilitza per a les tasques de configuració més complexes i les tasques relacionades amb bases de dades agrupades.

A més de l'anterior, s'utilitza el protocol SFTP per transferir fitxers (normalment llicències, certificats o registres) cap i des del servidor CMS.

A les guies de desplegament de Cisco hi ha escrit en blanc i anglès que cal desplegar el clúster almenys tres servidors (nodes) en el context de bases de dades. Perquè Només amb un nombre senar de nodes funcionarà el mecanisme per seleccionar un nou Mestre de base de dades i, en general, el Mestre de base de dades té una connexió amb la majoria de la base de dades del servidor CMS.

I com mostra la pràctica, dos servidors (nodes) realment no són suficients. El mecanisme de selecció funciona quan es reinicia el mestre, el servidor esclau es converteix en mestre només després que s'hagi activat el servidor reiniciat. Tanmateix, si en un clúster de dos servidors el servidor Mestre s'apaga sobtadament, el servidor Esclau no es convertirà en Mestre, i si l'Esclau s'apaga, el servidor Mestre restant es convertirà en Esclau.

Però en el context de XMPP, realment seria necessari muntar un clúster de tres servidors, perquè si, per exemple, desactiveu el servei XMPP en un dels servidors en què XMMP es troba a l'estat de líder, al servidor restant, XMPP es mantindrà en l'estat de seguidor i les connexions de CallBridge a XMPP cauran, perquè CallBridge es connecta exclusivament a XMPP amb l'estat de líder. I això és fonamental, perquè... no passarà cap trucada.

També en les mateixes guies de desplegament es demostra un clúster amb un servidor XMPP.

I tenint en compte l'anterior, queda clar per què: funciona perquè està en mode de failover.

En el nostre cas, el servidor XMPP estarà present als tres nodes.

Se suposa que els tres servidors estan activats.

Registres DNS

Abans de començar a configurar servidors, heu de crear registres DNS А и SRV tipus:

Tingueu en compte que als nostres registres DNS hi ha dos dominis example.com i conf.exemple.com. Example.com és un domini que tots els subscriptors de Cisco Unified Communication Manager poden utilitzar per als seus URI, que és molt probable que estiguin presents a la vostra infraestructura o que siguin presents. O example.com coincideix amb el mateix domini que els usuaris utilitzen per a les seves adreces de correu electrònic. O el client Jabber del vostre ordinador portàtil pot tenir un URI [protegit per correu electrònic]. Domini conf.example.com és el domini que es configurarà per als usuaris de Cisco Meeting Server. El domini del Cisco Meeting Server serà conf.example.com, per tant, per al mateix usuari de Jabber, s'hauria d'utilitzar l'URI user@ per iniciar sessió al Cisco Meeting Serverconf.exemple.com.

Configuració bàsica

Tots els paràmetres que es descriuen a continuació es mostren en un servidor, però s'han de fer a cada servidor del clúster.

QoS

Ja que el CMS genera en temps real trànsit sensible a retards i pèrdues de paquets, en la majoria dels casos es recomana configurar la qualitat de servei (QoS). Per aconseguir-ho, el CMS admet l'etiquetatge de paquets amb els codis de serveis diferenciats (DSCP) que genera. Tot i que la priorització del trànsit basada en DSCP depèn de com processen el trànsit els components de xarxa de la vostra infraestructura, en el nostre cas configurarem el nostre CMS amb la priorització DSCP típica basada en les millors pràctiques de QoS.

A cada servidor introduirem aquestes ordres

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

Així, tot el trànsit de vídeo estava marcat AF41 (DSCP 0x22), tot el trànsit de veu estava marcat EF (DSCP 0x2E), altres tipus de trànsit de baixa latència com SIP i XMPP utilitzen AF31 (DSCP 0x1A).

Comprovem:

NTP

El protocol de temps de xarxa (NTP) és important no només per proporcionar segells de temps precisos de trucades i conferències, sinó també per verificar els certificats.

Afegiu servidors NTP a la vostra infraestructura amb una comanda com ara

ntp server add <server>

En el nostre cas, hi ha dos servidors d'aquest tipus, de manera que hi haurà dos equips.
Comprovem:

I establiu la zona horària del nostre servidor

DNS

Afegim servidors DNS al CMS amb una ordre com:

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

En el nostre cas, hi ha dos servidors d'aquest tipus, de manera que hi haurà dos equips.
Comprovem:

Configuració de la interfície de xarxa

Configurem la interfície amb una comanda com:

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

Comprovem:

Nom del servidor (nom d'amfitrió)

Establem el nom del servidor amb una ordre com:

hostname <name>

I reiniciem.


Això completa la configuració bàsica.

Сертификаты

ТеорияCisco Meeting Server requereix una comunicació xifrada entre diversos components i, com a resultat, es requereixen certificats X.509 per a tots els desplegaments de CMS. Ajuden a garantir que altres servidors/serveis confien en els serveis/servidor.

Cada servei requereix un certificat, però crear certificats separats per a cada servei pot generar confusió i complexitat innecessària. Afortunadament, podem generar un parell de claus pública-privada d'un certificat i després reutilitzar-los en diversos serveis. En el nostre cas, s'utilitzarà el mateix certificat per a Call Bridge, XMPP Server, Web Bridge i Web Admin. Per tant, heu de crear un parell de claus de certificat públiques i privades per a cada servidor del clúster.

La agrupació de bases de dades, però, té alguns requisits especials de certificat i, per tant, requereix els seus propis certificats que són diferents dels dels altres serveis. CMS utilitza un certificat de servidor, que és similar als certificats utilitzats per altres servidors, però també hi ha un certificat de client utilitzat per a les connexions de base de dades. Els certificats de bases de dades s'utilitzen tant per a l'autenticació com per al xifratge. En lloc de proporcionar un nom d'usuari i una contrasenya perquè el client es connecti a la base de dades, presenta un certificat de client en el qual el servidor confia. Cada servidor del clúster de bases de dades utilitzarà el mateix parell de claus públiques i privades. Això permet que tots els servidors del clúster xifren les dades de manera que només poden ser desxifrades per altres servidors que també comparteixen el mateix parell de claus.

Perquè la redundància funcioni, els clústers de bases de dades han de constar d'un mínim de 3 servidors, però no més de 5, amb un temps màxim d'anada i tornada de 200 ms entre qualsevol membre del clúster. Aquest límit és més restrictiu que per a l'agrupació de Call Bridge, de manera que sovint és el factor limitant en els desplegaments distribuïts geogràficament.

La funció de base de dades per a un CMS té una sèrie de requisits únics. A diferència d'altres funcions, requereix un certificat de client i servidor, on el certificat de client té un camp CN específic que es presenta al servidor.

El CMS utilitza una base de dades Postgres amb un mestre i diverses rèpliques completament idèntiques. Només hi ha una base de dades primària alhora (el "servidor de bases de dades"). Els membres restants del clúster són rèpliques o "clients de bases de dades".

Un clúster de bases de dades requereix un certificat de servidor dedicat i un certificat de client. Han d'estar signats per certificats, normalment una autoritat de certificació privada interna. Com que qualsevol membre del clúster de bases de dades pot convertir-se en el mestre, els parells de certificats de servidor de base de dades i de client (que contenen les claus públiques i privades) s'han de copiar a tots els servidors perquè puguin assumir la identitat del client o del servidor de la base de dades. A més, s'ha de carregar el certificat arrel de la CA per garantir que es puguin verificar els certificats de client i servidor.

Per tant, creem una sol·licitud per a un certificat que serà utilitzat per tots els serveis del servidor excepte la base de dades (hi haurà una sol·licitud separada per a això) amb una ordre com:

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

A CN escrivim el nom general dels nostres servidors. Per exemple, si els noms d'amfitrió dels nostres servidors servidor01, servidor02, servidor03, llavors CN serà server.example.com

Fem el mateix als dos servidors restants amb la diferència que les ordres contindran els "noms d'amfitrió" corresponents.

Generem dues sol·licituds de certificats que seran utilitzats pel servei de base de dades amb ordres com:

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

pki csr dbclusterclient CN:postgres

on dbclusterserver и dbclusterclient noms de les nostres sol·licituds i futurs certificats, hostname1(2)(3) noms dels servidors corresponents.

Realitzem aquest procediment només en un servidor (!), i penjarem els certificats i els fitxers .key corresponents a altres servidors.

Activeu el mode de certificat de client a AD CS

També heu de combinar els certificats de cada servidor en un sol fitxer.A *NIX:

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

A Windows/DOS:

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

I puja a cada servidor:
1. Certificat de servidor “individual”.
2. Certificat arrel (juntament amb els intermedis, si n'hi ha).
3. Certificats per a la base de dades (“servidor” i “client”) i fitxers amb l'extensió .key, que es van generar en crear una sol·licitud dels certificats de la base de dades “servidor” i “client”. Aquests fitxers han de ser iguals a tots els servidors.
4. Expedient dels tres certificats “individuals”.

Com a resultat, hauríeu d'obtenir alguna cosa com aquesta imatge de fitxer a cada servidor.

Clúster de bases de dades

Ara que teniu tots els certificats carregats als servidors CMS, podeu configurar i habilitar l'agrupació de bases de dades entre els tres nodes. El primer pas és seleccionar un servidor com a node mestre del clúster de bases de dades i configurar-lo completament.

Base de dades mestra

El primer pas per configurar la rèplica de la base de dades és especificar els certificats que s'utilitzaran per a la base de dades. Això es fa mitjançant una comanda com:

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

Ara diguem al CMS quina interfície utilitzarà per agrupar bases de dades amb l'ordre:

database cluster localnode a

A continuació, inicialitzem la base de dades del clúster al servidor principal amb l'ordre:

database cluster initialize

Nodes de base de dades de clients

Fem el mateix procediment, només en lloc de l'ordre inicialització del clúster de la base de dades introduïu una ordre com:

database cluster join <ip address existing master>

on l'adreça IP adreça IP mestra existent del servidor CMS en què s'ha inicialitzat el clúster, simplement Mestre.

Comprovem com funciona el nostre clúster de bases de dades a tots els servidors amb l'ordre:

database cluster status

Fem el mateix al tercer servidor restant.

Com a resultat, resulta que el nostre primer servidor és el Mestre, la resta són Esclaus.

Servei d'administració web

Activa el servei d'administrador web:

webadmin listen a 445

El port 445 es va escollir perquè el port 443 s'utilitza per a l'accés de l'usuari al client web

Configurem el servei Web Admin amb fitxers de certificats amb una ordre com:

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

I habiliteu Web Admin amb l'ordre:

webadmin enable

Si tot va bé, rebrem línies d'ÈXIT que indiquen que l'Administrador Web està configurat correctament per a la xarxa i el certificat. Comprovem la funcionalitat del servei mitjançant un navegador web i introduïm l'adreça de l'administrador web, per exemple: cms.example.com: 445

Call Bridge Cluster

Call Bridge és l'únic servei present en cada desplegament de CMS. Call Bridge és el principal mecanisme de conferència. També proporciona una interfície SIP perquè les trucades es puguin encaminar cap a o des d'ella, per exemple, un Cisco Unified CM.

Les ordres descrites a continuació s'han d'executar a cada servidor amb els certificats adequats.
Per tant:

Associem els certificats al servei Call Bridge amb una ordre com:

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

Enllacem els serveis de CallBridge a la interfície que necessitem amb l'ordre:

callbridge listen a

I reinicieu el servei amb l'ordre:

callbridge restart

Ara que tenim els nostres Call Bridges configurats, podem configurar el clustering de Call Bridge. El clúster de Call Bridge és diferent del clúster de bases de dades o XMPP. Call Bridge Cluster pot suportar de 2 a 8 nodes sense cap restricció. Proporciona no només redundància, sinó també equilibri de càrrega perquè les conferències es puguin distribuir activament entre servidors Call Bridge mitjançant la distribució intel·ligent de trucades. El CMS té funcions addicionals, grups Call Bridge i funcions relacionades que es poden utilitzar per a una gestió posterior.

L'agrupament del pont de trucades es configura principalment mitjançant la interfície d'administració web
El procediment que es descriu a continuació s'ha de dur a terme a cada servidor del clúster.
Per tant,

1. Aneu a través del web a Configuració > Clúster.
2. In Identitat del pont de trucades Com a nom únic, introduïu callbridge[01,02,03] corresponent al nom del servidor. Aquests noms són arbitraris, però han de ser únics per a aquest clúster. Són de caràcter descriptiu perquè indiquen que són identificadors de servidor [01,02,03].
3.B Ponts de trucades agrupats introduïu els URL de l'administrador web dels nostres servidors al clúster, cms[01,02,03].example.com:445, al camp Adreça. Assegureu-vos d'especificar el port. Podeu deixar el domini SIP de Peer link buit.
4. Afegiu un certificat a la confiança de CallBridge de cada servidor, el fitxer del qual conté tots els certificats dels nostres servidors, que vam fusionar en aquest fitxer al principi, amb una ordre com:

callbridge trust cluster <trusted cluster certificate bundle>

I reinicieu el servei amb l'ordre:

callbridge restart

Com a resultat, a cada servidor hauríeu d'obtenir aquesta imatge:

Clúster XMPP

El servei XMPP del CMS s'utilitza per gestionar tot el registre i l'autenticació de Cisco Meeting Apps (CMA), inclòs el client web CMA WebRTC. El mateix Call Bridge també actua com a client XMPP amb finalitats d'autenticació i, per tant, s'ha de configurar com altres clients. La tolerància a errors XMPP és una característica que s'admet als entorns de producció des de la versió 2.1

Les ordres descrites a continuació s'han d'executar a cada servidor amb els certificats adequats.
Per tant:

Associem certificats amb el servei XMPP amb una ordre com:

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

A continuació, definiu la interfície d'escolta amb l'ordre:

xmpp listen a

El servei XMPP requereix un domini únic. Aquest és l'inici de sessió per als usuaris. En altres paraules, quan un usuari intenta iniciar sessió amb l'aplicació CMA (o mitjançant el client WebRTC), introdueix userID@logindomain. En el nostre cas serà userid@conf.exemple.com. Per què no és només example.com? En el nostre desplegament particular, vam seleccionar el nostre domini Unified CM que els usuaris de Jabber utilitzaran a Unified CM com a example.com, de manera que necessitàvem un domini diferent perquè els usuaris de CMS encaminéssin les trucades cap i des del CMS a través de dominis SIP.

Configureu un domini XMPP mitjançant una ordre com:

xmpp domain <domain>

I habiliteu el servei XMPP amb l'ordre:

xmpp enable

Al servei XMPP, heu de crear credencials per a cada Call Bridge que s'utilitzaran quan us registreu amb el servei XMPP. Aquests noms són arbitraris (i no estan relacionats amb els noms únics que heu configurat per a l'agrupació del pont de trucades). Heu d'afegir tres ponts de trucada en un servidor XMPP i després introduir aquestes credencials en altres servidors XMPP del clúster perquè aquesta configuració no s'adapta a la base de dades del clúster. Més endavant configurarem cada Call Bridge perquè utilitzi aquest nom i secret per registrar-se al servei XMPP.

Ara hem de configurar el servei XMPP al primer servidor amb tres Call Bridges callbridge01, callbridge02 i callbridge03. A cada compte se li assignaran contrasenyes aleatòries. Més tard s'introduiran en altres servidors de Call Bridge per iniciar sessió en aquest servidor XMPP. Introduïu les ordres següents:

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

Com a resultat, comprovem què va passar amb l'ordre:

xmpp callbridge list

A la resta de servidors hauria d'aparèixer exactament la mateixa imatge després dels passos que es descriuen a continuació.

A continuació, afegim exactament la mateixa configuració als dos servidors restants, només amb les ordres

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

Afegim Secret amb molta cura perquè, per exemple, no hi hagi espais addicionals.


Com a resultat, cada servidor hauria de tenir la mateixa imatge:

A continuació, a tots els servidors del clúster, especifiquem en confiança el fitxer que conté els tres certificats, creat anteriorment amb una ordre com aquesta:

xmpp cluster trust <trust bundle>

Activem el mode de clúster xmpp a tots els servidors de clúster amb l'ordre:

xmpp cluster enable

Al primer servidor del clúster, iniciem la creació d'un clúster xmpp amb l'ordre:

xmpp cluster initialize

En altres servidors, afegiu un clúster a xmpp amb una ordre com:

xmpp cluster join <ip address head xmpp server>

Comprovem a cada servidor l'èxit de la creació d'un clúster XMPP a cada servidor amb les ordres:

xmpp status
xmpp cluster status

Primer servidor:

Segon servidor:

Tercer servidor:

S'està connectant Call Bridge a XMPP

Ara que el clúster XMPP s'està executant, heu de configurar els serveis de Call Bridge per connectar-vos al clúster XMPP. Aquesta configuració es fa a través de l'administrador web.

A cada servidor, aneu a Configuració > General i al camp Nom únic de Call Bridge escriu noms únics corresponents al servidor Call Bridge pont de trucades[01,02,03]... En camp domini conf.example.ru i les contrasenyes corresponents, podeu espiar-les
a qualsevol servidor del clúster amb l'ordre:

xmpp callbridge list

Deixeu el camp "Servidor" buit Callbridge realitzarà una cerca de DNS SRV _xmpp-component._tcp.conf.example.comper trobar un servidor XMPP disponible. Les adreces IP per connectar callbridges a XMPP poden diferir en cada servidor, depèn dels valors que es tornin a la sol·licitud de registre _xmpp-component._tcp.conf.example.com callbridge, que al seu torn depèn de la configuració de prioritat per a un registre DNS determinat.

A continuació, aneu a Estat > General per verificar si el servei Call Bride està connectat correctament al servei XMPP.

Web Bridge

A cada servidor del clúster, activeu el servei Web Bridge amb l'ordre:

webbridge listen a:443

Configurem el servei Web Bridge amb fitxers de certificats amb una ordre com:

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

Web Bridge admet HTTPS. Redirigirà HTTP a HTTPS si està configurat per utilitzar "http-redirect".
Per habilitar la redirecció HTTP, utilitzeu l'ordre següent:

webbridge http-redirect enable

Per fer saber a Call Bridge que Web Bridge pot confiar en les connexions de Call Bridge, utilitzeu l'ordre:

webbridge trust <certfile>

on aquest és un fitxer que conté els tres certificats de cada servidor del clúster.

Aquesta imatge hauria d'estar a tots els servidors del clúster.


Ara hem de crear un usuari amb el rol “appadmin”, el necessitem per poder configurar el nostre clúster(!), i no cada servidor del clúster per separat, d'aquesta manera la configuració s'aplicarà per igual a cada servidor malgrat el fet que es faran una vegada.


Per a una configuració posterior utilitzarem Carter.

Per a l'autorització, seleccioneu Bàsic a la secció Autorització

Per enviar correctament les ordres al servidor CMS, heu d'establir la codificació necessària

Especifiquem Webbridge amb l'ordre PAL amb paràmetre url i significat cms.example.com



En el mateix pont web, indiquem els paràmetres necessaris: accés convidat, accés protegit, etc.

Grups de pont de trucades

Per defecte, el CMS no sempre fa l'ús més eficient dels recursos de conferència disponibles.

Per exemple, per a una reunió amb tres participants, cada participant pot acabar en tres Call Bridges diferents. Per tal que aquests tres participants es comuniquin entre ells, Call Bridges establirà automàticament connexions entre tots els servidors i clients del mateix espai, de manera que sembli com si tots els clients estiguessin al mateix servidor. Malauradament, l'inconvenient d'això és que una única conferència de 3 persones ara consumirà 9 ports multimèdia. Es tracta, òbviament, d'un ús ineficient dels recursos. A més, quan un Call Bridge està realment sobrecarregat, el mecanisme predeterminat és continuar acceptant trucades i oferir un servei de qualitat reduïda a tots els subscriptors d'aquest Call Bridge.

Aquests problemes es resolen mitjançant la funció Call Bridge Group. Aquesta característica es va introduir a la versió 2.1 del programari Cisco Meeting Server i s'ha ampliat per admetre l'equilibri de càrrega tant per a trucades entrants com sortides de Cisco Meeting App (CMA), inclosos els participants de WebRTC.

Per resoldre el problema de reconnexió, s'han introduït tres límits de càrrega configurables per a cada Call Bridge:

Límit de càrrega — aquesta és la càrrega numèrica màxima per a un pont de trucades concret. Cada plataforma té un límit de càrrega recomanat, com ara 96000 per al CMS1000 i 1.25 GHz per vCPU per a la màquina virtual. Les diferents trucades consumeixen una certa quantitat de recursos en funció de la resolució i la velocitat de fotogrames del participant.
NewConferenceLoadLimitBasisPoints (per defecte 50% loadLimit): estableix el límit de càrrega del servidor, després del qual es rebutgen les noves conferències.
ExistingConferenceLoadLimitBasisPoints (80% per defecte de loadLimit): el valor de càrrega del servidor després del qual es rebutjaran els participants que s'uneixin a una conferència existent.

Tot i que aquesta funció es va dissenyar per a la distribució de trucades i l'equilibri de càrrega, altres grups com ara servidors TURN, servidors Web Bridge i gravadors també es poden assignar a grups de pont de trucades perquè també es puguin agrupar correctament per a un ús òptim. Si algun d'aquests objectes no està assignat a un grup de trucades, se suposa que està disponible per a tots els servidors sense cap prioritat particular.

Aquests paràmetres es configuren aquí: cms.example.com:445/api/v1/system/configuration/cluster

A continuació, indiquem a cada callbridge a quin grup de callbridge pertany:

Primer callbridge

Segon pont de trucada

Tercer pont de trucades


Així, vam configurar el grup Call Brdge per utilitzar de manera més eficient els recursos del clúster de Cisco Meeting Server.

Importació d'usuaris des de l'Active Directory

El servei Web Admin té una secció de configuració LDAP, però no ofereix opcions de configuració complexes, i la informació no s'emmagatzema a la base de dades del clúster, de manera que la configuració s'haurà de fer, ja sigui manualment a cada servidor a través de la interfície web, o mitjançant l'API, i perquè "tres vegades" no us aixequem" encara configurarem les dades a través de l'API.

S'utilitza l'URL per accedir cms01.exemple.com:445/api/v1/ldapServers crea un objecte de servidor LDAP, especificant paràmetres com ara:

• IP del servidor
• número de port
• Nom d'usuari
• contrasenya
• assegurar

Segur: seleccioneu cert o fals segons el port, 389 - no segur, 636 - protegit.


Assignació de paràmetres d'origen LDAP als atributs del Cisco Meeting Server.
El mapeig LDAP mapeja els atributs del directori LDAP amb els atributs del CMS. Els atributs reals:

• jidMapping
• nameMapping
• CoSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Descripció dels atributsJID representa l'identificador d'inici de sessió de l'usuari al CMS. Com que es tracta d'un servidor LDAP de Microsoft Active Directory, el CMS JID s'assigna al sAMAccountName a LDAP, que és essencialment l'identificador d'inici de sessió de l'Active Directory de l'usuari. Tingueu en compte també que agafeu sAMAccountName i afegiu el domini conf.pod6.cms.lab al final perquè aquest és l'inici de sessió que utilitzaran els vostres usuaris per iniciar sessió al CMS.

nameMapping coincideix amb el que hi ha al camp DisplayName de l'Active Directory amb el camp de nom CMS de l'usuari.

CoSpaceNameMapping crea un nom d'espai CMS basat en el camp displayName. Aquest atribut, juntament amb l'atribut coSpaceUriMapping, és el que es requereix per crear un espai per a cada usuari.

coSpaceUriMapping defineix la part de l'usuari de l'URI associada a l'espai personal de l'usuari. Alguns dominis es poden configurar per marcar-se a l'espai. Si la part d'usuari coincideix amb aquest camp per a un d'aquests dominis, la trucada es dirigirà a l'espai d'aquest usuari.

coSpaceSecondaryUriMapping defineix un segon URI per arribar a l'espai. Això es pot utilitzar per afegir un àlies numèric per encaminar les trucades a l'espai de l'usuari importat com a alternativa a l'URI alfanumèric definit al paràmetre coSpaceUriMapping.

El servidor LDAP i l'assignació LDAP estan configurats. Ara cal enllaçar-los creant una font LDAP.

S'utilitza l'URL per accedir cms01.exemple.com:445/api/v1/ldapSource crea un objecte font LDAP, especificant paràmetres com ara:

• servidor
• cartografia
• baseDn
• Filtrar

Ara que la configuració LDAP s'ha completat, podeu realitzar l'operació de sincronització manual.

Ho fem a la interfície web de cada servidor fent clic Sincronitza ara a la secció Active Directory


o mitjançant l'API amb l'ordre PAL utilitzant l'URL per accedir cms01.exemple.com:445/api/v1/ldapSyncs

Conferències ad hoc

Què és això?En el concepte tradicional, una conferència és quan dos participants parlen entre ells, i un dels participants (utilitzant un dispositiu registrat amb Unified CM) prem el botó "Conferència", truca a l'altra persona i després de parlar amb aquest tercer. , torna a prémer el botó "Conferència" per unir-se a tots els participants a la conferència tripartita.

El que distingeix una conferència Ad-Hoc d'una conferència programada en un CMS és que una conferència Ad-Hoc no és només una trucada SIP al CMS. Quan l'iniciador de la conferència fa clic al botó Conferència una segona vegada per convidar tothom a la mateixa reunió, Unified CM ha de fer una trucada d'API al CMS per crear una conferència sobre la marxa a la qual després es transfereixen totes les trucades. Tot això passa desapercebut pels participants.

Això vol dir que Unified CM ha de configurar les credencials de l'API i l'adreça/port WebAdmin del servei, així com el tronc SIP directament al servidor CMS per continuar la trucada.

Si cal, CUCM pot crear dinàmicament un espai al CMS perquè cada trucada pugui arribar al CMS i coincidir amb la regla de trucada entrant que està destinada als espais.

Integració amb CUCM configurat de la mateixa manera que es descriu a l'article més d'hora tret que a Cisco UCM cal que creeu tres troncals per al CMS, tres ponts de conferència, al perfil de seguretat SIP especifiqueu tres noms d'assumptes, grups de rutes, llistes de rutes, grups de recursos multimèdia i llistes de grups de recursos multimèdia i afegiu algunes regles d'encaminament. al servidor de reunions de Cisco.

Perfil de seguretat SIP:


Troncs:


Cada tronc té el mateix aspecte:




Pont de conferències


Cada pont de conferències té el mateix aspecte:


Grup de Rutes


Llista de rutes


Grup de Recursos Mitjans


Llista de grups de recursos de mitjans

Regles de convocatòria

A diferència dels sistemes de gestió de trucades més avançats, com ara Unified CM o Expressway, CMS només busca el domini al camp SIP Request-URI per a noves trucades. Així que si SIP INVITE és per sip: [protegit per correu electrònic]El CMS només es preocupa per domini.com. CMS segueix aquestes regles per determinar on s'ha de dirigir una trucada:

1. El CMS primer intenta fer coincidir el domini SIP amb els dominis configurats a les regles de trucades entrants. Aquestes trucades es poden dirigir a espais ("orientats") o usuaris específics, IVR interns o destinacions de Microsoft Lync/Skype for Business (S4B) integrades directament.
2. Si no hi ha cap coincidència a les regles de trucades entrants, CMS intentarà coincidir amb el domini configurat a la taula de desviament de trucades. Si es fa una coincidència, la regla pot rebutjar explícitament la trucada o desviar la trucada. En aquest moment, el CMS pot reescriure el domini, cosa que de vegades és útil per trucar a dominis de Lync. També podeu optar per passar el llançament, el que significa que cap dels camps es modificarà més, o utilitzar un pla de marcatge intern de CMS. Si no hi ha cap coincidència a les regles de desviament de trucades, el valor predeterminat és rebutjar la trucada. Tingueu en compte que al CMS, tot i que la trucada està "desviada", els mitjans segueixen vinculats al CMS, la qual cosa vol dir que estarà a la ruta de senyalització i trànsit de mitjans.
Aleshores, només les trucades desviades estan subjectes a les regles de trucades sortints. Aquests paràmetres determinen les destinacions on s'envien les trucades, el tipus de troncal (ja sigui una nova trucada de Lync o una trucada SIP estàndard) i qualsevol conversió que es pugui realitzar si la transferència no està seleccionada a la regla de desviament de trucades.

Aquí teniu el registre real del que passa durant una conferència ad-hoc

La captura de pantalla ho mostra malament (no sé com fer-ho millor), així que escriuré el registre així:

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

La pròpia conferència ad-hoc:


Regles de trucades entrants
És necessari configurar els paràmetres de les trucades entrants per poder rebre una trucada al CMS. Com heu vist a la configuració de LDAP, tots els usuaris s'han importat amb el domini conf.pod6.cms.lab. Per tant, com a mínim, voleu que les trucades a aquest domini orientin espais. També haureu de configurar regles per a tot el que està destinat al nom de domini totalment qualificat (i potser fins i tot a l'adreça IP) de cadascun dels servidors CMS. El nostre control de trucades extern, Unified CM, configurarà troncs SIP dedicats a cadascun dels servidors CMS de manera individual. Depenent de si la destinació d'aquests troncs SIP és una adreça IP o el FQDN del servidor determinarà si el CMS s'ha de configurar per acceptar trucades dirigides a la seva adreça IP o FQDN.

El domini que té la regla d'entrada de prioritat més alta s'utilitza com a domini per a qualsevol espai d'usuari. Quan els usuaris se sincronitzen mitjançant LDAP, el CMS crea espais automàticament, però només la part de l'usuari de l'URI (coSpaceUriMapping), per exemple, user.space. Part domini L'URI complet es genera a partir d'aquesta regla. De fet, si inicieu sessió a Web Bridge en aquest moment, veureu que l'URI de l'espai no té un domini. En establir aquesta regla com a prioritat més alta, esteu establint el domini per als espais generats conf.exemple.com.


Regles de trucades sortints

Per permetre als usuaris fer trucades sortints al clúster de Unified CM, heu de configurar regles de sortida. El domini dels punts finals registrats amb Unified CM, com ara Jabber, és example.com. Les trucades a aquest domini s'han d'encaminar com a trucades SIP estàndard als nodes de processament de trucades de Unified CM. El servidor principal és cucm-01.example.com i el servidor addicional és cucm-02.example.com.

La primera regla descriu l'encaminament més senzill de trucades entre servidors de clúster.

Camp Local des del domini és responsable del que es mostrarà a l'URI SIP de la persona que truca després del símbol “@”. Si el deixem buit, després del símbol "@" hi haurà l'adreça IP del CUCM per la qual passa aquesta trucada. Si especifiquem un domini, després del símbol “@” hi haurà realment un domini. Això és necessari per poder tornar a trucar, en cas contrari no serà possible tornar a trucar mitjançant SIP-URI nom@adreça-ip.

Truqueu quan s'especifiqui Local des del domini


Truca quan NO indicat Local des del domini


Assegureu-vos d'especificar explícitament Encriptat o No xifrat per a les trucades sortints, perquè res funciona amb el paràmetre Auto.

Gravació

Les videoconferències són gravades pel servidor de registre. La gravadora és exactament la mateixa que el servidor de reunions de Cisco. La gravadora no requereix instal·lació de cap llicència. Les llicències de gravació són necessàries per als servidors que executen els serveis de CallBridge, és a dir. es requereix una llicència d'enregistrament i s'ha d'aplicar al component CallBridge, i no al servidor que executa Recorder. El gravador es comporta com un client XMPP (Extensible Messaging and Presence Protocol), de manera que el servidor XMPP ha d'estar habilitat al servidor que allotja CallBridge.

Perquè Tenim un clúster i la llicència s'ha d'"estirar" als tres servidors del clúster. A continuació, simplement al vostre compte personal a les llicències associem (afegim) les adreces MAC de les interfícies a de tots els servidors CMS inclosos al clúster.

I aquesta és la imatge que hauria d'estar a tots els servidors del clúster

En general, hi ha diversos escenaris per col·locar Recorder, però ens quedarem amb això:


Abans de configurar la gravadora, heu de preparar un lloc on s'enregistraran realment les videoconferències. De fet, aquí enllaç, com configurar tots els enregistraments. Em concentro en punts i detalls importants:

1. És millor treure el certificat del primer servidor del clúster.
2. L'error "Grabadora no disponible" pot produir-se perquè s'especifica un certificat incorrecte a la confiança de la gravadora.
3. És possible que l'escriptura no funcioni si el directori NFS especificat per a la gravació no és el directori arrel.

De vegades és necessari gravar automàticament una conferència d'un usuari o espai específic.

Per a això, es creen dos CallProfiles:
Amb la gravació desactivada


I amb funció de gravació automàtica


A continuació, "adjuntem" un CallProfile amb una funció de gravació automàtica a l'espai desitjat.


A CMS s'estableix que si un perfil de trucada està lligat explícitament a qualsevol espai o espai, aquest perfil de trucada només funciona en relació amb aquests espais específics. I si el CallProfile no està lligat a cap espai, de manera predeterminada s'aplica a aquells espais als quals no està lligat explícitament cap CallProfile.

La propera vegada intentaré descriure com s'accedeix al CMS fora de la xarxa interna de l'organització.

Fonts:

• 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

Font: www.habr.com