Бул чыгарылышта мен CMS серверин өчүрүү кластер режиминде орнотуунун кээ бир татаалдыктарын көрсөтөм жана түшүндүрөм.
теорияЖалпысынан алганда, CMS серверин жайылтуунун үч түрү бар:
- Бирдиктүү(Бирдиктүү бириктирилген), б.а. бул бардык керектүү кызматтар иштеп жаткан бир сервер. Көпчүлүк учурларда, жайгаштыруунун бул түрү кардарлардын ички мүмкүнчүлүгү үчүн гана ылайыктуу жана бир сервердин масштабдуулугу жана ашыкча чектөөлөрү олуттуу маселе болбогон чакан чөйрөлөрдө же CMS белгилүү бир функцияларды гана аткарган кырдаалдарда, мисалы, ad hoc Cisco UCM боюнча конференциялар.
Иштин болжолдуу схемасы:
- Single Split(Single Split) тышкы кирүү үчүн өзүнчө серверди кошуу менен мурунку жайылтуу түрүн кеңейтет. Мурунку жайгаштырууларда бул тышкы кардарлар ага кире ала турган демилитаризацияланган тармак сегментинде (DMZ) жана ички кардарлар CMSге кире алган тармактын өзөгүндө бир CMS серверин жайгаштырууну билдирген. Бул өзгөчө жайылтуу модели азыр деп аталган түрү менен алмаштырылат Single Edgeсерверлерден турат Cisco Expressway, аларда бир эле Firewall айланып өтүү мүмкүнчүлүктөрүнүн көбү бар же ээ болот, андыктан кардарларга атайын CMS серверин кошуунун кереги жок.
Иштин болжолдуу схемасы:
- Масштабдуу жана ийкемдүү(Масштабдалуучу жана катачылыкка чыдамдуу) Бул түр ар бир компонент үчүн резервдикти камтыйт, бул система сиздин муктаждыктарыңыз менен максималдуу кубаттуулукка чейин өсүүгө мүмкүндүк берет, ал эми иштен чыккан учурда ашыкчаны камсыз кылат. Ал ошондой эле коопсуз тышкы кирүүнү камсыз кылуу үчүн Single Edge концепциясын колдонот. Бул биз бул эпизоддо карап турган түрү болуп саналат. Эгерде биз кластердин бул түрүн кантип жайгаштырууну түшүнсөк, биз жайгаштыруулардын башка түрлөрүн гана түшүнбөстөн, суроо-талаптын потенциалдуу өсүшүн канааттандыруу үчүн CMS серверлеринин кластерлерин кантип түзүүнү да түшүнө алабыз.
жайылтууга өтүүдөн мурун, кээ бир негизги нерселерди түшүнүү керек, атап айтканда
Негизги CMS программалык компоненттери:
- маалыматтар базасы: Терүү планы, колдонуучу мейкиндиктери жана колдонуучулардын өздөрү сыяктуу кээ бир конфигурацияларды бириктирүүгө мүмкүндүк берет. Жогорку жеткиликтүүлүк үчүн кластерлөөнү колдойт (бир мастер) гана.
- Call Bridge: чалууларды жана мультимедиялык процесстерди башкарууну жана иштетүүнү толук көзөмөлдөөнү камсыз кылган аудио жана видеоконференциялар кызматы. Жогорку жеткиликтүүлүк жана масштабдуулук үчүн кластерлөөнү колдойт.
- XMPP сервери: Cisco Meeting Колдонмосун жана/же WebRTC(реалдуу убакыт байланыш, же жөн гана браузерде), ошондой эле компоненттер аралык сигнализация. Жогорку жеткиликтүүлүк үчүн гана кластердик болушу мүмкүн.
- Web Bridge: Кардарларга WebRTC мүмкүнчүлүгүн берет.
- Loadbalancer: Single Split режиминде Cisco Meeting Apps үчүн бирдиктүү туташуу чекити менен камсыз кылат. Кирүүчү байланыштар үчүн тышкы интерфейсти жана портту угат. Ошо сыяктуу эле, жүк баланстоочу XMPP серверинен келген TLS туташууларын кабыл алат, ал аркылуу тышкы кардарлардан TCP байланыштарын которуштурууга болот.
Биздин сценарийде бул кереги жок болот. - TURN сервер: мүмкүндүк берет Firewall айланып технологиясы менен камсыз кылат
Cisco Meeting App же SIP түзмөктөрү аркылуу тышкы кардарларды туташтыруу үчүн биздин CMSти Firewall же NAT артына коюңуз. Биздин сценарийде бул кереги жок болот. - Web Admin: Административдик интерфейс жана API мүмкүнчүлүгү, анын ичинде атайын Unified CM конференциялары үчүн.
Конфигурация режимдери
Башка Cisco өнүмдөрүнөн айырмаланып, Cisco Meeting Server жайгаштыруунун каалаган түрүн жайгаштыруу үчүн үч конфигурация ыкмасын колдойт.
- Буйрук сабы (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 жана эки домен бар экенин эске алыңыз Conf.example.com. Example.com - бул бардык Cisco Unified Communication Manager абоненттери өздөрүнүн URI'лери үчүн колдоно ала турган домен, бул сиздин инфраструктураңызда бар же болушу ыктымал. Же example.com колдонуучулар электрондук почта даректери үчүн колдонгон доменге дал келет. Же ноутбукуңуздагы Jabber кардарында URI болушу мүмкүн [электрондук почта корголгон]. домен Conf.example.com - Cisco Meeting Server колдонуучулары үчүн конфигурациялана турган домен. Cisco жолугушуу серверинин домени болот Conf.example.com, ошондуктан ошол эле Jabber колдонуучусу үчүн user@ URI Cisco жолугушуу серверине кирүү үчүн колдонулушу керекConf.example.com.
Негизги конфигурация
Төмөндө сүрөттөлгөн бардык орнотуулар бир серверде көрсөтүлгөн, бирок алар кластердеги ар бир серверде аткарылышы керек.
QoS
CMS жараткандан бери чыныгы убакыт кечиктирүүлөргө жана пакет жоготууларга сезгич трафик, көпчүлүк учурларда тейлөө сапатын (QoS) конфигурациялоо сунушталат. Буга жетүү үчүн, CMS өзү түзгөн Дифференциацияланган Кызмат Коддору (DSCPs) менен пакеттерди белгилөөнү колдойт. 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
Network Time Protocol (NTP) чалуулардын жана конференциялардын так убакыт белгилерин берүү үчүн гана эмес, сертификаттарды текшерүү үчүн да маанилүү.
сыяктуу буйрук менен инфраструктураңызга NTP серверлерин кошуңуз
ntp server add <server>
Биздин учурда мындай эки сервер бар, ошондуктан эки команда болот.
текшерүү:
Жана серверибиз үчүн убакыт алкагын орнотуңуз
DNS
Биз DNS серверлерин CMSге төмөнкүдөй буйрук менен кошобуз:
dns add forwardzone <domain-name> <server ip>
Биздин учурда мындай эки сервер бар, ошондуктан эки команда болот.
текшерүү:
Network Interface Configuration
Биз интерфейсти төмөнкүдөй буйрук менен конфигурациялайбыз:
ipv4 <interface> add <address>/<prefix length> <gateway>
текшерүү:
Сервердин аты (Хост аты)
Биз сервердин атын төмөнкүдөй буйрук менен орнотобуз:
hostname <name>
Жана биз кайра жүктөйбүз.
Бул негизги конфигурацияны аяктайт.
Тастыктамалар
теорияCisco Meeting Server ар кандай компоненттердин ортосундагы шифрленген байланышты талап кылат жана натыйжада, бардык CMS жайылтуулары үчүн X.509 сертификаттары талап кылынат. Алар кызматтарга/серверге башка серверлер/кызматтар тарабынан ишенүүгө жардам берет.
Ар бир кызмат сертификатты талап кылат, бирок ар бир кызмат үчүн өзүнчө сертификаттарды түзүү башаламандыкка жана ашыкча татаалдыкка алып келиши мүмкүн. Бактыга жараша, биз сертификаттын ачык-жеке ачкыч жуптарын түзүп, анан аларды бир нече кызматтарда кайра колдоно алабыз. Биздин учурда, ошол эле сертификат Call Bridge, XMPP Server, Web Bridge жана Web Admin үчүн колдонулат. Ошентип, сиз кластердеги ар бир сервер үчүн ачык жана купуя сертификат ачкычтарын түзүшүңүз керек.
Берилиштер базасын кластерлөө, бирок, кээ бир атайын сертификат талаптары бар жана ошондуктан башка кызматтардан айырмаланган өзүнүн сертификаттарын талап кылат. CMS сервер сертификатын колдонот, ал башка серверлер колдонгон сертификаттарга окшош, бирок маалымат базасын туташтыруу үчүн колдонулган кардар сертификаты да бар. Берилиштер базасынын сертификаттары аутентификация жана шифрлөө үчүн колдонулат. Кардар маалымат базасына туташуу үчүн колдонуучу атын жана паролду берүүнүн ордуна, сервер ишенген кардардын сертификатын берет. Берилиштер базасы кластериндеги ар бир сервер бирдей жалпы жана купуя ачкыч жуптарын колдонот. Бул кластердеги бардык серверлерге маалыматтарды бир эле ачкыч жуптарын бөлүшкөн башка серверлер гана чече ала тургандай шифрлөө мүмкүнчүлүгүн берет.
Артыкчылык иштеши үчүн, маалымат базасы кластерлери эң аз дегенде 3 серверден турушу керек, бирок 5тен ашпоого тийиш, кластердин каалаган мүчөлөрүнүн ортосунда максималдуу айланып өтүү убактысы 200 мс. Бул чек Call Bridge кластерлерине караганда көбүрөөк чектейт, ошондуктан географиялык жактан бөлүштүрүлгөн жайгаштырууларда көбүнчө чектөөчү фактор болуп саналат.
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де биз серверлерибиздин жалпы атын жазабыз. Мисалы, эгерде биздин серверлердин хост аттары сервер01, сервер02, сервер03, анда 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.cerWindows/DOS боюнча:
copy server01.cer + server02.cer + server03.cer server.cer
Жана ар бир серверге жүктөө:
1. "Жеке" сервердин сертификаты.
2. Түпкү күбөлүк (бар болсо, ортодогулар менен бирге).
3. Маалыматтар базасына сертификаттар («сервер» жана «кардар») жана .key кеңейтүүсү бар файлдар, алар «сервер» жана «кардар» маалыматтар базасынын сертификаттарына суроо-талапты түзүүдө түзүлгөн. Бул файлдар бардык серверлерде бирдей болушу керек.
4. Бардык үч "жеке" күбөлүктүн файлы.
Натыйжада, сиз ар бир серверде ушул файл сүрөтүнө окшош нерсени алышыңыз керек.
Маалымат базасы кластери
Эми сизде CMS серверлерине жүктөлгөн бардык сертификаттар бар, сиз үч түйүн ортосунда маалымат базасынын кластерлерин конфигурациялап, иштете аласыз. Биринчи кадам - бул маалымат базасы кластеринин башкы түйүнү катары бир серверди тандоо жана аны толугу менен конфигурациялоо.
Master Database
Берилиштер базасынын репликациясын орнотуудагы биринчи кадам маалымат базасы үчүн колдонула турган сертификаттарды көрсөтүү болуп саналат. Бул төмөнкүдөй буйрукту колдонуу менен жүзөгө ашырылат:
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 445445 порт тандалды, анткени 443 порт колдонуучунун веб кардарына кирүү үчүн колдонулат
Биз Web Admin кызматын төмөнкүдөй буйрук менен тастыктама файлдары менен конфигурациялайбыз:
webadmin certs <keyfile> <certificatefile> <ca bundle>Ал эми Веб Админди буйрук менен иштетиңиз:
webadmin enable
Эгер баары жакшы болсо, биз Web Admin тармак жана сертификат үчүн туура конфигурацияланганын көрсөткөн ИЙГИЛИК саптарын алабыз. Биз веб-браузердин жардамы менен кызматтын иштешин текшеребиз жана веб-администратордун дарегин киргизебиз, мисалы: : 445
Bridge Cluster чалуу
Call Bridge ар бир CMS жайылтууда болгон жалгыз кызмат. Call Bridge негизги конференция механизми болуп саналат. Ал ошондой эле, мисалы, Cisco Unified CM аркылуу чалууларды ага же андан башка жакка багыттоо үчүн SIP интерфейсин камсыз кылат.
Төмөндө сүрөттөлгөн буйруктар ар бир серверде тиешелүү сертификаттар менен аткарылышы керек.
Ошондуктан:
Биз сертификаттарды Call Bridge кызматы менен төмөнкүдөй буйрук менен байланыштырабыз:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Биз CallBridge кызматтарын бизге керектүү интерфейске буйрук менен байланыштырабыз:
callbridge listen aАл эми кызматты буйрук менен өчүрүп күйгүзүңүз:
callbridge restart
Эми Call Bridges конфигурациялангандан кийин, Call Bridge кластерин конфигурациялай алабыз. Call Bridge кластерлөө маалымат базасынан же XMPP кластеринен айырмаланат. Call Bridge Cluster 2ден 8ге чейинки түйүндөрдү эч кандай чектөөсүз колдой алат. Бул ашыкча гана эмес, ошондой эле чалууларды акылдуу бөлүштүрүү аркылуу конференциялар Call Bridge серверлери боюнча активдүү бөлүштүрүлүшү үчүн жүктүн тең салмактуулугун камсыз кылат. CMSте кошумча функциялар, Call Bridge топтору жана андан ары башкаруу үчүн колдонула турган тиешелүү функциялар бар.
Чалуу көпүрөлөрүнүн кластерлери негизинен веб администратор интерфейси аркылуу конфигурацияланат
Төмөндө сүрөттөлгөн процедура кластердеги ар бир серверде аткарылышы керек.
Ошентип,
1. Интернет аркылуу Конфигурация > Кластерге өтүңүз.
2. The Bridge инсандыгына чалыңыз Уникалдуу ат катары сервердин атына туура келген callbridge[01,02,03] киргизиңиз. Бул аталыштар ыктыярдуу, бирок бул кластер үчүн уникалдуу болушу керек. Алар сыпаттама мүнөзгө ээ, анткени алар сервердин идентификаторлору [01,02,03] экенин көрсөтүп турат.
3.B Кластердик чалуу көпүрөлөрү кластерге биздин серверлердин веб-администраторунун URL даректерин киргизиңиз, [01,02,03].example.com:445, Дарек талаасында. Портту көрсөтүүнү унутпаңыз. Сиз Peer Link SIP доменин бош калтырсаңыз болот.
4. Ар бир сервердин CallBridge ишенимине сертификат кошуңуз, анын файлында серверлерибиздин бардык сертификаттары камтылган, биз башында бул файлга кошулган, төмөнкүдөй буйрук менен:
callbridge trust cluster <trusted cluster certificate bundle>Ал эми кызматты буйрук менен өчүрүп күйгүзүңүз:
callbridge restart
Натыйжада, ар бир серверде сиз бул сүрөттү алышыңыз керек:
XMPP кластери
CMSдеги XMPP кызматы Cisco Meeting Apps (CMA), анын ичинде CMA WebRTC желе кардары үчүн бардык каттоо жана аныктыгын текшерүү үчүн колдонулат. Call Bridge өзү да аныктыгын текшерүү максатында XMPP кардары катары иштейт жана ошондуктан башка кардарлар сыяктуу конфигурацияланышы керек. XMPP ката толеранттуулугу 2.1 версиясынан бери өндүрүш чөйрөлөрүндө колдоого алынган өзгөчөлүк
Төмөндө сүрөттөлгөн буйруктар ар бир серверде тиешелүү сертификаттар менен аткарылышы керек.
Ошондуктан:
Биз XMPP кызматы менен сертификаттарды төмөнкүдөй буйрук менен байланыштырабыз:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Андан кийин буйрук менен угуу интерфейсин аныктаңыз:
xmpp listen aXMPP кызматы уникалдуу доменди талап кылат. Бул колдонуучулар үчүн логин. Башкача айтканда, колдонуучу CMA колдонмосу (же WebRTC кардары аркылуу) аркылуу кирүүгө аракет кылганда, алар userID@logindomain киргизет. Биздин учурда бул userid@ болотConf.example.com. Эмне үчүн бул жөн гана example.com эмес? Атайын жайылтуубузда Jabber колдонуучулары Unified CMде колдоно турган Unified CM доменибизди example.com катары тандадык, ошондуктан CMS колдонуучулары үчүн SIP домендери аркылуу CMSге жана андан чалууларды багыттоо үчүн башка домен керек болду.
XMPP доменин төмөнкүдөй буйрук менен орнотуңуз:
xmpp domain <domain>Ал эми XMPP кызматын буйрук менен иштетиңиз:
xmpp enableXMPP кызматында сиз XMPP кызматына катталууда колдонула турган ар бир Call Bridge үчүн эсептик дайындарды түзүшүңүз керек. Бул аталыштар ыктыярдуу (жана сиз чалуу көпүрөсүн кластерлөө үчүн конфигурацияланган уникалдуу аттарга тиешеси жок). Сиз бир XMPP серверине үч чалуу көпүрөсүн кошуп, андан кийин кластердеги башка XMPP серверлерине ошол эсептик дайындарды киргизишиңиз керек, анткени бул конфигурация кластердин маалымат базасына туура келбейт. Кийинчерээк биз ар бир Call Bridge бул аталышты жана 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 жазуусу үчүн артыкчылыктуу орнотууларга көз каранды.
Андан кийин, Call Bride кызматы XMPP кызматына ийгиликтүү туташкандыгын текшерүү үчүн Статус> Жалпы бөлүмүнө өтүңүз.
Web Bridge
Кластердеги ар бир серверде Web Bridge кызматын төмөнкү буйрук менен иштетиңиз:
webbridge listen a:443Биз Web Bridge кызматын төмөнкүдөй буйрук менен тастыктама файлдары менен конфигурациялайбыз:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge HTTPSти колдойт. Ал "http-багыттоо" колдонууга конфигурацияланса, HTTP'ди HTTPSге багыттайт.
HTTP багыттоосун иштетүү үчүн, төмөнкү буйрукту колдонуңуз:
webbridge http-redirect enableCall Bridge Web Bridge Call Bridge'ден туташууларга ишене аларын билдирүү үчүн, буйрукту колдонуңуз:
webbridge trust <certfile>бул жерде кластердеги ар бир сервердин үч сертификатын камтыган файл.
Бул сүрөт кластердеги ар бир серверде болушу керек.
Теперь нам нужно создать пользователя с ролью «appadmin», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут бир жолу.
Андан ары орнотуу үчүн биз колдонобуз .
Авторизациялоо үчүн, Авторизация бөлүмүндө Негизги тандаңыз
CMS серверине буйруктарды туура жөнөтүү үчүн керектүү коддоону орнотуу керек
Биз буйрук менен Webbridge көрсөтөбүз POST параметр менен нускага жана мааниси
Веб көпүрөнүн өзүндө биз керектүү параметрлерди көрсөтөбүз: конок мүмкүнчүлүгү, корголгон мүмкүндүк ж.б.
Bridge топторуна чалыңыз
Демейки боюнча, CMS дайыма эле ага жеткиликтүү конференция ресурстарын эң натыйжалуу пайдалана бербейт.
Мисалы, үч катышуучу менен жолугушуу үчүн, ар бир катышуучу үч башка Call Bridges менен аякташы мүмкүн. Бул үч катышуучу бири-бири менен баарлашуусу үчүн, Call Bridges автоматтык түрдө бир эле мейкиндиктеги бардык серверлер менен кардарлардын ортосунда байланыштарды орнотот, ошентип баары бардык кардарлар бир серверде тургандай көрүнөт. Тилекке каршы, мунун терс жагы - 3 адамдан турган бир конференция азыр 9 медиа портту керектейт. Бул, албетте, ресурстарды натыйжасыз пайдалануу. Кошумчалай кетсек, Call Bridge чындап ашыкча жүктөлгөндө, демейки механизм чалууларды кабыл алууну улантуу жана ошол Call Bridgeдин бардык абоненттерине сапаты төмөндөтүлгөн кызмат көрсөтүү болуп саналат.
Бул көйгөйлөр Call Bridge Group функциясын колдонуу менен чечилет. Бул функция Cisco Meeting Server программалык камсыздоосунун 2.1 версиясында киргизилген жана Cisco Meeting App (CMA) кирүүчү жана чыгуучу чалуулары үчүн, анын ичинде WebRTC катышуучулары үчүн жүк балансын колдоо үчүн кеңейтилген.
Кайра туташуу маселесин чечүү үчүн ар бир Call Bridge үчүн үч конфигурациялануучу жүк чектери киргизилген:
LoadLimit — бул белгилүү бир Call Bridge үчүн максималдуу сандык жүк. Ар бир платформанын сунушталган жүктөө чеги бар, мисалы, CMS96000 үчүн 1000 жана виртуалдык машина үчүн vCPU үчүн 1.25 ГГц. Ар кандай чалуулар катышуучунун резолюциясына жана кадр ылдамдыгына жараша белгилүү бир көлөмдөгү ресурстарды керектейт.
NewConferenceLoadLimitBasisPoints (демейки 50% loadLimit) - сервердин жүктөө чегин белгилейт, андан кийин жаңы конференциялар четке кагылат.
ExistingConferenceLoadLimitBasisPoints (демейки loadLimitтин 80%) - сервердин жүктөө мааниси, андан кийин учурдагы конференцияга кошулган катышуучулар четке кагылат.
Бул өзгөчөлүк чалууларды бөлүштүрүү жана жүктөмдү теңдөө үчүн иштелип чыкканы менен, TURN серверлери, веб көпүрө серверлери жана жазгычтар сыяктуу башка топтор да Чакыруу Bridge топторуна дайындалышы мүмкүн, ошондуктан алар да оптималдуу пайдалануу үчүн туура топтолушу мүмкүн. Эгерде бул объекттердин кайсынысы болбосун чакыруу тобуна ыйгарылбаса, алар кандайдыр бир артыкчылыксыз бардык серверлер үчүн жеткиликтүү болот деп болжолдонот.
Бул параметрлер бул жерде конфигурацияланган: :445/api/v1/система/конфигурация/кластер
Андан кийин, биз ар бир callbridge тобуна кайсы callbridge тобуна таандык экенин көрсөтөбүз:
Биринчи Callbridge
Экинчи Callbridge
Үчүнчү чалуу көпүрөсү
Ошентип, биз Cisco Meeting Server кластеринин ресурстарын натыйжалуу пайдалануу үчүн Call Brdige тобун конфигурацияладык.
Колдонуучуларды Active Directoryден импорттоо
Web Admin кызматында LDAP конфигурация бөлүмү бар, бирок ал татаал конфигурация опцияларын камсыз кылбайт жана маалымат кластердик маалымат базасында сакталбайт, андыктан конфигурация ар бир серверде же веб-интерфейс аркылуу кол менен аткарылышы керек болот. API, жана биз "үч жолу" "Турба" деп, биз дагы эле API аркылуу маалыматтарды орнотобуз.
Кирүү үчүн URL колдонуу :445/api/v1/ldapServers төмөнкүдөй параметрлерди көрсөтүү менен LDAP Server объектин түзөт:
- Server IP
- порт номери
- Колдонуучунун аты
- пароль
- камсыз кылуу
Коопсуз - портко жараша чын же жалганды тандаңыз, 389 - коопсуз эмес, 636 - корголгон.
LDAP булагынын параметрлерин Cisco Meeting сервериндеги атрибуттарга салыштыруу.
LDAP картасы LDAP каталогундагы атрибуттарды CMSдеги атрибуттарга картага түшүрөт. Чыныгы атрибуттары:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Атрибуттардын сүрөттөлүшүIADB CMSде колдонуучунун логин идентификаторун көрсөтөт. Бул Microsoft Active Directory LDAP сервери болгондуктан, CMS JID LDAP ичиндеги sAMAccountName менен карталанат, ал негизи колдонуучунун Active Directory кирүү ID'си болуп саналат. Ошондой эле sAMAccountName алып, анын аягына conf.pod6.cms.lab доменин кошуп жатканыңызды эске алыңыз, анткени бул сиздин колдонуучуларыңыз CMSге кирүү үчүн колдоно турган логин.
nameMapping Active Directory displayName талаасында камтылган нерсе колдонуучунун CMS аталышы талаасына дал келет.
coSpaceNameMapping displayName талаасынын негизинде CMS мейкиндик атын түзөт. Бул атрибут coSpaceUriMapping атрибуту менен бирге ар бир колдонуучу үчүн мейкиндикти түзүү үчүн талап кылынат.
coSpaceUriMapping колдонуучунун жеке мейкиндиги менен байланышкан URI колдонуучу бөлүгүн аныктайт. Кээ бир домендерди мейкиндикке терүү үчүн конфигурациялоого болот. Эгер колдонуучу бөлүгү бул домендердин бирине дал келсе, чалуу ошол колдонуучунун мейкиндигине багытталат.
coSpaceSecondaryUriMapping космоско жетүү үчүн экинчи URI аныктайт. Бул coSpaceUriMapping параметринде аныкталган алфавиттик-сандык URIга альтернатива катары импорттолгон колдонуучунун мейкиндигине чалууларды багыттоо үчүн сандык лакап ат кошуу үчүн колдонсо болот.
LDAP сервери жана LDAP картасы конфигурацияланган. Эми сиз LDAP булагын түзүү менен аларды бириктиришиңиз керек.
Кирүү үчүн URL колдонуу :445/api/v1/ldapSource төмөнкүдөй параметрлерди көрсөтүү менен LDAP Source объектин түзөт:
- Server
- картасын түзүү
- baseDn
- чыпка
Эми LDAP конфигурациясы аяктагандан кийин, сиз кол менен синхрондоштуруу операциясын аткара аласыз.
Биз муну ар бир сервердин веб интерфейсинде чыкылдатуу менен жасайбыз Азыр шайкештирүү бөлүмүндө Active Directory
же буйругу менен API аркылуу POST жетүү үчүн URL колдонуу :445/api/v1/ldapSyncs
Атайын конференциялар
Бул эмне?Салттуу концепцияда конференция - бул эки катышуучу бири-бири менен сүйлөшүп, катышуучулардын бири (Бирдиктүү CMде катталган аппаратты колдонуу менен) "Конференция" баскычын басып, башка адамга телефон чалып, ошол үчүнчү тарап менен сүйлөшкөндөн кийин. , үч тараптуу конференциянын бардык катышуучуларына кошулуу үчүн "Конференция" баскычын кайрадан басат.
Ad-Hoc конференциясын CMSдеги пландаштырылган конференциядан айырмалоочу нерсе, бул Ad-Hoc конференциясы CMSге SIP чалуу гана эмес. Конференциянын демилгечиси бардыгын бир жолугушууга чакыруу үчүн Конференция баскычын экинчи жолу чыкылдатканда, Unified CM бардык чалуулар өткөрүлө турган ыкчам конференция түзүү үчүн CMSге API чалуу жасашы керек. Мунун баары катышуучуларга байкалбастан болуп жатат.
Бул Unified CM кызматтын API эсептик дайындарын жана WebAdmin дарегин/портун, ошондой эле чалууну улантуу үчүн SIP-Trunk түз CMS серверине конфигурациялашы керек дегенди билдирет.
Зарыл болсо, CUCM динамикалык түрдө CMSде мейкиндикти түзө алат, андыктан ар бир чалуу CMSге жете алат жана боштуктар үчүн арналган кириш чалуу эрежесине дал келет.
CUCM менен интеграция макалада айтылгандай конфигурацияланган Мындан тышкары, Cisco UCMде сиз CMS үчүн үч магистрал, үч Конференция көпүрөсүн түзүшүңүз керек, SIP Коопсуздук профилинде үч Тема атын, Маршрут топторун, Маршрут тизмелерин, Медиа Ресурс топторун жана Медиа Ресурс Топторунун Тизмелерин көрсөтүп, бир нече маршруттук эрежелерди кошуңуз. Cisco жолугушуу серверине.
SIP коопсуздук профили:
Сандыктар:
Ар бир тулку бирдей көрүнөт:
Conference Bridge
Ар бир Conference Bridge окшош көрүнөт:
Маршрут тобу
Маршрут тизмеси
Медиа ресурстар тобу
Медиа ресурстар тобунун тизмеси
Чалуу эрежелери
Unified CM же Expressway сыяктуу чалууларды башкаруу тутумдарынан айырмаланып, CMS жаңы чалуулар үчүн SIP Request-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 чалуубу) жана чалууларды багыттоо эрежесинде өткөрүү тандалбаган болсо, аткарыла турган конверсияларды аныктайт.
Бул жерде Ad-Hoc конференциясынын учурунда эмне болуп жатканынын иш жүзүндөгү журналы
Скриншот аны начар көрсөтөт (мен аны кантип жакшыртууну билбейм), андыктан журналды мындай жазам:
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. Part Толук URI ушул эреженин негизинде түзүлөт. Чынында, эгер сиз ушул учурда Web Bridgeге кирсеңиз, Space URI домени жок экенин көрөсүз. Бул эрежени эң жогорку артыкчылык катары коюу менен, сиз түзүлгөн мейкиндиктер үчүн доменди коюп жатасыз conf.example.com.
Чыгуучу чалуу эрежелери
Колдонуучуларга Unified CM кластерине чыгуучу чалууларды жасоого уруксат берүү үчүн, сиз чыгуу эрежелерин конфигурациялашыңыз керек. Unified CM менен катталган акыркы чекиттердин домени, мисалы, Jabber, example.com болуп саналат. Бул доменге чалуулар стандарттуу SIP чалуулары катары Unified CM чалууларды иштетүү түйүндөрүнө багытталышы керек. Негизги сервер cucm-01.example.com, ал эми кошумчасы cucm-02.example.com.
Биринчи эреже кластердик серверлердин ортосундагы чалуулардын эң жөнөкөй багыттоосун сүрөттөйт.
талаа Доменден жергиликтүү "@" белгисинен кийин чалуучу адам үчүн чалуучунун SIP-URIсинде эмне көрсөтүлө турганы үчүн жооп берет. Эгерде биз аны бош калтырсак, анда “@” белгисинен кийин бул чалуу өтүүчү CUCMдин IP дареги болот. Эгерде биз доменди көрсөтсөк, анда “@” белгисинен кийин чындыгында домен болот. Бул кайра чалуу үчүн зарыл, антпесе SIP-URI name@ip-address аркылуу кайра чалуу мүмкүн эмес.
Көрсөтүлгөндө чалыңыз Доменден жергиликтүү
Качан чал НЕ белгисиз Доменден жергиликтүү
Чыгуучу чалуулар үчүн Шифрленген же Шифрленген эмес деп так көрсөтүүнү унутпаңыз, анткени Auto параметри менен эч нерсе иштебейт.
жазуу
Видеоконференциялар Record сервери тарабынан жазылат. Жазгыч Cisco Meeting Server менен дал келет. Жазгыч эч кандай лицензияны орнотууну талап кылбайт. Жаздыруу лицензиялары CallBridge кызматтарын иштеткен серверлер үчүн талап кылынат, б.а. Жаздыруу лицензиясы талап кылынат жана Жазгычты иштеткен серверге эмес, CallBridge компонентине колдонулушу керек. Жазгыч өзүн Extensible Messaging and Presence Protocol (XMPP) кардары катары алып барат, ошондуктан XMPP сервери CallBridge хостинг серверинде иштетилиши керек.
Анткени Бизде кластер бар жана лицензия кластердеги үч серверге тең “чоюлуу” керек. Андан кийин жөн гана лицензияларыңыздагы жеке аккаунтуңузда кластерге кирген бардык CMS серверлеринин a-интерфейстеринин MAC даректерин бириктиребиз (кошуубуз).
Бул кластердеги ар бир серверде болушу керек болгон сүрөт
Жалпысынан, жазгычты орнотуунун бир нече сценарийлери бар, бирок биз муну карманабыз:
Жазгычты орнотуудан мурун, видеоконференциялар чындыгында жазыла турган жерди даярдашыңыз керек. Чынында бул жерде , бардык жаздырууларды кантип орнотуу керек. Мен маанилүү пункттарга жана майда-чүйдөсүнө чейин басым жасайм:
1. Сертификатты кластердеги биринчи серверден алып салганыңыз жакшы.
2. Жазгычтын ишениминде туура эмес сертификат көрсөтүлгөндүктөн, "Диктофон жеткиликтүү эмес" катасы пайда болушу мүмкүн.
3. Жазуу үчүн көрсөтүлгөн NFS каталогу түпкү каталог болбосо, жазуу иштебей калышы мүмкүн.
Кээде белгилүү бир колдонуучунун же мейкиндиктин конференциясын автоматтык түрдө жаздыруу зарылчылыгы келип чыгат.
Бул үчүн эки CallProfiles түзүлөт:
Жаздыруу өчүрүлгөн
Жана автоматтык жазуу функциясы менен
Андан кийин, биз талап кылынган мейкиндикке автоматтык жазуу функциясы менен CallProfile "тиркелет".
CMSде ушунчалык белгиленген, эгерде CallProfile кандайдыр бир мейкиндикке же мейкиндикке ачык түрдө байланган болсо, анда бул CallProfile ушул белгилүү мейкиндиктерге карата гана иштейт. Ал эми CallProfile эч кандай мейкиндикке байланбаса, демейки боюнча ал эч кандай CallProfile ачык байланышпаган мейкиндиктерге колдонулат.
Кийинки жолу мен CMSге уюмдун ички тармагынан тышкары кантип кирерин сүрөттөөгө аракет кылам.
булагы:
Source: www.habr.com