---
title: Резервы
url: https://doc2.pstreamer.tv/ru/manual/webui/reserves.html
lang: ru
product: Perfect Streamer
version: 2.0.2.423
---

# Резервы

> **Важно**
>
> **Бета-версия 2.1.** Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности ([Программа бета-тестирования](../extras/beta.md#extras-beta)).

Резерв Meshwork — горячий резерв multicast-выходов между узлами одного домена. Несколько узлов получают один и тот же источник и держат одинаковые выходы на один multicast-адрес и порт; в эфир этот адрес отправляет только один из них — выбранный отправитель. Если отправитель отказывает или его останавливают, группу подхватывает другой узел, и приёмники продолжают получать поток с того же адреса без разрыва и без повторов.

Кроме групп multicast, резерв Meshwork собирает OTT-группы: OTT-раздачу одного канала на разных узлах (OTT-группы).

Состояние и настройки резерва этого узла собраны на экране «Резервы» области Meshwork ([Meshwork](meshwork.md#webui-fleet)). В демоверсии резерва нет: пункт меню недоступен.

## Группы резерва

Группу образуют выходы узлов домена, которые отправляют на один и тот же multicast-адрес и порт и у которых включено поле «Резерв Meshwork» (блок «Резерв Meshwork» редактора выхода). Участниками могут быть выходы UDP, RTP и Pro-MPEG ([UDP, RTP, Pro-MPEG и TCP](io/network.md#webui-io-network)). Выходы MPTS показываются в группе, но не резервируются.

Что нужно для группы:

- резерв включён на каждом узле с участником — поле «Резерв Meshwork» вкладки «Настройки» экрана «Резервы», затем перезапуск службы;
- у узлов заданы имя узла и домен ([Настройки сервера](administration.md#webui-server-settings)), и все они в одном основном домене: с узлами другого домена резерв не образуется;
- UDP-порт канала управления (по умолчанию 43975) открыт между узлами домена;
- у выхода — multicast-адрес и интерфейс отправки «Multicast egress interface»;
- у потоков участников одинаковые «Тип потока» и признак скремблированного канала: по ним узлы сравнивают источники.

Канал управления резерва защищён ключом домена Meshwork, поэтому у всех участников он должен быть одинаковым. Узлы с разными ключами друг друга не принимают: в таблице узлов это видно как «Ошибка аутентификации» и «Не совпадает» в столбце «Ключ».

**Один ли источник.** Узлы непрерывно сравнивают потоки своих участников по меткам времени и содержимому. Итог показывается в столбце «Источник»: «Тот же источник», «Тот же сигнал» (те же метки времени, другое кодирование), «По метке», «Свои метки времени», «Не доказан», «Дескремблирование различается» или «Ожидание», пока данных мало. Если вход потока сам ставит метки времени (файл, RTMP, RTSP, транскодер, MPTS-мультиплексор), сравнить их нельзя: задайте одинаковое поле «Метка источника для резерва» в редакторе потока на всех участниках.

## Кто отправляет

В режиме по умолчанию — поле «Передаёт только выбранный отправитель (reserve-gate)» вкладки «Настройки», включено — в каждой группе отправляет только выбранный узел, а остальные участники держат поток наготове. Если это поле выключить, резерв работает в режиме наблюдения: участники проверяются и показываются, но отправляют все. Поле читается при запуске службы; задайте его одинаково на всех узлах домена.

Отправителя выбирают голосованием узлы домена с включённым резервом. После запуска узел сначала проходит карантин: не голосует и не претендует, пока не услышит голосующих (не дольше 15 секунд). Группа переходит к другому участнику сама, когда:

- узел отправителя или его канал управления перестаёт отвечать;
- выход отправителя перестаёт отправлять;
- вход отправителя замолчал или перешёл на резервный, а у другого участника поток лучше.

Если источник пропал у всех участников сразу, группа не переключается. Узел, который останавливают штатно, сначала передаёт свои группы. После частых переключений автоматическое переключение группы приостанавливается — группа «заморожена» (алерт кода 72, `reserve-frozen`, [Резервирование потоков](../extras/alert_codes.md#extras-alert-codes-reserve)).

Отправителя можно выбрать и вручную: кнопка «Перенести…» в строке группы. Текущий и новый отправитель переключаются в один и тот же момент шкалы группы, без разрыва и без повтора; выход нового участника должен быть открыт и отправлять. Поле «Приоритет резерва» выхода (0–9, больший первым) задаёт предпочтительного участника, а «Вернуть через (с)» — через сколько секунд готовности такого участника группа вернётся к нему (0 — никогда, группа остаётся, пока её не перенесут).

**Домен из двух узлов.** Когда голосуют только два узла, перезапущенный узел забирает группу у второго не раньше чем через 30 секунд после своего запуска, и только если второй узел действительно пропал из Meshwork. Третий узел с включённым резервом тоже голосует и снимает это ожидание; на нём не обязательно держать участников.

Каждое переключение записывается в журнал событий потока и видно на дорожке «Резерв» графиков статистики ([Дорожка «Резерв»](streams.md#webui-stream-stats-reserve)).

## Задержка выхода

Чтобы переключение было бесшовным, резервные выходы отправляют поток с фиксированной задержкой относительно входа — это шкала времени группы. Её задаёт поле «Задержка выхода (мс)» вкладки «Настройки»: от 500 до 2500, по умолчанию 500. Задайте одно значение на всех участниках группы.

Новое значение применяется к выходу, когда он открывается заново: при запуске или после паузы выхода на несколько секунд и пуска. Работающий выход продолжает с прежней задержкой, и экран «Резервы» показывает, какое значение применится. Если резервный участник отстаёт от отправителя, отправитель сам сдвигает шкалу группы позже — не больше чем на 300 мс сверх заданной задержки и не дальше 2500 мс; когда отставание проходит, задержка возвращается по 5 мс каждые 5 секунд.

## Второй путь и Pro-MPEG

Участник с выходом RTP или Pro-MPEG может отправлять и второй путь по SMPTE ST 2022-7 ([Требования к сети для ST 2022-7](../planning/st2022_7.md#planning-st2022-7)). Отправитель группы отправляет оба пути. Задайте второй путь одинаково на всех участниках, включая «Path 2 multicast egress interface»: по второму пути узлы тоже следят за отправителем. Если второй путь участника отличается, группа показывает проблему «Путь 2 различается у участников» — переключение на него перенесёт или уберёт второй путь у приёмников.

Если вход потока сам принимает два пути, задержка выхода должна быть не меньше окна ожидания второго пути («Path skew (ms)» входа) плюс 400 мс. Иначе переключение при настоящей потере входа не будет бесшовным, и группа показывает проблему «Задержка резерва короче ожидания слияния».

Выход Pro-MPEG участвует в выборе отправителя только при определённой матрице FEC и без мультиплексирования и парольной фразы ([выход Pro-MPEG в группе резерва](io/network.md#webui-io-prompeg-reserve)).

## OTT-группы

OTT-группа объединяет OTT-раздачу (HLS, LL-HLS, DASH) одного канала на разных узлах домена: потоки или адаптивные наборы с одним и тем же именем группы. Участники находят друг друга и проверяются, а зритель HLS, чей узел отказал, продолжает смотреть с другого участника, не выходя из плеера (Переход зрителей на другой узел).

**Как включить.** Резерв Meshwork на узле должен быть включён (Группы резерва). Затем у потока — на вкладке «Поток» редактора, блок «Резерв Meshwork», — или в окне адаптивного набора включите поле «OTT-резерв» и задайте «Имя группы резерва»:

- до 64 символов `A-Z a-z 0-9 _ . -`, регистр важен; одно и то же имя на всех узлах, где идёт канал;
- пустое поле — именем группы служит имя OTT: «Имя потока в URL» у потока, «Имя OTT» у набора. Без обоих имён участник другим узлам не объявляется;
- изменение применяется в течение секунды и OTT-раздачу потока не перезапускает.

Участником может быть только SPTS-поток с включённой OTT-раздачей; у MPTS-потока поле не действует. Адаптивный набор — один участник, его ступени — потоки набора с видео. Источники потоков сравниваются так же, как у групп multicast, поэтому «Тип потока» и «Скремблированный канал» у участников должны совпадать; адаптивные наборы сопоставляются по имени. Чтобы другие узлы обращались к OTT-серверу этого узла по имени, задайте «Имя хоста» HTTP-сервера ([Потоковый HTTP-сервер](administration.md#webui-http-server)): без него другим узлам передаётся адрес узла и только по HTTP, если сертификат узла не выписан на этот адрес.

**Карточка OTT-группы** на вкладке «Состояние» показывает имя группы, форматы, которые она отдаёт («Отдаёт: …»), состояние, итог сравнения источника и проблемы. Состояния:

- «Есть резерв» — участник на другом узле может подменить этот;
- «Без защиты» — на других узлах есть участники, но ни один не может подменить этот;
- «Ждёт ключа» — у узла ещё нет согласованного ключа домена;
- «Не участник» — OTT-резерв включён, но поток или набор не участвует: нет имени группы, неверное имя, поток MPTS или ещё нет домена; причина — в проблемах;
- «Имя повторяется» — у двух потоков или наборов этого узла одно имя группы, и ни один из них не объявлен.

У каждого участника в карточке: «Резерв» — «Может подменить» или «Не предлагается» с первой непройденной проверкой, «Переход зрителя» — как зритель перейдёт на этого участника («Выровнен», «Общая шкала времени» или «С нуля»), «Эфир» и «Архив». Участник на узле версии до 2.1.0.456 зрителей не принимает: если остальные проверки пройдены, в столбце «Резерв» указано «Его версия пока не умеет принимать зрителей». Если все участники других узлов такие, группа остаётся без защиты.

Проблемы OTT-группы:

| Проблема | Что означает |
| --- | --- |
| «Нет имени группы» | Ни «Имени группы резерва», ни имени OTT: участник не объявляется. |
| «Неверное имя резерва» | Имя с недопустимыми символами или длиннее 64 символов, прочитанное из файла настроек. Пока его не исправят, поток не участник; имя OTT его не заменяет. |
| «Нет резерва на другом узле» | Ни один участник другого узла 60 секунд не может подменить этот: на других узлах нет такого имени или участники не проходят проверки (подробности — в описании проблемы). Узел поднимает алерт кода 70 (`reserve-unprotected`). |
| «Форматы OTT различаются» | Участники отдают разные форматы OTT. |
| «Нет имени хоста OTT-сервера» | Не задано «Имя хоста» HTTP-сервера: другим узлам передаётся адрес узла, и только по HTTP, если сертификат узла не выписан на этот адрес. Это информация, а не ошибка. |
| «Неверное имя хоста OTT-сервера» | «Имя хоста» HTTP-сервера — не имя хоста: узел не сообщает другим узлам адрес своего OTT-сервера. |
| «Часы узла сильно расходятся» | Часы узла другого участника расходятся с часами этого больше чем на 240 секунд: такой участник подменить этот не может. |
| «Ключа просмотра ещё нет» | У узла есть участник OTT-резерва, но ключа просмотра домена ещё нет: зрители этого узла на другие узлы не переходят, а резервных зрителей он не принимает. Через 2 минуты, если ключ может прийти с другого узла, узел поднимает алерт кода 78 (`reserve-view-key`). |
| «Ключ просмотра не доходит до этого узла» | Ключ есть у других узлов, но до этого узла не доходит; проверьте связь между узлами домена (алерт кода 78). |
| «Узел не принял ключ просмотра» | Узел с участником OTT-резерва 10 минут не подтверждает действующий ключ (алерт кода 78). |
| «Слишком много ключей просмотра» | Узел хранит больше четырёх ключей просмотра (алерт кода 78). |
| «Перегружен для резервных зрителей» | Узел отказывает новым резервным зрителям: CPU или сеть на пороге либо достигнут «Лимит резервных сессий» (Защита от перегрузки). |
| «Лестницы битрейтов различаются» | Для части ступеней этого участника у участника другого узла нет ступени с тем же кодеком и подходящим битрейтом: на этих ступенях резерва нет. Участник, у которого 60 секунд не подходит ни одна ступень, не предлагается: в столбце «Резерв» указано «Ни одна его ступень не подходит к ступеням этого узла». |
| «У узла нет https-адреса для резерва» | Узел участника не сообщает адрес HTTPS своего OTT-сервера: зрителям по HTTPS он резервом не предлагается. Задайте на том узле «Имя хоста» HTTP-сервера, на которое выписан его сертификат. |
| «У узла только частные адреса для резерва» | Узел участника сообщает только частные адреса: зрителям с публичных адресов он резервом не предлагается. |

## Переход зрителей на другой узел

С версии 2.1.0.458 master-плейлист живого HLS у участника OTT-группы называет до двух других узлов группы резервными вариантами каждой ступени — после собственных. Плеер, который поддерживает резервные варианты, сам переходит на резервный узел, когда узел зрителя перестаёт отдавать живое окно; зритель из плеера не выходит. Если поток узла остановился или завис, а резерв в эфире, узел сразу отвечает такому зрителю `404` на плейлист, и плеер переходит, не дожидаясь своих таймаутов. Зрители отказавшего узла распределяются между его резервами.

**Плееры.** Резервные варианты получают плееры, которые умеют ими пользоваться: AVPlayer (Safari, iOS, tvOS), hls.js и подобные плееры в браузере, ExoPlayer и Media3. Плееры, которые так переходить не умеют (VLC, mpv, Kodi, GStreamer, плееры на основе ffmpeg, приставки без User-Agent), получают master-плейлист без резервных строк и работают как раньше; сколько таких master-плейлистов выдано, показывает строка «Мастер-плейлисты без резерва» блока «Ключ просмотра OTT». Что получает каждый проигрыватель и что проверено — [Проигрыватели и резерв OTT/DVR](../extras/ott_players.md#extras-ott-players); что учесть в кеше и CDN — [8.1. Резерв OTT/DVR и CDN](../extras/ott_caching.md#extras-ott-cdn-reserve). Собственное приложение оператора может запросить резервы параметром `rsv=1` в адресе master-плейлиста или отказаться от них параметром `rsv=0`.

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

**Какой узел становится резервом.** Узел называется резервом, только если участник на нём может подменить участник этого узла (столбец «Резерв» — «Может подменить») и в момент запроса:

- недавно отдавал живое окно и отдаёт HLS;
- его часы расходятся с часами этого узла не больше чем на 240 секунд;
- у узлов общий ключ просмотра (ниже);
- узел не перегружен (Защита от перегрузки);
- у него есть ступень с тем же кодеком;
- зритель может до него достучаться тем же способом: зрителю по HTTPS нужен адрес HTTPS резервного узла, зрителю с публичного адреса — публичный адрес. Поэтому задайте «Имя хоста» HTTP-сервера на каждом узле ([Потоковый HTTP-сервер](administration.md#webui-http-server)).

**Ключ просмотра.** Резервный узел принимает зрителя другого узла по пропуску, привязанному к сессии зрителя, его узлу, потоку и времени. Пропуска подписываются ключом просмотра, общим для узлов домена с участниками OTT-резерва. Настраивать ничего не нужно: ключ создаётся сам, меняется каждые 7 дней и хранится только в памяти; его состояние показывает блок «Ключ просмотра OTT» на вкладке «Состояние», а кнопка «Сменить ключ просмотра» меняет его вручную. Если ключ не доходит до узла, узел поднимает алерт кода 78 (`reserve-view-key`).

**Ограничения этой бета-версии.** Резервные варианты получают только одиночные потоки, у которых участники на разных узлах берут один источник (переход «Общая шкала времени»). Адаптивные наборы, LL-HLS и DASH объединяются в группы и показываются, но резервов в master-плейлисте и манифесте у них пока нет; таких зрителей защищает только перенаправление при открытии (Перенаправление зрителей). Субтитры после перехода остаются на исходном узле. Master-плейлист архива и catch-up резервов не называет: архив других узлов зритель получает перенаправлением.

## Перенаправление зрителей

С версии 2.1.0.459 узел перенаправляет зрителя на другой узел OTT-группы (ответ `302`) уже при открытии master-плейлиста HLS и LL-HLS или манифеста DASH. Перенаправление не требует поддержки от плеера: ему следуют все плееры, в том числе VLC и приставки, и для DASH это единственная защита эфира в этой бета-версии. Работает для потоков и адаптивных наборов с включённым «OTT-резервом».

**Catch-up из архива других узлов.** Если зритель просит прошедший период, которого в архиве этого узла нет, узел отправляет его на узел группы, который хранит большую часть периода; глубина архива на узлах может быть разной. Если период не хранит ни один узел, зритель получает `404` (`reserve: no recording for this period`) — раньше пустой плейлист. Для HLS учитывается архив MPEG-TS, для LL-HLS и DASH — архив fMP4.

Переход к архиву другого узла выбирается по диапазону архива — от самой старой записи до самой новой. Если начало запрошенного периода попадает в диапазон архива этого узла, зрителя обслуживает сам узел, даже если на этот момент в его архиве пропуск (например, пока не работал вход): пропуски внутри диапазона на другой узел не переводятся.

**Новые зрители потока, который здесь не работает.** Зрителя, открывающего поток, который на этом узле не работает — остановлен или на паузе, в ошибке, его вход упал или картинки ещё нет, — узел отправляет на узел, где этот поток в эфире. Поток, который только запускается, не затрагивается: как только в его живом окне появился сегмент, зрителей обслуживает этот узел. Узел, перезапущенный с потоком на паузе, не перенаправляет новых зрителей, пока поток хотя бы раз не поработает.

**Сначала логин.** У потоков с включённым «OTT-резервом» логин зрителя проверяется раньше всего: при неверном пароле ответ всегда `403`, даже если поток не работает. Остальные потоки отвечают как раньше.

**Лимит подключений.** «Макс. подключений, HTTP/HLS» логина ([Пользователь: добавление и изменение](configure.md#webui-user-editor)) действует на каждом узле отдельно: перенаправленный абонент может открыть столько же сессий и на другом узле.

Узел выбирается так же, как резерв для перехода (Переход зрителей на другой узел), но плеер и уровень перехода не проверяются, поэтому подходят и адаптивные наборы, и LL-HLS. Сеть зрителя при выборе узла для catch-up не учитывается: другой узел должен быть доступен зрителю тем же способом — для HTTPS нужен адрес HTTPS.

## Защита от перегрузки

Резервный узел принимает нового зрителя другого узла (резервного зрителя), только пока у него есть запас: загрузка CPU хоста и сетевого интерфейса ниже порогов ошибки этих ресурсов в настройках алертов ([Оповещатель](administration.md#webui-alerter)), а число резервных сессий не достигло «Лимита резервных сессий» на вкладке «Настройки» (0 — без лимита, применяется сразу). Порог 0 отключает свою проверку. Своим зрителям и уже открытым резервным сессиям узел не отказывает никогда. Получив отказ, плеер переходит к следующему резерву, а перегруженный узел другие узлы на время перестают называть резервом.

Блок «Защита OTT от перегрузки» на вкладке «Состояние» показывает, есть ли запас, причины перегрузки, запас по сети и сессиям, пороги, число резервных сессий и отказов. Пока причина держится, у OTT-групп узла есть проблема «Перегружен для резервных зрителей». Если узел отказывает новым резервным зрителям 30 секунд подряд, он поднимает алерт кода 79 (`reserve-ott-overload`); алерт снимается после 60 секунд без отказов.

## Экран «Резервы»

Экран показывает группы, в которых есть участник этого узла; остальные узлы показывают свои. Если на узле резерв выключен, экран объясняет, как его включить, и даёт ссылку «Открыть настройки».

**Вкладка «Состояние».**

- Плитки «Группы», «Группы с проблемами», «Ошибки», «Предупреждения», «Узлы на канале» и «Группы по состоянию».
- Блок «Канал управления этого узла»: состояние канала, часы («Синхронизированы» или «Не синхронизированы»), отпечаток ключа, голосующие узлы, карантин и «Тайминги» — перехват, окно и задержка; счётчики «OTT-группы» и «Не отправлено отчётов» (отчёты, которые не поместились в датаграмму или отложены на следующий круг).
- Таблица «Узлы»: по строке на каждый узел канала — «Канал», «Ключ», «RTT, мс», «Сдвиг часов, мс», «Потери, %», «Последний ответ» и «Версия».
- Список «Группы». У группы — состояние, роль этого узла, отправитель и номер выборов, участники с приоритетом, ролью, признаком «Вещает» и итогом сравнения источника, блок «Выход этого узла» и список проблем. Состояния группы: «Одна» (другие участники о себе не сообщают), «Формируется» (участники найдены и проверяются), «Расхождение» (у участников разный тип потока или признак скремблированного канала) и «Конфликт» (в группу отправляет кто-то, кто в неё не входит).

Роль этого узла в группе: «Отправитель», «Резерв», «Претендует», «Один», «Не готов», «Карантин», «Ждёт ключ домена», «Отправитель без подтверждения», «Отстранён», «Освобождён», «Передаёт роль», «Принимает роль», «Не проверен» или «Нет».

Блок «Выход этого узла» показывает, открыт ли выход («Открыт: этот узел передаёт» или «Закрыт: передаёт другой участник»), выровнен ли он по шкале группы, запас, задержку, FEC группы у выхода Pro-MPEG и счётчики датаграмм. Растущие счётчики опоздавших датаграмм, переполнений и ошибок отправки подсвечиваются; отстающий резервный участник помечается: переключение на него не будет бесшовным.

**Вкладка «Настройки».** Поля «Резерв Meshwork», «Передаёт только выбранный отправитель (reserve-gate)», «UDP-порт канала управления» (1024–65535, по умолчанию 43975), «Интерфейс канала управления» (по умолчанию «Все интерфейсы»), «Задержка выхода (мс)», «Вернуть через (с)», «Лимит резервных сессий» (Защита от перегрузки) и «Интерфейс наблюдателя» (для узла, который только голосует; в этой версии ещё не используется). Включение резерва, режим, порт и интерфейс читаются при запуске службы: изменения вступают в силу после перезапуска.

## Проблемы группы

| Проблема | Что означает |
| --- | --- |
| «Конфликт адреса» | В группу отправляет источник, который в неё не входит (алерт кода 71, `reserve-address-conflict`). |
| «Два отправителя» | В группу одновременно отправляют два участника (алерт кода 67, `reserve-two-senders`). В режиме наблюдения это предупреждение: там отправляют все. |
| «Настройки различаются» | У участников разные «Тип потока» или признак скремблированного канала. |
| «Содержимое противоречит настройкам» | Поток участника не соответствует его настройкам: например, есть видео при типе потока «Только аудио». Решают настройки. |
| «Источник не доказан» | Источник участника 30 секунд не удаётся сопоставить (алерт кода 68, `reserve-source-mismatch`). |
| «Дескремблирование различается» | Открытые части потоков совпадают, а содержимое — нет: один из узлов не дескремблирует. |
| «Свои метки времени, нет метки источника» | Вход участника сам ставит метки времени: задайте одинаковую «Метку источника для резерва». |
| «Участник не подтверждён» | Узел объявляет участника, но его отчёты до этого узла не доходят. |
| «Два выхода этого узла» | Два выхода одного узла отправляют в одну группу. |
| «Не задан интерфейс multicast» | У выхода-участника не задан интерфейс отправки. |
| «Узел не видит группу» | Этот узел не может наблюдать группу; подробности — в описании проблемы. |
| «MPTS показан, но не резервируется» | Выход MPTS в группе показывается, но не резервируется. |
| «Вход DVB, ещё не проверен» | Поток идёт со входа DVB. |
| «Путь 2 различается у участников» | Второй путь участника идёт на другой адрес или не задан. |
| «Задержка резерва короче ожидания слияния» | Задержка выхода меньше окна ожидания второго пути входа плюс 400 мс. |
| «Участник ProMPEG без гейта: матрица или packets» | Выход Pro-MPEG не участвует в выборе отправителя: «столбцы × строки» — не степень двойки или в датаграмме не 7 TS-пакетов. Он отправляет всегда, рядом с отправителем группы, и группу не подхватывает. |
| «Участник ProMPEG без гейта: мультиплексирование или пароль» | То же, у выхода с мультиплексированием или парольной фразой. |
| «Матрица FEC ProMPEG различается» | Матрица FEC участника отличается или его версия её не сообщает: переключение на него меняет матрицу у приёмников. |

Алерты резерва — коды 66–74, 78 и 79 — перечислены в [Резервирование потоков](../extras/alert_codes.md#extras-alert-codes-reserve).