130 тысяч камер видеонаблюдения – как заставить их работать?
Привет, Хабр! Хотим снова поблагодарить вас за отличную обратную связь, на ряд ваших вопросов мы дадим развёрнутые ответы, в том числе — подробно расскажем про инфраструктуру нашей системы. Мы и сами подумывали в скором времени сделать такой пост, но раз вы тоже высказали интерес к данной тематике, то мы немного форсировали процесс.
Под катом — сразу к делу.Архитектура системы построена по модульному принципу, что является стандартом для систем такого масштаба. Но есть одно существенное отличие: этих модулей в системе не просто много, а очень много. Каждый модуль выполняет отдельные узкоспециализированные задачи, связанные с получением видеоизображений и информации от городских и ведомственных информационных систем (ИС), управлением доступом к обрабатываемым данным, предоставлением фото- и видеоизображений пользователям ЕЦХД и различным внешним потребителям, в том числе жителям города.Модули тесно взаимодействуют между собой на основе различных технологий (в основном — JSON, REST API и SOAP). Сами модули реализованы на различных языках (Java, C#, Java Script и другие), с использованием фреймворков (ASP.NET Web API, WCF, NLog, Entity Framework, MySQL ADO.NET managed drivers, Unity 3, EPPlus, Json.NET, EmitMapper, DotNetZip, jQuery, knockoutjs, Moment.js, underscore.js и так далее).
Всё это программное разнообразие функционирует под управлением различных операционных систем (Windows Server, SUSE Linux Enterprise Server, CentOS и другие) в среде виртуализации VMware vSphere 5.
Архитектура системы приведена на схеме:
Все модули имеют собственные механизмы отказоустойчивости и балансировки. Для этого используются кластерные технологии, различные варианты балансировки HTTP-запросов на основе nginx, а также управление очередями и приоритетами на прикладном уровне. Кроме того, все модули объединены по принципу слабой связности, что существенно повышает возможности развития и модификации системы в целом.
Данный подход позволяет сделать систему не только масштабируемой, но и очень гибкой в части реализации новых технологических процессов или внесения изменений в существующие, так как каждый модуль может развиваться самостоятельно, и поддержка обратной совместимости модуля является обязательным требованием.
Описание основных компонентов системы Видеоядро, обеспечивающее получение и обработку видеопотоков, представляет собой несколько сотен видеосерверов, работающих на ресурсах выделенных виртуальных машин под управлением Linux, обеспечивающих приём видеотрафика с более чем 145 тысяч камер, кодеров и других систем формирования видеопотока. Приём трафика осуществляется по протоколу RTSP (видео в формате H.264), схема приёма трафика может использоваться различная — на постоянной основе с настраиваемой глубиной записи (периодом хранения), или по запросу в случае необходимости простого просмотра видео. Такой гибкий подход позволяет экономить как серверные ресурсы, так и снижать загруженность каналов связи.В качестве протокола транспортного уровня в основном используется TCP, но в ряде случаев может использоваться и UDP. Видеосервера выполняют несколько задач:
— Основную: получение видеопотока, его запись и последующую выдачу потокового или архивного видео серверам ретрансляции или долговременное хранение части архивного видео на отдельном выделенном хранилище; — Ряд дополнительных: контроль доступности видеоисточника, контроль получения и соответствия видеопотока заданным параметрам (fps, bitrate, потери пакетов), а также через специализированные шины обмена данными информация от видеосерверов поступает в систему контроля оказания услуги для последующего учёта и передачи в службы эксплуатации.
Управление видеосерверами осуществляется через специализированный HTTP API, позволяющий полностью автоматизировать работу через управляющие системы. Функционирование видеосерверов контролируются через Zabbix, с использованием дополнительных внутренних механизмов видеосерверов.
Рестримминг — сервера ретрансляции — связующее звено между видеоядром (осуществляющим первичный приём видео и его запись) и пользователями (по сути основными потребителями видеоконтента). Встроенные механизмы реинкапсуляции и дистрибуции потокового видео позволяют обеспечивать ретрансляцию «живого» и архивного видеоконтента на ПК и портативные устройства (планшеты, телефоны). Рестримминг также может обеспечивать потоковую выдачу видеоконтента по RTSP для дополнительных систем, например, для систем видеоаналитики или системы управления транскодированием — ведь пользователям иногда требуется и «сжатый» видеопоток, если вдруг «просел» канал, а посмотреть видео очень хочется :) Также пользователи могут воспользоваться и специальным режимом просмотра в виде слайдшоу. Сервера ретрансляции работают в кластере и поддерживают режим динамического резервирования, а также изолируют видеоядро от возможных всплесков создаваемой пользователями нагрузки.
Пользовательский интерфейс — веб-интерфейс (front-end) обеспечивает авторизованный доступ для нескольких десятков тысяч зарегистрированных пользователей к системе видеонаблюдения и предоставляющий широкий набор различных функциональных возможностей, доступных из любой точки внутригородской сети, а в ряде случаев и через закрытые выделенные Интернет-ресурсы.
Работа обеспечивается в среде различных операционных систем (Windows, MacOS, Linux) на всех основных браузерах, что существенно упрощает организацию рабочих мест. Также поддерживается работа и с ряда мобильных устройств, например, на базе iOS.
Функциональные возможности достаточно разнообразны — начиная от обычного просмотра потокового и архивного видео (через flash-плеер на ПК, и нативные средства на iOS) и управления PTZ-функциями камер, поисковых механизмов с привязками к различным слоям картографии и интеграции с данными городских систем, и до использования гибкой ролевой модели, формирования персонального представления пользовательского интерфейса и встроенных механизмов обучения пользователей.
Front-end использует такие технологии как RequireJS, knockout, lodash, leaflet и другие. Back-end построен по модульному принципу, позволяющему обеспечивать необходимый уровень резервирования и масштабирования компонентов, используется система управления конфигурациями. ПО и технологии: Java/Tomcat, MariaDB, RabbitMQ и ряд других.
Шлюз интеграции — набор модулей подсистем, обеспечивающих изоляцию внешних потребителей информации от ядра системы. Выдаёт различную информацию внешним системам после прохождения авторизации и учётом заданных полномочий (т.е. доступного объёма данных и функциональных возможностей). Функционирует три основных логических компонента:
Компонент сервисного взаимодействия — это HTTP API, через который обеспечивается выдача заданного набора информации (наименования камер, адреса и координаты размещения, скриншоты и другая сопроводительная информация).
Компонент ретрансляции — предназначен для минимизации нагрузки на видеоядро и предоставления трансляции видеопотоков внешним системам (поддерживается вещания на flash, а также HLS для iOS-устройств). Видеоядро и сервера рестримминга обладают функциональностью CDN, а данный компонент работает как дополнительное CDN-звено распространения видеоконтента.
Компонент предоставления интерфейса — предназначен для встраивания во внешние системы в качестве готового интерфейса воспроизведения потоковой и архивной видеоинформации, например, путём встраивания через iframe и простой кастомизации (настройки визуального представления — цвета, необходимые функциональные кнопки и т.п.) через простые параметризированные вызовы.
Использование данных компонентов позволяет внешним системам не только получать доступ к данным и формировать собственный интерфейс визуализации информации, но и максимально просто имплементировать в свой интерфейс уже подготовленные компоненты.
Для предоставления пользователям доступа к камерам системы видеонаблюдения существует целый комплекс взаимосвязанных компонентов, обеспечивающих аутентификацию и авторизацию пользователей, приоритезацию доступа к функциям PTZ-управления, протоколирование действий пользователей и взаимодействие отдельных модулей.
Система поддерживает два вида аутентификации: с использованием учётных записей пользователей ЕЦХД и с использованием единой городской системы управления доступа к ресурсам (фактически, это возможность SSO для общегородских ИС). При этом, для одного физического пользователя, возможно совместное использование различных видов аутентификации. Ключевая аутентификационная информация пользователей ЕЦХД хранится в Active Directory, а вся дополнительная информация — в БД Microsoft SQL.
Все пароли, разумеется, передаются между модулями в зашифрованном виде. Или не передаются вообще, так мы тоже умеем :)
Предоставление полномочий и приоритетов доступа реализовано на основе единой для всех модулей ролевой модели, которая позволяет предоставлять доступ не только к камерам видеонаблюдения, но и к отдельным функциям системы. На текущий момент в системе существует более 100 различных полномочий: доступ к «живой» трансляции, возможность просмотра и экспорта архива фото- и видеоизображений, PTZ-управление, внесение изменений в отдельные системные реестры и справочники, создание расписания для получения снимков, создание маршрутов патрулирования, возможность доступа с мобильных устройств и многое другое. Система постоянно развивается, подключаются новые группы пользователей со своими задачами, и добавление новых полномочий в систему происходит, фактически, на лету.
Дополнительно существует несколько уровней приоритетов для различных групп пользователей и системных сервисов, что позволяет избегать конфликтов между различными группами пользователей и «прозрачно» перехватывать PTZ-управление камерами, обеспечивать управление в режимах патрулирования или перемещать зону обзора по расписанию.
Для того чтобы быстро и просто предоставлять полномочия для десятков тысяч пользователей и управлять ими, в системе применяются различные механизмы: назначение полномочий на группы пользователей, использование шаблонов с предопределенными типовыми полномочиями, смарт-группы (когда на основе заданных правил новые пользователи автоматически распределяются по группам). Аналогичные механизмы применяются для управления реестрами камер, но распределение по группам, в основном, реализовано по географическому принципу, типу услуги или принадлежности к ведомственной системе видеонаблюдения.
Контроль доступа осуществляется практически в режиме реального времени, и любое изменение состава полномочий моментально сказывается на пользователе. Дополнительно для контроля времени жизни ссылок на «живые» видеопотоки используются сессионные механизмы валидации на основе токенов. Кстати, именно отсутствие этого механизма в тестовом сервисе для жителей города и позволило получить доступ к «просроченным» ссылкам на видеопотоки.
В системе зафиксируются все действия пользователя и взаимодействие модулей на всех уровнях, что позволит проводить анализ любой ситуации. Система протоколирования фиксирует дату и время события, какие действия выполнил пользователь (вплоть до нажатия кнопок интерфейса), какие задания планировщика выполнялись в системе, чем завершился информационный обмен и многое другое. На текущий момент в системе зафиксировано более 10 млрд. записей о выполнении «технологических» процессов, каждая из которых состоит из нескольких отдельных протоколируемых действий. Сотрудники ДИТ ежедневно получают статистику, позволяющую определить активность пользователей в различных разрезах: какими порталами пользовались, количество просмотров «живых» трансляций, по каким группам камер было наибольшее количество запросов и т.п.
В качестве «вишенки на торте», система видеонаблюдения в цифрах:
Количество камер: более 145 тысяч; Количество пользователей: более 10 тысяч; Объём сетевого видеотрафика: около 120 Гбит/с; Объём системы хранения: 20 Пбайт.
Читайте также в нашем блоге на Хабре:» Хабраэффект для 130 000 камер Москвы» Информационные технологии кормят более 750 тысяч человек в Москве» Блог департамента информационных технологий города Москвы на «Хабрахабре»
Спасибо за внимание!
