Внешнее управление потоками¶

Flussonic предоставляет возможности для работы со статическими потоками и потоками с динамическим именем. Он позволяет загружать статические конфигурации потоков, использовать live-локации для публикации потоков с динамическим именем.

Таким образом, имена потоков могут быть:

• заранее известны Flussonic и указаны в конфигурации (статические потоки),
• заранее неизвестны Flussonic, но известны внешней подсистеме до обращения к Flussonic (потоки с динамическим именем).

Когда система состоит из двух-трёх серверов, то такие механизмы для статических потоков и потоков с динамическим именем работают. Если система расширяется и количество серверов увеличивается, то эти механизмы начинают ломаться и возникают сложности в работе системы.

Трудности управления большим кластером серверов¶

Если система включает в себя 20 и более серверов, работает с большим количеством потоков как статических, так и с динамическим именем, то возникают следующие трудности:

1. Неочевидно как эффективно распределять нагрузку между серверами.

   При большом количестве разных потоков, системе необходимо одни потоки запустить со статической конфигурацией, а другие — по запросу клиента. Механизмы для статической конфигурации работают тогда, когда система состоит из одного-двух серверов. Когда система расширяется и количество серверов увеличивается до 20, 30 и больше, а количество контента на этих серверах становится ещё больше, то становится неочевидно как распределять потоки между серверами. В таком случае привычные механизмы для статических потоков уже не работают.

2. Для внесения изменений в конфигурацию может быть необходимо обходить все серверы в кластере.

   Система, управляющая 20 и более серверами Flussonic, захватывающих телеканалы или IP-камеры, должна хранить в себе знание о том, что поток сейчас точно захватывается и захватывается единожды. В системе также должно храниться знание о том, что определённый поток захватывается определённым сервером, например, сервером A. Система также должна периодически проверять, что поток активен и сигнал захватывается. Если сервер А остановил свою работу, то необходимо перенести захват потока на сервер Б и запомнить, что теперь этот поток захватывается сервером Б. Если сервер Б отказал, то необходимо так же перенести захват на другой сервер и запомнить местоположение потока. Когда система переносит захват потока на новый сервер, необходимо также проверять состояние предыдущих серверов. Если один из них поднимется, то необходимо либо

   • удалить этот поток из конфигурации всех предыдущих серверов и оставить на текущем,

   либо

   • вернуть захват потока на вновь работающий сервер и удалить с предыдущих, чтобы избежать двойного захвата потока.

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

Во Flussonic есть решение проблем двойного захвата и отказа одного из серверов захвата — механизм кластерного захвата (cluster_ingest). Этот механизм позволяет автоматически захватывать потоки на другом сервере при отказе одного из серверов в кластере, а также удалять поток с других серверов при восстановлении работы первого. Однако этот механизм решает проблемы одним единственным способом без возможности кастомизации и изменения правил его работы. Поэтому мы придумали механизм управления конфигурацией потоков с помощью внешнего конфигурационного бэкенда — config_external.

О config_external¶

config_external — это внутренний механизм Flussonic, с помощью которого сервер может скачивать актуальную конфигурацию потоков из конфигурационного бэкенда. Конфигурационный бэкенд, сервер конфигурации — это внешний ресурс, который хранит в себе логику управления потоками и связан с базой данных для хранения такой конфигурации.

Принцип работы¶

Порядок работы config_external различается в зависимости от того, реализованы ли на стороне конфигурационного бэкенда отдельные запросы для обновления статических потоков GET /update_streams_list и работы с динамическими потоками GET /dynamic_streams_list. По умолчанию все запросы к конфигурационному бэкенду выполняются через один метод GET /streams.

Подробнее принцип работы в этих двух случаях описан ниже.

Один метод для всех потоков (по умолчанию)¶

config_external работает циклично и обновляет конфигурацию раз в две-три секунды. Каждый цикл обновления конфигурации выглядит следующим образом:

1. Flussonic запрашивает по API (метод GET /streams) актуальный список активных статических потоков у конфигурационного бэкенда и запускает их, если они ещё не были запущены.
2. Flussonic высчитывает разницу между списком имён уже запущенных на сервере потоков и списком имён статических потоков, который вернул конфигурационный бэкенд.
3. Flussonic отправляет запрос по API конфигурационному бэкенду с получившимся списком имён потоков (метод GET /streams с указанием ?name=.. в строке запроса), чтобы запросить конфигурацию для этих потоков.

1. Конфигурационный бэкенд возвращает конфигурацию для запрошенного списка потоков. Если для каких-то из запрошенных потоков не пришла конфигурация, то они автоматически удаляются с сервера.

Отдельные методы для обновления статических потоков и запроса динамических потоков¶

Flussonic запрашивает методом GET /streams актуальный список активных статических потоков у конфигурационного бэкенда.

Если в ответе конфигурационный бэкенд вернул заголовок X-Config-Server-Separate-Endpoints: true, то дальнейшие запросы к конфигурационному бэкенду выполняются следующим образом:

• Периодически выполняется GET /streams, и если на сервере Flussonic есть запущенные потоки, не включенные в ответ на GET /streams, то выполняется GET /update_streams_list для получения конфигурации или удаления этих потоков (схоже с поведением по умолчанию).

• Если у сервера Flussonic будет запрошен поток с неизвестным (динамическим) именем, то выполняется GET /dynamic_streams_list для получения конфигурации динамического потока.

  Несколько последовательных запросов такого рода могут быть сгруппированы в один вызов API по усмотрению Flussonic, при этом имена потоков указываются списком в параметре name.

Сценарии использования¶

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

С помощью config_external вы можете разработать любую логику распределения потоков по серверам кластера под ваши нужды и задачи. На базе конфигурационного бэкенда вы можете реализовать свою собственную версию геотаргетированного кластерного захвата или механизма source для ретрансляции потоков. Вы можете реализовать следующие механизмы для работы с кластером:

Геотаргетированный кластерный захват¶

Задача — захватить сигнал из источника в одной стране одним из близлежащих серверов.

Алгоритм действий может быть таким:

1. Flussonic запрашивает конфигурацию потоков у конфигурационного бэкенда.
2. Конфигурационный бэкенд просматривает список доступных серверов и выбирает самые географически близкие к источнику.
3. Конфигурационный бэкенд возвращает одному из таких серверов Flussonic конфигурацию с захватом источника.

Динамические таргетированные републикации¶

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

Принцип работы следующий:

1. Клиент отправляет запрос серверу публикации.
2. Сервер публикации обращается к конфигурационному бэкенду и запрашивает конфигурацию потока для клиента.
3. Конфигурационный бэкенд смотрит на список доступных транскодеров, определяет из них наименее загруженный и возвращает серверу публикации конфигурацию потока с отправкой (push) на наименее загруженный транскодер. При отправке потока сервером публикации не будет потери первого кадра.

Настройка config_external¶

Настроить адрес внешнего конфигурационного бэкенда можно одним из следующих способов:

• Прописать в файле конфигурации (/etc/flussonic/flussonic.conf) глобальную опцию config_external.

config_external https://example.com/config_backend/streams;

• Передать config_external через API, см. API Reference.

curl --request PUT --url http://127.0.0.1:80/streamer/api/v3/config \
--data '{"config_external":"https://example.com/config_backend/streams"}' \
--header 'Authorization: Basic base64_encoded_username:password' \
--header 'Content-Type: application/json'

• Создать переменную окружения STREAMER_CONFIG_EXTERNAL и указать в качестве значения путь к конфигурационному бэкенду. Мы рекомендуем использовать этот способ только для k8s окружения (или в другой системе автоматического развертывания). В остальных случаях будет удобнее задавать эту настройку через файл конфигурации, как показано выше.

STREAMER_CONFIG_EXTERNAL=https://example.com/config_backend/streams

При такой настройке Flussonic раз в две-три секунды будет обращаться к конфигурационному бэкенду за:

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

См. также Валидация конфига об отслеживании ошибок в конфигурации.

Управление эпизодами¶

config_external позволяет реализовать механизм защиты определенных частей архива от автоматического удаления, позволяющий решить следующие задачи:

• Организация услуги nPVR (Network Personal Video Recorder), то есть сохранение архива с записанной передачей, у которой известны границы во времени.
• Сохранение архива с видеокамеры, в котором присутствуют важные данные (движение, распознавание лиц и т.п.).

Для защиты записей используются эпизоды. Эпизод представляет собой набор метаданных об участке архива — уникальный идентификатор, время начала участка, опционально время окончания и пр.

Информация об эпизодах хранится на сервере конфигурационного бэкенда (по умолчанию в Flussonic Central, см. Защита участков DVR от удаления). Перед тем как начать периодическую очистку архива, Flussonic запрашивает у конфигурационного бэкенда список эпизодов для нужного потока и не удаляет те части архива, которая покрывается эпизодами.

Чтобы включить использование эпизодов:

1. В ответе на запрос GET /streams передайте заголовок X-Config-Server-Episodes: true.
2. В конфигурации DVR во Flussonic задайте параметр episodes_url.
3. Реализуйте на стороне конфигурационного бэкенда ответ на запрос GET /episodes по тому адресу, который вы пропишете в episodes_url.