RDMA через конвергентный Ethernet
RDMA через конвергентный Ethernet ( RoCE ) [1] — это сетевой протокол, который обеспечивает удаленный прямой доступ к памяти (RDMA) по сети Ethernet . Существует несколько версий RoCE. RoCE v1 представляет собой протокол канального уровня Ethernet и, следовательно, обеспечивает связь между любыми двумя хостами в одном широковещательном домене Ethernet . RoCE v2 — это протокол интернет-уровня , что означает, что пакеты RoCE v2 могут маршрутизироваться. Хотя протокол RoCE обладает преимуществами характеристик конвергентной сети Ethernet , его также можно использовать в традиционной или неконвергентной сети Ethernet. [2] [3] [4] [5]
Фон
[ редактировать ]Приложениям с интенсивным использованием сети, таким как сетевое хранилище или кластерные вычисления, требуется сетевая инфраструктура с высокой пропускной способностью и низкой задержкой. Преимущества RDMA перед другими интерфейсами программирования сетевых приложений, такими как сокеты Беркли, заключаются в более низкой задержке, меньшей нагрузке на процессор и более высокой пропускной способности. [6] Протокол RoCE обеспечивает меньшие задержки, чем его предшественник, протокол iWARP . [7] Существуют RoCE HCA (адаптеры хост-канала) с задержкой всего 1,3 микросекунды. [8] [9] в то время как самая низкая известная задержка iWARP HCA в 2011 году составляла 3 микросекунды. [10]
РоЦЭ v1
[ редактировать ]Протокол RoCE v1 — это протокол канального уровня Ethernet с типом Ethertype 0x8915. [2] Это означает, что применяются ограничения на длину кадра протокола Ethernet: 1500 байт для обычного кадра Ethernet и 9000 байт для большого кадра .
РоЦЕ v1.5
[ редактировать ]RoCE v1.5 — это необычный экспериментальный нестандартизированный протокол, основанный на протоколе IP. RoCE v1.5 использует поле протокола IP, чтобы отличать свой трафик от других протоколов IP, таких как TCP и UDP . Значение, используемое для номера протокола, не указано и остается на усмотрение развертывания.
РоЦЭ v2
[ редактировать ]Протокол RoCE v2 существует поверх протокола UDP/IPv4 или UDP/IPv6. [3] Номер порта назначения UDP 4791 зарезервирован для RoCE v2. [11] Поскольку пакеты RoCEv2 маршрутизируются, протокол RoCE v2 иногда называют маршрутизируемым RoCE. [12] или РРоЦЕ. [4] Хотя в целом порядок доставки пакетов UDP не гарантируется, спецификация RoCEv2 требует, чтобы пакеты с одним и тем же исходным портом UDP и одним и тем же адресом назначения не переупорядочивались. [4] Кроме того, RoCEv2 определяет механизм контроля перегрузки, который использует биты IP ECN для маркировки и CNP. [13] кадры для уведомления о подтверждении. [14] Программная поддержка RoCE v2 все еще находится на стадии разработки. [ когда? ] . Mellanox OFED 2.3 или новее имеет поддержку RoCE v2, а также ядро Linux v4.5. [15]
RoCE против InfiniBand
[ редактировать ]RoCE определяет, как выполнять RDMA через Ethernet , а спецификация архитектуры InfiniBand определяет, как выполнять RDMA через сеть InfiniBand. Ожидалось, что RoCE перенесет приложения InfiniBand, которые преимущественно основаны на кластерах, в общую конвергентную структуру Ethernet. [16] Другие ожидали, что InfiniBand продолжит предлагать более высокую пропускную способность и меньшую задержку, чем это возможно через Ethernet. [17]
Технические различия между протоколами RoCE и InfiniBand:
- Управление потоком на уровне канала: InfiniBand использует алгоритм на основе кредитов, чтобы гарантировать связь между HCA без потерь. RoCE работает поверх Ethernet. Реализациям может потребоваться сеть Ethernet без потерь для достижения характеристик производительности, аналогичных InfiniBand. Ethernet без потерь обычно настраивается с помощью управления потоком Ethernet или управления приоритетным потоком (PFC). Настройка сети Ethernet с мостом центра обработки данных (DCB) может быть более сложной, чем настройка сети InfiniBand. [18]
- Контроль перегрузки: Infiniband определяет контроль перегрузки на основе маркировки FECN/BECN, RoCEv2 определяет протокол управления перегрузкой, который использует ECN для маркировки, как это реализовано в стандартных коммутаторах, и кадры CNP для подтверждений.
- Коммутаторы InfiniBand обычно имеют меньшую задержку, чем коммутаторы Ethernet. Задержка между портами для одного конкретного типа коммутатора Ethernet составляет 230 нс. [19] против 100 нс [20] для коммутатора InfiniBand с таким же количеством портов.
RoCE против iWARP
[ редактировать ]В то время как протоколы RoCE определяют, как выполнять RDMA с использованием кадров Ethernet и UDP/IP, протокол iWARP определяет, как выполнять RDMA через транспорт, ориентированный на соединение, такой как протокол управления передачей (TCP). RoCE v1 ограничен одним широковещательным доменом Ethernet . Пакеты RoCE v2 и iWARP маршрутизируются. Требования к памяти для большого количества соединений, а также средства контроля потока и надежности TCP приводят к проблемам с масштабируемостью и производительностью при использовании iWARP в крупномасштабных центрах обработки данных и для крупномасштабных приложений (т. е. крупных предприятий, облачных вычислений, приложений Web 2.0). и т. д. [21] ). Кроме того, многоадресная рассылка определена в спецификации RoCE, тогда как текущая спецификация iWARP не определяет, как выполнять многоадресную рассылку RDMA. [22] [23] [24]
Надежность в iWARP обеспечивается самим протоколом, поскольку TCP надежен. RoCEv2, с другой стороны, использует UDP , который имеет гораздо меньшие накладные расходы и лучшую производительность, но не обеспечивает внутреннюю надежность, и поэтому надежность должна быть реализована вместе с RoCEv2. Одним из решений является использование конвергентных коммутаторов Ethernet, чтобы сделать локальную сеть надежной. Для этого требуется поддержка конвергентного Ethernet на всех коммутаторах в локальной сети и предотвращается перемещение пакетов RoCEv2 через глобальную сеть, такую как Интернет, которая не является надежной. Другое решение — повысить надежность протокола RoCE (т. е. надежный RoCE), что добавляет квитирование связи к RoCE для обеспечения надежности за счет производительности.
Вопрос о том, какой протокол лучше, зависит от производителя. Chelsio рекомендует и поддерживает исключительно iWARP. Mellanox, Xilinx и Broadcom рекомендуют и поддерживают исключительно RoCE/RoCEv2. Первоначально Intel поддерживала iWARP, но теперь поддерживает как iWARP, так и RoCEv2. [25] Другие поставщики, работающие в сетевой отрасли, обеспечивают поддержку обоих протоколов, например Marvell, Microsoft, Linux и Казань. [26] Cisco поддерживает оба RoCE [27] и собственный протокол VIC RDMA.
Оба протокола стандартизированы: iWARP является стандартом для RDMA через TCP, определенным IETF , а RoCE — стандартом для RDMA через Ethernet, определенным IBTA . [26]
Критика
[ редактировать ]Некоторые аспекты, которые могли быть определены в спецификации RoCE, опущены. Это:
- Как выполнить преобразование между основными GID RoCE v1 и MAC-адресами Ethernet . [28]
- Как преобразовать между вторичными GID RoCE v1 и MAC-адресами Ethernet. Неясно, можно ли реализовать вторичные GID в протоколе RoCE v1 без добавления протокола разрешения адресов, специфичного для RoCE.
- Как реализовать VLAN для протокола RoCE v1. Текущие реализации RoCE v1 хранят идентификатор VLAN в двенадцатом и тринадцатом байтах шестнадцатибайтового GID, хотя в спецификации RoCE v1 вообще не упоминаются VLAN. [29]
- Как выполнить преобразование между многоадресными GID RoCE v1 и MAC-адресами Ethernet. В реализациях 2010 года использовалось то же сопоставление адресов, которое было указано для сопоставления адресов многоадресной рассылки IPv6 с MAC-адресами Ethernet. [30] [31]
- Как ограничить многоадресный трафик RoCE v1 подмножеством портов коммутатора Ethernet. По состоянию на сентябрь 2013 года эквивалент протокола обнаружения прослушивателя многоадресной рассылки еще не определен для RoCE v1.
Кроме того, любой протокол, работающий через IP, не может предполагать, что базовая сеть имеет гарантированный порядок, равно как и не может предполагать, что перегрузка невозможна.
Известно, что использование PFC может привести к тупику всей сети. [32] [33] [34]
Продавцы
[ редактировать ]Некоторые поставщики оборудования с поддержкой RoCE включают:
- Mellanox (приобретена Nvidia в 2020 году, [35] бренд сохранен [36] )
- Emulex (приобретена Broadcom )
- Бродком
- QLogic (приобретена Cavium , переименована)
- Cavium (приобретена Marvell Technology Group , переименована)
- Хуавей
- АТТО Технология
- Делл Технологии
- Интел
- Блумбаза
- Xilinx (через мягкое IP-ядро FPGA )
- Гровф [37]
Ссылки
[ редактировать ]- ^ «Блог Роланда » Архив блога » Две заметки о IBoE» .
- ^ Jump up to: а б «Спецификация архитектуры InfiniBand™, выпуск 1.2.1, Приложение A16: RoCE» . Торговая ассоциация InfiniBand . 13 апреля 2010 года. Архивировано из оригинала 9 марта 2016 года . Проверено 29 апреля 2015 г.
- ^ Jump up to: а б «Спецификация архитектуры InfiniBand™, выпуск 1.2.1, Приложение A17: RoCEv2» . Торговая ассоциация InfiniBand . 2 сентября 2014 г. Архивировано из оригинала 17 сентября 2020 г. . Проверено 19 октября 2014 г.
- ^ Jump up to: а б с Офир Маор (декабрь 2015 г.). «Соображения RoCEv2» . Мелланокс .
- ^ Офир Маор (декабрь 2015 г.). «RoCE и решения для хранения данных» . Мелланокс .
- ^ Кэмерон, Дон; Ренье, Грег (2002). Архитектура виртуального интерфейса . Интел Пресс. ISBN 978-0-9712887-0-6 .
- ^ Фельдман, Майкл (22 апреля 2010 г.). «RoCE: история любви Ethernet-InfiniBand» . провод HPC .
- ^ «Комплексное Ethernet-решение с минимальной задержкой для финансовых услуг» (PDF) . Мелланокс . Март 2011.
- ^ «Краткий обзор конкурентного анализа RoCE и iWARP» (PDF) . Мелланокс . 9 ноября 2010 г.
- ^ «Подключение к серверу с низкой задержкой с помощью нового адаптера Terminator 4 (T4)» . Челсио . 25 мая 2011 г.
- ^ Диего Крупников (17 октября 2014 г.). «Реестр имен служб и номеров портов транспортного протокола» . ИАНА . Проверено 14 октября 2018 г.
- ^ Торговая ассоциация InfiniBand (ноябрь 2013 г.). «Состояние и планы RoCE» (PDF) . IETF .
- ^ Офир Маор (декабрь 2015 г.). «Формат пакета RoCEv2 CNP» . Мелланокс .
- ^ Офир Маор (декабрь 2015 г.). «Управление перегрузкой RoCEv2» . Мелланокс .
- ^ «Ядро GIT» . Январь 2016.
- ^ Мерритт, Рик (19 апреля 2010 г.). «Новая конвергентная сеть сочетает в себе Ethernet и InfiniBand» . ЭЭ Таймс .
- ^ Кернер, Шон Майкл (2 апреля 2010 г.). «InfiniBand переходит на Ethernet?» . Планета корпоративных сетей .
- ^ Мелланокс (2 июня 2014 г.). «Mellanox выпускает новое программное обеспечение для автоматизации, позволяющее сократить время установки Ethernet-фабрики с часов до минут» . Мелланокс .
- ^ «SX1036 — 36-портовая коммутационная система 40/56GbE» . Мелланокс . Проверено 21 апреля 2014 г.
- ^ «IS5024 — 36-портовая неблокируемая неуправляемая система коммутаторов InfiniBand 40 Гбит/с» . Мелланокс . Проверено 21 апреля 2014 г.
- ^ Рашти, Мохаммед (2010). «Переопределение iWARP: масштабируемая связь без установления соединения через высокоскоростной Ethernet» (PDF) . Международная конференция по высокопроизводительным вычислениям (HiPC) .
- ^ Х. Шах; и др. (октябрь 2007 г.). «Прямое размещение данных через надежный транспорт» . РФК 5041 . дои : 10.17487/RFC5041 . Проверено 4 мая 2011 г.
- ^ К. Бестлер; и др. (октябрь 2007 г.). Бестлер, К.; Стюарт, Р. (ред.). «Адаптация прямого размещения данных (DDP) протокола передачи управления потоком (SCTP)» . РФК 5043 . дои : 10.17487/RFC5043 . Проверено 4 мая 2011 г.
- ^ П. Калли; и др. (октябрь 2007 г.). «Кадрирование с выравниванием по маркеру PDU для спецификации TCP» . РФК 5044 . дои : 10.17487/RFC5044 . Проверено 4 мая 2011 г.
- ^ «Intel® Ethernet серии 800» . Интел. Май 2021.
- ^ Jump up to: а б Т Люстиг; Ф Чжан; Джей Ко (октябрь 2007 г.). «RoCE против iWARP – очередные «большие дебаты о хранилищах» » . Архивировано из оригинала 20 мая 2019 года . Проверено 22 августа 2018 г.
- ^ «Преимущества удаленного прямого доступа к памяти через маршрутизируемые структуры» (PDF) . Циско. Октябрь 2018.
- ^ Драйер, Роланд (6 декабря 2010 г.). «Две заметки о IBoE» . Блог Роланда Драйера .
- ^ Коэн, Эли (26 августа 2010 г.). «IB/core: добавить поддержку VLAN для IBoE» . ядро.орг .
- ^ Коэн, Эли (13 октября 2010 г.). «RDMA/cm: добавить поддержку RDMA CM для устройств IBoE» . ядро.орг .
- ^ Кроуфорд, М. (1998). «RFC 2464 — Передача пакетов IPv6 по сетям Ethernet» . IETF . дои : 10.17487/RFC2464 .
- ^ Ху, Шуйхай; Чжу, Ибо; Ченг, Пэн; Го, Чуаньсюн; Тан, Кун; Падхе1, Джитендра; Чен, Кай (2016). Тупики в сетях центров обработки данных: почему они возникают и как их избежать (PDF) . 15-й семинар ACM по актуальным темам в сетях. стр. 92–98.
{{cite conference}}: CS1 maint: числовые имена: список авторов ( ссылка ) - ^ Шпинер, Алекс; Захави, Эйтан; Здорнов Владимир; Анкер, Таль; Кадош, Мэтти (2016). Разблокирование тупиков кредитного цикла . 15-й семинар ACM по актуальным темам в сетях. стр. 85–91.
- ^ Миттал, Радика; Шпинер, Александр; Панда, Ауроджит; Захави, Эйтан; Кришнамурти, Арвинд; Ратнасами, Сильвия; Шенкер, Скотт (21 июня 2018 г.). «Возвращаясь к сетевой поддержке RDMA». arXiv : 1806.08159 [ cs.NI ].
- ^ «Nvidia: сделка с Mellanox может быть закрыта не раньше начала 2020 года» . 14 ноября 2019 г.
- ^ «Израильская экосистема искусственного интеллекта отмечает предложение NVIDIA о приобретении Mellanox | Блог NVIDIA» . 27 марта 2019 г.
- ^ «Grovf Inc. выпускает IP-ядро RDMA RoCE V2 FPGA с низкой задержкой для интеллектуальных сетевых карт» . Yahoo Новости .