— вы меняли именно 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 на чтение. Страйпинг сильно лучше.
Нагрузка на железо замерялась. Подробную аналитику по этому вопросу мы изложим в отдельном материале.
Ваше подозрение вполне справедливо. Нагрузка, на самом деле, больше, чем у этих решений. Это объясняется тем, что параллелизация вычислений в большем объеме использует ресурсы CPU, задействуя все ядра равномерно. Правда, стоит отметить, что эта нагрузка не критична и оставляет место для полноценной работы других приложений.
Наша оценка показала, что слишком много придется вносить изменений, работая с чужим кодом. Свой продукт оказалось писать проще и эффективнее, тк мы ничем не ограничены с точки зрения архитектурных ноу-хау. Тем более, mdraid пытались разогнать и Intel и SGI, к сожалению, удалось лишь точечно. Intel, в итоге, сделал VROC.
Как раз, наоборот, мы потратили много времени на попытку разогнать zfs, тем более у нас есть партнеры, которые хотели бы создавать пулы из наших устройств. Не вышло…
Полигон стоит собранный, если у вас есть идеи как получить лучшие результаты, мы готовы ими воспользоваться, а полученные цифры добавим в статью.
Мы пробовали использовать разные (4, 16, стандартный (128), 1024). Производительность практически не менялась. 1M нам советовали специалисты по ZFS с рынка HPC (Там файловая система используется как backend для Lustre). На нем и остановились.
Мы запустили сокращенный набор тестов с recordsize=8k. В ближайшее время добавим результаты.
1. Тестирование детально не описывали здесь, поскольку тестирование распределенно кластера это большая и сложная тема, которую можно долго обсуждать ввиду большого количества параметров и правильной интерпретации результатов. Лучше все подробно расписать в отдельной статье. Над табличкой добавили информацию про параметры нагрузки.
2. Для двух дисков этой модели при наличие сетевого RAID — локальный страйп подойдет.
В случае отказа 1 диска будет работать сетевой RAID. За два года использования нашего кластера (32 накопителя) не было ни одного отказа.
Также в наших нодах стоят по 16 HDD. Для них мы используем локальный RAID6. Для трех NVMe рекомендуем локальную 5-ку. Перед выбором схем защиты мы строили модель отказов системы, выдерживая уровень доступности 99.999.
RAIDIX поддерживает любые диски любых производителей.
JBOD от WD продается только с минимальным набором дисков и официально расширяется только дисками этого же производителя.
iozone -i0 -i1 -I -+n -r 16m -s 100g -t N -+m hostlist-xfsN
Большая часть тестов — на стороне партнера, и мы не все детали можем разглашать.
Меняли recordsize. volblocksize = 8K во всех тестах. Меняли на меньший (4k) — влияние минимальное.
Нет, пул заполнен не полностью:
tank :: USED 2.24T :: AVAIL 4.17T
tank/raid :: USED 2.24T :: AVAIL 4.17T
64 потока с глубиной 32 при iops тестах
Lustre, все же, не zvol пользует. Когда тестируешь на уровне ФС (iozone) результаты лучше. На нашем полигоне с RAIDZ2 около 3GBps на запись и 4GBPs на чтение. Страйпинг сильно лучше.
Ваше подозрение вполне справедливо. Нагрузка, на самом деле, больше, чем у этих решений. Это объясняется тем, что параллелизация вычислений в большем объеме использует ресурсы CPU, задействуя все ядра равномерно. Правда, стоит отметить, что эта нагрузка не критична и оставляет место для полноценной работы других приложений.
Полигон стоит собранный, если у вас есть идеи как получить лучшие результаты, мы готовы ими воспользоваться, а полученные цифры добавим в статью.
Мы запустили сокращенный набор тестов с recordsize=8k. В ближайшее время добавим результаты.
2. Для двух дисков этой модели при наличие сетевого RAID — локальный страйп подойдет.
В случае отказа 1 диска будет работать сетевой RAID. За два года использования нашего кластера (32 накопителя) не было ни одного отказа.
Также в наших нодах стоят по 16 HDD. Для них мы используем локальный RAID6. Для трех NVMe рекомендуем локальную 5-ку. Перед выбором схем защиты мы строили модель отказов системы, выдерживая уровень доступности 99.999.
За пожелания — отдельное спасибо :)
2. Попозже добавим сюда спецификацию с NVDIMM-N.
JBOD от WD продается только с минимальным набором дисков и официально расширяется только дисками этого же производителя.