Горячий резерв multicast-выходов¶
Важно
Бета-версия 2.1. Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности (Программа бета-тестирования).
Горячий резерв защищает приёмники multicast — приставки, телевизоры, вещательные приёмники — от отказа узла. Несколько узлов держат одинаковые выходы на один multicast-адрес и порт. Отправляет в группу один из них, а при его отказе группу подхватывает другой — без разрыва и без повторов, на том же адресе.
Два слова этой страницы: участник — выход узла в группе резерва; отправитель — узел, который сейчас отправляет в группу. Поля и экран описаны в Резервы; здесь — что спланировать заранее.
Узел A отказал: группу подхватывает узел B, приёмники остаются на том же адресе.¶
Когда нужен¶
Приёмники принимают канал по UDP, RTP или Pro-MPEG multicast и не умеют сами переключаться на другой адрес: IPTV оператора, гостиничное ТВ, вещательная сеть.
Серверы нужно обслуживать по очереди, без перерыва в эфире: узел, который останавливают штатно, сначала передаёт свои группы.
Для зрителей OTT нужен другой механизм — Резерв OTT/DVR. От потерь в сети защищают протокол и ST 2022-7 (Резервирование: что от чего защищает).
Узлы¶
Сколько. Два узла с участниками; лучше три узла с включённым резервом. В домене из двух таких узлов перезапущенный узел забирает группу только через 30 секунд и только если второй действительно пропал. Третий узел, даже без своих каналов, голосует и снимает это ожидание (Кто отправляет).
Мощность. Резервный узел держит поток наготове: принимает источник и обрабатывает его так же, как отправитель. Каждый узел рассчитывайте на полную нагрузку своих групп.
Домен. Все узлы — в одном домене Meshwork: том, что задан узлу как основной (Настройки сервера), с одинаковым ключом домена. С узлами другого домена резерв не образуется.
Часы. Время на узлах синхронизировано (NTP); узел с несинхронизированными часами поднимает алерт кода 74 (
reserve-clock-unsynced).Версия. Резерв — возможность версии 2.1; в 2.0.2 его нет, второй сервер там держат холодным резервом.
Источник¶
Узлы сравнивают потоки участников по меткам времени и содержимому и переключаются только между участниками с доказанно одним источником. Поэтому:
оба узла получают тот же источник: тот же multicast со спутникового приёмника, тот же поток от кодера;
у потоков одинаковые «Тип потока» и признак скремблированного канала;
если вход сам ставит метки времени (файл, RTMP, RTSP, транскодер, мультиплексор MPTS), сравнить источники нельзя — задайте одинаковую «Метку источника для резерва» на всех участниках;
вход DVB группа помечает проблемой «Вход DVB, ещё не проверен»: резерв с такими входами в бете не проверялся — проверьте переключение на своей схеме до эфира.
Сеть¶
Канал управления. UDP-порт 43975 (по умолчанию) открыт между всеми узлами домена. По нему узлы голосуют и следят друг за другом; он защищён ключом домена.
Адреса. У всех участников группы — один и тот же multicast-адрес, порт и интерфейс отправки «Multicast egress interface» в сети приёмников.
Приёмники — по группе, не по отправителю. Каждый узел отправляет со своего адреса, поэтому после переключения группа приходит с другого адреса источника. (ASM — подписка на группу от любого источника, SSM — только от перечисленных.)
Приёмники ASM (IGMPv2 или IGMPv3 без списка источников) работают.
Приёмники SSM (IGMPv3 INCLUDE) — только если в подписке перечислены адреса всех узлов группы.
Вход Perfect Streamer, который принимает такую группу: «SSM source address» и «Path 2 SSM source address» — пустые.
Общий адрес или виртуальный IP не нужен.
Коммутаторы. IGMP snooping и один querier (устройство, которое опрашивает подписчиков IGMP) в сети приёмников, как для любого multicast (IGMP snooping и querier). Подключите узлы к разным коммутаторам ядра: отказ общего коммутатора резерв узлов не спасает.
Полоса. Каждый узел принимает источник целиком; в сеть приёмников группу отправляет один узел.
Кто отправляет и задержка¶
Только выбранный отправитель (по умолчанию). В группу отправляет один узел, другие держат поток наготове.
Режим наблюдения. Отправляют все, резерв только проверяет участников. Подходит для пробного запуска рядом с работающей схемой.
Задержка выхода. Чтобы переключение было бесшовным, выходы группы отправляют поток с фиксированной задержкой от входа: от 500 до 2500 мс, по умолчанию 500. Это добавочная задержка канала для приёмников; задайте одно значение на всех участниках (Задержка выхода).
Задержка и второй путь входа. Если вход принимает два пути ST 2022-7, «Задержка выхода» должна быть не меньше окна второго пути («Path skew (ms)» входа) плюс 400 мс: иначе переключение при настоящей потере входа не будет бесшовным.
Предпочтительный узел. «Приоритет резерва» выхода задаёт, какой участник предпочтителен, а «Вернуть через (с)» — вернётся ли группа к нему после восстановления.
Pro-MPEG и второй путь¶
Выход Pro-MPEG участвует в выборе отправителя, если «столбцы × строки» — степень двойки, в датаграмме 7 TS-пакетов, нет мультиплексирования и парольной фразы, а матрица одинакова на всех участниках. Иначе он отправляет всегда, рядом с отправителем, и группу не подхватывает (выход Pro-MPEG в группе резерва).
Второй путь ST 2022-7 отправляет отправитель группы. Задайте его одинаково на всех участниках, включая
path2-mcast-if: по второму пути узлы тоже следят за отправителем (Требования к сети для ST 2022-7).
Ограничения¶
Выходы MPTS показываются в группе, но не резервируются.
Если источник пропал у всех участников сразу, группа не переключается: резерв узлов не заменяет резервные входы (1. Источник: резервные входы).
После частых переключений автоматическое переключение группы приостанавливается (алерт кода 72,
reserve-frozen).В демоверсии резерва нет.
Перед запуском¶
На экране «Резервы» каждого узла все узлы домена видны в таблице «Узлы» с подтверждённым ключом, часы — «Синхронизированы».
У каждой группы итог сравнения источника — «Тот же источник» или «Тот же сигнал», без проблем.
Пробное переключение кнопкой «Перенести…» в строке группы проходит без перерыва на приёмнике; на дорожке «Резерв» статистики потока видно событие переключения.
Алерты кодов 66–74 доставляются дежурному (Резервирование потоков).
