Хранилище под видеонаблюдение. HELP

[1dimon1]

Росли вместе с "Форпост" с восьми камер и одного HDD до 100 камер и четырнадцати HDD в дисковой полке на LSI MegaRAID SAS2108. Всё без избыточности - нужды в ней не было и нет. Каждый диск в JBOD.  На каждый HDD писал свой "стример" - некий программный модуль. В итоге стали появляться ситуации, когда 30-40 камер пишут одним стримером на один HDD, в результате чего из-за высокой на нагрузки по окончанию места на HDD переключения не происходит. Специалистами из "Форпост" было предложено либо привязать строго камеры к стримерам, но это неким криптом, т.е. "на коленках", либо создать из всех дисков один (или не один) большой RAID. Судя по всему "балансировки" нагрузки между стримерами у них пока что не существует.

Вопрос: как лучше поступить в рамках имеющихся ресурсов? Интересуют мнения многоуважаемых всех.

[jffulcrum]

Ничего толкового вы с таким колхозным решением не сделаете. RAID-0 - один диск улетел и привет, RAID-10 - половина емкости вдаль, RAID-5/6 - на запись будет больно, да и диски у вас скорее всего не RAID-ориентированные. Размазывать софтом, типа полку к серверу с FreeBSD, и все диски как есть засунуть на сервере в ZFS и в RAID-Z1 или Z2, но для целей видеонаблюдения реализаций не встречал, как оно себя на 100 потоках поведет - вопрос, вопрос. Не говоря о прелестях саппорта умирающей системы.

[vurd]

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

[naves]

1 hour ago, vurd said:

базе собственной фс, который размазывает по хранилищу все камеры и собирает с них же по кусочкам

Так это же аналог нулевого рейда, 1 диск сдох и привет всему архиву.

Если софт сам не умеет размазывать, то остаются только скрипты, переопределяющие стримеры, или перемещение записанных файлов с изменением путей к ним в БД/индексе.

[alibek]

9 минут назад, naves сказал:

Так это же аналог нулевого рейда

Вроде бы ближе к JBOD, чем к RAID-0.

[straus]

1 час назад, alibek сказал:

Вроде бы ближе к JBOD, чем к RAID-0.

Между JBOD (Link) и RAID0 (Stripe) разница небольшая. JBOD прицепляет один диск за другим, а RAID0 чередует сектора с дисков, позволяя дискам работать параллельно. По ёмкости те же яйца, только в профиль, единственное полосатик выигрывает по производительности. По отказоустойчивости - теоретически с JBOD можно что-то вытянуть, на практике - хрен вам.
 

[Shurhenchik]

4 часа назад, naves сказал:

Так это же аналог нулевого рейда, 1 диск сдох и привет всему архиву

Вообще-то, в случае с видео это не совсем так.

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

Правда хбз как и реализовано ли это в Форпосте

 

6 часов назад, jffulcrum сказал:

RAID-5/6 - на запись будет больно

Внешний датасторадж с настоящим RAID-контроллером а не софтовой реализацией избавит от боли... и от толстой пачки денег :)

 

[vurd]

9 часов назад, naves сказал:

Так это же аналог нулевого рейда, 1 диск сдох и привет всему архиву.

Если софт сам не умеет размазывать, то остаются только скрипты, переопределяющие стримеры, или перемещение записанных файлов с изменением путей к ним в БД/индексе.

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

[Shurhenchik]

1 час назад, vurd сказал:

Я же говорю, это их ноухау со своей же фс. Очень убедительно рассказывали

Ога-ога, прямо-таки ноухау Форпоста???

 

[alibek]

Сама идея разумеется не нова.

А ее реализация в виде своей ФС вполне себе ноухау.

Я тоже эти рассказы слышал, но все же на мой взгляд плюсы не перекрывают минусов.

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

[Shurhenchik]

1 час назад, alibek сказал:

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

Поддерживаю. 

[1dimon1]

5 hours ago, alibek said:

Сама идея разумеется не нова.

А ее реализация в виде своей ФС вполне себе ноухау.

Я тоже эти рассказы слышал, но все же на мой взгляд плюсы не перекрывают минусов.

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

А вот "оптимизированная дисковая конфигурация или хороший SAN" это что? Пальцем можете тыкнуть?

[alibek]

Если пальцем, то NetApp FAS2750 или Fujitsu DX60 с FC эти 100 камер легко утилизируют.

 

[naves]

6 hours ago, Shurhenchik said:

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

Это разве не взаимоисключающие параграфы?

Я имею в виду, когда хранилка отдает больше 20 дисков как единый Storage Pool, а не RAID group.

Чтобы не использовалась "проприетарная реализация" хранилка должна отдавать свои N дисков как есть, и хост уже поверх них использует какой-нибудь ZFS RAID-Z

Edited December 26, 2019 by naves

[LostSoul]

7 часов назад, naves сказал:

Это разве не взаимоисключающие параграфы?

 

ну форматы некоторых хранилок достаточно открыты и изучены и имеют софтовую реализацию в ядре линукс и различных recovery тулзах

в отличии от узкоспециализированного решения от форпост.

хотя,например,  китайская да***вская dhfs в некоторых тулзах таки есть уже

 

[Shurhenchik]

6 часов назад, naves сказал:

и хост уже поверх них использует какой-нибудь ZFS RAID-Z

Лично я - за внешнюю СХД с каким-нибудь надлежащим RAID.

Решение отработанное, надежное, эффективное.

И лучше я буду использовать аппаратный контроллер а не всякие софтовые ухищрения.

 

[LostSoul]

6 часов назад, Shurhenchik сказал:

И лучше я буду использовать аппаратный контроллер а не всякие софтовые ухищрения.

 

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

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

 

Его хотя бы понятно как чинить, когда рассыпется.  А не "обратитесь на платную поддержку в рабочее время".

 

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

 

Если бюджеты ограничены и нужно вылететь "на честном слове и одном крыле"  - большая глупость использовать аппаратный контроллер.

 

[alibek]

5 минут назад, LostSoul сказал:

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

Вы поинтересуйтесь на досуге, а не транслируйте слухи.

К примеру у нас используется NetApp E2700. Это по большому счету уже устаревшее решение где-то семилетней давности и в следующем году у него EOL.

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

[Shurhenchik]

10 минут назад, LostSoul сказал:

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

Вот только работает это решение не на твоем процессоре, которому еще всякой хрени надо кучу делать, а на своем собственном.

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

 

12 минут назад, LostSoul сказал:

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

Если хочешь проблем - да, используй софтовое решение от линукса.

 

13 минут назад, LostSoul сказал:

Его хотя бы понятно как чинить, когда рассыпется.

Резервные и архивные копии не слыхали?

[LostSoul]

4 минуты назад, alibek сказал:

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

как вы будете чинить это решение,  если оно внезапно сгорит? или как то еще непредсказуемо и внезапно кончится?

 

[Shurhenchik]

14 минут назад, LostSoul сказал:

Когда на складе всегда лежит в коробке такой же точно новый сервер в ЗИП

Кому надо - бери карепак и не нужен тебе такой же сервер, пусть вендор голову себе греет

[LostSoul]

1 минуту назад, Shurhenchik сказал:

Если хочешь проблем - да, используй софтовое решение от линукса.

 

Мой опыт за 20+ лет  -  все проблемы имели крутые админы, использовавшие аппаратный рейд.   После того как он рассыпался, и никто не знает ( включая платную поддержку ) , как теперь шалтая-болтая собрать.

Пользователи linux рейдов живут скучно,  никаких приключений на жопу. Оно просто работает и все.  И если сломалось то в гугле сразу 100500 ссылок как все правильно собрать, с подробным описанием всех подводных камней.

 

[Shurhenchik]

15 минут назад, LostSoul сказал:

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

Если нет архивации - то это вопрос времени когда все завалится

[LostSoul]

3 минуты назад, Shurhenchik сказал:

Резервные и архивные копии не слыхали?

Я написал выше - хорошо быть богатым и здоровым.

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

 

[Shurhenchik]

16 минут назад, LostSoul сказал:

Если бюджеты ограничены и нужно вылететь "на честном слове и одном крыле"  - большая глупость использовать аппаратный контроллер.

Если решение не ответственное, то можно хоть из домашнего компа датасторадж сделать  и щеки надувать что дешево.