Как выполнить расчет хранилища видеонаблюдения на 60 суток

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

В этой задаче чаще ошибаются дважды. Сначала умножают число камер на условный объем «для Full HD», хотя вход, парковка и пустой коридор сжимается по-разному. Затем полученный объем называют емкостью массива, забывая про RAID, служебное пространство, запас на заполнение и рост битрейта ночью. На бумаге получается ровно 60 суток, а регистратор начинает удалять архив через 43 или 51 день.

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

Считать нужно от измеренного битрейта, а не мегапикселей

Битрейт показывает, сколько данных камера реально выдает за секунду, поэтому именно он входит в расчет объема и полосы. Две камеры 1920x1080 с одинаковыми 25 кадрами в секунду могут отличаться по среднему потоку в несколько раз: одна смотрит на спокойный склад с ровным светом, другая на листву, дождь, фары и поток людей.

На битрейт одновременно влияют разрешение, частота кадров, выдержка, уровень шума, сложность сцены, широкодинамический режим, кодек, профиль сжатия, длина GOP и выбранный режим управления потоком. Поэтому таблица «2 Мп равно 2 Мбит/с» годится для ранней оценки, но не для закупки дисков. Она скрывает именно те отклонения, которые съедают запас.

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

Измерять следует основной поток записи, а не поток, открытый оператором в раскладке. У камеры могут быть отдельные профили для архива, живого просмотра, мобильного клиента и аналитики. Сложение не всех потоков подряд, а только реально проходящих через конкретный сетевой участок, предотвращает завышение. На линии камера-сервер учитывают все передаваемые потоки, в дисковом тракте только те, которые VMS пишет.

Есть полезная проверка единиц. Если интерфейс показывает 4 Мбит/с, это мегабиты, а емкость диска указана в байтах. Деление на восемь переводит биты в байты. Ошибка на этом месте дает восьмикратный промах, и я видел ее даже в аккуратно оформленных спецификациях.

Одна формула связывает битрейт, срок и объем

Для непрерывного потока объем определяется простым произведением битрейта на время. В десятичных единицах, которыми производители маркируют диски, одна камера создает за сутки примерно 10,8 ГБ на каждый 1 Мбит/с:

ГБ/сутки = битрейт_Мбит_с × 86 400 / 8 / 1 000
ТБ/60_суток = битрейт_Мбит_с × 86 400 × 60 / 8 / 1 000 000
ТБ/60_суток = битрейт_Мбит_с × 0,648

Камера со средним потоком 4 Мбит/с запишет около 2,592 ТБ за 60 суток. Десять таких камер дадут 25,92 ТБ сырого видео. Это еще не размер массива: здесь нет аудио, метаданных, файловых накладных расходов, RAID и свободного пространства.

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

V60 = Σ(число_камер_i × средний_битрейт_i × доля_записи_i × 0,648)

доля_записи равна 1 для круглосуточной записи. Для записи 12 часов в сутки по расписанию она равна 0,5. Для событийной записи это доля времени, когда VMS действительно пишет основной поток, с учетом предзаписи и послезариси. Значение 0,2 означает примерно 4,8 часа записанного видео в среднем за сутки, а не то, что движение занимало ровно 20 процентов каждого часа.

К сырому видео добавляют отдельные потоки данных. Аудио 64 Кбит/с почти незаметно рядом с 8 Мбит/с видео одной камеры, но на сотнях каналов и длинном сроке оно уже занимает терабайты. Метаданные аналитики, индекс поиска, база событий и миниатюры зависят от VMS. Если поставщик не дает документированную норму, выделите им измеренный процент после пилота или отдельный фиксированный том. Не прячьте их в неясный «коэффициент надежности».

Я использую последовательную запись расчета, которую легко проверить: сырой объем видео, дополнительные данные, резерв емкости, полезная емкость RAID, физическая емкость. Когда все поправки склеены в один коэффициент 1,4, никто через полгода не помнит, что туда входило. Раздельные строки позволяют заменить одно допущение, не пересчитывая проект по догадке.

Разрешение и кодек дают только стартовое допущение

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

Документ Axis о кодеке AV1 приводит показательный, но не универсальный набор сцен. В параллельных тестах одной камеры поток AV1 был близок к H.265, а H.264 оказался выше; разброс между городской дневной, ночной и транспортной сценой при этом заметен. Из этого следует полезный вывод: сравнивать кодеки надо на одном устройстве, с одной сценой и одинаковой требуемой детализацией. Переносить рекламный процент с чужого ролика в свою смету нельзя.

Для первоначальной ведомости допустимы диапазоны, если они явно помечены как допущения. Например, спокойная камера 1080p при 15 кадрах в секунду на H.265 может стартовать с оценки 1,5-3 Мбит/с, оживленная 4 Мп с 20 кадрами в секунду с 3-6 Мбит/с, а детальная 4K сцена с 12-16 Мбит/с. Это не нормативы. Они лишь дают порядок величины до пилота и помогают понять, где проект требует особенно тщательного замера.

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

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

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

Непрерывная запись и запись по движению считаются по-разному

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

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

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

Гибридный режим часто лучше чистой записи по движению. Основной поток сохраняется по событию, а низкоскоростной или низкочастотный поток пишется постоянно. Так остается контекст, если детектор пропустил начало события, и при этом экономия сохраняется. В формуле обе части считают отдельно:

V = V_фоновый_поток × 100% времени + V_основной_поток × доля событий

Не применяйте коэффициент активности к потоку, который уже меняет битрейт от сцены, без проверки смысла метрики. VBR при пустом кадре сам снижает средний поток, а при движении повышает. Если средний битрейт взят за полный день, он уже содержит реальную активность. Дополнительное умножение на 0,3 допустимо только когда камера передает этот поток в VMS постоянно, но VMS записывает его 30 процентов времени. Иначе экономия учитывается дважды.

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

Пиковая полоса важнее среднего объема

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

Входящая полоса сервера записи равна сумме потоков, которые он получает. К ней добавляют служебный трафик и запас:

B_ingest = Σ(пиковый_битрейт_камеры × число_камер) × 1,2

Коэффициент 1,2 здесь не закон, а прозрачный 20-процентный проектный резерв. Если сеть разделена на участки, расчет повторяют для каждого uplink, коммутатора и сетевого интерфейса сервера. Нельзя взять общую сумму объекта и сделать вывод, что каждый линк выдержит ее автоматически. Узким местом часто оказывается один гигабитный uplink от удаленного корпуса.

Исходящую полосу считают отдельно. Одновременный просмотр, воспроизведение архива, экспорт, репликация и резервное копирование читают данные с сервера. Четыре оператора с раскладкой по 16 камер не всегда создают 64 новых потока: VMS может раздавать субпотоки или мультикаст, а может открыть отдельный unicast каждому клиенту. Это нужно увидеть в архитектуре конкретной системы.

Поток в мегабитах удобно перевести в последовательную запись на диск делением на восемь. Суммарные 600 Мбит/с равны примерно 75 МБ/с до накладных расходов. Для современного массива это выглядит умеренно, но видеозапись состоит из множества одновременных потоков, а рядом идут чтение, перестроение RAID, проверка массива и экспорт. Паспортная максимальная скорость одного пустого диска не описывает такое состояние.

Axis в документации по управлению битрейтом различает VBR и MBR. VBR сохраняет качество, позволяя потоку расти на сложной сцене; MBR ограничивает верхнюю скорость, но при жестком лимите качество может упасть именно в момент активного события. Поэтому лимит нельзя выбирать только по доступной полосе. Запишите тестовую сцену с движением, дождем или искусственным шумом и проверьте детали на ограниченном потоке.

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

RAID не заменяет расчет полезной емкости

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

Для одинаковых дисков грубая оценка выглядит так:

RAID 5: полезно ≈ (N - 1) × размер диска
RAID 6: полезно ≈ (N - 2) × размер диска
RAID 10: полезно ≈ N × размер диска / 2

Эти формулы дают верхнюю границу до форматирования и служебных потерь. В массиве из восьми дисков по 12 ТБ RAID 6 оставляет около 72 ТБ десятичной емкости, а RAID 10 около 48 ТБ. Интерфейс операционной системы может показывать меньшее число в ТиБ, потому что один ТиБ равен 2^40 байт, тогда как производитель диска считает один ТБ как 10^12 байт. Это разница единиц, а не пропавшие данные.

Не проектируйте том до 100 процентов заполнения. VMS, файловой системе и операциям обслуживания нужно свободное место; кроме того, фактический битрейт никогда не совпадает с расчетом идеально. Рабочий порог 80-85 процентов полезной емкости часто разумен, но точное значение берут из документации VMS и хранилища. Если система начинает удалять старое видео при 90 процентах, именно 90 процентов, а не полный том участвует в расчете срока.

Формулу физической емкости удобно читать справа налево:

требуемая_полезная_емкость = (видео + аудио + метаданные) × резерв_роста / допустимое_заполнение

Допустим, данные за 60 суток занимают 70 ТБ, на рост и неточность заложено 20 процентов, а заполнять том разрешено до 85 процентов. Требуется 70 × 1,2 / 0,85 = 98,82 ТБ полезной емкости. Затем под эту величину подбирают конфигурацию RAID. Восемь дисков по 16 ТБ в RAID 6 дают около 96 ТБ до форматирования, то есть не проходят, хотя номинально на коробках написано 128 ТБ.

Отдельно решите, что произойдет при отказе. Во время перестроения массив читает все оставшиеся диски и продолжает принимать видео. Нужно проверить скорость записи и срок архива в деградированном режиме. Горячий резерв ускоряет начало восстановления, но не добавляет полезной емкости. Второй сервер или реплика в другом помещении защищает от отказа корпуса, контроллера, ошибки администратора и физического происшествия, чего один RAID не делает.

Диски выбирают по записи в год, отсекам и восстановлению

Для круглосуточного архива выбирают диски, рассчитанные на постоянную многопоточную запись и на фактическую годовую нагрузку. Слова «для видеонаблюдения» сами по себе недостаточны: надо открыть паспорт конкретной модели и проверить лимит workload, допустимое число отсеков, технологию записи и условия эксплуатации.

Western Digital определяет годовую нагрузку как объем пользовательских данных, переданных на диск или с диска, пересчитанный на 8760 часов работы. В актуальном паспорте обычных WD Purple указан уровень до 180 ТБ в год, а у отдельных старших моделей и линейки Pro значения выше. Seagate для SkyHawk также указывает 180 ТБ в год, а для SkyHawk AI 550 ТБ в год. Эти числа относятся к конкретным сериям и моделям, поэтому их нельзя переносить на любой диск того же бренда.

Сравните лимит с реальной записью и чтением. Если массив ежегодно принимает 500 ТБ видео и распределяет запись равномерно на восемь дисков, грубая доля записи составляет 62,5 ТБ на диск. Но перестроение, воспроизведение, проверки, экспорт и особенности RAID добавляют чтение и запись. Производитель считает workload по данным в обоих направлениях, а не только по полезному архиву. Нужен запас, особенно если система одновременно обслуживает аналитику.

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

Число поддерживаемых потоков в паспорте тоже не заменяет расчет производительности. Заявление «до 64 камер» предполагает определенные условия и не говорит, что 64 потока по 20 Мбит/с с параллельным экспортом подходят вашему массиву. Смотрите на суммарный поток, характер операций и результаты нагрузочного теста. Для крупных систем лучше несколько предсказуемых групп хранения, чем один огромный том, отказ или перестроение которого затрагивает весь объект.

Температура и питание входят в проект хранения. Диски греются сильнее при плотной установке и восстановлении RAID; контроллер может ограничить скорость или отключить диск за пределами режима. Нужны контролируемый воздушный поток, мониторинг SMART, оповещения, ИБП и корректное завершение работы. ИБП не обязан держать объект часами, но должен перекрыть переключение питания или дать серверу штатно остановить запись.

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

Проверка на живой сцене меняет смету

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

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

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

После пилота выполните четыре сверки:

1. Рассчитанный суточный прирост архива совпадает с измеренным в пределах объяснимых накладных расходов.
2. Пиковые потоки проходят через каждый сетевой участок без потерь и очередей.
3. Архив воспроизводится и экспортируется при одновременной записи всех камер.
4. Система сохраняет запись во время проверки массива или отказа одного диска согласно выбранному RAID.

Затем проведите контроль срока без ожидания двух месяцев. Измерьте рост за семь суток, умножьте на 60/7 и сравните с емкостью, которую VMS реально разрешает занять. Отдельно смоделируйте повышенную активность. Этот прогноз не заменяет итоговую проверку на 60-й день, но быстро обнаруживает ошибку в единицах, профиле потока или политике хранения.

Не принимайте систему по числу установленных терабайт. В акте нужны измеренный битрейт по группам, доступная полезная емкость, порог удаления, прогноз срока, пиковая нагрузка и результаты воспроизведения. Тогда изменение одной группы камер можно пересчитать, а не обсуждать по памяти.

Полный расчет для 48 камер

Рассмотрим объект с 48 камерами и обязательным архивом 60 суток. В проекте есть 24 внутренние камеры 1080p со средним потоком 2 Мбит/с, 16 уличных камер 4 Мп по 5 Мбит/с и 8 камер 4K по 12 Мбит/с. Все пишутся непрерывно, а указанные значения получены после пилота, включая день и ночь.

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

24 × 2 + 16 × 5 + 8 × 12 = 224 Мбит/с

Сырой объем за 60 суток:

224 × 0,648 = 145,152 ТБ

Добавим 3 ТБ на аудио, индексы, миниатюры и служебные данные, полученные из измерения пилотной VMS. База расчета становится 148,152 ТБ. Закладываем 20 процентов на рост сцены, замену нескольких камер и отличие длительного периода от пилота:

148,152 × 1,2 = 177,7824 ТБ

Если том разрешено заполнять до 85 процентов, требуемая полезная емкость массива равна:

177,7824 / 0,85 = 209,16 ТБ

Конфигурация из 16 дисков по 16 ТБ в RAID 6 дает грубо 224 ТБ до форматирования: (16 - 2) × 16. Она проходит по емкости с небольшим остатком, но решение еще нельзя утверждать. Нужно вычесть служебные потери конкретного массива, проверить совместимость 16-дисковой группы, скорость перестроения, годовую нагрузку на модель диска и производительность при записи с одновременным чтением.

Теперь полоса. Допустим, измеренные пики составили 3,5 Мбит/с для внутренних камер, 9 Мбит/с для уличных и 20 Мбит/с для 4K. Если неблагоприятное событие может затронуть все камеры одновременно, верхняя сумма равна:

24 × 3,5 + 16 × 9 + 8 × 20 = 388 Мбит/с
388 × 1,2 = 465,6 Мбит/с с сетевым запасом

Один гигабитный интерфейс формально вмещает прием, но на нем нельзя бездумно смешивать запись, клиентский просмотр, резервное копирование и управление. Практический проект разведет трафик по VLAN и интерфейсам там, где это поддерживает архитектура, проверит каждый uplink и оставит место для исходящего чтения. Если две удаленные площадки сходятся через канал 200 Мбит/с, общая гигабитная карта сервера эту проблему не исправит.

Для записи по движению расчет выглядел бы иначе. Предположим, внутренние камеры пишут основной поток 35 процентов времени и фоновый поток 0,3 Мбит/с постоянно, а остальные камеры остаются непрерывными. Тогда внутреннюю группу считают как 24 × (2 × 0,35 + 0,3), а не как 24 × 2 × 0,35, потому что фоновая запись продолжается всегда. Долю 35 процентов нужно подтвердить по сохраненным клипам с предзаписью и послезарисью.

На крупных и государственных объектах расчет должен стать частью технического задания: таблица потоков, срок хранения, полезная емкость, уровень RAID, режим отказа, требования к дискам и метод приемочного теста. GSE может спроектировать серверную и дата-центровую часть такой системы на базе стоечных серверов S200 и связать расчет с поставкой, интеграцией и круглосуточной поддержкой по Казахстану.

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