Cisco Rapat Server 2.5.2. Kluster ing mode Scalable lan Resilient kanthi fungsi rekaman konferensi video

Ing Jeksa Agung bisa ngetokake iki aku bakal nuduhake lan nerangake sawetara saka intricacies nyetel server CMS ing mode kluster failover.


TeoriUmumé, ana telung jinis panyebaran server CMS:

• Single Gabungan(Single digabungake), i.e. iki minangka salah sawijining server sing kabeh layanan sing dibutuhake mlaku. Umume kasus, jinis penyebaran iki mung cocog kanggo akses klien internal lan ing lingkungan sing luwih cilik ing ngendi skalabilitas lan watesan redundansi saka server siji ora dadi masalah kritis, utawa ing kahanan sing CMS mung nindakake fungsi tartamtu, kayata ad hoc. konferensi ing Cisco UCM.

  Skema perkiraan kerja:
  

• Pisah Tunggal(Single Split) ngluwihi jinis panyebaran sadurungé kanthi nambah server kapisah kanggo akses njaba. Ing panyebaran warisan, iki tegese nyebarake server CMS ing segmen jaringan demiliterisasi (DMZ) ing ngendi klien eksternal bisa ngakses, lan siji server CMS ing inti jaringan ing ngendi klien internal bisa ngakses CMS. Model penyebaran tartamtu iki saiki diganti dening jinis sing disebut Ujung Tunggal, kang kasusun saka server Cisco Expressway, sing duwe utawa bakal duwe akeh kapabilitas bypass Firewall sing padha supaya klien ora perlu nambah server CMS pinggiran khusus.

  Skema perkiraan kerja:
  

• Scalable lan Resilient(Scalable and Fault Tolerant) Jinis iki kalebu redundansi kanggo saben komponèn, ngidini sistem kanggo tuwuh karo kabutuhan kanggo kapasitas maksimum nalika nyediakake redundansi ing cilik saka Gagal. Uga nggunakake konsep Single Edge kanggo nyedhiyakake akses eksternal sing aman. Iki minangka jinis sing bakal kita deleng ing episode iki. Yen kita ngerti carane nyebarake jinis kluster iki, kita ora mung ngerti jinis panyebaran liyane, nanging uga bisa ngerti carane nggawe klompok server CMS kanggo nampung wutah potensial sing dikarepake.

Sadurunge pindhah menyang penyebaran, sampeyan kudu ngerti sawetara perkara dhasar, yaiku

Komponen utama piranti lunak CMS:

• database: Ngidini sampeyan nggabungake sawetara konfigurasi, kayata rencana telpon, spasi pangguna, lan pangguna dhewe. Ndhukung clustering kanggo kasedhiyan dhuwur (master tunggal) mung.
• Telpon Bridge: layanan kanggo audio lan video conferencing sing nyedhiyani kontrol lengkap liwat Manajemen lan Processing telpon lan pangolahan multimedia. Ndhukung clustering kanggo kasedhiyan dhuwur lan skalabilitas.
• server XMPP: tanggung jawab kanggo ndhaptar lan otentikasi klien nggunakake Aplikasi Cisco Meeting lan/utawa WebRTC(komunikasi wektu nyata, utawa mung ing browser), uga sinyal interkomponen. Bisa kluster mung kanggo kasedhiyan dhuwur.
• Jembatan Web: Nyedhiyani akses klien menyang WebRTC.
• Loadbalancer: Nyedhiyani titik sambungan siji kanggo Cisco Meeting Aplikasi ing mode Split Single. Ngrungokake antarmuka eksternal lan port kanggo sambungan mlebu. Kajaba iku, load balancer nampa sambungan TLS sing mlebu saka server XMPP, sing bisa ngalih sambungan TCP saka klien eksternal.
  Ing skenario kita ora bakal dibutuhake.
• TURN server: Nyedhiyani teknologi bypass Firewall sing ngidini
  nyeleh CMS konco Firewall utawa NAT kanggo nyambungake klien external nggunakake Cisco Meeting App utawa piranti SIP. Ing skenario kita ora bakal dibutuhake.
• Admin web: Antarmuka administratif lan akses API, kalebu kanggo konferensi khusus Unified CM.

Mode Konfigurasi

Boten kados produk Cisco liyane, Cisco Meeting Server ndhukung telung cara konfigurasi kanggo nampung sembarang jinis penyebaran prajurit.

• Command Line (CLI): Antarmuka baris printah dikenal minangka MMP kanggo konfigurasi dhisikan lan tugas certificate.
• Administrator Web: Utamane kanggo konfigurasi sing gegandhengan karo CallBridge, utamane nalika nyetel server non-clustered siji.
• REST API: Digunakake kanggo tugas konfigurasi paling Komplek lan database clustered tugas related.

Saliyane ing ndhuwur, protokol digunakake SFTP kanggo nransfer file—biasane lisensi, sertifikat, utawa log—menyang lan saka server CMS.

Ing Panuntun penyebaran prajurit saka Cisco ditulis ing putih lan Inggris sing kluster kudu disebarake paling telu server (node) ing konteks database. Amarga Mung karo nomer ganjil saka kelenjar bakal mekanisme kanggo milih anyar Database Master karya, lan ing umum Master Database wis sambungan karo paling saka database server CMS.

Lan minangka praktik nuduhake, loro server (node) pancen ora cukup. Mekanisme pilihan dianggo nalika Master rebooted, server Slave dadi Master mung sawise server rebooted munggah. Nanging, yen ing kluster loro server, server Master tiba-tiba metu, mula server Budak ora bakal dadi Master, lan yen Budak metu, server Master sing isih ana bakal dadi Budak.

Nanging ing konteks XMPP, mesthine kudu ngumpulake klompok telung server, amarga yen, contone, sampeyan mateni layanan XMPP ing salah siji saka server kang XMMP ing status Leader, banjur ing server isih XMPP bakal tetep ing status Follower lan sambungan CallBridge kanggo XMPP bakal tiba mati, amarga CallBridge nyambung eksklusif menyang XMPP kanthi status Pemimpin. Lan iki kritis, amarga ... ora telpon siji bakal liwat.

Uga ing panyebaran padha nuntun cluster karo siji server XMPP dituduhake.

Lan njupuk menyang akun ndhuwur, dadi cetha kok: kerjane amarga iku ing mode failover.

Ing kasus kita, server XMPP bakal ana ing kabeh telung simpul.

Dianggep kabeh telung server kita wis munggah.

cathetan DNS

Sadurunge miwiti nyetel server, sampeyan kudu nggawe cathetan DNS А и SRV jinis:

Elinga yen ing cathetan DNS ana rong domain conto.com lan conf.conto.com. Example.com minangka domain sing kabeh pelanggan Cisco Unified Communication Manager bisa digunakake kanggo URI, sing paling mungkin ana ing infrastruktur sampeyan utawa kemungkinan ana. Utawa conto. com cocog karo domain sing padha digunakake pangguna kanggo alamat email. Utawa klien Jabber ing laptop sampeyan bisa uga duwe URI [email dilindhungi]. Domain conf.example.com minangka domain sing bakal dikonfigurasi kanggo pangguna Cisco Meeting Server. Domain saka Cisco Meeting Server bakal conf.example.com, dadi kanggo pangguna Jabber sing padha, pangguna@ URI kudu digunakake kanggo mlebu menyang Server Rapat Ciscoconf.conto.com.

Konfigurasi dhasar

Kabeh setelan sing diterangake ing ngisor iki ditampilake ing siji server, nanging kudu rampung ing saben server ing kluster.

QoS

Wiwit CMS ngasilake nyata-wektu lalu lintas sensitif kanggo telat lan mundhut paket, ing paling kasus dianjurake kanggo ngatur kualitas layanan (QoS). Kanggo entuk iki, CMS ndhukung paket menehi tag kanthi Kode Layanan Diferensiasi (DSCPs) sing digawe. Sanajan prioritas lalu lintas adhedhasar DSCP gumantung saka cara lalu lintas diproses dening komponen jaringan infrastruktur sampeyan, ing kasus kita bakal ngatur CMS karo prioritas DSCP khas adhedhasar praktik paling apik QoS.

Ing saben server kita bakal ngetik printah iki

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

Mangkono, kabeh lalu lintas video ditandhani AF41 (DSCP 0x22), kabeh lalu lintas swara ditandhani EF (DSCP 0x2E), jinis lalu lintas latensi kurang kayata SIP lan XMPP nggunakake AF31 (DSCP 0x1A).

Priksa:

NTP

Network Time Protocol (NTP) penting ora mung kanggo nyedhiyakake cap wektu sing akurat kanggo telpon lan konferensi, nanging uga kanggo verifikasi sertifikat.

Tambah server NTP menyang infrastruktur sampeyan kanthi printah kaya

ntp server add <server>

Ing kasus kita, ana rong server kasebut, mula bakal ana rong tim.
Priksa:

Lan atur zona wektu kanggo server kita

DNS

Kita nambah server DNS menyang CMS kanthi printah kaya:

dns add forwardzone <domain-name> <server ip>

Ing kasus kita, ana rong server kasebut, mula bakal ana rong tim.
Priksa:

Konfigurasi Antarmuka Jaringan

Kita ngatur antarmuka kanthi printah kaya:

ipv4 <interface> add <address>/<prefix length> <gateway>

Priksa:

Jeneng server (jeneng host)

Kita nyetel jeneng server kanthi printah kaya:

hostname <name>

Lan kita urip maneh.


Iki ngrampungake konfigurasi dhasar.

Sertifikat

TeoriCisco Meeting Server mbutuhake komunikasi ndhelik antarane macem-macem komponen, lan minangka asil, sertifikat X.509 dibutuhake kanggo kabeh penyebaran CMS. Dheweke mbantu njamin manawa layanan / server kasebut dipercaya dening server / layanan liyane.

Saben layanan mbutuhake sertifikat, nanging nggawe sertifikat sing kapisah kanggo saben layanan bisa nyebabake kebingungan lan kerumitan sing ora perlu. Untunge, kita bisa ngasilake pasangan kunci publik-pribadi sertifikat banjur digunakake maneh ing macem-macem layanan. Ing kasus kita, sertifikat sing padha bakal digunakake kanggo Call Bridge, XMPP Server, Web Bridge lan Admin Web. Mangkono, sampeyan kudu nggawe pasangan kunci sertifikat umum lan pribadi kanggo saben server ing kluster.

Nanging, clustering database duwe sawetara syarat sertifikat khusus lan mula mbutuhake sertifikat dhewe sing beda karo layanan liyane. CMS nggunakake sertifikat server, sing padha karo sertifikat sing digunakake dening server liyane, nanging uga ana sertifikat klien sing digunakake kanggo sambungan database. Sertifikat database digunakake kanggo otentikasi lan enkripsi. Tinimbang menehi jeneng pangguna lan sandhi kanggo klien kanggo nyambung menyang database, menehi sertifikat klien sing dipercaya dening server. Saben server ing kluster database bakal nggunakake pasangan kunci umum lan pribadi sing padha. Iki ngidini kabeh server ing kluster bisa ndhelik data kanthi cara sing mung bisa didekripsi dening server liyane sing uga nuduhake pasangan kunci sing padha.

Kanggo redundansi bisa digunakake, kluster database kudu kalebu minimal 3 server, nanging ora luwih saka 5, kanthi wektu round-trip maksimum 200 ms antarane anggota kluster. Watesan iki luwih mbatesi tinimbang kluster Call Bridge, mula asring dadi faktor watesan ing penyebaran geografis.

Peran database kanggo CMS nduweni sawetara syarat unik. Ora kaya peran liyane, mbutuhake sertifikat klien lan server, ing ngendi sertifikat klien duwe lapangan CN tartamtu sing diwenehake menyang server.

CMS nggunakake database postgres kanthi siji master lan sawetara replika sing padha. Mung ana siji basis data utama sekaligus ("server database"). Anggota kluster sing isih ana yaiku replika utawa "klien database".

Kluster database mbutuhake sertifikat server darmabakti lan sertifikat klien. Dheweke kudu ditandatangani dening sertifikat, biasane panguwasa sertifikat pribadi internal. Amarga anggota kluster database bisa dadi master, server database lan pasangan sertifikat klien (ngemot kunci umum lan pribadi) kudu disalin menyang kabeh server supaya bisa nganggep identitas klien utawa server database. Kajaba iku, sertifikat ROOT CA kudu dimuat kanggo mesthekake yen sertifikat klien lan server bisa diverifikasi.

Dadi, kita nggawe panjaluk sertifikat sing bakal digunakake dening kabeh layanan server kajaba database (bakal ana panjaluk sing kapisah kanggo iki) kanthi prentah kaya:

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

Ing CN kita nulis jeneng umum server kita. Contone, yen jeneng host saka server kita server01, server02, server03, banjur CN bakal server.example.com

Kita nindakake perkara sing padha ing rong server sing isih ana kanthi bedane printah kasebut bakal ngemot "jeneng host" sing cocog.

Kita ngasilake rong panjalukan kanggo sertifikat sing bakal digunakake dening layanan database kanthi prentah kaya:

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

pki csr dbclusterclient CN:postgres

ngendi dbclusterserver и dbclusterclient jeneng panjaluk kita lan sertifikat mangsa ngarep, jeneng host1(2)(3) jeneng server sing cocog.

Kita nindakake prosedur iki mung ing siji server (!), Lan kita bakal ngunggah sertifikat lan file .key sing cocog menyang server liyane.

Aktifake mode sertifikat klien ing AD CS

Sampeyan uga kudu nggabungake sertifikat kanggo saben server dadi siji file.Ing *NIX:

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

Ing Windows/DOS:

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

Lan upload menyang saben server:
1. Sertifikat server "Individu".
2. Sertifikat ROOT (bebarengan karo sing penengah, yen ana).
3. Certificates kanggo database ("server" lan "klien") lan file karo extension .key, kang kui nalika nggawe panjalukan kanggo "server" lan "klien" sertifikat database. File kasebut kudu padha ing kabeh server.
4. File saka kabeh telung sertifikat "individu".

Akibaté, sampeyan kudu njaluk kaya gambar file iki ing saben server.

Kluster Database

Saiki sampeyan duwe kabeh sertifikat sing diunggah menyang server CMS, sampeyan bisa ngatur lan ngaktifake clustering database ing antarane telung simpul kasebut. Langkah pisanan yaiku milih siji server minangka simpul master kluster database lan ngatur kanthi lengkap.

Master Database

Langkah pisanan kanggo nyetel replikasi database yaiku nemtokake sertifikat sing bakal digunakake kanggo database. Iki rampung nggunakake printah kaya:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Saiki ayo menehi CMS antarmuka sing digunakake kanggo clustering database kanthi printah:

database cluster localnode a

Banjur kita miwiti database kluster ing server utama kanthi printah:

database cluster initialize

Node Database Klien

Kita nindakake prosedur sing padha, mung tinimbang prentah database cluster initialize ketik printah kaya:

database cluster join <ip address existing master>

ing ngendi alamat ip alamat ip master sing ana ing server CMS ing ngendi kluster kasebut diinisialisasi, mung Master.

Kita mriksa kepiye kluster database bisa digunakake ing kabeh server kanthi prentah:

database cluster status

Kita nindakake perkara sing padha ing server katelu sing isih ana.

Akibaté, pranyata server pisanan kita yaiku Master, liyane yaiku Budak.

Layanan Admin Web

Aktifake layanan administrator web:

webadmin listen a 445

Port 445 dipilih amarga port 443 digunakake kanggo akses pangguna menyang klien web

Kita ngatur layanan Admin Web kanthi file sertifikat kanthi prentah kaya:

webadmin certs <keyfile> <certificatefile> <ca bundle>

Lan aktifake Admin Web kanthi printah:

webadmin enable

Yen kabeh apik, kita bakal nampa garis SUKSES sing nuduhake yen Admin Web wis dikonfigurasi kanthi bener kanggo jaringan lan sertifikat. Kita mriksa fungsi layanan nggunakake browser web lan ketik alamat administrator web, contone: cms.example.com: 445

Telpon Kluster Bridge

Telpon Bridge minangka siji-sijine layanan sing ana ing saben panyebaran CMS. Telpon Bridge minangka mekanisme konferensi utama. Iku uga menehi antarmuka SIP supaya telpon bisa routed menyang utawa saka, contone, Cisco Unified CM.

Printah sing diterangake ing ngisor iki kudu dieksekusi ing saben server kanthi sertifikat sing cocog.
Dadi:

Kita nggandhengake sertifikat karo layanan Call Bridge kanthi prentah kaya:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Kita ngiket layanan CallBridge menyang antarmuka sing dibutuhake kanthi prentah:

callbridge listen a

Lan miwiti maneh layanan kanthi printah:

callbridge restart

Saiki kita wis dikonfigurasi Call Bridges, kita bisa ngonfigurasi Call Bridge clustering. Call Bridge clustering beda karo database utawa clustering XMPP. Telpon Bridge Cluster bisa ndhukung saka 2 nganti 8 kelenjar tanpa watesan. Nyedhiyakake ora mung redundansi, nanging uga ngimbangi beban supaya konferensi bisa disebarake kanthi aktif ing server Call Bridge nggunakake distribusi telpon cerdas. CMS nduweni fitur tambahan, grup Call Bridge lan fitur sing gegandhengan sing bisa digunakake kanggo manajemen luwih lanjut.

Kluster jembatan telpon dikonfigurasi utamane liwat antarmuka admin web
Prosedur sing diterangake ing ngisor iki kudu ditindakake ing saben server ing kluster.
Supaya

1. Bukak web menyang Konfigurasi > Kluster.
2. Ing Telpon identitas Bridge Minangka jeneng unik, ketik callbridge[01,02,03] sing cocog karo jeneng server. Jeneng-jeneng iki sembarang, nanging kudu unik kanggo klompok iki. Iki minangka deskriptif amarga nuduhake yen dheweke minangka pengenal server [01,02,03].
3.B Kluster Telpon Bridges ketik URL administrator web server kita ing kluster, CMS[01,02,03].example.com:445, ing kolom Alamat. Dadi manawa kanggo nemtokake port. Sampeyan bisa ninggalake Peer link SIP domain kosong.
4. Tambah sertifikat kanggo kapercayan CallBridge saben server, file sing ngemot kabeh sertifikat server kita, sing digabungake menyang file iki ing wiwitan, kanthi prentah kaya:

callbridge trust cluster <trusted cluster certificate bundle>

Lan miwiti maneh layanan kanthi printah:

callbridge restart

Akibaté, ing saben server sampeyan kudu njaluk gambar iki:

Kluster XMPP

Layanan XMPP ing CMS digunakake kanggo nangani kabeh registrasi lan otentikasi kanggo Cisco Meeting Apps (CMA), kalebu klien web CMA WebRTC. Call Bridge dhewe uga tumindak minangka klien XMPP kanggo tujuan otentikasi lan mulane kudu dikonfigurasi kaya klien liyane. Toleransi kesalahan XMPP minangka fitur sing wis didhukung ing lingkungan produksi wiwit versi 2.1

Printah sing diterangake ing ngisor iki kudu dieksekusi ing saben server kanthi sertifikat sing cocog.
Dadi:

Kita nggandhengake sertifikat karo layanan XMPP kanthi prentah kaya:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Banjur nemtokake antarmuka ngrungokake kanthi printah:

xmpp listen a

Layanan XMPP mbutuhake domain unik. Iki minangka login kanggo pangguna. Ing tembung liyane, nalika pangguna nyoba mlebu nggunakake aplikasi CMA (utawa liwat klien WebRTC), dheweke ngetik userID@logindomain. Ing kasus kita bakal dadi userid@conf.conto.com. Napa ora mung conto. com? Ing panyebaran tartamtu, kita milih domain Unified CM sing bakal digunakake pangguna Jabber ing Unified CM minangka example.com, mula kita butuh domain sing beda kanggo pangguna CMS kanggo ngarahake telpon menyang lan saka CMS liwat domain SIP.

Nggawe domain XMPP nggunakake printah kaya:

xmpp domain <domain>

Lan aktifake layanan XMPP kanthi printah:

xmpp enable

Ing layanan XMPP, sampeyan kudu nggawe kredensial kanggo saben Call Bridge sing bakal digunakake nalika ndhaptar layanan XMPP. Jeneng-jeneng iki sewenang-wenang (lan ora ana hubungane karo jeneng unik sing sampeyan atur kanggo kluster jembatan telpon). Sampeyan kudu nambahake telung kreteg telpon ing siji server XMPP banjur ketik kredensial kasebut ing server XMPP liyane ing kluster amarga konfigurasi iki ora cocog karo database kluster. Mengko kita bakal ngatur saben Bridge Telpon kanggo nggunakake jeneng iki lan rahasia kanggo ndhaftar karo layanan XMPP.

Saiki kita kudu ngatur layanan XMPP ing server pisanan kanthi telung Call Bridges callbridge01, callbridge02 lan callbridge03. Saben akun bakal diwenehi sandhi acak. Banjur bakal dilebokake ing server Call Bridge liyane kanggo mlebu menyang server XMPP iki. Ketik printah ing ngisor iki:

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

Akibaté, kita mriksa apa sing kedadeyan karo printah:

xmpp callbridge list

Persis gambar sing padha kudu katon ing server sing isih ana sawise langkah-langkah sing diterangake ing ngisor iki.

Sabanjure, kita nambahake setelan sing padha ing rong server sing isih ana, mung nganggo printah

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

Kita nambah Rahasia kanthi ati-ati supaya, contone, ora ana spasi ekstra.


Akibaté, saben server kudu duwe gambar sing padha:

Sabanjure, ing kabeh server ing kluster, kita nemtokake file sing ngemot kabeh telung sertifikat, digawe sadurunge kanthi prentah kaya iki:

xmpp cluster trust <trust bundle>

Kita ngaktifake mode kluster xmpp ing kabeh server kluster kanthi printah:

xmpp cluster enable

Ing server pisanan kluster, kita miwiti nggawe kluster xmpp kanthi prentah:

xmpp cluster initialize

Ing server liyane, tambahake kluster menyang xmpp kanthi prentah kaya:

xmpp cluster join <ip address head xmpp server>

Kita mriksa saben server sukses nggawe kluster XMPP ing saben server kanthi printah:

xmpp status
xmpp cluster status

Server pisanan:

Server kapindho:

Server katelu:

Nyambungake Bridge Telpon menyang XMPP

Saiki kluster XMPP mlaku, sampeyan kudu ngatur layanan Call Bridge kanggo nyambung menyang kluster XMPP. Konfigurasi iki ditindakake liwat admin web.

Ing saben server, pindhah menyang Konfigurasi> Umum lan ing lapangan Jeneng unik Jembatan Telpon nulis jeneng unik cocog kanggo server Telpon Bridge callbridge[01,02,03]... Ing lapangan domain conf.example.ru lan sandhi sing cocog, sampeyan bisa Spy
ing server apa wae ing kluster kanthi prentah:

xmpp callbridge list

Ninggalake kolom "Server" kosong Callbridge bakal nindakake panelusuran DNS SRV kanggo _xmpp-component._tcp.conf.example.comkanggo nemokake server XMPP sing kasedhiya. Alamat IP kanggo nyambungake callbridges menyang XMPP bisa uga beda-beda ing saben server, gumantung saka apa nilai sing bali menyang panyuwunan rekaman _xmpp-component._tcp.conf.example.com callbridge, sing gumantung ing setelan prioritas kanggo rekaman DNS sing diwenehake.

Sabanjure, pindhah menyang Status> Umum kanggo verifikasi manawa layanan Telpon Pengantin kasil disambungake menyang layanan XMPP.

Jembatan Web

Ing saben server ing kluster, aktifake layanan Web Bridge kanthi prentah:

webbridge listen a:443

Kita ngatur layanan Web Bridge kanthi file sertifikat kanthi prentah kaya:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge ndhukung HTTPS. Bakal pangalihan HTTP menyang HTTPS yen dikonfigurasi nggunakake "http-redirect".
Kanggo ngaktifake pangalihan HTTP, gunakake printah ing ngisor iki:

webbridge http-redirect enable

Supaya Call Bridge ngerti yen Web Bridge bisa dipercaya sambungan saka Call Bridge, gunakake printah:

webbridge trust <certfile>

ngendi iki file ngemot kabeh telung sertifikat saka saben server ing kluster.

Gambar iki kudu ana ing saben server ing kluster.


Saiki kita kudu nggawe pangguna kanthi peran "appadmin", kita butuh supaya kita bisa ngatur kluster kita (!), Lan ora saben server ing kluster kasebut kanthi kapisah, kanthi cara iki setelan kasebut bakal ditrapake kanthi merata kanggo saben server sanajan ana kasunyatan sing padha bakal digawe sapisan.


Kanggo persiyapan luwih kita bakal nggunakake Posmen.

Kanggo wewenang, pilih Dasar ing bagean Wewenang

Kanggo ngirim printah kanthi bener menyang server CMS, sampeyan kudu nyetel enkoding sing dibutuhake

Kita nemtokake Webbridge kanthi printah POST karo parameter url lan makna cms.example.com



Ing webbridge dhewe, kita nuduhake paramèter sing dibutuhake: akses tamu, akses sing dilindhungi, lsp.

Telpon Bridge Groups

Kanthi gawan, CMS ora tansah nggunakake paling efisien sumber daya konferensi kasedhiya kanggo iku.

Contone, kanggo rapat karo telung peserta, saben peserta bisa mungkasi ing telung beda Telpon Bridges. Supaya telung peserta iki bisa komunikasi karo saben liyane, Telpon Bridges bakal kanthi otomatis nggawe sambungan antarane kabeh server lan klien ing Space padha, supaya kabeh katon kaya kabeh klien ing server padha. Sayange, kekurangane yaiku konferensi 3 wong saiki bakal nggunakake 9 port media. Iki jelas nggunakake sumber daya sing ora efisien. Kajaba iku, nalika Jembatan Telpon pancen kakehan beban, mekanisme standar yaiku terus nampa telpon lan nyedhiyakake layanan kualitas suda kanggo kabeh pelanggan Jembatan Telpon kasebut.

Masalah kasebut ditanggulangi kanthi nggunakake fitur Call Bridge Group. Fitur iki dikenalaké ing versi 2.1 saka piranti lunak Cisco Meeting Server lan wis ditambahi kanggo ndhukung mbukak balancing kanggo loro mlebu lan metu Cisco Meeting App (CMA) telpon, kalebu peserta WebRTC.

Kanggo ngatasi masalah panyambungan maneh, telung watesan beban sing bisa dikonfigurasi wis dikenalake kanggo saben Jembatan Telpon:

LoadLimit - iki minangka beban angka maksimum kanggo Jembatan Telpon tartamtu. Saben platform duwe watesan beban sing disaranake, kayata 96000 kanggo CMS1000 lan 1.25 GHz saben vCPU kanggo mesin virtual. Telpon sing beda-beda nggunakake sumber daya tartamtu gumantung saka resolusi lan tingkat pigura saka peserta.
NewConferenceLoadLimitBasisPoints (standar 50% loadLimit) - nyetel watesan mbukak server, sawise konferensi anyar ditolak.
Ana KonferensiLoadLimitBasisPoints (standar 80% saka loadLimit) - nilai beban server sawise peserta sing melu konferensi sing wis ana bakal ditolak.

Nalika fitur iki dirancang kanggo distribusi telpon lan mbukak imbangan, grup liyane kayata TURN Server, Web Bridge Server lan Recorder uga bisa diutus kanggo Telpon Bridge Groups supaya padha uga bisa diklompokaké kanthi bener kanggo nggunakake optimal. Yen samubarang obyek kasebut ora ditugasake menyang grup telpon, mesthine bakal kasedhiya kanggo kabeh server tanpa prioritas tartamtu.

Parameter kasebut dikonfigurasi ing kene: cms.example.com:445/api/v1/system/configuration/cluster

Sabanjure, kita nuduhake saben callbridge sing kalebu klompok callbridge:

Callbridge pisanan

Callbridge kapindho

Callbridge katelu


Mangkono, kita ngatur grup Telpon Brdige kanggo luwih irit nggunakake sumber saka Cisco Meeting Server cluster.

Ngimpor pangguna saka Active Directory

Layanan Web Admin duwe bagean konfigurasi LDAP, nanging ora menehi opsi konfigurasi rumit, lan informasi ora disimpen ing database kluster, supaya konfigurasi kudu rampung, kanthi manual ing saben server liwat antarmuka Web, utawa liwat. API, lan supaya kita "telu" Aja tangi "kita isih bakal nyetel data liwat API.

Nggunakake URL kanggo ngakses cms01.example.com:445/api/v1/ldapServers nggawe obyek LDAP Server, nemtokake paramèter kayata:

• IP server
• nomer port
• Jeneng pangguna
• sandi
• ngamanake

Aman - pilih bener utawa salah gumantung ing port, 389 - ora aman, 636 - dilindhungi.


Pemetaan paramèter sumber LDAP kanggo atribut ing Cisco Meeting Server.
Pemetaan LDAP memetakan atribut ing direktori LDAP menyang atribut ing CMS. Atribut nyata:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Katrangan saka atributIADB makili ID mlebu pangguna ing CMS. Amarga iki minangka server LDAP Microsoft Active Directory, CMS JID map menyang sAMAccountName ing LDAP, sing ateges ID login Active Directory pangguna. Uga elinga yen sampeyan njupuk sAMAccountName lan nambah domain conf.pod6.cms.lab ing pungkasan amarga iki minangka login pangguna sing bakal digunakake kanggo mlebu menyang CMS.

nameMapping cocog karo apa sing ana ing lapangan Active Directory displayName menyang kolom jeneng CMS pangguna.

coSpaceNameMapping nggawe jeneng spasi CMS adhedhasar kolom displayName. Atribut iki, bebarengan karo atribut coSpaceUriMapping, sing dibutuhake kanggo nggawe spasi kanggo saben pangguna.

coSpaceUriMapping nemtokake bagean pangguna saka URI sing digandhengake karo ruang pribadi pangguna. Sawetara domain bisa dikonfigurasi supaya bisa ditelpon menyang papan. Yen bagean pangguna cocog karo kolom iki kanggo salah sawijining domain kasebut, telpon bakal diarahake menyang ruang pangguna kasebut.

coSpaceSecondaryUriMapping nemtokake URI kapindho kanggo nggayuh spasi. Iki bisa digunakake kanggo nambah alias numerik kanggo nuntun telpon menyang ruang pangguna sing diimpor minangka alternatif kanggo URI alfanumerik sing ditetepake ing parameter coSpaceUriMapping.

Server LDAP lan pemetaan LDAP dikonfigurasi. Saiki sampeyan kudu nyambungake kanthi nggawe sumber LDAP.

Nggunakake URL kanggo ngakses cms01.example.com:445/api/v1/ldapSource nggawe obyek Sumber LDAP, nemtokake paramèter kayata:

• server
• pemetaan
• dhasarDn
• Filter

Saiki konfigurasi LDAP wis rampung, sampeyan bisa nindakake operasi sinkronisasi manual.

Kita nindakake iki ing antarmuka Web saben server kanthi ngeklik Sink saiki bagean Direktori aktif


utawa liwat API karo printah POST nggunakake URL kanggo ngakses cms01.example.com:445/api/v1/ldapSyncs

Konferensi Ad-Hoc

Apa iki?Ing konsep tradisional, konferensi yaiku nalika rong peserta ngobrol, lan salah sijine peserta (nggunakake piranti sing kadhaptar karo Unified CM) mencet tombol "Konferensi", nelpon wong liya, lan sawise ngomong karo pihak katelu kasebut. , menet tombol "Konferensi" maneh. kanggo nggabungake kabeh peserta ing konferensi tripartit.

Sing mbedakake konferensi Ad-Hoc saka konferensi sing dijadwalake ing CMS yaiku konferensi Ad-Hoc ora mung telpon SIP menyang CMS. Nalika inisiator konferensi ngeklik tombol Konferensi kaping pindho kanggo ngundang kabeh wong menyang rapat sing padha, Unified CM kudu nelpon API menyang CMS kanggo nggawe konferensi on-the-fly sing banjur kabeh telpon ditransfer. Kabeh iki kedadeyan tanpa disadari dening para peserta.

Iki tegese Unified CM kudu ngatur kredensial API lan alamat WebAdmin / port layanan uga SIP Trunk langsung menyang server CMS kanggo nerusake telpon.

Yen perlu, CUCM bisa kanthi dinamis nggawe spasi ing CMS supaya saben telpon bisa tekan CMS lan cocog karo aturan telpon mlebu sing dimaksudake kanggo spasi.

Integrasi karo CUCM diatur kanthi cara sing padha kaya sing diterangake ing artikel kasebut sadurunge kajaba ing Cisco UCM sampeyan kudu nggawe telung trunks kanggo CMS, telung Konferensi Bridges, ing Profil Keamanan SIP nemtokake telung Jeneng Subject, Groups Route, Dhaptar Route, Media Resourse Groups lan Media Resourse Group Dhaftar, lan nambah sawetara aturan nuntun. kanggo Cisco Meeting Server.

Profil Keamanan SIP:


Trunks:


Saben batang katon padha:




Jembatan Konferensi


Saben Jembatan Konferensi katon padha:


Grup Rute


Daftar Rute


Grup Sumber Media


Dhaftar Grup Sumber Media

Aturan Telpon

Ora kaya sistem manajemen telpon sing luwih maju kayata Unified CM utawa Expressway, CMS mung nggoleki domain ing kolom SIP Request-URI kanggo telpon anyar. Dadi yen SIP INVITE kanggo sip: [email dilindhungi]CMS mung peduli babagan domain.com. CMS ngetutake aturan iki kanggo nemtokake ngendi arep ngarahake telpon:

1. CMS pisanan nyoba kanggo cocog domain SIP karo domain diatur ing aturan telpon mlebu. Telpon kasebut banjur bisa diarahake menyang spasi ("diangkah") utawa pangguna tartamtu, IVR internal, utawa tujuan Microsoft Lync/Skype for Business (S4B) sing diintegrasi langsung.
2. Yen ora ana sing cocog karo aturan telpon sing mlebu, CMS bakal nyoba cocog karo domain sing dikonfigurasi ing tabel penerusan telpon. Yen cocog digawe, aturan kasebut bisa kanthi tegas nolak telpon utawa nerusake telpon kasebut. Ing wektu iki, CMS bisa nulis ulang domain, sing kadhangkala migunani kanggo nelpon domain Lync. Sampeyan uga bisa milih kanggo pass uncalan, kang tegese ora ana lapangan bakal luwih diowahi, utawa nggunakake rencana CMS telpon internal. Yen ora ana sing cocog karo aturan sing diterusake telpon, standar kasebut yaiku nolak telpon kasebut. Elinga yen ing CMS, sanajan telpon kasebut "diterusake", media kasebut isih ana ing CMS, tegese bakal ana ing jalur sinyal lan lalu lintas media.
Banjur mung telpon sing diterusake tundhuk karo aturan telpon metu. Setelan iki nemtokake tujuan kanggo ngirim telpon, jinis trunk (apa iku telpon Lync anyar utawa telpon SIP standar), lan konversi apa wae sing bisa ditindakake yen transfer ora dipilih ing aturan nerusake telpon.

Punika log nyata babagan apa sing kedadeyan sajrone konferensi Ad-Hoc

Gambar kasebut nuduhake kurang apik (aku ora ngerti carane nggawe luwih apik), mula aku bakal nulis log kaya iki:

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:12

Konferensi Ad-Hoc dhewe:


Aturan Telpon mlebu
Konfigurasi paramèter telpon mlebu perlu kanggo bisa nampa telpon ing CMS. Kaya sing sampeyan deleng ing persiyapan LDAP, kabeh pangguna diimpor nganggo domain conf.pod6.cms.lab. Dadi minimal, sampeyan pengin nelpon menyang domain iki kanggo target spasi. Sampeyan uga kudu nyiyapake aturan kanggo kabeh sing dimaksudake kanggo jeneng domain sing mumpuni (lan bisa uga alamat IP) saben server CMS. Kontrol telpon eksternal kita, Unified CM, bakal ngonfigurasi batang SIP khusus kanggo saben server CMS kanthi individu. Gumantung apa tujuan batang SIP iki minangka alamat IP utawa FQDN server bakal nemtokake manawa CMS kudu dikonfigurasi kanggo nampa telpon sing diarahake menyang alamat IP utawa FQDN.

Domain sing nduweni aturan mlebu prioritas paling dhuwur digunakake minangka domain kanggo spasi pangguna apa wae. Nalika pangguna nyelarasake liwat LDAP, CMS kanthi otomatis nggawe spasi, nanging mung bagean pangguna saka URI (coSpaceUriMapping), contone, user.space. Part domain URI lengkap digawe adhedhasar aturan iki. Nyatane, yen sampeyan mlebu menyang Web Bridge ing wektu iki, sampeyan bakal weruh yen Space URI ora duwe domain. Kanthi nyetel aturan iki minangka prioritas paling dhuwur, sampeyan nyetel domain kanggo spasi sing digawe conf.contone.com.


Aturan Telpon metu

Kanggo ngidini pangguna nelpon metu menyang kluster Unified CM, sampeyan kudu ngatur aturan metu. Domain titik pungkasan sing didaftar ing Unified CM, kayata Jabber, yaiku example.com. Telpon menyang domain iki kudu dialihake minangka panggilan SIP standar menyang simpul pangolahan telpon Unified CM. Server utama yaiku cucm-01.example.com, lan server tambahan yaiku cucm-02.example.com.

Aturan pisanan njlèntrèhaké nuntun paling gampang saka telpon antarane server kluster.

lapangan Lokal saka domain tanggung jawab kanggo apa sing bakal ditampilake ing panelpon SIP-URI kanggo wong sing diarani sawise simbol "@". Yen kita ninggalake kosong, banjur sawise simbol "@" bakal ana alamat IP CUCM kang liwat telpon iki. Yen kita nemtokake domain, banjur sawise simbol "@" bakal ana domain. Iki perlu supaya bisa nelpon maneh, yen ora, ora bisa nelpon maneh liwat SIP-URI name@ip-address.

Telpon nalika dituduhake Lokal saka domain


Telpon kapan Ora dituduhake Lokal saka domain


Priksa manawa sampeyan nemtokake kanthi jelas Enkripsi utawa Ora Enkripsi kanggo telpon metu, amarga ora ana sing bisa digunakake karo parameter Otomatis.

Ngrekam

Konferensi video direkam dening server Rekam. Recorder persis padha Cisco Meeting Server. Perekam ora mbutuhake instalasi lisensi apa wae. Lisensi rekaman dibutuhake kanggo server sing nganggo layanan CallBridge, yaiku. lisensi Rekam dibutuhake lan kudu Applied kanggo komponèn CallBridge, lan ora kanggo server mlaku Recorder. Perekam tumindak minangka klien Extensible Messaging and Presence Protocol (XMPP), saengga server XMPP kudu diaktifake ing server hosting CallBridge.

Amarga Kita duwe kluster lan lisensi kudu "digawe dowo" ing kabeh telung server ing kluster kasebut. Banjur mung ing akun pribadhi ing lisensi sing digandhengake (nambah) alamat MAC saka antarmuka a kabeh server CMS sing kalebu ing kluster.

Lan iki gambar sing kudu ing saben server ing kluster

Umumé, ana sawetara skenario kanggo nyelehake Perekam, nanging kita bakal tetep iki:


Sadurunge nyiyapake Perekam, sampeyan kudu nyiyapake papan ing ngendi konferensi video bakal direkam. Sejatine kene pranala, carane nyiyapake kabeh Rekaman. Aku fokus ing poin lan rincian penting:

1. Iku luwih apik kanggo slip certificate saka server pisanan ing kluster.
2. Kesalahan "Recorder ora kasedhiya" bisa kedadeyan amarga sertifikat salah kasebut ing Trust Recorder.
3. Nulis bisa uga ora bisa digunakake yen direktori NFS sing ditemtokake kanggo ngrekam dudu direktori root.

Kadhangkala ana perlu kanggo ngrekam konferensi kanthi otomatis siji pangguna utawa papan tartamtu.

Kanggo iki, rong CallProfiles digawe:
Kanthi rekaman dipatèni


Lan kanthi fungsi ngrekam otomatis


Sabanjure, kita "masang" CallProfile kanthi fungsi rekaman otomatis menyang papan sing dikarepake.


Ing CMS wis ditetepake yen CallProfile disambungake kanthi jelas menyang papan utawa papan apa wae, banjur CallProfile iki mung bisa digunakake ing hubungane karo spasi tartamtu kasebut. Lan yen CallProfile ora kaiket ing papan apa wae, mula kanthi standar ditrapake ing papan kasebut sing ora ana CallProfile sing diikat kanthi jelas.

Sabanjure aku bakal nyoba kanggo njlèntrèhaké carane CMS diakses ing njaba jaringan internal organisasi.

Sumber:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

Source: www.habr.com