Граница публикуемых потоков

[Ilya K.]

Здравствуйте.
Скажите, пожалуйста, количество публикуемых потоков ограничена только мощностью сервера, на котором развёрнут Origin, либо можно каким-то образом объединить несколько серверов Origin в один логический, по аналогии с Edge. Предназначен ли Web Call Server в принципе для одновременной публикации очень большого количества потоков? Например, несколько тысяч, десятков тысяч.

 

[Max]

Несколько тысяч входящих потоков - это очень много. Если битрейт одного потока 1 Мегабит/сек (640x360 - 800x450 стрим с учетом возможного разброса битрейта), то несколько тысяч входящих потоков - это несколько гигабит в секунду. При этом, полоса до сервера должна быть гарантирована, иначе стримы ее забьют. Стандартные условия хостинг провайдеров и датацентров не гарантируют полосу до сервера. Поэтому, без специальных условий по трафику, распределить большое количество стримов можно только по большому количеству распределенных Origin-серверов в разных датацентрах. Для этого можно использовать в качестве балансировщика нагрузки haproxy или nginx.

Перед тем как стрим попадает на Origin сервер, клиент устанавливает websocket соединение с Origin-сервером по порту 8443 (default).
И именно это соединение можно балансировать. Т.е. если клиент указал адрес балансировщика wss://load-balancer-ip:443 то его соединение будет переброшено например на Origin235, и далее стрим пойдет именно на этот сервер Origin235 без проксирования аудио и видео трафика через балансировщик, т.е. напрямую. А дальше этот стрим попадает в CDN и его видят все Edge-серверы. Самый простой способ распределения Round Robin - по кругу равномерно приземлять вебсокет соединение на существующие Origin-серверы. Более сложные балансировки, с учетом метрик загрузки серверов. В этом случае, потребуются какие-то скрипты на стороне haproxy, которые выбирают Origin в зависимости от метрик. Метрики WCS в текстовом виде доступны по запросу http://host:8081?action=stat

 

[Ilya K.]

Здравствуйте. Скажите пожалуйста, есть на это подробные статьи?

 

[Max]

Google Cloud

Google Cloud Platform для WebRTC CDN с балансировкой и автоматическим масштабированием | Flashphoner Streaming & Calls for Web

flashphoner.com

Amazon AWS

CDN с балансировкой и автоматическим масштабированием на базе Amazon Web Services | Flashphoner Streaming & Calls for Web

flashphoner.com

В статьях описывается балансировка между Edge - серверами. Но точно также балансируются Origin-серверы. Технически нет разницы к какому серверу балансировщик перенаправит соединение - к одному из Origins или к одному из Edges.

Если брать свой балансировщик ни AWS ни Google, то это скорее всего будет haproxy. Где-то говорили, что именно он находится под капотом балансировщика AWS. Поэтому под него отдельно надо статьи поискать.

 

[evgeniy.mukhin]

Добрый день. Сделали с origin всё как по этой инструкции и не работает.
Подключились к веб-интерфейсу origin по доменному имени, присвоенному балансировщику нагрузки в разделе media devices, запустили сессию, на edge во вкладке media devices при попытке запустить видео получили ошибку в консоли браузера:
16:49:39 INFO webrtc - FOUND WEBRTC CACHED INSTANCE, id a40f2780-f918-11eb-b497-81e0e7294424-REMOTE_CACHED_VIDEO
и видео не запустилось.

 

[Max]

16:49:39 INFO webrtc - FOUND WEBRTC CACHED INSTANCE, id a40f2780-f918-11eb-b497-81e0e7294424-REMOTE_CACHED_VIDEO

Это не ошибка, а нормальное поведение: отображается информация о закэшированном видео элементе.
Были ли какие-нибудь ошибки в консоли/интерфейсе примера? Проверьте также в примере Two Way Streaming, он выводит подробное описание при получении статуса потока FAILED.
Проверьте, опубликован ли поток на Origin сервере, это можно увидеть на странице статистики или при помощи REST API запроса /stream/find_all. Если поток на Origin сервере опубликован, а с Edge не играет, проверяйте, есть ли связь между Origin и Edge, при помощи REST API.
Если поток на Origin не публикуется, смотрите ошибки публикации. Например, Failed by ICE timeout говорит о том, что порты для передачи медиа трафика заблокированы.
Также рекомендуем проводить тестирование на потоке с небольшим разрешением/битрейтом, чтобы исключить проблемы с каналом.

 

[evgeniy.mukhin]

Спасибо, с этим разобрался. Так же возник вопрос можно ли как-то их синхронизировать? На двух origin могут создаться два стрима, один нормальный и один - черный экран. И воспроизводятья они, похоже, в случайном порядке. Плюс трансляция экрана может пойти на один origin, а поток с веб-камеры на другой.

 

[Max]

Плюс трансляция экрана может пойти на один origin, а поток с веб-камеры на другой.

Это штатное поведение ELB: невозможно предсказать, на какой инстанс он пробросит websocket-соединение.
Поэтому необходимо использовать REST hooks. Например, определить клиента в /connect, и передать на этого клиента адрес конкретного сервера, куда он должен подключаться для трансляции потоков. Пример реализации можно посмотреть здесь или в этой статье
Другой вариант - публиковать поток трансляции экрана и веб-камеру в одной websocket сессии, например, как это сделано в примере Two Way Video Chat and ScreenSharing (исходный код на GitHub). В примере используется RoomApi и функция Room.publish, если Вы не используете RoomApi, то на каждый из двух потоков будет вызов Session.createStream() и Stream.publish()

 

[evgeniy.mukhin]

Добрый день. Подскажите, пожалуйста. Столкнулись с такой проблемой: есть два сервера origin, которые находятся за AWS Classic Load Balancer. Делаем к ним запрос вида /rest-api/mixer/startup. Если запрос посылается напрямую на конкретный сервер, то всё ок. Если на/через load balancer, то сначала возвращается код 502 BAD_GATEWAY, а на второй запрос возвращается 409 Conflict

 

[Max]

Добрый день.

Troubleshoot a Classic Load Balancer: HTTP errors - Elastic Load Balancing

Troubleshoot the error messages returned for your Classic Load Balancer.

docs.aws.amazon.com

Здесь говорится, что балансер может возвращать 502, если получил невалидный Response от WCS сервера.

Вы можете выполнить запрос через HTTP и снять дамп на стороне WCS сервера.

tcpdump port 80 -i eth0 -B 10000 -w log.pcap

В этом случае, в дампе будет видно ответ WCS сервера и возможно станет понятно почему этот ответ не нравится балансировщику Амазон.
Если ответ валидный, значит проблема на стороне балансировщика Amazon и есть смысл попробовать другой HTTP/HTTPS балансировщик, не Classic.