Документация на Flussonic Media Server

  1. Быстрый старт
  2. How To
  3. Потоковое вещание
    1. Публикация
    2. Прием мультикаста
    3. Варианты источников
    4. Переключение источников
    5. Плейлисты
    6. Наложение логотипа
    7. Миксер
    8. WebRTC публикация
    9. SDI
    10. Отправка на другие сервера
    11. Распознавание DVB субтитров
  4. Транскодер
    1. Логотип
    2. Hardware
    3. Скриншоты
    4. Мозаика
  5. DRM
    1. Simple CAS
    2. Conax DRM
    3. BuyDRM (KeyOS)
  6. Авторизация
    1. Конструктор бэкендов
    2. Сервис сбора статистики
    3. Domain lock
    4. Middleware
    5. Secure links
    6. Ограничение сессий
    7. Мультиавторизация
    8. Бан IP адресов
    9. DVR
    10. Aliaser
  7. API
    1. HTTP API
    2. Events API
    3. MySQL API
    4. SQL API для кластеров
    5. SNMP
  8. Кластер
    1. Ретрансляция
    2. Кластерный захват
    3. Балансировщик нагрузки
    4. Пиринг
    5. Организация CDN
  9. VOD
    1. Кэш
    2. Облако
    3. Транскодирование файлов
  10. DVR
    1. Настройка
    2. Timeshift
    3. Catchup
    4. Проигрывание
    5. Экспорт в MP4
    6. Доступ по протоколам
    7. Timelapse
    8. API
    9. Кластеризация DVR
    10. Репликация
    11. Облако
  11. Воспроизведение
    1. HLS
    2. embed.html
    3. HTML5 с низкой задержкой
    4. Плеер HTML5 с низкой задержкой
    5. MPEG-TS
    6. RTMP
    7. DASH
    8. HDS
    9. RTSP
    10. multicast, CBR UDP
    11. WebRTC проигрывание
    12. H.265
  12. Администрирование
    1. Установка
    2. Обновление

    3. Конфигурация
    4. Мониторинг
    5. Производительность
    6. Лицензия
    7. LUA скрипты
    8. Безопасность
    9. Let's Encrypt
    10. Миграция
  13. IPTV
    1. Захват спутникового видео
    2. Транскодирование
    3. Middleware в IPTV OTT
    4. Экспорт EPG со спутника
    5. Группы каналов

Кластерный захват потоков

Кластерный захват потоков необходим для решения следующей проблемы: допустим у вас есть некоторое количество сервером (до 20 штук), объединённых в группу, и есть множество потоков, которые надо принять, причём каждый поток только на каком-то одном сервере из группы.

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

Механизм кластерного захвата работает следующим образом: в конфигурационном файле описываются все сервера, участвующие в захвате и прописывается директива cluster_key:

cluster_key MYSECRET;

peer s01.myhosting.com;
peer s02.myhosting.com;
peer s03.myhosting.com;

После чего описываются нужные потоки и им указывается опция cluster_ingest:

stream cam01 {
  url ...;
  cluster_ingest;
}

stream cam02 {
  url ...;
  cluster_ingest;
}

stream cam03 {
  url ...;
  cluster_ingest capture_at=s01.myhosting.com;
}

В качестве параметра опции можно указать явную привязку к одному серверу. Это не жесткая привязка, потому что если этот сервер выключится, поток всё равно поднимется на другом.

При достаточно большом количестве потоков они будут равномерно распределены между серверами.

Если сервер отключится, потоки автоматически поднимутся на других серверах. Если он включится, потоки автоматически отключатся на других и вернутся на него.

Если обратиться за потоком к любому серверу из кластера, на котором этого потока нет, то он отдаст код на редирект к другому серверу.

Т.е. фактически можно обратиться к любому серверу из кластера и перенаправят на текущий активный сервер.

В данный момент этой возможностью можно пользоваться для захвата с камер или в ситуации, когда надо пробросить по узкому каналу много телеканалов и распределить их между ретрансляторами в датацентре.

К этому механизму планируется доделать следующие возможности:

  • автоматическая репликация архива с резервного сервера на основной с последующим стиранием с реплики после восстановления
  • возможно альтернативную конфигурацию для транскодера в случае аварийного приёма канала с соседнего сервера

Таймауты Anchor Anchor x2

Вы можете играть с таймаутами в конфигурации, но вам нужно быть очень осторожными. Установка слишком малых тайм-аутов сделает систему нерабочей.

Помните очень важный факт: в сети невозможно отличить потерю связи и очень долгую задержку.

peer s01.myhosting.com {
  fetch_timeout 1;
  stale_timeout 3;
}

Это покажет Flussonic Media Server, чтобы получать потоки от пиров раз в 1 секунду. Это ОЧЕНЬ часто и так нельзя использовать в работе. Но вы можете играть с ним. fetch_timeout несет за это ответственность.

stale_timeout 3; — сообщит Flussonic Media Server, что потоки от этого пира были мертвы после 3 секунд отсутствия ответа от этого пира.

Поэтому, если этот пир перегружен и не может ответить через 3 секунды, он считается мертвым, и механизм кластеризации запустит свои потоки на локальном хосте.