Планирование ёмкости VMS и референс хранения

Кратко

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

Кому и зачем это нужно

Одно здание с тридцатью камерами почти считается само; тысяча камер на кампусе или система, которая должна продолжать запись, пока диск перестраивается, – нет. Это итоговый разбор блока хранения и масштаба, написанный для системного интегратора, IT- или операционного руководителя, продакт-менеджера, которому нужно превратить число камер в конкретный список железа – сколько серверов записи, сколько хранилища, какая сеть, сколько мест просмотра – и защитить эту цифру перед держателем бюджета. Предварительных знаний не требуется: каждый термин объясняется простым языком, каждая оценка показана арифметикой, которую можно повторить, а ошибку, которая тихо губит больше бюджетов, чем любая другая, – размер под ёмкость при забытых потоке, просмотре и резерве – здесь невозможно пропустить. Сделайте расчёт верно – и система переживёт свой первый плохой день; ошибитесь – и она роняет кадры, заполняется раньше срока или слепнет ровно тогда, когда нужна для инцидента.

Планирование ёмкости в одном предложении

Планирование ёмкости – это работа по тому, чтобы каждый ресурс, на который опирается система, был достаточно велик для нагрузки и имел запас, до любых закупок. Система видеонаблюдения – камеры, сеть, программа, которая записывает и управляет многими потоками (её называют системой управления видео, или VMS от Video Management System), хранилище и экраны для операторов – опирается на пять разных ресурсов, и центральная мысль этой статьи в том, что они заканчиваются не одновременно.

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

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

Нажмите, чтобы увеличить

Начните с нагрузки: единица спроса – камера

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

Вот что стоит одна типовая камера. Возьмём камеру 1080p (два мегапикселя), кодирующую в H.265 на 4 мегабита в секунду (Mbps) – нормальная современная настройка.

Строка хранилища использует константу, выведенную в статье о хранении: поток 1 Mbps, записываемый круглосуточно, даёт около 10,8 гигабайта в день (1 Mbps × 86 400 секунд ÷ 8 бит-в-байте ÷ 1000 ≈ 10,8 GB). Мы не будем выводить математику ретенции заново – это работа статьи о математике ретенции, а рычаг режима записи, который режет эти числа вдвое и больше, разобран в стратегиях записи. Для планирования ёмкости важно одно: получив нагрузку на камеру, любое другое число в дизайне выходит умножением.

Одна оговорка перед масштабированием: это плановые оценки, и реальные установки отличаются. Камеры с переменным битрейтом дают всплески, когда сцена оживает, и инструменты вендоров это прямо говорят – AXIS Site Designer, оценивающий трафик и хранилище, отмечает, что расчётные цифры – оценки и «неизбежно будут отличаться от измерений трафика реальной установки». Планируйте по числам; проверяйте пилотом.

Размер сервера записи: вопрос потока, а не числа

Первый предел, в который упирается большинство систем, – сервер записи, компьютер с той частью VMS, что принимает потоки камер и пишет их на диск. Обычный вопрос – «сколько камер тянет один сервер?», и обычный ответ в виде круглого числа вроде пятидесяти или ста вводит в заблуждение, потому что настоящий предел – это устойчивый поток, а не число камер.

Начнём с эмпирического правила, потому что на малом масштабе оно действительно полезно. Milestone, один из крупнейших разработчиков VMS, документирует, что меньшие системы до 50–100 камер могут работать на одном сервере, где все программные компоненты делят одну машину. За примерно сотней камер рекомендуется выносить компоненты на выделенные серверы. Этот порог – не закон физики; это точка, где совмещённая нагрузка записи, базы данных и стриминга на одной машине начинает конкурировать сама с собой.

Теперь реальность потока, которую число камер прячет. Тот же вендор документирует один сервер записи, выдерживающий не менее 3,1 гигабита в секунду записи – достаточно для 700 камер 1080p по 4,4 Mbps каждая. Это куда больше «сотни», и причина в том, что сервер записи в режиме чистой записи не декодирует видео; он принимает сжатые потоки и пишет их на диск. Ограничение – насколько быстро сетевая карта принимает, а диски впитывают, а не сколько имён камер в списке. За одним хорошо оснащённым сервером может стоять месяц видео двух тысяч камер – в зависимости от разрешения, частоты кадров и сжатия.

Поэтому серьёзные внедрения делят программу на роли. Один сервер управления держит конфигурацию, учётные записи и правила – это мозг, и видео он почти не несёт. Несколько серверов записи берут каждый по части камер и делают тяжёлую работу приёма и хранения. Именно это деление позволяет одной VMS масштабироваться до 100 000 камер и больше, как показывают корпоративные внедрения Milestone, без того чтобы какая-то одна машина делала всё. Сервер управления лёгкий; серверы записи добавляют по мере роста числа камер.

Нажмите, чтобы увеличить

«Частая ошибка: размер сервера записи только по числу камер. Спецификация «один сервер на 100 камер» может ошибаться в обе стороны – мало серверов для 100 камер 4K с высоким битрейтом (которые превышают поток записи сервера) или расточительно много для 100 камер 1080p с низким битрейтом. Размеряйте по суммарному битрейту, который сервер должен принять и записать, в мегабайтах в секунду, и сверяйте с сетевой картой и дисковой подсистемой. Число камер – стартовая оценка; битрейт – настоящий бюджет.»

Размер хранилища: ёмкость и поток – два бюджета

Хранилище – где живёт самое дорогое и чаще всего неверно посчитанное число системы, и у него два бюджета, которые оба нужно закрыть. Пропуск любого из них ломает систему по-своему.

Первый бюджет – ёмкость: достаточно терабайт под срок хранения. Это математика ретенции, и здесь мы держим её коротко, потому что статья о математике ретенции владеет ею целиком. Для нашего примера на 40 камер по 2 Mbps непрерывной записи 30 дней:

40 камер × 2 Mbps × 10,8 GB/день-на-Mbps = 864 GB/день
864 GB/день × 30 дней ≈ 26 TB записанного видео

Эти 26 TB – сырое видео. Диски, которые покупают на деле, должны быть больше, потому что резервирование чётностью (RAID), файловая система и правило никогда не забивать диск выше ~80% дают накладные расходы – примерно множитель 1,4–1,6, так что ~26 TB видео требуют ~39 TB выделенного хранилища. Железо, которое его держит, – прямые диски, сетевое хранилище, уровни RAID – тема статьи о локальной архитектуре хранения; планированию ёмкости нужен только множитель.

Второй бюджет – поток: диски должны принимать входящий поток записи без пауз, вечно. Этот бюджет забывают, и здесь число камер снова вводит в заблуждение. Наши 40 камер по 2 Mbps пишут:

40 камер × 2 Mbps = 80 Mbps = 10 MB/s логической записи, 24/7

Десять мегабайт в секунду звучат пустяком – один диск это потянет. Но запись видеонаблюдения – это более 90% записи, а RAID с чётностью умножает каждую запись. На RAID 6 (двойная чётность, обычный выбор для видеонаблюдения) одна логическая запись может стоить до шести физических дисковых операций – это штраф записи. Так что массив должен выдерживать порядка:

10 MB/s логических × ~6 (штраф записи RAID 6) ≈ 60 MB/s сырой дисковой работы, без пауз

Поднимите камеры до 4 Mbps – и это удваивается до ~120 MB/s устойчиво, без пауз. Подсистема хранения, размеренная только под ёмкость – пара больших медленных дисков, – может хранить видео, но не успевает за ним, и рекордер начинает ронять кадры. Решение – размерять под устойчивый поток записи, а не только под терабайты: достаточно шпинделей или достаточно быстрые диски, диски класса видеонаблюдения (CMR, не SMR) и уровень RAID, чей штраф записи вы учли. Поток в терминах хранения берётся из IOPS × размер блока – числа операций в секунду на объём каждой, – так что дизайн только под ёмкость, игнорирующий IOPS, спланирован наполовину.

Нажмите, чтобы увеличить

«Частая ошибка: размер хранилища под терабайты, но не под мегабайты в секунду. Массив на 100 TB из горстки больших медленных архивных дисков имеет ёмкость на недели видео и поток – ни на что: диски закрывают бюджет ёмкости и промахиваются по бюджету записи, и рекордер роняет кадры под нагрузкой. Всегда размеряйте оба: ёмкость – из срока хранения, поток – из скорости живой записи, умноженной на штраф RAID.»

Бюджет сети и питания

Камеры живут в сети, а у сети свои потолки – трафик, порты коммутаторов и электричество, которое доставляет питание по кабелю Ethernet (PoE – ток на том же кабеле, что и данные). Их дёшево спланировать и дорого переделывать, поэтому им место в плане ёмкости с самого начала.

Трафик – снова складываемая нагрузка. Сорок камер по 4 Mbps – это 160 Mbps к рекордеру, комфортно на гигабитном канале. Но плотность растёт быстро: 24-портовый коммутатор, полностью занятый камерами 4 мегапикселя в H.265, может гнать почти 1 гигабит в секунду устойчивого трафика, поэтому практическая рекомендация – ставить 10-гигабитные аплинки на любой коммутатор, несущий больше примерно шестнадцати камер. Аплинк – соединение от краевого коммутатора вверх к серверам записи – обычное скрытое узкое место: порт каждой камеры в порядке, а единственный аплинк, несущий их все, – нет, и слишком малый аплинк проявляется рывками или потерей видео.

У питания тоже есть бюджет. Каждая камера тянет примерно 6–12 Вт по PoE; поворотные камеры (PTZ) и модели с обогревом тянут больше и требуют PoE+ (стандарт 802.3at, до 30 Вт). Правило интеграторов – выбирать коммутатор, чей суммарный бюджет питания превышает прогнозный пик на 20–30%, чтобы коммутатор не работал на пределе блока питания.

И запас: размеряйте коммутаторы примерно на 70–75% загрузки, чтобы у сети был запас на 18–24 месяца роста, и держите камеры в своём сегменте сети (отдельный VLAN или физическая сеть), чтобы трафик видеонаблюдения был изолирован от офисного и гостевого. В числах:

40 камер × 4 Mbps = 160 Mbps суммарно
→ гигабитный канал к рекордеру загружен на ~16% — комфортно, с запасом на рост
40 камер × ~10 Вт средн. = ~400 Вт PoE
→ выбрать коммутатор(ы) с бюджетом PoE ~520+ Вт (400 Вт × 1,3)

Этот слой сети и питания – часть более широкой системы, которую анатомия системы видеонаблюдения раскладывает от и до; здесь это один из пяти бюджетов, которые вы складываете.

Ёмкость просмотра: тихо забытое узкое место

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

Современный ПК с современным графическим процессором (GPU) декодирует примерно 150 кадров в секунду видео 1080p H.264 – это всего около пяти потоков камер по 30 кадров в секунду или один поток 4K. Это и есть стена. Оператор, открывший видеостену из 25 плиток полноразмерных потоков, перегрузит обычную рабочую станцию задолго до того, как сеть или рекордеры что-то заметят.

Индустрия решает это двумя способами, и план ёмкости должен назвать оба. Первый – субпотоки: большинство камер отдают высокоразрешённый основной поток (для записи) и низкоразрешённый субпоток (для многокамерного просмотра), так что видеостена тянет 25 маленьких субпотоков вместо 25 полных, а клиент декодирует один основной поток, лишь когда оператор разворачивает плитку на весь экран. Это тот же приём «писать в полном качестве, смотреть в низком», что делает федерацию доступной между площадками. Второй – аппаратное декодирование: VMS перекладывает распаковку на GPU (Intel Quick Sync или карты NVIDIA), что позволяет одной машине показать куда больше камер, чем смог бы её CPU.

Для размера ориентир интеграторов: рабочая станция на стену из примерно шестнадцати потоков хочет 8-ядерный CPU и GPU с аппаратным декодом; тяжёлая многомониторная станция к 400 камерам на девяти дисплеях хочет два-четыре CPU и серьёзный GPU. Важное число – суммарный поток декода (мегабиты в секунду, которые клиент должен распаковать), а не число камер.

«Частая ошибка: идеально спланировать запись и хранилище, а потом забыть клиент. Диспетчерская покупает красивые рекордеры и большой массив, затем ставит видеостену из 64 камер на офисный ПК и смотрит, как он заикается. Рекордеры в порядке; клиент не может декодировать столько потоков. Размеряйте просмотр как отдельный бюджет – субпотоки для стен, аппаратный декод и рабочая станция под нагрузку декода.»

Запас и резерв: что нужно в проде

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

Запас – это намеренный зазор между ёмкостью и нагрузкой. Держите серверы записи, хранилище, сеть и клиентов примерно на 70–80% предела, а не на 100%, чтобы оживлённая сцена, всплеск движения или год роста не толкнули ни один ресурс за край. Запас – самая дешёвая страховка в дизайне: чаще всего это просто покупка на размер больше.

Резерв – это запасной, готовый на каждом слое, что может отказать. Прод-VMS строит его слоями:

Два из них стоит назвать простыми словами. Резервный сервер записи – это запасной рекордер, простаивающий и следящий за активными рекордерами; если один отказал, запасной подхватывает его камеры, и запись продолжается. Это паттерн N+1 – N рабочих серверов плюс один запасной, – и именно он не даёт отказу диска или сервера превратиться в пробел в записи. Failover сервера управления ставит мозг на два кластерных компьютера, так что если первый встал, второй берёт управление автоматически.

Одно важное ограничение, перенесённое из федерации: этот резерв работает в пределах одного вендора. Резервный сервер Milestone следит за рекордерами Milestone, а не за чужим брендом; резерв, как и федерация, живёт внутри экосистемы вендора. А самый недооценённый риск – это окно ребилда: после отказа диска массив RAID работает в деградации, пока перестраивается на запасной, и второй отказ в этом окне (часы–дни на больших дисках) может потерять массив. Это инженерная причина, почему дефолт видеонаблюдения – RAID 6 плюс горячий резерв, а не RAID 5; статья о локальном хранении разбирает этот режим отказа детально.

Нажмите, чтобы увеличить

Референс-дизайн хранения и масштаба

Сложив пять бюджетов и резерв, получаем референс-дизайн, который реально собирается. Вот рабочий пример среднего размера – 200 камер на одной площадке, 1080p, 4 Mbps, непрерывная запись, срок хранения 30 дней – размеренный от и до. Числа – плановые оценки; пилот их проверяет.

Поток записи и серверы. 200 камер × 4 Mbps = 800 Mbps = 100 MB/s записи. Вполне в пределах документированной ёмкости одного хорошо оснащённого сервера записи (вспомним цифру 3,1 Gbit/s / 700 камер), но ради резерва и запаса делим на два сервера записи (~100 камер каждый, на ~70% загрузки) плюс один резервный рекордер – пул N+1 из трёх.

Хранилище. 200 × 4 Mbps × 10,8 GB/день = 8,64 TB/день; × 30 дней ≈ 260 TB видео; × 1,5 на RAID 6 + файловую систему + запас на 80%-заполнение ≈ ~390 TB выделенного, на дисках класса видеонаблюдения CMR в RAID 6 с горячим резервом, размеренных под ~150 MB/s устойчивой записи (100 MB/s логических × штраф RAID 6, с запасом).

Сеть и питание. 200 × 4 Mbps = 800 Mbps суммарно, несут краевые коммутаторы с 10G аплинками в изолированном VLAN; бюджет PoE ~200 × 10 Вт × 1,3 ≈ 2,6 кВт, разнесённый по коммутаторам, каждый размерён на 20–30% выше нагрузки.

Управление и просмотр. Один сервер управления (лёгкий), с failover сервера управления для прода. Диспетчерская с двумя рабочими станциями видеостены, тянущими субпотоки на стену и основные потоки по клику, с GPU аппаратного декода в каждой.

Хребет стандартов. Весь дизайн стоит на открытых стандартах, чтобы не быть привязанным к одному бренду камер: ONVIF (общий язык между камерами и VMS) несёт стриминг по Profile S/T, запись и выдачу по Profile G, метаданные аналитики по Profile M – за глубиной см. коммерческий обзор профилей ONVIF в системах безопасности. На системном уровне международный стандарт IEC 62676-4:2025 (Системы видеонаблюдения для применений в безопасности – Часть 4: Руководство по применению) – это рамка для выбора, планирования, установки и объективной оценки VSS, опора стандартов для вопроса «правильно ли я это спроектировал?». За обзором того, что VMS делает на таком масштабе у одного вендора, см. системы управления видеонаблюдением.

Это итоговый разбор для одной площадки. Когда внедрение охватывает много площадок, тот же дизайн на площадку становится узлом федеративной архитектуры; когда в картину входит аналитика, слой вычислений следует референс-архитектуре edge + cloud. Планирование ёмкости – та же арифметика на любом масштабе.

Планирование ёмкости по шагам

Метод, связывающий всё воедино, – это фиксированная последовательность; следуйте ей, и ничто не останется неразмеренным.

1. Сосчитайте камеры и зафиксируйте настройки каждой (разрешение, битрейт, fps, режим записи).
2. Посчитайте нагрузку каждой камеры на каждый ресурс; умножьте на число; сложите.
3. Размерьте серверы записи по суммарному ПОТОКУ ЗАПИСИ (MB/s), а не по числу камер.
4. Размерьте хранилище дважды — ЁМКОСТЬ (TB под срок) и ПОТОК (запись MB/s × штраф RAID).
5. Размерьте сеть (суммарно Mbps, аплинки, порты) и питание PoE (+20–30%).
6. Размерьте слой просмотра по суммарному ПОТОКУ ДЕКОДА (субпотоки + аппаратный декод).
7. Добавьте запас (работа на 70–80%) и резерв (RAID+spare, рекордер N+1, failover управления, UPS).
8. Проверьте пилотом; пересчитывайте при изменении камер, битрейтов и сроков.

Это та же дисциплина оценки, которую оценка проекта видеонаблюдения превращает в цену, а полносистемная модель стоимости видеонаблюдения считает со своей таблицей – планирование ёмкости даёт количества, а те статьи навешивают стоимости. Инструменты вендоров (AXIS Site Designer, дизайнер решений Milestone, инструменты размера серверов) автоматизируют шаги 1–6 для малых и средних систем и стоят использования как сверка, помня, что их вывод – оценка. Рабочий лист ниже проводит по восьми шагам с заполненными формулами.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Планирование ёмкости выглядит как таблица, а оказывается архитектурной задачей: слой записи надо размерять по устойчивому потоку, а не по числу камер, хранилище должно закрывать и бюджет ёмкости, и бюджет скорости записи, клиентский слой должен декодировать в пределах реального лимита GPU, а у каждого слоя должна быть история резерва на момент, когда что-то отказало посреди инцидента. Фора Софт строит видеостриминг, real-time медиа на WebRTC, видеонаблюдение и системы компьютерного зрения с 2005 года – 250+ выпущенных проектов для 400+ клиентов – а это ровно та смесь, что нужна масштабной VMS: доставка медиа с учётом полосы, оркестрация многих серверов, инженерия хранения и потока и слой аналитики поверх. Мы ведём от того, как система ведёт себя под реальной нагрузкой – что диски выдерживают, когда все камеры пишут разом, что клиентская стена реально декодирует, что происходит с записью при падении сервера, – и размеряем дизайн вокруг этих чисел, затем проверяем пилотом до того, как кто-то подпишет заказ.

Главное

• Планирование ёмкости размеряет пять ресурсов – поток записи, хранилище, сеть/питание, просмотр, управление – каждый упирается в предел в своей точке.
• Камера – единица спроса: перечислите камеры, умножьте каждую нагрузку, сложите, затем добавьте запас.
• Размеряйте серверы записи по устойчивому потоку записи (MB/s), а не по круглому числу камер.
• У хранилища два бюджета: ёмкость (TB под срок) и поток (запись MB/s × штраф RAID).
• Клиент/просмотр часто самое слабое звено – его ограничивает декод; используйте субпотоки и аппаратный декод.
• Прод-дизайн работает на 70–80% с резервом на каждом слое; настоящая опасность – окно ребилда.

Что почитать дальше

• Как работает хранение видеонаблюдения: математика ретенции
• Локальная архитектура хранения: NVR, SAN, NAS и RAID
• Федерация: управление многими площадками и серверами как одной