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

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

Поэтому сервер считаем не по числу камер, а по профилю нагрузки:

входящий видеопоток → запись → дисковый I/O → VMS/службы → аналитика → поиск/экспорт → сеть → отказ/восстановление.

Сначала фиксируем, что сервер обязан делать одновременно. Потом подбираем CPU, RAM, хранилище, NIC и GPU — если он действительно нужен.

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

NVR удобен, когда его документированные пределы подходят задаче.

Сервер становится осмысленным, когда нужны:

• VMS с отдельными ролями серверов;

• большой или неоднородный парк установленного оборудования;

• гибкая архитектура хранения;

• аналитика, требующая серверных вычислений и ресурсов GPU;

• много операторов/интеграций;

• архитектура с несколькими серверами;

• отдельная роль записи и хранения;

• масштабирование, которое готовое специализированное устройство ограничивает.

Сам факт большого числа камер не делает сервер обязательным.

Сначала сравниваем задачу с реальными пределами NVR и архитектуры VMS.

Для каждой группы камер фиксируем:

• количество;

• разрешение;

• FPS;

• кодек;

• фактический/проектный битрейт;

• основной/дополнительный поток;

• непрерывная запись или запись по событиям;

• звук и метаданные, если используются;

• место выполнения аналитики: камера, сервер или другой узел;

• требуемый срок хранения;

• критичность записи.

Отдельно:

• VMS и её роли серверов;

• число операторов;

• типичные раскладки просмотра в реальном времени;

• одновременные пользователи архива;

• нагрузка при экспорте;

• нагрузка интеграций и API, если она существенна;

• мониторинг;

• сценарий расширения.

Это входные данные.

Модель процессора или уровень RAID — уже решения.

Сервер записи принимает потоки от камер/источников и записывает их в хранилище.

Для первой оценки нужен суммарный входящий битрейт.

Но одного суммарного значения в Мбит/с тоже недостаточно.

Важны:

• число одновременных соединений;

• накладные расходы протокола и драйвера;

• метаданные и звук;

• особенности работы VMS;

• пиковые нагрузки и особенности переменного битрейта;

• сетевой путь;

• характер записи на накопители.

Поэтому сервер не принимается только по таблице “сумма битрейта меньше 1 Gb/s”.

Нагрузка процессора зависит от того, что делает конкретная VMS.

Сценарии могут отличаться:

• поток в основном принимается и записывается;

• сервер выполняет перекодирование;

• обнаружение движения и аналитика на сервере;

• операции с базой данных и индексами;

• шифрование;

• интеграции;

• экспорт.

Поэтому нельзя задавать универсальное правило: «до 64 камер — такой CPU, до 128 — такой».

Сначала документация VMS и испытание пилотной конфигурации под полной нагрузкой.

GPU может быть нужен для:

• серверной аналитики;

• аппаратного декодирования, кодирования и перекодирования;

• работы конкретных модулей VMS;

• выполнения задач искусственного интеллекта.

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

Для каждого требования к видеопроцессору фиксируем:

• какая функция;

• какие камеры;

• какие разрешение и частота кадров;

• ускорение, поддерживаемое производителем;

• что произойдёт без GPU;

• приёмочное испытание.

“Поставим GPU с запасом” без описания нагрузки — не инженерный критерий.

На необходимый объём RAM влияют:

• VMS;

• количество служб;

• база данных и индексация;

• аналитика;

• кэширование;

• количество устройств;

• интеграции;

• ОС.

Не выбираем объём только по формуле “X GB на камеру”, если VMS этого не требует.

Фиксируем:

• исходные требования производителя;

• фактическое потребление ресурсов на пилотной конфигурации;

• запас ресурсов для согласованного масштаба.

Расчёт глубины архива отвечает: сколько архива нужно и как проверить фактическую глубину.

Расчёт сервера отвечает: способен ли тракт хранения данных сервера записывать и читать нужную нагрузку.

Нужно учитывать:

• одновременная запись;

• чтение архива;

• экспорт;

• нагрузка базы данных и индексов;

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

• работа контроллера и кэша;

• рекомендации для файловой системы и хранилища VMS.

Большое число TB не означает автоматически достаточную производительность.

При выборе уровня RAID отдельно учитываются:

• допустимое число отказов;

• полезная ёмкость;

• характер записи и чтения;

• поведение при восстановлении массива;

• архитектура контроллера, VMS и хранилища.

При расчёте сервера учитываем выбранную архитектуру RAID и проверяем оборудование под требуемой нагрузкой.

Нельзя считать универсальным правило: «для видеонаблюдения всегда RAID 5/6/10».

ВХОДЯЩИЙ ПОТОК СЕРВЕРА: камеры/периферийные узлы → сервер записи.

ИСХОДЯЩИЙ ПОТОК СЕРВЕРА: сервер → клиентские программы операторов, центральные службы и пути резервного копирования, архивирования и экспорта, если архитектура использует этот маршрут.

При выборе сетевого интерфейса и межузлового соединения проверяем:

• ожидаемый суммарный трафик;

• одновременный доступ клиентов;

• сеть хранения данных, если она выделена отдельно;

• резервирование, если требуется;

• совместимость коммутатора и межузлового соединения.

10GbE не требуется автоматически каждому видеосерверу. 1GbE также нельзя автоматически считать достаточным.

В некоторых архитектурах сервер записи передаёт потоки клиентам, а декодирование выполняется на рабочей станции оператора.

В других системах часть обработки может происходить на сервере.

Поэтому нельзя автоматически добавлять “100 камер × декодирование” к нагрузке процессора сервера записи.

Сначала смотрим архитектуру конкретной VMS.

Рабочее место оператора рассчитывается отдельно.

“Будет аналитика” — слишком расплывчато.

Для каждой функции аналитики на сервере:

• модуль;

• количество потоков;

• разрешение и частота кадров, используемые аналитикой;

• ресурсы процессора и видеопроцессора;

• частота событий;

• лицензия;

• поведение при отказе;

• приёмка.

Если аналитика выполняется внутри камеры, нагрузка сервера будет другой.

Сервер легко принять в момент, когда:

• камеры пишут;

• никто не ищет архив;

• никто не экспортирует;

• аналитика простаивает.

Поэтому испытание под полной нагрузкой должно включать согласованную одновременную нагрузку.

Например:

1. все предусмотренные проектом потоки записываются;

2. оператор открывает обычную раскладку просмотра в реальном времени;

3. второй пользователь ищет архив;

4. идёт экспорт;

5. аналитика и обработка событий работают под нагрузкой, если требуется;

6. мониторинг собирает данные о состоянии системы;

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

Не устанавливаем универсальный “допустимый CPU %”. Оцениваем рекомендации производителя, стабильность и запас ресурсов.

Приёмка:

• начинается контрольный инцидент;

• запись продолжается со всех согласованных камер;

• оператор открывает архив;

• переходит к нужному моменту и запускает воспроизведение;

• экспортирует фрагмент;

• параллельная запись продолжается;

• после операции проверяем отсутствие разрыва на контрольных камерах.

Если сервер прекрасно пишет, пока никто не пользуется архивом, это неполная проверка.

Вместо “оставим 30%” фиксируем:

ИСХОДНАЯ КОНФИГУРАЦИЯ:

• N камер;

• текущий битрейт;

• текущая аналитика;

• текущие операторы.

РАСШИРЕНИЕ:

• +M камер;

• повышенное разрешение для выбранных сцен;

• новая аналитика;

• второй оператор;

• увеличение срока хранения и расширение хранилища.

После этого видно, где необходим запас ресурсов: CPU, GPU, RAM, NIC, диски, слоты, PSU, лицензии.

Процент может получиться любым — он является следствием сценария, а не правилом.

Вопрос не: «нужен ли второй сервер?»

Вопрос: что должно произойти, если сервер записи недоступен?

Возможные требования:

• запись может остановиться до восстановления;

• критичные камеры должны перейти на failover;

• локальное хранение на периферийных устройствах должно закрыть часть разрыва;

• другая роль сервера принимает камеры;

• оператор должен получить сигнал тревоги.

Конкретные возможности зависят от VMS.

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

Резервирование системы в целом — отдельная задача.

После сдачи фиксируем исходные показатели:

• входящий битрейт;

• загрузка процессора и памяти в обычном режиме;

• использование хранилища;

• свободная и полезная ёмкость;

• показатели состояния дисков и массивов, доступные в выбранной системе;

• сетевой трафик;

• состояние служб VMS;

• температуры и показания аппаратных датчиков, если доступны;

• текущее количество устройств;

• ожидаемая глубина хранения из расчёта архива.

На следующем обслуживании можно сравнивать с исходными показателями вместо фразы “сервер вроде работает”.

ТЕСТ 1 — ПЕРЕЧЕНЬ ОБОРУДОВАНИЯ

Фиксируем VMS, роли серверов, группы камер и профили потоков.

ТЕСТ 2 — ПРИЁМ ПОТОКОВ

Все согласованные потоки поступают на сервер.

ТЕСТ 3 — ЗАПИСЬ

Запись идёт по принятому режиму без потерь, обнаруженных в периоде приёмочного испытания.

ТЕСТ 4 — ХРАНИЛИЩЕ

Подсистема хранения выдерживает рабочую запись.

ТЕСТ 5 — ПОИСК

Параллельно открывается архив и выполняется переход к нужному моменту и воспроизведение.

ТЕСТ 6 — ЭКСПОРТ

Идёт экспорт согласованного фрагмента при продолжающейся записи.

ТЕСТ 7 — КЛИЕНТСКАЯ НАГРУЗКА

Рабочая раскладка оператора проверяется в той части, которая реально использует ресурсы сервера.

ТЕСТ 8 — АНАЛИТИКА

Требуемые функции серверной аналитики включены и создают реальную нагрузку.

ТЕСТ 9 — СЕТЬ

Проверяем фактический трафик серверных интерфейсов и межузловых соединений при согласованной нагрузке.

ТЕСТ 10 — ПЕРЕЗАПУСК

В согласованном окне перезапускается сервер или серверная роль VMS; проверяем восстановление.

ТЕСТ 11 — ОТКАЗ

Если предусмотрен failover — выполняется контролируемое испытание отказа серверной роли согласно архитектуре VMS.

ТЕСТ 12 — МАСШТАБИРОВАНИЕ

На основании измерений фиксируются исходные показатели и допустимое расширение либо ограничение.

• профиль нагрузки;

• схема ролей серверов;

• группы камер и потоков;

• согласованные исходные значения битрейта;

• обоснование выбора процессора, памяти и видеопроцессора;

• границы архитектуры хранения;

• требования к сетевому интерфейсу и межузловому соединению;

• версия и роль VMS;

• исходные данные из расчёта архива;

• нагрузка аналитики;

• результаты пилотных испытаний и испытаний под полной нагрузкой;

• исходные показатели;

• известные узкие места;

• сценарий расширения;

• порядок действий при отказе и восстановлении;

• перечень допущений;

• документация, достаточная для дальнейшего обслуживания.

Нужно подобрать готовый NVR? → «NVR для IP-камер».

Нужно понять, сколько дней реально хранится видео? → «Архив видеонаблюдения».

Нужно выбрать RAID и поведение при отказе дисков? → «RAID для архива видеонаблюдения».

Нужно построить помещение/стойку/питание/охлаждение? → «Серверная и телекоммуникационный узел».

Нужно резервировать всю CCTV при отказах? → «Видеонаблюдение с резервированием».

Нужно внедрить именно TRASSIR? → сначала проверка совместимости и профиля нагрузки TRASSIR, затем расчёт серверного оборудования.

Нужно объединить несколько площадок в одну VMS? → «Интеграция видеонаблюдения в VMS».

Полезно прислать:

• VMS и версию;

• число камер;

• параметры видеопотоков или экспорт конфигурации;

• реальные значения битрейта, если система уже работает;

• разрешение, частота кадров и кодеки;

• режим записи;

• требуемый срок хранения;

• перечень функций аналитики;

• число операторов;

• типичные раскладки просмотра в реальном времени;

• сколько одновременных пользователей архива;

• сценарий экспорта;

• текущее серверное оборудование;

• сеть/межузловое соединение;

• RAID/хранилище;

• ожидаемое расширение;

• требование к failover.

Лучший исходный вопрос: «Что сервер должен уметь делать одновременно в самый тяжёлый рабочий момент?»

Стоимость определяют:

• VMS;

• количество и тип потоков;

• битрейт;

• роли серверов;

• CPU/RAM;

• видеопроцессор, если его необходимость обоснована;

• ёмкость и производительность хранилища;

• архитектура RAID и контроллера хранения;

• сетевой интерфейс и межузловое соединение;

• аналитика;

• лицензии;

• резервирование;

• требования к стойке и питанию;

• перенос системы;

• мониторинг и сопровождение;

• сценарий расширения.

Цена и конфигурация «сервера на N камер» определяются после составления профиля нагрузки.

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

Сколько камер выдержит сервер видеонаблюдения?

Без параметров видеопотоков и VMS корректно ответить нельзя. Число камер само по себе не описывает суммарный битрейт, аналитику, операции ввода-вывода при работе с архивом, нагрузку клиентских программ и другие нагрузки.

Что важнее — CPU или диски?

Зависит от архитектуры. Для обычной записи узким местом могут быть хранилище и сеть, а при серверной аналитике — CPU/GPU. Это определяется профилем нагрузки и требованиями VMS.

Нужна ли видеокарта серверу видеонаблюдения?

Не автоматически. GPU нужен, если конкретная нагрузка VMS, аналитики, декодирования и перекодирования использует поддерживаемое ускорение на видеопроцессоре.

Нужен ли 10GbE?

Только если схема потоков трафика и архитектура показывают такую необходимость. Сначала считаем/измеряем трафик и смотрим пути между сервером, хранилищем и клиентами.

Чем сервер отличается от NVR?

NVR — готовый аппаратный регистратор с фиксированными документированными ограничениями. Серверная VMS-архитектура гибче по ролям серверов, хранению и вычислительным ресурсам, но требует отдельного расчёта ресурсов и эксплуатации.

RAID заменяет резервное копирование или failover?

Нет. RAID решает отказ части дисковой подсистемы в пределах выбранной архитектуры. Резервный сервер с переключением при отказе, резервное копирование и дополнительная копия — отдельные задачи.