LINUX.ORG.RU
ФорумTalks

RAID-0 на большом числе HDD (6+)

 


2

2

Не критично, не необходимо, но порой очень не хватает капец быстрого и емкого (5+ Тб) массива. С хоть какими-то иопсами.
Соотношение «реально нужно» к «подрочить» - 35\75.

Пока есть 3х1тб RAID-0 из ST1000VX000. Винты крутые, быстрые, на одной пластине, тихие, не греются. Кто-то на лоре советовал - респект ему.

Но этого объема не всегда хватает. И иопсов хочется больше. Трансформация файла в несколько тб в другую геометрическую проекцию - это ад и израиль. И 96гб рамы не спасают.

Пока вижу два варианта:
Или докупить 2-3 самых дешевых ссд по терабайту (типа какого https://www.computeruniverse.ru/products/90638357/ocz-trion-150.asp) или добить число винтов до 6-8 шт (по свободным слотам).

ssd 512гб nvme под систему и наиболее частый кейс работы с сырьем - уже есть. Хватает, это покрывает большинство реальных регулярных практических задач.

Вариант с винтами:
++1. Винты, даже такие мелкие (не оптимальная цена за 1тб) - это более универсальный инструмент (закончив этот изврат их можно использовать полезнее).
++2. Объема 8х1тб мне точно хватит даже под будущие замороченные проекты.
--3. Таки это не ссд. Но я не настолько освоил производство денег, чтоб покупать терабайты и терабайты ссд.
--4. Экстремально дешевые ссд могут оказаться совсем говном в плане предсказуемости и стибильности.

Вариант с ссд:
++1. Таки +1-2тб ссд (тоже в нулевке) - было круто.
--2. Без нулевки на винтах не обойтись. Ибо место. Будет три уровня хранения данных. Будет гемор «не учел объем, не влезло на третий день записи»
--3. Цена.

Пока склоняюсь к докупке винтов.
У кого-нибудь есть мысли на счет это дибилизма?

PS
Сохранность данных на нулевом рейде не критична! Может рассыпаться по расписанию раз в неделю. Плевать.

PPS
Кэширование и сжатие рамы не рассматривается. Ведь это потребует целого исследования, интерпретации результатов и т.п. Смысла нет.



Последнее исправление: dk- (всего исправлений: 2)

Можно выделить SSD под кеш, чтобы наиболее часто используемые данные читались с него (можно, ЕМНИП, сделать и чтобы писались сначала туда, а потом уже на HDD). Если винда так умеет.

И 96гб рамы не спасают

А винде можно её сжимать?

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

Нет. Кэши, сжатие рамы - все исключено полностью. Куда более меня шарящие в этом люди отвергли такие идеи на корню.
Да «кэширование» терабайтов это тот еще прикол.

dk-
() автор топика
Ответ на: комментарий от dk-

Ну тогда фиг знает. Если у тебя там объёмы такие, что один файл на SSD даже не влезет. Я бы тоже взял винты.

sudopacman ★★★★★
()

болен насущные вопросы это есть ли у тебя место для 8 дисков в корпусе, есть ли провода (питание и сата для 8 дискоа и т. д.

futurama ★★★★★
()
Ответ на: комментарий от futurama

Это вообще не вопросы. Места, портов, питания, вентиляции - заглаза.
У меня сейчас ссд жрет 2 порта, и еще 8 свободны.

dk-
() автор топика
Ответ на: комментарий от dk-

Тогда бери hdd че? ssd еще не майнлайн, хотя и хочет.

futurama ★★★★★
()

Всё зависит от профиля нагрузки, но в целом SSD хотя бы на десятую часть объёма винтов + flashcache/bcache дают серьёзный прирост производительности, при гуманной стоимости

selivan ★★★
()
Ответ на: комментарий от dk-

Какая лютая жесть у вас твориться. А что за нагрузки такие, если не секрет, раз настолько важна и скорость записи больших данных и иопсы ?

DawnCaster ★★
()
Ответ на: комментарий от selivan

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

DawnCaster ★★
()
Ответ на: комментарий от selivan

Увы и ах, на венде нет flashcache/bcache, а интеловая проприетарная утиль для кэширования может использовать AFAIK максимум 64GB SSD.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Учитывая «качество» фейковых raid'ов от интеля, к данной приблуде доверия ещё меньше.

DawnCaster ★★
()
Ответ на: комментарий от dk-

Объединение в RAID 0 более 4х SSD не даёт пропорционального прироста скорости ввиду не синхронности работы контроллеров SSD.

Какие задачи у твоего RAID массива? Фото, видео-редактирование, порно, торренты, компиляция?

rezedent12 ☆☆☆
()

ну началось.
а сколько у тя портов?
если не ошибаюсь, на х99 = 8сата.
докупи еще дисков.

но, вообще, надо смотреть уже на более другие решения.

Deleted
()
Ответ на: комментарий от Deleted

8 свободных портов есть.

Да какие другие решения - ссд терабайтами - дорого. И в избыточных массивах особой нужды нет. Да и цена контроллеров же.

Линукс не рассматривается в принципе, ибо софт.

Да и софт все еще перепиливают иногда. Вот даже если сейчас какое хитрое кэширование поможет, то потом может и навредить. Плюс эта мега задача этим софтом решает редко очень. Ее там никто особо и не оптмизирует. Ибо 99% задач куда проще и насущней.

dk-
() автор топика
Ответ на: комментарий от dk-

ну вот на рейд контроллер я и намекал.

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

Deleted
()
Ответ на: комментарий от dk-

А как насчёт такого фантастического варианта - собрать отдельный СХД на линуксе и поднять там ISCSI ? Делать всё это на 10 гигабитном езернете, (хотя и гигабитный при правильной организации спокойно выдаёт по 20000 иопсов ~100 мегабайт в секунду на запись или чтение).

А с клиентской стороны - там хоть венда хоть что. Главное чтобы умела монтировать диски по ISCSI.

Идея выглядит каким-то диким оверкиллом, я согласен, но у вас задачи тоже какие-то не слишком простые: требования по производительности огромные, масштабируется всё плохо. Тут уже действительно впору думать о какой-то принципиально другой организации системы хранения.

DawnCaster ★★
()
Ответ на: комментарий от dk-

Линукс не рассматривается в принципе, ибо софт.

И что, мы же инженеры, per recrum ad astra. Linux + bcache + KVM, пробросить блочное устройство целиком + сверху винда.

selivan ★★★
()
Ответ на: комментарий от selivan

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

dk-
() автор топика
Ответ на: комментарий от sudopacman

Да и проброс видяшки и USB в qemu-kvm работает далеко не идеально. А если просто qemu-kvm виртуалку использовать - для задач хоть немного связанных с 3D и обработкой изображений это уже не подходит.

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

проброс видяшки и USB в qemu-kvm

Я предполагал скорее что-то вроде сервера с файлопомойкой или мсскуэль. Сейчас посмотрел внимательнее «Трансформация файла в несколько тб» - значит, не угадал.

selivan ★★★
()
Последнее исправление: selivan (всего исправлений: 1)
Ответ на: комментарий от selivan

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

DawnCaster ★★
()
Ответ на: комментарий от dk-

Ну, если денег на SSD не дают, а делать кровь из носа надо, то возможно придётся изображать компетентного специалиста. Я не сказал, что этот вариант простой и лёгкий.

selivan ★★★
()
Ответ на: комментарий от selivan

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

Натыкался в инете на интересный материал по теме 4-6-8 ссд в рейд-0 - вот там косяков нашли приличное количество. А про винты подобное не нагуглил.

А денег мне самому себе выдавать. И это, экономически, игрушка, а не доходная статья. Так что сильно не хочу тратиться.

Еще я пробовал в нулевой массив добавлять другого типа винты. Типа к этим 1тб-1пластина добавлять винты на 3тб. Но получалась какая-то странная рандомная деградация. На разных винтах проседания скростей\доступа были. Сделал для себя колхозный вывод - только идентичные винт ы.

dk-
() автор топика
Ответ на: комментарий от DawnCaster

Linux на железе, в нём собран нулевой нейд из дисков, поверх этого рейда и SSD с помощью bcache/flashcache собрано быстрое блочное устройство. В KVM запущена винда, ей это устройство проброшено напрямую. На отладку такой конструкции может уйти много сил и времени, но по идее реализуемо.

selivan ★★★
()
Ответ на: комментарий от selivan

bcache/flashcache

Не зная и не тестируя работу целевого приложения, это совершенно бесполезно. Может даже дикий регресс устроить. Я же говорю - там трансформация терабайтов в терабайты. Как именно она проходит - неизвестно. Но по косвенным признакам - тупо в один поток и через кучу создаваемых временных файлов. Она там сотни тысяч файлов создает размерами от 4М до 512М. И постоянно чем-то шуршит с ними.

dk-
() автор топика
Ответ на: комментарий от dk-

сжатие рамы исключено

Ну, если у тебя все ядра процессора не загружены на 146%, то потеря производительности от сжатия, кмк, должна быть меньше потери производительности от того, что система начнёт свопиться.

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

Может. Но вот «виртуальной памяти» (с т.з. системы) оно жрет где-то +30% к реальной раме.

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

dk-
() автор топика
Ответ на: комментарий от selivan

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

Насколько я понял, у TC помимо того что венда, ещё и софт достаточно специфический, скорее всего что-то что требует работу с графикой и видеоадаптером - такие штуки крайне плохо работают в виртуальных машинах, говорю как неудавшийся геймдев (чего я не перепробывал уже на программистском поприще). Поэтому я и предположил что ему-бы стоило пробросить в виртуальную машину с вендой ещё и видяшку.

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

Кстати да. Первый файл (сшитое изображение) - считает именно на видеокарте. ОпенЦЛ. А вот нарезка и конвертация уже потом идет процессором обычным.

dk-
() автор топика
Ответ на: комментарий от sudopacman

Да не, я кое как обходился SSH'ем )) Но да, для нормальной работы - очень-бы желательно. Кое как можно обойтись дешевым китайским HDMI\DVI - квм свитчем работающим только для видео - оно стоит на али всего около 10 баксов.

DawnCaster ★★
()
Ответ на: комментарий от dk-

Может серьезно подумаете о внешнем СХД ? На стороне СХД можно будет без каких-либо изменений для клиентской венды любой фаршмак творить с организацией стораджа.

Так или иначе вам придётся всё что вы делаете тестировать, с таким требованиями.

Для начала можно собрать простенький «бичевский» СХД из какой-нибудь старой материнки - гигабитная сеть сейчас должна быть везде, главное рамы туда напихать хотя-бы гигов 16. Попробуете накатить туда линукс, или даже BSD. Поиграетесь во всю с bcacbe или даже с zfs - для начала, убедитесь подходит-ли вся эта шняга для вашего конкретного случая по IOPS'ам (гигабитная сеть у меня вытягивает от 20000 до 30000 иопсов из клиентской венды с установленным флажком «отключить очистку буфера кэша записей windows» (замерял с помощью hdtune). всё это при использовании и правильной настройке istgt на сервере)

А потом, если окажется что система не страдает от падения иопсов при работе вашей софтины - то соберёте уже нормальный СХД с 10 гигабитной сетью (уж всяко должно хватить) - стоимость сетевушек и всего необходимого вполне себе подъемная (уж всяко дешевле терабайтных SSD).

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

Про графику меня уже поправили, я сначала не обратил внимание.

selivan ★★★
()
Ответ на: комментарий от DawnCaster

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

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

Вполне. Эту функцию в моём варианте и выполняет HDMI-свитч.

DawnCaster ★★
()
Ответ на: комментарий от i-rinat

Но нет навыка и знаний на такой опыт. И нет желания кому-то за это платить. В конце концов можно просто тупо долго ждать. Задача то не каждодневная.

dk-
() автор топика
Ответ на: комментарий от dk-

Блин, теперь я тоже себе такой хочу.

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

DawnCaster ★★
()
Ответ на: комментарий от dk-

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

Главное, чтобы ОЗУ можно было много напихать (для zfs с его кешированием, без которого всё встаёт колом, очень актуально), и что-бы портов под диски было много, а в SSD кеш пихаем для начала любой копеечный SSD.

Такой вариант хорош, если у вас уже накопилось дофига всякого железа разной степени древности.

Есть ещё интересный вариант, но это совсем из раздела «очумелые ручки». Суть такова: тут предлагали делать сторадж на линуксе, а венду пускать на виртуалке. А что если сделать наоборот - у вас вот ваш комп с вендой. В него вы втыкаете все ваши 8 HDD дисков и ещё 1 SSD под кеш. Далее, ставите какое-нибудь ПО для виртуализации: виртуал-бокс или вмварю - там должна быть возможность проброса целых дисков в виртуальную машину (во всяком случае, в линукс-версии это точно было, сам использовал в виртуал-боксе). Создаете там виртуальную машину под «виртуальный» СХД - даёте ей гигов 16 озу (у вас ведь и так 96?), пару ядер процессора, и напрямую отдаёте ей все ваши диски и SSD. А там уже внутри виртуальной машины делаете весь фаршмак со сторажем и кешем - а в вашу хостовую венду - это дело пробрасывается через iscsi и виртуальную сеть (virtio гарантированно выдаст не менее 2-4 гигабит).

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

СХД с гигабитной сетью

Это не схд. Это говно!
Один десктопный винт уже сильно быстрее такой сети. По всем параметрам.

dk-
() автор топика
Ответ на: комментарий от dk-

И да и нет. Я игровой комп держу на таком бич-СХД поднятом на основной рабочей машине (просто обычный юзерспейсны istgt и dnsmaq как tftp сервер, и гигабитный кабель напрямую. пожалел деньги купить для игрового компа SSD). Так вот - гигабитная сеть с MTU 6000 (реалтековская сетевуха на игровом компе не даёт установить больше), держит 20-30 тысяч iops'ов (запросы по 4кб) и стабильные 100 мегабайт в секунду на запись, когда на венде отключён описанный выше флажок в настройке дискового устройства. Эти параметры она держит «на горячем» кеше, когда все сервисные структкры NTFS (и MFT) уже закешированы в озу хоста - в настоящем СХД за подобные вещи отвечает SSD кеш как раз таки. Весь этот велосипед - это хуже чем SSD (90 тысяч иопсов и выше), но намного лучше чем 1 HDD (150-300 иопсов).

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

Все это фигня :)
У меня сеть годится только для «скинуть с флешки на удаленное хранилище копию сырья» и «рабочий набор файлов забэкапить на удаленное хранилище» (в роли хранилки микросервер с 10м рейдом). Все. И это у меня ни баз данных ни мелких файлов нет.

dk-
() автор топика
Ответ на: комментарий от dk-

В общем, я не знаю что ещё посоветовать. Остаётся только посочувствовать - венда в плане организации любого нестандартного стоража убога на 100%.

DawnCaster ★★
()
Ответ на: комментарий от DawnCaster

Линукс тут не поможет. Кэшировать неизвестно что, неизвестной какой структуры, неизвестно каким образом записываемого\редактируеого - то же бред.

Нет структуры данных\потока - нет решения.

dk-
() автор топика
Ответ на: комментарий от dk-

Пусть создаёт временные файлы на отдельном SSD. Так можно?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от dk-

Линукс не рассматривается в принципе, ибо софт.

тогда это офтопик

crypt ★★★★★
()
Ответ на: комментарий от dk-

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

На винде? О_О

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.