Как зарезервировать захват источника¶

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

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

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

cluster_key abcd;
peer flussonic:8080;
peer streamer:8081;
peer s03.myhosting.com;

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

stream cam01 {
  input file://vod/bunny.mp4;
  cluster_ingest;
}
stream cam02 {
  input file://vod/bunny.mp4;
  cluster_ingest;
}
stream cam03 {
  input fake://fake;
  cluster_ingest capture_at=streamer;
}

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

Статус серверов в вашем кластере отображается на странице Cluster -> Overview.

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

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

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

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

Таймауты¶

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

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

Пример конфигурации кластера с использованием таймаутов:

cluster_key abcd;
peer flussonic1:8080;
peer streamer:8081 {
  fetch_timeout 1000;
  stale_timeout 3000;
}

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

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

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