RDMA sobre Ethernet convergente

De Wikipedia, la enciclopedia libre
Esta es una versión antigua de esta página, editada a las 18:32 24 feb 2020 por InternetArchiveBot (discusión · contribs.). La dirección URL es un enlace permanente a esta versión, que puede ser diferente de la versión actual.

RDMA sobre Ethernet convergente (RoCE por sus siglas en inglés) es un protocolo de red que permite el acceso remoto directo a la memoria (RDMA) a través de una red Ethernet. Lo hace encapsulando un paquete de transporte InfiniBand a través de Ethernet. Hay dos versiones de RoCE, RoCE v1 y RoCE v2. RoCE v1 es un protocolo de capa de enlace Ethernet y, por lo tanto, permite la comunicación entre dos hosts en el mismo dominio de difusión Ethernet. RoCE v2 es un protocolo de capa de Internet que significa que los paquetes RoCE v2 pueden enrutarse. Aunque el protocolo RoCE se beneficia de las características de una red Ethernet convergente, el protocolo también se puede utilizar en una red Ethernet tradicional o no convergente.[1]​[2]​ [3]​[4]​

Antecedentes

Las aplicaciones intensivas en red, como el almacenamiento en red o la informática en clúster, necesitan una infraestructura de red con un ancho de banda alto y una latencia baja. Las ventajas de RDMA sobre otras interfaces de programación de aplicaciones de red como los sockets de Berkeley son menor latencia, menor carga de CPU y mayor ancho de banda.[5]​ El protocolo RoCE permite latencias más bajas que su predecesor, el protocolo iWARP.[6]​ Existen HCA RoCE (Adaptador de canal de host) con una latencia tan baja como 1.3 microsegundos[7]​ [8]​ mientras que la latencia de HCA iWARP más baja conocida en 2011 fue de 3 microsegundos.[9]​

Formato de encabezado RoCE

Versiones

RoCE v1

El protocolo RoCE v1 es un protocolo de capa de enlace Ethernet con Ethertype 0x8915.[1]​ Esto significa que se aplican los límites de longitud de trama del protocolo Ethernet: 1500 bytes para una trama Ethernet normal y 9000 bytes para una trama jumbo.

RoCE v1.5

El RoCE v1.5 es un protocolo poco común, experimental y no estandarizado que se basa en el protocolo IP. RoCE v1.5 usa el campo de protocolo IP para diferenciar su tráfico de otros protocolos IP como TCP y UDP. El valor utilizado para el número de protocolo no está especificado y se deja a la implementación para que lo seleccione.

RoCE v2

El protocolo RoCE v2 existe sobre el protocolo UDP/IPv4 o UDP/IPv6.[2]​ El número de puerto de destino UDP 4791 se ha reservado para RoCE v2.[10]​ Dado que los paquetes RoCEv2 son enrutables, el protocolo RoCE v2 a veces se denomina RoCE enrutable[11]​ o RRoCE. [3]​ Aunque en general el orden de entrega de los paquetes UDP no está garantizado, la especificación RoCEv2 requiere que los paquetes con el mismo puerto de origen UDP y la misma dirección de destino no se deben reordenar. Además, RoCEv2 define un mecanismo de control de congestión que utiliza los bits IP ECN para marcar y las tramas CNP [12]​ para la notificación de acuse de recibo.[13]​ El soporte de software para RoCE v2 todavía está surgiendo. Mellanox OFED 2.3 o posterior tiene soporte RoCE v2 y también Linux Kernel v4.5.[14]​

RoCE versus InfiniBand

RoCE define cómo realizar RDMA a través de Ethernet, mientras que la especificación de arquitectura InfiniBand define cómo realizar RDMA a través de una red InfiniBand. Se esperaba que RoCE trajera aplicaciones InfiniBand, que se basan predominantemente en clústeres, en una estructura convergente Ethernet común.[15]​ Otros esperaban que InfiniBand siguiera ofreciendo un mayor ancho de banda y una latencia más baja de lo que es posible a través de Ethernet.[16]​

Las diferencias técnicas entre los protocolos RoCE e InfiniBand son:

  • Control de flujo de nivel de enlace: InfiniBand utiliza un algoritmo basado en el crédito para garantizar una comunicación HCA-a-HCA sin pérdidas. RoCE se ejecuta sobre Ethernet, las implementaciones pueden requerir una red Ethernet sin pérdida para alcanzar características de rendimiento similares a InfiniBand, la Ethernet sin pérdida generalmente se configura mediante control de flujo de Ethernet o control de flujo prioritario (PFC). Configurar una red Ethernet de puente de centro de datos (DCB) puede ser más complejo que configurar una red InfiniBand. [17]​
  • Control de congestión: Infiniband define el control de congestión basado en el marcado FECN/BECN, RoCEv2 define un protocolo de control de congestión que utiliza ECN para el marcado implementado en interruptores estándar y tramas CNP para acuses de recibo.
  • Los conmutadores InfiniBand disponibles siempre han tenido una latencia menor que los conmutadores Ethernet. La latencia de puerto a puerto para un tipo particular de conmutador Ethernet es 230 ns[18]​ versus 100 ns[19]​ para un conmutador InfiniBand con el mismo número de puertos.

RoCE versus iWARP

Mientras que los protocolos RoCE definen cómo realizar RDMA usando tramas Ethernet y UDP/IP, el protocolo iWARP define cómo realizar RDMA a través de un transporte orientado a la conexión como el Protocolo de Control de Transmisión (TCP). RoCE v1 está limitado a un solo dominio de difusión Ethernet. Los paquetes RoCE v2 e iWARP son enrutables. Los requisitos de memoria de una gran cantidad de conexiones junto con los controles de flujo y confiabilidad de TCP conducen a problemas de escalabilidad y rendimiento al usar iWARP en centros de datos a gran escala y para aplicaciones a gran escala (es decir, empresas a gran escala, computación en la nube, aplicaciones web 2.0, etc.).[20]​ Además, la multidifusión se define en la especificación RoCE, mientras que la especificación iWARP actual no define cómo realizar RDMA multidifusión.[21]​[22]​[23]​

La confiabilidad en iWARP viene dada por el protocolo en sí, ya que TCP es confiable. RoCEv2, por otro lado, utiliza UDP, que tiene una sobrecarga mucho menor y un mejor rendimiento, pero no proporciona confiabilidad inherente, y por lo tanto, la confiabilidad debe implementarse junto con RoCEv2. Una solución es utilizar conmutadores Ethernet convergentes para hacer que la red de área local sea confiable. Esto requiere soporte convergente de Ethernet en todos los conmutadores en la red de área local y evita que los paquetes RoCEv2 viajen a través de una red de área amplia como Internet, lo cual no es confiable. Otra solución es agregar confiabilidad al protocolo RoCE (es decir, RoCE confiable) que agrega handshake a RoCE para proporcionar confiabilidad a costa del rendimiento.

La cuestión de qué protocolo es mejor depende del proveedor. Intel y Chelsio recomiendan y apoyan exclusivamente iWARP. Mellanox, Xilinx y Broadcom recomiendan y admiten exclusivamente RoCE/RoCEv2. Otros proveedores involucrados en la industria de la red brindan soporte para ambos protocolos, como Marvell, Microsoft, Linux y Kazan.[24]​ Cisco admite tanto RoCE[25]​ como su propio protocolo VIC RDMA.

Ambos protocolos están estandarizados con iWARP como el estándar para RDMA sobre TCP definido por el IETF y RoCE como el estándar para RDMA sobre Ethernet definido por el IBTA.[26]​

Críticas

Algunos aspectos que podrían haberse definido en la especificación RoCE se han omitido. Estos son:

  • Cómo traducir entre los GID principales de RoCE v1 y las direcciones MAC de Ethernet.[27]​
  • Cómo traducir entre GID secundarios de RoCE v1 y direcciones MAC de Ethernet. No está claro si es posible implementar GID secundarios en el protocolo RoCE v1 sin agregar un protocolo de resolución de direcciones específico de RoCE.
  • Cómo implementar VLAN para el protocolo RoCE v1. Las implementaciones actuales de RoCE v1 almacenan la ID de VLAN en el duodécimo y decimotercer byte del GID de dieciséis bytes, aunque la especificación RoCE v1 no menciona las VLAN en absoluto.[28]​
  • Cómo traducir entre GCE multidifusión RoCE v1 y direcciones MAC Ethernet. Las implementaciones en 2010 utilizaron la misma asignación de direcciones que se ha especificado para asignar direcciones de multidifusión IPv6 a direcciones MAC de Ethernet.[29]​[30]​
  • Cómo restringir el tráfico de multidifusión RoCE v1 a un subconjunto de los puertos de un conmutador Ethernet. A partir de septiembre de 2013, aún no se ha definido un equivalente del protocolo Multicast Listener Discovery para RoCE v1.

Además, cualquier protocolo que se ejecute a través de IP no puede asumir que la red subyacente ha garantizado el pedido, como tampoco puede suceder que se produzca congestión.

Se sabe que el uso de PFC puede conducir a un punto muerto en toda la red.[31]​[32]​[33]​

Vendedores

Los vendedores populares de equipos habilitados para RoCE incluyen:

Referencias

  1. ↑ a b «InfiniBand™ Architecture Specification Release 1.2.1 Annex A16: RoCE». InfiniBand Trade Association. 13 de abril de 2010. 
  2. ↑ a b «InfiniBand™ Architecture Specification Release 1.2.1 Annex A17: RoCEv2». InfiniBand Trade Association. 2 de septiembre de 2014. 
  3. ↑ a b Ophir Maor (December 2015). «RoCEv2 Considerations». Mellanox. 
  4. ↑ Ophir Maor (December 2015). «RoCE and Storage Solutions». Mellanox. 
  5. ↑ Cameron, Don; Regnier, Greg (2002). Virtual Interface Architecture. Intel Press. ISBN 978-0-9712887-0-6. 
  6. ↑ Feldman, Michael (22 de abril de 2010). «RoCE: An Ethernet-InfiniBand Love Story». HPC wire. Archivado desde el original el 10 de febrero de 2014. Consultado el 4 de enero de 2020. 
  7. ↑ «End-to-End Lowest Latency Ethernet Solution for Financial Services». Mellanox. March 2011. 
  8. ↑ «RoCE vs. iWARP Competitive Analysis Brief». Mellanox. 9 de noviembre de 2010. 
  9. ↑ «Low Latency Server Connectivity With New Terminator 4 (T4) Adapter». Chelsio. 25 de mayo de 2011. 
  10. ↑ Diego Crupnicoff (17 de octubre de 2014). «Service Name and Transport Protocol Port Number Registry». IANA. Consultado el 14 de octubre de 2018. 
  11. ↑ InfiniBand Trade Association (November 2013). «RoCE Status and Plans». IETF. 
  12. ↑ Ophir Maor (December 2015). «RoCEv2 CNP Packet Format». Mellanox. 
  13. ↑ Ophir Maor (December 2015). «RoCEv2 Congestion Management». Mellanox. 
  14. ↑ «Kernel GIT». January 2016. 
  15. ↑ Merritt, Rick (19 de abril de 2010). «New converged network blends Ethernet, InfiniBand». EE Times. 
  16. ↑ Kerner, Sean Michael (2 de abril de 2010). «InfiniBand Moving to Ethernet ?». Enterprise Networking Planet. 
  17. ↑ Mellanox (2 de junio de 2014). «Mellanox Releases New Automation Software to Reduce Ethernet Fabric Installation Time from Hours to Minutes». Mellanox. Archivado desde el original el 3 de marzo de 2016. Consultado el 4 de enero de 2020. 
  18. ↑ «SX1036 - 36-Port 40/56GbE Switch System». Mellanox. Archivado desde el original el 22 de abril de 2014. Consultado el 21 de abril de 2014. 
  19. ↑ «IS5024 - 36-Port Non-blocking Unmanaged 40Gb/s InfiniBand Switch System». Mellanox. Archivado desde el original el 19 de abril de 2014. Consultado el 21 de abril de 2014. 
  20. ↑ . 2010.  Falta el |título= (ayuda)
  21. ↑ H. Shah (October 2007). «Direct Data Placement over Reliable Transports». RFC 5041. Consultado el 4 de mayo de 2011. 
  22. ↑ C. Bestler (October 2007). «Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation». RFC 5043. Consultado el 4 de mayo de 2011. 
  23. ↑ P. Culley (October 2007). «Marker PDU Aligned Framing for TCP Specification». RFC 5044. Consultado el 4 de mayo de 2011. 
  24. ↑ T Lustig (October 2007). «RoCE vs. iWARP – The Next "Great Storage Debate"». Consultado el 22 de agosto de 2018. 
  25. ↑ «Benefits of Remote Direct Memory Access Over Routed Fabrics». Cisco. October 2018. 
  26. ↑ T Lustig (October 2007). «RoCE vs. iWARP – The Next "Great Storage Debate"». Consultado el 22 de agosto de 2018. 
  27. ↑ Dreier, Roland (6 de diciembre de 2010). «Two notes on IBoE». Roland Dreier's blog. 
  28. ↑ Cohen, Eli (26 de agosto de 2010). «IB/core: Add VLAN support for IBoE». kernel.org. 
  29. ↑ Cohen, Eli (13 de octubre de 2010). «RDMA/cm: Add RDMA CM support for IBoE devices». kernel.org. 
  30. ↑ Crawford, M. (1998). «RFC 2464 - Transmission of IPv6 Packets over Ethernet Networks». IETF. 
  31. ↑ . 15th ACM Workshop on Hot Topics in Networks. 2016. pp. 92-98. 
  32. ↑ . 15th ACM Workshop on Hot Topics in Networks. 2016. pp. 85-91. 
  33. ↑ Mittal, Radhika (21 de junio de 2018). «Revisiting Network Support for RDMA». MISSING LINK.. 
  34. ↑ https://blogs.nvidia.com/blog/2019/03/27/israel-mellanox-nvidia/
Obtenido de «https://es.wikipedia.org/w/index.php?title=RDMA_sobre_Ethernet_convergente&oldid=123799920»