Comments 17
все результаты тестов оказались лучше паспортных данных,
у Soligim P series огромный кэш, порядка 10% ёмкости, если мне память не изменяет.
После его пробивания будет чот в районе 500 мегабайт в секунду.
Т.е. если диск 4 терра, то кэш 400 гиг? Хм. Откуда такая информация? Никогда не сталкивался, наоборот часто пишут что на enterprise дисках с кэшами особо не балуются для стабильности параметров. Да и странно тогда что 3/1.2 указывают как паспортную скорость... Надо подумать как можно сделать тест на терру...
А зачем на Target'е использовать ESXi, а сверху ещё виртуалку? Может лучше сразу ОС поставить на этот сервер без использования виртуализации?
Такая конфигурация системы по пожеланию заказчика. Часть серверов compute + storage, часть только compute. На самом деле в этом что-то есть. Жалко терять место в шкафу, 80 ядер и почти терра памяти если можно использовать это для дополнительных ВМ
Странные хотелки у заказчика.
Если хочется NVME-over-TCP и NVME-over-RDMA, то лучше для этого использовать серверы (таргеты) только в роли СХД. Текущая конфигурация с таргетами, к сожалению, сильно переусложнена, что увеличивает время диагностики любых проблем. Не понятно, где теряются iops, почему временами увеличиваются задержки и прочее.
Если хочется конфигурации compute + storage, то тогда стоит смотреть в сторону Software Defined Storage, например, vSAN или Nutanix.
Ну на самом деле статья совсем не об этом и не для обсуждения чьих то "хотелок"... Каждый вправе чего-то захотеть, если его желания не нарушают уголовный и другие кодексы... Тем более что в данном случае точно есть некоторые причины для этого, поверьте.
Три раза да. И esxi целевая система. И были интересны именно эти результаты. И если бы мы увидели что на уровне esxi всё сильно хуже чем по спекам, то тогда наверное попробовали бы накатить тесты на голое железо. А так стало понятно что потери минимальны (по крайней мере по последовательному доступу) и нет особого практического смысла в дополнительной переустановке системы...
Но тогда либо чисто для теста могли линуха накатить на голое железо (на один из свободных дисков?…), а потом уже ставить esxi по ТЗ заказчика. Либо сразу указать что esxi - целевая система заказчика, поэтому и результаты были интересны при использовании именно такого конфига…
А если для случайных операций увеличить размер блока скорость увеличивается? Проверяли такое?
Я в прошлом году пробовал выполнить подобное тестирование.
В качестве стэнда, на котором будут подключены диски брал виртуалку под OpenStack
Настраивал NVME over TCP по https://habr.com/ru/companies/beeline_tech/articles/770174/
Для NVME over RDMA были поданы несколько LUN с СХД, у которой включена эта функциональность.
И тут проявилась принципиальная разница этих двух подходов.
Over TCP заработал сразу
А вот RDMA для работы на виртуалке в OpenStack уровень доступа к железу сетевого адаптера недостаточен. Оно просто не завелось. Так как основной платформой хотели делать именно такие виртуалки - дальше этого эксперимента не пошло.
Число путей в случае over TCP, если у вас не несколько адаптеров, воткнутые в разные коммутаторы не принципиально.
Как описано в статье про настройку Over TCP число соединений для каждого неймспейса равно числу процессоров. И даже на виртуалке, с единственным сетевым адаптером при 4 отданных процессорах спокойно выжимали 95+% скорости при случайной записи/чтении через fio по сравнению с запущенным локально на NVME дисках fio c теми же самыми опциями.
Число путей сильно влияет на то, что можно выжать через iScsi.
Да, RDMA требует правильной конфигурации и ОС и свичей, я об этом писал. Без этого ничего не запустится.
Что касается утверждения что число путей сильно влияет только на iSCSI - то позвольте с этим не согласиться. Как показывают тесты выше, второй путь для NVME добавляет примерно 20%-30% на случайные чтение/запись, что, согласитесь, очень немало. А по поводу iSCSI , раз уже зашёл разговор об этом, то тесты ниже. Multipath однозначно положительно влияет, никто не спорит. При правильной настройке почти в 2 раза по всем показателям. Но и 20% это тоже неплохо..
iSCSI one path Fixed:
iSCSI RoundRobing 1000 IOps limit:
iSCSI RoundRobing 1 IOps limit:
у меня пытки тестов RDMA были на виртуалках, и при единственном сетевом интерфейсе.
Over TCP просто хотели использовать для сравнения результатов, так как до этого много играли на физике.
При подаче единственного диска в выделенном неймспейсе в таких тестах OverTCP разница от числа путей не существенная.
При подаче многих дисков, увеличении глубины IO, числа потоков самое заметное увеличение было при использовании ethernet как транспорта именно для iscsi
У нас просто 4x25 Гб адаптера управляемых FRR для тестов NVME over TCP использовались и ОС занималась распределением трафика по адаптерам.
Наличие 128 потоков на неймспейс для NVME команд просто давало хорошее равномерное распределение по 4 адаптерам, что позволяло их равномерно загружать.
У iScsi такой ровной утилизации адаптеров добились только после поднятия числа node.session.nr_sessions
Поэтому выходит, что OverTCP более универсальный, его проще настроить, он более неприхотлив к инфраструктуре. Падение скорости по сравнению с RDMA - плата за эту универсальность и неприхотливость.
В любом случае все надо тестировать и по итогам тестов принимать решения.
Если найти методологию тестирования Intel (согласно которой пишутся эти вот самые цифры 3.2 на чтение, 1.8 на запись), то из нее [примерно] следует, что сделано это при условии локальной записи/чтения блоками 256к (или даже 512к?), на сырое устройство без файловой системы. Для тестов 1М пусть ок, предположим что эффективнее чем 256к, но на 16к получить цифры, превышающее Интеловые - выглядит странно. То ли префетч/батчинг, то ли погрешность измерения/методики. Ну или предположить, что транспорт так хорош, что быстрее локальных дисков.
А какие локальные показатели (fio) с машины куда воткнуты диски?
У микрона есть в спецификациях парамеры тестирования
Размер блока для всего диска 4Кб/512б можно настроить.
И для 512б, который так любят базы больше издержек (первые версии прошивок для 7450 в него не умели).
Устройство без файловой системы это нормально для некоторых баз данных. Они ими сами в таком случае управляют.
Для того, чтобы оценить реальную скорость чтения число байт, которые предстоит случайно прочитать стоит задать раза в 3 больше, чем размер диска.
Для записи немного жалко ресурса, но узнать сколько раза нужно полностью перезаписать диск, чтобы потерять 1% его здоровья стоит. Потом на этом основании расчёты можно разные делать.
Сейчас уже сложно померять локальный fio на этой конкретной машинке, потому что SPDK забирает диски под себя, меняя драйвер.
Мои результаты тестов сравнения быстродействия NVME-over-TCP и NVME-over-RDMA