Сервер для видеонаблюдения (VMS): расчет хранилища и нагрузки

Зачем считать хранилище и нагрузку до покупки сервера

Если сервер под видеонаблюдение выбирают «на глаз», проблемы обычно всплывают не сразу, а через пару недель. Сначала внезапно заканчивается место в архиве, затем тормозит поиск и просмотр. В худшем случае появляются пропуски записи и «рваное» видео в пиковые часы.

Главная ошибка - ориентироваться только на число камер и суммарную емкость дисков. Для VMS важнее не «сколько камер», а сколько данных они реально пишут каждую секунду и как долго эти данные нужно хранить. Две системы на 50 камер могут отличаться в разы по нагрузке: одна пишет 2 Мбит/с на камеру, другая 10 Мбит/с из-за более высокого качества, FPS или сложного сценария.

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

Перед закупкой сервер для видеонаблюдения (VMS) проще всего «приземлить» в трех цифрах:

• Мбит/с - входящий поток записи;
• ТБ - архив на нужную глубину;
• TB/day - объем записи в сутки (насколько «тяжело» дискам).

Эти показатели помогают быстро понять, хватит ли 1G сети, какой класс дисков нужен, и сколько накопителей потребуется с учетом реальной полезной емкости.

Минимум, который стоит зафиксировать заранее: средний и пиковый битрейт по камерам, глубину архива (в днях) и режим записи (24/7 или по событию), общий входящий трафик с запасом на рост, а также TB/day для оценки нагрузки на дисковую подсистему.

Простой пример: сегодня планируется 30 камер «в среднем качестве», а через полгода добавятся еще 20 и вырастет FPS на части точек. Сервер может упереться не в емкость, а в скорость записи и сеть. Расчет до покупки обычно дешевле, чем срочная замена дисков, апгрейд сети и перенос архива потом.

Какие исходные данные собрать по камерам и VMS

Чтобы расчет получился близким к реальности, начните не с дисков и RAID, а с параметров камер и настроек VMS. Сервер для видеонаблюдения (VMS) чаще всего «упирается» в то, что не учли на входе: пики битрейта, второй поток для просмотра, иной режим записи.

По каждой камере полезно собрать паспортные данные и то, как она будет настроена на объекте. Важно отличать «максимум по спецификации» от «так будет работать в проекте».

Что стоит фиксировать (хватит одной таблицы):

• Разрешение, FPS, кодек (H.264 или H.265) и ключевые настройки кодирования.
• Тип сцены и условия: улица или помещение, много движения, фары, снег, листва.
• Управление битрейтом: CBR или VBR и заданный лимит (если он есть).
• Режим записи: постоянная, по движению, по расписанию, с предзаписью и постзаписью.
• Сколько потоков реально будет использоваться: основной на запись, субпоток на «живой» просмотр, дополнительные потоки для мобильных клиентов или видеостены.

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

Дальше уточните, что VMS делает помимо записи. Детекция движения на камере и детекция на сервере - это разные нагрузки. Аналитика, распознавание, транскодирование для удаленного доступа, шифрование, много одновременных просмотров могут потребовать больше CPU/GPU и памяти, чем сама запись.

Пример из практики: на складе 40 камер пишут постоянно, охрана одновременно смотрит 16 камер, а руководитель открывает мобильный просмотр в дороге. Если заранее не учесть субпотоки и число подключений, расчет по хранилищу будет верным, но сеть и сервер начнут «задыхаться» в часы пик.

Как посчитать и проверить битрейт камер

Битрейт - это сколько данных камера реально передает и записывает в секунду. Он напрямую влияет на сеть, диски и итоговую стоимость архива. И он не равен разрешению: две камеры 4 Мп могут давать разный поток из-за кодека, FPS, уровня сжатия и того, что происходит в кадре.

Для первичной оценки используют типовые диапазоны и сразу закладывают запас. В расчет часто берут средний битрейт, но закупку планируют по пиковому. Иначе сервер для видеонаблюдения (VMS) будет упираться в сеть или запись в самые неудобные моменты.

Ориентиры для «нормальной» картинки при 15-25 FPS:

• 1080p: H.264 2-6 Мбит/с, H.265 1-4 Мбит/с
• 4 Мп: H.264 4-10 Мбит/с, H.265 2-7 Мбит/с
• 4K: H.264 8-20 Мбит/с, H.265 4-14 Мбит/с

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

Самый надежный способ - измерить реальный битрейт тестом. Достаточно 15-30 минут записи в типичных условиях и отдельно в худших (ночь, снег, часы пик), затем посмотреть, какой объем получился.

Практичная проверка:

• включите кодек, разрешение и FPS, как в проекте;
• запишите тестовый фрагмент 15-30 минут;
• разделите размер файла на время записи и переведите в Мбит/с;
• повторите для «сложной» сцены.

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

Расчет объема архива: глубина хранения и реальная емкость

Объем архива для сервера для видеонаблюдения (VMS) считается прямолинейно: средний битрейт x время записи x число камер. Главное - держать единицы измерения в порядке, иначе легко промахнуться на несколько терабайт.

Базовая логика такая: Мбит/с переводим в МБ/с (делим на 8), затем умножаем на секунды. Для прикидки удобно помнить: 1 Мбит/с - это примерно 10,8 ГБ в сутки.

Пример без сложных формул: 20 камер по 4 Мбит/с, запись 24/7, хранение 30 дней.

• Одна камера: 4 x 10,8 = 43,2 ГБ/сутки.
• За 30 дней: 43,2 x 30 = 1296 ГБ, то есть примерно 1,3 ТБ на камеру.
• На 20 камер: около 25,9 ТБ.

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

• накладные расходы файловой системы и служебные данные VMS (часто 5-15%);
• резерв под пики битрейта (ночь, снег, дождь, шум);
• запас на рост (новые камеры, выше FPS, выше разрешение).

Если запись по движению, не умножайте «как для 24/7». Задайте процент активности. Например, 25% активности означает, что камера в среднем пишет около 6 часов из 24. Лучше брать не оптимистичную оценку, а цифру, подтвержденную тестом или пилотом.

Практичный минимум по запасу емкости - плюс 20-30% к расчету. Это спасает, когда через полгода добавляют несколько камер или меняют качество, и архив начинает «съедать» место быстрее плана.

Требования к дискам и RAID для стабильной записи

Для VMS важны не только терабайты, но и предсказуемая последовательная запись 24/7. Архив может «не влезать» не по объему, а по скорости: камер стало больше, диск не успевает принимать поток, появляются пропуски и «дыры» в архиве.

Обычно хранилище делают на HDD: они дешевле за 1 ТБ и хорошо подходят для длинной непрерывной записи. SSD чаще полезны рядом с архивом: под систему, базу VMS, индексы, кэш и временные файлы. Это ускоряет поиск и прокрутку таймлайна, но не отменяет правильного подбора HDD под постоянную запись.

Какой RAID чаще подходит под видеозапись

Выбор RAID - это баланс между емкостью, отказоустойчивостью и тем, как быстро массив восстановится после отказа диска.

• RAID 5 экономит емкость, но выдерживает отказ только одного диска. На больших HDD и при долгом rebuild риск выше.
• RAID 6 выдерживает отказ двух дисков. Часто это более спокойный выбор для архивов, особенно когда дисков много.
• RAID 10 дает высокую скорость и быстрое восстановление, но забирает половину емкости.

Для систем на 32-64 камеры с планом расширения RAID 6 или RAID 10 обычно дает меньше неприятных сюрпризов, чем RAID 5.

Rebuild: где скрыт главный риск

Проблема не только в том, что rebuild долгий. В этот период падает производительность, растет нагрузка на оставшиеся диски, и появляется реальное «окно уязвимости». Типичная ситуация: нагрузка уже близка к пределу, один диск вышел из строя, и пока массив восстанавливается, система начинает терять кадры именно в часы пик.

Что полезно продумать заранее: hot spare (чтобы восстановление стартовало сразу), SMART и уведомления, плановую замену дисков по наработке, а также разделение ролей (SSD под ОС и базу VMS, отдельный массив под архив).

Если вы собираете серверную платформу под архив, имеет смысл заранее предусмотреть число корзин, контроллер и запас по дискам. В стойковых платформах уровня GSE S200 это обычно решается на этапе конфигурации, чтобы расширение архива не превращалось в риск для записи.

Сеть для IP-камер: как оценить трафик и не упереться в 1G

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

Практичное правило: суммарный входящий поток = сумма битрейтов камер + 10-20% запаса. Пики появляются при сложной сцене (дождь, снег, толпа), при переключении день-ночь, а также когда VMS временно пишет «рывками» из-за буфера.

Порты 1G и 10G: когда что нужно

1G порт дает около 900-940 Мбит/с полезной скорости. Если у вас 80 камер по 8 Мбит/с, это 640 Мбит/с только на запись. Добавьте запас, служебный трафик, удаленные просмотры, и вы быстро окажетесь на грани.

Если расчет подходит к 70-80% от 1G, закладывайте 10G или разделение потоков по интерфейсам (например, один порт для камер, второй для пользователей и экспорта архива). Это обычно проще, чем потом «лечить» заикания видео.

VLAN и аплинки: где чаще всего теряют скорость

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

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

Пример: если охрана одновременно смотрит 16 камер по 4 Мбит/с, это еще +64 Мбит/с. Вроде немного, но при работе «впритык» к 1G такие добавки и дают рывки и потери кадров.

Нагрузка на сервер: CPU, RAM, GPU и роль функций VMS

Нагрузка в VMS обычно делится на две части: запись и просмотр. Запись чаще упирается в диски и сеть (сервер принимает поток и пишет его в архив). Просмотр, особенно с несколькими операторами, сильнее нагружает процессор и иногда видеокарту, потому что потоки нужно декодировать и выводить на экраны.

CPU нагружают не камеры сами по себе, а то, что VMS делает с видеопотоками. Если сервер просто принимает H.265 и пишет на диски, загрузка процессора может быть умеренной. Но стоит включить обработку, и картина меняется.

Что чаще всего «ест» CPU: массовое декодирование для живого просмотра и видеостен, транскодирование для удаленного доступа, аналитика на стороне сервера, шифрование и водяные знаки, обслуживание базы и индексов.

GPU нужен не всегда. Он помогает, когда много одновременных просмотров в высоком разрешении, когда активно используется H.265 (декодирование тяжелее), или когда аналитика умеет работать на GPU. Если сервер выполняет только запись и редкий просмотр 1-2 каналов, отдельная видеокарта часто будет лишней.

RAM и системный диск важны из-за «внутренней кухни» VMS. База, журналы, индексы, кэш кадров и сервисы лучше держать на SSD отдельно от архива. Если системный диск медленный или забит логами, VMS может тормозить даже при нормальных дисках архива.

Еще один частый недоучет - сколько клиентов будет подключаться одновременно. Например, 4 оператора по 16 камер на экране - это десятки декодируемых потоков. Субпотоки и ограничение FPS для операторов нередко дают больший эффект, чем попытка «добавить еще CPU».

Пошаговый расчет: от камер до конфигурации сервера

Чтобы подобрать сервер для видеонаблюдения (VMS) без сюрпризов, удобнее идти одним маршрутом: параметры камер -> диски и архив -> сеть -> вычисления. Так сразу видно, где нужен запас, а где будет переплата.

Рабочая последовательность:

1. Зафиксируйте параметры камер и режим записи: разрешение, FPS, кодек (H.264/H.265), VBR или CBR, запись 24/7 или по событию, аудио, второй поток для просмотра.

2. Посчитайте суммарный битрейт: сложите средний битрейт всех камер и добавьте 20-30% на пики (снег, дождь, толпа, ночной режим). Для VBR это особенно важно.

3. Переведите битрейт в архив: суммарный поток (Мбит/с) умножьте на время записи в сутки и на нужное число дней. Если часть камер пишет не круглосуточно, учитывайте режим отдельно.

4. Выберите RAID и посчитайте полезную емкость: не путайте «сырой» объем дисков с тем, что останется после RAID и резервов. Одновременно оцените, выдержит ли дисковая подсистема постоянную запись по скорости.

5. Проверьте сеть: хватит ли 1G по аплинкам, сколько портов нужно, где будут PoE-коммутаторы, и не появится ли узкое место между камерами, сервером и рабочими местами.

6. Оцените вычисления: просмотр, транскодирование, серверная детекция движения и аналитика нагружают CPU/GPU и RAM. Если планируются десятки одновременных просмотров или аналитика на потоке, нужен запас по процессору и памяти, а GPU имеет смысл рассматривать при тяжелой аналитике.

Мини-сценарий: 40 камер по 6 Мбит/с - это около 240 Мбит/с, с запасом примерно 300 Мбит/с. Здесь уже важно проверять аплинки и дисковую подсистему, а не только «объем в ТБ». Для таких задач обычно смотрят стойковые серверы, где можно поставить много дисков и обеспечить стабильную запись (например, класс S200).

Где чаще всего ошибаются при масштабировании камер

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

Типовые ошибки:

• Берут битрейт «из спецификации» и не проверяют ночной режим. Ночью появляется шум, включается усиление, растет движение (фары, насекомые), и H.264/H.265 дает заметно больше мегабит, чем днем.
• Считают емкость дисков «по наклейке». RAID забирает часть объема, файловая система тоже, плюс у VMS есть служебные данные.
• Планируют хранение впритык. Камеры добавляют постепенно, потом повышают FPS или разрешение. Запас по хранилищу и пропускной способности - нормальная практика.
• Забывают про удаленный просмотр и экспорт архива в рабочее время. Это добавляет чтения с дисков и трафик в сети, и запись проседает именно в часы пик.
• Переоценивают RAID 5 на больших дисках. Восстановление после отказа может идти долго, а в этот период падает скорость и растет риск второго сбоя.
• Пытаются держать запись и тяжелую аналитику на одном сервере без расчета. Ресурсы начинают конкурировать с записью, особенно при транскодировании и распознавании.

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

Пример расчета на сценарии без сложных формул

Представим школу или клинику: 48 IP-камер, часть в коридорах, часть на улице. Настройки: 1080p, 15 FPS, H.265, запись 24/7, архив 30 дней. Нужно понять требования к сети и дискам.

Для прикидки берем средний битрейт на камеру. Для 1080p/15 FPS/H.265 часто закладывают 2-4 Мбит/с. Возьмем 3 Мбит/с (на улице может быть выше из-за листвы, снега и фар).

Трафик: 48 x 3 = 144 Мбит/с. В мегабайтах это 144 / 8 = 18 МБ/с постоянной записи.

Архив: 18 МБ/с x 86 400 с = около 1,55 млн МБ в сутки, то есть примерно 1,5 ТБ/сутки. За 30 дней получится около 45 ТБ «сырого» объема. Если добавить 15-25% на служебные накладные расходы, колебания битрейта и «неидеальные» сцены, целиться стоит примерно в 55 ТБ полезной емкости.

Теперь RAID. Если собрать RAID 6, то из N дисков два уходят под защиту. Например, 10 дисков по 10 ТБ: 100 ТБ сыро, полезно около 80 ТБ (и чуть меньше после форматирования). Это дает хороший запас под 30 дней.

Что меняется при росте:

• Добавили 16 камер (стало 64): 64 x 3 = 192 Мбит/с (24 МБ/с), архив примерно 60 ТБ за 30 дней без запаса.
• Подняли FPS до 25: битрейт часто растет примерно в 1,5-1,8 раза. Если стало 5 Мбит/с на камеру, то 48 x 5 = 240 Мбит/с, и архив может уйти к 75 ТБ за 30 дней.

Перед финальным выбором полезно «дожать» вводные у охраны и ИТ: архив 30 дней нужен для всех камер или только части, запись строго 24/7 или по событию, будут ли аналитика и дополнительные потоки, сколько одновременных просмотров, как устроена сеть и аплинки (1G/10G).

Чеклист перед закупкой и следующие шаги

Перед покупкой железа полезно на 20 минут перепроверить вводные. Большинство проблем в VMS начинается не со «слабого сервера», а с неверных ожиданий по битрейту, архиву и пиковым нагрузкам.

Что проверить до расчета и коммерческого предложения:

• Снимите реальный битрейт с нескольких камер днем и ночью (лучше в движении). Ночной режим, дождь или снег часто поднимают поток в 1,5-3 раза.
• Пересчитайте глубину архива по полезной емкости. RAID, форматирование и резервы уменьшают доступный объем.
• Оцените запас по сети и по записи на диск в пике. Даже если средняя загрузка невысокая, одновременный рост битрейта по всем камерам может упереться в 1G.
• Продумайте обслуживание дисков: hot spare, мониторинг SMART, сценарий деградации массива, сроки и порядок замены.
• Зафиксируйте, какие функции VMS включены (аналитика, детекция на сервере, транскодирование на клиентов). Это напрямую влияет на CPU/GPU и RAM.

Хороший быстрый тест: взять худший сценарий (ночь + движение) и проверить, выдержит ли система запись и сеть, даже если «в среднем все нормально».

Дальше логика простая: сначала требования VMS и камер, затем сервер и диски, и только после этого финальная стоимость. Если вы планируете рост на 12-24 месяца, закладывайте запас сразу, чтобы добавление камер не превращалось в аварийный проект.

Если проект в Казахстане и важны поставка, внедрение и дальнейшая поддержка, имеет смысл рассмотреть не только железо, но и интеграцию. Например, GSE.kz (gse.kz) как производитель и системный интегратор может закрыть и стойковые серверы S200 для архива, и инфраструктурную часть, включая сервисное сопровождение 24/7 через сеть по стране.