Cisco Meeting Server 2.5.2. Kluster skaleeritavas ja vastupidavas režiimis koos videotöötluse salvestamise funktsiooniga

Selles väljaandes näitan ja selgitan CMS-serveri seadistamise nüansse tõrketaluvuse klastrirežiimis.


TeooriaÜldiselt on olemas kolm CMS-serveri juurutamise tüüpi:

• Single Combined(Üks kombineeritud), see tähendab, et see on üks server, kus on käivitatud kõik vajalikud teenused. Enamasti on seda tüüpi juurutamine rakendatav ainult sisekliendi juurdepääsuks ja väikestes keskkondades, kus ühte serverisse skaleerimise ja üleliigsuse piirangud ei ole kriitilise tähtsusega probleem, või olukordades, kus CMS täidab ainult teatud funktsioone, nagu spetsiaalsed konverentsid Cisco UCM-il.

  Umbes töödiagramm:
  

• Single Split(Üks jagatud) laiendab eelmise juurutamise tüüpi, lisades eraldi serveri väliseks juurdepääsuks. Vanemates juurutustes tähendas see CMS-serveri juurutamist demilitariseeritud tsoonis (DMZ), kus välikliendid pääseksid sellele juurde, ja üht CMS-serverit võrgu tuumas, kus siseklientidele CMS-ile juurdepääs antakse. See konkreetne juurutusmudel tõrjutakse nüüd välja nn tüübi poolt Single Edge, mis koosneb serveritest Cisco Expressway, mis samuti on või tulevad olema paljusid Firewall'i ümbersidumise võimalusi, seega ei pea klientidel olema eraldi CMS piiri serverit.

  Umbes töödiagramm:
  

• Skaleeritav ja vastupidav(Skaleeritav ja talitlushäirete suhtes vastupidav) see tüüp sisaldab igas komponentis üleliigsust, võimaldades süsteemil kasvada teie vajaduste järgi maksimaalse mahutavuseni, pakkudes samal ajal üleliigsust tõrke korral. Samuti kasutatakse selleks ühe serva kontseptsiooni, et tagada turvaline väline juurdepääs. See on tüüp, millega me sel numbril tegeleme. Kui me mõistame, kuidas selle tüübi klastrit rakendada, mõistame me mitte ainult teisi rakendustüüpe, vaid saame ka aru, kuidas luua CMS serverite klastreid arvestades võimaliku kasvava nõudluse.

Enne rakendusele üleminekut tuleb mõista mõningaid põhiasju, nimelt

CMS põhikomponendid:

• Andmebaas: võimaldab kombineerida teatud konfiguratsioone, nagu tellijagrupp, kasutajaruumi ja kasutajad ise. Toetab klasterdamist ainult kõrge kättesaadavuse tagamiseks (üks peamine).
• Call Bridge: teenus audio- ja videokonverentside jaoks, mis tagab täieliku kontrolli kõnede ja multimeedia protsesside haldamise üle. Toetab klasterdamist kõrge kättesaadavuse ja skaleeritavuse jaoks.
• XMPP server: vastutab klientide registreerimise ja autentimise eest, kes kasutavad rakendust Cisco Meeting Application ja/või WebRTC (reaalaegne suhtlemine, või lihtsalt brauseris), samuti komponentidevahelise signalisatsiooni eest. Saab klasterdada ainult kõrge kättesaadavuse jaoks.
• Web Bridge: pakub klientidele juurdepääsu WebRTC-le.
• Loadbalancer: tagab ühe ühenduspunkti Cisco Meeting App rakenduste jaoks Single Split režiimis. Kuulab väliseks liidese ja pordi sisenevaid ühendusi. Samuti tasakaalustab see sissetulevaid TLS-ühendusi XMPP-serverilt, mille kaudu saab suunata TCP-ühendusi välistelt klientidelt.
  Meie stsenaariumis ei ole seda vaja.
• TURN server: tagab tulemüüridest või NAT-idest möödumise tehnoloogia, mis võimaldab
  meie CMS-i viia tulemüüri või NAT-i taha, et ühendada väliskliendid, kes kasutavad Cisco Meeting App või SIP seadmeid. Meie stsenaariumis ei ole seda vaja.
• Web Admin: haldusliides ja API-juurdepääs, sealhulgas spetsiaalsete Unified CM konverentside jaoks.

Konfigureerimismoodid

Erinevalt enamikest teistest Cisco toodetest toetab Cisco Meeting Server kolme konfiguratsioonimeetodit, mis võimaldavad rakendada mistahes tüüpi paigaldust.

• Käskliides (CLI): Käskliides, tuntud kui MMP, esialgsete seadistuste ja sertifikaatide haldamiseks.
• Veebiadministraator: peamiselt CallBridge'iga seotud seadistuste jaoks, eriti ühe klastritud serveri seadistamisel.
• REST API: kasutatakse kõige keerukamate seadistusülesannete ja klastrandmebaasi ülesannete jaoks.

Peale ülaltoodut kasutatakse protokolli SFTP failide edastamiseks — tavaliselt litsentside, sertifikaatide või logide edastamiseks CMS serverisse ja tagasi.

Cisco paigaldusjuhendites on selgelt välja öeldud, et klaster tuleb paigaldada vähemalt kolmest serverist (sõlmest) andmebaaside kontekstis. Kuna ainult paaritu arvu sõlmede puhul töötab uue andmebaasi Meistri valimise mehhanism, ja Meistril on seos suurema osa CMS serveri andmebaasiga.

Ja nagu praktika näitab, ei piisa kahest serverist (nodest) tõeliselt. Valikumehaanika töötab Master'i taaskäivitamisel, Slave server muutub Master'iks ainult pärast taaskäidetud serveri ülesseadmist. Kui aga kahe serveriga klastris Master server äkki "süütuks" jääb, siis Slave server Masters'iks ei muutu, ja kui Slave "süütuks" jääb, siis jääb ülejäänud Master server Slave'iks.

Kuid XMPP kontekstis on tõesti vaja luua kolmese serverite klaster, kuna kui näiteks XMPP teenus ühe serveri peal, kus XMPP on staatuse Leader, välja lülitada, siis jääb teises serveris XMPP staatuseks Follower ja CallBridge'ide ühendus XMPP'ga katkeb, kuna CallBridge ühendub ainult XMPP'ga, millel on staatuse Leader. See on kriitiline, kuna ükski kõne ei toimu.

Samuti näidatakse nendes deployment guide'ides klastrit, kus on üks XMPP server.

Ja arvestades eelnevat on selge, miks: see töötab ainult failover režiimis.

Meie puhul on XMPP server kõikides kolmes nodis.

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

DNS kirjed

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

Pange tähele, et meie DNS-kirjedes on kaks domeeni example.com ja conf.example.com. Example.com on domeen, mida võivad kasutada kõik Cisco Unified Communication Manageri kliendid, mis tõenäoliselt olemas on või on suur tõenäosus, et see on olemas. Või domeen example.com vastab samale domeenile, mida kasutajad oma e-posti aadressides kasutavad. Või võib teie sülearvuti Jabberi klient olla URI-ga user@example.com. Domeen conf.example.com on see domeen, mis seadistatakse Cisco Meeting Serveri kasutajatele. Cisco Meeting Serveri domeen on conf.example.com, seega peab sama Jabberi kasutaja Cisco Meeting Serverisse sisselogimiseks kasutama URI-d user@conf.example.com.

Aluskonfiguratsioon

Kõik allpool kirjeldatud seaded on näidatud ühel serveril, kuid need tuleb läbi viia igas klastris asuvas serveris.

QoS

Kuna CMS genereerib reaalajas Viiteteavet, mis on viivituste ja pakettide kaotuse osas tundlik, soovitatakse enamikul juhtudel QoS-i seadistamine. Selleks toetab CMS erinevate teenuste (DSCP) koodidega pakettide märgistamist, mida ta genereerib. Kuigi DSCP põhine prioriseerimine sõltub sellest, kuidas teie infrastruktuuri võrgu komponendid käsitlevad liiklust, seadistame meie CMS-i tüüpilise DSCP prioriteetide jaotusega, põhinedes QoS parimates praktikas.

Igal serveril sisestame järgmised käsud

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

Nii on kogu video liiklus märgistatud AF41 (DSCP 0x22), kogu hääl liiklus märgistatud EF (DSCP 0x2E), muud madala latentsuse liikluse tüübid, nagu SIP ja XMPP, kasutavad AF31 (DSCP 0x1A).

Kontrollin:

NTP

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

Lisame teie infrastruktuuri NTP serverid käsuga

ntp server add

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

Ja seame meie serveri ajavööndi.

DNS

DNS serverid CMS-i lisame käsuga:

dns add forwardzone

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

Võrguliidese konfiguratsioon

Seame liidese käsklusega:

ipv4  add 
/

Kontrollin:

Serveri nimi (Hostname)

Serveri nime seadmiseks kasutame käsku:

hostname

Ja taaskäivitame.


Sellega on põhikonfiguratsioon lõpetatud.

Sertifikaadid

TeooriaCisco Meeting Server nõuab krüpteeritud komunikatsiooni erinevate komponentide vahel ja seetõttu on kõikidele CMS-i juurutustele vajalikud X.509 sertifikaadid. 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 tekitada segadust ja liigset keerukust. Õnneks saame genereerida sertifikaadi avatud ja privaatsete võtmete paari ning seejärel kasutada neid mitme teenuse jaoks. Meie juhul kasutatakse sama sertifikaati Call Bridge'i, XMPP-serveri, Web Bridge'i ja Web Admini jaoks. Seega tuleb iga klastrisse kuuluva serveri jaoks luua üks avatud ja privaatsete võtmete paar sertifikaati.

Andmebaasi klasterdamisel on aga teatud erilised nõuded sertifikaatide osas, mistõttu on vajalikud spetsiifilised sertifikaadid, mis erinevad teiste teenuste sertifikaatidest. CMS kasutab serveri sertifikaati, mis sarnaneb teiste serverite kasutatavatele sertifikaatidele, kuid seal on ka kliendi sertifikaat, mida kasutatakse andmebaasi ühenduste puhul. Andmebaasi sertifikaate kasutatakse nii autentimise kui ka krüpteerimise eesmärgil. Selle asemel, et anda kasutajanimi ja parool kliendiühenduse loomiseks andmebaasi, esitab see kliendi sertifikaadi, mida server usaldab. Iga server andmebaasi klastris kasutab sama avalikku ja privaatset võtme paari. See võimaldab kõigil klastris olevatel serveritel krüpteerida andmeid selliselt, et neid saavad dekodeerida ainult teised serverid, mis kasutavad samu võtme paare.

Ette broneerimine toimiks, peavad andmebaasi klasdtrid sisaldama vähemalt 3 serverit, kuid mitte rohkem kui 5, maksimaalse signaalikadalipäeva vastastikuse viitega 200 ms kõigi klastrite liikmete vahel. See piirang on rangem, kui Call Bridge'i klasterdamisel, seega on see sageli geograafiliselt jaotatud arendustes piirav tegur.

CMS-i andmebaasi rollil on mitmeid ainulaadseid nõudeid. Erinevalt teistest rollidest nõuab see kliendi- ja serverisertifikaati, kus kliendi sertifikaadil on kindel CN-väli, mis esitatakse serverile.

CMS kasutab postgres andmebaasi, millel on üks põhi ja mitmeid täiesti identsed replikad. Igal hetkel on ainult üks peamine andmebaas („andmebaasiserver“). Ülejäänud klastriliikmed on replikad või „andmebaasi kliendid“.

Andmebaasi klastriks on vajalikud pühendatud serveri ja kliendi sertifikaat. Need peavad olema allkirjastatud tavaliselt sisemiste eraprivaatsete sertifitseerimiskeskustega. Kuna andmebaasi klastris võib iga liige saada peamiseks, peavad andmebaasi serveri ja kliendi sertifikaatide paarid (millel on avatud ja suletud võtmed) olema kopeeritud kõikidele serveritele, et nad saaksid aktsepteerida kliendi või andmebaasi serveri identiteeti. Lisaks peab olema laaditud CA juuresoleku sertifikaat, et tagada kliendi ja serveri sertifikaatide kontrollimine.

Nii et koostame sertifikaadi taotluse, mida kasutavad kõik serveri teenused välja arvatud andmebaas (selle jaoks tehakse eraldi taotlus) käsuga:

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

CNis kirjutame meie serverite üldise nime. Näiteks, kui meie serverite hostname'id on server01, server02, server03, siis CN on server.example.com

Teeme sama ka ülejäänud kahel serveril, ainult et käskudes on vastavad «hostname'id».

Formeerime kaks sertifikaadi taotlust, mida kasutavad andmebaasiteenuse käsud:

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

pki csr dbclusterclient CN:postgres

kus dbclusterserver ja dbclusterclient meie taotlus- ja tulevaste sertifikaatide nimed, hostname1(2)(3) vastavate serverite nimed.

Seda protseduuri teeme ainult ühel serveril(!), ja sertifikaadid ning vastavad .key-failid laadime teistele serveritele üles.

Kliendi sertifikaadi režiimi aktiveerimine AD CS-is

Samuti tuleb iga serveri jaoks sertifikaadid ühte faili liitaIn *NIX:

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

Windows/DOS-is:

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

Ja laadige igale serverile üles:
1. „Isiklik“ serveri sertifikaat.
2. Juhtsertifikaat (koos vahe-sertifikaatidega, kui neid on).
3. Andmebaasi sertifikaadid („server“ ja „kliendi“) ning .key-failid, mis loodi „serveri“ ja „kliendi“ andmebaasi sertifikaadi taotluse koostamisel. Need failid peavad olema kõigis serverites identsed.
4. Kolme „isikliku“ sertifikaadi fail.

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

Andmebaasi klaster

Nüüd, kui teil on kõik sertifikaadid CMS-serveritele üles laaditud, saate seadistada ja aktiveerida andmebaaside klasterdamise kolme sõlme vahel. Esimene samm on valida üks server andmebaasi klastrina peamiseks sõlmeks ja see täielikult seadistada.

Peamine andmebaas

Andmebaasi replikatsiooni seadistamise esimene samm on määrata sertifikaadid, mida andmebaasis kasutada. Seda tehakse järgmise käsuga:

database cluster certs

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

database cluster localnode a

Seejärel initsialiseerime klastriva andmebaasi peamisel serveril käsuga:

database cluster initialize

Kliendi andmebaasi sõlmed

Teeme sama protseduuri, kuid käsu asemel database cluster initialize sisestame käsu kujul:

database cluster join

kus on CMS-serveri IP-aadress, millel klaster initsialiseeriti, lihtsamalt öeldes Masteri.

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

database cluster status

Teeme sama ka kolmandal serveril.

Tulemusena on meie esimene server Master, ülejäänud on Slave'id.

Web Admin Teenus

Lülitame sisse veebihaldusteenuse:

webadmin listen a 445

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

Konfigureerime Web Admin teenuse sertifikaatide failidega järgmise käsuga:

webadmin certs

Ja lülitame Web Admin teenuse sisse käsuga:

webadmin enable

Kui kõik on korras, saame SUCCESS read, kus on märgitud, et Web Admin on õigesti seadistatud võrgu ja sertifikaadi jaoks. Kontrollime teenuse tööd veebilehitseja kaudu, sisestades veebihalduri aadressi, näiteks: cms.example.com:445

Call Bridge Klaster

Call Bridge on ainus teenus, mis on olemas igas CMS-i juurutuses. Call Bridge on peamine konverentsiskeemi mehhanism. See pakub ka SIP liidest, nii et kõnesid saab suunata sinna või sealt, näiteks Cisco Unified CM-iga.

Allpool kirjeldatud käsud tuleb teostada iga serveri puhul vastavate sertifikaatidega.
Nii et:

Seome sertifikaadid Call Bridge teenusega käsu abil:

callbridge certs  []

Seome CallBridge teenuseid seome vajalikku liidese ühendamiseks käsuga:

callbridge listen a

Ja käivitame teenuse käsuga:

callbridge restart

Nüüd, kui meil on seadistatud Call Bridge'id, saame seada Call Bridge'i klasterdamise. Call Bridge'i klasterdamine erineb andmebaasi või XMPP klasterdamisest. Call Bridge'i klaster suudab toetada 2 kuni 8 sõlme ilma piiranguteta. See tagab mitte ainult üleliigsuse, vaid ka koormuse jaotamise, tänu millele saavad konverentsid aktiivselt jaotuda Call Bridge'i serverite vahel, kasutades nutikat kõnede jaotamist. CMS-il on täiendavad funktsioonid, Call Bridge'i rühmad ja nendega seotud funktsioonid, mida saab kasutada edasiseks haldamiseks.

Call Bridge'i klasterdamine seadistatakse peamiselt veebihalduri kaudu
Allpool kirjeldatud protseduur tuleb läbi viia igal klusteri serveril.
Nii et,

1. Logige sisse läbi veebiraamatute Configuration > Cluster.
2. Call Bridge'i identiteet Helista sildi identiteeti ainult ainulaadse nime sisestamine callbridge[01,02,03], mis vastab serveri nimele. Need nimed on suvalised, kuid peavad olema selle klastri jaoks ainulaadsed. Need on kirjeldavad, kuna näitavad, et need on serverite identifikaatorid [01,02,03].
3.V Klastri Call Bridges sisestame meie klastrisse kuuluvate serverite veebihalduri URL-id, cms[01,02,03].example.com:445, aadressi väljale. Port peab olema kindlasti määratud. Saate jätta Peer link SIP domeeni tühjaks.
4. Lisame CallBridge'ile igale serverile usaldusväärsuse sertifikaadi, mille fail sisaldab kõiki meie serverite sertifikaate, mille oleme alguses kokku liitnud, käsuga:

callbridge trust cluster

Ja käivitame teenuse käsuga:

callbridge restart

Iga serveri puhul peaks olema saadud selline pilt:

XMPP klaster

XMPP teenust CMS-is kasutatakse kogu registreerimise ja autentimise haldamiseks Cisco Meeting Apps (CMA), sealhulgas CMA WebRTC veebikliendi jaoks. Ise Call Bridge toimib samuti XMPP kliendina autentimise eesmärkidel ning seetõttu peab olema seadistatud nagu teised kliendid. XMPP talitlushäire taluvus on funktsioon, mida toetatakse tootmiskeskkondades alates versioonist 2.1.

Allpool kirjeldatud käsud tuleb teostada iga serveri puhul vastavate sertifikaatidega.
Nii et:

Seome SSL-sertifikaate sidudes XMPP teenusega käsklusega:

xmpp certs  []

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

xmpp listen a

XMPP teenus vajab ainulaadset domeeni. See on kasutajate sisselogimine. Teisisõnu, kui kasutaja püüab CMA rakendusega (või WebRTC kliendi kaudu) süsteemi sisse logida, sisestab ta userID@logindomain. Meie puhul on see userid@conf.example.com. Miks mitte lihtsalt example.com? Meie konkreetses seadistuses valisime oma domeeni Unified CM, mida Jabberi kasutajad kasutavad Unified CM-is, näiteks example.com, seega vajame CMS-i kasutajatele teist domeeni, et suunata kõnesid CMS-i ja CMS-ilt läbi SIP domeenide.

Seadistage XMPP domeen käsklusega:

xmpp domain

Ja aktiveerime XMPP teenuse käsklusega:

xmpp enable

XMPP teenuses tuleb iga Call Bridge'i jaoks luua mandaadid, mida kasutatakse XMPP teenusesse registreerimiseks. Nende nimed on juhuslikud (ja ei ole seotud ainulaadsete nimedega, mille olete seadnud kutsungi sildistamiseks). Ühele XMPP serverile tuleb lisada kolm kutsungi silda ja seejärel sisestada need mandaadid teistele XMPP serveritele klastris, kuna see konfiguratsioon ei mahu klastribaasi andmebaasi. Hiljem seadistame iga Call Bridge'i kasutama seda nime ja salajast, et registreeruda XMPP teenusesse.

Nüüd peame seadistama XMPP teenuse esimeses serveris kolme Call Bridge'iga callbridge01, callbridge02 ja callbridge03. Iga kontole määratakse juhuslikud paroolid. Hiljem sisestatakse need teiste Call Bridge serverite jaoks, et siseneda sellele XMPP-serverile. 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

Sarnane pilt peaks olema ka ülejäänud serverites pärast allpool kirjeldatud toimingute tegemist.

Jätkame samade seadete lisamist kahel ülejäänud serveril, kasutades ainult neid käske.

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

Salaseme salvestame hoolikalt, et sinna ei sattuks näiteks liigseid tühikuid.


Iga serveri puhul peaks olema sama pilt:

Edasi näitame kõikides klastriserverites usaldusfaili, mis sisaldab eelnevalt loodud kolme sertifikaadi, kasutades käsku:

xmpp cluster trust

Käivitame XMPP klastrirežiimi kõigis klastriserverites järgmise käsuga:

xmpp cluster enable

Esimeses klastriserveris algatame XMPP klastrite loomise käsuga:

xmpp cluster initialize

Ülejäänud serverites liitume XMPP klastriga käsku kasutades:

xmpp cluster join

Kontrollime iga serveri puhul XMPP klastrite loomise eduka kestvuse järgmiste käskudega:

xmpp status
xmpp cluster status

Esimene server:

Teine server:

Kolmas server:

Call Bridge'i ühendamine XMPP-iga

Nüüd, kui XMPP klaster on töös, tuleb seadistada Call Bridge'i teenused ühenduma XMPP klastriga. See konfigureerimine toimub veebihalduri kaudu.

Läheme igas serveris segmenti Configuration > General ja väljale Unique Call Bridge name kirjutame vastavale serverile unikaalsed Call Bridge'i nimed callbridge[01,02,03]. Väljale Domeen conf.example.ru ja ja vastavad paroolid, saab neid vaadata
igal klastriserveril käsuga:

xmpp callbridge list

Jätame välja välja „Server“ Callbridge teeb DNS SRV otsingu _xmpp-component._tcp.conf.example.com, et leida saadaval XMPP server. Callbridge’i ühenduse IP-aadressid võivad erinevates serverites erineda, see sõltub sellest, millised väärtused tagastatakse SRV kirje päringu käigus. _xmpp-component._tcp.conf.example.com Callbridge’i osas, mis omakorda sõltub määratud prioriteetidest selle DNS kirje jaoks.

Seejärel liikuda menüüsse Status > General, et veenduda, kas Call Bride teenus on XMPP teenusega edukalt ühendatud.

Web Bridge

Igal klastriserveril aktiveerime Web Bridge teenuse käsuga:

webbridge listen a:443

Seame Web Bridge teenuse sertifikaatide failidega käsuga:

webbridge certs

Web Bridge toetab HTTPS. See suunab HTTP üle HTTPS-ile, kui on seadistatud kasutama „http-redirect“.
HTTP ümbersuunamise lubamiseks kasutage järgmist käsku:

webbridge http-redirect enable

Käsku Call Bridge’ile, et Web Bridge usaldaks Call Bridge’ilt ühendusi, kasutage käsku:

webbridge trust

kus see on fail, mis sisaldab kõiki kolme sertifikaati igalt serverilt klastris.

Tõhus töö peab olema iga klastriserveri juures.


Nüüd peame looma kasutaja rolliga «appadmin», kuna see on vajalik meie klastrite seadistamiseks (!), mitte iga klastriserveri eraldi seadistamiseks, nii et seaded rakenduvad igas serveris ühtlaselt ning need tehakse ühekordselt.


Edasise seadistamise jaoks kasutame Postman.

Autentimiseks valige Basic jaotises Autorization

CMS-serveritele käskude korrektseks saatmiseks tuleb seada õige kodeering

Määrame Webbridge'id käsuga POST argumenti url ja väärtusega cms.example.com



Webbridge'is määrame vajalikud parameetrid: külalisjuurdepääs, kaitstud juurdepääs ja muu.

Call Bridge Groups

Vaikimisi ei kasuta CMS alati võimalikult tõhusalt olemasolevaid konverentsivahendeid.

Näiteks, kui kohtumisele osaleb kolm osalejat, võivad nad kõik asuda erinevates Call Bridgetes. Selleks, et need kolm osalejat saaksid omavahel suhelda, seadistavad Call Bridged automaatselt ühendused kõigi serverite ja klientide vahel ühes ja samas Space's, nii et see näeb välja nagu kõik kliendid asuksid ühes serveris. Kahjuks on selle puuduseks see, et kolme osalejaga konverents kasutab nüüd 9 meediaporti. See on ilmselgelt ebaefektiivne ressursside kasutamine. Lisaks, kui Call Bridge on tõeliselt üle koormatud, toimib vaikimisi mehhanism jätkata kõnede vastuvõtmist ja teenuste pakkumist madalama kvaliteediga kõigile selle Call Bridge’i abonentidele.

Need probleemid lahendatakse Call Bridge Group funktsiooni abil. See funktsioon tutvustati Cisco Meeting Serveri 2.1 versioonis ja seda on laiendatud koormuse tasakaalustamise toetamiseks nii sissetulevate kui ka väljaminevate kõnede, Cisco Meeting Appi (CMA) puhul, sealhulgas WebRTC osalejate jaoks.

Ümberühendamise probleemide lahendamiseks on iga Call Bridge'i jaoks kehtestatud kolm kohandatavat koormuse piiri:

LoadLimit — on maksimaalne numbriline koormus konkreetse Call Bridge'i jaoks. Igal platvormil on soovitatav koormuse piirmäär, näiteks 96000 CMS1000 jaoks ja 1.25 GHz virtuaalse protsessori jaoks virtuaalmasinas. Erinevad kõned tarbivad sõltuvalt osaleja eraldusvõimest ja kaadrisagedusest teatud hulga ressursse.
NewConferenceLoadLimitBasisPoints (vaikimisi 50% loadLimit) — seab serveri koormuse piiri, mille ületamisel lükatakse uued konverentsid tagasi.
ExistingConferenceLoadLimitBasisPoints (vaikimisi 80% loadLimit) — serveri koormuse väärtus, mille ületamisel lükatakse tagasi osalejad, kes liituvad olemasoleva konverentsiga.

Kuigi see funktsioon on loodud kõnede ja koormuse jaotamiseks, võivad Call Bridge'i rühmadele olla määratud ka teised grupid, nagu TURN serverid, Web Bridge serverid ja salvestusseadmed, nii et neid saab õigesti rühmitada optimaalse kasutuse jaoks. Kui mõni neist objektidest ei ole määratud kõnede gruppi, eeldatakse, et need on kõigile serveritele kergesti kättesaadavad ilma eriliste prioritiseerimisteta.

Needleparameet here: cms.example.com:445/api/v1/system/configuration/cluster

Next, we indicate to each callbridge which callbridge group it belongs to:

First callbridge

Second callbridge

Third callbridge


This way, we have set up the Call Bridge group for more effective use of resources in the Cisco Meeting Server cluster.

Import users from Active Directory

The Web Admin service has an LDAP configuration section, but it does not provide complex configuration options, and the information is not stored in the cluster database. Therefore, the setup will have to be performed either manually on each server through the web interface or via the API, and to avoid having to 'get up three times', we will set the data through the API.

Using the URL to access cms01.example.com:445/api/v1/ldapServers we create an LDAP Server object, specifying parameters such as:

• Server IP address
• port number
• username
• password
• secure

Secure — true or false depending on the port; 389 is non-secure, 636 is secure.


Map LDAP source parameters to attributes in the Cisco Meeting Server.
LDAP mapping correlates attributes in the LDAP directory with attributes in the CMS. The actual attributes are:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Atribuutide kirjeldusJID tähistab kasutaja sisenemise identifikaatorit CMS-i. Kuna see on Microsoft Active Directory LDAP-server, seondub CMS-i JID LDAP-s olevaga sAMAccountName, mis on sisuliselt kasutaja sisenemise identifikaator Active Directorys. Samuti pidage meeles, et võtate sAMAccountName'i ja lisate sellele domeeni conf.pod6.cms.lab, kuna see on sisselogimise nimi, mida teie kasutajad CMS-i sisenemiseks kasutavad.

nameMapping seondub Active Directory displayName välja sisalduvaga, CMS-i kasutaja nime väljal.

coSpaceNameMapping loodab CMS-i space'i nime displayName välja põhjal. See atribuut koos coSpaceUriMapping atribuudiga on vajalik, et luua igale kasutajale space.

coSpaceUriMapping määratleb kasutaja isikliku space'iga seotud URI kasutajapoolse osa. Mõned domeenid võivad olla seadistatud keskkonna määramiseks. Kui kasutaja osa vastab selle välja väärtusele ühes nendest domeenidest, suunatakse väljakutse selle kasutaja space'i.

coSpaceSecondaryUriMapping määrab teise URI, et saavutada space. Seda saab kasutada numbrilise hüüdnime lisamiseks, et suunata kõnesid imporditud kasutaja space'isse alternatiivina tähestiku ja numbritega URI-le, mis on määratud parameetris coSpaceUriMapping.

LDAP server ja LDAP-i kaardistamine on seadistatud. Nüüd on vajalik need omavahel siduda, luues LDAP-i allika.

Using the URL to access cms01.example.com:445/api/v1/ldapSource loome LDAP allika objekti, määrates sellised parameetrid nagu:

• server
• mapping
• baseDn
• filter

Nüüd, kui LDAP-i seadistamine on valmis, saab teostada käsitsi sünkroonimise.

Teeme seda kas iga serveri veebiliidese kaudu, klikkides Sünkroniseeri nüüd jaotises Active Directory


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

Ad-Hoc konverentsid

Mis see on?Traditsioonilises mõttes on konverents see, kui kaks osalejat räägivad omavahel ja üks osalejat (kasutades Unified CM-is registreeritud seadet) vajutab nuppu "Konverents", helistab teisele inimesele ja pärast vestlust selle kolmanda osapoolega vajutab uuesti nuppu "Konverents", et liituda kõigi kolme osalejaga kolmik-konverentsil.

Ad-Hoc konverentsi määratleb see, et Ad-Hoc konverents ei ole lihtsalt SIP-kõne CMS-ile. Kui konverentsi algataja vajutab nuppu "Konverents" teist korda, et kutsuda kõiki samasse koosolekusse, peab Unified CM kutsuma CMS-i API-d, et luua "otsekohe" konverents, kuhu kõik kõned suunatakse. Kõik see toimub osalejate jaoks märkamatult.

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

Vajadusel võib CUCM dünaamiliselt luua CMS-is ruumi, et iga kõne saaks CMS-ile kohale jõuda ja vastata sissetulevate kõnede reeglile, mis on ette nähtud ruumide jaoks.

Integratsioon CUCM-iga seatakse üles nagu on kirjeldatud artiklis oleme teada saanud välja arvatud, et Cisco UCM-is tuleb luua kolm trunki CMS-ile, kolm Konverentsi Silda, SIP Security Profiilis määrata kolm Subject Nime, Route Group, Route List, Media Resource Group ja Media Resource Group List, ning Cisco Meeting Serveris tuleb pisut lisada marsruutimise reegleid.

SIP Security Profiil:


Trunkid:


Iga trunk näeb välja identne:




Konverentsi Sild


Iga Konverentsi Sild näeb välja identne:


Rühma grupp


Rühma nimekiri


Meediaressursi rühma


Meediaressursi rühma nimekiri

Kutsereeglid

Erinevalt täiustatud kutsest juhtimise süsteemidest nagu Unified CM või Expressway, vaatab CMS uusi kutseid domeeni ainult SIP Request-URI väljal. Seega, kui SIP INVITE on mõeldud sip:user@domain.com, huvitab CMS ainult domain.com. CMS järgib neid reegleid, et määrata, kuhu kõne suunata:

1. Esiteks püüab CMS siduda SIP domeeni sisenemiskutsete töötlemise reeglitega seadistatud domeenidega. Seejärel saab neid kutseid suunata ('sihtkohtadesse') ruumidesse või konkreetsetele kasutajatele, sisemisele IVR-ile või otse integreeritud adressaatidele Microsoft Lync/Skype for Business (S4B).
2. Kui sisenevate kõnede töötlemise reeglite vahel ei ole ühtegi vastet, üritab CMS sobitada domeeni, mis on seadistatud kõne suunamise tabelis. Kui sobivus on loodud, võib reegel kõne selgesõnaliselt tagasi lükata või suunata. Sel ajal võib CMS domeeni ümber kirjutada, mis on mõnikord kasulik kõnede jaoks Lynci domeenidesse. Samuti saate valida pass throw, mis tähendab, et ükski väli ei muutu täiendavalt, või kasutada CMS-i sisemist kasutajagruppi. Kui kõne suunamise reeglite vahel puuduvad vasted, kasutatakse vaikesena kõne tagasilükkamist. Pidage meeles, et CMS-is, kuigi kõne on "suunatud", on multimeedia endiselt seotud CMS-iga, mis tähendab, et see on signalisatsiooni ja multimeedia liikluse teel.
Siis alluvad ainult suunatud kõned väljakutsereeglitele. Need sätted määravad adressaadid, kuhu kõned saata, ühendusliini tüübi (kas uus Lynci kõne või standardne SIP) ja mis tahes transformatsioonid, mis võivad toimuda, kui kõne suunamise reeglis ei ole valitud edasiviimist.

Siin on logi sellest, mis toimub Ad-Hoc konverentsil

Kuvatud ekraanipildil on kehv (ei tea, kuidas paremini teha), seetõttu kirjutan logi nii:

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

Info	kutse loomine ebaõnnestus, coSpace'i leidmine ebaõnnestus -- proovib andmebaasist võtta

Info	API "001036270012" Ruum GUID: 7986bb6c-af4e-488d-9190-a75f16844e44  Kutse GUID: 93bfb890-646c-4364-8795-9587bfdc55ba  Kutse Korrelaator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  Sisemine G

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

Info	kutse 7: sisse tulev SIP kutse "sip:672@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

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

Info	konverents 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nimega "001036270012"

Info	kutse 7: konfigureeritud - API kutse jalg bc0be45e-ce8f-411c-be04-594e0220c38e SIP kutse ID-ga "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	kutse 7: seadistamine UDT RTP seansi jaoks DTLS (kombineeritud media ja kontroll)
Info	konverents "001036270012": krüpteerimata kutse jalad on nüüd olemas

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

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

Info	kutse 8: sisse tulev SIP kutse "sip:690@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	kutse 8: konfigureeritud - API kutse jalg db61b242-1c6f-49bd-8339-091f62f5777a SIP kutse ID-ga "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	kutse 8: seadistamine UDT RTP seansi jaoks DTLS (kombineeritud media ja kontroll)

Info	kutse 9: sisse tulev SIP kutse "sip:673@172.x.x.x" kohaliku URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	kutse 9: konfigureeritud - API kutse jalg 37a6e86d-d457-47cf-be24-1dbe20ccf98a SIP kutse ID-ga "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	kutse 9: seadistamine UDT RTP seansi jaoks DTLS (kombineeritud media ja kontroll)
Info	kutse 8: kompenseerimine kaug-otsaga, mis ei vasta koormuse tüüpidele

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

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

Info	kutse 7: kompenseerimine kaug-otsaga, mis ei vasta koormuse tüüpidele
Info	kutse 8: mitte sobivate koormuse tüüpide režiim 1/0
Info	kutse 8: pakub mittesobiva koormuse tüüpide režiimis
Info	kutse 8: järgneva ühe koodiga pakkumine sai
Info	kutse 8: mitte sobivate koormuse tüüpide režiim 1/0
Info	kutse 8: pakub mittesobiva koormuse tüüpide režiimis
Info	kutse 8: saadetakse vastus ühe koode tehnikaga pakkumise lisamiseks
Info	kutse 9: kompenseerimine kaug-otsaga, mis ei vasta koormuse tüüpidele

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

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

Info	kutse 9: BFCP (kliendi roll) on nüüd aktiivne
Info	kutse 9: saadetakse BFCP tere kliendina, kui tere on saadud, kui BFCP ei ole aktiivne
Info	kutse 9: BFCP (kliendi roll) on nüüd aktiivne
Info	kutse 7: lõpetamine; kaug-SIP purunemine - ühendatud 0:13
Info	kutse 7: häviv API kutse jalg bc0be45e-ce8f-411c-be04-594e0220c38e

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

Info	kutse 9: ooterežiim
Info	kutse 9: mitte sobivate koormuse tüüpide režiim 1/0
Info	kutse 9: pakub mittesobiva koormuse tüüpide režiimis
Info	kutse 8: ooterežiim
Info	kutse 8: järgneva ühe koodiga pakkumine sai
Info	kutse 8: mitte sobivate koormuse tüüpide režiim 1/0
Info	kutse 8: pakub mittesobiva koormuse tüüpide režiimis
Info	kutse 8: saadetakse vastus ühe koode tehnikaga pakkumise lisamiseks
Info	kutse 9: lõpetamine; kaug-SIP purunemine - ühendatud 0:12

Ad-Hoc konverents:


Sissetulevate kõnede reeglid
Sissetulevate kõnede seadistamine on vajalik, et võimaldada kõnede vastuvõtmist CMS-is. Nagu te nägite LDAP-i seadistamisel, imporditakse kõik kasutajad domeenilt conf.pod6.cms.lab. Seetõttu soovite, et kõned sellele domeenile suunataks ruumidesse. Samuti pead seadma reeglid kõigile, mis on suunatud iga CMS-i serveri täisdomeenile (ja võib-olla isegi IP-aadressile). Meie välises kõnede kontrollis, Unified CM, on SIP-puled konfigureeritud iga CMS-i serveri jaoks eraldi. Sõltuvalt sellest, kas nende SIP-puude sihtkoht on IP-aadress või serveri täisdomeen, määrab see, kas CMS-i tuleb seadistada selle IP-aadressile või täisdomeenile suunatud kõnede vastuvõtmiseks.

Domeen, millel on kõrgeima prioriteediga sissetuleva liikluse reegel, kasutatakse domeenina kõikide kasutajakohaste ruumide jaoks. Kui kasutajad sünkroniseeritakse LDAP-i kaudu, loob CMS automaatselt ruumid, kuid ainult URI kasutajakohase osa (coSpaceUriMapping), näiteks user.space. domain Täielik URI luuakse selle reegli põhjal. Tegelikult, kui te sellel etapil Web Bridge'i siseneksite, siis näeksite, et Space URI-l puudub domeen. Seades selle reegli kõrgeimaks prioriteediks, määrate genereeritud space'ide domeeni kui conf.example.com.


Väljaminevate kõnede reeglid

Kasutajate väljaminevate kõnede võimaldamiseks Unified CM klastri puhul on vajalik seadistada väljaminevate ühenduste reeglid. Unified CM-s registreeritud lõpp-punktide domeen, nagu näiteks Jabber, on example.com. Kõned sellele domeenile peaks suunama tavaliste SIP-kõnedena Unified CM kõneserveritesse. Peamise serverina toimib cucm-01.example.com, lisana cucm-02.example.com.

Esimene reegel kirjeldab kõnede lihtsaimat marsruutimist serverite vahel klastri sees.

Väli Local from domain mugav-URI helistaja jaoks dial-up'i isikule, kellele helistatakse, pärast sümbolit «@». Kui jätame selle tühjaks, siis pärast sümbolit «@» kuvatakse CUCM'i IP-aadress, mille kaudu see kõne läheb. Kui me täpsustame domeeni, siis pärast sümbolit «@» kuvataksegi domeen. See on vajalik, et saaksime tagasi helistada; muidu pole võimalik jõuda tagasi SIP-URI nime@ip-aadress kaudu.

Kõne, kui on määratud Local from domain


Kõne, kui EI määratud Local from domain


Kohustuslik on selgelt märkida, kas kõned on Encrypted või Unencrypted, sest parameetri Auto korral ei tööta midagi.

Salvestamine

Videokonverentside salvestamine toimub Record-serveri kaudu. Recorder on täpselt sama mis Cisco Meeting Server. Recorder ei vaja endale mingeid litsentse. Salvestamise litsentsid on vajalikud serveritele, kus on avatud CallBridge teenused, st salvestamise litsents on vajalik ja peab olema rakendatud CallBridge komponendile, mitte serverile, kus Recorder töötab. Recorder käitub nagu kliendieheline protokollide vahetuse ja kohaloleku (XMPP) klient, seetõttu peab XMPP server olema lubatud serveris, kus asub CallBridge.

Kuna meil on klaster ja litsents tuleb venitada kõikidele kolmele klastriserverile, seetõttu seostame (lisame) kõigi klastrisse kuuluvate CMS serverite a-liidese MAC-aadressid litsentside osakonnas isiklikus kabinetis.

Ja selline pilt peaks olema iga klastriserveri peal.

Tegelikult on Recorder’i paigutamiseks mitu stsenaariumi, kuid me jääme selle juurde:


Enne Recorder’i seadistamist tuleb ette valmistada koht, kuhu salvestatakse videokonverentsid. See on siis. link, kuidas seadistada kogu Recording. Ma rõhutan olulisi hetki ja detaile:

1. Sertifikaat on parem esimeselt serverilt klastris.
2. Viga "Recorder unavailable" võib tekkida, kui Recorder Trustis on määratud vale sertifikaat.
3. Salvestamine võib mitte toimida, kui salvestamiseks on määratud mittejuurekataloog NFS-is.

Mõnikord on vaja automaatselt salvestada ühe konkreetse kasutaja või space’i konverents.

Selleks luuakse kaks CallProfile’i:
Ilma salvestusfunktsioonita


Ja automaatse salvestusfunktsiooniga


Seejärel lisame vajaliku space’i juurde CallProfile’i koos automaatse salvestusfunktsiooniga.


CMS-is on nii seadistatud, et kui CallProfile on selgelt seotud mõne space'iga või space'idega, siis töötab see CallProfile ainult nende konkreetsete space'ide kontekstis. Kui CallProfile ei ole seotud ühegi space'iga, siis rakendatakse seda vaikimisi nende space'ide puhul, millega ei ole selgelt seotud ühtki CallProfile'i.

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

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