NVMe oF/TCP – новые возможности для корпоративной инфраструктуры

Введение
По прогнозам [15] продажи корпоративных SSD с использованием интерфейса PCIe/NVMe занимают бОльшую долю рынка (рис. 1). Спецификация NVMe™/TCP Transport Binding стала доступна для публичной загрузки в ноябре 2018 г. [1] и определила новый транспорт, добавленный в семейство уже ранее существующих транспортов NVMe™: PCIe®, FC, Infiniband и RDMA (рис. 2; здесь не представлен еще один транспорт – NVMe oF over Omni Path, имеющий незначительное присутствие на рынке). NVMe/TCP определяет маппирование (mapping) очередей NVMe, капсул NVMe oF и доставку данных по протоколу IETF TCP (Transport Control Protocol). Транспорт NVMe/TCP предлагает дополнительные улучшения, такие как встроенная целостность данных (DIGEST) и оперативная безопасность транспортного уровня (TLS, Transport Layer Security). NVMe/TCP обеспечивает эффективные сквозные операции NVMe между хостами NVMe oF и устройствами контроллера NVMe oF, соединенными между собой любой стандартной IP сетью с отличными характеристиками производительности и задержки. Это позволяет центрам обработки данных использовать существующую инфраструктуру Ethernet с многоуровневыми топологиями коммутаторов и традиционными сетевыми адаптерами Ethernet. NVMe/TCP предназначен для наложения на существующие программные реализации транспорта TCP, а также будущие реализации аппаратного ускорения. Программные драйверы узлов и контроллеров NVMe/TCP также доступны для внедрения как в среде ядра Linux, так и в среде SPDK [3, 4]. Обе реализации NVMe/TCP были разработаны для бесшовного подключения к существующим программным стекам NVMe и NVMe oF. ПО NVMe/TCP не требует какого либо специального оборудования/микропрограмм CPU для работы, хотя различные классы процессоров и сетевых адаптеров могут поддерживать различную производительность при развертывании NVMe/TCP. Для запуска NVMe/TCP необходимо установить хост NVMe/TCP и подсистему NVM. Программное обеспечение доступно с ядром Linux (v5.0) и SPDK (v.19.01), а также коммерческими оконечными устройствами NVMe/TCP. Основное значение появление стандарта NVMe/TCP – дать возможность воспользоваться преимуществами технологии NVMe, прежде всего, в части значительно бОльшей производительности и меньших задержек по сравнению с HDD (на базе команд ввода/вывода SCSI) при построении законченных (end to end) NVMe решений гораздо бОльшему числу потребителей на уже существующей инфраструктуре в условиях ограниченности бюджета (в основном, используя не проприетарную инфраструктуру). Привязывая протокол NVMe к TCP, NVMe/TCP обеспечивает эффективную сквозную передачу команд и данных между хостами NVMe oF и устройствами контроллерами NVMe oF по любым стандартным сетям TCP/IP на базе Ethernet. Крупномасштабные центры обработки данных могут использовать существующую сетевую инфраструктуру на базе Ethernet с многоуровневыми топологиями коммутаторов и традиционными сетевыми адаптерами. Основная ценность NVMe/TCP заключается в том, что он [17]:
– работает с любой стандартной сетью TCP/IP на основе Ethernet и не требует специальных сетей или оборудования;
– обладает высокой масштабируемостью, что позволяет выполнять крупномасштабные развертывания и операции на больших расстояниях;
– может использоваться для создания больших пулов хранения NVMe для дезагрегированных инфраструктур;
– может обеспечить производительность (пропускную способность и задержку), сравнимую с FC, при более низкой стоимости порта.
Оценка преимуществ использования NVMe/TCP в сравнении с реализациями NVMe на других транспортах при блочном доступе к данным представлена на рис. 3.
Проблема NVMe oF на основе Ethernet, особенно NVMe/TCP, заключается в том, что при масштабировании до сотен и тысяч конечных точек фабрики он по существу становится Интернетом вещей (IoT) в центре обработки данных. Реализации IoT требуют обнаружения, регистрации и настройки конечных точек с нулевым или минимальным вмешательством, поскольку выполнение этих действий вручную для тысяч конечных точек быстро становится трудоемким, подверженным ошибкам и крайне неэффективным с точки зрения затрат. Фабрика NVMeoF/FC отлично справляется с автоматическим обнаружением и регистрацией конечных точек. Чтобы NVMe/TCP стал жизнеспособной альтернативой FC в центре обработки данных, он должен предоставлять пользователям возможности обнаружения и регистрации конечных точек, подобные FC, а также возможности зонирования, подобные FC. Dell в составе рабочей группы консорциума NVMe совместно с другими членами в нее входящими разработала ряд спецификаций к основному стандарту NVMe для решения этой проблемы. ПО SmartFabric Storage (SFSS) от Dell Technologies помогает автоматизировать обнаружение и регистрацию хостов и подсистем с использованием NVMe/TCP.

Введение

Рис. 1. Продажи корпоративных SSD по интерфейсам [15].

Рис. 2. Архитектура различных транспортов NVMe oF.

Рис. 3. Преимущества использования NVMe/TCP в сравнении с другими транспортами.

Производительность NVMe/TCP в сравнении с iSCSI. Первоначальное внутреннее тестирование Dell дало следующие результаты (https://www.dell.com/en us/blog/the future of software defined networking for storage connectivity/):
• IOPs — NVMe/TCP обеспечивает в 2,5 3,5 раза больше операций ввода вывода по сравнению с iSCSI;
• Latency — NVMe/TCP задержка сократилась на 70 75%;
• CPU per IO — NVMe/TCP снижает загрузку CPU на 40–50%.

Предыстория NVMe-oF/TCP
NVMe (NonVolatile Memory express,  http://nvmexpress.org/) — это масштабируемый хост-контроллерный интерфейс, разработанный для удовлетворения требований клиентских и корпоративных систем, использующих PCIe для работы с flash-памятью/SSD. Спецификация интерфейса NVMe обеспечивает быстрый доступ к SSD-накопителям с прямым подключением. NVMe поддерживает до 64 КБ очередей ввода/вывода (I/O), при этом каждая очередь ввода/вывода поддерживает до 64 КБ команд. Кроме того, интерфейс NVMe обеспечивает поддержку нескольких пространств имен и включает в себя надежные отчеты об ошибках и возможности управления. NVMe — гораздо более эффективный протокол, чем SAS (последовательный системный интерфейс для небольших компьютеров) или SATA. В целом набор команд NVMe можно масштабировать для будущих приложений и не обременять устройство устаревшими требованиями поддержки.

Предыстория NVMe-oF/TCP

История развития транспортов NVMe представлена на рис. 4 [14]. Среди основных преимуществ NVMe:
–  нет практического ограничения на количество невыполненных команд (до 64K-1 очередей, каждая из которых содержит до 64K-1 необработанных команд);
–  поддержка многоядерных процессоров без блокировки (каждое ядро выделяет собственные очереди и прерывания);
–  эффективный механизм дверного звонка (doorbell) устраняет необходимость чтения регистров в пути ввода-вывода;
–  команды фиксированного размера 64 байта и завершения 16 байт, а также оптимизированные наборы команд обеспечивают быстрое и эффективное декодирование и выполнение команд;
–  внеочередная (out of order) обработка команд и доставка данных.
СХД получили многократный прирост скорости, когда появились первые массивы на основе NVMe SSD, но устройства по-прежнему общались с серверами используя протокол  SCSI, разработанный для HDD. В полной мере все преимущества использования NVMe SSD удалось достичь, когда стал поддерживаться сетевой протокол NVMe-oF как на стороне хоста, так и сетевой фабрикой и самим массивом. При этом остается большое поле для разработки дополняющих решений – ускорителей/адаптеров, связанных с поддержкой (ускорением) как самой функциональности SSD (например, “сбор мусора”, выравнивание износа SSD и др.), так и сервисов данных (компрессия, дедупликация и др.). Такие решения могут развиваться как на основе вычислительной мощности CPU (выделенных ядер) серверов (а также CPU в составе самих массивов), используемых для сервисов, так и на основе специализированных адаптеров (как правило, подключаемых по PCIe), реализуемых на базе FPGA, ASIC, RISC-V и CPU (x86, ARM и др.).
NVMe-oF обеспечивает масштабирование до тысяч устройств NVMe и увеличивает расстояние внутри центра обработки данных, через которое можно получить доступ к устройствам и подсистемам NVMe. Стандарт NVMe улучшает время доступа на несколько порядков по сравнению с реализациями, использующими устройства SCSI и SATA.
NVMe-oF разработан, чтобы использовать преимущества эффективности NVMe и распространять ее на фабрики. В целом снижается нагрузка на CPU стека ввода-вывода, а реализация NVMe относительно проста в различных средах фабрики. Кроме того, присущий очередям ввода-вывода NVMe параллелизм делает NVMe пригодным для реализации в очень больших фабриках.
NVMe-oF поддерживает согласованность архитектуры и программного обеспечения NVMe во всех конструкциях фабрики, предоставляя преимущества NVMe независимо от типа фабрики или типа энергонезависимой памяти, используемой целевым хранилищем.

Типы транспортов NVMe-oF
Консорциум NVMe разработал спецификацию NVMe over Fabric (NVMe-oF), чтобы удовлетворить потребность в масштабируемом решении для хранения при реализации блочного доступа  к хранилищу NVMe для более крупных серверных инфраструктур на большом расстоянии. NVMe-oF позволяет подключать устройства хранения к элементам сервера по схеме «многие ко многим», давая возможность развертывания больших объемов высокопроизводительных хранилищ.
NVMe-oF позволяет создать уровень абстракции между вычислительной инфраструктурой и инфраструктурой хранения, а также передавать команды и ответы NVMe на расстоянии через различные структуры на основе сообщений без необходимости перевода на стороне хоста или на стороне хранилища. На рис. 4а показаны различные типы транспортов NVMe [17].

Типы транспортов NVMe-oF

Фабрики с памятью
В фабриках на основе памяти команды, ответы и данные NVMe используют общую память между хостом и подсистемой хранения. Этот метод был в основном указан в исходном базовом стандарте NVMe, который определял, как команды и ответы NVMe сопоставляются с очередями в общей памяти на хосте через интерфейс PCIe. Этот метод известен как транспортная модель на основе памяти, в которой команды, ответы и данные передаются между памятью хоста и хранилищем путем выполнения явных операций чтения и записи памяти с использованием прямого доступа к памяти (DMA, Direct Memory Access) по внутренней высокоскоростной фабрике PCIe.

Фабрики с памятью

Фабрики на основе сообщений (Message-based fabrics)
В фабриках на основе сообщений команды, ответы и данные NVMe инкапсулируются и помещаются в зависящие от фабрики пакеты для передачи на расстояние в удаленную подсистему хранения. Существуют две определенные спецификации транспорта NVMe на основе сообщений:

Фабрики на основе сообщений (Message-based fabrics)

–  Fibre Channel (NVMe/FC) — NVMe-инициаторы (хостов)  с  FC HBA (Host Bus Adapters) могут получать доступ к целевым устройствам NVMe по выделенным фабрикам FC или через фабрики FC over Ethernet (FCoE). Стандарты Fibre Channel, которыми управляет Технический комитет T11 Международного комитета по стандартам информационных технологий (INCITS, International Committee for Information Technology Standards), описывает, как NVMe взаимодействует с FC. Организация NVM Express не управляет спецификацией транспорта NVMe/FC;
–  NVMe/TCP — это технология NVMe-oF, которая создает баланс между производительностью и стоимостью, поскольку она расширяет NVMe по всему центру обработки данных с использованием простых и эффективных сетей на основе Ethernet TCP/IP.

 

 

Гибридные фабрики памяти/сообщений (NVMe/RDMA)
NVMe/RDMA (удаленный прямой доступ к памяти) считается самым эффективным из типов транспорта NVMe-oF, поскольку приложения могут получать доступ к удаленной памяти без участия операционной системы хоста или стека сетевого программного обеспечения. Он может передавать данные напрямую без участия ядра и не потребляет дополнительных циклов CPU для обработки трафика ни на стороне сервера, ни на стороне хранилища. Основной недостаток сетей NVMe/RDMA в том, что они значительно усложняют развертывание инфраструктуры, управление и масштабируемость, сводя на нет первоначальные финансовые преимущества использования общих сетей на базе Ethernet.

Гибридные фабрики памяти/сообщений (NVMe/RDMA)

Рис. 4б. Критерии выбора NVMe-транспортов для различных нагрузок [17].

Рис. 4в. Прогноз IDC по использованию различных NVMe-транспортов (IDC “The NVMe over Fabrics Market Revenue Forecast: A Rapid Ramp Driven Pri-marily by NVMe/TCP”, July 2021)[17].

Существует три типа фабрик NVMe/RDMA:
–  NVMe over RDMA over Converged Ethernet (NVMe/RoCE);
–  NVMe over InfiniBand (NVMe/IB);
–  NVMe over iWarp (NVMe/iWarp).

На рис. 4б показаны различные целевые варианты использования транспортов NVMe-oF. NVMe/RDMA лучше всего подходит для высокопроизводительных и специализированных рабочих нагрузок, которые обычно встречаются в высокопроизводительных вычислительных средах (HPC), а также для прямой миграции подключенных хранилищ в развертывания Ethernet Bunch of Flash (EBOF). NVMe/RDMA предлагает более высокую производительность, но эта дополнительная производительность достигается за счет дополнительной сложности реализации. NVMe/TCP обеспечивает баланс между производительностью и стоимостью и позиционируется как «рабочая лошадка» NVMe-oF общего назначения. NVMe/FC хорошо подходит для существующих крупных FC-инфраструктур, выполняющих критически важные рабочие нагрузки [17].
IDC в своем исследовании (IDC “The NVMe over Fabrics Market Revenue Forecast: A Rapid Ramp Driven Primarily by NVMe/TCP”, July 2021) дала достаточно оптимистический прогноз по использованию NVMe/TCP-транспорта уже в ближайшие годы (рис. 4в).

Рекомендации по развертыванию NVMe/TCP
Передача команд NVMe по сети TCP требует особого внимания. Для передачи протокола NVMe на расстояние, в частности, Dell Technologies рекомендует обратить на следующие параметры для базовой сети:
–  используйте сети 25 GbE или выше для корпоративного уровня NVMe/TCP;
–  отделите трафик NVMe/TCP от общего трафика. Рассмотрите возможность изоляции трафика NVMe/TCP в отдельной физической сети или VLAN в целях безопасности;
–  внедрите jumbo-кадры, увеличив сетевой MTU по умолчанию с 1500 до 9000. В зависимости от рабочей нагрузки использование jumbo-кадров может обеспечить дополнительную пропускную способность, поскольку можно доставить больше данных меньшим количеством пакетов. Эта дополнительная пропускная способность может значительно сократить вычислительные затраты на обработку TCP-трафика. Jumbo-кадры требуют, чтобы все устройства в сети были совместимы с Jumbo-кадрами и имели включенные Jumbo-кадры. При реализации Jumbo-кадров установите MTU хоста и хранилища на 9000 и установите для коммутаторов более высокие значения (например, 9216), где это возможно;
–  используйте «плоские» сети, чтобы свести к минимуму задержку. В идеале массивы хоста и хранения должны сосуществовать в одной подсети и находиться на минимальном расстоянии друг от друга.

Рекомендации по развертыванию NVMe/TCP

NVMe 2.0 – новые возможности для корпоративных развертываний
Стандарты NVMe и NVMeoF постоянно развиваются некоммерческим сообществом NVMexpress (http://nvmexpress.org/), объединяющим всех мировых вендоров. Основные усилия здесь направлены на упрощение существующих протоколов, повышение их безопасности и производительности. В последнем случае это, прежде всего, в части обмена данными, автоматизации развертывания и др. В июне 2021 г. вышла спецификация NVMe 2.0, которая затронула не только базовый состав команд NVMe, но и определила отдельные спецификации транспортов NVMe.
Семейство спецификаций NVMe 2.0 (рис. 5, табл. 1) состоит [9] из нескольких документов, включая спецификацию NVMe Base, спецификацию Command Set (например, NVM Command Set specification, ZNS Command Set specification, KV Command Set specification), спецификации транспорта (например, PCIe Transport specification, Fibre Channel Transport specification, RDMA Transport specification и TCP Transport specification), спецификацию загрузки NVMe (NVMe Boot specification) и спецификацию интерфейса управления NVMe (NVMe Management Interface specification).
Спецификация NVM Express Base (NVM Express Base) определяет протокол для ПО хоста для взаимодействия с энергонезависимыми подсистемами памяти через различные memory-based и message-based транспорты.
Спецификация интерфейса управления NVM Express (NVMe-MI) определяет дополнительный интерфейс управления для всех подсистем NVM Express.
Спецификации набора команд ввода-вывода NVM Express определяют структуры данных, функции, страницы журналов, команды и значения состояния, расширяющие базовую спецификацию NVM Express. Спецификации транспорта NVM Express определяют привязку протокола NVMe, включая свойства контроллера, к определенному транспорту.
Спецификация NVM Express Boot (NVMe Boot) определяет конструкции и рекомендации по загрузке с интерфейсов NVM Express.
Технология NVMe® over Fabrics (NVMe-oF™) определяет общую архитектуру, которая поддерживает ряд приложений хранения данных для протокола блочного доступа NVMe через сетевые фабрики. Функции технологии NVMe-oF можно использовать на всех рынках — от клиентских развертываний до облачных. С выпуском спецификаций NVMe 2.0 спецификация NVMe-oF была разделена на базовую, а специфичные транспорты фабрики — TCP Transport, RDMA Transport и PCI Express® (PCIe®) Transport — были разбиты на свои собственные спецификации [13]. Индивидуальные транспортные спецификации позволяют NVM Express изолировать и независимо адаптировать транспорт для развития памяти и транспорта коммутационной сети  (см. рис. 4). Недавно реструктурированная базовая спецификация NVMe включает команды коммутационной сети, специфичные для управления устройствами коммутационной сети, такими как контроллеры обнаружения и другие [6].
Спецификация NVMe-oF была реструктурирована, чтобы облегчить добавление новых возможностей и изменений в спецификации, что позволило разработчикам ссылаться только на те части спецификации, которые имеют отношение к продукту, который они разрабатывают. Разработчикам больше не нужно смотреть на другие виды транспорта при реализации коммутационного устройства для конкретного транспорта, что позволяет упростить внедрение и развертывание технологии NVMe.

NVMe 2.0 – новые возможности для корпоративных развертываний

Рис. 5. Рестуктуризированное семейство спецификаций NVMe 2.0.

Основные возможности NVMe 2.0 [12]:–  спецификация ZNS (Zoned Namespaces) предоставляет интерфейс зонированного устройства хранения, который позволяет SSD и хосту совместно размещать данные. ZNS позволяет согласовывать данные с физическим носителем SSD, повышая общую производительность и снижая стоимость устройства, а также увеличивая емкость носителя, которая может быть доступна хосту. Спецификация Zoned Namespace Command Set определяет, как можно работать с твердотельными накопителями ZNS. Тремя важными эксплуатационными характеристиками ZNS SSD являются:

• зонированное пространство имен разделено на набор зон одинакового размера, которые представляют собой смежные неперекрывающиеся диапазоны адресов логических блоков;
• запись внутри зоны должна быть последовательной и начинаться с позиции “Write Pointer”;
• каждая зона должна быть стерта, прежде чем ее можно будет переписать;

зонированное пространство имен разделено на набор зон одинакового размера, которые представляют собой смежные неперекрывающиеся диапазоны адресов логических блоков;

запись внутри зоны должна быть последовательной и начинаться с позиции “Write Pointer”;

каждая зона должна быть стерта, прежде чем ее можно будет переписать;

–  набор команд KV (Key Value) обеспечивает доступ к данным на контроллере твердотельного накопителя NVMe с использованием ключа, а не адреса блока. KV позволяет приложениям напрямую взаимодействовать с приводом, используя пары ключ-значение, избегая накладных расходов на таблицы преобразования между ключами и логическими блоками;
–  типы пространств имен предоставляют механизм, позволяющий контроллеру NVMe SSD поддерживать различные наборы команд, которые определены как часть выпуска NVMe 2.0, а также пути для будущих наборов команд;
–  управление группами выносливости NVMe (NVMe Endurance Group Management) позволяет настраивать носители в группы выносливости, предоставляя детализированный доступ к твердотельным накопителям и улучшая контроль. Управление группами выносливости NVMe позволяет настраивать носители в группы выносливости и наборы NVM. Это обеспечивает детализацию доступа к SSD и улучшенный контроль. Endurance Group NVM были впервые представлены в NVMe 1.4, но у клиентов были ограниченные возможности для их настройки. Конфигурация должна быть либо жестко закодирована в прошивке накопителя, либо обрабатываться с помощью команд, специфичных для производителя. NVMe 2.0 предоставляет пользователям механизм для управления группами выносливости. Благодаря большему количеству настраиваемых параметров подсистема NVM может иметь большую гибкость, чтобы изолировать влияние производительности ввода-вывода и операции выравнивания износа для разных пользователей на общих дисках или массивах;
–  поддержка ротационных носителей обеспечивает поддержку жестких дисков на NVMe с обновлениями функций, возможностей управления и другими улучшениями, необходимыми для поддержки жестких дисков;
–  обновление прошивки нескольких контроллеров определяет поведение при обновлении прошивки в сложных системах с несколькими контроллерами;
–  усовершенствования функции отключения позволяют контролировать демонстрацию из системы управления корпусом для упрощения управления несколькими дисками одновременно;
–  команда Simple Copy копирует данные из одного пространства имен на диске, перенося операции копирования с нескольких исходных LBA на один целевой LBA;
–  32/64-битный CRC расширяет защиту информации и данных до 32- и 64-битных, что позволяет использовать новые типы метаданных;
–  Command Group Control предотвращает непреднамеренные изменения после инициализации системы и защищает систему от непреднамеренных или злонамеренных изменений;
–  спецификации NVMe 2.0 поддерживают обратную совместимость с предыдущими поколениями NVMe.

Набор команд NVMe® Key Value обеспечивает ключ к эффективности хранения данных [18, 19]
Набор команд NVM Express® Key Value (NVMe-KV), ратифицированный в июне 2020 года, обеспечивает доступ к данным пространства имен на NVMe® SSD используя ключ, а не адрес логического блока.
Набор команд NVMe-KV получает свое название, потому что его данные обрабатываются ключом, который позволяет пользователям получить доступ к значениям данных переменного размера (например, объекту) и обойти накладные расходы хоста, поддерживающего таблицу преобразования. Ключ может обращаться к данным от одного байта до значительно большого объема данных (например, мегабайт).

Набор команд NVMe® Key Value обеспечивает ключ к эффективности хранения данных [18, 19]


®

Набор команд NVMe-KV повышает производительность системы хранения данных
Ключ передается непосредственно на устройство (вместо маппирования на хосте ключа к нескольким логическим блокам). Такой подход увеличивает количество транзакций в секунду, экономит вычисления на хосте и удаляет уровень трансляции, что приводит к повышению производительности.
Еще одним преимуществом является то, что набор команд NVMe-KV устраняет накладные расходы на подготовку. Для логического блочного устройства с over provisioned (с избыточным выделением ресурсов, то есть больше логических адресов, чем есть физического пространства) необходимо отменить выделение логических блоков, если хотите их повторно использовать. Хранилище Key Value позволяет обойти этот шаг; когда удаляется пара ключ-значение, это физическое пространство хранения теперь является непрерывной частью физического хранилища и может снова использоваться для другой пары ключ-значение, не беспокоясь о том, что вы повторно используете для него тот же механизм адр

Набор команд NVMe-KV повышает производительность системы хранения данных

Набор команд NVMe-KV предназначен для ключевых отраслевых сценариев использования
Key Value — это эффективный способ поддержки различных протоколов объектного хранилища на уровне устройства и архитектуры. Все приложения, использующие формат объектного хранилища, получат выгоду от Key Value — примерами этого являются Ceph, RocksDB и другие приложения такого рода, имеющие дело с объектами.
Если хранятся записи, связанные с уникальным идентификатором, таким как медицинская карта или номер сотрудника, то ключом становится номер медицинской карты или номер сотрудника, и он индексируется непосредственно ко всей записи для этой конкретной информации.
Еще один вариант использования связан с вычислительными задачами хранения (computational storage). Например, при выполнении вычисления на образе (picture) можно передать ключ, и этот ключ указывает на всю картину (вместо того, чтобы отправлять ей целую кучу логических блоков и длину логических блоков, которые составляют эту картину).
Это всего лишь несколько примеров многих приложений, к которым может применяться набор команд NVMe-KV. Мы с нетерпением ждем возможности увидеть, как набор команд NVMe-KV используется в реальном мире по мере появления новых вариантов использования.

Набор команд NVMe-KV предназначен для ключевых отраслевых сценариев использования

Новые функции повышения безопасности фабрики и упрощения развертывания NVMe 2.0
Несколько новых функций безопасности и управления были представлены с выпуском спецификаций NVMe 2.0. Например, внутриполосная аутентификация была добавлена для повышения безопасности и предотвращения спуфинга (spoofing), позволяя хосту проверять в хранилище, что он тот, за кого себя выдает, и наоборот. Кроме того, безопасность на транспортном уровне (TLS), которая используется HTTP для TCP-трафика, теперь доступна до версии 1.3 и защищает связь между хостом и NVMe через устройства хранения TCP fabric.
Добавлены новые возможности для улучшения и автоматизации процесса обнаружения NVMe-oF-устройств. Первая упрощает действия, выполняемые хостом во время обнаружения. Еще одна новая возможность позволяет автоматически обнаруживать NVMe/TCP устройства хостами. Это подобно тому, как сетевые принтеры обнаруживаются хостами. Наконец, была создана возможность централизованной точки управления (CDC) для управления доступом к NVMe/TCP-устройствам  [6]. Последняя функциональность активно развивалась представителями HPE и Dell в составе т.н. решений SmartFabric, которые уже представлены на рынке.
Всего для автоматизации развертывания разработано/разрабатываются 3 стандарта:
–  Automated Discovery of NVMe-oF Discovery Controllers for IP Networks (TP 8009 – ratified);
–  NVMe-oF Centralized Discovery Controller (TP 8010 – ratified);
–  NVMe-oF Discovery Enhancements – Subsystem Driven Zoning with Pull Registrations (TP 8016 – в разработке).
Все 3 стандарта обнаружения применимы только к IP-транспортам фабрик.

Новые функции повышения безопасности фабрики и упрощения развертывания NVMe 2.0

Рис. 6. Automated Discovery of NVMeoF Discovery Controllers for IP Networks.

Automated Discovery of NVMe-oF Discovery Controllers for IP Networks
Спецификация TP 8009  (автоматическое обнаружение и регистрация конечных точек NVMe-oF с использованием mDNS) определяет механизм автоматического обнаружения для конечных точек хоста и подсистемы для динамического обнаружения CDC с использованием [17]:
–  сервисов Multicast Dynamic Naming Services (mDNS), определенных интернет-стандартами RFC 676, которые представляют собой многоадресный протокол для доступа к сохраненной информации DNS;
–  сервисов  DNS Service Discovery (DNS-SD), определенных интернет-стандартами RFC 6763, которые определяют формат сервиса discovery information для хранения в DNS.
Эти два механизма широко используются для автоматического обнаружения таких устройств, как бытовая техника, термостаты, лампочки и датчики в Интернете вещей.

Automated Discovery of NVMe-oF Discovery Controllers for IP Networks

Преимущества, которые предоставляет спецификация (рис. 6, [14]):
–  упрощение провижининга хостов, позволяя им обнаруживать NVMe®/TCP Discovery контроллеры;
–  IP-адрес контроллера обнаружения может быть определен:

• через административную конфигурацию;
• средствами вне спецификации;
• через новую возможность, которая использует запись службы обнаружения доменных имен (DNS-SD, Domain Name System Service Discovery).

через административную конфигурацию;

средствами вне спецификации;

через новую возможность, которая использует запись службы обнаружения доменных имен (DNS-SD, Domain Name System Service Discovery).

Рис. 7. NVMe-oF Centralized Discovery Controller.

Рис. 8. Использование централизованного контроллера обнаружения (CDC) позволяет упростить развертывание в средах, начиная от 64 хостов [10].

NVMe-oF Centralized Discovery Controller
Спецификация TP 8010  основана на механизмах автообнаружения, определенных в TP 8009. Кроме того, она определяет следующие возможности, подобные FC, в CDC, позволяя:
–  CDC агрегировать информацию об обнаружении для узлов и подсистем NVMe-oF (NVMe/TCP) с помощью механизма регистрации (Naming Services). Эта функциональность эквивалентна Fibre Channel Naming Services;
–  группировать информацию о хосте и подсистеме для контроля доступа (зонирования), что позволяет управлять ресурсами. Эта функциональность эквивалентна Fibre Channel Zoning;
–  генерировать AEN для сообщения об изменениях в фабрике. Эта функциональность эквивалентна Fibre Channel Registered State Change Notifications (RSCN).

NVMe-oF Centralized Discovery Controller


 

Основные функции спецификации (рис. 7, [14]):
–  обеспечение discovery информацией для консолидации и возможности ее извлечения из единой службы обнаружения (Discovery Service) за счет:

• централизованного контроллера обнаружения (CDC, Centralized Discovery Controller), который сообщает информацию об обнаружении, зарегистрированную контроллерами прямого обнаружения (Direct Discovery Controllers) и хостами;
• контроллера прямого обнаружения (DDC, Direct Discovery Controller);

централизованного контроллера обнаружения (CDC, Centralized Discovery Controller), который сообщает информацию об обнаружении, зарегистрированную контроллерами прямого обнаружения (Direct Discovery Controllers) и хостами;

контроллера прямого обнаружения (DDC, Direct Discovery Controller);

–  DDC регистрируется в CDC одним из следующих способов:

• push-регистрации с использованием команды Discovery Information Management;
• уведомления CDC о необходимости регистрации по запросу;
• Administration configuration.

push-регистрации с использованием команды Discovery Information Management;

уведомления CDC о необходимости регистрации по запросу;

Administration configuration.

Использование CDC с NVMe-oF™ на IP-фабриках, таких как NVMe/TCP и NVMe/RDMA, позволяет преодолеть проблемы обнаружения и может обеспечить значительные преимущества в средах приложений (от edge до центра обработки данных). Используя автоматическое обнаружение, каждый хост и подсистема SAN на базе IP NVMe автоматически обнаруживает CDC, который объединяет информацию об обнаружении и ограничениях подключения для всех хостов и подсистем. Упрощая и автоматизируя процесс обнаружения и обеспечивая административную настройку ограничений подключения с помощью зонирования фабрики NVMe в SAN на базе IP NVMe, среды центров обработки данных могут испытывать меньшие накладные расходы за счет более централизованной системы. Автоматизация обнаружения и зонирование фабрики NVMe обеспечивают эволюцию существующего обнаружения хостов за счет более эффективного использования существующих функций [10] (рис. 8).
Пример автоматизированного развертывания для решений Dell на базе SmartFabric Storage Software (SFSS) представлен в [11]. Клиенты могут настраивать отношения между хостом и подсистемой посредством зонирования, как и в случае Fibre Channel (FC).
Простота развертывания, особенно в средах средних и крупных предприятий, является основной причиной, по которой некоторые пользователи предпочитают FC другим IP-технологиям, несмотря на потенциал экономии и повышение производительности. Для развертывания сетевой инфраструктуры затраты на Ethernet в некоторых решениях до 89% ниже, чем на FC (на основе расчетов внутреннего исследования Dell, сентябрь 2022 г. Фактические результаты могут отличаться). Dell сообщает, что внедрение Dell EMC PowerSwitch и SmartFabric Services (SFS) может использоваться для автоматизации настройки уже установленных у клиентов коммутаторов, составляющих их NVMe IP SAN (https://www.dell.com/en-us/blog/the-future-of-software-defined-networking-for-storage-connectivity/).

Преимущества NVMe 2.0 для корпоративных рынков
Функция доменов и разделов, которая позволяет создавать систему хранения данных из нескольких доменов, дает возможность поддерживать новые варианты использования корпоративных массивов и подсистем хранения данных [7].
Спецификации NVMe 2.0 обновили информацию о защите, чтобы теперь поддерживать 32-разрядные и 64-разрядные CRC, что обеспечивает более надежную защиту данных для крупномасштабных систем хранения данных.
Спецификация NVMe 2.0 дает возможность использовать преимущества таких новых функций как Endurance Group Management, которые открывают возможности использования и управления устройствами типа QLC.
Технология NVMe-oF позволяет удаленным устройствам в сети выглядеть как локально подключенные устройства, что критически важно для поддержки дезагрегированного подхода к хранению.
В дополнение к повышению производительности системы хранения данных, еще одним преимуществом внедрения технологии NVMe на предприятии является то, что она обеспечивает большую гибкость для разработчиков. Крупная реорганизация спецификаций NVMe 2.0 делает их более полными для разработчиков. Эти переработанные спецификации дали разработчикам возможность смешивать и сочетать различные флэш-технологии и позволяют разработчикам работать с обоими одновременно через один и тот же интерфейс. Эта гибкость будет способствовать более широкому внедрению технологии NVMe на всех рынках, включая корпоративные.

Преимущества NVMe 2.0 для корпоративных рынков

see here now

Новая система команд NVMe в составе базовой спецификации
До выпуска спецификаций NVMe 2.0 набор команд NVM был единственным набором команд для выполнения операций чтения/записи и требовался для реализации устройств блочных хранилищ NVMe. Теперь, с доступностью набора команд зонированного пространства имен и набора команд значения ключа, есть три механизма на выбор. При написании спецификации устройство может выбрать поддержку любой комбинации наборов команд. Хост может выбрать, какая комбинация подходит, и поддерживать по одному за раз, любую комбинацию из двух за раз или даже трех за раз. При этом следует иметь в виду, что любое существующее пространство имен связано только с одним набором команд [8].
Спецификация NVM Command Set фактически является набором команд block address, который уже существовал в спецификации NVMe 1.4 Base. В спецификации NVM Command Set есть несколько новых функций. Во-первых, функция Copy Command была реализована для экономии времени передачи для хоста. Ранее, если узлу приходилось копировать данные из одного места в другое в пространстве имен, узел выполнял операцию чтения, переносил данные куда-нибудь, а затем выполнял еще одну запись данных на адрес логического блока (LBA). Теперь с помощью команды Copy Command контроллер может выполнить это внутренне без необходимости передачи данных.
Планируется добавление расширения (Cross Namespace Copy, TP4130) к Copy Command  в течение 2023 г. (см. рис. 8) для копирования данных между пространствами имен. “Original” Copy Command выполняется только для одного пространства имен. “Enhanced” Copy Command может собирать данные из одного или множества пространства имен в целевое пространство имен (рис. 9).
Copy Command не переформатирует данные:
–  формат данных логического блока и метаданных должен быть одинаковым;
–  тип и размер сквозной (End-to-End) защиты данных должны быть одинаковыми;
–  Logical Block Storage Tag Mask и Storage Tag Size должны совпадать.
Во-вторых, теперь есть возможность создать бОльшую защиту информации и обеспечить 64-битный и 32-битный CRC, что поддерживает большую надежность для передачи и хранения данных для хоста.
Спецификация набора команд NVM общедоступна на сайте NVM Express (https://nvmexpress.org/) вместе со спецификациями zoned Namespace и Key Value Command Set (https://nvmexpress.org/developers/nvme-command-set-specifications/).

Новая система команд NVMe в составе базовой спецификации

Рис. 9. Расширение Copy Command – Cross Namespace Copy.

Рис. 10. Направления развития NVMe [14].

Дальнейшие направления развития стандарта NVMe 2.0
Ближайшие направления развития функциональности NVMe были представлены председателем NVMe® Technical Workgroup Питером Онуфриком (Peter Onufryk, научный сотрудник Intel) осенью 2022 г. [14] (рис. 10).

Дальнейшие направления развития стандарта NVMe 2.0

Поддержка архитектуры Computational Storage
Поддержка архитектуры Computational Storage даст возможность полностью распараллелить работу с разными SSD, устраняя “узкое место” при работе памятью, и добиться (рис. 11):
–  более высокой производительности и меньшей задержки благодаря параллельной работе нескольких SSD;
–  cнижения энергопотребления из-за меньшего перемещения данных;
–  более высокой производительности и уменьшенной задержке благодаря устранению узких мест процессора ввода-вывода и памяти.

Поддержка архитектуры Computational Storage

Рис. 11. Поддержка архитектуры Computational Storage интерфейсом NVMe по
зволяет полностью распараллелить работу с SSD.

Computational Programs (TP4091, TP4134)
Завершение разработки этой функциональности планируется в 2024 г. Она позволит (рис. 12):
–  стандартизировать фреймворки для computational storage;
–  ввести новый набор команд для работы с Compute Namespaces:

Computational Programs (TP4091, TP4134)

• фиксированные функциональные программы (Fixed function programs);
• загружаемые программы;

фиксированные функциональные программы (Fixed function programs);

загружаемые программы;

–  набор команд для Memory Namespaces и Subsystem Local Memory:

• требуется для computational programs, но является новым общим архитектурным элементом NVMe;
• механизм копирования в/из другого типа пространство имен NVM любого другого типа в пространства имен памяти.

требуется для computational programs, но является новым общим архитектурным элементом NVMe;

механизм копирования в/из другого типа пространство имен NVM любого другого типа в пространства имен памяти.

Рис. 12. Пример операций computational programs.

Пример операций представлен на рис. 12:
(1)       чтение данных из пространства имен NVM в пространство имен памяти;
(2)       выполнение программы, связанной с computational namespace;
(3)       программа считывает данные из пространства имен памяти;
(4) программа сохраняет результат в пространство имен памяти.

Рис. 13. Опция NVMe Flexible Data Placement.

Flexible Data Placement (TP4146)
Ратификация опции Flexible Data Placement – 1 кв. 2023 г. Flexible Data Placement даст возможность (рис. 13):
–  расширить набор команд NVM, что позволит размещать данные под управлением хоста;
–  работы с Reclaim Unit (RU) — единицей хранения NVM, которую можно независимо читать, записывать и стирать;
–  работы с Reclaim Groups (RG) — независимой коллекцией одного или нескольких RU:

Flexible Data Placement (TP4146)

• ограниченное вмешательство между RG;
• каждая RG имеет один или несколько дескрипторов блока возврата (RUH, Reclaim Unit Handles), каждый из которых указывает на RU;

ограниченное вмешательство между RG;

каждая RG имеет один или несколько дескрипторов блока возврата (RUH, Reclaim Unit Handles), каждый из которых указывает на RU;

–  использовать директиву о размещении данных (Data Placement Directive), которая позволяет хосту указывать RG и RU, где размещать записанные данные.

Поддержка распределенных пространств имен (Dispersed Namespaces, TP 4034)Dispersed Namespaces – это новая
функциональность, которая появилась в 2022 г. (рис. 14). Определения:
–  подсистема NVM включает один или несколько контроллеров, ноль или несколько пространств имен и один или несколько портов;
–  контроллер – это интерфейс между хостом и подсистемой NVM;
–  пространство имен – это отформатированное количество энергонезависимой памяти.
Распределенное пространство имен — это общие пространства имен, к которым могут одновременно обращаться контроллеры в двух или более подсистемах NVM. При этом:
–  страница журнала/лога содержит список NQN для всех подсистем NVM, содержащих контроллеры, способных получить доступ к распределенным пространствам имен;
–  подсистема NVM может поддерживать резервирование распределенных пространств имен.

Поддержка распределенных пространств имен (Dispersed Namespaces, TP 4034)

Примеры приложений с использованием функции Dispersed Namespaces представлены на рис. 15.

Рис. 14. Опция NVMe Dispersed Namespaces.

Рис. 15. Примеры приложений с поддержкой опции NVMe Dispersed Namespaces.

Subsystem Local Memory (TP4091, TP4134)
Разрабатывается для работы с байтадресуемой памятью, например, через SDK eBPF (например, используется при работе с загружаемыми программами). Это расширение системы команд памяти и пространства имен памяти (Memory Namespaces). Subsystem Local Memory требуется для computational programs, но представляет новый архитектурный элемент NVMe®. Это механизм копирования в/из пространство имен NVM любого другого типа в пространство имен памяти (рис. 16).

Subsystem Local Memory (TP4091, TP4134)

Рис. 16. Функция Subsystem Local Memory.

Scalable Resource Management (TP6011)
Scalable Resource Management определяет стандартный фреймворк для динамического создания, настройки и предоставления «экспортированных» подсистем NVM из базовых (underlying) физических ресурсов в «базовую» (underlying) подсистему NVM (рис. 17, [14]).
Новые команды администратора, которые позволяют:
–  cоздавать и управлять подсистемой Exported NVM;
–  управлять экспортируемыми пространствами имен;
–  управлять экспортируемыми портами.
Scalable Resource Management также дает возможность управлять доступом хоста к экспортированной подсистеме NVM с помощью «Списка разрешенных хостов» (“Allowed Host List”).

Scalable Resource Management (TP6011)

Рис. 17. Функция Scalable Resource Management.

Network Boot / UEFI (TP8012, TP4126)
Эта опция дает возможность загрузки ОС через транспорт NVMe-oF™ и представляет собой спецификацию загрузки.
Network Boot / UEFI – это стандартизированное решение от нескольких поставщиков для загрузки компьютерных систем из образов ОС, хранящихся на устройствах NVMe в сети. Это критично для крупных развертываний. Опубликованная спецификация загрузки NVM Express® и партнерство с экосистемой UEFI и ACPI позволяют это сделать за счет использования стандарта NVMe-oF.
В марте 2023 г. был представлен доклад  [16] представляет собой погружение в детали новой спецификации и разработку прототипа с открытым исходным кодом для загрузки через транспорт NVMe/TCP с использованием реализации UEFI.
Зачем технологии NVMe® нужна спецификация загрузки? В настоящее время успешные сетевые технологии хранения, такие как Fibre Channel и iSCSI, имеют стандартизированные решения, которые позволяют подключенным компьютерным системам загружаться с образов ОС, хранящихся на узлах хранения. Отсутствие таких стандартизированных возможностей в транспорте NVMe over Fabrics (NVMe-oF™) стало препятствием для его внедрения.
В загрузке через транспорт NVMe®/TCP был стандартизован прошлый опыт загрузки через iSCSI и возможности экосистемы:
–  при загрузке с поддержкой iSCSI передача ОС осуществлялась с помощью механизма, называемого «Таблица микропрограмм загрузки iSCSI» (iBFT, “iSCSI Boot Firmware Table”);
–  при загрузке с поддержкой iSCSI iBFT содержит информацию, которая будет использоваться совместно BIOS/предзагрузочными средами и ОС.
При разработке стандарта загрузки через  NVMe® и NVMe-oF™ Namespaces был использован этот уже отработанный механизм, адаптированный для транспорта NVMe-oF™/TCP. Для технологии NVMe был реализован аналогичный механизм (рис. 18) конфигурирования  – NBFT (NVMe Boot Firmware Table).

Network Boot / UEFI (TP8012, TP4126)

Рис. 18. Разница между загрузкой с iSCSI и загрузкой через транспорт NVMeoF.

NVMe Boot Specification была опубликована (рис. 19) на nvmexpress.org (https://nvmexpress.org/developers/nvme-boot-specification/) в декабре 2022 г. Он определяет конструкции и рекомендации по загрузке с интерфейсов NVM Express® через поддерживаемые транспорты. Версия 1.0 определяет расширения интерфейса NVMe для загрузки через транспорт NVMe/TCP, в которой описываются:
–  общие принципы загрузки для транспорта NVMe/NVMe-oF;
–  механизм enumeration загрузочных устройств и переключения конфигурации из среды Pre-OS в среду OS (таблицы ACPI);
–  этапы загрузки и поток в среде UEFI до загрузки ОС;
–  руководство по внедрению и внедрению и лучшие практики:

• конфигурация загрузки для транспорта NVMe-oF в предзагрузочной среде;
• механика использования (consumption) таблиц ACPI операционной системой;
• специфика транспорта ОС и фабрики.

конфигурация загрузки для транспорта NVMe-oF в предзагрузочной среде;

механика использования (consumption) таблиц ACPI операционной системой;

специфика транспорта ОС и фабрики.

Рис. 19. NVMe Boot Specification в семействе спецификаций NVMe.

Key Per I/O  (TP4055, ратификация – 2 кв. 2023 г.)
В NVMe® пространство имен представляет собой набор адресов логических блоков (LBA, logical block address), доступных для хост-программного обеспечения. Пространство имен NVMe эквивалентно логическому устройству SCSI (LU) или тому. При представлении хосту каждое пространство имен имеет уникальный идентификатор в устройствах. Например,  /dev/nvme0n1  определяет контроллер 0 и пространство имен 1.
Идентификатор пространства имен (NSID) — это идентификатор, используемый контроллером для предоставления доступа к пространству имен. Пространство имен — это не физическая изоляция блоков, а изоляция логических блоков, адресуемых хост-программным обеспечением (https://nvmexpress.org/resource/nvme-namespaces/). Диски с самошифрованием выполняют шифрование диапазонов LBA в пространствах имен [14].
Ключ для каждого ввода-вывода обеспечивает динамическое точное управление шифрованием, указывая, какой ключ шифрования использовать для каждого ввода-вывода
–  назначение ключа шифрования конфиденциальному (“чувствительному”) файлу или хост-объекту;
–  упрощенная поддержка Общего регламента по защите данных (GDPR, General Data Protection Regulation);
–  упрощенная поддержка стирания, когда данные распределяются и смешиваются с другими данными, которые необходимо сохранить (например, RAID и erasure coding).
Механизмы загрузки ключей и управления ими не входят в спецификацию.
Разработка данного TP ведется на основе соглашения о взаимодействии между NVM Express® и TCG Storage Work Group.

Key Per I/O  (TP4055,
ратификация
– 2
кв
. 2023
г
.)

Тестирование: сравнение протокола NVMeOF TCP с iSCSI на одинаковом Ethernet-подключении
Для тестирования используем один и тот же диск как raw device без файловой системы, с настроенным на него таргетом ISCSI и NVMeOF TCP. Проводим три замера производительности fio в рамках одного сервера на внутренний диск, и между двумя серверами по протоколам iSCSI и NVMeOF по одной и той же сети 25Gbit ethernet. Некоторые замеры дополнительно выполнены на более медленном канале 10Gbit
При тестировании берем значения общего времени отклика на операции случайного чтения: запись более ресурсоемкая для диска операция; случайный характер исключает потенциальную возможность объединения пакетов в один(если это вообще возможно); общее время, а не время чистой записи без учета времени прохождения стека ввода-вывода  ОС – для анализа накопления времени завершения чтения, поскольку нас интересует больше производительность канала/общая латентность клиентского тома, чем чистое время обработки ввода-вывода диском в нашем случае, или СХД в общем случае. Брать чистое время отклика устройства имеет смысл при замерах производительности подключенной СХД – поскольку в этом случае, мы не учитываем команды, находящиеся в очереди ОС, и о существовании которых СХД вообще не знает, и никак не может влиять на их производительность.
Сценарии подачи нагрузки, выбраны следующим образом: все возможные варианты нагрузки не проверяются, для сокращения времени тестирования.
Выбираем количество потоков равное 1 – для замера минимально возможного времени отклика, но не достигая максимальных цифр IOPS, потому что однопоточная нагрузка на диск не приводит к достижению его максимальной производительности.
Так же рассматриваем количество потоков равное 4 – предполагаем, что генерация нагрузки так же требовательна к CPU ресурсам, как и само чтение. Поэтому для минимизации влияния генератора нагрузки на чтение, используем заведомо меньшее количество потоков, чем доступно ядер процессоров. Большее количество потоков, в том числе лишено смысла в случае iSCSI подключения, тестирование которого выполнялось раньше NVMe – maxIOPS канала достигается задолго до ограничений диска, эти IOPS диск может обработать и в один поток.
Размер блока нужно рассмотреть минимальный и максимальный – 4кб и 128кб, и какой-то средний, выбран 16кб, для исследования характера изменений времени отклика в зависимости от размера пакета. Так же это даст больше информации для анализа, что является большим ограничением – производительность подсистемы ввода-вывода (в какой-то момент не может обработать больше I/O операций), или же ширина канала (уперлись в пропускную способность в Gbit/sec)
Глубина очереди – параметр, дающий наибольшее влияние на итоговое время отклика. Для исследования характера нарастания, требуется проверка как минимальной длины очереди для определения минимальных latency, так и большой – для получения максимальной производительности. Есть примерные прикидки оптимальной глубины очереди для конкретных значений IOPS на поток (определяется по тому, сколько времени уходит на обработку одной операции ввода-вывода: например, latency = 0,5мс, показатель IOPS = 100000. Это значит, что за 1сек обрабатывается 2000 последовательных запросов, соответственно, очередь нужна не меньше 100000/2000= 50), но конкретных цифр пока не было – поэтому проверки  проводились для всех сценариев с одинаковым различным набором глубин очереди – 4, 8, 16, 32, 64 и 256.
Каждый сценарий выполняется с постепенным нарастанием количества операций ввода-вывода, от минимальной до предельной.
В результате проведено около 110 серий замеров, по 15-20 десятисекундных замеров в каждом.
Результаты выложены в папке: https://drive.google.com/drive/folders/1TtNYWm5NkTiLWBaMc47x8_7RuqdGJGSt?usp=share_link
В табл. 2 приведены следующие данные: maxIOPS на сценарии / среднее время отклика при средней загрузке системы / максимальное общее время отклика, включая нахождение в очереди ОС.
Анализ этих цифр позволяет сделать следующие выводы:
–  общая пропускная способность выросла в 2-5 раз;
–  производительность диска, подключенного по протоколу NVME по сети 25Gbit ethernet, меньше производительности внутреннего NVMe устройства, примерно в 2 раза по максимальным IOPS, и в 3 раза по Latency – в целом, это все еще отличия в разы, но возможно использование низколатентной сети 100Gbit, которая должна обеспечить достаточную пропускную способность, и латентность ниже в 1.5-2раза;
–  обнаруженное ограничение порядка 240Кiops – связано скорее с пропускной способность канала, чем задержками в канале.
Это равносильно чистой скорости канала около 9Гбит/сек – что видится приемлемым, с учетом сложности построения пакетов ethernet;
–  задержки остались на прежнем уровне либо снизились в 1,1-1,5 раз;
–  все типы подключения тома на низкой (до 50-80% от максимальной) нагрузке показывают суб-линейное нарастание latency, которое позже переходит в степенное-экспоненциальное, и оканчивается сатурацией около показателей максимальных IOPS и соответствующего времени отклика;
–  механизм обработки очередей показывает очень хорошие результаты, качественная сериализация идет на стороне таргета, так что на стороне клиента количество очередей практически не влияет на производительность. Большая глубина очереди дает большее число IOPS, но и большие задержки;
–  повтор тестов NVMeOF TCP на 25Gb линии вместо 10Gb убрал необходимость тестировать FC канал подключения – даже если он покажет лучшие показатели, разница с iSCSI слишком значительна;
–  тестирование канала FC возможно покажет меньшие задержки, стоит провести такое сравнительное тестирование в будущем.

Тестирование: сравнение протокола NVMeOF TCP с iSCSI на одинаковом Ethernet-подключении

https://drive.google.com/drive/folders/1TtNYWm5NkTiLWBaMc47x8_7RuqdGJGSt?usp=share_link

Таблица 2. Сценарии тестирования

Источники, доп. ресурсы
[1]  Welcome NVMe™/TCP to the NVMe-oF™ Family of Transports. Blog. Authors: Sagi Grimberg, Chief SW Architect, Lightbits Labs and Dave Minturn, Intel Corp., Fabrics Linux Driver WG Chair – https://nvmexpress.org/welcome-nvme-tcp-to-the-nvme-of-family-of-transports/.
[2]  NVMe/TCP Transport Binding specification – http://tjn.nvme.ws1.vtm-ws.com/wp-content/uploads/NVM-Express-over-Fabrics-1.0-Ratified-TPs-1.zip.
[3]  The Linux Kernel NVMe/TCP support – http://git.infradead.org/nvme.git/shortlog/refs/heads/nvme-tcp.
[4]  The SPDK NVMe/TCP support – https://review.gerrithub.io/#/c/spdk/spdk/+/425191/.
[5]  NVMe over TCP: How it supercharges SSD storage over IP networks, by John Edwards, Mar 15, 2021 – https://www.networkworld.com/article/3609921/nvme-over-tcp-how-it-supercharges-ssd-storage-using-standard-ip-networks.html.
[6]  NVMe® 2.0 Specifications: Support for Fabrics and Multi-Domain Subsystems. Blog. By Fred Knight, Principal Standards Technologist at NetApp, December 13, 2022 – https://nvmexpress.org/nvme-2-0-specifications-support-for-fabrics-and-multi-domain-subsystems/.
[7]  NVMe 2.0 Specifications: Shaping the Future of Enterprise Storage. Blog. By Bill Lynn, Dell EMC. January 24, 2023 – https://nvmexpress.org/nvme-2-0-specifications-shaping-the-future-of-enterprise-storage/.
[8]  The NVM Command Set: New Specification, Features and More. Blog. By Mike Allison, Senior Director, Samsung. December 5, 2022 – https://nvmexpress.org/the-nvm-command-set-new-specification-features-and-more/.
[9]  NVMe Specifications Overview – https://nvmexpress.org/specifications/.
[10]     Discovery Automation Enhancement: Enabling NVMe Over IP-Based Fabrics Systems Webinar. 30 ноября 2022 г. – https://www.youtube.com/watch?v=n0RTlhNbaGs.
[11]     Why Automated Discovery Changes the Game for NVMe/TCP.  By Ihab Tarazi   |   December 19, 2022 – https://www.dell.com/en-us/blog/why-automated-discovery-changes-the-game-for-nvme-tcp/.
[12]     NVM Express Announces the Rearchitected NVMe® 2.0 Library of Specifications. June 3, 2021 – https://nvmexpress.org/nvm-express-announces-the-rearchitected-nvme-2-0-library-of-specifications/.
[13]     The Need for Speed: NVMe™, NVMe-oF™, and Data Processing Accelerators. Feb 21, 2023 – https://www.g2minc.com/_files/ugd/435b9b_38cd3beac5194916960f857d16570bc3.pdf.
[14]     NVM Express State of the Union. Peter Onufryk, Intel Fellow. NVMe® Technical Workgroup Chair, 09.2022 – https://nvmexpress.org/wp-content/uploads/NVM-Express-State-of-the-Union.pdf.
[15]     Worldwide Solid-State Storage Forecast, 2022–2026 (May 2022) IDC #US47831722
[16]     Booting Your OS Across the NVMe® over Fabrics (NVMe-oF™) Transport. NVMe Boot Specification + Boot over NVMe/TCP Reference Implementation. Doug Farley (Dell Technologies), Phil Cayton (Intel), Rob Davis (NVIDIA). March 1, 2023 – https://nvmexpress.org/wp-content/uploads/NVMe-oF-Network-Boot-Webinar-Deck_FINAL.pdf, https://nvmexpress.org/resource/booting-your-os-across-the-nvme-of-transport-nvme-boot-specification/.
[17]     NVMe, NVMe/TCP, and Dell SmartFabric Storage Software Overview. IP SAN Solution Primer, January 2022, H18917, Technical Guide. Dell Technologies Solutions – https://infohub.delltechnologies.com/t/nvme-nvme-tcp-and-dell-smartfabric-storage-software-overview-ip-san-solution-primer-1/, https://infohub.delltechnologies.com/t/networking-solutions-57/.
[18]     NVMe® Key Value Command Set Provides the Key to Storage Efficiency. Posted on: July 18, 2022 – https://nvmexpress.org/nvme-key-value-command-set-provides-the-key-to-storage-efficiency/.
[19]     The Key to Value: Understanding the NVMe Key-Value Standard, sept. 1, 2020 – https://www.youtube.com/watch?v=uQFl5T7IKpI&t=1156s.

Источники
,
доп
.
ресурсы

Авторы:
Гантимуров А.П., Калашник А.Г., Ларин О.А.

Отслеживать