Central’ная трансформация: От Push к Pull
В этой статье мы расскажем, как изменили архитектуру системы видеонаблюдения Watcher с push-подхода конфигурации и событий на pull-подход. Этот переход не только упростил код, но и снизил издержки на администрирование системы видеонаблюдения, повысил ее производительность, и сделал работу архива более стабильной в многосерверной конфигурации.
Архитектура Watcher - как это было и к чему это привело
Давайте начнем с того, что представлял из себя Watcher ранее. В его состав входили программные компоненты - Watcher и Flussonic Media Server. Watcher взял на себя всю бизнес-логику, хранил информацию о камерах, пользователях и разрешениях доступа, а также отвечал за передачу настроек и конфигураций в Flussonic Media Server. Flussonic Media Server выполнял функции стримера, захватывая видео с камер и записывая архив. Помимо этого, Flussonic контролировал необходимость удаления или сохранения определенных сегментов в архиве.
Схема 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