У цьому випуску я покажу та поясню деякі тонкощі налаштування CMS сервера в режимі кластеру відмови.
ТеоріяВзагалі існує три типи розгортання CMS сервера:
- Single Combined(єдиний комбінований), тобто. це один сервер, на якому запущені всі необхідні послуги. У більшості випадків цей тип розгортання застосовується лише для доступу внутрішніх клієнтів і в невеликих середовищах, де обмеження масштабованості та надмірності одного сервера не є критичною проблемою, або в ситуаціях, коли CMS виконує лише певні функції, такі як спеціальні конференції на Cisco UCM.
Зразкова схема роботи:
- Одиночний спліт(Єдиний розділений) розширює попередній тип розгортання, додаючи окремий сервер зовнішнього доступу. У застарілих розгортаннях це означало розгортання сервера CMS в демілітаризованому сегменті мережі (DMZ), де зовнішні клієнти могли б отримати доступ до нього, і одного сервера CMS в ядрі мережі, де отримують доступ до CMS внутрішні клієнти. Ця конкретна модель розгортання тепер витісняється так званим типом Single Edge, що складається з серверів Cisco Expressway, які або мають, або будуть мати багато можливостей обходу Firewall'a, тому клієнтам не потрібно додавати виділений прикордонний сервер CMS.
Зразкова схема роботи:
- Scalable and Resilient(Масштабований і відмовостійкий) цей тип включає надлишковість для кожного компонента, що дозволяє системі зростати з вашими потребами до максимальної ємності, забезпечуючи при цьому надмірність у разі збою. Він також використовує Single Edge концепцію для забезпечення безпечного зовнішнього доступу. Це тип, який ми розглянемо у цьому випуску. Якщо ми розумітимемо, як розгорнути кластер цього типу, ми не тільки зрозуміємо інші типи розгортання, але й зможемо зрозуміти, як створювати кластери CMS серверів з урахуванням потенційного зростання потреб.
Перш ніж переходити до розгортання, потрібно розуміти деякі базові речі, а саме
Основні програмні компоненти CMS:
- Database: дозволяє об'єднувати деякі конфігурації, такі як абонентська група, простори користувачів та користувачів. Підтримує кластеризацію лише високої доступності (один майстер).
- Зателефонуйте в міст: сервіс для аудіо- та відеоконференцій, що замикає на собі повний контроль за керуванням та обробкою викликами та мультимедіа процесами. Підтримує кластеризацію для високої доступності та масштабованості.
- XMPP server: відповідає за реєстрацію та автентифікацію клієнтів, які використовують додаток Cisco Meeting Application та/або WebRTC(real-time communication, ну або просто в браузері)а також міжкомпонентну сигналізацію. Може бути кластеризований лише для високої доступності.
- Web Bridge: надає доступ клієнтів до WebRTC.
- Loadbalancer: забезпечує єдину точку підключення для програм Cisco Meeting App у режимі Single Split. Прослуховує зовнішній інтерфейс та порт для вхідних з'єднань. В рівній мірі балансувальник навантаження приймає вхідні TLS з'єднання з сервером XMPP, через які він може перемикати TCP-з'єднання від зовнішніх клієнтів.
У нашому сценарії він не знадобиться. - TURN server: забезпечує технологію обходу Firewall'а, що дозволяє
вивісити наш CMS за Firewall'ом або NAT'ом для підключення зовнішніх клієнтів, які використовують Cisco Meeting App або SIP пристрої. У нашому сценарії він не знадобиться. - Web Admin: адміністративний інтерфейс та доступ до API, у тому числі для спеціальних конференцій Unified CM.
Режими конфігурації
На відміну від більшості інших продуктів Cisco, Cisco Meeting Server підтримує три методи налаштування, які дозволяють розгорнути будь-який вид розгортання.
- Командний рядок (CLI): Інтерфейс командного рядка, відомий як MMP, для завдань початкового налаштування та сертифікатів.
- Веб-адміністратор: насамперед для конфігурації, пов'язаної з CallBridge, особливо при налаштуванні одного некластеризованого сервера.
- REST API: використовується для найскладніших завдань з налаштування та завдань, пов'язаних із кластерною базою даних.
Крім вищезгаданого, використовується протокол SFTP для передачі файлів – зазвичай ліцензій, сертифікатів чи журналів – на сервер CMS та з нього.
У deployment guide'ах від Cisco англійською по білому написано, що кластер потрібно розгортати мінімум із трьох серверів (нодів) у тих баз даних. Т.к. тільки з непарною кількістю вузлів відпрацює механізм вибору нового Майстра бази даних, і взагалі Майстер бази даних має зв'язок з більшою частиною бази даних CMS сервера.
І як практика показує двох серверів дійсно дійсно не цілком достатньо. Механізм вибору відпрацьовує при перезавантаженні Master'а, Slave сервер стає Master'ом виключно після підняття перезавантаженого сервера. Однак, якщо в кластері з двох серверів Master сервер раптом «погас», то Slave сервер Master'ом не стане, а якщо «погас» Slave то і Master Server, що залишився, стане Slave'ом.
А ось у контексті XMPP дійсно потрібно було б збирати кластер із трьох серверів, т.к. якщо, наприклад, відключити XMPP службу одному з серверів у якому XMMP у статусі Leader, то залишився сервері XMPP так і залишиться у статусі Follower і підключення CallBridge'й до XMPP відваляться, т.к. CallBridge підключається виключно до XMPP із статусом Leader. І це критично, т.к. жоден дзвінок не пройде.
Також у цих же deployment guide'ах демонструється кластер із одним XMPP сервером.
І з урахуванням вище сказаного стає зрозуміло чому: працює тому що в режимі failover.
У нашому випадку XMPP сервер буде присутній на всіх трьох нодах.
Передбачається, що всі три наші сервери піднято.
DNS запису
Перш ніж приступати до налаштування серверів, необхідно завести DNS записи А и SRV типів:
Зверніть увагу, що в наших DNS записах є два домени example.com і конф.example.com. Example.com є доменом, який можуть використовувати для своїх URI всі абоненти Cisco Unified Communication Manager'a, який, швидше за все, у вашій інфраструктурі присутній або з високою ймовірністю бути присутнім. Або домен example.com відповідає тому ж домену, який користувачі використовують для своїх електронних адрес. Або клієнт Jabber на вашому ноутбуці може мати URI [захищено електронною поштою]. Домен конф.example.com — це той домен, який буде налаштований для користувачів Cisco Meeting Server. Доменом Cisco Meeting Server'a буде конф.example.com, тому для того ж користувача Jabber для входу в Cisco Meeting Server потрібно буде використовувати URI user@конф.example.com.
Базова конфігурація
Всі налаштування описані нижче показані одному сервері, але провести їх потрібно кожному сервері кластера.
QoS
Оскільки CMS генерує реального часу трафік, чутливий до затримок та втрати пакетів, в більшості випадків рекомендується налаштувати якість обслуговування (QoS). Для цього CMS підтримує маркування пакетів кодами диференційованих послуг (DSCP), які він генерує. Хоча пріоритезація трафіку на основі DSCP залежить від того, як трафік обробляється мережевими компонентами вашої інфраструктури, в нашому випадку ми налаштуємо наш CMS з типовим розподілом пріоритетів DSCP на основі кращих практик QoS.
На кожному сервері введемо ці команди
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)
Ім'я сервера задаємо командою виду:
hostname <name>
І перезавантажуємо.
У цьому базова конфігурація завершена.
Сертифікати
ТеоріяCisco Meeting Server вимагає шифрованого зв'язку між різними компонентами, і в результаті сертифікати X.509 потрібні для всіх розгортань CMS. Вони допомагають забезпечити довіру до служб/сервера іншим серверам/службам.
Для кожної служби потрібний сертифікат, однак створення окремих сертифікатів для кожної служби може призвести до плутанини та зайвої складності. На щастя, ми можемо створити пару відкритого та закритого ключів сертифіката, а потім повторно використовувати їх для декількох служб. У нашому випадку той самий сертифікат буде використовуватися для Call Bridge, сервера XMPP, Web Bridge та Web Admin. Таким чином потрібно створити по парі відкритого та закритого ключів сертифіката на кожен сервер у кластері.
Кластеризація бази даних, однак, має деякі особливі вимоги до сертифікатів і тому вимагає своїх сертифікатів, відмінних від сертифікатів інших служб. CMS використовує сертифікат сервера, який схожий на сертифікати, що використовуються іншими серверами, але також є сертифікат клієнта, який використовується для з'єднань з базою даних. Сертифікати бази даних використовуються як для аутентифікації, так і для шифрування. Замість надавати ім'я користувача та пароль для підключення клієнта до бази даних, він представляє сертифікат клієнта, якому довіряє сервер. Кожен сервер у кластері бази даних буде використовувати одну і ту ж пару відкритого та закритого ключів. Це дозволяє всім серверам у кластері шифрувати дані таким чином, щоб вони могли бути розшифровані лише іншими серверами, які також використовують ту саму пару ключів.
Щоб резервування працювало, кластери бази даних повинні складатися як мінімум з 3 серверів, але не більше 5 з максимальним часом проходження сигналу в обох напрямках 200 мс між будь-якими членами кластера. Ця межа є більш обмежувальною, ніж для кластеризації Call Bridge, тому вона часто є обмежуючим фактором географічно розподілених розгортаннях.
Роль бази даних для CMS має низку унікальних вимог. На відміну від інших ролей, він вимагає сертифіката клієнта та сервера, де сертифікат клієнта має певне поле CN, яке представляється серверу.
CMS використовує базу даних postgres з одним головним та декількома повністю ідентичними репліками. У кожен час існує лише одна основна база даних («сервер бази даних»). Інші члени кластера є репліками чи «клієнтами бази даних».
Для кластера бази даних потрібні сертифікат виділеного сервера та сертифікат клієнта. Вони мають бути підписані сертифікатами, зазвичай внутрішнім приватним центром сертифікації. Оскільки будь-який із членів кластера бази даних може стати головним, пари сертифікатів сервера бази даних та клієнта (що містять відкритий та закритий ключі) мають бути скопійовані на всі сервери, щоб вони могли прийняти ідентичність клієнта чи сервера бази даних. Крім того, кореневий сертифікат CA повинен бути завантажений, щоб гарантувати, що сертифікати клієнта та сервера можуть бути перевірені.
Отже, формуємо запит для сертифіката, який використовуватиметься всіма службами сервера за винятком database (для цього буде окремий запит) командою виду:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
У CN пишемо узагальнену назву наших серверів. Наприклад, якщо hostname'и наших серверів сервер01, сервер02, сервер03, то CN буде server.example.com
Те саме робимо на двох серверах, що залишилися, з тією відмінністю, що в командах будуть відповідні «hostname'и»
Формуємо два запити для сертифікатів, які використовуватимуться службою database командами виду:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresде dbclusterserver и dbclusterclient імена наших запитів та майбутніх сертифікатів, hostname1(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
Client Database Nodes
Проробляємо ту саму процедуру, тільки замість команди database cluster initialize вводимо команду виду:
database cluster join <ip address existing master>де ip address existing master ip адреса CMS сервера на якому була проведена ініціалізація кластера, просто Master'a.
Перевіряємо, як працює наш кластер бази даних на всіх серверах командою:
database cluster status
Те саме робимо і на третьому сервері, що залишився.
У результаті виходить, перший наш сервер є Master'ом, інші Slave'ами.
Web Admin Service
Включаємо службу веб-адміністратора:
webadmin listen a 445445 порт вибрано тому, що 443 порт використовується для доступу користувачів до web-клієнт
Налаштовуємо Web Admin службу із файлами сертифікатів командою виду:
webadmin certs <keyfile> <certificatefile> <ca bundle>І включаємо Web Admin командою:
webadmin enable
Якщо все добре, ми отримаємо рядки SUCCESS, в яких зазначено, що Web Admin правильно налаштований для мережі та сертифіката. Перевіряємо працездатність служби за допомогою веб-браузера та вводимо адресу веб-адміністратора, наприклад: : 445
Call Bridge Cluster
Call Bridge є єдиною службою, яка присутня в кожному розгортанні CMS. Call Bridge є основним механізмом конференц-зв'язку. Він також забезпечує SIP інтерфейс, тому виклики можуть маршрутизуватися до нього або з нього, наприклад Cisco Unified CM'ом.
Наведені нижче команди потрібно виконати на кожному сервері з відповідними сертифікатами.
Отже:
Зв'язуємо сертифікати із службою Call Bridge командою виду:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Прив'язуємо служби CallBridge до потрібного інтерфейсу командою:
callbridge listen aІ перезапускаємо службу командою:
callbridge restart
Тепер, коли ми налаштовані Call Bridge'и, ми можемо налаштувати кластеризацію Call Bridge. Кластеризація Call Bridge відрізняється від кластеризації баз даних або XMPP. Call Bridge Cluster може підтримувати від 2 до 8 вузлів без обмежень. Він забезпечує не лише надмірність, а й розподіл навантаження, завдяки чому конференції можуть активно розподілятися між серверами Call Bridge за допомогою інтелектуального розподілу дзвінків. CMS має додаткові функції, групи Call Bridge та пов'язані з ними функції, які можна використовувати для подальшого керування.
Кластеризація мосту дзвінків налаштовується в основному через інтерфейс веб-адміністратора
Нижчеописану процедуру необхідно провести кожному сервері кластера.
Отже,
1. Заходимо через web у Configuration > Cluster.
2. В Call Bridge identity як унікальне ім'я вводимо callbridge[01,02,03] відповідне ім'я сервера. Ці імена довільні, але мають бути унікальними для цього кластера. Вони мають описовий характер, оскільки вказують на те, що це ідентифікатори серверів [01,02,03].
3.В Clustered Call Bridges вводимо URL-адреси веб-адміністратора наших серверів у кластері, [01,02,03].example.com:445, у полі Address. Обов'язково вкажіть порт. Ви можете залишити Peer link SIP domain порожнім.
4. Додаємо на довіру CallBridge'у кожного сервера сертифікат, файл якого містить усі сертифікати наших серверів, які ми злили в цей файл на самому початку, командою виду:
callbridge trust cluster <trusted cluster certificate bundle>І перезапускаємо службу командою:
callbridge restart
У результаті на кожному сервері має вийти така картина:
XMPP Cluster
Служба XMPP у CMS використовується для обробки всієї реєстрації та аутентифікації для 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@конф.example.com. Чому це не просто example.com? У нашому конкретному розгортанні ми вибрали наш домен Unified CM, який користувачі Jabber будуть використовувати в Unified CM як example.com, тому нам потрібен інший домен для користувачів CMS, щоб маршрутизувати виклики в CMS та з CMS через домени SIP.
Налаштуйте домен XMPP за допомогою команди виду:
xmpp domain <domain>І включаємо службу XMPP командою:
xmpp enableУ службі XMPP необхідно створити облікові дані для кожного Call Bridge, які будуть використовуватися для реєстрації в службі XMPP. Ці імена є довільними (і не пов'язані з унікальними іменами, які ви налаштували для кластеризації моста викликів). На одному сервері XMPP необхідно додати три мости дзвінків, а потім ввести ці облікові дані на інших серверах XMPP у кластері, оскільки ця конфігурація не міститься в кластерній базі даних. Пізніше ми налаштуємо кожен Call Bridge для використання цього імені та секрету для реєстрації у службі XMPP.
Тепер нам потрібно налаштувати службу XMPP на першому сервері з трьома Call Bridge'ами callbridge01, callbridge02 та callbridge03. Кожен обліковий запис буде призначено випадкові паролі. Пізніше вони будуть введені на інших серверах Call Bridge для входу на цей сервер XMPP. Вводимо такі команди:
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 callbridge03Secret додаємо дуже акуратно, щоб випадково в нього, наприклад, не потрапили зайві прогалини.
У результаті кожному сервері мають бути така однакова картина:
Далі на всіх серверах кластера вказуємо в довіру файл, який містить усі три сертифікати, створений раніше командою виду:
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 запущено, необхідно налаштувати служби Call Bridge для підключення до кластера XMPP. Ця конфігурація здійснюється через веб-адміністратор.
Заходимо на кожному сервері в Configuration > General та у полі Unique Call Bridge name пишемо відповідні серверу унікальні імена Call Bridge callbridge[01,02,03]. В полі Область conf.example.ru та відповідні паролі, підглянути їх можна
на будь-якому сервері кластера командою:
xmpp callbridge list
Поле «Сервер» залишаємо порожнім, Колбрідж виконає пошук DNS SRV для _xmpp-component._tcp.conf.example.com, щоб знайти доступний сервер XMPP. IP адреси підключення callbridge'ою до XMPP можуть відрізнятися на кожному сервері, це залежить від того, які значення повертаються на запит по запису _xmpp-component._tcp.conf.example.com callbridge'у, що у свою чергу залежить від налаштувань пріоритетів для цього DNS запису.
Далі переходимо в Status > General, щоб переконатися, що служба Call Bride підключена до служби XMPP.
Web Bridge
На кожному сервері кластера включаємо службу Web Bridge командою:
webbridge listen a:443Налаштовуємо Web Bridge службу із файлами сертифікатів командою виду:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge підтримує HTTPS. Він перенаправлятиме HTTP на HTTPS, якщо налаштований для використання «http-redirect».
Щоб увімкнути перенаправлення HTTP, використовуйте таку команду:
webbridge http-redirect enableЩоб Call Bridge дав зрозуміти, що Web Bridge'у можна довіряти з'єднанням з Call Bridge, використовуйте команду:
webbridge trust <certfile>де це файл, що містить усі три сертифікати від кожного сервера у кластері.
Така картина має бути на кожному сервері кластера.
Тепер нам потрібно створити користувача з роллю «appadmin», він нам потрібен для того, щоб ми могли налаштовувати наш кластер(!), а не кожен сервер кластера окремо, таким чином налаштування застосовуватимуться однаково на кожен сервер при тому, що вони будуть виконуватися один раз.
Для подальшого налаштування ми будемо використовувати .
Для авторизації вибираємо Basic у розділі Autorization
Для коректного надсилання команд на сервери CMS потрібно виставити потрібне кодування
Вказуємо Webbridge'і командою POST з параметром URL та значенням
У самому webbridge'e вказуємо потрібні параметри: гостьовий доступ, захищений доступ та інше.
Call Bridge Groups
За замовчуванням CMS не завжди максимально ефективно використовує доступні ресурси конференц-зв'язку.
Наприклад, для зустрічі з трьома учасниками кожен учасник може опинитися на трьох різних Call Bridge'ax. Для того, щоб ці три учасники могли спілкуватися один з одним, Call Bridge'и автоматично встановлять з'єднання між усіма серверами і клієнтами в тому самому Space'e, щоб виглядало це все так, ніби всі клієнти на одному сервері. На жаль, недоліком цього є те, що одна конференція із 3 осіб тепер споживатиме 9 медіа-портів. Це, мабуть, неефективне використання ресурсів. Крім того, коли Call Bridge дійсно перевантажений, механізм за замовчуванням полягає в тому, щоб продовжувати приймати дзвінки та надавати послуги зі зниженою якістю всім абонентам цього Call Bridge'a.
Ці проблеми вирішуються за допомогою функції Call Bridge Group. Ця функція була представлена у версії 2.1 програмного забезпечення Cisco Meeting Server і була розширена для підтримки балансування навантаження як для вхідних, так і вихідних викликів, Cisco Meeting App (CMA), включаючи учасників WebRTC.
Для вирішення проблеми перепідключення були введені три обмеження навантаження, що настроюються для кожного Call Bridge:
LoadLimit - це максимальне числове навантаження для конкретного Call Bridge. Кожна платформа має рекомендоване граничне значення навантаження, наприклад 96000 для CMS1000 і 1.25 GHz на віртуальний процесор для віртуальної машини. Різні виклики споживають певну кількість ресурсів залежно від роздільної здатності та частоти кадрів учасника.
NewConferenceLoadLimitBasisPoints (за замовчуванням 50% loadLimit) — встановлює межу завантаження сервера, після якого відхиляються нові конференції.
ExistingConferenceLoadLimitBasisPoints (за замовчуванням 80% від loadLimit) – значення завантаження сервера, після якого учасники, які приєднуються до існуючої конференції, будуть відхилені.
У той час, як ця функція була розроблена для розподілу викликів та розподілу навантаження, інші групи, такі, як сервери TURN, сервери Web Bridge та пристрої запису, також можуть бути призначені для Call Bridge Groups, тому вони також можуть бути правильно згруповані для раціонального використання. Якщо якийсь із цих об'єктів не призначений групі викликів, передбачається, що вони доступні всім серверам без певного пріоритету.
Ці параметри налаштовуються тут: :445/api/v1/system/configuration/cluster
Далі вказуємо кожному callbridge'у до якої callbridge-групи він належить:
Перший callbridge
Другий callbridge
Третій callbridge
Таким чином ми налаштували групу Call Brdige'e для більш ефективного використання ресурсів кластера Cisco Meeting Server'a.
Імпорт користувачів із Active Directory
Служба Web Admin має розділ конфігурації LDAP, але він не надає складних параметрів конфігурації, і інформація не зберігається в кластерній базі даних, тому налаштування доведеться виконувати, або вручну на кожному сервері через Web-інтерфейс, або через API, і щоб нам тричі не вставати дані ми будемо задавати все-таки через API.
Використовуючи URL-адресу для доступу :445/api/v1/ldapServers створюємо об'єкт LDAP Server'a, вказуючи такі параметри, як:
- IP-адреса сервера
- номер порту
- Ім'я користувача
- пароль
- безпечний
Secure - true або false вибираємо залежно від порту, 389 - не захищений, 636 - захищений.
Відображаємо LDAP параметри джерела на атрибути Cisco Meeting Server'e.
Відображення LDAP зіставляє атрибути в каталозі LDAP з атрибутами CMS. Власне атрибути:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Опис атрибутівIADB представляє ідентифікатор входу користувача CMS. Оскільки це LDAP-сервер Microsoft Active Directory, JID CMS зіставляється з sAMAccountName в LDAP, який є ідентифікатором входу в Active Directory користувача. Також зверніть увагу, що ви берете sAMAccountName і додаєте домен conf.pod6.cms.lab до кінця, тому що це логін, який ваші користувачі будуть використовувати для входу в CMS.
nameMapping зіставляє те, що міститься у полі Active Directory displayName, із полем імені CMS користувача.
coSpaceNameMapping створює ім'я space'a CMS на основі поля displayName. Цей атрибут разом з атрибутом coSpaceUriMapping є тим, що потрібно створити space'a для кожного користувача.
coSpaceUriMapping визначає користувальницьку частину URI, пов'язану з особистим space'ом користувача. Деякі домени можуть бути налаштовані для набору в space. Якщо частина користувача збігається з цим полем для одного з цих доменів, виклик буде направлено в space цього користувача.
coSpaceSecondaryUriMapping визначає другий URI, щоб досягти space'a. Це може використовуватися для додавання числового псевдоніма для маршрутизації викликів у space імпортованого користувача як альтернативу буквено-цифровому URI, визначеному в параметрі coSpaceUriMapping.
Сервер LDAP та зіставлення LDAP налаштовані. Тепер потрібно зв'язати їх разом, створивши джерело LDAP.
Використовуючи URL-адресу для доступу :445/api/v1/ldapSource створюємо об'єкт LDAP Source, вказуючи такі параметри, як:
- сервер
- відображення
- baseDn
- фільтрувати
Тепер, коли налаштування LDAP завершено, можна виконати операцію синхронізації вручну.
Робимо це або у Web-інтерфейсі кожного сервера натиснувши Синхронізуйте зараз у розділі Active Directory
або через API командою POST використовуючи URL-адресу для доступу :445/api/v1/ldapSyncs
Ad-Hoc конференції
Що це?У традиційному понятті конференція це, коли два учасники розмовляють один з одним, а один із учасників (використовуючи пристрій, зареєстрований у Unified CM) натискає кнопку «Конференція», викликає іншу людину і після розмови з цією третьою стороною натискає знову натисніть кнопку «Конференція» , щоб приєднатися до всіх учасників тристоронньої конференції.
Ad-Hoc конференцію від запланованої конференції у CMS відрізняє те, що Ad-Hoc конференція – це не просто виклик SIP для CMS. Коли ініціатор конференції натискає кнопку «Конференція» вдруге, щоб запросити всіх на те саме зібрання, Unified CM повинен виконати виклик API для CMS, щоб створити конференцію «на льоту», на яку потім передаються всі виклики. Усе це відбувається непомітно учасників.
Це означає, що Unified CM має налаштувати облікові дані API та адресу/порт WebAdmin служби, а також SIP-Trunk безпосередньо на сервер CMS для продовження виклику.
При необхідності CUCM може динамічно створювати space в CMS, щоб кожен виклик міг дійти до CMS і відповідати правилу вхідних дзвінків, яке призначене для space'ів.
Інтеграція з CUCM налаштовується так само, як описано у статті за винятком того, що на Cisco UCM потрібно створити три транки для CMS, три Conference Bridge'a, в SIP Security Profile вказати три Subject Name'a, Route Group'у, Route List, Media Resourse Group і Media Resourse Group List, а в Cisco Meeting Server'e трохи додати правила маршрутизації.
SIP Security Profile:
Транки:
Кожен транк виглядає однаково:
Міст конференції
Кожен Conference Bridge виглядає однаково:
Route Group
Список маршрутів
Media Resourse Group
Media Resourse Group List
Правила дзвінків
На відміну від досконаліших систем керування викликами, таких як Unified CM або Expressway, для нових викликів CMS переглядає домен лише у полі SIP Request-URI. Так що якщо SIP INVITE призначений для sip: [захищено електронною поштою], CMS піклується лише про domain.com. CMS слід цим правилам для визначення, куди направити дзвінок:
1. Спочатку CMS намагається зіставити домен SIP з доменами, налаштованими у правилах обробки вхідних дзвінків. Потім ці виклики можна надсилати в (цільові) простору або конкретним користувачам, внутрішнім IVR або безпосередньо інтегрованим адресатам Microsoft Lync/Skype для бізнесу (S4B).
2. Якщо в правилах вхідних дзвінків немає збігів, CMS спробує зіставити домен, налаштований у таблиці переадресації дзвінків. Якщо зіставлення встановлено, правило може явно відхилити або переадресувати виклик. У цей час CMS може переписати домен, що іноді корисно для дзвінків до доменів Lync. Ви також можете вибрати pass throw, що означає, що жодне з полів не буде додатково змінено або використовувати внутрішню абонентську групу 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Сама Ad-Hoc конференція:
Правила вхідних дзвінків
Налаштування параметрів вхідних дзвінків необхідне для отримання дзвінка до CMS. Як ви бачили в налаштуванні LDAP, усі користувачі були імпортовані з доменом conf.pod6.cms.lab. Тому, як мінімум, ви хочете, щоб виклики в цей домен призначалися для пропусків. Вам також потрібно буде встановити правила для всього, що призначене для повного доменне ім'я (і, можливо, навіть для IP-адреси) кожного із серверів CMS. У нашому зовнішньому контролі викликів, Unified CM, буде налаштовано магістралі SIP, призначені для кожного із серверів CMS індивідуально. Залежно від того, чи є призначення цих магістралей SIP IP-адресою, чи повне доменне ім'я сервера визначатиме, чи потрібно налаштувати CMS для прийому дзвінків, спрямованих на його IP-адресу або повне доменне ім'я.
Домен, що має правило вхідного трафіку з найвищим пріоритетом, використовується як домен для будь-яких користувацьких space'ів. Коли користувачі синхронізуються через LDAP, CMS автоматично створює space'и, але тільки частину користувача URI (coSpaceUriMapping), наприклад, user.space. Частина повного URI створюється з урахуванням цього правила. Фактично, якби ви увійшли до Web Bridge на цьому етапі, ви б побачили, що Space URI не має домену. Встановивши це правило як найвищий пріоритет, ви задаєте домен для згенерованих space'ів як конф.example.com.
Правила вихідних дзвінків
Щоб дозволити користувачам здійснювати вихідні дзвінки у кластері Unified CM, необхідно налаштувати правила вихідних з'єднань. Домен кінцевих точок, зареєстрованих у Unified CM, таких як Jabber, є example.com. Виклики в цей домен слід надсилати як стандартні SIP-дзвінки на вузли обробки дзвінків Unified CM. Як основний виступає cucm-01.example.com сервер, як додатковий cucm-02.example.com.
Перше правило описує найпростішу маршрутизацію дзвінків між серверами кластера.
Поле Local від будинку відповідає за те, що буде відображатися в SIP-URI того, хто дзвонить у кого дзвонять після символу «@». Якщо ми його залишимо порожнім, то після символу @ буде ip-адреса CUCM'a через який цей дзвінок проходить. Якщо ж ми вкажемо домен, то після символу @ власне і буде домен. Це потрібно для того, щоб була можливість передзвонити назад, інакше додзвонитися назад по SIP-URI ім'я@ip-адреса буде неможливим.
Дзвінок коли вказано Local від будинку
Дзвінок коли НЕ вказано Local від будинку
Обов'язково вкажіть Encrypted або Unencrypted вихідні дзвінки, тому при параметрі Auto нічого не працює.
запис
Запис відеоконференцій ведеться Record-сервером. Recorder являє собою такий самий Cisco Meeting Server. Recorder не вимагає встановлення на себе жодних ліцензій. Ліцензії на запис потрібні серверам, на яких запущені служби CallBridge, тобто. ліцензія Recording необхідна і повинна застосовуватися до компонента CallBridge, а не до сервера, де запущений Recorder. Recorder поводиться як клієнт розширюваного протоколу обміну повідомленнями та присутності (XMPP), тому сервер XMPP має бути включений на сервері, на якому розміщений CallBridge.
Т.к. у нас кластер та ліцензію потрібно «розтягнути» на всі три сервери кластера. То просто в особистому кабінеті в ліцензіях асоціюємо (додаємо) MAC-адреси a-інтерфейсів всіх CMS серверів, що входять до кластера.
І ось така картина має бути на кожному сервері кластера
Взагалі сценаріїв розміщення Recorder'a кілька, але ми дотримуватимемося такого:
Перед тим, як налаштовувати Recorder, потрібно підготувати місце куди власне і записуватимуться відеоконференції. Власне ось як налаштувати весь Recording. Я акцентую увагу на важливих моментах та деталях:
1. Сертифікат краще підсунути від першого сервера у кластері.
2. Помилка Recorder unavailable може виникати тому, що вказано не той сертифікат в Recorder Trust.
3. Запис може не йти, якщо для запису вказаний не кореневий каталог NFS.
Іноді виникає потреба автоматично записувати конференцію одного конкретного користувача або space'a.
Для цього створюються два CallProfile'a:
З відключеною функцією запису
І з автоматичною функцією запису
Далі до потрібного space'у "прикручуємо" CallProfile з автоматичною функцією запису.
У CMS так заведено, що якщо CallProfile явно прив'язаний до будь-яких space'ів або space'у, то і працює цей CallProfile стосовно тільки цих конкретних space'ів. А якщо CallProfile не прив'язаний до жодного space'у, то за умовчанням він застосовується до тих space'ам яких явно не прив'язаний жоден CallProfile.
Наступного разу спробую описати, як доступ до CMS за межами внутрішньої мережі організації.
Джерела:
Джерело: habr.com