Технология NVMe через различные фабрики (далее NVMeOF) оформлена в качестве стандарта летом 2016 года, она была встроена в пятую ветку ядра Linux.

Поэтому, когда было решено мигрировать объемные базы данных с легаси-решений на общедоступные платформы, возник вопрос — можно ли применить эту технологию увеличения дискового пространства для создания зеркал локальных дисков?

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

Меня зовут Алексей Дрожжов, я старший инженер в билайне, и в этом посте расскажу, как мы решали эту задачу.

Задача: подключить много дисков с нескольких серверов

• Основная машина-сервер баз данных (далее просто сервер)

• 128 процессорных ядер (число ядер влияет на работу NVMeOF), 24 локальных диска NVMe.

• 2 донора дисков (далее доноры) с 12 различными NVMe дисками, которые предстояло отдать на сервер баз данных.

• На каждой машине было установлено по 4 x 25Гб адаптера, с настроенным FRR. D В результате имелось по одному интерфейсному IP, который помогал утилизировать имеющиеся 4 интерфейса.

В качестве операционной системы был выбран дистрибутив Oracle Linux 8.8, с ядром Unbreakable Enterprise Kernel (uek) 5.15. Так как нужного функционала для сервера баз данных в этом ядре уже не было, то использовалось ядро, с которым поставлялся Oracle Linux 8.6. Предыдущая версия uek, основанная на ядре 5.4

Таблица с версиями uek ядер на сайте Oracle.

Варианты, описанные в сети (почему везде одна и та же картинка от оракла и всего один диск?)

Если поискать примеры настройки NVMEoF, то вроде бы описана масса вариантов.
Но все они сводятся к тому, что как где-то как транспорт используют RDMA, а где-то TCP.

Также разнообразие заключается в том, что может быть описание для Ubuntu-совместимых дистрибутивов, или для RedHat-совместимых, или же для обоих сразу.

Это очень похоже на обучение твисту учителем танцев-героем Моргунова в «Кавказкой пленнице»: правой ногой RedHat, левой ногой Ubuntu, а теперь попробуем обеими ногами одновременно!

Везде приводится одна и та же картина из блога по Oracle Linux, описывающего NVME oF

Да и на Хабре она же, например тут.

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

С чего-то надо начинать, ссылку на описание технологии дали, про картинку вспомнили, поэтому давайте тогда и свою инструкцию напишем!

Настройка подключения одного диска

До того как будет возможно подключить один диск, делаем настройку пре-реквизитов.

1. Открываем порт, который используется для транспорта (по умолчанию у Oracle закрыто все)

firewall-cmd --add-port=9100/tcp --permanent
systemctl restart firewalld

2. Подгружаем необходимые модули в ядро

modprobe nvmet
modprobe nvmet-tcp

Первый подключает nvme transport, второй его реализацию для tcp

Для того чтобы эти модули подключались после перезагрузки, их следует указать в файле настроек /etc/modules

После подключения модулей ядра для настройки соединения должны появиться конфигурационные директории и файлы в каталоге /sys/kernel/config/nvmet/subsystems

3. Включаем сервис nvmet для автоматического восстановления настроек раздачи дисков на доноре systemctl enable nvmet

Сохранить настройки, которые применятся после старта системы, можно через nvmetcli save, очистить текущие — через nvmetcli clear

На доноре должны быть созданы

• Порт. Cущность верхнего уровня, описывает параметры транспорта, используемого в NVMeOF

• Подсистема. Набор дисков, обладающий некими ограничениями (например, по доступу)

• Неймспейс. Набор атрибутов для диска из подсистемы

После этого можно раздать диск такой последовательностью

#Создание и настройка порта
mkdir /sys/kernel/config/nvmet/ports/1
cd /sys/kernel/config/nvmet/ports/1
echo 10.26.54.1 |sudo tee -a addr_traddr > /dev/null
echo tcp|sudo tee -a addr_trtype > /dev/null
echo 4420|sudo tee -a addr_trsvcid > /dev/null
echo ipv4|sudo tee -a addr_adrfam > /dev/null


#Создание и настройка подсистемы.
cd /sys/kernel/config/nvmet/subsystems
mkdir test
cd test
echo -n 1 > /sys/kernel/config/nvmet/subsystems/test/attr_allow_any_host

#Добавление диска в подсистему
cd namespaces ; mkdir 1; cd 1
echo -n /dev/nvme0n1 > device_path
echo -n 1 > enable

#Присоединение подсистемы к порту. Это даст возможность к ней подключится 
ln -s /sys/kernel/config/nvmet/subsystems/test/ /sys/kernel/config/nvmet/ports/1/subsystems/test

И подключить розданный диск с донора на сервере

Было

[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...

Подключаем и стало

[root@donor2 ~]# nvme connect -n test  -t tcp -a 10.26.54.1 -s 4420
[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme12n1         4fd8d16e6af65b4c8652 Linux                                    1           3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...

Интересные наблюдения:

[root@donor2 ~]# nvme disconnect-all
[root@donor2 ~]# ss | grep nvm | wc -l
0
[root@donor2 ~]# nvme connect -n test  -t tcp -a 10.26.54.1 -s 4420
[root@donor2 ~]# ss | grep nvm | wc -l
129

После подключения у нас открылось 129 соединений на порт 4420 (называется nvm-express). Это на 1 больше, чем число ядер на системе!

По умолчанию система nvme создает число очередей на подсистему, равное числу ядер в системе.

В документации на nvme connect указано, как можно менять число очередей на нужное.

Подключение нескольких дисков через единственную подсистему

Отключимся от дисков с донора на сервере через
nvme disconnect-all

Сбросим конфигурацию на доноре через
nvmetcli clear

Настроим заново раздачу дисков в подсистеме test, но на этот раз не одного диска, а двух

#Повторяем настройку порта, потому что nvmetcli clear её сбросил
mkdir /sys/kernel/config/nvmet/ports/1
cd /sys/kernel/config/nvmet/ports/1
echo 10.26.54.1 |sudo tee -a addr_traddr > /dev/null
echo tcp|sudo tee -a addr_trtype > /dev/null
echo 4420|sudo tee -a addr_trsvcid > /dev/null
echo ipv4|sudo tee -a addr_adrfam > /dev/null

cd /sys/kernel/config/nvmet/subsystems
mkdir test; cd test
echo -n 1 > /sys/kernel/config/nvmet/subsystems/test/attr_allow_any_host

cd namespaces ; mkdir 1; cd 1
echo -n /dev/nvme0n1 > device_path
echo -n 1 > enable


#Добавляем второй диск в подсистему
cd ..; mkdir 2; cd 2
echo -n /dev/nvme1n1 > device_path
echo -n 1 > enable

ln -s /sys/kernel/config/nvmet/subsystems/test/ /sys/kernel/config/nvmet/ports/1/subsystems/test

Подключим всё ту же подсистему на сервере

[root@donor2 ~]# nvme disconnect-all
[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
/dev/nvme3n1          22483D3A43B6         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...
[root@donor2 ~]# nvme connect -n test  -t tcp -a 10.26.54.1 -s 4420
[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme12n1         4546bfc0e35a1a5a8695 Linux                                    1           3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme12n2         4546bfc0e35a1a5a8695 Linux                                    2           3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...

Дисков теперь два, а не один. Появился новый неймспейс 2 (n2 вместо n1) у префикса имени диска nvme12.

У дисков одинаковый SN и модель Linux. Как-то не очень удобно их различать

Оценим увеличение числа дисков на систему

Проверим, как дела с портами.

[root@donor2 ~]# ss | grep nvm | wc -l
129

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

Проброс оригинальных атрибутов

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

[root@donor1 ~]# ls -1 /sys/kernel/config/nvmet/ports/1/subsystems/test/namespaces/2
ana_grpid
buffered_io
device_nguid
device_path
device_uuid
enable
revalidate_size

[root@donor1 ~]# ls -1 /sys/kernel/config/nvmet/ports/1/subsystems/test/
allowed_hosts
attr_allow_any_host
attr_cntlid_max
attr_cntlid_min
attr_model
attr_pi_enable
attr_serial
attr_version

Похоже, что в настройках подсистемы можно указать серийник и модель!

Давайте попробуем их обновить.

На доноре сделаем так

echo -n serial > /sys/kernel/config/nvmet/subsystems/test/attr_serial
echo -n model > /sys/kernel/config/nvmet/subsystems/test/attr_model

После чего переподключим диски!

[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme12n1         serial               model                                    1           3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme12n2         serial               model                                    2           3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...

Стало интереснее, но, видимо, у единственной подсистемы есть ограничения.

Недостатки работы c единственной подсистемой

При всей простоте настройки и подключения у простейшего подхода есть недостатки.

• Единственный серийник и модель не дают различить, какой диск — какой.

• Ограничение по числу очередей действует для всех дисков.

• Но самое значительное ограничение — чтобы отключить конкретный диск от сервера, надо отключать все, делать реконфигурацию на доноре и подключать полностью подсистему.

Смена подхода. Один диск - одна подсистема. Её преимущества

Решено было выделить один диск в отдельную подсистему. Имя подсистемы состоит из префикса донора и номера физического диска в системе. В таком случае можно присвоить раздаваемому диску свой серий ник и модель. Да и персонализировать номер неймспейса

Настраиваем раздаваемые диски

# Настройка порта без изменений
mkdir /sys/kernel/config/nvmet/ports/1
cd /sys/kernel/config/nvmet/ports/1
echo 10.26.54.1 |sudo tee -a addr_traddr > /dev/null
echo tcp|sudo tee -a addr_trtype > /dev/null
echo 4420|sudo tee -a addr_trsvcid > /dev/null
echo ipv4|sudo tee -a addr_adrfam > /dev/null

# Создаем посистему, актуализируем серийник и модель, присоединяем единственый диск

seq 0 11 | while read dn; do

cd /sys/kernel/config/nvmet/subsystems
mkdir ora1$dn
cd ora1$dn
echo -n 1 > attr_allow_any_host
nvme list | grep -w "nvme${dn}n1" | awk '{print "Lin-"$2}'>  attr_serial
nvme list | grep -w "nvme${dn}n1" | awk '{print "D1-"$3}'> attr_model
cd namespaces/

mkdir "1$dn"; cd "1$dn"

echo -n "/dev/nvme${dn}n1" > device_path; echo -n 1 > enable;

# Каждую подсистему, после конфигурации, присоединяем к порту
sudo ln -s /sys/kernel/config/nvmet/subsystems/ora1$dn/ /sys/kernel/config/nvmet/ports/1/subsystems/ora1$dn
done

Тут уже используется уникальный номер неймспейса вместо традиционной ‘1’. Он будет передан на сервер.

Присоединяем диски.

[root@donor2 ~]# seq 0 11 | while read dn; do nvme connect -n ora1$dn  -t tcp -a 10.26.54.1 -s 4420;done
[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1          22483D3A3682         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
...
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           0.00   B /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme12n1         Lin-22463D388D7F     D1-Micron_7450_MTFDKCC3T2TFS             10          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme13n1         Lin-22463D389E34     D1-Micron_7450_MTFDKCC3T2TFS             11          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme14n1         Lin-22483D3A3618     D1-Micron_7450_MTFDKCC3T2TFS             12          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme15n1         Lin-22463D388D8D     D1-Micron_7450_MTFDKCC3T2TFS             13          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme16n1         Lin-22483D39FD8D     D1-Micron_7450_MTFDKCC3T2TFS             14          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme17n1         Lin-22483D3A10DE     D1-Micron_7450_MTFDKCC3T2TFS             15          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme18n1         Lin-22483D3A10A3     D1-Micron_7450_MTFDKCC3T2TFS             16          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme19n1         Lin-22483D39EDC4     D1-Micron_7450_MTFDKCC3T2TFS             17          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme2n1          22463D37437C         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
/dev/nvme20n1         Lin-22483D39FD6E     D1-Micron_7450_MTFDKCC3T2TFS             18          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme21n1         Lin-22483D3A17F3     D1-Micron_7450_MTFDKCC3T2TFS             19          3.20  TB /   3.20  TB    512   B +  0 B   5.15.0-1
/dev/nvme22n1         Lin-22343D03026C     D1-Micron_7450_MTFDKCC1T6TFS             110         1.60  TB /   1.60  TB    512   B +  0 B   5.15.0-1
/dev/nvme23n1         Lin-22343D02FB9E     D1-Micron_7450_MTFDKCC1T6TFS             111         1.60  TB /   1.60  TB    512   B +  0 B   5.15.0-1
/dev/nvme3n1          22483D3A43B6         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
/dev/nvme4n1          22483D3A41D4         
...

Внутренняя нумерация неймспейса в имени диска после буквы ‘n’ для NVMe стала всегда 1. Логический же номер неймспейса в списке соответствует назначеному на доноре. Только он может становиться 0 в случае проблем с сетью, но об этом будет далее.

Каждому диску теперь соответствует своя подсистема, имя которой можно использовать в udev

[root@server rules.d]# cat 10-local.rules
SUBSYSTEM=="block",ATTRS{subsysnqn}=="donor0-0",SYMLINK+="remote100"
SUBSYSTEM=="block",ATTRS{subsysnqn}=="donor0-1",SYMLINK+="remote101"
SUBSYSTEM=="block",ATTRS{subsysnqn}=="donor0-2",SYMLINK+="remote102"

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

Ситуация с портами для 12 подсистем.

[root@donor2 ~]# ss | grep nvm | wc -l
1548
[root@donor2 ~]# bc
1548/12
129

При использовании уникальной подсистемы для каждого диска число открытых портов растет пропорционально числу подсистем. Каждый диск получает достаточное число очередей. Но 60 тысяч портов может не хватить для подключения большого числа дисков.

[root@donor2 ~]# bc
60000/129
465
60000/257
233

Если у вас 256 ядер, то вряд ли вы сможете подключить больше 230 дисков Это такая грубая оценка масштабируемости решения вверх.

Деструктивные тесты. Влияние настроек таймаутов.

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

Проблемы с сетью бывают всегда.

FRR отвечает за то, что один из адаптеров может отказать. В таком случае есть второй адаптер. Но возможен же случай полной потери сети. Спасибо FRR — его просто эмулировать, отключив только общий IP, можно продолжать наблюдать по ssh на реальный IP интерфейса за тем, что происходит.

А происходит следующее.

• Сервер достаточно быстро определяет, что команды до донора не доходят

• Меняет логический номер неймспейса, полученный с донора на 0, убирая информацию о серийнике и модели

[root@donor2 ~]# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1          22483D3A3682         Micron_7450_MTFDKCC3T2TFS                1           0.00   B /   3.20  TB    512   B +  0 B   E2MU110
/dev/nvme1n1          22483D2FA24F         Micron_7450_MTFDKCC3T2TFS                1           3.10  TB /   3.20  TB    512   B +  0 B   E2MU110
/dev/nvme10n1         22343D02BBCD         Micron_7450_MTFDKCC1T6TFS                1           1.55  TB /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme11n1         22343D02BB5D         Micron_7450_MTFDKCC1T6TFS                1           1.55  TB /   1.60  TB    512   B +  0 B   E2MU110
/dev/nvme12n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme13n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme14n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme15n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme16n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme17n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme18n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B
/dev/nvme19n1                                                                       0           0.00   B /   0.00   B      1   B +  0 B	

При восстановлении соединения напротив имен дисков появляются и неймспейс, и серийник с названием модели. Программы, выполнявшие IO, продолжают свою работу

Большое влияние на оперативность определения доступности дисков оказывают настройки таймаутов команды nvme connect. По умолчанию системе надо 10 минут, чтобы окончательно принять решение, что диск недоступен, но можно указать нужное значение через --ctrl-loss-tmo=30

Таймауты настраиваются только на стороне клиента. На раздающей стороне никаких таймаутов нет.

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

Принимающая диски система ведет себя в таком случае иначе.nvme list продолжает показывать серийник, модель и неймспейс до самого отключения. По истечении таймаута диск удаляется из системы. До истечения таймаута диск никак не меняет свой статус.

Решение о готовности технологии для промышленной эксплуатации. Oops. Пока не стоит

Хотя показатели скорости дисковых операций были очень хорошими (тестирование скорости отдельная тема), от использования технологии было решено отказаться.

Двойное отключение сети и восстановление подключения дисков вызывало на ядре uek 5.4 Oops, который, благодаря настройкам ядра для сервера баз данных, приводил к панике ядра и рестарту сервера баз данных.

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

Это касается исключительно решений на общедоступных компонентах, опенсорсе и базовом наборе команд nvme. Не просто так у каждого из крупных вендоров свой набор расширений.

See 'nvme help <command>' for more information on a specific command

The following are all installed plugin extensions:
  intel           Intel vendor specific extensions
  amzn            Amazon vendor specific extensions
  lnvm            LightNVM specific extensions
  memblaze        Memblaze vendor specific extensions
  wdc             Western Digital vendor specific extensions
  huawei          Huawei vendor specific extensions
  netapp          NetApp vendor specific extensions
  toshiba         Toshiba NVME plugin
  micron          Micron vendor specific extensions
  seagate         Seagate vendor specific extensions
  virtium         Virtium vendor specific extensions
  shannon         Shannon vendor specific extensions
  dera            Dera vendor specific extensions
  sfx             ScaleFlux vendor specific extensions
  transcend       Transcend vendor specific extensions
  zns             Zoned Namespace Command Set
  nvidia          NVIDIA vendor specific extensions
  ymtc            Ymtc vendor specific extensions'''

Общие впечатления

До того как обнаружили проблему с перезагрузкой сервера, на стадии деструктивных тестов была собрана ожидаемая конфигурация. 1 сервер с локальными 24 дисками (максимум для используемой модели) с подключением 48 дисков по NVMeOF, которые были поданы с 3 различных доноров, находящихся в различных стойках.

Тестирование производительности дисковой подсистемы производилось по наихудшему сценарию. 50/50 чтение/запись, размер блока 8k, размер очереди ввода-выводя выставленный в 1. Заявленный миллион IOPS на NVMe диске в таком сценарии превратился 50 тысяч для локального диска и 20 тысяч для диска, подключенного по NVMe OF.

Копирование в параллели нескольких дисков на другие диски того же размера для эмуляции миграции после аварии проблем с загрузкой сети не выявили. Полностью нагрузить 100 Гб сеть получилось только несколькими копиями iPerf3.

Ждать поддержки от вендорского продукта более свежих ядер, несколько наивно оптимистично.

Решили работать с тем, что есть. Перешли на ядро UEK7, основанное на 5.15, хотя и у оракла для UEK6 и появилась версия с улучшениями в NVMe-подсистеме, которые устранили причину нашей перезагрузки.

Попробовали пересчитать на сколько хватит заявленного ресурса NVMe дисков из спецификации (5 лет, при 3-кратной перезаписи всего диска за день).

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

Немножко поломали голову над тем, почему Micron 7450 заявляют о размере физического блока в 256 кб и чем нам это грозит. Спойлер: обновлением прошивки диска, после чего размер блока стал 4 кб.

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