--- title: Горячий резерв multicast-выходов url: https://doc2.pstreamer.tv/ru/manual/planning/multicast_reserve.html lang: ru product: Perfect Streamer version: 2.0.2.423 --- # Горячий резерв multicast-выходов > **Важно** > > **Бета-версия 2.1.** Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности ([Программа бета-тестирования](../extras/beta.md#extras-beta)). Горячий резерв защищает приёмники multicast — приставки, телевизоры, вещательные приёмники — от отказа узла. Несколько узлов держат одинаковые выходы на один multicast-адрес и порт. Отправляет в группу один из них, а при его отказе группу подхватывает другой — без разрыва и без повторов, на том же адресе. Два слова этой страницы: **участник** — выход узла в группе резерва; **отправитель** — узел, который сейчас отправляет в группу. Поля и экран описаны в [Резервы](../webui/reserves.md#webui-fleet-reserves); здесь — что спланировать заранее. ![Два узла домена Meshwork получают один источник и держат выход на одну группу 239.0.0.10:1234; узел A был отправителем и отказал, узел B подхватывает группу в той же точке шкалы времени; приёмники остаются на той же группе; третий узел только голосует.](../../_images/reserve_multicast.svg) *Узел A отказал: группу подхватывает узел B, приёмники остаются на том же адресе.* ## Когда нужен - Приёмники принимают канал по UDP, RTP или Pro-MPEG multicast и не умеют сами переключаться на другой адрес: IPTV оператора, гостиничное ТВ, вещательная сеть. - Серверы нужно обслуживать по очереди, без перерыва в эфире: узел, который останавливают штатно, сначала передаёт свои группы. Для зрителей OTT нужен другой механизм — [Резерв OTT/DVR](ott_reserve.md#planning-ott-reserve). От потерь в сети защищают протокол и ST 2022-7 ([Резервирование: что от чего защищает](redundancy.md#planning-redundancy)). ## Узлы - **Сколько.** Два узла с участниками; лучше три узла с включённым резервом. В домене из двух таких узлов перезапущенный узел забирает группу только через 30 секунд и только если второй действительно пропал. Третий узел, даже без своих каналов, голосует и снимает это ожидание ([Кто отправляет](../webui/reserves.md#webui-fleet-reserves-sender)). - **Мощность.** Резервный узел держит поток наготове: принимает источник и обрабатывает его так же, как отправитель. Каждый узел рассчитывайте на полную нагрузку своих групп. - **Домен.** Все узлы — в одном домене Meshwork: том, что задан узлу как основной ([Настройки сервера](../webui/administration.md#webui-server-settings)), с одинаковым ключом домена. С узлами другого домена резерв не образуется. - **Часы.** Время на узлах синхронизировано (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](hotels/network.md#planning-hotels-igmp)). Подключите узлы к разным коммутаторам ядра: отказ общего коммутатора резерв узлов не спасает. - **Полоса.** Каждый узел принимает источник целиком; в сеть приёмников группу отправляет один узел. ## Кто отправляет и задержка - **Только выбранный отправитель** (по умолчанию). В группу отправляет один узел, другие держат поток наготове. - **Режим наблюдения.** Отправляют все, резерв только проверяет участников. Подходит для пробного запуска рядом с работающей схемой. - **Задержка выхода.** Чтобы переключение было бесшовным, выходы группы отправляют поток с фиксированной задержкой от входа: от 500 до 2500 мс, по умолчанию 500. Это добавочная задержка канала для приёмников; задайте одно значение на всех участниках ([Задержка выхода](../webui/reserves.md#webui-fleet-reserves-delay)). - **Задержка и второй путь входа.** Если вход принимает два пути ST 2022-7, «Задержка выхода» должна быть не меньше окна второго пути («Path skew (ms)» входа) плюс 400 мс: иначе переключение при настоящей потере входа не будет бесшовным. - **Предпочтительный узел.** «Приоритет резерва» выхода задаёт, какой участник предпочтителен, а «Вернуть через (с)» — вернётся ли группа к нему после восстановления. ## Pro-MPEG и второй путь - Выход Pro-MPEG участвует в выборе отправителя, если «столбцы × строки» — степень двойки, в датаграмме 7 TS-пакетов, нет мультиплексирования и парольной фразы, а матрица одинакова на всех участниках. Иначе он отправляет всегда, рядом с отправителем, и группу не подхватывает ([выход Pro-MPEG в группе резерва](../webui/io/network.md#webui-io-prompeg-reserve)). - Второй путь ST 2022-7 отправляет отправитель группы. Задайте его одинаково на всех участниках, включая `path2-mcast-if`: по второму пути узлы тоже следят за отправителем ([Требования к сети для ST 2022-7](st2022_7.md#planning-st2022-7)). ## Ограничения - Выходы MPTS показываются в группе, но не резервируются. - Если источник пропал у всех участников сразу, группа не переключается: резерв узлов не заменяет резервные входы ([1. Источник: резервные входы](redundancy.md#planning-redundancy-source)). - После частых переключений автоматическое переключение группы приостанавливается (алерт кода 72, `reserve-frozen`). - В демоверсии резерва нет. ## Перед запуском - На экране «Резервы» каждого узла все узлы домена видны в таблице «Узлы» с подтверждённым ключом, часы — «Синхронизированы». - У каждой группы итог сравнения источника — «Тот же источник» или «Тот же сигнал», без проблем. - Пробное переключение кнопкой «Перенести…» в строке группы проходит без перерыва на приёмнике; на дорожке «Резерв» статистики потока видно событие переключения. - Алерты кодов 66–74 доставляются дежурному ([Резервирование потоков](../extras/alert_codes.md#extras-alert-codes-reserve)).