LINUX.ORG.RU

Намутил свой сетевой протокол для дисков

 , , ,


13

8

https://github.com/vtl/ethblk

На имеющемся железе пробрасывает NVMe примерно на его родной скорости, и делает это в два с лишним раза быстрее штатного линуксового nvme-over-tcp. Дальше упирается в мой слабый клиентский комп, но на большом железе производительность растёт до миллионов IOPS через один диск. 50 GbE успешно загружал на полную катушку, был, практически, line rate.

★★★★★

Это получается и стенку в магазине можно приподнять в систему можно подключить удаленный NVMe и работать с ним как с локальным диском, с возможностью записи через O_DIRECT и вот это всё?

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 1)

В скрипте вижу включение jumbo frames, а без этого передача сильно просаживается?

В чем подвох такого ускорения передачи?

Какая минимальная версия ядра нужна для сборки? Ни тут, ни в README инфы про версию не нашёл.

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

Это получается и стенку в магазине можно приподнять в систему можно подключить удаленный NVMe и работать с ним как с локальным диском, с возможностью записи через O_DIRECT и вот это всё?

Можно на пачке NVMe сделать страйптнутый LVM, пробросить его по сети и иметь больше миллиона IOPS с одного диска. У меня полтора было на 50 GbE.

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

Звучит очень круто. Под какую задачу разрабатывалось? Можно пару примеров использования?

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

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

В скрипте вижу включение jumbo frames, а без этого передача сильно просаживается?

Достаточно прилично. Но тоже может работать. Прям сейчас не может, надо параметры создания очереди диска в инициаторе подправить. А ещё лучше, MTU path discovery прикрутить.

В чем подвох такого ускорения передачи?

Стандартно... Multiqueue, оптимизация доступа к памяти (нет горячих спинлоков, не пишутся общие области памяти, предварительное выделение, где только можно), zero-copy (кроме приёма в инициаторе). В случае с L3 (IP/UDP) ещё и не использую кернельный IP-стек.

Какая минимальная версия ядра нужна для сборки? Ни тут, ни в README инфы про версию не нашёл.

Разрабатывалось под 4.13, но давно не проверял. На 5.0 и 5.1 точно работает.

Извините, торопился: через час уезжаю в одиночку в тундру от переизбытка цивилизации лечиться, на всякий случай исходники в таком вот виде выложил. Мало ли... Документация будет.

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

Извините, торопился: через час уезжаю в одиночку в тундру от переизбытка цивилизации лечиться, на всякий случай исходники в таком вот виде выложил. Мало ли... Документация будет.

Если что, считать тебя коммунистом кем? :P

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

Прям сейчас не может, надо параметры создания очереди диска в инициаторе подправить. А ещё лучше, MTU path discovery прикрутить.

Ясно.

Разрабатывалось под 4.13, но давно не проверял. На 5.0 и 5.1 точно работает.

Пробовал собирать на debian 9 с 4.9 и ловил ошибки. На armbian с 4.14 тоже не собралось.

А вместо блочного устройства с файлом будет работать или с loop-устройством?

через час уезжаю в одиночку в тундру

Ну вопрос всё равно будет актуален. :)

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

Пробовал собирать на debian 9 с 4.9 и ловил ошибки. На armbian с 4.14 тоже не собралось.

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

armbian? На не-x86 не проверял. В протоколе BE всё должно быть, но раз не проверял, то наверняка не работает.

А вместо блочного устройства с файлом будет работать или с loop-устройством?

С файлом не будет, а loop - блочное устройство.

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

Я чет затупил. В твоем тесте только чтение. А я подумал что речь о записи. Интересно глянуть что с записью получается, есть ли какие-то подводные камни.

Я уже уехал

Хорошего отдыха.

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

Можно на пачке NVMe сделать страйптнутый LVM, пробросить его по сети и иметь больше миллиона IOPS с одного диска. У меня полтора было на 50 GbE.

А зачем? Эту пачку NVMe можно локально разместить. Можно сделать программный RAID0 или RAID1 на паре из локального и удаленного NVMe?

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

Тогда я не понял фразу «Дальше упирается в мой слабый клиентский комп, но на большом железе производительность растёт до миллионов IOPS через один диск».

Во что конкретно там упирается производительность?

anonymous ()

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

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

Это домашняя поделка, я даже железа на $3к за свой счёт под это дело купил. И ещё тыщи 2 надо: клиент не тянет.

А ещё я сегодня на айсберг залазил =)

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

На Debian 10 с 4.19.67 собралось, но проверять буду, когда машина в пределах одного помещения со мной будет. :)

Десятков гигабит у меня нет, но потыкать желание есть.

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

Плюс-минус работает примерно с 4.13, но для потыкивания желательна сотня гигабит, плюс железо, могущее прокормить это дело :) fio, запущенный на i7-3770, не может сеть нагрузить нормально.

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

Да мне это больше как альтернативу iscsi интересно потыкать. Не IOPS измерять и просто запустить у себя. :)

Если еще dkms.conf замутишь, то будет прям вообще зашибись.

Radjah ★★★★★ ()
Последнее исправление: Radjah (всего исправлений: 1)