Протокол собственный
все зависит от его реализации
Кодирование потока надеюсь у вас специализированные железки или 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 независимых сервера, даже размещенных в разных помещениях (очень может оптимизировать физически сеть) позволят оптимизировать итоговую стоимость решения, по сравнению с очень мощным, размещенным в одном месте.
