RAID0 медленнее чем 1 диск

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

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

Если кратко, SSD - это по сути флеш память.

У неё есть ресурс циклов перезаписи. Поэтому контроллер делает выравнивание износа ячеек. Это первое.

Второе, при записи в память контроллер оперирует блоками в несколько мегабайт. Условно, допустим 4 Мб. Когда ты записываешь на SSD диск 4 Кб данных, контроллер делает следующее:

• Считывает блок размером в 4 Мб, в котором находится сектор, в который ты хочешь записать данные;
• Заменяет в памяти в 4Мб нужный фрагмент данных;
• Определяет свободный блок в 4Мб с наименьшим износом;
• Записывает в него 4 Мб;
• Изменяет схему сопоставления флеш памяти и номеров секторов.

В случае наличия внутреннего кэша контроллер в начале упорядочивает поступившие на запись данные, чтобы он мог записать их во флеш память за раз, порциями по 4Мб в наименее изношенные области памяти.

Не покупай дешёвых SSD, покупай серверные, у них и очередь записи нормальная и нормальная работа контроллера с указанной в 7 абзаце схемой.

А у тебя слишком дешёвый, не подходящий для твоих нужд.

Я недавно для одного филиала собирал RAID1 из пары crucial MX500 2Tb. Тупило несчадно, высокий iowait при, например, миграции виртуалки с этого массива приводил к полной неработоспособности всех других VM. Собирал зеркало как в ZFS, так и, теста ради, в mdadm. Результат был одинаков. Т.к. не было времени особо разбираться с корнем проблемы решил простой заменой дисков на Intel D3-S4620.

Возможно и твоя причина – попытка использовать дектопные диски в рейде.

Консумерские в рейде херово работают, у нас давно еще была попытка из консумерских самсунгов (емнип, 850 про) собирать в составе блейдов Dell PowerEdge, похожий эффект был, хотя и не такой ярковыраженный. В итоге вместо них были взяты тошибы и интелы DC серий.

Уже наверно раз десятый повторяю: не используйте raid0 если у вас для этого нет веских обоснований (если они будут то вопросы задавать уже не придётся). Он двукратно портит надёжность и почти не даёт прироста скорости. Хочешь (почти) удвоить скорость с помощью двух дисков - раскидай по ним файлы на отдельных точках монтирования так чтоб нагрузка разделилась примерно поровну.

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

Золотые слова!

В топку raid контроллеры, даже самые дорогие. Нет в них сейчас особого смысла. Лучше данные по дискам раскидывать, тогда выйдет реальное увеличение скорости даже на не серверных дисках.

Я не так давно заморачивался с рейдами на дорогущем контроллере с батарейкой (не помню название, но дорогущий кетаец). Диски были HDD серверные, снова не помню, что за зверье, но тоже дорогие.

Результат меня опечалил. RAID0 оказался медленнее сингл диска! RAID6 ноздря в ноздрю с RAID0.

RAID должен был использоваться под данные Postgresql.

После моих мытарств было решено просто раскидать базы по разным дискам без красноглазия с RAID.

Я писал исключительно про raid0, и не важно контроллер или нет. Все остальные raid-ы делаются в первую очередь для увеличения надёжности за счёт избыточности (что эта аббревиатура и означает), и эту функцию они выполняют хорошо.

Я писал исключительно про raid0, и не важно контроллер или нет. Все остальные raid-ы делаются в первую очередь для увеличения надёжности за счёт избыточности (что эта аббревиатура и означает), и эту функцию они выполняют хорошо.

Увеличение надежности лучше достигать избыточным бэкапом.

Это, однозначно, надежнее!

Бывает выгорает сам RAID контроллер и… Нужно иметь прозапас еще один такой же, в противном случае RAID может и не собраться.

А что бы лежал и пылился контроллер ценой в несколько штук баксов… Не рационально как-то.

Можно, конечно собирать софтовый RAID, но… Стоит ли овчинка выделки?

Спасибо за комменты. итак, был у знакомого. Взяли для тестов micron 5400 max, intel d3 s4520, adata su650. Все по 2 диска. 5400 max raid0 - rand rw 9.2-11mb/s Intel d3 - 9 Adata su650 - 17

Ну я в ступоре. Диск ценой в 50$ быстрее чем диски ценой в 300$…

Раскидать данные по дискам то можно, согласен, в моем случае можно взять тот же мх500 2Тб и не морочить голову (так оно наверное и будет :)

Но тут уже пошел спортивный интерес… Как результат, прирост iops есть при использовании 6+ дисков. ДАЖЕ на 5 дисках не дотянуло по скорости до одного.

Ну и я замечу, никто не обратил внимание на то, что я писал про виртуализацию. Для виртуалок hw raid - просто жесть. Он не рапортует, что занят, а просто молчит.

И как итог у меня вознткает вопрос о смысле raid (кроме избыточных, да и с теми вопрос)… а если мы говорим о raid10, raid5, 6 и тд - скажите у кого на практике дох диск и делали хот свап? Мне 1 раз пришлось. Итог - пока hardware raid пересобрал массив так тупило безбожно, что работать нельзя было вовсе. А по времени заняло раза в 3 дольше чем поднялись бы бекапы.

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

Ну я в ступоре. Диск ценой в 50$ быстрее чем диски ценой в 300$…

У нас ситуация немного иная, но тоже показательная.

На машине с ssd крутится postgresql, в который сплошным потоком льются данные.

Начали проверять и оказывется, что часть данных просто потерялась!

Перемонтировали и теперь файлы БД лежат на HDD. О чудо! Данные перестали теряться. А HDD на 5400 оборотов.

К сожалению я не могу привести всю статистику, т.к. проблема возникла на объекте, а меня на нем не было. Я не знаю какие там стоят ssd и точные модели хардов. Знаю что харды серверные на 5400 sata2.

Итог - пока hardware raid пересобрал массив так тупило безбожно, что работать нельзя было вовсе.

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

Т.е. RAID5 лучше вообще не использовать. RAID6, RAID1 или RAID10…

Может проще раскидать виртуалки по дискам и забить на RAID? А что бы не бояться потери данных, то делать регулярные бэкапы на большой HDD.

Бекапы льются 2р/день.

Из всего вышеперечисленного я вижу что раскидать по дискам - самый большой еффект в скорости. Кстати, занимаюсь тестом на 2х6Тб wd blue hdd. Там еффект на лицо, действительно iops даже более чем в 2 раза выше.

Взяли для тестов micron 5400 max, intel d3 s4520, adata su650. Все по 2 диска. 5400 max raid0 - rand rw 9.2-11mb/s Intel d3 - 9 Adata su650 - 17

Хороший тест. Явно прослеживается проблема или в том как ты собираешь рейды или в методологии тестирования или в железе сервера (контроллер же переключении в jbod?)

Рейды собираешь программно? Из ОП поста как-то это не явно

Рейды с чередованием на NVMe говно.

Рейды (вообще любые) на домашних дисках - говно.

Выкинуть и забыть. Причина:

У рейдов есть метаданные.

На каждом мембере массива есть т.н. суперблок который обновляется каждую запись (долго объяснять почему - но это так). Поэтому при мелкой записи блоком 4К у тебя в два раза больше операций записи. А еще этот суперблок обновляется с синком (сбросом внутреннего кэша диска) - что еще сильней замедляет работу. Главное отличие «энтерпрайзных» от «консамерских» SSD это как раз поведение под синком.

Поэтому если нужен больший объем - делай linear и забудь про чередование.

Нужна непрерывность - делай зеркало на энтерпрайзных дисках.

в системе накатил lvm thin

Но виноват конечно raid0

На каждом мембере массива есть т.н. суперблок который обновляется каждую запись (долго объяснять почему - но это так).

А мне было бы очень интересно послушать что это за «суперблок» такой, и почему в RAID0 он апдейтится на всех дисках даже на очень коротких writes?

А, точно. Это для чередования с избыточностью про суперблок, на простом чередовании RAID0 такого нет.

Хороший тест. Явно прослеживается проблема или в том как ты собираешь рейды или в методологии тестирования или в железе сервера (контроллер же переключении в jbod?)

Тесты проведены на: Hw raid hp p440, Mdadm, lvm stripes.

Я не включаю jbod. Я поставил hba H240.

Появились мысли о том, что затупливает HBA карта.

Но, не знаю насколько это правильно звучит, да и не могу найти информацию о enterprise ssd, но в raid нормально работают диски БЕЗ своего кеша. Например те же дешманские Adata su650 они впринципе не колосально быстрые, но стабильные. Например если single disk пишет монотонно 330Мб/с, то он и 400Гб пишет так же, а rand rw на нем 10,то они стабильно 10.

Само же тестирование банальное - на виртуальной машине на этом массиве запускаю diskmark, на хосте nmon.

Да собственно и diskmark не нужен, винда что стартует, что вытупливает даже браузер в ней так, что глаз поддергивается. Поэтому пока расбросал на отдельные диски и все летает.

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

По поводу размера блока:игрался от 4К до 16М - одна малина.

По поводу enterprise ssd - я озвучил на каких пробовал. К сожалению у меня тут не склад и нет «левого» финансирования для тестов,потому нет возможности накупить уеву тучу ентерпрайз дисков и тестить.

По поводу linear - можно, но забивается 1ssd и вся VG безбожно тупит.

Про синк - хзхз, даже не могу найти инфы по этому поводу

Кстати про ZFS striped. Износ дисков колосальный. За 3 года мои MX500 нарработали аж 12-16% wearout. За 4 месяца работы в ZFS стало 49-61%

Не надо делать lvm со страйпом поверх md. Делай lvm raid - тогда каждый диск как отдельный рейд и они меньше друг другу мешают. В моем бывшем клауде (несколько десятков стораджевых нод) это стандартная практика, и она себя оправдывает в производительности, с каждого стораджа снимали несколько сотен тысяч иопс (более 700 тысяч)

Никакого lvm stripe поверх md. Я имел ввиду и то и то пробовал. поверх md был просто lvm, был ext4.

Каждый диск как отдельный рейд это как?

Для увеличения iops можно попробовать сделать массив с –bitmap-chunk=1G или больше. Также можно в proxmox поставить тип кэширования writeback и использовать формат образа raw.

Надо было на btrfs делать.

Кстати про ZFS striped. Износ дисков колосальный. За 3 года мои MX500 нарработали аж 12-16% wearout. За 4 месяца работы в ZFS стало 49-61%

При этом нагрузки такие же?

Да. Вчера рылся по просторам интернета наткнулся на форуме proxmox даже, что intel d3 на zfs умирает за пару месяцев

Bitmap-chunk для mdadm насколько я понял. Собвстенно поставить его в 1Гиг - будет условно «кеш» крутиться. Ну и ок, 1гиг залетит, а дальше?

Diskmark в винде, винда в виртуалке - здесь слишком много лишнего для теста дисковой системы.

Тестируй с помощью fio, например.

Это с autotrim=on или с zpool trim по крону? В общем, политика трима какая?

Этот параметр влияет на размер блока bitmap. При частой записи в один блок, bitmap обновляется один раз. При сбое питания будет ребилд этого участка. По умолчанию 64Мб

Diskmark в винде, винда в виртуалке - здесь слишком много лишнего для теста дисковой системы.

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

Это с autotrim=on или с zpool trim по крону? В общем, политика трима какая?

Хоть так хоть так. Пробовал и autorim=off и on