Резерв OTT/DVR

Важно

Бета-версия 2.1. Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности (Программа бета-тестирования).

Резерв OTT/DVR защищает зрителей OTT-раздачи от отказа узла или потока на нём. Узлы, которые раздают один канал, объединяются в OTT-группу — по одинаковому имени группы. Защита работает двумя способами:

  • переход во время просмотра — master-плейлист HLS называет проигрывателю резервные узлы, и при отказе своего узла проигрыватель продолжает с другого;

  • перенаправление при открытии — узел, который не может обслужить нового зрителя или запрос архива, отправляет их на узел, который может.

Поля, экран и подробности — OTT-группы; здесь — что спланировать.

Два узла OTT-группы получают один источник; master-плейлист узла A называет узел B резервом; когда поток или узел A отказывает, проигрыватель с поддержкой резерва переходит на узел B по его публичному адресу HTTPS; новый зритель или запрос архива к узлу A получает перенаправление 302 на узел B.

Отказ узла A: проигрыватель уходит на узел B, а новые зрители и запросы архива перенаправляются на него.

Когда нужен

  • Канал раздаётся по HLS, LL-HLS или DASH зрителям в интернете или в большой сети, и отказ одного сервера не должен останавливать просмотр.

  • Нужен архив (catch-up) даже тогда, когда на одном из узлов запись прерывалась.

Приёмники multicast защищает другой механизм — Горячий резерв multicast-выходов. От отказа источника защищают резервные входы (1. Источник: резервные входы), и их стоит держать на каждом узле группы.

Что защищено в этой бета-версии

Случай

Что происходит

Ограничения

Зритель смотрит, узел или поток отказал

Проигрыватель переходит на резервный узел из master-плейлиста

Одиночные потоки HLS с одним источником на узлах; проигрыватели с поддержкой резервных вариантов (Проигрыватели и резерв OTT/DVR)

Новый зритель открывает поток, который на узле не работает

Перенаправление 302 на узел, где поток в эфире

Любой проигрыватель; HLS, LL-HLS и DASH

Запрос архива за период, которого на узле нет

Перенаправление 302 на узел, где период записан; 404, если его нет нигде

Узел выбирается по диапазону архива; пропуски внутри диапазона узел обслуживает сам

Адаптивные наборы, LL-HLS и DASH защищены только перенаправлением при открытии: зритель, который уже смотрит, при отказе узла переоткрывает поток. Субтитры после перехода остаются на исходном узле.

Узлы и группа

  • Сколько. Два узла и больше. Master-плейлист называет каждому зрителю до двух резервных узлов, выбранных равномерно, поэтому зрители отказавшего узла распределяются по всем подходящим узлам группы (Мощность).

  • Домен и резерв. Все узлы — в одном домене Meshwork с включённым резервом Meshwork. Зритель приходит на резервный узел с пропуском — подписанным разрешением смотреть с другого узла. Подписывает его ключ просмотра, который узлы согласуют сами. Часы узлов должны расходиться не больше чем на 240 секунд.

  • Группа. У потока или адаптивного набора включён «OTT-резерв», а «Имя группы резерва» одинаково на всех узлах, где идёт канал.

  • Один источник. Переход во время просмотра работает между участниками, у которых доказан один источник: узлы берут тот же поток, а не каждый свой.

  • Версия. Участник — поток или набор узла в OTT-группе. Участник на узле версии до 2.1.0.456 зрителей не принимает: обновите все узлы группы.

  • Лимит подключений. «Макс. подключений, HTTP/HLS» логина действует на каждом узле отдельно: перенаправленный абонент может открыть столько же сессий и на другом узле.

Адреса узлов

Резервный узел проигрыватель открывает напрямую, по адресу, который этот узел объявляет, — мимо узла, с которого зритель пришёл, и мимо общего балансировщика.

  • Публичный адрес у каждого узла. Задайте «Имя хоста» HTTP-сервера каждого узла (Потоковый HTTP-сервер) — DNS-имя, доступное зрителям, например node-b.example.net. Без него узел объявляет свой адрес и только по HTTP.

  • Публичные зрители — публичные адреса. Зрителю с публичного адреса узел не предлагает резерв с частным адресом (проблема «У узла только частные адреса для резерва»).

  • HTTPS. Зрителю по HTTPS — в том числе за прокси, который передаёт X-Forwarded-Proto: https, — предлагаются только резервы с адресом HTTPS. Сертификат каждого узла должен быть выписан на его «Имя хоста» (проблема «У узла нет https-адреса для резерва»).

  • Прокси. Узел судит об адресе зрителя по соединению, X-Forwarded-For не читает. За прокси с частным адресом все зрители выглядят частными, и правило о публичных адресах не работает: давайте узлам публичные адреса.

  • Кеш и CDN. CDN годится перед основными адресами каждого узла; общее имя CDN на несколько узлов для резервных адресов не подходит (8.1. Резерв OTT/DVR и CDN).

Мощность

При отказе узла его зрители распределяются по остальным подходящим узлам группы: каждый зритель уходит на один из двух своих резервов, а резервы разным зрителям выбираются равномерно. Из N подходящих узлов каждый оставшийся получает около 1/(N−1) зрителей отказавшего. Закладывайте на каждом узле запас по CPU и сетевому интерфейсу на 1 + 1/(N−1) обычной нагрузки: двойную при двух узлах, полуторную при трёх.

Подходящим узел считается, только пока он одновременно:

  • предлагается резервом (столбец «Резерв» — «Может подменить») и отдавал живое окно — последние сегменты эфира в плейлисте — в последние 10 минут;

  • берёт тот же источник (переход «Общая шкала времени»);

  • отдаёт HLS на MPEG-TS со ступенями того же кодека (у адаптивного набора — с битрейтом не больше чем в 1,25 раза выше);

  • расходится по часам с этим узлом не больше чем на 240 секунд и держит ключ просмотра;

  • не перегружен.

Защита от перегрузки бережёт резервный узел, но мощности не добавляет. Нового зрителя другого узла узел не принимает, когда:

  • загрузка CPU или сети выше порогов ошибки в настройках алертов (Оповещатель);

  • достигнут «Лимит резервных сессий».

Своим зрителям узел не отказывает никогда (Защита от перегрузки). Получив отказ, проигрыватель идёт к своему второму резерву.

Если отказали оба резерва, зритель теряет поток. Отказы дольше 30 секунд — алерт кода 79 (reserve-ott-overload): запаса не хватает.

Архив

Для перенаправления к архиву учитывается архив протокола запроса: MPEG-TS для HLS, fMP4 для LL-HLS и DASH. Глубина архива на узлах может быть разной: запрос уходит на узел, который хранит большую часть периода. Узел выбирается по диапазону архива — от самой старой записи до самой новой; пропуски внутри своего диапазона узел обслуживает сам. Хранение архива — DVR: архив потока.

Проигрыватели

Переход во время просмотра доступен проигрывателям, которые умеют переключаться на резервные варианты: AVPlayer (Safari, iOS, tvOS), hls.js и подобные проигрыватели в браузере, ExoPlayer и Media3. VLC, проигрыватели на основе ffmpeg, mpv, Kodi и приставки без User-Agent резервных вариантов не получают и при отказе узла переоткрывают поток — тогда срабатывает перенаправление. Что проверено для каждого проигрывателя, звук и видео в браузерах — Проигрыватели и резерв OTT/DVR.

Для своего проигрывателя на hls.js: задайте короткие таймауты загрузки плейлиста и сегмента, около одной целевой длительности сегмента, — тогда переход занимает секунды.

Перед запуском

  • На экране «Резервы» у OTT-группы состояние «Есть резерв», без проблем; блок «Ключ просмотра OTT» — «Действует».

  • У каждого узла задано публичное «Имя хоста», сертификат HTTPS выписан на него.

  • Пробный отказ — пауза входа потока на одном узле — переводит проигрыватель на другой узел; новый зритель этого потока получает перенаправление.

  • Алерты кодов 70, 78 и 79 доставляются дежурному (Резервирование потоков).