ProHoster > blogg > administration > Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

I det här numret kommer jag att visa och förklara några av krångligheterna med att ställa in en CMS-server i failover-klusterläge.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

ТеорияI allmänhet finns det tre typer av CMS-serverdistribution:

  • Enkel kombinerad(Singel kombinerad), d.v.s. detta är en server där alla nödvändiga tjänster körs. I de flesta fall är denna typ av distribution endast lämplig för intern klientåtkomst och i mindre miljöer där skalbarheten och redundansbegränsningarna för en enskild server inte är ett kritiskt problem, eller i situationer där CMS endast utför vissa funktioner, såsom ad hoc konferenser om Cisco UCM.

    Ungefärligt arbetsschema:
    Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

  • Enkel Split(Single Split) utökar den tidigare distributionstypen genom att lägga till en separat server för extern åtkomst. I äldre distributioner innebar detta att man distribuerade en CMS-server i ett demilitariserat nätverkssegment (DMZ) där externa klienter kunde komma åt den, och en CMS-server i nätverkskärnan där interna klienter kunde få åtkomst till CMS. Denna speciella implementeringsmodell ersätts nu av den så kallade typen Enkel kant, som består av servrar Cisco Expressway, som antingen har eller kommer att ha många av samma Firewall-bypass-funktioner så att klienter inte behöver lägga till en dedikerad Edge CMS-server.

    Ungefärligt arbetsschema:
    Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

  • Skalbar och motståndskraftig(Skalbar och feltolerant) Denna typ inkluderar redundans för varje komponent, vilket gör att systemet kan växa med dina behov till sin maximala kapacitet samtidigt som det ger redundans i händelse av fel. Den använder också Single Edge-konceptet för att ge säker extern åtkomst. Det är den här typen vi kommer att titta på i det här avsnittet. Om vi ​​förstår hur man distribuerar den här typen av kluster kommer vi inte bara att förstå andra typer av distributioner, utan vi kommer också att kunna förstå hur man skapar kluster av CMS-servrar för att tillgodose potentiell tillväxt i efterfrågan.

Innan du går vidare till distributionen måste du förstå några grundläggande saker, nämligen

Huvudkomponenter i CMS-programvaran:

  • Databas: Låter dig kombinera vissa konfigurationer, som uppringningsplan, användarutrymmen och användarna själva. Stöder endast klustring för hög tillgänglighet (single master).
  • Ring Bridge: en tjänst för ljud- och videokonferenser som ger full kontroll över hantering och behandling av samtal och multimediaprocesser. Stöder klustring för hög tillgänglighet och skalbarhet.
  • XMPP-server: ansvarig för registrering och autentisering av klienter som använder Cisco Meeting Application och/eller WebRTC(realtidskommunikation, eller helt enkelt i webbläsaren), såväl som interkomponentsignalering. Kan endast klustras för hög tillgänglighet.
  • Web Bridge: Ger klientåtkomst till WebRTC.
  • Lastbalanserare: Ger en enda anslutningspunkt för Cisco Meeting Apps i Single Split-läge. Lyssnar på det externa gränssnittet och porten för inkommande anslutningar. På samma sätt accepterar lastbalanseraren inkommande TLS-anslutningar från XMPP-servern, genom vilka den kan byta TCP-anslutningar från externa klienter.
    I vårt scenario kommer det inte att behövas.
  • TURN server: Tillhandahåller brandväggsbypass-teknik som tillåter
    placera vårt CMS bakom en brandvägg eller NAT för att ansluta externa klienter med Cisco Meeting App eller SIP-enheter. I vårt scenario kommer det inte att behövas.
  • Webbadministratör: Administrativt gränssnitt och API-åtkomst, inklusive för speciella Unified CM-konferenser.

Konfigurationslägen

Till skillnad från de flesta andra Cisco-produkter stöder Cisco Meeting Server tre konfigurationsmetoder för alla typer av distribution.

  • Kommandorad (CLI): Kommandoradsgränssnitt känt som MMP för initial konfiguration och certifikatuppgifter.
  • Webbadministratör: Främst för CallBridge-relaterade konfigurationer, särskilt när du konfigurerar en enda icke-klustrad server.
  • REST API: Används för de mest komplexa konfigurationsuppgifterna och klustrade databasrelaterade uppgifter.

Utöver ovanstående används protokollet SFTP för att överföra filer – vanligtvis licenser, certifikat eller loggar – till och från CMS-servern.

I distributionsguider från Cisco står det skrivet på vitt och engelska att klustret måste distribueras minst tre servrar (noder) i samband med databaser. Därför att Endast med ett udda antal noder fungerar mekanismen för att välja en ny Databas Master, och i allmänhet har Databas Master en koppling till större delen av CMS-serverdatabasen.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Och som praktiken visar är två servrar (noder) verkligen inte tillräckligt. Valmekanismen fungerar när mastern startas om, slavservern blir master först efter att den omstartade servern har tagits fram. Men om masterservern plötsligt slocknar i ett kluster med två servrar, kommer inte slavservern att bli master, och om slaven slocknar kommer den återstående masterservern att bli slav.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Men i samband med XMPP skulle det verkligen vara nödvändigt att sätta ihop ett kluster med tre servrar, eftersom om du till exempel inaktiverar XMPP-tjänsten på en av servrarna där XMMP är i Leader-status, kommer XMPP att förbli i Follower-status på den återstående servern och CallBridge-anslutningar till XMPP kommer att avbrytas, eftersom CallBridge ansluter exklusivt till XMPP med Leader-status. Och detta är kritiskt, eftersom... inte ett enda samtal kommer att gå igenom.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Även i samma distributionsguider visas ett kluster med en XMPP-server.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Och med hänsyn till ovanstående blir det tydligt varför: det fungerar eftersom det är i failover-läge.

I vårt fall kommer XMPP-servern att finnas på alla tre noderna.

Det antas att alla våra tre servrar är uppe.

DNS-poster

Innan du börjar konfigurera servrar måste du skapa DNS-poster А и SRV typer:

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Observera att det i våra DNS-poster finns två domäner example.com och conf.example.com. Exempel.com är en domän som alla Cisco Unified Communication Manager-prenumeranter kan använda för sina URI:er, som sannolikt finns i din infrastruktur eller sannolikt finns. Eller example.com matchar samma domän som användare använder för sina e-postadresser. Eller Jabber-klienten på din bärbara dator kan ha en URI [e-postskyddad]. Domän conf.example.com är domänen som kommer att konfigureras för Cisco Meeting Server-användare. Domänen för Cisco Meeting Server kommer att vara conf.example.com, så för samma Jabber-användare skulle user@ URI behöva användas för att logga in på Cisco Meeting Serverconf.example.com.

Grundläggande konfiguration

Alla inställningar som beskrivs nedan visas på en server, men de måste göras på varje server i klustret.

QoS

Eftersom CMS genererar realtid trafik känslig för förseningar och paketförluster, i de flesta fall rekommenderas det att konfigurera tjänstekvalitet (QoS). För att uppnå detta stöder CMS:n taggning av paket med de Differentiated Services Codes (DSCP) som den genererar. Även om DSCP-baserad trafikprioritering beror på hur trafiken bearbetas av nätverkskomponenterna i din infrastruktur, kommer vi i vårt fall att konfigurera vårt CMS med typisk DSCP-prioritering baserat på QoS bästa praxis.

På varje server kommer vi att ange dessa kommandon

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

Således var all videotrafik märkt AF41 (DSCP 0x22), all rösttrafik märktes EF (DSCP 0x2E), andra typer av trafik med låg latens som SIP och XMPP använder AF31 (DSCP 0x1A).

Vi kontrollerar:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

NTP

Network Time Protocol (NTP) är viktigt inte bara för att tillhandahålla korrekta tidsstämplar för samtal och konferenser, utan också för att verifiera certifikat.

Lägg till NTP-servrar till din infrastruktur med ett kommando som

ntp server add <server>

I vårt fall finns det två sådana servrar, så det kommer att finnas två lag.
Vi kontrollerar:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Och ställ in tidszonen för vår server
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

DNS

Vi lägger till DNS-servrar till CMS med ett kommando som:

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

I vårt fall finns det två sådana servrar, så det kommer att finnas två lag.
Vi kontrollerar:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Nätverksgränssnittskonfiguration

Vi konfigurerar gränssnittet med ett kommando som:

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

Vi kontrollerar:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Servernamn (värdnamn)

Vi ställer in servernamnet med ett kommando som:

hostname <name>

Och vi startar om.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Detta slutför den grundläggande konfigurationen.

Certifikat

ТеорияCisco Meeting Server kräver krypterad kommunikation mellan olika komponenter, och som ett resultat krävs X.509-certifikat för alla CMS-distributioner. De hjälper till att säkerställa att tjänsterna/servern är betrodd av andra servrar/tjänster.

Varje tjänst kräver ett certifikat, men att skapa separata certifikat för varje tjänst kan leda till förvirring och onödig komplexitet. Som tur är kan vi generera ett certifikats offentlig-privata nyckelpar och sedan återanvända dem över flera tjänster. I vårt fall kommer samma certifikat att användas för Call Bridge, XMPP Server, Web Bridge och Web Admin. Därför måste du skapa ett par offentliga och privata certifikatnycklar för varje server i klustret.

Databasklustring har dock vissa speciella certifikatkrav och kräver därför egna certifikat som skiljer sig från de andra tjänsterna. CMS använder ett servercertifikat, som liknar de certifikat som används av andra servrar, men det finns också ett klientcertifikat som används för databasanslutningar. Databascertifikat används för både autentisering och kryptering. Istället för att tillhandahålla ett användarnamn och lösenord för klienten att ansluta till databasen, presenterar den ett klientcertifikat som servern litar på. Varje server i databasklustret kommer att använda samma publika och privata nyckelpar. Detta gör att alla servrar i klustret kan kryptera data på ett sådant sätt att de bara kan dekrypteras av andra servrar som också delar samma nyckelpar.

För att redundans ska fungera måste databaskluster bestå av minst 3 servrar, men inte fler än 5, med en maximal tur och returtid på 200 ms mellan alla klustermedlemmar. Denna gräns är mer restriktiv än för Call Bridge-klustring, så den är ofta den begränsande faktorn i geografiskt distribuerade distributioner.

Databasrollen för ett CMS har ett antal unika krav. Till skillnad från andra roller kräver det ett klient- och servercertifikat, där klientcertifikatet har ett specifikt CN-fält som presenteras för servern.

CMS använder en postgres-databas med en master och flera helt identiska repliker. Det finns bara en primär databas åt gången ("databasservern"). De återstående medlemmarna i klustret är repliker eller "databasklienter".

Ett databaskluster kräver ett dedikerat servercertifikat och ett klientcertifikat. De måste undertecknas av certifikat, vanligtvis en intern privat certifikatutfärdare. Eftersom alla medlemmar i databasklustret kan bli master måste databasservern och klientcertifikatparen (som innehåller de offentliga och privata nycklarna) kopieras till alla servrar så att de kan anta identiteten för klienten eller databasservern. Dessutom måste CA-rotcertifikatet laddas för att säkerställa att klient- och servercertifikaten kan verifieras.

Så vi skapar en begäran om ett certifikat som kommer att användas av alla servertjänster utom databasen (det kommer att finnas en separat begäran för detta) med ett kommando som:

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

I CN skriver vi det allmänna namnet på våra servrar. Till exempel om värdnamnen på våra servrar server01, server02, server03, då blir CN server.exempel.com

Vi gör samma sak på de återstående två servrarna med skillnaden att kommandona kommer att innehålla motsvarande "värdnamn"

Vi genererar två förfrågningar om certifikat som kommer att användas av databastjänsten med kommandon som:

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

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

pki csr dbclusterclient CN:postgres

där dbclusterserver и dbclusterklient namn på våra förfrågningar och framtida certifikat, värdnamn1(2)(3) namnen på motsvarande servrar.

Vi utför denna procedur endast på en server (!), och vi kommer att ladda upp certifikaten och motsvarande .key-filer till andra servrar.

Aktivera klientcertifikatläge i AD CSCisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Du måste också slå samman certifikaten för varje server till en fil.På *NIX: 

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

På Windows/DOS: 

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

Och ladda upp till varje server:
1. "Individuellt" servercertifikat.
2. Rotcertifikat (tillsammans med mellanliggande, om några).
3. Certifikat för databasen (“server” och “klient”) och filer med filtillägget .key, som genererades när en begäran om databascertifikaten “server” och “klient” skapades. Dessa filer måste vara samma på alla servrar.
4. Fil med alla tre "individuella" certifikat.

Som ett resultat bör du få något liknande den här filbilden på varje server.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Databaskluster

Nu när du har laddat upp alla certifikat till CMS-servrarna kan du konfigurera och aktivera databasklustring mellan de tre noderna. Det första steget är att välja en server som huvudnod för databasklustret och helt konfigurera den.

Master Database

Det första steget i att ställa in databasreplikering är att ange vilka certifikat som ska användas för databasen. Detta görs med ett kommando som:

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

Låt oss nu berätta för CMS vilket gränssnitt som ska användas för databasklustring med kommandot:

database cluster localnode a

Sedan initierar vi klusterdatabasen på huvudservern med kommandot:

database cluster initialize

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Klientdatabasnoder

Vi gör samma procedur, bara istället för kommandot initiering av databaskluster ange ett kommando som:

database cluster join <ip address existing master>

där ip-adress befintlig master-ip-adress för CMS-servern där klustret initierades, helt enkelt Master.

Vi kontrollerar hur vårt databaskluster fungerar på alla servrar med kommandot:

database cluster status

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Vi gör samma sak på den återstående tredje servern.

Som ett resultat visar det sig att vår första server är Mästaren, resten är Slavar.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Webbadministratörstjänst

Aktivera webbadministratörstjänsten:

webadmin listen a 445

Port 445 valdes eftersom port 443 används för användaråtkomst till webbklienten

Vi konfigurerar Web Admin-tjänsten med certifikatfiler med ett kommando som:

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

Och aktivera Web Admin med kommandot:

webadmin enable

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Om allt är bra kommer vi att få SUCCESS-rader som indikerar att Web Admin är korrekt konfigurerad för nätverket och certifikatet. Vi kontrollerar tjänstens funktionalitet med hjälp av en webbläsare och anger webbadministratörens adress, till exempel: cms.example.com: 445

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ring Bridge Cluster

Call Bridge är den enda tjänsten som finns i varje CMS-distribution. Call Bridge är den huvudsakliga konferensmekanismen. Den tillhandahåller också ett SIP-gränssnitt så att samtal kan dirigeras till eller från det av till exempel en Cisco Unified CM.

Kommandon som beskrivs nedan måste utföras på varje server med lämpliga certifikat.
Så:

Vi associerar certifikat med Call Bridge-tjänsten med ett kommando som:

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

Vi binder CallBridge-tjänster till gränssnittet vi behöver med kommandot:

callbridge listen a

Och starta om tjänsten med kommandot:

callbridge restart

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Nu när vi har konfigurerat våra Call Bridges kan vi konfigurera Call Bridge-klustring. Call Bridge-klustring skiljer sig från databas- eller XMPP-klustring. Call Bridge Cluster kan stödja från 2 till 8 noder utan några begränsningar. Det ger inte bara redundans utan också lastbalansering så att konferenser aktivt kan distribueras över Call Bridge-servrar med hjälp av intelligent samtalsdistribution. CMS har ytterligare funktioner, Call Bridge-grupper och relaterade funktioner som kan användas för vidare hantering.

Anropsbrygga klustring konfigureras främst via webbadministratörsgränssnittet
Proceduren som beskrivs nedan måste utföras på varje server i klustret.
Så,

1. Gå via webben till Konfiguration > Kluster.
2. In Call Bridge-identitet Som ett unikt namn anger du callbridge[01,02,03] som motsvarar servernamnet. Dessa namn är godtyckliga, men måste vara unika för detta kluster. De är beskrivande till sin natur eftersom de indikerar att de är serveridentifierare [01,02,03].
3.B Klustrade samtalsbryggor ange webbadministratörsadresserna för våra servrar i klustret, cms[01,02,03].example.com:445, i fältet Adress. Var noga med att ange porten. Du kan lämna Peer-länk SIP-domän tom.
4. Lägg till ett certifikat till CallBridge-förtroendet för varje server, vars fil innehåller alla certifikat för våra servrar, som vi slog ihop till den här filen i början, med ett kommando som: 

callbridge trust cluster <trusted cluster certificate bundle>

Och starta om tjänsten med kommandot:

callbridge restart

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Som ett resultat bör du få den här bilden på varje server:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

XMPP-kluster

XMPP-tjänsten i CMS används för att hantera all registrering och autentisering för Cisco Meeting Apps (CMA), inklusive webbklienten CMA WebRTC. Själva Call Bridge fungerar också som en XMPP-klient för autentiseringsändamål och måste därför konfigureras som andra klienter. XMPP-feltolerans är en funktion som har stöds i produktionsmiljöer sedan version 2.1

Kommandon som beskrivs nedan måste utföras på varje server med lämpliga certifikat.
Så:

Vi associerar certifikat med XMPP-tjänsten med ett kommando som:

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

Definiera sedan lyssningsgränssnittet med kommandot:

xmpp listen a

XMPP-tjänsten kräver en unik domän. Detta är inloggningen för användare. Med andra ord, när en användare försöker logga in med CMA-appen (eller via WebRTC-klienten), anger de användar-ID@logindomän. I vårt fall kommer det att vara användarid@conf.example.com. Varför är det inte bara example.com? I vår specifika implementering valde vi vår Unified CM-domän som Jabber-användare kommer att använda i Unified CM som example.com, så vi behövde en annan domän för CMS-användare att dirigera samtal till och från CMS genom SIP-domäner.

Konfigurera en XMPP-domän med ett kommando som:

xmpp domain <domain>

Och aktivera XMPP-tjänsten med kommandot:

xmpp enable

I XMPP-tjänsten måste du skapa autentiseringsuppgifter för varje Call Bridge som kommer att användas vid registrering med XMPP-tjänsten. Dessa namn är godtyckliga (och är inte relaterade till de unika namn du konfigurerat för samtalsbryggklustring). Du måste lägga till tre anropsbryggor på en XMPP-server och sedan ange dessa referenser på andra XMPP-servrar i klustret eftersom den här konfigurationen inte passar in i klusterdatabasen. Senare kommer vi att konfigurera varje samtalsbrygga att använda detta namn och hemlighet för att registrera sig med XMPP-tjänsten.

Nu måste vi konfigurera XMPP-tjänsten på den första servern med tre Call Bridges callbridge01, callbridge02 och callbridge03. Varje konto kommer att tilldelas slumpmässiga lösenord. De kommer senare att läggas in på andra Call Bridge-servrar för att logga in på denna XMPP-server. Ange följande kommandon:

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

Som ett resultat kontrollerar vi vad som hände med kommandot:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Exakt samma bild bör visas på de återstående servrarna efter stegen som beskrivs nedan.

Därefter lägger vi till exakt samma inställningar på de återstående två servrarna, bara med kommandona

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

Vi lägger till Secret väldigt noggrant så att det till exempel inte finns några extra mellanslag i den.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Som ett resultat bör varje server ha samma bild:

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Därefter, på alla servrar i klustret, anger vi i förtroende filen som innehåller alla tre certifikat, skapade tidigare med ett kommando som detta:

xmpp cluster trust <trust bundle>

Vi aktiverar xmpp-klusterläge på alla klusterservrar med kommandot:

xmpp cluster enable

På den första servern i klustret initierar vi skapandet av ett xmpp-kluster med kommandot:

xmpp cluster initialize

På andra servrar, lägg till ett kluster till xmpp med ett kommando som:

xmpp cluster join <ip address head xmpp server>

Vi kontrollerar på varje server framgången med att skapa ett XMPP-kluster på varje server med kommandona:

xmpp status
xmpp cluster status

Första servern:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Andra servern:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Tredje servern:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ansluter Call Bridge till XMPP

Nu när XMPP-klustret körs måste du konfigurera Call Bridge-tjänsterna för att ansluta till XMPP-klustret. Denna konfiguration görs via webbadministratören.

På varje server går du till Konfiguration > Allmänt och i fältet Unikt namn på Call Bridge skriv unika namn som motsvarar serverns Call Bridge callbridge[01,02,03]... I fält Domän conf.example.ru och motsvarande lösenord, du kan spionera på dem
på valfri server i klustret med kommandot:

xmpp callbridge list

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Lämna fältet "Server" tomt Callbridge kommer att utföra en DNS SRV-sökning efter _xmpp-component._tcp.conf.example.comför att hitta en tillgänglig XMPP-server. IP-adresserna för att ansluta callbridges till XMPP kan skilja sig åt på varje server, det beror på vilka värden som returneras till postbegäran _xmpp-component._tcp.conf.example.com callbridge, vilket i sin tur beror på prioritetsinställningarna för en given DNS-post.

Gå sedan till Status > Allmänt för att verifiera om Call Bride-tjänsten är ansluten till XMPP-tjänsten.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Web Bridge

På varje server i klustret, aktivera Web Bridge-tjänsten med kommandot:

webbridge listen a:443

Vi konfigurerar Web Bridge-tjänsten med certifikatfiler med ett kommando som:

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

Web Bridge stöder HTTPS. Den kommer att omdirigera HTTP till HTTPS om den är konfigurerad att använda "http-redirect".
För att aktivera HTTP-omdirigering, använd följande kommando:

webbridge http-redirect enable

För att låta Call Bridge veta att Web Bridge kan lita på anslutningar från Call Bridge, använd kommandot:

webbridge trust <certfile>

där detta är en fil som innehåller alla tre certifikaten från varje server i klustret.

Den här bilden bör finnas på varje server i klustret.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Nu måste vi skapa en användare med rollen "appadmin", vi behöver den så att vi kan konfigurera vårt kluster(!), och inte varje server i klustret separat, på så sätt kommer inställningarna att tillämpas lika på varje server trots faktum att de kommer att göras en gång.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

För ytterligare inställningar kommer vi att använda Postman.

För auktorisering, välj Grundläggande i avsnittet Auktorisering

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

För att korrekt skicka kommandon till CMS-servern måste du ställa in den kodning som krävs

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Vi anger Webbridge med kommandot POST med parameter URL och mening cms.example.com

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

I själva webbbryggan anger vi de nödvändiga parametrarna: gäståtkomst, skyddad åtkomst, etc.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ring Bridge-grupper

Som standard använder CMS inte alltid den mest effektiva användningen av de tillgängliga konferensresurserna.

Till exempel, för ett möte med tre deltagare kan varje deltagare hamna på tre olika samtalsbryggor. För att dessa tre deltagare ska kunna kommunicera med varandra kommer Call Bridges automatiskt att upprätta förbindelser mellan alla servrar och klienter i samma Space, så att det hela ser ut som om alla klienter finns på samma server. Tyvärr är nackdelen med detta att en enda konferens för tre personer nu kommer att förbruka 3 mediaportar. Detta är uppenbarligen en ineffektiv resursanvändning. Dessutom, när en samtalsbrygga verkligen är överbelastad, är standardmekanismen att fortsätta att acceptera samtal och tillhandahålla lägre kvalitetsservice till alla abonnenter på den samtalsbryggan.

Dessa problem löses med funktionen Call Bridge Group. Den här funktionen introducerades i version 2.1 av Cisco Meeting Server-programvaran och har utökats för att stödja lastbalansering för både inkommande och utgående Cisco Meeting App-samtal (CMA), inklusive WebRTC-deltagare.

För att lösa återanslutningsproblemet har tre konfigurerbara lastgränser införts för varje samtalsbrygga:

Lastgräns — detta är den maximala numeriska belastningen för en viss anropsbrygga. Varje plattform har en rekommenderad belastningsgräns, såsom 96000 för CMS1000 och 1.25 GHz per vCPU för den virtuella maskinen. Olika samtal förbrukar en viss mängd resurser beroende på deltagarens upplösning och bildhastighet.
NewConferenceLoadLimitBasisPoints (standard 50% loadLimit) - ställer in serverns belastningsgräns, varefter nya konferenser avvisas.
ExistingConferenceLoadLimitBasisPoints (standard 80% av loadLimit) - serverns belastningsvärde efter vilket deltagare som går med i en befintlig konferens kommer att avvisas.

Även om den här funktionen designades för samtalsdistribution och lastbalansering, kan andra grupper som TURN-servrar, webbbryggservrar och inspelare också tilldelas samtalsbrygggrupper så att de också kan grupperas korrekt för optimal användning. Om något av dessa objekt inte är tilldelat en samtalsgrupp antas de vara tillgängliga för alla servrar utan någon särskild prioritet.

Dessa parametrar konfigureras här: cms.example.com:445/api/v1/system/configuration/cluster

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Därefter anger vi för varje anropsbrygga vilken anropsbrygggrupp den tillhör:

Första callbridge
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Andra anropsbryggan
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Tredje anropsbryggan
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Därför konfigurerade vi Call Brdige-gruppen för att mer effektivt använda resurserna i Cisco Meeting Server-klustret.

Importera användare från Active Directory

Webbadministratörstjänsten har en LDAP-konfigurationssektion, men den ger inga komplexa konfigurationsalternativ, och informationen lagras inte i klusterdatabasen, så konfigurationen måste göras, antingen manuellt på varje server via webbgränssnittet, eller genom API:et, och så att vi "tre gånger "Gå inte upp" kommer vi fortfarande att ställa in data via API:et.

Använder URL för att komma åt cms01.example.com:445/api/v1/ldapServers skapar ett LDAP-serverobjekt och anger parametrar som:

  • Server IP
  • portnummer
  • Användarnamn
  • пароль
  • säkra

Säker - välj sant eller falskt beroende på porten, 389 - inte säker, 636 - skyddad.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Mappning av LDAP-källparametrar till attribut i Cisco Meeting Server.
LDAP-mappningen mappar attributen i LDAP-katalogen till attributen i CMS. De faktiska attributen:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Beskrivning av attributJID representerar användarens inloggnings-ID i CMS. Eftersom detta är en Microsoft Active Directory LDAP-server, mappas CMS JID till sAMAccountName i LDAP, som i huvudsak är användarens Active Directory-inloggnings-ID. Notera också att du tar sAMAccountName och lägger till domänen conf.pod6.cms.lab i slutet av den eftersom detta är den inloggning som dina användare kommer att använda för att logga in på CMS.

nameMapping matchar det som finns i Active Directory displayName-fältet med användarens CMS-namnfält.

coSpaceNameMapping skapar ett CMS-utrymmesnamn baserat på fältet displayName. Detta attribut, tillsammans med coSpaceUriMapping-attributet, är vad som krävs för att skapa ett utrymme för varje användare.

coSpaceUriMapping definierar användardelen av URI:n som är kopplad till användarens personliga utrymme. Vissa domäner kan konfigureras för att ringas upp i rymden. Om användardelen matchar detta fält för en av dessa domäner kommer samtalet att dirigeras till den användarens utrymme.

coSpaceSecondaryUriMapping definierar en andra URI för att nå rymden. Detta kan användas för att lägga till ett numeriskt alias för att dirigera samtal till den importerade användarens utrymme som ett alternativ till den alfanumeriska URI som definieras i parametern coSpaceUriMapping.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

LDAP-servern och LDAP-mappningen är konfigurerade. Nu måste du länka dem tillsammans genom att skapa en LDAP-källa.

Använder URL för att komma åt cms01.example.com:445/api/v1/ldapSource skapa ett LDAP-källobjekt och specificera parametrar som:

  • server
  • kartläggning
  • baseDn
  • filtrera

Nu när LDAP-konfigurationen är klar kan du utföra den manuella synkroniseringen.

Vi gör detta antingen i webbgränssnittet för varje server genom att klicka Synkronisera nu avsnitt Active Directory
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

eller via API:t med kommandot POST använder URL för att komma åt cms01.example.com:445/api/v1/ldapSyncs

Ad-hoc konferenser

Vad är det här?I det traditionella konceptet är en konferens när två deltagare pratar med varandra och en av deltagarna (med en enhet registrerad med Unified CM) trycker på knappen "Konferens", ringer upp den andra personen och efter att ha pratat med den tredje parten , trycker på knappen "Konferens" igen för att gå med alla deltagare i trepartskonferensen.

Det som skiljer en Ad-Hoc-konferens från en schemalagd konferens i ett CMS är att en Ad-Hoc-konferens inte bara är ett SIP-samtal till ett CMS. När konferensinitiatorn klickar på knappen Konferens en andra gång för att bjuda in alla till samma möte, måste Unified CM göra ett API-anrop till CMS för att skapa en direktkonferens dit alla samtal sedan överförs. Allt detta sker obemärkt av deltagarna.

Detta innebär att Unified CM måste konfigurera API-uppgifterna och WebAdmin-adressen/porten för tjänsten samt SIP-trunken direkt till CMS-servern för att fortsätta samtalet.

Vid behov kan CUCM dynamiskt skapa ett utrymme i CMS så att varje samtal kan nå CMS och matcha regeln för inkommande samtal som är avsedd för utrymmen.

Integration med CUCM konfigureras på samma sätt som beskrivs i artikeln tidigare förutom att på Cisco UCM måste du skapa tre trunkar för CMS, tre konferensbryggor, i SIP-säkerhetsprofilen ange tre ämnesnamn, ruttgrupper, ruttlistor, mediaresursgrupper och mediaresursgrupplistor, och lägg till några routningsregler till Cisco Meeting Server.

SIP-säkerhetsprofil:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Trunks:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Varje stam ser likadan ut:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Konferensbron
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Varje konferensbrygga ser likadan ut:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ruttgrupp
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ruttlista
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Mediaresursgrupp
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Mediaresursgrupplista
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Samtalsregler

Till skillnad från mer avancerade samtalshanteringssystem som Unified CM eller Expressway, söker CMS endast upp domänen i SIP Request-URI-fältet för nya samtal. Så om SIP INVITE är för en klunk: [e-postskyddad]CMS bryr sig bara om domain.com. CMS följer dessa regler för att avgöra vart ett samtal ska dirigeras:

1. CMS försöker först matcha SIP-domänen med domänerna som konfigurerats i reglerna för inkommande samtal. Dessa samtal kan sedan dirigeras till ("riktade") utrymmen eller specifika användare, interna IVR:er eller direkt integrerade Microsoft Lync/Skype for Business-destinationer (S4B).
2. Om det inte finns någon matchning i reglerna för inkommande samtal kommer CMS att försöka matcha den domän som konfigurerats i tabellen för vidarekoppling av samtal. Om en matchning görs kan regeln uttryckligen avvisa samtalet eller vidarekoppla samtalet. För närvarande kan CMS skriva om domänen, vilket ibland är användbart för att anropa Lync-domäner. Du kan också välja att passera kast, vilket innebär att inget av fälten kommer att ändras ytterligare, eller använda en intern CMS-uppringningsplan. Om det inte finns någon matchning i reglerna för vidarekoppling av samtal är standarden att avvisa samtalet. Tänk på att i CMS, även om samtalet "vidarekopplas", är media fortfarande bundna till CMS, vilket innebär att det kommer att ligga i signalerings- och mediatrafikvägen.
Då gäller endast vidarekopplade samtal reglerna för utgående samtal. Dessa inställningar bestämmer destinationerna dit samtal skickas, trunktyp (oavsett om det är ett nytt Lync-samtal eller ett standard SIP-samtal) och eventuella konverteringar som kan utföras om överföring inte är vald i regeln för vidarekoppling av samtal.

Här är den faktiska loggen över vad som händer under en ad-hoc-konferens

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Skärmdumpen visar det dåligt (jag vet inte hur man gör det bättre), så jag skriver loggen så här:

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

Själva ad-hoc-konferensen:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Regler för inkommande samtal
Att konfigurera parametrarna för inkommande samtal är nödvändigt för att kunna ta emot ett samtal i CMS. Som du såg i LDAP-inställningen importerades alla användare med domänen conf.pod6.cms.lab. Så som ett minimum vill du att anrop till den här domänen ska rikta in sig på utrymmen. Du kommer också att behöva sätta upp regler för allt som är avsett för det fullt kvalificerade domännamnet (och kanske till och med IP-adressen) för var och en av CMS-servrarna. Vår externa samtalskontroll, Unified CM, kommer att konfigurera SIP-trunkar dedikerade till var och en av CMS-servrarna individuellt. Beroende på om destinationen för dessa SIP-trunkar är en IP-adress eller serverns FQDN kommer att avgöra om CMS måste konfigureras för att acceptera samtal som riktas till dess IP-adress eller FQDN.

Den domän som har högst prioritet för inkommande regel används som domän för eventuella användarutrymmen. När användare synkroniserar via LDAP skapar CMS automatiskt utrymmen, men bara användardelen av URI:n (coSpaceUriMapping), till exempel user.space. Del domän Den fullständiga URIn genereras baserat på denna regel. Faktum är att om du skulle logga in på Web Bridge vid det här laget skulle du se att Space URI inte har en domän. Genom att ställa in den här regeln som högsta prioritet ställer du in domänen för de genererade utrymmena konf.exempel.com.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Regler för utgående samtal

För att tillåta användare att ringa utgående samtal till Unified CM-klustret måste du konfigurera utgående regler. Domänen för slutpunkter som är registrerade med Unified CM, som Jabber, är example.com. Samtal till denna domän bör dirigeras som standard SIP-samtal till Unified CM-samtalsbehandlingsnoder. Huvudservern är cucm-01.example.com, och den extra servern är cucm-02.example.com.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning
Den första regeln beskriver den enklaste dirigeringen av samtal mellan klusterservrar.

Fält Lokal från domän är ansvarig för vad som kommer att visas i uppringarens SIP-URI för den person som blir uppringd efter "@"-symbolen. Om vi ​​lämnar det tomt, kommer det efter "@"-symbolen att finnas CUCM:s IP-adress genom vilken detta samtal passerar. Om vi ​​anger en domän, kommer det faktiskt att finnas en domän efter "@"-symbolen. Detta är nödvändigt för att kunna ringa tillbaka, annars går det inte att ringa tillbaka via SIP-URI namn@ip-adress.

Ring när det anges Lokal från domän
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Ring när INTE anges Lokal från domän
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Se till att uttryckligen ange Krypterad eller Okrypterad för utgående samtal, eftersom ingenting fungerar med parametern Auto.

Inspelning

Videokonferenser spelas in av inspelningsservern. Recorder är exakt samma som Cisco Meeting Server. Recorder kräver ingen installation av några licenser. Inspelningslicenser krävs för servrar som kör CallBridge-tjänster, d.v.s. en inspelningslicens krävs och måste tillämpas på CallBridge-komponenten och inte på servern som kör Recorder. Recorder fungerar som en Extensible Messaging and Presence Protocol (XMPP)-klient, så XMPP-servern måste vara aktiverad på servern som är värd för CallBridge.

Därför att Vi har ett kluster och licensen måste "sträckas ut" över alla tre servrarna i klustret. Sedan helt enkelt i ditt personliga konto i de licenser vi associerar (lägger till) MAC-adresserna för a-gränssnitten för alla CMS-servrar som ingår i klustret.

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Och det här är bilden som borde finnas på varje server i klustret

Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

I allmänhet finns det flera scenarier för att placera Recorder, men vi kommer att hålla oss till detta:
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Innan du ställer in Recorder måste du förbereda en plats där videokonferenserna faktiskt kommer att spelas in. Faktiskt här länk, hur du ställer in all inspelning. Jag fokuserar på viktiga punkter och detaljer:

1. Det är bättre att ta bort certifikatet från den första servern i klustret.
2. Felet "Inspelare ej tillgänglig" kan uppstå eftersom fel certifikat är specificerat i Recorder Trust.
3. Skrivningen kanske inte fungerar om den NFS-katalog som anges för inspelning inte är rotkatalogen.

Ibland finns det ett behov av att automatiskt spela in en konferens för en specifik användare eller utrymme.

För detta skapas två CallProfiler:
Med inspelning inaktiverad
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Och med automatisk inspelningsfunktion
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

Därefter "bifogar" vi en CallProfile med en automatisk inspelningsfunktion till önskat utrymme.
Cisco Meeting Server 2.5.2. Kluster i skalbart och fjädrande läge med funktion för videokonferensinspelning

I CMS är det så etablerat att om en CallProfile är explicit bunden till något utrymme eller utrymme, så fungerar denna CallProfile endast i förhållande till dessa specifika utrymmen. Och om CallProfile inte är bunden till något utrymme, tillämpas den som standard på de utrymmen som ingen CallProfile är uttryckligen bunden till.

Nästa gång ska jag försöka beskriva hur CMS nås utanför organisationens interna nätverk.

Källor:

Källa: will.com

Lägg en kommentar