En ĉi tiu numero mi montros kaj klarigos kelkajn el la komplikaĵoj de agordo de CMS-servilo en malsukcesa cluster-reĝimo.
TeorioĜenerale, ekzistas tri specoj de CMS-servila deplojo:
- Unuopa Kombinita(Ununura kombinita), t.e. ĉi tiu estas unu servilo sur kiu funkcias ĉiuj necesaj servoj. Plejofte, ĉi tiu speco de deplojo taŭgas nur por interna klienta aliro kaj en pli malgrandaj medioj, kie la skaleblo kaj redundlimigo de ununura servilo ne estas kritika afero, aŭ en situacioj kie la CMS nur plenumas certajn funkciojn, kiel ad hoc. konferencoj pri Cisco UCM.
Proksimuma laborskemo:
- Single Split(Single Split) etendas la antaŭan deplojspecon aldonante apartan servilon por ekstera aliro. En heredaĵdeplojoj, tio signifis deploji CMS-servilon en demilitarigita retsegmento (DMZ) kie eksteraj klientoj povis aliri ĝin, kaj unu CMS-servilon en la retkerno kie internaj klientoj povis aliri la CMS. Ĉi tiu speciala deplojmodelo nun estas anstataŭita de la tielnomita tipo Ununura Rando, kiu konsistas el serviloj Cisco Expressway, kiuj aŭ havas aŭ havos multajn el la samaj Fajrmuraj preterpasaj kapabloj por ke klientoj ne bezonas aldoni dediĉitan randan CMS-servilon.
Proksimuma laborskemo:
- Skalebla kaj rezistema(Skalebla kaj Faŭltolerema) Ĉi tiu tipo inkluzivas redundon por ĉiu komponento, permesante al la sistemo kreski laŭ viaj bezonoj ĝis sia maksimuma kapacito dum li provizas redundon en kazo de fiasko. Ĝi ankaŭ uzas la koncepton Single Edge por disponigi sekuran eksteran aliron. Ĉi tiu estas la tipo, kiun ni rigardos en ĉi tiu epizodo. Se ni komprenas kiel disfaldi ĉi tiun tipon de areto, ni ne nur komprenos aliajn specojn de deplojoj, sed ni ankaŭ povos kompreni kiel krei aretojn de CMS-serviloj por akomodi eblan kreskon de postulo.
Antaŭ ol transiri al deplojo, vi devas kompreni kelkajn bazajn aferojn, nome
Ĉefaj CMS-programaraj komponantoj:
- Datumbazo: Permesas al vi kombini kelkajn agordojn, kiel ciferplanon, uzantspacojn kaj uzantojn mem. Elportas clustering por alta havebleco (ununura majstro) nur.
- Voku Ponton: servo por audio kaj videokonferenco kiu disponigas plenan kontrolon super la administrado kaj prilaborado de vokoj kaj plurmediaj procezoj. Elportas clustering por alta havebleco kaj skaleblo.
- XMPP-servilo: respondeca pri registrado kaj aŭtentikigo de klientoj uzante la Cisco Meeting Application kaj/aŭ WebRTC (realtempa komunikado, aŭ simple en la retumilo), same kiel interkomponan signaladon. Povas esti grupigita nur por alta havebleco.
- Reteja Ponto: Provizas klientan aliron al WebRTC.
- Ŝarĝbalancilo: Provizas ununuran konekton por Cisco Meeting Apps en Single Split-reĝimo. Aŭskultas la eksteran interfacon kaj havenon por envenantaj konektoj. Egale, la ŝarĝbalancilo akceptas alvenantajn TLS-ligojn de la XMPP-servilo, per kiu ĝi povas ŝanĝi TCP-konektojn de eksteraj klientoj.
En nia scenaro ĝi ne estos bezonata. - TURN servilo: Provizas fajroŝirmilon preterpasantan teknologion kiu permesas
metu nian CMS malantaŭ Fajromuro aŭ NAT por konekti eksterajn klientojn per Cisco Meeting App aŭ SIP-aparatoj. En nia scenaro ĝi ne estos bezonata. - Reta Administranto: Administra interfaco kaj API-aliro, inkluzive por specialaj Unified CM-konferencoj.
Agordaj Reĝimoj
Male al la plej multaj aliaj Cisco-produktoj, Cisco Meeting Server subtenas tri agordajn metodojn por alĝustigi ajnan specon de deplojo.
- Komandlinio (CLI): Komandlinia interfaco konata kiel MMP por komenca agordo kaj atestiltaskoj.
- Reteja Administranto: Ĉefe por CallBridge rilataj agordoj, precipe kiam agordado de ununura ne-amasigita servilo.
- REST-API: Uzita por la plej kompleksaj agordaj taskoj kaj amasigitaj datumbazaj rilataj taskoj.
Krom la supre, la protokolo estas uzata SFTP translokigi dosierojn—kutime permesilojn, atestojn aŭ protokolojn—al kaj de la CMS-servilo.
En deplojgvidiloj de Cisco estas skribite en blanka kaj angla, ke la areto devas esti deplojita almenaŭ tri serviloj (nodoj) en la kunteksto de datumbazoj. Ĉar Nur kun nepara nombro da nodoj funkcios la mekanismo por elekti novan Database Master, kaj ĝenerale la Database Master havas rilaton kun la plej granda parto de la CMS-servila datumbazo.
Kaj kiel praktiko montras, du serviloj (nodoj) vere ne sufiĉas. La elekta mekanismo funkcias kiam la Majstro estas rekomencita, la Slave-servilo iĝas Majstro nur post kiam la rekomencita servilo estas edukita. Tamen, se en aro de du serviloj la Mastro-servilo subite eliras, tiam la Sklavo-servilo ne iĝos la Majstro, kaj se la Sklavo eliras, tiam la restanta Majstra servilo iĝos la Sklavo.
Sed en la kunteksto de XMPP, vere necesus kunveni aron de tri serviloj, ĉar se vi ekzemple malŝaltas la XMPP-servon en unu el la serviloj, en kiuj XMMP estas en la statuso de Gvidanto, tiam sur la restanta servilo XMPP restos en la stato de Sekvanto kaj la konektoj de CallBridge al XMPP falos, ĉar CallBridge konektas ekskluzive al XMPP kun Gvida statuso. Kaj ĉi tio estas kritika, ĉar... neniu voko trapasos.
Ankaŭ en la sama deplojo gvidas areto kun unu XMPP-servilo estas pruvita.
Kaj konsiderante la supre, evidentiĝas kial: ĝi funkcias ĉar ĝi estas en malsukcesa reĝimo.
En nia kazo, la XMPP-servilo ĉeestos sur ĉiuj tri nodoj.
Oni supozas, ke ĉiuj tri niaj serviloj estas ŝaltitaj.
DNS-rekordoj
Antaŭ ol vi komencas agordi servilojn, vi devas krei DNS-rekordojn А и SRV tipoj:
Bonvolu noti, ke en niaj DNS-rekordoj estas du domajnoj example.com kaj konf.ekzemplo.com. Example.com estas domajno, kiun ĉiuj abonantoj de Cisco Unified Communication Manager povas uzi por siaj URIoj, kiu plej verŝajne ĉeestas en via infrastrukturo aŭ verŝajne ĉeestas. Aŭ example.com kongruas kun la sama domajno, kiun uzantoj uzas por siaj retadresoj. Aŭ la Jabber-kliento sur via tekkomputilo eble havas URI [retpoŝte protektita]. Domajno konf.example.com estas la domajno kiu estos agordita por uzantoj de Cisco Meeting Server. La domajno de la Cisco Meeting Server estos konf.example.com, do por la sama Jabber-uzanto, la user@ URI devus esti uzata por ensaluti en Cisco Meeting Serverkonf.ekzemplo.com.
Baza agordo
Ĉiuj agordoj priskribitaj malsupre estas montritaj sur unu servilo, sed ili devas esti faritaj sur ĉiu servilo en la areto.
QoS
Ĉar la CMS generas Reala tempo trafiko sentema al prokrastoj kaj paka perdo, en la plej multaj kazoj oni rekomendas agordi kvaliton de servo (QoS). Por atingi tion, la CMS subtenas etikedajn pakaĵetojn kun la Diferentiated Services Codes (DSCPoj) kiujn ĝi generas. Kvankam DSCP-bazita trafika prioritato dependas de kiel la trafiko estas prilaborita de la retaj komponantoj de via infrastrukturo, en nia kazo ni agordos nian CMS kun tipa DSCP-prioritigo bazita sur QoS plej bonaj praktikoj.
Sur ĉiu servilo ni enigos ĉi tiujn komandojn
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ATiel, ĉiu videotrafiko estis markita AF41 (DSCP 0x22), ĉiu voĉtrafiko estis markita EF (DSCP 0x2E), aliaj specoj de malalta latencia trafiko kiel ekzemple SIP kaj XMPP uzas AF31 (DSCP 0x1A).
Ni kontrolas:
NTP
Network Time Protocol (NTP) gravas ne nur por provizi precizajn tempomarkojn de vokoj kaj konferencoj, sed ankaŭ por kontroli atestojn.
Aldonu NTP-servilojn al via infrastrukturo per komando kiel
ntp server add <server>
En nia kazo, ekzistas du tiaj serviloj, do estos du teamoj.
Ni kontrolas:
Kaj agordu la horzonon por nia servilo
DNS
Ni aldonas DNS-servilojn al la CMS per komando kiel:
dns add forwardzone <domain-name> <server ip>
En nia kazo, ekzistas du tiaj serviloj, do estos du teamoj.
Ni kontrolas:
Agordo de Reta Interfaco
Ni agordas la interfacon per komando kiel:
ipv4 <interface> add <address>/<prefix length> <gateway>
Ni kontrolas:
Servilonomo (Gastignomo)
Ni fiksas la servilan nomon per komando kiel:
hostname <name>
Kaj ni rekomencas.
Ĉi tio kompletigas la bazan agordon.
Atestiloj
TeorioCisco Meeting Server postulas ĉifritan komunikadon inter diversaj komponentoj, kaj kiel rezulto, X.509-atestiloj estas postulataj por ĉiuj CMS-deplojoj. Ili helpas certigi, ke la servoj/servilo estas fidindaj de aliaj serviloj/servoj.
Ĉiu servo postulas atestilon, sed krei apartajn atestojn por ĉiu servo povas konduki al konfuzo kaj nenecesa komplekseco. Feliĉe, ni povas generi la publikan-privatan ŝlosilparon de atestilo kaj poste reuzi ilin tra pluraj servoj. En nia kazo, la sama atestilo estos uzata por Call Bridge, XMPP Server, Web Bridge kaj Web Admin. Tiel, vi devas krei paron da publikaj kaj privataj atestilŝlosiloj por ĉiu servilo en la areto.
Datumbazgrupo, tamen, havas kelkajn specialajn atestpostulojn kaj tial postulas siajn proprajn atestojn kiuj estas diferencaj de tiuj de la aliaj servoj. CMS uzas servilan atestilon, kiu estas simila al la atestiloj uzataj de aliaj serviloj, sed ekzistas ankaŭ klientatestilo uzata por datumbazaj konektoj. Datumbazaj atestiloj estas uzataj por aŭtentikigo kaj ĉifrado. Anstataŭ provizi uzantnomon kaj pasvorton por la kliento por konekti al la datumbazo, ĝi prezentas klientan atestilon, kiu estas fidinda de la servilo. Ĉiu servilo en la datumbaza areto uzos la saman publikan kaj privatan ŝlosilparon. Ĉi tio permesas al ĉiuj serviloj en la areto ĉifri datumojn tiel, ke ĝi nur povas esti deĉifrita per aliaj serviloj, kiuj ankaŭ kunhavas la saman ŝlosilparon.
Por ke la redundo funkciu, datumbazaj aretoj devas konsisti el minimume 3 serviloj, sed ne pli ol 5, kun maksimuma rondvetura tempo de 200 ms inter iuj aretmembroj. Ĉi tiu limo estas pli limiga ol por Voka Ponto-grupo, do ĝi ofte estas la limiga faktoro en geografie distribuitaj deplojoj.
La datumbaza rolo por CMS havas kelkajn unikajn postulojn. Male al aliaj roloj, ĝi postulas klient- kaj servilatestilon, kie la klientatestilo havas specifan CN-kampon kiu estas prezentita al la servilo.
La CMS uzas postgresan datumbazon kun unu majstro kaj pluraj tute identaj kopioj. Estas nur unu primara datumbazo samtempe (la "datumbaza servilo"). La ceteraj membroj de la areto estas kopioj aŭ "datumbazaj klientoj".
Datumararo postulas dediĉitan servilan atestilon kaj klientatestilon. Ili devas esti subskribitaj per atestiloj, kutime interna privata atestila aŭtoritato. Ĉar ĉiu membro de la datumbazo povas iĝi la majstro, la datumbaza servilo kaj klient-atestilparoj (enhavantaj la publikajn kaj privatajn ŝlosilojn) devas esti kopiitaj al ĉiuj serviloj por ke ili povu supozi la identecon de la kliento aŭ datumbaza servilo. Krome, la CA radika atestilo devas esti ŝarĝita por certigi ke la kliento- kaj servilaj atestiloj povas esti kontrolitaj.
Do, ni kreas peton por atestilo, kiu estos uzata de ĉiuj servilaj servoj krom la datumbazo (estos aparta peto por tio) kun komando kiel:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
En CN ni skribas la ĝeneralan nomon de niaj serviloj. Ekzemple, se la gastigantaj nomoj de niaj serviloj servilo01, servilo02, servilo03, tiam CN estos servilo.ekzemplo.com
Ni faras la samon sur la ceteraj du serviloj kun la diferenco, ke la komandoj enhavos la respondajn "gastnomojn"
Ni generas du petojn por atestiloj, kiuj estos uzataj de la datumbaza servo kun komandoj kiel:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreskie dbclusterserver и dbclusterclient nomoj de niaj petoj kaj estontaj atestiloj, gastiga nomo1(2)(3) nomoj de la respondaj serviloj.
Ni plenumas ĉi tiun proceduron nur sur unu servilo (!), kaj ni alŝutos la atestilojn kaj respondajn .key-dosierojn al aliaj serviloj.
Ebligu klientan atestreĝimon en AD CS
Vi ankaŭ devas kunfandi la atestilojn por ĉiu servilo en unu dosieron.Sur *NIX:
cat server01.cer server02.cer server03.cer > server.cerSur Vindozo/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Kaj alŝutu al ĉiu servilo:
1. "Individua" servila atestilo.
2. Radika atestilo (kune kun mezaj, se ekzistas).
3. Atestiloj por la datumbazo ("servilo" kaj "kliento") kaj dosieroj kun la etendo .key, kiuj estis generitaj dum kreado de peto por la "servilo" kaj "kliento" datumbazatestiloj. Ĉi tiuj dosieroj devas esti la samaj en ĉiuj serviloj.
4. Dosiero de ĉiuj tri "individuaj" atestiloj.
Kiel rezulto, vi devus ricevi ion kiel ĉi tiu dosierbildo sur ĉiu servilo.
Datumbaza Areto
Nun kiam vi havas ĉiujn atestojn alŝutitajn al la CMS-serviloj, vi povas agordi kaj ebligi datumbazan grupigon inter la tri nodoj. La unua paŝo estas elekti unu servilon kiel la majstran nodon de la datumbazo kaj plene agordi ĝin.
Majstra Datumaro
La unua paŝo en agordo de datumbaza reproduktado estas specifi la atestojn, kiuj estos uzataj por la datumbazo. Ĉi tio estas farita per komando kiel:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Nun ni diru al la CMS kiun interfacon uzi por datumbaza amasiĝo kun la komando:
database cluster localnode aTiam ni pravigigas la clusterdatumbazon sur la ĉefa servilo per la komando:
database cluster initialize
Kliento-Datumbazaj Nodoj
Ni faras la saman proceduron, nur anstataŭ la komando datumbaza grapolo pravalorigi enigu komandon kiel:
database cluster join <ip address existing master>kie ip-adreso ekzistanta majstra ip-adreso de la CMS-servilo sur kiu la areto estis pravigita, simple Majstro.
Ni kontrolas kiel nia datumbaza areto funkcias en ĉiuj serviloj per la komando:
database cluster status
Ni faras la samon sur la restanta tria servilo.
Rezulte, rezultas, ke nia unua servilo estas la Majstro, la ceteraj estas Sklavoj.
Reta Administra Servo
Ebligu la retadministran servon:
webadmin listen a 445Haveno 445 estis elektita ĉar haveno 443 estas uzita por uzantaliro al la retkliento
Ni agordas la TTT-administran servon per atestiloj kun komando kiel:
webadmin certs <keyfile> <certificatefile> <ca bundle>Kaj ebligu Retan Administranton per la komando:
webadmin enable
Se ĉio estas en ordo, ni ricevos SUKC-liniojn indikante, ke Reta Administranto estas ĝuste agordita por la reto kaj atestilo. Ni kontrolas la funkciojn de la servo per retumilo kaj enigas la adreson de la administranto de la retejo, ekzemple: : 445
Voku Ponta Areto
Call Bridge estas la sola servo ĉeestanta en ĉiu CMS-deplojo. Voka Ponto estas la ĉefa konferenca mekanismo. Ĝi ankaŭ disponigas SIP-interfacon tiel ke vokoj povas esti direktitaj al aŭ de ĝi per, ekzemple, Cisco Unified CM.
La komandoj priskribitaj sube devas esti ekzekutitaj sur ĉiu servilo kun la taŭgaj atestiloj.
Do:
Ni asocias atestojn kun la Voka Ponta servo kun komando kiel:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Ni ligas CallBridge-servojn al la interfaco, kiun ni bezonas per la komando:
callbridge listen aKaj rekomencu la servon per la komando:
callbridge restart
Nun kiam ni havas niajn Vokajn Pontojn agordita, ni povas agordi Vokpontan clustering. Voka Ponta clustering estas diferenca de datumbazo aŭ XMPP clustering. Call Bridge Cluster povas subteni de 2 ĝis 8 nodoj sen iuj limigoj. Ĝi disponigas ne nur redundon, sed ankaŭ ŝarĝbalancadon tiel ke konferencoj povas esti aktive distribuitaj tra Call Bridge-serviloj uzante inteligentan vokdistribuon. La CMS havas kromajn funkciojn, Call Bridge-grupojn kaj rilatajn funkciojn, kiuj povas esti uzataj por plia administrado.
Voka ponta clustering estas agordita ĉefe per la interreta administra interfaco
La proceduro priskribita sube devas esti efektivigita sur ĉiu servilo en la areto.
Kaj tiel,
1. Iru tra la reto al Agordo > Areto.
2. En Voku Bridge-identecon Kiel unika nomo, enigu callbridge[01,02,03] responda al la servila nomo. Ĉi tiuj nomoj estas arbitraj, sed devas esti unikaj por ĉi tiu aro. Ili estas priskribaj en naturo ĉar ili indikas ke ili estas servilaj identigiloj [01,02,03].
3.B Clustered Call Bridges enigu la retadministrantajn URL-ojn de niaj serviloj en la areto, [01,02,03].example.com:445, en la kampo Adreso. Nepre specifu la havenon. Vi povas lasi Peer-link SIP-domajnon malplena.
4. Aldonu atestilon al la CallBridge-trusto de ĉiu servilo, kies dosiero enhavas ĉiujn atestojn de niaj serviloj, kiujn ni kunfandis en ĉi tiun dosieron komence, kun komando kiel:
callbridge trust cluster <trusted cluster certificate bundle>Kaj rekomencu la servon per la komando:
callbridge restart
Kiel rezulto, sur ĉiu servilo vi devus ricevi ĉi tiun bildon:
XMPP-Areto
La XMPP-servo en la CMS estas uzata por pritrakti ĉian registradon kaj aŭtentikigon por Cisco Meeting Apps (CMA), inkluzive de la retkliento CMA WebRTC. La Voka Ponto mem ankaŭ funkcias kiel XMPP-kliento por aŭtentikigceloj kaj tial devas esti agordita kiel aliaj klientoj. XMPP-faŭltoleremo estas trajto kiu estis subtenata en produktadmedioj ekde versio 2.1
La komandoj priskribitaj sube devas esti ekzekutitaj sur ĉiu servilo kun la taŭgaj atestiloj.
Do:
Ni asocias atestojn kun la servo XMPP kun komando kiel:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Poste difinu la aŭskultantan interfacon per la komando:
xmpp listen aLa servo XMPP postulas unikan domajnon. Ĉi tio estas la ensaluto por uzantoj. Alivorte, kiam uzanto provas ensaluti uzante la CMA-apon (aŭ per la WebRTC-kliento), ili eniras userID@logindomain. En nia kazo ĝi estos userid@konf.ekzemplo.com. Kial ĝi ne estas nur example.com? En nia aparta deplojo, ni elektis nian Unified CM-domajnon, kiun Jabber-uzantoj uzos en Unified CM kiel example.com, do ni bezonis malsaman domajnon por CMS-uzantoj por direkti vokojn al kaj de la CMS per SIP-domajnoj.
Agordu XMPP-domajnon per komando kiel:
xmpp domain <domain>Kaj ebligu la servon XMPP per la komando:
xmpp enableEn la XMPP-servo, vi devas krei akreditaĵojn por ĉiu Voka Ponto, kiu estos uzata dum registriĝo kun la XMPP-servo. Ĉi tiuj nomoj estas arbitraj (kaj ne rilatas al la unikaj nomoj, kiujn vi agordis por voka ponta grupigo). Vi devas aldoni tri alvokopontojn sur unu XMPP-servilo kaj poste enigi tiujn akreditaĵojn sur aliaj XMPP-serviloj en la areto ĉar ĉi tiu agordo ne konvenas en la clusterdatumbazo. Poste ni agordos ĉiun Vokan Ponton por uzi ĉi tiun nomon kaj sekreton por registriĝi kun la servo XMPP.
Nun ni devas agordi la XMPP-servon sur la unua servilo kun tri Call Bridges callbridge01, callbridge02 kaj callbridge03. Al ĉiu konto estos asignitaj hazardaj pasvortoj. Ili poste estos enmetitaj sur aliaj Call Bridge-serviloj por ensaluti en ĉi tiun XMPP-servilon. Enigu la sekvajn komandojn:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Kiel rezulto, ni kontrolas kio okazis kun la komando:
xmpp callbridge list
Ĝuste la sama bildo devus aperi sur la ceteraj serviloj post la paŝoj priskribitaj sube.
Poste ni aldonas ĝuste la samajn agordojn sur la ceteraj du serviloj, nur per la komandoj
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Ni aldonas Sekreton tre zorge, por ke, ekzemple, ne estu kromaj spacoj en ĝi.
Kiel rezulto, ĉiu servilo havu la saman bildon:
Poste, en ĉiuj serviloj en la areto, ni specifas fide la dosieron enhavanta ĉiujn tri atestojn, kreitajn antaŭe per komando kiel ĉi tio:
xmpp cluster trust <trust bundle>Ni ebligas xmpp-clusterreĝimon en ĉiuj cluster-serviloj per la komando:
xmpp cluster enableSur la unua servilo de la areto, ni komencas la kreadon de xmpp cluster kun la komando:
xmpp cluster initializeSur aliaj serviloj, aldonu areton al xmpp per komando kiel:
xmpp cluster join <ip address head xmpp server>Ni kontrolas sur ĉiu servilo la sukceson krei XMPP-grupon sur ĉiu servilo per la komandoj:
xmpp status
xmpp cluster statusUnua servilo:
Dua servilo:
Tria servilo:
Konektante Vokponton al XMPP
Nun kiam la XMPP-areto funkcias, vi devas agordi la Call Bridge-servojn por konekti al la XMPP-areto. Ĉi tiu agordo estas farita per la retadministranto.
Sur ĉiu servilo, iru al Agordo> Ĝenerala kaj en la kampo Unika nomo de Voka Ponto skribu unikajn nomojn de Call Bridge respondantaj al la servilo vokponto[01,02,03]... En kampo havaĵo conf.example.ru kaj respondaj pasvortoj, vi povas spioni ilin
sur iu ajn servilo en la areto kun la komando:
xmpp callbridge list
Lasu la kampon "Servilo" malplena Callbridge faros serĉon de DNS SRV por _xmpp-component._tcp.conf.example.compor trovi disponeblan XMPP-servilon. La IP-adresoj por konekti vokpontojn al XMPP povas malsami sur ĉiu servilo, ĝi dependas de kiaj valoroj estas redonitaj al la rekorda peto. _xmpp-component._tcp.conf.example.com callbridge, kiu siavice dependas de la prioritataj agordoj por donita DNS-rekordo.
Poste, iru al Statuso> Ĝenerala por kontroli ĉu la servo de Call Bride estas sukcese konektita al la servo XMPP.
Reteja Ponto
Sur ĉiu servilo en la areto, ebligu la servon Web Bridge per la komando:
webbridge listen a:443Ni agordas la servon Web Bridge kun atestiloj kun komando kiel:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge subtenas HTTPS. Ĝi redirektos HTTP al HTTPS se agordita por uzi "http-redirektilon".
Por ebligi HTTP-alidirekton, uzu la jenan komandon:
webbridge http-redirect enablePor sciigi al Call Bridge, ke Web Bridge povas fidi ligojn de Call Bridge, uzu la komandon:
webbridge trust <certfile>kie ĉi tio estas dosiero enhavanta ĉiujn tri atestojn de ĉiu servilo en la areto.
Ĉi tiu bildo devus esti sur ĉiu servilo en la areto.
Nun ni devas krei uzanton kun la rolo "appadmin", ni bezonas ĝin por ke ni povu agordi nian areton (!), kaj ne ĉiun servilon en la areto aparte, tiamaniere la agordoj estos aplikitaj egale al ĉiu servilo malgraŭ la fakto ke ili estos faritaj unufoje.
Por plia agordo ni uzos .
Por rajtigo, elektu Baza en la sekcio Rajtigo
Por ĝuste sendi komandojn al la CMS-servilo, vi devas agordi la bezonatan kodigon
Ni specifas Webbridge per la komando POST kun parametro url kaj signifo
En la retponto mem, ni indikas la bezonatajn parametrojn: gasta aliro, protektita aliro, ktp.
Voku Pontajn Grupojn
Defaŭlte, la CMS ne ĉiam faras la plej efikan uzon de la konferencaj rimedoj disponeblaj al ĝi.
Ekzemple, por renkontiĝo kun tri partoprenantoj, ĉiu partoprenanto povas alveni sur tri malsamaj Vokaj Pontoj. Por ke ĉi tiuj tri partoprenantoj komunikiĝu inter si, Call Bridges aŭtomate establos ligojn inter ĉiuj serviloj kaj klientoj en la sama Spaco, tiel ke ĉio aspektas kvazaŭ ĉiuj klientoj estas sur la sama servilo. Bedaŭrinde, la malavantaĝo de ĉi tio estas, ke ununura 3-persona konferenco nun konsumos 9 amaskomunikilajn havenojn. Ĉi tio evidente estas malefika uzo de rimedoj. Aldone, kiam Voka Ponto estas vere troŝarĝita, la defaŭlta mekanismo estas daŭri akcepti vokojn kaj disponigi reduktitan kvalitan servon al ĉiuj abonantoj de tiu Voka Ponto.
Ĉi tiuj problemoj estas solvitaj uzante la funkcion Call Bridge Group. Ĉi tiu funkcio estis enkondukita en versio 2.1 de Cisco Meeting Server-programaro kaj estis etendita por subteni ŝarĝan ekvilibron por kaj enirantaj kaj forirantaj Cisco Meeting App (CMA) vokoj, inkluzive de WebRTC-partoprenantoj.
Por solvi la rekonektan problemon, tri agordeblaj ŝarĝlimoj estis lanĉitaj por ĉiu Voka Ponto:
Ŝarĝlimo — ĉi tio estas la maksimuma nombra ŝarĝo por aparta Voka Ponto. Ĉiu platformo havas rekomenditan ŝarĝlimon, kiel ekzemple 96000 por la CMS1000 kaj 1.25 GHz per vCPU por la virtuala maŝino. Malsamaj vokoj konsumas certan kvanton da rimedoj depende de la rezolucio kaj framfrekvenco de la partoprenanto.
Novaj KonferencoLoadLimitBasisPoints (defaŭlte 50% loadLimit) - fiksas la servilan ŝarĝlimon, post kiu novaj konferencoj estas malakceptitaj.
Ekzistantaj KonferencoLoadLimitBasisPoints (defaŭlte 80% de loadLimit) - la servila ŝarĝvaloro post kiu partoprenantoj aliĝantaj al ekzistanta konferenco estos malakceptitaj.
Dum ĉi tiu funkcio estis desegnita por voka distribuo kaj ŝarĝo-ekvilibro, aliaj grupoj kiel TURN Servers, Web Bridge Servers kaj Registriloj ankaŭ povas esti asignitaj al Call Bridge Groups tiel ke ili ankaŭ povas esti konvene grupigitaj por optimuma uzo. Se iu el ĉi tiuj objektoj ne estas asignita al voka grupo, ili estas supozitaj esti haveblaj al ĉiuj serviloj sen iu ajn speciala prioritato.
Ĉi tiuj parametroj estas agorditaj ĉi tie: :445/api/v1/system/configuration/cluster
Poste, ni indikas al ĉiu vokponto al kiu vokponta grupo ĝi apartenas:
Unua callbridge
Dua vokponto
Tria vokponto
Tiel, ni agordis la grupon Call Brdge por pli efike uzi la rimedojn de la Cisco Meeting Server-grupo.
Importi uzantojn el Active Directory
La Web Admin-servo havas LDAP-agordan sekcion, sed ĝi ne disponigas kompleksajn agordajn opciojn, kaj la informoj ne estas stokitaj en la grapoldatumbazo, do agordo devos esti farita, ĉu permane sur ĉiu servilo per la Reta interfaco, aŭ pere. la API, kaj por ke ni "trifoje "Ne leviĝu" ni ankoraŭ starigos la datumojn per la API.
Uzante URL por aliri :445/api/v1/ldapServers kreas objekton de LDAP-Servilo, precizigante parametrojn kiel:
- Servilo IP
- havennumero
- Uzantnomo
- pasvorto
- certigi
Sekura - elektu vera aŭ malvera depende de la haveno, 389 - ne sekura, 636 - protektita.
Mapado de LDAP-fontoparametroj al atributoj en Cisco Meeting Server.
La LDAP-mapado mapas la atributojn en la LDAP-dosierujo al la atributoj en la CMS. La realaj atributoj:
- jidMapado
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Priskribo de atributojIADB reprezentas la ensalutan ID de la uzanto en la CMS. Ĉar ĉi tio estas Microsoft Active Directory LDAP-servilo, la CMS-JID mapas al la sAMAccountName en LDAP, kiu estas esence la ensalutidentigilo de la Active Directory de la uzanto. Ankaŭ notu, ke vi prenu sAMAccountName kaj aldonu la domajnon conf.pod6.cms.lab al la fino de ĝi ĉar ĉi tiu estas la ensaluto, kiun viaj uzantoj uzos por ensaluti en la CMS.
nameMapping kongruas tion, kio estas enhavita en la kampo displayName de Active Directory al la kampo de nomo CMS de la uzanto.
coSpaceNameMapping kreas CMS-spacan nomon bazitan sur la kampo displayName. Ĉi tiu atributo, kune kun la atributo coSpaceUriMapping, estas necesa por krei spacon por ĉiu uzanto.
coSpaceUriMapping difinas la uzantan parton de la URI asociita kun la persona spaco de la uzanto. Kelkaj domajnoj povas esti agorditaj por esti diskitaj en spacon. Se la uzantparto kongruas kun ĉi tiu kampo por unu el ĉi tiuj domajnoj, la alvoko estos direktita al la spaco de tiu uzanto.
coSpaceSecondaryUriMapping difinas duan URI por atingi spacon. Ĉi tio povas esti uzata por aldoni numeran kaŝnomon por direkti vokojn al la spaco de la importita uzanto kiel alternativo al la alfanombra URI difinita en la parametro coSpaceUriMapping.
La LDAP-servilo kaj LDAP-mapado estas agorditaj. Nun vi devas ligi ilin kune kreante LDAP-fonton.
Uzante URL por aliri :445/api/v1/ldapSource kreu LDAP-Fontan objekton, specifante parametrojn kiel:
- servilo
- surĵeto
- bazDn
- filtrilo
Nun kiam la LDAP-agordo estas kompleta, vi povas plenumi la manan sinkronigan operacion.
Ni faras ĉi tion aŭ en la Reta interfaco de ĉiu servilo klakante Sinkronigu nun sekcio Aktiva Dosierujo
aŭ per la API kun la komando POST uzante URL por aliri :445/api/v1/ldapSyncs
Ad-Hoc-konferencoj
Kio estas ĉi tio?En la tradicia koncepto, konferenco estas kiam du partoprenantoj parolas unu kun la alia, kaj unu el la partoprenantoj (uzante aparaton registritan kun Unified CM) premas la butonon "Konferenco", vokas la alian personon, kaj post paroli kun tiu tria partio. , denove premas la butonon "Konferenco" por aliĝi al ĉiuj partoprenantoj en la triparta konferenco.
Kio distingas Ad-Hoc-konferencon de planita konferenco en CMS estas ke Ad-Hoc-konferenco ne estas nur SIP-voko al CMS. Kiam la konferenca iniciatinto duan fojon alklakas la Konferencan butonon por inviti ĉiujn al la sama renkontiĝo, Unified CM devas fari API-vokon al la CMS por krei tujan konferencon al kiu ĉiuj vokoj tiam estas transdonitaj. Ĉio ĉi okazas nerimarkite de la partoprenantoj.
Ĉi tio signifas, ke Unified CM devas agordi la API-akreditaĵojn kaj WebAdmin-adreson/havenon de la servo same kiel la SIP Trunko rekte al la CMS-servilo por daŭrigi la vokon.
Se necese, CUCM povas dinamike krei spacon en la CMS tiel ke ĉiu voko povas atingi la CMS kaj egali la envenantan vokregulon kiu estas destinita por spacoj.
Integriĝo kun CUCM agordita en la sama maniero kiel priskribite en la artikolo krom ke ĉe Cisco UCM vi devas krei tri trunkojn por la CMS, tri Konferencajn Pontojn, en la SIP-Sekurec-Profilo specifu tri Subjektajn Nomojn, Itinerajn Grupojn, Itinerajn Listojn, Amaskomunikilajn Rimedo-Grupojn kaj Amaskomunikilajn Rimedo-Grupojn, kaj aldoni kelkajn vojajn regulojn. al Cisco Meeting Server.
SIP Sekureca Profilo:
Trunkoj:
Ĉiu trunko aspektas same:
Konferenca Ponto
Ĉiu Konferenca Ponto aspektas same:
Itinera Grupo
Itinera Listo
Media Resource Group
Listo de Amaskomunikilaraj Grupoj
Voku Regulojn
Male al pli altnivelaj alvokaj administradsistemoj kiel ekzemple Unified CM aŭ Expressway, CMS nur serĉas la domajnon en la SIP Request-URI-kampo por novaj vokoj. Do se SIP INVITE estas por trinkaĵo: [retpoŝte protektita]La CMS nur zorgas pri domajno.com. CMS sekvas ĉi tiujn regulojn por determini kie direkti vokon:
1. La CMS unue provas kongrui la SIP-domajnon kun la domajnoj agorditaj en la envenantaj vokaj reguloj. Tiuj vokoj tiam povas esti direktitaj al ("celaj") spacoj aŭ specifaj uzantoj, internaj IVR-oj, aŭ rekte integraj Microsoft Lync/Skype for Business (S4B) cellokoj.
2. Se ne estas kongruo en la envenantaj vokaj reguloj, CMS provos kongrui kun la domajno agordita en la voka plusendado. Se matĉo estas farita, la regulo povas eksplicite malakcepti la vokon aŭ plusendi la vokon. Ĉi-momente, la CMS povas reverki la domajnon, kio foje estas utila por voki Lync-domajnojn. Vi ankaŭ povas elekti preterpasi ĵeton, kio signifas, ke neniu el la kampoj estos plu modifita, aŭ uzi internan CMS-ciferplanon. Se ne estas kongruo en la reguloj pri alvoko, la defaŭlto estas malakcepti la vokon. Memoru, ke en la CMS, kvankam la voko estas "plusendita", la amaskomunikilaro ankoraŭ estas ligita al la CMS, kio signifas, ke ĝi estos en la signala kaj amaskomunikila trafikvojo.
Tiam nur plusenditaj vokoj estas submetitaj al la elirantaj vokaj reguloj. Ĉi tiuj agordoj determinas la cellokojn kie vokoj estas senditaj, la trunko-tipo (ĉu ĝi estas nova Lync-voko aŭ norma SIP-voko), kaj iujn ajn konvertiĝojn, kiuj povas esti faritaj se translokigo ne estas elektita en la regulo pri plusendado de vokoj.
Jen la reala protokolo pri tio, kio okazas dum Ad-Hoc-konferenco
La ekrankopio montras ĝin malbone (mi ne scias kiel plibonigi ĝin), do mi skribos la protokolon tiel:
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:12La Ad-Hoc-konferenco mem:
Alvenaj Vokaj Reguloj
Agordi la parametrojn de envenantaj vokoj estas necesa por povi ricevi vokon en la CMS. Kiel vi vidis en la agordo de LDAP, ĉiuj uzantoj estis importitaj per la domajno conf.pod6.cms.lab. Do minimume, vi volas alvokojn al ĉi tiu domajno celi spacojn. Vi ankaŭ devos starigi regulojn por ĉio, kio estas destinita por la plene kvalifikita domajna nomo (kaj eble eĉ la IP-adreso) de ĉiu el la CMS-serviloj. Nia ekstera voka kontrolo, Unified CM, agordos SIP-trunkojn dediĉitajn al ĉiu el la CMS-serviloj individue. Depende de ĉu la celloko de ĉi tiuj SIP-trunkoj estas IP-adreso aŭ la FQDN de la servilo determinos ĉu la CMS devas esti agordita por akcepti vokojn direktitajn al ĝia IP-adreso aŭ FQDN.
La domajno kiu havas la plej altan prioritatan eniran regulon estas uzata kiel la domajno por iuj uzantspacoj. Kiam uzantoj sinkronigas per LDAP, la CMS aŭtomate kreas spacojn, sed nur la uzantan parton de la URI (coSpaceUriMapping), ekzemple user.space. Parto La plena URI estas generita surbaze de ĉi tiu regulo. Fakte, se vi ensalutus en Web Bridge ĉe ĉi tiu punkto, vi vidus, ke la Spaca URI ne havas domajnon. Agordante ĉi tiun regulon kiel la plej altan prioritaton, vi fiksas la domajnon por la generitaj spacoj konf.ekzemplo.com.
Eksiĝintaj Vokaj Reguloj
Por permesi al uzantoj fari elirajn vokojn al la Unified CM-areto, vi devas agordi elirajn regulojn. La domajno de finpunktoj registritaj kun Unified CM, kiel ekzemple Jabber, estas example.com. Vokoj al ĉi tiu domajno devas esti direktitaj kiel normaj SIP-vokoj al Unified CM-vokaj prilaboraj nodoj. La ĉefa servilo estas cucm-01.example.com, kaj la aldona estas cucm-02.example.com.
La unua regulo priskribas la plej simplan vojigon de vokoj inter clusterserviloj.
kampo Loka de domajno respondecas pri tio, kio estos montrata en la SIP-URI de la alvokanto por la vokita persono post la simbolo "@". Se ni lasas ĝin malplena, tiam post la simbolo "@" estos la IP-adreso de CUCM, tra kiu ĉi tiu alvoko pasas. Se ni specifas domajnon, tiam post la simbolo “@” efektive estos domajno. Tio estas necesa por povi revoki, alie ne eblos revoki per SIP-URI nomo@ip-adreso.
Voku kiam indikite Loka de domajno
Voku kiam NE indikita Loka de domajno
Nepre specifu eksplicite Ĉifrita aŭ Neĉifrita por eksiĝintaj vokoj, ĉar nenio funkcias kun la Aŭtomata parametro.
registrado
Videokonferencoj estas registritaj de la Rekordservilo. Registrilo estas ĝuste la sama kiel Cisco Meeting Server. Registrilo ne postulas instaladon de ajnaj permesiloj. Registradlicencoj estas postulataj por serviloj funkciantaj CallBridge-servojn, t.e. Registradlicenco estas postulata kaj devas esti aplikita al la CallBridge-komponento, kaj ne al la servilo prizorganta Registrilo. Registrilo kondutas kiel Extensible Messaging and Presence Protocol (XMPP) kliento, do la XMPP-servilo devas esti ebligita sur la servilo gastiganta CallBridge.
Ĉar Ni havas areton kaj la permesilo devas esti "streĉita" tra ĉiuj tri serviloj en la areto. Tiam simple en via persona konto en la permesiloj ni asocias (aldonas) la MAC-adresojn de la a-interfacoj de ĉiuj CMS-serviloj inkluzivitaj en la cluster.
Kaj ĉi tiu estas la bildo, kiu devus esti sur ĉiu servilo en la areto
Ĝenerale, ekzistas pluraj scenaroj por loki Registrilon, sed ni konservos ĉi tion:
Antaŭ ol instali Registrilon, vi devas prepari lokon, kie la videokonferencoj efektive estos registritaj. Fakte ĉi tie , kiel agordi ĉiujn Registradojn. Mi koncentriĝas pri gravaj punktoj kaj detaloj:
1. Pli bone estas gliti la atestilon de la unua servilo en la areto.
2. La eraro "Registrilo nedisponebla" povas okazi ĉar la malĝusta atestilo estas specifita en la Registrador-Fido.
3. Skribado eble ne funkcias se la NFS-dosierujo specifita por registrado ne estas la radika dosierujo.
Kelkfoje necesas aŭtomate registri konferencon de unu specifa uzanto aŭ spaco.
Por tio, du Vokaj Profiloj estas kreitaj:
Kun registrado malebligita
Kaj kun aŭtomata registra funkcio
Poste ni "aligas" CallProfile kun aŭtomata registra funkcio al la dezirata spaco.
En CMS estas tiel establita, ke se VokProfilo estas eksplicite ligita al iu ajn spaco aŭ spaco, tiam ĉi VokProfilo funkcias nur rilate al ĉi tiuj specifaj spacoj. Kaj se la VokProfilo ne estas ligita al iu spaco, tiam defaŭlte ĝi estas aplikata al tiuj spacoj al kiuj neniu VokProfilo estas eksplicite ligita.
Venontfoje mi provos priskribi kiel la CMS estas alirebla ekster la interna reto de la organizo.
Fontoj:
fonto: www.habr.com