In questu prublema, vi mustrarà è spiegheraghju alcune di e intricacies di a stallazione di un servitore CMS in u modu di cluster di failover.
TeoriaIn generale, ci sò trè tippi di implementazione di u servitore CMS:
- Unicu cumminatu(Single cumminatu), i.e. Questu hè un servitore nantu à quale tutti i servizii necessarii sò in esecuzione. In a maiò parte di i casi, stu tipu di implementazione hè adattatu solu per l'accessu di u cliente internu è in ambienti più chjuchi induve a scalabilità è e limitazioni di redundancy di un servitore unicu ùn sò micca un prublema critica, o in situazione induve u CMS solu eseguisce certe funzioni, cum'è ad hoc. cunferenze nantu à Cisco UCM.
Schema apprussimativu di u travagliu:
- Single Split(Single Split) estende u tipu di implementazione precedente aghjunghjendu un servitore separatu per accessu esternu. In implementazioni legacy, questu significava implementà un servitore CMS in un segmentu di rete demilitarizatu (DMZ) induve i clienti esterni puderanu accede, è un servitore CMS in u core di a rete induve i clienti internu puderanu accede à u CMS. Stu mudellu di implementazione particulari hè avà rimpiazzatu da u tipu chjamatu Single Edge, chì hè custituitu di servitori Cisco Expressway, chì anu o averebbe parechje di e stesse capacità di bypass di Firewall per chì i clienti ùn anu micca bisognu di aghjunghje un servitore CMS di punta dedicatu.
Schema apprussimativu di u travagliu:
- Scalabile è Resiliente(Scalable and Fault Tolerant) Stu tipu include redundancy per ogni cumpunente, chì permette à u sistema di cresce cù i vostri bisogni à a so capacità massima mentre furnisce redundancy in casu di fallimentu. Utiliza ancu u cuncettu Single Edge per furnisce un accessu esternu sicuru. Questu hè u tipu chì guardemu in questu episodiu. Se avemu capitu cumu implementà stu tipu di cluster, ùn avemu micca solu capiscenu altri tipi di implementazioni, ma pudemu ancu capisce cumu creà clusters di servitori CMS per accodà a crescita potenziale in a dumanda.
Prima di passà à implementazione, avete bisognu di capiscenu alcune cose basi, vale à dì
Principali cumpunenti di u software CMS:
- Archivio: Permette di cumminà alcune cunfigurazioni, cum'è u pianu di marcatu, i spazii d'utilizatori è l'utilizatori stessi. Supporta clustering per alta dispunibilità (single master) solu.
- Call Bridge: un serviziu di cunferenza audio è video chì furnisce un cuntrollu tutale di a gestione è di trasfurmazioni di chjamate è prucessi multimediali. Supporta clustering per alta dispunibilità è scalabilità.
- servitore XMPP: rispunsevuli di a registrazione è l'autentificazione di i clienti chì utilizanu l'Applicazione Cisco Meeting è/o WebRTC (cumunicazione in tempu reale, o solu in u navigatore), è ancu di signalazione intercompunenti. Pò esse raggruppati solu per alta dispunibilità.
- Web Bridge: Fornisce accessu à u cliente à WebRTC.
- Loadbalancer: Fornisce un puntu di cunnessione unicu per Cisco Meeting Apps in modalità Single Split. Ascolta l'interfaccia esterna è u portu per e cunnessione entranti. Ugualmente, u bilanciu di carica accetta e cunnessione TLS entranti da u servitore XMPP, attraversu quale pò cambià e cunnessione TCP da i clienti esterni.
In u nostru scenariu ùn serà micca necessariu. - TURN server: Fornisce a tecnulugia di bypass Firewall chì permette
mette u nostru CMS daretu à un Firewall o NAT per cunnette i clienti esterni utilizendu Cisco Meeting App o dispositivi SIP. In u nostru scenariu ùn serà micca necessariu. - Web Admin: Interfaccia amministrativa è accessu API, cumpresu per cunferenzi speciali Unified CM.
Modi di cunfigurazione
A cuntrariu di a maiò parte di l'altri prudutti Cisco, Cisco Meeting Server supporta trè metudi di cunfigurazione per accoglie ogni tipu di implementazione.
- Linea di cummanda (CLI): Interfaccia di linea di cumanda cunnisciuta cum'è MMP per a cunfigurazione iniziale è e funzioni di certificatu.
- Amministratore Web: Principalmente per e cunfigurazioni relative à CallBridge, soprattuttu quandu si stabilisce un servitore unicu senza cluster.
- REST API: Adupratu per i travaglii di cunfigurazione più cumplessi è i travaglii di basa di dati raggruppati.
In più di u sopra, u protocolu hè utilizatu SFTP per trasfiriri i fugliali-di solitu licenze, certificati, o logs-versu è da u servitore CMS.
In i guidi di implementazione da Cisco hè scrittu in biancu è in inglese chì u cluster deve esse implementatu almenu trè servitori (nodi) in u cuntestu di basa di dati. Perchè Solu cù un numeru imparu di nodi, u mecanismu per selezziunà un novu travagliu di Database Master, è in generale u Database Master hà una cunnessione cù a maiò parte di a basa di dati di u servitore CMS.
E cum'è a pratica mostra, dui servitori (nodi) sò veramente micca abbastanza. U mecanismu di selezzione funziona quandu u Maestru hè riavviatu, u servitore Slave diventa Maestru solu dopu chì u servitore riavviatu hè rializatu. Tuttavia, se in un cluster di dui servitori, u servitore Maestru s'alluntana subitu, u servitore Slave ùn diventerà micca u Maestru, è se u Slave esce, u servitore Master restante diventerà u Slave.
Ma in u cuntestu di XMPP, seria veramente necessariu di assemblà un cluster di trè servitori, perchè se, per esempiu, disattiveghjanu u serviziu XMPP in unu di i servitori in quale XMMP hè in u statutu di Leader, allora in u servitore restante XMPP resterà in u status di Follower è e cunnessione CallBridge à XMPP cascanu, perchè. CallBridge si cunnetta esclusivamente à XMPP cù status Leader. È questu hè criticu, perchè ... micca una sola chjama passerà.
Ancu in a stessa guida di implementazione un cluster cun un servitore XMPP hè dimustratu.
E tenendu in contu u sopra, diventa chjaru perchè: funziona perchè hè in modu di failover.
In u nostru casu, u servitore XMPP serà presente nantu à tutti i trè nodi.
Si assume chì tutti i trè di i nostri servitori sò up.
I registri DNS
Prima di inizià a stallazione di i servitori, avete bisognu di creà registri DNS А и SRV tipi:
Per piacè nutate chì in i nostri registri DNS ci sò dui domini example.com è cunf.esempiu.com. Example.com hè un duminiu chì tutti l'abbonati di u Cisco Unified Communication Manager ponu utilizà per i so URI, chì hè più prubabilmente presente in a vostra infrastruttura o hè prubabilmente presente. Or example.com currisponde à u stessu duminiu chì l'utilizatori utilizanu per i so indirizzi email. O u cliente Jabber in u vostru laptop pò avè un URI [email prutettu]. Duminiu cunf.example.com hè u duminiu chì serà cunfiguratu per l'utilizatori di Cisco Meeting Server. U duminiu di u Cisco Meeting Server serà cunf.example.com, cusì per u stessu utilizatore Jabber, l'URI user@ avissi da esse usatu per accede à u Cisco Meeting Servercunf.esempiu.com.
Cunfigurazione basica
Tutti i paràmetri descritti quì sottu sò mostrati nantu à un servitore, ma anu da esse fattu nantu à ogni servitore in u cluster.
QoS
Dapoi u CMS genera In tempu reale u trafficu sensibile à i ritardi è a perdita di pacchetti, in a maiò parte di i casi hè cunsigliatu di cunfigurà a qualità di serviziu (QoS). Per ottene questu, u CMS sustene i pacchetti di tagging cù i Codici di Servizi Differenziati (DSCP) chì genera. Ancu se a priorità di u trafficu basatu in DSCP dipende da cumu u trafficu hè trattatu da i cumpunenti di a rete di a vostra infrastruttura, in u nostru casu, cunfiguremu u nostru CMS cù a priorità tipica DSCP basata nantu à e migliori pratiche QoS.
In ogni servitore entremu sti cumandamenti
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ACusì, tuttu u trafficu di video era marcatu AF41 (DSCP 0x22), tuttu u trafficu di voce era marcatu EF (DSCP 0x2E), altri tipi di trafficu di bassa latenza cum'è SIP è XMPP utilizanu AF31 (DSCP 0x1A).
Verificate:
NTP
Network Time Protocol (NTP) hè impurtante micca solu per furnisce timestamps precisi di chjamate è cunferenze, ma ancu per verificà i certificati.
Aghjunghjite i servitori NTP à a vostra infrastruttura cù un cumandamentu cum'è
ntp server add <server>
In u nostru casu, ci sò dui servitori tali, cusì ci saranu duie squadre.
Verificate:
È stabilisce u fusu orariu per u nostru servitore
DNS
Aghjunghjemu i servitori DNS à u CMS cù un cumandamentu cum'è:
dns add forwardzone <domain-name> <server ip>
In u nostru casu, ci sò dui servitori tali, cusì ci saranu duie squadre.
Verificate:
Cunfigurazione di l'interfaccia di rete
Configuremu l'interfaccia cù un cumandamentu cum'è:
ipv4 <interface> add <address>/<prefix length> <gateway>
Verificate:
Nome di u servitore (Hostname)
Fixemu u nome di u servitore cù un cumandamentu cum'è:
hostname <name>
È riavviamu.
Questu cumpleta a cunfigurazione basica.
Certificati
TeoriaCisco Meeting Server richiede una cumunicazione criptata trà parechji cumpunenti, è in u risultatu, i certificati X.509 sò richiesti per tutte e implementazioni CMS. Aiutanu à assicurà chì i servizii / u servitore hè fiducia da altri servitori / servizii.
Ogni serviziu richiede un certificatu, ma a creazione di certificati separati per ogni serviziu pò purtà à cunfusione è cumplessità inutile. Per furtuna, pudemu generà una coppia di chjave publica-privata di un certificatu è poi riutilizà in parechji servizii. In u nostru casu, u listessu certificatu serà utilizatu per Call Bridge, XMPP Server, Web Bridge è Web Admin. Cusì, avete bisognu di creà un paru di chjave di certificatu publicu è privatu per ogni servitore in u cluster.
U clustering di basa di dati, in ogni modu, hà alcuni requisiti di certificatu speciale è per quessa esige i so certificati chì sò diffirenti da quelli di l'altri servizii. CMS usa un certificatu di u servitore, chì hè simile à i certificati utilizati da altri servitori, ma ci hè ancu un certificatu di cliente utilizatu per e cunnessione di basa di dati. I certificati di basa di dati sò usati sia per l'autentificazione sia per a criptografia. Invece di furnisce un nome d'utilizatore è una password per u cliente per cunnette à a basa di dati, presenta un certificatu di cliente chì hè fiduciale da u servitore. Ogni servitore in u cluster di basa di dati utilizerà a stessa coppia di chjave publica è privata. Questu permette à tutti i servitori in u cluster per criptà e dati in modu chì pò esse decifratu solu da altri servitori chì anu ancu sparte u listessu paru di chjave.
Per chì a redundanza funziona, i clusters di basa di dati devenu esse un minimu di servitori 3, ma micca più di 5, cù un tempu massimu di andata e ritorno di 200 ms trà i membri di u cluster. Stu limitu hè più restrittivu chè per u clustering di Call Bridge, cusì hè spessu u fattore limitante in implementazioni distribuite geograficamente.
U rolu di basa di dati per un CMS hà una quantità di esigenze uniche. A cuntrariu di l'altri roles, esige un certificatu di cliente è servitore, induve u certificatu di u cliente hà un campu CN specificu chì hè prisentatu à u servitore.
U CMS usa una basa di dati postgres cù un maestru è parechje rèpliche completamente identiche. Ci hè solu una basa di dati primaria à tempu (u "servitore di basa di dati"). I membri rimanenti di u cluster sò repliche o "clienti di basa di dati".
Un cluster di basa di dati richiede un certificatu di servitore dedicatu è un certificatu di cliente. Deve esse firmati da certificati, di solitu una autorità di certificazione privata interna. Perchè ogni membru di u cluster di basa di dati pò diventà u maestru, u servitore di basa di dati è i coppie di certificati di u cliente (cuntenendu e chjave publica è privata) deve esse copiatu à tutti i servitori per pudè assume l'identità di u cliente o di u servitore di basa di dati. Inoltre, u certificatu root CA deve esse caricatu per assicurà chì i certificati di u cliente è di u servitore ponu esse verificati.
Dunque, creemu una dumanda per un certificatu chì serà utilizatu da tutti i servizii di u servitore eccettu a basa di dati (ci serà una dumanda separata per questu) cù un cumandamentu cum'è:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
In CN scrivemu u nome generale di i nostri servitori. Per esempiu, se i nomi d'ospiti di i nostri servitori servitore 01, servitore 02, servitore 03, tandu CN serà server.example.com
Facemu u listessu nantu à i dui servitori rimanenti cù a diffarenza chì i cumandamenti cuntenenu i "hostnames" currispondenti.
Generemu duie dumande per i certificati chì seranu utilizati da u serviziu di basa di dati cù cumandamenti cum'è:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresinduve dbclusterserver и dbclusterclient nomi di e nostre richieste è futuri certificati, hostname1(2)(3) nomi di i servitori currispundenti.
Facemu sta prucedura solu nantu à un servitore (!), È caricheremu i certificati è i schedarii .key currispondenti à altri servitori.
Habilita u modu di certificatu di cliente in AD CS
Avete ancu bisognu di unisce i certificati per ogni servitore in un schedariu.À *NIX:
cat server01.cer server02.cer server03.cer > server.cerIn Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
È caricate à ogni servitore:
1. Certificatu di u servitore "Individuale".
2. Certificatu Root (inseme cù quelli intermedii, s'ellu ci hè).
3. Certificati per a basa di dati ("servitore" è "client") è schedari cù l'estensione .key, chì sò stati generati quandu creanu una dumanda per i certificati di basa di dati "servitore" è "client". Questi schedari devenu esse listessi in tutti i servitori.
4. File di tutti i trè certificati "individuali".
In u risultatu, duvete ottene qualcosa cum'è questa stampa di u schedariu in ogni servitore.
Cluster di basa di dati
Avà chì avete tutti i certificati caricati à i servitori CMS, pudete cunfigurà è attivà u clustering di basa di dati trà i trè nodi. U primu passu hè di selezziunà un servitore cum'è u nodu maestru di u cluster di basa di dati è cunfigurà cumplettamente.
Master Database
U primu passu in a creazione di a replicazione di a basa di dati hè di specificà i certificati chì seranu utilizati per a basa di dati. Questu hè fattu cù un cumandamentu cum'è:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Avà dicemu à u CMS quale interfaccia aduprà per a basa di dati di clustering cù u cumandimu:
database cluster localnode aAllora inizializà a basa di dati di cluster in u servitore principale cù u cumandimu:
database cluster initialize
Nodi di basa di dati di u cliente
Facemu a stessa prucedura, solu invece di u cumandamentu inizializza u cluster di basa di dati entre un cumandamentu cum'è:
database cluster join <ip address existing master>induve l'indirizzu ip l'indirizzu ip maestru esistente di u servitore CMS in quale u cluster hè statu inizializatu, solu Master.
Cuntrollamu cumu u nostru cluster di basa di dati funziona in tutti i servitori cù u cumandimu:
database cluster status
Facemu u listessu nantu à u terzu servitore restante.
In u risultatu, si trova chì u nostru primu servitore hè u Maestru, u restu sò Slaves.
Serviziu Web Admin
Attivà u serviziu di amministratore web:
webadmin listen a 445U portu 445 hè statu sceltu perchè u portu 443 hè utilizatu per l'accessu d'utilizatori à u cliente web
Configuremu u serviziu Web Admin cù i schedarii di certificatu cù un cumandamentu cum'è:
webadmin certs <keyfile> <certificatefile> <ca bundle>È attivate Web Admin cù u cumandimu:
webadmin enable
Se tuttu hè bè, riceveremu e linee SUCCESS chì indicanu chì Web Admin hè cunfiguratu currettamente per a reta è u certificatu. Cuntrollamu a funziunalità di u serviziu cù un navigatore web è inserite l'indirizzu di l'amministratore web, per esempiu: : 445
Call Bridge Cluster
Call Bridge hè l'unicu serviziu presente in ogni implementazione CMS. Call Bridge hè u principale mecanismu di cunferenza. Hè ancu furnisce una interfaccia SIP per chì e chjama ponu esse instradate da o da ellu, per esempiu, un Cisco Unified CM.
I cumandamenti descritti quì sottu deve esse eseguitu nantu à ogni servitore cù i certificati appropritati.
So:
Associemu certificati cù u serviziu Call Bridge cù un cumandamentu cum'è:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Lighemu i servizii di CallBridge à l'interfaccia chì avemu bisognu cù u cumandimu:
callbridge listen aÈ ripigliate u serviziu cù u cumandimu:
callbridge restart
Avà chì avemu i nostri Call Bridges cunfigurati, pudemu cunfigurà u clustering Call Bridge. U clustering Call Bridge hè diversu da a basa di dati o clustering XMPP. Call Bridge Cluster pò sustene da 2 à 8 nodi senza restrizioni. Fornisce micca solu ridondanza, ma ancu equilibriu di carica per chì e cunferenze ponu esse attivamente distribuite in i servitori di Call Bridge utilizendu una distribuzione intelligente di chjama. U CMS hà funzioni supplementari, gruppi di Call Bridge è funzioni cunnessi chì ponu esse aduprati per più gestione.
Call bridge clustering hè cunfiguratu principarmenti attraversu l'interfaccia di amministratore web
A prucedura descritta quì sottu deve esse realizatu nantu à ogni servitore in u cluster.
Cusì,
1. Andà à traversu u web à Configurazione> Cluster.
2. In Call Bridge identità Cum'è un nome unicu, entre callbridge[01,02,03] chì currisponde à u nome di u servitore. Questi nomi sò arbitrarii, ma devenu esse unichi per questu cluster. Sò di natura descrittiva perchè indicanu chì sò identificatori di u servitore [01,02,03].
3.B Clustered Call Bridges entre l'URL di l'amministratore web di i nostri servitori in u cluster, [01,02,03].example.com:445, in u campu Indirizzu. Assicuratevi di specificà u portu. Pudete lascià u duminiu Peer link SIP viotu.
4. Aghjunghjite un certificatu à a fiducia di CallBridge di ogni servitore, u schedariu di quale cuntene tutti i certificati di i nostri servitori, chì avemu unitu in stu schedariu à u principiu, cù un cumandamentu cum'è:
callbridge trust cluster <trusted cluster certificate bundle>È ripigliate u serviziu cù u cumandimu:
callbridge restart
In u risultatu, in ogni servitore duvete ottene sta stampa:
Cluster XMPP
U serviziu XMPP in u CMS hè utilizatu per trattà tutte e registrazioni è l'autentificazione per Cisco Meeting Apps (CMA), cumpresu u cliente web CMA WebRTC. U Call Bridge stessu agisce ancu cum'è un cliente XMPP per scopi di autentificazione è per quessa deve esse cunfiguratu cum'è altri clienti. A tolleranza di errore XMPP hè una funzione chì hè stata supportata in ambienti di produzzione da a versione 2.1
I cumandamenti descritti quì sottu deve esse eseguitu nantu à ogni servitore cù i certificati appropritati.
So:
Associemu certificati cù u serviziu XMPP cù un cumandamentu cum'è:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Allora definisce l'interfaccia d'ascolta cù u cumandimu:
xmpp listen aU serviziu XMPP richiede un duminiu unicu. Questu hè u login per l'utilizatori. In altri palori, quandu un utilizatore prova di login cù l'app CMA (o attraversu u cliente WebRTC), entra in userID@logindomain. In u nostru casu serà userid@cunf.esempiu.com. Perchè ùn hè micca solu example.com? In a nostra implementazione particulare, avemu sceltu u nostru duminiu CM Unificatu chì l'utilizatori di Jabber utilizanu in Unified CM cum'è example.com, cusì avemu bisognu di un duminiu sfarente per l'utilizatori di CMS per indirizzà e chjama à u CMS attraversu domini SIP.
Configurate un duminiu XMPP cù un cumandamentu cum'è:
xmpp domain <domain>È attivate u serviziu XMPP cù u cumandimu:
xmpp enableIn u serviziu XMPP, duvete creà credenziali per ogni Call Bridge chì serà utilizatu quandu si registra cù u serviziu XMPP. Questi nomi sò arbitrarii (è ùn sò micca ligati à i nomi unichi chì avete cunfiguratu per u clustering di u ponte di chjama). Duvete aghjunghje trè ponti di chjama in un servitore XMPP è poi inserite quelli credenziali in altri servitori XMPP in u cluster perchè sta cunfigurazione ùn si mette micca in a basa di dati di cluster. In seguitu, cunfiguremu ogni Call Bridge per utilizà stu nome è u sicretu per registrà cù u serviziu XMPP.
Avà avemu bisognu di cunfigurà u serviziu XMPP in u primu servitore cù trè Call Bridges callbridge01, callbridge02 è callbridge03. Ogni contu serà attribuitu password casuale. Seranu più tardi inseriti in altri servitori di Call Bridge per accede à stu servore XMPP. Inserite i seguenti cumandamenti:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03In u risultatu, cuntrollemu ciò chì hè accadutu cù u cumandamentu:
xmpp callbridge list
Esattamente a stessa stampa deve apparisce nantu à i servitori rimanenti dopu à i passi descritti quì sottu.
Dopu, aghjustemu esattamente i stessi paràmetri nantu à i dui servitori rimanenti, solu cù i cumandamenti
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Aghjunghjemu Secret assai cun cura per chì, per esempiu, ùn ci sò micca spazii extra in questu.
In u risultatu, ogni servitore deve avè a listessa stampa:
In seguitu, nantu à tutti i servitori in u cluster, specifiemu in fiducia u schedariu chì cuntene tutti i trè certificati, creati prima cù un cumandamentu cum'è questu:
xmpp cluster trust <trust bundle>Attivà u modu di cluster xmpp in tutti i servitori di cluster cù u cumandimu:
xmpp cluster enableIn u primu servitore di u cluster, avemu principiatu a creazione di un cluster xmpp cù u cumandimu:
xmpp cluster initializeIn altri servitori, aghjunghje un cluster à xmpp cù un cumandamentu cum'è:
xmpp cluster join <ip address head xmpp server>Cuntrollamu in ogni servitore u successu di creà un cluster XMPP in ogni servitore cù i cumandamenti:
xmpp status
xmpp cluster statusPrimu servitore:
Second server:
Terzu servitore:
Cunnettendu Call Bridge à XMPP
Avà chì u cluster XMPP hè in esecuzione, avete bisognu di cunfigurà i servizii di Call Bridge per cunnette à u cluster XMPP. Sta cunfigurazione hè fatta attraversu l'amministratore web.
In ogni servitore, andate à Configurazione> Generale è in u campu Nome unicu Call Bridge scrivite nomi unichi Call Bridge chì currispondenu à u servitore callbridge[01,02,03]... In campu Domain conf.example.ru e password currispundenti, vi ponu spia à elli
in ogni servitore in u cluster cù u cumandimu:
xmpp callbridge list
Lasciate u campu "Server" viotu Callbridge farà una ricerca DNS SRV per _xmpp-component._tcp.conf.example.comper truvà un servitore XMPP dispunibule. L'indirizzi IP per cunnette i callbridges à XMPP ponu differisce in ogni servitore, dipende da quali valori sò tornati à a dumanda di registrazione. _xmpp-component._tcp.conf.example.com callbridge, chì à u turnu dipende da i paràmetri di priorità per un datu DNS record.
Dopu, vai à Status> General per verificà s'ellu u serviziu Call Bride hè cunnessu bè cù u serviziu XMPP.
Web Bridge
In ogni servitore in u cluster, attivate u serviziu Web Bridge cù u cumandimu:
webbridge listen a:443Cunfiguremu u serviziu Web Bridge cù i schedarii di certificatu cù un cumandamentu cum'è:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge supporta HTTPS. Redirigerà HTTP à HTTPS se cunfiguratu per utilizà "http-redirect".
Per attivà a redirezzione HTTP, utilizate u cumandimu seguente:
webbridge http-redirect enablePer fà sapè à Call Bridge chì Web Bridge pò fidà di e cunnessione da Call Bridge, utilizate u cumandimu:
webbridge trust <certfile>induve questu hè un schedariu chì cuntene tutti i trè certificati da ogni servitore in u cluster.
Questa stampa deve esse in ogni servitore in u cluster.
Avà avemu bisognu di creà un utilizatore cù u rolu "appadmin", avemu bisognu per pudè cunfigurà u nostru cluster (!), È micca ogni servitore in u cluster separatamente, questu modu i paràmetri seranu applicati ugualmente à ogni servitore malgradu u fattu ch'elli seranu fatti una volta.
Per più cunfigurazione useremu .
Per l'autorizazione, selezziunate Basic in a sezione Autorizazione
Per mandà currettamente cumandamenti à u servitore CMS, avete bisognu di stabilisce a codificazione necessaria
Specificemu Webbridge cù u cumandimu POST cun paràmetru indirizzu è significatu
In u webbridge stessu, indichemu i paràmetri richiesti: accessu d'ospiti, accessu prutettu, etc.
Call Bridge Groups
Per automaticamente, u CMS ùn faci micca sempre l'usu più efficiente di e risorse di cunferenza dispunibili.
Per esempiu, per una reunione cù trè participanti, ogni participante pò finisce in trè ponti di Call differenti. In ordine di sti trè participanti à cumunicà cù l 'àutri, Call Bridges hà da stabilisce automaticamente ligami trà tutti i servori è i clienti in u listessu Space, tantu chi si vede cum'è s'è tutti i clienti sò nant'à u listessu servore. Sfortunatamente, l'inconveniente di questu hè chì una sola cunferenza di 3 persone cunsumerà avà 9 porti di media. Questu hè ovviamente un usu inefficace di risorse. Inoltre, quandu un Call Bridge hè veramente sovraccaricatu, u mecanismu predeterminatu hè di cuntinuà à accettà e chjama è furnisce un serviziu di qualità ridutta à tutti l'abbonati di quellu Call Bridge.
Sti prublemi sò risolti cù a funzione Call Bridge Group. Questa funzione hè stata introdutta in a versione 2.1 di u software Cisco Meeting Server è hè stata allargata per sustene l'equilibriu di carica per e chjama in entrata è in uscita Cisco Meeting App (CMA), cumpresi i participanti WebRTC.
Per risolve u prublema di ricunnessione, trè limiti di carica configurabili sò stati introdotti per ogni Call Bridge:
LoadLimit - questu hè a carica numerica massima per un particulare Call Bridge. Ogni piattaforma hà un limitu di carica cunsigliatu, cum'è 96000 per u CMS1000 è 1.25 GHz per vCPU per a macchina virtuale. E diverse chjamate cunsumanu una certa quantità di risorse secondu a risoluzione è a freccia di quadru di u participante.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) - stabilisce u limitu di carica di u servitore, dopu chì e novi cunferenze sò rifiutate.
ConferenceLoadLimitBasisPoints esistenti (default 80% of loadLimit) - u valore di carica di u servitore dopu chì i participanti chì si uniscenu à una cunferenza esistente seranu rifiutati.
Mentre sta funzione hè stata cuncepita per a distribuzione di chjamate è l'equilibriu di carica, altri gruppi cum'è TURN Servers, Web Bridge Servers and Recorders ponu ancu esse assignati à Call Bridge Groups in modu chì ponu ancu esse raggruppati bè per un usu ottimali. Se qualcunu di sti ogetti ùn sò micca attribuiti à un gruppu di chjama, sò presumitu chì sò dispunibuli per tutti i servitori senza alcuna priorità particulare.
Questi paràmetri sò cunfigurati quì: :445/api/v1/system/configuration/cluster
Dopu, indichemu à ogni callbridge à quale gruppu di callbridge appartene:
Prima callbridge
Second callbridge
Terzu callbridge
Cusì, avemu cunfiguratu u gruppu Call Brdige per utilizà più efficacemente e risorse di u cluster Cisco Meeting Server.
Importazione di utilizatori da Active Directory
U serviziu Web Admin hà una sezione di cunfigurazione LDAP, ma ùn furnisce micca opzioni di cunfigurazione cumplesse, è l'infurmazioni ùn sò micca guardati in a basa di dati di cluster, cusì a cunfigurazione duverà esse fatta, sia manualmente in ogni servitore per via di l'interfaccia Web, sia per mezu di l'interfaccia Web. l'API, è cusì chì avemu "trè volte "Ùn alzate micca" avemu sempre stabilitu i dati via l'API.
Utilizà l'URL per accede :445/api/v1/ldapServers creanu un oggettu di u Servitore LDAP, specificendu paràmetri cum'è:
- IP di u servitore
- numeru portu
- nome d'utilizatore
- password
- uttèniri
Secure - selezziunate veru o falsu secondu u portu, 389 - micca sicuru, 636 - prutettu.
Mappatura di i paràmetri di fonte LDAP à l'attributi in Cisco Meeting Server.
U mapping LDAP mappe l'attributi in u repertoriu LDAP à l'attributi in u CMS. L'attributi attuali:
- jidMapping
- nameMapping
- CoSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Descrizzione di l'attributiJID rapprisenta l'ID di login di l'utilizatore in u CMS. Siccomu questu hè un servitore LDAP di Microsoft Active Directory, u CMS JID mappe à u sAMAccountName in LDAP, chì hè essenzialmente l'ID di login di l'Active Directory di l'utilizatori. Innota ancu chì pigliate sAMAccountName è aghjunghje u duminiu conf.pod6.cms.lab à a fine perchè questu hè u login chì i vostri utilizatori utilizanu per accede à u CMS.
nameMapping currisponde à ciò chì hè cuntenutu in u campu di DisplayName di Active Directory à u campu di nome CMS di l'utilizatore.
CoSpaceNameMapping crea un nome di spaziu CMS basatu annantu à u campu displayName. Questu attributu, inseme cù l'attributu coSpaceUriMapping, hè ciò chì hè necessariu per creà un spaziu per ogni utilizatore.
coSpaceUriMapping definisce a parte di l'utilizatori di l'URI assuciatu cù u spaziu persunale di l'utilizatore. Certi domini ponu esse cunfigurati per esse dialed in u spaziu. Se a parte di l'utilizatori currisponde à questu campu per unu di sti domini, a chjama serà diretta à u spaziu di quellu utilizatore.
coSpaceSecondaryUriMapping definisce un secondu URI per ghjunghje à u spaziu. Questu pò esse usatu per aghjunghje un alias numericu per u routing chjamati à u spaziu di l'utilizatore impurtatu cum'è una alternativa à l'URI alfanumericu definitu in u paràmetru coSpaceUriMapping.
U servitore LDAP è a mappatura LDAP sò cunfigurati. Avà avete bisognu di ligà inseme creendu una fonte LDAP.
Utilizà l'URL per accede : 445/api/v1/ldapSource crea un ughjettu LDAP Source, specificendu paràmetri cum'è:
- servore
- aerial
- basa Dn
- filtre
Avà chì a cunfigurazione LDAP hè cumpleta, pudete fà l'operazione di sincronizazione manuale.
Facemu questu sia in l'interfaccia Web di ogni servitore clicchendu Sincronizza avà rùbbrica Active Directory
o via l'API cù u cumandimu POST usendu l'URL per accede :445/api/v1/ldapSyncs
Conferenze ad-hoc
Chì ghjè sta?In u cuncettu tradiziunale, una cunferenza hè quandu dui participanti parlanu l'un à l'altru, è unu di i participanti (aduprendu un dispositivu registratu cù Unified CM) pressu u buttone "Conferenza", chjama l'altra persona, è dopu avè parlatu cù quellu terzu. , appughjà torna u buttone "Conferenza" per unisce tutti i participanti à a cunferenza tripartita.
Ciò chì distingue una cunferenza Ad-Hoc da una cunferenza pianificata in un CMS hè chì una cunferenza Ad-Hoc ùn hè micca solu una chjama SIP à un CMS. Quandu l'iniziatore di a cunferenza cliccate nantu à u buttone Conferenza una seconda volta per invità tutti à a listessa riunione, Unified CM deve fà una chjama API à u CMS per creà una cunferenza in u volu à quale tutte e chjama sò trasferite. Tuttu chistu passa inosservatu da i participanti.
Questu significa chì Unified CM deve cunfigurà e credenziali API è l'indirizzu WebAdmin / portu di u serviziu, è ancu u SIP Trunk direttamente à u servitore CMS per cuntinuà a chjama.
In casu di necessariu, CUCM pò creà dinamicamente un spaziu in u CMS per chì ogni chjama pò ghjunghje à u CMS è currisponde à a regula di a chjama entrante chì hè destinata à i spazii.
Integrazione cù CUCM cunfiguratu in u listessu modu cum'è discrittu in l'articulu eccettu chì in Cisco UCM avete bisognu di creà trè trunks per u CMS, trè Ponti di Conferenza, in u Profilu di Sicurezza SIP specificate trè Nomi di Sughjetti, Gruppi di Route, Liste di Route, Gruppi di Risorse Media è Listi di Gruppi di Risorse Media, è aghjunghje uni pochi di reguli di routing. à u Cisco Meeting Server.
Profilu di Sicurezza SIP:
Trunchi:
Ogni troncu pare u listessu:
Ponte di cunferenza
Ogni ponte di cunferenza hè u listessu:
Gruppu Route
Lista di i percorsi
Gruppu di Risorse Media
Lista di Gruppi di Risorse Media
Call Rules
A cuntrariu di i sistemi di gestione di chjamate più avanzati cum'è Unified CM o Expressway, CMS cerca solu u duminiu in u campu SIP Request-URI per i novi chjamati. Allora se SIP INVITE hè per sip: [email prutettu]U CMS si preoccupa solu di domain.com. CMS segue queste regule per determinà induve indirizzà una chjama:
1. U CMS prima prova à currisponde à u duminiu SIP cù i duminii cunfigurati in e regule di chjama in entrata. Queste chjamate ponu esse dirette à spazi ("targeted") o utilizatori specifichi, IVR interni, o destinazioni integrate direttamente Microsoft Lync / Skype for Business (S4B).
2. Se ùn ci hè micca un match in i reguli di chjama in entrata, CMS pruvarà à currisponde à u duminiu cunfiguratu in a tavola di rinviu di chjama. Se una partita hè fatta, a regula pò esplicitamente rifiutà a chjama o trasmette a chjama. À questu tempu, u CMS pò riscrive u duminiu, chì hè qualchì volta utile per chjamà i domini Lync. Pudete ancu sceglie di passà scaccià, chì significa chì nimu di i campi serà più mudificatu, o utilizate un pianu di dial CMS internu. Se ùn ci hè micca un match in e regule di rinviu di chjama, u predeterminatu hè di ricusà a chjama. Tenite in mente chì in u CMS, ancu s'è a chjama hè "inviata", i media hè sempre ligatu à u CMS, chì significa chì serà in a strada di signalazione è trafficu media.
Allora solu i chjami trasmessi sò sottumessi à e regule di e chjama in uscita. Queste paràmetri determinanu e destinazioni induve e chjamate sò mandate, u tipu di troncu (sia una nova chjamata Lync o una chjama SIP standard), è qualsiasi cunversione chì pò esse realizatu se u trasferimentu ùn hè micca sceltu in a regula di rinviu di chjama.
Eccu u logu attuale di ciò chì succede durante una cunferenza Ad-Hoc
A screenshot mostra male (ùn sò micca sapè cumu fà megliu), dunque scriveraghju u logu cusì:
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:12A cunferenza Ad-Hoc stessu:
Reguli di chjama in entrata
A cunfigurazione di i paràmetri di e chjama in entrata hè necessariu per pudè riceve una chjama in u CMS. Comu avete vistu in a cunfigurazione LDAP, tutti l'utilizatori sò stati impurtati cù u duminiu conf.pod6.cms.lab. Allora à u minimu, vulete chjamate à stu duminiu per spazii di destinazione. Avete ancu bisognu di stabilisce e regule per tuttu ciò chì hè destinatu à u nome di duminiu cumplettamente qualificatu (è forsi ancu l'indirizzu IP) di ognunu di i servitori CMS. U nostru cuntrollu di chjama esterna, Unified CM, cunfigurà trunk SIP dedicati à ognunu di i servitori CMS individualmente. Sicondu s'ellu u destinazione di sti trunks SIP hè un indirizzu IP o u FQDN di u servitore determinarà se u CMS deve esse cunfiguratu per accettà chjamati diretti à u so indirizzu IP o FQDN.
U duminiu chì hà a regula di entrata di priorità più alta hè utilizatu cum'è u duminiu per qualsiasi spazii d'utilizatori. Quandu l'utilizatori sincronizzanu via LDAP, u CMS crea automaticamente spazii, ma solu a parte di l'utilizatori di l'URI (coSpaceUriMapping), per esempiu, user.space. Part L'URI sanu hè generatu basatu annantu à sta regula. In fatti, sè vo site à accede à Web Bridge à questu puntu, vi vede chì l'URI Space ùn hà micca un duminiu. Per stabilisce sta regula cum'è a più alta priorità, site u duminiu per i spazii generati per esse cunf.esempiu.com.
Regoli di chjama in uscita
Per permette à l'utilizatori di fà chjamate in uscita à u cluster Unified CM, deve cunfigurà e regule in uscita. U duminiu di endpoints registrati cù Unified CM, cum'è Jabber, hè example.com. E chjama à stu duminiu duveranu esse dirette cum'è chjama SIP standard à i nodi di trasfurmazioni di chjamate Unified CM. U servitore principale hè cucm-01.example.com, è l'altru hè cucm-02.example.com.
A prima regula descrive u routing più simplice di chjamate trà i servitori di cluster.
chjosu Locale da u duminiu hè rispunsevuli di ciò chì serà affissatu in u SIP-URI di u chjamante per a persona chjamata dopu à u simbulu "@". S'è l'avemu lasciatu viotu, dopu à u simbulu "@" ci serà l'indirizzu IP di u CUCM per quale passa sta chjama. Sè avemu specificatu un duminiu, dopu dopu à u simbulu "@" ci sarà veramente un duminiu. Questu hè necessariu per pudè chjamà, altrimenti ùn serà micca pussibule di chjamà via SIP-URI name@ip-address.
Chjama quandu hè specificatu Locale da u duminiu
Chjamate quandu Micca indicatu Locale da u duminiu
Assicuratevi di specificà esplicitamente Encrypted o Unencrypted per e chjama in uscita, perchè nunda ùn funziona cù u paràmetru Auto.
Ti Vurria
E cunferenze video sò registrate da u servitore Record. Recorder hè esattamente u listessu cum'è Cisco Meeting Server. Recorder ùn hà micca bisognu di l'installazione di alcuna licenza. Licenze di registrazione sò richieste per i servitori chì eseguenu servizii CallBridge, i.e. una licenza di registrazione hè necessaria è deve esse appiicata à u cumpunente CallBridge, è micca à u servitore chì esegue Recorder. U registratore si cumporta cum'è un clientu XMPP (Extensible Messaging and Presence Protocol), cusì u servitore XMPP deve esse attivatu in u servitore chì ospita CallBridge.
Perchè Avemu un cluster è a licenza deve esse "allungata" in tutti i trè servitori in u cluster. Allora simpricimenti in u vostru contu persunale in e licenze chì avemu assuciatu (aghjunghje) l'indirizzi MAC di l'a-interfaces di tutti i servitori CMS inclusi in u cluster.
È questu hè a stampa chì deve esse in ogni servitore in u cluster
In generale, ci sò parechje scenarii per mette u Recorder, ma ci fermamu à questu:
Prima di stallà u Recorder, avete bisognu di preparà un locu induve e videoconferenze seranu veramente arregistrate. In fatti quì , quantu à stallà tutti i Recording. Mi fucalizza nantu à punti impurtanti è dettagli:
1. Hè megliu slip u certificatu da u primu servitore in u cluster.
2. L'errore "Recorder unavailable" pò accade perchè u certificatu sbagliatu hè specificatu in u Recorder Trust.
3. A scrittura ùn pò micca travaglià se u repertoriu NFS specificatu per a registrazione ùn hè micca u cartulare radicali.
A volte ci hè bisognu di registrà automaticamente una cunferenza di un utilizatore o spaziu specificu.
Per questu, sò creati dui CallProfiles:
Cù a registrazione disattivata
È cù a funzione di registrazione automatica
In seguitu, "attachemu" un CallProfile cù una funzione di registrazione automatica à u spaziu necessariu.
In CMS hè cusì stabilitu chì se un CallProfile hè esplicitamente ligatu à qualsiasi spaziu o spaziu, allora questu CallProfile funziona solu in relazione à questi spazii specifichi. È se u CallProfile ùn hè micca ligatu à alcunu spaziu, da u predeterminatu hè appiicatu à quelli spazii à quale nisun CallProfile hè esplicitamente ligatu.
A prossima volta pruvaraghju à descriverà cumu si accede à u CMS fora di a reta interna di l'urganizazione.
Sources:
Source: www.habr.com