Pull to refresh

Comments 9

немного офтоп, но зачем базе 5.4?(!)…

Привет, это автор.

У Оракла есть своя линейка ядер. UEK.

5.4 это UEK6, 5.15 это UEK7.

В своей операционке для своей СУБД, для улучшенной поддержки технологии ASM на уровне ядра был встроен специальный драйвер, но после UEK6 от неё отказались

Oracle UEK7 Oracleasm kernel module has been removed (dbsysupgrade.com)

Плюсики за статью и информацию в ней, но мигающую картинку "Fail" я бы всё-таки убрал, т.к. сильно раздражает. Или заменил бы её на обычную картинку.

В массовой культуре не особо много прямых отсылок к панике ядра в Linux.

Только анимация из заставки "The IT Crowd" пришла в голову.

Поэтому gif анимация с фрагментом из начала именно этой заставки и была взята

Для получения более свежего NVMe стека на UEK6 можно попробовать задействовать NVidia/Mellanox OFED, который в частности бэкпортирует разнообразные модули с актуального ядра к реалиям различных дистрибутивов.

Касательно конфигурации подключения, модуль хоста (nvme) по-умолчанию включает функциональность native multipath и соответственно не очевидно, что выгоднее - жонглировать сетевым трафиком или же несколькими подключениями на уровне блочного I/O.

По поводу распределения дисков по отдельным подсистемам(subsystems), перекликаясь с предыдущим пунктом, можно утилизировать Asymmetric Namespace Access (ANA - 8.1 Asymmetric Namespace Access Reporting) , поскольку в текущей реализации модуля таргета(nvmet) поддерживается возможность указания до 128 ANA групп, в большинстве случаем можно назначить по группе на диск и таким образом атомарно контролировать к ним доступ для хостов.

На тему "одинаковых серийников" у namespace-ов подключаемой подсистемы, стоит обращать внимание на вывод в частности команды nvme id-ns где обитают параметры вроде NGUID, задуманными быть глобальными идентификаторами namespace-a независимо от того из какой подсистемы его отдают. На уровне udev правил может быть необходимость в доработке чтобы NGUID утилизировался как ID_SERIAL.

P.S. В целом для администрирования таргета разрабатывается утилита nvmetcli, хотя на мой взгляд она больше подходит для восстановления ресурсов на старте системы чем добавления/удаления отдельных.

P. P.S. Если самоцель была в отдаче NVMe дисков, то в RDMA варианте можно утилизировать поддержку PCI Peer-to-Peer DMA через указание параметра p2pmem.

Спасибо большое!
Конкретные версии ядра одобряются Ораклом для работы Оракла.
Поэтому и решено было перейти на 5.15, с заменой встроенной ASMLib на правила udev, а не на кастомизированное ядро.
Диски разбиваются на множество партиций одинакового размера. 3 терабайтные на 10, так надо команде DBA.

Они же и просили серийники, да и придумали это простое правило

NV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{DEVPATH}=="/devices/virtual*", ENV{ID_PART_ENTRY_NAME}=="asm*", PROGRAM="/bin/sh -c \"dev=echo %k | awk -F p '{print $1}' ; /sbin/nvme list-subsys $dev | /bin/grep traddr | /bin/sed 's/.*traddr=\([[:graph:]]*\).*/\1/'\"", SYMLINK+="asmdisk/remote_%c{1}_$env{ID_SERIAL_SHORT}_p$env{ID_PART_ENTRY_NUMBER}", OWNER="oracle", GROUP="dba", MODE="0660"

Для нужного им именования партиций

Если очередь и в правду была 1, то:
20000 IOPS - это 50 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 20000 IOPS )
50000 IOPS - это 20 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 50000 IOPS )

Я не нашел в доках "миссии" NVMe 2.0. Предположу, что оно создавалось для возможности эффективного использования NVMe по сети. И мне кажется , что цель достигнута. А доказательством можно считать разницу в 30 микросекунд между локальным диском и удаленным.

>>> Заявленный миллион IOPS на NVMe диске в таком сценарии превратился 50 тысяч для локального диска и 20 тысяч для диска, подключенного по NVMe OF.

Тут Вы не учли физику. Миллион в секунду - это 1 сек / 1000000 = 1 микросекунда на один ввод или вывод. Выши результаты показывают 20 микросекунд. Уточните у производителя как получить миллион. Скорее всего там тест был на чтение, да еще были прогреты файловый кэш или включен буфер. Производители часто не про маленькие, но важные детали.

>>>Тестирование производительности дисковой подсистемы производилось по наихудшему сценарию. 50/50 чтение/запись


Сходу не удалось найти материалов, но на сколько я помню для ssd худшим сценарием есть последовательная запись.

Sign up to leave a comment.