Как рассчитать сервер для видеонаблюдения: камеры, видеоархив, CPU и сеть

Сервер для видеонаблюдения рассчитывают по трём составляющим нагрузки: приём и запись потоков, хранение и чтение архива, декодирование и видеоаналитика. Число камер связывает эти задачи, но не описывает их полностью. Для 64 камер без перекодирования может быть важнее дисковая подсистема, чем максимальное число ядер. Для 16 камер с распознаванием объектов ограничителем уже могут стать декодер, ускоритель и обработка кадров.

Какие данные собрать до выбора видеосервера?

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

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

Запись, декодирование и распознавание: в чём разница?

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

Декодирование превращает H.264/H.265 в кадры. Детекция движения обрабатывает кадры и выделяет изменения. Нейросетевой детектор выполняет инференс на подготовленных фрагментах. Дополнительные функции могут использовать другие модели. Ускоритель инференса не обязательно умеет декодировать видео, а встроенный VGA-контроллер BMC не заменяет GPU с видеодекодером.

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

Как рассчитать объём видеоархива на 7, 14 и 30 суток?

Для непрерывной записи в десятичных единицах: V, ТБ = N × B × 0,0108 × D, где N — число камер, B — средний битрейт одной камеры в Мбит/с, D — число суток. Коэффициент получается из 86 400 секунд в сутках и перевода битов в байты. Один постоянный поток 1 Мбит/с создаёт 10,8 ГБ за сутки.

Здесь 1 ТБ равен 1000 ГБ, как в маркировке накопителей. В двоичных единицах ОС число будет другим: 1 ТБ примерно равен 0,91 ТиБ. Это разница единиц, а не потеря дисковой ёмкости. Служебные структуры, звук и база событий учитываются отдельно.

Таблица не включает запас свободного места и потери ёмкости на отказоустойчивость. Если видеоархив 64 камер должен занимать не более 80% полезного пространства, потребуется минимум 82,944 ÷ 0,8 = 103,68 ТБ полезной ёмкости до остальных данных. Добавить 20% к объёму — не то же самое: 82,944 × 1,2 = 99,53 ТБ оставляет лишь 16,7% пространства свободным.

Как считать камеры с разными битрейтами и режимами записи?

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

Пример: 24 камеры по 4 Mbps и 8 камер по 8 Mbps дают 24 × 4 + 8 × 8 = 160 Mbps. Непрерывная запись за 30 суток требует 160 × 10,8 × 30 = 51 840 GB, или 51,84 TB. При проектном заполнении полезного пространства не выше 80% требуется не меньше 64,8 TB до служебных расходов VMS. Ёмкость массивов до вычета паритета с этим числом сравнивать нельзя.

Если восемь камер из второй группы пишут лишь половину времени, расчётный средний поток архива уменьшается на 32 Mbps. Но сетевой вход при одновременной активности всех камер остаётся 160 Mbps. Коэффициент событийной записи уменьшает оценку удерживаемого архива, а не автоматически пиковую пропускную способность и потребность аналитики.

Как учесть переменный битрейт и запись по движению?

При событийной записи вводят долю времени сохранения k: V = N × B × 0,0108 × D × k. Если 32 камеры по 4 Мбит/с действительно сохраняют 35% времени, за 30 суток получится 41,472 × 0,35 = 14,5152 ТБ. Однако k — результат наблюдения и правил записи, а не постоянное свойство камеры. Движение снега, тени и события на нескольких зонах могут приблизить его к единице.

Предзапись и постзапись увеличивают время сохраняемого материала. При частых событиях интервалы сливаются. Нельзя обещать экономию 70% только потому, что включена запись по движению. Для ответственного объекта сначала проверяют, допустимы ли пробелы в архиве, затем выбирают политику хранения.

CBR, VBR, ночь и дождь: почему средний битрейт недостаточен?

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

Снимайте временные ряды нескольких типичных суток, включая тяжёлые условия. Для ёмкости нужен интегральный объём, для сети и записи — пики с понятным интервалом усреднения. «Максимум за секунду», «95-й процентиль за минуту» и среднее за сутки — разные числа. Единичный короткий всплеск и часовая перегрузка требуют разных решений.

Допустим, 64 камеры обычно дают по 4 Mbps, но в тяжёлом режиме устойчиво достигают 7 Mbps. Вход меняется с 256 до 448 Mbps. Добавив в качестве проектного условия 25% резерва на служебный трафик и расширение, получаем 560 Mbps. Такой запас не доказывает достаточность любого гигабитного тракта: дополнительно учитывают сетевую топологию, другие потребители и выходящие потоки.

Сколько дисков нужно и какой RAID использовать?

Сначала рассчитывают полезную ёмкость, затем определяют число дисков. Условный массив из 10 дисков по 18 ТБ с двумя дисками эквивалентной ёмкости под двойную чётность даёт около 144 ТБ до файловой системы и служебных резервов. При принятом лимите заполнения 80% на видео остаётся около 115,2 ТБ. Для рассмотренных 64 камер на 30 суток это достаточный бюджет по объёму, но производительность и совместимость ещё требуется проверить.

В эту десятку не включён отдельный hot spare. Если он нужен, добавляют физический диск и отсек, а его ёмкость не считают в рабочий архив. Также учитывают будущий рост: четыре свободных отсека полезны только тогда, когда контроллер, backplane, лицензия VMS и процедура расширения позволяют их использовать.

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

Почему одной проверки скорости последовательной записи недостаточно?

Входящий поток 64 камер по 4 Мбит/с составляет всего 32 МБ/с сжатого видео. На первый взгляд это мало для современного массива. Но сервер одновременно записывает множество файлов, обновляет индексы, обслуживает просмотр разных временных интервалов, удаляет старые сегменты и может восстанавливать отказавший диск. Характер доступа становится сложнее одной непрерывной записи в пустой файл.

При выборе HDD проверьте тип записи, рабочую нагрузку, тайм-ауты и совместимость с контроллером. На потребительских SMR возможны длительные провалы при перезаписи и rebuild, поэтому цену за терабайт сопоставляют с поведением рабочего массива.

Систему и базу событий нередко выносят на отдельные SSD, а большой видеоархив размещают на HDD. Это уменьшает конкуренцию мелких операций и видеопотоков. Но итоговая схема зависит от VMS: некоторым продуктам нужны определённые файловые системы, тома или собственный формат хранения. Общий выбор архитектуры вынесен в материал NAS или сервер хранения.

Как рассчитать сеть для камер, операторов и экспорта?

Сетевой бюджет складывают по направлениям и участкам, а не просто суммируют все числа в одну цифру. У 64 камер основной поток 4 Мбит/с и дополнительный 0,5 Мбит/с дают входящий трафик 288 Мбит/с. При проектном запасе 25% бюджет входа составит 360 Мбит/с. Этот запас — выбранное условие примера; нужный размер определяют по пикам и политике эксплуатации.

Если четыре оператора смотрят по 16 основных потоков через сервер, исходящая видеонагрузка может достигать ещё 256 Мбит/с до протокольных расходов. Экспорт со скоростью 100 МБ/с добавляет 800 Мбит/с. На одном гигабитном исходящем соединении одновременные просмотр и такой экспорт уже не помещаются. Полный дуплекс позволяет одновременно передавать и принимать, но не увеличивает пропускную способность одного направления сверх скорости порта.

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

Почему Wi-Fi может мешать даже при небольшом битрейте?

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

NetworkChuck столкнулся с этим после расширения домашней установки до десяти камер. В разборе отдельно показаны основной поток записи, дополнительный поток детекции и проблема нескольких подключений. Для уменьшения повторных соединений использовалась ретрансляция go2rtc; также менялись настройки сети. Этот опыт полезен как предупреждение: проблема изображения может находиться между камерой и сервером, а замена CPU её не решит.

«Я установил столько камер, что это разрушило мою беспроводную сеть».

NetworkChuck, перевод фрагмента об увеличении числа Wi-Fi-камер.

Для постоянной объектовой системы обычно удобнее проводные камеры и заранее рассчитанный PoE-бюджет. Если Wi-Fi необходим, проводят отдельное обследование эфира и длительный тест. Регулярный перезапуск камеры, помогавший в конкретном домашнем опыте, не заменяет устранение причины потери записи в рабочем проекте.

Как подобрать CPU и RAM для 16–128 камер?

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

Оценка обработки кадров: 64 потока 1920×1080 при 25 FPS дают около 3,32 миллиарда пикселей в секунду. Дополнительные потоки 640×360 при 5 FPS — около 73,73 миллиона, то есть примерно в 45 раз меньше по числу пикселей. Это не обещание 45-кратного ускорения CPU: алгоритмы, декодеры и число объектов работают сложнее. Но расчёт показывает масштаб различий между двумя режимами.

После декодирования размер буфера задаётся форматом кадра. Для 1920×1080 в YUV 4:2:0 один кадр занимает примерно 3,11 МБ без дополнительных структур. RAM рассчитывают по числу таких буферов и потоков, а затем добавляют процессы, кэш и базу событий VMS.

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

Когда нужны GPU, Quick Sync, Coral или другой ускоритель?

Сначала выбирают VMS/NVR и поддерживаемый программный путь. Для декодирования проверяют конкретный GPU, профиль кодека, глубину цвета, разрешение, драйвер и доступ устройства из контейнера или ВМ. Общее название NVIDIA, Intel или AMD не подтверждает поддержку любого видеопотока. Quick Sync требует подходящей графической подсистемы; наличие процессора Intel само по себе её не гарантирует.

Для инференса проверяют поддерживаемый backend, формат и размер модели, точность, память и скорость на выбранном разрешении. Конфигурации с Coral, Hailo, OpenVINO и TensorRT имеют разные аппаратные и программные требования. Отдельно подтверждают обработку дополнительных функций, например семантического поиска или распознавания лиц.

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

Как согласовать точность детекции и ресурсы сервера?

В разборе Home Automation Guy главный поток сохраняет детали архива, а отдельный менее тяжёлый поток используется для наблюдения и распознавания. Практический вопрос состоит в том, остаётся ли нужный объект различимым на выбранном расстоянии. Снижение разрешения и fps полезно только пока выполняются требования к обнаружению, а не ради минимального процента CPU.

Проверяйте маленький объект вдали, быстрое пересечение кадра, контровой свет, ночь и перекрытие объекта. Маска движения, зона интереса и фильтр объекта решают разные задачи. Ошибка настройки способна скрыть нужное событие даже при большом запасе GPU. Набор классов и поведение детектора зависят от модели и версии ПО; увеличение числа отмеченных классов не обязано линейно увеличивать вычисления.

Для приёмки заведите тестовый набор событий. Например, 40 проходов человека в заданной зоне, 20 проездов автомобиля и отдельный набор сцен без целевых объектов. Считайте пропуски и ложные события, сохраняйте условия. Это проектная методика проверки, а не обещание конкретной точности Frigate или другого продукта. Параметры инференса выбирают по этому результату вместе с задержкой обработки.

Что показывает опыт Frigate с 50 и 100 имитируемыми камерами?

В эксперименте 45HomeLab источником служил отдельный генератор RTSP из зацикленных коротких записей. Для каждой условной камеры создавались основной и дополнительный потоки. Приём выполнялся на HL15 2.0 с EPYC 7452 и RTX 4060, между системами использовали 10GbE. Автор показал рабочую конфигурацию примерно на 50 камерах и назвал её удобной точкой для своего теста.

В зацикленных сценах 45HomeLab возникало необычно много событий. Автор оценивал возможность 75–100 камер, но показанный результат относился примерно к 50 симулированным камерам. Для своего объекта отдельно проверяют генератор, детектор и архив, затем повторяют прогон с реальными устройствами. Основной и дополнительный потоки относятся к одной камере и отдельно в число камер не складываются.

Как сделать нагрузочный стенд, если камеры ещё не куплены?

В подготовительном разборе 45HomeLab сцены с движением и сложной погодой приведены к 1080p/30 fps. Файлы отдаёт отдельная машина, поэтому эта работа не занимает ресурсы исследуемого NVR.

Генератор сам способен стать ограничением. Запишите его CPU, сеть, фактическое число потоков и отсутствие пропусков ещё до входа в VMS. Один файл, многократно передаваемый одинаково, не воспроизводит независимые изменения сцен и обрывы реальных камер. Сначала удобно проверить ёмкость тракта в контролируемых условиях, затем обязательны реальные устройства, PoE-коммутатор и рабочие настройки.

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

Матрица конфигураций: что меняется с ростом задачи?

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

Совместимость камер, ПО и серверной платформы

Совместимость проверяют по функциям: поток RTSP, PTZ, двустороннее аудио, события, поиск архива и управление настройками. Для ONVIF сверяют поддерживаемые профили. До массовой закупки подключают образец каждой серии с нужной прошивкой.

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

Доступ к камерам и администрированию отделяют от обычной пользовательской сети. BMC размещают в защищённом сегменте. Пароли не включают в публичные примеры RTSP-адресов и журналы, а удалённый доступ организуют через управляемый защищённый канал. Локальное хранение само по себе не делает систему неуязвимой.

Продукция Supermicro подбирается по готовой ведомости камер. Битрейт, срок хранения, аналитика и число операторов определяют шасси, диски и ускорители.

Что проверить в камерах, VMS и операторском рабочем месте?

В учебном примере примем 32 камеры по 9 W: на выходах PoE требуется 288 W. Потребление от розетки будет включать также коммутатор и потери. Кроме общего бюджета, например 370 W, проверяют предел каждого порта и требования подключаемой камеры.

Как учитывать отказ диска, экспорт и восстановление архива одновременно?

Пример требования: все 64 камеры продолжают запись с заданными параметрами, четыре оператора просматривают архив, параллельно выгружается согласованный объём, а массив восстанавливает отказавший накопитель. Задайте допустимые сроки экспорта и восстановления, количество пропущенных кадров и задержку открытия архива. Без этих условий выражение «поддерживает 64 камеры» не описывает тяжёлый рабочий режим.

Размер экспортируемых данных также считается по битрейту. Фрагмент 30 минут одной камеры при 4 Mbps занимает около 900 MB без дополнительной упаковки. Для 16 камер тот же интервал — примерно 14,4 GB. Срок передачи зависит от фактической скорости чтения архива, обработки VMS и сети получателя; максимальная линейная скорость NIC является только верхним пределом.

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

Что произойдёт с архивом при разрыве связи с камерами?

Для переживания обрыва линии нужна запись на камере или промежуточном регистраторе. Автоматическое заполнение пропуска после возврата связи испытывают на конкретной паре камеры и VMS: поддержка microSD и backfill проверяются раздельно.

Условный филиал имеет 16 камер по 4 Mbit/s. Общий поток составляет 64 Mbit/s, или 8 MB/s в десятичном расчёте. Час записи — 28,8 GB. Если после восстановления связи этот час нужно догрузить ещё за час, добавится в среднем 8 MB/s архивной передачи поверх 8 MB/s текущего потока: всего 16 MB/s, или 128 Mbit/s до сетевых накладных расходов. Канал, рассчитанный только на 64 Mbit/s, такой срок догрузки не обеспечит.

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

Как сделать архив пригодным для поиска и выгрузки событий?

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

Структура видеопотока тоже влияет на работу клиента. Например, GOP из 50 кадров при 25 кадрах/с охватывает 2 секунды. Это не обещание ровно двухсекундной задержки поиска: значение зависит от размещения ключевых кадров, формата, декодера и VMS. Настройки камеры меняют в пилоте вместе с оценкой качества, объёма и удобства просмотра.

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

Программа проверки видеосервера перед сдачей

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

Частые вопросы о расчёте сервера видеонаблюдения

RAID заменяет резервную копию нужного фрагмента?

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

H.265 всегда экономит ровно половину места?

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