Cisco Meeting Server 2.5.2. Klastri Scalable and Resilient režiimis koos videokonverentside salvestamise funktsiooniga

Selles väljaandes näitan ja selgitab mõningaid CMS serveri konfigureerimise nüansse talitluspidevuse klasterrežiimis.


TeooriaTegelikult on olemas kolm tüüpi CMS serveri juurutamist:

• Single Combined(Üks kombineeritud), st see on üks server, kus on käivitatud kõik vajalikud teenused. Enamasti on see juurutustüüp rakendatav ainult sisemiste klientide juurdepääsuks ja väikestes keskkondades, kus ühe serveri skaleerimise ja ülemineku piirangud ei ole kriitilised, või olukordades, kus CMS täidab ainult teatud funktsioone, nagu spetsiaalsed konverentsid Cisco UCM-il.

  Umbes töö scheem:
  

• Single Split(Üks jagatud) laiendab eelnevat juurutustüüpi, lisades eraldi serveri välisjuurdepääsuks. Ajaloolistes juurutustes tähendas see CMS serveri juurutamist demilitariseeritud tsoonis (DMZ), kus väliskliendid saavad sellele ligi, ja ühte CMS serverit võrgus, kus saavad CMS-ile juurdepääsu sisemised kliendid. See konkreetne juurutusmudel on nüüd asendatud nn tüübiga Single Edge, mis koosneb serveritest Cisco Expressway, millel on või tulevad olema paljud tulemüürivältimise võimalused, seega ei pea klientidel lisama eraldi CMS piiri serverit.

  Umbes töö scheem:
  

• Scalable and Resilient(Skaaleeritav ja talitluspidev) see tüüp hõlmab üleliigsust igas komponendis, mis võimaldab süsteemil kasvada teie vajadustega kuni maksimaalse mahuni, tagades samas liialdamise tõrke korral. See kasutab ka Single Edge kontseptsiooni turvalise välisjuurdepääsu tagamiseks. See on tüüp, mida me selles väljaandes käsitleme. Kui me mõistame, kuidas juurutada sellist tüüpi klastreid, saame aru ka teistest juurutustüüpidest ning suudame mõista, kuidas luua CMS serverite klastreid, arvestades potentsiaalset kasvu vajadustes.

Enne juurutamise juurde asumist on vaja mõista mõningaid põhiasju, nimelt

CMS põhikomponendid:

• Database: võimaldab ühendada mõningaid konfiguratsioone, nagu tellijate grupid, kasutajate ruumid ja kasutajad ise. Toetab klasterdamist ainult kõrge kättesaadavuse jaoks (üks meister).
• Call Bridge: teenus audio- ja videokonverentside jaoks, mis tagab täieliku kontrolli kõnede ja meedia töötlemise üle. Toetab klasterdamist kõrge kättesaadavuse ja skaleeritavuse tagamiseks.
• XMPP server: vastutab klientide registreerimise ja autentimise eest, kes kasutavad rakendust Cisco Meeting Application ja/või WebRTC (reaalaegne kommunikatsioon, või lihtsalt veebilehitsejas), samuti komponentidevaheline signalisatsioon. Saab klasterdada ainult kõrge kättesaadavuse tagamiseks.
• Web Bridge: annab klientidele ligipääsu WebRTC-le.
• Loadbalancer: tagab üheühenduspunkti Cisco Meeting App rakendustele ühes Split režiimis. Jälgib välist liidest ja porti sisendühenduste jaoks. Ühtlaselt jagab koormuse tasakaalustaja sissetulevaid TLS-ühendusi XMPP serverist, mille kaudu ta saab suunata TCP-ühendusi välistest klientidest.
  Meie stsenaariumis ei ole see vajalik.
• TURN server: tagab tulemüüri ümber mineku tehnoloogia, mis võimaldab
  paigutada meie CMS-i tulemüürile või NAT-i taha, et ühendada väliseid kliente, kes kasutavad Cisco Meeting App või SIP seadmeid. Meie stsenaariumis ei ole see vajalik.
• Web Admin: haldusteenus ja juurdepääs API-le, sealhulgas spetsiaalsetele konverentsidele Unified CM.

Konfigureerimisrežiimid

Erinevalt enamikest teistest Cisco toodetest toetab Cisco Meeting Server kolme seadistamismeetodit, mis võimaldavad rakendada igasuguseid juurutusi.

• Käsurealiidese (CLI): Käsurealiides, tuntud kui MMP, esialgsete seadistuste ja sertifikaatide jaoks.
• Veebihaldur: eelkõige CallBridge'i seondumisega seotud seadistuste jaoks, eriti ühe klasterdatud serveri seadistamisel.
• REST API: kasutatakse kõige keerulisemate seadistusülesannete jaoks ja klusterdatud andmebaasiga seotud ülesannete jaoks.

Lisaks eeltoodule kasutatakse protokolli SFTP failide edastamiseks — tavaliselt litsentside, sertifikaatide või logide edastamiseks CMS serverisse ja sealt välja.

Cisco juurutusjuhistes on selgelt öeldud, et klaster tuleb juurutada vähemalt kolmest serverist (node'ist) andmebaasi kontekstis. Kuna ainult paaritu arvu sõlmedega töötab uue andmebaasi peamise valimise mehhanism ja peamine andmebaasi seos on suurema osa CMS serveri andmebaasiga.

Kuna praktika näitab, et kahe serveri (node) olemasolu ei ole tõepoolest piisav. Valikumehhanism töötab Masteri taaskäivitamisel, Slave server muutub Masteriks ainult pärast taaskäitatud serveri üles tõstmist. Kui kahe serveriga klastris Master server mingil põhjusel "lülitub välja", ei muutu Slave server Masteriks, aga kui Slave "lülitub välja", muutub alles jäänud Master server samuti Slave’iks.

XMPP kontekstis on tõepoolest vaja luua klaster kolmest serverist, sest kui näiteks keelata XMPP teenus ühel serveritest, mille XMMP seisund on Leader, jääb alles jäänud serveris XMPP seisundisse Follower ning CallBridge'i ühendused XMPP-ga katkeb, kuna CallBridge ühendub ainult XMPP-ga seisundis Leader. See on kriitiline, sest ükski kõne ei toimu.

Neid samu juurutusjuhiseid järgides demonstreeritakse ühte XMPP serverit sisaldavat klastri näidet.

Arvestades eeltoodut, on selge, miks see töötab: see toimib failover režiimis.

Meie puhul on XMPP server kõikides kolmes node'is.

Eeldatakse, et kõik kolm meie serverit on üles tõstetud.

DNS kirjed

Enne serverite seadistamisele asumist tuleb luua DNS kirjed A ja SRV tüübid:

Pange tähele, et meie DNS kirjade hulgas on kaks domeeni example.com ja conf.example.com. Example.com on domeen, mida saavad kasutada kõik Cisco Unified Communication Manageri abonendid, mis tõenäoliselt teie infrastruktuuris olemas on või ilmselt saab olema. Või domeen example.com vastab samale domeenile, mida kasutajad kasutavad oma e-posti aadressides. Või võib teie sülearvuti Jabber klient olla URI user@example.com. Domeen conf.example.com on see domeen, mis konfigureeritakse Cisco Meeting Serveri kasutajatele. Cisco Meeting Serveri domeen on conf.example.com, seega peab sama Jabber kasutaja Cisco Meeting Serverisse sisselogimiseks kasutama URI user@conf.example.com.

Põhikonfiguratsioon

Kõik allpool kirjeldatud seadistused on näidatud ühel serveril, kuid need tuleb teostada igas serveris klastri sees.

QoS

Kuna CMS genereerib reaalajas Viivitustundlik ja paketikaotuse suhtes tundlik liiklus, enamikul juhtudel soovitatakse konfigureerida teenuse kvaliteet (QoS). Selleks toetab CMS teenuste diferentseerimise koodide (DSCP) pakettide märgistamist, mida see genereerib. Kuigi liikluse prioriteet DSCP alusel sõltub sellest, kuidas teie infrastruktuuri võrgu komponendid liiklust töötlevad, seadistame meie CMS-i tavapäraste QoS parimate praktikate põhjal tüüpilise DSCP prioriteedi jaotuse.

Igal serveril sisestame järgmised käsklused

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

Seega, kogu videotrafik on märgistatud AF41 (DSCP 0x22), kogu hääl liiklus on märgistatud EF (DSCP 0x2E), muud madala latentsusega liikluse vormid, nagu SIP ja XMPP, kasutavad AF31 (DSCP 0x1A).

Kontrollime:

NTP

Aegade võrgu protokoll (NTP) ei ole oluline mitte ainult täpsete ajamärkide tagamiseks kõnede ja konverentside jaoks, vaid ka sertifikaatide kontrollimiseks.

Lisame NTP serverid teie infrastruktuuri järgmise tüüpi käsuga

ntp server add

Meie juhul on selliseid servereid kaks, seega on käske ka kaks.
Kontrollime:

Ja seadistame meie serveri ajavööndi

DNS

DNS serverid lisame CMS-is järgmise tüüpi käsuga:

dns add forwardzone

Meie juhul on selliseid servereid kaks, seega on käske ka kaks.
Kontrollime:

Võrgu liidese konfiguratsioon

Seadistame liidese järgmise tüüpi käsuga:

ipv4  add 
 /

Kontrollime:

Serveri nimi (Hostname)

Seadistame serveri nime järgmise tüüpi käsuga:

hostname

Ja taaskäivitame.


Sellega on põhiline konfiguratsioon lõpetatud.

Sertifikaadid

TeooriaCisco Meeting Server nõuab erinevate komponentide vahel krüpteeritud suhtlust, ja seetõttu on X.509 sertifikaadid vajalikud kõigi CMS-i juurutuste jaoks. Need aitavad tagada usaldusväärsuse teenuste/serveri ja teiste serverite/teenuste vahel.

Iga teenuse jaoks on vajalik sertifikaat, kuid iga teenuse jaoks eraldi sertifikaatide loomine võib põhjustada segadust ja liigset keerukust. Õnneks saame genereerida avatud ja privaatse võtme sertifikaadi paari ning seejärel neid mitu korda kasutada erinevates teenustes. Meie juhul kasutatakse sama sertifikaati Call Bridge'i, XMPP serveri, Web Bridge'i ja Web Admini jaoks. Seega tuleb igale klastris olevale serverile luua avatud ja privaatse võtme sertifikaadi paar.

Andmebaasi klasterdamine omab siiski mõningaid erilisi nõudeid sertifikaatidele ja seetõttu vajab see omaenda sertifikaate, mis erinevad teiste teenuste sertifikaatidest. CMS kasutab serveri sertifikaati, mis sarnaneb teiste serverite kasutatavatele sertifikaatidele, kuid seal on ka kliendi sertifikaat, mida kasutatakse andmebaasiga ühenduste jaoks. Andmebaasi sertifikaate kasutatakse nii autentimiseks kui ka krüpteerimiseks. Kliendi andmebaasi ühendamiseks ei esita ta kasutajanime ja parooli, vaid esitab kliendi sertifikaadi, millele server usaldab. Igal andmebaasi klastris asuval serveril on sama avaliku ja privaatse võtme paar. See võimaldab kõikidel klastris asuvatel serveritel andmeid krüpteerida selliselt, et neid saab dekodeerida ainult teised serverid, mis kasutavad samuti sama võtme paari.

Tõhusaks varundamiseks peavad andmebaasi klastrid koosnema vähemalt 3 serverist, kuid mitte rohkem kui 5, maksimaalse signaalikestvusega mõlemas suunas 200 ms igas klastriliikmes. See piirmäär on rangem kui Call Bridge klasterdamisel, seega on see sageli piiravaks teguriks geograafiliselt jaotatud rakendustes.

CMS andmebaasi rollil on mitmeid unikaalseid nõudeid. Erinevalt teistest rollidest vajab see kliendi ja serveri sertifikaati, kus kliendi sertifikaadil on kindel CN välja, mis esitatakse serverile.

CMS kasutab Postgres andmebaasi, millel on üks peamine ja mitu täiesti identset koopia. Igal ajahetkel on olemas ainult üks peamine andmebaas („andmebaasiserver”). Ülejäänud klastriliikmed on koopiad või „andmebaasi kliendid.”

Andmebaasi klastriks on vajalikdedikeeritud serveri ja kliendi sertifikaadid. Need peavad olema allkirjastatud tavaliselt sisemiste erakasutussertifitseerimiskeskustega. Kuna mis tahes andmebaasi klastriliikmest võib saada peamine, peavad andmebaasi serveri ja kliendi sertifikaatide paarid (mis hõlmavad avalikke ja privaatseid võtmeid) olema kopeeritud kõikidele serveritele, et nad saaksid aktsepteerida andmebaasi kliendi või serveri identiteeti. Lisaks tuleb laadida CA juuresoleksertifikaat, et tagada kliendi ja serveri sertifikaatide kontrollitavus.

Nii, koostame sertifikaadi taotluse, mida kasutavad kõik serveriteenused, välja arvatud andmebaas (selle jaoks on eraldi taotlus), käsuga:

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

CN-is kirjutame meie serverite üldnimetuse. Näiteks, kui meie serverite hostname'id on server01, server02, server03, siis CN on server.example.com

Teeme sama ülejäänud kahel serveril, erandiga, et käskudes on vastavad ‘hostname’id’

Koostame kaks sertifikaadi taotlust, mida kasutab andmebaasi teenus käskudega:

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

pki csr dbclusterclient CN:postgres

kus dbclusterserver ja dbclusterclient meie taotluste ja tulevaste sertifikaatide nimed, hostname1(2)(3) vastavad serverite nimed.

Seda protseduuri teeme ainult ühel serveril(!), ning laeme sertifikaadid ja vastavad .key-failid üles teistesse serveritesse.

Kliendi sertifikaadi režiimi sisselülitamine AD CS-is

Samuti tuleb kõik serverite sertifikaadid kokku ühendada ühte failiLinuxis:

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

Windowsis/DOS-is:

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

Ja laadige iga serveri peale:
1. „Isiklik“ serveri sertifikaat.
2. Juuresoleksertifikaat (koos vahe-sertifikaatidega, kui need on olemas).
3. Andmebaasi sertifikaadid („serveri“ ja „kliendi“) ning failid, millel on laiend .key, mis loodi „serveri“ ja „kliendi“ sertifikaadi taotluse loomisel. Need failid peavad olema kõigil serveritel samad.
4. Kolme „isikliku“ sertifikaadi fail.

Lõpptulemusena peaks iga serveri failistruktuur välja nägema umbes selline.

Andmebaasi klaster

Nüüd, kui kõik sertifikaadid on CMS-serveritesse üles laaditud, saab seadistada ja aktiveerida andmebaasi klasterdamise kolme sõlme vahel. Esimene samm on valida üks server andmebaasi klastrite peamiseks sõlmeks ja selle täielik seadistamine.

Peamine andmebaas

Esimene samm andmebaasi replikatsiooni seadistamisel on määrata sertifikaadid, mida kasutatakse andmebaasi jaoks. See toimub järgmise käsu abil:

database cluster certs

Nüüd määrame CMS-ile, millist liidest kasutada andmebaasi klasterdamiseks käsuga:

database cluster localnode a

Seejärel initsialiseerime klastrite andmebaasi pealserveris käsuga:

database cluster initialize

Kliendi andmebaasi sõlmed

Teeme sama protseduuri, ainult selle asemel, et käivitada käsku database cluster initialize sisestame käsu vormis:

database cluster join

kus ip address existing master on CMS-serveri IP-aadress, kus klaster initsialiseeriti, lihtsalt Master.

Kontrollime, kuidas meie andmebaasi klaster kõigis serverites töötab käsuga:

database cluster status

Teeme sama ka kolmandal serveril.

Lõpuks selgub, et meie esimene server on Master, ülejäänud slaavid.

Veebihaldusteenus

Lülitame sisse veebihalduri teenuse:

webadmin listen a 445

Port 445 on valitud, kuna port 443 on kasutusel kasutajate juurdepääsuks veebikliendile.

Seadistame veebihalduri teenuse sertifikaatide failidega käsuga:

webadmin certs

Ja aktiveerime veebihalduri käsuga:

webadmin enable

Kui kõik on korras, saame rida SUCCESS, kus on näidatud, et veebihaldur on õigesti seadistatud võrgu ja sertifikaadi jaoks. Kontrollime teenuse tööd veebibrauseri kaudu, sisestades veebihalduri aadressi, näiteks: cms.example.com:445

Call Bridge klaster

Call Bridge on ainus teenus, mis on iga CMS-iga juurutatud. Call Bridge on peamine konverentsside vahend. See pakub ka SIP-liidese, et kõnesid saaks suunata temasse või temast välja, näiteks Cisco Unified CM-iga.

Allpool toodud käsud tuleb täita igas serveris vastavate sertifikaatidega.
Nii:

Seome sertifikaadid Call Bridge teenusega käsuga:

callbridge certs  []

Seome CallBridge teenused soovitud liidesega käsuga:

callbridge listen a

Ja taaskäivitame teenuse käsuga:

callbridge restart

Nüüd, kui meil on seadistatud Call Bridge'id, saame seadistada Call Bridge'i klasterdamise. Call Bridge'i klasterdamine erineb andmebaasi või XMPP klasterdamisest. Call Bridge'i klaster võib toetada 2 kuni 8 sõlme ilma piiranguteta. See tagab mitte ainult üleliigsuse, vaid ka koormuse jaotamise, mille tõttu saavad konverentsid aktiivselt jaguneda Call Bridge'i serverite vahel nutika kõnede jaotamise kaudu. CMS-il on lisafunktsioonid, Call Bridge'i rühmad ja nendega seotud funktsioonid, mida saab kasutada edasiseks haldamiseks.

Call Bridge'i klasterdamine seadistatakse peamiselt veebihalduri liidese kaudu.
Allpool kirjeldatud protseduur tuleb teostada igas klastriseervere.
Nii,

1. Logi sisse veebis aadressil Configuration > Cluster.
2. Valige Call Bridge'i identiteet ainulaadse nime jaoks sisestage callbridge[01,02,03], mis vastab serveri nimele. Need nimed on suvalised, kuid peavad olema klastris unikaalsed. Need on kirjeldavad, kuna need viitavad sellele, et need on serveri identifikaatorid [01,02,03].
3. Väljas Klastritud Call Bridges sisestage meie klastris asuvate serverite veebihalduri URL-id, cms[01,02,03].example.com:445, väljale Aadress. Veenduge, et port oleks määratud. Võite jätta Peer link SIP domeeni tühjaks.
4. Lisage iga serveri CallBridge'ile usaldusväärne sertifikaat, fail, mis sisaldab kõiki meie serverite sertifikaate, mille me selle faili alguses koos selle käsuga voolitud olime:

callbridge trust cluster

Ja taaskäivitame teenuse käsuga:

callbridge restart

Kokkuvõttes peaks igas serveris olema selline pilt:

XMPP klaster

CMS-i XMPP teenust kasutatakse kõigi registreerimise ja autentimise töötlemiseks Cisco Meeting Apps (CMA) jaoks, sealhulgas CMA WebRTC veebiklient. Call Bridge toimib ka XMPP kliendina autentimise eesmärkidel ja seetõttu tuleb see seadistada nagu teised kliendid. XMPP leidlikkuse funktsioon toetatakse tootmiskeskkondades alates versioonist 2.1.

Allpool toodud käsud tuleb täita igas serveris vastavate sertifikaatidega.
Nii:

Seome sertifikaadid XMPP teenusega käsuga:

xmpp certs  []

Seejärel määrake kuulamisliides käsuga:

xmpp listen a

XMPP teenus vajab unikaalset domeeni. See on login kasutajatele. Teisisõnu, kui kasutaja proovib rakendusega CMA (või läbi WebRTC kliendi) sisse logida, sisestab ta userID@logindomain. Meie puhul on see userid@conf.example.com. Miks see ei ole lihtsalt example.com? Meie konkreetsetes seadistustes valisime oma domeeni Unified CM, mida Jabberi kasutajad kasutavad Unified CM-is nagu example.com, seetõttu vajame CMS-i kasutajatele teist domeeni, et suunata kõnesid CMS-i ja CMS-ist läbi SIP domeenide.

Seadistage XMPP domeen käsu abil:

xmpp domain

Ja aktiveerime XMPP teenuse käsuga:

xmpp enable

XMPP teenuses tuleb iga Call Bridge'i jaoks luua mandaadid, mida kasutatakse XMPP teenuses registreerimiseks. Need nimed on juhuslikud (ja ei ole seotud ainulaadsete nimedega, mille olete seadistanud kõnesildade klasterdamiseks). Ühel XMPP serveril tuleb lisada kolm kõnesilda, ning seejärel sisestada need mandaadid teistesse XMPP serveritesse klusters, kuna see konfiguratsioon ei mahuta klusterandmebaasi. Hiljem seadistame iga Call Bridge'i selle nime ja salajase sõna kasutamiseks XMPP teenuses registreerimiseks.

Nüüd peame seadistama XMPP teenuse esimesel serveril kolme Call Bridge'iga callbridge01, callbridge02 ja callbridge03. Iga kontole antakse juhuslikud paroolid. Hiljem sisestatakse need teistes Call Bridge serverites selle XMPP serveri sisselogimiseks. Sisestame järgmised käsud:

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

Lõpuks kontrollime, mis välja tuli, käsuga:

xmpp callbridge list

Sama pilt peaks olema ka teistes serverites pärast allpool kirjeldatud toimingute tegemist.

Seejärel lisame jäänud kahele serverile täpselt samad seadistused, ainult käsud:

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

Salajase sõna lisame väga ettevaatlikult, et sinna kogemata näiteks liigseid tühikuid ei satuks.


Lõpuks peaks igal serveril olema sama pilt:

Edasi määrame kõigis klusteri serverites usaldusfaili, mis sisaldab kõiki kolme varem loodud sertifikaati, käsuga:

xmpp cluster trust

Lülitame XMPP klusteri režiimi sisse kõigis klusteri serverites käsuga:

xmpp cluster enable

Alguses serveris klastris käivitame xmpp klastrite loomise käsu:

xmpp cluster initialize

Teistes serverites lisame xmpp klastrisse järgmise vorminguga käsuga:

xmpp cluster join

Kontrollime igas serveris XMPP klastrite loomise edukust järgmiste käskudega:

xmpp status
xmpp cluster status

Esimene server:

Teine server:

Kolmas server:

Call Bridge'i ühendamine XMPP-ga

Nüüd, kui XMPP klaster on käivitatud, tuleb seadistada Call Bridge'i teenused, et nad saaksid XMPP klastriga ühenduda. See konfiguratsioon tehakse veebihalduri kaudu.

Logime igas serveris sisse Configuration > General ja väljal Unique Call Bridge name sisestame serveriga seotud unikaalsed Call Bridge'i nimed callbridge[01,02,03]. Väljal Domeen conf.example.ru ja vastavad paroolid, mida saab vaadata
igast klastriserverist järgmise käsuga:

xmpp callbridge list

Väli 'Server' jääb tühjaks, Callbridge otsib DNS SRV-d _xmpp-component._tcp.conf.example.com, et leida saadaval XMPP server. Callbridge'i ühendus IP-aadressid võivad igas serveris erineda, see sõltub, millised väärtused saadakse DNS kirje pärimisele. _xmpp-component._tcp.conf.example.com Callbridge'i tulemused sõltuvad samuti antud DNS kirje prioriteetide seadetest.

Seejärel läheme jaosse Status > General, et veenduda, et Call Bridge'i teenus on edukalt ühendatud XMPP teenusega.

Web Bridge

Igas klastriserveris lülitame Web Bridge'i teenuse sisse käsuga:

webbridge listen a:443

Seadistame Web Bridge teenuse sertifikaatide failidega järgmise vorminguga käsu:

webbridge certs

Web Bridge toetab HTTPS-i. See suunab HTTP automaatselt HTTPS-ile, kui on seadistatud 'http-redirect' kasutamiseks.
HTTP ümbersuunamise lubamiseks kasutage järgmist käsku:

webbridge http-redirect enable

Et Call Bridge saaks teada, et Web Bridge usaldab Call Bridge'i ühendusi, kasutage käsku:

webbridge trust

kus see on fail, mis sisaldab kõiki kolme sertifikaati igast klastriserverist.

Selline pilt peaks olema igas klastriserveris.


Nüüd peame looma kasutaja 'appadmin' rolliga, seda on meil vaja, et saaksime seadistada meie klastrit (!), mitte iga klastriserverit eraldi, nii et seadistused rakenduvad ühtlaselt igas serveris, kuigi need tehakse vaid üks kord.


Edasihekse seadistamiseks kasutame Postman.

Autentimiseks valime Basic jaotises Autorization

CMS-serveritele käskude õigeks saatmiseks tuleb seadistada õige kodeering

Määra Webbridge'ide jaoks käsuga POST parameetriga url ja väärtusega cms.example.com



Igal webbridge'il peab olema vajalikud parameetrid: külalisjuurdepääs, kaitstud juurdepääs jne.

Call Bridge Groups

Vaikimisi ei kasuta CMS alati oma konverentsikõnede ressursse maksimaalselt tõhusalt.

Näiteks kolme osalejaga kohtumise puhul võivad kõik osalejad viibida kolmes erinevas Call Bridge'is. Selleks, et need kolm osalejat saaksid omavahel suhelda, loob Call Bridge'id automaatselt ühendused kõigi serverite ja klientide vahel samas Space'is, et kõik kliendid näeksid välja nagu nad oleksid ühel ja samal serveril. Kahjuks on selle puudus see, et üks 3-inimese konverents tarbib nüüd 9 meediaporti. See pole kahtlemata ressursikasutuse poolest efektiivne. Lisaks, kui Call Bridge on tõeliselt üle koormatud, on vaikimisi mehhanismiks telefonikõnede vastuvõtmise jätkamine ja teenuste osutamine madalama kvaliteediga kõigile selle Call Bridge'i osalejatele.

Need probleemid lahendatakse Call Bridge Group'i funktsiooniga. See funktsioon tutvustati Cisco Meeting Serveri 2.1 versioonis ja seda on laiendatud koormuse tasakaalustamise toe osutamiseks nii sissetulevatele kui väljaminevatele kõnedele, sealhulgas WebRTC osalejatele.

Ühenduvuse probleemide lahendamiseks on iga Call Bridge'i jaoks seatud kolm kohandatavat koormuse piirangut:

LoadLimit on maksimaalne numbriline koormus konkreetse Call Bridge'i jaoks. Igal platvormil on soovitatav koormuse piirang, näiteks 96000 CMS1000 jaoks ja 1.25 GHz virtuaalse protsessori kohta virtuaalmasinas. Erinevad kõned tarbivad erineva hulga ressursse osaleja resolutsioonist ja kaadrisagedusest sõltuvalt.
NewConferenceLoadLimitBasisPoints (vaikimisi 50% loadLimit) – määrab serveri koormuse piiri, mille järel uued konverentsid tagastatakse.
ExistingConferenceLoadLimitBasisPoints (vaikimisi 80% loadLimit’ist) – serveri koormuse väärtus, mille järel praegusesse konverentsi liituvad osalejad tagastatakse.

Kuigi see funktsioon on loodud kõnede ja koormuse jaotamiseks, võivad ka teised grupid, nagu TURN-serverid, Web Bridge'id ja salvestusseadmed, olla määratud Call Bridge Groups'ile, et neid saaks õigesti grupeerida optimaalsete ressursside kasutamiseks. Kui ükski neist objektidest ei ole kõnegrupile määratud, arvatakse, et nad on kõikidele serveritele kergesti juurdepääsetavad ilma eriliste prioriteetideta.

Need seaded on siin konfigureeritud: cms.example.com:445/api/v1/system/configuration/cluster

Seejärel määrame igale callbridge’ile, millisesse callbridge-gruppi see kuulub:

Esimene callbridge

Teine callbridge

Kolmas callbridge


Nii oleme seadnud Call Bridge'i rühma, et kasutada Cisco Meeting Server'i ressursse tõhusamalt.

Kasutajate importimine Active Directory'st

Web Admin teenusel on LDAP-i konfiguratsiooni osa, kuid see ei paku keerukaid konfiguratsiooni parameetreid ning teave ei salvestata klastrisse andmebaasi, seega tuleb konfigureerimine teha kas käsitsi iga serveri kaudu Web-liidese kaudu või API kaudu, ja et me 'kolm korda ei tõuseks', määrame andmed siiski API kaudu.

Kasutades URL- aadressi juurdepääsuks cms01.example.com:445/api/v1/ldapServers loome LDAP Server'i objekti, määrates sellised parameetrid nagu:

• Serveri IP-aadress
• pordi number
• kasutajanimi
• parool
• secure

Secure – true või false valime sõltuvalt portist, 389 – ei ole kaitstud, 636 – on kaitstud.


Kuvame LDAP allika parameetrid atribuutideks Cisco Meeting Server'is.
LDAP-i kaardistamine seob LDAP-i katalooge atribuudid CMS-i atribuutidega. Konkreetsed atribuudid:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Atribuutide kirjeldusJID esindab CMS-i kasutaja sisenemise identifikaatorit. Kuna see on Microsoft Active Directory LDAP-server, vastab CMS-i JID LDAP-is sAMAccountName'ile, mis on põhimõtteliselt Active Directory kasutaja sisenemise identifikaator. Samuti pidage meeles, et võtate sAMAccountName'i ja lisate lõppu domeeni conf.pod6.cms.lab, kuna see on sisselogimine, mida teie kasutajad CMS-i sisenemiseks kasutavad.

nameMapping seob selle, mis on Active Directory displayName väljal, CMS-i kasutaja nime väljal.

coSpaceNameMapping loomine CMS-i space'i nime põhjal displayName väljast. See atribuut koos coSpaceUriMapping atribuudiga on vajalik iga kasutaja space'i loomiseks.

coSpaceUriMapping määrab URI kasutaja osa, mis on seotud kasutaja isikliku space'iga. Mõned domeenid võivad olla seadistatud space'i kirjutamiseks. Kui kasutaja osa kattub selle välja väärtusega nende domeenide jaoks, suunatakse kõne sellele kasutajale mõeldud space'i.

coSpaceSecondaryUriMapping määrab teise URI, et jõuda space'ini. Seda saab kasutada numbrilise hüüdnime lisamiseks kõnede suunamiseks imporditud kasutaja space'i alternatiivina tähe-numbrilise URI, mis on määratud parameetris coSpaceUriMapping.

LDAP server ja LDAP vaste on seadistatud. Nüüd on vaja need omavahel siduda, luues LDAP allika.

Kasutades URL- aadressi juurdepääsuks cms01.example.com:445/api/v1/ldapSource loome LDAP Source objekti, määrates sellised parameetrid nagu:

• server
• mapping
• baseDn
• filter

Nüüd, kui LDAP seadistus on lõpetatud, saab teostada käsitsi süntsideerimise toimingu.

Teeme seda kas iga serveri veebiliideses, vajutades Sync now jaotises Active Directory


või API kaudu käsuga POST kasutades URL-i ligipääsuks cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc konverentsid

Mis see on?Traditsioonilises mõttes on konverents see, kui kaks osalist räägivad omavahel ja üks osalistest (kasutades Unified CM-s registreeritud seadet) vajutab nuppu „Konverents”, kutsub teise inimese ja pärast vestlust selle kolmanda osapoolega vajutab uuesti nuppu „Konverents”, et liituda kõigi kolmeosalise konverentsi osalistega.

Ad-Hoc konverents erineb CMS'i planeeritud konverentsist selles, et Ad-Hoc konverents ei ole lihtsalt SIP-kõne CMS-i jaoks. Kui konverentsi algataja vajutab nuppu „Konverents” teist korda, et kutsuda kõiki sama koosolekule, peab Unified CM kutsuma CMS-i API-d, et luua 'reisimisega' konverents, kuhu seejärel suunatakse kõik kõned. Kõik see toimub osalejate jaoks märkamatult.

See tähendab, et Unified CM peab seadistama API mandaadid ja WebAdmin teenuse aadressi / sadama, samuti SIP-Trunki otse CMS serverisse, et kõne saaks jätkuda.

Vajadusel saab CUCM dünaamiliselt luua CMS-i space'i, et iga kõne saaks CMS-i ja vastaks kõnede vastuvõtmise reeglile, mis on mõeldud space'ide jaoks.

Integratsioon CUCM-iga seadistatakse nagu on kirjeldatud artiklis artiklis v.a. Cisco UCM tuleb luua kolm trunki CMS-i jaoks, kolm Conference Bridge'i, SIP Security Profile'is tuleb määrata kolm Subject Name'i, Route Group, Route List, Media Resource Group ja Media Resource Group List, ning Cisco Meeting Serveris tuleb veidi lisada marsruutimise reegleid.

SIP Security Profile:


Trunkid:


Iga trunk näeb välja ühesugune:




Conference Bridge


Iga Conference Bridge näeb välja ühesugune:


Route Group


Route List


Media Resource Group


Media Resource Group List

Helistamisreeglid

Erinevalt keerukamatest helijuhtimissüsteemidest, nagu Unified CM või Expressway, vaatab CMS uusi kõnesid ainult SIP Request-URI valdkonnas. Juhul, kui SIP INVITE on mõeldud sip:user@domain.com, hoolitseb CMS ainult domain.com eest. CMS järgib neid reegleid, et määrata, kuhu kõne suunata:

1. Esiteks proovib CMS sobitada SIP domeeni sisenevate kõnede töötlemise reeglitega. Seejärel saab neid kõnesid suunata (“sihtkohtadesse”) aladesse või konkreetsetele kasutajatele, sisemisele IVR-ile või otse Microsoft Lynci/Skype for Business (S4B) integreeritud adressaatidele.
2. Kui sisenevate kõnede töötlemise reeglitega ei ole ühtegi vastet, proovib CMS sobitada domeeni, mis on seadistatud kõnede ülekande tabelis. Kui sobivus on loodud, võib reegel selgelt kõne tagasi lükata või suunata. Sellisel hetkel võib CMS domeeni ümber kirjutada, mis on mõnikord kasulik Lynci domeenide kõnede puhul. Võite valida ka pass throw, mis tähendab, et ühtegi välja ei muudetud või kasutada CMSi sisemist abonentgruppi. Kui kõnede ülekande reeglitega ei ole ühtegi vastet, kasutatakse vaikevalikuna kõne tagasi lükamist. Pange tähele, et CMS-is, kuigi kõne on „ülekantud“, on multimeedia endiselt seotud CMS-iga, mis tähendab, et see jääb signalisatsiooni ja multimeedia liikluse teele.
Sel juhul kehtivad kõneülekande reeglid ainult ülekantud kõnedele. Need valikud määravad adressaadid, kuhu kõned saata, ühendusliini tüübi (kas see on uus Lynci kõne või tavaline SIP) ja kõik muundamised, mis võivad toimuda, kui kõnede ülekande reeglites ei ole valitud ülekannet.

Siin on logi sellest, mis juhtub Ad-Hoc konverentsil

Kuvatõmmisel on see halb (ei tea, kuidas paremini teha), seega kirjutan logi nii:

Teave	127.0.0.1:35870: API kasutaja "api" lõi uue ruumi 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Teave	kõne loomine ebaõnnestus coSpace leidmisel -- proovib andmebaasist taastada

Teave	API "001036270012" Ruum GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Kõne GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Kõne Korrelaatori GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Sisemine G

Teave	127.0.0.1:35872: API kasutaja "api" lõi uue kõne 93bfb890-646c-4364-8795-9587bfdc55ba

Teave	kõne 7: sissetulev SIP kõne "sip:672@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Teave	API kõne tulemus bc0be45e-ce8f-411c-be04-594e0220c38e kõnes 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API kõne 93bfb890-646c-4364-8795-9587bfdc55ba)

Teave	konverents 434f88d0-8441-41e1-b6ee-6d1c63b5b098 kontrolli/meedia GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Teave	konverents 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nimi "001036270012"

Teave	kõne 7: konfigureeritud - API kõne tulemus bc0be45e-ce8f-411c-be04-594e0220c38e SIP kõne ID-ga "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Teave	kõne 7: seadistatakse UDT RTP seanss DTLS jaoks (kombineeritud meedia ja juhtimine)
Teave	konverents "001036270012": krüpteerimata kõne jalad on nüüd kohal

Teave	osaleja "672@172.x.x.x" liitus ruumiga 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Teave	osaleja "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) liitus konverentsiga 434f88d0-8441-41e1-b6ee-6d1c63b5b098 kaudu SIP

Teave	kõne 8: sissetulev SIP kõne "sip:690@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Teave	API kõne tulemus db61b242-1c6f-49bd-8339-091f62f5777a kõnes 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API kõne 93bfb890-646c-4364-8795-9587bfdc55ba)

Teave	kõne 8: konfigureeritud - API kõne tulemus db61b242-1c6f-49bd-8339-091f62f5777a SIP kõne ID-ga "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Teave	kõne 8: seadistatakse UDT RTP seanss DTLS jaoks (kombineeritud meedia ja juhtimine)

Teave	kõne 9: sissetulev SIP kõne "sip:673@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Teave	API kõne tulemus 37a6e86d-d457-47cf-be24-1dbe20ccf98a kõnes 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API kõne 93bfb890-646c-4364-8795-9587bfdc55ba)

Teave	kõne 9: konfigureeritud - API kõne tulemus 37a6e86d-d457-47cf-be24-1dbe20ccf98a SIP kõne ID-ga "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Teave	kõne 9: seadistatakse UDT RTP seanss DTLS jaoks (kombineeritud meedia ja juhtimine)
Teave	kõne 8: kompenseerib kaugpoolt, mis ei vasta koormustüüpidele

Teave	osaleja "690@172.x.x.x" liitus ruumiga 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Teave	osaleja "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) liitus konverentsiga 434f88d0-8441-41e1-b6ee-6d1c63b5b098 kaudu SIP

Teave	kõne 7: kompenseerib kaugpoolt, mis ei vasta koormustüüpidele
Teave	kõne 8: mitte vastavad koormustüüpide režiim 1\/0
Teave	kõne 8: vastab pakkumisele mitte vastavate koormustüüpide režiimis
Teave	kõne 8: järgnev ainukoodite pakkumine saanud
Teave	kõne 8: mitte vastavad koormustüüpide režiim 1\/0
Teave	kõne 8: vastab pakkumisele mitte vastavate koormustüüpide režiimis
Teave	kõne 8: saadab vastuse ainukoodite lisapakkumisele
Teave	kõne 9: kompenseerib kaugpoolt, mis ei vasta koormustüüpidele

Teave	osaleja "673@172.x.x.x" liitus ruumiga 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Teave	osaleja "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) liitus konverentsiga 434f88d0-8441-41e1-b6ee-6d1c63b5b098 kaudu SIP

Teave	kõne 9: BFCP (kliendi roll) on nüüd aktiivne
Teave	kõne 9: saadab BFCP tere kliendina, järgides tere saamist, kui BFCP ei olnud aktiivne
Teave	kõne 9: BFCP (kliendi roll) on nüüd aktiivne
Teave	kõne 7: lõpetamine; kaugne SIP katkestus - ühendatud 0:13
Teave	kõne 7: hävitatakse API kõne tulemus bc0be45e-ce8f-411c-be04-594e0220c38e

Teave	osaleja "672@x.x.x" lahkus ruumist 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Teave	kõne 9: ootel
Teave	kõne 9: mitte vastavad koormustüüpide režiim 1\/0
Teave	kõne 9: vastab pakkumisele mitte vastavate koormustüüpide režiimis
Teave	kõne 8: ootel
Teave	kõne 8: järgnev ainukoodite pakkumine saanud
Teave	kõne 8: mitte vastavad koormustüüpide režiim 1\/0
Teave	kõne 8: vastab pakkumisele mitte vastavate koormustüüpide režiimis
Teave	kõne 8: saadab vastuse ainukoodite lisapakkumisele
Teave	kõne 9: lõpetamine; kaugne SIP katkestus - ühendatud 0:12

Ad-Hoc konverentsi iseloomustus:


Sissetulevate kõnede reeglid
Sissetulevate kõnede parameetrite seadistamine on vajalik, et võimaldada kõnede vastuvõtmist CMS-is. Nagu nägite LDAP-i seadistuses, on kõik kasutajad imporditud domeeniga conf.pod6.cms.lab. Seetõttu tahate, et kõned, mis on suunatud sellele domeenile, oleksid määratud space'idele. Samuti peate seadma reeglid kõikide jaoks, mis on suunatud täielikule domeeninimele (ja võimalikult ka iga CMS-serveri IP-aadressile). Meie välises kõnede kontrollis, Unified CM-is, on SIP-põhimikud seadistatud iga CMS-serveri jaoks eraldi. Sõltuvalt sellest, kas nende SIP-põhimike määramine on IP-aadress või serveri täielik domeen, määrab see, kas CMS tuleb seadistada kõnede vastuvõtmiseks, mis on suunatud tema IP-aadressile või täielikule domeeninimele.

Domeen, millel on kõrgeima prioriteediga sissetuleva liikluse reegel, kasutatakse domeenina kõikide kasutajate space'ide jaoks. Kui kasutajad sünkroniseeruvad läbi LDAP-i, loob CMS automaatselt space'id, kuid ainult URI kasutajapoolse osa (coSpaceUriMapping), näiteks user.space. Osa domain täielikust URI-st luuakse selle reegli põhjal. Tegelikult, kui te siseneksite Web Bridge'i sellel hetkel, näeksite, et Space URI-l ei ole domeeni. Seades selle reegli kõrgeimaks prioriteediks, määrate domeeni loodud space'idele kui conf.example.com.


Väljundkõnede reeglid

Kasutajate väljundkõnede võimaldamiseks Unified CM klastrisse tuleb seadistada väljundühenduste reeglid. Unified CM-s registreeritud lõpp-punktide domeen, nagu Jabber, on example.com. Sellesse domeeni tehtavad kõned tuleks suunata nagu tavalised SIP-kõned Unified CM-i kõnekäsitluse sõlmedesse. Peamine server on cucm-01.example.com, lisaserverina cucm-02.example.com.

Esimene reegel kirjeldab lihtsaimat kõnede marsruutimist serverite vahel klastris.

Väli Kohalik domeen vastutab selle eest, mis kuvatakse helistaja SIP-URI-s sellel, kellele helistatakse pärast sümbolit „@“. Kui jätame selle tühjaks, siis on pärast sümbolit „@“ CUCM-i IP-aadress, mille kaudu kõne toimub. Kui määrame domeeni, siis on pärast sümbolit „@“ domeen. See on vajalik, et oleks võimalik tagasi helistada, vastasel juhul ei ole võimalik tagasi helistada SIP-URI nime@ip-aadress.

Kõne, kui määratud Kohalik domeen


Kõne, kui EI on märgitud Kohalik domeen


Oluline on selgelt märkida, kas väljakutsed on Encrypted või Unencrypted, sest parameetri Auto korral ei toimi midagi.

Salvestamine

Videokonverentside salvestamine toimub Record-serveri kaudu. Recorder on täpselt sama Cisco Meeting Server. Recorder ei nõua endale mingeid litsentse. Salvestamise litsentse vajavad serverid, kus on käivitatud CallBridge teenused, st Recording litsents on vajalik ja peab olema rakendatud CallBridge komponendile, mitte serverile, kus Recorder töötab. Recorder käitub nagu XMPP protokolli kliendi, seega peab XMPP server olema sisse lülitatud serveris, kus asub CallBridge.

Kuna meil on klaster ja litsents tuleb „venitada“ kõikidele kolmele klastri serverile. Lihtsalt seostame (lisame) kõigi CMS serverite A-liidesed MAC-aadressi isiklikus kabinetis litsentsides.

Ja selline pilt peaks olema igal klastriserveril

Tegelikult on Recorder'i paigutamiseks mitu stsenaariumi, kuid me järgime järgmist:


Enne Recorder'i seadistamist on vajalik ette valmistada koht, kuhu videokonverentsid salvestatakse. Just nii link, kuidas seadistada kogu Recording. Keskendun olulistele punktidele ja detailidele:

1. Sertifikaat on parem anda esimeselt serverilt klastris.
2. Viga „Recorder unavailable“ võib tekkida seetõttu, et Recorder Trust'is on ees vale sertifikaat.
3. Salvestamine ei pruugi toimuda, kui salvestamiseks on määratud mittejuurekataloog NFS-is.

Mõnikord on vajalik automaatselt salvestada ühe konkreetse kasutaja või ruumi konverents.

Selleks luuakse kaks CallProfile'i:
Salvestamise funktsiooniga maha lülitatud


Ja automaatse salvestamise funktsiooniga


Seejärel seostame vajaliku ruumi CallProfile'iga automaatse salvestamise funktsiooniga.


CMS-is on sellitud nii, et kui CallProfile on selgelt seotud teatavate ruumidega või ruumiga, siis töötab see CallProfile ainult nende konkreetsete ruumide jaoks. Kui CallProfile ei ole seotud ühegi ruumiga, rakendub see vaikimisi just nendele ruumidele, millega ei ole selgelt seotud ühtegi CallProfile'i.

Järgmine kord üritan kirjeldada, milliseid viise kasutatakse CMS-ile juurdepääsuks organisatsiooni sisevõrgust väljaspool.

Allikad:

• 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

Allikas: habr.com