Предисловие скопировано из Part 1.
С момента прошлой статьи прошло 2 года (и за время написания статьи ещё полгода), за это время:
количество дисков в системе увеличилось до 8 PM9A3 1.92TB;
вышло несколько новых прошивок на PM9A3;
сеть обновилась с ConnectX-3 Pro 40G до ConnectX-4 100G;
В связи с этим - было решено заново провести тесты.
У данной статьи такие же две цели, как и у прошлой:
Протестировать производительность трёх систем объединения физических устройств в одно логическое, как для локального доступа к нему, так и для использования в качестве блочного массива для виртуализации.
Создание бэкэнда для кластера в виде одноконтроллерного хранилища.
Иными словами выводы данной статьи не применимы, когда Вам нужно:
Синхронное отказоустойчивое решение
Надежность >>> скорость
Долговременное решение, которое можно поставить и забыть
0. Оглавление
0) Оглавление
1) Описание тестового стенда
2) Общая настройка серверов
2.1) Особые условия
3) iSER
3.1) Raw Data
3.2) VDbench - 4k - 100% rng - 100% Write
3.3) VDbench - 4k - 100% rng - 100% read
3.4) VDbench - 4k - 80% rng - 50/50 r/w
3.5) VDbench - 64k - 80% rng - 75/25 r/w
3.6) VDbench - 8k - 80% rng - 75/25 r/w
3.7) FIO - 256k - 0% rng - 0/100 r/w
3.8) FIO - 4k - 100% rng - 100/0 r/w
3.9) FIO - 4k - 100% rng - 70/30 r/w
3.10) FIO - 8k - 100% rng 70/30 r/w
3.11) Сравнение софт рейдов
3.11.1) Raid0
3.11.2) Raid5
4) NVMe-oF
4.1) Проблемы Next-Next-Next для NVMe-oF
4.2) Raw Data
4.3) VDbench - 4k - 100% rng - 100% Write
4.4) VDbench - 4k - 100% rng - 100% read
4.5) VDbench - 4k - 80% rng - 50/50 r/w
4.6) VDbench - 64k - 80% rng - 75/25 r/w
4.7) VDbench - 8k - 80% rng - 75/25 r/w
4.8) FIO - 256k - 0% rng - 0/100 r/w
4.9) FIO - 4k - 100% rng - 100/0 r/w
4.10) FIO - 4k - 100% rng - 70/30 r/w
4.11) FIO - 8k - 100% rng 70/30 r/w
4.12) Сравнение софт рейдов
4.12.1) Raid0
4.12.2) Raid5
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
ВМ: Ubuntu 24.04 (6.11.0-26)
ZFS: 2.4.0
Схема подключения для тестов 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
Случайное 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
Случайное 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
Случайное 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
Конфигурация 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
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
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
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
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
Настройки хоста со стороны 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
(назад к оглавлению)
(назад к описанию теста)
3.3 VDbench - 4k - 100% rng - 100% read
(назад к оглавлению)
(назад к описанию теста)
3.4 VDbench - 4k - 80% rng - 50/50 r/w
(назад к оглавлению)
(назад к описанию теста)
3.5 VDbench - 64k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
3.6 VDbench - 8k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
3.7 FIO - 256k - 0% rng - 0/100 r/w
(назад к оглавлению)
(назад к описанию теста)
3.8 FIO - 4k - 100% rng - 100/0 r/w
(назад к оглавлению)
(назад к описанию теста)
3.9 FIO - 4k - 100% rng - 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
3.10 FIO - 8k - 100% rng 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
3.11 Сравнение софт рейдов
3.11.1 Raid0
Итогом стало лидерство LVM в тестах где нагрузка идёт в рамках пары дисков (vdbench) и аналогичное по % лидерство mdadm в тестах где есть множество дисков (8 штук). Также стоит отметить тот факт, что отключение Checksum даёт следующий прирост для производительности ZFS (порядка ~22%):
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
(назад к оглавлению)
(назад к описанию теста)
4.4 VDbench - 4k - 100% rng - 100% read
(назад к оглавлению)
(назад к описанию теста)
4.5 VDbench - 4k - 80% rng - 50/50 r/w
(назад к оглавлению)
(назад к описанию теста)
4.6 VDbench - 64k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
Вот тут наглядно видно, что mdadm не хватает ядер учитывая, что таргет NVMe скушал практически всё себе. LVM тоже не очень хорошо, даже с учётом всех особых условий
4.7 VDbench - 8k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
4.8 FIO - 256k - 0% rng - 0/100 r/w
(назад к оглавлению)
(назад к описанию теста)
Ситуация схожа с 64k тестом, опять же mdadm не хватает CPU, но в отличии от LVM - он не ломает таргет, поэтому послабления не получил. Но ZFS конечно на последовательной записи большим асинхронным блоком в режиме рейда лидер, в конце концов ему достаточно положить блок в память, чтобы быть готовым принять следующим, в то время как mdadm и lvm прежде чем писать дальше нужно сперва записать предыдующий блок.
4.9 FIO - 4k - 100% rng - 100/0 r/w
(назад к оглавлению)
(назад к описанию теста)
4.10 FIO - 4k - 100% rng - 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
4.11 FIO - 8k - 100% rng 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
4.12 Сравнение софт рейдов
4.12.1 Raid 0
4.12.2 Raid 5
Вывод
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.
В столбце 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 ему не было послаблений в лице более жирной ВМ.
5) Update 1. ZFS compression
Относительно ZFS и оставленной компресси по умолчанию:
Отключение компресси привело к следующим результатам, которые ложатся в 5% погрешность для большей части тестов по IOPS и latency, а вот по CPU load выигрыш получился приличный для последовательного записи и чтения в тестах FIO, где генерируемые данные имели параметр buffer_compress_percentage=50. В таблице сооветственно значения ZFS noLZ4 делённые на ZFS lz4 (табличные данные приведены в общей таблице) при подключение через iSER.
akirsanov
Спасибо за тесты, полезные цифры