Origin-Edge AWS Auto Scale CDN

[Maksym]

Добрый день.
Интересует вопрос не столько по масштабированию, как об уведомлении Edge о наличии стрима на Origin.
Посмотрел вот эту статью и получается, чтобы Edge узнал на каком Origin находиться стрим, этот самый Origin должен уведомить Edge. Делается это через настройку в файле WCS_HOME/conf/loadbalancing.xml
Схема приблизительно такая:
1...10 Origin(AWS Auto Scale)
5...50 Edge(AWS Auto Scale)
Стримеры заходят через AWS LB-1 и публикуют стрим на одном из Origin.
Зрители заходят через AWS LB-2 и смотрят стрим по stream_ID
Теперь собственно вопросы:

1. Если добавляется новый Edge, то для того, что бы стрим попадал на него, необходимо его имя/IP вписать на Origin в файле WCS_HOME/conf/loadbalancing.xml и перезагрузить WCS. Но это же приведет к крешу живых стримов. Как добавить нужный Edge без перезагрузки Origin? Или я что-то сильно не в ту сторону копаю?
2. Если не все верно понял, то дайте направление, как при добавлении нового Edge сделать так, что бы он проигрывал нужный стрим по stream_ID, не взирая на то, на каком Origin этот стрим публикуется.
3. Может это можно сделать через REST API?

 

[Max]

Добрый день

Эта статья по статической CDN версии 1.0.
Такой тип CDN подойдет если есть один или несколько потоков, которые раздаются через фиксированное количество серверов.

Не так давно мы добавили динамическую CDN 2.0:
https://flashphoner.com/downloads/tmp/CDN_2.0-RU-draft.pdf

Здесь вы можете ввести новый сервер в любой момент времени.
В этой реализации CDN серверы общаются между собой по протоколу websoket.
Если добавляется Edge-сервер, он автоматически получает маршруты в системе.

Реализация CDN 2.0 доступна в последних сборках, начиная с 2723.

 

[Maksym]

Понял. Спасибо.

 

[Maksym]

Еще вопрос по конференции
Будет ли работать конференция, при настройке CDN 2.0
В том плане, что кол-во Origin/Edge динамичесское и они находятся за лоадбалансером.
P.S.: У вас получилось настроить ELB/ALB что бы подключаться к WCS, которые находятся за ними. А то у меня возникли трудности и пришлось настраивать nginx, который выступает сейчас в это роли

 

[Max]

Будет ли работать конференция, при настройке CDN 2.0

Если вопрос про Room API и пример Conference
https://wcs5-eu.flashphoner.com/client2/examples/demo/streaming/conference/conference.html
Тогда ответ - нет. Конференция сейчас построена на обмене статусами потоков и этот обмен происходит в пределах одного сервера.

Чтобы конференция заработала на CDN, нужно кастомное распределение потоков.
Например:
1. Пользователь получает соединение с WCS Origin - сервером и передает ID комнаты.
2. WCS сервер передает эту информацию на бэкэнд.

/connect
{
custom:{roomId:'12345'}
}

3. Этот же пользователь публикует поток на Origin. WCS сервер передает статус потока на бэкенд.

/StreamStatusEvent
{
name:'stream1'
status:PUBLISHING
}

4. Зритель может получать нотификации с бэкэнда и видеть какие стримы в данный момент доступны.
Бэкэнд может вызвать

/rest-api.data/send
{
operationId:'122222',
sessionId:'1111111',
payload:{
'name':'value'
}
}

В этом случае сообщение с произвольными данными будет доставлено клиенту. Например, там может быть имя потока, к которому есть доступ и зритель может проиграть этот поток, вызвав stream.play().
Так работает текущая конференция (пример Conference) в рамках одного сервера.
В случае нескольких серверов, все они должны работать с одним бэкендом, который знает
1) С каким сервером имеет соединение клиент.
2) Какой room ID клиент передал при подключении.
3) Какие стримы клиент публикует.
4) Какие зрители есть у этих стримов.

 

[Max]

У вас получилось настроить ELB/ALB что бы подключаться к WCS, которые находятся за ними

Мы не тестировали с Amazon ELB.
Если он поддерживает балансинг Websockets то должно работать.
Если не поддерживает, то лучше использовать Nginx или HA proxy.

 

[Maksym]

Сейчас, когда я начинаю публикацию стрима на ориджин, то этот стрим с эджа я могу посмотреть спустя 5 секунд, после подключения(первого, последующие подключения к этому же стриму проходят гораздо быстрее 2-3 сек.). Есть ли какая-то настройка, которая уменьшит время подключения к стриму на эджах?

 

[Max]

Есть две настройки:

periodic_fir_request=true
periodic_fir_request_interval=5000

Если добавить эти настройки в конфиг flashphoner.properties сервера Origin, то Origin будет запрашивать у браузера K-фрейм каждые 5 секунд, что должно улучшить время проключения видео. Чем чаще идут K-фреймы, тем быстрее начинается декодирование и появляется картинка.
При этом, слишком коротокие интервалы могут быть вредны. Браузер будет слишком часто отправлять K-фреймы и может забить полосу.

 

[Maksym]

Спасибо. Но думается мне, что тут надо либо принудительно заставить ориджины оповещать эджы о наличии стрима на этом ориджине,
либо запрарашиивать с эджей о наличии стримов на всех эджах.
Так как, по тому что я заметил - первое подключение срима на эдже происходит дольше на 30-40%% в отличии от того,
если я подключаюсь к этому же стриму, на этом же ориджтине, но второй и более раз(в течении 5 минут, больше не тестили)

 

[Max]

Но думается мне, что тут надо либо принудительно заставить ориджины оповещать эджы о наличии стрима на этом ориджине,
либо запрарашиивать с эджей о наличии стримов на всех эджах.

Это уже работает из коробки. Каждый из участников сети знает где находится стрим с нужным именем.

первое подключение стрима на эдже происходит дольше на 30-40%

При первом подключении к Edge серверу, Edge устанавливает подключение с Origin сервером и проходит полный цикл создания WebRTC соединения. Это занимает время.

Уменьшить это время можно только если делать рестриминг на Edge непосредственно после того, как стрим опубликован на Origin.
Но в этом случае теряется динамичность CDN (откат на версию CDN 1.0). Т.е. если у вас например 5 Origin серверов и 10 Edge севверов, то все потоки, попадающие на 5 серверов будут реплицироваться на 10. В результате будет 50 потокв на Edge серверах, т.е. даже на тех Edge серверах, где нет клиентов для просмотра этих потоков. Получается потоки будут ре-стримить впустую без зрителей.

В случае с CDN 2.0, зритель 'заказывает' поток и CDN нужно некоторое время чтобы доставить этот поток с нужного Origin-сервера. После этого последующие проключения проходят быстрее, т.к. поток уже 'прибыл' на Edge-сервер.