Особенности организации ИТ-инфраструктуры для видеонаблюдения



    Рынок систем видеонаблюдения (сейчас стали использовать модный термин Video Surveillance) развивается быстро и очень технологичен. Крутизна современных систем видеонаблюдения определяется не только мощью видеокамер и функциональностью ПО, но и ИТ-инфраструктурой, которая будет всё это добро обслуживать.

    Конечно, речь не идет о небольших инсталляциях на пару десятков камер, где можно обойтись одним компом, простым сервером или NVR-ом и, естественно, рассматриваются только IP-решения, аналоговое видеонаблюдение осталось в прошлом.

    Когда дело касается сотен и даже тысяч видеокамер одним сервером или готовым решением из коробки обойтись не получится, особенно если необходимы дополнительные функции, связанные с видеоаналитикой (обнаружение, слежение, распознавание), интеграцией с кассовыми решениями, интеграцией в комплексные системы безопасности (СКУД, ОПС). В таком случае оптимальным решением является использование специализированного ПО для видеонаблюдения – VMS (Video Management Software), которое предусматривает возможность масштабирования и поддержки большого количества IP-камер, а также все необходимые для проекта функции и возможности.

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

    • локальные носители серверов;
    • Direct Attached Storage (DAS) — дисковые полки, подключаемые к серверам напрямую;
    • и/или выделенные СХД с файловым или блочным доступом.

    Естественно, под серверами мы понимаем серверы, на которые установлено ПО видеонаблюдения (VMS), условно будем их называть — видеосерверы.
    Обработка большого количества видеопотоков с высокими характеристиками требует серьёзных вычислительных мощностей. В первую очередь это касается процессорных ресурсов, в плане оперативки видеосерверы, как правило, не прожорливы, обычно хватает 8-16ГБ ОЗУ на сервер, но конечно встречаются исключения.

    Требования к видеосерверу на 100 потоков


    Попробуем оценить требования к вычислительным ресурсам и, самое главное, к подсистеме хранения, которые предъявляются в серьезных проектах по видеонаблюдению. Будем исходить из того, что видеосерверы осуществляют прием, обработку и запись видеопотоков в архив, а также другой необходимый функционал VMS, без упора на видеоаналитику, которая в разы увеличивает требования к вычислительным ресурсам. Отображение картинки с IP-камер для мониторинга в реальном времени и воспроизведение видео из архива должно осуществляться с выделенных УРМ (Удаленных Рабочих Мест), что позволяет снять с видеосерверов значительную часть вычислительной нагрузки (до половины). УРМ видеонаблюдения представляют собой довольно мощные ПК уровня графический станций со специальным клиентским ПО для подключения к VMS и возможностью вывода множества картинок на большие экраны.

    За основу возьмем поток с одной IP-камеры по протоколам ONVIF (открытый стандарт взаимодействия IP-камер и VMS), с разрешением Full-HD (1920x1080), базовым кодеком H.264 и частотой 25 кадров в секунду, при условии высокой активности в кадре. Согласно онлайн-калькулятору ITV|AxxonSoft, одного из лидеров рынка VMS, такой видеопоток генерирует трафик 6,86 Мбит/с.

    Вычислительные ресурсы, необходимые для обработки 100 видео-потоков с запасом могут быть обеспечены 4х-ядерным процессором Intel Xeon E3-1225 V3. По текущим меркам проц довольно слабый, на ОЗУ достаточно выделить 8-16ГБ. В итоге в плане мощности можем обойтись недорогим 1U серваком или даже хорошим настольным ПК. Однако с хранилищем под архив видеозаписей дела обстоят сложнее.

    Для хранения видеоархива глубиной 1 месяц (стандартное требование) на 100 потоков при условии круглосуточной записи потребуется хранилище с полезной ёмкостью порядка 212ТБ, что можно подтвердить чудовищно сложными расчетами:

    (6,86Мбит/с * 3600с * 24ч * 30д *100камер) / (8*1024*1024) = 211,97 ТБ, поскольку 1ТБ = 8*1024*1024 Мбит

    Такой объем хранилища достигается за счет использования большого количества дисков высокой ёмкости (4-6-8-10 ТБ). Они могут использоваться независимо, каждый сам по себе, тогда VMS будет писать на них данные последовательно либо распределять их по всем дискам сразу, в зависимости от производителя. Минусы такого подхода:

    • надежность — при выходе из строя диска, теряется часть видеоархива;
    • производительность — упираемся в производительность одного диска если запись не распределяется по дискам на уровне ПО видеонаблюдения.

    Использование RAID-массивов


    Решение проблемы — объединение дисков в RAID-массивы (RAID-группы). Для локальных и напрямую подключенных к серверам дисков — с помощью выделенных аппаратных RAID-контроллеров.

    Технология RAID имеет несколько уровней (методов реализации), основные из них: 0, 1, 10, 5, 6, 50, 60. RAID-0 — страйпинг, данные параллельно пишутся на все диски массива. RAID-1 и RAID-10 — зеркалирование, запись данных дублируется на пары дисков. Уровни 5, 6, 50, 60 – контроль четности, осуществляют вычисление контрольных суммы, которые распределяются по всем дискам при этом утилизируют эквивалент ёмкости одного или двух дисков массива (дисковой группы).

    RAID-0 — это классика жанра, тип массива горячо любимый отдельными горе-айтишниками и отдельными интеграторами видеонаблюдения. Скорость максимальная и никаких накладных расходов на избыточность — её нет, полезный объём равен сырому. Соответственно, при вылетании одного диска мы теряем все данные в массиве без возможности восстановления. Этот уровень RAID подходит только для тестовых сред, где потеря данных допустима и некритична, в любых прикладных задачах RAID-0 неприемлем, в т.ч. и для видеонаблюдения.

    RAID-1 — не подходит поскольку, поскольку рассчитан только на 2 диска.

    RAID-10 (RAID-0 из множества зеркальных пар RAID-1) — не подходит, поскольку накладные расходы слишком велики, из общей сырой ёмкости полезной будет только половина. На последовательных операциях будет уступать по скорости записи уровням 5, 6, 50, 60.

    RAID-5 и RAID-50 (RAID-0 из нескольких одинаковых групп RAID-5) — имеют чуть меньше накладных расходов, чем RAID-6 и RAID-60 (один диск на избыточность в дисковой группе вместо двух) и работают быстрее, но позволяют пережить отказ только одного диска. В случае перестроения таких массивов нагрузка на них многократно возрастает и вероятность выхода еще одного диска резко повышается, это особенно актуально для видеонаблюдения, где используются диски больших объемов, которые, соответственно, и перестраиваются дольше. Если до завершения перестроения вылетит ещё один диск, то хана данным на всём массиве, они будут потеряны. Поэтому использовать RAID-5 и RAID-50 для видеонаблюдения нежелательно.


    Для видеонаблюдения оптимальными являются уровни 6 и 60 (RAID-0 из нескольких одинаковых групп RAID-6), поскольку они дают максимальную надежность и позволяют пережить одновременный отказ любых двух дисков.


    Вообще, уже много лет использование RAID-6 и RAID-60 является лучшей практикой для любых задач в ИТ-индустрии из-за их отказоустойчивости, хотя на случайном доступе конечно приходится использовать RAID-10.

    Для видеонаблюдения данные уровни RAID особенно актуальны, поскольку показывают отличную производительность на последовательном доступе, характерном для видеопотока. В такой ситуации RAID-6 или RAID-60 предпочтительнее RAID-10 поскольку:

    • скорость последовательно записи выше — в RAID-6/60 больше полезных шпинделей, чем в RAID-10;
    • накладных расходов меньше — всего два диска под избыточность на всю дисковую группу в RAID-6/60, вместо половины дисков в RAID-10;
    • отказоустойчивость выше — RAID-6/60 позволяет отработать одновременный отказ любых двух дисков, RAID-10 гарантирует сохранность данных при отказе только одного диска.

    Следует отметить важный недостаток RAID-6 и RAID-60 по сравнению с RAID-10 – значительная просадка производительности в деградированном состоянии, когда вылетает один и тем более два диска, с RAID 5 и 50 ситуация та же. RAID-10 контрольные суммы не считает, что практически исключает просадку производительности. Однако, учитывая, что половина ёмкости в RAID-10 уходит под зеркало, для видеонаблюдения, в котором нужны очень большие объёмы, его применять не рационально. Если использовать производительные аппаратные RAID-контроллеры или СХД, правильно планировать массив и систему в целом, деградация массива RAID-6/60 не вызовет катастрофы, при этом ёмкость дисков будет использоваться эффективно.

    Планирование хранилища видеосервера на 100 потоков


    Возвращаемся из теоретического экскурса в RAID-технологии и вспоминаем, что нам нужен массив на 212ТБ. Для организации хранилища такого объема при условии использования RAID-6 или RAID-60 нам понадобится 26-30 HDD по 10ТБ:

    • 1 группа RAID-6 из 26 дисков: 24 диска — полезный объём, 2 диска — контрольные суммы;
    • 2 отдельные дисковые группы RAID-6 по 14 дисков или аналогичный RAID-60;
    • 3 отдельные дисковые группы RAID-6 по 10 дисков или аналогичный RAID-60.

    Такое количество дисков можно разместить только в специальной стоечной серверной платформе 4U, либо использовать внешнюю дисковую полку в комплекте с 1U-сервером, на котором будет выполняться обработка потоков. В любом случае будет необходимо использование хорошего выделенного (не встроенного в материнку) аппаратного RAID-контроллера с поддержкой RAID-6/60, который сможет вытянуть такое количество дисков и обеспечить нормальную работу массива в случае деградации — отказа 1-2 дисков.

    Требования к видеосерверу на 500 потоков


    Рассмотрим требования к системе на 500 IP-камер. В этом случае нам потребуется два процессора Intel Xeon E5-2630 V3 (8 ядер по 2,4ГГц), а лучше два Intel Xeon E5-2680 V3 (12 ядер по 2,5ГГц). Стало быть, серверная платформа должна быть двух-процессорной и мы по-прежнему можем обойтись одним серваком.

    Полезная ёмкость видео-архива в данном случае переваливает за 1ПБ, а если точно – составляет
    1 059,84 ТБ, это 117 дисков по 10ТБ, для кратности и с запасом лучше взять 120 дисков. Накладные расходы на размещение контрольных сумм в RAID-массиве потребуют еще 10-20-30 таких дисков, например, 5-10-15 дисковых групп RAID-6/60 по 26-14-10 дисков. Такое количество дисков не войдет ни в одну стандартную серверную платформу (максимум 24-36 HDD 3,5’’ на сервер 4U), понадобятся внешние дисковые полки. В данном случае одним из вариантов решения будет 2х-сокетный сервер 1U и две 4U дисковые полки (90+60 HDD), подключенные каскадом. Правильный RAID-контроллер сможет вытянуть нужное нам количество дисков, двумя кабелями Mini-SAS HD подключаем его к первой корзине (дисковой полке), а вторую корзину двумя такими же кабелями цепляем к первой.



    Распределение нагрузки и лирическое отступление


    Мы рассмотрели примеры проектирования ИТ-инфраструктуры для систем видеонаблюдения на 100 и 500 IP-камер, генерирующих серьёзную нагрузку. Назвать такие системы видеонаблюдения мелкими и дешевыми никак нельзя. Система на 100 камер это как минимум средний проект, а 500 уже крупный. Тем не менее, в обоих случаях мы смогли обойтись одним сервером, в первом случае без дисковых полок или с одной, во втором хватит двух больших корзин.

    В плане вычислительной мощности и производительности дисковой подсистемы подход работает, один сервер всё вывозит. Значения в 100 и 500 потоков довольно условны, определяется особенностями проекта, сложностью нагрузки и выбранной VMS. На практике реальными цифрами скорее будут 50-100-200 потоков на сервер. Ведь если задача предполагает серьёзную видеоаналитику, либо осуществляется постоянный многопоточный просмотр данных из архива, мы можем упереться в производительность очень крутых процессоров и дисковой подсистемы уже на 50-100 потоках. Соответственно, если камер сотни и даже тысячи, необходимо разворачивать ферму (множество) видеосерверов, каждый из которых возьмет свою долю потоков: 50, 100 или 200 в зависимости от нагрузки и аппаратной конфигурации. Распределение нагрузки по множеству идентичных видеосерверов, каждый из которых хранит данные на дисках подключенных напрямую (DAS), для видеонаблюдения стандартная практика.

    В более простых ситуациях, когда от системы требуется просто стабильная качественная запись видео без дополнительной нагрузки на аналитику, а просмотр из архива осуществляется по одной камере (время от времени, а можно и постоянно) — 500 IP-камер на сервер уже более реально. Если поставить 18-ядерные процы, несколько RAID-контроллеров и кучу дисковых корзин, то на один сервак теоретически можно повесить и 1000+ потоков. В принципе большие системы можно строить из нескольких серверов на 500+ камер, следуя указанной выше концепции набора DAS-серверов.

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

    Необходимость резервирования


    Вернёмся к делу, использование концепции DAS-серверов (один мощный сервер или пул серверов) для построения больших систем видеонаблюдения при всей своей прелести имеет очень серьёзные недостатки в плане отказоустойчивости и сопровождения подсистемы хранения.

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

    Если система видеонаблюдения построена на одном сервере, и он не дублируется (резервируется), то мы кладём яйца в одну корзину. В случае если этот видеосервер гикнется (выйдет из строя), а такое случается, видео будет писать некуда, пока мы его не наладим, при этом есть риск потерять видеоархив, частично или целиком. Особенно это опасно для яиц стероидных монстров на 500+ камер, поскольку всё завязывается на единственный сервер, лучше этого избегать и распределять нагрузку по нескольким серверам.

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

    Однако потеря сотни или нескольких сотен камер на время восстановления видеосервера во многих случаях неприемлема. Поэтому необходимо предусматривать резервирование видеосерверов. Для этого к пулу серверов видеонаблюдения необходимо добавить один или несколько выделенных резервных серверов. В нормальном режиме, когда все основные серверы живы, резервные серверы простаивают, но если один или несколько основных серверов падает, VMS автоматически переключает их потоки на резервные серверы. Вычислительная мощность и конфигурация резервных серверов в идеале должна быть идентична основным, ёмкость их хранилища должна обеспечить приемлемую глубину архива на время восстановления основных серверов. Естественно VMS должна поддерживать функционал резервирования или кластеризации и должна быть куплена соответствующая лицензия.

    Подход с использованием СХД


    Альтернативный подход, на наш взгляд более правильный, надежный и технологичный — разделение вычислительных ресурсов и ресурсов хранения. В таком случае мы делаем отказоустойчивый кластер из нескольких серверов 1-2U на которых устанавливается VMS и происходит обработка видеопотоков, а данные храним на одной или нескольких отказоустойчивых двух-контроллерных внешних системах хранения данных (СХД). Масштабировать эти два набора ресурсов можно независимо, увеличивая количество серверов кластера, производительность и дисковые ресурсы СХД.

    Правильная СХД в отличии от сервера не имеет единых точек отказа. СХД — это специализированный программно-аппаратный комплекс, единственными задачами которого являются надежное хранение и обеспечение требуемой скорости ввода/вывода данных, отказоустойчивость закладывается в неё по умолчанию.

    Если СХД является единым решением, то все её элементы дублируются или обеспечивается их избыточность. Основным элементом СХД является контроллер (storage processor), он осуществляет обработку ввода/вывода, объединение дисков в RAID-группы и создание на них логических разделов или томов, которые предоставляются конечным устройствам (видеосерверам — узлам кластера), хранящим данные на СХД. Правильная СХД имеет два контроллера. В нормальном режиме оба контроллера делят нагрузку пополам, если один из них сдох (отказал), то второй без остановки автоматически возьмёт на себя всю нагрузку, это будет прозрачно и незаметно для конечных узлов (видеосерверов). RAID-группы в которые объединяются диски СХД позволяют пережить отказ одного или нескольких дисков. Сетевые интерфейсы и блоки питания дублируются. Это значит, что в СХД нет ни одной единой точки отказа, не дублируется в ней только пассивная печатная плата, которая теоретически сломаться не может. Вывести из строя такую СХД, можно только топором или ведром воды, а на этот случай можно «завести проездной» и для полного счастья реплицировать данные на вторую такую же СХД. Да дорого, но, если задача настолько критична, то никаких денег не жалко, главное, что такая техническая возможность есть.

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

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

    Организация сети хранения данных


    Подключение видеосерверов к СХД осуществляется по протоколам файлового (NAS, например, NFS или SMB) или блочного (SAN, например, iSCSI, FC, iSER) доступа и в идеале требует создание выделенной сети хранения данных. Для этого каждый видеосервер должен быть оборудован соответствующими физическими адаптерами, желательно выделенными и задублированными. Ядром сети хранения будет выступать пара выделенных коммутаторов, соединяющих множество видеосерверов с СХД. Физическое выделение сети хранения из остальных сетей передачи данных, использование для её организации отдельного оборудования с дублированием (коммутаторы и адаптеры) будет гарантировать её простоту и прозрачность, безопасность и изоляцию, заданную пропускную способность и отказоустойчивость.



    В простейшем случае для организации сети хранения достаточно пары производительных коммутаторов 10GbE (Ethernet, 10Гбит/с) и пары выделенных портов 1-10GbE на каждый видеосервер, при этом в качестве транспорта можно использовать файловый NFS или блочный iSCSI. Теоретически в ситуациях требующих большей производительности (очень крупные проекты) могут понадобиться конвергентные адаптеры Ethernet или Infiniband (IB) с поддержкой RDMA (SRP, iSER, RoCE) и соответствующие коммутаторы, причем на серверах скорее всего с избытком хватит портов 10Гбит/с, а на коммутаторах и СХД понадобится не менее 40Гбит/с. Также может быть полезен старый добрый Fibre Chanel (FC, 16Гбит/с), если хватит пропускной способности.

    Преимущества использования СХД для видеонаблюдения


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

    • Уход от необходимости организации и сопровождения локальных или DAS дисковых массивов на серверах. Практически все данные систем видеонаблюдения хранятся централизованно на СХД, локальные диски на серверах нужны только для создания загрузочных разделов с ОС и установленной VMS. Для их организации хватит пары небольших бюджетных носителей объединённых в RAID-1 на базе встроенного в материнку контроллера.

    • Для организации видеосерверов оптимальным вариантом платформы будет компактный и производительный 1U-сервер. Необходимость использования громоздких 2-4U серверных платформ или DAS-полок отпадает. Вместе с этим уходит необходимость установки дорогостоящих аппаратных RAID-контроллеров в каждый сервер.

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

    И напоследок, неоспоримый аргумент в пользу использования СХД в серьёзных проектах для видеонаблюдения. Он работает независимо от количества VMS-серверов, даже в случае если кластер включает только два видеосервера — основной и резервный. СХД является общим хранилищем и всегда доступно всем узлам кластера видеонаблюдения. Поэтому при падении одного из основных узлов резервный узел подхватит все его видеопотоки и продолжит их писать в архив на тот же том, поскольку он находится на СХД. Фактически произойдет переезд сущности VMS-сервера с отказавшей основной железки на резервную со всеми настройками. Можно будет прозрачно работать с видеоархивом данного сервера на всё его глубину. Конечно такая возможность должна поддерживаться на уровне ПО видеонаблюдения (VMS).

    В традиционном DAS-подходе с локальными массивами так сделать не получится, поскольку организовать общее хранилище невозможно. При падении сервера его локальный массив становится недоступен, резервному серверу придется писать архив в своё локальное хранилище, работа с архивом будет доступна только в рамках записанных после падения данных, архив с основного сервера для просмотра будет недоступен. После восстановления основного сервера возникнут вопросы с синхронизацией архивов. Это серьёзный недостаток.

    Резюме


    В этой статье мы постарались разобраться в особенностях организации ИТ-инфраструктуры и подсистемы хранения данных для видеонаблюдения. Рассмотрели преимущества и недостатки подходов использования серверов с локальными (DAS) хранилищами и СХД. Пришли к выводу, что для крупных проектов, не допускающих простоев, отказов и деградации функциональности, использование СХД для хранения видеоархивов является оптимальным решением, несмотря на некоторую сложность.

    В следующей статье будут рассмотрены критерии выбора СХД для видеонаблюдения. На десерт — описание крупного проекта по видеонаблюдению на 2000 камер с реализацией хранилища на базе RAIDIX.
    RAIDIX
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 22

      0
      > 3 отдельные дисковые группы RAID-6 по 10 дисков или аналогичный RAID-60.
      Из опыта, в случаи DAS хранилищ использовать такую конфу не оптимально, ребилды очень долгие особенно на высокоплотных дисках.
      раид группы оптимальнее собирать из 5+- дисков, и обязательно 1 глобальный spare disk.

      Но как только начинается аналитика, требуются уже процы.
        0
        Спасибо. Для стандартных серверных ИТ-задач производители дают именно такие рекомендации. Если диски большие — не делай большие ДГ.

        Если не секрет ваш опыт на дисках какого объёма и на каких контроллерах?
          0
          LSI 9271 и Adaptec 8805. Диски от 4х до 8 Гб в зависимости от времени приобретения.
          3U сервера на 26 дисков.
          0
          У NetApp есть ящики на 60 дисков с DDP, который на четверть быстрее R6 по иопсам и на порядок по скорости ребилда.
            0
            Для видеонаблюдения важен throughput (MБ/с), а не IOPS. Охотно верю, что Нэтап будет производительней обычных аппаратных рэйд-контроллеров, но прямо скажем — это дорогое решение.
          0
          «процы», «сервак», «Ненужно заморачиваться с сетью» — это, по меньше мере, сильно роняет восприятие текста
          но это был просто низкий стиль
          а вот перл «они могут быть ассами» взял поистине олимпийскую высоту
          хотите писАть — уважайте читателя
            0
            Спасибо за ненужно и ассов! Поправили!
            0
            На центральном складе одной дочерней компании одного крупного федерального ритейлера техники несколько лет назат, в войне стыда и экономии, родилось решение на 120 камер Ubiquity AirCam, пяти виртуальных машин с тогда еще совсем бесплатными айвидеонами, на одном физическом сервере, и двух хранилках Lenovo-EMC PX-400 по 26 терабайт полезной емкости на каждом. Никакого резервирования, хранить данные пять недель минимум. Бизнес плевался и ругался, когда айвидеон забывал куски записей, крашился и терял камеры, но раньше было еще хуже (D-Link 2103 + go1984 на локальных дисках, управляющий складом сказал что это хорошее решение, главное что дешево, а то что плохо работает так это ИТшники дураки). Сформулировать техническим языком мораль я затрудняюсь.
              0
              Видимо хотелось за минимум денег получить хорошее решение, но не получилось…
                0
                Это штатный ИТ отдел в не-ИТ компании, решение о покупке принимает не начальник ИТ отдела, а начальник того подразделения, которое несет издержки. Плюс к тому, начиналось это как «мамой клянемся, нам надо 20 камер максимум, и хранить видео неделю, и лучше бесплатно», и за год превратилось в монстра. Качественного видеонаблюдения задёшево не бывает, кто бы что ни говорил. До сих пор всё развитие видеонаблюдения (и вообще всего на филиалах) в огромной компании на 1500 филиалов и 20к сотрудников по всей стране строит инфраструктуру по типу «чем дешевле, тем лучше», то есть удовлетворить требования как можно дешевле. Слава богу это не касается центральных сервисов компании, формирующих костяк инфраструктуры.
              0

              Почему в расчётах не учитывается детекция движения?
              Возможно придётся хранить гораздо меньше, а вот вычислительные ресурсы окажутся гораздо более высокими.


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


              Аппаратные детекторы записи в бюджетных камерах отрабатывают очень некорректно, приходится включать детектор на регистраторе, который можно настроить гораздо точнее. Но включение на всех камерах программного детектора приводило к очень большому потреблению памяти и процессора, пришлось некоторые камеры, где движение регулярно, перевести на постоянную запись.
              В итоге только через пару месяцев добились постоянно корректной работы системы. К слову при этом сэкономили огромную сумму, сделав систему наблюдения на 48 IP FHD камер своими силами и используя бюджетные решения. Цены интеграторов были совсем другого порядка.

                0
                Никто не сможет дать гарантию, что детектор будет корректно срабатывать в 100% случаев. Таким образом есть вероятность, что мы можем не записать важное событие. Поэтому на критичных проектах, объектах или камерах приходится писать постоянно. Иначе бы все и всегда писали только по детектору.
                0
                Почему в расчётах не учитывается детекция движения? — потому, что всё зависит от картинки в кадре, от конкретного проекта. Взяли просто самый общий, самый сложный случай, когда нужно писать постоянно.

                Спасибо за комментарий, интересный.

                Какой VMS пользовались? Как хранилище сделали?
                  0

                  Не делали сами ни систему хранения, ни VMS, воспользовались готовым отечественным решением.
                  Боюсь это всё будет рекламой, а им она не нужна. По запросу "системы видеонаблюдения в Москве" на первом месте.
                  Уже третий год у нас работает два регистратора, один на 32 камеры, другой на 16. Простенькие коробочки, внутри:
                  MB: ASRock Q1900-ITX
                  CPU: Intel® Celeron® CPU J1900 @ 1.99GHz
                  VIDEO: Intel Corporation ValleyView Gen7
                  RAM: в первом 3664MB, во втором 1833MB


                  В каждом по 16GB, в первом 4 HDD, во втором два. Резервирования никакого, нам не критично. Единственное: запись с камеры направленной на один регистратор, пишется на регистратор в другом офисе и наоборот. Проблем пока не возникало.


                  Приведу ещё практические цифры, вдруг кому-то интересно.
                  Поток реального времени с камер разный, в зависимости от картинки, установленного максимального битрейта и fps. Варьируется от 300 кБ/c до 900 кБ/c. Битрейт разный, так как на отдельных камерах он увеличен с 4мБит/c до 8 для распознавания лиц и номеров. Ну и несколько камер у нас 2048х1536, но это на поток меньше влияет, чем сама картинка.
                  Просуммировал отчёт по времени по всем архивам, в среднем камера пишет 6 часов в день, с учётом того, что многие камеры пишут постоянно и круглосуточно. По выходным сильно падает количество записанных часов, так как часть камер в кабинетах.
                  Так же легко вычислить, что в среднем в день камера пишет 15ГБ основного потока.
                  Дополнительный поток ещё 1.5 ГБ. в день и его мы тоже храним, помогает быстро смотреть архивы с телефона.
                  А вот сколько занимает БД событий мне не удалось выяснить, но думаю это мизер по сравнению с видеопотоком.
                  В следующий раз буду покупать более мощный по вычислительным ресурсам регистратор, чтобы писать действительно важные вещи, а не всё подряд. Хочется автоматическое распознавания номеров, лиц, событий.

                    0
                    Если я правильно понял вашего вендора VMS, то камеры у вас Hikvision (бесплатные лицензии на поток).У себя на камерах, где наблюдались проблемы в детекции просто выкрутил чувствительность на максимум и успокоился, возможно зря. Сравнивали ли работу на повышенной\максимальной чувствительности аппаратного детектора и программного? Программный детектор использовали дефолтовый или SIMT?
                      0

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

                        0
                        Не Trassir? А вот про буфер интересно, надо у ТП уточнить. Даже мысли не допускал, что аппаратном детекторе буфер предзаписи и тайм-аут после движения могут не работать.
                          0

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

                            0
                            ТП ответила, что при аппаратном детектере предзапись работает. В любом случае спасибо за полезную информацию. Камер у нас почти на порядок больше, и много движения в кадре (по 15-23 часов записи) — проблема не столь явно проявляется.
                        0
                        Мы с камерами и настройками VMS так глубоко не заморачивались, наша стихия ИТ-инфраструктура, особенно хранение данных, про это и статья.
                    0
                    Вычислительные ресурсы, необходимые для обработки 100 видео-потоков с запасом могут быть обеспечены 4х-ядерным процессором Intel Xeon E3-1225 V3.
                    — а что подразумевается под обработкой?
                      0
                      VMS принимает поток от камеры и пишет его в архив, стало быть — запись в первую очередь.

                    Only users with full accounts can post comments. Log in, please.