¶ Общая информация
Гибридный вариант внедрения DION заключается в переносе ряда сервисов, отвечающих за работу с конфиденциальной информацией на площадку заказчика, в то время как остальные компоненты DION продолжают функционировать в облаке. Это позволяет добиться безопасной обработки конфиденциальных медиа-данных при сравнительно небольшом расходе ресурсов серверного оборудования.
Схема гибридного DION приведена ниже. На ней не отображены компоненты SIP, они будут рассмотрены отдельно.
_(3).jpg)
| Наименование компонентна | Описание компонента |
|---|---|
| Служебные компоненты, взаимодействуют с облаком DION напрямую | |
| DION-Proxy | компонент, отвечающий за обнаружение гибридных нод облаком DION |
| Прикладные компоненты гибрида, взаимодействующие с облаком через Dion-Proxy | |
| MEDIA (SFU + Audiohub) | компонент, отвечающий за обработку аудио и видео-потоков |
| Recorder, Record Converter, Record delivery | компоненты, отвечающие за создание, конвертацию и скачивание пользователями видеозаписей конференций |
| API Video Gateway | компонент, отвечающий за пользовательские и служебные запросы к сервисам DION-Video |
| Компоненты гибрида, не взаимодействующие с облаком DION | |
| TURN | компонент, отвечающий за подключение внешних пользователей ко внутренним медиа-серверам через NAT |
| KMS | компонент, хранящий секрет для выработки ключа шифрования |
| HLS Delivery, HLS Converter, Upload Companion, DLP Adapter | компоненты Dion Video |
Для обеспечения отказоустойчивости возможно резервирование нод в режиме Active-Active в рамках одной площадки, а также разнесение идентичных нод по разным площадкам также в режиме Active-Active.
¶ Георезервирование
Гибридный DION может быть развернут на две площадки и более, при этом все площадки являются активными. Резервирование компонент происходит в режиме Active-Active.
Пользователь может быть направлен на любую из площадок, при этом обязательно наличие L3 связности между компонентами в разных ЦОД.
Далее описаны детали резервирования различных сервисов DION. Обратите внимание, что количество нод одного типа в рамках одной площадки неограниченно. Дополнительные ноды взаимодействуют друг с другом и с другими сервисами полностью аналогично отображенным на схеме.
Рекомендуемая схема резервирования для нескольких площадок — N+N.
¶ Dion-Proxy
.Dion-proxy является управляющим компонентом гибридного DION, располагается в DMZ и обеспечивает передачу управляющих команд в облако DION и обратно.
В конфигурационном файле каждого dion-proxy необходимо перечислить адреса всех прикладных компонентов DION, расположенных на обеих площадках, в том числе адреса всех других нод dion-proxy.
В конфигурационных файлах прикладных сервисов указываются списком адреса всех dion-proxy на всех площадках.
¶ Media (SFU + Audiohub)
Все медиа-сервера взаимодействуют между собой. Это требуется для создания каскадных подключений в больших конференциях. В DION пока не предусмотрено геораспределение медиа-серверов с привязкой к площадке, поэтому медиа-трафик может быть передан между площадками.
¶ TURN
Ноды TURN должны иметь связность со всеми медиа-серверами на всех площадках. В конфигурационных файлах TURN не указываются адреса Dion-Proxy, однако в конфигурационных файлах Dion-Proxy должны быть перечислены адреса всех нод TURN.
¶ Сервисы записи конференций
Сервисы записи могут быть масштабированы независимо друг от друга. Например, допускается иметь по 2 ноды Recorder на каждой из площадок, но при этом по одной ноде Record Converter и Record Delivery.
Распределение пользовательских запросов между нодами Record Delivery производится средствами DNS.
Ноды Recorder должны иметь связность со всеми медиа-серверами на всех площадках.
Все ноды KMS должны иметь идентичную конфигурацию. В конфигурационных файлах KMS не указываются адреса Dion-Proxy, однако в конфигурационных файлах Dion-Proxy должны быть перечислены адреса всех нод KMS.
Для хранения записей необходимо реализовать отказоустойчивый кластер S3.
¶ Видеопортал Dion Video
.jpg)
Прикладные сервисы Dion-Video можно масштабировать независимо друг от друга. Балансировка в рамках площадки может производиться по DNS, если в конфигурационных файлах используются FQDN, а не IP-адреса.
Пользовательские запросы должны балансироваться на уровне DNS.
При наличии дополнительного резервирования в рамках каждой из площадок, допускается исключить взаимодействие компонентов между площадками. Все связи компонентов между собой указываются в конфигурационных файлах.
¶ SIP гибрид
На текущий момент ноды 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-серверами случайным образом. |
| SFU |
Конференции распределяются между всеми активными SFU равномерно по принципу “конференция будет проводиться на сервере с наименьшим количеством активных конференций”. В рамках одной конференции первые 100 пользователей работают на одном SFU на площадке А, затем конференция каскадируется и 101-199 пользователи будут распределены на второй доступный SFU на той же площадке, если такой имеется. Каждая последующая сотня пользователей в рамках одной конференции будет распределена на следующий доступный SFU по очереди. Конференции не каскадируются между SFU на разных площадках. |
| Audiohub | Конференции распределяются между всеми активными Audiohub равномерно по принципу “конференция будет проводиться на сервере с наименьшим количеством активных конференций”. Все пользователи в рамках одной конференции работают на одном Audiohub. Выбранный Audiohub может быть расположен на VM, отличной от выбранного SFU. |
| KMS | Сервис дублируется, все компоненты обращаются к первому KMS по списку, указанному в их конфигурационных файлах, до тех пор, пока тот доступен. |
| Recorder | Конференции распределяются между всеми активными Recorder равномерно по принципу “конференция будет записываться на сервере с наименьшим количеством активных записей”. Recorder всегда находится на той же площадке, где и SFU, на котором проводится конференция. |
| Record Converter | Нагрузка распределяется по алгоритму Round Robin. |
| Record Delivery | Балансировка запросов на уровне 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 | не требуются | Не влияет. |
| Один TURN | не требуется | Пользователи из Интернета не могут подключиться к конференции, автоматический переход на другой активный TURN. Переход занимает от 30 секунд. |
| Все TURN | не требуется | Пользователи из Интернета не могут попасть во внутренние конференции. Не затрагивает сами конференции и внутренних пользователей. |
| Один Audiohub | не требуются | Звук в конференциях пропадает, видео и демонстрация экрана не затрагиваются. Звук восстанавливается автоматически за несколько секунд, если есть другие активные Audiohub или восстановился текущий. |
| Один SFU | не требуются | Конференции зависают, в затронутую конференцию нельзя подключиться. Автоматическое восстановление в течение нескольких секунд, если есть другие активные SFU или восстановился текущий. |
| Один Recorder | не требуются | Запись прекращается, пользователи получают уведомление. Запись можно начать заново. Будут сохранены обе части записи. |
| Один Record Converter | может потребоваться запросить повторную конвертацию видео-записи | Если в момент падения сервиса запись была в обработке, запись не будет обработана. Если запись не обработана в течение суток, обратитесь в службу поддержки. |
| Все Record Converter | может потребоваться запросить повторную конвертацию видео-записи | Если в момент падения сервиса запись была в обработке, запись не будет обработана. Записи, созданные в момент недоступности сервиса, будут обработаны позже, как только хотя бы один Record Converter будет восстановлен. |
| Один Record Delivery | не требуются | Нет влияния, если в административной панели прописан общий FQDN для всех Record Delivery. |
| Все Record Delivery | не требуются | Записи будут доступны пользователям для скачивания после восстановления как минимум одного Record Converter. |
| Один 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. |
| Внимание: После автоматического переподключения в конференцию пользователю может потребоваться выключить и заново включить камеру и микрофон. | ||
¶ Установка
Если вы разворачиваете стенд с нуля, воспользуйтесь инструкцией по установке нужной версии.
Если вы расширяете существующее внедрение без отказоустойчивости, выполните следующие шаги:
- Разверните дополнительные VM в соответствии с требованиями к ресурсам.
- Выполните конфигурацию новых VM согласно инструкции по установке
- Добавьте информацию о новых нодах в конфигурационные файлы уже существующих сервисов
Обратите внимание, что при установке дополнительных нод необходимо прописать их все в последней секции конфигурационного файла каждого Dion-Proxy.
При редактировании файла proxy.yml необходимо соблюдать отступы!
При добавлении дополнительных нод Dion-Proxy необходимо перечислить их в конфигурационных файлах прикладных сервисов и других Dion-Proxy.