Производительность блочного хранилища на основе софт рейдов (mdadm, LVM и ZFS) при использовании iSER и NVMe-oF

Первая статья была посвящена производительности со стороны локальной системы (https://habr.com/ru/articles/753322/).

Смысл данной статьи остаётся схожей, показать максимальную производительность, когда вопрос сохранности данных решается репликами или бэкапами.

Цель данной статьи протестировать производительность трёх систем объединения физических устройств в одну логическую группу при использовании iSER и NVMe-oF.

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

1. mdadm raid0

2. LVM stripe

3. ZFS stripe (default lz4)

А также самое функциональное решение из доступных бесплатных бэкэндов:

4. ZFS stripe с компрессией и дедупликацией

При подключении через iSER и NVMe-oF.

Оглавление:

1. Тестовый стенд

2. iSER

   2.1 MDADM

   2.2 LVM

   2.3 ZFS

3. NVMe-oF

   3.1 MDADM

   3.2 LVM

   3.3 ZFS

4. Вывод

1. Тестовый стенд:

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

• Motherboard: Supermicro H11SSL-i

• CPU: EPYC 7302

• RAM: 4x64GB Micron 2933MHz

• Сеть: 40GbE ConnectX-3 Pro, 10GbE/25GbE ConnectX-4 LN EN

• ОС: ESXi 7U3 build 20036586

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

• Motherboard: Tyan S8030 (ver 1GbE)

• CPU: EPYC 7302

• RAM: 4x64GB Micron 2933MHz

• Сеть: 40GbE ConnectX-3 Pro x2 (Один адаптер прокинут в ВМ)

• ОС: ESXi 7U3 build 21930508

ВМ хранения на сервере виртуализации #2, которая будет предоставлять блочный доступ для хоста 1 и хоста 2:

• ОС: Ubuntu 22.04, ядро 6.2.0-26 (mitigations=off)

• vCPU: 8

• RAM: 64GB (для ZFS расширена до 128ГБ)

• Диски: 6xPM9A3 1.92TB (обновлены до версии GDC5902Q)

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

Примечание: Для HCIbench отсутствует документация по тому как поменять код тестирования на использование /dev/nvme0nX, вместо /dev/sdX, в связи с этим тесты проводятся с использованием pvscsi.
Согласно тестам различие между pvscsi и nvme контроллером лежит в пределах погрешности измерения 5% (подробнее в таблице тестов) для версии 7U3, так как полноценный NVMe back-to-back был реализован только в 8U2, которая уже не поддерживается ConnectX-3 🙁

Параметр Prepare Virtual Disk Before Testing выставлено в значение Random. Тесты проводятся с использованием — 4 ВМ с двумя дисками по 100ГБ, 8 vCPU, 16GB RAM.

Для выбора тестов ориетиром для параметров были взяты значения из следующего источника.

• Тест 1:

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

• Тест 2:

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

• Тест 3:

  VDbench — 64k — 80% seq — 75/25 r/w — 8 thread per disk

• Тест 4:

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

• Тест 5:

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

Для тестирования падения скорости в результате добавления прослойки в виде ВМ использовались тесты из первой части, результаты ниже в таблице и графика (погрешность +-5%,):

Результаты тестов iperf3 между ConnnectX-3 Pro, выполнялись путём проброса ConnectX-3 Pro в ВМ на каждом из хостов, т.е. схема выглядит следующим образом:

Результатом стало:

Округляя в меньшую сторону, получаем:

34 Gbits/sec (или 4.25 Gbytes/s)

Относительно OFED. Для тестов также использовалась Ubuntu 20.04 с ядром 5.5 и установленным для него OFED, но Ubuntu 22.04.03 с ядром 6.2 продемонстрировала выше производительность и повторяемость в iperf3.

s1:  [ ID] Interval           Transfer     Bitrate         Retr s1:  [  5]   0.00-10.00  sec  15.2 GBytes  13.0 Gbits/sec  1062    sender s1: s1:  iperf Done. s2:  - - - - - - - - - - - - - - - - - - - - - - - - - s2:  [ ID] Interval           Transfer     Bitrate         Retr s2:  [  5]   0.00-10.00  sec  14.8 GBytes  12.7 Gbits/sec  1856    sender s2: s2:  iperf Done. s3:  - - - - - - - - - - - - - - - - - - - - - - - - - s3:  [ ID] Interval           Transfer     Bitrate         Retr s3:  [  5]   0.00-10.00  sec  10.0 GBytes  8.59 Gbits/sec  1027    sender

s1:  [ ID] Interval           Transfer     Bitrate         Retr s1:  [  5]   0.00-10.00  sec  13.4 GBytes  11.5 Gbits/sec  1705    sender s1:  [  5]   0.00-10.04  sec  13.2 GBytes  11.3 Gbits/sec          receiver s1: s1:  iperf Done. s2:  - - - - - - - - - - - - - - - - - - - - - - - - - s2:  [ ID] Interval           Transfer     Bitrate         Retr s2:  [  5]   0.00-10.00  sec  10.4 GBytes  8.93 Gbits/sec  2171    sender s2:  [  5]   0.00-10.05  sec  10.1 GBytes  8.61 Gbits/sec          receiver s3:  - - - - - - - - - - - - - - - - - - - - - - - - - s3:  [ ID] Interval           Transfer     Bitrate         Retr s3:  [  5]   0.00-10.00  sec  16.8 GBytes  14.5 Gbits/sec  1513    sender s3:  [  5]   0.00-10.04  sec  16.7 GBytes  14.3 Gbits/sec          receiver s3: s3:  iperf Done.

Сравнивания производительность NVMe дисков при их подключении напрямую в ОС или через VMware с PCIe passthrough можно говорить о том, что производительность не меняется, так как результаты находятся в пределах 2% погрешности.

Таблица excel по тестам дисков подключённых напрямую к физическому хосту и прокинутых в хост виртуализации.

Рассматриваться будет 2 сценария:

1. Выдача блочного устройства через iSER с помощью LIO (настройка осуществляется с помощью targetcli-fb с мастер ветки репозитория)

2. Выдача блочного устройства через NVMe-oF с помощью SPDK.

   Небольшое отступление — сперва планировалось использовать нативную реализацию ядра — nvmet (https://enterprise-support.nvidia.com/s/article/howto-configure-nvme-over-fabrics—nvme-of—target-offload), но она не поддерживается VMware (https://koutoupis.com/2022/04/22/vmware-lightbits-labs-and-nvme-over-tcp/ https://communities.vmware.com/t5/ESXi-Discussions/NVMEof-Datastore-Issues/td-p/2301440), поэтому был использован SPDK (https://spdk.io/doc/nvmf.html, https://spdk.io/doc/bdev.html)

2. iSER

Со стороны Linux:

В настройках LIO прописывается enable_iser boolean=true на уровне портала:

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

Дополнительно для девайса прописаны следующие опции (https://documentation.suse.com/ses/7/html/ses-all/deploy-additional.html):

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

Со стороны VMware:

esxcli rdma iser add

Затем настройка аналогична настройкам как для iSCSI массива.

Производительность mdadm с тестами FIO из первой части на 1 ВМ выглядит следующим образом:

Конечный график выглядит следующим образом:

2.1 MDADM

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=6 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1

2.2 LVM

lvcreate -i6 -I64 --type striped -l 100%VG -n nvme_stripe nvme

2.3 ZFS

v1 (without dedup)

zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=128k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1 zfs create -s -V 10T -o volblocksize=16k -o compression=lz4 nvme/iser

v2 (with dedup)

zpool create -o ashift=12 -O compression=lz4 -O atime=off -O dedup=on -O recordsize=128k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1 zfs create -s -V 10T -o volblocksize=16k -o compression=lz4 nvme/iser

3. NVMe-oF:

Со стороны Linux:

Помимо банальной установки SPDK (https://spdk.io/doc/getting_started.html), есть 1 нюанс. На момент написания статьи SPDK из мастера не работает с VMware по причине реализации проверки на параметр responder_resources == 0. Со стороны VMware этот параметр равен 1 (https://github.com/spdk/spdk/issues/3115). Поэтому необходимо собрать версию 23.05.x, поэтому процесс установки spdk будет начинаться не с — пофикшено в c8b9bba

git clone https://github.com/spdk/spdk --recursive modprobe nvme-rdma modprobe rdma_ucm modprobe rdma_cm scripts/setup.sh screen - либо другая сессия, либо можно написать демона, который будет запускать его сам build/bin/nvmf_tgt ctrl+a d - отключение от сессии screen и возврат в консоль scripts/rpc.py nvmf_create_transport -t RDMA -u 8192 -i 131072 -c 8192 scripts/rpc.py nvmf_create_subsystem nqn.2016-06.io.spdk:cnode1 -a -s SPDK00000000000001 -d SPDK_Controller scripts/rpc.py bdev_aio_create /dev/md0 md0 scripts/rpc.py nvmf_subsystem_add_ns nqn.2016-06.io.spdk:cnode1 md0 scripts/rpc.py nvmf_subsystem_add_listener nqn.2016-06.io.spdk:cnode1 -t rdma -a 10.20.0.1 -s 4420 scripts/rpc.py nvmf_subsystem_add_listener nqn.2016-06.io.spdk:cnode1 -t rdma -a 10.20.0.5 -s 4420

Со стороны VMware:

esxcli system module parameters set -m nmlx4_core -p «enable_rocev2=1» (в противном случае будет ошибка «Underlying device does not support requested gid/RoCE type.»)

Затем в веб создаётся VMware NVME over RDMA Storage Adapter, в controller задаётся IP адрес ВМ, указанный ранее, в поле порт — порт 4420

Производительность mdadm с тестами FIO из первой части на 1 ВМ выглядит следующим образом:

Конечный график выглядит следующим образом:

3.1 MDADM

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=6 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1

3.2 LVM

lvcreate -i6 -I64 --type stripe  -l 100%VG -n lvm_stripe stripe

3.3 ZFS

v1 (without dedup)

zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=128k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1 zfs create -s -V 10T -o volblocksize=16k -o compression=lz4 nvme/iser

v2 (with dedup)

zpool create -o ashift=12 -O compression=lz4 -O atime=off -O dedup=on -O recordsize=128k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1 zfs create -s -V 10T -o volblocksize=16k -o compression=lz4 nvme/iser

4. Вывод

LVM показывает самые высокие результаты, поэтому если брать его за 100%, то результаты тестов будут выглядеть следующим образом:

ZFS как и ожидалось демонстрирует не самые высокие результаты, но это, в том числе, связано с нагрузкой по CPU, но и в целом на это влияет тот факт, что ZFS не приспособлен для быстрой работы с NVMe.

Все результаты тестов доступны тут и таблица excel тут (да, все таблицы в архиве, так как гугл таблицы ломают формулы).

График всех тестов с группировкой по используемому протоколу подключения выглядит следующим образом (график дублируется из пункт 2 и 3)

График всех тестов с группировкой по используемому софт рейду

P.S. Если Вы считаете, что эти тесты неполные, в них что-то упущено или они некорректны — я открыт к любым предложениям по их дополнению.