Meta✴ представила MetaRoCE — новый транспортный RDMA-протокол на базе обычного Ethernet, созданный для крупных ИИ-кластеров. Компания разместила спецификации MetaRoCE, эталонную программную реализацию и набор тестов на соответствие требованиям (Compliance Test Suite, CTS) в рамках OCP, предоставив возможность его внедрения всем желающим. В Meta✴ настаивают на том, что Ethernet должен быть предпочтительной инфраструктурой для ИИ, продемонстрировав, что её реализация RoCE может обеспечивать распределённое обучение ИИ в масштабе, объединяя миллионы GPU.

Компания отметила, что в ходе инференса низкая задержка коммуникации между распределёнными сегментами модели напрямую влияет на время отклика для сотен миллионов пользователей. Даже небольшие сетевые помехи ограничивают вычислительную мощность. Протокол RoCE (RDMA over Converged Ethernet) предполагает, что сеть будет доставлять каждый пакет в определённом порядке, используя PFC и препятствуя распылению пакетов, обеспечивая производительность в многоплоскостных и крупномасштабных сетях. При использовании MetaRoCE в строгом выполнении очерёдности передачи данных нет необходимости. Главная задача — обеспечение высокой пропускной способности, низкой задержки в конце очереди распределения и простоты эксплуатации по мере роста сети при увеличении количества ускорителей и расстояний между ними.

Источник изображений: engineering.fb.com

Как указано в блоге Meta✴, суть MetaRoCE проста: сетевая фабрика видит пакеты, а сетевая карта (NIC) — намерения. Традиционные архитектуры ориентированы на «ум» фабрики, полагаясь на коммутаторы для обеспечения отсутствия потерь и поддержания порядка. Перенося интеллектуальные функции на конечную точку, MetaRoCE декомпозирует сеть на множество детализированных (мелкозернистых) логических путей, каждый из которых имеет свою собственную телеметрию в реальном времени — время приёма-передачи данных для каждого пути (Per-path RTT), состояние ECN и загрузку. Такая прозрачность открывает возможности, которые трудно достичь с помощью традиционного RDMA.

MetaRoCE распределяет пакеты по множеству путей, поэтому они поступают не в том порядке, в каком были отправлены. Транспортный уровень рассматривает неупорядоченное поступление как обычный случай. Каждый пакет имеет свой адрес назначения, а данные записываются непосредственно в конечную область памяти по мере их поступления, без буфера переупорядочивания и блокировок. При этом MetaRoCE всегда рассматривает Ethernet-фабрику как систему с потерями и не требует от неё иного поведения. Прикладной уровень практически не затрагивается — существующие RDMA-«глаголы» и программные стеки работают без изменений, а дополнительные функции поддерживаются с помощью расширений стандартных API.

MetaRoCE предоставляет каждому соединению несколько путей и распределяет по ним пакет за пакетом. Каждый путь имеет свой уникальный исходный UDP-порт в качестве энтропии ECMP, который сетевая карта может изменить в любой момент, чтобы перенаправить трафик с неподходящего маршрута. Выбор пути пакета полностью зависит от NIC, так что и эффективность работы всей фабрики зависит от NIC. Оценка каждого пути позволяет явно отличить перегрузку и от сбоя, и сделать перебалансировку, избавившись от плохо работающего пути без обрыва соединение целиком и с возможностью переотправки ровно того пакета, который потерялся из-за сбоя или перегрузки.

MetaRoCE сочетает в себе традиционный ECN-контроль перегрузки с AIMD у отправителя с обратной связью со стороны получателя, который при каждом ACK уведомляет отправителя о выделенной ему доле из общей доступной получателю полосы. MetaRoCE запрашивает у фабрики олько две функции, которые уже есть в каждом коммутаторе: ECN и ECMP. Протокол Meta✴ не требует обрезки пакетов, внутрисетевой телеметрии, управления потоком на основе кредитов или распыления пакетов на стороне коммутатора, но и наличие этих функций не мешает работе протокола. MetaRoCE совместим практически с любыми топологиями, в том числе с сегментами в облачных системах, конфигурацию которых нельзя контролировать. В протоколе нет проприетарных компонентов, поэтому фабрика может свободно оптимизироваться с точки зрения стоимости и кабельной разводки.

Очередь отправки и очередь приёма (Queue Pair, QP) отвечают как за упорядоченный поток сообщений, так и за пропускную способность. Традиционный RDMA получает больше того или другого путём открытия большего количества QP (по несколько десятков на каждую пару узлов), не знающих ничего ни о друг друге в плане перегрузки, ни об их состоянии в NIC. MetaRoCE использует одно соединение для множества независимых упорядоченных потоков (в т.ч. по одному на каждую коллективную операцию), использующее множественные пути под управлением одного контроллера перегрузки.

Чтобы ускорить проверку аппаратного обеспечения, Meta✴ совместно с AMD реализовала MetaRoCE на DPU Pensando. На 64-узловом кластере GPU AMD, работающем под управлением RCCL, компании напрямую сравнили MetaRoCE с RoCEv2 при выполнении коллективных операций All-Reduce и All-to-All.

Результаты, как утверждает Meta✴, соответствуют поставленным целям:

• MetaRoCE стабильно обеспечивал более высокую пропускную способность и меньшее время завершения потока по сравнению с RoCEv2.
• При потере пакетов, когда пропускная способность RoCEv2 снижается, MetaRoCE сохраняет около 86 % пропускной способности при потере 1 % пакетов и продолжает обеспечивать полезную пропускную способность даже при экстремальной потере 10 % пакетов, плавно снижаясь, а не коллапсируя.
• Multiplane-топология с 4 и 8 независимым физическими подключениями к коммутаторам для каждого NIC с поддержкой до 4000 одновременных подключений подтвердила, что пропускная способность линейно зависит от количества плоскостей.
• При имитации сбоев на отдельных физических подключениях в сценарии выше протокол демонстрирует плавное автономное восстановление — трафик перераспределяется без участия приложения или вмешательства оператора.

Эти результаты подтверждают правильность выбора, сделанного при разработке MetaRoCE, отметила Meta✴. Благодаря тому, что протокол с самого начала разрабатывался с учётом возможных потерь пакетов, а интеллектуальные функции вынесены на периферию, он обеспечивает более высокую производительность в идеальных условиях и плавно снижает нагрузку при сбоях. Компания подчеркнула, что протокол MetaRoCE является открытым, его спецификации добавлены в OCP, и любой поставщик может с их помощью создать и реализовать совместимое оборудование. Впрочем, во многом похожий протокол MRC (Multipath Reliable Connection) также передан в OCP, да и Ultra Ethernet тоже решает схожие задачи.

Государственная канцелярия интернет-информации КНР (Cyberspace Administration of China, CAC) представила план расширенного внедрения сетевого протокола IPv6 до 2030 года. Более того, продвигается т.н. IPv6+, упрощающий контроль деятельности пользователей в Сети, сообщает The Register.

Пекин рассчитывает, что к 2027 году к IPv6-подключениями к Сети должны быть обеспечены более 900 млн пользователей, на этот протокол должно прийтись 38 % сетевого трафика в стране. Кроме того, к тому же сроку IPv6 должны поддерживать все подключенные к Сети устройства. К 2030 году количество активных пользователей должно превысить 950 млн, а на долю IPv6 приходиться 42 % сетевого трафика. К этому же времени для новых сетей в приоритете будет выделение IPv6-адресов, что ускорит переход к единому стеку IPv6 в стране и поможет формированию системы сетевых сервисов и приложений, в которой этот протокол будет доминировать.

Примечательно, что власти призывают развивать работы над IPv6+. Речь идёт о комплексе улучшений IPv6, позволяющем отправителям пакетов описывать передаваемую информацию с помощью метаданных и даже предлагать маршрут, по которому она должна передаваться. Как утверждали эксперты, IPv6+ якобы привлекателен для режимов, «стремящихся контролировать своих граждан», поскольку телеком-операторы смогут читать метаданные, делать выводы на их основе и при необходимости цензурировать трафик.

Источник изображения: John Moeses Bauan/unsplash.com

Правда, телеком-операторам выгодно применение подобных технологий даже без политики. Так, они смогут идентифицировать трафик, за который могли бы брать дополнительную плату — обязанность инвестиций в инфраструктуру «последней мили» для доставки контента стриминговых сервисов обычно ложится именно на них. Любопытно, что китайские производители уже внедрили поддержку IPv6+ в телеком-оборудование, поставлявшееся на экспорт в несколько стран.

Ранее Китай уже пытался внедрить протокол New IP для замены TCP/IP, также включавший функции, которые можно использовать для слежки. Впрочем, попытка добиться его одобрения Международным союзом электросвязи (International Telecommunications Union) закончилась не вполне успешно. Тем не менее, Пекин продолжает активно продвигать свою версию интернет-протоколов в стране и за рубежом, а также участвовать в разработке глобальных стандартов.

Чуть более года назад сообщалось, что Индия и Китай стали лидерами по внедрению IPv6 потому, что когда-то им досталось совсем мало IPv4-адресов. Впрочем, внедрение протокола ведётся весьма активно и в других странах. Ещё пару лет назад Вьетнам поставил цель перевести все сети страны на IPv6 к 2030 году.

OpenAI в партнёрстве с AMD, Broadcom, Intel, Microsoft и NVIDIA анонсировала технологию Multipath Reliable Connection (MRC) — сетевой протокол, призванный повысить производительность и отказоустойчивость масштабных GPU-кластеров, ориентированных на ресурсоёмкие задачи ИИ. MRC уже используется во всех крупных кластерах OpenAI c NVIDIA GB200, в том числе в первом ЦОД Stargate, а также в ЦОД Microsoft по проекту Fairwater.

Отмечается, что при обучении больших языковых моделей (LLM) каждый этап предполагает огромное количество пересылок данных между узлами в кластере. При этом единственная задержка при подобных транзакциях может повлиять на весь процесс, потенциально провоцируя простои тысяч ИИ-ускорителей. Такие прерывания приводят к снижению эффективности использования имеющихся вычислительных мощностей и к увеличению временных затрат. Наиболее распространёнными причинами задержек и нестабильности при передаче данных являются перегрузка сети, сбои в работе каналов связи и коммутационных устройств. Причём по мере увеличения масштабов кластеров проблемы усугубляются: неполадки возникают всё чаще, а их устранение становится более затруднительным.

Протокол MRC, как утверждается, устраняет ряд ключевых недостатков сетей Ethernet применительно к инфраструктурам ИИ. В частности, вводятся такие механизмы, как адаптивная многопутевая передача данных, многоканальные перекрёстные Ethernet-фабрики, «распыление» пакетов, быстрое восстановление после сбоев и пр. MRC коренным образом меняет способ передачи трафика по сети.

Источник изображений: OpenAI

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

Ещё одной важной особенностью MRC является многоуровневая архитектура, которая изменяет саму физическую концепцию построения интерконнекта. Так, например, сетевой интерфейс 800GbE может быть разделён на 100GbE-каналы, связанные с восемью различными коммутаторами отдельными каналами. В результате можно построить восемь отдельных параллельных сетей. Такой подход оказывает значительное влияние на структуру кластера. В частности, коммутатор c 64 портами 800GbE можно использовать в конфигурации на 512 × 100GbE. И это позволяет построить сеть, объединяющую около 131 тыс. GPU, используя всего два уровня коммутации, против традиционных трёх- или четырёхуровневых топологий.

В протоколе MRC также используется новый способ обработки перегрузок и потери пакетов в сетях Ethernet. Обычно применяется технология PFC (Priority Flow Control) — управление потоками на основе приоритетов: этот механизм предполагает приостановку передачи данных для конкретных классов трафика, а не для всего порта целиком. В случае MRC задействован иной подход, основанный на выборочных подтверждениях, явных запросах на повторную передачу и обрезке пакетов. Так, когда коммутатор сталкивается с перегрузкой, он может отрезать полезную нагрузку и переслать в пункт назначения только заголовок пакета, что позволяет получателю быстро идентифицировать отсутствующие данные и запросить повторную передачу. Утверждается, что это даёт возможность восстанавливаться после сбоев и перегрузок в течение микросекунд, что на порядки быстрее по сравнению с обычными архитектурами.

С внедрением MRC сокращается необходимость в динамической маршрутизации. Если пакеты теряются на каком-либо пути, система на основе MRC просто перестаёт использовать этот путь. Вместо динамической маршрутизации применяется так называемая сегментная маршрутизация IPv6 (IPv6 Segment Routing, SRv6), которая позволяет отправителю напрямую задать путь прохождения пакета, прописав последовательность идентификаторов коммутаторов. При пересылке данных коммутатор проверяет наличие собственного идентификатора. Если он присутствует, он удаляет из пакета свой идентификатор и ищет следующий за ним идентификатор в статической таблице маршрутизации, которая указывает, куда необходимо отправить пакет данных.

В отличие от динамической маршрутизации, такая статическая таблица формируется при первой настройке коммутатора и в дальнейшем не изменяется. MRC использует SRv6 для передачи пакетов по всем физическим каналам и уровням, а также по множеству путей в каждом из них. Если какой-либо путь становится недоступен, система игнорирует его. При этом коммутаторам не нужно пересчитывать маршруты или выполнять другие действия, кроме как строго следовать статическим маршрутам, заложенным в таблице.

Протокол MRC выпущен в рамках проекта OCP. В целом, как отмечается, MRC обеспечивает три ключевых преимущества перед стандартными Ethernet-сетями для кластеров ИИ. Во-первых, MRC позволяет создавать многоуровневые высокоскоростные инфраструктуры для платформ с более чем 131 072 конечных точек, используя всего два уровня коммутаторов. Во-вторых, адаптивное распределение пакетов обеспечивает эффективную балансировку нагрузки, благодаря чему практически отсутствуют перегрузки в ядре сети. В-третьих, применение SRv6 обеспечивает быстрый обход сбоев и отправку пакетов только по работающим путям.

Компания Broadcom заявила, что её сетевые адаптеры Thor Ultra, а также коммутаторы Tomahawk 5 и Tomahawk 6 изначально поддерживают функциональность MRC. В частности, Thor Ultra позволяет использовать 2, 4 или 8 параллельных сетей на одном порту и распределять трафик одновременно по 128 каналам. При этом Tomahawk 5 обеспечивает коммутационную способность до 51,2 Тбит/с, а Tomahawk 6 — до 102,4 Тбит/с. В свою очередь, NVIDIA отмечает, что протокол MRC, будучи расширением RoCE, совместим с решениями Spectrum-X Ethernet. OpenAI уже использовала MRC при обучении нескольких ИИ-моделей, задействовав коммутаторы Broadcom и NVIDIA. Конкуренцию MRC составляет схожий во многих аспектах Ultra Ethernet.

Стеку TCP/IP, благодаря которому существует всемирная сеть, уже не один десяток лет. DARPA начало исследования по этой теме ещё в конце 60-х, и не все согласны с тем, что данная технология продолжает отвечать требованиям времени: Huawei предложила Международному союзу электросвязи (ITU) план по отказу от TCP/IP и переходу на более современное и безопасное, по её мнению, решение New IP.

Определённый резон в этом есть: современные сети чрезвычайно сложны, они базируются на весьма разнообразном оборудовании, и что такое «кибервойна» сегодня, пожалуй, знают все, кто хоть сколько-то интересуется тематикой информационных технологий. Достаточно хотя бы сделать на нашем сайте поиск по слову «уязвимость» — и становится понятным, что понятия «интернет» и «безопасность» сегодня сочетаются не очень хорошо.

Демонстрация TCP/IP, объединяющая сети ARPANET, PRNET и SATNET. 1977 год

Корпорация Huawei выступила в ITU с предложением отказаться от стека TCP/IP и перейти на использование более гибких и безопасных технологий. Понять позицию китайской компании можно: она находится в состоянии «войны» с США и желание продвинуть собственные технологии для нее совершенно естественно. Позиции, предлагаемые Huawei, выглядят довольно привлекательно:

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

Технических деталей, к сожалению, в публичном доступе пока нет. Реакция на предложение Huawei оказалась достаточно негативной: оно было охарактеризовано, как попытка внедрения централизации и «тоталитарных» методов. В частности, предложенный механизм отсечения частей сети можно использовать не только для защиты от DDoS-атак.

Сама Huawei обвинения в «тоталитаризме» отвергла, заявив, что не связывает технологию с политикой. Еврокомиссия опубликовала свой ответ: в нём говорится, что за время своего существования модель TCP/IP доказала свою жизнеспособность, продемонстрировав нужную степень отказоустойчивости и масштабируемости. Аналогичной точки зрения придерживается Cisco, считая TCP/IP достаточно гибкой технологией, чтобы отвечать вызовам времени.

О дивный, новый Интернет!

Нужда в усовершенствовании сетевых технологий существует, но это следует делать в рамках существующих стандартов. Евросоюз планирует защищать «видение единого, открытого, нейтрального, свободного и нефрагментированного интернета». («the vision of a single, open, neutral, free and unfragmented internet»).

Тем не менее, война технологий, скорее всего, в ближайшее время продолжится. Предсказать исход пока не представляется возможным, но Huawei явно не собирается сдаваться просто так и будет продвигать инициативу New IP далее.