Гибридный вариант внедрения DION заключается в переносе ряда сервисов, отвечающих за работу с конфиденциальной информацией, на площадку заказчика, в то время как остальные компоненты DION продолжают функционировать в облаке. Это позволяет добиться безопасной обработки конфиденциальных медиа-данных при сравнительно небольшом расходе ресурсов серверного оборудования.
Схема гибридного DION приведена ниже. На ней не отображены компоненты SIP, они будут рассмотрены отдельно.
Наименование компонентна | Описание компонента |
---|---|
Служебные компоненты, взаимодействуют с облаком DION напрямую | |
DION-Proxy | компонент, отвечающий за обнаружение гибридных нод облаком DION |
Прикладные компоненты гибрида, взаимодействующие с облаком через Dion-Proxy | |
MEDIA (SFU + Audiohub) | компонент, отвечающий за обработку аудио и видео-потоков |
Recorder, Record Converter, Record delivery | компоненты, отвечающие за создание, конвертацию и скачивание пользователями видеозаписей конференций |
API Video Gateway, DMZ Video Proxy | компоненты, отвечающие за пользовательские и служебные запросы к сервисам DION-Video |
Компоненты гибрида, не взаимодействующие с облаком DION | |
TURN | компонент, отвечающий за подключение внешних пользователей ко внутренним медиа-серверам через NAT |
KMS | компонент, хранящий секрет для выработки ключа шифрования |
HLS Delivery, HLS Converter, Upload Companion, DLP Adapter | компоненты Dion Video |
Для обеспечения отказоустойчивости возможно резервирование нод в режиме Active-Active в рамках одной площадки. Гибридный DION может быть развернут на две площадки и более, при этом все площадки являются активными (Active-Active) и обязательно наличие L3 связности между компонентами в разных ЦОД.
Для сервисов конференций и записи предусмотрен механизм геораспределения.
Доступ к сервисам DION.Video в разных ЦОД регулируется на уровне DNS организации.
Начиная с версии гибридного DION 5.15 можно настроить привязку пользователей и нод, отвечающих за проведение конференций и записи, к площадке. Это позволяет управлять распределением пользователей по медиа-серверам во время конференции, повысить качество обслуживания за счет выбора ближайшего к пользователю сервера и существенно снизить объем трафика между ЦОДами.
Площадка в данном случае — это ЦОД, центр присутствия или любая другая логическая сущность, объединяющая в себе ноды, имеющие полную сетевую связность друг с другом согласно таблице доступов.
Сервисы, поддерживающие геораспределение:
Каждая нода гибридного DION теперь имеет привязку к площадке. Привязка задается в конфигурационном файле dion-proxy и действует для всех нод, которые описаны в данном файле.
Следовательно, теперь dion-proxy должен знать только о тех нодах, которые расположены с ним на одной площадке. А эти ноды — только о своих dion-proxy. В рамках площадки поддерживается резервирование нод по типу Active-Active (см. раздел “Отказоустойчивость в рамках одной площадки”).
Исключение составляет сервис record-delivery. Для скачивания записи конференции пользователь перенаправляется на адрес Record Delivery, указанный в административной панели DION. Если указано доменное имя, управлять распределением пользователей по нодам record-delivery следует на уровне DNS организации.
Корректная схема взаимодействия компонентов гибридного DION при геораспределении:
Пример неверной реализации:
В административной панели DION можно задать привязку к площадке пользовательских подсетей. Это означает, что пользователи с адресами из заданного диапазона будут направлены на медиа-сервера на соответствующей площадке согласно установленному правилу. Существует 4 типа правил привязки пользователей к площадке:
Тип правила | Принцип работы |
---|---|
по-умолчанию | Выделяется любой сервер |
нестрогое | Для подключения выделяется сервер из заданного ЦОД. Если в заданном ЦОД нет доступных серверов для подключения, выделяются ресурсы из ЦОД по умолчанию. Правило справедливо для медиа-серверов и серверов записи. |
строгое | Для подключения выделяется сервер из заданного ЦОД. Если в заданном ЦОД нет доступных серверов для подключения, пользователи не могут подключиться. Если нет доступных серверов записи, запись не начинается. |
строгое для медиа | Для подключения выделяется сервер из заданного ЦОД. Если в заданном ЦОД нет доступных серверов для подключения, пользователи не могут подключиться. Если нет доступных серверов записи, запись начинается в ЦОД по умолчанию. |
Существует преднастроенное правило, согласно которому для подключения клиентов, чьи адреса не попадают под заданные диапазоны, может использоваться любой доступный сервер.
Требуется dion-proxy версии 5.15 и выше.
Настройка геораспределения состоит из модификации конфигурационных файлов dion-proxy и создания правил распределения в административной панели.
1. Откройте на редактирование файл /etc/dion/proxy.yaml
2. Укажите название Площадки (ЦОД) в переменной logicalDatacenter:
Все сервисы, зарегистрированные через этот dion-propxy будут привязаны к указанной Площадке
3. Убедитесь в том, что в переменной allProxyGrpcOuterAddresses:
указаны адреса только тех нод dion-proxу, которые расположены на указанной Площадке
4. Убедитесь в том, что в секции, перечисляющей адреса медиа-нод, TURN и сервисов записи указаны только ноды, расположенные на указанной Площадке
5. Сохраните изменения в файле и перезапустите сервис dion-proxy
1. В административной панели перейдите в Настройки организации → Гибридные сервисы
2. Возле каждой ноды должна появиться привязка к площадке, указанной в переменной logicalDatacenter:
в конфигурационном файле соответствующего dion-proxy
1. Перейдите в административную панель DION в раздел Настройки организации→Конференции → Площадки
2. Добавьте правила распределения пользователей по ЦОД. Не забудьте сделать правило активным. Правила считываются по порядку следования.
В поле “Клиентские подсети
” необходимо указать адреса, с которых пользовательские устройства обращаются в облако DION. Это публичные адреса, не внутренняя подсеть.
Запустите гибридную конференцию от имени пользователя, IP адрес которого находится в одном из диапазонов, для которого существует правило в административной панели. Не завершайте конференцию.
Перейдите в административную панель DION в раздел Конференции
Найдите данную конференцию, кликните по имени конференции и зайдите в ее настройки
Кликните по имени пользователя. Откроется боковая панель с параметрами конференции.
При проведении конференций, в которых одновременно участвуют много внешних абонентов и внутренних пользователей, неизбежно растет нагрузка на интернет-шлюз организации.
Каскадирование в облако позволяет построить каскадное соединение между облачными и гибридными медиа-серверами, за счет чего нагрузка на канал связи резко сокращается.
Детали реализации и настройка описаны в данной статье.
Далее приведены правила резервирования различных сервисов DION. Обратите внимание, что количество нод одного типа в рамках одной площадки неограниченно. Дополнительные ноды взаимодействуют друг с другом и с другими сервисами полностью аналогично отображенным на схеме.
Рекомендуемая схема резервирования для нескольких площадок — N+N.
Dion-proxy является управляющим компонентом гибридного DION, располагается в DMZ и обеспечивает передачу управляющих команд в облако DION и обратно.
В конфигурационном файле каждого dion-proxy в рамках Площадки необходимо перечислить адреса всех прикладных компонентов DION, расположенных на той же площадке, в том числе адреса всех других нод dion-proxy и адреса TURN.
В конфигурационных файлах прикладных сервисов указываются списком адреса всех dion-proxy на данной площадке.
Допускается установка по одному dion-proxy на каждой из Площадок. При отказе dion-proxy мертвой считается вся площадка целиком, пользователи переключаются на другую площадку, если в политика распределения Нестрогая, и отключаются от конференции в случае Строгой политики геораспределения.
Все медиа-сервера взаимодействуют между собой. Это требуется для создания каскадных подключений в больших конференциях. Медиа-трафик может быть передан между площадками в случае, если в одной конференции участвуют пользователи из разных локаций.
В каскадном подключении не дублируются медиа-потоки, что позволяет экономить трафик между площадками.
Ноды TURN должны иметь связность со всеми медиа-серверами, расположенными на той же площадке.
В конфигурационных файлах TURN не указываются адреса нод Dion-Proxy, однако в конфигурационных файлах Dion-Proxy должны быть перечислены адреса всех нод TURN, расположенных на той же площадке.
Для TURN, которые работают по старой схеме подключения (без привязки к dion-proxy), необходима связность со всеми медиа-серверами на всех площадках.
Сервисы записи могут быть масштабированы независимо друг от друга. Например, допускается иметь по 2 ноды Recorder на каждой из площадок, но при этом по одной ноде Record Converter и Record Delivery.
Распределение пользовательских запросов между нодами Record Delivery производится средствами DNS. В административной панели для перенаправления указывается DNS имя, соответствующее всем нодам Record Delivery. В зависимости от расположения пользователя, DNS сервер может отдавать пользователю ближайшую ноду Record Delivery.
Ноды Recorder должны иметь связность со всеми медиа-серверами на всех площадках.
Все ноды KMS должны иметь идентичную конфигурацию. В конфигурационных файлах KMS не указываются адреса Dion-Proxy, однако в конфигурационных файлах Dion-Proxy должны быть перечислены адреса всех нод KMS, расположенных на той же площадке.
Для хранения записей необходимо реализовать отказоустойчивый кластер S3.
В версии 3.1 зафиксирован баг: поддерживается только 1 DMZ Video Proxy для каждого из компонентов.
Прикладные сервисы Dion-Video можно масштабировать независимо друг от друга. Балансировка в рамках площадки может производиться по DNS, если в конфигурационных файлах используются FQDN, а не IP-адреса.
Пользовательские запросы должны балансироваться на уровне DNS.
При наличии дополнительного резервирования в рамках каждой из площадок, допускается исключить взаимодействие компонентов между площадками. Все связи компонентов между собой указываются в конфигурационных файлах.
На текущий момент ноды SIP не поддерживают геораспределение. Поэтому для каждого блока можно либо зарезервировать Dion-Proxy в рамках площадки (рекомендованный вариант), либо прописать все Dion-Proxy организации.
Все элементы могут масштабироваться независимо друг от друга. При появлении новых нод SIP Server необходимо решить вопрос маршрутизации вызовов между нодами. Чаще всего для звонка используется общее для всех SIP Server нод DNS имя.
Отказоустойчивость сервисов в рамках одной площадки реализуется абсолютно аналогично схемам выше.
Рекомендуемая схема резервирования в рамках одной площадки — N+1.
Компонент | Распределение нагрузки |
---|---|
Dion-Proxy |
Все dion-proxy в компании активны. Управляющие команды распределяются равномерно между всеми активными dion-proxy по алгоритму Round Robin. Dion-proxy также служит для мониторинга состояния компонент. Каждый прикладной компонент должен иметь информацию обо всех нодах dion-proxy на своей площадке. Каждый dion-proxy должен иметь информацию обо всех остальных компонентах на своей площадке, включая второй dion-proxy. Для этого все связи прописываются в конфигурационных файлах dion-proxy и прикладных сервисов. |
Turn | Внешние пользователи распределяются между всеми зарегистрированными в облаке DION TURN-серверами в зависимости от того, на какой площадке проходит конференция. Если конференция проходит на Площадке 1, для подключения внешних пользователей будет использоваться один из TURN-серверов, расположенных на этой площадке. Распределение в рамках одной площадки происходит по алгоритму Round Robin. |
SFU |
Конференции распределяются между всеми активными SFU заданной площадки равномерно по принципу “конференция будет проводиться на сервере с наименьшим количеством активных конференций”. При подключении первого пользователя в конференцию проверяется правило геораспреления. Конференция привязывается к той площадке, на которую направлен первый пользователь. Если в конференцию заходят пользователи, привязанные к другим площадкам, поднимается каскадное соединение между SFU на их площадке и основным SFU конференции. Пользователи подключаются согласно своим правилам геораспределения. В рамках одной конференции первые 100 пользователей (если они привязаны к площадке А) работают на одном SFU на площадке А, затем конференция каскадируется и 101-199 пользователи будут распределены на второй доступный SFU на той же площадке, если такой имеется. Каждая последующая сотня пользователей в рамках одной конференции будет распределена на следующий доступный SFU по очереди. Конференции каскадируются между SFU на разных площадках, только если в них есть участники, привязанные к разным площадкам. |
Audiohub | Конференции распределяются между всеми активными Audiohub на площадке равномерно по принципу “конференция будет проводиться на сервере с наименьшим количеством активных конференций”. Все пользователи в рамках одной конференции работают на одном Audiohub. Выбранный Audiohub может быть расположен на VM, отличной от выбранного SFU. |
KMS | Сервис дублируется, все компоненты обращаются к первому KMS по списку, указанному в их конфигурационных файлах, до тех пор, пока тот доступен. |
Recorder | Конференции распределяются между всеми активными Recorder равномерно по принципу “конференция будет записываться на сервере с наименьшим количеством активных записей”. Recorder, по возможности, находится на той же площадке, где и SFU, на котором проводится конференция. Если доступных Recorder на этой площадке нет, а правило распределения “Нестрогое” или “Строгое для Медиа”, запись будет запущена на Recorder на другой доступной площадке. |
Record Converter | Нагрузка распределяется по алгоритму Round Robin. |
Record Delivery | Балансировка запросов на уровне DNS. |
DMZ Video Proxy | Балансировка запросов на уровне DNS |
API Video Gateway | Балансировка запросов на уровне DNS |
HLS Delivery | Балансировка запросов на уровне DNS |
HLS Converter | Балансировка запросов на уровне DNS |
Upload Companion | Балансировка запросов на уровне DNS |
DLP Adapter | Нет резервирования, либо балансировка запросов на уровне DNS |
SIP Server | Балансировка на уровне DNS, УПАТС или через изменение адреса при звонке |
SIP Translator | Нагрузка распределяется равномерно по принципу “звонок будет проведен на сервере с наименьшим количеством звонков” |
SIP Transcoder | Нагрузка распределяется равномерно по принципу “звонок будет проведен на сервере с наименьшим количеством звонков” |
В случае георезервирования нет привязки к конкретной площадке. Все компоненты являются активными и взаимодействуют между собой, как показано на схеме выше. |
Отказ | Действия администратора | Влияние на пользователей |
---|---|---|
Выход из строя экземпляра компонент DION затрагивает только те конференции и пользователей, которые в данный момент активны именно на этом экзмепляре. Для конференций и пользователей, работающих на других экземплярах, сбой и восстановление проходят прозрачно. | ||
Один dion-proxy | не требуются | Не влияет, если зарезервирован в рамках площадки или распределение “Нестрогое”. |
Все dion-proxy | требуются | Полная недоступность гибридных конференций |
Один TURN | не требуется | Пользователи из Интернета не могут подключиться к конференции, автоматический переход на другой активный TURN. Переход занимает от 30 секунд. |
Все TURN | не требуется | Пользователи из Интернета не могут попасть во внутренние конференции. Не затрагивает сами конференции и внутренних пользователей. |
Один Audiohub | не требуются | Звук в конференциях пропадает, видео и демонстрация экрана не затрагиваются. Звук восстанавливается автоматически за несколько секунд, если есть другие активные Audiohub на данной площадке при “Строгом” распределении или на любой другой площадке при “Нестрогом" распределении или восстановился текущий Audiohub. |
Один SFU | не требуются | Конференции зависают, в затронутую конференцию нельзя подключиться. Автоматическое восстановление в течение нескольких секунд, если есть другие активные SFU на данной площадке при “Строгом” распределении или на любой другой площадке при “Нестрогом" распределении или восстановился текущий SFU. |
Один Recorder | не требуются | Запись прекращается, пользователи получают уведомление. Запись можно начать заново. Будут сохранены обе части записи. |
Один Record Converter | может потребоваться запросить повторную конвертацию видео-записи | Если в момент падения сервиса запись была в обработке, запись не будет обработана. Если запись не обработана в течение суток, обратитесь в службу поддержки. |
Все Record Converter | может потребоваться запросить повторную конвертацию видео-записи | Если в момент падения сервиса запись была в обработке, запись не будет обработана. Записи, созданные в момент недоступности сервиса, будут обработаны позже, как только хотя бы один Record Converter будет восстановлен. |
Один Record Delivery | не требуются | Нет влияния, если в административной панели прописан общий FQDN для всех Record Delivery. |
Все Record Delivery | не требуются | Записи будут доступны пользователям для скачивания после восстановления как минимум одного Record Converter. |
Один DMZ Video Proxy | требуются |
|
Один API Video Gateway | не требуются |
Зависит от настроек DNS и сетевых доступов на площадке и между ними. В сценарии, который представлен на схеме выше, выход из строя единственного API Video Gateway на площадке повлечет за собой вывод из строя всех сервисов Dion-Video этой площадки, а также недоступность видеопортала для пользователей данной площадки. |
Один HLS Delivery | не требуются |
Зависит от настроек DNS и сетевых доступов на площадке и между ними. В сценарии, который представлен на схеме выше, при выходе из строя единственного HLS Delivery на площадке недоступен просмотр видео на локальном видео-портале пользователями данной площадки. Если HLS Delivery не единственный, запросы будут обработаны второй нодой, балансировка за счет DNS. |
Один Upload Companion | не требуются |
Зависит от настроек DNS и сетевых доступов на площадке и между ними. В сценарии, который представлен на схеме выше, при выходе из строя единственного Upload Companion на площадке недоступна загрузка файлов на локальный видео-портал пользователями данной площадки. Если Upload Companion не единственный, запросы будут обработаны второй нодой, балансировка за счет DNS. |
Один HLS Converter | не требуются |
Зависит от настроек DNS и сетевых доступов на площадке и между ними. В сценарии, который представлен на схеме выше, при выходе из строя единственного HLS Converter на площадке недоступен просмотр видео на локальном видео-портале пользователями данной площадки. Если HLS Converter не единственный, запросы будут обработаны второй нодой, балансировка за счет DNS. |
Один SIP Server | желательно убрать адреса из DNS или trunk-ов | Звонки, проходящие на упавшей ноде, будут прерваны. При повторном вызове и верной маршрутизации вызова пользователь будет подключен через другой доступный SIP Server. |
Один SIP Translator | не требуются | В звонках, проходящих на упавшей ноде, пропадет видео-поток к SIP-устройству. При повторном вызове пользователь будет подключен через другой доступный SIP Translator |
Один SIP Transcoder | не требуются | В звонках, проходящих на упавшей ноде, пропадет видео-поток от SIP-устройства.При повторном вызове пользователь будет подключен через другой доступный SIP Transcoder. |
Выход из строя одного из двух ЦОД | не требуются |
Аналогичен выходу из строя всех отдельных компонент, расположенных в этом ЦОД. Сервис восстановится автоматически с переключением на активный ЦОД в течение нескольких секунд. Запись конференций может быть прервана, конференции могут зависнуть. Работа Dion Video зависит от настроек DNS. |
Внимание: После автоматического переподключения в конференцию пользователю может потребоваться выключить и заново включить камеру и микрофон. |
Если вы разворачиваете стенд с нуля, воспользуйтесь инструкцией по установке нужной версии.
Если вы расширяете существующее внедрение без отказоустойчивости, выполните следующие шаги:
Обратите внимание, что при установке дополнительных нод необходимо прописать их все в последней секции конфигурационного файла каждого Dion-Proxy на площадке.
При редактировании файла proxy.yml необходимо соблюдать отступы!
При добавлении дополнительных нод Dion-Proxy необходимо перечислить их в конфигурационных файлах прикладных сервисов и других Dion-Proxy на данной площадке.