Телефон
Электронная почта
Мессенджеры
Связаться со специалистом
Задать вопрос
Оставить заявку
Наш специалист перезвонит Вам в течение двух минут и детально проконсультирует

    Ваш номер телефона

    Ваше имя

    Ваш email

    Сообщение

    или
    Напишите нам в соц. сетях
    Остались вопросы?
    Наш специалист перезвонит Вам в течение двух минут и ответит на ваши вопросы

      Ваш номер телефона

      Ваше имя

      Ваш email

      Ваш вопрос

      или
      Напишите нам в соц. сетях
      Спасибо!
      Ваша заявка отправлена.
      Скоро мы свяжемся с вами
      или
      Напишите нам в соц. сетях
      Мы официальный представитель китайского завода HUANANZHI
      Каталог
      Каталог
      Связаться со специалистом
      0
      Всё о серверном железе

      Сервер видеонаблюдения: как рассчитать хранилище под IP-камеры

      8 мин. чтения

      Сервер видеонаблюдения представляет собой компьютер x86-архитектуры (обычные Xeon-серверы, а не специализированные «коробочные» NVR), который принимает видеопоток с IP-камер, записывает его на дисковый массив и отдаёт для просмотра и аналитики. Главная инженерная задача при подборе такого сервера: не мощность процессора и не количество портов, а точный расчёт объёма хранилища. Ошибка в формуле оборачивается либо переплатой за неиспользуемые терабайты, либо архивом, который обрывается раньше требуемого срока хранения (30 суток, типовой стандарт для большинства объектов по требованиям безопасности).

      Формула расчёта объёма архива

      Базовая формула не зависит от бренда оборудования и одинакова для любого NVR или VMS:

      Объём архива (ГБ) = битрейт камеры (Мбит/с) × количество камер × время хранения (сек) / 8 / 1024

      Деление на 8 переводит биты в байты, деление на 1024, мегабайты в гигабайты. Время хранения переводится в секунды (сутки × 86 400). Разберём на конкретном примере.

      Пример: 20 камер, 4 Мбит/с, 30 суток непрерывной записи

      • Битрейт одной камеры: 4 Мбит/с (типично для 4-мегапиксельной камеры с кодеком H.264 при среднем качестве сцены).
      • Число камер: 20.
      • Время хранения: 30 суток = 2 592 000 секунд.

      Расчёт: 4 × 20 × 2 592 000 / 8 / 1024 = 25 313 ГБ ≈ 24,7 ТБ на 30 суток непрерывной записи всех 20 камер.

      На практике к результату добавляют запас 10–15% на пиковые сцены (движение, смена освещения увеличивают битрейт CBR-потоков) и на служебные данные VMS (индексы, метаданные аналитики). Итоговый ориентир для этого примера: около 27–28 ТБ полезного объёма после форматирования и с учётом отказоустойчивости RAID.

      Что реально влияет на объём: разрешение, кодек, режим записи

      Кодек H.265 против H.264

      Кодек H.265 (HEVC) при одинаковом разрешении и субъективном качестве картинки даёт битрейт в среднем на 40–50% ниже, чем H.264. Та же камера, что писала на 4 Мбит/с в H.264, в H.265 обычно укладывается в 2–2,5 Мбит/с. Для расчётного примера выше переход на H.265 снижает требуемый объём с 24,7 ТБ примерно до 13–14 ТБ на те же 30 суток. Разница ощутимо влияет на выбор конфигурации сервера и итоговую стоимость дисковой подсистемы.

      Разрешение камеры

      Битрейт растёт вместе с разрешением почти линейно при одном кодеке и одинаковой частоте кадров: 2 Мп камера в H.264 обычно требует 2–3 Мбит/с, 4 Мп: 4–6 Мбит/с, 8 Мп (4K): 8–12 Мбит/с. Перед расчётом стоит взять реальные цифры битрейта из спецификации конкретной модели камеры или из настроек её потока: паспортные «средние» значения производителя часто занижены относительно факта на сложных сценах.

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

      Запись только по движению (motion detection) сокращает фактический объём записанных данных на 60–80% на большинстве объектов: камера пишет не круглосуточно, а лишь в интервалы активности в кадре. Экономия сильно зависит от сцены: на оживлённой проходной выигрыш минимален, на складе в нерабочее время максимален. Для объектов с юридическими требованиями к непрерывности архива (банки, часть ретейла) запись по движению обычно не подходит, там расчёт ведётся по формуле непрерывной записи без скидок.

      Таблица: число камер и битрейт → объём хранилища и RAID

      Ориентировочные объёмы для 30 суток непрерывной записи (H.264, без запаса на пик-нагрузку), а также рекомендуемый уровень RAID под соответствующее число дисков в сервере.

      Камер Битрейт на камеру Объём за 30 суток Рекомендуемый RAID
      8 4 Мбит/с ~10 ТБ RAID 10 (4 диска)
      16 4 Мбит/с ~20 ТБ RAID 6 (6–8 дисков)
      20 4 Мбит/с ~25 ТБ RAID 6 (8 дисков)
      32 6 Мбит/с ~60 ТБ RAID 6 (8+ дисков, увеличенная ёмкость)
      64 8 Мбит/с (4К, H.265) ~85 ТБ RAID 6 с расширяемой корзиной СХД

      Таблица показывает порядок величин для быстрой прикидки. Для точного подбора сервера всегда пересчитывайте по формуле выше с реальным битрейтом ваших камер: паспортные значения могут отличаться от расчётных на 20–30%.

      RAID для непрерывной записи: почему не RAID 5

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

      • RAID 6: переживает отказ двух дисков одновременно, оптимален для больших ёмких массивов (8+ дисков) с длительным хранением. Стандартный выбор для архивов видеонаблюдения объёмом от 20 ТБ.
      • RAID 10: быстрее на запись и чтение (важно при большом числе одновременных потоков и при просмотре архива несколькими операторами), но полезная ёмкость составляет только половину от суммарной ёмкости дисков. Оправдан на небольших конфигурациях (до 8 камер) или там, где критична скорость доступа к архиву, а не максимальная ёмкость.
      • Горячий резерв (hot spare): отдельный диск в режиме ожидания, который автоматически включается в массив при отказе одного из рабочих. На круглосуточных архивах экономит время до физической замены диска и снижает риск попадания под «второй отказ» во время ребилда.

      Роль CPU и ОЗУ при видеоаналитике

      Если сервер только пишет поток на диск (пассивное хранение), нагрузка на процессор минимальна: справится один Xeon средней линейки. Ситуация меняется, если на сервере одновременно работает видеоаналитика: детекция лиц, распознавание номеров, подсчёт людей, трекинг объектов в кадре. Такая нагрузка представляет собой уже параллельную обработку десятков видеопотоков в реальном времени, и здесь важны количество ядер (аналитика хорошо масштабируется на многопоточность) и объём ОЗУ (буферизация кадров, работа нескольких модулей распознавания одновременно). Двухпроцессорная платформа с ECC REG памятью: типичное решение для серверов, которые совмещают хранение архива и серверную аналитику по нескольким каналам одновременно, а не выносят распознавание на отдельный edge-модуль в самой камере.

      Совместимость с ПО VMS: Trassir, Macroscop, «Линия» и другие

      Сервер на базе Xeon и стандартной серверной платформы x86 не привязан к конкретному производителю программного обеспечения видеонаблюдения. На такой сервер можно установить любую VMS: Trassir, Macroscop, «Линия», Axxon Next, Intellect и другие, по тем же принципам, что и на обычный компьютер. Требования к лицензиям на число каналов и версии ОС смотрите у конкретного вендора ПО, а не у поставщика сервера. Это отличает серверный подход от «коробочных» NVR с закрытой прошивкой: аппаратная платформа выбирается по параметрам (число дисковых отсеков, объём памяти, CPU), а программная часть подбирается отдельно, под требования конкретного проекта и уже используемой на объекте системы.

      Число дисковых отсеков: закладывайте запас на рост

      Расчёт хранилища редко делается один раз навсегда: число камер на объекте обычно растёт, а требования к сроку хранения архива иногда ужесточаются нормативно. Практический подход: подбирать сервер не впритык под текущий объём, а с запасом по числу свободных дисковых отсеков (2U-платформы с 8–12 отсеками дают такой резерв). Это позволяет нарастить ёмкость установкой дополнительных дисков без замены всего сервера, когда архив перестаёт помещаться в исходный расчёт.

      Готовые конфигурации в нашем каталоге

      Для проектов видеонаблюдения у нас есть готовые 2U-серверы HUANANZHI на платформе 2× Intel Xeon E5 v4, с оперативной памятью DDR4 ECC REG и аппаратным RAID-контроллером HP/HPE P840, который поддерживает RAID 6 и RAID 10 для описанных выше сценариев отказоустойчивого архива. Хранилище построено на горячих SSD Intel S4510: конфигурации от 4×2 ТБ (8 ТБ) до 8×2 ТБ (16 ТБ), стоимость от 688 558 ₽.

      Важная оговорка по-честному: это SSD-хранилище среднего объёма, рассчитанное на скоростной доступ к архиву и умеренное число камер. По таблице расчёта выше оно закрывает конфигурации примерно до 16–20 камер на 30 суток в H.264 (заметно больше в H.265 или в режиме записи по движению). Для очень больших архивов, от 32 камер и выше, либо от требования хранить 60–90 суток, объём наращивается индивидуально: дисковая корзина сервера позволяет добавлять накопители, либо подбирается конфигурация с HDD большего объёма вместо SSD. По таким проектам лучше обратиться за индивидуальным подбором: мы посчитаем точный объём под ваше число камер, битрейт и срок хранения.

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

      Заключение

      Расчёт хранилища для сервера видеонаблюдения строится на одной формуле: битрейт × число камер × время хранения. Но точность результата зависит от честных исходных данных: реального битрейта камер (а не паспортного минимума), выбранного кодека, режима записи и требуемого срока хранения по нормативам объекта. RAID 6 остаётся разумным выбором по умолчанию для круглосуточных архивов, RAID 10 хорош там, где важна скорость доступа к записи. Прежде чем заказывать сервер, пересчитайте объём под свои условия: цифра «плюс-минус 20 ТБ» на этапе проекта дороже обходится после монтажа, чем при подборе.

      Нужна помощь с расчётом под конкретный объект (число камер, разрешение, срок хранения)? Напишите нам, подберём конфигурацию сервера и объём RAID-массива под ваши параметры без переплаты за неиспользуемые терабайты.

      Автор статьи
      Поделиться:
      Корзина
      Вход

      Нет аккаунта?

      Сайдбар
      Магазин
      Избранное
      0 пунктов Заказ
      Мой аккаунт
      ×
      Сообщество HUANANZHI
      Присоединяйтесь к Telegram-чату! Советы по сборке, помощь от владельцев комплектующих и свежие новости бренда.
      Вступить в чат