Как стать автором
Обновить

Тестирование программных RAID-массивов для NVMe-устройств по методике SNIA

Время на прочтение11 мин
Количество просмотров12K
Всего голосов 10: ↑6 и ↓4+2
Комментарии19

Комментарии 19

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

Может, я чего-то не понимаю, но:


"… recordsize=1M ....." — это при измерении производительности ZFS зачем? Вы не пробовали при recordsize 8К то же самое померять?

Наверное результаты портили всю картину. На своём решении они выставили 16к, так что очевидно результаты подгоняли.
Как раз, наоборот, мы потратили много времени на попытку разогнать zfs, тем более у нас есть партнеры, которые хотели бы создавать пулы из наших устройств. Не вышло…
Полигон стоит собранный, если у вас есть идеи как получить лучшие результаты, мы готовы ими воспользоваться, а полученные цифры добавим в статью.
recordsize к zvol не относится, вам нужно было увеличивать volblocksize на соответствующих блоках.
volblocksize — аналог recordsize для zvol.
Мы пробовали использовать разные (4, 16, стандартный (128), 1024). Производительность практически не менялась. 1M нам советовали специалисты по ZFS с рынка HPC (Там файловая система используется как backend для Lustre). На нем и остановились.

Мы запустили сокращенный набор тестов с recordsize=8k. В ближайшее время добавим результаты.
Что же получается в итоге?

Популярные и доступные программные RAID-массивы для работы с NVMe-устройствами не могут показать той производительности, что заложена в аппаратном потенциале..

… и вместо того, чтобы соответствующим образом улучшить mdadm, мы запилим своё.
А продавать потом как?
Вот именно, куча сложностей. А так сами написали, сами раздаем бесплатные лицензии. Никто не мешает.
Наша оценка показала, что слишком много придется вносить изменений, работая с чужим кодом. Свой продукт оказалось писать проще и эффективнее, тк мы ничем не ограничены с точки зрения архитектурных ноу-хау. Тем более, mdraid пытались разогнать и Intel и SGI, к сожалению, удалось лишь точечно. Intel, в итоге, сделал VROC.

Подскажите, а не замерялась нагрузка на ЦП/память?
Есть подозрение, что результат, по мимо прочего, достигается бОльшим имполбзованием шин памяти/ЦП, чем это делают mdev/zfs ...

Нагрузка на железо замерялась. Подробную аналитику по этому вопросу мы изложим в отдельном материале.
Ваше подозрение вполне справедливо. Нагрузка, на самом деле, больше, чем у этих решений. Это объясняется тем, что параллелизация вычислений в большем объеме использует ресурсы CPU, задействуя все ядра равномерно. Правда, стоит отметить, что эта нагрузка не критична и оставляет место для полноценной работы других приложений.
Расскажите пожалуйста, хотя бы в самом общем виде, о причинах очень плохой производительности MDRAID и ZFS.
С обычными HDD этот продукт не работает?
Теоретически он может работать с HDD, но мы не тестировали, поэтому, не можем рекомендовать. Можете скачать бесплатную версию и попробовать :)
Предполагая, что в ZFS вы тестировали именно ZVOL:
— вы меняли именно recordsize? Он к ZVOL никак не относится, аналогичный для ZVOL параметр — volblocksize. Его надо обязательно менять соответственно нагрузке, от 4k до 1M. На 1M мерять 4k нагрузку для ZFS — убийство.
— вы пул заполняли полностью? ZFS пулы нельзя заполнять полностью, особенность любой CoW ФС с переменным размером блока. Рекомендуется заполнять до 80%, далее можно донастроить в зависимости от размера пула, но никак не 100%.
— какое количество потоков? На 1 потоке RAIDZ выдаст вам IOPS 1 диска, но при росте потоков ZFS прекрасно агрегирует запись.

Если ваш тест корректен, то получается все юзеры ZFS в мире (включая HPC на lustre) получают не более 700Мбайт на запись? Уверяю, что ZFS спокойно даёт больше.
— вы меняли именно recordsize? Он к ZVOL никак не относится, аналогичный для ZVOL параметр — volblocksize. Его надо обязательно менять соответственно нагрузке, от 4k до 1M. На 1M мерять 4k нагрузку для ZFS — убийство.

Меняли recordsize. volblocksize = 8K во всех тестах. Меняли на меньший (4k) — влияние минимальное.

— вы пул заполняли полностью? ZFS пулы нельзя заполнять полностью, особенность любой CoW ФС с переменным размером блока.

Нет, пул заполнен не полностью:
tank :: USED 2.24T :: AVAIL 4.17T
tank/raid :: USED 2.24T :: AVAIL 4.17T

— какое количество потоков? На 1 потоке RAIDZ выдаст вам IOPS 1 диска, но при росте потоков ZFS прекрасно агрегирует запись.

64 потока с глубиной 32 при iops тестах

Если ваш тест корректен, то получается все юзеры ZFS в мире (включая HPC на lustre) получают не более 700Мбайт на запись? Уверяю, что ZFS спокойно даёт больше.

Lustre, все же, не zvol пользует. Когда тестируешь на уровне ФС (iozone) результаты лучше. На нашем полигоне с RAIDZ2 около 3GBps на запись и 4GBPs на чтение. Страйпинг сильно лучше.
Спасибо за ответ.

Меняли recordsize. volblocksize = 8K во всех тестах. Меняли на меньший (4k) — влияние минимальное.

Lustre, все же, не zvol пользует.

То есть вы НЕ меняли volblocksize в бОльшую сторону (а recordsize к zvol не относится). Для zvol стоит ставить соответствующий нагрузке размер volblocksize, на больших блоках результат тогда будет адекватный.

Ваше решение, кстати, не CoW?

Не пробовали тестировать с более высокочастотными процессорами? Оно, конечно, сильно от софта зависит, но должно быть заметно получше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий