Введение

Компания Excelero была основана в 2014 г. и разрабатывала программно-определяемое блочное хранилище на базе NVMe SSD-накопителей с малой задержкой для гипермасштабируемых приложений, таких как ИИ, машинное обучение и вычисления на GPU, в облаке и на периферии. В 2017-19 гг. Excelero была удостоена (https://www.excelero.com/recognition/) ряда престижных наград: Gold Medal Stevie^® Award (16th Annual International Business Awards^®), Most Innovative Flash Memory Technology (Flash Memory Summit 2019), Innovator in NVMe over TCP/IP 2019 (IDC Report) и др.

В марте 2022 г. Excelero была куплена NVIDIA (https://blogs.nvidia.com/blog/2022/03/07/exceler-ostorage-software/). «Мы будем работать с NVIDIA, чтобы обеспечить поддержку наших существующих клиентов, и в дальнейшем мы очень рады применить наш опыт в области блочного хранения данных к платформам искусственного интеллекта и HPC мирового класса от NVIDIA», — сказал Янив Ромем (Yaniv Romem), генеральный директор и соучредитель Excelero. Среди новых задач команды Excelero — расширение поддержки блочного хранилища в стеке корпоративного программного обеспечения NVIDIA, например, в кластерах для высокопроизводительных вычислений. Также блочное хранилище играет важную роль в программной среде DOCA (DPU SDK, https://developer.nvidia.com/networking/doca), которая работает на NVIDIA DPU. В будущем технология Excelero будет интегрирована в стек корпоративного ПО NVIDIA.

Excelero NVMesh

С расширением доступности высокопроизводительных технологий, таких как: GPU, AI-акселераторы, относительно дешевые многоядерные CPU и др., а также с расширением использования когнитивных технологий (AI/ML/DL), позволяющих не только автоматизировать, но и роботизировать многие бизнес-процессы и системы, возрастают требования по доступу к данным при многократном увеличении их в объемах и, в частности, к таким показателям, как: задержки, пропускная способность, производительность IOPs и др. Одна из основных среди них – задержка.

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

Excelero  NVMesh – это программная разработка компании Excelero (продвигаемая с 2015 г.) для создания программно-определяемого распределенного блочного продукта хранения (NVMesh), который выполняется на стандартном (commodity) серверном оборудовании для хранения данных. Excelero была первым поставщиком NAFA (NVMe All-Flash), который развивал свои предложения только на программном продукте [1].

Отличительные особенности разработки Excelero NVMesh заключаются в следующем: флэш-память NVMe для локального сервера отлично подходит, но часто недостаточно используется в емкости, производительности или в обоих случаях, в то время как общее хранилище (NVMe AFA) может отставать в производительности или увеличивать задержки (рис. 1).

Рис. 1. Архитектура NVMesh в сравнении с локальным хранением и AFA-хранилищем позволяет поддерживать максимальную производительность и эффективность и неограниченную масштабируемость.

Excelero была одним из первых участников рынка NAFA и остается главным разработчиком распределенного проекта NAFA, или Scale Out Flash Storage (SOFS).

Excelero обеспечивает для приложений задержку 25 мкс для блочного доступа на базе NVMe over fabrics, а также поддерживает совместное использование NVMe в любой сети как для локальных, так и распределенных файловых систем. В результате клиенты и их приложения выигрывают от производительности локальной флэш-памяти с удобством централизованного хранения, максимально избегая при этом пропритарных технологий и сокращая совокупную стоимость владения.

NVMesh от Excelero – распределенное блочное хранилище с наименьшей задержкой для разделяемого NVM-eхранилища. Это 100%-ное программное решение, которое поддерживает любое оборудование, позволяет запускать любую локальную или совместно используемую/параллельную файловую систему и обладающее возможностями, которые облегчают веб-масштабирование при широком спектре используемых сетевых протоколов и приложений.

NVMesh абстрагирует базовое оборудование, создает логические тома с избыточностью и обеспечивает централизованное, интеллектуальное управление и мониторинг. Распределенные ресурсы хранения NVMe объединяются с возможностью создания произвольных динамических блочных томов, которые могут использоваться любым хостом, на котором работает блочный клиент NVMesh (см. рис. 2).

Рис. 2. NVMesh абстрагирует базовое оборудование, создает логические тома с избыточностью и обеспечивает централизованное, интеллектуальное управление и мониторинг. Распределенные ресурсы хранения NVMe объединяются с возможностью создания произвольных динамических блочных томов, которые могут использоваться любым хостом, на котором работает блочный клиент NVMesh.

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

Рис. 3. NVMesh развертывается как виртуальный распределенный энергонезависимый массив и поддерживает как конвергентные, так и дезагрегированные архитектуры.

Решения SOFS состоят из комбинации программного пакета SOFS и серверов, обычно содержащих устройства хранения NVMe™. SOFS эволюционировали из программно-определяемого хранилища (SDS, Software-Defined Storage), но масштабируются до сотен или даже тысяч узлов. SOFS также в значительной степени заимствует часть принципов у DAS-ориентированных архитектур хранилищ, используемых гипермасштабными компаниями (AWS, Google, Azure, Facebook и BATs). Используя NVMe over Fabrics в качестве магистрали, решения SOFS могут обеспечить удаленный доступ к блокам и файлам, распределенным по большому количеству серверов с локальной производительностью и задержкой. Одним из важных принципов высокопроизводительного распределения является уменьшение до нуля количества «прыжков» (hops) через серверы.

Идеально доступ к данным прямой – от клиента к диску, не проходящий через процессор.

NVMesh поддерживает широкий выбор протоколов и коммутационных сетей, включая TCP/IP, InfiniBand, RoCE v2, RDMA и NVMe-oF. NVMesh развертывается как виртуальный, распределенный энергонезависимый массив и поддерживает как конвергентные, так и дезагрегированные архитектуры, предоставляя клиентам полную свободу в их архитектурном проектировании. Ключевым компонентом NVMesh от Excelero является запатентованная функция удаленного прямого доступа к диску (RDDA, Remote Direct Drive Access), которая обходит CPU и, как следствие, позволяет избежать эффекта “шумных” соседей на приложение. Переход от поддержки служб данных от централизованного CPU к полному распределению на стороне клиента обеспечивает линейную масштабируемость, обеспечивает детерминированную производительность для приложений и позволяет клиентам максимально эффективно использовать свои флэш-накопители (https://www.excelero.com/nvmesh–on–private–cloud/).

Преимущества SOFS в сравнении с SDS

SDS был построен на основе нескольких устройств хранения данных, подключенных к вычислительным узлам через Ethernet, обычно NFS или iSCSI:

• устройства хранения, подключенные к внутреннему хранилищу (JBOD) через SAS или SATA, имели ограниченную гибкость из-за сетевых ограничений SAS/SATA;
• для пользователей SDS-решения выглядели также, как развертывания SAN или NAS на основе массива хранения, но (как правило) с меньшими затратами и меньшей производительностью;
• SDS был по сути «SAN для бедных».

SOFS использует NVMe Over Fabric™ (NVMeoF™) для подключения хранилища, вычислительных узлов:

• узлы могут быть как вычислительными, так и узлами хранения или обоими одновременно – без дифференциации;
• полностью гибкая/составная (composable) топология сети;
• производительность удаленного хранилища приближается к производительности локального хранилища;
• SOFS-решения легко масштабируются до тысяч узлов. Также снимается проблема «где сколько места хранения».

Также в отличие от более ранних разработок SDS (например, Nutanix) NVMesh полностью оптимизирован для NVMe и при использовании HDD преимущества RDDA теряются (познавательный блог – http://chansblog.com/excelero–the–latest–software–defined–storage–startup/, прим. ред.).

Оценка IDC разработок Excelero

В 2019 г. Excelero была названа IDC новатором (IDC Innovators: NVMe over TCP, 2019, Doc #US45088519).

Среди преимуществ разработок Excelero IDC отмечает:

• распределенный дизайн Excelero, на основе ПО, разворачиваемого на стороне хоста, исключает возможность того, что контроллеры в массиве общего хранилища могут стать узким местом для производительности. Программное обеспечение NVMesh предлагает несколько модулей, которые обеспечивают значительную гибкость конфигурации: MeshProtect поддерживает разнообразные конфигурации RAID, включая RAID-6 и его распределенный вариант (erasure coding data protection). MeshConnect поддерживает четыре различных параметра NVMeoF (FC, RoCE, TCP, InfiniBand), а MeshInspect предоставляет аналитику хранилища;
• подход Excelero, основанный только на программном обеспечении, дает компании значительную гибкость в работе с партнерами по каналам, чтобы также создавать различные предложения устройств хранения данных (которые могли бы ориентироваться на корпоративный рынок). Сегодня клиенты могут создавать решения для платформ хранения данных из некоторой комбинации только программного продукта, карты аппаратного ускорения SmartNIC для разгрузки хост-процессоров и любых опций NVMe-oF;
• Excelero является одним из наиболее зрелых стартапов NAFA с венчурными инвестициями от Mellanox, Qualcomm, Micron и WesternDigital.

Excelero выделяется своей моделью развертывания – только на основе программного обеспечения в любой из тысяч конфигураций (которая дешевле и исключает привязку к поставщику оборудования), распределенным дизайном и поддержкой карты аппаратного ускорения SmartNIC для разгрузки ЦП сервера на хостах (особое преимущество для NVMe/TCP).

Компоненты и особенности NVMesh

NVMesh – это законченное web-масштабируемое SOFS-решение с распределенной защитой данных и выделением (provisioning) емкости хранения, которые делают разделяемое NVMe-хранилище практичным, эффективным и легко управляемым.

MeshConnect™ поддерживает традиционные сетевые технологии, предоставляя NVMesh самый широкий выбор поддерживаемых фабрик и протоколов. Поддерживаемые протоколы: TCP/IP или RDMA, включая Ethernet и InfiniBand.

MeshProtect™ – это гибкая распределенная архитектура защиты данных, предлагающая различные уровни защиты, обеспечивающие устойчивость и производительность в соответствии с потребностями приложений. Варианты варьируются от отсутствия избыточности, зеркального отображения (1 + 1) до избыточности, основанной на четности (N + M). Последний обеспечивает эффективность хранения более 90%, но и высокую производительность с минимальными задержками в крупномасштабных конфигурациях (рис. 4).

Рис. 4. Три уровня защиты данных в NVMesh.

MeshInspect™ предоставляет аналитику производительности для быстрого и точного определения аномалий. Клиенты получают все преимущества от подробной статистики производительности и утилизации в масштабах всего кластера, что позволяет осуществлять мониторинг и анализ среды хранения. Администраторы могут воспользоваться полностью кастомизированной визуализацией с детальными показателями рабочих нагрузок и наборов данных приложений.

NVMesh позволяет клиентам максимально использовать оборудование в своей инфраструктуре. Это относится к носителям NVMe, а также к процессорам серверов приложений и серверам GPU (для AI/ML/DL).

Системы NVIDIA GPU стали основным ресурсом для рабочих нагрузок AI и ML. Последним нововведением NVIDIA является NVIDIA Magnum IO, набор программного обеспечения для значительно большей пропускной способности данных на много-серверных вычислительных узлах с несколькими графическими процессорами, чем это было возможно ранее. Ключевой особенностью NVIDIA Magnum IO является технология NVIDIA GPUDirect Storage, которая обеспечивает прямой путь передачи данных между памятью и хранилищем графического процессора, позволяя данным обходить ЦП и перемещаться по «открытым магистралям», предлагаемым графическими процессорами, устройствами хранения и сетевыми устройствами.

NVMesh^® имеет адаптированный NVIDIAFS Driver API и другие инструменты, такие как CUDA APIs – для плавной интеграции своих решений в среду хранения GPUDirect. NVMesh использует те же принципы, что и NVIDIA Magnum IO, обходя процессоры для прямого доступа к носителям NVMe. Комбинируя GPUDirect Storage с NVMesh, пользователи обходят процессоры от памяти GPU до устройств NVMe, обеспечивая беспроблемный доступ с высокой производительностью к разделяемому NVM-хранилищу.

Excelero имеет несколько патентов США, регулирующих методы для этого обхода.

Excelero NVMesh интегрируется с ПО инфраструктуры K8s и ему подобными через замену драйвера NVMe в ядре Linux на собственный, ведущий себя точно так же, как NVMe драйвер. Он поставляет виртуальные диски NVMe, так что не нужно менять ни чего в аппликативном стэке, а дополнительные затраты процессора исчисляются несколькими процентами. С системами, основанными на К8s, NVMesh работает через CSI plugin.

Спецификация NVMesh представлена в табл. 1.

С точки зрения управления (https://www.excelero.com/nvmesh–user–guide/2.5.2/en/topic/overview) можно выделить четыре основных программных элемента NVMesh 2.5.2 (см. рис. 3):

• Management;
• Intelligent Client Block Driver (initiator);
• Target;
• Topology Manager (TOMA).

Табл. 1. Спецификация NVMesh.

Управление

Управление — это элемент централизованного администрирования развертывания NVMesh 2.5.2, обеспечивающий управление хранилищем, настройку и функции мониторинга. Он функционирует как графический веб-интерфейс и как интерфейс управления RESTful API.

Драйвер клиентского блока (инициатор)

Клиент NVMesh 2.5.2 реализует функциональность блочного устройства для клиентов или потребителей хранилища, часто называемых инициаторами. После подключения тома они проявляют себя как блочные устройства в каталоге /dev/nvmesh (в Linux).

Узел, который имеет одно или несколько устройств NVMe для совместного использования, называется конвергентным узлом. На конвергентных узлах работает как клиентское, так и целевое программное обеспечение. Управление также может выполняться на клиенте или на конвергентном узле (рис. 5).

Рис. 5. Взаимодействие компонентов NVMesh.

Цель

Цель идентифицирует оборудование для хранения, диски NVMe и совместимые сетевые карты, а также настраивает пути RDDA к целевым дискам от имени клиентов хранилища. Это ПО работает на целевом узле, который представляет собой любой физический узел, содержащий твердотельные накопители для совместного использования. Цели также запускают программный компонент пользовательского пространства под названием TOMA (Topology Manager).

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

Менеджеры топологии (TOMA)

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

Лидер распределяет изменения топологии среди других менеджеров топологии в кластере. Менеджеры обнаруживают состояния ошибок, такие как перезагрузка узла или отсутствующие диски, и несут ответственность за действия по обработке ошибок. Он отслеживает такие события, как изменения состояния диска или сети. Он инициирует перестроение и предотвращает «расщепление мозга» в конфигурациях зеркальных томов.

Развертывание

На одном компьютере можно запустить один или несколько компонентов NVMesh 2.5.2 , что обеспечивает гибкость архитектуры системы хранения. Типичная установка будет включать несколько клиентских узлов и несколько целевых узлов. Управление может выполняться практически в любом месте при наличии соединения TCP/IP с клиентом и целевыми узлами.

Для наилучшей производительности клиентские узлы и целевые узлы должны иметь один или несколько сетевых адаптеров RDMA. Если имеется несколько портов или сетевых карт, NVMesh 2.5.2 попытается использовать их все по умолчанию. Можно ограничить количество используемых сетевых карт. NVMesh 2.5.2 поддерживает RDMA через Converged Ethernet версии 2 (RoCEv2), а также RDMA через InfiniBand.

Целевой узел, на котором работает целевой модуль, должен иметь один или несколько NVMe SSD. Целевой модуль поддерживает настройку путей RDDA на сетевых адаптерах с поддержкой RDMA. Для большинства ядер требуется установить драйверы RDMA Mellanox OpenFabrics Enterprise Distribution (OFED). Для более современных ядер достаточно драйвера «inbox». Поддерживаемые версии NIC и OFED можно найти в отдельной матрице взаимодействия NVMesh. Драйверы Mellanox OFED доступны на: http://www.mellanox.com/page/products_dyn?product_family.

Коммуникация пути данных клиента идет непосредственно к Целям. Отсутствует поиск диспетчера метаданных, перенаправление или другие системные узкие места, часто связанные с устаревшими решениями SDS. Важно отметить, что между Клиентами нет связи. Точно так же для инициированного клиентом ввода-вывода цели не отправляют друг другу информацию о пути данных.

Цели обмениваются данными для восстановления неисправного диска на равноправной Цели. Они также выполняют регулярную связь пути управления друг с другом, используя упрощенный протокол состояния или протокол проверки активности.

Поддержание доступности

NVMesh 2.5.2 обеспечивает высокую доступность как программных, так и аппаратных компонентов.

Доступность сервера – NVMesh 2.5.2 постоянно отслеживает доступность узлов кластера. Когда целевой сервер выходит из строя из-за проблемы с оборудованием или программным обеспечением, в течение нескольких секунд другие целевые серверы идентифицируют сбой и при необходимости переключают соответствующие тома в статус деградированных.

Доступность сети – NVMesh 2.5.2 постоянно отслеживает доступность сетевых ссылок, как у клиентов, так и у целей. Ссылки переключаются автоматически.

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

Балансировка нагрузки

По умолчанию клиенты NVMesh 2.5.2 используют все доступные сетевые ссылки или пути между собой и целевыми объектами. Трафик агрегируется по нескольким ссылкам. Если ссылка не работает, Клиент автоматически перенаправит трафик на другую доступную ссылку.

Типы поддерживаемых логических томов

NVMesh 2.5.2 поддерживает несколько типов томов, различающихся расположением данных и уровнем защиты данных. В настоящее время поддерживаются следующие типы логических томов:

• объединенный (Concatenated);
• чередующийся RAID-0 (Striped RAID-0);
• зеркальный RAID-1 (Mirrored RAID-1);
• чередующийся и зеркальный RAID-10 (Striped & Mirrored RAID-10);
• на основе кода стирания (Erasurecoded), часто также называемое кодированием на основе четности.

Тома выделяются из пула устройств хранения под управлением NVMesh 2.5.2. Тома могут использовать часть одного устройства или части нескольких устройств. Часть устройства также может быть целым устройством. На одном устройстве может размещаться часть одного тома или часть нескольких томов. Часть тома может также быть всем томом.

Минимальные конфигурации

Минимальный кластер для MeshProtect 1/10

Кластер NVMesh 2.5.2 использует сегменты, распределенные по дискам и хостам, для достижения консенсуса большинства по состояниям томов. Для тома MeshProtect 1/10 минимальное количество дисков с данными — два, но третий диск должен участвовать в качестве арбитра с небольшим сегментом метаданных. Поскольку эти сегменты также должны находиться на отдельных хостах, строгая минимальная избыточная конфигурация кластера NVMesh 2.5.2 — это три хоста. В случаях, когда в кластере недостаточно хостов или дисков для достижения большинства, виртуальное или «фиктивное» устройство может быть создано на сервере без дисков NVMe. Это устройство называется приводом арбитра. Этот диск арбитра будет создан в виде файла /var на Target, но будет содержать только метаданные, используемые для согласования объема.

Управление может быть развернуто на одном хосте. Если желательны резервные серверы управления, их следует развернуть на более чем на одном узле. Управление хранит свои данные в базе данных MongoDB. Для обеспечения избыточности базы данных обычно используются 3 узла.

Это приводит к тому, что минимальный избыточный кластер NVMesh 2.5.2 состоит как минимум из 3 хостов, причем как минимум 2 хоста имеют физические диски NVMe (рис. 6).

Рис. 6. Минимальный избыточный кластер NVMesh.

Предпочтительный и рекомендуемый минимальный кластер NVMesh 2.5.2 — это 4 хоста, все с дисками NVMe, поскольку это позволяет создавать тома MeshProtect 1/10 в сбалансированных парах хостов. В этой конфигурации нет необходимости создавать диск арбитра (рис. 7).

Рис. 7. Минимальный рекомендуемый кластер NVMesh.

В ситуациях, когда нет необходимости в высокой доступности, можно установить клиент NVMesh 2.5.2, цель и управление на одном сервере. В этой конфигурации администратор может создавать конкатенированные или чередующиеся тома MeshProtect 0.

Администратор также может создавать тома MeshProtect 60 с резервированием дисков, но без резервирования узлов. Для избыточной системы NVMesh 2.5.2 с томами MeshProtect 60 требуется как минимум 3 узла для базы данных MongoDB управления, которая также может запускать управление и может быть объединена с целевыми объектами. Фактическое количество необходимых целей зависит от выбранных параметров MeshProtect 60 и требуемого уровня резервирования. Подробное описание этого – https://www.excelero.com/nvmeshuserguide/2.5.2/en/topic/target–node–redundancy.

Лучшие практики (NUMA-архитектуры)

При настройке NVMesh 2.5.2 на серверах с архитектурами ЦП на основе неоднородного доступа к памяти (NUMA, non-uniform memory access) важно учитывать конфигурацию сетевых карт и дисков NVMe по сравнению с NUMA. Поскольку каждое ядро ЦП имеет определенный фиксированный предел пропускной способности на пути межсоединений к любой из областей памяти NUMA (узлов), а каждый ЦП имеет фиксированное количество линий PCIe к сетевым адаптерам и дискам NVMe, ввод-вывод, выдаваемый ядром ЦП на конкретную сетевую карту или диск NVMe может повлиять пропускная способность межсоединения NUMA.

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

Поэтому лучше всего сбалансировать доступ к памяти в соответствии со спецификацией ядер ЦП и узлов NUMA, производительностью межсоединений и спецификациями производительности сетевых карт и дисков NVMe.

Больше информации – https://www.excelero.com/nvmesh-user-guide/2.5.2/en/topic/nvmesh-best-practices, https://www.manula.com/manuals/nvmesh/nvmesh-user-guide/2.5.2/en/pdf.

Примеры использования NVMesh

Прежде, чем перейти к представлению конкретных кэйсов использования NVMesh, необходимо сделать ряд замечаний. Существующие benchmarks, прежде всего, ориентированы на проверку работы GPU или алгоритмов, но не на стресс СХД. В реальных условиях ситуация как раз обратная, и способности СХД, например, по одновременному чтению большого количества маленьких (от 10 до 30 КБ) изображений (это то, что определит, насколько эффективно будут использованы GPUs) не хватает. Недавно на NVIDIA DGX1 с 8 графическими процессорами – V100 и с одним внешним сервером – SuperMicro BigTwin с 16 дисками, на котором “бежит” NVMesh target с локальной файловой системой XFS, Excelero продемонстрировала, что NVMesh позволяет открывать и читать почти 1 млн таких файлов в секунду. Для ряда клиентов это критично, так как они, например, обрабатывают десятки миллионов фотографий с 10 серверов с 8 или 16 GPU в каждом. Другие клиенты работают с тысячами MRI scans, каждый из которых достигает 0,5 ТБ и поэтому пропускная способность чрезвычайно важна. Но также важны и количество случайных маленьких операций над файлами (включая поиск и открытие файлов и не только IOPS!), и задержка (время до первого байта).

Использование формата TFRecord (формат для хранения последовательности двоичных записей, в каждом по 100-200 Mбайт).

В то время когда TFRecord используется повсеместно в benchmarks, чтобы улучшить пропускную способность проверки и больше нагрузить GPU, эта функциональность практически отсутствует в реальных установках, так как: во-первых, предполагается, что каждый batch, составляющий отдельный TFRecord, распределен достаточно равномерно и случайно среди категорий – иначе результаты обучения будут искажены; во-вторых, требуется удвоить объем хранения, так как оригиналы не стираются; и, в-третьих, предполагается, что нормализация оригиналов не будет меняться между сессиями обучения, что далеко не всегда случается на практике. TFRecords – это хорошая и нужная технология которая еще требует доработки, чтобы быть по-настоящему применимой.

1. Расширение возможностей NVIDIA DGX1 сервера (http://www.pny.eu/en/consumer/exploreфallфproducts/storage/13383s2400)

Семейство серверов NVIDIA DGX изменило возможности AI-вычислений. Однако ограничения внутреннего пространства для флэш-памяти NVMe являются сдерживающим фактором для роста производительности и общих возможностей.

PNY 3S-2400 AI Optimized Storage Server создает центральный пул NVMe со сверхнизкой задержкой, который может совместно использоваться одним или несколькими серверами DGX. Это позволяет снять все названные выше ограничения.

Простое подключение DGX-1 через NVIDIA EDR InfiniBand/100Gbe по протоколу RDMA, совместимому с NVIDIA, к PNY 3S-2400 AI Optimized Storage Server обеспечивает просмотр ресурса NVMe и работу сервера NVIDIA DGX-1 так, как если бы PNY 3S-2400 был внутренним ресурсом по отношению к DGX (рис. 8).

Рис. 8. Схемы подключения NVIDIA DGX-1 к серверу PNY 3S-2400.

Современные серверы искусственного интеллекта потребляют и анализируют данные с гораздо большей скоростью, чем традиционные решения для хранения данных. Это приводит к низкой загрузке графического процессора и значительному увеличению времени обучения, а также снижению производительности. PNY 3S-2400 был разработан с нуля для рабочих нагрузок AI и оптимизации NVIDIA DGX. Обеспечение сверхнизкой задержки и огромной пропускной способности по цене, которая позволяет инвестировать больше средств в ресурсы графического процессора и меньше – в дорогостоящее, более медленное, хранилище.

NVMesh-дизайн PNY позволяет производить масштабирование поэтапно, чтобы удовлетворить требования развиваемого проекта без каких-либо ограничений. Результаты тестирования приведены на рис. 9 и в табл. 2.

Рис. 9. Результаты тестирования сервера DGX1, подключенного к одному серверу PNY 3S-2400.

Табл. 2.  Результаты тестирования 4-х конфигураций.

2. Использование NVMesh в качестве буфера для хранения контрольных точек

SciNet – крупнейший канадский суперкомпьютерный центр, который предоставляет канадским исследователям вычислительные ресурсы и экспертизу, необходимые для проведения их исследований при большом масштабировании. Центр помогает работать в области биомедицинских и аэрокосмических технологий в астрофизике и климатологии.

SciNet приобрела NVMesh, чтобы использовать флэш-память NVMe в качестве буфера (burst buffer storage) памяти для хранения данных контрольных точек, необходимых при рестартах. Burst буфер – это быстрый промежуточный уровень между непостоянной (non-persistent) памятью вычислительных узлов и хранилищем, который обеспечивает быструю проверку контрольных точек, так что вычислительные задания можно легко перезапустить. Поскольку пользователи запускают крупномасштабные приложения для моделирования, симуляции, анализа и визуализации, которые иногда выполняются неделями, сбой при вычислениях может иногда разрушать результат всей длительной работы. Чтобы избежать этого, мы реализовали этот буфер на основе программно-определяемого блочного хранилища Excelero NVMesh поверх параллельной файловой системы IBM Spectrum Scale (рис. 10).

Рис. 10. Использование Excelero NVMesh поверх IBM Spectrum Scale параллельной файловой системы в качестве буфера для хранения данных контрольных точек.

“Хотя мы приобрели NVMesh для использования в качестве буфера, – говорит д-р Дэниел Грюнер, главный технический директор консорциума высокопроизводительных вычислений SciNet – наша ИТ-команда быстро обнаружила, что сами рабочие нагрузки наших пользователей могут значительно выиграть от хранилища, которое имеет гораздо большую пропускную способность и лучшую реактивность, особенно при использовании сценариев с высоким IOPs, чего невозможно добиться с вращающимися дисками. Со временем этот вариант использования стал преобладать, демонстрируя ценность гибкости платформы NVMesh”.

Контрольные точки обычно сохраняются в разделяемой параллельной файловой системе, и для этого SciNet использует IBM Spectrum Scale (ранее GPFS). Но поскольку кластеры становятся больше и объем памяти на узел увеличивается, соответственно, увеличиваются объемы данных каждой контрольной точки, что требует больше времени для ее завершения или более высокой производительности файловой системы.

Совместное использование ресурсов NVMe Flash в масштабах предприятия помогает сохранить контрольные точки в течение 15 минут, что соответствует требованиям SLA.

На базе ПО NVMesh был организован объединенный пул распределенной высокопроизводительной петабайтного масштаба системы, в составе которой 80 NVMe-устройств с пропускной способностью 148 ГБ/с на запись контрольных точек (ограничивается количеством устройств) и с общей пропускной способностью чтения 230 ГБ/с по сети. Это позволяет поддерживать более 20 млн случайных 4K-операций ввода-вывода в секунду.

Добавляя обычные флэш-накопители и программное обеспечение NVMesh для вычисления узлов в низколатентную существующую сетевую структуру суперкомпьютера, система обеспечивает избыточность без влияния на целевые ЦП. Это позволяет стандартным серверам выходить за рамки своей обычной роли в качестве целевых блочных устройств – теперь серверы также могут выступать в роли файловых серверов.

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

[1] Excelero NVEdge для HA IoT-эры, Кирилл Шойхет (Kirill Shoikhet, Chief Architect) – главный архитектор, Excelero Storage) – http://www.storagenews.ru/76/Excelero_76.pdf.

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

Отслеживать