Cisco Meeting Server 2.5.2. Klaster v režime Scalable and Resilient s funkciou nahrávania videokonferencií

V tomto čísle ukážem a vysvetlím niektoré zložitosti nastavenia servera CMS v režime klastra prepnutia pri zlyhaní.


ТеорияVo všeobecnosti existujú tri typy nasadenia servera CMS:

• Jednoduché Kombinované(Jednoduché kombinované), t.j. toto je jeden server, na ktorom bežia všetky potrebné služby. Vo väčšine prípadov je tento typ nasadenia vhodný len pre interný klientsky prístup a v menších prostrediach, kde škálovateľnosť a obmedzenia redundancie jedného servera nie sú kritickým problémom, alebo v situáciách, keď CMS vykonáva len určité funkcie, ako napríklad ad hoc konferencie na Cisco UCM.

  Približná schéma práce:
  

• Single Split(Single Split) rozširuje predchádzajúci typ nasadenia pridaním samostatného servera pre externý prístup. V starších nasadeniach to znamenalo nasadenie servera CMS v segmente demilitarizovanej siete (DMZ), kde k nemu mali prístup externí klienti, a jedného servera CMS v jadre siete, kde mali k CMS prístup interní klienti. Tento konkrétny model nasadenia je teraz nahradený typom tzv Single Edge, ktorý pozostáva zo serverov Rýchlostná cesta Cisco, ktoré buď majú alebo budú mať veľa rovnakých možností obchádzania brány firewall, takže zákazníci nemusia pridávať vyhradený server CMS.

  Približná schéma práce:
  

• Škálovateľné a odolné(Scalable and Fault Tolerant) Tento typ zahŕňa redundanciu pre každý komponent, čo umožňuje systému rásť podľa vašich potrieb na maximálnu kapacitu a zároveň poskytuje redundanciu v prípade zlyhania. Používa tiež koncept Single Edge na zabezpečenie bezpečného externého prístupu. Toto je typ, na ktorý sa pozrieme v tejto epizóde. Ak pochopíme, ako nasadiť tento typ klastra, pochopíme nielen ďalšie typy nasadení, ale budeme tiež schopní pochopiť, ako vytvoriť klastre serverov CMS, aby sme uspokojili potenciálny rast dopytu.

Predtým, ako prejdete k nasadeniu, musíte pochopiť niektoré základné veci, konkrétne

Hlavné softvérové ​​komponenty CMS:

• databázy: Umožňuje vám kombinovať niektoré konfigurácie, ako napríklad plán vytáčania, používateľské priestory a samotných používateľov. Podporuje len klastrovanie pre vysokú dostupnosť (jeden hlavný server).
• Zavolajte Bridge: služba pre audio a video konferencie, ktorá poskytuje plnú kontrolu nad riadením a spracovaním hovorov a multimediálnymi procesmi. Podporuje klastrovanie pre vysokú dostupnosť a škálovateľnosť.
• server XMPP: zodpovedný za registráciu a autentifikáciu klientov pomocou aplikácie Cisco Meeting Application a/alebo WebRTC(komunikácia v reálnom čase alebo jednoducho v prehliadači), ako aj medzizložková signalizácia. Môže byť zoskupený iba pre vysokú dostupnosť.
• Webový most: Poskytuje klientsky prístup k WebRTC.
• Loadbalancer: Poskytuje jeden bod pripojenia pre aplikácie Cisco Meeting Apps v režime Single Split. Počúva externé rozhranie a port pre prichádzajúce pripojenia. Rovnako nástroj na vyrovnávanie zaťaženia akceptuje prichádzajúce pripojenia TLS zo servera XMPP, cez ktorý môže prepínať pripojenia TCP od externých klientov.
  V našom scenári to nebude potrebné.
• TURN server: Poskytuje technológiu premostenia brány firewall, ktorá umožňuje
  umiestnite náš CMS za bránu firewall alebo NAT na pripojenie externých klientov pomocou aplikácie Cisco Meeting App alebo zariadení SIP. V našom scenári to nebude potrebné.
• Webový správca: Administratívne rozhranie a prístup k API, vrátane špeciálnych konferencií Unified CM.

Konfiguračné režimy

Na rozdiel od väčšiny ostatných produktov Cisco, Cisco Meeting Server podporuje tri konfiguračné metódy na prispôsobenie sa akémukoľvek typu nasadenia.

• Príkazový riadok (CLI): Rozhranie príkazového riadka známe ako MMP pre počiatočnú konfiguráciu a certifikačné úlohy.
• Webový administrátor: Predovšetkým pre konfigurácie súvisiace s CallBridge, najmä pri nastavovaní jedného servera bez klastrov.
• REST API: Používa sa pre najzložitejšie konfiguračné úlohy a úlohy súvisiace s klastrovanou databázou.

Okrem vyššie uvedeného sa používa protokol SFTP na prenos súborov – zvyčajne licencií, certifikátov alebo protokolov – na a zo servera CMS.

V návodoch na nasadenie od spoločnosti Cisco je bielo a anglicky napísané, že je potrebné nasadiť klaster aspoň tri servery (uzly) v kontexte databáz. Pretože Iba s nepárnym počtom uzlov bude mechanizmus výberu nového Master databázy fungovať a vo všeobecnosti má Database Master spojenie s väčšinou databáz CMS servera.

A ako ukazuje prax, dva servery (uzly) naozaj nestačia. Mechanizmus výberu funguje, keď sa reštartuje hlavný server, podriadený server sa stane hlavným až po spustení reštartovaného servera. Ak však v klastri dvoch serverov náhle zhasne hlavný server, potom sa podriadený server nestane hlavným, a ak zhasne podriadený, potom sa zostávajúci hlavný server stane podriadeným.

Ale v kontexte XMPP by bolo naozaj potrebné zostaviť klaster troch serverov, pretože ak napríklad zakážete službu XMPP na jednom zo serverov, na ktorých je XMMP v stave lídra, potom na zostávajúcom serveri zostane XMPP v stave nasledovateľa a spojenia CallBridge s XMPP spadnú, pretože CallBridge sa pripája výhradne k XMPP so statusom Leader. A to je kritické, pretože... neprejde ani jeden hovor.

V rovnakých sprievodcoch nasadením je tiež demonštrovaný klaster s jedným serverom XMPP.

A berúc do úvahy vyššie uvedené, je jasné prečo: funguje to, pretože je v režime núdzového prepnutia.

V našom prípade bude server XMPP prítomný na všetkých troch uzloch.

Predpokladá sa, že všetky tri naše servery sú v prevádzke.

DNS záznamy

Skôr ako začnete nastavovať servery, musíte vytvoriť záznamy DNS А и SRV typy:

Upozorňujeme, že v našich záznamoch DNS sú dve domény example.com a conf.example.com. Example.com je doména, ktorú môžu všetci predplatitelia aplikácie Cisco Unified Communication Manager použiť pre svoje identifikátory URI, ktoré sa s najväčšou pravdepodobnosťou nachádzajú vo vašej infraštruktúre alebo pravdepodobne budú prítomné. Alebo example.com zodpovedá rovnakej doméne, ktorú používatelia používajú pre svoje e-mailové adresy. Alebo klient Jabber na vašom notebooku môže mať URI [chránené e-mailom]. doména conf.example.com je doména, ktorá bude nakonfigurovaná pre používateľov Cisco Meeting Server. Doménou servera Cisco Meeting Server bude conf.example.com, takže pre toho istého používateľa Jabber by bolo potrebné použiť identifikátor URI user@ na prihlásenie na server Cisco Meeting Serverconf.example.com.

Základná konfigurácia

Všetky nastavenia popísané nižšie sú zobrazené na jednom serveri, ale je potrebné ich vykonať na každom serveri v klastri.

QoS

Keďže CMS generuje real-time prenos citlivý na oneskorenia a stratu paketov, vo väčšine prípadov sa odporúča nakonfigurovať kvalitu služby (QoS). Aby sa to dosiahlo, CMS podporuje označovanie paketov kódmi diferencovaných služieb (DSCP), ktoré generuje. Hoci prioritizácia prevádzky na základe DSCP závisí od toho, ako je prevádzka spracovaná sieťovými komponentmi vašej infraštruktúry, v našom prípade nakonfigurujeme náš CMS s typickou prioritizáciou DSCP na základe osvedčených postupov QoS.

Na každom serveri zadáme tieto príkazy

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

Všetka video prevádzka bola teda označená AF41 (DSCP 0x22), všetka hlasová prevádzka bola označená EF (DSCP 0x2E), ostatné typy prevádzky s nízkou latenciou ako SIP a XMPP používajú AF31 (DSCP 0x1A).

skontrolujte:

NTP

Network Time Protocol (NTP) je dôležitý nielen pre poskytovanie presných časových pečiatok hovorov a konferencií, ale aj pre overovanie certifikátov.

Pridajte NTP servery do svojej infraštruktúry pomocou príkazu ako

ntp server add <server>

V našom prípade sú dva takéto servery, takže tímy budú dva.
skontrolujte:

A nastavte časové pásmo pre náš server

DNS

DNS servery pridávame do CMS príkazom ako:

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

V našom prípade sú dva takéto servery, takže tímy budú dva.
skontrolujte:

Konfigurácia sieťového rozhrania

Rozhranie nakonfigurujeme príkazom ako:

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

skontrolujte:

Názov servera (názov hostiteľa)

Názov servera nastavíme príkazom ako:

hostname <name>

A reštartujeme.


Tým je základná konfigurácia hotová.

Certifikáty

ТеорияCisco Meeting Server vyžaduje šifrovanú komunikáciu medzi rôznymi komponentmi, a preto sú pre všetky nasadenia CMS potrebné certifikáty X.509. Pomáhajú zabezpečiť, aby služby/server boli dôveryhodné inými servermi/službami.

Každá služba vyžaduje certifikát, ale vytváranie samostatných certifikátov pre každú službu môže viesť k nejasnostiam a zbytočnej zložitosti. Našťastie môžeme vygenerovať pár verejného a súkromného kľúča certifikátu a potom ich znova použiť vo viacerých službách. V našom prípade bude rovnaký certifikát použitý pre Call Bridge, XMPP Server, Web Bridge a Web Admin. Preto musíte vytvoriť pár verejných a súkromných kľúčov certifikátu pre každý server v klastri.

Klastrovanie databáz má však niektoré špeciálne požiadavky na certifikáty, a preto vyžaduje vlastné certifikáty, ktoré sa líšia od certifikátov iných služieb. CMS používa certifikát servera, ktorý je podobný certifikátom, ktoré používajú iné servery, ale existuje aj klientsky certifikát používaný na pripojenie k databáze. Databázové certifikáty sa používajú na autentifikáciu aj šifrovanie. Namiesto poskytnutia používateľského mena a hesla pre klienta na pripojenie k databáze predstavuje klientsky certifikát, ktorý je dôveryhodný serverom. Každý server v databázovom klastri bude používať rovnaký pár verejných a súkromných kľúčov. To umožňuje všetkým serverom v klastri šifrovať údaje takým spôsobom, že ich môžu dešifrovať iba iné servery, ktoré tiež zdieľajú rovnaký pár kľúčov.

Aby redundancia fungovala, databázové klastre musia pozostávať z minimálne 3 serverov, ale nie viac ako 5, s maximálnym časom obehu medzi všetkými členmi klastra 200 ms. Tento limit je reštriktívnejší ako pre klastrovanie Call Bridge, takže je často limitujúcim faktorom v geograficky distribuovaných nasadeniach.

Databázová rola pre CMS má množstvo jedinečných požiadaviek. Na rozdiel od iných rolí vyžaduje certifikát klienta a servera, pričom certifikát klienta má špecifické pole CN, ktoré je prezentované serveru.

CMS používa postgres databázu s jedným masterom a niekoľkými úplne identickými replikami. Naraz existuje iba jedna primárna databáza („databázový server“). Zostávajúcimi členmi klastra sú repliky alebo „databázoví klienti“.

Databázový klaster vyžaduje certifikát dedikovaného servera a certifikát klienta. Musia byť podpísané certifikátmi, zvyčajne internou súkromnou certifikačnou autoritou. Pretože každý člen databázového klastra sa môže stať hlavným, páry certifikátov databázového servera a klienta (obsahujúce verejný a súkromný kľúč) sa musia skopírovať na všetky servery, aby mohli prevziať identitu klienta alebo databázového servera. Okrem toho sa musí zaviesť koreňový certifikát CA, aby sa zabezpečilo overenie certifikátov klienta a servera.

Vytvoríme teda požiadavku na certifikát, ktorý budú používať všetky serverové služby okrem databázy (na to bude samostatná požiadavka) s príkazom ako:

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

V KN píšeme všeobecný názov našich serverov. Napríklad, ak sú názvy hostiteľov našich serverov server01, server02, server03, potom bude CN server.example.com

To isté robíme na zvyšných dvoch serveroch s tým rozdielom, že príkazy budú obsahovať zodpovedajúce „názvy hostiteľov“

Vygenerujeme dve žiadosti o certifikáty, ktoré bude používať databázová služba s príkazmi ako:

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

pki csr dbclusterclient CN:postgres

kde dbclusterserver и dbclusterclient mená našich požiadaviek a budúcich certifikátov, hostname1(2)(3) názvy príslušných serverov.

Tento postup vykonávame iba na jednom serveri (!) a certifikáty a príslušné súbory .key nahráme na iné servery.

Povoliť režim certifikátu klienta v AD CS

Musíte tiež zlúčiť certifikáty pre každý server do jedného súboru.Dňa *NIX:

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

V systéme Windows/DOS:

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

A nahrajte na každý server:
1. „Individuálny“ certifikát servera.
2. Koreňový certifikát (spolu s prechodnými, ak existujú).
3. Certifikáty k databáze („server“ a „klient“) a súbory s príponou .key, ktoré boli vygenerované pri vytváraní žiadosti o certifikáty databázy „server“ a „klient“. Tieto súbory musia byť rovnaké na všetkých serveroch.
4. Súbor všetkých troch „individuálnych“ certifikátov.

V dôsledku toho by ste na každom serveri mali dostať niečo ako tento obrázok súboru.

Databázový klaster

Teraz, keď máte všetky certifikáty nahrané na servery CMS, môžete nakonfigurovať a povoliť klastrovanie databázy medzi tromi uzlami. Prvým krokom je vybrať jeden server ako hlavný uzol databázového klastra a plne ho nakonfigurovať.

Hlavná databáza

Prvým krokom pri nastavovaní replikácie databázy je špecifikácia certifikátov, ktoré sa použijú pre databázu. To sa vykonáva pomocou príkazu ako:

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

Teraz povedzme CMS, ktoré rozhranie má použiť na klastrovanie databáz pomocou príkazu:

database cluster localnode a

Potom inicializujeme databázu klastra na hlavnom serveri príkazom:

database cluster initialize

Uzly klientskej databázy

Robíme rovnaký postup, len namiesto príkazu inicializácia databázového klastra zadajte príkaz ako:

database cluster join <ip address existing master>

kde ip adresa existujúca hlavná ip adresa servera CMS, na ktorom bol klaster inicializovaný, jednoducho Master.

Skontrolujeme, ako funguje náš databázový klaster na všetkých serveroch pomocou príkazu:

database cluster status

To isté robíme na zostávajúcom treťom serveri.

Výsledkom je, že náš prvý server je Master, zvyšok sú Slaves.

Web Admin Service

Povoliť službu správcu webu:

webadmin listen a 445

Port 445 bol zvolený, pretože port 443 sa používa na prístup používateľa k webovému klientovi

Službu Web Admin nakonfigurujeme pomocou súborov certifikátov pomocou príkazu ako:

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

A povoľte Web Admin príkazom:

webadmin enable

Ak je všetko v poriadku, dostaneme riadky ÚSPECH, ktoré označujú, že Web Admin je správne nakonfigurovaný pre sieť a certifikát. Funkčnosť služby skontrolujeme pomocou webového prehliadača a zadáme adresu správcu webu, napr. cms.example.com: 445

Zavolajte Bridge Cluster

Call Bridge je jediná služba prítomná v každom nasadení CMS. Call Bridge je hlavným konferenčným mechanizmom. Poskytuje tiež rozhranie SIP, takže hovory naň alebo z neho môže smerovať napríklad Cisco Unified CM.

Príkazy popísané nižšie sa musia vykonať na každom serveri s príslušnými certifikátmi.
Takže:

Certifikáty spájame so službou Call Bridge s príkazom ako:

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

Služby CallBridge naviažeme na rozhranie, ktoré potrebujeme, pomocou príkazu:

callbridge listen a

A reštartujte službu príkazom:

callbridge restart

Teraz, keď máme nakonfigurované naše mosty hovorov, môžeme nakonfigurovať klastrovanie mostov hovorov. Klastrovanie mosta hovorov sa líši od klastrovania databázy alebo XMPP. Call Bridge Cluster môže podporovať 2 až 8 uzlov bez akýchkoľvek obmedzení. Poskytuje nielen redundanciu, ale aj vyvažovanie záťaže, takže konferencie môžu byť aktívne distribuované cez servery Call Bridge pomocou inteligentnej distribúcie hovorov. CMS má ďalšie funkcie, skupiny Call Bridge a súvisiace funkcie, ktoré možno použiť na ďalšiu správu.

Klastrovanie premostenia hovorov sa konfiguruje predovšetkým prostredníctvom webového administrátorského rozhrania
Postup popísaný nižšie sa musí vykonať na každom serveri v klastri.
Takže,

1. Prejdite cez web na Konfigurácia > Klaster.
2. Zavolajte identitu Bridge Ako jedinečný názov zadajte callbridge[01,02,03] zodpovedajúci názvu servera. Tieto názvy sú ľubovoľné, ale musia byť jedinečné pre tento klaster. Majú popisný charakter, pretože naznačujú, že ide o serverové identifikátory [01,02,03].
3.B Clustered Call Bridges zadajte webové adresy administrátorov našich serverov v klastri, cms[01,02,03].example.com:445, v poli Adresa. Nezabudnite zadať port. Môžete nechať Peer link SIP doménu prázdnu.
4. Do dôveryhodnosti CallBridge každého servera pridajte certifikát, ktorého súbor obsahuje všetky certifikáty našich serverov, ktoré sme do tohto súboru zlúčili hneď na začiatku, príkazom ako:

callbridge trust cluster <trusted cluster certificate bundle>

A reštartujte službu príkazom:

callbridge restart

V dôsledku toho by ste na každom serveri mali dostať tento obrázok:

XMPP klaster

Služba XMPP v CMS sa používa na spracovanie všetkých registrácií a autentifikácie pre aplikácie Cisco Meeting Apps (CMA), vrátane webového klienta CMA WebRTC. Samotný Call Bridge tiež funguje ako klient XMPP na účely autentifikácie, a preto musí byť nakonfigurovaný ako ostatní klienti. Odolnosť voči chybám XMPP je funkcia, ktorá je podporovaná v produkčných prostrediach od verzie 2.1

Príkazy popísané nižšie sa musia vykonať na každom serveri s príslušnými certifikátmi.
Takže:

Certifikáty spájame so službou XMPP s príkazom ako:

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

Potom definujte rozhranie počúvania príkazom:

xmpp listen a

Služba XMPP vyžaduje jedinečnú doménu. Toto je prihlásenie pre používateľov. Inými slovami, keď sa používateľ pokúsi prihlásiť pomocou aplikácie CMA (alebo prostredníctvom klienta WebRTC), zadá userID@logindomain. V našom prípade to bude userid@conf.example.com. Prečo to nie je len example.com? V našom konkrétnom nasadení sme vybrali našu Unified CM doménu, ktorú budú používatelia Jabber používať v Unified CM ako example.com, takže sme potrebovali inú doménu pre používateľov CMS na smerovanie hovorov do az CMS cez domény SIP.

Nastavte doménu XMPP pomocou príkazu ako:

xmpp domain <domain>

A povoľte službu XMPP príkazom:

xmpp enable

V službe XMPP musíte vytvoriť prihlasovacie údaje pre každý most hovorov, ktoré sa použijú pri registrácii v službe XMPP. Tieto názvy sú ľubovoľné (a nesúvisia s jedinečnými názvami, ktoré ste nakonfigurovali pre klastrovanie mostov hovorov). Musíte pridať tri mosty hovorov na jeden server XMPP a potom zadať tieto poverenia na iné servery XMPP v klastri, pretože táto konfigurácia sa nezmestí do databázy klastra. Neskôr nakonfigurujeme každý Call Bridge na používanie tohto mena a tajomstva na registráciu v službe XMPP.

Teraz musíme nakonfigurovať službu XMPP na prvom serveri s tromi mostíkmi hovorov callbridge01, callbridge02 a callbridge03. Každému účtu budú priradené náhodné heslá. Neskôr budú zadané na iných serveroch Call Bridge, aby sa prihlásili na tento server XMPP. Zadajte nasledujúce príkazy:

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

V dôsledku toho skontrolujeme, čo sa stalo s príkazom:

xmpp callbridge list

Presne rovnaký obrázok by sa mal objaviť na ostatných serveroch po krokoch opísaných nižšie.

Ďalej pridáme presne rovnaké nastavenia na zvyšné dva servery, iba s príkazmi

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

Tajomstvo pridávame veľmi opatrne, aby v ňom napríklad neboli žiadne medzery navyše.


Výsledkom je, že každý server by mal mať rovnaký obrázok:

Ďalej na všetkých serveroch v klastri špecifikujeme ako dôveryhodnosť súbor obsahujúci všetky tri certifikáty, ktoré boli vytvorené skôr príkazom, ako je tento:

xmpp cluster trust <trust bundle>

Klastrový režim xmpp povolíme na všetkých klastrových serveroch príkazom:

xmpp cluster enable

Na prvom serveri klastra spustíme vytvorenie xmpp klastra príkazom:

xmpp cluster initialize

Na iných serveroch pridajte klaster do xmpp pomocou príkazu ako:

xmpp cluster join <ip address head xmpp server>

Úspešnosť vytvorenia XMPP klastra na každom serveri kontrolujeme na každom serveri pomocou príkazov:

xmpp status
xmpp cluster status

Prvý server:

Druhý server:

Tretí server:

Pripojenie Call Bridge k XMPP

Teraz, keď je klaster XMPP spustený, musíte nakonfigurovať služby Call Bridge na pripojenie ku klastru XMPP. Táto konfigurácia sa vykonáva prostredníctvom správcu webu.

Na každom serveri prejdite do časti Konfigurácia > Všeobecné a do poľa Jedinečný názov Call Bridge napíšte jedinečné názvy zodpovedajúce serveru Call Bridge volací most[01,02,03]... V poli Doména conf.example.ru a príslušné heslá, môžete ich špehovať
na ľubovoľnom serveri v klastri pomocou príkazu:

xmpp callbridge list

Pole „Server“ nechajte prázdne Callbridge vykoná vyhľadávanie DNS SRV _xmpp-component._tcp.conf.example.comnájsť dostupný server XMPP. IP adresy na pripojenie callbridgeov k XMPP sa môžu na každom serveri líšiť, záleží na tom, aké hodnoty sa vrátia do požiadavky na záznam _xmpp-component._tcp.conf.example.com callbridge, ktorý zase závisí od nastavenia priority pre daný DNS záznam.

Potom prejdite na Stav > Všeobecné a overte, či je služba Call Bride úspešne pripojená k službe XMPP.

Webový most

Na každom serveri v klastri povoľte službu Web Bridge pomocou príkazu:

webbridge listen a:443

Službu Web Bridge nakonfigurujeme pomocou súborov certifikátov pomocou príkazu ako:

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

Web Bridge podporuje HTTPS. Presmeruje HTTP na HTTPS, ak je nakonfigurovaný na použitie "http-redirect".
Ak chcete povoliť presmerovanie HTTP, použite nasledujúci príkaz:

webbridge http-redirect enable

Ak chcete dať Call Bridge vedieť, že Web Bridge môže dôverovať pripojeniam z Call Bridge, použite príkaz:

webbridge trust <certfile>

kde ide o súbor obsahujúci všetky tri certifikáty z každého servera v klastri.

Tento obrázok by mal byť na každom serveri v klastri.


Teraz musíme vytvoriť používateľa s rolou „appadmin“, potrebujeme to, aby sme mohli konfigurovať náš klaster(!), a nie každý server v klastri samostatne, týmto spôsobom sa nastavenia použijú rovnako na každý server napriek skutočnosť, že raz budú vyrobené.


Pre ďalšie nastavenie použijeme poštár.

Pre autorizáciu vyberte Basic v časti Autorizácia

Pre správne odosielanie príkazov na CMS server je potrebné nastaviť požadované kódovanie

Webbridge špecifikujeme príkazom POST s parametrom url a zmysel cms.example.com



V samotnom webbridge uvádzame požadované parametre: hosťovský prístup, chránený prístup atď.

Call Bridge Groups

V predvolenom nastavení CMS nie vždy najefektívnejšie využíva zdroje konferencie, ktoré má k dispozícii.

Napríklad pri stretnutí s tromi účastníkmi môže každý účastník skončiť na troch rôznych mostoch hovorov. Aby títo traja účastníci mohli medzi sebou komunikovať, Call Bridges automaticky vytvorí spojenie medzi všetkými servermi a klientmi v rovnakom priestore, takže to všetko vyzerá, ako keby boli všetci klienti na rovnakom serveri. Bohužiaľ, nevýhodou je, že jedna konferencia pre 3 osoby teraz spotrebuje 9 mediálnych portov. Je zrejmé, že ide o neefektívne využívanie zdrojov. Navyše, keď je Call Bridge skutočne preťažený, predvolený mechanizmus je pokračovať v prijímaní hovorov a poskytovaní služieb so zníženou kvalitou všetkým účastníkom tohto Call Bridge.

Tieto problémy sa riešia pomocou funkcie Call Bridge Group. Táto funkcia bola predstavená vo verzii 2.1 softvéru Cisco Meeting Server a bola rozšírená o podporu vyvažovania záťaže pre prichádzajúce aj odchádzajúce hovory aplikácie Cisco Meeting App (CMA), vrátane účastníkov WebRTC.

Na vyriešenie problému s opätovným pripojením boli zavedené tri konfigurovateľné limity zaťaženia pre každý most hovorov:

LoadLimit — toto je maximálne číselné zaťaženie pre konkrétny most hovorov. Každá platforma má odporúčaný limit zaťaženia, napríklad 96000 1000 pre CMS1.25 a XNUMX GHz na vCPU pre virtuálny počítač. Rôzne hovory spotrebúvajú určité množstvo zdrojov v závislosti od rozlíšenia a snímkovej frekvencie účastníka.
NewConferenceLoadLimitBasisPoints (predvolená hodnota 50% loadLimit) – nastavuje limit zaťaženia servera, po ktorom sú nové konferencie odmietnuté.
ExistingConferenceLoadLimitBasisPoints (predvolená hodnota 80 % z limitu zaťaženia) – hodnota zaťaženia servera, po prekročení ktorej budú účastníci pripájajúci sa k existujúcej konferencii odmietnutí.

Zatiaľ čo táto funkcia bola navrhnutá na distribúciu hovorov a vyvažovanie záťaže, ku skupinám premostenia hovorov možno priradiť aj iné skupiny, ako sú servery TURN, servery Web Bridge a záznamníky, aby ich bolo možné správne zoskupiť pre optimálne využitie. Ak niektorý z týchto objektov nie je priradený k skupine hovorov, predpokladá sa, že je dostupný pre všetky servery bez konkrétnej priority.

Tieto parametre sa konfigurujú tu: cms.example.com:445/api/v1/system/configuration/cluster

Ďalej označíme pre každý callbridge, do ktorej skupiny callbridgeov patrí:

Prvý volací most

Druhý volací most

Tretí spojovací mostík


Skupinu Call Brdige sme teda nakonfigurovali tak, aby efektívnejšie využívala prostriedky klastra Cisco Meeting Server.

Importovanie používateľov zo služby Active Directory

Služba Web Admin má sekciu konfigurácie LDAP, ale neposkytuje komplexné možnosti konfigurácie a informácie nie sú uložené v databáze klastra, takže konfiguráciu bude potrebné vykonať buď manuálne na každom serveri cez webové rozhranie, alebo cez API, a aby sme „trikrát „Nevstávaj“, aj tak nastavíme údaje cez API.

Použitie adresy URL na prístup cms01.example.com:445/api/v1/ldapServers vytvorí objekt servera LDAP s uvedením parametrov, ako napríklad:

• IP servera
• číslo portu
• užívateľské meno
• пароль
• zabezpečiť

Secure - vyberte true alebo false v závislosti od portu, 389 - nezabezpečené, 636 - chránené.


Mapovanie zdrojových parametrov LDAP na atribúty v Cisco Meeting Server.
Mapovanie LDAP mapuje atribúty v adresári LDAP na atribúty v CMS. Skutočné atribúty:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Popis atribútovJID predstavuje prihlasovacie ID používateľa v CMS. Keďže ide o server Microsoft Active Directory LDAP, CMS JID sa mapuje na sAMAccountName v LDAP, čo je v podstate používateľské prihlasovacie ID služby Active Directory. Tiež si všimnite, že vezmete sAMAccountName a na jeho koniec pridáte doménu conf.pod6.cms.lab, pretože toto je prihlasovacie meno, ktoré budú vaši používatelia používať na prihlásenie do CMS.

nameMapping sa zhoduje s tým, čo je obsiahnuté v poli displayName v Active Directory, s poľom s názvom CMS používateľa.

coSpaceNameMapping vytvorí názov priestoru CMS na základe poľa displayName. Tento atribút spolu s atribútom coSpaceUriMapping je to, čo sa vyžaduje na vytvorenie priestoru pre každého používateľa.

coSpaceUriMapping definuje užívateľskú časť URI spojenú s osobným priestorom užívateľa. Niektoré domény môžu byť nakonfigurované tak, aby sa dali vytočiť do priestoru. Ak sa používateľská časť zhoduje s týmto poľom pre jednu z týchto domén, hovor bude smerovaný do priestoru tohto používateľa.

coSpaceSecondaryUriMapping definuje druhý URI na dosiahnutie priestoru. Toto možno použiť na pridanie číselného aliasu na smerovanie hovorov do priestoru importovaného používateľa ako alternatívu k alfanumerickému URI definovanému v parametri coSpaceUriMapping.

Server LDAP a mapovanie LDAP sú nakonfigurované. Teraz ich musíte prepojiť vytvorením zdroja LDAP.

Použitie adresy URL na prístup cms01.example.com:445/api/v1/ldapSource vytvorte zdrojový objekt LDAP a zadajte parametre, ako napríklad:

• server
• mapovanie
• baseDn
• filtrovať

Teraz, keď je konfigurácia LDAP dokončená, môžete vykonať operáciu manuálnej synchronizácie.

Urobíme to buď vo webovom rozhraní každého servera kliknutím Synchronizovať teraz časť Active Directory


alebo cez API s príkazom POST na prístup pomocou adresy URL cms01.example.com:445/api/v1/ldapSyncs

Ad-hoc konferencie

Čo je to?V tradičnom poňatí je konferencia, keď sa dvaja účastníci rozprávajú medzi sebou a jeden z účastníkov (pomocou zariadenia registrovaného v Unified CM) stlačí tlačidlo „Konferencia“, zavolá druhej osobe a po rozhovore s touto treťou stranou , opäť stlačí tlačidlo „Konferencia.“ aby ste sa pripojili k všetkým účastníkom tripartitnej konferencie.

To, čo odlišuje konferenciu Ad-Hoc od plánovanej konferencie v CMS, je to, že konferencia Ad-Hoc nie je len SIP hovor do CMS. Keď iniciátor konferencie klikne na tlačidlo Konferencia druhýkrát, aby pozval všetkých na rovnakú schôdzu, Unified CM musí uskutočniť volanie API do CMS, aby vytvoril priebežnú konferenciu, na ktorú sa potom prenesú všetky hovory. To všetko prebieha bez povšimnutia účastníkov.

To znamená, že Unified CM musí nakonfigurovať poverenia API a adresu/port WebAdmin služby, ako aj SIP Trunk priamo na server CMS, aby mohol hovor pokračovať.

V prípade potreby môže CUCM dynamicky vytvoriť priestor v CMS, aby sa každý hovor mohol dostať do CMS a zodpovedať pravidlu prichádzajúceho hovoru, ktoré je určené pre medzery.

Integrácia s CUCM nakonfigurovaný rovnakým spôsobom, ako je popísané v článku skôr okrem toho, že na Cisco UCM musíte vytvoriť tri kmene pre CMS, tri konferenčné mosty, v bezpečnostnom profile SIP špecifikovať tri názvy subjektov, skupiny trás, zoznamy trás, skupiny mediálnych zdrojov a zoznamy skupín mediálnych zdrojov a pridať niekoľko pravidiel smerovania na Cisco Meeting Server.

Bezpečnostný profil SIP:


Kufre:


Každý kmeň vyzerá rovnako:




Konferenčný most


Každý konferenčný most vyzerá rovnako:


Skupina trás


Zoznam trás


Skupina mediálnych zdrojov


Zoznam skupín mediálnych zdrojov

Pravidlá hovoru

Na rozdiel od pokročilejších systémov na správu hovorov, ako sú Unified CM alebo Expressway, CMS vyhľadáva pri nových hovoroch doménu iba v poli SIP Request-URI. Takže ak je SIP INVITE na dúšok: [chránené e-mailom]CMS sa stará iba o doménu.com. CMS sa riadi týmito pravidlami, aby určil, kam smerovať hovor:

1. CMS sa najprv pokúsi priradiť doménu SIP k doménam nakonfigurovaným v pravidlách pre prichádzajúce hovory. Tieto hovory potom môžu byť smerované do („cielených“) priestorov alebo konkrétnych používateľov, interných IVR alebo priamo integrovaných destinácií Microsoft Lync/Skype for Business (S4B).
2. Ak nie je zhoda v pravidlách pre prichádzajúce hovory, CMS sa pokúsi nájsť zhodu s doménou nakonfigurovanou v tabuľke presmerovania hovorov. Ak dôjde k zhode, pravidlo môže hovor explicitne odmietnuť alebo ho presmerovať. V súčasnosti môže CMS prepísať doménu, čo je niekedy užitočné pri volaní domén Lyncu. Môžete sa tiež rozhodnúť pre odovzdanie, čo znamená, že žiadne z polí nebude ďalej upravované, alebo použiť interný plán vytáčania CMS. Ak sa v pravidlách presmerovania hovorov nenájde žiadna zhoda, štandardne sa hovor odmietne. Majte na pamäti, že v CMS, hoci je hovor „presmerovaný“, médiá sú stále viazané na CMS, čo znamená, že budú v signálnej a mediálnej dopravnej ceste.
Potom sa pravidlám odchádzajúceho hovoru vzťahujú len na presmerované hovory. Tieto nastavenia určujú ciele, kam sa hovory odosielajú, typ linky (či už ide o nový hovor cez Lync alebo štandardný hovor SIP) a akékoľvek konverzie, ktoré možno vykonať, ak v pravidle presmerovania hovorov nie je vybratý prenos.

Tu je skutočný záznam toho, čo sa deje počas ad-hoc konferencie

Snímka obrazovky to ukazuje zle (neviem, ako to zlepšiť), takže protokol napíšem takto:

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

Samotná ad-hoc konferencia:


Pravidlá prichádzajúcich hovorov
Konfigurácia parametrov prichádzajúcich hovorov je nevyhnutná pre možnosť prijatia hovoru v CMS. Ako ste videli v nastavení LDAP, všetci používatelia boli importovaní s doménou conf.pod6.cms.lab. Minimálne teda chcete, aby volania do tejto domény zacielili na priestory. Budete tiež musieť nastaviť pravidlá pre všetko, čo je určené pre plne kvalifikovaný názov domény (a možno aj IP adresu) každého zo serverov CMS. Naše externé riadenie hovorov, Unified CM, nakonfiguruje SIP trunky vyhradené pre každý zo serverov CMS individuálne. V závislosti od toho, či je cieľom týchto SIP kanálov IP adresa alebo FQDN servera, určí, či je potrebné CMS nakonfigurovať na prijímanie hovorov smerovaných na jeho IP adresu alebo FQDN.

Doména, ktorá má pravidlo vstupu s najvyššou prioritou, sa používa ako doména pre všetky užívateľské priestory. Keď sa používatelia synchronizujú cez LDAP, CMS automaticky vytvorí priestory, ale iba používateľskú časť URI (coSpaceUriMapping), napríklad user.space. Časť doména Úplné URI sa generuje na základe tohto pravidla. V skutočnosti, ak by ste sa v tomto bode prihlásili do Web Bridge, videli by ste, že Space URI nemá doménu. Nastavením tohto pravidla ako najvyššej priority nastavujete doménu pre generované medzery conf.example.com.


Pravidlá odchádzajúcich hovorov

Ak chcete používateľom povoliť odchádzajúce volania do klastra Unified CM, musíte nakonfigurovať pravidlá pre odchádzajúce. Doména koncových bodov registrovaných v Unified CM, ako je Jabber, je example.com. Hovory do tejto domény by mali byť smerované ako štandardné hovory SIP do uzlov na spracovanie hovorov Unified CM. Hlavný server je cucm-01.example.com a ďalší je cucm-02.example.com.

Prvé pravidlo popisuje najjednoduchšie smerovanie hovorov medzi klastrovými servermi.

Pole Lokálne z domény je zodpovedný za to, čo sa zobrazí v SIP-URI volajúceho pre volanú osobu po symbole „@“. Ak ho necháme prázdne, za symbolom „@“ bude IP adresa CUCM, cez ktorú tento hovor prechádza. Ak zadáme doménu, potom za symbolom „@“ bude v skutočnosti doména. Je to potrebné, aby ste mohli zavolať späť, inak nebude možné zavolať späť cez SIP-URI meno@ip-adresa.

Zavolajte, keď je to uvedené Lokálne z domény


Zavolaj kedy NOT uvedené Lokálne z domény


Pre odchádzajúce hovory nezabudnite explicitne zadať Šifrované alebo Nešifrované, pretože s parametrom Auto nič nefunguje.

záznam

Videokonferencie sú nahrávané serverom Record. Recorder je úplne rovnaký ako Cisco Meeting Server. Rekordér nevyžaduje inštaláciu žiadnych licencií. Licencie na nahrávanie sú potrebné pre servery so službami CallBridge, t.j. vyžaduje sa nahrávacia licencia a musí byť aplikovaná na komponent CallBridge, a nie na server so systémom Recorder. Záznamník sa správa ako klient XMPP (Extensible Messaging and Presence Protocol), takže server XMPP musí byť povolený na serveri, ktorý hostí CallBridge.

Pretože Máme klaster a licenciu je potrebné „natiahnuť“ na všetky tri servery v klastri. Potom jednoducho vo svojom osobnom účte v licenciách priradíme (pridáme) MAC adresy a-rozhraní všetkých CMS serverov zahrnutých v klastri.

A toto je obrázok, ktorý by mal byť na každom serveri v klastri

Vo všeobecnosti existuje niekoľko scenárov umiestnenia rekordéra, ale budeme sa držať tohto:


Pred nastavením Recorder si musíte pripraviť miesto, kde sa budú videokonferencie skutočne nahrávať. Vlastne tu odkaz, ako nastaviť celé nahrávanie. Zameriavam sa na dôležité body a detaily:

1. Je lepšie odovzdať certifikát z prvého servera v klastri.
2. Chyba „Recorder unavailable“ sa môže vyskytnúť, pretože je v Recorder Trust zadaný nesprávny certifikát.
3. Zápis nemusí fungovať, ak adresár NFS určený na nahrávanie nie je koreňovým adresárom.

Niekedy je potrebné automaticky nahrávať konferenciu jedného konkrétneho užívateľa alebo priestoru.

Na tento účel sa vytvoria dva profily volania:
So zakázaným nahrávaním


A s funkciou automatického nahrávania


Ďalej do požadovaného priestoru „priložíme“ CallProfile s funkciou automatického nahrávania.


V CMS je tak zavedené, že ak je CallProfile explicitne viazaný na akýkoľvek priestor alebo priestor, potom tento CallProfile funguje iba vo vzťahu k týmto špecifickým priestorom. A ak CallProfile nie je viazaný na žiadny priestor, potom sa štandardne aplikuje na tie priestory, na ktoré nie je explicitne viazaný žiadny CallProfile.

Nabudúce sa pokúsim popísať, ako sa k CMS pristupuje mimo internej siete organizácie.

Zdroje:

• 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-a-novšie. pdf

Zdroj: hab.com