Федеративный VMS: много площадок как одна система

TL;DR

Федерация – это способ заставить много независимых систем записи (по одной на здание, магазин или кампус) вести себя для оператора как единая система, не сливая видео в одну гигантскую базу и не свозя его в один дата-центр. Каждая площадка продолжает писать на своём железе и работает, даже если канал до головного офиса упал; центральная площадка добавляет общий обзор, общий список тревог и общий поиск по всем, забирая видео по глобальной сети (WAN) только для тех камер, которые кто-то реально смотрит. В этом весь фокус: программа, которая записывает и управляет множеством потоков камер (Video Management System, VMS), пишет «на краю» и отдаёт поток по запросу, поэтому сети с тысячами камер нужны десятки мегабит до офиса, а не тысячи, которых стоила бы централизация всех потоков. Федерация мощна, но привязана к вендору – открытого стандарта, который подчинил бы один бренд VMS другому, нет, – поэтому как только нужен единый обзор по разным брендам, это уже не федерация, а более тяжёлая интеграция.

Почему это важно

Одно здание – это просто: один VMS, камеры, пара серверов записи, одна сеть. Сложности начинаются со второго здания и нарастают к пятидесятому. Эта статья – для системного интегратора, руководителя эксплуатации, менеджера продукта или начальника безопасности предприятия либо города, которому нужно больше камер, чем вмещает один сервер или одна площадка, и чтобы при этом всё ощущалось как единая система без хрупкого, прожорливого по трафику месива под капотом. Сделаете архитектуру верно – и сеть магазинов или город управляет тысячами камер как одним окном, а каждая точка остаётся самодостаточной; ошибётесь – либо «положите» сеть, пытаясь свести все потоки в центр, либо получите пятьдесят островов, которые невозможно смотреть вместе. Никаких предварительных знаний не нужно: каждый термин объясняется простыми словами, арифметика трафика и хранения показана вслух, а единственное решение, которое тихо определяет всю систему – где живёт видео против того, где его смотрят, – сделано явным.

Одна идея: много независимых систем – одно окно

Начнём с того, чем федерация не является. Это не один огромный VMS, в который воткнуты все камеры мира, и не центральный склад, куда свозится всё видео. И то и другое ломается на масштабе – почему, разберём ниже.

Федерация делает обратный ход. Вы строите каждую точку как законченную самодостаточную систему видеонаблюдения – со своими камерами, своим сервером записи, своим хранилищем, своими локальными операторами – а затем связываете эти независимые системы в иерархию так, чтобы оператор с нужными правами видел и искал по всем как по одной. Эта общая структура называется федеративной иерархией: одна родительская площадка наверху, дочерние под ней и (если нужно) дочерние под теми.

Полезная аналогия – сеть посольств. Каждое посольство управляется само, ведёт свои дела и остаётся открытым, даже если связь со столицей оборвана. Головной офис в столице не хранит копии всех документов; он держит полномочия и справочник, чтобы дотянуться до любого посольства, когда это нужно. Федерация придаёт сети наблюдения ту же форму: локальная автономия, центральный охват.

Вот почему определяющее свойство федеративной системы – независимость. Дочерняя площадка пишет свои камеры на свои диски и полностью работоспособна сама по себе. Если канал глобальной сети – связь между площадками на большом расстоянии, сокращённо WAN – упал, эта площадка продолжает запись, а её сотрудники продолжают работать; гаснет лишь центральный обзор именно этой одной точки, и все остальные не затронуты. White paper Milestone по федерации формулирует это прямо: локальные администраторы и пользователи могут войти, смотреть видео и управлять своей площадкой, даже когда связь с иерархией оборвана, а потеря одной площадки не нарушает доступ к остальным. Именно эта гарантия отделяет федерацию от централизованной схемы, где один сбой ослепляет всех.

Нажмите, чтобы увеличить

Почему не один большой VMS?

Очевидный вопрос: почему просто не растить один VMS, пока он не покроет всё? Потому что VMS масштабируется ступенями, и каждая ступень упирается в стену.

Один сервер VMS записывает ограниченное число камер – практически где-то 50–100, прежде чем нагрузка записи, хранения и раздачи на одной машине станет узким местом. Дальше любой серьёзный VMS распределяет работу по серверам записи: один сервер управления держит конфигурацию и учётные записи, а несколько серверов записи берут по доле камер. Это всё ещё одна система – одна база, один административный домен – и она масштабируется далеко. Milestone XProtect, например, документирует одиночные системы на 100 000 и более камер, построенные так.

Так если одна система уже вмещает 100 000 камер, зачем вообще федерация? Потому что число камер – не единственное, что масштабируется. Три другие силы выталкивают за пределы одной системы, и они не про сырую ёмкость:

Первая – география. Одна система предполагает одну надёжную быструю сеть. Растяните её через WAN на пятьдесят магазинов на бизнес-интернете – и предположение рушится: нельзя гонять одну низколатентную базу и одну фабрику раздачи по пятидесяти ненадёжным дальним каналам.

Вторая – автономия. Отделение банка, магазин или удалённая подстанция обычно должны работать, когда канал до офиса упал, и часто обязаны оставаться под локальным контролем по юридическим или операционным причинам. Монолит делает каждую точку зависимой от центра.

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

Федерация отвечает на всё три, оставляя каждую точку отдельной системой и добавляя сверху тонкий слой общей видимости. Это стандартный ход, как только развёртывание переваливает примерно за тысячу камер или охватывает больше одной реальной локации, – поэтому крупнейшие сети наблюдения в мире (у одного клиента Genetec более 170 000 камер) федеративны, а не монолитны.

Что на самом деле значит «как одна»

Когда вендоры говорят, что федеративная система ведёт себя «как одна», они имеют в виду конкретный набор вещей, объединённых на родителе, хотя нижележащие системы остаются раздельными. Полезно говорить конкретно о том, что именно становится общим.

Общим становится дерево камер: оператор на родителе видит структуру папок со всеми площадками и всеми камерами, которые ему разрешено видеть, и может перетаскивать камеры с разных площадок в одну экранную раскладку. Общим становится список тревог и событий: единый менеджер тревог собирает тревоги, события аналитики и (где есть) распознанные номера со всех площадок в одну очередь, так что центр мониторинга смотрит один список, а не пятьдесят. Общей становится карта: глобальная карта размещает камеры всех площадок по их реальным координатам, так что оператор кликает локацию и поднимает её камеры. И общим становится поиск – в пределах того, что каждая площадка проиндексировала: оператор запускает поиск, который веером расходится по площадкам.

Что категорически не общее – это сама запись. Видео остаётся на хранилище каждой площадки. Родитель не держит копию. Когда оператор открывает камеру удалённой площадки, видео тянется с её рекордера по WAN, вживую, ровно столько, сколько он смотрит, – и затем останавливается. Это и есть тот шов, который делает всю затею посильной по деньгам, и он заслуживает отдельного раздела.

Нажмите, чтобы увеличить

Права заслуживают здесь слова, потому что именно они делают общий обзор безопасным. Федерация несёт тонко гранулированные права по площадке и по камере, и они могут учитывать расписание. Реальный пример из документации Milestone: можно дать офицерам безопасности штаба доступ к уличным камерам удалённой площадки только в рабочие часы, но ко всем её камерам, внутренним и наружным, в нерабочее время. Общий обзор – не «всё или ничего»; он ровно настолько широк, насколько разрешает владелец каждой площадки.

Тезис о трафике: пишем на краю, отдаём по запросу

Вот расчёт, который решает, разумна многоплощадочная схема или обречена. Представьте сеть магазинов: 50 магазинов по 30 камер, итого 1 500 камер, каждая выдаёт поток HD на 4 Mbps (мегабита в секунду). Наивная схема говорит: гнать каждую камеру в центральный VMS в штабе, чтобы смотреть и писать всё в одном месте. Сколько это стоит сети?

1 500 камер × 4 Mbps = 6 000 Mbps = 6 Gbps, постоянно, 24/7, в одно здание

Шесть гигабит в секунду, без пауз, только на приём – прежде чем хоть один оператор что-то посмотрел. Ни один WAN-бюджет ритейла этого не переживёт. Централизованная мечта мертва на одной арифметике.

Федерация убивает проблему, отказываясь двигать видео по умолчанию. Каждый магазин пишет свои 30 камер локально. По WAN ходят только две вещи. Первая – струйка трафика синхронизации, что держит справочник иерархии актуальным: в федерации Milestone плановая синхронизация идентификационных данных площадок идёт каждые 10 минут и тратит менее 1 MB за раз. Пятьдесят площадок, синхронизирующихся по <1 MB каждые десять минут, – это порядка нескольких килобайт в секунду суммарно: шум. Вторая – видео по запросу: камеры, которые оператор реально смотрит, и только пока смотрит.

Так что настоящий вопрос к WAN не «как мне нести 1 500 потоков?», а «сколько камер будут смотреть одновременно и в каком качестве?». Допустим, дежурный пост в штабе показывает видеостену на 25 камер. Гоните их на полных 4 Mbps – и нужно:

25 камер × 4 Mbps = 100 Mbps, и только пока они на экране

Это нормальный бизнес-канал, не фантазия, – и он заменяет 6 Gbps. WAN съёжился в шестьдесят раз, потому что мы перестали централизовать видео и централизовали только обзор.

Сжать можно ещё сильнее просмотром с учётом трафика. Большинство IP-камер отдают сразу несколько потоков – основной (main stream) высокого разрешения для локальной записи и субпоток (substream) низкого разрешения (часто CIF на нескольких кадрах в секунду, порядка 100–500 kbps) для удалённого и многокамерного просмотра. Когда стена в штабе показывает 25 маленьких плиток, ей не нужны 25 полноразмерных потоков – она тянет субпотоки. Двадцать пять субпотоков по 512 kbps – это около 12,8 Mbps, а оператор кликает плитку на весь экран, чтобы подтянуть основной поток именно этой камеры, когда нужна детализация. (Некоторые системы вместо этого перекодируют – пережимают поток меньше на сервере, – но мультистрим с камеры распространённее, потому что серверное перекодирование дорого по вычислениям.) Принцип один: тратить трафик WAN только на то, что смотрит человек, в том качестве, что ему реально нужно.

Нажмите, чтобы увеличить

Хранилище остаётся там, где камеры

Момент, удивляющий новичков в федерации: она не централизует хранилище и не является стратегией бэкапа. Каждая площадка считает и держит свою запись, используя ту же арифметику хранения, что и любая отдельная система. Мы подробно разобрали эту математику в статье как работает хранение видеонаблюдения; применительно к одному магазину 30 камер по 2 Mbps в непрерывной записи 30 дней – это примерно:

30 камер × 2 Mbps → при ~10,8 ГБ/день на 1 Mbps:
30 × 2 × 10,8 ГБ/день = 648 ГБ/день
648 ГБ/день × 30 дней ≈ 19,4 ТБ в этом магазине

Эти ~19,4 ТБ живут в магазине, на рекордере магазина, и точка. Федерация никогда не тянет их в штаб. Умножьте на 50 магазинов – и получите ~970 ТБ видео, распределённого по сети, что ровно и объясняет, почему никто не хочет держать это в одном месте. Схема держит проблему хранения каждой точки размером в одну точку.

Это также значит, что три решения по хранению остаются за площадкой, и вы принимаете их с остальным Блоком 5, а не с федерацией: как долго каждая точка хранит видео и как удаляет по графику (политика хранения) и бэкапит ли точка во внешнее или архивирует в облако (облачное и гибридное хранилище). Федерации это безразлично; она федерирует обзор, а не диски. Практическое следствие: когда следователю нужно сохранить видео сверх обычного срока удаления, такая «блокировка доказательства» применяется и обеспечивается на каждой управляющей площадке, так что единая межплощадочная блокировка становится одной блокировкой на каждой площадке, где есть нужные камеры. Часы хранения остаются локальными, даже когда расследование центральное.

Граница стандарта: федерация проприетарна

Теперь самый важный – и самый недопонятый – факт о федерации. Чтобы его увидеть, вспомните, что делает остальную систему наблюдения совместимой. Открытый стандарт ONVIF (Open Network Video Interface Forum) позволяет камере одного производителя говорить с VMS другого через профили: Profile S для живого стрима, Profile G для записи и выгрузки, Profile T для продвинутого стрима, Profile M для метаданных и аналитики. ONVIF – это общий язык на границе «камера – VMS», и он действительно вендоронезависим. (Глубину того, как работает ONVIF, см. в коммерческом обзоре профилей ONVIF в системах безопасности и нашем инженерном разборе ONVIF для инженеров.)

Вот в чём подвох. ONVIF стандартизует границу между камерой и VMS. Он ничего не говорит о границе между одним VMS и другим. Нет профиля ONVIF – и нет профиля PSIA, и никакого иного открытого стандарта – для федерации двух платформ VMS в одну иерархию. Федерация живёт целиком над стандартизованным слоем, в собственном проприетарном протоколе каждого вендора.

Следствие резкое: вы можете федерировать платформу вендора только саму под собой. Площадка Milestone федерируется под родителем Milestone; система Genetec – под родителем Genetec. Нельзя федерировать площадку Milestone под родителем Genetec, потому что у них нет общего языка, чтобы образовать иерархию. Даже внутри одного вендора путь бывает односторонним – в платформе Genetec, например, унаследованная система Omnicast федерируется вверх в Security Center, но видео Security Center не федерируется вниз в Omnicast. Федерация – это фича вендорской экосистемы, а не стандарт совместимости.

Нажмите, чтобы увеличить

«Частая ошибка: думать, что можно федерировать разные бренды. Город говорит участвующему ведомству: «просто федерируйте свои камеры Milestone под нашей Genetec». Как федерацию – нельзя. Единый обзор по разным брендам VMS – это другой, более тяжёлый проект: слой PSIM (Physical Security Information Management) или индивидуальная интеграция на SDK или API каждого VMS, которая тянет видео и события из каждой платформы и переподаёт их в нейтральной консоли. Это строится, и мы это строим, но это интеграционная работа, а не галочка. Путать одно с другим – так межведомственные проекты и сжигают бюджет.»

Схемы – сравнение

Федерация – одна из четырёх схем запустить больше камер, чем вмещает один ящик, и выбор правильной – и есть собственно проектное решение. Таблица ставит их рядом. (Как и в любом сравнении VMS в этом разделе, она называет, где живёт запись, переживает ли схема обрыв WAN, работает ли между вендорами, есть ли открытый SDK для интеграции и какова модель развёртывания.)

Несколько заметок, которые таблица не вмещает. Interconnect (термин Milestone; у других вендоров есть аналоги) – правильный инструмент, когда удалённые точки слишком малы или ненадёжны, чтобы держать свой полноценный VMS: вместо федерации равного центральная система сама дотягивается и пишет выбранные камеры с каждой удалённой точки, буферизуя через хлипкие каналы. Она меняет краевую автономию федерации на центральное управление и центральное хранение, что иногда ровно то, что нужно «тёмной» удалённой точке. Облачный видеонаблюдение-как-сервис (VSaaS) – известные примеры Eagle Eye Networks и Verkada – обходит вопрос федерации, делая центральным планом сам облачный аккаунт: локальный мост (bridge) или облачный рекордер на каждой точке буферизует локально и выгружает в дата-центры провайдера, так что многоплощадочность – это умолчание, а не фича, которую вы собираете. Это самая простая многоплощадочная история операционно – ценой постоянной экономики трафика и подписки, разобранной в нашей статье об облачном и гибридном хранилище.

Нажмите, чтобы увеличить

Как считать и поэтапно разворачивать федерацию

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

Сначала проектируйте каждую площадку так, будто она автономна, по анатомии системы и математике хранения – камеры, серверы записи, локальное хранилище, локальный срок хранения. Федеративная площадка – это обычная площадка, которую позже свяжут, поэтому в её внутреннем устройстве ничего не меняется. Именно поэтому федерации не нужны лишние серверы и, в случае Milestone, лишние лицензии: иерархия – фича уже имеющихся продуктов, поверх обычного TCP/IP, без особого сетевого железа.

Второе – считайте WAN под просмотр, а не под приём. Оцените реалистичный пик одновременно просматриваемых удалённых камер на центральной площадке, выберите качество потока под каждый контекст просмотра (субпоток для стен и мобильных, основной – для сфокусированного разбора) и добавьте запас. Ранний пример – стена на 25 плиток на субпотоках ~13 Mbps, с всплесками до полного разрешения по клику – типичная отправная точка; круглосуточный центр мониторинга, смотрящий больше площадок сразу, требует пропорционально больше.

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

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

Когда федерация пересекает государственные границы – европейский ритейлер тянет видео из магазинов в нескольких странах в один обзор головного офиса, – учтите: центральный просмотр идентифицируемого видео, записанного в другой стране, может быть трансграничной передачей персональных данных (в ЕС – глава V GDPR о передачах). Инженерная схема не меняется, но юридическое основание для центрального обзора – меняется; это инженерное руководство, не юридический совет, и трансграничному развёртыванию стоит подтвердить основание передачи у квалифицированного юриста. Глубокий разбор – в Блоке 6.

Где здесь Фора Софт

В буклете федерация выглядит просто, а в продакшене становится тонкой: центральный план должен агрегировать тревоги и поиск по площадкам, не таща каждую запись по WAN; путь просмотра должен переключаться между субпотоком и основным потоком по контексту; модель прав должна выражать реальную оргструктуру с доступом по площадке и расписанию. Фора Софт строит видеостриминг, real-time-медиа на WebRTC, видеонаблюдение и системы компьютерного зрения с 2005 года – 250+ выполненных проектов для 400+ клиентов – а это ровно тот набор, которого требует федерация: раздача медиа с учётом трафика, оркестрация многих серверов и слой межплощадочного поиска и аналитики сверху. Когда единый обзор должен охватить разные бренды VMS, мы строим слой интеграции поверх SDK или API каждой платформы, а не делаем вид, что федерация умеет пересекать границу вендора. Мы ведём от того, как система ведёт себя под реальной нагрузкой – что WAN реально несёт на пике, как быстро возвращает межплощадочный поиск, что происходит с каждой площадкой при обрыве канала, – и проектируем возможности вокруг этих чисел.

Главное

• Федерация связывает независимые, самозаписывающиеся площадки в одну иерархию родитель/дочерние, видимую как единая система.
• Каждая федеративная площадка продолжает запись и остаётся работоспособной, даже если WAN до родителя упал.
• Пишем на краю, отдаём по запросу: по WAN идут синхронизация плюс только те камеры, что смотрят.
• Централизовать все потоки невозможно – 1 500 камер потребовали бы 6 Gbps; федерации хватает десятков Mbps.
• Федерация не централизует хранилище и не служит бэкапом; хранение и архив остаются за площадкой.
• Открытого стандарта федерации VMS – VMS нет – это привязка к вендору; межбрендовый обзор требует PSIM или интеграции на SDK.

Что почитать дальше

• Как работает хранение видеонаблюдения: математика сроков
• Облачное и гибридное хранилище для видеонаблюдения
• Масштабирование VMS: планирование ёмкости и эталонный дизайн хранения