惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cisco Talos Blog
Cisco Talos Blog
V
V2EX
C
Check Point Blog
GbyAI
GbyAI
D
Docker
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
B
Blog RSS Feed
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
Netflix TechBlog - Medium
T
Troy Hunt's Blog
博客园 - Franky
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Microsoft Security Blog
Microsoft Security Blog
P
Privacy & Cybersecurity Law Blog
WordPress大学
WordPress大学
The Cloudflare Blog
S
SegmentFault 最新的问题
Latest news
Latest news
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
I
InfoQ
博客园 - 【当耐特】
NISL@THU
NISL@THU
A
About on SuperTechFans
T
Tailwind CSS Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
The Hacker News
The Hacker News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Scott Helme
Scott Helme
雷峰网
雷峰网
C
CXSECURITY Database RSS Feed - CXSecurity.com
Security Latest
Security Latest
V
Vulnerabilities – Threatpost
Security Archives - TechRepublic
Security Archives - TechRepublic
A
Arctic Wolf
Hacker News: Ask HN
Hacker News: Ask HN
N
News and Events Feed by Topic
IT之家
IT之家
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
aimingoo的专栏
aimingoo的专栏
T
Threat Research - Cisco Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
阮一峰的网络日志
阮一峰的网络日志
SecWiki News
SecWiki News
大猫的无限游戏
大猫的无限游戏
S
Security Affairs
The Register - Security
The Register - Security
www.infosecurity-magazine.com
www.infosecurity-magazine.com
L
LINUX DO - 热门话题
T
Tor Project blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Производительность софт NVMe рейдов на основе mdadm, LVM и ZFS при использовании iSER и NVMe-oF (100G version) — Part 2
Dante4 · 2026-05-02 · via Все публикации подряд на Хабре

Уровень сложностиСредний

Время на прочтение20 мин

Охват и читатели453

Обзор

Предисловие скопировано из Part 1.

С момента прошлой статьи прошло 2 года (и за время написания статьи ещё полгода), за это время:

  • количество дисков в системе увеличилось до 8 PM9A3 1.92TB;

  • вышло несколько новых прошивок на PM9A3;

  • сеть обновилась с ConnectX-3 Pro 40G до ConnectX-4 100G;

В связи с этим - было решено заново провести тесты.

У данной статьи такие же две цели, как и у прошлой:

  1. Протестировать производительность трёх систем объединения физических устройств в одно логическое, как для локального доступа к нему, так и для использования в качестве блочного массива для виртуализации.

  2. Создание бэкэнда для кластера в виде одноконтроллерного хранилища.

Иными словами выводы данной статьи не применимы, когда Вам нужно:

  1. Синхронное отказоустойчивое решение

  2. Надежность >>> скорость

  3. Долговременное решение, которое можно поставить и забыть

0. Оглавление

1. Описание тестового стенда

(назад к оглавлению)

Сервер виртуализации 1:

  • Motherboard: Supermicro H11SSL-i

  • CPU: EPYC 7302

  • RAM: 4x64GB Micron 2933MHz

  • Сеть SAN: 100GbE ConnectX-4 MT27700

  • Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN

  • ОС: ESXi 7U3 build 20036586

Сервер виртуализации 2:

  • Motherboard: Supermicro H11DSI-NT

  • CPU: EPYC 7302 x2

  • RAM: 16x32GB Samsung 3200 MHz

  • Сеть SAN: 100GbE ConnectX-4 MT27700

  • Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN

  • ОС: ESXi 7U3 build 20036586

Сервер хранения (гибридный сервер с PCIe Passthrough):

  • Motherboard: Tyan S8030 (ver 1GbE)

  • CPU: EPYC 7F52

  • RAM: 4x64GB Micron 2933MHz

  • Сеть SAN: 100GbE ConnectX-4 MT27700 x2

  • Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN

  • Диски: 8 x PM9A3 1.92TB, форматированы в 512n

Схема подключения для тестов NVMe-oF и iSER:
Схема подключения

Схема подключения

2. Общая настройка серверов.

(назад к оглавлению)
Для тестирования была создана ВМ с iSER (LIO) и NVMe-oF (SPDK) таргетом, для NVMe-oF тестов параметры ВМ оставались неизменные, кроме ZFS тестов, а именно 6 ядер, 64ГБ памяти.

Для ZFS - в случае iSER память была расширена до 128ГБ, а в случае с NVMe-oF размер ВМ увеличен до 8 ядер и количество оперативной памяти до 128ГБ.

Конфигурация нагрузочных ВМ HCIbench-а

FIO тесты:

  • По 2 ВМ на хост (6 ВМ суммарно)

  • 8 vCPU

  • 16GB оперативной памяти

  • 8 дисков по 32ГБ

vdbench тесты:

  • По 2 ВМ на хост (6 ВМ суммарно)

  • 8 vCPU

  • 16GB оперативной памяти

  • 2 диска по 100ГБ

Конфигурация FIO

Тесты являются тестами из пресета vsan easyrun

Последовательная запись 256k

fio-8vmdk-100ws-256k-0rdpct-0randompct-1threads

[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=write
random_generator=tausworthe64
blocksize=256K
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all

[job0-7]
filename=/dev/sda
size=100%
iodepth=1

(к тесту iSER)
(к тесту NVMe-oF)

Случайное 100% чтение 4k

fio-8vmdk-100ws-4k-100rdpct-100randompct-4threads-50compress-50dedupe

[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randread
random_generator=tausworthe64
blocksize=4K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all

[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4

(к тесту iSER)
(к тесту NVMe-oF)

Случайное 70% чтение 30% запись 4k

fio-8vmdk-100ws-4k-70rdpct-100randompct-4threads-50compress-50dedupe

[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randrw
rwmixread=70
percentage_random=100
random_generator=tausworthe64
blocksize=4K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all

[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4

(к тесту iSER)
(к тесту NVMe-oF)

Случайное 50% чтение 50% записи 8к

fio-8vmdk-100ws-8k-50rdpct-100randompct-4threads-50compress-50dedupe

[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randrw
rwmixread=50
percentage_random=100
random_generator=tausworthe64
blocksize=8K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all

[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4

(к тесту iSER)
(к тесту NVMe-oF)

Конфигурация vdbench

Тесты взяты отсюда

100% cлучайная запись 4к, 4 потока на диск

vdb-2vmdk-100ws-4k-0rdpct-100randompct-4threads

2 raw disk, 100% random, 0% read

sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4
sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4
wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=0,seekpct=100
rd=run1,wd=wd1,iorate=max,elapsed=300

(к тесту iSER)
(к тесту NVMe-oF)

100% случайное чтение 4к, 4 потока на диск

vdb-2vmdk-100ws-4k-100rdpct-100randompct-4threads

2 raw disk, 100% random, 100% read

sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=100,seekpct=100 rd=run1,wd=wd1,iorate=max,elapsed=300

(к тесту iSER)
(к тесту NVMe-oF)

80% случайное, 20% последовательное, 50% чтение 50% записи 4к, 4 потока на диск

vdb-2vmdk-100ws-4k-50rdpct-80randompct-4threads

2 raw disk, 80% random, 50% read

sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=50,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300

(к тесту iSER)
(к тесту NVMe-oF)

80% случайное, 20% последовательное, 75% чтение 25% записи 64к, 4 потока на диск

vdb-2vmdk-100ws-64k-75rdpct-80randompct-4threads

2 raw disk, 80% random, 75% read

sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=64k,rdpct=75,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300

(к тесту iSER)
(к тесту NVMe-oF)

80% случайное, 20% последовательное, 75% чтение 25% записи 8к, 4 потока на диск

vdb-2vmdk-100ws-8k-75rdpct-80randompct-4threads

2 raw disk, 80% random, 75% read

sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=8k,rdpct=75,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300

(к тесту iSER)
(к тесту NVMe-oF)

Настройки хоста со стороны BIOS

Для настроек BIOS помогли эти две статьи (#1, #2):

NPS=1
L3 Cache as NUMA domain = Disabled
IOMMU = Enabled
PCIe Ten Bit Tag Support = Enabled
Prefered IO = Manual
Preferred IO Bus = <conntectX-4 pcie ID из lspci>
APBDIS = 1
Fixed SOC P-state=P0
DF C-states=Disable
Global C-State Control =Enable
Determinism Control = Manual
Determinism Enable = Power
TDP Control = Manual
TDP = <max CPU TDP>
PPT Control = Manual
PPT = <max CPU TDP>

Для наглядности Google Spreadsheet:

https://docs.google.com/spreadsheets/d/1f49vAqj-m4n4sSb8tD-PahenhBxXMx4Ju0QM_RvhU38/edit?usp=sharing

2.1 Особые условия

(назад к оглавлению)
В силу того, что SPDK работает по пуллинг принципу - он занимает все ядра, что ему отдали всегда на 100%. Поэтому процессам, которые хотят взять себе ресурсов, к примеру, для рассчёта parity возникает определённая проблема, включая даже банально, что так как LVM считает себя более приоритетным, SPDK ломается и теряет QID генерирую дубликаты.

Скрытый текст

spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:2, qid:1), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:1
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 1 (cntlid:2)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:3, qid:1), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:1
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 1 (cntlid:3)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:3, qid:2), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:2
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 2 (cntlid:3)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:2, qid:2), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:2
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 2 (cntlid:2)

Решением стало:

1) Уменьшение количество ядер отданных инициатору до 2 в случае с LVM Raid5, и до 4 в случае с ZFS Stipe и RaidZ

2) Увеличение размера ВМ с SPDK с 6 до 8 ядер.

Также для тестов ZFS все диски сперва были пропущены через blkdiscard с ожидаем после этого в 1 ночь, чтобы контроллер отработал все фоновые задачи.

3. iSER

(назад к оглавлению)
iSER особо не поменялся и его настройка всё такая же, что со стороны Вари, что со стороны Linux (targetcli)

На уровне IQN:

set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1

На уровне LUN-а:

set attribute emulate_3pc=1 emulate_tpu=1 emulate_caw=1 max_write_same_len=65535 emulate_tpws=1 is_nonrot=1

3.1 Raw Data

(назад к оглавлению)
Сырые значения сгруппированы по типу использованного софт рейда. Графические данные по имени теста.

MDADM Raid0

MDADM Raid0

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

284 723.17

1 112.19

6.20%

0.17

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

225 953.33

882.63

7.00%

0.21

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

257 869.23

1 007.30

8.27%

0.16

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

0.21

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

88 482.30

5 530.14

9.10%

0.53

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.56

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

227 262.77

1 775.49

10.28%

0.17

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.22

Последовательная запись 256к (vsan easyrun)

11 166.15

2 790.67

7.25%

4.57

Случайное 100% чтение 4k (vsan easyrun)

361 540.68

1 411.67

8.97%

0.53

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

367 324.14

1 434.33

12.24%

0.49

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

0.54

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

343 850.64

2 686.00

16.61%

0.53

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

0.59

MDADM Raid5

MDADM Raid5

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

67 847.47

265.03

1.92%

0.88

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

203 026.33

793.07

3.48%

0.24

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

119 058.50

465.07

4.98%

0.70

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

0.21

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

24 256.00

1 516.00

4.73%

5.76

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.40

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

122 714.27

958.70

5.95%

0.67

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.24

Последовательная запись 256к (vsan easyrun)

1 417.53

353.67

1.48%

16.97

Случайное 100% чтение 4k (vsan easyrun)

139 514.77

544.67

3.51%

0.69

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

120 456.52

470.33

6.03%

0.87

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

0.77

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

77 749.53

607.00

7.79%

1.45

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

1.02

LVM Raid0

LVM Raid0

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

299 001.83

1 167.97

12.60%

0.16

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

234 285.33

915.18

14.10%

0.20

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

268 003.80

1 046.89

15.50%

0.15

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

0.20

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

100 048.77

6 253.05

15.98%

0.52

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.60

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

233 907.83

1 827.41

18.73%

0.16

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.22

Последовательная запись 256к (vsan easyrun)

18 722.06

4 680.00

4.78%

2.64

Случайное 100% чтение 4k (vsan easyrun)

350 870.49

1 370.33

6.73%

0.55

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

354 473.82

1 384.00

12.09%

0.51

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

0.56

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

332 271.50

2 595.33

16.86%

0.55

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

0.61

LVM Raid5

LVM Raid5

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

59 304.53

231.65

5.83%

0.80

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

91 895.98

358.97

6.84%

0.52

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

81 976.13

320.22

7.62%

0.71

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

0.45

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

13 216.58

826.04

8.13%

7.45

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

2.36

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

77 631.65

606.50

9.56%

0.82

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

0.55

Последовательная запись 256к (vsan easyrun)

1 889.59

472.00

3.23%

25.60

Случайное 100% чтение 4k (vsan easyrun)

123 334.01

481.25

4.06%

1.56

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

106 681.02

416.00

6.37%

1.88

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

1.76

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

73 436.82

573.25

8.07%

2.84

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

2.39

ZFS Stripe (Raid0)

ZFS Stripe (Raid0)

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

13 854.37

54.12

10.95%

3.46

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

78 314.83

305.92

11.06%

0.61

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

29 376.40

114.75

11.07%

1.82

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

1.45

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

18 672.80

1 167.06

11.96%

2.31

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

2.74

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

38 804.50

303.16

14.39%

1.26

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

1.24

Последовательная запись 256к (vsan easyrun)

3 424.75

855.75

2.55%

14.02

Случайное 100% чтение 4k (vsan easyrun)

83 428.24

325.50

5.15%

2.32

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

40 025.47

155.75

7.41%

5.24

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

4.69

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

28 179.41

219.75

8.60%

7.34

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

6.30

ZFS RaidZ (Raid5)

ZFS RaidZ (Raid5)

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk

12 718.27

49.68

10.10%

3.77

VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk

72 718.70

284.06

11.33%

0.66

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE

24 668.73

96.36

12.59%

2.40

VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ

1.49

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

15 468.27

966.77

13.69%

2.09

VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ

3.51

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE

35 068.17

273.97

15.93%

1.39

VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ

1.37

Последовательная запись 256к (vsan easyrun)

3 213.39

803.00

3.64%

15.02

Случайное 100% чтение 4k (vsan easyrun)

75 045.22

292.33

5.97%

2.56

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

34 054.32

132.33

8.69%

6.14

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

5.43

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

24 047.15

187.33

10.08%

8.63

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

7.34

ZFS Stripe (Raid0) без чексумм

ZFS Stripe nochecksum

iSER

IOPS

MB/s

CPU util

latency

VDbench - 4k - 100% rng - 0/100 r/w - 4 thread per disk

21 469.40

83.86

6.10%

2.23

VDbench - 4k - 100% rng - 100/0 r/w - 4 thread per disk

81 155.30

317.01

8.15%

0.59

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

39 117.90

152.80

10.35%

1.29

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

1.17

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

20 887.43

1305.46

12.27%

2.02

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

2.44

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

48 347.85

377.72

14.71%

1.01

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

1.00

Последовательная запись 256к (vsan easyrun)

3 600.64

899.67

6.37%

13.34

Случайное 100% чтение 4k (vsan easyrun)

84 736.52

330.33

6.92%

2.27

Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE

51 076.97

199.33

7.87%

3.94

Случайное 70% чтение 30% запись 4k (vsan easyrun) READ

3.69

Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE

37 120.03

289.33

8.95%

5.48

Случайное 70% чтение 30% записи 8к (vsan easyrun) READ

4.88

3.2 VDbench - 4k - 100% rng - 100% Write

(назад к оглавлению)
(назад к описанию теста)

График Latency на запись

График Latency на запись

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.3 VDbench - 4k - 100% rng - 100% read

(назад к оглавлению)
(назад к описанию теста)

График Latency на чтение

График Latency на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.4 VDbench - 4k - 80% rng - 50/50 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.5 VDbench - 64k - 80% rng - 75/25 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.6 VDbench - 8k - 80% rng - 75/25 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.7 FIO - 256k - 0% rng - 0/100 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency на запись

График Latency на запись

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.8 FIO - 4k - 100% rng - 100/0 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency на чтение

График Latency на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.9 FIO - 4k - 100% rng - 70/30 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.10 FIO - 8k - 100% rng 70/30 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

3.11 Сравнение софт рейдов

3.11.1 Raid0

Общий график по Raid0. По вертикали МБ/с, по горизонтали тесты

Общий график по Raid0. По вертикали МБ/с, по горизонтали тесты

Итогом стало лидерство LVM в тестах где нагрузка идёт в рамках пары дисков (vdbench) и аналогичное по % лидерство mdadm в тестах где есть множество дисков (8 штук). Также стоит отметить тот факт, что отключение Checksum даёт следующий прирост для производительности ZFS (порядка ~22%):

Сравнение ZFS с и без чексумм при подключении через iSER

Сравнение ZFS с и без чексумм при подключении через iSER

3.11.2 Raid5

По вертикали МБ/с, по горизонтали тесты

По вертикали МБ/с, по горизонтали тесты

4. NVMe-oF

4.1 Проблемы Next-Next-Next для NVMe-oF

При простом включении NVMe-oF (включая настройки тут, тут и тут) и SPDK в начале всё работало, но в ходе тестов начала проявляться значительная деградация, вплоть до того, что датастор открывался по 5-12 секунд, при простом копировании ВМок производительности других ВМ падала в 0 (именно в 0, т.е. IO вообще не проходили), а в логах сыпалось:

2025-05-17T19:17:46.535Z warning hostd[2099859] [Originator@6876 sub=IoTracker] In thread 2099865, open("/vmfs/volumes/6828d6a7-6e0bb546-8c25-ac1f6be8140e/hci-fio-datastore-6001-1-4/hci-fio-datastore-6001-1-4_1.vmdk~") took over 5 sec.

А средний отклик IO достигал вплоть до 9 секунд судя по графикам.

В ходе изучения всех возможных настроек производительности для выхода из этой ситуации нашлись следующие настройки, помимо настроек BIOS обозначенных выше.

Для настроек самой CX4:

/opt/mellanox/bin/mlxconfig -d mt4115_pciconf0 set LLDP_NB_DCBX_P1=1 LLDP_NB_TX_MODE_P1=2 LLDP_NB_RX_MODE_P1=2 LLDP_NB_DCBX_P2=1 LLDP_NB_TX_MODE_P2=2 LLDP_NB_RX_MODE_P2=2 CNP_DSCP_P1=48 CNP_802P_PRIO_P1=6 CNP_DSCP_P2=48 CNP_802P_PRIO_P2=6

Для ESXi финальными настройками стало:

esxcli system module parameters set -m nmlx5_core -p "pfctx=0x08 pfcrx=0x08 dcbx=2 trust_state=2 DRSS=4 RSS=8 GEN_RSS=3 max_queues=32 dropless_rq=1"

esxcli system module parameters set -m nmlx5_rdma -p "dscp_force=26 pcp_force=3 roce_version=2"

esxcli network nic ring current set -n vmnicX -r 8192 -t 8192

Полная резервация частоты для ВМ с дисками и повышение Shares до High.

Для Linux внутри ВМ финальной настройкой стало:

Скрипт запуска SPDK таргета (part 1)

#!/bin/bash
mst start
tc_wrap.py -i ens257f0np0
mlnx_qos -i ens257f0np0 --cable_len=1
mlnx_qos -i ens257f0np0 --trust pcp
mlnx_qos -i ens257f0np0 --pfc 0,0,0,1,0,0,0,0
mkdir -p /sys/kernel/config/rdma_cm/mlx5_0
sysctl -w net.ipv4.tcp_ecn=1
echo 6 > /sys/class/net/ens257f0np0/ecn/roce_np/cnp_802p_prio
echo 106 | sudo tee /sys/class/infiniband/mlx5_0/tc/1/traffic_class
cma_roce_tos -d mlx5_0 -t 106
ip link set ens257f0np0.101 type vlan egress-qos-map 4:3
ip link set ens257f0np0.102 type vlan egress-qos-map 4:3
ip link set ens257f0np0.103 type vlan egress-qos-map 4:3
sysctl -w net.core.netdev_budget=600
sysctl -w net.core.rmem_max=16777216
sysctl -w net.ipv4.tcp_rmem=“16384 349520 16777216”
sysctl -w net.ipv4.tcp_congestion_control=cubic
sysctl -w net.core.netdev_budget_usecs=4000
ethtool -G ens257f0np0 rx 8192 tx 8192
mlnx_qos -i ens257f0np0 --tsa=ets,ets,ets,ets,ets,ets,ets,ets --tcbw=0,0,0,100,0,0,0,0

Что удивительно, но даже в случае виртуализации Ubuntu считала что у процессора есть 8 C-state и пыталась их использовать, поэтому их тоже пришлось выключить:

GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off processor.max_cstate=0 default_hugepagesz=1G hugepagesz=1G"

Для SPDK настройками запуска стало:

Скрипт запуска SPDK таргета (part 2)

PCI_ALLOWED=“none” HUGEMEM=40960 /home/storage/spdk/scripts/setup.sh
/home/storage/spdk/build/bin/nvmf_tgt -m 0x3F -s 40G --wait-for-rpc &
sleep 10
/home/storage/spdk/scripts/rpc.py log_set_level DEBUG
/home/storage/spdk/scripts/rpc.py log_set_print_level DEBUG
/home/storage/spdk/scripts/rpc.py iobuf_set_options --small-pool-count 8192 --large-pool-count 4096
/home/storage/spdk/scripts/rpc.py framework_start_init
/home/storage/spdk/scripts/rpc.py nvmf_create_transport -t RDMA -u 16384 -i 131072 -c 8192 -m 127 -q 4096 --acceptor-poll-rate 100
/home/storage/spdk/scripts/rpc.py bdev_aio_create /dev/nvme/nvme_stripe nvme_spdk --fallocate
/home/storage/spdk/scripts/rpc.py nvmf_create_subsystem nqn.2024-05.io.spdk:cnode1 -a -s SPDK00 -d SPDK
/home/storage/spdk/scripts/rpc.py nvmf_subsystem_add_ns nqn.2024-05.io.spdk:cnode1 nvme_spdk

Со стороны Mikrotik настройки в целом в сооветствии со статьёй с одним исключением. На уровне буфферов выстановлены следущие настройки:

Настройка буферов в микротике

Настройка буферов в микротике

Благодаря этому получилось полностью избавить от дропов (до этого при тестах на последотельную запись были дропы пакетов)

Итоговые показатели переданных пакетов за время тестов

Итоговые показатели переданных пакетов за время тестов

4.2 Raw Data

MDADM Raid0

MDADM Raid0

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU util [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

450 770.63

1 760.82

8.81%

0.10

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

321 877.10

1 257.33

10.61%

0.15

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

375 080.07

1 465.17

12.50%

0.10

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

0.15

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

88 269.87

5 516.88

13.67%

0.46

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

0.58

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

329 445.77

2 573.80

15.41%

0.10

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

0.16

Последовательная запись 256к

22 864.93

5 715.50

6.75%

2.21

Случайное 100% чтение 4k

488 403.93

1 907.25

12.70%

0.40

Случайное 70% чтение 30% запись 4k WRITE

486 361.39

1 899.50

18.49%

0.36

Случайное 70% чтение 30% запись 4k READ

0.41

Случайное 70% чтение 30% записи 8к WRITE

473 253.78

3 696.75

23.63%

0.39

Случайное 70% чтение 30% записи 8к READ

0.42

MDADM Raid5

MDADM Raid5

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU util [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

60 531.05

236.44

8.45%

0.82

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

308 500.73

1 205.08

9.89%

0.16

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

102 964.75

402.21

11.13%

0.69

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

0.24

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

21 025.80

1 314.11

12.02%

7.65

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

0.49

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

110 443.53

862.85

13.22%

0.98

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

0.25

Последовательная запись 256к

1398.76

349.00

7.77%

35.52

Случайное 100% чтение 4k

477 304.20

1 864.00

12.79%

0.41

Случайное 70% чтение 30% запись 4k WRITE

176 430.51

688.75

14.99%

1.95

Случайное 70% чтение 30% запись 4k READ

0.73

Случайное 70% чтение 30% записи 8к WRITE

61 383.76

479.25

15.81%

4.50

Случайное 70% чтение 30% записи 8к READ

1.83

LVM Raid0

LVM Raid0

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU util [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

459 686.88

1 795.65

17.01%

0.10

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

325 189.12

1 270.27

18.50%

0.15

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

374 578.24

1 463.19

20.74%

0.10

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

0.15

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

90 484.62

5 655.28

22.08%

0.47

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

0.58

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

328 563.80

2 566.91

24.30%

0.10

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

0.16

Последовательная запись 256к

21 587.40

5396.40

10.48%

2.28

Случайное 100% чтение 4k

485 780.49

1 897.20

14.57%

0.40

Случайное 70% чтение 30% запись 4k WRITE

473 075.11

1 847.40

18.85%

0.37

Случайное 70% чтение 30% запись 4k READ

0.42

Случайное 70% чтение 30% записи 8к WRITE

456 659.78

3 567.00

23.51%

0.40

Случайное 70% чтение 30% записи 8к READ

0.44

LVM Raid5

LVM Raid5

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU load [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

79463.13

310.40

12.51%

0.60

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

290 190.37

1133.56

14.09%

0.16

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

135 977.73

531.17

14.85%

0.55

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

0.16

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

32 461.10

2 028.82

16.05%

4.98

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

0.31

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

153 652.13

1 200.41

17.87%

0.75

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

0.17

Последовательная запись 256к

2 291.33

572.67

3.13%

22.19

Случайное 100% чтение 4k

181 423.16

708.00

4.63%

1.06

Случайное 70% чтение 30% запись 4k WRITE

124 911.17

487.00

6.03%

1.61

Случайное 70% чтение 30% запись 4k READ

1.50

Случайное 70% чтение 30% записи 8к WRITE

87 156.36

680.67

7.23%

3.12

Случайное 70% чтение 30% записи 8к READ

1.28

ZFS Stripe (Raid0)

ZFS Stripe

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU util [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

15 179.28

59.29

9.84%

3.16

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

72 292.00

282.39

11.32%

0.66

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

28 532.58

111.46

13.08%

1.73

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

1.63

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

19 079.55

1192.47

14.85%

1.82

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

2.74

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

38 681.13

302.20

16.68%

1.26

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

1.23

Последовательная запись 256к

4 202.06

1 050.00

6.96%

12.00

Случайное 100% чтение 4k

78 842.56

307.50

8.50%

2.45

Случайное 70% чтение 30% запись 4k WRITE

38 714.70

150.75

9.67%

5.04

Случайное 70% чтение 30% запись 4k READ

4.96

Случайное 70% чтение 30% записи 8к WRITE

28 630.00

223.25

10.52%

7.05

Случайное 70% чтение 30% записи 8к READ

6.43

ZFS RaidZ (Raid5)

ZFS RaidZ

NVMe-oF

IOPS

Bandwidth [MB/s]

CPU util [%]

latency [ms]

VDbench - 4k - 100% rng - 100% Write - 4 thread per disk

12 260.97

47.89

12.48%

3.91

VDbench - 4k - 100% rng - 100% read - 4 thread per disk

57 072.60

222.94

13.27%

0.84

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE

22 959.23

89.68

13.98%

2.14

VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ

2.06

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE

14 061.90

878.87

14.85%

2.13

VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ

3.84

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE

30 963.83

241.91

16.65%

1.58

VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ

1.54

Последовательная запись 256к

2 928.63

731.50

7.65%

16.96

Случайное 100% чтение 4k

61 621.75

240.50

8.61%

3.13

Случайное 70% чтение 30% запись 4k WRITE

30 315.13

118.00

9.56%

6.48

Случайное 70% чтение 30% запись 4k READ

6.38

Случайное 70% чтение 30% записи 8к WRITE

22 773.56

177.50

10.24%

9.23

Случайное 70% чтение 30% записи 8к READ

8.16

4.3 VDbench - 4k - 100% rng - 100% Write

(назад к оглавлению)
(назад к описанию теста)

График Latency на запись

График Latency на запись

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.4 VDbench - 4k - 100% rng - 100% read

(назад к оглавлению)
(назад к описанию теста)

График Latency на чтение

График Latency на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.5 VDbench - 4k - 80% rng - 50/50 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency, красный - запись, синий - чтение

График Latency, красный - запись, синий - чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.6 VDbench - 64k - 80% rng - 75/25 r/w

(назад к оглавлению)
(назад к описанию теста)

Красный график задержка на запись, синий на чтение

Красный график задержка на запись, синий на чтение

Вот тут наглядно видно, что mdadm не хватает ядер учитывая, что таргет NVMe скушал практически всё себе. LVM тоже не очень хорошо, даже с учётом всех особых условий

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.7 VDbench - 8k - 80% rng - 75/25 r/w

(назад к оглавлению)
(назад к описанию теста)

Красный график задержка на запись, синий на чтение

Красный график задержка на запись, синий на чтение

Суммарный график IO в МБ/с

4.8 FIO - 256k - 0% rng - 0/100 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency на запись

График Latency на запись

Ситуация схожа с 64k тестом, опять же mdadm не хватает CPU, но в отличии от LVM - он не ломает таргет, поэтому послабления не получил. Но ZFS конечно на последовательной записи большим асинхронным блоком в режиме рейда лидер, в конце концов ему достаточно положить блок в память, чтобы быть готовым принять следующим, в то время как mdadm и lvm прежде чем писать дальше нужно сперва записать предыдующий блок.

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.9 FIO - 4k - 100% rng - 100/0 r/w

(назад к оглавлению)
(назад к описанию теста)

График Latency на чтение

График Latency на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.10 FIO - 4k - 100% rng - 70/30 r/w

(назад к оглавлению)
(назад к описанию теста)

Красный график задержка на запись, синий на чтение

Красный график задержка на запись, синий на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.11 FIO - 8k - 100% rng 70/30 r/w

(назад к оглавлению)
(назад к описанию теста)

Красный график задержка на запись, синий на чтение

Красный график задержка на запись, синий на чтение

Суммарный график IO в МБ/с

Суммарный график IO в МБ/с

4.12 Сравнение софт рейдов

4.12.1 Raid 0

Общий график по Raid0. По вертикали МБ/с, по горизонтали тесты

Общий график по Raid0. По вертикали МБ/с, по горизонтали тесты

4.12.2 Raid 5

Общий график по Raid5. По вертикали МБ/с, по горизонтали тесты

Общий график по Raid5. По вертикали МБ/с, по горизонтали тесты

Вывод

mdadm показывает себя в Raid5 (если ему дать послабления в NVMe-oF как для ZFS), LVM в raid0. ZFS ваш выбор если у вас ВСЯ нагрузка это много-много асинхронного чтения\записи блоками по 64+кб.

Графическое представление NVMe-oF vs iSER

Зелёный - NVMe-oF
Бордовый - iSER

mdadm Raid0

Значения как и ожидались, NVMe-oF показывает результаты лучше по всем тестам, кроме mix r/w большим блоком, где показывается паритет

mdadm Raid5

Даже не смотря на нехватку ресурсов - mdadm с nvme-of всё ещё прекрасно себя чувствует в половине тестов.

LVM Raid0

Из интересной аномалии тут это не паритет 64кб операции, но он объясняется тем, что в случае с NVMe-oF у нас оставалась высокая задержка на запись 64кб блоком при одновременном чтении.

LVM Raid5

LVM с учётом особых условий демонстрирует ожидаемый эффект от NVMe-oF по всем тестам,

ZFS Stripe (Raid0)

С ZFS картина конечно сильно печальней, для сочетания NVMe-oF и ZFS однозначно нужен отдельный хост, потому что что таргет, что ZFS насилуют CPU только так. Количество ядер надо брать по количеству NVMe дисков + ещё нужно на таргет количество хостов / 2 округленное в большую сторону. Т.е. для 3 хостов минимум 2 ядра, для 5 - 3 ядра, и т.д.

ZFS RaidZ (Raid5)

Картина аналогичная Stripe, то так как RaidZ ещё более CPU intensive - iSER показывает однозначный выигрыш.

Итоговая картина NVMe-oF vs iSER с цветовой гаммой выглядит следующим образом, в ней показатели NVMe-oF поделены на iSER.

Raid0, NVMe-oF vs iSER

Raid0, NVMe-oF vs iSER

Raid5 NVMe-oF vs iSER

Raid5 NVMe-oF vs iSER

В столбце IOPS, если NVMe-oF / iSER >= 1, то это зелёный цвет (мы получили больше IOPS на NVMe-oF), в противном случае оттенок коричневого

В столбце Latency, если NVMe-oF / iSER <= 1, то это зелёный цвет (мы получили задержку ниже при использовании NVMe-oF), в противном случае оттенок коричневого

В столбце CPU Load, если NVMe-oF / iSER <= 1, то это зелёный цвет (мы получили показатели CPU USED на уровне кластера ниже при использовании NVMe-oF), в противном случае оттенок коричневого

Почему мы проигрываем по CPU, когда основная задача NVMe-oF разгрузить CPU? Потому что таргет SPDK работает по пуллинг механизму, а значит он работает всегда на 100% всех ядер, которые ему отдали, а CPU load указан для всего кластера, а не только для ВМ-ок. Если выносить SPDK на отдельную физическую машину, то CPU load тоже будет в зелёной зоне:

И в случае ZFS есть не менее интересный нюанс. Из-за того, что SPDK всегда использует, ядра что ему выдали на 100% - ZFS банально не хватает CPU на то, чтобы выполнить свои операции, из-за чего мы практически всегда проигрываем iSER таргету в ядре. Аналогичная ситуация с mdadm в рейде, но в отличии от ZFS ему не было послаблений в лице более жирной ВМ.