Комментарии 16
1x 10GBps всё-таки маловато, чтобы раскрыть полностью потенциал NVMe-шек, особенно если их по сети целый пучок монтируется.
Говорят, если достаточно долго сидеть на берегу реки, можно увидеть рассвет и закат любых самых немыслимых технологий.
Безумно интересно. Любопытно, согласится ли подобным образом экспортироваться Intel PMem?
Опять же, я экспортировал обычные USB 2.0. Было жутко тормознуто, но работало. Опять же, вторая версия NVME поддерживает экспорт любых блочных девайсов. В процессе написания статьи я экспортировал жёсткие диски, флешки, NVME, SSD и Raid массивы.
А по поводу "заката" SSD - тут, судя по всему это просто закат SAS. У них, конечно, есть новая версия, которая позволяет пропихивать нереальные гигабиты в секунду, но по факту - нафига оно нужно? (Это с точки зрения команды NVME)
Прикол в том, что мы просто берём и втыкаем всё в PCIe шину. Так проще с точки зрения архитектуры.
Вот, например, сервер, в который можно втыкать NVME с U.2 интерфейсом. Разница между M.2 (которые у меня) и U.2 (который на картинке) в том, что последний можно вытаскивать из сервера на ходу.
Так что, если NVME продолжат развиваться так же хорошо (и так же открыто) как они делают сейчас, то я думаю, что тут вопрос времени.
Нафига нам нужен SAS, который был изначально сделан для крутящихся HDD, когда чипы в любом современном SSD работают быстрее на nvme.
Прикол в том, что мы просто берём и втыкаем всё в PCIe шину
Тут главное, чтобы один глюкнувший девайс не повесил эту PCIe шину разом для всех устройств.
Пока что проблем не было. Я запросто и в больших количествах получал сегфолты на девайсах, при этом сама система продолжала стабильно работать.
Мне ещё предстоит изучить протокол PCIe и NVMe, но выглядит так, что устройства достаточно независимы.
Я запросто и в больших количествах получал сегфолты на девайсах
Вы наверное получали сегфолты не на девайсах, а на CPU сервера, потому что сегфолт именно на процессоре NVMe диска выглядит примерно так, как я сказал)
А из-за чего такое происходит? Почему конечная точка вешает всю сетку и, главное, почему нет механизмов, предотвращающих это? Ну, там, наподобие ACS (и, кстати, если девайсы в изолированных IOMMU группах - они всё равно вешают root complex?).
Понимаю, что вопросы кажутся наивными, но они такие и есть - я не понимаю, это просчет в спецификации или намеренно так сделано в силу каких-то обстоятельств.
Можете подтолкнуть к правильным размышлениям?
Начнём с серверных NVME для испытаний
разве sn720 — серверные nvme?
dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsyncа зачем тут dsync? да и запись одного гигабайта для теста выглядит недостаточной
попробуйте
dd if=/dev/zero of=test1.img bs=1G count=128 oflag=direct status=progressТут при наших параметрах мы видим, что в рандомной записи 4х гигабайт данных, NVME побеждает всех и вся. Но при этом, удалённо он работает как кусок… Гхм. Никак. Полная фигня короче
на картинке не подписаны единицы измерения. обычно производительность случайной записи измеряют в iops'ах, но тут явно не они
Обязательно пишите ваши параметры к fio, я запущу их на серверах и дам знать.
можно взять из ридми к vitastor, например, вполне осмысленные тесты:
I use the following 6 commands with small variations to benchmark any storage:
- Linear write:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX- Linear read:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX- Random write latency (T1Q1, this hurts storages the most):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX- Random read latency (T1Q1):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX- Parallel write iops (use numjobs if a single CPU core is insufficient to saturate the load):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX- Parallel read iops (use numjobs if a single CPU core is insufficient to saturate the load):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX
если вы сможете поднять этот самый vitastor и выложить для сравнения тесты ещё и с ним, будет совсем замечательно.
и да, меня смущает, что вы запускаете fio не на блочных устройствах, а на файлах.
То есть, вы запросто можете впихнуть любое блочное устройство в протокол NVME.
так возможность экспортировать блочные устройства по сети существует давно, тому же iSCSI больше 20 лет.
что нового/полезного тут приносит NVMe? (я не критикую, я интересуюсь)
Бред.
Во-первых, чтобы без нормальной оптимизации BIOS/Grub - автор может смело удалять статью. Она ниочём!
Во-вторых, Автор ты даже не удосужился покопать дальше nvme list. Есть ещё удивительный параметр lba, а кроме него отдельно и оптимизация записи.
В-третьих, есть замечательная компания RAIDIX, чьи лицензии Мы продаём, прекрасно заменяют дорогостоящие контроллеры.
В-четвёртых, от Jumbo-фреймов толку не будет, нужно обладать хотя бы начальными знаниями и понимать что такое фрагментированные пакеты.
Личный совет - если Автор сможет подумать лобной долей и прочитать описание о всех доступных командах nvmecli, а особенно переформатировать блок записи...
Отдельно
Что касается ASUS-карты расширения, по опыту реализации проектов с ней, в BIOS включать AUTO-mode бессмысленно, работать с разными производителями NVMe, она не будет. Только в принудительном режиме 4-х и в слоте 16-х. Процессор старый, хм...учите матчасть, дело не в нём.
Мы уже давно используем данную технологию на протяжении 3 лет, с момента когда только появились первые накопители. В купе с PROXMOX + RAIDIX, обходимся без дополнительного аппаратного расширителя.
Как резюме - статья ничём, тупо потратили маркетинговый бюджет компании. Изобразили уважаемого человека который копал настолько глубоко и поступательно, что даже убогий Делориан стал машиной времени.
https://hascon.ru - если кому нужно адекватное железо на NVMe, пишите!
Во-первых, чтобы без нормальной оптимизации BIOS/Grub - автор может смело удалять статью. Она ниочём!
Если автор не нашел как эту оптимизацию сделать - вероятно 99% админов кому это потребуется - не найдет (или найдет далеко не сразу), статья с точки зрения такого админа - хороша
В-третьих, есть замечательная компания RAIDIX, чьи лицензии Мы продаём, прекрасно заменяют дорогостоящие контроллеры.
Как я понимаю - они ж программный RAID + свои железки продают?. Но тогда сразу встает, требующий отдельного ответа, вопрос - а чем lvm хуже? Да, возможно lvm хуже но это надо изучать отдельно. А если рассматривать их железки - это отдельная вообще тема - тест то про накопители а не хранилки.
У вас в "Мы дорожим своей репутацией | every promise responsibility" вы буковку с пропустили)
На сайте
Девочка, балансирующая на NVME-over-TCP 2.0