Рынок систем видеонаблюдения (сейчас стали использовать модный термин 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
