Show content

Как снизить стоимость видеосистемы

Форум Системы безопасности / Форум Видеонаблюдение /

24.09.2014 13:05:51

Основные проблемы:

1) трудность резервирования питания 220В с сохранением низковольтных выходов 12В, 24В, 9В, и даже 5В, поскольку хотелось сделать универсальное изделие для разных камер. Вариант с резервированием 220В и кучкой адаптеров не слишком изящен.

2) всепогодность и необслуживаемость неизбежно обходятся в большие габариты и цену.

3) мало софтов заточено под распределённые УНИВЕРСАЛЬНЫЕ системы. Не работает народ с NVR как с линейным оборудованием, да и сами NVR не заточены под такую работу. Нет-нет, да и требуют они при разного рода сбоях мышку с моником подцепить, и решить проблему на месте. А это место предполагается не в тёплой серверной, а на 5-метровом столбе в пургу.

Ну если сравнивать цену резервирования по электропитанию, да еще и RIAD 220-Волтовых серверов - против 12 вольтовых NVR-ров, то не думаю что выгрыш в цене, да еще и для показателя: Ампер/Часов, а вернее продолжительность автономной работы от БИРП-12 vs стоимость UPS-220 с тем же моторесурсом - будет у систем с одним глобальным серверным хранилищем. ;-)

Ну а если еще вспомнить что ВК (причем не важно IP это, или еще какая ВК) в случае резервирования всей системы - всё равно будет требовать индивидуального резерва, то проблема с "кучей" адаптеров для распределенной системы по типу "всё в одном шкапчике" - мне кажется тоже надуманной.

По поводу выхода из строя - так я вам больше скажу ширпотребные IP-ВК также подвержены зависаю, и требуют к себе "столбового уважения" ничуть не чаще (и не чуть не реже) чем DVR/NVR из поднебесной.

А вот проблем с софтом умеющим юзать NVR-ы(DVR-ы) да еще и от разных брендодержателей, да еще и умеющие объединять их в единое целое под названием удаленное АРМ - таки да нет! ;-(

И вот это (ИМХО) и есть - самая большая проблема, не позволяющая строить системы с распределенными сетевыми хранилищами на базе NVR, DVR, или даже на базе SD-карт в IP-ВК, а всё же остальное - решаемо и не так уж и дорого, ну или не дороже чем....

24.09.2014 17:22:18

Запись на камерах для большинства объектов не подходит.........из-за воровства/вандализма/пожаров и т.п.

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

А Лансеры - да, у нас тоже не идут. Ставим NVR-ы или самосборные писюки под виндой или фирменные сервера, в зависимости от конфигурации объекта, и объединяем в сетки.

24.09.2014 18:58:47

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

25.09.2014 07:37:09

А как буфер перетоптаться при сбое

Не получается!

:-(

Камера - она WEB-сервер (а ни клиент) и она понятие не имеет что твориться далее её сегмента сети (да ей это и не надо), т.е. она не занет - упала это где-то по дороге сеть, или может это просто клиент отвалил, но при этом - видео, это вещь потоковая, да еще и мало того что сжатая, а еще и "порезанная" на GOP-пы и их (если они "вылетели") - уже обратно не возвернешь и на SD карточку не запишешь.

Вот и получается - что писать на SD нужно или все GOP-пы подряд, ну или хотя бы выборочные GOP-ы по собственному детектору движения ВК. - Только в этом случае не будет потери информации, или вернее - у нас появится шанс что вся интересующая нас информация сохраниться на SD и её можно будет затем получить.

26.09.2014 21:32:03

о системе распределённой записи, без центрального сервера вообще

Как только вы откажетесь от централизованных архивных хранилищ, встанет вопрос о некоем общесетевом софте и организации распределенного архива на самих же камерах, причем с распределенной системой резервирования данных. В теории решаемая задача - торренты же работают в конце концов. На реальных камерах сейчас этого не сделать, значит опять надстройка вроде тех-же стрит-серверов с роскошным сетевым софтом, и мощной сетью межсерверного обмена данными. Кстати, стрит сервера в нынешнем виде только промежуточным хранением занимаются. Суммарный объем дискового пространства серверов должен быть равен объему отсутствующего центрального хранилища. Т.е. получается, что вместо одного локального сервера надо сделать кучу периферийных в климатическом исполнении. В процеесе проектирования кто-нить скажет: "А чё мы сервера на столбы корячим, давайте их в одной стойке соберём в центре обработки - дешевше будет". Дальше придут к выводу, что простенький периферийный сервак может обработать 4 камеры, а аналогичный по стоимости стационарный - ну скажем штук 40. Потом скажут - и нахрена нам эта стойка, писюк поставим помощнее и ага.

Все это проходилось неоднократно. Практика показывает,что растаскивание задачи из центра на периферию всегда удорожает систему, поскольку задача так просто не делится по сложности пропорционально на N кусочков. Каждый периферийный огрызок должен решать задачу, сходную по сложности с задачей центрального сервера + сетевой обмен + каналы связи. То, что решалось на скоростях системной шины, вы вытаскиваете на длинные межсерверные кишки. И число связей должно возрасти, кольцевой линией не отделаешься, надо ставить дополнительные свичи внутрисетевого обмена для повышения живучести системы и снятия пиковых нагрузок.

Короче, создание подобной системы требует общей технической готовности. Или серьезных причин для создания этой самой готовности.

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

В общем, опять диалектика, всякое эволюционное развитие и пр. хрень. Будет общая техническая готовность - будет и видеонаблюдение по настоящему сетевым. А так, порассуждать - ну да, конечно, здорово было бы. Чем мы тут и занимаемся благополучно, включая наезды с жабами. Фи, моветон.

29.09.2014 07:59:54

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

А что именно Вам так необходимо решать, да еще и на скоростях системной шины? ;-)

Уж часом не распаковыванием ли сжатого, да еще и c 50-70% потерями, причем переданного именно на длинных "межсерверных кишках" видеосигнала Вы собираетесь решать задачи на системной шине сервера?!

И видимо решать эти задачи на системных скоростях Вам необходимо для всевозможной аналитической обработки, которая так необходима для выборочной записи из Big Data потока полученного по IP 100 мбитным каналам в сжатом виде!

- я правильно Вас понял?

PS

Практика показывает,что растаскивание задачи из центра на периферию всегда удорожает систему

Ну во-первых не всегда и не везде, взять хотя бы для примера тот же скажем СКУД, или туже самую ОПС с системой всевозможных расширителей управляемых по шине: - и та и другая правильно построенная система, - вполне работоспособна и даже без центрального сервера.

Ну а что касаемо видеосистем, так прежде чем так огульно утверждать что распределенная система будет ВСЕГДА дороже локальной, ну ВЫ для начала попробуйте хоть раз ДЛЯ СЕБЯ составить проектно-сметную прикидку двух равнозначных по функционалу систем выполненных:

- по обще принятой локальной схеме с одним сервером и количеством ВК большем чем ну скажем 32

- и все тоже но по распределенной схеме, предложенной Михаилом Арсетьевым, но на железе доступном сегодня.

;-)

02.10.2014 10:06:18

Прошу прощения, что задал вопрос и исчез на пол месяца. Больно интересный проект в разработке http://onlinecctvplan.ru

Все CCTV со всеми расчетами уводим в OnLine. Очень интересная тема.

Но вернусь к своему вопросу с утверждения Macroscop.

Macroscop утверждает что: «параллельная запись потоков от всех камер на все диски системы хранения повышает общую скорость записи.»

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

Egor этот момент прокомментировал так: «при параллельной записи скорость записи на каждый диск теоретически в N раз меньше скорости общего потока (N - число дисков). Поскольку диск - самое медленное устройство в системе, общая скорость записи возрастает.».

На сервер идет последовательный поток, максимальная скорость которого не должна превышать скорости записи HDD. Этот поток Macroscop перераспределяет на все диски, деля его на блоки чуть больше мегабайта. Как можно последовательный поток разделить для записи на большое количество дисков? Давайте посмотрим на рисунок.

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

После того как первый диск закончит запись 1-го блока начинается запись второго блока 2-м диском. При этом 1-й и 3-й диски ничего не пишут.

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

Где я ошибаюсь?

02.10.2014 11:28:40

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

Где я ошибаюсь?

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

02.10.2014 11:57:35

но правильнее это когда весь поток находится сначала в буфере памяти,

В таком случаи, о каком увеличении скорости записи мы говорим?

Разве распаковка последовательного потока в памяти не занимает время?

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

Получается все заявления об увеличении скорости записи это пиар ход.

02.10.2014 11:59:10

но правильнее это когда весь поток находится сначала в буфере памяти,

Разве распаковка последовательного потока в памяти не занимает время?

Для каких целей распаковывать поток?