Считаем нагрузку и цену для видеонаблюдения на 16 камер

MAATRIX

Заказчик просит «сервер под видеонаблюдение на 16 камер», а дальше — тишина: какое разрешение, какой кодек, сколько хранить архив, никто не уточняет. Дальше можно либо гадать и потом краснеть, когда диск на 4 ТБ забивается архивом за неделю вместо месяца, либо посчитать заранее по конкретным цифрам. Ниже — рабочая методика: как из параметров камеры получить суммарный поток, сколько это займёт сети и диска, и как не потерять архив при отказе одного накопителя.

Битрейт одной камеры: от чего он зависит

Битрейт видеопотока с камеры — это не константа из даташита, а результат нескольких факторов, которые складываются вместе:

• Разрешение — чем больше пикселей, тем больше данных на кадр.
• Кодек — H.265 (HEVC) при той же картинке даёт примерно вдвое меньший поток, чем H.264, за счёт более эффективного сжатия. Это ориентир, а не точная пропорция — на разных сценах разница может быть от 30% до 55%.
• Частота кадров (fps) — 25-30 fps почти вдвое тяжелее, чем 12-15 fps при прочих равных. Для статичных сцен (склад, парковка ночью) многие ставят 10-12 fps без потери практической пользы записи.
• Сложность сцены — камера на пустом коридоре и камера на оживлённой кассе с одинаковым разрешением дадут разный реальный битрейт: кодек тратит больше бит на движение и детали. Даташит указывает *максимальный* или *средний* битрейт при типовой нагрузке — не факт, что ваша сцена в него впишется.
• Режим потока — CBR (постоянный битрейт) даёт предсказуемую нагрузку на сеть и диск, но переплачивает на простых сценах. VBR (переменный) экономит место в среднем, но пиковый битрейт может кратковременно превышать средний в 1,5-2 раза — это надо закладывать в запас по сети.

Ниже — ориентировочные диапазоны битрейта по разрешению и кодеку. Это оценка по типовым характеристикам IP-камер, а не измеренные вами цифры — реальный битрейт вашей модели и сцены может отличаться в любую сторону, проверяйте по факту через статистику NVR или счётчики трафика на порту после запуска.

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

Суммарный поток и требования к сети

Дальше — простое умножение, но с важными оговорками. Базовая формула:

Bitrate_total = Bitrate_camera × N_cameras

Если у вас 16 одинаковых камер 4 Мп на H.265 со средним битрейтом 3 Мбит/с (берём из середины диапазона выше):

Bitrate_total = 3 Мбит/с × 16 = 48 Мбит/с

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

1. Запас на пики VBR. Если камеры работают в переменном битрейте, закладывайте множитель 1,3–1,5 к среднему значению — иначе в момент, когда несколько камер одновременно ловят активную сцену (открылась дверь, проехала группа машин), канал может подвиснуть или начнутся потери кадров при записи.
2. Удалённый просмотр. Если оператор смотрит живое видео через веб-интерфейс или мобильное приложение, это отдельный исходящий поток поверх записи — считайте его отдельно, особенно если просмотр идёт в оригинальном качестве.
3. Трафик на резервное копирование или экспорт, если архив синхронизируется куда-то ещё (см. ниже про непрерывную запись против записи по детекции движения).

С учётом множителя 1,4 на пики получаем практическую потребность в канале:

48 Мбит/с × 1,4 ≈ 67 Мбит/с

Для 16 камер такого класса штатного гигабитного порта (1 Гбит/с) хватает с большим запасом даже с учётом удалённого просмотра. Порог, когда стоит задуматься о более широком канале или агрегации портов, — это в первую очередь 4К-камеры в количестве больше 10-12 штук на один сервер, либо ситуация, когда к тому же серверу подключены дополнительные нагрузки (аналитика, транскодирование для мобильного клиента). Разницу между форматами канала подробно разбирали в статье про гигабитный канал против 10-гигабитного — если ваш расчёт суммарного потока уже подбирается к 300-500 Мбит/с, туда стоит заглянуть до заказа сервера.

Место на диске: формула расчёта архива

Это тот пункт, где чаще всего ошибаются — берут ёмкость диска «на глаз» вместо расчёта. Формула для объёма архива:

V (байт) = (Bitrate_total [бит/с] / 8) × 86400 × N_days

Здесь 86400 — количество секунд в сутках, деление на 8 переводит биты в байты (битрейт традиционно измеряется в битах, а объём диска — в байтах). Если у вас суммарный поток в мегабитах в секунду, удобнее считать так:

V (ГБ) = (Bitrate_total_Мбит/с × 10^6 / 8) × 86400 × N_days / 10^9

Пример для наших 48 Мбит/с суммарного потока (без запаса на пики — это расчёт именно объёма записи, пики VBR тут сглаживаются средним за сутки) и глубины архива 30 дней:

48 × 10^6 / 8 = 6 000 000 байт/с (6 МБ/с)
6 000 000 × 86400 = 518 400 000 000 байт/сутки (≈ 518 ГБ/сутки)
518 ГБ × 30 дней ≈ 15 550 ГБ ≈ 15,5 ТБ

То есть непрерывная запись 16 камер этого класса на 30 дней требует порядка 15,5 ТБ полезного места — и это без RAID-избыточности и без запаса. К полученному числу дальше нужно добавить:

• 10-15% инженерного запаса — файловая система, метаданные NVR, индексы, служебные логи никогда не дают использовать 100% номинальной ёмкости диска.
• Избыточность RAID — RAID 5/6 «съедают» ёмкость под контрольные суммы, RAID 10 — ровно половину сырой ёмкости. Это отдельный множитель поверх V, разбираем в разделе про RAID ниже.
• Буфер сверх номинального срока хранения — многие NVR не удаляют самые старые записи ровно по истечении N дней, а держат небольшой буфер (например, ещё 1-3 дня), чтобы не потерять данные, если администратор не успел вовремя отреагировать на переполнение.

Сколько закладывать места с запасом при планировании — тема отдельного разбора, если нужен общий подход к резервам под диск на сервере, а не только под видеоархив.

Постоянная запись или запись по детекции движения

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

Непрерывная запись всего потока. Пишется всё, что видит камера, 24/7. Плюс — гарантированно есть запись любого момента, включая события без движения в кадре (человек стоит неподвижно, предмет просто лежит в кадре, статичная сцена, которую детектор движения не считает «событием»). Минус — это тот самый полный объём V из формулы выше, без экономии.

Запись по детекции движения. Пишется только тогда, когда детектор (встроенный в камеру или в NVR) фиксирует движение в кадре или в заданной зоне. Экономия объёма может быть очень значительной, но конкретная цифра сильно зависит от сцены и чувствительности детектора — по разным реальным инсталляциям встречаются оценки от 30% до 80% экономии по сравнению с непрерывной записью. Это именно ориентир для планирования, а не гарантированный процент — на охраняемой стоянке с постоянным трафиком экономия будет куда скромнее, чем на складе, где движение бывает раз в час.

Риск записи по детекции — вы физически не можете восстановить то, чего не было записано. Конкретные сценарии, где это стреляет:

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

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

RAID для архива видеонаблюдения: как выбрать уровень

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

Коротко по уровням применительно именно к видеоархиву (постоянная последовательная запись 16 потоков, большие ёмкости, редкие, но объёмные операции чтения при экспорте инцидента):

Ключевой нюанс для архивов на крупных дисках (8-16-20 ТБ, типичных сейчас для NVR-хранилищ): при отказе одного диска в RAID 5 массив входит в ребилд, который на дисках такой ёмкости может растягиваться на много часов или сутки. Всё это время массив работает без избыточности — если во время ребилда всплывёт нечитаемый сектор (URE) на любом из оставшихся дисков, массив может не восстановиться, и вы потеряете весь архив целиком, а не только данные за период отказа. Это ровно та причина, по которой практика сместилась в сторону RAID 6 — он переживает отказ второго диска именно в период ребилда первого. Логика восстановления и риски подробно разобраны в статье о том, как RAID себя ведёт при отказе диска.

Если критична не только надёжность, но и скорость записи (все 16 потоков пишутся одновременно на один массив без буферизации), сравните RAID 6 с RAID 10 предметно — у них разная логика распределения нагрузки на запись и разная цена ёмкости. Разбор RAID 10 против RAID 6 и более широкий обзор как вообще выбирать уровень RAID помогут сориентироваться, если сервер несёт и другую нагрузку.

Дополнительно для архива видеонаблюдения: выносите систему на отдельный от архива диск (ОС и NVR-софт — на небольшой SSD или зеркало, архив — на отдельный массив из ёмких HDD, так отказ архивного диска не роняет саму систему записи); держите горячий резерв (hot spare), если бюджет позволяет — это сокращает время до старта ребилда с часов до минут; мониторьте здоровье дисков по SMART-атрибутам до того, как они откажут полностью, а не постфактум.

Пример расчёта конфигурации сервера на 16 камер

Собираем всё вместе на конкретном примере: 16 камер, 4 Мп, H.265, средний битрейт 3 Мбит/с, требование — 30 дней архива, критичные 4 камеры (входные группы) пишутся непрерывно, остальные 12 — по детекции движения.

Сеть:

Суммарный поток: 16 × 3 Мбит/с = 48 Мбит/с
С запасом на пики VBR (×1,4): ≈ 67 Мбит/с
Вывод: 1 Гбит/с порта достаточно с большим запасом

Диск, непрерывные камеры (4 шт., 30 дней):

4 × 3 Мбит/с = 12 Мбит/с → 1,5 МБ/с
1,5 МБ/с × 86400 × 30 ≈ 3 888 000 МБ ≈ 3,9 ТБ

Диск, камеры по детекции движения (12 шт., 30 дней, оценка экономии 50% — берём консервативно середину диапазона 30-80%):

12 × 3 Мбит/с = 36 Мбит/с → 4,5 МБ/с (при непрерывной записи)
Полный объём при непрерывной записи: 4,5 × 86400 × 30 ≈ 11 664 000 МБ ≈ 11,7 ТБ
С экономией 50% от детекции движения: ≈ 5,8 ТБ

Итоговая потребность в полезном месте:

3,9 ТБ + 5,8 ТБ ≈ 9,7 ТБ
Плюс инженерный запас 15%: ≈ 11,2 ТБ полезной ёмкости

Вариант диска под RAID 6: 6 дисков по 4 ТБ (сырая ёмкость 24 ТБ), полезная ёмкость (N-2)/N × 24 ТБ = 4/6 × 24 ≈ 16 ТБ — с запасом на будущий рост архива или добавление камер. Если бюджет диска жёстче, можно взять 5 дисков по 4 ТБ (полезно ≈ 12 ТБ) — впритык к расчёту без пространства на рост, что для системы безопасности рискованно с самого начала эксплуатации.

Для CPU и RAM: запись 16 потоков без встроенной видеоаналитики (детекцию движения обычно делает сама камера или лёгкий модуль NVR) — нагрузка умеренная, сервер уровня младшего-среднего Xeon/EPYC с 16-32 ГБ RAM берёт такую задачу без напряжения. Серверная видеоаналитика (распознавание лиц, номеров, подсчёт объектов) поверх записи — отдельная и куда более прожорливая по CPU/GPU нагрузка, которую в этот расчёт мы не закладывали, и планировать её нужно отдельно под конкретный софт.

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

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