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

Question

[Art_Sh82]

Есть несколько вопросов:
1. Делаем систему видеонаблюдения, при этом используем 4G камеры. Прошивка кастомная, камера сама шлет поток на сервак. Поток h.265 + AAC 1920*1080 30fps. Протокол собственный. Задача сервака аудио-видео фреймы упаковывать в MP4 контейнер. Длительность каждого файла 5-10 мин. Кол-во камер: 300. Какой требуется сервак, имеется ввиду память-проц, и какая дисковая подсистема?
2. Задача чуть усложняется и мы хотим смотреть ролики. При этом кол-во пользователей, которые будут смотреть ролики, не превышает 10. Раскодировку потока перекладываем на сторону клиента. Вопрос тот же, какое железо надо?
3. К серваку есть желание подключить 4-5LTE CAT4 модемов разных операторов с реальными IP. Т.е. сервак видит мир через беспроводное соединение. Как сделать балансировку каналов связи? Можно ли привязать все IP к единому доменному имени, чтобы через него камеры коннектились на сервак?

Answer 1

[rPman]

Протокол собственный

все зависит от его реализации

Кодирование потока надеюсь у вас специализированные железки или ip-камеры, потому как иначе такой поток не всякий сервер сможет обработать (можно сколхозить на базе nvidia gpu что-нибудь).

Все остальное не добавляет никаких особых требований, настоятельно рекомендую собрать и протестировать уменьшенную версию решения с 1-2 камерами, скорее всего каждая будет требовать десяток другой ram и процент от ядра процессора.

300+10 потоков умножаете на битрейт, плюс 30% получаете требования к дисковой системе. Обычные дешевые hdd дадут порядка 100мбайт/сек (помним что линейная скорость у hdd дисков не равномерная и кратно падает при нелинейном доступе, т.е. во время просмотра роликов, и то, если оттюнить файловую, к примеру увеличить параметр read-ahead), т.е. при 8мбит/с на камеру к примеру позволит на диск писать не больше 100 потоков а если одновременно и читать, то в разы меньше. Я видел системы, сколхозенные на windows машинах, они захлебывались на паре десятков потоков на диск. Так что рекомендую linux,

Можно добавить промежуточный ssd буфер, на который будет производиться запись с камер, а уже с него паралелельным скриптом чанки видео переносятся на hdd, при просмотре роликов во временном интервале, пока они влезают на ssd, особого замедления не будет, и да скорость работы с ssd нужно брать в худшем (делить на 2 от худшей скорости записи на синтетических тестах, после полной записи всего объема на диск и помнить о быстрой выработки ресурса записи в таком режиме)

Есть два способа использования этого буфера

выбор зависит от того, какие именно ролики нужно будет смотреть из архива или недавние:
* в буфер пишутся чанки видео и копируются на hdd в режиме FIFO, заполнив диск по максимуму, таким образом буфер содержит видео за последние X времени, и позволит просматривать эффективно только эти, к сожалению архив смотреть нельзя, так как это уронит скорость и будут потери данных записываемых в буфер
* в буфер пишутся чанки видео и тут же параллельным скриптом с удалением переносятся на hdd, таким образом буфер будет постоянно пустой, но во время просмотра видео из hdd архива, копирование должно приостанавливаться/замедляться (разруливать приоритетами ОС), во время просмотра роликов из архива, буфер начнет заполняться, когда он закончится, либо нужно останавливать просмотр либо будут потери видео

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

raid0 дополнительную нагрузку на процессор не дает, и позволит примерно в sqrt(n) раз ускорить работу итогового устройства (n - количество дисков, и да, хоть на синтетических тестах линейная скорость возрастает n-крат, случайный доступ при просмотре роликов убьет весь этот бонус)

raid5-6 может добавить требований к процессору, но незначительно, один 100мбит поток примерно кушает половину нагрузки ядра средней современной машинки

raid0 - - mirror нагрузки не создает, т.е. если внезапно скорости процессора будет не хватать, можно будет за счет уменьшения эффективности хранения освободить чуток процессора от raid5

Теперь самое главное, с вашей нагрузкой по сети выходите за границы гигабита (порядка 2.5гбит), что заметно повышает стоимость железа (10гбит сетевые карты кратно выше в цене как на стороне сервера так и вся сетевая инфраструктура), поэтому вполне возможно что 2-3 независимых сервера, даже размещенных в разных помещениях (очень может оптимизировать физически сеть) позволят оптимизировать итоговую стоимость решения, по сравнению с очень мощным, размещенным в одном месте.

Comments

[Art_Sh82]

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

[rPman]

я подробно описал
если не объединять диски в raid то математика дубовая - считаешь сколько потоков обработает диск, набиваешь дисками сервер сколько можешь, профит

1гбит сетевая карта сумеет без особых проблем где то 700мбит потоков обслужить(чистый гигабит возможен только на синтетике плюс дешевые карты не умеют полностью утилизировать), делим на 2.5мбит получаем 280 камер, при использовании cow файловой системы, write only диск hdd способен записывать 100мбайт/сек (800мбит) (в этом случае нельзя читать диск, только писать, т.е. вариант с ssd/hdd кешем, позволяющим буферизировать записи пока идет просмотр ролика из архива), без такого тюнинга hdd дис потянет в 10 раз меньше.

дели и считай сколько дисков минимум понадобится чтобы утилизировать поток, добавляй дисков на обслуживание выбранного raid (один raid массив кстати при подсчете скорости считать как единый диск), профит

Т.е. если лениво, то нужно будет пара серверов суммарно примерно 10 дисков чтобы обработать поток, если же тюнить то хватит по 1-2 диска hdd и по 1 ssd для буфера

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

upd. когда я смотрю на цены на готовые сервера видеонаблюдений, мне смешно, сервер с ценой в 200к тянет 16 потоков О_о

но как пример снизу в худшем надеюсь понятно да?

[Art_Sh82]

Хорошо разьясняешь))) Спасибо. У меня специализация - железячник, как сделать камеру знаю, а вот что бы написать ТЗ на сервак, знаний не хватает.
Подводя итог: 2*HDD в рейд + буферный SSD - поток записи до 800мбит + можно смотреть ролики. Экзотика не нужна и рассчитываем 1 сервак на 800мбит -> 280 камер.
Хотим добавить еще камер - ставим такой же сервак. Через сеть обьединяем их, что бы получить доступ к архиву с обоих хранилищь.
Верно?

[rPman]

2 hdd это 2 рейд массива (например raid1 по 2 диска итого 4) если без резервирования то да по 2 диска, ssd нужен не дешевый, потому как копеечные не умеют больше 50мб запись (после полной записи всего диска, это видно сразу когда в кристалмарк ставишь побольше файл, под размер всего диска к примеру) но их тоже много можно пихать

добавь нагрузку процессора на

Протокол собственный.

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

я заговорился только про nas под данные

советую протестировать вашу логику на кошках, в слепую не делать все

[Art_Sh82]

Кстати, а что скажешь насчет подключения сервака по беспроводке? Используя хаб LTE модемов. С аппаратной точки зрения никаких проблем нет, но есть вопросы, как их объеденить в единую сеть.

[rPman]

Пару гигабит по беспроводной сети? вопросы к вашему провайдеру такие задавай

Я не понял, а хранить не надо данные? если не надо хранить нафиг вам вообще hdd, хватит ssd на нужный временной период! вся проблема - просмотр роликов во время их записи, они роняют скорость работы с hdd дисками в разы (почему я и говорю про буфер).

p.s. только что запустил для теста на мега медленный сервер (2014 года целерон на mitx плате) с самыми дешевыми 3тб тошиба дисками, запись в 70 потоков синтетика, 33мбайта/сек, нагрузка на проц 80% samba, диск 16% , md0_raid5 - 5% (raid5 Из 5 дисков, оно легко дает 200мбайт/сек)

[Art_Sh82]

Хранилище это само собой разумееется. Но ксати, вы подали одну интресную идею, насчет использования только SSD. Кстати, насчет проца, я так понимаю, нет смысла использовать специализированную серверную мать или серверные процы все же лучше?

[rPman]

Серверное железо дает выше надежность (за счет хотя бы ecc памяти) и предсказуемость (что не будут танцы с бубном из-за экзотической конфигурации десктопного железа просто при настройке)... если готовы за это переплачивать х3 стоимость, почему нет

Специализированное железо это значит возможность запустить готовый специализированный софт или добавить специализированные компоненты, если этого нет - зачем переплачивать за чужой вендорлок?

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

p.s. лично я бы брал десктопное железо на базе ryzen 5 или 7 и собирал бы решение самостоятельно (в вашем случае нанять разработчика/многорукого шиву, а точнее иметь такого в штате), вплоть до кодовой базы

[Art_Sh82]

Привет. Я так понимаю, оптимально, мне нужна мать с парочкой m2 интерфейсов на борту и raid контроллером? Можешь какие то можели посоветовать, если ориентируешься в этой сфере?

[Art_Sh82]

Или в качестве буферов можно использовать обычные SATA SSD винты?

[rPman]

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

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

ssd диск выбирать по скорости в худшем (тестировать с БОЛЬШИМ объемом тест файла, желательно после полной записи на весь объем диска, так как в этом случае скорость должна кратно упасть от 'паспортных'), так как работая буфером видеоданные будут писаться и одновременно такой же объем считываться с него, т.е. двойная нагрузка (но запись обычно больше грузит устройство), интерфейс подключения не важен, так как по вашей задаче вы не упираетесь в лимиты даже SATA.

[Art_Sh82]

Т.е. мне хватит обычной мамки. Буферный SSD я могу терабайтник поставить, его с головой хватит.

[rPman]

совет, вместо одного диска большого, два по меньше, так как дешевые ssd обычно не шибко быстрые

[mordo445]

Art_Sh82, зная множество серверов для видеонаблюдения могу сказать с уверенностью: буферный SSD никем не используется. Используются RAID контроллеры, в т.ч. с RAM кэшем (на батарейке), объединение дисков в массив RAID 5 или 6. Если сервер планируется с нагрузкой в 300 камер, то будьте готовы, пользователь конечник по своему понимает количество камер -- он ждет, что 300 камер запросто будут кодироваться 8..16 Мбит, и ждет что всё будет работать. И просто по опыту, на Win стабильными были ВМС с серверами до 48 потоков, более всегда пляска с битрейтом и бубном, не зависимо от того, чье железо и софт, секурос, макроскоп, кс-протект и прочая ВМС братия. Возможно сказывается применение всеми перечисленными не самых производительных RAID контроллеров и дисков SATA, с файловой системой NTFS. Мнение от наладчика.

[rPman]

Аппаратный raid с ram НЕ ПОМОЖЕТ от слова никак, а вот гемороя создаст прилично.

С некоторым красноглазием можно потюнить параметр read-ahead (по больше от дефолтного, в мегабайтах или десятках), но тогда не рекомендуется использовать cow файловые системы, можно сделать свой механизм предварительного сохранения данных большими блоками, готовых решений я не видел, но и не искал серьезно, алгоритм там простой - необходимо увеличить минимальный размер данных, который будет считываться и записываться на диск, с принудительной буферизацией (пока не наберется этот блок данных, на диск не записывать), и для 300 потоков это очень большой объем.

ssd буфер это компромисcное решение, позволит дешево (без заметного кодинга) решить проблему, ограничив срок просмотра архива часами (а кому надо больше?)

Если решать в лоб, скорость работы диска падает на порядок, поэтому такие системы тянут от силы пару десятков потоков на hdd. Судя по прайс листам, готовые системы именно такие. Т.е. если по расчетам на срок хранения нужны несколько десятков дисков, то почему нет