Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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], в то время как самая низкая известная задержка HCA iWARP в 2011 году составляла 3 микросекунды. [9]

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

RoCE v1 [ править ]

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

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 v4.5. [14]

RoCE против InfiniBand [ править ]

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

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

  • Управление потоком на уровне канала: InfiniBand использует алгоритм на основе кредита, чтобы гарантировать без потерь связь между HCA и HCA. RoCE работает поверх Ethernet, реализациям может потребоваться сеть Ethernet без потерь для достижения характеристик производительности, аналогичных InfiniBand, Ethernet без потерь обычно настраивается через управление потоком Ethernet или управление приоритетным потоком (PFC). Настройка сети Ethernet с мостовым соединением центра обработки данных (DCB) может быть более сложной, чем настройка сети 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 . [24]

Критика [ править ]

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

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

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

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

Продавцы [ править ]

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

  • Mellanox (приобретена Nvidia , [33] бренд сохранен [34] )
  • Emulex (приобретен Broadcom )
  • Broadcom
  • QLogic (приобретена Cavium , переименована)
  • Cavium (приобретена Marvell Technology Group , переименована)
  • Huawei
  • Технология ATTO
  • Bloombase

Ссылки [ править ]

  1. ^ a b «Спецификация архитектуры InfiniBand ™, версия 1.2.1, приложение A16: RoCE» . Торговая ассоциация InfiniBand . 13 апреля 2010 г.
  2. ^ a b «Спецификация архитектуры InfiniBand ™, версия 1.2.1, приложение A17: RoCEv2» . Торговая ассоциация InfiniBand . 2 сентября 2014 г.
  3. ^ a b 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)» . Челсио . 25 мая 2011г.
  10. ^ Диего Crupnicoff (17 октября 2014). «Реестр имени службы и номера порта транспортного протокола» . IANA . Проверено 14 октября 2018 года .
  11. ^ InfiniBand Trade Association (ноябрь 2013 г.). «Статус и планы RoCE» (PDF) . IETF .
  12. ↑ Офир Маор (декабрь 2015 г.). «Формат пакета CNP RoCEv2» . 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-маркера для спецификации TCP» . RFC 5044 . Проверено 4 мая 2011 года .
  24. ^ a b T Lustig; Ф Чжан; Дж. Ко (октябрь 2007 г.). «RoCE против iWARP - следующий« большой спор о хранении » » . Проверено 22 августа 2018 года .
  25. ^ «Преимущества удаленного прямого доступа к памяти по маршрутизируемым фабрикам» (PDF) . Cisco. Октябрь 2018.
  26. ^ Дрейер, Roland (6 декабря 2010). «Две ноты по IBoE» . Блог Роланда Драйера .
  27. ↑ Коэн, Эли (26 августа 2010 г.). «IB / core: добавить поддержку VLAN для IBoE» . kernel.org .
  28. ↑ Коэн, Эли (13 октября 2010 г.). «RDMA / cm: добавить поддержку RDMA CM для устройств IBoE» . kernel.org .
  29. Перейти ↑ Crawford, M. (1998). «RFC 2464 - Передача пакетов IPv6 по сетям Ethernet» . IETF .
  30. ^ Ху, Шуйхай; Чжу, Ибо; Ченг, Пэн; Го, Чуаньсюн; Тан, Кун; Padhye1, Jitendra; Чен, Кай (2016). Тупики в сетях центров обработки данных: почему они образуются и как их избежать (PDF) . 15-й семинар ACM по горячим темам в сетях. С. 92–98.
  31. ^ Шпинер, Алекс; Захави, Эйтан; Здорнов, Владимир; Анкер, Таль; Кадош, Мэтти (2016). Разблокирование тупиков кредитного цикла . 15-й семинар ACM по горячим темам в сетях. С. 85–91.
  32. ^ Миттал, Радхика; Шпинер Александр; Панда, Ауроджит; Захави, Эйтан; Кришнамурти, Арвинд; Ратнасами, Сильвия; Шенкер, Скотт (21 июня 2018 г.). «Возвращение к сетевой поддержке RDMA». arXiv : 1806.08159 [ cs.NI ].
  33. ^ https://www.crn.com/news/components-peripherals/nvidia-mellanox-deal-may-not-close-until-early-2020
  34. ^ https://blogs.nvidia.com/blog/2019/03/27/israel-mellanox-nvidia/