Технология 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
Да и на Хабре она же, например тут.
На ней хорошо показано, что, куда и зачем ходит стрелочками кин-дза-дзашных цветов. Наверное, за этот оммаж культовому фильму её и любят приводить.
С чего-то надо начинать, ссылку на описание технологии дали, про картинку вспомнили, поэтому давайте тогда и свою инструкцию напишем!
Настройка подключения одного диска
До того как будет возможно подключить один диск, делаем настройку пре-реквизитов.
Открываем порт, который используется для транспорта (по умолчанию у Oracle закрыто все)
firewall-cmd --add-port=9100/tcp --permanent
systemctl restart firewalld
Подгружаем необходимые модули в ядро
modprobe nvmetmodprobe nvmet-tcp
Первый подключает nvme transport, второй его реализацию для tcp
Для того чтобы эти модули подключались после перезагрузки, их следует указать в файле настроек /etc/modules
После подключения модулей ядра для настройки соединения должны появиться конфигурационные директории и файлы в каталоге /sys/kernel/config/nvmet/subsystems
Включаем сервис 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 кб.
Основная причина продолжения: оно даже в таком виде, прямо из коробки (по инструкции выше) на базе доступных комплектующих в разы, не на порядок, а только в разы быстрее эксплуатируемых решений, построенных на решениях ушедших вендоров.