Cisco жиналыс сервері 2.5.2. Бейне конференция жазу функциясы бар масштабталатын және серпімді режимдегі кластер

Бұл шығарылымда мен CMS серверін ауыстыру кластері режимінде орнатудың кейбір қыр-сырын көрсетемін және түсіндіремін.


ТеорияЖалпы, CMS серверін орналастырудың үш түрі бар:

• Біріктірілген(Бірыңғай біріктірілген), яғни. бұл барлық қажетті қызметтер жұмыс істейтін бір сервер. Көп жағдайда қолданудың бұл түрі тек ішкі клиенттік қатынас үшін және бір сервердің ауқымдылығы мен артық шектеулері маңызды мәселе болып табылмайтын кішірек орталарда немесе CMS арнайы функцияларды ғана орындайтын жағдайларда ғана жарамды, мысалы, арнайы Cisco UCM бойынша конференциялар.

  Жұмыстың шамамен схемасы:
  

• Жалғыз бөліну(Single Split) сыртқы қатынас үшін бөлек серверді қосу арқылы алдыңғы орналастыру түрін кеңейтеді. Бұрынғы орналастыруларда бұл сыртқы клиенттер оған қол жеткізе алатын қарусыздандырылған желі сегментінде (DMZ) CMS серверін және ішкі клиенттер CMS-ке қол жеткізе алатын желі ядросында бір CMS серверін қолдануды білдіреді. Бұл нақты орналастыру үлгісі енді түрі деп аталатын түрімен ауыстырылады Жалғыз жиек, ол серверлерден тұрады Cisco Expressway, оларда көптеген бірдей желіаралық қалқанды айналып өту мүмкіндіктері бар немесе болады, сондықтан клиенттерге арнайы CMS серверін қосудың қажеті жоқ.

  Жұмыстың шамамен схемасы:
  

• Масштабталатын және серпімді(Масштабталатын және ақауларға төзімді) Бұл түрге әрбір құрамдас үшін резервтеу кіреді, бұл жүйенің сіздің қажеттіліктеріңізбен максималды сыйымдылығына дейін өсуіне мүмкіндік береді, сонымен бірге сәтсіздік жағдайында резервтеуді қамтамасыз етеді. Ол сондай-ақ қауіпсіз сыртқы қатынасты қамтамасыз ету үшін Single Edge тұжырымдамасын пайдаланады. Бұл түрді біз осы эпизодта қарастырамыз. Егер біз кластердің осы түрін қалай орналастыру керектігін түсінетін болсақ, біз орналастырудың басқа түрлерін түсініп қана қоймаймыз, сонымен қатар сұраныстың әлеуетті өсуін қанағаттандыру үшін CMS серверлерінің кластерлерін қалай жасау керектігін түсінеміз.

Орналастыруға көшпес бұрын, сіз кейбір негізгі нәрселерді түсінуіңіз керек, атап айтқанда

CMS бағдарламалық құралының негізгі компоненттері:

• дерекқор: Теру жоспары, пайдаланушы кеңістіктері және пайдаланушылардың өздері сияқты кейбір конфигурацияларды біріктіруге мүмкіндік береді. Тек жоғары қолжетімділік (бір басты) үшін кластерлеуді қолдайды.
• Көпірге қоңырау шалыңыз: қоңыраулар мен мультимедиялық процестерді басқару мен өңдеуді толық бақылауды қамтамасыз ететін аудио және бейнеконференциялар қызметі. Жоғары қолжетімділік және масштабтау үшін кластерлеуді қолдайды.
• XMPP сервері: Cisco Meeting қолданбасын және/немесе WebRTC(нақты уақыттағы байланыс немесе жай браузерде), сонымен қатар құрамдас аралық сигнализация. Тек жоғары қолжетімділік үшін кластерлеуге болады.
• Веб көпір: WebRTC қызметіне клиенттік қатынасты қамтамасыз етеді.
• Жүктеме теңестіруші: Жалғыз бөлу режимінде Cisco Meeting қолданбалары үшін жалғыз қосылым нүктесін қамтамасыз етеді. Кіріс қосылымдар үшін сыртқы интерфейс пен портты тыңдайды. Жүктеме теңестіруші XMPP серверінен кіріс TLS қосылымдарын қабылдайды, ол арқылы сыртқы клиенттерден TCP қосылымдарын ауыстыра алады.
  Біздің сценарийде бұл қажет емес.
• TURN сервер: мүмкіндік беретін брандмауэрді айналып өту технологиясын қамтамасыз етеді
  Cisco Meeting қолданбасы немесе SIP құрылғылары арқылы сыртқы клиенттерді қосу үшін CMS-ті брандмауэр немесе NAT артына қойыңыз. Біздің сценарийде бұл қажет емес.
• Веб әкімшісі: Әкімшілік интерфейс және API қатынасы, соның ішінде арнайы Unified CM конференциялары үшін.

Конфигурация режимдері

Басқа Cisco өнімдерінің көпшілігінен айырмашылығы, Cisco жиналыс сервері орналастырудың кез келген түрін орналастыру үшін үш конфигурация әдісін қолдайды.

• Пәрмен жолы (CLI): Бастапқы конфигурациялау және сертификат тапсырмалары үшін MMP ретінде белгілі пәрмен жолы интерфейсі.
• Веб-әкімші: Ең алдымен CallBridge қатысты конфигурациялар үшін, әсіресе кластерлік емес жалғыз серверді орнату кезінде.
• REST API: Ең күрделі конфигурация тапсырмалары және кластерленген дерекқорға қатысты тапсырмалар үшін пайдаланылады.

Жоғарыда айтылғандарға қосымша хаттама қолданылады SFTP файлдарды (әдетте лицензияларды, сертификаттарды немесе журналдарды) CMS серверіне және одан тасымалдау үшін.

Cisco қолдану нұсқаулығында кластерді орналастыру қажет екендігі ақ және ағылшын тілінде жазылған. кем дегенде үш дерекқорлар контекстіндегі серверлер (түйіндер). Өйткені Түйіндердің тақ санымен ғана жаңа Дерекқор шеберін таңдау механизмі жұмыс істейді, және жалпы алғанда, Дерекқор шебері CMS серверінің дерекқорының көпшілігімен байланысы бар.

Ал тәжірибе көрсеткендей, екі сервер (түйін) шынымен жеткіліксіз. Таңдау механизмі Мастер қайта жүктелгенде жұмыс істейді, бағынды сервер қайта жүктелген сервер шыққаннан кейін ғана Мастер болады. Алайда, егер екі сервер кластерінде негізгі сервер кенет сөніп қалса, онда бағынышты сервер Мастер болмайды, ал егер бағынышты өшсе, қалған негізгі сервер бағындыға айналады.

Бірақ XMPP контекстінде үш серверден тұратын кластерді жинау қажет болады, өйткені егер, мысалы, XMMP Лидер күйінде болатын серверлердің бірінде XMPP қызметін өшірсеңіз, қалған серверде XMPP Follower күйінде қалады және XMPP-ге CallBridge қосылымдары үзіледі, себебі CallBridge тек Көшбасшы мәртебесі бар XMPP-ге қосылады. Бұл өте маңызды, өйткені ... бірде-бір қоңырау өтпейді.

Сондай-ақ, бірдей орналастыру нұсқаулығында бір XMPP сервері бар кластер көрсетіледі.

Жоғарыда айтылғандарды ескере отырып, неге екені белгілі болады: ол жұмыс істейді, себебі ол ауыстырып-қосу режимінде.

Біздің жағдайда XMPP сервері барлық үш түйінде болады.

Біздің үш серверіміз де жұмыс істейді деп болжануда.

DNS жазбалары

Серверлерді орнатуды бастамас бұрын, DNS жазбаларын жасау керек А и SRV түрлері:

Біздің DNS жазбаларымызда example.com және екі домен бар екенін ескеріңіз конференция.example.com. Example.com — барлық Cisco Unified Communication Manager жазылушылары өз URI мекенжайлары үшін пайдалана алатын домен, ол сіздің инфрақұрылымыңызда бар немесе болуы ықтимал. Немесе example.com пайдаланушылар электрондық пошта мекенжайлары үшін пайдаланатын доменге сәйкес келеді. Немесе ноутбуктағы Jabber клиентінде URI болуы мүмкін [электрондық пошта қорғалған]. Домен конференция.example.com — Cisco Meeting Server пайдаланушылары үшін конфигурацияланатын домен. Cisco жиналыс серверінің домені болады конференция.example.com, сондықтан сол Jabber пайдаланушысы үшін user@ URI Cisco жиналыс серверіне кіру үшін пайдаланылуы керек.конференция.example.com.

Негізгі конфигурация

Төменде сипатталған барлық параметрлер бір серверде көрсетілген, бірақ олар кластердегі әрбір серверде орындалуы керек.

QoS

CMS құратындықтан шынайы уақыт кідірістерге және пакеттердің жоғалуына сезімтал трафик, көп жағдайда қызмет көрсету сапасын (QoS) конфигурациялау ұсынылады. Бұған қол жеткізу үшін CMS өзі жасайтын дифференциалды қызмет кодтарымен (DSCP) тегтеу пакеттерін қолдайды. DSCP негізіндегі трафик басымдылығы трафикті инфрақұрылымыңыздың желілік құрамдас бөліктерімен қалай өңдейтініне байланысты болса да, біздің жағдайда біз CMS-ті QoS үздік тәжірибелеріне негізделген әдеттегі DSCP басымдылығымен конфигурациялаймыз.

Әрбір серверде біз осы командаларды енгіземіз

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

Осылайша, барлық бейне трафигі AF41 (DSCP 0x22) деп белгіленді, барлық дауыстық трафик EF (DSCP 0x2E) деп белгіленді, SIP және XMPP сияқты кідіріссіз трафиктің басқа түрлері AF31 (DSCP 0x1A) қолданылады.

Тексеру:

NTP

Желілік уақыт протоколы (NTP) қоңыраулар мен конференциялардың нақты уақыт белгілерін беру үшін ғана емес, сонымен қатар сертификаттарды тексеру үшін де маңызды.

сияқты пәрмен арқылы инфрақұрылымға NTP серверлерін қосыңыз

ntp server add <server>

Біздің жағдайда мұндай екі сервер бар, сондықтан екі команда болады.
Тексеру:

Біздің сервер үшін уақыт белдеуін орнатыңыз

DNS

Біз DNS серверлерін CMS жүйесіне келесідей пәрменмен қосамыз:

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

Біздің жағдайда мұндай екі сервер бар, сондықтан екі команда болады.
Тексеру:

Желі интерфейсінің конфигурациясы

Біз интерфейсті келесідей пәрменмен конфигурациялаймыз:

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

Тексеру:

Сервер атауы (хост аты)

Біз сервер атауын келесідей пәрменмен орнатамыз:

hostname <name>

Және біз қайта жүктейміз.


Бұл негізгі конфигурацияны аяқтайды.

Сертификаттар

ТеорияCisco жиналыс сервері әртүрлі құрамдас бөліктер арасындағы шифрланған байланысты қажет етеді және нәтижесінде барлық CMS орналастырулары үшін X.509 сертификаттары қажет. Олар қызметтерге/серверге басқа серверлер/қызметтердің сенімді болуын қамтамасыз етуге көмектеседі.

Әрбір қызмет сертификатты қажет етеді, бірақ әрбір қызмет үшін жеке сертификаттар жасау шатасуға және қажетсіз күрделілікке әкелуі мүмкін. Бақытымызға орай, біз сертификаттың жалпы-жеке кілт жұбын жасай аламыз, содан кейін оларды бірнеше қызметтерде қайта пайдалана аламыз. Біздің жағдайда дәл сол сертификат Call Bridge, XMPP Server, Web Bridge және Web Admin үшін пайдаланылады. Осылайша, кластердегі әрбір сервер үшін жалпы және жеке куәлік кілттерінің жұбын жасау керек.

Дегенмен, деректер базасын кластерлеуде кейбір арнайы сертификат талаптары бар, сондықтан басқа қызметтердің сертификаттарынан ерекшеленетін өз сертификаттарын талап етеді. CMS сервер сертификатын пайдаланады, ол басқа серверлер пайдаланатын сертификаттарға ұқсас, бірақ дерекқор қосылымдары үшін пайдаланылатын клиент сертификаты да бар. Деректер базасының сертификаттары аутентификация үшін де, шифрлау үшін де қолданылады. Клиентке дерекқорға қосылу үшін пайдаланушы аты мен құпия сөзді берудің орнына ол сервер сенімді клиент куәлігін ұсынады. Дерекқор кластеріндегі әрбір сервер бірдей жалпы және жеке кілт жұбын пайдаланады. Бұл кластердегі барлық серверлерге деректерді бірдей кілт жұбын ортақ пайдаланатын басқа серверлер ғана шифрдан шығаруға болатындай шифрлауға мүмкіндік береді.

Артықшылық жұмыс істеуі үшін дерекқор кластерлері ең аз дегенде 3 серверден тұруы керек, бірақ 5-тен көп емес, кез келген кластер мүшелері арасындағы ең көп айналу уақыты 200 мс. Бұл шектеу Қоңыраулар көпірі кластерлеуіне қарағанда шектеуші болып табылады, сондықтан ол көбінесе географиялық түрде бөлінген орналастырулардағы шектеуші фактор болып табылады.

CMS үшін дерекқор рөлінің бірқатар бірегей талаптары бар. Басқа рөлдерден айырмашылығы, ол клиент пен сервер сертификатын талап етеді, мұнда клиент сертификатында серверге ұсынылған арнайы CN өрісі болады.

CMS бір негізгі және бірнеше толығымен бірдей көшірмелері бар postgres дерекқорын пайдаланады. Бір уақытта тек бір негізгі дерекқор бар («деректер базасының сервері»). Кластердің қалған мүшелері репликалар немесе «деректер базасының клиенттері» болып табылады.

Дерекқор кластері арнайы сервер сертификатын және клиент сертификатын қажет етеді. Оларға сертификаттар, әдетте ішкі жеке куәлік органы қол қоюы керек. Дерекқор кластерінің кез келген мүшесі басты бола алатындықтан, дерекқор сервері және клиент куәлігі жұптары (ашық және жеке кілттерді қамтитын) барлық серверлерге клиенттің немесе дерекқор серверінің сәйкестігін қабылдай алатындай етіп көшірілуі керек. Бұған қоса, клиент пен сервер сертификаттарын тексеруге болатынына көз жеткізу үшін CA түбірлік куәлігі жүктелуі керек.

Сонымен, біз дерекқордан басқа барлық сервер қызметтері пайдаланатын сертификатқа сұраныс жасаймыз (бұл үшін бөлек сұрау болады) келесідей пәрменмен:

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

CN-де біз серверлеріміздің жалпы атауын жазамыз. Мысалы, егер серверлеріміздің хост атаулары server01, server02, server03, содан кейін CN болады server.example.com

Біз қалған екі серверде де солай істейміз, айырмашылығы командаларда сәйкес «хост атаулары» болады.

Біз келесідей пәрмендермен дерекқор қызметі пайдаланатын сертификаттарға екі сұраныс жасаймыз:

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

pki csr dbclusterclient CN:postgres

қайда dbclusterserver и dbclusterclient біздің сұраныстарымыздың және болашақ сертификаттардың атаулары, хост аты1(2)(3) сәйкес серверлердің атаулары.

Біз бұл процедураны тек бір серверде (!) орындаймыз және біз сертификаттар мен сәйкес .key файлдарын басқа серверлерге жүктейміз.

AD CS жүйесінде клиент сертификаты режимін қосыңыз

Сондай-ақ әрбір сервер үшін сертификаттарды бір файлға біріктіру қажет.*NIX күні:

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

Windows/DOS жүйесінде:

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

Әр серверге жүктеп салу:
1. «Жеке» сервер сертификаты.
2. Түбірлік куәлік (бар болса, аралық куәліктермен бірге).
3. Дерекқорға («сервер» және «клиент») және «сервер» және «клиент» дерекқор сертификаттарына сұраныс жасау кезінде жасалған .key кеңейтімі бар файлдар үшін сертификаттар. Бұл файлдар барлық серверлерде бірдей болуы керек.
4. Барлық үш «жеке» куәліктің файлы.

Нәтижесінде әрбір серверде осы файл суреті сияқты нәрсені алу керек.

Мәліметтер базасының кластері

Енді сізде CMS серверлеріне жүктеп салынған барлық сертификаттар бар, сіз үш түйін арасында дерекқор кластерін теңшеуге және қосуға болады. Бірінші қадам дерекқор кластерінің негізгі түйіні ретінде бір серверді таңдау және оны толық конфигурациялау болып табылады.

Негізгі деректер қоры

Дерекқор репликациясын орнатудың бірінші қадамы дерекқор үшін пайдаланылатын сертификаттарды көрсету болып табылады. Бұл келесідей пәрмен арқылы орындалады:

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

Енді CMS пәрменімен дерекқорды кластерлеу үшін қандай интерфейсті пайдалану керектігін айтайық:

database cluster localnode a

Содан кейін негізгі сервердегі кластерлік дерекқорды пәрменмен инициализациялаймыз:

database cluster initialize

Клиент деректер қоры түйіндері

Біз бірдей процедураны орындаймыз, тек команданың орнына дерекқор кластерін инициализациялау сияқты пәрменді енгізіңіз:

database cluster join <ip address existing master>

мұндағы IP мекенжайы кластер инициализацияланған CMS серверінің бар басты IP мекенжайы, жай ғана Мастер.

Біздің дерекқор кластерінің барлық серверлерде қалай жұмыс істейтінін пәрмен арқылы тексереміз:

database cluster status

Қалған үшінші серверде де солай істейміз.

Нәтижесінде бірінші серверіміз Мастер, қалғандары құлдар болып шықты.

Веб әкімші қызметі

Веб-әкімші қызметін қосыңыз:

webadmin listen a 445

445 порт таңдалды, себебі 443 порты пайдаланушының веб-клиентке кіруі үшін пайдаланылады

Біз Web Admin қызметін сертификат файлдарымен келесідей пәрменмен конфигурациялаймыз:

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

Және Web Admin пәрменімен қосыңыз:

webadmin enable

Егер бәрі жақсы болса, веб-әкімші желі және сертификат үшін дұрыс конфигурацияланғанын көрсететін SUCCESS жолын аламыз. Біз веб-шолғыш арқылы қызметтің функционалдығын тексереміз және веб-әкімшінің мекенжайын енгіземіз, мысалы: cms.example.com: 445

Көпір кластеріне қоңырау шалыңыз

Call Bridge - әрбір CMS қолдануында бар жалғыз қызмет. Call Bridge негізгі конференция механизмі болып табылады. Сондай-ақ ол, мысалы, Cisco Unified CM арқылы қоңырауларды оған немесе одан бағыттауға болатын SIP интерфейсін қамтамасыз етеді.

Төменде сипатталған пәрмендер сәйкес сертификаттары бар әрбір серверде орындалуы керек.
Мәселен:

Біз сертификаттарды Call Bridge қызметімен келесідей пәрменмен байланыстырамыз:

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

Біз CallBridge қызметтерін пәрмен арқылы қажетті интерфейске байланыстырамыз:

callbridge listen a

Және қызметті келесі пәрменмен қайта іске қосыңыз:

callbridge restart

Енді бізде қоңырау шалу көпірлері конфигурацияланған, біз Call Bridge кластерлеуін конфигурациялай аламыз. Қоңыраулар көпірі кластерленуі дерекқор немесе XMPP кластерлеуінен ерекшеленеді. Call Bridge Cluster 2-ден 8 түйінге дейін шектеусіз қолдау көрсете алады. Ол артықшылықты ғана емес, сонымен қатар конференцияларды интеллектуалды қоңырауларды тарату арқылы Call Bridge серверлері бойынша белсенді түрде таратуға болатын жүктемені теңестіруді қамтамасыз етеді. CMS қосымша мүмкіндіктері, Call Bridge топтары және одан әрі басқару үшін пайдалануға болатын қатысты мүмкіндіктерге ие.

Қоңыраулар көпірін кластерлеу негізінен веб-әкімші интерфейсі арқылы конфигурацияланады
Төменде сипатталған процедура кластердегі әрбір серверде орындалуы керек.
Осылайша,

1. Интернет арқылы Конфигурация > Кластер тармағына өтіңіз.
2. В Bridge идентификациясына қоңырау шалыңыз Бірегей атау ретінде сервер атына сәйкес callbridge[01,02,03] енгізіңіз. Бұл атаулар ерікті, бірақ осы кластер үшін бірегей болуы керек. Олар сипаттамалық сипатта болады, өйткені олар сервер идентификаторлары екенін көрсетеді [01,02,03].
3.V Кластерленген қоңырау көпірлері кластерге серверлеріміздің веб-әкімші URL мекенжайларын енгізіңіз, м.ғ.к.[01,02,03].example.com:445, Мекенжай өрісінде. Портты көрсетуді ұмытпаңыз. Peer link SIP доменін бос қалдыра аласыз.
4. Әрбір сервердің CallBridge сеніміне сертификатты қосыңыз, оның файлында серверлеріміздің барлық сертификаттары бар, біз оны ең басында осы файлға біріктіріп, келесі пәрменмен:

callbridge trust cluster <trusted cluster certificate bundle>

Және қызметті келесі пәрменмен қайта іске қосыңыз:

callbridge restart

Нәтижесінде әрбір серверде мына суретті алу керек:

XMPP кластері

CMS ішіндегі XMPP қызметі CMA WebRTC веб-клиентін қоса алғанда, Cisco Meeting Apps (CMA) үшін барлық тіркеуді және аутентификацияны өңдеу үшін пайдаланылады. Қоңырау көпірінің өзі де аутентификация мақсатында XMPP клиенті ретінде әрекет етеді, сондықтан басқа клиенттер сияқты конфигурациялануы керек. XMPP қатеге төзімділігі - 2.1 нұсқасынан бастап өндіріс орталарында қолдау көрсетілетін мүмкіндік

Төменде сипатталған пәрмендер сәйкес сертификаттары бар әрбір серверде орындалуы керек.
Мәселен:

Біз сертификаттарды XMPP қызметімен келесі пәрменмен байланыстырамыз:

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

Содан кейін пәрмен арқылы тыңдау интерфейсін анықтаңыз:

xmpp listen a

XMPP қызметі бірегей доменді қажет етеді. Бұл пайдаланушылар үшін логин. Басқаша айтқанда, пайдаланушы CMA қолданбасы арқылы (немесе WebRTC клиенті арқылы) кіруге әрекеттенгенде, ол userID@logindomain енгізеді. Біздің жағдайда ол userid@ боладыконференция.example.com. Неліктен бұл жай example.com емес? Біздің арнайы орналастыруымызда Jabber пайдаланушылары Unified CM жүйесінде example.com ретінде пайдаланатын Unified CM доменін таңдадық, сондықтан CMS пайдаланушыларына SIP домендері арқылы CMS-ке және одан қоңырауларды бағыттау үшін басқа домен қажет болды.

XMPP доменін келесідей пәрмен арқылы орнатыңыз:

xmpp domain <domain>

XMPP қызметін келесі пәрменмен қосыңыз:

xmpp enable

XMPP қызметінде XMPP қызметіне тіркелу кезінде пайдаланылатын әрбір қоңырау көпірі үшін тіркелгі деректерін жасау керек. Бұл атаулар ерікті (және қоңырау көпірін кластерлеу үшін теңшелген бірегей атауларға қатысты емес). Бір XMPP серверіне үш қоңырау көпірін қосып, содан кейін бұл тіркелгі деректерін кластердегі басқа XMPP серверлеріне енгізу керек, себебі бұл конфигурация кластер дерекқорына сәйкес келмейді. Кейінірек біз әрбір қоңырау көпірін XMPP қызметіне тіркелу үшін осы атауды және құпияны пайдалану үшін конфигурациялаймыз.

Енді XMPP қызметін бірінші серверде үш Call Bridges callbridge01, callbridge02 және callbridge03 арқылы конфигурациялау керек. Әрбір тіркелгіге кездейсоқ құпия сөздер тағайындалады. Олар кейінірек осы XMPP серверіне кіру үшін басқа Call Bridge серверлеріне енгізіледі. Келесі пәрмендерді енгізіңіз:

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

Нәтижесінде біз пәрменмен не болғанын тексереміз:

xmpp callbridge list

Дәл сол сурет төменде сипатталған қадамдардан кейін қалған серверлерде пайда болуы керек.

Әрі қарай, біз қалған екі серверде дәл сол параметрлерді тек пәрмендермен қосамыз

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

Біз құпияны өте мұқият қосамыз, мысалы, онда қосымша бос орындар жоқ.


Нәтижесінде әрбір серверде бірдей сурет болуы керек:

Әрі қарай, кластердегі барлық серверлерде біз келесі пәрменмен бұрын жасалған барлық үш сертификатты қамтитын файлды сенімді түрде көрсетеміз:

xmpp cluster trust <trust bundle>

Біз барлық кластер серверлерінде xmpp кластер режимін келесі пәрменмен қосамыз:

xmpp cluster enable

Кластердің бірінші серверінде біз келесі пәрменмен xmpp кластерін құруды бастаймыз:

xmpp cluster initialize

Басқа серверлерде келесі пәрменмен xmpp-ге кластерді қосыңыз:

xmpp cluster join <ip address head xmpp server>

Әрбір серверде әрбір серверде XMPP кластерін жасаудың сәттілігін пәрмендер арқылы тексереміз:

xmpp status
xmpp cluster status

Бірінші сервер:

Екінші сервер:

Үшінші сервер:

Call Bridge XMPP-ге қосылуда

Енді XMPP кластері іске қосылғаннан кейін XMPP кластеріне қосылу үшін Call Bridge қызметтерін конфигурациялау қажет. Бұл конфигурация веб-әкімші арқылы жасалады.

Әрбір серверде Конфигурация > Жалпы тармағына және өріске өтіңіз Бірегей Call Bridge атауы Call Bridge серверіне сәйкес бірегей атауларды жазыңыз callbridge[01,02,03]... Алаңда Домен conf.example.ru және сәйкес құпия сөздерді тыңдай аласыз
кластердегі кез келген серверде пәрменмен:

xmpp callbridge list

«Сервер» өрісін бос қалдырыңыз Callbridge үшін DNS SRV іздеуін орындайды _xmpp-component._tcp.conf.example.comқол жетімді XMPP серверін табу үшін. Шақыру көпірлерін XMPP-ге қосуға арналған IP мекенжайлары әр серверде әр түрлі болуы мүмкін, бұл жазба сұрауына қандай мәндер қайтарылатынына байланысты. _xmpp-component._tcp.conf.example.com callbridge, бұл өз кезегінде берілген DNS жазбасының басымдылық параметрлеріне байланысты.

Әрі қарай, Қалыңдықты шақыру қызметінің XMPP қызметіне сәтті қосылғанын тексеру үшін Күй > Жалпы тармағына өтіңіз.

Веб көпір

Кластердегі әрбір серверде Web Bridge қызметін пәрменмен қосыңыз:

webbridge listen a:443

Біз Web Bridge қызметін сертификат файлдарымен келесідей пәрменмен конфигурациялаймыз:

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

Web Bridge HTTPS протоколын қолдайды. Ол "http-қайта бағыттауды" пайдалану үшін конфигурацияланса, HTTP протоколын HTTPS серверіне қайта бағыттайды.
HTTP қайта бағыттауды қосу үшін келесі пәрменді пайдаланыңыз:

webbridge http-redirect enable

Call Bridge қолданбасына Web Bridge Call Bridge қосылымдарына сене алатынын білу үшін келесі пәрменді пайдаланыңыз:

webbridge trust <certfile>

мұнда бұл кластердегі әрбір сервердің барлық үш сертификатын қамтитын файл.

Бұл сурет кластердегі әрбір серверде болуы керек.


Теперь нам нужно создать пользователя с ролью «appadmin», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут бір рет.


Әрі қарай орнату үшін біз қолданамыз почташы.

Авторизациялау үшін Авторизация бөлімінде Негізгі опциясын таңдаңыз

Командаларды CMS серверіне дұрыс жіберу үшін қажетті кодтауды орнату қажет

Webbridge пәрменімен белгілейміз POST параметрімен URL және мағынасы cms.example.com



Веб-көпірдің өзінде біз қажетті параметрлерді көрсетеміз: қонақтарға кіру, қорғалған кіру және т.б.

Bridge топтарына қоңырау шалыңыз

Әдепкі бойынша, CMS әрқашан оған қолжетімді конференция ресурстарын барынша тиімді пайдалана бермейді.

Мысалы, үш қатысушымен кездесу үшін әрбір қатысушы үш түрлі қоңырау көпірінде аяқталуы мүмкін. Осы үш қатысушының бір-бірімен байланысуы үшін Call Bridges бір кеңістіктегі барлық серверлер мен клиенттер арасында автоматты түрде байланыс орнатады, осылайша барлығы барлық клиенттер бір серверде сияқты көрінеді. Өкінішке орай, мұның кемшілігі - бір 3 адамдық конференция енді 9 медиа портты тұтынады. Бұл ресурстарды тиімсіз пайдалану екені анық. Сонымен қатар, қоңырау шалу көпірі шынымен шамадан тыс жүктелген кезде, әдепкі механизм қоңырауларды қабылдауды жалғастыру және осы қоңырау көпірінің барлық абоненттеріне төмен сапалы қызмет көрсету болып табылады.

Бұл мәселелер Call Bridge Group мүмкіндігі арқылы шешіледі. Бұл мүмкіндік Cisco Meeting Server бағдарламалық құралының 2.1 нұсқасында енгізілген және кіріс және шығыс Cisco Meeting App (CMA) қоңыраулары, соның ішінде WebRTC қатысушылары үшін жүктемені теңестіруді қолдау үшін кеңейтілген.

Қайта қосу мәселесін шешу үшін әрбір қоңырау көпірі үшін конфигурацияланатын үш жүктеме шегі енгізілген:

Жүктеме шегі — бұл белгілі бір Call Bridge үшін максималды сандық жүктеме. Әрбір платформада ұсынылған жүктеме шегі бар, мысалы, CMS96000 үшін 1000 және виртуалды машина үшін vCPU үшін 1.25 ГГц. Әртүрлі қоңыраулар қатысушының рұқсаты мен кадр жиілігіне байланысты ресурстардың белгілі бір мөлшерін тұтынады.
NewConferenceLoadLimitBasisPoints (әдепкі 50% loadLimit) - серверді жүктеу шегін орнатады, содан кейін жаңа конференциялар қабылданбайды.
ExistingConferenceLoadLimitBasisPoints (әдепкі loadLimit 80%) - серверді жүктеу мәні, содан кейін бар конференцияға қосылатын қатысушылар қабылданбайды.

Бұл мүмкіндік қоңырауды тарату және жүктемені теңестіру үшін жасалған болса да, TURN серверлері, веб-көпір серверлері және рекордерлер сияқты басқа топтар да оңтайлы пайдалану үшін дұрыс топтастырылуы үшін Қоңырау көпірі топтарына тағайындалуы мүмкін. Егер осы нысандардың кез келгені қоңыраулар тобына тағайындалмаса, олар барлық серверлер үшін қандай да бір ерекше басымдықсыз қол жетімді деп есептеледі.

Бұл параметрлер осы жерде конфигурацияланады: cms.example.com:445/api/v1/жүйе/конфигурация/кластер

Әрі қарай, біз әрбір қоңырау шалу көпірінің қай callbridge тобына жататынын көрсетеміз:

Бірінші қоңырау шалу

Екінші қоңырау шалу

Үшінші көпір


Осылайша, Call Bdige тобын Cisco Meeting Server кластерінің ресурстарын тиімдірек пайдалану үшін конфигурацияладық.

Пайдаланушыларды Active Directory ішінен импорттау

Web Admin қызметінде LDAP конфигурация бөлімі бар, бірақ ол күрделі конфигурация опцияларын қамтамасыз етпейді және ақпарат кластер дерекқорында сақталмайды, сондықтан конфигурацияны веб-интерфейс арқылы әрбір серверде қолмен немесе API, және біз «үш рет «тұрмау» үшін біз әлі де API арқылы деректерді орнатамыз.

Қол жеткізу үшін URL мекенжайын пайдалану cms01.example.com:445/api/v1/ldapServers келесі параметрлерді көрсете отырып, LDAP серверінің нысанын жасайды:

• Сервер IP
• порт нөмірі
• Қолданушының аты
• пароль
• қауіпсіз

Secure - портқа байланысты шын немесе жалғанды ​​таңдаңыз, 389 - қауіпсіз емес, 636 - қорғалған.


LDAP бастапқы параметрлерін Cisco жиналыс серверіндегі төлсипаттарға салыстыру.
LDAP салыстыру LDAP каталогындағы төлсипаттарды CMS жүйесіндегі төлсипаттармен салыстырады. Нақты атрибуттар:

• jidMapping
• атауды салыстыру
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Атрибуттардың сипаттамасыJID CMS жүйесінде пайдаланушының кіру идентификаторын көрсетеді. Бұл Microsoft Active Directory LDAP сервері болғандықтан, CMS JID LDAP ішіндегі sAMAccountName картасымен салыстырылады, ол негізінен пайдаланушының Active Directory кіру идентификаторы болып табылады. Сондай-ақ sAMAccountName алып, оның соңына conf.pod6.cms.lab доменін қосатыныңызды ескеріңіз, себебі бұл сіздің пайдаланушыларыңыз CMS жүйесіне кіру үшін пайдаланатын логин.

атауды салыстыру Active Directory displayName өрісіндегі мазмұнды пайдаланушының CMS атауы өрісіне сәйкестендіреді.

coSpaceNameMapping displayName өрісіне негізделген CMS кеңістігі атауын жасайды. Бұл төлсипат coSpaceUriMapping төлсипатымен бірге әрбір пайдаланушы үшін кеңістік жасау үшін қажет.

coSpaceUriMapping пайдаланушының жеке кеңістігімен байланысты URI пайдаланушы бөлігін анықтайды. Кейбір домендерді кеңістікке теру үшін конфигурациялауға болады. Пайдаланушы бөлігі осы домендердің біреуі үшін осы өріске сәйкес келсе, қоңырау сол пайдаланушының кеңістігіне бағытталады.

coSpaceSecondaryUriMapping кеңістікке жету үшін екінші URI анықтайды. Бұл coSpaceUriMapping параметрінде анықталған әріптік-сандық URI-ге балама ретінде импортталған пайдаланушының кеңістігіне қоңырауларды бағыттау үшін сандық бүркеншік атын қосу үшін пайдаланылуы мүмкін.

LDAP сервері және LDAP салыстыру конфигурацияланған. Енді LDAP көзін жасау арқылы оларды біріктіру керек.

Қол жеткізу үшін URL мекенжайын пайдалану cms01.example.com:445/api/v1/ldapSource келесідей параметрлерді көрсете отырып, LDAP Source нысанын жасайды:

• сервер
• картаға
• baseDn
• фильтр

Енді LDAP конфигурациясы аяқталғаннан кейін қолмен синхрондау әрекетін орындауға болады.

Біз мұны әр сервердің веб-интерфейсінде басу арқылы жасаймыз Қазір синхрондаңыз бөлім Active Directory


немесе пәрменмен API арқылы POST кіру үшін URL мекенжайын пайдалану cms01.example.com:445/api/v1/ldapSyncs

Арнайы конференциялар

Бұл не?Дәстүрлі концепцияда конференция екі қатысушының бір-бірімен сөйлесуі және қатысушылардың бірі (Uified CM-де тіркелген құрылғыны пайдалану арқылы) «Конференция» түймесін басып, басқа адамға қоңырау шалып, сол үшінші тараппен сөйлескеннен кейін болады. , үшжақты конференцияның барлық қатысушыларына қосылу үшін «Конференция» түймесін қайтадан басыңыз.

Арнайы конференцияның CMS жүйесіндегі жоспарланған конференциядан айырмашылығы мынада: Ad-Hoc конференциясы CMS-ге SIP қоңырауы ғана емес. Конференцияны бастаушы барлығын бір жиналысқа шақыру үшін Конференция түймесін екінші рет басқанда, Бірыңғай CM барлық қоңыраулар тасымалданатын жедел конференцияны жасау үшін CMS жүйесіне API қоңырауын жасауы керек. Мұның бәрі қатысушылардың назарынсыз өтеді.

Бұл қоңырауды жалғастыру үшін Unified CM API тіркелгі деректерін және WebAdmin мекенжайын/қызмет портын, сондай-ақ SIP магистралін тікелей CMS серверіне конфигурациялауы керек дегенді білдіреді.

Қажет болса, CUCM динамикалық түрде CMS жүйесінде бос орынды жасай алады, осылайша әрбір қоңырау CMS жүйесіне жетеді және бос орындарға арналған кіріс қоңырау ережесіне сәйкес келеді.

CUCM-мен интеграция мақалада сипатталғандай конфигурацияланған бұрын Cisco UCM жүйесінде сіз CMS үшін үш магистраль, үш конференция көпірін жасауыңыз керек, SIP қауіпсіздік профилінде үш тақырып атын, маршрут топтарын, маршрут тізімдерін, медиа ресурстар топтарын және медиа ресурстар тобының тізімдерін көрсетіңіз және бірнеше маршруттау ережелерін қосыңыз. Cisco жиналыс серверіне.

SIP қауіпсіздік профилі:


Сандықтар:


Әрбір діңгек бірдей көрінеді:




Конференция көпірі


Әрбір конференция көпірі бірдей көрінеді:


Маршрут тобы


Маршруттар тізімі


Медиа ресурстар тобы


Медиа ресурстар тобының тізімі

Қоңырау ережелері

Unified CM немесе Expressway сияқты кеңейтілген қоңырауларды басқару жүйелерінен айырмашылығы, CMS жаңа қоңыраулар үшін SIP сұрауы-URI өрісінде доменді ғана іздейді. Сонымен, SIP INVITE ішуге арналған болса: [электрондық пошта қорғалған]CMS тек domain.com туралы ойлайды. CMS қоңырауды қайда бағыттау керектігін анықтау үшін мына ережелерді сақтайды:

1. CMS алдымен SIP доменін кіріс қоңырау ережелерінде конфигурацияланған домендермен сәйкестендіруге тырысады. Содан кейін бұл қоңырауларды («мақсатты») кеңістіктерге немесе белгілі бір пайдаланушыларға, ішкі IVR құрылғыларына немесе тікелей біріктірілген Microsoft Lync/Skype for Business (S4B) тағайындауларына бағыттауға болады.
2. Егер кіріс қоңырау ережелерінде сәйкестік болмаса, CMS қоңырауды қайта бағыттау кестесінде конфигурацияланған доменге сәйкес келуге тырысады. Сәйкестік жасалса, ереже қоңырауды ашық түрде қабылдамауы немесе қоңырауды қайта бағыттауы мүмкін. Осы уақытта CMS доменді қайта жазуы мүмкін, бұл кейде Lync домендерін шақыру үшін пайдалы. Сондай-ақ, жіберуді таңдауға болады, яғни өрістердің ешқайсысы одан әрі өзгертілмейді немесе ішкі CMS теру жоспарын пайдаланыңыз. Қоңырауды қайта бағыттау ережелерінде сәйкестік болмаса, әдепкі бойынша қоңырауды қабылдамау керек. Есіңізде болсын, CMS-те қоңырау «қайта жіберілген» болса да, медиа әлі де CMS-ге байланысты, яғни ол сигнал беру және медиа-трафик жолында болады.
Содан кейін тек қайта жіберілген қоңыраулар шығыс қоңырау ережелеріне бағынады. Бұл параметрлер қоңыраулар жіберілетін орындарды, магистральдық түрін (жаңа Lync қоңырауы немесе стандартты SIP қоңырауы болсын) және қоңырауды қайта бағыттау ережесінде тасымалдау таңдалмаған жағдайда орындалуы мүмкін кез келген түрлендірулерді анықтайды.

Мұнда арнайы конференция кезінде не болып жатқанының нақты журналы берілген

Скриншот оны нашар көрсетеді (мен оны қалай жақсарту керектігін білмеймін), сондықтан журналды келесідей жазамын:

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

Арнайы конференцияның өзі:


Кіріс қоңырауларының ережелері
Кіріс қоңырауларының параметрлерін конфигурациялау CMS жүйесінде қоңырауды қабылдау мүмкіндігін алу үшін қажет. LDAP орнатуында көргеніңіздей, барлық пайдаланушылар conf.pod6.cms.lab доменімен импортталған. Сондықтан, кем дегенде, бос орындарға осы доменге қоңырау шалғыңыз келеді. Сондай-ақ, CMS серверлерінің әрқайсысының толық домендік атауына (және тіпті IP мекенжайына да) арналған барлық ережелерді орнату қажет болады. Біздің сыртқы қоңырауды басқару құралы, Unified CM, CMS серверлерінің әрқайсысына арналған SIP транзакцияларын жеке конфигурациялайды. Осы SIP транзакцияларының тағайындалған жері IP мекенжайы немесе сервердің FQDN екеніне байланысты CMS оның IP мекенжайына немесе FQDN-ге бағытталған қоңырауларды қабылдау үшін конфигурациялану қажеттігін анықтайды.

Ең жоғары басым кіріс ережесі бар домен кез келген пайдаланушы кеңістіктері үшін домен ретінде пайдаланылады. Пайдаланушылар LDAP арқылы синхрондағанда, CMS автоматты түрде бос орындар жасайды, бірақ тек URI (coSpaceUriMapping) пайдаланушы бөлігі, мысалы, user.space. Бөлім домен Толық URI осы ереже негізінде жасалады. Шындығында, егер сіз осы сәтте Web Bridge жүйесіне кіретін болсаңыз, Space URI-де домен жоқ екенін көресіз. Бұл ережені ең жоғары басымдық ретінде орнату арқылы сіз жасалған бос орындар үшін доменді орнатасыз конф.example.com.


Шығыс қоңырау ережелері

Пайдаланушыларға Unified CM кластеріне шығыс қоңыраулар жасауға рұқсат беру үшін шығыс ережелерін конфигурациялау керек. Jabber сияқты Unified CM жүйесінде тіркелген соңғы нүктелердің домені example.com болып табылады. Бұл доменге қоңыраулар стандартты SIP қоңыраулары ретінде Unified CM қоңырауды өңдеу түйіндеріне бағытталуы керек. Негізгі сервер cucm-01.example.com, ал қосымша сервер cucm-02.example.com.

Бірінші ереже кластерлік серверлер арасындағы қоңыраулардың ең қарапайым маршруттауын сипаттайды.

өріс Доменнен жергілікті «@» белгісінен кейін қоңырау шалушы үшін қоңырау шалушының SIP-URI-де не көрсетілетініне жауап береді. Егер біз оны бос қалдырсақ, онда «@» белгісінен кейін бұл қоңырау өтетін CUCM IP мекенжайы болады. Егер доменді көрсетсек, онда «@» белгісінен кейін іс жүзінде домен болады. Бұл кері қоңырау шалу үшін қажет, әйтпесе SIP-URI name@ip-address арқылы кері қоңырау шалу мүмкін болмайды.

Белгіленген кезде қоңырау шалыңыз Доменнен жергілікті


Қашан қоңырау шалыңыз ЕМЕС көрсетілген Доменнен жергілікті


Шығыс қоңыраулар үшін «Шифрланған» немесе «Шифрланбаған» параметрін нақты көрсетуді ұмытпаңыз, себебі «Авто» параметрімен ештеңе жұмыс істемейді.

жазба

Бейне конференциялар Жазба серверімен жазылады. Диктофон Cisco жиналыс серверімен бірдей. Диктофон ешқандай лицензияларды орнатуды қажет етпейді. Жазу лицензиялары CallBridge қызметтерін іске қосатын серверлер үшін қажет, яғни. Жазу лицензиясы қажет және Recorder іске қосылған серверге емес, CallBridge компонентіне қолданылуы керек. Диктофон өзін кеңейтілетін хабар алмасу және қатысу протоколы (XMPP) клиенті ретінде әрекет етеді, сондықтан XMPP сервері CallBridge хостинг серверінде қосылуы керек.

Өйткені Бізде кластер бар және лицензия кластердегі барлық үш серверде «созылуы» керек. Содан кейін лицензиялардағы жеке тіркелгіңізде біз кластерге кіретін барлық CMS серверлерінің a-интерфейстерінің MAC мекенжайларын байланыстырамыз (қосамыз).

Бұл кластердегі әрбір серверде болуы керек сурет

Жалпы, Диктофонды орналастырудың бірнеше сценарийі бар, бірақ біз мынаны ұстанамыз:


Диктофонды орнатпас бұрын бейнеконференциялар шынымен жазылатын орынды дайындау керек. Шын мәнінде осында байланыс, барлық Жазуды орнату жолы. Мен маңызды сәттерге және мәліметтерге назар аударамын:

1. Куәлікті кластердегі бірінші серверден алған дұрыс.
2. «Диктофон қолжетімсіз» қатесі Recorder Trust жүйесінде қате сертификат көрсетілгендіктен орын алуы мүмкін.
3. Жазу үшін көрсетілген NFS каталогы түбірлік каталог болмаса, жазу жұмыс істемеуі мүмкін.

Кейде белгілі бір пайдаланушының немесе кеңістіктің конференциясын автоматты түрде жазу қажеттілігі туындайды.

Ол үшін екі CallProfiles жасалады:
Жазу өшірілген


Және автоматты жазу функциясымен


Әрі қарай, біз қалаған кеңістікке автоматты жазу функциясы бар CallProfile «тіркеміз».


CMS жүйесінде CallProfile кез келген кеңістікке немесе кеңістікке анық байланыстырылған болса, бұл CallProfile тек осы нақты кеңістіктерге қатысты жұмыс істейтіні соншалықты бекітілген. Ал егер CallProfile ешбір кеңістікке байланыстырылмаса, әдепкі бойынша ол ешқандай CallProfile нақты байланыспаған кеңістіктерге қолданылады.

Келесі жолы мен CMS-ке ұйымның ішкі желісінен тыс кіру жолын сипаттауға тырысамын.

Көздер:

• 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-және кейінірек. pdf

Ақпарат көзі: www.habr.com