В этом выпуске я покажу и объясню некоторые тонкости настройки CMS сервера в режиме отказоустойчивого кластера.
В deployment guide'ах от Cisco английским по белому написано, что кластер нужно разворачивать минимум из трёх серверов(нодов) в контексте баз данных. Т.к. только с нечётным количеством узлов отработает механизм выбора нового Мастера базы данных, и вообще Мастер базы данных имеет связь с большей частью базы данных CMS сервера.
И как практика показывает двух серверов(нодов) действительно не вполне достаточно. Механизм выбора отрабатывает при перезагрузке Master'а, Slave сервер становится Master'ом исключительно после поднятия перезагруженного сервера. Однако, если в кластере из двух серверов Master сервер вдруг «погас», то Slave сервер Master'ом не станет, а если «погас» Slave то и оставшийся Master сервер станет Slave'ом.
А вот в контексте XMPP действительно нужно бы собирать кластер из трёх серверов, т.к. если, например, отключить XMPP службу на одном из серверов в котором XMMP в статусе Leader, то на оставшемся сервере XMPP так и останется в статусе Follower и подключения CallBridge'й к XMPP отвалятся, т.к. CallBridge подключается исключительно к XMPP со статусом Leader. А это критично, т.к. ни один звонок не пройдёт.
Также в этих же deployment guide'ах демонстрируется кластер с одним XMPP сервером.
И с учётом выше сказанного становится понятно почему: работает потому что в режиме failover.
В нашем случае XMPP сервер будет присутствовать на всех трёх нодах.
Предполагается, что все три наши сервера подняты.
Прежде чем приступать к настройке серверов необходимо завести DNS записи А и SRV типов:
Обратите внимание, что в наших DNS записях присутствует два домена example.com и conf.example.com. Example.com является доменом, который могут использовать для своих URI все абоненты Cisco Unified Communication Manager'a, который скорее всего в вашей инфраструктуре присутствует или с высокой долей вероятности присутствовать будет. Или домен example.com соответствует тому же домену, который пользователи используют для своих адресов электронной почты. Или же клиент Jabber на вашем ноутбуке может иметь URI user@example.com. Домен conf.example.com — это тот домен, который будет настроен для пользователей Cisco Meeting Server'a. Доменом Cisco Meeting Server'a будет conf.example.com, поэтому для того же пользователя Jabber для входа в Cisco Meeting Server нужно будет использовать URI user@conf.example.com.
Все настройки описываемые ниже показаны на одном сервере, но провести их нужно на каждом сервере кластера.
Поскольку CMS генерирует real-time трафик, чувствительный к задержкам и потере пакетов, в большинстве случаев рекомендуется настроить качество обслуживания (QoS). Для этого CMS поддерживает маркировку пакетов кодами дифференцированных услуг (DSCP), которые он генерирует. Хотя приоритезация трафика на основе DSCP зависит от того каким образом трафик обрабатывается сетевыми компонентами вашей инфраструктуры, в нашем случае мы настроим наш CMS с типичным распределением приоритетов DSCP на основе лучших практик QoS.
На каждом сервере введём вот эти команды
Таким образом, весь видео трафик был помечен AF41 (DSCP 0x22), весь голосовой трафик помечен EF (DSCP 0x2E), прочие виды трафика с низкой задержкой, такие как SIP и XMPP, используют AF31 (DSCP 0x1A).
Проверяем:
Сетевой протокол времени (NTP) важен не только для обеспечения точных временных отметок звонков и конференций, но также и для проверки сертификатов.
Добавляем сервера NTP вашей инфраструктуры командой вида
В нашем случае таких серверов два, поэтому и команд будет две.
Проверяем:
И задаём временную зону для нашего сервера
DNS серверы в CMS добавляем командой вида:
В нашем случае таких серверов два, поэтому и команд будет две.
Проверяем:
Настраиваем а интерфейс командой вида:
Проверяем:
Имя сервера задаём командой вида:
И перезагружаем.
На этом базовая конфигурация закончена.
Итак, формируем запрос для сертификата, который будет использоваться всеми службами сервера за исключением database(для этого будет отдельный запрос) командой вида:
В CN пишем обобщённое название наших серверов. Например если hostname'ы наших серверов server01, server02, server03, то CN будет server.example.com
Тоже самое делаем на оставшихся двух серверах с тем отличием, что в командах будут соответствующие «hostname'ы»
Формируем два запроса для сертификатов, которые будут использоваться службой database командами вида:
где dbclusterserver и dbclusterclient имена наших запросов и будущих сертификатов, hostname1(2)(3) имена соответствующих серверов.
Эту процедуру мы выполняем только на одном сервере(!), а сертификаты и соответствующие .key-файлы загрузим на другие сервера.
И загрузить на каждый сервер:
1. «Индивидуальный» сертификат сервера.
2. Корневой сертификат(вместе с промежуточными если такие есть).
3. Сертификаты для базы данных(«серверный» и «клиентский») и файлы с расширением .key, которые сформировались при создании запроса для «серверного» и «клиентского» сертификата базы данных. Эти файлы должны быть на всех серверах одними и теми же.
4. Файл всех трёх «индивидуальных» сертификатов.
В итоге должна получиться примерно такая файловая картина на каждом сервере.
Теперь, когда у вас есть все сертификаты, загруженные на серверы CMS, вы можете настроить и включить кластеризацию базы данных между тремя узлами. Первым шагом является выбор одного сервера в качестве главного узла кластера базы данных и его полная настройка.
Первым шагом в настройке репликации базы данных является указание сертификатов, которые будут использоваться для базы данных. Это делается с помощью команды вида:
Теперь укажем CMS, какой интерфейс использовать для кластеризации баз данных командой:
Затем инициализируем базу данных кластера на главном сервере командой:
Проделываем ту же самую процедуру, только вместо команды database cluster initialize вводим команду вида:
где ip address existing master ip адрес CMS сервера на котором была произведена инициализация кластера, попросту Master'a.
Проверяем как работает наш кластер базы данных на всех серверах командой:
Тоже самое делаем и на оставшемся третьем сервере.
В итоге получается, что первый наш сервер является Master'ом, остальные Slave'ами.
Включаем службу веб-администратора:
445 порт выбран потому, что 443 порт используется для доступа пользователей в web-клиент
Настраиваем Web Admin службу с файлами сертификатов командой вида:
И включаем Web Admin командой:
Если всё хорошо, то мы получим строки SUCCESS, в которых указано, что Web Admin правильно настроен для сети и сертификата. Проверяем работоспособность службы с помощью веб-браузера и вводим адрес веб-администратора, например: cms.example.com:445
Call Bridge является единственной службой, присутствующей в каждом развертывании CMS. Call Bridge является основным механизмом конференц-связи. Он также обеспечивает SIP интерфейс, так что вызовы могут маршрутизироваться к нему или из него, например Cisco Unified CM'ом.
Описанные ниже команды надо выполнить на каждом сервере с соответствующими сертификатами.
Итак:
Связываем сертификаты со службой Call Bridge командой вида:
Привязываем службы CallBridge к нужному нам интерфейсу командой:
И перезапускаем службу командой:
Теперь, когда у нас есть настроены 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-адреса веб-администратора наших серверов в кластере, cms[01,02,03].example.com:445, в поле Address. Обязательно укажите порт. Вы можете оставить Peer link SIP domain пустым.
4. Добавляем в доверие CallBridge'у каждого сервера сертификат, файл которого содержит все сертификаты наших серверов, которые мы слили в этот файл в самом начале, командой вида:
И перезапускаем службу командой:
В итоге на каждом сервере должна получиться вот такая картина:
Служба XMPP в CMS используется для обработки всей регистрации и аутентификации для Cisco Meeting Apps (CMA), включая веб-клиента CMA WebRTC. Сам Call Bridge также действует, как клиент XMPP для целей аутентификации и поэтому должен быть настроен как другие клиенты. Отказоустойчивость XMPP — это функция, которая поддерживается в производственных средах, начиная с версии 2.1
Описанные ниже команды надо выполнить на каждом сервере с соответствующими сертификатами.
Итак:
Связываем сертификаты со службой XMPP командой вида:
Затем определите интерфейс прослушивания командой:
Для службы XMPP требуется уникальный домен. Это логин для пользователей. Другими словами, когда пользователь пытается войти в систему с помощью приложения CMA (или через клиент WebRTC), он вводит userID@logindomain. В нашем случае это будет userid@conf.example.com. Почему это не просто example.com? В нашем конкретном развертывании мы выбрали наш домен Unified CM, который пользователи Jabber будут использовать в Unified CM, как example.com, поэтому нам нужен другой домен для пользователей CMS, чтобы маршрутизировать вызовы в CMS и из CMS через домены SIP.
Настройте домен XMPP с помощью команды вида:
И включаем службу XMPP командой:
В службе XMPP необходимо создать учетные данные для каждого Call Bridge, которые будут использоваться при регистрации в службе XMPP. Эти имена являются произвольными (и не связаны с уникальными именами, которые вы настроили для кластеризации моста вызовов). На одном сервере XMPP необходимо добавить три моста вызовов, а затем ввести эти учетные данные на других серверах XMPP в кластере, поскольку эта конфигурация не помещается в кластерную базу данных. Позже мы настроим каждый Call Bridge для использования этого имени и секрета для регистрации в службе XMPP.
Теперь нам нужно настроить службу XMPP на первом сервере с тремя Call Bridge'ами callbridge01, callbridge02 и callbridge03. Каждой учетной записи будут назначены случайные пароли. Позже они будут введены на других серверах Call Bridge для входа на этот XMPP-сервер. Вводим следующие команды:
В итоге проверяем что получилось командой:
В точности такая же картина должны быть на остальных серверах после действий описанных ниже.
Далее добавляем на оставшихся двух серверах точно такие настройки, только командами
Secret добавляем очень аккуратно, чтобы случайно в него например не попали лишние пробелы.
В итоге на каждом сервере должны быть такая одинаковая картина:
Далее на всех серверах кластера указываем в доверие файл содержащий все три сертификата, созданный ранее командой вида:
Включаем режим xmpp кластера на всех серверах кластера командой:
На первом сервере кластера инициируем создание xmpp кластера командой:
На остальных серверах добавляем в xmpp кластер командой вида:
Проверяем на каждом сервере успешность создания XMPP кластера на каждом сервере командами:
Первый сервер:
Второй сервер:
Третий сервер:
Теперь, когда кластер XMPP запущен, необходимо настроить службы Call Bridge для подключения к кластеру XMPP. Эта конфигурация выполняется через веб-администратор.
Заходим на каждом сервере в Configuration > General и в поле Unique Call Bridge name пишем соответствующие серверу уникальные имена Call Bridge callbridge[01,02,03]. В поле Domain conf.example.ru и соответствующие пароли, подсмотреть их можно
на любом сервере кластера командой:
Поле «Сервер» оставляем пустым, Callbridge выполнит поиск 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 службу с файлами сертификатов командой вида:
Web Bridge поддерживает HTTPS. Он будет перенаправлять HTTP на HTTPS, если настроен для использования «http-redirect».
Чтобы включить перенаправление HTTP, используйте следующую команду:
Чтобы Call Bridge дал понять, что Web Bridge'у можно доверять соединениям из Call Bridge, используйте команду:
где это файл, содержащий все три сертификата от каждого сервера в кластере.
Такая картина должны быть на каждом сервере кластера.
Теперь нам нужно создать пользователя с ролью «appadmin», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут один раз.
Для дальнейшей настройки мы будем использовать Postman.
Для авторизации выбираем Basic в разделе Autorization
Для корректной отправки команд на сервера CMS нужно выставить нужную кодировку
Указываем Webbridge'и командой POST с параметром url и значением cms.example.com
В самом webbridge'e указываем нужны параметры: гостевой доступ, защищенный доступ и прочее.
По умолчанию 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, так что они также могут быть правильно сгруппированы для оптимального использования. Если какой-либо из этих объектов не назначен группе вызовов, предполагается, что они доступны всем серверам без какого-либо определенного приоритета.
Эти параметры настраиваются здесь: cms.example.com:445/api/v1/system/configuration/cluster
Далее указываем каждому callbridge'у к какой callbridge-группе он принадлежит:
Первый callbridge
Второй callbridge
Третий callbridge
Таким образом мы настроили группу Call Brdige'eй для более эффективного использования ресурсов кластера Cisco Meeting Server'a.
Служба Web Admin имеет раздел конфигурации LDAP, но он не предоставляет сложные параметры конфигурации, и информация не сохраняется в кластерной базе данных, поэтому настройку придется выполнять, либо вручную на каждом сервере через Web-интерфейс, либо через API, и чтобы нам «три раза не вставать» данные мы будем задавать всё-таки через API.
Используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapServers cоздаём объект LDAP Server'a, указывая такие параметры, как:
Secure — true или false выбираем в зависимости от порта, 389 — не защищенный, 636 — защищённый.
Отображаем LDAP параметры источника на атрибуты в Cisco Meeting Server'e.
Отображение LDAP сопоставляет атрибуты в каталоге LDAP с атрибутами в CMS. Собственно атрибуты:
Сервер LDAP и сопоставление LDAP настроены. Теперь требуется связать их вместе, создав источник LDAP.
Используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapSource cоздаём объект LDAP Source, указывая такие параметры, как:
Теперь, когда настройка LDAP завершена, можно выполнить операцию ручной синхронизации.
Делаем это либо в Web-интерфейсе каждого сервера нажав Sync now в разделе Active Directory
либо через API командой POST используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapSyncs
Интеграция с 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
Каждый Conference Bridge выглядит одинаково:
Route Group
Route List
Media Resourse Group
Media Resourse Group List
В отличие от более совершенных систем управления вызовами, таких как Unified CM или Expressway, для новых вызовов CMS просматривает домен только в поле SIP Request-URI. Так что, если SIP INVITE предназначен для sip: user@domain.com, 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 конференции
На скриншоте видно плохо(не знаю как сделать лучше), поэтому напишу лог так:
Сама 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. Часть domain полного URI создается на основе этого правила. Фактически, если бы вы вошли в Web Bridge на этом этапе, вы бы увидели, что у Space URI нет домена. Установив это правило в качестве наивысшего приоритета, вы задаете домен для сгенерированных space'ов как conf.example.com.
Правила исходящих вызовов
Чтобы разрешить пользователям совершать исходящие вызовы в кластер Unified CM, необходимо настроить правила исходящих соединений. Доменом конечных точек, зарегистрированных в Unified CM, таких как Jabber, является example.com. Вызовы в этот домен следует направлять как стандартные SIP-вызовы на узлы обработки вызовов Unified CM. В качестве основного выступает cucm-01.example.com сервер, в качестве дополнительного cucm-02.example.com.
Первое же правило описывает простейшую маршрутизацию звонков между серверами кластера.
Поле Local from domain отвечает за то, что будет отображаться в SIP-URI звонящего у того кому звонят после символа "@". Если мы его оставим пустым, то после символа "@" будет ip-адрес CUCM'a через который этот звонок проходит. Если же мы укажем домен, то после символа "@" собственно и будет домен. Это нужно для того, чтобы была возможность перезвонить обратно, иначе дозвониться обратно по SIP-URI имя@ip-адрес будет не возможно.
Звонок когда указан Local from domain
Звонок когда НЕ указан Local from domain
Обязательно явно укажите 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 за пределами внутренней сети организации.
Источники:
Теория
Вообще существует три типа развёртывания CMS сервера:
Прежде чем переходить к развёртыванию нужно понимать некоторые базовые вещи, а именно
Основные программные компоненты CMS:
В отличие от большинства других продуктов Cisco, Cisco Meeting Server поддерживает три метода настройки, позволяющих развернуть любой вид развертывания.
Кроме вышеуказанного, используется протокол SFTP для передачи файлов — обычно лицензий, сертификатов или журналов — на сервер CMS и с него.
- Single Combined(Единый комбинированный), т.е. это один сервер, на котором запущены все необходимые сервисы. В большинстве случаев этот тип развертывания применим только для доступа внутренних клиентов и в небольших средах, где ограничения масштабируемости и избыточности одного сервера не являются критической проблемой, или в ситуациях, когда CMS выполняет только определенные функции, такие как специальные конференции на Cisco UCM.
Примерная схема работы:
- Single Split(Единый разделённый) расширяет предыдущий тип развёртывания, добавляя отдельный сервер для внешнего доступа. В устаревших развертываниях это означало развертывание сервера CMS в демилитаризованном сегменте сети(DMZ), где внешние клиенты могли бы получить к нему доступ, и одного сервера CMS в ядре сети, где получают доступ к CMS внутренние клиенты. Эта конкретная модель развертывания теперь вытесняется так называемым типом Single Edge, который состоит из серверов Cisco Expressway, которые либо имеют, либо будут иметь многие из возможностей обхода Firewall'a, поэтому клиентам не нужно добавлять выделенный пограничный сервер CMS.
Примерная схема работы:
- Scalable and Resilient(Масштабируемый и отказоустойчивый) этот тип включает в себя избыточность для каждого компонента, что позволяет системе расти с вашими потребностями до максимальной ёмкости, обеспечивая при этом избыточность в случае сбоя. Он также использует концепцию Single Edge для обеспечения безопасного внешнего доступа. Это тип, который мы рассмотрим в этом выпуске. Если мы будем понимать, как развернуть кластер этого типа, мы не только поймём другие типы развертывания, но и сможем понять, как создавать кластеры CMS серверов с учетом потенциального роста потребностей.
Прежде чем переходить к развёртыванию нужно понимать некоторые базовые вещи, а именно
Основные программные компоненты CMS:
- Database: позволяет объединять некоторые конфигурации, такие как абонентская группа, пространства пользователей и самих пользователей. Поддерживает кластеризацию только для высокой доступности (один мастер).
- Call Bridge: сервис для аудио- и видеоконференций, замыкающий на себе полный контроль за управлением и обработкой вызовами и мультимедиа процессами. Поддерживает кластеризацию для высокой доступности и масштабируемости.
- 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 сервер станет Slave'ом.
А вот в контексте XMPP действительно нужно бы собирать кластер из трёх серверов, т.к. если, например, отключить XMPP службу на одном из серверов в котором XMMP в статусе Leader, то на оставшемся сервере XMPP так и останется в статусе Follower и подключения CallBridge'й к XMPP отвалятся, т.к. CallBridge подключается исключительно к XMPP со статусом Leader. А это критично, т.к. ни один звонок не пройдёт.
Также в этих же deployment guide'ах демонстрируется кластер с одним XMPP сервером.
И с учётом выше сказанного становится понятно почему: работает потому что в режиме failover.
В нашем случае XMPP сервер будет присутствовать на всех трёх нодах.
Предполагается, что все три наши сервера подняты.
DNS записи
Прежде чем приступать к настройке серверов необходимо завести DNS записи А и SRV типов:
Обратите внимание, что в наших DNS записях присутствует два домена example.com и conf.example.com. Example.com является доменом, который могут использовать для своих URI все абоненты Cisco Unified Communication Manager'a, который скорее всего в вашей инфраструктуре присутствует или с высокой долей вероятности присутствовать будет. Или домен example.com соответствует тому же домену, который пользователи используют для своих адресов электронной почты. Или же клиент Jabber на вашем ноутбуке может иметь URI user@example.com. Домен conf.example.com — это тот домен, который будет настроен для пользователей Cisco Meeting Server'a. Доменом Cisco Meeting Server'a будет conf.example.com, поэтому для того же пользователя Jabber для входа в Cisco Meeting Server нужно будет использовать URI user@conf.example.com.
Базовая конфигурация
Все настройки описываемые ниже показаны на одном сервере, но провести их нужно на каждом сервере кластера.
QoS
Поскольку CMS генерирует real-time трафик, чувствительный к задержкам и потере пакетов, в большинстве случаев рекомендуется настроить качество обслуживания (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 должен быть загружен, чтобы гарантировать, что сертификаты клиента и сервера могут быть проверены.
Для каждой службы требуется сертификат, однако создание отдельных сертификатов для каждой службы может привести к путанице и лишней сложности. К счастью, мы можем сгенерировать пару открытого и закрытого ключей сертификата, а затем повторно использовать их для нескольких служб. В нашем случае один и тот же сертификат будет использоваться для 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'ы наших серверов server01, server02, server03, то CN будет server.example.com
Тоже самое делаем на оставшихся двух серверах с тем отличием, что в командах будут соответствующие «hostname'ы»
Формируем два запроса для сертификатов, которые будут использоваться службой database командами вида:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.compki csr dbclusterclient CN:postgresгде dbclusterserver и dbclusterclient имена наших запросов и будущих сертификатов, hostname1(2)(3) имена соответствующих серверов.
Эту процедуру мы выполняем только на одном сервере(!), а сертификаты и соответствующие .key-файлы загрузим на другие сервера.
Включение режима клиентского сертификата в AD CS
Ещё нужно слить в один файл сертификаты для каждого сервера
В *NIX:
В Windows/DOS:
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. Файл всех трёх «индивидуальных» сертификатов.
В итоге должна получиться примерно такая файловая картина на каждом сервере.
Database Cluster
Теперь, когда у вас есть все сертификаты, загруженные на серверы CMS, вы можете настроить и включить кластеризацию базы данных между тремя узлами. Первым шагом является выбор одного сервера в качестве главного узла кластера базы данных и его полная настройка.
Master Database
Первым шагом в настройке репликации базы данных является указание сертификатов, которые будут использоваться для базы данных. Это делается с помощью команды вида:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Теперь укажем CMS, какой интерфейс использовать для кластеризации баз данных командой:
database cluster localnode aЗатем инициализируем базу данных кластера на главном сервере командой:
database cluster initializeClient 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 правильно настроен для сети и сертификата. Проверяем работоспособность службы с помощью веб-браузера и вводим адрес веб-администратора, например: cms.example.com: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-адреса веб-администратора наших серверов в кластере, cms[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 aДля службы XMPP требуется уникальный домен. Это логин для пользователей. Другими словами, когда пользователь пытается войти в систему с помощью приложения CMA (или через клиент WebRTC), он вводит userID@logindomain. В нашем случае это будет userid@conf.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]. В поле Domain conf.example.ru и соответствующие пароли, подсмотреть их можно
на любом сервере кластера командой:
xmpp callbridge listПоле «Сервер» оставляем пустым, Callbridge выполнит поиск 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», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут один раз.
Для дальнейшей настройки мы будем использовать Postman.
Для авторизации выбираем Basic в разделе Autorization
Для корректной отправки команд на сервера CMS нужно выставить нужную кодировку
Указываем Webbridge'и командой POST с параметром url и значением cms.example.com
В самом 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, так что они также могут быть правильно сгруппированы для оптимального использования. Если какой-либо из этих объектов не назначен группе вызовов, предполагается, что они доступны всем серверам без какого-либо определенного приоритета.
Эти параметры настраиваются здесь: cms.example.com: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-адрес для доступа cms01.example.com:445/api/v1/ldapServers cоздаём объект LDAP Server'a, указывая такие параметры, как:
- IP-адрес сервера
- номер порта
- имя пользователя
- пароль
- secure
Secure — true или false выбираем в зависимости от порта, 389 — не защищенный, 636 — защищённый.
Отображаем LDAP параметры источника на атрибуты в Cisco Meeting Server'e.
Отображение LDAP сопоставляет атрибуты в каталоге LDAP с атрибутами в CMS. Собственно атрибуты:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Описание атрибутов
JID представляет идентификатор входа пользователя в 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.
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-адрес для доступа cms01.example.com:445/api/v1/ldapSource cоздаём объект LDAP Source, указывая такие параметры, как:
- server
- mapping
- baseDn
- filter
Теперь, когда настройка LDAP завершена, можно выполнить операцию ручной синхронизации.
Делаем это либо в Web-интерфейсе каждого сервера нажав Sync now в разделе Active Directory
либо через API командой POST используя URL-адрес для доступа cms01.example.com: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'ов.
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
Каждый Conference Bridge выглядит одинаково:
Route Group
Route List
Media Resourse Group
Media Resourse Group List
Правила вызовов
В отличие от более совершенных систем управления вызовами, таких как Unified CM или Expressway, для новых вызовов CMS просматривает домен только в поле SIP Request-URI. Так что, если SIP INVITE предназначен для sip: user@domain.com, 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:672@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
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 "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info call 7: setting up UDT RTP session for DTLS (combined media and control)
Info conference "001036270012": unencrypted call legs now present
Info participant "672@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 8: incoming SIP call from "sip:690@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
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 "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info call 8: setting up UDT RTP session for DTLS (combined media and control)
Info call 9: incoming SIP call from "sip:673@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
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 "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
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 "690@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "690@172.x.x.x" (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 "673@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "673@172.x.x.x" (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 "672@x.x.x" 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. Часть domain полного URI создается на основе этого правила. Фактически, если бы вы вошли в Web Bridge на этом этапе, вы бы увидели, что у Space URI нет домена. Установив это правило в качестве наивысшего приоритета, вы задаете домен для сгенерированных space'ов как conf.example.com.
Правила исходящих вызовов
Чтобы разрешить пользователям совершать исходящие вызовы в кластер Unified CM, необходимо настроить правила исходящих соединений. Доменом конечных точек, зарегистрированных в Unified CM, таких как Jabber, является example.com. Вызовы в этот домен следует направлять как стандартные SIP-вызовы на узлы обработки вызовов Unified CM. В качестве основного выступает cucm-01.example.com сервер, в качестве дополнительного cucm-02.example.com.
Первое же правило описывает простейшую маршрутизацию звонков между серверами кластера.
Поле Local from domain отвечает за то, что будет отображаться в SIP-URI звонящего у того кому звонят после символа "@". Если мы его оставим пустым, то после символа "@" будет ip-адрес CUCM'a через который этот звонок проходит. Если же мы укажем домен, то после символа "@" собственно и будет домен. Это нужно для того, чтобы была возможность перезвонить обратно, иначе дозвониться обратно по SIP-URI имя@ip-адрес будет не возможно.
Звонок когда указан Local from domain
Звонок когда НЕ указан Local from domain
Обязательно явно укажите Encrypted или Unencrypted будут исходящие звонки, потому при параметре Auto ничего не работает.
Recording
Запись видеоконференций ведётся 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 за пределами внутренней сети организации.
Источники:
- 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-and-later.pdf