NSDI'24 | 阿里云飞天洛神云网络论文解读——《LuoShen》揭秘新型融合网关 洛神云网关
引言
论文详解
论文背景
方案选择
去除了单独用于网络设施的硬件,降低了成本,降低了空间占用;
可直接复用软件版本的GW和LB代码,适配工作量小,快速打包进小型化边缘云上线。
全球第一台基于ServerSwitch的边缘融合云网关。 在数据平面上通过创新的流水线折叠layout到达了性能和表项存储空间的完美平衡。 在控制平面,基于BGP路由进行组件间的引流,并同时具备了故障切换和负载均衡的能力。 (实际部署一年,取得的效果)成本降低75%,空间占用降低87%,在边缘场景对于ecs2local业务,提供约3-5us时延,1.2Tbps的吞吐量。
方案实现:融合的原则
小型化:要降低边缘网络设施占用的机柜空间,在机柜中给物理服务器预留更多的空间,保证租户可以创建更多的虚拟机;
不同的云网络业务share相似的表项,且在边缘场景下,每个表都较小,可以进行融合。例如在之前的单角色网关中,阿里云云网络已经实践了将域内VPC内和VPC间访问的业务都用VGW来处理;将跨域访问和IDC访问的业务都用TGW来处理。实际上,VGW和TGW同样共享VXLAN路由表,可以将这两个网关进一步融合。此外,考虑到IDC访问时的CSW主要实现VXLAN和VLAN的转换,可以进一步将这部分功能与VGW、TGW融合在一起,形成一个融合的网元CGW;
由于Tofino芯片的吞吐量极高,可以将用于处理Underlay流量的Switch和处理Overlay流量的网元融合在一起,进一步塞进Tofino的Pipline中;
考虑到边缘场景的流量有限,对于原来基于单独x86服务器实现的网元,可以将它们放到x86的多个CPU core上。但不用害怕CPU单核打爆的问题,因为突发大流量会用Tofino芯片处理,XGW和SLB的流量都可以通过CX5进行限速,不会出现软转发被打爆的问题;
对于一些网元,如SLB,既需要维护大状态,又需要高速处理,无论放在CPU或Tofino都不合适,可以使用FPGA进行承载(FPGA具备大容量的HBM和快速的处理能力);
原来的LSW负责实现流量向各个网元的分发,同时将其放入Tofino的Pipeline中;考虑到Tofino既可以实现流量绕回,又可以将流量向其他硬件转发,所以可以基于Tofino来实现流量的下一跳分发。此外,这种架构沿用了中心云的架构,多活保证健壮性,单组件挂掉可以切换;
可以基于CPU实现软件网元,并将各种组件的控制平面也放到CPU上,但需要进行严格的资源隔离(使用Docker等云原生环境)。
Pipeline 折叠
将原来的四根Pipeline折叠成了一根,吞吐量降为1.6Tbps,且不同业务会竞争流水线资源;
大量Tofino的端口被用作内部loopback,无法挂载更多的NC。
报文处理流程
对于域内VPC间的VM互访业务, 流量会穿过Tofino的流水线(在CGW组件和SW组件上处理),然后被转发到另一个VPC中的目的VM上。
对于来自Internet经过SLB负载均衡到VM的业务,流量会穿过Tofino的流水线(在IGW组件和SW组件处理),然后被SW转发到x86上的SLB网元处理。当查找到需要送往的目的VM时,流量还需要重新穿过Tofino的流水线,经过SW组件的处理,然后被转发到同一VPC的目的VM上。这个场景是租户在自己的VPC内部署了SLB对自己的业务进行负载均衡。
对于来自VM经过SLB+负载均衡到VM的业务,流量会穿过Tofino的流水线(在CGW组件和SW组件处理),然后被SW转发到FPGA上的SLB+网元处理。当查找到需要送往的目的VM时,流量还需要重新穿过Tofino的流水线,经过SW组件的处理,然后被转发到另一个VPC的目的VM上。这个场景是租户访问某些云服务,由于云服务会处理来自多个租户的请求,因此SLB+的处理性能要求较高,使用FPGA进行加速。
有状态流量
控制面
1)软件数据平面的高速转发行为不会影响控制平面表项的接收和下发
2)多个组件表项下发相互不影响
一方面,各组件利用Docker实现,并进行绑核处理,不同组件分配不同的核,避免不同组件之间CPU资源的竞争;
另一方面,对于控制平面和数据平面均在同一个Docker中的组件,进行更细粒度的绑核,一部分核给控制平面,一部分核给数据平面,避免同一组件的控制平面和数据平面对CPU资源的竞争;此外,因为CPU资源有限,在系统设计时,让部分组件共享CPU资源(例如CGW agent、IGW agent),为保证达到功能和CPU资源之间的平衡,我们根据业务对CPU时间片使用情况,把CPU时间片使用较多的业务和CPU时间片使用较少的业务绑定在相同的核处理,充分利用CPU资源。
实验结果
对于VM-VM (same VPC)、VMVM(different VPCs)、VM-Cross-region-VM和VM-IDC这些业务,吞吐量均可以达到1.2Tbps,这是因为这些业务的数据包只需经过Tofino的处理,并且处理仅涉及头字段内容的修改;
对于VM-Internet和Internet-VM这两种业务,虽然数据包只需经过Tofino的处理,但是处理会涉及到拆头和加头的操作,影响吞吐量。具体地,VM-Internet业务的数据包经过Tofino处理,会进行拆(8(VXLAN)+20(IP)+8(UDP)=36Bytes)的操作,导致吞吐量下降,小于1.2Tbps,而Internet-VM业务的数据包经过Tofino处理, 会进行加头(8(VXLAN)+20(IP)+8(UDP)=36Bytes)的操作,导致吞吐量增加,超过1.2Tbps,但是受限于Tofino的12个端口转发性能瓶颈,实际的吞吐量也是接近1.2Tbps;
对于VM-LB-Service业务, 吞吐量接近200Gbps,这是因为该业务的流量需要送到FPGA处理,而FPGA与Tofino之间是通过两个100G的端口直接相连的;
对于Internet-LB-Service业务, 吞吐量仅为78Gbps,这是因为该业务的流量需要送到CPU处理,而CPU与Tofino之间是通过两个100G的CX5网卡相连的,并且只分配了部分CPU core用作SLB业务流量的转发。
对于VM-VM (same VPC)和VMInternet这两种业务,流量仅经过Tofino处理,需要经过3个Pipeline,产生的时延约为3.2us;
对于VM-VM(different VPCs)、VM-Cross-region-VM和VM-IDC这些业务,流量仅经过Tofino处理,但是这些流量在经过Ingress Pipe 0处理后,需要在TM中Resubmit回去,再经过一次Ingress Pipe 0,然后再经过2.5个Pipeline,产生的时延约3.5us;
对于Internet-VM业务, 流量仅经过Tofino处理,需要经过4个Pipeline,产生的时延约为4us;对于VM-LB-Service业务,流量在经过Tofino的3个Pipeline后,被送往FPGA处理,处理完后,还得再经过Tofino的3个Pipeline,产生的时延约为8.5us;
对于Internet-LB-Service业务,流量在经过Tofino的3个Pipeline后,被送往x86处理,处理完后,还得再经过Tofino的3个Pipeline,产生的时延约为26.5us。
总结
微信扫码关注该文公众号作者