V tomto čísle ukážu a vysvětlím některé složitosti nastavení serveru CMS v režimu clusteru s podporou převzetí služeb při selhání.
TeorieObecně existují tři typy nasazení serveru CMS:
- Jednoduché Kombinované(Jednoduché kombinované), tzn. toto je jeden server, na kterém běží všechny potřebné služby. Ve většině případů je tento typ nasazení vhodný pouze pro interní klientský přístup a v menších prostředích, kde omezení škálovatelnosti a redundance jednoho serveru nejsou kritickým problémem, nebo v situacích, kdy CMS provádí pouze určité funkce, jako je ad hoc konference na Cisco UCM.
Přibližné schéma práce:
- Single Split(Single Split) rozšiřuje předchozí typ nasazení přidáním samostatného serveru pro externí přístup. Ve starších nasazeních to znamenalo nasazení serveru CMS v segmentu demilitarizované sítě (DMZ), kde k němu měli přístup externí klienti, a jednoho serveru CMS v jádru sítě, kde měli interní klienti přístup k CMS. Tento konkrétní model nasazení je nyní nahrazován tzv. typem Single Edge, který se skládá ze serverů Cisco Expressway, které buď mají nebo budou mít mnoho stejných funkcí Firewall bypass, takže zákazníci nemusí přidávat vyhrazený okrajový CMS server.
Přibližné schéma práce:
- Škálovatelné a odolné(Scalable and Fault Tolerant) Tento typ zahrnuje redundanci pro každou komponentu, což umožňuje systému růst podle vašich potřeb na maximální kapacitu a zároveň poskytuje redundanci v případě selhání. Používá také koncept Single Edge k zajištění bezpečného externího přístupu. To je typ, na který se podíváme v této epizodě. Pokud pochopíme, jak nasadit tento typ clusteru, porozumíme nejen dalším typům nasazení, ale budeme také schopni porozumět tomu, jak vytvořit clustery serverů CMS, aby vyhovovaly potenciálnímu růstu poptávky.
Než přejdete k nasazení, musíte pochopit některé základní věci, jmenovitě
Hlavní softwarové komponenty CMS:
- Databáze: Umožňuje kombinovat některé konfigurace, jako je vytáčecí plán, uživatelské prostory a samotné uživatele. Podporuje klastrování pouze pro vysokou dostupnost (jeden hlavní server).
- Zavolejte Bridge: služba pro audio a video konference, která poskytuje plnou kontrolu nad správou a zpracováním hovorů a multimediálními procesy. Podporuje clustering pro vysokou dostupnost a škálovatelnost.
- server XMPP: zodpovědný za registraci a ověřování klientů pomocí aplikace Cisco Meeting Application a/nebo WebRTC(komunikace v reálném čase nebo jednoduše v prohlížeči), stejně jako mezisložková signalizace. Lze seskupit pouze pro vysokou dostupnost.
- Webový most: Poskytuje klientský přístup k WebRTC.
- Loadbalancer: Poskytuje jeden bod připojení pro aplikace Cisco Meeting Apps v režimu Single Split. Poslouchá externí rozhraní a port pro příchozí připojení. Stejně tak load balancer přijímá příchozí TLS spojení ze serveru XMPP, přes který může přepínat TCP spojení z externích klientů.
V našem scénáři to nebude potřeba. - TURN server: Poskytuje technologii bypassu brány firewall, která umožňuje
umístěte náš CMS za bránu firewall nebo NAT pro připojení externích klientů pomocí aplikace Cisco Meeting App nebo zařízení SIP. V našem scénáři to nebude potřeba. - Správce webu: Administrativní rozhraní a přístup k API, včetně speciálních konferencí Unified CM.
Režimy konfigurace
Na rozdíl od většiny ostatních produktů Cisco podporuje Cisco Meeting Server tři konfigurační metody pro jakýkoli typ nasazení.
- Příkazový řádek (CLI): Rozhraní příkazového řádku známé jako MMP pro počáteční konfigurační a certifikační úlohy.
- Správce webu: Primárně pro konfigurace související s CallBridge, zejména při nastavování jednoho neklastrovaného serveru.
- REST API: Používá se pro nejsložitější konfigurační úlohy a úlohy související s klastrovanou databází.
Kromě výše uvedeného se používá protokol SFTP k přenosu souborů – obvykle licencí, certifikátů nebo protokolů – na a ze serveru CMS.
V průvodcích nasazením od společnosti Cisco je bíle a anglicky napsáno, že je třeba cluster nasadit alespoň tři servery (uzly) v kontextu databází. Protože Pouze s lichým počtem uzlů bude mechanismus pro výběr nového Database Master fungovat a obecně Database Master má spojení s většinou databáze CMS serveru.
A jak ukazuje praxe, dva servery (uzly) opravdu nestačí. Mechanismus výběru funguje, když je Master restartován, Slave server se stane Masterem až po obnovení restartovaného serveru. Pokud však ve shluku dvou serverů Master server náhle vypadne, pak se Slave server nestane Masterem, a pokud Slave vypadne, pak se zbývající Master server stane Slave.
Ale v kontextu XMPP by bylo opravdu nutné sestavit cluster tří serverů, protože pokud například zakážete službu XMPP na jednom ze serverů, na kterých je XMMP ve stavu Leader, pak na zbývajícím serveru zůstane XMPP ve stavu Follower a spojení CallBridge s XMPP odpadnou, protože CallBridge se připojuje výhradně k XMPP se statusem Leader. A to je kritické, protože... neproběhne ani jeden hovor.
Ve stejných průvodcích nasazením je také demonstrován cluster s jedním XMPP serverem.
A když vezmeme v úvahu výše uvedené, je jasné proč: funguje to, protože je v režimu převzetí služeb při selhání.
V našem případě bude XMPP server přítomen na všech třech uzlech.
Předpokládá se, že všechny tři naše servery jsou v provozu.
DNS záznamy
Než začnete nastavovat servery, musíte vytvořit DNS záznamy А и SRV typy:
Upozorňujeme, že v našich záznamech DNS jsou dvě domény example.com a conf.example.com. Example.com je doména, kterou mohou všichni předplatitelé Cisco Unified Communication Manager používat pro své identifikátory URI, které se s největší pravděpodobností nacházejí ve vaší infrastruktuře nebo pravděpodobně budou přítomny. Nebo example.com odpovídá stejné doméně, kterou uživatelé používají pro své e-mailové adresy. Nebo klient Jabber na vašem notebooku může mít URI [chráněno e-mailem]. Doména conf.example.com je doména, která bude nakonfigurována pro uživatele Cisco Meeting Server. Doména serveru Cisco Meeting Server bude conf.example.com, takže pro stejného uživatele Jabber by bylo nutné použít identifikátor URI user@ k přihlášení k serveru Cisco Meeting Serverconf.example.com.
Základní konfigurace
Všechna níže popsaná nastavení jsou zobrazena na jednom serveru, ale je třeba je provést na každém serveru v clusteru.
QoS
Protože CMS generuje v reálném čase provoz citlivý na zpoždění a ztrátu paketů, ve většině případů se doporučuje nakonfigurovat kvalitu služby (QoS). Aby toho bylo dosaženo, CMS podporuje označování paketů pomocí kódů diferencovaných služeb (DSCP), které generuje. Ačkoli prioritizace provozu na základě DSCP závisí na tom, jak je provoz zpracován síťovými komponentami vaší infrastruktury, v našem případě nakonfigurujeme náš CMS s typickou prioritizací DSCP na základě osvědčených postupů QoS.
Na každém serveru zadáme tyto příkazy
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AVeškerý video provoz byl tedy označen AF41 (DSCP 0x22), veškerý hlasový provoz byl označen EF (DSCP 0x2E), ostatní typy provozu s nízkou latencí jako SIP a XMPP používají AF31 (DSCP 0x1A).
Zkontrolujeme:
NTP
Network Time Protocol (NTP) je důležitý nejen pro poskytování přesných časových razítek hovorů a konferencí, ale také pro ověřování certifikátů.
Přidejte NTP servery do vaší infrastruktury pomocí příkazu jako
ntp server add <server>
V našem případě jsou takové servery dva, takže týmy budou dva.
Zkontrolujeme:
A nastavte časové pásmo pro náš server
DNS
DNS servery přidáme do CMS příkazem jako:
dns add forwardzone <domain-name> <server ip>
V našem případě jsou takové servery dva, takže týmy budou dva.
Zkontrolujeme:
Konfigurace síťového rozhraní
Rozhraní nakonfigurujeme příkazem jako:
ipv4 <interface> add <address>/<prefix length> <gateway>
Zkontrolujeme:
Název serveru (hostname)
Jméno serveru nastavíme příkazem jako:
hostname <name>
A restartujeme.
Tím je základní konfigurace hotová.
Certifikáty
TeorieCisco Meeting Server vyžaduje šifrovanou komunikaci mezi různými součástmi, a proto jsou pro všechna nasazení CMS vyžadovány certifikáty X.509. Pomáhají zajistit, aby služby/server byly důvěryhodné jinými servery/službami.
Každá služba vyžaduje certifikát, ale vytváření samostatných certifikátů pro každou službu může vést k nejasnostem a zbytečné složitosti. Naštěstí můžeme vygenerovat pár veřejného a soukromého klíče certifikátu a poté je znovu použít ve více službách. V našem případě bude stejný certifikát použit pro Call Bridge, XMPP Server, Web Bridge a Web Admin. Musíte tedy vytvořit pár veřejných a soukromých klíčů certifikátu pro každý server v clusteru.
Klastrování databáze má však některé speciální požadavky na certifikáty, a proto vyžaduje vlastní certifikáty, které se liší od certifikátů ostatních služeb. CMS používá certifikát serveru, který je podobný certifikátům používaným jinými servery, ale existuje také klientský certifikát používaný pro připojení k databázi. Databázové certifikáty se používají jak pro autentizaci, tak pro šifrování. Namísto poskytnutí uživatelského jména a hesla pro klienta pro připojení k databázi představuje klientský certifikát, kterému server důvěřuje. Každý server v databázovém clusteru bude používat stejný pár veřejného a soukromého klíče. To umožňuje všem serverům v clusteru šifrovat data takovým způsobem, že je mohou dešifrovat pouze jiné servery, které také sdílejí stejný pár klíčů.
Aby redundance fungovala, musí databázové klastry sestávat z minimálně 3 serverů, ale ne více než 5, s maximální dobou zpáteční cesty 200 ms mezi všemi členy klastru. Tento limit je více omezující než pro clustering Call Bridge, takže je často omezujícím faktorem v geograficky distribuovaných nasazeních.
Databázová role pro CMS má řadu jedinečných požadavků. Na rozdíl od jiných rolí vyžaduje klientský a serverový certifikát, kde klientský certifikát má specifické pole CN, které je prezentováno serveru.
CMS využívá postgresovou databázi s jedním masterem a několika zcela identickými replikami. V jednom okamžiku existuje pouze jedna primární databáze („databázový server“). Zbývající členové clusteru jsou repliky nebo "databázové klienty".
Databázový cluster vyžaduje certifikát vyhrazeného serveru a klientský certifikát. Musí být podepsány certifikáty, obvykle interní soukromou certifikační autoritou. Protože se master databází může stát jakýkoli člen databázového klastru, musí být páry certifikátů databázového serveru a klienta (obsahující veřejný a soukromý klíč) zkopírovány na všechny servery, aby mohly převzít identitu klienta nebo databázového serveru. Kromě toho musí být načten kořenový certifikát CA, aby bylo zajištěno ověření klientských a serverových certifikátů.
Vytvoříme tedy požadavek na certifikát, který budou používat všechny služby serveru kromě databáze (bude na to samostatný požadavek) příkazem jako:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Do CN zapisujeme obecný název našich serverů. Například pokud názvy hostitelů našich serverů server01, server02, server03, pak bude CN server.example.com
Totéž provedeme na zbývajících dvou serverech s tím rozdílem, že příkazy budou obsahovat odpovídající „názvy hostitelů“
Vygenerujeme dvě žádosti o certifikáty, které bude databázová služba používat s příkazy jako:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreskde dbclusterserver и dbclusterclient názvy našich požadavků a budoucí certifikáty, hostname1(2)(3) názvy odpovídajících serverů.
Tento postup provádíme pouze na jednom serveru (!) a certifikáty a odpovídající soubory .key nahrajeme na další servery.
Povolit režim klientského certifikátu ve službě AD CS
Musíte také sloučit certifikáty pro každý server do jednoho souboru.Na *NIX:
cat server01.cer server02.cer server03.cer > server.cerV systému Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
A nahrajte na každý server:
1. „Individuální“ certifikát serveru.
2. Kořenový certifikát (společně s případnými přechodnými).
3. Certifikáty pro databázi („server“ a „klient“) a soubory s příponou .key, které byly vygenerovány při vytváření žádosti o certifikáty databáze „server“ a „klient“. Tyto soubory musí být stejné na všech serverech.
4. Soubor všech tří „individuálních“ certifikátů.
V důsledku toho byste měli na každém serveru získat něco jako tento obrázek souboru.
Databázový klastr
Nyní, když máte všechny certifikáty nahrány na servery CMS, můžete nakonfigurovat a povolit shlukování databáze mezi třemi uzly. Prvním krokem je vybrat jeden server jako hlavní uzel databázového klastru a plně jej nakonfigurovat.
Hlavní databáze
Prvním krokem při nastavení replikace databáze je určení certifikátů, které budou pro databázi použity. To se provádí pomocí příkazu jako:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Nyní řekněme CMS, které rozhraní má použít pro shlukování databáze pomocí příkazu:
database cluster localnode aPoté inicializujeme databázi clusteru na hlavním serveru příkazem:
database cluster initialize
Uzly klientské databáze
Provedeme stejný postup, jen místo příkazu inicializovat databázový cluster zadejte příkaz jako:
database cluster join <ip address existing master>kde ip address stávající hlavní IP adresa serveru CMS, na kterém byl cluster inicializován, jednoduše Master.
Zkontrolujeme, jak náš databázový cluster funguje na všech serverech pomocí příkazu:
database cluster status
Totéž uděláme na zbývajícím třetím serveru.
Výsledkem je, že náš první server je Master, zbytek jsou Slave.
Služba pro správu webu
Povolte službu správce webu:
webadmin listen a 445Port 445 byl vybrán, protože port 443 se používá pro přístup uživatele k webovému klientovi
Službu Web Admin nakonfigurujeme pomocí souborů certifikátů pomocí příkazu jako:
webadmin certs <keyfile> <certificatefile> <ca bundle>A povolte Web Admin příkazem:
webadmin enable
Pokud je vše v pořádku, obdržíme řádky ÚSPĚCH indikující, že Web Admin je správně nakonfigurován pro síť a certifikát. Funkčnost služby zkontrolujeme pomocí webového prohlížeče a zadáme adresu správce webu, např. : 445
Zavolejte Bridge Cluster
Call Bridge je jediná služba přítomná v každém nasazení CMS. Call Bridge je hlavním konferenčním mechanismem. Poskytuje také rozhraní SIP, takže hovory do něj nebo z něj mohou být směrovány například pomocí Cisco Unified CM.
Níže popsané příkazy musí být provedeny na každém serveru s příslušnými certifikáty.
Takže:
Certifikáty spojujeme se službou Call Bridge s příkazem jako:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Spojíme služby CallBridge s rozhraním, které potřebujeme, pomocí příkazu:
callbridge listen aA restartujte službu příkazem:
callbridge restart
Nyní, když máme naše Call Bridge nakonfigurované, můžeme nakonfigurovat Call Bridge clustering. Klastrování mostu volání se liší od shlukování databáze nebo XMPP. Call Bridge Cluster může podporovat 2 až 8 uzlů bez jakýchkoli omezení. Poskytuje nejen redundanci, ale také vyrovnávání zátěže, takže konference mohou být aktivně distribuovány mezi servery Call Bridge pomocí inteligentní distribuce hovorů. CMS má další funkce, skupiny Call Bridge a související funkce, které lze použít pro další správu.
Clusterování můstků volání se konfiguruje především prostřednictvím webového administrátorského rozhraní
Níže popsaný postup musí být proveden na každém serveru v clusteru.
To znamená,
1. Přejděte na webu do Konfigurace > Cluster.
2. V Zavolejte identitu Bridge Jako jedinečný název zadejte callbridge[01,02,03] odpovídající názvu serveru. Tyto názvy jsou libovolné, ale pro tento cluster musí být jedinečné. Jsou ve své podstatě popisné, protože označují, že se jedná o identifikátory serveru [01,02,03].
3.B Clustered Call Bridges zadejte adresy URL webových administrátorů našich serverů v clusteru, [01,02,03].example.com:445, v poli Adresa. Nezapomeňte zadat port. Peer link SIP doménu můžete nechat prázdnou.
4. Přidejte certifikát do důvěryhodnosti CallBridge každého serveru, jehož soubor obsahuje všechny certifikáty našich serverů, které jsme do tohoto souboru sloučili hned na začátku, příkazem jako:
callbridge trust cluster <trusted cluster certificate bundle>A restartujte službu příkazem:
callbridge restart
V důsledku toho byste na každém serveru měli získat tento obrázek:
XMPP Cluster
Služba XMPP v CMS se používá ke zpracování veškeré registrace a ověřování pro Cisco Meeting Apps (CMA), včetně webového klienta CMA WebRTC. Samotný Call Bridge také funguje jako klient XMPP pro účely ověřování, a proto musí být nakonfigurován jako ostatní klienti. Odolnost proti chybám XMPP je funkce, která je podporována v produkčním prostředí od verze 2.1
Níže popsané příkazy musí být provedeny na každém serveru s příslušnými certifikáty.
Takže:
Certifikáty spojujeme se službou XMPP s příkazem jako:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Poté definujte naslouchací rozhraní příkazem:
xmpp listen aSlužba XMPP vyžaduje jedinečnou doménu. Toto je přihlašovací jméno pro uživatele. Jinými slovy, když se uživatel pokusí přihlásit pomocí aplikace CMA (nebo prostřednictvím klienta WebRTC), zadá ID uživatele@logindomena. V našem případě to bude userid@conf.example.com. Proč to není jen example.com? V našem konkrétním nasazení jsme vybrali naši Unified CM doménu, kterou budou uživatelé Jabber používat v Unified CM jako example.com, takže jsme potřebovali jinou doménu pro uživatele CMS pro směrování hovorů do az CMS přes domény SIP.
Nastavte doménu XMPP pomocí příkazu jako:
xmpp domain <domain>A povolte službu XMPP příkazem:
xmpp enableVe službě XMPP musíte vytvořit přihlašovací údaje pro každý most hovorů, který bude použit při registraci do služby XMPP. Tyto názvy jsou libovolné (a nesouvisí s jedinečnými názvy, které jste nakonfigurovali pro shlukování mostu volání). Musíte přidat tři mosty volání na jeden server XMPP a poté zadat tato pověření na jiných serverech XMPP v clusteru, protože tato konfigurace se nevejde do databáze clusteru. Později nakonfigurujeme každý Call Bridge tak, aby používal toto jméno a tajný klíč k registraci do služby XMPP.
Nyní potřebujeme nakonfigurovat službu XMPP na prvním serveru se třemi Call Bridges callbridge01, callbridge02 a callbridge03. Každému účtu budou přidělena náhodná hesla. Později budou zadány na jiných serverech Call Bridge pro přihlášení k tomuto serveru XMPP. Zadejte následující příkazy:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03V důsledku toho zkontrolujeme, co se stalo s příkazem:
xmpp callbridge list
Po níže popsaných krocích by se na zbývajících serverech měl objevit přesně stejný obrázek.
Dále přidáme přesně stejná nastavení na zbývající dva servery, pouze s příkazy
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Tajemství přidáváme velmi opatrně, aby v něm například nebyly žádné mezery navíc.
V důsledku toho by měl mít každý server stejný obrázek:
Dále na všech serverech v clusteru zadáme jako důvěryhodnost soubor obsahující všechny tři certifikáty, vytvořené dříve pomocí příkazu, jako je tento:
xmpp cluster trust <trust bundle>Režim xmpp clusteru povolíme na všech clusterových serverech příkazem:
xmpp cluster enableNa prvním serveru clusteru zahájíme vytvoření xmpp clusteru příkazem:
xmpp cluster initializeNa jiných serverech přidejte cluster do xmpp pomocí příkazu jako:
xmpp cluster join <ip address head xmpp server>Úspěšnost vytvoření clusteru XMPP na každém serveru kontrolujeme na každém serveru pomocí příkazů:
xmpp status
xmpp cluster statusPrvní server:
Druhý server:
Třetí server:
Připojení Call Bridge k XMPP
Nyní, když je cluster XMPP spuštěn, musíte nakonfigurovat služby Call Bridge pro připojení ke clusteru XMPP. Tato konfigurace se provádí přes web admin.
Na každém serveru přejděte do Konfigurace > Obecné a do pole Jedinečný název Call Bridge napište jedinečná jména odpovídající serveru Call Bridge volací most[01,02,03]... V poli Doména conf.example.ru a odpovídající hesla, můžete je špehovat
na libovolném serveru v clusteru pomocí příkazu:
xmpp callbridge list
Pole „Server“ ponechte prázdné Callbridge provede vyhledání DNS SRV _xmpp-component._tcp.conf.example.comnajít dostupný server XMPP. IP adresy pro připojení callbridge k XMPP se mohou na každém serveru lišit, záleží na tom, jaké hodnoty jsou vráceny do požadavku na záznam _xmpp-component._tcp.conf.example.com callbridge, což zase závisí na nastavení priority pro daný DNS záznam.
Dále přejděte na Stav > Obecné a ověřte, zda je služba Call Bride úspěšně připojena ke službě XMPP.
Webový most
Na každém serveru v clusteru povolte službu Web Bridge pomocí příkazu:
webbridge listen a:443Službu Web Bridge nakonfigurujeme pomocí souborů certifikátů pomocí příkazu jako:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge podporuje HTTPS. Přesměruje HTTP na HTTPS, pokud je nakonfigurováno pro použití "http-redirect".
Chcete-li povolit přesměrování HTTP, použijte následující příkaz:
webbridge http-redirect enableChcete-li dát Call Bridge vědět, že Web Bridge může důvěřovat spojením z Call Bridge, použijte příkaz:
webbridge trust <certfile>kde se jedná o soubor obsahující všechny tři certifikáty z každého serveru v clusteru.
Tento obrázek by měl být na každém serveru v clusteru.
Nyní musíme vytvořit uživatele s rolí „appadmin“, potřebujeme ji, abychom mohli konfigurovat náš cluster(!), a ne každý server v clusteru samostatně, tímto způsobem bude nastavení aplikováno stejně na každý server navzdory skutečnost, že budou jednou vyrobeny.
Pro další nastavení použijeme .
Pro autorizaci vyberte Základní v části Autorizace
Pro správné odesílání příkazů na CMS server je třeba nastavit požadované kódování
Příkazem specifikujeme Webbridge POST s parametrem url a význam
V samotném webbridge uvádíme požadované parametry: přístup pro hosty, chráněný přístup atd.
Call Bridge Groups
Ve výchozím nastavení CMS ne vždy nejefektivněji využívá dostupné konferenční zdroje.
Například u schůzky se třemi účastníky může každý účastník skončit na třech různých můstcích hovorů. Aby spolu tito tři účastníci komunikovali, Call Bridges automaticky naváže spojení mezi všemi servery a klienty ve stejném prostoru, takže vše vypadá, jako by všichni klienti byli na stejném serveru. Nevýhodou je bohužel to, že jedna konference pro 3 osoby nyní spotřebuje 9 mediálních portů. To je zjevně neefektivní využívání zdrojů. Navíc, když je přemostění hovorů skutečně přetíženo, výchozí mechanismus je nadále přijímat hovory a poskytovat služby se sníženou kvalitou všem účastníkům tohoto přemostění hovorů.
Tyto problémy jsou řešeny pomocí funkce Call Bridge Group. Tato funkce byla představena ve verzi 2.1 softwaru Cisco Meeting Server a byla rozšířena o podporu vyrovnávání zátěže pro příchozí i odchozí volání aplikace Cisco Meeting App (CMA), včetně účastníků WebRTC.
Pro vyřešení problému opětovného připojení byly pro každý Call Bridge zavedeny tři konfigurovatelné limity zatížení:
LoadLimit — toto je maximální numerické zatížení pro konkrétní můstek hovorů. Každá platforma má doporučený limit zatížení, například 96000 1000 pro CMS1.25 a XNUMX GHz na vCPU pro virtuální počítač. Různé hovory spotřebovávají určité množství zdrojů v závislosti na rozlišení a snímkové frekvenci účastníka.
NewConferenceLoadLimitBasisPoints (výchozí 50% loadLimit) - nastavuje limit zatížení serveru, po jehož překročení jsou nové konference odmítnuty.
ExistingConferenceLoadLimitBasisPoints (výchozí 80 % loadLimit) – hodnota zatížení serveru, po jejímž překročení budou účastníci připojující se k existující konferenci odmítnuti.
I když byla tato funkce navržena pro distribuci hovorů a vyrovnávání zátěže, lze ke skupinám Call Bridge Group přiřadit i další skupiny, jako jsou servery TURN Server, Web Bridge Server a Recorders, takže je lze také správně seskupit pro optimální využití. Pokud některý z těchto objektů není přiřazen skupině volání, předpokládá se, že je dostupný všem serverům bez jakékoli konkrétní priority.
Tyto parametry se konfigurují zde: :445/api/v1/system/configuration/cluster
Dále každému callbridge označíme, do které skupiny callbridge patří:
První volací most
Druhý volací most
Třetí volací most
Proto jsme nakonfigurovali skupinu Call Brdige, aby efektivněji využívala zdroje clusteru Cisco Meeting Server.
Import uživatelů z Active Directory
Služba Web Admin má konfigurační sekci LDAP, ale neposkytuje komplexní možnosti konfigurace a informace nejsou uloženy v databázi clusteru, takže konfiguraci bude nutné provést buď ručně na každém serveru přes webové rozhraní, nebo prostřednictvím API, a tak, že jsme „třikrát „Nevstávej“, stále nastavíme data přes API.
Přístup pomocí adresy URL :445/api/v1/ldapServers vytvoří objekt serveru LDAP s uvedením parametrů, jako jsou:
- IP serveru
- číslo portu
- имя пользователя
- heslo
- zajistit
Secure – vyberte true nebo false v závislosti na portu, 389 – nezabezpečeno, 636 – chráněno.
Mapování parametrů zdroje LDAP na atributy v Cisco Meeting Server.
Mapování LDAP mapuje atributy v adresáři LDAP na atributy v CMS. Skutečné atributy:
- jidMapping
- mapování jmen
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Popis atributůJID představuje přihlašovací ID uživatele v CMS. Protože se jedná o server Microsoft Active Directory LDAP, CMS JID se mapuje na sAMAccountName v LDAP, což je v podstatě přihlašovací ID uživatele Active Directory. Všimněte si také, že vezmete sAMAccountName a na jeho konec přidáte doménu conf.pod6.cms.lab, protože toto je přihlašovací jméno, které budou vaši uživatelé používat pro přihlášení do CMS.
mapování jmen odpovídá tomu, co je obsaženo v poli displayName služby Active Directory, s polem názvu CMS uživatele.
coSpaceNameMapping vytvoří název prostoru CMS na základě pole displayName. Tento atribut spolu s atributem coSpaceUriMapping je to, co je nutné k vytvoření prostoru pro každého uživatele.
coSpaceUriMapping definuje uživatelskou část URI přidruženou k osobnímu prostoru uživatele. Některé domény lze nakonfigurovat tak, aby byly vytáčeny do prostoru. Pokud uživatelská část odpovídá tomuto poli pro jednu z těchto domén, bude hovor směrován do prostoru tohoto uživatele.
coSpaceSecondaryUriMapping definuje druhý URI pro dosažení prostoru. To lze použít k přidání číselného aliasu pro směrování hovorů do prostoru importovaného uživatele jako alternativu k alfanumerickému URI definovanému v parametru coSpaceUriMapping.
Server LDAP a mapování LDAP jsou nakonfigurovány. Nyní je musíte propojit vytvořením zdroje LDAP.
Přístup pomocí adresy URL :445/api/v1/ldapSource vytvořte zdrojový objekt LDAP a zadejte parametry, jako jsou:
- Server
- mapování
- baseDn
- filtr
Nyní, když je konfigurace LDAP dokončena, můžete provést ruční synchronizaci.
To provedeme buď ve webovém rozhraní každého serveru kliknutím Synchronizujte nyní část Active Directory
nebo přes API s příkazem POST pomocí adresy URL pro přístup :445/api/v1/ldapSyncs
Ad-hoc konference
Co je to?V tradičním pojetí je konference, kdy spolu mluví dva účastníci a jeden z účastníků (pomocí zařízení registrovaného u Unified CM) stiskne tlačítko „Konference“, zavolá druhé osobě a po rozhovoru s touto třetí stranou , opětovným stisknutím tlačítka „Konference“ se připojíte ke všem účastníkům tripartitní konference.
To, co odlišuje konferenci Ad-Hoc od plánované konference v CMS, je to, že konference Ad-Hoc není jen SIP volání do CMS. Když iniciátor konference klepne na tlačítko Konference podruhé, aby pozval všechny na stejnou schůzku, musí Unified CM uskutečnit volání API do CMS, aby vytvořilo průběžnou konferenci, na kterou jsou poté všechny hovory převedeny. To vše probíhá bez povšimnutí účastníků.
To znamená, že Unified CM musí nakonfigurovat pověření API a adresu/port WebAdmin služby a také SIP Trunk přímo na server CMS, aby mohl hovor pokračovat.
V případě potřeby může CUCM dynamicky vytvořit prostor v CMS, takže každý hovor může dosáhnout CMS a odpovídat pravidlu pro příchozí hovory, které je určeno pro prostory.
Integrace s CUCM nakonfigurovat stejným způsobem, jak je popsáno v článku kromě toho, že na Cisco UCM musíte vytvořit tři kmeny pro CMS, tři konferenční mosty, v profilu zabezpečení SIP zadat tři názvy předmětů, skupiny tras, seznamy tras, skupiny mediálních prostředků a seznamy skupin mediálních prostředků a přidat několik pravidel směrování na Cisco Meeting Server.
Bezpečnostní profil SIP:
Kufry:
Každý kufr vypadá stejně:
Konferenční most
Každý konferenční most vypadá stejně:
Skupina tras
Seznam tras
Skupina mediálních zdrojů
Seznam skupin mediálních zdrojů
Pravidla volání
Na rozdíl od pokročilejších systémů pro správu hovorů, jako je Unified CM nebo Expressway, CMS pro nové hovory vyhledává pouze doménu v poli SIP Request-URI. Takže pokud je SIP INVITE pro doušek: [chráněno e-mailem]CMS se stará pouze o doménu.com. CMS se řídí těmito pravidly, aby určil, kam má být hovor směrován:
1. CMS se nejprve pokusí porovnat doménu SIP s doménami nakonfigurovanými v pravidlech pro příchozí hovory. Tyto hovory pak mohou být směrovány do („cílených“) prostorů nebo konkrétních uživatelů, interních IVR nebo přímo integrovaných destinací Microsoft Lync/Skype for Business (S4B).
2. Pokud není v pravidlech pro příchozí hovory žádná shoda, CMS se pokusí najít shodu s doménou nakonfigurovanou v tabulce přesměrování hovorů. Pokud dojde ke shodě, pravidlo může hovor výslovně odmítnout nebo hovor přesměrovat. V tuto chvíli může CMS doménu přepsat, což je někdy užitečné pro volání domén Lyncu. Můžete se také rozhodnout pro předání, což znamená, že žádné z polí nebude dále upravováno, nebo použít interní vytáčecí plán CMS. Pokud v pravidlech přesměrování hovorů není žádná shoda, výchozím nastavením je hovor odmítnout. Mějte na paměti, že v CMS, i když je hovor „přesměrován“, jsou média stále vázána na CMS, což znamená, že budou v signalizační a mediální cestě.
Pravidla pro odchozí hovory pak podléhají pouze přesměrovaným hovorům. Tato nastavení určují cíle, kam se hovory odesílají, typ linky (ať už se jedná o nový hovor Lyncu nebo standardní hovor SIP) a případné konverze, které lze provést, pokud v pravidle přesměrování hovorů není vybrán přenos.
Zde je skutečný záznam toho, co se děje během konference Ad-Hoc
Snímek obrazovky to ukazuje špatně (nevím, jak to vylepšit), takže protokol napíšu 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:12Samotná ad-hoc konference:
Pravidla pro příchozí hovory
Konfigurace parametrů příchozích hovorů je nezbytná pro možnost příjmu hovoru v CMS. Jak jste viděli v nastavení LDAP, všichni uživatelé byli importováni s doménou conf.pod6.cms.lab. Minimálně tedy chcete volání do této domény do cílových prostorů. Budete také muset nastavit pravidla pro vše, co je určeno pro plně kvalifikovaný název domény (a možná i IP adresu) každého ze serverů CMS. Naše externí řízení hovorů, Unified CM, nakonfiguruje SIP trunky vyhrazené pro každý ze serverů CMS samostatně. V závislosti na tom, zda je cílem těchto SIP trunků IP adresa nebo FQDN serveru, určí, zda je potřeba CMS nakonfigurovat tak, aby přijímal hovory směrované na jeho IP adresu nebo FQDN.
Doména s nejvyšší prioritou příchozího pravidla se používá jako doména pro všechny uživatelské prostory. Když se uživatelé synchronizují přes LDAP, CMS automaticky vytvoří mezery, ale pouze uživatelskou část URI (coSpaceUriMapping), například user.space. Část Na základě tohoto pravidla je generováno úplné URI. Ve skutečnosti, pokud byste se v tomto okamžiku přihlásili do Web Bridge, viděli byste, že Space URI nemá doménu. Nastavením tohoto pravidla jako nejvyšší priority nastavujete doménu pro generované mezery conf.example.com.
Pravidla pro odchozí hovory
Chcete-li uživatelům povolit odchozí volání do clusteru Unified CM, musíte nakonfigurovat odchozí pravidla. Doména koncových bodů registrovaných u Unified CM, jako je Jabber, je example.com. Volání do této domény by měla být směrována jako standardní volání SIP do uzlů zpracování volání Unified CM. Hlavní server je cucm-01.example.com a další je cucm-02.example.com.
První pravidlo popisuje nejjednodušší směrování hovorů mezi servery clusteru.
Pole Lokální z domény je odpovědný za to, co se zobrazí v SIP-URI volajícího pro volanou osobu po symbolu „@“. Pokud necháme prázdné, pak za symbolem „@“ bude IP adresa CUCM, přes kterou tento hovor prochází. Pokud zadáme doménu, pak za symbolem „@“ bude ve skutečnosti doména. To je nutné, aby bylo možné zavolat zpět, jinak nebude možné zavolat zpět přes SIP-URI jméno@ip-adresa.
Zavolejte, když je to uvedeno Lokální z domény
Zavolejte kdy NOT uvedeno Lokální z domény
Ujistěte se, že jste pro odchozí hovory výslovně uvedli Encrypted nebo Unencrypted, protože s parametrem Auto nic nefunguje.
Záznam
Videokonference jsou zaznamenávány záznamovým serverem. Recorder je úplně stejný jako Cisco Meeting Server. Recorder nevyžaduje instalaci žádných licencí. Licence k nahrávání jsou vyžadovány pro servery se službami CallBridge, tzn. je vyžadována licence pro nahrávání a musí být aplikována na komponentu CallBridge, nikoli na server, na kterém je spuštěn Recorder. Záznamník se chová jako klient XMPP (Extensible Messaging and Presence Protocol), takže server XMPP musí být povolen na serveru hostujícím CallBridge.
Protože Máme cluster a licenci je třeba „roztáhnout“ na všechny tři servery v clusteru. Pak jednoduše ve vašem osobním účtu v licencích přiřadíme (přidáme) MAC adresy a-rozhraní všech CMS serverů zahrnutých v clusteru.
A toto je obrázek, který by měl být na každém serveru v clusteru
Obecně existuje několik scénářů pro umístění Recorder, ale my se budeme držet tohoto:
Před nastavením Recorderu si musíte připravit místo, kde se budou videokonference skutečně nahrávat. Vlastně tady , jak nastavit veškeré nahrávání. Zaměřuji se na důležité body a detaily:
1. Je lepší podat certifikát z prvního serveru v clusteru.
2. Chyba „Recorder unavailable“ může nastat, protože je v Recorder Trust zadán nesprávný certifikát.
3. Zápis nemusí fungovat, pokud adresář NFS určený pro záznam není kořenový adresář.
Někdy je potřeba automaticky nahrát konferenci jednoho konkrétního uživatele nebo prostoru.
K tomu jsou vytvořeny dva CallProfily:
S deaktivovaným nahráváním
A s funkcí automatického nahrávání
Dále do požadovaného prostoru „přiložíme“ CallProfile s funkcí automatického nahrávání.
V CMS je tak zavedené, že pokud je CallProfile explicitně vázán na jakýkoli prostor nebo prostor, pak tento CallProfile funguje pouze ve vztahu k těmto specifickým prostorům. A pokud CallProfile není vázán na žádný prostor, pak je standardně aplikován na ty prostory, ke kterým není žádný CallProfile explicitně vázán.
Příště se pokusím popsat, jak se k CMS přistupuje mimo interní síť organizace.
Zdroje:
Zdroj: www.habr.com