RDMA через конвергентный Ethernet - RDMA over Converged Ethernet

RDMA через конвергентный Ethernet (RoCE) - сетевой протокол, который позволяет удаленный прямой доступ к памяти (RDMA) через Ethernet сеть. Это достигается путем инкапсуляции IB транспортный пакет через Ethernet. Существует две версии RoCE: RoCE v1 и RoCE v2. RoCE v1 - это Ethernet уровень связи протокол и, следовательно, обеспечивает связь между любыми двумя хостами в одном и том же Ethernet широковещательный домен. RoCE v2 - это Интернет-уровень протокол, что означает возможность маршрутизации пакетов RoCE v2. Хотя протокол RoCE выигрывает от характеристик конвергентная сеть Ethernet, протокол также можно использовать в традиционной или неконвергентной сети Ethernet.[1][2][3][4]

Задний план

Сетевые приложения, такие как сетевое хранилище или кластерные вычисления, нуждаются в сетевой инфраструктуре с высокой пропускной способностью и низкой задержкой. Преимущества RDMA перед другими сетями интерфейсы прикладного программирования такие как Розетки Berkeley имеют меньшую задержку, меньшую нагрузку на ЦП и более высокую пропускную способность.[5] Протокол RoCE обеспечивает меньшие задержки, чем его предшественник, iWARP протокол.[6] Существуют RoCE HCA (адаптер хост-канала) с задержкой всего 1,3 микросекунды.[7][8] в то время как самая низкая известная задержка iWARP HCA в 2011 году составила 3 ​​микросекунды.[9]

Формат заголовка RoCE

RoCE v1

Протокол RoCE v1 - это протокол канального уровня Ethernet с Ethertype 0x8915.[1] Это означает, что применяются ограничения на длину кадра протокола Ethernet: 1500 байт для обычного Кадр Ethernet и 9000 байт для jumbo frame.


RoCE v1.5

RoCE v1.5 - это необычный экспериментальный нестандартный протокол, основанный на протоколе IP. RoCE v1.5 использует поле протокола IP, чтобы отличать свой трафик от других протоколов IP, таких как TCP и UDP. Значение, используемое для номера протокола, не указано, и его выбор остается на усмотрение развертывания.

RoCE v2

Протокол RoCE v2 существует поверх протокола UDP / IPv4 или UDP / IPv6.[2] Номер порта назначения UDP 4791 зарезервирован для RoCE v2.[10] Поскольку пакеты RoCEv2 маршрутизируемы, протокол RoCE v2 иногда называют маршрутизируемым RoCE.[11] или RRoCE.[3] Хотя в целом порядок доставки пакетов UDP не гарантируется, спецификация RoCEv2 требует, чтобы пакеты с одним и тем же портом источника UDP и адресом назначения не переупорядочивались.[3] Кроме того, RoCEv2 определяет механизм управления перегрузкой, который использует биты IP ECN для маркировки и CNP.[12] кадры для уведомления о подтверждении.[13] Программная поддержка RoCE v2 все еще появляется. Mellanox OFED 2.3 или более поздняя версия поддерживает RoCE v2, а также Linux Kernel v4.5.[14]

RoCE против InfiniBand

RoCE определяет, как выполнять RDMA поверх Ethernet в то время InfiniBand спецификация архитектуры определяет, как выполнять RDMA в сети InfiniBand. Ожидалось, что RoCE перенесет приложения InfiniBand, которые в основном основаны на кластерах, в общую конвергентную структуру Ethernet.[15] Другие ожидали, что InfiniBand и дальше будет предлагать более высокую пропускную способность и меньшую задержку, чем это возможно при использовании Ethernet.[16]

Технические различия между протоколами RoCE и InfiniBand:

  • Управление потоком на канальном уровне: InfiniBand использует алгоритм на основе кредита, чтобы гарантировать связь между HCA без потерь. RoCE работает поверх Ethernet, реализациям может потребоваться сеть Ethernet без потерь для достижения характеристик производительности, аналогичных InfiniBand, Ethernet без потерь обычно настраивается через Управление потоком Ethernet или приоритетное управление потоком (PFC). Настройка Мост для центров обработки данных (DCB) Сеть Ethernet может быть более сложной, чем настройка сети InfiniBand.[17]
  • Контроль перегрузки: Infiniband определяет контроль перегрузки на основе маркировки FECN / BECN, RoCEv2 определяет протокол управления перегрузкой, который использует ECN для маркировки, как это реализовано в стандартных коммутаторах, и кадры CNP для подтверждений.
  • Доступные коммутаторы InfiniBand всегда имели меньшую задержку, чем коммутаторы Ethernet. Задержка между портами для одного конкретного типа коммутатора Ethernet составляет 230 нс.[18] против 100 нс[19] для коммутатора InfiniBand с таким же количеством портов.

RoCE против iWARP

Хотя протоколы RoCE определяют, как выполнять RDMA с использованием кадров Ethernet и UDP / IP, iWARP протокол определяет, как выполнять RDMA через транспорт с установлением соединения, такой как Протокол управления передачей (TCP). RoCE v1 ограничен одним Ethernet широковещательный домен. Пакеты RoCE v2 и iWARP маршрутизируемы. Требования к памяти для большого количества подключений наряду с контролем потока и надежности TCP приводят к проблемам масштабируемости и производительности при использовании iWARP в крупных центрах обработки данных и для крупномасштабных приложений (например, крупных предприятий, облачных вычислений, приложений Web 2.0 и т. Д. .[20]). Кроме того, многоадресная передача определена в спецификации RoCE, тогда как текущая спецификация iWARP не определяет, как выполнять многоадресную передачу RDMA.[21][22][23]

Надежность в iWARP дается самим протоколом, как TCP надежен. RoCEv2, с другой стороны, использует UDP который имеет гораздо меньшие накладные расходы и лучшую производительность, но не обеспечивает присущей надежности, и поэтому надежность должна быть реализована вместе с RoCEv2. Одно из решений - использовать конвергентные коммутаторы Ethernet, чтобы сделать локальную сеть надежной. Это требует поддержки конвергентного Ethernet на всех коммутаторах в локальной сети и предотвращает прохождение пакетов RoCEv2 через глобальную сеть, такую ​​как Интернет, которая ненадежна. Другое решение - добавить надежность протоколу RoCE (то есть надежному RoCE), который добавляет квитирование к RoCE, чтобы обеспечить надежность за счет производительности.

Вопрос о том, какой протокол лучше, зависит от производителя. Intel и Chelsio рекомендуют и поддерживают iWARP исключительно. Mellanox, Xilinx и Broadcom рекомендуют и поддерживают исключительно RoCE / RoCEv2. Другие поставщики, работающие в сетевой индустрии, обеспечивают поддержку обоих протоколов, например, Marvell, Microsoft, Linux и Kazan.[24] Cisco поддерживает как RoCE[25] и их собственный протокол VIC RDMA.

Оба протокола стандартизированы: iWARP является стандартом для RDMA через TCP, определенным IETF и RoCE является стандартом для RDMA через Ethernet, определенным IBTA.[26]

Критика

Некоторые аспекты, которые могли быть определены в спецификации RoCE, были исключены. Эти:

  • Как выполнить перевод между первичными GID RoCE v1 и Ethernet MAC-адреса.[27]
  • Как выполнить перевод между вторичными GID RoCE v1 и MAC-адресами Ethernet. Неясно, возможно ли реализовать вторичные GID в протоколе RoCE v1 без добавления протокола разрешения адресов, специфичного для RoCE.
  • Как реализовать VLAN для протокола RoCE v1. Текущие реализации RoCE v1 хранят идентификатор VLAN в двенадцатом и тринадцатом байтах шестнадцатибайтового GID, хотя спецификация RoCE v1 вообще не упоминает VLAN.[28]
  • Как выполнить перевод между многоадресными GID RoCE v1 и MAC-адресами Ethernet. В реализациях 2010 года использовалось то же сопоставление адресов, которое было указано для сопоставления групповых адресов IPv6 с MAC-адресами Ethernet.[29][30]
  • Как ограничить многоадресный трафик RoCE v1 подмножеством портов коммутатора Ethernet. По состоянию на сентябрь 2013 г., эквивалент Обнаружение многоадресного прослушивателя протокол еще не определен для RoCE v1.

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

Известно, что использование PFC может привести к тупиковой ситуации во всей сети.[31][32][33]

Продавцы

Популярные производители оборудования с поддержкой RoCE включают:

использованная литература

  1. ^ а б «Спецификация архитектуры InfiniBand ™, версия 1.2.1, приложение A16: RoCE». Торговая ассоциация InfiniBand. 13 апреля 2010 г.
  2. ^ а б «Спецификация архитектуры InfiniBand ™, версия 1.2.1, приложение A17: RoCEv2». Торговая ассоциация InfiniBand. 2 сентября 2014 г.
  3. ^ а б c Офир Маор (декабрь 2015 г.). «Соображения по RoCEv2». Mellanox.
  4. ^ Офир Маор (декабрь 2015 г.). «RoCE и решения для хранения данных». Mellanox.
  5. ^ Кэмерон, Дон; Ренье, Грег (2002). Архитектура виртуального интерфейса. Intel Press. ISBN  978-0-9712887-0-6.
  6. ^ Фельдман, Майкл (22 апреля 2010 г.). "RoCE: история любви к Ethernet-InfiniBand". Провод HPC.
  7. ^ «Комплексное решение Ethernet с минимальной задержкой для финансовых услуг» (PDF). Mellanox. Март 2011 г.
  8. ^ «Обзор конкурентного анализа RoCE и iWARP» (PDF). Mellanox. 9 ноября 2010 г.
  9. ^ «Подключение к серверу с низкой задержкой и новым адаптером Terminator 4 (T4)». Chelsio. 25 мая 2011г.
  10. ^ Диего Крупникофф (17 октября 2014 г.). «Реестр имени службы и номера порта транспортного протокола». IANA. Получено 14 октября 2018.
  11. ^ InfiniBand Trade Association (ноябрь 2013 г.). «Статус и планы RoCE» (PDF). IETF.
  12. ^ Офир Маор (декабрь 2015 г.). "Формат пакета RoCEv2 CNP". Mellanox.
  13. ^ Офир Маор (декабрь 2015 г.). «Управление перегрузкой RoCEv2». Mellanox.
  14. ^ "Ядро GIT". Январь 2016 г.
  15. ^ Мерритт, Рик (19 апреля 2010 г.). «Новая конвергентная сеть сочетает в себе Ethernet и InfiniBand». EE Times.
  16. ^ Кернер, Шон Майкл (2 апреля 2010 г.). "InfiniBand переходит на Ethernet?". Планета корпоративных сетей.
  17. ^ Mellanox (2 июня 2014 г.). «Mellanox выпускает новое программное обеспечение для автоматизации, чтобы сократить время установки Ethernet Fabric с часов до минут». Mellanox.
  18. ^ «SX1036 - 36-портовая система коммутатора 40 / 56GbE». Mellanox. Получено 21 апреля, 2014.
  19. ^ "IS5024 - 36-портовая неблокирующая неуправляемая система коммутаторов InfiniBand 40 Гбит / с". Mellanox. Получено 21 апреля, 2014.
  20. ^ Рашти, Мохаммад (2010). «Новое определение iWARP: масштабируемая связь без установления соединения через высокоскоростной Ethernet» (PDF). Международная конференция по высокопроизводительным вычислениям (HiPC).
  21. ^ Х. Шах; и другие. (Октябрь 2007 г.). «Прямое размещение данных через надежный транспорт». RFC 5041. Получено 4 мая, 2011.
  22. ^ К. Бестлер; и другие. (Октябрь 2007 г.). «Адаптация к прямому размещению данных (DDP) по протоколу управления потоком (SCTP)». RFC 5043. Получено 4 мая, 2011.
  23. ^ П. Калли; и другие. (Октябрь 2007 г.). «Выровненное кадрирование PDU Marker для спецификации TCP». RFC 5044. Получено 4 мая, 2011.
  24. ^ Т. Люстиг; Ф Чжан; Дж. Ко (октябрь 2007 г.). «RoCE против iWARP - следующий большой спор о хранилищах»"". Получено 22 августа, 2018.
  25. ^ «Преимущества удаленного прямого доступа к памяти по маршрутизируемым фабрикам» (PDF). Cisco. Октябрь 2018.
  26. ^ Т. Люстиг; Ф Чжан; Дж. Ко (октябрь 2007 г.). «RoCE против iWARP - следующий большой спор о хранилищах»"". Получено 22 августа, 2018.
  27. ^ Дрейер, Роланд (6 декабря 2010 г.). «Две ноты по IBoE». Блог Роланда Драйера.
  28. ^ Коэн, Эли (26 августа 2010 г.). «IB / core: добавить поддержку VLAN для IBoE». kernel.org.
  29. ^ Коэн, Эли (13 октября 2010 г.). «RDMA / cm: добавить поддержку RDMA CM для устройств IBoE». kernel.org.
  30. ^ Кроуфорд, М. (1998). «RFC 2464 - Передача пакетов IPv6 по сетям Ethernet». IETF.
  31. ^ Ху, Шуйхай; Чжу, Ибо; Ченг, Пэн; Го, Чуаньсюн; Тан, Кун; Padhye1, Jitendra; Чен, Кай (2016). Тупики в сетях центров обработки данных: почему они образуются и как их избежать (PDF). 15-й семинар ACM по горячим темам в сетях. С. 92–98.
  32. ^ Шпинер, Алексей; Захави, Эйтан; Здорнов, Владимир; Анкер, Таль; Кадош, Мэтти (2016). Разблокирование тупиковых ситуаций кредитного цикла. 15-й семинар ACM по горячим темам в сетях. С. 85–91.
  33. ^ Миттал, Радхика; Шпинер Александр; Панда, Ауроджит; Захави, Эйтан; Кришнамурти, Арвинд; Ратнасами, Сильвия; Шенкер, Скотт (21 июня 2018 г.). «Возвращение к сетевой поддержке RDMA». arXiv:1806.08159 [cs.NI ].
  34. ^ https://www.crn.com/news/components-peripherals/nvidia-mellanox-deal-may-not-close-until-early-2020
  35. ^ https://blogs.nvidia.com/blog/2019/03/27/israel-mellanox-nvidia/