Сервер видеонаблюдения без сюрпризов: как посчитать камеры, диски и реальный срок архива

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

Кейс из практики: почему 16 камер могут съесть больше дисков, чем ожидали

Типовая ситуация: офис, склад или небольшое производство. Ставят 16–24 IP-камеры, часть на входах, часть в проходах, часть на улице. В проекте пишут: 4 Мп, H.265, 25 кадров/с, архив 30 дней. Под это берут сервер или регистратор с несколькими дисками, часто считая по усреднённому битрейту из калькулятора.

Первые недели всё выглядит нормально. Потом появляются вопросы:

• архив хранится меньше заявленного срока;
• при одновременном просмотре нескольких камер интерфейс начинает тормозить;
• при выгрузке фрагмента за нужный день нагрузка на диски резко растёт;
• после добавления ещё 4 камер свободное место заканчивается быстрее, чем ожидали;
• при отказе диска восстановление RAID идёт долго, а запись всё это время остаётся под нагрузкой.

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

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

Четыре параметра, с которых начинается расчёт

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

1. Количество камер и режим записи

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

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

2. Разрешение, FPS, кодек и битрейт

Разрешение само по себе мало что говорит. Две камеры 4 Мп могут давать разный поток из-за настроек кодека, сложности сцены и частоты кадров. Практически важен битрейт: например, 2, 4, 6 или 8 Мбит/с на камеру.

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

3. Срок хранения архива

7, 14, 30, 60 и 90 дней — это принципиально разные проекты. Увеличение архива с 30 до 60 дней почти линейно увеличивает требования к полезному объёму дисков. Компрессия не спасает, если поток уже задан.

4. Схема отказоустойчивости и запас

Полезный объём дисков не равен сумме наклеек на HDD. RAID 1, RAID 5, RAID 6, RAID 10 дают разную ёмкость и разную устойчивость к отказам. Плюс часть пространства уйдёт на файловую систему, метаданные, базу VMS, индексы, журналирование и резерв под нормальную работу.

Для видеонаблюдения разумно закладывать запас хотя бы порядка 20–30% к расчётному объёму архива. Если объект будет расти, лучше считать с запасом по корзине и портам, а не только по сегодняшнему числу камер.

Пример расчёта: 24 камеры, архив 30 дней, без магии в таблицах

Возьмём рабочий сценарий: 24 IP-камеры по 4 Мп, запись постоянно, кодек H.265, средний рабочий битрейт 4 Мбит/с на камеру. Нужен архив 30 дней.

Формула для грубой оценки:

Общий поток = число камер × битрейт одной камеры
Объём в сутки = общий поток / 8 × 86400 секунд
Объём архива = объём в сутки × число дней

Считаем:

24 камеры × 4 Мбит/с = 96 Мбит/с
96 / 8 = 12 МБ/с
12 МБ/с × 86400 ≈ 1 036 800 МБ в сутки
Это примерно 1,04 ТБ в сутки в десятичном исчислении
За 30 дней: около 31 ТБ полезного архива

Теперь важная часть: 31 ТБ — это не ответ, а только нижняя граница. К ней нужно добавить запас на колебания битрейта, индексы, служебные данные и нормальную работу массива. Если заложить 25%, получим примерно 39 ТБ полезного пространства.

Что это значит по дискам? Один из возможных вариантов — 8 дисков по 8 ТБ в RAID 6. Номинально это 64 ТБ сырых дисков, полезно после RAID 6 останется около 48 ТБ до учёта особенностей файловой системы и пересчёта TB/TiB. Для указанного сценария это уже похоже на рабочую конфигурацию с запасом.

Но это не универсальный рецепт. Если камеры будут писать по 6–8 Мбит/с, если нужен архив 60 дней или если добавятся дополнительные потоки для аналитики, расчёт меняется. Например, при 6 Мбит/с на камеру тот же объект даст уже 144 Мбит/с общего потока и около 46–47 ТБ архива за 30 дней до запаса.

Отдельно стоит выделить диски под систему. ОС, VMS и база конфигурации лучше живут на SSD или NVMe, а архив — на отдельном HDD-массиве. Это не вопрос красоты схемы: когда система одновременно пишет поток, строит индексы и обслуживает интерфейс оператора, смешивание всего на одном массиве может стать источником задержек.

Диски, RAID и сеть: где чаще всего появляется узкое место

Видеосервер редко упирается только в процессор. Чаще проблема в дисковой подсистеме и сети.

HDD для архива

Для архива обычно используют HDD, рассчитанные на постоянную работу. Важно смотреть не только на объём, но и на тип записи. Для серверного видеонаблюдения лучше избегать SMR-дисков там, где ожидается постоянная интенсивная запись и восстановление массива. Предпочтительнее CMR, особенно при RAID.

SSD и NVMe

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

RAID 5, RAID 6 или RAID 10

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

Нельзя забывать про rebuild. Когда один диск заменили, массив восстанавливается под нагрузкой. В это время сервер продолжает писать видео. Если конфигурация была собрана без запаса, именно в этот момент могут проявиться задержки, пропуски или падение отзывчивости.

Сеть

1 Гбит/с на бумаге даёт около 125 МБ/с, на практике полезная пропускная способность ниже. Для 24 камер по 4 Мбит/с общий входящий поток около 96 Мбит/с — это немного для гигабита. Но если добавить операторские рабочие места, выгрузку архива, резервное копирование, несколько потоков высокого качества и рост числа камер, запас быстро уменьшается.

Для крупных объектов стоит рассматривать 2.5G, 10G или разделение сети камер и офисной сети. Это особенно важно, если рядом живут NAS, сервер виртуализации, терминальные пользователи, VDI или другие сервисы.

CPU, GPU и виртуализация: когда видеосерверу нужна не только дисковая корзина

Если сервер просто принимает потоки и пишет их на диск без перекодирования, требования к CPU обычно умеренные. Нагрузка растёт, когда появляются:

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

Для аналитики может понадобиться GPU сервер или хотя бы конфигурация с подходящей видеокартой. Но видеокарта нужна не потому, что в проекте есть слово AI, а потому что конкретная VMS или аналитический модуль умеет использовать GPU и нагрузка это оправдывает. Перед закупкой стоит проверить требования производителя ПО: поддерживаемые модели, объём видеопамяти, число потоков, формат ускорения.

Отдельный вопрос — виртуализация. Разместить VMS в виртуальной машине можно, и это нормальный сценарий для части объектов. Hyper-V и Proxmox VE давно используются в инфраструктуре, их официальные материалы описывают базовые возможности платформ: Microsoft Hyper-V и Proxmox VE. Но видеонаблюдение в виртуализации требует аккуратности.

Что проверить заранее:

• как подключаются диски: напрямую, через HBA, через виртуальный диск или сетевое хранилище;
• хватает ли I/O не только в среднем, но и при просмотре архива;
• как VMS относится к виртуальной среде по лицензированию;
• нужна ли передача GPU внутрь ВМ;
• как будет выполняться резервное копирование без разрушения производительности;
• что произойдёт при миграции ВМ или обслуживании хоста.

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

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

Где сервер видеонаблюдения подходит, а где лучше выбрать другой сценарий

Выделенный сервер видеонаблюдения хорошо подходит, когда:

• камер больше, чем условные 8–12, и объект будет расти;
• нужен архив 30 дней и больше;
• есть несколько операторов или частый поиск по архиву;
• используются камеры высокого разрешения;
• требуется RAID и понятная замена дисков;
• есть интеграция с охраной, СКУД, кассами или аналитикой;
• нужно держать данные локально, без зависимости от внешнего канала.

Но есть сценарии, где выделенный сервер может быть избыточен.

Для небольшой точки с 2–4 камерами, коротким архивом и простым просмотром иногда достаточно регистратора или камеры с локальной записью. Для временного объекта может подойти облачное хранение, если устраивают стоимость, канал связи и политика доступа. Облачные диски уровня офисного хранения, например тарифы наподобие Яндекс 360 для бизнеса, полезны для файлов и совместной работы, но не являются прямой заменой локальному видеосерверу с постоянным потоком с десятков камер. Там другая экономика, другие требования к каналу и другая модель доступа.

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

Короткий чек-лист перед закупкой

Перед выбором сервера стоит пройтись по списку. Он помогает быстро увидеть, где в проекте не хватает данных.

По камерам

• Сколько камер сейчас и сколько может быть через год?
• Какое разрешение и FPS реально нужны по каждой зоне?
• Какой рабочий битрейт заложен: минимальный, средний или с запасом?
• Запись постоянная, по движению или смешанная?
• Есть ли второй поток для просмотра и мобильных клиентов?

По архиву

• Сколько дней нужно хранить запись по регламенту?
• Одинаковый ли срок хранения для всех камер?
• Нужен ли горячий быстрый доступ ко всему архиву или только к последним дням?
• Планируется ли резервная выгрузка важных фрагментов?

По железу

• ОС и VMS стоят на отдельном SSD/NVMe?
• Архив вынесен на отдельный HDD-массив?
• RAID выбран с учётом отказа диска и времени восстановления?
• Есть ли свободные корзины под рост?
• Диски подходят для постоянной записи и RAID?
• Сеть камер отделена от офисной хотя бы логически?

По нагрузке

• Сколько операторов одновременно смотрят камеры?
• Нужна ли видеоаналитика или распознавание?
• Будет ли VMS работать в виртуальной машине?
• Есть ли рядом 1С, NAS, VDI или другие чувствительные сервисы?
• Что произойдёт при отказе одного диска, коммутатора или сетевого порта?

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

Ещё по теме на huananzhi.ru

• Серверы для видеонаблюдения
• SSD-накопители

Читайте также

• Тихий сервер на Xeon для дома и офиса: как выбрать охлаждение, корпус и вентиляторы без серверного гула
• X99 на Xeon в 2026 году: рабочая серверная платформа или ловушка дешёвого бюджета
• 5 ошибок при выборе серверной материнской платы: где ломается конфигурация под 1С, GPU, NAS и VDI

Автор статьи