原文标题:NSDI'24 | 阿里云飞天洛神云网络论文解读——《LuoShen》揭秘新型融合网关 洛神云网关
原文作者:阿里云开发者
冷月清谈:
技术演进
受限于边缘云机房的离散性和容量,云网络团队重新设计阿里云云网络设施,提出超融合网关「洛神」概念,将公有云 VPC 设施推向边缘。
融合原则
边缘网络场景对小型化和性能提出了双重挑战,洛神网关基于以下设计原则实现融合方案:小型化、业务功能融合和组件资源共享。
Pipeline 折叠
洛神网关采用了创新 Pipeline 折叠技术,将 Tofi no 的四根 PipeLine 折叠为一根,达到性能和表项存储空间的平衡。
报文处理流程
论文详细分析了三类业务的报文处理流程:域内 VM 互访、来自互联网访问负载均衡云服务,以及来自 VM 访问负载均衡云服务。
有状态流量
洛神网关在 CPU 上支持有状态网元,如 SLB,并提供基于 FPGA 的扩展以加速对云服务流量的负载均衡处理。
控制面
洛神网关通过容器化和绑核等方式,在 CPU 上隔离不同角色的进程,保证控制平面和数据平面的稳定运行。
实验结果
测试结果表明,洛神网关在 12 个端口满载 1.2Tbps 流量的情况下,VM 互访、VM 跨地域和 VM 访问 IDC 等业务吞吐量均达 1.2Tbps,而 VM 访问负载均衡云服务业务吞吐量可达 200Gbps,延迟保持在 3-4 微秒的较低水平。
怜星夜思:
2、洛神网关在边缘云场景中有哪些潜在应用?
3、洛神网关的未来发展趋势可能会是什么?
原文内容
引言
论文详解
论文背景
方案选择
-
去除了单独用于网络设施的硬件,降低了成本,降低了空间占用;
-
可直接复用软件版本的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。
总结