Конфигурация с использованием Load Balancer

[vladimir_manushko]

Здравствуйте!

Согласно этому документу (https://docs.flashphoner.com/displa...WSloadbalancerwithautoscalequicksetup-Testing) мы могли бы построить решение с учётом балансировки. На первый взгляд оно выглядит рабочим, но у меня некоторые моменты вызвали вопросы. Было бы здорово получить на них ответы.

Итак,

1. Наш программный продукт - это платформа, которая будет заниматься стриммингом видео. Наш подход предполагает обьединение двух стримов в один с помощью микшера и дальнейшая ретрансляция итогового стрима на внешние сервисы. Скажите пожалуйста, можно ли при использовании load balancer быть уверенным, что пользователи, чьи стримы должны микшироваться, гарантированно попадут на один сервер? Как быть уверенным в том, что в случае разрыва пользователь подключится на нужный сервер? Или же для микшера не важно на каком физическом сервере находятся потоки и они могут находиться на разных инстансах?

2. В документации указано, что нужно использовать запрос с параметром action=stat и в ответе смотреть на поле connections_websocket. В вашей инструкции нет примера как настроить балансер так, чтобы он брал во внимание этот параметр и каким-то образом обрабатывал ответ. Подскажите, где я могу посмотреть пример такой настройки?

 

[Max]

Добрый день.

Скажите пожалуйста, можно ли при использовании load balancer быть уверенным, что пользователи, чьи стримы должны микшироваться, гарантированно попадут на один сервер?

Нет. Ни один из протестированных нами балансеров (AWS EC2, Google Cloud) этого не гарантирует.

Или же для микшера не важно на каком физическом сервере находятся потоки и они могут находиться на разных инстансах?

Потоки, предназначенные для микширования в одном микшере, должны зайти на сервер с этим микшером.
Если предполагается подключение подписчиков к выходным потокам микшеров по WebRTC, тогда возможен вариант такой CDN:
- Origin серверы, где производится микширование, расположены во внешней сети. Туда заходят потоки, которые должны быть смикшированы. Балансировку необходимо реализовать самостоятельно таки образом, чтобы одна комната (один микшер) был на одном сервере.
- Edge серверы, к который подключаются WebRTC подписчики, расположены за балансировщиком. Подписчики распределяются между серверами автоматически: если превышена заданная нагрузка на CPU, балансировщик поднимает новый инстанс и отправляет Websocket подключения на него

В документации указано, что нужно использовать запрос с параметром action=stat и в ответе смотреть на поле connections_websocket

Это пример, позволяющий проверить, к какому из инстансов мы подключились. Пример настройки Classic Load balancer в AWS EC2 приведен здесь, п 2.5. Также, начиная со сборки 5.2.679, добавлен отдельный эндпойнт для контроля работоспособности сервера в балансировщике нагрузки

http://wcs:8081/health-check

Подробнее здесь
Также посмотрите, пожалуйста, эту статью по настройке CDN с балансировкой в AWS и эту - по Google Cloud.

 

[dimazz]

Здравствуйте! Чтобы не создавать отдельную тему, напишу сюда. В продолжении темы с балансировщиком - нами был выбран AWS ALB.
Т.к. по требованию нужно создавать отдельный EC2 instance на котором будет создаваться микшер и 2 пользователя будут использовать webrtc - первоначальная архитектура была организована следующим образом:

1. Есть ALB и listener с сертификатом для wss и 9000-м портом для сокетов снаружи, который будет проксировать на 8081 порт flashphoner (инстансы будут не постоянными и поэтому лучшим решением было использовать alb с сертификатом для wss и одним сабдоменом)
2. программно создается EC2 flashphoner instance из EC2 launch template.
3. далее создается target group и в нее добавляется новый инстанс.
4. затем создается правило в listener в котором указывается нужный query-string с перенаправлением на эту target group.
5. в конечном итоге получаем ендпоинт для двух пользователей с нужным wss для webrtc и rtmp стрим на выходе для броадкаста ,а так же с уверенностью, что все это на одном инстансе.
Но вот в чем проблема - естественно в такой архитектуре webrtc не сможет корректно работать, т.к. нет возможности организовать доступ к нужным портам через балансировщик на этот же инстанс и в итоге получаем ошибку что-то вроде failed by ICE timeout.
Использовать внешние turn и т.д. нет возможности.
Есть ли в данном варианте альтернативы , как можно обойти это проблему или лучше искать другое решение?
спасибо

 

[Max]

Но вот в чем проблема - естественно в такой архитектуре webrtc не сможет корректно работать, т.к. нет возможности организовать доступ к нужным портам через балансировщик на этот же инстанс и в итоге получаем ошибку что-то вроде failed by ICE timeout.

Балансировщик должен пробрасывать websocket соединения на внешний адрес инстанса, и медиапорты на инстансах должны быть открыты в Security Group при создании шаблона (п 6). В этом случае WebRTC должен работать.

Использовать внешние turn и т.д. нет возможности.

Вы можете использовать встроенный TURN или настроить coturn в том же инстансе. В этом случае, однако, потребуется решить задачу проброса двух портов через балансировщик на один и тот же инстанс: websocket порт 8443 и TURN порт 3478.

 

[dimazz]

добавление портов непосредственно на инстанс (UDP 31000 - 32000) решило проблему, спасибо