Отдельный модуль при резервировании вещания

"...Для резервирования планируем схему "зеркало" ("Основной" + "Ведущий"). Для автоматического переключения эфира при падении основного сервера нам нужен какой-то отдельный модуль? Или это зашито в логику работы двух экземпляров вещательных программ?..."

Схемы резервирования описаны  здесь.  

Действительно, нужен отдельный модуль, который занимается переключением сигнала основного сервера на сигнал резервного в случае аварии. Для SDI-сигнала и IP-потока схемы немного отличаются. В случае вещания SDI "отдельный модуль" состоит из коммутатора резерва (переключает сигналы) и устройства SLControlBox101 (подаёт сигнал на переключение).  В случае IP-потоков "отдельный модуль" представляет собой отдельный сервер, который и отслеживает потоки, и производит переключение с основного потока на резервный.

Входной SRT-поток как резерв для SDI-сигнала

"...

Каким образом в программе OnAir3 можно организовать резерв по входу, если основным источником в настоящий момент у нас SDI-сигнал (плата FD722), а в качестве резерва планируется входной SRT-поток? Какие компоненты и лицензии дополнительно понадобятся?..."

Дополнительные лицензии не требуются.

Порядок настройки:

1)Для приёма SRT-потока нужно установить ПО плагина IPOut. Инструкция по установке, ссылка на инсталлятор здесь.

2)Закрыть программу OnAir3.

"Бесшовный" переход на резерв в случае выхода из строя основного сервера

"...Может можно будет сделать "бесшовный" переход на резерв в случае выхода из строя основного вещательного сервера? Используем Форвард ТС IP..."

Можно организовать резерв с помощью наших продуктов.

С обоих серверов (основного и резервного) уходят IP-потоки с трансляцией вашего телеканала. На третьем сервере устанавливается наше ПО Шлюз IP-IP, которое принимает оба потока. Это ПО отслеживает корректность одного из IP-потоков (главного) и в случае ошибок переключается на второй IP-поток (резервный).

Дополнительная информация по схеме резервирования здесь.

Что можно прочитать про шлюз?

"...Что можно почитать про резервирование IP-потоков? Интересует, например, шлюз?..."

"Шлюз IP-IP" - это программное решение, отслеживающее выходные IP-потоки и переключающее на резервный в случае пропадания основного потока.

Общая схема резервирования при IP-вещании здесь.

Краткое описание настройки "Шлюза IP-IP" здесь (раздел "Резервирование IP-потоков (UDP)").

Дополнительная информация, связанная со "Шлюзом IP-IP", здесь.

Один "Шлюз" для нескольких IP-каналов

"...Есть вопрос по резервированию IP-вещания. Может ли один "Шлюз" работать для нескольких IP-каналов? Или для каждой пары серверов (ведущий + ведомый) нужен отдельный "Шлюз"? Если же один "Шлюз" способен работать с несколькими каналами, то лицензия потребуется одна? Или отдельная лицензия для каждой пары резервируемых каналов?..."

Один "Шлюз IP-IP" может резервировать несколько каналов вещания (несколько пар ведущий + ведомый). Лицензия нужна одна, вне зависимости от числа резервируемых каналов.

Анализирует ли устройство SLControlBox101 выходной сигнал платы?

"...Интересует устройство SLControlBox101 в функции WatchDog. Правильно ли мы понимаем, что оно  анализирует выход платы на наличие подвижной картинки и при обнаружении стоп-кадра и автоматически переводит на резервный Форвард. Если это так, то сколько по времени должен быть стоп-кадр, чтобы произошло переключение? Как можно настроить время анализа стоп-кадра у SLControlBox101?.."

Устройство SLControlBox101 не анализирует видеосигналы, не коммутирует видеосигналы, а только управляет коммутатором резерва для переключения на резервный сигнал.

Формирование HLS-потока на стороне шлюза

"...Кроме IP-потока на выходе формируем ещё и HLS. Используем схему вещания из двух рабочих станций и шлюза IP-IP для резервирования. Возможно ли организовать формирование HLS-потока на стороне шлюза, а не на стороне вещающих серверов?..."

Да, на стороне шлюза можно построить граф, принимающий UDP-поток и отправляющий его на HLS. В качестве входного устройства нужно выбрать SL UDP/RTP (Raw TS), а выходное - SL HLS Segmemter.

Каким образом развёртывается резервирование?

"...Все вещание (IP) у нас идёт с одного компьютера.  Каким образом развёртывается резервирование? Допустим, рядом еще один компьютер с менее высокими характеристиками. Висит в локальной сети вместе с основным компьютером вещания. Если основной компьютер по каким либо причинам не в сети, то переключается на резервный - некий whoch dock. Нужно ли еще лицензию на резервный компьютер? Либо есть решения для подобных методов вещания?..."

Про резервирование при IP-вещании описано здесь.

Синхронизация нескольких каналов по схеме ведущий-ведомый

"...На нашем сервере идёт вещание трёх каналов. Собираемся приобретать резервный. Есть ли  возможность синхронизировать каждый отдельный экземпляр программы OnAir3 по схеме ведущий-ведомый друг с другом? Условно: 1-й экземпляр сервера А, с 1-м экземпляром сервера Б, 2-й со 2-м и т.д..."

Да, конечно есть. 

Синхронизация плейлистов на основном и резервном серверах

"...Для работы основного и резервного серверов плейлисты по идее должны мгновенно синхронизироваться. Как это устроено в Форвард ТА?..."

В ПО Форвард ТА есть встроенная программная опция "Зеркалирование" . Именно она обеспечивает синхронизацию расписаний вещания на основном и резервном серверах.

Нужна ли лицензия для организации резервирования?

"... Нужна ли лицензия для организации резервирования вещания или это бесплатное решение?..."

И  да, и нет. 

При организации схем резервирования потребуется дополнительное оборудование (устройство

Отработают ли скрипты TSF при разных версиях ПО?

"...Собрали видеосервер для резервирования вещания. Выбрали схему "Зеркало". На резервном сервере установили новое ПО, на ведущем пока установлена старая версия. Отработают ли скрипты TSF при разных версиях ПО?..."

Скорее всего, скрипты работать будут. Но лучше на резервном и основном сервере использовать одинаковые версии ПО. Подробнее .

На резервном и основном серверах разные платы?

 "...Собрали видеосервер на плате FD722 для резервирования вещания старого видеосервера на плате FD422. Выбрали схему резервирования "Зеркало". Такая схема с разными платами будет работать?..."

Да, такая схема вполне рабочая. 

Но есть одно ограничение. У платы FD422 в режиме HD работает только один вход, а у платы FD722 - два. Поэтому если вы используете два"живых" входа, то такая схема не сработает.

ОС на ведущем и ведомом серверах

 "...Обязательно должно быть одинаковой операционная система Windows на основном и резервном серверах? Что если Windows 10 и 11 на этих серверах? А Windows 7 и 10?..."

Рекомендуем использовать одинаковую ОС. Либо максимально близкие по дате релиза.

 Конфигурация на Windows 10 и 11 может использоваться. 

А пару Windows 7 и 10 не рекомендуем. Тем более, что от поддержки работы нашего ПО на Windows 7 мы планируем скоро отказаться.

Версии программного обеспечения на ведущем и ведомом сервере

"...При резервировании вещания версии программного обеспечения на ведущем и ведомом сервере обязательно должны быть одинаковые?..."

Версии ПО должны быть одинаковые (рекомендуем)  или очень близкие. Сильного "разбега" версий быть не должно:

1. Если версии  очень сильно отличаются, то есть вероятность несовпадения протокола передачи команд между основным и резервным серверами при зеркалировании. И они не смогут нормально обмениваться сообщениями между собой.
2. Возможности самого ПО могут сильно отличаться. То, что уже появилось в новой версии ПО, может отсутствовать в старой.

51051 или 41051?

"...При настройке зеркалирования в документации был указан порт обмена сообщениями 51051, а здесь в блоге нашел информацию что порт 41051. Какой в итоге нужен?..."

Несколько раз меняли, но в конце концов остановились на 41051. Подробнее...

Важно: порт на ведущем и ведомом сервере должен быть один и тот же!

Версии ПО на резервной и основной машинах

"...На "резерве", где проверяли работу скрипта TSF_Transitions, версия OnAir3 3.12.72. На "мастере" - 3.8.32. Обновлять ПО обязательно надо, чтобы все скрипты заработали?Заработает скрипт на старой версии ПО или нет?..."

На старой версии ПО скрипт, скорее всего, работать будет. В нём нет ничего особенного, чтобы слишком зависеть от версии основного ПО.

Важно! Версия самого скрипта должна быть одинаковой на обеих машинах.

Важно! Рекомендуем использовать на основной и резервной машине одинаковые версии основного ПО.

Организация бесперебойного вещания

 "...Возможно ли организовать бесперебойное вещание? Т.е. в случае выхода из строя (или технического обслуживания) одного вещательного сервера происходило бы автоматическое переключение на резервный..."

Да, конечно. Существуют схемы для организации бесперебойного вещания. Они могут быть применены для различных типов сигналов (SDI, IP). Описаны здесь. Самая популярная - "Зеркало".

"Бесшовный" переход на новый сервер

"...Мы купили сервер, хотим с него осуществлять вещание телеканала "...". Есть ли у  вас какое-то решение, чтобы данный процесс прошел "бесшовно"?..."

Можно сократить время до минимума, если собрать схему резервирования. Ваш текущий сервер будет основным. Ваш новый - резервным. Потребуется третий сервер-коммутатор (очень маломощный). Схема и описание резервирования здесь.

Нужен ли комплект лицензий для "холодного" резерва?

  "...На первом этапе хотим организовать "холодный" резерв для вещания (сломался основной сервер - со склада принесли резервный, применили регистрации с основного сервера, переставили в него HASP-ключ. запустили вещание). Нужен ли комплект лицензий для резервного сервера?..."

Нет, доп. комплект лицензий не нужен. Но некоторые действия на резервном сервере необходимо сделать заранее: установить такую же ОС и  такую же версию ПО как и на основном, применить комплект лицензий.