Central’ная трансформация: От Push к Pull

05.09.2023

7мин. чтения

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

Central’ная трансформация: От Push к Pull

Архитектура Watcher - как это было и к чему это привело

Давайте начнем с того, что представлял из себя Watcher ранее. В его состав входили программные компоненты - Watcher и Flussonic Media Server. Watcher взял на себя всю бизнес-логику, хранил информацию о камерах, пользователях и разрешениях доступа, а также отвечал за передачу настроек и конфигураций в Flussonic Media Server. Flussonic Media Server выполнял функции стримера, захватывая видео с камер и записывая архив. Помимо этого, Flussonic контролировал необходимость удаления или сохранения определенных сегментов в архиве.

Первоначальная архитектура Watcher

Схема 1 - Первоначальная архитектура Watcher


Архитектура Watcher в области управления конфигурациями и событиями работала по принципу “push”, когда центральная система инициирует передачу конфигурации в систему, которая предоставляет сервис. Flussonic Media Server, в данном случае, выполнял роль сервиса, в то время как Watcher действовал как оркестратор.

Watcher при создании, удалении, переноса стрима через API управлял списком стримов на медиасервере. Аналогично и с архивом: чтобы интересное событие не стерлось через 2-3 дня, Watcher по API создавал и удалял Locks, т.е. пометки в архиве о том, что его надо держать дольше, чем стандартное время жизни архива. Это важная функция, поскольку позволяет в десятки и сотни раз сократить использование диска.

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

На пути решения этих проблем архитектура может начать очень сильно усложняться и терять свою эффективность и изящество. Операции синхронизации состояния, такие как передача конфигурации и управление состоянием через команды типа “заблокируй в архиве этот сегмент” (DVR_LOCK), начали выполняться Watcher’ом в огромных объемах, потому что без этого нужно было бы делать всю систему слишком хрупкой (именно так появляются волшебные кнопки «сбросить кеш»). Это начало влиять на производительность Flussonic Media Server и всей системы в целом.

График из телеметрии - проблемы с количеством API запросов и временем их выполнения у клиента в июне 2023 года


На верхнем графике (с количеством вызовов) видна “пила” с 06/09 по 06/29: у клиента был хаос с неопределенным количеством API-запросов, особенно это касалось запросов, по блокировке сегментов архива (“stream_dvr_lock_save”).

Это снижало производительность API Flussonic Media Server. А на нижнем графике видно, что количество API запросов, которые занимали более одной секунды, росло, страдала общая производительность всей системы (простыми словами - тормозила! )

Попытки оптимизации и ограничения push-подхода

Для решения проблемы клиента в новом релизе в июле мы предприняли попытки оптимизировать количество API-запросов к Flussonic Media Server через Watcher в рамках push-модели.

График - попытки оптимизации количества API-запросов в новом релизе Watcher


На графике видно, как “пила” в июле немного “сгладилась”, количество запросов уменьшилось, и длительность запросов сократилась, но не драматически, система продолжала подтормаживать.

Мы осознали, что дальнейшая оптимизация подхода “push” в области управления конфигурацией ограничена. Вернее, от нас это требует бОльших ресурсов и времени разработки и тюнингования, так как push-подход требует хранить гораздо больше состояний. И он гораздо более хрупкий.

Новый оркестратор и смена парадигмы - PUSH vs. PULL в управлении конфигурациями

Осознав, что дальнейшие попытки оптимизации push-модели слишком ресурсозатратные, мы решили кардинально изменить подход в управлении конфигурацией системы видеонаблюдения. Во-первых, мы выделили функции оркестрации в отдельную систему Central. Во-вторых, мы перешли от “push” к модели “pull”.

Схема Watcher после выделения Central


Рассмотрим, в чем заключается разница. Теперь в Central остается знание о состоянии (state) стримеров (Flussonic Media Server), и контроль над этим состоянием на уровне медиа-сервера больше не требуется. Central хранит знания о состоянии и всю информацию о конфигурации.

Flussonic Media Server “тянет” (pull) обновленную конфигурацию из Central - системы, которая обладает знанием о состоянии, вместо ожидания “пуша” извне. Такой подход позволил создать единую точку, где хранится информация о состоянии, и множество экземпляров Flussonic Media Server могут получать эту информацию регулярно при необходимости. Самое важное здесь, что при переходе с более сложной и затейливой push системы на pull, мы фактически отказываемся разбирать всю ту сложность и вариативность способов недополучения push апдейтов, а заменяем их на регулярное вытаскивание целевого состояния.

Ранее, для обновления (push) состояния на каждой из нод в кластере медиа-серверов требовалось физически посещать каждую ноду и переносить конфигурацию, распределяя ее между узлами. Вместе с этим надо было очень тщательно следить не только за всеми неудачными попытками обращения к медиасерверу, а ещё и за всеми серверами, которые внезапно откатились или на них вручную поменяли конфигурацию. Теперь, вместо необходимости посещать разные узлы для синхронизации состояния, состояние собирается в Central, и все узлы получают его оттуда, когда они готовы. Актуальная конфигурация попадет на стриминговый сервер за секунды.

PUSH vs. PULL в управлении архивом

Аналогично, мы переходили от “push” к “pull” в управлении состоянием архива. Сначала мы перешли на механизм хранения эпизодов вместо отдельных сегментов. Прежде блокировка сегментов в архиве (DVR_LOCK) контролировалась при помощи push’а через Watcher, где каждый сегмент в файловой системе помечался как “заблокированный”. Теперь же Flussonic запрашивает информацию (pull) у Central о том, какие эпизоды следует сохранить.

Сейчас Watcher, чтобы сохранить (заблокировать) эпизод, обращается к Central, и Central просто регистрирует информацию в базе данных. Это действие заметно менее затратное, чем операция с диском. БД Central хранит метаданные каждого эпизода, где указаны начало и конец временного интервала, а также могут содержаться превью, скриншоты и другая информация. Сами кадры и аудио хранятся в архиве на той ноде, которая оптимальна для этого. Это определяется кластером.

Дополнительно, такой подход в разы более экономичный, чем “блокировка” архива на трех и более дисках Flussonic-серверов. Для ясности, ранее нам приходилось обращаться к трем медиа-серверам, находить соответствующий сегмент на одном из дисков и изменять файловую систему для его “блокировки”. Теперь вместо хождения по мукам хождения по медиа-серверам Flussonic, мы просто создаем одну запись в базе данных Central. После этого все серверы Flussonic Media Server, даже если их количество составляет 1000, получают информацию от Central. Central дает им указание о том, какие сегменты нужно заблокировать, а все остальные могут быть удалены.

Переход клиента на новую конфигурацию Watcher c Central и на pull-парадигму

График - количество API-запросов и время их выполнения после миграции на Central


В августе наш клиент мигрировал на новую конфигурацию Watcher, в состав которой входил оркестратор Central и новая pull-парадигма в управлении конфигурациями (состояниями), стримерами и архивами.

На верхнем графике видно, что количество API-запросов стало практически “линейным” и предсказуемым (особенно это касается запросов относительно сохранения локов архива), и как выровнялось время выполнения API запросов на нижнем графике.

ИТОГО: благодаря Central и pull-подходу клиент получил контролируемое и предсказуемое количество API-запросов и время их выполнения, снизилось потребление сетевых ресурсов, нагрузка на память и CPU уменьшилась вдвое, и благодаря pull- подходу работа архива стала более стабильной!

Выводы:

  • Если вы используете Watcher и сомневаетесь переходить ли на Central, так как “все и так работает, зачем ломать?” - не сомневайтесь. Примеры наших клиентов доказывают кардинальные улучшения производительности, особенно это касается крупных распределенных инсталляций Watcher.

  • Благодаря pull-парадигме и механизму, основанному на эпизодах в Central, операции по организации архива стали дешевле, а сам архив, устойчивым к поломкам, так как метаданные архива хранятся в отдельной базе данных Central, а сам архив хранится на самой оптимальной ноде в кластере.

  • Также благодаря такому подходу на один медиа-сервер можно распределить большее количество камер.

  • И “вишенка на торте”- благодаря pull- походу Central инфраструктура стримеров (медиа-серверов) становится stateless, благодаря чему систему видеонаблюдения легко запустить в облачной контейнерной среде типа Kubernetes

img
Автор:
Аркадий Велькер
Директор по продукту в компании Flussonic
Руководит процессом создания продуктов, отвечающих требованиям клиентов, вызовам отрасли и текущим тенденциям
Ключевые слова:
Watcher Central

Бесплатный триал Watcher

Отправляя заявку, вы соглашаетесь с правилами и условиями

Как установить Flussonic

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

Email: support@flussonic.com Phone: +7 (717) 272-78-21