Page tree
Skip to end of metadata
Go to start of metadata

Введение

При проектировании систем видео-наблюдения часто стоит вопрос об удобстве работы с архивом. В интерфейсе ПО Trassir наглядно отображается глубина записанного архива. Измеряется глубина архива в днях.

Индикация глубины архива представлена следующим образом:









Подчеркнутая строчка - это индикатор глубины архива. Данный индикатор отражает глубину архива видеопотоков. Расположены они следующим образом:

основной поток/привилегированный поток /субпоток (например: 78/0/58).

Глубина архива считается с первой записи в архиве. Если у вас есть запись в архиве 7 дней назад, а за последующие шесть дней записи нет, то глубина архива, все равно, будет отображаться 7 дней.

В ПО Trassir 3.1 архив от предыдущих версий ПО Trassir в статистике глубины архива не учитывается.

ПО Trassir может вести запись на жесткие диски (HDD), сетевые жесткие диски и папки, твердотельные накопители (SSD, флеш-накопители) сетевые хранилища (NAS). Под запись архива лучше использовать файловую систему NTFS, так как тестирование работы архива с другими файловыми системами не проводилось. Исключением является файловая система EXT 4. Данная файловая система используется на наших серверах с предустановленной Trassir OS 

ПО Trassir не пишет архив на системный раздел, а также диски и разделы объемом меньше 10Гб.

Ниже представлена структура архива ПО Trassir.

Структура архива  и принцип его работы

В корне каждого HDD или раздела HDD создается папка с именем TrassirArchive-3.1. В данную папку “складывается” вся информация с камер. Архив ПО Trassir имеет определенную структуру. На рис. 1 приведена структура архива.













Рис. 1

Как видно из рис. 1 в папке имеется ряд файлов, каждый из которых отвечает за определенный функционал ПО Trassir. Рассмотрим более подробно:

1. блоки и индексы архива.

2. флаги архива.

3. метаданные ActiveSearch


1. Блоки  и индексы архива.


Блоки архива служат ячейками для хранения видеопотоков подключенных камер к ПО Trassir. Соответственно архив ПО Trassir состоит из файлов-блоков (по 2Гб) и файлов индексов (по 15мб).

В файлах-блоках хранится информация со всех камер подключенных к ПО Trassir.

Файл индекса содержит в себе информацию о дате, времени, и какой камере принадлежат те или иные кадры (фреймы).

В названии файла блока отражено:

- тип потока (Префикс “1-” - основной поток, “2-” - привилегированный поток, “3-” - субпоток).

- префикс “а” и “f” свидетельствуют о времени записи блока в архив, то есть индекс “a” свидетельствует, что блок в архив был записан в настоящем времени,  а индекс “f” - свидетельствует о записи блока архива в будущем. Такое возможно при переводе часов на сервере на более ранее время. Что является нормальной реакцией Trassir на ненормальное поведение системы.

Блоки с префиксом “f” в интерфейсе ПО Trassir будут находится в “потерянных каналах” и иметь имя - “имя канала (future)” (рис.2).












Рис. 2.

 

Если на сервере время переводили несколько раз, то блоки архива, которые уже имели префикс “f” МОГУТ быть не читаемы. В такой ситуации необходимо обратиться в техническую поддержку.

Мегаблоки

Мегаблоки - несколько блоков архива с общим файлом индекса, то есть на каждом диске есть файл индекса, содержащий в себе информацию о других блоках входящих в состав этого мегаблока. Использование мегаблоков позволяет повысить скорость работы с блоками архива и более равномерно распределить (уменьшить) нагрузку на HDD сервера. Достигается это за счет того, что прочитав один файл индекса мегаблока ПО Trassir оперирует сразу с несколькими блоками архива, которые расположенны на разных HDD сервера.

На создание мегаблоков влияет количество каналов и количество HDD подключенное к серверу.

В ситуации когда в системе (на сервере) от 5 каналов и от 3 HDD, будут создаваться мегаблоки.












Рис. 3


2. Флаги архива.


Рассмотрим за что отвечают флаги архива.

Motion_search_mark - флаг указывающий на каком HDD хранятся метаданные  ActiveSearch (ActiveSearch - это видеоаналитика ПО Trassir позволяющая искать наличие движений в указанной пользователем области кадра). Данный флаг должен быть только на одном HDD (если этот HDD не отключали и запись аналитики не велась на другой HDD).

Initial_fill - флаг отвечающий за заполнение HDD файлами архива.

При отсутствии файла initial_fill в директории TrassirArchive-3.1 архив будет перезаписываться независимо от наличия свободного места на HDD.(При условии наличия созданых блоков на данном диске.).

Цикл перезаписи архива начнется автоматически при следующих условиях:

- когда на HDD без метаданных ActiveSearch (то есть без флага motion_search_mark) остается 2Гб свободного места.

- в случае, если на HDD имеются метаданные ActiveSearch, то цикл перезаписи начнется при 12Гб свободного места на HDD или меньше, в зависимости от условий (например большого количества метаданных ActiveSearch). В данном случае 10Гб будут отведены под метаданные ActiveSearch, а 2Гб для перезаписи блоков архива.

При начале цикла перезаписи флаг initial_fill удаляется.

Файл README.txt - данный файл не является флагом. ПО Trassir с помощью данного файла определяет наличие прав чтения и записи в папку архива.

Format_mark - данный флаг присутствует только в Trassir OS. Он свидетельствует о том, что HDD отформатирован и готов для записи архива. При удалении данного флага появится возможность форматирования этого HDD в Trassir OS.


3. Метаданные ActiveSearch.


В структуру архива входят папки, которые содержат в себе метаданные для видеоаналитики  ActiveSearch.

Названия папок содержат префиксы “M$” и GUID’ы каналов (см рис. 1).

Соответственно в папках содержатся файлы метаданных  ActiveSearch.

В названии файла метаданных отражена дата события и его время в unixtime (рис.4).









Рис. 4


При изъятии HDD с метаданными ActiveSearch  (например диск 1) ПО Trassir начнет записывать новые метаданные ActiveSearch на любой другой HDD (например диск 2). При возвращении в систему ранее изъятого диска (диск 1) ПО Trassir будет снова оперировать с метаданными ActiveSearch ранее изъятого HDD (то есть с диском 1). Соответственно метаданные ActiveSearch с другого HDD (диска 2) в ПО Trassir доступны не будут. Но их можно перенести из одной папки в другую.

Данные ActiveSearch “прикреплены” к времени когда было совершено событие. После перезаписи блока архива относящегося к какому-либо событию данные этого события из БД ActiveSearch будут удалены только в 00:00 ночи, то есть при наступлении следующего дня.

HDD, на котором присутствует флаг motion_search_mark “уйдет” на перезапись архива при 10 Гб. свободного места (10 Гб. отведены для БД ActiveSearch.). При “разрастании”  БД ActiveSearch больше 10 Гб. будут удаляться блоки архива.


Три кольца записи


При определенных настройках ПО Trassir на HDD будут записываться основной видеопоток, привилегированный видеопоток, субпоток - это и есть технология - “три кольца записи”. При большом количестве HDD в системе ПО Trassir чередует HDD между собой в зависимости от нагрузки на них. Для записи основного потока за единицу времени ПО Trassir не может использовать больше 4 HDD.

На рис. 5 представлено более наглядно распределение записи на HDD:



















Рис. 5

Как видно из рис.5 основной видеопоток и привилегированный видеопоток на HDD записывается по алгоритму n-1, то есть субпоток пишется всегда на отдельный HDD.

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


Скорость записи и максимальный объем архива


1. Скорость записи архива.

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

В ПО Trassir 3.0, из-за особенностей записи архива, HDD сервера со временем фрагментировались, что в конечном итоге приводило к “падению” скорости чтения и записи архива.


Что такое фрагментация жесткого диска и какие проблемы она с собой несет?

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

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

Чем сильнее фрагментирована файловая система, тем медленней компьютер работает с информацией на жестком диске (то есть снижается скорость записи и чтения). А в связи с тем, что жесткий диск — одно из наиболее узких мест в быстродействии ПК, то при увеличении фрагментации может значительно страдать производительность всего компьютера.


Что такое дефрагментация жесткого диска?


Дефрагментацией HDD называется процесс, в процессе которого убираются фрагменты файлов или хотя-бы уменьшается их количество. 


Соответственно, если HDD отведенный под архив был отформатирован и смонтирован в ПО Trassir под запись, то такой HDD не будет фрагментированным и фрагментироваться в дальнейшем не будет, при условии конечно отсутствия человеческого фактора. 


В табл. 1 отражена скорость записи архива в ПО Trassir.



Количество HDD

фрагментированные HDD

не фрагментированные HDD

1

4 mB/s

25 mB/s

2

5 mB/s

50 mB/s

3

15 mB/s

100 mB/s

4

20 mB/s

150 mB/s

5

25 mB/s

200 mB/s

6

25 mB/s

200 mB/s

7

25 mB/s

200 mB/s

8

25 mB/s

200 mB/s

Табл. 1




Чем больше время беспрерывной работы ПО Трассир сервер, тем более быстро можно работать с архивом. Это связано с тем, что ПО Trassir за время своей работы хранит в кэше/буфере информацию о имени и расположении файлов индексов/блоков.



 2. Максимальный объем архива.


В нашем архиве есть определённые ограничения на максимальный размер диска под архив (глубина архива). Связано это с тем, что размер файла индексации конечен и не может превышать 15мб. А ведь в этом файле хранится вся информация о каждом из каналов в системе и ссылка на блоки, где присутствует хотя бы кусочек архива относящегося к этому каналу. Чем больше каналов в системе - тем больше таких записей, а от размера диска зависит кол-во созданных блоков и значит цепочки зависимостей длиннее и содержат больше данных. Т.е. существует прямо пропорциональная зависимость между доступным кол-вом каналов и размером дисков. 

Вот формула расчёта этой зависимости:

Кол-во каналов * ( Максимальное кол-во 2Гб блоков / 1024 / 1024 ) ≤ Размер a-block файла

Кол-во каналов - тут всё понятно.

Максимальное кол-во 2Гб блоков = размер диска (Гб) / 2.

Пример: 1,8Тб диск вмещает в себя 900 блоков.

Размер a-block файла = константа в 15мб. 

Если мы вылезаем за пределы в 15мб, то лишняя информация будет утеряна и цепочка зависимостей для канала будет неполной. В итоге Трассиру придётся перебирать все ближайшие файлы индексации и достраивать цепочку самостоятельно. Когда кол-во таких файлов десятки тысяч - данная процедура уже начинает занимать ощутимое время. Чем грозит выход за рамки этих ограничений для пользователей? Долгая индексация при запуске Трассира (вкл. дисков): например по 10-15 минут. Сильные задержки при построении таймлайна: например несколько минут переходить на следующий день/месяц.

Дополнительно



1. Расчет емкости HDD.

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

где:

C - количество камер.

B - битрейт выставленный на устройстве (битрейт - буквально, скорость прохождения битов информации, то есть максимальное количество бит, которое можно передать в единицу времени.).

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

Запомним, что 1 байт = 8 бит. Поэтому в формуле выше общий битрейт с устройств необходимо поделить на 8.

Полученный результат - это объем информации за секунду. Далее переводим секунды в минуты, то есть умножаем на 60 (получаем объем информации за минуту), затем еще раз умножаем на 60 (получаем за час) и т.д.

Пример:

Имеем 23 камеры с максимальным разрешением записи 2Mpix и 4Tb HDD на сервере.

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


Соответственно находим общий битрейт:

средний битрейт для 2mp камер при 25 к/с. (1920х1080/25fps) составляет 3 мбит.

23 * 3 = 69 мбит/с (это общий битрейт со всех 23 камер).

Переводим мбит/с в мб/с поделив на 8.

69/8 = 8,7 мб/с (необходимая скорость записи на HDD сервера, при условии что диск нефрагентированный согласно табл. 1 проблем с нехваткой скорости записи не будет)

Далее переводим в минуты умножив на 60.

8,7 * 60 = 522 мб/м.

И так далее переводим в часы и сутки.

522 * 60 = 31320 мб/ч.

31320 *24 = 751680 мб/сутки.

Для более удобного восприятия полученный результат переведем в Гб.

751680/1024 = 734 Гб в сутки при постоянной записи.

Соответственно переведем емкость HDD из Тб. в Гб., то есть 4 * 1024 = 4096Гб.

И в итоге находим глубину архива.

4096/734 =  5, то есть глубина архива составит 5 суток, при условии, что запись велась на сервере постоянно.

 

Для удобства на нашем сайте есть калькулятор по расчету глубины архива:http://www.dssl.ru/support/tech/trassir-calc.php


2. Распределение блоков архива при различных емкостях HDD.


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

Пример 1.

Рассмотрим ситуацию, когда под запись архива отведено 2 HDD объемом по 2Тб. каждый. На рис. 6 представлено как будут распределяться блоки архива в такой системе.









Рис. 6

Как видно из картинки диски заполняются блоками архива равномерно.

Пример 2.

Рассмотрим случай когда в системе 2 HDD, но один диск объемом 2Тб, а второй диск - 4Тб. (рис. 7).











Рис. 7

В этом случае наблюдаем, что ПО Trassir блоки архива на HDD меньшего объема (2Тб.) начинает прореживать, тем самым увеличивая нагрузку (чтения/записи) на HDD большего объема.

Пример 3.

Рассмотрим ситуацию (рис. 8) при использовании в системе нескольких HDD по 2Тб. (например 2 HDD) и NAS (сетевого хранилища) объемом 10Тб.  Клиентам такую конфигурацию не рекомендуем.

Вот почему: 












Рис. 8

Как видно из рис.8 при такой большой разнице в объеме между HDD и NAS, на NAS всегда будет присутствовать свободное место. Вызвано это тем, что ПО Trassir пытается выравнять архив по всем дискам. Соответственно данная конфигурация не целесообразна.

То есть, для обеспечения нормальной работоспособности архива с использованием NAS большого объема необходимо будет создать на NAS логические разделы объемом примерно равным объемом используемых HDD в системе, либо с помощью RAID контроллера объединять все локальные HDD на сервере в раздел аналогичного объема, что и на NAS.

В ПО Trassir можно добавить максимум 24 тома для записи. Связано это с ограничениями Windows по кол-ву латинских букв для назначения томов устройств.

Обойти это ограничение возможно путем добавления HDD как сетевая папка. 


Частые ошибки HDD в ПО Trassir


В процессе эксплуатации ПО Trassir могут возникать различные ошибки связанные с архивом. Рассмотрим более подробно наиболее часто встречающиеся из них:


disk too slow - данная ошибка возникает в ситуациях, когда скорости записи HDD недостаточно для записи видеопотока.

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

 

disk too slow(2) - данная ошибка возникает в ситуациях, когда из-за нехватки скорости записи “активный” блок архива еще не записан полностью, но необходимо уже начать запись информации в следующий блок архива.

 

disk space not available - данная ошибка возникает в случаях когда ПО Trassir по каким то причинам не может выделить свободное место для создание блока архива.

 

(error 27) ERROR_SECTOR_NOT_FOUND - сектор не найден, возможно на HDD присутствуют битые сектора.

 

(error 1117) cannot write  - запрос не был выполнен из-за ошибки ввода/вывода на устройстве). Данная ошибка может быть вызвана нехваткой прав для записи на HDD или некорректными настройками в ПО Trassir (например все HDD включены только на чтение).

 

ошибка boost::file::system::rename с ссылкой на определенный блок - кто-то стер блок.

 

При использовании привилегированных каналов в случае, если глубина основного потока будет составлять меньше суток, в ПО Trassir возникнет ошибка: “нынешние настройки привели к вытеснению основного потока…”





Остались вопросы? Задайте их прямо здесь...