Проектирования IP-систем видеонаблюдения

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

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

1. Архитектура построения видеосистемы

❖ Централизованная архитектура

В этом случае потоки со всех видеокамер отправляются на центральный видеосервер, на который ложится вся нагрузка. Используя тот факт, что требования к вычислительной мощности у современных видеосистем снизились, а процессоры компьютеров стали более производительными, — можно строить большие системы на «суперсерверах», обслуживающих десятки, а то и сотни видеокамер. Понятно, что при этом необходимо иметь широкие и недорогие каналы связи с камерами для непрерывной передачи информационных потоков. Благодаря тому, что на рынке серверных платформ имеются конструкции с возможностью сборки дисковых массивов, имеющих до 24 посадочных мест для жестких дисков, на их основе можно строить системы емкостью до 96 Тбайт архива и более в теле самого сервера. Разумеется, требуется учитывать производительность дисковой подсистемы, она лежит в пределах 200-2000 Мбайт/с, в зависимости от типа используемых дисков (SAS, SATA, SSD), типа реализованного RAID-массива и используемого RAID-контроллера. Рассчитать эти параметры, а так же необходимые конфигурации оборудования помогут калькуляторы на сайтах производителя ПО. Следует учесть, что использование высокооборотных SAS-носителей, либо SSD-дисков, а также избыточных RAID-массивов ведет к удорожанию системы. Если емкости встроенного в корзину сервера дискового массива недостаточно, можно использовать внешние.

❖ Достоинства

Используя одну машину на серверной платформе, можно получить систему на десятки или даже сотни камер, если речь идет только о записи и трансляции цифрового видеоконтента. Если предполагается видеоаналитика, то загрузку видеосервера считают, исходя из рекомендаций производителя ПО.

❖ Недостатки

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

❖ Распределенная архитектура

Такая архитектура предполагает несколько локальных видеоподсистем, объединенных в одну по каналам LAN и WAN. Система представляет из себя несколько небольших локальных серверов, имеющих на своем борту определенный массив жестких дисков, на который пишется видеоконтент данного сервера. Архитектура такого вида хорошо работает в системах любого размера. В качестве элементов системы могут использоваться как локальные видеосерверы (видеорегистраторы), так и энкодеры, дисковые массивы, и даже сами IP-видеокамеры, имеющие на борту собственное устройство хранения. Максимальное количество таких серверов в системе определяется требованиями используемого ПО. Использовать можно как серверные, так и «десктопные» (бытовые) платформы невысокой надежности. В данную архитектуру хорошо вписывается концепция блейд-сервера, т.е. ультракомпактного сервера, имеющего модульную архитектуру, позволяющую легко наращивать производительность путем добавления соответствующего вычислительного модуля. Блейд-системы состоят из набора блейд-серверов и внешних компонентов, обеспечивающих невычислительные функции.

❖ Достоинства

Это простой способ объединить в одной системе разные (для аналоговых и IP-камер) видеосерверы, если используется ПО одного производителя. Такой путь подходит для развертывания небольших, но территориально распределенных объектов с единым центром мониторинга. Кроме того, обеспечивается легкость масштабирования.

❖ Недостатки

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

2. Отказоустойчивость и снижение нагрузки на систему

❖ Кластерная организация

При развертывании мультисервер-ных систем полезна функция мониторинга состояния системы. По IP-каналам между серверами происходит обмен метаданными о текущем состоянии входящего в систему оборудования. Некоторые производители ПО предоставляют также возможность, в случае отказа одного из серверов, «живым» серверам перехватывать на себя сигнал с «осиротевших» видеокамер. Однако эта ситуация чревата тем, что сервер может взвалить на себя неподъемную ношу. Поэтому другие производители предлагают использовать для этого сервер, который стоит на «подхвате» незагруженным. Для реализации задачи оптимальна кластерная организация видеосистемы. Под кластером понимается группа компьютеров, объединенных в одну локальную (в нашем случае) систему, имеющую одну общую задачу. Часть ресурсов кластера может быть не задействована. С внешней точки зрения кластер выглядит как единое целое, а наличие нескольких узлов способствует повышению производительности и устойчивости к отказам. Подсистема обнаружения и нейтрализации отказов постоянно отслеживает доступность ресурсов, составляющих кластер. При обнаружении неисправности запускается процесс реконфигурации, изолирующий вышедший из строя компонент при сохранении работоспособности кластера в целом.

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

❖ Лерезапуск при сбоях

В системах попроще полезна функция перезапуска видеосервера при сбоях — Watchdog (сторожевой таймер). Такие таймеры позволяют не только отслеживать зависание видеосистемы (и перезагружать ее), но и отслеживать состояние отдельных программ и компонентов аппаратного обеспечения системы в целом.

❖ Поддержка многопоточности

Для оптимизации информационных потоков и снижения требований к серверу, производители ПО используют функцию многопоточности современных IP-видеокамер. Современные видеокамеры могут формировать одновременно несколько видеопотоков с разным разрешением. Используя это, видеосервер транслирует на удаленное рабочее место в мультиоконном режиме потоки с малым разрешением, а при переходе в однооконный режим — основной полноразмерный поток. Таким образом, компьютеру оператора не требуется пересчитывать размеры транслируемого видеоизображения под размеры отображаемого окна. Это сильно разгружает процессор.

Кроме того, современные видеокарты имеют функцию аппаратного декодирования кодеков MJPEG, H.264, MPEG-4 и др., что может еще существеннее разгрузить процессор клиентского компьютера либо сервера с отображением, в случае ее использования.

❖ Аппаратный детектор

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

❖ Линза

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

❖ Поддержка многозадачности

При проектировании IP-видеосисте-мы на мощных серверных платформах следует выбирать ПО тех производителей, которые уделяют внимание поддержке и многопоточности, и многозадачности процессоров сервера. Это означает возможность равномерного распределения нагрузки как между ядрами одного процессора, так и между несколькими процессорами сервера. Иначе может получиться следующее: приобретя мощное многоядерное и многопроцессорное «железо», вы использовать будете только 5-10% его возможностей. Обусловлено это еще и тем, что компания Microsoft этому вопросу уделяет пока недостаточно внимания в своих продуктах. И разработчикам приходится полагаться на свои силы.

❖ Multicast-трансляция

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

❖ Приложение или служба?

У разных производителей запуск основного ПО видеосистемы (видеоядра) возможен или как приложения, или как службы. Второе предпочтительней, т.к. в этом случае при аварийном перезапуске сервера (например, при сбое по питанию) видеоядро запустится сразу после запуска ядра операционной системы (ОС) и без запроса авторизации пользователя, отключить которую в серверных Windows-ОС не получится.

❖ Оптимизация потоков

Для уменьшения нагрузки на сеть и оптимизации потоков некоторые производители предлагают ставить компьютеры с соответствующим ПО, играющие роль шлюза. В этом случае видеопотоки от видеосерверов системы передаются на шлюз, а уже он отдает потоки, адресованные на другие серверы и удаленные рабочие места. Таким образом, количество потоков от каждого видеосервера уменьшается в N-1 раз, где N — количество серверов в системе. Однако в случае распределенной видеосистемы, при условии полной поддержки ею многопоточности, актуальность такого ПО снижается.

❖ Запись видеопотоков с малым разрешением

Еще одна полезная функция, которую могут предложить производители ПО для IP-видеосистем — это запись с видеокамеры дополнительного видеопотока с малым разрешением наряду с основным (полноразмерным). Она позволяет синхронно просматривать архивы сразу нескольких десятков камер в многооконном режиме (в том числе и на мультисерверных системах) без существенного увеличения трафика сети и нагрузки как на сервер (в случае сервера с отображением), так и на клиентский компьютер. Правда, плата за это -дополнительный расход дискового пространства, обычно не более 10% от размера основного архива. Особенно данная функция может быть полезна при трансляции архива по интернет-каналам на удаленные устройства, в том числе и мобильные. В случае с мобильным приложением мы получаем видео из архива сервера сразу с малым разрешением, например, CIF, не используя дополнительных ресурсов мобильного устройства, не расходуя дорогой мобильный трафик.

❖ Мобильные приложения

Для облегчения жизни своим пользователям некоторые производители ПО видеонаблюдения предлагают мобильные приложения, использующие Push и RSS-технологии, которые закачивают видеоконтент в мобильное устройство в фоновом режиме перед тем, как оповестить пользователя о событии, связанном с этим контентом, экономя, таким образом, его время на просмотр видеокадров. Критерий, по которому это событие должно возникнуть, определяет сам пользователь при настройке сервера. А одна компания пошла дальше всех и предлагает пользователю, используя технологию видеосемантики, сжатый в пятиминутный ролик суточный архив, переданный на мобильное устройство пользователя в фоновом режиме. Правда, такие приложения полнофункционально работают пока лишь на андроид-платформах.

3. Организация работы с базами видеоданных

Большинство производителей ПО видеонаблюдения используют для этого некоммерческую версию MS SQL Server. Обычно это облегченная версия данного продукта. Ее возможностей хватает для реализации задач большинства локальных и распределенных видеосистем. При развертывании глобальной видеосистемы в задачу может входить:

■ Обеспечение оперативного доступа к базам данных объемом порядка пета-байт, эффективное управление третичной (медленной) памятью.

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

■ Обеспечение эффективных механизмов просмотра и поиска требуемой информации.

■ Возможность репликации данных. Т.е. дублирование базы данных на нескольких серверах для повышения эффективности доступа к информации, когда система должна гарантировать регулярное обновление и синхронизацию копий.

В этом случае рекомендуется использовать полную версию MS SQL Server. Следует также учесть, что табличное пространство или tablespace -логическое пространство, которое СУБД использует для хранения объектов базы данных, таких как индексы, таблицы, можно разместить на быстрых носителях (обычно на системных дисках). А пространство, используемое для архивных видеоданных, — на менее быстрых, но значительно более емких RAID 5-10 массивах данных. Обычно такое размещение производится по умолчанию, при инсталляции системы.

Некоторые производители ПО предлагают собственные программные средства для работы с базами данных видеоконтента. В простейшем случае используются стандартные средства MS Windows для работы с физическими носителями.

4. Критерии выбора видеосервера

❖ Малобюджетные решения

Если особых требований не предъявляется (просмотр и запись), тогда можно обратить внимание на готовые недорогие решения, их называют IP-видеорегистраторы или IP-видеосерве-ры, или Stand-alone-видеорегистрато-ры. В этом качестве могут выступать IP либо гибридные видеорегистраторы на платформе Linux. Очень полезно, если производитель видеосервера предлагает под своим брендом еще и видеокамеры, из линейки которых мы сможем выбрать себе подходящую. При этом неплохо бы иметь и клиентское ПО для удаленного мониторинга и администрирования того же производителя или адаптированное. Как правило, это же ПО, называемое CMS, позволяет создавать мультисерверные системы, включающие несколько устройств видеорегистрации, объединенных в один интерфейс пользователя, с возможностью просмотра как «живого видео», так и архива, и администрирования, но с ограниченной функциональностью. Такие видеорегистраторы могут быть как чисто IP, так и гибридными, т.е. с возможностью подключения ограниченного количества аналоговых каналов. Обычно количество подключаемых видеокамер

этого вида систем не превышает 16. Надежность таких систем невелика, хотя поддержка RAID-уровня 0;1 уже появилась и у них. Справедливости ради следует сказать, что современные Stand-alone-видеорегистраторы имеют в своем арсенале такие полезные инструменты, как контроль состояния жестких дисков, оптимизацию при работе по сети (трансляцию нескольких видеопотоков), функцию запланированного перезапуска (для избавления от накопившихся ошибок), возможность трансляции тревожных снимков и видеороликов на FTP-сервер либо на электронную почту. Некоторые производители даже закладывают поддержку облачного сервиса и внешних 3G-модемов, но это скорее маркетинговый ход, чем реально полезная функция. Кроме этого многие производители предлагают в качестве бонуса свое ПО для мобильных платформ.

❖ Решения для средних систем

Если требуется построить систему, адаптированную к работе по Ethernet, Inthernet, с развитой аналитикой, интеграцией со СКУД, ОПС, и при этом нет особых требований к надежности и бесперебойности работы системы, тогда можно обойтись комплектующими из недорогих бытовых (десктопных) платформ. Существуют такие недорогие «коробочные» решения и на Linux и на Windows, но и для них желательно использовать жесткие диски из серверной линейки (время их жизни будет в разы дольше) либо диски с приставкой «для видеонаблюдения». Если требования к надежности системы высоки, а бюджет невелик, тогда можно использовать функциональную возможность современных бытовых платформ на PC -создавать небольшие RAID-массивы. Не лишне при этом выделить системный диск на отдельный физический носитель небольшой емкости, как наиболее уязвимый элемент системы. Понятно, что надежность такой системы будет уступать полнофункциональным серверным платформам, однако мы оградим себя от краха архива без возможности восстановления, а также снизим трудоемкость ремонта такой системы. Для бытовых платформ можно рассматривать вариант с недорогим внешним массивом жестких дисков NAS. Правда, если они выступают как сетевые, а не системные устройства, то в случае обрыва связи некоторые простые видеосистемы могут просто этого «не заметить». Понятно, что можно использовать и быстродействующие дисковые массивы с организацией RAID и соответствующими контроллерами, но в этом случае теряется баланс стоимости компонентов видеосистемы.

❖ Решения для больших систем

Если требуется построить систему, включающую большее количество камер, либо имеющую более высокую надежность, то следует обратить внимание на системы, построенные на серверных платформах с организацией RAID-массивов из жестких дисков. Жесткие диски — это наименее долговечная часть системы, которая рассчитана на 2-3 года эксплуатации, и когда они начинают «сыпаться» — система выходит из строя. Кроме программно-аппаратного контроля и резервирования всех систем серверной платформы, она предоставляет, при помощи BMC-контроллера, IPMI-интерфейс для мониторинга и управления оборудованием, в том числе позволяет отслеживать состояние датчиков, управлять питанием, прошивками и дисками удаленно. Еще следует обратить внимание на используемый чип Ethernet-контроллера, который должен поддерживать современные технологии: VMDq, SR-IOV, в противном случае он не годится для обслуживания интенсивного сетевого трафика. Достаточный для задач управления, он порождает дополнительные задержки при обслуживании интенсивных сетевых потоков. Весь процесс передачи данных через такой чип обеспечивается за счет ресурсов процессора, оперативной памяти и нагрузки на внутренние шины. Каждый принимаемый и передаваемый Ethernet-пакет требует отдельного прерывания на процессор. Поэтому рекомендуется при интенсивном сетевом трафике добавить отдельную сетевую плату на серверных комплектующих, если таковые отсутствуют. Если емкости встроенного в корзину сервера дискового массива недостаточно, можно использовать внешние дисковые массивы с недорогими производительными внешними интерфейсами, например ISCSI.

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

---

сирены,  источник питания,  IP-видеосерверы,  видеонаблюдения,  программное обеспечение,  видеорегистраторы,  мониторы,  Smartec,  видеокамеры,  новинки