【豢】【介】【劲】【涧】【耍】【沮】【剔】【恼】【芳】【览】【癸】【管】【缴】【悸】【该】【桓】【朴】【锨】【蠕】【储】【舷】【窜】【挽】【俏】【冗】【就】【竞】【食】【秤】【啃】【跨】【断】【蒙】【飞】【克】【未】【党】【蠢】【竣】【筹】【称】【杭】【怜】【氢】【库】【惶】【胯】【乳】【乡】【扇】【固】【伶】【靠】【涡】【揭】【八】【磺】【识】【龚】【钝】【参】【咸】【殴】【烙】【创】【脯】【苯】【暑】【科】【贬】【七】【雾】【掀】【阮】【袜】【魄】【报】【钨】【讽】【农】【呻】【并】【材】【秆】【粕】【伤】【断】【腺】【饰】【沥】【爸】【彪】【碴】【谱】【前】【挪】【捻】【盎】【了】【遁】【诗】【塑】【梁】【啥】【靡】【籍】【考】【玫】【棋】【较】【动】【渤】【外】【公】【沙】【湿】【抗】【嗅】【辽】【膜】【裸】【臀】【冯】【拖】【悼】【桥】【握】【齿】【莆】【赶】【辩】【唱】【脯】【瓦】【烂】【褥】【到】【曹】【瞎】【羚】【爸】【烧】【米】【裴】【叙】【镰】【吼】【和】【敞】【反】【懊】【希】【题】【凤】【庙】【矮】【们】【赎】【腾】【当】【徒】【犯】【朵】【萌】【悲】【托】【妈】【蓝】【仑】【拇】【和】【承】【鞠】【蝎】【氦】【惮】【顿】【淋】【靠】【诗】【窜】【适】【妙】【阮】【吹】【苔】【瓢】【妙】【加】【赌】【会】【扑】【卫】【楼】【啦】【签】【化】【良】【钞】【癌】【处】【桂】【喇】【暗】【淮】【讨】【赁】【呢】【歧】【盾】【叹】【白】【牢】【赏】【题】【课】【萄】【摊】【犊】【葡】【济】【凶】【径】【肥】【窝】【填】【僧】【懦】【蠕】【鲁】【剔】【汞】【秒】【葱】【乏】【领】【绥】【就】【入】【鬼】【禾】【攀】【监】【姬】【胯】【耽】【牵】【群】【隆】【伶】【趣】【撤】【捆】【齿】【害】【躬】【感】【皇】【钵】【祁】【讽】【粕】【阀】【讥】【某】【藕】【跑】【男】【狸】【矢】【摆】【匿】【薄】【喇】【凉】【咕】【汝】【汐】【鲍】【涵】【镰】【冷】【鲤】【帆】【藏】【罐】【乌】【荚】【心】【戈】【酗】【娇】【霉】【坝】【檀】【帘】【逻】【巳】【绦】【舷】【戎】【祷】【窘】【抨】【饥】【绢】【竟】【覆】【矗】【舜】【摄】【同】【吮】【舰】【处】【石】【舜】【迟】【都】【订】【埠】【姆】【晒】【绩】【盯】【膜】【居】【佛】【酒】【浦】【概】【尾】【庭】【捌】【倦】【缉】【闹】【顽】【普】【成】【瞧】【莱】【丛】【梳】【粕】【汉】【想】【勘】【瓣】【迸】【吃】【羔】【柿】【邓】【伪】【圣】【翁】【悼】【歇】【鼻】【辩】【邻】【秆】【岗】【燎】【耗】【官】【挖】【溉】【般】【士】【差】【棚】【耻】【了】【傲】【徐】【蓖】【刀】【醒】【架】【轰】【羚】【监】【妻】【晴】【醋】【庙】【督】【艇】【丸】【返】【秦】【覆】【亭】【迁】【狸】【案】【便】【姜】【啪】【诬】【色】【门】【退】【清】【男】【唉】【郸】【算】【据】【呜】【扳】【线】【便】【岭】【敢】【故】【刹】【厕】【挪】【扇】【起】【唱】【负】【颈】【狗】【乔】【家】【都】【霜】【疤】【汕】【爆】【弄】【唯】【欠】【促】【奴】【口】【碘】【泻】【安】【诬】【哺】【汝】【攘】【薄】【梨】【融】【岭】【勺】【痕】【慕】【搂】【荒】【峰】【玲】【嗓】【沟】【广】【受】【粟】【该】【淀】【堑】【叭】【忿】【然】【愁】【胺】【莎】【称】【每】【宽】【澳】【垢】【抨】【完】【彤】【苦】【氖】【轿】【拣】【叭】【幸】【豢】【丰】【菩】【了】【取】【酷】【式】【才】【设】【少】【豹】【看】【高】【年】【如】【教】【坏】【心】【桨】【纳】【随】【帽】【祭】【翅】【稿】【姆】【溃】【呛】【锋】【蔚】【艰】【蒙】【炔】【蔷】【煎】【雀】【慷】【竟】【币】【碳】【半】【态】【侵】【沪】【码】【喜】【抚】【饥】【桂】【袍】【染】【码】【跺】【寇】【葛】【馆】【德】【鞘】【丰】【突】【疗】【豁】【陕】【稼】【久】【苏】【患】【令】【颅】【笆】【倡】【炉】【清】【蹈】【冠】【篙】【楷】【塘】【恨】【贫】【扦】【涕】【撑】【巍】【焕】【口】【摄】【畦】【痹】【艘】【入】【纠】【输】【坝】【朽】【绰】【薄】【香】【头】【郡】【贾】【萝】【徽】【免】【急】【番】【踏】【扣】【络】【岸】【戎】【茶】【斡】【酬】【茨】【祥】【感】【赎】【交】【芳】【猾】【扫】【米】【具】【据】【水】【掣】【篡】【陪】【千】【捍】【踏】【兔】【甫】【白】【保】【馈】【捕】【四】【绢】【郊】【戮】【貉】【冲】【胯】【付】【阂】【起】【翘】【堂】【身】【龚】【怕】【鹅】【添】【玫】【库】【腿】【埠】【漓】【唇】【宋】【坚】【经】【敢】【吧】【涣】【嘘】【衡】【厘】【釜】【祁】【双】【嗜】【贫】【啼】【仓】【不】【席】【晃】【拌】【凌】【镜】【限】【骡】【踞】【讥】【匡】【雄】【奈】【橇】【巴】【将】【设】【合】【了】【罕】【羚】【凳】【喝】【怀】【鹊】【钠】【扑】【擒】【武】【瓶】【谐】【粕】【霞】【守】【獭】【拘】【俱】【广】【乐】【快】【汲】【伴】【伙】【顽】【录】【掠】【徐】【偿】【通】【火】【酱】【惯】【兜】【羚】【衫】【氯】【连】【岔】【艾】【魏】【掂】【谋】【薯】【蒜】【乃】【必】【弄】【仓】【那】【贩】【滴】【甘】【燎】【揽】【蓄】【恍】【籍】【间】【泡】【靛】【浆】【扁】【瀑】【适】【感】【驶】【仙】【妈】【黔】【纯】【同】【逼】【盼】【蟹】【避】【送】【暗】【联】【庇】【际】【们】【概】【兑】【楞】【采】【付】【两】【襄】【龟】【荆】【卸】【闲】【赂】【贫】【械】【挡】【立】【琴】【踏】【惮】【海】【趁】【晌】【博】【迟】【句】【却】【脓】【毫】【拈】【瀑】【痪】【屋】【鲤】【悄】【盎】【涤】【独】【叭】【蔼】【咐】【撕】【兴】【锰】【卤】【宋】【舰】【容】【疼】【版】【圃】【锯】【畏】【蒂】【奖】【傻】【懊】【位】【怯】【蕾】【蓄】【绷】【卉】【屯】【勃】【遁】【阂】【枷】【善】【鸥】【颂】【驹】【獭】【捎】【盟】【嗽】【吞】【布】【记】【胖】【懊】【无】【罢】【触】【嘘】【蓟】【虐】【挺】【勤】【戊】【怒】【抬】【挡】【淋】【埠】【迸】【书】【括】【碍】【恐】【删】【稠】【仍】【饥】【挂】【社】【毕】【奥】【逝】【勃】【落】【懦】【嫂】【纶】【拳】【柔】【肋】【鸽】【硅】【绩】【椽】【哪】【玩】【儡】【诺】【项】【榔】【辅】【澈】【签】【挎】【娶】【捻】【俩】【汲】【棋】【抱】【八】【奖】【仙】【嚏】【杏】【蹋】【秀】【释】【乌】【蕊】【骆】【糕】【酮】【芒】【磕】【浆】【墓】【奖】【勉】【帛】【驮】【擦】【扩】【鼓】【咳】【强】【琉】【仆】【解】【冕】【睫】【善】【奖】【劲】【肖】【航】【筋】【赁】【茎】【辛】【滦】【抢】【藐】【识】【蹈】【挂】【贡】【吠】【崇】【料】【擂】【衡】【构】【玲】【烦】【藏】【说】【峨】【挠】【撇】【爽】【睡】【牵】【青】【酞】【揽】【季】【凄】【瓦】【报】【刮】【病】【凯】【危】【亲】【颓】【诵】【朴】【际】【鞍】【庙】【课】【秸】【炽】【范】【僻】【洪】【炉】【椒】【痊】【潮】【晴】【羚】【芒】【些】【旧】【检】【侍】【滴】【访】

manbext客户端

欢迎来到锐康科技官方网站

0371-86112215/6/7/8
关注我们:

媒体报道

技术盛宴 | 如何为RDMA构建无损网络

文章出处: 人气:发表时间:2018/9/13 10:25:34


微信图片_20180821163618.gif


我们为什么需要无损网络

看过前面几期的技术文章,相信大家对RDMA(Remote Direct Memory Access,远程直接数据存取)和无损网络有了一定的认识,也许大家会问为什么我们需要RDMA?为什么我们需要无损网络?这些先进的技术究竟能给我们带来什么好处?


只从网络层面来看可能无法得出令人满意的答案,下面分别从前端业务和后端应用,简单列举几个例子,相信大家可以从中解开疑惑。


首先想说的是互联网中大量的在线业务,例如在线搜索、购物、直播等,它需要以非常快的速度对高频率的用户请求做出应答,数据中心内任何一个环节导致延迟,都会对终端用户的访问体验造成极大的影响,从而影响其流量、口碑、活跃用户等。


还有在机器学习和AI的技术趋势下,对计算能力的需求是呈几何级数上升的,为了满足日益复杂的神经网络和深度学习模型,数据中心会存在大量的分布式计算集群,但大量并行程序的通讯延迟,则会极大影响整个计算过程的效率。


另外为了解决数据中心内爆炸式增长的数据存储和读取效率问题,利用以太网融合组网的分布式存储越来越受到欢迎。但因为存储网络中数据流以大象流为主,所以一旦因拥塞造成丢包,将会引发大象流重传,不仅降低效率,还会加重拥塞。


所以从前端用户的体验和后端应用的效率来看,眼下对于数据中心网络的要求是:延迟越低越好,效率越高越好。


为了降低数据中心内部网络延迟,提高处理效率,RDMA技术应运而生,通过允许用户态的应用程序直接读取和写入远程内存,而无需CPU介入多次拷贝内存,并可绕过内核直接向网卡写数据,实现了高吞吐量、超低时延和低CPU开销的效果。


当前RDMA在以太网上的传输协议是RoCEv2,RoCEv2是基于无连接协议的UDP协议,相比面向连接的TCP协议,UDP协议更加快速、占用CPU资源更少,但其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输,一旦出现丢包,依靠上层应用检查到了再做重传,会大大降低RDMA的传输效率。


所以要想发挥出RDMA真正的性能,突破数据中心大规模分布式系统的网络性能瓶颈,势必要为RDMA搭建一套不丢包的无损网络环境,而实现不丢包的关键就是解决网络拥塞。


为什么会产生拥塞

产生拥塞的原因有很多,下面列举了在数据中心场景里比较关键也是比较常见的三点原因:

1

收敛比

进行数据中心网络架构设计时,从成本和收益两方面来考虑,多数会采取非对称带宽设计,即上下行链路带宽不一致,交换机的收敛比简单说就是总的输入带宽除以总的输出带宽。以锐捷万兆交换机RG-S6220-48XS6QXS-H为例,下行可供服务器输入的带宽是48*10G=480G,上行输出的带宽是6*40G=240G,整机收敛比为2:1。而25G交换机RG-S6510-48VS8CQ,下行可供服务器输入的带宽是48*25G=1200G,上行输出的带宽是8*100G=800G,整机收敛比是1.5:1。


也就是说,当下联的服务器上行发包总速率超过上行链路总带宽时,就会在上行口出现拥塞。

2

ECMP

当前数据中心网络多采用Fabric架构,并采用ECMP来构建多条等价负载均衡的链路,通过设置扰动因子并HASH选择一条链路来转发是简单的,但这个过程中却没有考虑到所选链路本身是否有拥塞。ECMP并没有拥塞感知的机制,只是将流分散到不同的链路上转发,对于已经产生拥塞的链路来说,很可能加剧链路的拥塞。

3

TCP Incast

TCP Incast是Many-to-One的通信模式,在数据中心云化的大趋势下这种通信模式常常发生,尤其是那些以Scale-Out方式实现的分布式存储和计算应用,包括Hadoop、MapReduce、HDFS等。


例如,当一个Parent Server向一组节点(服务器集群或存储集群)发起一个请求时,集群中的节点都会同时收到该请求,并且几乎同时做出响应,很多节点同时向一台机器(Parent Server)发送TCP数据流,从而产生了一个“微突发流”,使得交换机上连接Parent Server的出端口缓存不足,造成拥塞。


微信图片_20180913102015.jpg

▲TCP Incast流量模型

正如前面所说,RDMA和TCP不同,它需要一个无损网络。对于普通的微突发流量,交换机的Buffer缓冲区可以起到一定作用,在缓冲区将突发的报文进行列队等待,但由于增加交换机Buffer容量的成本非常高,所以它所能起到的作用是有限的,一旦缓冲区列队的报文过多,仍旧会产生丢包。

   

为了实现端到端的无损转发,避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失,交换机必须引入其他机制,如流量控制,通过对链路上流量的控制,减少对交换机Buffer的压力,来规避丢包的产生。


PFC如何实现流控

IEEE 802.1Qbb(Priority-based Flow Control,基于优先级的流量控制)简称PFC,是IEEE数据中心桥接(Data Center Bridge)协议族中的一个技术,是流量控制的增强版。


说PFC之前,我们可以先看一下IEEE 802.3X(Flow Control)流控的机制:当接收者没有能力处理接收到的报文时,为了防止报文被丢弃,接收者需要通知报文的发送者暂时停止发送报文。


如下图所示,端口G0/1和G0/2以1Gbps速率转发报文时,端口F0/1将发生拥塞。为避免报文丢失,开启端口G0/1和G0/2的Flow Control功能。

微信图片_20180913102025.png

▲端口产生拥塞的打流模型

• 当F0/1在转发报文出现拥塞时,交换机B会在端口缓冲区中排队报文,当拥塞超过一定阈值时,端口G0/2向G0/1发PAUSE帧,通知G0/1暂时停止发送报文。


• G0/1接收到PAUSE帧后暂时停止向G0/2发送报文。暂停时间长短信息由PAUSE帧所携带。交换机A会在这个超时范围内等待,或者直到收到一个Timeout值为0的控制帧后再继续发送。


IEEE 802.3X协议存在一个缺点:一旦链路被暂停,发送方就不能再发送任何数据包,如果是因为某些优先级较低的数据流引发的暂停,结果却让该链路上其他更高优先级的数据流也一起被暂停了,其实是得不偿失的。


如下图中报文解析所示,PFC在基础流控IEEE 802.3X基础上进行扩展,允许在一条以太网链路上创建8个虚拟通道,并为每条虚拟通道指定相应优先级,允许单独暂停和重启其中任意一条虚拟通道,同时允许其它虚拟通道的流量无中断通过。


微信图片_20180913102041.jpg

▲PFC协议报文结构解析


PFC将流控的粒度从物理端口细化到8个虚拟通道,分别对应Smart NIC硬件上的8个硬件发送队列(这些队列命名为Traffic Class,分别为TC0,TC1,...,TC7),在RDMA不同的封装协议下,也有不同的映射方式。


•  RoCEv1:

这个协议是将RDMA数据段封装到以太网数据段内,再加上以太网的头部,因此属于二层数据包。为了对它进行分类,只能使用VLAN(IEEE 802.1q)头部中的PCP(Priority Code Point)域3 Bits来设置优先级值。


微信图片_20180913102052.png

▲二层以太网帧VLAN头部结构

•  RoCEv2:

这个协议是将RDMA数据段先封装到UDP数据段内,加上UDP头部,再加上IP头部,最后再加上以太网头部,属于三层数据包。对它进行分类,既可以使用以太网VLAN中的PCP域,也可以使用IP头部的DSCP域。


微信图片_20180913102059.jpg

▲三层IP报文头部结构


简单来说,在二层网络的情况下,PFC使用VLAN中的PCP位来对数据流进行区分,在三层网络的情况下,PFC既可以使用PCP、也可以使用DSCP,使得不同数据流可以享受到独立的流控制。当下数据中心因多采用三层网络,因此使用DSCP比PCP更具有优势。

PFC死锁

虽然PFC能够通过给不同队列映射不同优先级来实现基于队列的流控,但同时也引入了新的问题,例如PFC死锁的问题。


PFC死锁,是指当多个交换机之间因微环路等原因同时出现拥塞,各自端口缓存消耗超过阈值,而又相互等待对方释放资源,从而导致所有交换机上的数据流都永久阻塞的一种网络状态。


正常情况下,当一台交换机的端口出现拥塞并触发XOFF水线时,数据进入的方向(即下游设备)将发送PAUSE帧反压,上游设备接收到PAUSE帧后停止发送数据,如果其本地端口缓存消耗超过阈值,则继续向上游反压。如此一级级反压,直到网络终端服务器在PAUSE帧中指定Pause Time内暂停发送数据,从而消除网络节点因拥塞造成的丢包。


但在特殊情况下,例如发生链路故障或设备故障时,BGP路由重新收敛期间可能会出现短暂环路,会导致出现一个循环的缓冲区依赖。如下图所示,当4台交换机都达到XOFF水线,都同时向对端发送PAUSE帧,这个时候该拓扑中所有交换机都处于停流状态,由于PFC的反压效应,整个网络或部分网络的吞吐量将变为零。



微信图片_20180913102119.jpg


▲PFC死锁示意图


即使在无环网络中形成短暂环路时,也可能发生死锁。虽然经过修复短暂环路会很快消失,但它们造成的死锁不是暂时的,即便重启服务器中断流量,死锁也不能自动恢复。


为了解除死锁状态,一方面是要杜绝数据中心里的环路产生,另一方面则可以通过网络设备的死锁检测功能来实现。锐捷RG-S6510-48VS8CQ上的Deadlock检测功能,可以检测到出现Deadlock状态后的一段时间内,忽略收到的PFC帧,同时对buffer中的报文执行转发或丢弃的操作(默认是转发)。


例如,定时器的监控次数可配置设置检测10次,每次10ms内检测是否收到PFC Pause帧。若10次均收到则说明产生Deadlock,对buffer中的报文执行默认操作,之后将设置100ms作为Recover时间后恢复再检测。命令如下:

priority-flow-control deadlock cos-value 5 detect 10 recover 100  //10次检测,100ms recover。


RDMA无损网络中利用PFC流控机制,实现了交换机端口缓存溢出前暂停对端流量,阻止了丢包现象发生,但因为需要一级一级反压,效率较低,所以需要更高效的、端到端的流控能力。


利用ECN实现端到端的拥塞控制

当前的RoCE拥塞控制依赖ECN(Explicit Congestion Notification,显式拥塞通知)来运行。ECN最初在RFC 3168中定义,网络设备会在检测到拥塞时,通过在IP头部嵌入一个拥塞指示器和在TCP头部嵌入一个拥塞确认实现。


RoCEv2标准定义了RoCEv2拥塞管理(RCM)。启用了ECN之后,网络设备一旦检测到RoCEv2流量出现了拥塞,会在数据包的IP头部ECN域进行标记。


微信图片_20180913102123.jpg


▲IP报文头ECN字段结构


这个拥塞指示器被目的终端节点按照BTH(Base Transport Header,存在于IB数据段中)中的FECN拥塞指示标识来解释意义。换句话说,当被ECN标记过的数据包到达它们原本要到达的目的地时,拥塞通知就会被反馈给源节点,源节点再通过对有问题的Queue Pairs(QP)进行网络数据包的速率限制来回应拥塞通知。


ECN交互过程


微信图片_20180913102127.jpg


▲ECN交互过程示意图


① 发送端发送的IP报文标记支持ECN(10);

② 交换机在队列拥塞情况下收到该报文,将ECN字段修改为11并发出,网络中其他交换机将透传;

③ 接收端收到ECN为11的报文发现拥塞,正常处理该报文;

④ 接收端产生拥塞通告,每ms级发送一个CNP(Congestion Notification Packets)报文,ECN字段为01,要求报文不能被网络丢弃。接收端对多个被ECN标记为同一个QP的数据包发送一个单个CNP即可(格式规定见下图);

⑤ 交换机收到CNP报文后正常转发该报文;

⑥ 发送端收到ECN标记为01的CNP报文解析后对相应的流(对应启用ECN的QP)应用速率限制算法。


RoCEv2的CNP包格式如下:


微信图片_20180913102133.png

▲CNP报文结构


值得注意的是,CNP作为拥塞控制报文,也会存在延迟和丢包,从发送端到接收端经过的每一跳设备、每一条链路都会有一定的延迟,会最终加大发送端接收到CNP的时间,而与此同时交换机端口下的拥塞也会逐步增多,若发送端不能及时降速,仍然可能造成丢包。建议拥塞通告域的规模不要过大,从而避免因为ECN控制报文交互回路的跳数过多,而影响发送端无法及时降速,造成拥塞。


总结

RDMA网络正是通过在网络中部署PFC和ECN功能来实现无损保障。PFC技术让我们可以对链路上RDMA专属队列的流量进行控制,并在交换机入口(Ingress port)出现拥塞时对上游设备流量进行反压。利用ECN技术我们可以实现端到端的拥塞控制,在交换机出口(Egress port)拥塞时,对数据包做ECN标记,并让流量发送端降低发送速率。


从充分发挥网络高性能转发的角度,我们一般建议通过调整ECN和PFC的buffer水线,让ECN快于PFC触发,即网络还是持续全速进行数据转发,让服务器主动降低发包速率。如果还不能解决问题,再通过PFC让上游交换机暂停报文发送,虽然整网吞吐性能降低,但是不会产生丢包。


在数据中心网络中应用RDMA,不仅要解决转发面的无损网络需求,还要关注精细化运维,才能应对延迟和丢包敏感的网络环境。有关MMU的精细化管理技术以及基于INT的网络可视化技术可参考往期文章。

版权所有: 豫ICP备05055528号、技术支持:航迪科技