In hierdie uitgawe sal ek sommige van die ingewikkeldhede van die opstel van 'n CMS-bediener in failover-klustermodus wys en verduidelik.
teorieOor die algemeen is daar drie tipes CMS-bedienerontplooiing:
- Enkel gekombineer(Enkel gekombineer), m.a.w. dit is een bediener waarop al die nodige dienste loop. In die meeste gevalle is hierdie tipe ontplooiing slegs geskik vir interne kliënttoegang en in kleiner omgewings waar die skaalbaarheid en oortolligheidsbeperkings van 'n enkele bediener nie 'n kritieke kwessie is nie, of in situasies waar die CMS slegs sekere funksies verrig, soos ad hoc konferensies oor Cisco UCM.
Geskatte skema van werk:
- Enkel Split(Single Split) brei die vorige ontplooiingstipe uit deur 'n aparte bediener vir eksterne toegang by te voeg. In verouderde ontplooiings het dit beteken die ontplooiing van 'n CMS-bediener in 'n gedemilitariseerde netwerksegment (DMZ) waar eksterne kliënte toegang daartoe kon kry, en een CMS-bediener in die netwerkkern waar interne kliënte toegang tot die CMS kon kry. Hierdie spesifieke ontplooiingsmodel word nou vervang deur die sogenaamde tipe Enkelrand, wat uit bedieners bestaan Cisco snelweg, wat óf baie van dieselfde Firewall-omleidingsvermoëns het óf sal hê, sodat kliënte nie 'n toegewyde rand CMS-bediener hoef by te voeg nie.
Geskatte skema van werk:
- Skaalbaar en veerkragtig(Skaalbaar en fouttolerant) Hierdie tipe sluit oortolligheid vir elke komponent in, wat die stelsel in staat stel om met jou behoeftes tot sy maksimum kapasiteit te groei terwyl dit oortolligheid verskaf in geval van mislukking. Dit gebruik ook die Single Edge-konsep om veilige eksterne toegang te verskaf. Dit is die tipe waarna ons in hierdie episode sal kyk. As ons verstaan hoe om hierdie tipe groepering te ontplooi, sal ons nie net ander tipes ontplooiings verstaan nie, maar ons sal ook kan verstaan hoe om groepe CMS-bedieners te skep om potensiële groei in aanvraag te akkommodeer.
Voordat jy aangaan met ontplooiing, moet jy 'n paar basiese dinge verstaan, naamlik
Hoof CMS sagteware komponente:
- Databasis: Laat jou toe om sommige konfigurasies te kombineer, soos skakelplan, gebruikersruimtes en gebruikers self. Ondersteun slegs groepering vir hoë beskikbaarheid (enkel meester).
- Bel Bridge: 'n diens vir oudio- en videokonferensies wat volle beheer oor die bestuur en verwerking van oproepe en multimediaprosesse bied. Ondersteun groepering vir hoë beskikbaarheid en skaalbaarheid.
- XMPP-bediener: verantwoordelik vir registrasie en verifikasie van kliënte wat die Cisco Meeting Application en/of WebRTC(intydse kommunikasie, of bloot in die blaaier), sowel as interkomponent sein. Kan slegs gegroepeer word vir hoë beskikbaarheid.
- Webbrug: Verskaf kliënttoegang tot WebRTC.
- Loadbalanseerder: Verskaf 'n enkele verbindingspunt vir Cisco Meeting Apps in Enkel Split-modus. Luister na die eksterne koppelvlak en poort vir inkomende verbindings. Die lasbalanseerder aanvaar eweneens inkomende TLS-verbindings vanaf die XMPP-bediener, waardeur dit TCP-verbindings van eksterne kliënte kan verander.
In ons scenario sal dit nie nodig wees nie. - TURN bediener: Verskaf Firewall-omseiltegnologie wat dit toelaat
plaas ons CMS agter 'n Firewall of NAT om eksterne kliënte met behulp van Cisco Meeting App of SIP-toestelle te verbind. In ons scenario sal dit nie nodig wees nie. - Web Admin: Administratiewe koppelvlak en API-toegang, insluitend vir spesiale Unified CM-konferensies.
Konfigurasiemodusse
Anders as die meeste ander Cisco-produkte, ondersteun Cisco Meeting Server drie konfigurasiemetodes om enige tipe ontplooiing te akkommodeer.
- Opdragreël (CLI): Command line koppelvlak bekend as MMP vir aanvanklike konfigurasie en sertifikaat take.
- Web administrateur: Hoofsaaklik vir CallBridge-verwante konfigurasies, veral wanneer 'n enkele nie-gegroepeerde bediener opgestel word.
- REST API: Word gebruik vir die mees komplekse konfigurasietake en gegroepeerde databasisverwante take.
Benewens bogenoemde word die protokol gebruik SFTP om lêers—gewoonlik lisensies, sertifikate of logboeke—na en van die CMS-bediener oor te dra.
In ontplooiingsgidse van Cisco is dit in wit en Engels geskryf dat die cluster ontplooi moet word ten minste drie bedieners (nodes) in die konteks van databasisse. Omdat Slegs met 'n onewe aantal nodusse sal die meganisme vir die keuse van 'n nuwe databasismeester werk, en oor die algemeen het die databasismeester 'n verbinding met die meeste van die CMS-bedienerdatabasis.
En soos die praktyk toon, is twee bedieners (nodes) regtig nie heeltemal genoeg nie. Die seleksiemeganisme werk wanneer die Meester herlaai word, die Slaafbediener word eers Meester nadat die herlaaide bediener opgebring is. As die Meesterbediener egter skielik in 'n groep van twee bedieners uitgaan, sal die Slaafbediener nie die Meester word nie, en as die Slaaf uitgaan, sal die oorblywende Meesterbediener die Slaaf word.
Maar in die konteks van XMPP sou dit regtig nodig wees om 'n groep van drie bedieners saam te stel, want as jy byvoorbeeld die XMPP-diens deaktiveer op een van die bedieners waarin XMMP in Leier-status is, sal XMPP op die oorblywende bediener in Volger-status bly en CallBridge-verbindings na XMPP sal afval, want CallBridge koppel eksklusief aan XMPP met leierstatus. En dit is van kritieke belang, want ... nie 'n enkele oproep sal deurgaan nie.
Ook in dieselfde ontplooiingsgidse word 'n groepering met een XMPP-bediener gedemonstreer.
En met inagneming van bogenoemde, word dit duidelik hoekom: dit werk omdat dit in failover-modus is.
In ons geval sal die XMPP-bediener op al drie nodusse teenwoordig wees.
Daar word aanvaar dat al drie ons bedieners op is.
DNS rekords
Voordat jy begin met die opstel van bedieners, moet jy DNS-rekords skep А и SRV tipes:
Neem asseblief kennis dat daar in ons DNS-rekords twee domeine is example.com en conf.voorbeeld.com. Voorbeeld.com is 'n domein wat alle Cisco Unified Communication Manager-intekenare kan gebruik vir hul URI's, wat heel waarskynlik in jou infrastruktuur teenwoordig is of waarskynlik teenwoordig sal wees. Of example.com pas by dieselfde domein wat gebruikers vir hul e-posadresse gebruik. Of die Jabber-kliënt op jou skootrekenaar het dalk 'n URI [e-pos beskerm]. domein conf.example.com is die domein wat vir Cisco Meeting Server-gebruikers opgestel sal word. Die domein van die Cisco Meeting Server sal wees conf.example.com, dus vir dieselfde Jabber-gebruiker sal die gebruiker@ URI gebruik moet word om by Cisco Meeting Server aan te meldconf.voorbeeld.com.
Basiese konfigurasie
Alle instellings wat hieronder beskryf word, word op een bediener gewys, maar dit moet op elke bediener in die groep gedoen word.
QoS
Sedert die CMS genereer real-time verkeer sensitief vir vertragings en pakkieverlies, in die meeste gevalle word dit aanbeveel om kwaliteit van diens (QoS) op te stel. Om dit te bereik, ondersteun die CMS merker van pakkies met die Differentiated Services Codes (DSCP's) wat dit genereer. Alhoewel DSCP-gebaseerde verkeersprioritisering afhang van hoe die verkeer deur die netwerkkomponente van jou infrastruktuur verwerk word, sal ons in ons geval ons CMS opstel met tipiese DSCP-prioritisering gebaseer op QoS-beste praktyke.
Op elke bediener sal ons hierdie opdragte invoer
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ADus, alle videoverkeer is gemerk AF41 (DSCP 0x22), alle stemverkeer is gemerk EF (DSCP 0x2E), ander tipes lae latensieverkeer soos SIP en XMPP gebruik AF31 (DSCP 0x1A).
Ons kyk na:
NTP
Netwerktydprotokol (NTP) is nie net belangrik vir die verskaffing van akkurate tydstempels van oproepe en konferensies nie, maar ook om sertifikate te verifieer.
Voeg NTP-bedieners by jou infrastruktuur met 'n opdrag soos
ntp server add <server>
In ons geval is daar twee sulke bedieners, so daar sal twee spanne wees.
Ons kyk na:
En stel die tydsone vir ons bediener in
DNS
Ons voeg DNS-bedieners by die CMS met 'n opdrag soos:
dns add forwardzone <domain-name> <server ip>
In ons geval is daar twee sulke bedieners, so daar sal twee spanne wees.
Ons kyk na:
Netwerkkoppelvlakkonfigurasie
Ons konfigureer die koppelvlak met 'n opdrag soos:
ipv4 <interface> add <address>/<prefix length> <gateway>
Ons kyk na:
Bedienernaam (gasheernaam)
Ons stel die bediener naam met 'n opdrag soos:
hostname <name>
En ons herlaai.
Dit voltooi die basiese konfigurasie.
Sertifikate
teorieCisco Meeting Server vereis geënkripteerde kommunikasie tussen verskeie komponente, en gevolglik word X.509-sertifikate vir alle CMS-ontplooiings vereis. Hulle help om te verseker dat die dienste/bediener deur ander bedieners/dienste vertrou word.
Elke diens vereis 'n sertifikaat, maar die skep van aparte sertifikate vir elke diens kan tot verwarring en onnodige kompleksiteit lei. Gelukkig kan ons 'n sertifikaat se publiek-private sleutelpaar genereer en dit dan oor verskeie dienste hergebruik. In ons geval sal dieselfde sertifikaat gebruik word vir Call Bridge, XMPP Server, Web Bridge en Web Admin. U moet dus 'n paar publieke en private sertifikaatsleutels vir elke bediener in die groep skep.
Databasisgroepering het egter 'n paar spesiale sertifikaatvereistes en vereis dus sy eie sertifikate wat verskil van dié van die ander dienste. CMS gebruik 'n bedienersertifikaat, wat soortgelyk is aan die sertifikate wat deur ander bedieners gebruik word, maar daar is ook 'n kliëntsertifikaat wat vir databasisverbindings gebruik word. Databasissertifikate word vir beide verifikasie en enkripsie gebruik. In plaas daarvan om 'n gebruikersnaam en wagwoord vir die kliënt te verskaf om aan die databasis te koppel, bied dit 'n kliëntsertifikaat aan wat deur die bediener vertrou word. Elke bediener in die databasiskluster sal dieselfde publieke en private sleutelpaar gebruik. Dit laat alle bedieners in die groepering toe om data op so 'n manier te enkripteer dat dit slegs deur ander bedieners gedekripteer kan word wat ook dieselfde sleutelpaar deel.
Vir oortolligheid om te werk, moet databasisklusters uit 'n minimum van 3 bedieners bestaan, maar nie meer as 5 nie, met 'n maksimum retoertyd van 200 ms tussen enige groeplede. Hierdie limiet is meer beperkend as vir Call Bridge-groepering, so dit is dikwels die beperkende faktor in geografies verspreide ontplooiings.
Die databasisrol vir 'n CMS het 'n aantal unieke vereistes. Anders as ander rolle, vereis dit 'n kliënt- en bedienersertifikaat, waar die kliëntsertifikaat 'n spesifieke CN-veld het wat aan die bediener aangebied word.
Die CMS gebruik 'n postgres-databasis met een meester en verskeie heeltemal identiese replikas. Daar is net een primêre databasis op 'n slag (die "databasisbediener"). Die oorblywende lede van die groepering is replikas of "databasiskliënte".
'n Databasiskluster vereis 'n toegewyde bedienersertifikaat en 'n kliëntsertifikaat. Hulle moet onderteken word deur sertifikate, gewoonlik 'n interne private sertifikaatowerheid. Omdat enige lid van die databasiskluster die meester kan word, moet die databasisbediener en kliëntsertifikaatpare (wat die publieke en private sleutels bevat) na alle bedieners gekopieer word sodat hulle die identiteit van die kliënt of databasisbediener kan aanneem. Daarbenewens moet die CA-wortelsertifikaat gelaai word om te verseker dat die kliënt- en bedienersertifikate geverifieer kan word.
Dus, ons skep 'n versoek vir 'n sertifikaat wat deur alle bedienerdienste gebruik sal word behalwe die databasis (daar sal 'n aparte versoek hiervoor wees) met 'n opdrag soos:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
In CN skryf ons die algemene naam van ons bedieners. Byvoorbeeld, as die gasheername van ons bedieners bediener01, bediener02, bediener03, dan sal CN wees bediener.voorbeeld.com
Ons doen dieselfde op die oorblywende twee bedieners met die verskil dat die opdragte die ooreenstemmende "gasheername" sal bevat
Ons genereer twee versoeke vir sertifikate wat deur die databasisdiens gebruik sal word met opdragte soos:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreswaar dbclusterbediener и dbclusterkliënt name van ons versoeke en toekomstige sertifikate, gasheernaam1(2)(3) name van die ooreenstemmende bedieners.
Ons voer hierdie prosedure slegs op een bediener (!) uit en ons sal die sertifikate en ooreenstemmende .key-lêers na ander bedieners oplaai.
Aktiveer kliëntsertifikaatmodus in AD CS
U moet ook die sertifikate vir elke bediener in een lêer saamvoeg.Op *NIX:
cat server01.cer server02.cer server03.cer > server.cerOp Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
En laai op na elke bediener:
1. “Individuele” bedienersertifikaat.
2. Wortelsertifikaat (saam met intermediêres, indien enige).
3. Sertifikate vir die databasis ("bediener" en "kliënt") en lêers met die .key-uitbreiding, wat gegenereer is toe 'n versoek vir die "bediener" en "kliënt" databasissertifikate geskep is. Hierdie lêers moet dieselfde wees op alle bedieners.
4. Lêer van al drie “individuele” sertifikate.
As gevolg hiervan, behoort u iets soos hierdie lêerprent op elke bediener te kry.
Databasisgroepering
Noudat jy al die sertifikate na die CMS-bedieners opgelaai het, kan jy databasisgroepering tussen die drie nodusse instel en aktiveer. Die eerste stap is om een bediener as die hoofnodus van die databasiskluster te kies en dit volledig op te stel.
Meester databasis
Die eerste stap in die opstel van databasisreplikasie is om die sertifikate te spesifiseer wat vir die databasis gebruik sal word. Dit word gedoen met behulp van 'n opdrag soos:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Kom ons vertel nou vir die CMS watter koppelvlak om te gebruik vir databasisgroepering met die opdrag:
database cluster localnode aDan inisialiseer ons die groepdatabasis op die hoofbediener met die opdrag:
database cluster initialize
Kliëntdatabasis nodes
Ons doen dieselfde prosedure, net in plaas van die opdrag databasiskluster inisialiseer voer 'n opdrag in soos:
database cluster join <ip address existing master>waar ip-adres bestaande meester-ip-adres van die CMS-bediener waarop die groep geïnisialiseer is, eenvoudig Meester.
Ons kyk hoe ons databasiskluster op alle bedieners werk met die opdrag:
database cluster status
Ons doen dieselfde op die oorblywende derde bediener.
As gevolg hiervan, blyk dit dat ons eerste bediener die Meester is, die res is Slawe.
Webadministrasiediens
Aktiveer die webadministrateurdiens:
webadmin listen a 445Poort 445 is gekies omdat poort 443 gebruik word vir gebruikerstoegang tot die webkliënt
Ons konfigureer die Web Admin-diens met sertifikaatlêers met 'n opdrag soos:
webadmin certs <keyfile> <certificatefile> <ca bundle>En aktiveer Web Admin met die opdrag:
webadmin enable
As alles goed is, sal ons SUKSES-lyne ontvang wat aandui dat Web Admin korrek opgestel is vir die netwerk en sertifikaat. Ons kontroleer die funksionaliteit van die diens met behulp van 'n webblaaier en voer die adres van die webadministrateur in, byvoorbeeld: : 445
Bel Bridge Cluster
Call Bridge is die enigste diens wat in elke CMS-ontplooiing teenwoordig is. Call Bridge is die belangrikste konferensiemeganisme. Dit bied ook 'n SIP-koppelvlak sodat oproepe daarheen of daarvandaan herlei kan word deur byvoorbeeld 'n Cisco Unified CM.
Die opdragte wat hieronder beskryf word, moet op elke bediener uitgevoer word met die toepaslike sertifikate.
Dus:
Ons assosieer sertifikate met die Call Bridge-diens met 'n opdrag soos:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Ons bind CallBridge-dienste aan die koppelvlak wat ons benodig met die opdrag:
callbridge listen aEn herbegin die diens met die opdrag:
callbridge restart
Noudat ons ons Call Bridges opgestel het, kan ons Call Bridge-groepering instel. Oproepbruggroepering verskil van databasis- of XMPP-groepering. Call Bridge Cluster kan van 2 tot 8 nodusse ondersteun sonder enige beperkings. Dit bied nie net oortolligheid nie, maar ook lasbalansering sodat konferensies aktief oor Call Bridge-bedieners versprei kan word deur intelligente oproepverspreiding te gebruik. Die CMS het bykomende kenmerke, Call Bridge-groepe en verwante kenmerke wat vir verdere bestuur gebruik kan word.
Oproepbruggroepering word hoofsaaklik deur die webadministrasie-koppelvlak gekonfigureer
Die prosedure wat hieronder beskryf word, moet op elke bediener in die groep uitgevoer word.
So,
1. Gaan deur die web na Configuration > Cluster.
2. In Bel Bridge-identiteit As 'n unieke naam, voer callbridge[01,02,03] in wat ooreenstem met die bedienernaam. Hierdie name is arbitrêr, maar moet uniek wees vir hierdie groepering. Hulle is beskrywend van aard omdat hulle aandui dat hulle bedieneridentifiseerders [01,02,03] is.
3.B Gegroepeerde oproepbrûe voer die webadministrateur-URL'e van ons bedieners in die groep in, [01,02,03].example.com:445, in die adresveld. Maak seker dat jy die poort spesifiseer. U kan eweknieskakel SIP-domein leeg laat.
4. Voeg 'n sertifikaat by die CallBridge-trust van elke bediener, waarvan die lêer al die sertifikate van ons bedieners bevat, wat ons heel aan die begin in hierdie lêer saamgevoeg het, met 'n opdrag soos:
callbridge trust cluster <trusted cluster certificate bundle>En herbegin die diens met die opdrag:
callbridge restart
As gevolg hiervan, op elke bediener behoort jy hierdie prentjie te kry:
XMPP-groepering
Die XMPP-diens in die CMS word gebruik om alle registrasie en verifikasie vir Cisco Meeting Apps (CMA) te hanteer, insluitend die CMA WebRTC-webkliënt. Die Call Bridge self tree ook op as 'n XMPP-kliënt vir stawingsdoeleindes en moet dus opgestel word soos ander kliënte. XMPP-fouttoleransie is 'n kenmerk wat sedert weergawe 2.1 in produksieomgewings ondersteun word
Die opdragte wat hieronder beskryf word, moet op elke bediener uitgevoer word met die toepaslike sertifikate.
Dus:
Ons assosieer sertifikate met die XMPP-diens met 'n opdrag soos:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Definieer dan die luisterkoppelvlak met die opdrag:
xmpp listen aDie XMPP-diens vereis 'n unieke domein. Dit is die aanmelding vir gebruikers. Met ander woorde, wanneer 'n gebruiker probeer aanmeld met die CMA-toepassing (of deur die WebRTC-kliënt), voer hulle gebruikerID@logindomein in. In ons geval sal dit userid@ weesconf.voorbeeld.com. Hoekom is dit nie net example.com nie? In ons spesifieke ontplooiing het ons ons Unified CM-domein gekies wat Jabber-gebruikers in Unified CM as example.com sal gebruik, so ons het 'n ander domein nodig gehad vir CMS-gebruikers om oproepe na en van die CMS deur SIP-domeine te stuur.
Stel 'n XMPP-domein op met 'n opdrag soos:
xmpp domain <domain>En aktiveer die XMPP-diens met die opdrag:
xmpp enableIn die XMPP-diens moet jy geloofsbriewe skep vir elke Call Bridge wat gebruik sal word wanneer jy by die XMPP-diens registreer. Hierdie name is arbitrêr (en hou nie verband met die unieke name wat jy vir oproepbruggroepering opgestel het nie). Jy moet drie oproepbrûe op een XMPP-bediener byvoeg en dan daardie geloofsbriewe op ander XMPP-bedieners in die groepie invoer omdat hierdie konfigurasie nie in die groepdatabasis pas nie. Later sal ons elke oproepbrug opstel om hierdie naam en geheim te gebruik om by die XMPP-diens te registreer.
Nou moet ons die XMPP-diens op die eerste bediener opstel met drie Call Bridges callbridge01, callbridge02 en callbridge03. Elke rekening sal ewekansige wagwoorde toegeken word. Hulle sal later op ander Call Bridge-bedieners ingevoer word om by hierdie XMPP-bediener aan te meld. Voer die volgende opdragte in:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03As gevolg hiervan, kyk ons wat gebeur het met die opdrag:
xmpp callbridge list
Presies dieselfde prentjie moet op die oorblywende bedieners verskyn na die stappe wat hieronder beskryf word.
Vervolgens voeg ons presies dieselfde instellings op die oorblywende twee bedieners by, net met die opdragte
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Ons voeg Geheim baie versigtig by sodat daar byvoorbeeld geen ekstra spasies daarin is nie.
As gevolg hiervan moet elke bediener dieselfde prentjie hê:
Vervolgens, op alle bedieners in die groepie, spesifiseer ons in vertroue die lêer wat al drie sertifikate bevat, wat vroeër geskep is met 'n opdrag soos hierdie:
xmpp cluster trust <trust bundle>Ons aktiveer xmpp cluster mode op alle cluster bedieners met die opdrag:
xmpp cluster enableOp die eerste bediener van die groep begin ons die skepping van 'n xmpp-groepering met die opdrag:
xmpp cluster initializeVoeg op ander bedieners 'n groep by xmpp met 'n opdrag soos:
xmpp cluster join <ip address head xmpp server>Ons kyk op elke bediener na die sukses van die skep van 'n XMPP-groepering op elke bediener met die opdragte:
xmpp status
xmpp cluster statusEerste bediener:
Tweede bediener:
Derde bediener:
Koppel Call Bridge aan XMPP
Noudat die XMPP-kluster loop, moet jy die Call Bridge-dienste opstel om aan die XMPP-cluster te koppel. Hierdie konfigurasie word deur die webadministrateur gedoen.
Gaan op elke bediener na Configuration > General en in die veld Unieke Call Bridge naam skryf unieke Call Bridge name wat ooreenstem met die bediener callbridge[01,02,03]... In die veld Domain conf.example.ru en ooreenstemmende wagwoorde, jy kan daarop spioeneer
op enige bediener in die groep met die opdrag:
xmpp callbridge list
Laat die "Server" veld leeg Oproepbrug sal 'n DNS SRV-soektog uitvoer vir _xmpp-komponent._tcp.conf.example.comom 'n beskikbare XMPP-bediener te vind. Die IP-adresse vir die koppeling van callbridges aan XMPP kan op elke bediener verskil, dit hang af van watter waardes na die rekordversoek teruggestuur word _xmpp-komponent._tcp.conf.example.com callbridge, wat op sy beurt afhang van die prioriteitinstellings vir 'n gegewe DNS-rekord.
Gaan dan na Status > Algemeen om te verifieer of die Call Bride-diens suksesvol aan die XMPP-diens gekoppel is.
Webbrug
Aktiveer die Web Bridge-diens op elke bediener in die groepering met die opdrag:
webbridge listen a:443Ons konfigureer die Web Bridge-diens met sertifikaatlêers met 'n opdrag soos:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge ondersteun HTTPS. Dit sal HTTP na HTTPS herlei as dit opgestel is om "http-redirect" te gebruik.
Gebruik die volgende opdrag om HTTP-herleiding te aktiveer:
webbridge http-redirect enableOm Call Bridge te laat weet dat Web Bridge verbindings vanaf Call Bridge kan vertrou, gebruik die opdrag:
webbridge trust <certfile>waar dit 'n lêer is wat al drie sertifikate van elke bediener in die groepie bevat.
Hierdie prentjie moet op elke bediener in die groep wees.
Nou moet ons 'n gebruiker skep met die "appadmin" rol, ons het dit nodig sodat ons ons cluster(!) kan konfigureer en nie elke bediener in die cluster afsonderlik nie, op hierdie manier sal die instellings ewe op elke bediener toegepas word ten spyte van die feit dat hulle een keer gemaak sal word.
Vir verdere opstelling sal ons gebruik .
Vir magtiging, kies Basies in die magtiging afdeling
Om opdragte korrek na die CMS-bediener te stuur, moet jy die vereiste enkodering stel
Ons spesifiseer Webbridge met die opdrag POS met parameter url en betekenis
In die webbrug self dui ons die vereiste parameters aan: gastoegang, beskermde toegang, ens.
Bel Bridge Groups
By verstek maak die CMS nie altyd die doeltreffendste gebruik van die konferensiehulpbronne wat daarvoor beskikbaar is nie.
Byvoorbeeld, vir 'n vergadering met drie deelnemers, kan elke deelnemer op drie verskillende Oproepbrûe beland. Ten einde hierdie drie deelnemers met mekaar te kan kommunikeer, sal Call Bridges outomaties verbindings tussen alle bedieners en kliënte in dieselfde ruimte vestig, sodat dit alles lyk asof alle kliënte op dieselfde bediener is. Ongelukkig is die nadeel hiervan dat 'n enkele 3-persoon konferensie nou 9 mediapoorte sal verbruik. Dit is natuurlik 'n ondoeltreffende gebruik van hulpbronne. Daarbenewens, wanneer 'n Oproepbrug werklik oorlaai is, is die verstekmeganisme om voort te gaan om oproepe te aanvaar en verminderde kwaliteit diens aan alle intekenare van daardie Oproepbrug te verskaf.
Hierdie probleme word opgelos deur die Call Bridge Group-funksie te gebruik. Hierdie kenmerk is bekendgestel in weergawe 2.1 van Cisco Meeting Server-sagteware en is uitgebrei om lasbalansering te ondersteun vir beide inkomende en uitgaande Cisco Meeting App (CMA)-oproepe, insluitend WebRTC-deelnemers.
Om die heraansluitingsprobleem op te los, is drie konfigureerbare laslimiete vir elke oproepbrug ingestel:
Laailimiet — dit is die maksimum numeriese las vir 'n spesifieke Oproepbrug. Elke platform het 'n aanbevole laslimiet, soos 96000 vir die CMS1000 en 1.25 GHz per vCPU vir die virtuele masjien. Verskillende oproepe verbruik 'n sekere hoeveelheid hulpbronne, afhangende van die resolusie en raamtempo van die deelnemer.
NewConferenceLoadLimitBasisPoints (verstek 50% loadLimit) - stel die bedienerladingslimiet, waarna nuwe konferensies afgekeur word.
Bestaande ConferenceLoadLimitBasisPoints (verstek 80% van loadLimit) - die bedienerlaaiwaarde waarna deelnemers wat by 'n bestaande konferensie aansluit, verwerp sal word.
Terwyl hierdie kenmerk ontwerp is vir oproepverspreiding en lasbalansering, kan ander groepe soos TURN Servers, Web Bridge Servers en Recorders ook aan Call Bridge Groups toegewys word sodat hulle ook behoorlik gegroepeer kan word vir optimale gebruik. As enige van hierdie voorwerpe nie aan 'n oproepgroep toegewys is nie, word aanvaar dat dit beskikbaar is vir alle bedieners sonder enige spesifieke prioriteit.
Hierdie parameters word hier gekonfigureer: :445/api/v1/system/configuration/cluster
Vervolgens dui ons aan elke oproepbrug aan watter oproepbruggroep dit behoort:
Eerste oproepbrug
Tweede oproepbrug
Derde oproepbrug
Ons het dus die Call Brdige-groep gekonfigureer om die hulpbronne van die Cisco Meeting Server-kluster doeltreffender te gebruik.
Voer gebruikers in vanaf Active Directory
Die Web Admin-diens het 'n LDAP-konfigurasie-afdeling, maar dit bied nie komplekse konfigurasie-opsies nie, en die inligting word nie in die groepdatabasis gestoor nie, dus opstelling sal gedoen moet word, hetsy handmatig op elke bediener via die webkoppelvlak, of deur die API, en sodat ons "drie keer "Moenie opstaan nie" sal ons steeds die data via die API stel.
Gebruik URL om toegang te verkry :445/api/v1/ldapServers skep 'n LDAP-bedienerobjek, wat parameters spesifiseer soos:
- Bediener IP
- poortnommer
- gebruiker naam
- пароль
- verseker
Veilig - kies waar of onwaar, afhangende van die poort, 389 - nie veilig nie, 636 - beskerm.
Kartering van LDAP-bronparameters aan eienskappe in Cisco Meeting Server.
Die LDAP-kartering karteer die eienskappe in die LDAP-gids na die eienskappe in die CMS. Die werklike eienskappe:
- jidMapping
- naamMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskrywing van eienskappeIADB verteenwoordig die gebruiker se aanmeld-ID in die CMS. Aangesien dit 'n Microsoft Active Directory LDAP-bediener is, word die CMS JID na die sAMAccountName in LDAP gekoppel, wat in wese die gebruiker se Active Directory-aanmelding-ID is. Neem ook kennis dat jy sAMAccountName neem en die domein conf.pod6.cms.lab aan die einde daarvan voeg, want dit is die aanmelding wat jou gebruikers sal gebruik om by die CMS aan te meld.
naamMapping pas wat vervat is in die Active Directory-vertoonnaam-veld by die gebruiker se CMS-naamveld.
coSpaceNameMapping skep 'n CMS-spasienaam gebaseer op die vertoonnaam-veld. Hierdie kenmerk, saam met die coSpaceUriMapping-kenmerk, is wat nodig is om 'n spasie vir elke gebruiker te skep.
coSpaceUriMapping definieer die gebruikerdeel van die URI wat met die gebruiker se persoonlike ruimte geassosieer word. Sommige domeine kan gekonfigureer word om na die spasie geskakel te word. As die gebruikerdeel by hierdie veld vir een van hierdie domeine pas, sal die oproep na daardie gebruiker se spasie gerig word.
coSpaceSecondaryUriMapping definieer 'n tweede URI om ruimte te bereik. Dit kan gebruik word om 'n numeriese alias by te voeg om oproepe na die ingevoerde gebruiker se spasie te stuur as 'n alternatief vir die alfanumeriese URI wat in die coSpaceUriMapping-parameter gedefinieer is.
Die LDAP-bediener en LDAP-kartering is gekonfigureer. Nou moet jy hulle aan mekaar koppel deur 'n LDAP-bron te skep.
Gebruik URL om toegang te verkry :445/api/v1/ldapSource skep 'n LDAP-bronobjek, wat parameters spesifiseer soos:
- bediener
- karteer
- basisDn
- filter
Noudat die LDAP-konfigurasie voltooi is, kan jy die handmatige sinchronisasiebewerking uitvoer.
Ons doen dit óf in die webkoppelvlak van elke bediener deur te klik Sinkroniseer nou artikel Active Directory
of via die API met die opdrag POS gebruik URL om toegang te verkry :445/api/v1/ldapSyncs
Ad-hoc konferensies
Wat is dit?In die tradisionele konsep is 'n konferensie wanneer twee deelnemers met mekaar praat, en een van die deelnemers (met behulp van 'n toestel wat by Unified CM geregistreer is) die "Konferensie"-knoppie druk, die ander persoon bel, en nadat hy met daardie derde party gepraat het , druk weer die "Konferensie"-knoppie. om by alle deelnemers aan die drieledige konferensie aan te sluit.
Wat 'n Ad-Hoc-konferensie van 'n geskeduleerde konferensie in 'n CMS onderskei, is dat 'n Ad-Hoc-konferensie nie net 'n SIP-oproep na die CMS is nie. Wanneer die konferensie-inisieerder 'n tweede keer op die Konferensie-knoppie klik om almal na dieselfde vergadering te nooi, moet Unified CM 'n API-oproep na die CMS maak om 'n on-the-fly-konferensie te skep waarna alle oproepe dan oorgedra word. Dit alles gebeur ongemerk deur die deelnemers.
Dit beteken dat Unified CM die API-geloofsbriewe en WebAdmin-adres/poort van die diens sowel as die SIP-trunk direk na die CMS-bediener moet konfigureer om die oproep voort te sit.
Indien nodig, kan CUCM dinamies 'n spasie in die CMS skep sodat elke oproep die CMS kan bereik en ooreenstem met die inkomende oproepreël wat vir spasies bedoel is.
Integrasie met CUCM gekonfigureer op dieselfde manier as beskryf in die artikel behalwe dat jy op Cisco UCM drie stamme vir die CMS moet skep, drie konferensiebrûe, in die SIP-sekuriteitsprofiel spesifiseer drie Vakname, Roetegroepe, Roetelyste, Mediahulpbrongroepe en Mediahulpbrongroeplyste, en voeg 'n paar roeteringsreëls by na Cisco Meeting Server.
SIP-sekuriteitsprofiel:
Trunks:
Elke stam lyk dieselfde:
Konferensiebrug
Elke konferensiebrug lyk dieselfde:
Roete Groep
Roete lys
Mediahulpbrongroep
Mediahulpbrongroeplys
Oproepreëls
Anders as meer gevorderde oproepbestuurstelsels soos Unified CM of Expressway, soek CMS slegs die domein in die SIP Request-URI-veld vir nuwe oproepe. So as SIP INVITE vir slukkie is: [e-pos beskerm]Die CMS gee net om oor domain.com. CMS volg hierdie reëls om te bepaal waarheen om 'n oproep te stuur:
1. Die CMS probeer eers om die SIP-domein te pas by die domeine wat in die inkomende oproepreëls gekonfigureer is. Hierdie oproepe kan dan na (“geteikende”) ruimtes of spesifieke gebruikers, interne IVR's of direk geïntegreerde Microsoft Lync/Skype for Business (S4B)-bestemmings herlei word.
2. As daar geen ooreenstemming in die inkomende oproepreëls is nie, sal CMS probeer om die domein wat in die oproepaanstuurtabel opgestel is, te pas. As 'n passing gemaak word, kan die reël die oproep uitdruklik verwerp of die oproep aanstuur. Op hierdie tydstip kan die CMS die domein herskryf, wat soms nuttig is om Lync-domeine te bel. Jy kan ook kies om gooi te slaag, wat beteken dat geen van die velde verder gewysig sal word nie, of 'n interne CMS-skakelplan gebruik. As daar geen ooreenstemming in die oproepaanstuurreëls is nie, is die verstek om die oproep te verwerp. Hou in gedagte dat in die CMS, hoewel die oproep "aangestuur", is die media steeds gebonde aan die CMS, wat beteken dit sal in die sein- en mediaverkeerpad wees.
Dan is slegs aangestuurde oproepe onderhewig aan die uitgaande oproepreëls. Hierdie instellings bepaal die bestemmings waarheen oproepe gestuur word, die hooflyntipe (of dit 'n nuwe Lync-oproep of 'n standaard SIP-oproep is), en enige omskakelings wat uitgevoer kan word as oordrag nie in die oproepaanstuurreël gekies is nie.
Hier is die werklike logboek van wat tydens 'n ad-hoc-konferensie gebeur
Die skermkiekie wys dit swak (ek weet nie hoe om dit beter te maak nie), so ek sal die log so skryf:
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:12Die ad-hoc-konferensie self:
Reëls vir inkomende oproepe
Die opstel van die parameters van inkomende oproepe is nodig om 'n oproep in die CMS te kan ontvang. Soos jy in die LDAP-opstelling gesien het, is alle gebruikers ingevoer met die domein conf.pod6.cms.lab. So op 'n minimum wil jy oproepe na hierdie domein hê om spasies te teiken. U sal ook reëls moet opstel vir alles wat bedoel is vir die volledig gekwalifiseerde domeinnaam (en miskien selfs die IP-adres) van elk van die CMS-bedieners. Ons eksterne oproepbeheer, Unified CM, sal SIP-trunks opstel wat aan elkeen van die CMS-bedieners individueel toegewy is. Afhangende van of die bestemming van hierdie SIP-trunks 'n IP-adres of die bediener se FQDN is, sal bepaal of die CMS gekonfigureer moet word om oproepe te aanvaar wat na sy IP-adres of FQDN gerig is.
Die domein wat die hoogste prioriteit inkomende reël het, word as die domein vir enige gebruikerspasies gebruik. Wanneer gebruikers via LDAP sinkroniseer, skep die CMS outomaties spasies, maar slegs die gebruikerdeel van die URI (coSpaceUriMapping), byvoorbeeld user.space. Deel Die volledige URI word op grond van hierdie reël gegenereer. Trouens, as jy op hierdie stadium by Web Bridge sou aanmeld, sou jy sien dat die Space URI nie 'n domein het nie. Deur hierdie reël as die hoogste prioriteit te stel, stel jy die domein vir die gegenereerde spasies op konf.voorbeeld.com.
Reëls vir uitgaande oproepe
Om gebruikers toe te laat om uitgaande oproepe na die Unified CM-kluster te maak, moet jy uitgaande reëls opstel. Die domein van eindpunte wat by Unified CM geregistreer is, soos Jabber, is example.com. Oproepe na hierdie domein moet as standaard SIP-oproepe na Unified CM-oproepverwerkingsnodes herlei word. Die hoofbediener is cucm-01.example.com, en die bykomende bediener is cucm-02.example.com.
Die eerste reël beskryf die eenvoudigste roetering van oproepe tussen groepbedieners.
Veld Plaaslik vanaf domein is verantwoordelik vir wat in die oproeper se SIP-URI vertoon sal word vir die persoon wat na die "@"-simbool gebel word. As ons dit leeg laat, sal daar na die "@"-simbool die CUCM se IP-adres wees waardeur hierdie oproep gaan. As ons 'n domein spesifiseer, sal daar na die "@" simbool eintlik 'n domein wees. Dit is nodig om te kan terugbel, anders sal dit nie moontlik wees om terug te bel via SIP-URI naam@ip-adres nie.
Bel wanneer aangedui Plaaslik vanaf domein
Bel wanneer NIE aangedui Plaaslik vanaf domein
Maak seker dat u geënkripteer of ongeënkripteerd uitdruklik spesifiseer vir uitgaande oproepe, want niks werk met die Auto parameter nie.
Recording
Videokonferensies word deur die Rekordbediener opgeneem. Opnemer is presies dieselfde as Cisco Meeting Server. Opnemer vereis nie installering van enige lisensies nie. Opnamelisensies word vereis vir bedieners wat CallBridge-dienste gebruik, d.w.s. 'n Opnamelisensie word vereis en moet op die CallBridge-komponent toegepas word, en nie op die bediener wat Opnemer gebruik nie. Opnemer tree op as 'n XMPP-kliënt (Extensible Messaging and Presence Protocol), dus die XMPP-bediener moet geaktiveer word op die bediener wat CallBridge huisves.
Omdat Ons het 'n groep en die lisensie moet oor al drie bedieners in die groep "rek" word. Dan eenvoudig in jou persoonlike rekening in die lisensies wat ons assosieer (voeg by) die MAC-adresse van die a-koppelvlakke van alle CMS-bedieners wat in die groepering ingesluit is.
En dit is die prentjie wat op elke bediener in die groep moet wees
Oor die algemeen is daar verskeie scenario's vir die plasing van Recorder, maar ons sal hierby bly:
Voordat u Recorder opstel, moet u 'n plek voorberei waar die videokonferensies werklik opgeneem sal word. Eintlik hier , hoe om alle opname op te stel. Ek fokus op belangrike punte en besonderhede:
1. Dit is beter om die sertifikaat van die eerste bediener in die groep af te skuif.
2. Die “Opnemer onbeskikbaar”-fout kan voorkom omdat die verkeerde sertifikaat in die Opnemertrust gespesifiseer is.
3. Skryf sal dalk nie werk as die NFS-gids wat vir opname gespesifiseer is nie die wortelgids is nie.
Soms is daar 'n behoefte om outomaties 'n konferensie van een spesifieke gebruiker of spasie op te neem.
Hiervoor word twee oproepprofiele geskep:
Met opname gedeaktiveer
En met outomatiese opname funksie
Vervolgens "heg" ons 'n CallProfile met 'n outomatiese opname-funksie aan die verlangde spasie.
In CMS is dit so vasgestel dat indien 'n Oproepprofiel uitdruklik aan enige spasie of spasie gekoppel is, dan werk hierdie Oproepprofiel slegs in verhouding tot hierdie spesifieke spasies. En as die CallProfile nie aan enige spasie gebind is nie, word dit by verstek toegepas op daardie spasies waaraan geen CallProfile eksplisiet gebind is nie.
Volgende keer sal ek probeer beskryf hoe toegang tot die CMS buite die organisasie se interne netwerk verkry word.
Bronne:
Bron: will.com