Selles väljaandes näitan ja selgitan mõningaid keerukusi CMS-serveri seadistamisel tõrkesiirdeklastri režiimis.
ТеорияÜldiselt on CMS-i serveri juurutamist kolme tüüpi:
- Üksik kombineeritud(Üksik kombineeritud), st. see on üks server, kus töötavad kõik vajalikud teenused. Enamasti sobib seda tüüpi juurutamine ainult kliendisiseseks juurdepääsuks ja väiksemates keskkondades, kus ühe serveri mastaapsuse ja liiasuse piirangud ei ole kriitiliseks probleemiks või olukordades, kus CMS täidab ainult teatud funktsioone, näiteks ad hoc. Cisco UCM-i konverentsidel.
Ligikaudne tööskeem:
- Üksik Split(Single Split) laiendab eelmist juurutustüüpi, lisades välise juurdepääsu jaoks eraldi serveri. Pärandjuurutustes tähendas see CMS-serveri juurutamist demilitariseeritud võrgusegmendis (DMZ), kus välised kliendid said sellele juurde pääseda, ja ühe CMS-serveri võrgutuuma, kus sisekliendid pääsesid CMS-ile juurde. Seda konkreetset juurutusmudelit asendab nüüd nn tüüp Üks serv, mis koosneb serveritest Cisco kiirtee, millel on või on palju samu tulemüüri möödaviiguvõimalusi, nii et kliendid ei pea lisama spetsiaalset CMS-serverit.
Ligikaudne tööskeem:
- Skaleeritav ja vastupidav(Skaleeritav ja tõrketaluv) See tüüp hõlmab iga komponendi koondamist, võimaldades süsteemil kasvada vastavalt teie vajadustele maksimaalse võimsuseni, pakkudes samal ajal liiasust rikke korral. Samuti kasutab see turvalise välise juurdepääsu tagamiseks Single Edge kontseptsiooni. See on tüüp, mida me selles episoodis vaatleme. Kui mõistame, kuidas seda tüüpi klastreid juurutada, ei mõista me mitte ainult teist tüüpi juurutusi, vaid saame ka aru, kuidas luua CMS-serverite klastreid, et rahuldada potentsiaalset nõudluse kasvu.
Enne juurutamise juurde liikumist peate mõistma mõnda põhiasja, nimelt
Peamised CMS-i tarkvara komponendid:
- andmebaas: võimaldab kombineerida mõningaid konfiguratsioone, näiteks valimisplaani, kasutajaruume ja kasutajaid endid. Toetab rühmitamist ainult kõrge kättesaadavuse tagamiseks (üks juht).
- Helista Bridge'ile: heli- ja videokonverentsi teenus, mis tagab täieliku kontrolli kõnede ja multimeediumiprotsesside haldamise ja töötlemise üle. Toetab klasterdamist kõrge kättesaadavuse ja mastaapsuse tagamiseks.
- XMPP server: vastutab klientide registreerimise ja autentimise eest, kasutades Cisco koosolekurakendust ja/või WebRTC(reaalajas suhtlus või lihtsalt brauseris), samuti komponentidevaheline signaalimine. Saab rühmitada ainult kõrge kättesaadavuse tagamiseks.
- Veebisild: annab kliendile juurdepääsu WebRTC-le.
- Koormuse tasakaalustaja: pakub Cisco koosolekurakenduste jaoks ühtse ühenduspunkti režiimis Single Split. Kuulab välist liidest ja porti sissetulevate ühenduste jaoks. Samuti aktsepteerib koormuse tasakaalustaja XMPP-serverist sissetulevaid TLS-ühendusi, mille kaudu saab välisklientidelt TCP-ühendusi vahetada.
Meie stsenaariumi järgi pole seda vaja. - Pööra server: pakub tulemüüri möödaviigutehnoloogiat, mis võimaldab
asetage meie CMS tulemüüri või NAT-i taha, et ühendada välised kliendid Cisco Meeting Appi või SIP-seadmete abil. Meie stsenaariumi järgi pole seda vaja. - Veebiadministraator: haldusliides ja API juurdepääs, sealhulgas spetsiaalsete Unified CM konverentside jaoks.
Konfiguratsioonirežiimid
Erinevalt enamikust teistest Cisco toodetest toetab Cisco Meeting Server kolme konfiguratsioonimeetodit igat tüüpi juurutamiseks.
- Käsurida (CLI): käsurea liides, mida nimetatakse MMP-ks esialgse konfiguratsiooni ja sertifikaadi toimingute jaoks.
- Veebiadministraator: Peamiselt CallBridge'iga seotud konfiguratsioonide jaoks, eriti ühe klastrita serveri seadistamisel.
- REST API: kasutatakse kõige keerukamate konfiguratsiooniülesannete ja rühmitatud andmebaasiga seotud ülesannete jaoks.
Lisaks ülaltoodule kasutatakse protokolli SFTP failide (tavaliselt litsentside, sertifikaatide või logide) edastamiseks CMS-serverisse ja sealt.
Cisco juurutusjuhendites on valges ja inglise keeles kirjutatud, et klaster tuleb juurutada vähemalt kolm serverid (sõlmed) andmebaaside kontekstis. Sest Ainult paaritu arvu sõlmede korral töötab uue andmebaasijuhi valimise mehhanism ja üldiselt on andmebaasijuhil ühendus enamiku CMS-i serveri andmebaasiga.
Ja nagu praktika näitab, ei piisa kahest serverist (sõlmest) tegelikult päriselt. Valikumehhanism töötab ülemseadme taaskäivitamisel, alamserverist saab ülemseade alles pärast taaskäivitatud serveri avamist. Kui aga kahest serverist koosnevas klastris peaserver järsku kustub, ei saa alamserverist ülemserverit ja kui alamserver kustub, saab ülejäänud ülemserver alluvaks.
Aga XMPP kontekstis oleks tõesti vaja kokku panna kolmest serverist koosnev klaster, sest kui näiteks keelate XMPP teenuse ühes serveris, milles XMMP on Leader-olekus, siis ülejäänud serveris jääb XMPP jälgija olekusse ja CallBridge'i ühendused XMPP-ga katkevad, sest CallBridge loob ühenduse ainult liidri staatusega XMPP-ga. Ja see on kriitiline, sest... ükski kõne ei lähe läbi.
Samuti on samades juurutusjuhendites demonstreeritud ühe XMPP-serveriga klastrit.
Ja ülaltoodut arvesse võttes saab selgeks, miks: see töötab, kuna on tõrkesiirderežiimis.
Meie puhul on XMPP-server kõigis kolmes sõlmes.
Eeldatakse, et kõik kolm meie serverit on üleval.
DNS-kirjed
Enne serverite seadistamise alustamist peate looma DNS-kirjed А и SRV tüübid:
Pange tähele, et meie DNS-kirjetes on kaks domeeni example.com ja conf.example.com. Näide.com on domeen, mida kõik Cisco Unified Communication Manageri abonendid saavad kasutada oma URI-de jaoks, mis on tõenäoliselt teie infrastruktuuris olemas või tõenäoliselt olemas. Või vastab example.com samale domeenile, mida kasutajad kasutavad oma e-posti aadresside jaoks. Või võib teie sülearvuti Jabberi kliendil olla URI [meiliga kaitstud]. Domeen conf.example.com on domeen, mis konfigureeritakse Cisco Meeting Serveri kasutajatele. Cisco koosolekuserveri domeen on conf.example.com, nii et sama Jabberi kasutaja puhul tuleb Cisco koosolekuserverisse sisselogimiseks kasutada URI-d user@conf.example.com.
Põhikonfiguratsioon
Kõik allpool kirjeldatud seaded kuvatakse ühes serveris, kuid neid tuleb teha igas klastri serveris.
QoS
Kuna CMS genereerib reaalajas liiklus on tundlik viivituste ja pakettide kadumise suhtes, enamikul juhtudel on soovitatav konfigureerida teenuse kvaliteet (QoS). Selle saavutamiseks toetab CMS pakettide märgistamist selle genereeritud diferentseeritud teenuste koodidega (DSCP). Kuigi DSCP-põhine liikluse prioriseerimine sõltub sellest, kuidas teie infrastruktuuri võrgukomponendid liiklust töötlevad, konfigureerime meie CMS-i tüüpilise DSCP prioritiseerimisega, mis põhineb QoS-i parimatel tavadel.
Igas serveris sisestame need käsud
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ASeega oli kogu videoliiklus tähistatud AF41 (DSCP 0x22), kogu kõneliiklus tähisega EF (DSCP 0x2E), muud tüüpi madala latentsusega liiklus, nagu SIP ja XMPP, kasutavad AF31 (DSCP 0x1A).
Kontrollime:
NTP
Network Time Protocol (NTP) on oluline mitte ainult kõnede ja konverentside täpsete ajatemplite pakkumiseks, vaid ka sertifikaatide kontrollimiseks.
Lisage oma infrastruktuurile NTP-servereid käsuga nagu
ntp server add <server>
Meie puhul on selliseid servereid kaks, seega on kaks meeskonda.
Kontrollime:
Ja määrake meie serveri ajavöönd
DNS
Lisame CMS-i DNS-serverid järgmise käsuga:
dns add forwardzone <domain-name> <server ip>
Meie puhul on selliseid servereid kaks, seega on kaks meeskonda.
Kontrollime:
Võrguliidese konfigureerimine
Konfigureerime liidese järgmise käsuga:
ipv4 <interface> add <address>/<prefix length> <gateway>
Kontrollime:
Serveri nimi (hostinimi)
Seadsime serveri nime järgmise käsuga:
hostname <name>
Ja me taaskäivitame.
See lõpetab põhikonfiguratsiooni.
Sertifikaadid
ТеорияCisco Meeting Server nõuab krüpteeritud sidet erinevate komponentide vahel ja seetõttu on kõigi CMS-i juurutuste jaoks vaja X.509 sertifikaate. Need aitavad tagada, et teised serverid/teenused usaldavad teenuseid/serverit.
Iga teenus nõuab sertifikaati, kuid iga teenuse jaoks eraldi sertifikaatide loomine võib põhjustada segadust ja tarbetut keerukust. Õnneks saame luua sertifikaadi avaliku-privaatvõtmepaari ja seejärel kasutada neid mitmes teenuses. Meie puhul kasutatakse sama sertifikaati Call Bridge, XMPP Server, Web Bridge ja Web Admin jaoks. Seega peate iga klastri serveri jaoks looma avaliku ja privaatse sertifikaadi võtmete paari.
Andmebaasi klastrimisel on aga teatud erinõuded sertifikaadile ja seetõttu on vaja oma sertifikaate, mis erinevad teiste teenuste omadest. CMS kasutab serveri sertifikaati, mis on sarnane teiste serverite kasutatavatele sertifikaatidele, kuid andmebaasiühenduste jaoks on olemas ka kliendi sertifikaat. Andmebaasi sertifikaate kasutatakse nii autentimiseks kui ka krüptimiseks. Selle asemel, et anda kliendile andmebaasiga ühenduse loomiseks kasutajanimi ja parool, esitab see kliendi sertifikaadi, mida server usaldab. Iga andmebaasiklastri server kasutab sama avaliku ja privaatvõtme paari. See võimaldab kõigil klastri serveritel andmeid krüpteerida nii, et neid saavad dekrüpteerida ainult teised sama võtmepaari jagavad serverid.
Koondamise toimimiseks peavad andmebaasiklastrid koosnema vähemalt 3 serverist, kuid mitte rohkem kui viiest serverist, kusjuures maksimaalne edasi-tagasi vaheaeg klastri liikmete vahel on 5 ms. See piirang on piiravam kui Call Bridge klastrite puhul, seega on see sageli piirav tegur geograafiliselt hajutatud juurutustes.
CMS-i andmebaasirollil on mitmeid ainulaadseid nõudeid. Erinevalt teistest rollidest nõuab see kliendi ja serveri sertifikaati, kus kliendi sertifikaadil on konkreetne CN-väli, mis esitatakse serverile.
CMS kasutab postgresi andmebaasi, millel on üks juht ja mitu täiesti identset koopiat. Korraga on ainult üks esmane andmebaas ("andmebaasiserver"). Ülejäänud klastri liikmed on koopiad või "andmebaasi kliendid".
Andmebaasiklastri jaoks on vaja spetsiaalset serveri sertifikaati ja kliendi sertifikaati. Need peavad olema allkirjastatud sertifikaatidega, tavaliselt sisemise erasertifitseerimisasutusega. Kuna iga andmebaasiklastri liige võib saada ülemaks, tuleb andmebaasiserveri ja kliendi sertifikaadi paarid (mis sisaldavad avalikku ja privaatvõtit) kopeerida kõikidesse serveritesse, et nad saaksid omandada kliendi või andmebaasiserveri identiteedi. Lisaks tuleb laadida CA juursertifikaat, et tagada kliendi ja serveri sertifikaatide kontrollimine.
Seega loome sertifikaadi päringu, mida kasutavad kõik serveriteenused, välja arvatud andmebaas (selleks tuleb eraldi taotlus) järgmise käsuga:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
CN-is kirjutame oma serverite üldnimed. Näiteks kui meie serverite hostinimed server01, server02, server03, siis on CN server.example.com
Teeme sama ülejäänud kahes serveris, selle erinevusega, et käsud sisaldavad vastavaid "hostinimesid"
Loome kaks taotlust sertifikaatide jaoks, mida andmebaasiteenus kasutab järgmiste käskudega:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreskus dbclusterserver и dbclusterclient meie taotluste ja tulevaste sertifikaatide nimed, hostinimi1(2)(3) vastavate serverite nimed.
Teeme seda protseduuri ainult ühes serveris (!) ning sertifikaadid ja vastavad .key failid laeme üles teistesse serveritesse.
Kliendi sertifikaadirežiimi lubamine AD CS-is
Samuti peate ühendama iga serveri sertifikaadid üheks failiks.*NIX-is:
cat server01.cer server02.cer server03.cer > server.cerWindowsis/DOS-is:
copy server01.cer + server02.cer + server03.cer server.cer
Ja laadige igasse serverisse üles:
1. “Individuaalne” serveri sertifikaat.
2. Juuretunnistus (koos vahepealsete omadega, kui need on olemas).
3. Andmebaasi sertifikaadid (“server” ja “klient”) ja failid laiendiga .key, mis genereeriti “serveri” ja “kliendi” andmebaasi sertifikaatide päringu koostamisel. Need failid peavad olema kõikides serverites ühesugused.
4. Kõigi kolme “individuaalse” sertifikaadi fail.
Selle tulemusena peaksite igasse serverisse saama midagi selle failipildi taolist.
Andmebaasi klaster
Nüüd, kui teil on kõik sertifikaadid CMS-serveritesse üles laaditud, saate konfigureerida ja lubada andmebaaside rühmitamist kolme sõlme vahel. Esimene samm on valida üks server andmebaasi klastri peasõlmeks ja see täielikult konfigureerida.
Põhiandmebaas
Esimene samm andmebaasi replikatsiooni seadistamisel on määrata andmebaasi jaoks kasutatavad sertifikaadid. Seda tehakse käsuga nagu:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Nüüd ütleme CMS-ile, millist liidest kasutada andmebaasi rühmitamiseks käsuga:
database cluster localnode aSeejärel lähtestame põhiserveris oleva klastri andmebaasi käsuga:
database cluster initialize
Klientide andmebaasi sõlmed
Teeme sama protseduuri, ainult käsu asemel andmebaasi klastri lähtestamine sisestage selline käsk:
database cluster join <ip address existing master>kus ip-aadress CMS-serveri olemasolev peamise IP-aadress, millel klaster initsialiseeriti, lihtsalt Master.
Kontrollime, kuidas meie andmebaasiklaster töötab kõigis serverites käsuga:
database cluster status
Teeme sama ülejäänud kolmandas serveris.
Selle tulemusena selgub, et meie esimene server on Master, ülejäänud on orjad.
Veebiadministraatori teenus
Luba veebiadministraatori teenus:
webadmin listen a 445Port 445 valiti, kuna porti 443 kasutatakse kasutaja juurdepääsuks veebikliendile
Konfigureerime veebiadministraatori teenuse sertifikaadifailidega järgmise käsuga:
webadmin certs <keyfile> <certificatefile> <ca bundle>Ja lubage Web Admin käsuga:
webadmin enable
Kui kõik on korras, saame EDU read, mis näitavad, et veebiadministraator on võrgu ja sertifikaadi jaoks õigesti konfigureeritud. Kontrollime teenuse funktsionaalsust veebibrauseri abil ja sisestame veebiadministraatori aadressi, näiteks: : 445
Helista sillaklastrisse
Call Bridge on ainus teenus, mis on saadaval igas CMS-i juurutuses. Call Bridge on peamine konverentsimehhanism. See pakub ka SIP-liidest, nii et kõnesid saab suunata sinna või sealt näiteks Cisco Unified CM-i abil.
Allpool kirjeldatud käsud tuleb täita igas vastavate sertifikaatidega serveris.
Nii et:
Seome sertifikaadid Call Bridge teenusega järgmise käsuga:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Seome CallBridge'i teenused vajaliku liidesega käsuga:
callbridge listen aJa taaskäivitage teenus käsuga:
callbridge restart
Nüüd, kui meie kõnesillad on konfigureeritud, saame konfigureerida kõnesilla klastrite. Call Bridge klasterdamine erineb andmebaasi või XMPP klasterdamisest. Call Bridge Cluster toetab ilma piiranguteta 2 kuni 8 sõlme. See ei paku mitte ainult koondamist, vaid ka koormuse tasakaalustamist, nii et konverentse saab aktiivselt jaotada Call Bridge serverite vahel intelligentse kõnejaotuse abil. CMS-il on lisafunktsioonid, Call Bridge rühmad ja seotud funktsioonid, mida saab edasiseks haldamiseks kasutada.
Kõnesildade rühmitamine konfigureeritakse peamiselt veebiadministraatori liidese kaudu
Allpool kirjeldatud protseduur tuleb läbi viia igas klastri serveris.
Niisiis,
1. Avage veebis jaotis Configuration > Cluster.
2. In Helista Bridge'i identiteedile Unikaalse nimena sisestage serveri nimele vastav callbridge[01,02,03]. Need nimed on suvalised, kuid peavad olema selle klastri jaoks ainulaadsed. Need on oma olemuselt kirjeldavad, kuna näitavad, et need on serveri identifikaatorid [01,02,03].
3.B Kobarasillad sisestage klastris meie serverite veebiadministraatori URL-id, [01,02,03].example.com:445 väljale Aadress. Täpsustage kindlasti port. Peer link SIP domeeni võite tühjaks jätta.
4. Lisage iga serveri CallBridge usaldussüsteemi sertifikaat, mille failis on kõik meie serverite sertifikaadid, mille me sellesse faili kohe alguses liidasime järgmise käsuga:
callbridge trust cluster <trusted cluster certificate bundle>Ja taaskäivitage teenus käsuga:
callbridge restart
Selle tulemusel peaksite igas serveris saama järgmise pildi:
XMPP klaster
CMS-i XMPP-teenust kasutatakse kogu Cisco Meeting Appsi (CMA), sealhulgas CMA WebRTC veebikliendi registreerimise ja autentimise haldamiseks. Call Bridge ise toimib autentimise eesmärgil ka XMPP-kliendina ja seetõttu tuleb see konfigureerida nagu teised kliendid. XMPP veataluvus on funktsioon, mida on tootmiskeskkondades toetatud alates versioonist 2.1
Allpool kirjeldatud käsud tuleb täita igas vastavate sertifikaatidega serveris.
Nii et:
Seome sertifikaadid XMPP-teenusega järgmise käsuga:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Seejärel määrake kuulamisliides käsuga:
xmpp listen aXMPP-teenus nõuab ainulaadset domeeni. See on kasutajate sisselogimine. Teisisõnu, kui kasutaja proovib CMA rakenduse (või WebRTC-kliendi) kaudu sisse logida, sisestab ta kasutajaID@logindomain. Meie puhul on see userid@conf.example.com. Miks pole see lihtsalt example.com? Meie konkreetse juurutuse puhul valisime oma Unified CM-i domeeni, mida Jabberi kasutajad Unified CM-is kasutavad näiteks example.com, seega vajasime CMS-i kasutajate jaoks teist domeeni, et suunata CMS-i ja sealt välja kõned SIP-domeenide kaudu.
Seadistage XMPP domeen, kasutades sellist käsku:
xmpp domain <domain>Ja lubage XMPP teenus käsuga:
xmpp enableXMPP-teenuses peate looma volikirjad iga kõnesilla jaoks, mida kasutatakse XMPP-teenusega registreerumisel. Need nimed on suvalised (ja ei ole seotud kordumatute nimedega, mille olete konfigureerinud kõnesilla klastrite jaoks). Peate lisama ühte XMPP-serverisse kolm kõnesilda ja seejärel sisestama need mandaadid klastri teistesse XMPP-serveritesse, kuna see konfiguratsioon ei mahu klastri andmebaasi. Hiljem konfigureerime iga kõnesilla kasutama seda nime ja saladust XMPP-teenusega registreerumiseks.
Nüüd peame konfigureerima XMPP-teenuse esimeses serveris kolme kõnesillaga callbridge01, callbridge02 ja callbridge03. Igale kontole määratakse juhuslikud paroolid. Need sisestatakse hiljem sellesse XMPP-serverisse sisselogimiseks teistesse Call Bridge'i serveritesse. Sisestage järgmised käsud:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Selle tulemusena kontrollime, mis juhtus käsuga:
xmpp callbridge list
Täpselt sama pilt peaks pärast allpool kirjeldatud toiminguid ilmuma ka ülejäänud serverites.
Järgmisena lisame ülejäänud kahele serverile täpselt samad sätted, ainult käskudega
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Lisame Secreti väga ettevaatlikult, et sinna ei jääks näiteks lisatühikuid.
Selle tulemusena peaks igal serveril olema sama pilt:
Järgmisena määrame kõigis klastri serverites usaldusväärselt faili, mis sisaldab kõiki kolme sertifikaati, mis on loodud varem järgmise käsuga:
xmpp cluster trust <trust bundle>Lubame xmpp klastri režiimi kõigis klastri serverites käsuga:
xmpp cluster enableKlastri esimeses serveris käivitame xmpp klastri loomise käsuga:
xmpp cluster initializeTeistes serverites lisage xmpp-le klaster järgmise käsuga:
xmpp cluster join <ip address head xmpp server>Kontrollime igas serveris XMPP-klastri loomise edukust igas serveris järgmiste käskudega:
xmpp status
xmpp cluster statusEsimene server:
Teine server:
Kolmas server:
Call Bridge'i ühendamine XMPP-ga
Nüüd, kui XMPP-klaster töötab, peate XMPP-klastriga ühenduse loomiseks konfigureerima Call Bridge'i teenused. See konfigureerimine toimub veebiadministraatori kaudu.
Valige igas serveris Configuration > General ja väljal Ainulaadne Call Bridge'i nimi kirjutage unikaalsed nimed, mis vastavad serverile Call Bridge kõnesild[01,02,03]... Väljas Domeen conf.example.ru ja vastavaid paroole, saate nende järele luurata
mis tahes klastri serveris käsuga:
xmpp callbridge list
Jätke väli „Server” tühjaks Callbridge teostab DNS SRV otsingu _xmpp-component._tcp.conf.example.comsaadaoleva XMPP-serveri leidmiseks. IP-aadressid kõnesildade ühendamiseks XMPP-ga võivad igas serveris erineda, see sõltub sellest, millised väärtused salvestuspäringule tagastatakse _xmpp-component._tcp.conf.example.com callbridge, mis omakorda sõltub antud DNS-kirje prioriteediseadetest.
Järgmisena minge jaotisse Olek > Üldine, et kontrollida, kas teenus Call Bride on XMPP-teenusega edukalt ühendatud.
Veebisild
Igas klastri serveris lubage Web Bridge'i teenus käsuga:
webbridge listen a:443Konfigureerime Web Bridge'i teenuse sertifikaadifailidega järgmise käsuga:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge toetab HTTPS-i. See suunab HTTP ümber HTTPS-i, kui see on konfigureeritud kasutama "http-ümbersuunamist".
HTTP ümbersuunamise lubamiseks kasutage järgmist käsku:
webbridge http-redirect enableKui soovite anda Call Bridge'ile teada, et Web Bridge saab Call Bridge'i ühendusi usaldada, kasutage käsku:
webbridge trust <certfile>kus see on fail, mis sisaldab kõiki kolme klastri iga serveri sertifikaati.
See pilt peaks olema klastri igas serveris.
Nüüd peame looma "appadmin" rolliga kasutaja, vajame seda selleks, et saaksime oma klastrit(!) seadistada, mitte iga klastri serverit eraldi, nii rakenduvad sätted igale serverile võrdselt, hoolimata tõsiasi, et neid tehakse üks kord.
Edasiseks seadistamiseks kasutame .
Autoriseerimiseks valige jaotises Autoriseerimine valik Põhiline
Käskude korrektseks saatmiseks CMS-serverisse peate määrama vajaliku kodeeringu
Täpsustame Webbridge'i käsuga POST parameetriga URL ja tähendus
Veebisillas endas näitame nõutavad parameetrid: külaliste juurdepääs, kaitstud juurdepääs jne.
Helista sillagruppidele
Vaikimisi ei kasuta CMS alati kõige tõhusamalt talle saadaolevaid konverentsiressursse.
Näiteks kolme osalejaga koosoleku puhul võib iga osaleja sattuda kolmele erinevale kõnesillale. Selleks, et need kolm osalejat saaksid omavahel suhelda, loob Call Bridges automaatselt ühendused kõigi samas ruumis olevate serverite ja klientide vahel, nii et kõik tundub, nagu oleksid kõik kliendid samas serveris. Kahjuks on selle negatiivne külg see, et üks 3-liikmeline konverents tarbib nüüd 9 meediaporti. See on ilmselgelt ebaefektiivne ressursside kasutamine. Lisaks, kui kõnesild on tõeliselt ülekoormatud, jätkab vaikemehhanism kõnede vastuvõtmist ja madalama kvaliteediga teenuse pakkumist kõigile selle Call Bridge'i abonentidele.
Need probleemid lahendatakse funktsiooni Call Bridge Group abil. See funktsioon võeti kasutusele Cisco Meeting Serveri tarkvara versioonis 2.1 ja seda on laiendatud, et toetada nii sissetulevate kui ka väljaminevate Cisco Meeting Appi (CMA) kõnede, sealhulgas WebRTC osalejate koormuse tasakaalustamist.
Taasühendamisprobleemi lahendamiseks on iga kõnesilla jaoks kasutusele võetud kolm konfigureeritavat koormuspiirangut:
LoadLimit — see on konkreetse kõnesilla maksimaalne arvkoormus. Igal platvormil on soovitatav koormuspiirang, näiteks CMS96000 puhul 1000 ja virtuaalmasina puhul 1.25 GHz vCPU kohta. Erinevad kõned tarbivad sõltuvalt osaleja eraldusvõimest ja kaadrisagedusest teatud hulga ressursse.
NewConferenceLoadLimitBasisPoints (vaikimisi 50% loadLimit) – määrab serveri koormuspiirangu, mille järel lükatakse uued konverentsid tagasi.
OlemasolevadConferenceLoadLimitBasisPoints (vaikimisi 80% loadLimitist) – serveri laadimise väärtus, mille järel olemasoleva konverentsiga liitunud osalejad tagasi lükatakse.
Kuigi see funktsioon oli mõeldud kõnede jaotamiseks ja koormuse tasakaalustamiseks, saab kõnesillagruppidele määrata ka muid rühmi, nagu TURN-serverid, veebisillaserverid ja salvestid, et neid saaks optimaalseks kasutamiseks ka õigesti rühmitada. Kui mõni neist objektidest ei ole kõnegrupile määratud, eeldatakse, et need on saadaval kõikidele serveritele ilma erilise prioriteedita.
Need parameetrid konfigureeritakse siin: :445/api/v1/system/configuration/cluster
Järgmisena näitame igale kõnesillale, millisesse kõnesillagruppi see kuulub:
Esimene kõnesild
Teine kõnesild
Kolmas kõnesild
Seega konfigureerisime Call Brdige rühma Cisco Meeting Serveri klastri ressursse tõhusamalt kasutama.
Kasutajate importimine Active Directoryst
Veebihalduri teenusel on LDAP-i konfiguratsiooni jaotis, kuid see ei paku keerulisi konfiguratsioonivalikuid ja teavet ei salvestata klastri andmebaasi, seega tuleb konfigureerimine teha kas käsitsi igas serveris veebiliidese kaudu või API ja nii, et me "kolm korda "Ära tõuse", määrame andmed ikkagi API kaudu.
Juurdepääsuks URL-i kasutamine :445/api/v1/ldapServers loovad LDAP-serveri objekti, määrates näiteks järgmised parameetrid:
- Serveri IP
- pordi number
- Kasutajanimi
- parool
- kindlustama
Turvaline – vali olenevalt pordist tõene või väär, 389 – pole turvaline, 636 – kaitstud.
LDAP allika parameetrite vastendamine Cisco Meeting Serveri atribuutidega.
LDAP-i vastendus vastendab LDAP-kataloogis olevad atribuudid CMS-i atribuutidega. Tegelikud atribuudid:
- jidMapping
- nimekaardistamine
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Atribuutide kirjeldusIADB tähistab kasutaja sisselogimise ID-d CMS-is. Kuna tegemist on Microsoft Active Directory LDAP-serveriga, vastendatakse CMS JID LDAP-is sAMAccountName'iga, mis on sisuliselt kasutaja Active Directory sisselogimise ID. Pange tähele ka seda, et kasutate sAMAccountName ja lisate selle lõppu domeeni conf.pod6.cms.lab, kuna see on sisselogimine, mida teie kasutajad CMS-i sisselogimiseks kasutavad.
nimekaardistamine ühtib Active Directory väljal DisplayName sisalduva kasutaja CMS-i nime väljaga.
coSpaceNameMapping loob välja displayName põhjal CMS-i ruumi nime. Seda atribuuti koos atribuudiga coSpaceUriMapping on vaja iga kasutaja jaoks ruumi loomiseks.
coSpaceUriMapping määrab kasutaja isikliku ruumiga seotud URI kasutajaosa. Mõningaid domeene saab konfigureerida kosmosesse valimiseks. Kui kasutajaosa vastab ühele neist domeenidest sellele väljale, suunatakse kõne selle kasutaja ruumi.
coSpaceSecondaryUriMapping määrab ruumi jõudmiseks teise URI. Seda saab kasutada numbrilise varjunime lisamiseks kõnede suunamiseks imporditud kasutaja ruumi alternatiivina coSpaceUriMapping parameetris määratletud tähtnumbrilisele URI-le.
LDAP-server ja LDAP-i vastendus on konfigureeritud. Nüüd peate need omavahel siduma, luues LDAP-allika.
Juurdepääsuks URL-i kasutamine :445/api/v1/ldapSource loob LDAP-i lähteobjekti, määrates näiteks järgmised parameetrid:
- server
- kaardistus
- baseDn
- filtreerida
Nüüd, kui LDAP-i konfigureerimine on lõpetatud, saate käsitsi sünkroonida.
Teeme seda kas iga serveri veebiliideses, klõpsates Sünkroonige kohe lõik Active Directory
või API kaudu käsuga POST kasutades juurdepääsuks URL-i :445/api/v1/ldapSyncs
Ad-hoc konverentsid
Mis see on?Traditsioonilises kontseptsioonis on konverents siis, kui kaks osalejat räägivad omavahel ja üks osalejatest (kasutades Unified CM-is registreeritud seadet) vajutab nuppu "Konverents", helistab teisele inimesele ja pärast selle kolmanda osapoolega rääkimist. , vajutab uuesti nuppu "Konverents". et liituda kõigi kolmepoolse konverentsiga osalejatega.
Ad-hoc-konverentsi CMS-is plaanitud konverentsist eristab see, et ad-hoc-konverents ei ole lihtsalt SIP-kõne CMS-ile. Kui konverentsi algataja klõpsab teist korda nuppu Konverents, et kutsuda kõik samale koosolekule, peab Unified CM tegema API-kõne CMS-ile, et luua lennates konverents, kuhu kõik kõned seejärel üle kantakse. Kõik see juhtub osalejatele märkamatult.
See tähendab, et Unified CM peab kõne jätkamiseks konfigureerima API mandaadid ja teenuse WebAdmini aadressi/pordi ning SIP-i magistraalvõrgu otse CMS-serverisse.
Vajadusel saab CUCM dünaamiliselt luua CMS-is ruumi, et iga kõne jõuaks CMS-i ja vastaks sissetuleva kõne reeglile, mis on mõeldud tühikute jaoks.
Integreerimine CUCM-iga konfigureeritud samamoodi nagu artiklis kirjeldatud välja arvatud see, et Cisco UCM-is peate looma CMS-i jaoks kolm magistraati, kolm konverentsisilda, määrama SIP-turvaprofiilis kolm teemanime, marsruudirühmad, marsruudiloendid, meediumiressursside rühmad ja meediumiressursside rühmade loendid ning lisama mõned marsruutimisreeglid. Cisco koosolekuserverisse.
SIP-turvaprofiil:
Pagasiruumid:
Iga pagasiruum näeb välja sama:
Konverentsi sild
Iga konverentsisild näeb välja sama:
Marsruudirühm
Marsruudiloend
Meediaressursside rühm
Meediaressursside rühmade loend
Kõnereeglid
Erinevalt arenenumatest kõnehaldussüsteemidest, nagu Unified CM või Expressway, otsib CMS uute kõnede jaoks ainult domeeni väljalt SIP Request-URI. Nii et kui SIP INVITE on lonksu jaoks: [meiliga kaitstud]CMS hoolib ainult domeenist.com. CMS järgib neid reegleid, et määrata, kuhu kõne suunata.
1. CMS proovib esmalt sobitada SIP domeeni sissetuleva kõne reeglites konfigureeritud domeenidega. Need kõned saab seejärel suunata („sihitud“) ruumidesse või kindlatesse kasutajatesse, sisemistesse IVR-idesse või otse integreeritud Microsoft Lync/Skype for Business (S4B) sihtkohtadesse.
2. Kui sissetuleva kõne reeglid ei vasta, proovib CMS sobitada kõne suunamise tabelis konfigureeritud domeeni. Sobivuse korral võib reegel kõne selgesõnaliselt tagasi lükata või kõne edasi suunata. Praegu võib CMS domeeni ümber kirjutada, mis on mõnikord kasulik Lynci domeenidele helistamisel. Saate valida ka sööduviske, mis tähendab, et ühtki väljast enam ei muudeta, või kasutada sisemist CMS-i valimisplaani. Kui kõne suunamise reeglid ei vasta, lükatakse vaikimisi kõne tagasi. Pidage meeles, et kuigi CMS-is on kõne "edasi suunatud", on meedium siiski seotud CMS-iga, mis tähendab, et see jääb signaalimis- ja meedialiikluse teele.
Siis kehtivad väljaminevate kõnede reeglid ainult edasisuunatud kõnedele. Need sätted määravad sihtkohad, kuhu kõned saadetakse, magistraalvõrgu tüübi (olgu see uus Lynci kõne või standardne SIP-kõne) ja kõik konversioonid, mida saab teha, kui kõne suunamise reeglis ei ole ülekandmist valitud.
Siin on tegelik logi ad-hoc konverentsi ajal toimuvast
Ekraanipilt näitab seda halvasti (ma ei tea, kuidas seda paremaks muuta), seega kirjutan logi järgmiselt:
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:12Ad-Hoc konverents ise:
Sissetulevate kõnede reeglid
Sissetulevate kõnede parameetrite seadistamine on vajalik CMS-is kõne vastuvõtmiseks. Nagu LDAP-i seadistuses nägite, imporditi kõik kasutajad domeeniga conf.pod6.cms.lab. Nii et vähemalt soovite sellele domeenile helistada, et sihtida ruume. Samuti peate seadistama reeglid kõige jaoks, mis on ette nähtud iga CMS-serveri täielikult kvalifitseeritud domeeninime (ja võib-olla isegi IP-aadressi) jaoks. Meie väline kõnejuhtimine, Unified CM, konfigureerib igale CMS-serverile eraldi SIP-i magistraalid. Sõltuvalt sellest, kas nende SIP magistraalide sihtkoht on IP-aadress või serveri FQDN, määrab, kas CMS tuleb konfigureerida vastu võtma tema IP-aadressile või FQDN-ile suunatud kõnesid.
Domeeni, millel on kõrgeima prioriteediga sissetulev reegel, kasutatakse kõigi kasutajaruumide domeenina. Kui kasutajad sünkroonivad LDAP-i kaudu, loob CMS automaatselt tühikud, kuid ainult URI kasutajaosa (coSpaceUriMapping), näiteks user.space. osa Täielik URI luuakse selle reegli alusel. Tegelikult, kui logiksite sel hetkel sisse Web Bridge'i, näeksite, et ruumi-URI-l pole domeeni. Seades selle reegli kõrgeimaks prioriteediks, määrate loodud tühikute domeeni konf.example.com.
Väljuvate kõnede reeglid
Selleks, et kasutajad saaksid teha ühtsesse CM-i klastrit väljaminevaid kõnesid, peate konfigureerima väljuvad reeglid. Unified CM-is registreeritud lõpp-punktide domeen, nagu Jabber, on example.com. Kõned sellele domeenile tuleks suunata standardsete SIP-kõnedena ühendatud CM-i kõnetöötlussõlmedesse. Põhiserver on cucm-01.example.com ja lisaserver on cucm-02.example.com.
Esimene reegel kirjeldab kõige lihtsamat kõnede marsruutimist klastri serverite vahel.
Väli Kohalik domeenist vastutab selle eest, mida kuvatakse helistaja SIP-URI-s inimese jaoks, kellele helistatakse pärast sümbolit @. Kui jätame selle tühjaks, on sümboli “@” järel CUCM-i IP-aadress, mille kaudu kõne läbib. Kui määrame domeeni, siis pärast sümbolit “@” on tegelikult domeen. See on vajalik tagasihelistamiseks, vastasel juhul ei saa SIP-URI kaudu tagasi helistada nimi@ip-aadress.
Helista, kui määratud Kohalik domeenist
Helista millal EI näidatud Kohalik domeenist
Väljuvate kõnede jaoks määrake kindlasti selgesõnaliselt krüpteeritud või krüptimata, sest parameetriga Auto ei tööta midagi.
Salvestamine
Videokonverentsid salvestab salvestusserver. Salvesti on täpselt sama, mis Cisco koosolekuserver. Salvesti ei nõua litsentside installimist. Salvestuslitsentsid on vajalikud CallBridge'i teenuseid kasutavate serverite jaoks, st. Salvestuslitsents on nõutav ja seda tuleb rakendada CallBridge'i komponendile, mitte salvestajat töötavale serverile. Salvesti käitub XMPP (Extensible Messaging and Presence Protocol) kliendina, seega peab XMPP-server olema CallBridge'i hostivas serveris lubatud.
Sest Meil on klaster ja litsentsi tuleb "venitada" kõigi kolme klastri serveri vahel. Seejärel seostame (lisame) lihtsalt teie isiklikul kontol litsentsides kõigi klastris sisalduvate CMS-serverite a-liideste MAC-aadressid.
Ja see on pilt, mis peaks olema klastri igas serveris
Üldiselt on Salvesti paigutamiseks mitu stsenaariumi, kuid me jääme selle juurde:
Enne Salvesti seadistamist peate ette valmistama koha, kus videokonverentse tegelikult salvestatakse. Tegelikult siin , kuidas seadistada kõiki salvestusi. Keskendun olulistele punktidele ja detailidele:
1. Sertifikaat on parem klastri esimesest serverist.
2. Tõrge „Salvestaja pole saadaval” võib ilmneda, kuna salvesti usaldusväärsuses on määratud vale sertifikaat.
3. Kirjutamine ei pruugi töötada, kui salvestamiseks määratud NFS-kataloog ei ole juurkataloog.
Mõnikord on vaja ühe konkreetse kasutaja või ruumi konverents automaatselt salvestada.
Selleks luuakse kaks kõneprofiili:
Kui salvestamine on keelatud
Ja automaatse salvestusfunktsiooniga
Järgmiseks “kinnitame” vajalikule kohale automaatse salvestusfunktsiooniga CallProfile’i.
CMS-is on kehtestatud nii, et kui kõneprofiil on otseselt seotud mis tahes tühiku või tühikuga, töötab see kõneprofiil ainult nende konkreetsete ruumide puhul. Ja kui kõneprofiil ei ole seotud ühegi tühikuga, siis vaikimisi rakendatakse seda nendele tühikutele, millega ükski kõneprofiil pole otseselt seotud.
Järgmisel korral proovin kirjeldada, kuidas CMS-ile pääseb juurde väljaspool organisatsiooni sisevõrku.
Allikad:
Allikas: www.habr.com