Предел числа камер на одном сервере видеонаблюдения: где именно ломается запись

MAATRIX

Проект на 32 камеры работал нормально, добавили ещё 16 — и запись начала рассыпаться: в архиве появляются провалы, живой просмотр подвисает, а на графиках сервера вроде бы всё в порядке. Вопрос «сколько камер потянет этот сервер» звучит как арифметика, но за ним стоят три разных предела — сетевой, дисковый и процессорный — и обычно ломается тот, который вообще не считали. Разберём, как посчитать нагрузку заранее и найти, во что упирается запись, когда она уже начала сыпаться.

Три предела, а не один

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

• Сеть. Если камеры IP и пишут поток на сервер по сети (а не локально через аналоговый видеорегистратор), совокупный трафик всех потоков должен физически пройти через сетевую карту и коммутатор. Это отдельная полоса пропускания, которая считается независимо от диска.
• Дисковый ввод-вывод. Каждая камера — это отдельный поток записи, который ложится на диск своим файлом или сегментом. Много параллельных потоков записи — это не последовательная запись одного файла, а фактически смесь потоков, которая по поведению диска ближе к случайной нагрузке, чем кажется на первый взгляд.
• CPU. Транскодирование потоков (запись в другом разрешении, чем снимает камера), детекция движения и аналитика на стороне сервера, работа веб-интерфейса с live-просмотром — всё это процессорное время, которое растёт с числом камер нелинейно, если включена аналитика.

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

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

Как посчитать нагрузку по битрейту: базовая формула

Отправная точка любого расчёта — не число камер, а суммарный битрейт, который они создают. Формула на бумаге простая:

Суммарный битрейт = Σ (битрейт_камеры_i) × коэффициент_пиковой_нагрузки

Проблема не в формуле, а в том, что подставляют в неё средний битрейт из даташита камеры, хотя современные IP-камеры почти всегда пишут не в постоянном битрейте (CBR), а в переменном (VBR) с ограничением сверху. При статичной картине (пустой коридор, парковка ночью) поток сжимается сильно и битрейт падает в разы относительно заявленного максимума. При движении в кадре, шуме матрицы в темноте или включении ИК-подсветки битрейт резко растёт — и именно в этот момент, когда на записи действительно что-то происходит, сеть и диск получают максимальную нагрузку.

Отсюда практический вывод: считать нужно не по среднему, а по максимальному битрейту, который камера способна выдать в профиле записи (это значение либо задаётся явно лимитом в настройках камеры, либо указано в спецификации как «peak bitrate» / «max bitrate»). Если камера настроена без верхнего лимита битрейта — это первое, что стоит исправить перед расчётом, иначе цифра из даташита ничего не гарантирует.

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

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

Сеть: полоса, коммутаторы и PoE-бюджет

Если камеры подключены по IP и пишут напрямую на сервер (а не через промежуточный локальный NVR, агрегирующий поток), сетевая часть считается отдельно от всего остального.

Практический расчёт: берёте суммарный пиковый битрейт из предыдущего раздела в мегабитах в секунду и сравниваете с реальной пропускной способностью канала между камерами и сервером — не с номинальной скоростью порта, а с фактической, которую канал способен держать под нагрузкой (коммутатор, аплинк, при необходимости — маршрутизация между сегментами). 1 Гбит/с канал в теории даёт около 1000 Мбит/с, но с учётом накладных расходов, других сервисов на том же канале и запаса для скачков трафика лучше не планировать загрузку канала под запись выше 60–70% от номинала.

Отдельная и часто упускаемая деталь — бюджет PoE-коммутатора. Он ограничивает не пропускную способность сети, а суммарную электрическую мощность, которую коммутатор может раздать на все камеры (особенно с ИК-подсветкой и подогревом корпуса зимой). Если бюджета не хватает, коммутатор не поднимает часть портов или снижает питание — сеть в порядке, а часть камер просто нестабильна. Это не проблема сервера, но её легко спутать с сетевым пределом самого NVR.

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

Диск: IOPS, RAID и разница между записью и просмотром архива

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

Каждая камера пишет свой поток отдельным файлом или циклическим сегментом. Когда таких потоков одновременно 20, 40, 80 — диск физически переключается между записью в разные места, даже если каждый отдельный поток пишется последовательно внутри своего файла. Для HDD это постоянные перемещения головки и резкое падение эффективной скорости против паспортной последовательной записи. Для SSD ситуация мягче, но тоже не бесплатна: множество параллельных потоков — уже не идеальный последовательный паттерн, а смесь, которая ближе к случайной записи, а у неё предел — IOPS, а не мегабайты в секунду. Как отличить, что диск упёрся именно в IOPS, разобрано в статье про предел IOPS.

Практические выводы для планирования:

• Для систем с большим числом камер (условно от нескольких десятков) RAID-массив на SSD/NVMe с быстрой случайной записью почти всегда выигрывает у HDD того же объёма — не по цене за терабайт, а по способности держать много параллельных потоков без деградации.
• Если бюджет позволяет только HDD, стоит закладывать заметный запас по числу дисков в массиве и полосе контроллера, а не считать по паспортной последовательной скорости одного диска — реальная нагрузка от десятков параллельных потоков ведёт себя иначе.
• RAID-уровень имеет значение: массивы с вычислением чётности (RAID 5/6) отдают запись медленнее, чем зеркалирование или страйп, из-за накладных расходов на пересчёт при каждой операции записи — это стоит учитывать отдельно при выборе конфигурации под видеопоток.
• Просмотр архива поверх непрерывной записи — это дополнительное чтение, которое конкурирует с записью за те же диски. На системах, где архив смотрят часто и несколько человек одновременно, стоит закладывать запас именно под это, а не только под сами потоки записи.

Отдельно стоит учитывать частоту записи на диск, которую задаёт VMS-софт: одни системы пишут крупными последовательными блоками раз в несколько секунд, другие — почти постоянным потоком. Первый вариант заметно бережнее к диску при том же суммарном битрейте.

CPU: транскодирование, детекция движения и live-просмотр

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

• Транскодирование. Запись основного потока в высоком разрешении и одновременная генерация суб-потока для live-просмотра в более низком качестве (чтобы не гонять полный поток в браузер оператора) — это перекодирование в реальном времени, и оно заметно тяжелее, чем просто приём и запись готового потока.
• Детекция движения и аналитика на сервере. Если камеры сами не умеют определять движение или лица (edge-детекция на стороне камеры сейчас распространена, но не универсальна), эту работу берёт на себя сервер — постоянный анализ кадров по каждому потоку, который нагружает CPU пропорционально не только числу камер, но и сложности алгоритма.
• Многопользовательский live-просмотр. Каждый одновременно открытый в браузере или клиенте живой поток может требовать отдельного транскодирования под конкретное устройство — это тоже CPU, причём в моменты, которые не совпадают с обычной нагрузкой записи.

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

Типичные ошибки планирования

Большинство инцидентов «сервер не тянет камеры» сводится к нескольким повторяющимся ошибкам, а не к нехватке железа как таковой.

• Расчёт по среднему битрейту вместо пикового. Даташит камеры или её текущее потребление в спокойной сцене ничего не говорит о том, что будет при движении в кадре, включении ИК-подсветки ночью или шуме матрицы в темноте — именно в эти моменты битрейт растёт кратно, и именно тогда сеть и диск получают реальный пик, а не расчётный.
• Игнорирование одновременного чтения архива. Расчёт сделан только под запись, а на практике оператор или несколько клиентов постоянно смотрят прошлые записи — это дополнительная нагрузка на диск и сеть поверх непрерывной записи, которую забыли учесть.
• Смешение сетевых сегментов. Камеры, запись и обычный офисный или интернет-трафик идут через один и тот же канал без разделения на VLAN или без отдельного аплинка — в момент пиковой нагрузки они конкурируют за одну и ту же полосу.
• Расчёт диска по объёму архива, а не по нагрузке записи. Считают, сколько терабайт нужно на месяц хранения, и на этом успокаиваются — а вопрос, выдержит ли этот массив параллельную запись от всех камер одновременно, остаётся без ответа до первого инцидента.
• Добавление камер без пересчёта. Систему спланировали под 20 камер, потом добавили 10, потом ещё 10 — и каждый раз казалось, что «ещё пара камер погоды не сделает». По отдельности — да, кумулятивно — предел был пройден задолго до последнего добавления, просто деградация была постепенной и её списывали на что-то другое.
• Единый профиль записи для всех камер. Камере на входе в помещение с постоянным движением людей и камере, направленной на пустую стену склада, задают одинаковый битрейт и профиль — вместо того чтобы дифференцировать настройки по реальной значимости и активности сцены каждой камеры.

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

Частые вопросы