Введение – эволюция архитектуры четырех поколений SmartNIC

Выделяют четыре поколения эволюциии архитектуры NIC до SmartNIC [5].

SmartNIC первого поколения

Сетевые карты SmartNIC первого поколения избавили от рудиментарных функций без сохранения состояния, таких как CRC, RSS и т.д.

TOE (TCP offload engine) был первым примером разгрузки с отслеживанием состояния. Однако большая часть сетевой обработки по-прежнему выполнялась на хосте (рис. 1).

Рис. 1. Архитектура «BasicNIC» или «CoreNIC».

Первое поколение SmartNIC именовалось «BasicNIC» или «CoreNIC». Элементарные разгрузки НЕ понимали состояние. У этих сетевых адаптеров не было интеллектуальных возможностей для отправки пакетов на выходной порт без обхода PCIe (влияние на производительность).

Второе поколение SmartNIC

Сетевые адаптеры SmartNIC второго поколения, также известны как «Offload-» / «Feature-» NIC. В них ускорение может быть in-line или side-looking (линейное или “боковое”). Акселератор может добавлять метаданные к пакетам, если они встроены (рис. 1а).

Рис. 1а. Архитектура SmartNIC второго поколения.

Для функций NIC требуется уже несколько интерфейсов для классификации и управления трафиком. FPGA или NPU могут дополнительно разгружать выбранные функции NIC. Классический пример — разгрузка Microsoft GFT (Generic Flow Table) (30% обработки хоста).

Второе поколение обычно называют «разгрузочной сетевой картой».

Третье поколение SmartNIC

В сетевых адаптерах SmartNIC третьего поколения уже появляются ядра общего назначения, которые позволяют перенести программное обеспечение сервера/хоста на аналогичные ядра SMP (Linux). Также появляется выделенная память на сетевой карте для ядер. Разгрузка обычно представляла собой OVS и другие виртуализированные сетевые функции (VNF) (рис. 1б).

Рис. 1б. Архитектура SmartNIC третьего поколения.

Проблемой остается объем обработки пакетов, который могут выполнять ядра SMP. Стандартная функция NIC имела слабые возможности классификации и небольшие/или отсутствующие возможности программирования (однако также были развернуты некоторые устройства с поддержкой языка P4).

Четвертое поколение SmartNIC

Поддерживаемая cкорость соединения в четвертом поколении SmartNIC увеличена до 200-400 Гбит/с. Поддерживается более эффективная обработка состояния на низких уровнях. Реализованная поддержка внешнего машинного обучения/ускорения хранения без участия сервера. Реализована проверенная, открытая программируемость ПО и аппаратная гибкость (рис. 1в).

Рис. 1в. Архитектура SmartNIC четвертого поколения.

Пропускная способность диктует обязательность пути передачи данных с использованием MIMD-архитектуры (Multiple Instruction Multiple Data) с большим количеством небольших ядер в модели «выполнение до завершения». Поддерживается трехуровневая модель обработки. Необходимость затрат (мощность-производительность площадь) приводит к внедрению чиплетов.

Среди ключевых атрибутов SmartNIC четвертого поколения следующие:

• программируемость — многие открытые ядра организованы как комплекс MIMD;
• гибкость — использование чиплетов от экспертов в разных областях (чиплет ввода-вывода, процессорный чиплет, машинное обучение и т.д.);
• компонуемость — использование гетерогенных элементов, использование чипов, произведенных по разным технологиям, повторное использование;
• масштабируемость — согласованная масштабируемая архитектура от 25G до nX100G, без блокировки или потери пакетов (включая очень большие пакеты).

 

По прогнозам Dell’Oro Group [11] рынок SmartNIC будет расти с ежегодными темпами 26% в период с 2021 г. по 2026 г. и к 2026 г. составит 40% рынка Ethernet-адаптеров (рис. 1г).

Рис. 1г. Рынок SmartNIC при среднегодовом темпе роста 26% к 2026 г. будет занимать 60% рынка адаптеров Ethernet.

Intel

Причины появления IPU/DPU

Infrastructure Processing Unit (IPU) – инфраструктурный процессор был представлен в рамках конференции Six Five Summit [1, 2]. В своем выступлении Навин Шеной (Navin Shenoy, Executive VP & GM, Data Platforms Group, Intel, June 21 2021, [1]) отметил следующие причины, вызванные масштабирование дата-центорв и которые стимулировали появление класса устройств IPU (рис. 2):

• затрудненное, перегруженное или неэффективное использование ресурсов;
• динамические сдвиги в производительности рабочей нагрузки, потребности в памяти и хранилище;
• быстро расширяющиеся гибридные среды;
• перегруженный поток данных;
• несовместимые методы безопасности и программные API.

Рис. 2. Причины, стимулирующие разработку IPU [1].

Чтобы сделать использование центра обработки данных более эффективным, классические монолитные программные приложения стали разбиваются на более мелкие сервисориентированные компоненты, которые работают в своих собственных контейнерах, называемых микросервисами (рис. 2). Каждый микросервис содержит собственный балансировщик нагрузки и высокораспределенную и дезагрегированную архитектуру. Преимущества этого подхода включают в себя более легкое восстановление после сбоев программного обеспечения, когда функция в контейнере дает сбой, его рабочую нагрузку можно перенаправить в другой контейнер или микрослужбу и продолжить работу с небольшим влиянием на службу в целом. Или, если существует высокий спрос на ресурсы для одной микрослужбы, система может сделать соответствующий запрос на более динамичное и автоматическое увеличение памяти вычислительных ресурсов для поддержки этой конкретной микрослужбы.

В результате, возникла необходимость в поддержке очень сложных, масштабируемых и высокопроизводительных микросервисов создающих потребность в эффективной оркестровке и эффективном перемещении. Одновременно с этим пример Facebook показывает, что большая часть вычислений в самых разных рабочих нагрузках идет на накладные расходы рабочих нагрузок, таких как перемещение памяти или хеширование и сжатие (рис. 2а). Исследования Google и Facebook показали, что на связь микросервисов может расходоваться от 22% [4] до 80% (https://research.google/pubs/pub44271.pdf) тактов центрального процессора.

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

Как видно из рис. 3, во многих сервисах Facebook большая циклов CPU тратится на их оркестрацию, а не на прикладную логику.

Рис. 3. Распределение циклов CPU в продуктивных микросервисах Facebook [3].

Web. Web реализует виртуальную машину HipHop, систему Just-In-Time для PHP и Hack для обслуживания веб-запросов от конечных пользователей. Web использует параллелизм на уровне запросов для частых обращений к другим микросервисам: входящий запрос назначается рабочему потоку, который обслуживает запрос до завершения [3].

Feed1 и Feed2. Feed1 и Feed2 — это два микросервиса в службе новостей Facebook. Feed2 объединяет ответы различных листовых микросервисов в дискретные «истории», которые за тем характеризуются в виде плотных векторов признаков с помощью экстракторов признаков и изученных моделей. Векторы признаков отправляются в Feed1, который вычисляет и возвращает прогнозируемый вектор релевантности пользователя. Затем истории ранжируются и выбираются для отображения на основе векторов релевантности.

Ads1 и Ads2. Ads1 и Ads2 хранят пользовательские и рекламные данные, соответственно. Когда Ads1 получает запрос объявления, он извлекает пользовательские данные из запроса и отправляет информацию о маркетинге в Ads2. Ads2 поддерживает отсортированный список объявлений, который он просматривает, чтобы вернуть объявления, соответствующие критериям маркетинга, в Ads1. Затем Ads1 ранжирует возвращенные объявления.

Cache1 и Cache2. Cache — это служба кэширования больших объектов с распределенной памятью (похожая на широко используемые эталонные тесты кэширования), которая снижает требования к пропускной способности различных резервных хранилищ. Cache1 и Cache2 соответствуют двум уровням Cache в каждом географическом регионе. Службы клиентов связываются с уровнем Cache2. Если запрос отсутствует в Cache2, он перенаправляется на уровень Cache1. Промахи Cache1 отправляются в базовый кластер базы данных в этом регионе.

Чтобы решить эту “налоговую проблему”, и был предложен IPU, который должен ускорить эту накладную часть функций инфраструктуры, включая виртуализацию сети, виртуализацию хранилища, безопасность или сжатие (рис. 4).

Рис. 4. IPU обеспечивает новый уровень инфраструктурных сервисов дата-центра.

IPU это эволюция линейки Intel SmartNIC, которая в сочетании с микропроцессором Xeon обеспечивает высокоинтеллектуальное ускорение инфраструктуры. Кроме того, IPU позволяет более предсказуемым образом обеспечивать новые уровни изоляции элементов управления безопасностью системы. Также FPGA можно использовать для подключения кастомизированных нагрузок. Таким образом, сочетание этой возможности IPU с продолжающейся тенденцией к микросервисам — это уникальная возможность добиться реализации более оптимального аппаратного и программного обеспечения.

Еще один способ противостоять динамическому сдвигу, который наблюдается в гипермасштабируемом центре обработки данных, и более эффективно обрабатывать рабочие нагрузки — это ускорить эти рабочие нагрузки. Intel делает это двумя способами. Во–первых, Intel к микропроцессору общего назначения добавляет ускорение для более быстрого выполнения определенных рабочих нагрузок. Во-вторых, Intel признает появление XPU – дискретных ускорителей приложений, таких как решения Habana, Gaudi и Goya.

Запуск процессорной платформы Xeon 3-го поколения в начале 2021 года стал новаторским во многих отношениях. Xeon 3-го поколения — это единственный массовый серверный процессор х86 со встроенным ускорением искусственного интеллекта, и поэтому эта возможность привела к огромным улучшениям от поколения к поколению по сравнению с улучшением в 4 раза для тип нагрузки глубокого обучения (рис. 5). Кроме того, уже более десяти лет Intel лидирует в отрасли по снижению стоимости криптографических алгоритмических инноваций благодаря инновациям, которые мы добавили в Xeon, таким как инструкции Intel по ускорению AESNI.

Рис. 5. Intel Xeon 3-го поколения – первый в мире массовый x86 CPU со встроенным ускорителем AI.

Процессор Xeon 3-го поколения укрепляет эту лидирующую позицию благодаря встроенному криптоускорению Intel с революционной производительностью во множестве важных криптографических алгоритмов, включая криптографию с открытым ключом, симметричное шифрование и хеширование – до 4-кратного улучшения криптографической производительности, а также 4-кратного улучшения глубокого обучения по сравнению с предыдущим поколением. Но некоторым из клиентов этого недостаточно и в результате Intel приняла ряд решений о разработке специальных, специализированных, дискретных ускорителей, особенно для обучения ИИ и логического вывода. В 2019 году Intel приобрела компанию Habana Labs.

Использование решений Habana Gaudi в AWS для самых разных приложений, таких как персонализация обработки языка, обнаружение и классификация объектов. В инстансах AWS EC2 используется 8 ускорителей Gaudi, и, возможно, что эти решения будут обеспечивать на 40% лучшую цену и производительность, чем текущие инстансы EC2 на базе графического процессора для машинного обучения (рис. 6). Решение Habana Gaudi это первый ускоритель без графического процессора, предлагаемым для обучения моделей в AWS.

Рис. 6. Решение Habana Gaugi показывает на 40% более лучшую производительность, чем текущие инстансы (на 2020 г.) EC2 на базе графического процессора для машинного обучения.

Недостаточно иметь централизованный центр обработки данных, обрабатывающий информацию. Данные должны обрабатываться ближе к границе, и поэтому поставщики телекоммуникационных услуг осознали это и начали думать о самой сети почти как об облаке. Как сделать сетевые ресурсы доступными для различных приложений? Как сделать сеть более облачной, более виртуализированной, более программируемой, более гибкой? Intel работала вместе с клиентами, поставщиками телекоммуникационных услуг, в течение последнего десятилетия, начиная с перехода к виртуализации сетевых функций для базовой сети, и теперь впервые есть возможность перенести эти облачные свойства на границу сети к тому, что называется RAN или сеть радиодоступа (radio access network).

Старый способ проектирования сетей заключался в использовании в основном проприетарного оборудования с фиксированными функциями в радиомачтах и базовых станциях. Это было отлично с точки зрения производительности, но не идеально с точки зрения затрат или гибкости, и новый способ заключается в том, чтобы в основном использовать серверную технологию, которая используется в облаке и на предприятии на базе процессора Xeon (рис. 7). Intel объединяет ее с программным обеспечением для сети, таким как Flex RAN, для запуска сетевых рабочих нагрузок для RAN на облачной технологии, что позволяет сделать управление сетью более программируемым с виртуализацией. В конечном итоге инфраструктура вышки сотовой связи будет представлять мини-центр обработки данных на границе, который будет поддерживать более эффективные услуги, избавляя от необходимости возвращать большое количество данных в центральный центр обработки данных, одновременно снижая затраты, повышая производительность и улучшая пользовательский опыт. Ведущие операторы, такие как Verizon, Dish Wireless, Telefonica, SK Telecom, Rakuten и многие другие, используют утвержденную облачную архитектуру и строят свои сети 5G вместе с Intel.

Рис. 7. Инфраструктура вышки сотовой связи будет представлять мини-центр обработки данных на границе.

Видение Intel центра обработки данных будущего потребует новой интеллектуальной архитектуры для облака вплоть до периферии: CPU, IPU и XPU будут работать согласованно, чтобы более эффективно запускать масштабируемые микросервисы с разделяемой общей памятью и хранилищем. Это будет возможно благодаря программными платформами с открытым исходным кодом.

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

Такая новая архитектура поможет решить сегодняшние проблемы нехватки ресурсов, перегруженных потоков данных и несовместимых платформенных решений безопасности. Эта интеллектуальная архитектура дата-центра будет иметь три вычислительных категории — CPU для вычислений общего назначения, XPU для ускорения приложений и рабочих нагрузок и IPU для ускорения инфраструктуры — все они будут подключены через интеллектуальную программируемую фабрику для эффективного использования ресурсов дата-центра (рис. 8).

Рис. 8. Интеллектуальная архитектура дата-центра будет иметь три вычислительных категории — CPU для вычислений общего назначения, XPU для ускорения приложений и рабочих нагрузок и IPU для ускорения инфраструктуры — все они будут подключены через интеллектуальную программируемую фабрику.

Блок обработки инфраструктуры (IPU, Infrastructure Processing Unit) – это программируемое сетевое устройство, предназначенное для того, чтобы позволить поставщикам облачных и коммуникационных услуг снизить накладные расходы и высвободить производительность процессоров. Архитектура Intel на базе IPU имеет несколько основных преимуществ:

• сильное разделение функций инфраструктуры и рабочей нагрузки арендатора позволяет арендаторам полностью контролировать ЦП.
• облачный оператор может переложить задачи инфраструктуры на IPU, максимизируя загрузку ЦП и прибыль.
• IPU могут управлять трафиком хранилища, что снижает задержку при эффективном использовании емкости хранилища за счет бездисковой серверной архитектуры (рис. 9).

Рис. 9. Преимущества бездисковой серверной архитектуры.

Благодаря IPU клиенты могут лучше использовать ресурсы с помощью безопасного, программируемого и стабильного решения, которое позволяет им сбалансировать обработку и хранение. Признавая принцип «один размер не подходит для всех», Intel предложила более глубокий взгляд на свою архитектуру IPU и представила следующих новых членов семейства IPU – все они предназначены для решения сложных задач, связанных с разнесенными и рассредоточенными центрами обработки данных.

План развития IPU-решений Intel [7]

В 2021 г. на Architecture Day корпорация Intel представила новую категорию продуктов — Infrastructure Processing Unit (IPU) — для ускорения сетевой инфраструктуры центров обработки данных. Портфель инфраструктурных ускорителей Intel включает 3 класса решений: IPU, IPU-платфомы и SmartNICs (рис. 10).

Рис. 10. Портфель IPU-решений Intel.

В 2022 году на Intel Vision 2022 компания представила дорожную карту IPU на период до 2025 года и далее (рис. 10а).

Рис. 10а. План выхода IPU-решений Intel (https://www.servethehome.com/intel-ipu-plans-revealed-for-800gbps-ipus-in-2025-dpu/).

В настоящее время Intel предлагает два программируемых IPU 200G второго поколения: Oak Springs Canyon и Mount Evans. Oak Springs Canyon основан на процессоре Intel^® Xeon^® D и Intel^® Agilex™ FPGA. Mount Evans — это первый IPU на базе ASIC, который был разработан в сотрудничестве с Google для Google Cloud Platform. IPU Oak Springs Canyon и Mount Evans обеспечивают ускорение инфраструктуры, необходимое для разгрузки рабочих нагрузок 200G, и оба IPU работают совместно с серверами на базе процессоров Intel Xeon.

IPU Mount Evans основан на лучшем в своем классе механизме обработки пакетов, созданном в ASIC. Эта интегральная микросхема ASIC поддерживает множество сетевых сценариев использования, включая разгрузку vSwitch, брандмауэры и виртуальную маршрутизацию, и обеспечивает значительный запас для будущих сценариев использования. IPU Mount Evans эмулирует устройства NVMe с очень высокой скоростью операций ввода-вывода в секунду, используя и расширяя контроллер Intel^® Optane™ NVMe.

IPU на базе ASIC обеспечивают оптимальную производительность и мощность, используемые для безопасной работы в сети и хранения данных. IPU на основе FPGA ускоряют вывод на рынок развивающихся сетевых стандартов, обеспечивают перепрограммируемый и безопасный путь передачи данных и могут более гибко обрабатывать многие типы пользовательских рабочих нагрузок. И Oak Springs Canyon, и Mount Evans поддерживаются общей моделью программирования под названием IPDK (Infrastructure Programmer Development Kit), которая представляет собой независимую от поставщика среду драйверов и API с открытым исходным кодом для разгрузки и управления инфраструктурой, которая работает на многих аппаратных платформах, включая процессоры и IPU.

Microsoft разработала и развернула миллионы Intel FPGA в своей всемирной сети центров обработки данных, демонстрируя значительный опыт Microsoft в использовании FPGA для ускорения инфраструктуры центров обработки данных. Ускорение на основе FPGA привело к 5-кратному сокращению задержки для клиентов Microsoft Azure.

В ближайшие два-три года Intel представит следующее поколение IPU Oak Springs Canyon и Mount Evans на базе ASIC под кодовыми названиями Hot Springs Canyon и Mount Morgan соответственно. Эти IPU следующего поколения будут IPU 400G. Далее в течение 2025 года или позже, Intel выпустит новое поколение IPU на базе 800G FPGA и ASIC.

Корпорация Intel считает, что IPU необходимы для успеха Datacenter of the Future, поскольку IPU снижают нагрузку на инфраструктуру, которая тормозит процессоры серверов. Во всем мире насчитывается более семи миллионов центров обработки данных, начиная от облачных центров обработки данных и заканчивая локальными периферийными центрами обработки данных, и все эти центры обработки данных имеют узкие места в инфраструктуре. IPU могут устранить многие из этих узких мест в инфраструктуре, освободив серверные ЦП для выполнения рабочих нагрузок приложений, а не инфраструктурных задач (рис. 10б).

Рис. 10б. Сферы применения IPU для устранения узких мест инфраструктуры.

IPU Intel уже являются ключевой частью предложения Intelligent Fabric в центрах обработки данных и в первую очередь ориентированы на потребности поставщиков облачных услуг (CSP), но поставщики услуг связи (CoSP) и крупные предприятия также пожинают плоды IPU в своих центрах обработки данных. Процессоры Intel IPU повышают безопасность, снижают накладные расходы и высвобождают ЦП для выполнения бизнес-рабочих нагрузок, изолируя рабочие нагрузки инфраструктуры поставщика услуг от рабочих нагрузок, выполняемых клиентами центра обработки данных.

IPU Intel обеспечиваются мощной программной основой с открытым исходным кодом, в том числе независимой от поставщика IPDK, которая основана на истории работы Intel с сообществом разработчиков ПО с открытым исходным кодом над такими проектами, как SPDK, DPDK и P4, что упрощает разработку передового программного обеспечения и услуг. IPDK позволяет разработчикам сосредоточиться на своих приложениях, а не на базовом API или сложностях оборудования.

IPU обеспечивают множество преимуществ для центра обработки данных, включая превосходную совокупную стоимость владения, улучшенную производительность, повышенную энергоэффективность, меньшую задержку и повышенную безопасность. В результате, операторы связи наряду с CoSP, корпоративными клиентами и клиентами во многих других сегментах рынка уже широко внедряют IPU Intel, поэтому корпорация Intel расширила свою дорожную карту общедоступных IPU еще на два поколения.

Доступность [8]

2022: IPU 2-го поколения:

• Mount Evans, первый процессор Intel ASIC, и Oak Springs Canyon, процессор Intel FPGA второго поколения, поставляемый Google и другим сервис-провайдерам;

 

2023/24: IPU 3-го поколения:

• 400-гигабитные IPU под кодовыми названиями Mount Morganи Hot Springs Canyon, которые, как ожидается, будут доступны для клиентов и партнеров;

 

2025/26:

• ожидается, что 800-гигабитные IPU следующего поколения будут продаваться клиентам и партнерам.

 

200-гигабитные IPU

Mount Evans — это кодовое название первого процессора ASIC от Intel, спроектированного и разработанного с помощью Google Cloud. Он объединяет опыт нескольких поколений FPGA SmartNIC и IPU первого поколения на базе Intel FGPA:

• готовое к гипермасштабированию, оно предлагает высокопроизводительную сеть и разгрузку виртуализации хранилища, сохраняя при этом высокий уровень контроля;
• предоставляет лучший в своем классе программируемый механизм обработки пакетов, позволяющий использовать такие варианты, как брандмауэры и виртуальная маршрутизация; основанный на технологии Intel Optane, для эмуляции устройств NVMe;
• развертывает усовершенствованное ускорение шифрования и сжатия, используя высокопроизводительную технологию Intel® Quick Assist;
• может быть запрограммирован с использованием широко используемых существующих программных сред, включая DPDK, SPDK; конвейер можно настроить с помощью программирования P4;
• ожидается, что поставки Google и другим поставщикам услуг начнутся в 2022 году; широкое развертывание ожидается в 2023 году.

 

Oak Springs Canyon — это кодовое название платформы IPU Intel 2-го поколения на базе FPGA, созданная с использованием Intel^® Xeon^® D и Intel^® Agilex™ FPGA, ведущих в отрасли FPGA по мощности, эффективности и производительности. Oak Springs Canyon предлагает:

• разгрузку функции виртуализации сети для таких рабочих реализует интерфейс хранилища NVM с аппаратным ускорением нагрузок, как открытый виртуальный коммутатор (OVS), и функций хранения, таких как NVMe over Fabric и RoCE v2;
• стандартная, но настраиваемая платформа, которая позволяет клиентам настраивать свой путь передачи данных и свои решения с помощью FPGA и Intel Xeon-D с программным обеспечением, таким как Intel^® Open FPGA Stack, масштабируемой программной и аппаратной инфраструктурой с доступом к исходному коду;
• возможность программирования с использованием широко используемых существующих программных сред, включая DPDK и SPDK, оптимизированных для архитектуры x86;
• более безопасный, высокоскоростной сетевой интерфейс 2x 100Gigabit Ethernet с усиленным криптоблоком;
• поддержка VirtIO в оборудовании для собственной поддержки Linux.

 

400-гигабитные IPU

Mount Morgan — это Intel ASIC IPU следующего поколения. Отгрузка ожидается в 2023/2024 гг.

Hot Springs Canyon — это IPU-платформа нового поколения Intel на базе FPGA. Ожидается, что поставки начнутся в 2023 г., а более широкое развертывание ожидается в 2024 г.

800-гигабайтный IPU следующего поколения Поставки ожидаются в 2025/26 г.

Портфель IPU-решений Intel

Intel^® IPU ASIC E2000 (https://www.intel.com/content/www/us/en/products/details/network-io/ipu/e2000-asic.html)

Intel^® IPU ASIC E2000 (кодовое название – Mount Evans), разработанный совместно с Google, ведущим поставщиком облачных услуг, использует интегрированные знания нескольких поколений Intel^® FPGA SmartNIC для обеспечения высокой производительности при реальных рабочих  нагрузках с безопасностью и изоляцией (рис. 11).

Рис. 11. Архитектура и технические особенности Intel^® IPU E2000.

Intel^® IPU ASIC E2000 позволяет поставщикам облачных услуг и услуг связи сократить накладные расходы и повысить производительность центральных процессоров за счет:

• технологических инноваций: высоко программируемый механизм обработки пакетов, интерфейс хранилища NVM Express, расширенный за счет технологии Intel^® Optane™, надежный транспорт нового поколения, усовершенствованное шифрование и ускорение сжатия;
• дизайна ПО с открытым исходным кодом: комплект для разработки инфраструктурных программ (IPDK) использует и расширяет комплект для разработки плоскости данных (DPDK) и комплект для разработки производительности хранилища (SPDK). IPDK не зависит от поставщика и работает на ЦП, IPU, DPU или коммутаторе.

 

Основные технические особенности и преимущества Intel^® IPU E2000 (https://www.intel.com/content/www/us/en/products/details/network–io/ipu.html):

• возможность подключения: 2 x 100 GbE или 1 x 200 GbE;
• до 16 Arm Neoverse N1 Cores;
• поддержка PCIe 4.0 x16;
• до 48GB DRAM;
• целевые нагрузки для ускорения: обработка пакетов, OVS,NVMe-OF and Storage, RDMA/RoCEV2, Traffic shaping and QoS, Security – Inline and Lookaside Crypto with Compression;
• готовый к гипермасштабируемости, обеспечивает разгрузку высокопроизводительной сети (200 Гбит/с) и виртуализацию хранилища при сохранении высокой степени контроля, безопасности и изоляции приложений пользователей;
• предоставляет лучший в своем классе программируемый механизм обработки пакетов, позволяющий использовать такие варианты использования, как межсетевые экраны и виртуальная маршрутизация;
• может программироваться с использованием существующих, обычно используемых программных сред, включая DPDK, SPDK; конвейер может быть настроен с использованием языка программирования P4, впервые разработанного подразделением Intel Barefoot Switch Division;
• поддержка совместного проектирования SW/HW/Accel;
• реализует интерфейс хранилища NVMe с аппаратным ускорением, масштабируемый по сравнению с технологией Intel Optane, для эмуляции устройств NVMe;
• развертывает усовершенствованное ускорение шифрования и сжатия с использованием высокопроизводительной технологии Intel^® Quick Assist;
• надежный транспорт нового поколения.

 

У Intel есть 3 основных преимущества для своих IPU. В частности, это разделение уровней инфраструктуры и приложений, функции разгрузки инфраструктуры и возможность использования бездисковых сер верных архитектур (рис. 11а, https://www.servethehome.com/intel–mount–evans–dpu–ipu–arm–accelerator–at–hot–chips-33/).

Рис. 11а. Три основных преимущества Intel IPU.

Частью цели Mount Evans является перенос большего количества рабочих нагрузок инфраструктуры на ASIC, а не выполнение их на ЦП, тем самым высвобождая ядра ЦП для продаваемых сервисов сервис-провайдерами или использования для других более важных целей (рис. 11б).

Рис. 11б. Разгрузка основных функций CPU на базе Intel IPU.

Одной из ключевых целей Mount Evans является внедрение инноваций на стороне инициатора хранения. Intel продвигает эту особенность как часть идеи бездисковых серверов. Цель состоит в том, чтобы IPU Mount Evans DPU создал виртуальный том. Этот виртуальный том создается на серверной части инфраструктуры в сети. Для сервера это выглядит как локальное устройство NVMe. Он может управляться поставщиком инфраструктуры, поэтому можно выполнять такие действия, как управление моментальными снимками, расширение емкости и т.д., без необходимости запуска этих функций на центральном процессоре. Другой аспект заключается в том, что Mount Evans может сжимать данные в ASIC перед их передачей по сети. Сжатие и шифрование перед переда чей данных по сети ускоряет внутреннюю передачу и снижает нагрузку на полосу пропускания (рис. 11в).

Рис. 11в. Масштабируемая архитектура хранения на базе Intel IPU.

Одна из ключевых особенностей IPU Mount Evans (поддерживается также и на базе FPGA) является быстрый программируемый механизм обработки пакетов, который можно использовать с помощью языка P4 (существует с 2013 года) и который поддерживает такие процессы, как поиск, изменение, модификация, шифрование и сжатие.

Intel получила P4 от приобретения Barefoot и имеет программируемый конвейер для полнофункционального виртуального коммутатора. Он также может запускать несколько программ P4 одновременно, каждая со своими собственными плоскостями управления.

Barefoot Networks — компьютерная сетевая компания разрабатывает и производит микросхемы программируемых сетевых коммутаторов, системы и программное обеспечение. В июне 2019 г. Intel объявила о приобретении Barefoot по неизвестной цене.  В январе 2023 г. Intel заявила, что остановила производство своих сетевых чипов (https://en.wikipedia.org/wiki/Barefoot_Networks).

Barefoot Tofino — это программируемый чип коммутатора P4, способный работать со скоростью до 6,5 Тбит/с.

Среди поддерживаемых IPU Mount Evans программируемых функций (рис. 11г):

• программируемый конвейер Leadership P4:
  • полная аппаратная поддержка vSwitch и не только;
  • состав конвейера за счет рециркуляции и цепных операций без ущерба для производительности;
  • программируемый синтаксический анализатор, точное совпадение, совпадение с подстановочными знаками, совпадение диапазона, LPM, счетчики, статистика, модификатор;
• MLEvans поддерживает пакетную обработку в масштабе:
  • классификация функций, предназначенных для масштабирования;
  • классификация @scale для > 10 млн записей, поддерживаемых DDR;
  • поддержка операций, управляемых конвейером, таких как автоматическое добавление потока и устаревание;
  • большие кэши L1 с дополнительным SLC в вычислительном кэше;
• тесная связанность с вычислительным комплексом:
  • большие кэши L1, дополнительно поддерживаемые вычислительным кэшем, предназначены для решения задач с гипермасштабируемой производительностью;
  • мультитерабайтная кросс-секционная полоса пропускания между NSS и CC;
  • широкие возможности метаданных, включая передачу данных вычислительному ПО;
• Mt.Evans поддерживает богатую модель программирования обработки пакетов:
  • инструментальная программа на базе P4;
  • логическая композиция конвейера за счет рециркуляции и цепных операций без ущерба для производительности;
• MLEvans поддерживает гибкую, независимую от протокола обработку пакетов:
  • многократный поиск за проход с несколькими типами классификации (точное совпадение, подстановочный знак, диапазон);
  • универсальный редактор, способный произвольно манипулировать заголовками, используя поля пакетов и метаданных с постоянной производительностью независимо от преобразования пакетов.

Рис. 11г. Программируемая обработка пакетов Intel IPU на базе Р4.

Пример реализации карты IPU с IPU ASIC E2000 – рис. 11д.

Рис. 11д. Карта IPU с Intel Mount Evans (Vision 2022, https://www.servethehome.com/intel-e2000-is-the-new-intel-mount-evans-dpu-ipu-brand/).

Intel IPU на базе FPGA (Oak Springs Canyon)

В портфеле Intel две линейки IPU на базе FPGA: Intel^® IPU Plat form C5000X-PL и Intel^® IPU Platform F2000X-PL (табл. 1). Линейки продвигаются Intel на рынке совместно с партнерами Silicom (https://www.silicomusa.com/) и Inventec (https://ebg.inventec.com/en).

Табл. 1. Сравнительные характеристики Intel^® IPU на базе FPGA.

Intel^® IPU Platform F2000X-PL (https://www.intel.com/content/www/us/en/products/details/network-io/ipu/f2000x-pl-platform.html)

Intel^® IPU Platform F2000XPL – это высокопроизводительная платформа ускорения облачной инфраструктуры на базе FPGA с двумя сетевыми интерфейсами 100 GbE. Она может поддерживать рабочие нагрузки облачной инфраструктуры, такие как: обработку пакетов, OVS, NVMe-oF, Security/Isolation, Crypto, RDMA/ RoCEV2 (рис. 12).

Рис. 12. Intel^® Infrastructure Processing Unit (Intel^® IPU) Platform F2000X-PL (https://www.intel.com/content/www/us/en/products/details/network-io/ipu/f2000x-pl-platform.html).

Ключевые особенности Intel^® IPU Platform F2000XPL:

• готовность к гипермасштабированию поддерживать такие как решения OVS, NVMe over Fabrics и RoCE, а также аппаратный криптоблок для обеспечения безопасности на линейной скорости;
• кастомизированная с ориентацией на будущее FPGA обеспечивает настраиваемые рабочие нагрузки благодаря возможности перепрограммирования FPGA и программированию с помощью комплекта для разработки инфраструктурных программ (IPDK), комплекта для разработки плоскости данных (DPDK), комплекта для разработки производительности хранилища (SPDK) и стека Intel^® Open FPGA (Intel^® OFS);

• возможность партнерам и клиентам Intel настраивать свои решения с помощью Intel Open FPGA Stack, масштабируемой программной и аппаратной инфраструктуры с доступным исходным кодом.

 

Intel^® IPU Platform С5000X-PL (https://www.intel.com/content/www/us/en/products/details/network-io/ipu/f2000x-pl-platform.html, рис. 12а)

Рис. 12а. Intel^® IPU Platform C5000X-PL (https://www.intel.com/content/www/us/en/products/details/network-io/ipu/c5000x-pl-platform.html).

В линейке Intel^® IPU Platform С5000X-PL две модели: Silicom IPU C5010X (https://www.silicom-usa.com/pr/fpga-based-cards/40-gigabit-fpga-cards/c5010x-fpga-ipu-nic-intel-based/) и Inventec IPU C5020X (https://ebg.inventec.com/en/product/Accessories/Smart%20NIC%20Card/Inventec%20FPGA%20IPU%20C5020X).

Intel^® IPU Platform С5000X-PL – высокопроизводительная платформа ускорения облачной инфраструктуры на основе FPGA с сетевыми интерфейсами 2x25GbE. Она может поддерживать рабочие нагрузки облачной инфраструктуры, такие как: пакетную обработку, OVS, RDMA/RoCEv2.

Ключевые особенности Intel^® IPU Platform C5000X-PL:

• высокопроизводительная платформа ускорения сети и хранения данных на основе FPGA, идеально подходящая для поставщиков облачных услуг, которым требуются индивидуальные решения, такие как Open vSwitch, NVMe over Fabrics и масштабируемая безопасность;
• Intel^® Stratix^® 10 DX FPGA обеспечивает высокую производительность, малую задержку и настраиваемые функции, а Intel^® Xeon^® предлагает программируемость, соответствующую отраслевым стандартам;
• готовые к производству решения доступны через партнеров ODM.

Примеры использования Intel IPU [6]

По мере того, как сеть центра обработки данных продвигается вперед от 25 GbE к 50 GbE и в область терабитного Ethernet (100+ GbE), она создает беспрецедентные объемы сетевого трафика. Конечным результатом является экспоненциальное увеличение количества пакетов, передаваемых в секунду, что увеличивает нагрузку на возможности традиционной карты сетевого интерфейса (NIC).

Кроме того, появление программно-определяемых сетей (SDN, soft-ware-defined networking) увеличивает нагрузку на серверы, поскольку ядра ЦП поглощаются виртуальными коммутаторами, балансировкой нагрузки, шифрованием, глубокой проверкой пакетов и другими задачами, требующими интенсивного ввода-вывода.

При этом возрастающая сложность ПО для управления, работающего на серверах, еще больше утилизирует CPU. Поэтому возникает реальная необходимость управлять взрывным ростом сетевого трафика, а также разгружать «инфраструктурные» рабочие нагрузки с серверных ЦП, чтобы выделить больше ресурсов для обработки критически важных приложений. Исследования показали, что работа в сети в средах с высокой степенью виртуализации может потреблять до 30% циклов ЦП хоста.

IPU объединяют аппаратные пути передачи данных, которые могут включать FPGA, с процессорными ядрами. Это позволяет обрабатывать инфраструктуру со скоростью аппаратного обеспечения, чтобы не отставать от возрастающих скоростей сети, и гибкости программного обеспечения для реализации функций уровня управления.

При разработке своего первого IPU Intel объединила на одной плате Intel^® Stratix^® 10 FPGA, через который реализован высокоскоростной контроллер Ethernet и программируемый тракт данных, а также процессор Intel^® Xeon^® D для функций плоскости управления.

Сочетание этой возможности с текущей тенденцией в развитии микросервисов открывает уникальную возможность для функционально-ориентированной инфраструктуры, достигаемой за счет подбора оптимальных аппаратных компонентов и общих программных платформ для каждого приложения или службы. Для CSP это дает возможность ускорить работу облака при одновременном размещении большего количества сервисов (приложений/виртуальных машин) на одном компьютере, что приводит к улучшению предоставления услуг и увеличению потенциальной прибыли на каждый сервер.

Программируемые логические блоки ПЛИС Intel^® Stratix^® 10 обеспечивают высокопроизводительный способ выполнения таких задач, как обработка пакетов. Более того, набор инструментов Intel^® Toolkit с открытым стандартом и связанные библиотеки обеспечивают единую модель программирования, позволяющую разработчикам быстрее и проще развертывать решения. Кроме того, процессор Intel^® Xeon^® D с упором на эффективность и работу в сети в сочетании с комплектом разработки Data Plane Development Kit (DPDK) и комплектом Storage Performance Development Kit (SPDK) с открытым исходным кодом поддерживает разгрузку задач серверного ЦП, обеспечивая при этом полную совместимость с архитектурой x86, что устраняет необходимость перекодирования и снижает риски. Основываясь на обширных исследованиях и опыте, Intel продолжает совместную работу над сетевой экосистемой, чтобы вывести на рынок продукты IPU от таких компаний, как Silicom (https://www.silicomusa.com/) и Inventec (https://ebg.inventec.com/en).

Ведущие гипермасштабируемые CSP продвигают варианты использования IPU разгрузки, реализуя ценность IPU поэтапно. На типичном сервере хост-процессор выделяет циклы ЦП гипервизору, который может содержать виртуальный коммутатор, стек хранения и функции безопасности, а также различные приложения, которые могут выполняться на виртуальной машине или в контейнерах. Можно выделить 4 этапа IPU разгрузки (рис. 13):

• этап 1 – ускоренная работа в сети – перенос обычной функции виртуального коммутатора с процессора хост-приложений на IPU;
• этап 2 – ускоренное хранение — перенос стека хранения с процессора хост-приложений на IPU, что увеличивает пропускную способность и снижает сложность и накладные расходы;
• этап 3 – ускоренная безопасность — разгрузка шифрования/дешифрования, сжатия и других функций безопасности, которые в противном случае потребовали бы интенсивного использования ЦП процессора хост-приложений. (Эти функции часто сочетаются с сетевыми функциями и функциями хранения, которые были разгружены на этапах 1 и 2);
• этап 4 – инфраструктурная обработка — перенос функций управления службами гипервизора с процессора хост-приложений на IPU.

Рис. 13. Возможная этапность внедрения Intel^® IPU [6].

Этап 4 создает ценность двумя способами. Во-первых, существует сценарий «голого железа», когда клиент (арендатор) арендует весь физический сервер, в то время как CSP может управлять его работой с помощью подхода разгрузки IPU, предоставляя отдельный домен безопасности и физическую изоляцию от самого сервера приложений. Это обеспечивает арендатору полную работу с «голым железом» с отдельной платформой (через IPU) для поставщика служб шифрования для предоставления и защиты службы.

Во-вторых, в многопользовательской виртуализированной среде (рис. 13), где гипервизор имеет множество приложений, работающих на виртуальных машинах, функциональность гипервизора переносится на IPU. Это обеспечивает лучшую изоляцию для CSP и возможность справедливо распределять службы инфраструктуры сети и хранилища на эти виртуальные машины или контейнеры.

Как отмечалось выше [3], гипермасштабируемые провайдеры оценивают накладные расходы на связь микросервисов от 22% до 80% циклов ЦП. Это означает, что от 20% до 78% дорогостоящих ресурсов ЦП недоступны для «аренды», поэтому и более безопасный сервис, но также дает возможность монетизировать больше ресурсов сервера.

Укоренилась новая аксиома бизнеса — каждый бизнес — это технологический бизнес. Технологии больше не являются одним из определяющих факторов успеха — они становятся ключевым фактором успеха. Центральное место в этом занимают ИТ-стратегии DevOps и микросервисов. В совокупности они помогают организациям быстро разрабатывать, развертывать и масштабировать новые услуги.

Infrastructure Programmer Development Kit (IPDK)

Появление IPU и DPU на рынке ознаменовало новый этап развития современной системной ИТ-архитектуры и переход от архитектуры, ориентированной на ЦП, к набору независимых устройств и программно-определяемых функций устройств – к дезагрегированной и компонуемой системной архитектуре. Основные характеристики этой новой архитектуры (рис. 14):

• наличие собственного процессора общего назначения;
• возможность загрузки ОС общего назначения;
• возможности аппаратного ускорения для конкретных доменов;
• программно-определяемые функции устройства, которые позволяют развернутым на них программным компонентам определять функции устройства, представляемые хосту;
• разгрузка целых программных подсистем, таких как стек сети или хранилища, включая их уровни управления;
• строгая изоляция безопасности от хоста на аппаратном уровне;
• уникальный сетевой идентификатор;
• внеполосное (оut-of-band) управление, когда устройство, подобное блоку обработки данных/инфраструктуры (DPU/IPU), управляется отдельно от сервера, на котором оно находится, или устройство, подобное DPU/IPU, может использоваться для управления сервером.

Рис. 14. Сравнение архитектур SmartNIC и IPU/DPU [10].

Одновременно IPU/DPU выявили ряд проблем:

• несоответствие программного обеспечения аппаратным абстракциям и границам доверия;
• гипервизоры не могут эффективно абстрагировать специфичное для домена оборудование;
• желание использовать полностью CPU хоста для рабочих нагрузок приложений.

 

Для решения возникших сложностей внедрения IPU/DPU Intel инициировало проект IPDK, цель которого:

• создать управляемую сообществом открытую экосистему на основе стандартов для технологий, подобных DPU/IPU;
• создайте независимую от поставщика структуру и архитектуру для программных стеков на основе DPU/IPU;
• при необходимости повторно использовать существующие или определить набор новых общих API для технологий, подобных DPU/IPU;
• предоставить примеры реализации для проверки архитектур/API.

 

IPDK (https://ipdk.io/) — это открытый, не зависящий от поставщика фреймворк драйверов и API для разгрузки и управления инфраструктурой, работающий на CPU, IPU, DPU или коммутаторе (рис. 14а). IPDK работает в Linux и использует набор хорошо зарекомендовавших себя инструментов, таких как SPDK, DPDK и P4, для обеспечения виртуализации сети, виртуализации хранилища, предоставления рабочей нагрузки, корневого доверия и возможностей разгрузки, имеющихся на платформе. IPDK предоставляет общую платформу для повышения производительности, оптимизации ресурсов и защиты инфраструктуры в качестве под проекта Open Programmable Infrastructure (https://opiproject.org), проекта Linux Foundation (https://www.linuxfoundation.org/projects/).

IPDK поддерживает два стандартных интерфейса (см. рис. 14а):

– интерфейс инфраструктурных приложений:

• поддержка устройств и служб для приложений рабочей нагрузки;
• поддержка возможностей платформы на основе RPC (Re mote Procedure Call. RPC – это программный коммуникационный протокол, который одна программа может использовать для запроса услуги у программы, расположенной на другом компьютере в сети, без необходимости разбираться в деталях сети; https://www.techtarget.com/search–apparchitecture/definition/Remote–Procedure–Call–RPC);

– целевой интерфейс абстракции (TAI, Target Abstraction Interface):

• поддержка возможностей целей (Target Capabilities);
• поддержка функциональных API.

Рис. 14a. Архитектура IPDK.

Среди основных применений IPDK:

• разработка IaaS-сервисов – виртуальная сеть, хранилище и криптография для виртуальных машин, контейнеров и «голого железа»;
• разработка PaaS-сервисов – контейнерная сеть (Kubernetes) Sidecars (Envoy, MongoDB);
• разработка встроенного ускорения (Inline Acceleration) – Firewall, IDS, Network Telemetry 5G/Wireless Infrastructure, AI/ML.

Пример использования – IaaS-сервисы (рис.15, [9]):

• общее управление – одни и те же приложения IPDK в обоих случаях;
• общие интерфейсы – та же семантика для подключения устройств к хостам и виртуальным машинам;
• целевая абстракция – те же API, что и для KVM Target и Hardware Target.

Рис. 15. Пример развертывания IaaSсервисов на базе IPDK [9].

26 января 2023 г. был представлен второй выпуск IPDK версии 23.01, созданного, чтобы помочь разработчикам, работающим над программируемой инфраструктурой, быстро переносить свои приложения на платформы данных с открытым исходным кодом, работающие на процессорах, IPU, DPU и коммутаторах. Этот выпуск включает в себя (https://ipdk.io/news/2023/01/26/22-07-Release):

• обновления и улучшения рецепта для Infrastructure-as-a-Service («инфраструктура как услуга») – Virtual Networking Recipe (https://ipdk.io/documentation/Recipes/InfrastructureNetworking/);
• обновления и улучшения рецепта для Infrastructure-as-a-Service («инфраструктура как услуга») – Virtual Block Storage Recipe (https://ipdk.io/documentation/Recipes/VirtualBlockStorage/);
• первоначальный выпуск Kubernetes Networking Infrastructure Offload Recipe (https://ipdk.io/documentation/Recipes/PaaSOffloadKubernetes/);
• предварительный просмотр Inline IPsec Recipe (https://ipdk.io/documentation/Recipes/InlineIPsec/);
• обновления и улучшения для P4 DPDK as an IPDK Target P4DPDK Dataplane (https://github.com/p4lang/p4-dpdk-target) с p4.org (https://p4.org/).

 

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

Linux Foundation объявила (https://www.linuxfoundation.org/press–release/linux–foundation–announces–open–programmable–infrastructure–project/) о проекте Open Programmable Infrastructure (OPI, https://opiproject.org/), и IPDK присоединился к OPI в качестве подпроекта. Цели OPI – создание открытой экосистемы для архитектур и платформ следующего поколения, а также разработка открытого исходного кода IPDK.io как части OPI с общим управлением.

Целевой интерфейс абстракции (TAI, Target Abstraction Interface, https://ipdk.io/documentation/Interfaces/TargetAbstraction/) — это много платформенная абстракция, позволяющая как программным, так и аппаратным целевым объектам поддерживать рецепты, включенные в выпуске. Интерфейс приложений инфраструктуры (InfraApp, Infrastructure Application Interface, https://ipdk.io/documentation/Interfaces/InfraApp/) — это набор RPC, который обеспечивает оркестрацию SDN и управление инфраструктурой, включая поддержку программирования инфраструктуры с использованием P4.

Включенная программная цель использует KVM и vhost-user для поддержки виртуальных портов (virtio-net) и виртуальных дисков (virtio-blk) для инфраструктуры как услуги на основе виртуальных машин. Семантика добавления и удаления виртуальных устройств из KVM расширена до аппаратных целей, совместимых с TAI, для поддержки хостинга IaaS на «голом железе». Это обеспечивает общий интерфейс между экземплярами, размещенными на виртуальных машинах, работающими в программной инфраструктуре, и IaaS-хостингом на «голом железе» на основе IPU, DPU или коммутатора, а также позволяет экземплярам совместно использовать виртуальные сети и перемещать виртуальные диски между собой. Табличный интерфейс (Table Driven Interface, https://github.com/p4lang/tdi) от p4.org обеспечивает абстракцию, управляемую объектной моделью, на уровне TAI, позволяющую декларировать и компилировать требования приложений в соответствии с возможностями базовых программируемых целей. Разработчики, желающие перенести новые цели, могут начать с бэкенда p4-dpdk-targetс открытым исходным кодом в качестве эталона для подключения к набору рецептов, поддерживаемых в выпуске.

Виртуальная сеть устанавливается и настраивается с помощью OVS, который был исправлен для поддержки программируемой плоскости данных p4 и для удобства упакован в сетевой контейнер. Эти исправления предназначены для рассмотрения обратно в openvswitch.org (http://www.openvswitch.org/) и не предназначены для постоянной поддержки. Интеграция OVS и P4 также включает интеграцию с плоскостью данных ядра Linux, что позволяет нескольким плоскостям управления на базе Linux, таким как маршрутизация, объединение и туннелирование, работать одновременно с приложениями SDN, подключающимися через P4Runtime (https://p4.org/p4-spec/p4runtime/main/P4Runtime–Spec.html). Виртуальное блочное хранилище настраивается и настраивается с помощью SPDK (https://spdk.io), который используется в качестве примера приложения для демонстрации управления виртуальными устройствами, подключенными к протоколу хранения, в данном случае NVM-eover-TCP. SPDK также упакован в контейнер, чтобы упростить воспроизведение установки.

Планы Intel дальнейшего развитии IPDK [9]:

• агенты для использования IaaS и PaaS;
• полный набор функций для работы в сети, хранения и шифрования;
• полный набор функций для каждого интерфейса;
• интеграция SONiC (PINS);
• Intel также планирует предложить следующие аппаратные цели IPDK – серия Intel^® Tofino™, межсетевой процессор Mount Evans и межсетевой процессор Oak Springs Canyon.

NVIDIA

Nvidia  BlueField-3

21 марта 2023 г. Nvidia объявила об общедоступности (GA) своего блока обработки данных (DPU) BlueField-3. BlueField-3 представляет собой DPU третьего поколения от Nvidia и содержит около 22 миллиардов транзисторов. Новый DPU (рис. 16) поддерживает подключение Ethernet и InfiniBand со скоростью до «400 гигабит в секунду и обеспечивает в 4 раза большую вычислительную мощность, в 4 раза более быстрое криптоускорение, в 2 раза более быструю обработку данных и в 4 раза большую пропускную способность памяти по сравнению с предыдущим поколением BlueField», – согласно заявлению Nvidia (https://nvidianews.nvidia.com/news/oracle–cloud–infrastructure–chooses–nvidia–bluefield–data–center–acceleration–platform, https://www.hpcwire.com/2023/03/21/nvidia–announces–bluefield-3-ga–oracle–cloud–is–early–user/).

Рис. 16. Nvidia  BlueField-3.

В своем выступлении на GTC 23 генеральный директор Nvidia Дженсен Хуанг (Jensen Huang) сказал: «В современном программно-определяемом центре обработки данных операционная система, обеспечивающая виртуализацию, сетевое взаимодействие, хранение и безопасность, может потреблять почти половину ядер ЦП центра обработки данных и соответствующей мощности. Центры обработки данных должны ускорять каждую рабочую нагрузку, чтобы высвобождать энергию и освобождать ЦП для рабочей нагрузки, приносящей доход. Nvidia BlueField разгружает и ускоряет операционную систему центра обработки данных и программное обеспечение инфраструктуры».

Хуанг упомянул «более двух десятков партнеров по экосистеме», включая такие имена, как Cisco, DDN, Dell EMC и Juniper, которые сейчас используют технологию BlueField.

Кевин Дейерлинг, вице-президент по сетям, сказал: «BlueField-3 находится в полном производстве и доступен. Он имеет в два раза больше процессорных ядер Arm в сравнении с BlueField-2, больше ускорителей и выполняет рабочие нагрузки до восьми раз быстрее, чем наш DPU предыдущего поколения. BlueField-3 разгружает, ускоряет и изолирует рабочие нагрузки в облачных высоко производительных вычислениях, предприятиях и сценариях использования ускоренного ИИ».

Nvidia ориентируется на суперкомпьютеры, центры обработки данных и облачных провайдеров для своих DPU. На GTC Nvidia рекламировала развертывание Oracle Cloud Deployment, в котором BlueField-3 является частью более крупной победы Nvidia в DGX-in-the-Cloud (https://www.hpcwire.com/2023/03/21/nvidia–saifactory–services–start–at-37000/).

«Oracle Cloud Infrastructure — первая компания, которая запускает службу супервычислений DGX Cloud и ИИ, которая дает предприятиям немедленный доступ к инфраструктуре и ПО, необходимым для обучения передовых моделей для генеративного ИИ. Компания OCI также выбрала BlueField-3 для повышения производительности, эффективности и безопасности. BlueField-3 обеспечивает значительный прирост производительности и эффективности за счет разгрузки задач инфраструктуры центра обработки данных с ЦП, увеличивая количество виртуализированных экземпляров в восемь раз по сравнению с BluField-2», — сказал Дайерлинг.

Nvidia также сообщила, что BlueField3 обладает полной обратной совместимостью через программную среду DOCA (https://developer.nvidia.com/blog/transform–the–data–center–for–the–ai–era–with–nvidia–dpus–and–nvidia–doca/).

Сравнение структурных схем NVIDIA BlueField-2 и NVIDIA BlueField-3 дано на рис. 17 [14].

NVIDIA BLUEFIELD–2 DPU

ConnectX-6 Dx inside
200 Gbps Ethernet & InfiniBand, NRZ & PAM4 modulation
8 ARM A72 CPUs subsystem in a Tile architecture
– 8MB L2 cache, 6MB L3 cache in 4 Tiles
– ARM Frequency up-to 2.75GHz
Fully integrated PCIe switch, 16 bifurcated Gen4.0
– Root Complex or End Point modes
1GbE Out-of-Band management port

NVIDIA BLUEFIELD–3 DPU

ConnectX-7 inside
I/O
– 2x400Gbs (Active/Standby), 4x100Gbs Ethernet/InfiniBand
– 100G PAM4 serdes
– 400Gb/s bandwidth
– Integrated PCIe switch
– Gen5.0 x32+2
– Multi-host – 8 hosts
Compute sub-system
– 16 Arm®A78 v8.2+ Hercules @2.3GHz
– SkyMesh fully coherent low-latency interconnect
– 8MB L2 Cache, 16MB LLC System Cache
Built-in accelerators Advanced Memory sub-system
– Dual Channel 256GB DDR5-4800MT/s w/ ECC
– NVDIMM-N Support
– DDR memory encryption 1GbE Out-Of-Band management port
Self-hosted or Server-hosted
Technical Overview

Рис. 17. Сравнение структурных схем NVIDIA BlueField-2 и NVIDIA BlueField-3.

DOCA (DOCA 2.0 — его последняя версия) — это инструмент программирования для BlueField. Nvidia постоянно добавляет новые функции в линейку DPU. Недавно, например, была усилена встроенная обработка пакетов графического процессора для реализации решений с высокой скоростью передачи данных: фильтрация данных, размещение данных, сетевой анализ, обработка сигналов датчиков и многое другое. Новая библиотека DOCA GPUNetIO (https://developer.nvidia.com/blog/inline–gpu–packet–processing–with–nvidia–doca–gpunetio/) может преодолеть некоторые ограничения, обнаруженные в предыдущем решении DPDK (рис. 17а).

Рис. 17а. NVIDIA DOCA 2.0 software framework.

NVIDIA планирует выпускать новое поколение своих DPU каждые 18 месяцев, поддерживая экспоненциальный рост производительности (рис. 18, https://www.servethehome.com/nvidia–bluefield-3–dpu–architecture–at–hot–chips-33/).

Рис. 18. План выхода моделей BlueField.

Блок обработки данных (DPU, data processing unit) NVIDIA® BlueField®-3 — это инфраструктурная вычислительная платформа 3-го поколения, которая позволяет создавать программно-определяемые ИТ-инфраструктуры с аппаратным ускорением от облака до центра обработки данных и периферии. Благодаря сетевому подключению Ethernet 400 Гбит/с или InfiniBand NDR 400 Гбит/с DPU BlueField-3 разгружает, ускоряет и изолирует программно-определяемые сетевые функции, функции хранения, безопасности и управления, значительно повышая производительность, эффективность и безопасность центра обработки данных. Обеспечивая мощные вычисления и широкий спектр программируемых механизмов ускорения на пути ввода-вывода, BlueField-3 подходит для удовлетворения потребностей в инфраструктуре самых требовательных приложений, обеспечивая при этом полную обратную совместимость программного обеспечения благодаря программной среде NVIDIA DOCA™. DPU BlueField-3 превращают традиционные вычислительные среды в высокопроизводительные, эффективные и устойчивые центры обработки данных, позволяя организациям выполнять рабочие нагрузки приложений в безопасных многопользовательских средах. Отделяя инфраструктуру центра обработки данных от бизнес-приложений, BlueField-3 повышает безопасность центра обработки данных, оптимизирует операции и снижает общую стоимость владения. Используя технологию сетевых вычислений NVIDIA, BlueField-3 позволяет использовать суперкомпьютерные платформы следующего поколения, обеспечивая оптимальную производительность «голого железа» и встроенную поддержку изоляции арендаторов с несколькими узлами. Основные варианты моделей BlueField-3 и ключевые характеристики управления:

• 1 или 2 порта со скоростью подключения до 400 Гбит/с;
• 32 ГБ встроенной памяти DDR5;
• форм-факторы: HHHL, FHHL;
• внешний порт управления 1GbE;
• встроенный BMC.

 

Более полный список характеристик NVIDIA BlueField-3 DPU – табл.2.

Табл. 2. Основные характеристики NVIDIA BlueField-3 DPU.

Семейство моделей карт BlueField-3 [16]

DPU BlueField-3 состоит из трех основных блоков:

• сеть: NVIDIA ConnectX-7 SmartNIC последнего поколения со встроенными сетевыми и аппаратными ускорителями безопасности;
• программируемые вычисления: мощный кластер из 16 процессоров ARM A78 v2 с полностью когерентным межсетевым соединением с малой задержкой, оптимизированным для приложений плоскости управления. Программируемость плоскости данных достигается за счет ускоренного конвейера и нового программируемого ускорителя пути к данным (DPA). DPA — это процессор ввода-вывода и обработки пакетов, состоящий из 16 ядер с поддержкой Hyper-Threading, специально созданный для задач с интенсивным вводом-выводом и низкими вычислительными затратами, таких как эмуляция устройства, контроль перегрузки, пользовательские протоколы и т.д.;
• память: два 64-битных интерфейса памяти DDR5-5600 (пропускная способность 80 GB) и встроенный 32-канальный коммутатор PCIe Gen0. Интерфейс PCIe может быть раздвоен и использоваться либо как серверный (конечная точка), либо как самостоятельный (корневой комплекс) для управления GPU или напрямую подключенными SSD-устройствами.

 

Выступая в роли «сервера перед сервером», BlueField-3 является единственной платформой DPU со встроенным контроллером управления основной платой ASPEED AST2600 (BMC). BlueField BMC — это специальный процессор, который отслеживает физическое состояние платы DPU и позволяет системному администратору управлять платформой через независимое соединение. Это повышает безопасность, надежность, доступность и удобство обслуживания системы.

DPU BMC — это доверенное лицо с собственным внешним корнем доверия, обеспечивающим защиту встроенного ПО. Он позволяет предоставлять ресурсы BlueField DPU и управлять ими через отдельную внеполосную сеть управления, используя стандартные интерфейсы и протокол Redfish для управления полным жизненным циклом DPU.

Некоторые из функций BMC включают в себя:

• доступ через консольный интерфейс к BlueField DPU;
• настройка конфигурации BlueField UEFI;
• мониторинг BlueField DPU и его ресурсов;
• обновление и восстановление прошивки BlueField DPU;
• сброс управления (даже если ОС BlueField остановлена).

 

NVIDIA предлагает широкий спектр платформ BlueField-3 (рис. 18а), предназначенных для удовлетворения уникальных потребностей в вычислениях, памяти и производительности для различных отраслей и вариантов использования. Это позволяет клиентам выбрать правильный продукт BlueField-3, соответствующий их конкретным требованиям, и в то же время пользоваться расширенными функциями и передовой производительностью.

 

 Рис. 18а. Платформы NVIDIA BlueField-3 DPU с целевыми рынками.

Целевые рынки и флагманские платформы

DPU BlueField-3 используются на нескольких ключевых флагманских платформах и целевых рынках.

Гипермасштабируемые HPC/ИИ

Рабочие нагрузки HPC и AI первыми охватывают скорость сети 400 Гбит/с (NDR InfiniBand и 400 GbE), поскольку HPC — это максимальная производительность и огромные масштабы. BlueField расширяет возможности сетевых вычислений NVIDIA, используя свои ядра Arm для выгрузки элементов библиотеки интерфейса передачи сообщений (MPI) из центрального процессора системы и реализации неблокирующих коллективных операций. Это позволяет центральному процессору системы выполнять вычисления с перекрытием пиков.

B3240 – обладает высокой производительностью и сетевыми возможностями для удовлетворения самых сложных потребностей гипермасштабируемых высокопроизводительных вычислений/ ИИ. Эта платформа BlueField-3 позволяет таким системам, как NVIDIA DGX H100, выполнять научные исследования или генеративные задачи искусственного интеллекта. Он использует двойное подключение NDR 400 Гбит/с, подсистему памяти DDR5 32 ГБ и частоту ядра Arm 2,3 ГГц.

B3140H – имеет форм-фактор половинной высоты и половинной длины (HHHL), что делает его совместимым с большинством корпоративных серверов. Это устройство оснащено одним портом 400 Гбит/с и памятью DDR5 объемом 16 ГБ, при этом работая в условиях низкого энергопотребления. Это делает его идеальным выбором для сред HPC/AI, которым требуется масштабируемая производительность в условиях ограниченного пространства или доступной мощности.

Облачные вычисления

Быстрый рост, который переживает облачная индустрия, требует, чтобы поставщики облачных услуг постоянно внедряли инновации и адаптировали свои предложения услуг для удовлетворения потребностей клиентов. Современные облачные платформы используют виртуализацию на основе гипервизора, чтобы максимизировать количество виртуальных экземпляров, выделенных арендаторам как на уровне вычислительных ресурсов, так и на уровне центра обработки данных. BlueField-3, который поддерживает до 4096 виртуальных функций, позволяет поставщикам облачных услуг размещать в 48 раз больше виртуальных экземпляров на платформе облачных вычислений по сравнению с предыдущим поколением.

B3220 – обеспечивая двойную поддержку 200 Гбит/с, подсистему памяти DDR5 объемом 32 ГБ и частоту ядер Arm 2,3 ГГц, B3220 обладает производительностью и сетевыми возможностями для удовлетворения самых сложных облачных потребностей. Вот почему гипермасштабирующая компания Oracle Cloud Infrastructure (OCI) добавила BlueField-3 в свой сетевой стек, чтобы обеспечить современную устойчивую облачную инфраструктуру с высочайшей производительностью. Платформа B3220 также поддерживает системы NVIDIA OVX 3.0, обеспечивая более высокую производительность, безопасность с нулевым доверием и неограниченное масштабирование промышленных метавселенных приложений в облаке.

B3210 – при скорости 100 Гбит/с B3210 наилучшим образом соответствует требованиям ведущих корпоративных центров обработки данных. B3210 — это целевой DPU для запуска корпоративной платформы рабочих нагрузок VMware vSphere, повышающий производительность, эффективность и безопасность для тысяч компаний.

Хранилище

B3220SH – платформа B3220SH с собственным хостингом оптимизирована для систем хранения NVMe со встроенными ускорителями NVMe-oF или NVMe/TCP или данных в состоянии покоя. B3220SH может разместить до 16 твердотельных накопителей с использованием интерфейса x32 PCIe Gen 5.0.

Тестирование BlueField-2/3

На рис. 18б даны результаты тестирования BlueField-2 со стандартными NIC, представленные на конференции Hot Chips 2021 (https://hc33.hotchips.org/) [15].

Рис. 18б. Результаты тестирования BlueField-2 DPU со стандартными NIC [15].

NVIDIA BlueField-3 — это DPU NVIDIA третьего поколения с 22 миллиардами транзисторов. Это устройство типа «система на кристалле» (SoC), обеспечивающее подключение Ethernet и InfiniBand на скорости до 400 Гбит/с. Поддерживая до четырех различных MAC-адресов, BlueField-3 может предлагать различные конфигурации портов от одного порта, работающего на 400 Гбит/с (четыре линии PAM4 112), до четырех портов, работающих на скоростях 25, 50 или 100 Гбит/с.

BlueField-3 имеет в 2 раза большую пропускную способность сети, 4-кратную вычислительную мощность и почти 5-кратную пропускную способность памяти по сравнению с предыдущим поколением — и все это при полной обратной совместимости благодаря программной среде NVIDIA DOCA.

Эти ключевые усовершенствования позволяют BlueField-3 выполнять рабочие нагрузки до 8 раз быстрее, снижая совокупную стоимость владения и обеспечивая энергоэффективность центра обработки данных. Например, Bluefield3 разгружает коллективные операции HPC/AI MPI с центрального процессора, обеспечивая почти 20-процентное увеличение скорости, что означает экономию средств в размере 18 миллионов долларов для крупномасштабных суперкомпьютеров. Дополнительную информацию см. в разделе «Зеленый поезд»: DPU NVIDIA BlueField повышают эффективность центра обработки данных (рис. 18в).

Рис. 18в. DPU NVIDIA BlueField-3 продемонстрировал в четыре раза большую пропускную способность памяти и вычислительную мощность по сравнению с DPU NVIDIA BlueField-2.

BlueField-3 предлагает значительные улучшения производительности по сравнению с его предшественником, что делает его идеальным решением для рабочих нагрузок ИИ с интенсивным использованием данных, которым требуется высокопроизводительная сеть. На рис. 18г показаны результаты тестов, свидетельствующие о лучшей производительности сети BlueField-3.

Рис. 18г. Сравнение результатов тестирования DPU NVIDIA BlueField-2 и BlueField-3.

Встроенная обработка пакетов GPU с помощью NVIDIA DOCA GPUNetIO [12]

Растущее число сетевых приложений нуждается в обработке пакетов GPU в режиме реального времени для реализации решений с высокой скоростью передачи данных: фильтрация данных, размещение данных, сетевой анализ, обработка сигналов датчиков и многое другое.

Одной из основных причин этого является высокая степень параллелизма, которую GPU может обеспечить для параллельной обработки нескольких пакетов, обеспечивая при этом масштабируемость и программируемость. Обзор основных концепций этих методов и первоначальное решение, основанное на библиотеке DPDK gpudev, был представлен в посте Boosting Inline Packet Processing Using DPDK and GPUdev with GPUs (Ускорение встроенной обработки пакетов с помощью DPDK и GPUdev с графическими процессорами, [13]).

Новая библиотека NVIDIA DOCA GPUNetIO снимает ряд ограничений предыдущего метода, полностью устраняя CPU из процесса обработки.

Обработка сетевых пакетов GPU в реальном времени — это метод, полезный для нескольких различных областей приложений, включая обработку сигналов, сетевую безопасность, сбор информации и реконструкцию входных данных. Целью этих приложений является реализация встроенного конвейера обработки пакетов для приема пакетов в память графического процессора (без размещения копий в памяти процессора); обрабатывать их параллельно с одним или несколькими ядрами CUDA; а затем запустить вывод, оценить или отправить по сети результат расчета.

Как правило, в этом конвейере ЦП является посредником, поскольку он должен синхронизировать действия по приему сетевой карты (NIC) с обработкой графического процессора. Это активирует ядро CUDA, как только в память GPU поступают новые пакеты. Аналогичные соображения могут быть применены к отправляющей стороне конвейера (рис. 19).

Рис. 19. Приложение, ориентированное на ЦП, в котором ЦП управляет работой GPU и сетевой карты.

В рамках фреймворка Data Plane Development Kit (DPDK, https://www.dpdk.org) была представлена библиотека gpudev (https://doc.dpdk.org/guides/prog_guide/gpudev.html), которая обеспечивала решение для такого рода приложений: получение или отправка с использованием памяти GPU (технология GPUDirect RDMA) в сочетании с синхронизацией ЦП с малой задержкой (доп. сведения о различных подходах к координации работы ЦП и GPU – [13]).

GPUDirect Асинхронная сетевая связь, инициируемая ядром (GPUDirect Async Kernel-Initiated Network communications)

Рисунок 19 показывает, что центральный процессор является основным узким местом. У него слишком много обязанностей по синхронизации задач NIC и GPU и управлению несколькими сетевыми очередями. В качестве примера рассмотрим приложение с множеством очередей приема и входящим трафиком 100 Гбит/с. Решение, ориентированное на ЦП, будет иметь следующие события:

• CPU вызывает сетевую функцию в каждой очереди приема для приема пакетов в память GPU с использованием одного или нескольких ядер ЦП;
• CPU собирает информацию о пакетах (адреса пакетов, количество);
• CPU уведомляет GPU о новых полученных пакетах;
• GPU обрабатывает пакеты.

 

Этот ориентированный на CPU подход имеет следующие недостатки:

• потребление ресурсов: для работы с высокой пропускной способностью сети (100 Гбит/с и более) приложению может потребоваться выделение всего физического ядра CPU для приема или отправки пакетов;
• отсутствие масштабируемости: для получения или отправки пакетов параллельно с разными очередями приложению может потребоваться несколько ядер ЦП, даже в системах, где общее количество ядер ЦП может быть ограничено небольшим числом (в зависимости от платформы);
• зависимость от платформы: одно и то же приложение на маломощном процессоре снижает производительность.

 

Следующим естественным шагом для приложений встроенной обработки пакетов GPU является удаление CPU из критического пути. Переходя к решению, ориентированному на GPU, GPU может напрямую взаимодействовать с сетевой картой для получения пакетов, поэтому обработка может начинаться, как только пакеты поступают в память GPU. То же самое применимо и к операции отправки.

Способность GPU управлять активностью сетевой карты из ядра CUDA называется связью GPUDirect Async Kernel-Initiated Network (GDAKIN). При использовании NVIDIA GPU и сетевой карты NVIDIA, можно открыть регистры сетевой карты для прямого доступа GPU. Таким образом, ядро CUDA может напрямую настраивать и обновлять эти регистры, чтобы организовать сетевую операцию отправки или получения без вмешательства CPU (рис. 20).

Рис. 20. Приложение, ориентированное на GPU, в котором GPU управляет сетевой картой и обработкой пакетов без использования CPU.

DPDK по определению является фреймворком ЦП. Чтобы включить связь GDAKIN, необходимо было бы перенести весь путь управления на GPU, что неприменимо. По этой причине эта функция включается путем создания новой библиотеки NVIDIA DOCA.

Библиотека NVIDIA DOCA GPUNetIO

NVIDIA DOCA SDK (https://developer.nvidia.com/networking/doca) — это новая платформа NVIDIA, состоящая из драйверов, библиотек, инструментов, документации и примеров приложений. Эти ресурсы необходимы для использования приложения с функциями сети, безопасности и вычислений, которые аппаратное обеспечение NVIDIA может предоставить на хост-системах и DPU.

NVIDIA DOCA GPUNetIO — это новая библиотека, разработанная на основе версии NVIDIA DOCA 1.5, которая представляет понятие устройства GPU в экосистеме DOCA (рис. 21).

Рис. 21. NVIDIA DOCA GPUNetIO — новая библиотека DOCA, требующая наличия драйверов и библиотек GPU и CUDA, установленных на одной платформе.

Чтобы облегчить создание приложения обработки пакетов в реальном времени, ориентированного на GPU DOCA, DOCA GPUNetIO объединяет GPUDirect RDMA для ускорения пути данных (data-path), интеллектуальное управление памятью GPU, методы передачи сообщений с малой задержкой между CPU и GPU (через функции GDRCopy, https://github.com/NVIDIA/gdrcopy) и GDAKIN коммуникации.

Это позволяет ядру CUDA напрямую управлять сетевой картой NVIDIA ConnectX. Чтобы максимизировать производительность, библиотеку DOCA GPUNetIO следует использовать на платформах, которые считаются совместимыми с GPUDirect, где GPU и сетевая карта напрямую подключены через выделенный мост PCIe. В качестве примера можно привести конвергентную карту DPU

(https://www.nvidia.com/en–us/data–center/products/converged–accelerator), но та же топология может быть реализована и на хост-системах.

Цели DOCA GPUNetIO — это сетевые приложения обработки пакетов GPU, использующие протокол Ethernet для обмена пакетами в сети. С этими приложениями нет необходимости в фазе предварительной синхронизации между одноранговыми узлами через механизм OOB, как для приложений на основе RDMA. Также нет необходимости предполагать, что другие одноранговые узлы используют DOCA GPUNetIO для связи, и нет необходимости знать топологию. В будущих выпусках будет включена опция RDMA, чтобы охватить больше вариантов использования.

Функции DOCA GPUNetIO, включенные в текущем выпуске (на декабрь 2022 г.):

• коммуникации GDAKIN: ядро CUDA может вызывать функции устройства CUDA в библиотеке DOCA GPUNetIO, чтобы указать сетевой карте отправлять или получать пакеты;
• точное планирование отправки: можно запланировать передачу пакетов в будущем в соответствии с некоторой отметкой времени, предоставленной пользователем;
• GPUDirect RDMA: получение или отправка пакетов в непрерывной фиксированного размера памяти GPU без промежуточных копий памяти процессора;
• семафоры: обеспечивают стандартизированный протокол передачи сообщений с малой задержкой между CPU и GPU или между различными ядрами CUDA GPU;
• прямой доступ ЦП к памяти GPU: ЦП может изменять буферы памяти GPU без использования API памяти CUDA.

 

На рис. 22 показаны типичные шаги приложения DOCA GPUNetIO:

• фаза начальной настройки на ЦП:
  • использование DOCA для идентификации и инициализации устройства GPU и сетевого устройства;
  • использование DOCA GPUNetIO для создания очередей приема или отправки, управляемых из ядра CUDA;
  • использование DOCA Flow, чтобы определить, какой тип пакета должен попасть в каждую очередь приема (например, подмножество IP-адресов, протокол TCP или UDP и т.д.);
  • запуск одного или нескольких ядер CUDA (для выполнения обработки/фильтрации/анализа пакетов);
• время выполнения control и data path на GPU в ядре CUDA:
  • использование функции устройства DOCA GPUNetIO CUDA для отправки или получения пакетов;
  • использование функции устройства DOCA GPUNetIO CUDA для взаимодействия с семафорами для синхронизации работы с другими ядрами CUDA или с ЦП.

Рис. 22. Общий поток данных конвейера обработки пакетов графического процессора, состоящий из нескольких стандартных блоков.

Далее представлен обзор возможных макетов приложений конвейера обработки пакетов GPU, сочетающих строительные блоки DOCA GPUNetIO.

Пример 1. CPU получает, а GPU обрабатывает пакеты

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

Во время выполнения ЦП получает пакеты в память GPU. Он уведомляет одно или несколько ядер CUDA через семафоры DOCA GPUNetIO о поступлении нового набора пакетов в очередь, предоставляя такую информацию, как адрес памяти графического процессора и количество пакетов. На GPU ядро CUDA, опрашивая семафор, обнаруживает обновление и начинает обрабатывать пакеты (рис. 23).

Рис. 23. Конвейер обработки пакетов графическим процессором, где ЦП получает пакеты в память графического процессора и использует семафор NVIDIA DOCA GPUNetIO для уведомления ядра CUDA, обрабатывающего пакеты, о входящих пакетах.

Здесь семафор DOCA GPUNetIO имеет функциональность, аналогичную коммуникационному списку DPDK gpudev (https://developer.nvidia.com/blog/optimizing–inline–packet–processing–using–dpdk–and–gpudev–with–gpus/), обеспечивая механизм связи с малой задержкой между ЦП, получающим пакеты, и GPU, ожидающим получения этих пакетов перед их обработкой. Семафор также может использоваться графическим процессором для уведомления ЦП о завершении обработки пакетов или между двумя ядрами CUDA GPU для обмена информацией об обработанных пакетах.

Этот подход можно использовать в качестве основы для оценки эффективности. Поскольку он ориентирован на ЦП, он сильно зависит от модели ЦП, мощности и количества ядер.

Пример 2. GPU получает и GPU обрабатывает пакеты

Конвейер, ориентированный на ЦП, описанный в предыдущем разделе, можно улучшить с помощью ориентированного на ГП подхода к управлению очередями приема с помощью ядра CUDA с использованием связи GDAKIN. В следующих разделах приведены два примера: ядро с несколькими CUDA и ядро с одним CUDA.

Мульти-CUDA-ядро

При таком подходе задействовано как минимум два ядра CUDA: одно предназначено для приема пакетов, а второе — для обработки пакетов. Ядро CUDA получателя может предоставлять информацию о пакете второму ядру CUDA через семафор (рис. 24).

Рис. 24. Конвейер обработки пакетов графическим процессором, где ЦП получает пакеты в память графического процессора и использует семафор DOCA GPUNetIO для уведомления ядра CUDA, обрабатывающего пакеты, о входящих пакетах.

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

Ядро с одним CUDA

Предыдущая реализация может быть упрощена за счет наличия одного ядра CUDA, отвечающего за прием и обработку пакетов, при этом по-прежнему выделяется один блок CUDA для каждой очереди (рис. 25).

Рис. 25. Конвейер обработки пакетов графического процессора с одним ядром CUDA графического процессора, принимающим пакеты в память графического процессора и выполняющим обработку пакетов.

Одним из недостатков этого подхода является задержка между двумя операциями приема на блок CUDA. Если обработка пакетов занимает много времени, приложение может не успевать за получением новых пакетов в высокоскоростных сетях.

Пример 3. Прием GPU, обработка GPU и отправка GPU

До этого момента основное внимание уделялось части конвейера «получение и обработка». Однако DOCA GPUNetIO также позволяет производить некоторые данные на GPU, создавать пакеты и отправлять их из ядра CUDA без вмешательства ЦП. На рис. 26 показан пример полного конвейера приема, обработки и отправки.

Рис. 26. Конвейер обработки пакетов графического процессора с ядром CUDA графического процессора, принимающим пакеты в память графического процессора, выполняющим обработку пакетов и, наконец, созданием новых пакетов.

Пример 4. Приложение NVIDIA DOCA GPUNetIO

Как и любая другая библиотека NVIDIA DOCA, DOCA GPUNetIO имеет специальное приложение для справки по использованию API и для тестирования конфигурации и производительности системы. Приложение реализует конвейеры, описанные ранее, обеспечивая различные типы обработки пакетов, такие как контрольная сумма IP, фильтрация пакетов HTTP и пересылка трафика.

В следующем разделе представлен обзор различных режимов работы приложения. Сообщается о некоторых показателях производительности, которые следует рассматривать как предварительные результаты, которые могут измениться и улучшиться в будущих выпусках. Используются две эталонные системы, одна для приема пакетов, а вторая для отправки пакетов, соединенных встречно-параллельно (рис. 27).

Рис. 27. Системы получателя (Dell R750) и отправителя (Gigabyte), подключенные встречно-параллельно к эталонному приложению NVIDIA DOCA GPUNetIO.

Приемник, работающий с приложением DOCA GPUNetIO, представляет собой Dell PowerEdge R750 с конвергентной картой NVIDIA BlueField-2X DPU. Конфигурация представляет собой режим встроенного ЦП, поэтому приложение работает на ЦП хост системы с использованием сетевой карты NVIDIA ConnectX-6 Dx и графического процессора A100X от DPU. Конфигурация программного обеспечения: Ubuntu 20.04, MOFED 5.8 и CUDA 11.8.

Отправителем является Gigabyte Intel Xeon Gold 6240R с подключением PCIe Gen 3 к NVIDIA ConnectX-6 Dx. Эта машина не требует никакого графического процессора, так как на ней работает генератор пакетов T-Rex DPDK (https://trex–tgn.cisco.com/) v2.99. Конфигурация программного обеспечения — Ubuntu 20.04 с MOFED 5.8.

Приложение было выполнено также на ядрах DPU Arm, что привело к тому же результату производительности и доказало, что решение, ориентированное на GPU, не зависит от платформы по отношению к CPU.

Минимальные требования DOCA GPUNetIO — это системы с GPU и NIC с прямым подключением PCIe. DPU не является строгим требованием.

Пример 5. Контрольная сумма IP, только получение GPU

Приложение создает одну или несколько очередей приема, используя связь GDAKIN для приема пакетов. Вы можете использовать либо режим ядра с одним CUDA, либо режим ядра с не сколькими CUDA (рис. 28).

Рис. 28. Первый конвейерный режим в приложении NVIDIA DOCA GPUNetIO: GPU получает, вычисляет контрольную сумму IP и отправляет отчеты в CPU.

Каждый пакет обрабатывается простой проверкой контрольной суммы IP, и только пакеты, прошедшие этот тест, считаются хорошими. Через семафор количество хороших пакетов сообщается центральному процессору, который может распечатать отчет на консоли.

Нулевая потеря пакетов с одной очередью была достигнута путем отправки с помощью генератора пакетов T-Rex 3 Б пакетов размером 1 КБ со скоростью ~100 Гбит/с (~11,97 млн пакетов в секунду) и сообщения на стороне приложения DOCA GPUNetIO того же количества пакетов с правильная контрольная сумма IP. Та же конфигурация была протестирована на конвергентной карте BlueField-2 с теми же результатами, что доказывает, что связь GDAKIN является решением, не зависящим от платформы.

При размере пакета 512 байт генератор пакетов T-Rex не мог отправить более 86 Гбит/с (~20,9 млн пакетов в секунду). Даже с почти удвоенным количеством пакетов в секунду DOCA GPUNetIO не сообщил об отбрасывании пакетов.

Пример 6. HTTP-фильтрация, GPU только получает

В более сложном сценарии ядро CUDA, обрабатывающее пакеты, фильтрует только HTTP-пакеты с определенными характеристиками. Он копирует информацию о хороших пакетах во второй список HTTP-пакетов памяти графического процессора.

Как только следующий элемент в этом списке HTTP-пакетов заполнен пакетами, через выделенный семафор фильтрующее ядро CUDA разблокирует второе ядро CUDA, чтобы выполнить некоторые выводы по накопленным HTTP-пакетам. Семафор также можно использовать для передачи статистики потоку ЦП (рис. 29).

Рис. 29. Режим второго конвейера в приложении NVIDIA DOCA GPUNetIO. Графический процессор получает, фильтрует только HTTP-пакеты и через выделенный семафор разблокирует ядро   CUDA для выполнения некоторого анализа этих пакетов.

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

Пример 7. Traffic forward (трафик вперед)

В этом примере показано, как включить переадресацию трафика с помощью DOCA GPUNetIO с коммуникациями GDAKIN. В каждом полученном пакете MAC и IP-адреса источника и получателя меняются местами перед отправкой обратно пакетов по сети (рис. 30).

Рис. 30. Третий режим конвейера в приложении NVIDIA DOCA GPUNetIO. GPU получает, меняет MAC- и IP-адреса для каждого пакета и отправляет обратно измененные пакеты.

Доступ к NVIDIA DOCA GPUNetIO

DOCA GPUNetIO был выпущен публично вместе с выпуском DOCA 2.0.2 от апреля 2023 года для платформ x86 под управлением Ubuntu 20.04 и 22.04 с CUDA 12.1. Следующий выпуск DOCA будет поддерживать платформу ARM для запуска приложений GPUNetIO на ядрах конвергентных карт DPU и других операционных системах. Дополнительные сведения см. в GPUNetIO Programming Guide (https://docs.nvidia.com/doca/sdk/gpunetio–programming–guide).

Приложение, выпущенное с этой новой версией DOCA GPUNetIO, отличается от описанного в этом посте тем, что оно по-разному включает управление трафиком UDP, ICMP и TCP. Дополнительные сведения см. в GPU Packet Processing (https://docs.nvidia.com/doca/sdk/gpu–packet–processing).

Конвергентные ускорители NVIDIA

В портфеле NVIDIA представлен еще один класс интересных устройств – конвергентные ускорители (https://www.nvidia.com/enus/datacenter/products/converged–accelerator/).

В одной уникальной эффективной архитектуре конвергентные ускорители NVIDIA сочетают в себе мощную производительность графических процессоров NVIDIA с улучшенной сетью и безопасностью интеллектуальных сетевых карт NVIDIA (SmartNIC) и блоков обработки данных (DPU), обеспечивая максимальную производительность и повышенную безопасность для рабочих нагрузок с интенсивным вводом-выводом, ускоренных графическим процессором, от центра обработки данных до периферии.

Интегрируя GPU, DPU и коммутатор PCIe в одном устройстве, конвергентные ускорители NVIDIA предлагают сбалансированную архитектуру. В системах, где требуется несколько GPU и DPU, карта конвергентного ускорителя позволяет избежать конфликтов в системе PCIe сервера, поэтому производительность увеличивается линейно с дополнительными устройствами. Кроме того, конвергентная карта обеспечивает гораздо более предсказуемую производительность. Наличие этих компонентов на одной физической плате также повышает эффективность использования пространства и энергии. Конвергентные карты значительно упрощают развертывание и текущее обслуживание, особенно при установке на больших серверах.

В линейке конвергентных ускорителей 3 модели: NVIDIA A30X, NVIDIA A100X и NVIDIA AX800 (табл. 3). Среди их основных применений: 5G vRAN, AIbased cybersecurity, AI on 5G.

Табл. 3. Технические характеристики моделей серии конвергентных ускорителей NVIDIA.

NVIDIA A30X сочетает в себе графический процессор NVIDIA A30 с тензорными ядрами и DPU BlueField-2. С помощью MIG GPU можно разделить на четыре экземпляра GPU, каждый из которых запускает отдельную службу. Конструкция этой карты обеспечивает хороший баланс производительности вычислений и ввода-вывода для таких сценариев использования, как 5G vRAN и кибербезопасность на основе ИИ. Несколько служб могут работать на графическом процессоре с малой задержкой и предсказуемой производительностью, обеспечиваемой встроенным коммутатором PCIe.

NVIDIA A100X объединяет мощность графического процессора NVIDIA A100 с тензорными ядрами и DPU BlueField-2. С помощью MIG каждый A100 можно разделить на семь экземпляров графического процессора, что позволяет одновременно запускать еще больше сервисов.

A100X идеально подходит для случаев, когда требования к вычислениям более интенсивны. Примеры включают 5G с широкими возможностями множественного ввода и множественного вывода (MIMO), развертывание AIon5G и специализированные рабочие нагрузки, такие как обработка сигналов и обучение на нескольких узлах.

NVIDIA AX800 сочетает в себе технологию графического процессора архитектуры NVIDIA Ampere с DPU BlueField-3 (рис. 31). Он имеет пропускную способность памяти графического процессора почти 1 ТБ/с и может быть разделен на целых семь экземпляров графического процессора. Его 16 ядер Armv-8.2+ A78 Hercules поддерживают 256 потоков, что делает AX800 способным обеспечивать высокую производительность при самых требовательных рабочих нагрузках с интенсивным вводом-выводом, таких как 5G vRAN.

Рис. 31. Конвергентный ускоритель NVIDIA AX800.

Ускорение ИИ [17]

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

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

Конвергентный ускоритель NVIDIA — это первый в мире DPU с улучшенным ИИ. Он сочетает в себе вычислительную мощность GPU с преимуществами сетевого ускорения и безопасности DPU, создавая единую платформу для управления центром обработки данных с улучшенным ИИ. Конвергентные ускорители могут применять созданные ИИ правила к каждому пакету в сети центра обработки данных, создавая новые возможности для обеспечения безопасности и управления в режиме реального времени (рис. 32).

Рис. 32. В стандартном режиме DPU и GPU BlueField-2 подключаются с помощью выделенного коммутатора PCIe Gen4 для обеспечения полной пропускной способности за пределами хост-системы PCIe.

A100X сочетает в себе GPU A100 с тензорными ядрами и блок обработки данных NVIDIA BlueField-2 в одном модуле. A30X сочетает в себе графический процессор A30 Tensor Core с тем же DPU BlueField-2. Конвергентные карты обладают уникальной способностью расширять возможности BlueField-2 по разгрузке, изоляции и ускорению сети, включая вывод и обучение ИИ.

Оба ускорителя имеют встроенный переключатель PCIe между DPU и GPU. Встроенный коммутатор устраняет конкуренцию за ресурсы хоста, обеспечивая производительность GPUDirect RDMA на линейной скорости. Встроенный коммутатор также повышает безопасность, изолируя перемещение данных между графическим процессором и сетевой картой.

DPU с улучшенным ИИ

Конвергентные ускорители поддерживают два режима работы:

• cтандарт — DPU BlueField-2 и GPU работают отдельно;
• BlueField-X — PCI-коммутатор о переконфигурирован таким образом, что GPU предназначен для DPU и больше не виден хост-системе.

 

В режиме BlueField-X GPU предназначен исключительно для операционной системы, работающей на DPU. Режим BlueField-X создает новый класс ускорителей, невиданный ранее в отрасли: DPU с ускорением на GPU (рис. 33).

Рис. 33. В режиме BlueFieldX хост x86 видит только DPU BlueField-2, что позволяет DPU выполнять рабочие нагрузки ИИ для сетевых данных.

В режиме BlueField-X графический процессор может запускать модели ИИ на основе данных, проходящих через DPU, как «шишку в проводе» (“bump in the wire”). Нет снижения производительности и безопасности. Модель ИИ полностью ускоряется без потребления ресурсов хоста.

BlueField-X открывает новые варианты использования для кибербезопасности, управления центром обработки данных и ускорения ввода-вывода. Например, фреймворк Morpheus Cybersecurity (https://nvidianews.nvidia.com/news/nvidia–launches–morpheus–to–bring–ai–driven–automation–to–cybersecurity–industry) использует машинное обучение для устранения угроз безопасности, которые ранее было невозможно идентифицировать. Morpheus использует DPU для сбора телеметрии с каждого сервера в центре обработки данных и отправки ее на серверы с GPU для анализа.

С BlueField-X модели ИИ могут работать локально на конвергентном ускорителе на каждом сервере. Это позволяет Morpheus анализировать больше данных быстрее, одновременно устраняя дорогостоящее перемещение данных и уменьшая поверхность атаки для злоумышленников. Обнаружение вредоносных программ, предотвращение кражи данных и динамическое создание правил брандмауэра — варианты использования Morpheus, поддерживаемые BlueField-X.

Пример Morpheus лишь поверхностно показывает возможности BlueField-X. Для исследования сетей с поддержкой ИИ предоставляется комплект разработчика NVIDIA Converged Accelerator Developer Kit (https://developer.nvidia.com/converged–accelerator–devkit).

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

• прозрачная предварительная обработка видео. Предварительная обработка видео в режиме реального времени (дешифрование, чересстрочная развертка, преобразование формата и т.д.) для повышения пропускной способности IVA и плотности размещения камер;
• решение RU для малых сот — обработка сигналов RAN на конвергентном ускорителе для увеличения плотности абонентов и пропускной способности на обычном сервере gNodeB;
• вычислительное хранилище. Шифрование, индексирование и хеширование хранилища с помощью технологии Bump-in-the-wire для разгрузки дорогостоящих циклов ЦП с хоста хранилища, подготавливающего данные для долгосрочного хранения;
• обнаружение читерства (Cheating). — Обнаружение злонамеренного игрового процесса/мошенничества в потоковом игровом сервисе.

 

Комплект разработчика NVIDIA Converged Accelerator содержит примеры приложений, сочетающих CUDA и NVIDIA DOCA, а также документацию, которая поможет установить и настроить новый конвергентный ускоритель. Самое главное, мы предоставляем доступ к A30X и поддержку использования в обмен на обратную связь.

Чтобы начать, просто зарегистрируйтесь на веб-странице комплекта разработчика NVIDIA Converged Accelerator Developer Kit (https://developer.nvidia.com/converged–accelerator–devkit). В случае одобрения мы свяжемся с вами, как только оборудование будет готово к отправке, и вы сможете приступить к созданию ускоренных приложений следующего поколения.

Другие применения NVIDIA BlueField DPU

Среди других применений:

• “ускорение Suricata IDS/IPS с помощью NVIDIA BlueField DPU” (Accelerating the Suricata IDS/IPS with NVIDIA BlueField DPUs. May 04, 2023. By Moran Gonen, https://developer.nvidia.com/blog/accelerating-the-suricata-ids-ips-with-nvidia-bluefield-dpus/);
• “остановите современные атаки на системы безопасности в режиме реального времени с помощью ARIA Cybersecurity и NVIDIA” (Stop Modern Security Attacks in Real Time with ARIA Cybersecurity and NVIDIA. Jun 07, 2022. By Scott Ciccone, https://developer.nvidia.com/blog/stop-modern-security-attacks-in-real-time-with-aria-cybersecurity-and-nvidia/).

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

[1]  Why You Have Been Thinking About the Future of the Data Center All Wrong, Navin Shenoy | Executive VP & GM, Data Platforms Group | Intel, June 14 2021, The Six Five Summit – https://thesixfivesummit.com/session/why-you-have-been-thinking-about-the-future-of-the-data-center-all-wrong/.

[2]   Intel Unveils Infrastructure Processing Unit – https://www.intel.com/content/www/us/en/newsroom/news/infrastructure-processing-unit-data-center.html#gs.b7kexl.

[3]   Accelerometer: Understanding Acceleration Opportunities for Data Center Overheads at Hyperscale – https://research.facebook.com/publications/accelerometer-understanding-acceleration-opportunities-for-data-center-over-heads-at-hyperscale/.

[4]  From Profiling a warehouse-scale computer, Svilen Kanev, Juan Pablo Darago, Kim M Hazelwood, Parthasarathy/Ranganathan, Tipp J Moseley, Guyeon/ Wei, David Michael Brooks, ISCA’15 – https://research.google/pubs/pub44271.pdf.

[5]  Fourth Generation Architecture for SmartNICs. Jim Finnegan & Niel Viljoen. SmartNICs Summit, April 26-28, 2022 (PDF) – http://SmartNICsSummit.com.

[6]  IPU-Based Cloud Infrastructure: The Fulcrum for Digital Business, whate paper – https://www.intel.com/content/www/us/en/products/docs/programmable/ipu-based-cloud-infrastructure-white-paper.html.

[7]  Intel Rolls Out Multi-Generation Infrastructure Processing Unit (IPU) Roadmap at Vision 2022. Sabrina_Gomez? 05-16-2022 – https://community.intel.com/t5/Blogs/ProductsandSolutions/FPGA/Intel-Rolls-Out-Mult-iGeneration-Infrastructure-Processing-Unit/post/1384630.

[8]  Intel Unveils Infrastructure Processing Unit Roadmap; 2nd Generation to Ship in 2022 (Intel-IPU-Roadmap-Fact-Sheet.pdf).

[9]  Developing Software for Data Center Infrastructure Applications. Deb Chatterjee, Senior Director of Engineering, Intel (20220427_A 103_Chatterjee.PDF) – http://SmartNICsSummit.com.

[10]  Simplifying infrastructure offload and management on SmartNICs. Kyle Mestery, Senior PE, Intel; Deb Chatterjee, Senior Director, Intel (20220427_A103_Mestery_Chatterjee.PDF) – http://SmartNICsSummit.com.

[11]  Smart NIC Market Update, Baron Fung, Research Director, Dell’Oro Group (20220427_Plenary_Fung.PDF) – http://SmartNICsSummit.com.

[12]  Inline GPU Packet Processing with NVIDIA DOCA GPUNetIO. May 8, 2023. By Elena Agostini – https://developer.nvidia.com/blog/inline-gpu-packet-processing-with-nvidia-doca-gpunetio/.

[13]  Boosting Inline Packet Processing Using DPDK and GPUdev with GPUs. Apr 28, 2022. By Elena Agostini – https://developer.nvidia.com/blog/optimizing-inline-packet-processing-using-dpdk-and-gpudev-with-gpus/.

[14]  DATA PROCESSING UNIT (DPU). Technical overview. Alexander Petrovskiy, Staff System Engineer, NVIDIA Networking, August 2021 – https://s3.linkmeup.ru/linkmeup/podcasts/telecom/telecom-V102.pdf.

[15]  NVIDIA DATA CENTER PROCESSING UNIT (DPU) ARCHI TECTURE, Idan Burstein, DPU Principal Architect – https://hc33.hotchips.org/assets/program/conference/day1/HC2021.NVIDIA.IdanBurstein.v08.norecording.pdf.

[16]  Power the Next Wave of Applications with NVIDIA BlueField-3 DPUs. May 11, 2023. By Tal Roll and Itay Ozery – https://developer.nvidia.com/blog/power-the-next-wave-of-applications-with-nvidia-bluefield-3-dpus/.

[17]  Accelerating Data Center AI with the NVIDIA Converged Accelerator Developer Kit. Nov 10, 2021. By Jacob Liberman and Pete Lumbis – https://developer.nvidia.com/blog/accelerating-data-center-ai-with-the-nvidia-converged-accelerator-developer-kit/.

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

Отслеживать