Используем весь потенциал GPUDirect Storage при помощи PCIe Fabrics
Винсент Хаше (Vincent Hache), Microchip Technology
В статье рассмотрен вариант совместного использования графических процессоров и матричных коммутаторов PCIe Fabric для анализа больших объемов данных (Big data). Оцениваются различные возможные топологии и приводятся результаты испытаний.
Анализ больших объемов данных (Big data) и машинное обучение создают ряд проблем при их выполнении с помощью графических процессоров (GPU). Наборы данных, участвующие в описываемых процессах, могут иметь размер сотни терабайт и при этом требовать наличия скоростного доступа к миллионам файлов в хранилище. И чем больше становятся объемы информации, нуждающейся в обработке, тем очевиднее тот факт, что использование традиционных способов передачи данных от центрального процессора (CPU) к графическим и далее к хранилищу информации нецелесообразно, так как серьезно ограничивает ресурсы и возможности GPU. Несмотря на то что на данный момент уже существуют решения, позволяющие устранить эффект «бутылочного горлышка» (bottlenecks) на шине данных, например GPUDirect Storage от компании Nvidia, их полноценное применение невозможно из-за недостатков интерфейса PCIe.
Даже в своей последней итерации, PCIe Gen 4, интерфейс сохраняет ту же базовую древовидную иерархию, которая использовалась с момента его создания. Именно данный тип иерархии затрудняет эксплуатацию PCIe в конфигурациях с несколькими хостами и коммутаторами. К счастью, подобные ограничения можно обойти при помощи совместного использования PCIe Fabrics с устройствами хранения с поддержкой SR-IOV и динамического разделения коммутаторов. Благодаря такому подходу пул GPU и твердотельных накопителей (SSD) формата NVMe может быть задействован сразу несколькими хостами, при этом требуя для работы только стандартные системные драйверы.
Определение проблемы
Традиционно для передачи данных из хранилища в GPU использовался специальный буфер, представляющий собой область в системной памяти CPU и называемый буфером возврата (bounce buffer). В буфере возврата формируется несколько копий данных перед их передачей в графический процессор. Создание дополнительных копий данных не очень целесообразно, но неизбежно, поскольку это фундаментальный процесс CPU. Кроме того, перемещение данных через буфер возврата вызывает задержку, снижает общую эффективность работы GPU и излишне нагружает центральный процессор хоста. Использование такого подхода в системах с большим объемом памяти и высокой интенсивностью приема/передачи данных на портах ввода/вывода приведет к серьезным проблемам с производительностью.
Проблемы с производительностью объясняются тем, что, несмотря на огромные вычислительные способности, графический процессор не может задействовать все доступные ему ресурсы в полной мере из-за необходимости ожидания входных данных из буфера возврата, который становится «бутылочным горлышком» всей системы. По мере роста количества приложений, оперирующих большими объемами данных, описываемая выше ситуация оказывается все более неприемлемой. Задержка в передаче данных на GPU может вызвать проблемы и стать причиной уязвимости всей системы, с помощью которой злоумышленник, например, сможет беспрепятственно совершить мошенническую финансовую транзакцию. Кроме того, ожидание поступления данных способно отрицательно повлиять на время, необходимое для обучения модели ИИ. При рассмотрении описанных проблем становится ясно, почему устранение bottlenecks-эффекта, связанного с буфером возврата, является одной из приоритетных задач в высокопроизводительных системах, чья работа связана с анализом и обработкой больших объемов данных и искусственным интеллектом.
Именно по этой причине компания Nvidia создала технологию GPUDirect Storage, которая в настоящее время готовится к выходу на рынок и является самой современной разработкой компании с точки зрения оптимизации производительности GPU при использовании в системах машинного обучения, искусственного интеллекта и других, схожих по интенсивности нагрузки приложениях. Не так давно Nvidia уже представляла технологию GPU Direct RDMA, предназначенную для увеличения пропускной способности и уменьшения задержки за счет минимизации количества создаваемых копий в буфере возврата. Эта технология позволяла обеспечить прямой обмен данными между графическим процессором и сетевой интерфейсной платой (NIC). Новая же технология GPUDirect Storage поддерживает прямую передачу данных между локальным или удаленным хранилищем, таким как NVMe и GPU. И хотя в системе по-прежнему фигурирует центральный процессор, он больше не участвует в переброске данных, что значительно увеличивает пропускную способность, уменьшает задержку и снижает нагрузку на CPU.
PCIe 4.0: множество улучшений с одним исключением
Выпуск базовой спецификации PCI Express 4.0 версии 1.0 состоялся в 2017 году и предлагал значительные улучшения по сравнению с предшествующим поколением. среди усовершенствований было увеличение пропускной способности линии с 1 до 2 Гбит/с и, как следствие, повышение скорости шины до 16 Гбит/с. Однако PCIe по-прежнему использует жесткую древовидную иерархию, при которой на каждый домен приходится один корневой комплекс.
Несмотря на то что применявшаяся ранее топология шины для PCI и PCI–X была заменена подключением типа «точка-точка», в котором для распределения были предусмотрены коммутаторы, общий принцип иерархии остался прежним. PCIe Gen4 так же ориентирована на использование в однокорневых конфигурациях, где существует однозначная связь между корневым (root) и конечным (endpoint, EP) узлами. Таким образом, несмотря на плюсы, предлагаемые PCIe 4.0, для работы и использования преимуществ GPU Direct потребуется осуществить обход его иерархии в системе с несколькими коммутаторами и хостами.
На рисунках 1 и 2 показан пример топологии с несколькими хостами, наглядно отображающий описываемую проблему иерархии. Система, использующая PCIe и имеющая в составе один корневой порт, требует, чтобы хост 1 имел подключение к выделенному нисходящему порту (downstream port, DSP) коммутатора 1, который в свою очередь подключен к восходящему порту (upstream port, USP) коммутатора 2. В коммутаторе 2 также присутствует выделенный нисходящий порт, который подключен к восходящему порту коммутатора 3 и т. д.
Рис. 1. Пример топологии с несколькими хостами
Рис. 2. Требования к иерархии для каждого хоста
Таким образом, даже при организации простейшей системы на основе древовидной структуры PCIe потребуется подключение по отдельным каналам между каждым коммутатором, выделенным для того или иного хоста. Попытка разведения коммутаторов между несколькими хостами быстро приводит к тому, что система становится сложной и крайне неэффективной, что особенно заметно при организации крупной системы с множеством GPU, устройств для хранения информации, контроллеров и коммутаторов.
Решением данной проблемы может стать виртуализация ввода/вывода PCIe, поскольку в данном случае одно физическое устройство будет выглядеть как несколько виртуальных. Эти виртуальные устройства полностью независимы и позволяют одновременно работать нескольким операционным системам, при этом совместно используя физические решения, подключенные к шине PCIe, например SSD-накопители.
Виртуализация ввода/вывода с одним корнем (SR-IOV) позволяет разделять ресурсы ввода/вывода между несколькими образами системы на одном хосте, в то время как виртуализация ввода/вывода с несколькими корнями (MR-IOV) предоставляет возможность разделять эти ресурсы между образами системы уже на нескольких хостах. SR-IOV прекрасно работает в многоядерных системах с множеством сокетов, поскольку сокращает количество требуемых устройств ввода/вывода и при необходимости разрешает устанавливать их в системе. SR-IOV поддерживают множество устройств хранения информации, а также другие девайсы.
В отличие от SR-IOV, MR-IOV имеет более сложную структуру и позволяет неиспользуемым устройствам PCIe оставаться в домене с тем хостом, в котором они находятся. К примеру, если хост 1 применил все свои вычислительные ресурсы, а хосты 2 и 3 – нет, то было бы логично, чтобы хост 1 имел доступ к ресурсам хостов 2 и 3. Однако на практике это невозможно, поскольку хосты 2 и 3 находятся за пределами домена хоста 1, а значит, их ресурсы получают статус заблокированных. Выходом из данной ситуации могло бы послужить использование так называемой непрозрачной маршрутизации (Non-transparent bridging, NTB), однако такой подход достаточно сложен и требует установки нестандартных драйверов и программного обеспечения для каждого типа применяемого PCIeустройства. Более подходящим решением станет PCIe Fabric, которая в рамках стандартной топологии способна разместить несколько хостов с доступом к каждой конечной точке.
PCIe Fabric
Комбинируя преимущества устройств хранения информации с поддержкой SR-IOV и динамического разделения, можно создать структуру, лежащую поверх всех хостов, обладающую малой задержкой передачи и позволяющую решить описываемые выше проблемы иерархии. Пример такой структуры – PCIe Fabric, которая позволяет использовать пул GPU и NVMe SSD сразу на нескольких хостах, при этом требуя для работы только стандартные системные драйверы. При установке PCIe Fabric одноранговые (peer-to-peer, P2P) передачи идут непосредственно через саму структуру, что обеспечивает оптимальную маршрутизацию, снижает перегрузку корневого порта и устраняет эффект «бутылочного горлышка» в CPU (см. рис. 3).
Рис. 3. Отдельные домены для каждого хоста и структуры Fabric
Описываемый подход может быть реализован при помощи уже готовых микросхем-коммутаторов PCIe Fabric, таких как Microchip PM42036 PAX 36xG4 Gen 4, и организации двух дискретных, но взаимодействующих доменов: Fabric-домена, объединяющего все конечные точки, а также межкомпонентные каналы и доменов хостов. При такой организации хосты хранятся в отдельных виртуальных доменах, созданных с помощью ПО коммутатора PAX, предустановленного на встроенном процессоре микросхемы, поэтому коммутатор всегда будет отображаться как стандартное одноуровневое устройство PCIe с конечными точками, подключенными напрямую, независимо от того, где в Fabric-домене эти конечные точки находятся.
Транзакции, идущие из доменов хостов, преобразуются в идентификаторы и адреса в Fabric-домене и наоборот, что позволяет организовать маршрутизацию трафика в Fabric-домене и обойти стандартную иерархию PCIe. Это в свою очередь предоставляет доступ к коммутационным каналам, соединяющим коммутаторы и конечные точки, всем хостам в системе. Программное обеспеченнее коммутатора перехватывает весь трафик, идущий от хоста, включая транзакции, возникающие в процессе перечисления PCIe (PCIe enumeration), и виртуализирует простой, соответствующий спецификации PCIe коммутатор с настраиваемым количеством нисходящих портов.
Графические процессоры, подключенные к хостам, расположенным в других доменах, больше не получают статус заблокированных, поскольку теперь могут подключаться динамически в зависимости от потребностей каждого хоста. При использовании PCIe Fabric нет необходимости в установке каких-либо специальных драйверов, так как разделение хостов происходит в соответствии со спецификацией PCIe. Следует также отметить, что так как PCIe Fabric поддерживает P2P, данную технологию вполне можно использовать в приложениях машинного обучения.
Результаты тестирования
На рисунке 4 показан пример, как два хоста могут использовать свои виртуальные функции (VF) независимо друг от друга при помощи Fabric-домена, реализуя тем самым преимущества GPUDirect Storage, удаляя CPU из процесса обмена данными, устраняя эффект «бутылочного горлышка» и другие проблемы, связанные с использованием буфера возврата центрального процессора, предоставляя последнему возможность выполнять только те операции, для которых он лучше всего подходит.
Рис. 4. Пример работы двух хостов через Fabric-домен
При испытании системы, показанной на рисунке 4, на хост 1 была установлена операционная система Windows, а на хост 2 – Linux. В системе также были предусмотрены коммутаторы PAX PCIe, четыре GPGPU Nvidia M40 и один твердотельный накопитель Samsung NVMe с поддержкой SR-IOV. На хостах были запущены процессы, позволяющие эмулировать трафик, соответствующий реальным показателям при работе приложений машинного обучения, включая утилиту Nvidia CUDA для тестирования P2P-трафика и обучающую модель TensorFlow для классификации изображений cifar10. Встроенное ПО коммутатора обеспечивает низкоуровневую настройку и отвечает за управление маршрутами, а сама система управляется при помощи утилиты ChipLink от компании Microchip.
После загрузки Windows-хоста диспетчер PAX Fabric находит все устройства, обнаруженные в структуре с GPU, привязанными к хосту 1 и отображающимися в диспетчере устройств Windows как стандартные устройства. Хост рассматривает коммутатор как простое физическое устройство PCIe с настраиваемым количеством нисходящих портов. Поскольку принцип работы Fabric-структуры скрыт от хоста, он думает, что все четыре графических процессора напрямую подключены к виртуальному коммутатору. На следующем шаге происходит инициализация CUDA и обнаружение ею вышеописанных GPU.
Результаты проведения P2P-теста на пропускную способность с использованием описанной конфигурации показали 12,8 Гбит/с при однонаправленной передаче данных и 24,9 Гбит/с при двунаправленной. Передачи проходят напрямую через PCIe Fabric, минуя центральный процессор хоста. Модель TensorFlow запускается для обучения алгоритма классификации изображений Cifar10, распределяя нагрузку между всеми четырьмя графическими процессорами. После завершения операции два GPU могут быть отсоединены от хоста и возвращены в пул. Так как Fabric-коммутатор эмулирует горячее удаление неиспользуемых GPU, они сразу же становятся доступны в других приложениях.
Хост с предустановленной системой Linux, так же, как и его аналог с ОС Windows, видит в подключенных устройствах простой PCIe-коммутатор, не требующий установки специальных драйверов. Как и в предыдущем случае, как только CUDA обнаружит графические процессоры, может быть запущен тест на пропускную способность при P2P-подключении. Результаты теста оказались схожими с тестом, проведенным ранее для хоста с ОС Windows (см. табл.).
Таблица. Результаты тестов на пропускную способность при P2P-подключении GPU
Теперь, когда обе системы работают, виртуальные функции SR-IOV для SSD можно подключить к хосту с ОС Windows. И снова коммутаторы PAX выглядят как обычные физические устройства NVM, что позволяет хосту использовать стандартный драйвер NVMe. После подключения к хосту с ОС Windows, те же шаги выполняются и для его Linux-аналога, в результате чего в списке блочных устройств хоста 2 появляется новое устройство NVMe.
В описываемом примере используется лишь один SSD, но тот же самый подход можно применить и в RA ID-конфигурации. Надо отметить, что из-за высоких скоростей передачи данных скорость работы и задержка RA ID-контроллера будут иметь в данном случае критическое значение. В настоящее время единственным RA ID-контроллером, способным поддерживать скорость передачи данных 24,9 Гбит/с, является контроллер Microchip SmartRO C 3200 RA ID-on-chip. Он характеризуется низкой задержкой передачи, поддерживает до 16 линий PCIe Gen 4 к хосту и имеет обратную совместимость с PCIe Gen 2. Кроме того, драйвер для данного устройства также интегрирован в интерфейс библиотеки программного обеспечения Nvidia.
Заключение
Независимо от того, в какой конфигурации будет использоваться описанный в статье метод, все виртуальные PCIe-коммутаторы и динамически подключаемое оборудование будет представляться хосту в полном соответствии со спецификацией PCIe. Этот аспект является существенным преимуществом использования PCIe Fabric, поскольку отсутствует необходимость в установке специальных драйверов.
Другое преимущество состоит в том, что микропрограммное обеспечение используемого коммутатора обеспечивает простой интерфейс управления, благодаря чему PCIe Fabric можно управлять и настраивать с помощью недорогого внешнего процессора. Кроме того, режим P2P-передачи на коммутаторе включен по умолчанию и не требует дополнительной настройки или управления со стороны диспетчера.
Подводя итог, можно сказать, что PCIe Fabric – это практическое средство, позволяющее реализовать возможности GPU Direct Storage и не только решить проблемы, связанные с использованием буфера возвратов CPU, но и повысить производительность системы за счет увеличения скорости двунаправленной передачи данных до 24,9 Гбит/с.
Совместное применение методов разделения коммутаторов и SR-IOV позволяет динамически распределять ресурсы GPU и NVMe между несколькими хостами в системе в режиме реального времени, удовлетворяя тем самым высокие требования современных приложений машинного обучения.
MCA841
