基于融合以太网的RDMA

维基百科,自由的百科全书

基于融合以太网的RDMA(英語:RDMA over Converged Ethernet,缩写RoCE)是一个网络协议,允许在一个以太网[臺灣版仍應稱以太,乙字本不同音,誤用入聲字,與乙醚無關]网络上使用远程直接内存访问(RDMA)。RoCE有RoCE v1和RoCE v2两个版本。RoCE v1是一个以太网链路层协议,因此允许同一个以太网广播域中的任意两台主机间进行通信。RoCE v2是一个网络层协议,因而RoCE v2数据包可以被路由。虽然RoCE协议受益于融合以太网网络英语数据中心桥接的特征,但该协议也可用于传统或非融合的以太网网络。[1][2][3][4]

背景

网络密集型应用程序(如网络存储或群集计算)需要具有高带宽且低延迟的网络基础架构。RDMA相比其他网络应用程序接口(诸如Berkeley套接字)的优势是更低的延迟、更低的CPU占用,以及更高的带宽。[5]RoCE协议有着比其前身iWARP英语iWARP协议更低的延迟。[6]现有的RoCE HCA(主机通道适配器)的延迟低至1.3微秒[7][8],而在2011年已知的最低的iWARP HCA的延迟为3微秒。[9]

RoCE标头格式

RoCE v1

RoCE v1协议是一个以太网链路层协议,Ethertype为0x8915。它要符合以太网协议的帧长度限制:常规以太网帧为1500字节,巨型帧为9000字节。

RoCE v2

RoCEv2协议构筑于UDP/IPv4或UDP/IPv6协议之上。UDP目标端口号4791已保留给RoCE v2。[10]因为RoCEv2数据包是可路由的,所以RoCE v2协议有时被称为Routable RoCE[11]或RRoCE。虽然一般不保证UDP数据包的传达顺序,但RoCEv2规范要求,有相同UDP源端口及目标地址的数据包不得改变顺序。除此之外,RoCEv2定义了一种拥塞控制机制,使用IP ECN位用于标记,CNP[12]帧用于送达通知。[13]软件对RoCE v2的支持在不断涌现。Mellanox OFED 2.3或更高版本支持RoCE v2,Linux内核v4.5也提供支持。[14]

RoCE与InfiniBand相比

RoCE定义了如何在以太网上执行RDMA,InfiniBand架构规范则定义了如何在一个InfiniBand网络上执行RDMA。RoCE预期为将主要面向群集的InfiniBand应用程序带入到一个寻常的以太网融合结构。[15]有人[谁?]认为,InfiniBand将会继续提供比以太网更高的带宽以及更低的延迟。[16]

RoCE与InfiniBand协议之间的技术差异:

  • 链路级流量控制:InfiniBand使用一个积分算法来保证无损的HCA到HCA通信。RoCE运行在以太网之上,其实现可能需要“无损以太网”以达到类似于InfiniBand的性能特征,无损以太网一般通过以太网流量控制或优先流量控制(PFC)配置。配置一个数据中心桥接英语Data center bridging(DCB)以太网网络可能比配置InfiniBand网络更为复杂。[17]
  • 拥塞控制:Infiniband定义了基于FECN/BECN标记的拥塞控制,RoCEv2则定义了一个拥塞控制协议,它使用ECN标记在标准交换机中的实现,以及CNP帧用于送达确认。
  • 可用的InfiniBand交换机始终有比以太网交换机更低的延迟。一台特定类型以太网交换机的端口至端口延迟为230纳秒[18],而有相同端口数量的一台InfiniBand交换机为100纳秒[19]

RoCE与iWARP相比

相比RoCE协议定义了如何使用以太网和UDP/IP帧执行RDMA,iWARP协议定义了如何基于一个面向连接的传输(如传输控制协议,TCP)执行RDMA。RoCE v1受限于单个广播域,RoCE v2和iWARP封包则可以路由。在大规模数据中心和大规模应用程序(即大型企业、云计算、Web 2.0应用程序等[20])中使用iWARP时,大量连接的内存需求,以及TCP的流量和可靠性控制,将会导致可扩展性和性能问题。此外,RoCE规范中定义了多播,而当前的iWARP规范中没有定义如何执行多播RDMA。[21][22][23]

iWARP中的可靠性由协议本身提供,因为TCP/IP为可靠传输。相比而言,RoCEv2采用UDP/IP,这使它有更小的开销和更好的性能,但不提供固有的可靠性,因此可靠性必须搭配RoCEv2实现。其中一种解决方案是,使用融合以太网交换机使局域网变得可靠。这需要局域网内的所有交换机支持融合以太网,并防止RoCEv2数据包通过诸如互联网等不可靠的广域网传输。另一种解决方案是增加RoCE协议的可靠性(即可靠的RoCE),向RoCE添加握手,通过牺牲性能为代价提供可靠性。

两种协议哪种更好的问题取决于供应商。英特尔和Chelsio建议并独家支持iWARP。Mellanox、Xilinx以及Broadcom推荐并独家支持RoCE/RoCEv2。思科同时支持RoCE[24]与自家的VIC RDMA协议。网络行业中的其他供应商则同时提供两种协议的支持,这些供应商如Marvell微软Linux和Kazan。[25]

两种协议都经过了标准化,iWARP是IETF定义的基于以太网的RDMA,RoCE是InfiniBand贸易协会英语IBTA定义的基于以太网的RDMA  [26]

供应商

支持RoCE的设备的主要供应商包括:

参考文献

  1. ^ InfiniBand™ Architecture Specification Release 1.2.1 Annex A16: RoCE. 13 April 2010 [2018-12-21]. (原始内容存档于2016-03-09). 
  2. ^ InfiniBand™ Architecture Specification Release 1.2.1 Annex A17: RoCEv2. 2 September 2014 [2018-12-21]. (原始内容存档于2020-09-17). 
  3. ^ Ophir Maor. RoCEv2 Considerations. Mellanox. December 2015 [2018-12-21]. (原始内容存档于2018-04-10). 
  4. ^ Ophir Maor. RoCE and Storage Solutions. December 2015 [2018-12-21]. (原始内容存档于2016-12-21). 
  5. ^ Cameron, Don; Regnier, Greg. Virtual Interface Architecture. Intel Press. 2002. ISBN 978-0-9712887-0-6. 
  6. ^ Feldman, Michael. RoCE: An Ethernet-InfiniBand Love Story. 22 April 2010 [2018-12-21]. (原始内容存档于2014-02-10). 
  7. ^ End-to-End Lowest Latency Ethernet Solution for Financial Services (PDF). March 2011 [2018-12-21]. (原始内容存档 (PDF)于2020-06-13). 
  8. ^ RoCE vs. iWARP Competitive Analysis Brief (PDF). 9 November 2010 [2018-12-21]. (原始内容存档 (PDF)于2020-10-24). 
  9. ^ Low Latency Server Connectivity With New Terminator 4 (T4) Adapter. 25 May 2011 [2018-12-21]. (原始内容存档于2012-10-22). 
  10. ^ Diego Crupnicoff. Service Name and Transport Protocol Port Number Registry. 17 October 2014 [14 October 2018]. (原始内容存档于2019-05-20). 
  11. ^ InfiniBand Trade Association. RoCE Status and Plans (PDF). November 2013 [2018-12-21]. (原始内容存档 (PDF)于2020-06-13). 
  12. ^ Ophir Maor. RoCEv2 CNP Packet Format. December 2015 [2018-12-21]. (原始内容存档于2018-10-15). 
  13. ^ Ophir Maor. RoCEv2 Congestion Management. December 2015 [2018-12-21]. (原始内容存档于2018-10-15). 
  14. ^ Kernel GIT. January 2016. 
  15. ^ Merritt, Rick. New converged network blends Ethernet, InfiniBand. 19 April 2010 [2018-12-21]. (原始内容存档于2012-10-04). 
  16. ^ Kerner, Sean Michael. InfiniBand Moving to Ethernet ?. 2 April 2010 [2018-12-21]. (原始内容存档于2020-11-30). 
  17. ^ Mellanox. Mellanox Releases New Automation Software to Reduce Ethernet Fabric Installation Time from Hours to Minutes. 2 June 2014 [2018-12-21]. (原始内容存档于2016-03-03). 
  18. ^ SX1036 - 36-Port 40/56GbE Switch System. [April 21, 2014]. (原始内容存档于2014-04-22). 
  19. ^ IS5024 - 36-Port Non-blocking Unmanaged 40Gb/s InfiniBand Switch System. [April 21, 2014]. (原始内容存档于2014-04-19). 
  20. ^ Rashti, Mohammad. iWARP Redefined: Scalable Connectionless Communication over High-Speed Ethernet (PDF). International Conference on High Performance Computing (HiPC). 2010 [2019-03-12]. (原始内容存档 (PDF)于2017-08-10). 
  21. ^ H. Shah. Direct Data Placement over Reliable Transports. RFC 5041. October 2007 [May 4, 2011]. (原始内容存档于2020-11-27). 
  22. ^ C. Bestler. Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation. RFC 5043. October 2007 [May 4, 2011]. (原始内容存档于2020-11-25). 
  23. ^ P. Culley. Marker PDU Aligned Framing for TCP Specification. RFC 5044. October 2007 [May 4, 2011]. (原始内容存档于2020-11-27). 
  24. ^ 存档副本 (PDF). [2018-12-21]. (原始内容存档 (PDF)于2020-06-13). 
  25. ^ T Lustig; F Zhang; J Ko,. RoCE vs. iWARP – The Next “Great Storage Debate”. October 2007 [August 22, 2018]. (原始内容存档于2019-05-20). 
  26. ^ T Lustig; F Zhang; J Ko,. RoCE vs. iWARP – The Next “Great Storage Debate”. October 2007 [August 22, 2018]. (原始内容存档于2019-05-20). CS1 maint: Multiple names: authors list (link)