引言

网络系统设计和实现领域顶会 NSDI‘24于4月16-18日在美国加州圣塔克拉拉市（SANTA CLARA, CA, USA）举办，来自世界各地的研究人员、开发工程师、系统架构师等齐聚一堂，分享他们的最新的研究成果并交流设计思考，共同推进网络系统领域的发展。

阿里云飞天洛神云网络（下文简称洛神网络）领域两篇论文<LuoShen: A Hyper-Converged Programmable Gateway for Multi-TenantMulti-Service Edge Clouds>和<Poseidon: A Consolidated Virtual Network Controller that Manages Millions of Tenants via Config Tree>

阿里云飞天洛神云网络平台是阿里云飞天操作系统的三大核心组件之一，支撑了整个飞天操作系统中的网络服务。在本文中，我们将详细介绍在边缘场景高性能云网关<LuoShen>的技术演进思路。

论文详解

论文背景

在过去十年里，公有云为客户提供了快速弹性构建业务的能力，通过规模化运营取得了巨大的商业成功。随着客户对时延和数据安全性需求的增多，云厂商尝试在贴近用户的地域构建边缘云，将公有云的基础设施延伸到边缘。例如一些客户对时延有着极致的需求（如游戏、制造业、高频交易）；一些客户出于安全的考虑，希望数据存储在本地；一些客户的数据则较难迁移到中心；电信厂商也正在尝试云化他们的电信设施。然而，不同于公有云，边缘云的机房站点分布离散、数量众多，但因为仅仅服务邻近的客户，每个站点的容量较为有限。如果直接将公有云的基础设施迁移到每个边缘云机房，则会面临成本和空间两方面的问题。

数据中心网络架构

为解决上述问题，飞天洛神云网络提出超融合网关<LuoShen>，基于包含Tofino、FPGA和CPU的ServerSwitch新型硬件形态重新架构阿里云的云网络设施，将整个公有云中的VPC设施push到了边缘的机柜中。

<LuoShen>的设计目标包括：小型化设备（降低边缘网络占用机柜空间）、多合一（在一台设备里集成所需要的功能）、低成本（降低边缘网络的成本）、稳定性（避免发生单核打爆风险）以及根据边缘场景灵活地按需组合网关功能，并尽可能地复用中心网络避免重复开发。

边缘融合网络架构

方案选择

在公有云边缘化的需求刚被提出时，阿里云就在尝试寻找合适的方案，考虑到边缘云场景流量相对较低，为了降低小型边缘云的起建成本和设备总大小，阿里云云网络团队初期尝试将中心云的多个网关功能融合在x86服务器中，以少量XGW网关结合LB功能（处理Overlay流量）外加ToR交换机（处理Underlay流量）的形式服务本地云和云盒。

这种方案的好处是：

去除了单独用于网络设施的硬件，降低了成本，降低了空间占用；
可直接复用软件版本的GW和LB代码，适配工作量小，快速打包进小型化边缘云上线。

然而，部署经验表明在边缘云中同样存在大带宽和大单流的场景，出现了网关水位突破上限和大单流将单核打爆的情况。在本地云中，曾经出现过租户将边缘云作为流量就近接入公有云的PoP点，将大流量引流到本地云中，然后上传到公有云中，因此出现了大带宽的场景；在云盒中，曾经出现过租户在IDC中部署的大量IoT设备的流量汇聚到GRE隧道大单流上云的场景，在这两种场景下XGW的软转发方案达到了性能的瓶颈。

综上，边缘云的网络方案的难点在于需要在狭小的空间内提供足够的性能，同时考虑压缩成本。基于上述考虑，阿里云云网络提出了洛神云网关的超融合方案，这个方案的主要创新点包括：

全球第一台基于ServerSwitch的边缘融合云网关。
在数据平面上通过创新的流水线折叠layout到达了性能和表项存储空间的完美平衡。
在控制平面，基于BGP路由进行组件间的引流，并同时具备了故障切换和负载均衡的能力。
（实际部署一年，取得的效果）成本降低75%，空间占用降低87%，在边缘场景对于ecs2local业务，提供约3-5us时延，1.2Tbps的吞吐量。

方案实现：融合的原则

在边缘场景，客户既希望得到边缘的低延迟优势，又不想妥协VPC的业务能力。例如，边缘云同样有跨VPC和跨域互访的需求，也会频繁和IDC、公网以及远端的公有云进行交互。云网络需要在一台设备里集成所有需要的功能，提供与公有云中VPC网络设施等价的业务处理能力，包括东西向Underlay流量交换，公网、IDC、网元Underlay流量引流，负载均衡，域内、域间VM互访，IDC上云/下云，VM公网访问等等。

基于这个前提，阿里云云网络制定了下面的设计原则

小型化：要降低边缘网络设施占用的机柜空间，在机柜中给物理服务器预留更多的空间，保证租户可以创建更多的虚拟机；
不同的云网络业务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 折叠

Tofino硬件设备包含四根Pipeline，每个Pipeline分为Ingress Pipe和Egress Pipe，Ingress到Egress需要穿过TM，每根Pipeline对应16个端口，总共64个端口。

在选定洛神云网络的Pipeline折叠方案之前，也设计有其它备选折叠方案——针对CGW和IGW进行了两组Pipeline的分别折叠，不足之处是：两个Pipeline的流量可能不均衡，两个Pipeline的表项占用可能不均衡，SW需要复制两份，有的业务需要引流。

另外，选定的折叠方案考虑了最小化移植代价，将原来IGW的Pipeline进行了整体平移嫁接到了融合网关中，而备选折叠方案则需要在移植过程中添加较多的二次开发工作。

两种不同的折叠方案（左：Luoshen选定方案）

通过流水线的多次折叠（2或3次loopback操作），将CGW、IGW和SW顺序排布在单根折叠后的Tofino流水线中（考虑到这些组件中表项的数量较多，size较大，无法存储在单个Pipe中，因此这些组件至少都跨过了两个Pipe）。所有业务都会经过Tofino内的串行Pipeline，并且业务在Tofino中所走的路径不一致，会出现分支。

阿里云云网络的Pipeline存在两处分支点（如上图所示）：一个是Ingress Pipe 1处的IGW分支，主要用来区分SNAT和DNAT的业务；另一个在Ingress Pipe 3处的SW分支，主要用来选择Underlay转发的下一跳（去往公网、VM、IDC、CPU or FPGA）。

拿常见的云业务为例，比如域内VPC内VM互访的业务，流量在Tofino中会走CGW (Ingress Pipe 0) -> CGW (Egress Pipe 1) -> IGW(Ingress Pipe 1) -> IGW (Egress Pipe 3) -> SW (Ingress Pipe3) -> SW (Egress Pipe 0)的路径。而从Internet访问VM的业务，流量在Tofino中会走CGW (Ingress Pipe 0) -> CGW(Egress Pipe 1) -> IGW (Ingress Pipe 1) -> IGW (Egress Pipe 2) -> IGW (Ingress Pipe 2) -> IGW (Egress Pipe 3) -> SW (Ingress Pipe3) -> SW (Egress Pipe 0)的路径。

<Luoshen>现有的流水线布局也存在一些潜在问题：

将原来的四根Pipeline折叠成了一根，吞吐量降为1.6Tbps，且不同业务会竞争流水线资源；
大量Tofino的端口被用作内部loopback，无法挂载更多的NC。

考虑到Tofino芯片的转发能力本来就很强，且在云盒场景中，机柜内主机数量本来就不多，且流量有限，Luoshen目前的方案刚好是合适的。此外，在实际部署时，阿里云云网络也基于两台网关设备做热备份，进一步增加了挂载NC的数量和吞吐量。对于本地云场景，除了直挂NC外，还可以通过额外的交换机进行旁挂，通过交换机进一步地扩展挂载NC的数量。同时，通过增加Luoshen网关到4台或8台，进一步扩展网关的处理性能。

报文处理流程

这里分别描述三种业务的包路径，展示融合网关的处理细节（如下图所示）。

对于域内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进行加速。

有状态流量

融合网关中，在CPU上阿里云云网络提供了对有状态网元的支持，例如SLB等。通常，来自公网访问云服务的流量，相关数据包首先会经过IGW处理，然后送往SLB负载均衡选择合适的RS，最后将数据包发送至相应的RS访问云服务。Tofino作为整个融合网关流量的出入口，来自公网访问云服务的流量需要从Tofino进入，首先到达CGW组件的处理逻辑，根据Dst IP查找CGW Classify表，会跳过CGW后续处理逻辑，直接进入IGW组件的处理逻辑，同样根据Dst IP查找IGW Classify表，得知为来自公网访问云服务的流量，需要经过IGW组件的处理，进一步查找DNAT表，得到SLB的VIP，并对数据包进行VXLAN封装（其中Outer Dst IP为SLB的VIP），接着进入SW组件的处理逻辑，根据Outer Dst IP查找路由表，将数据包送至CPU。

此外，在阿里云云网络的系统中，FPGA作为扩展，可支持有状态网元的快转加速。对于云服务访问来说，存在Internet访问和VM访问两种情况，两种情况流量规模并不相同。因此考虑规模较小的Internet访问云服务的流量使用CPU上的SLB网元进行处理，而对于规模较大的VM访问云服务的流量，由FPGA硬件加速的SLB进行处理。

来自VM访问云服务的流量同样需要从Tofino进入，首先到达CGW组件的处理逻辑，根据Outer Dst IP和VNI查找CGW Classify表，得知为来自VM访问云服务的流量，需要经过CGW组件的处理，进一步查找VXLAN路由表和VMNC映射表，得到SLB+的VIP，并修改数据包的OuterIP（其中Outer Dst IP改为SLB+的VIP），然后进入IGW组件的处理逻辑，根据Outer Dst IP和VNI，查找IGW Classify表，会跳过IGW后续处理逻辑，接着进入SW组件的处理逻辑，根据Outer Dst IP查找路由表，将数据包送至FPGA。

控制面

融合网关中，在CPU上需要承担多个角色的实现，比如多个组件（例如IGW、CGW）的控制平面（这些控制平面需要负责接收远端控制器的表项推送，并作为接口处理模块，将表项通过驱动下发到硬件或软件的数据平面）、数据平面业务的转发（例如XGW、SLB）。

虽然各个角色共享CPU资源，但为保证

1）软件数据平面的高速转发行为不会影响控制平面表项的接收和下发

2）多个组件表项下发相互不影响

3）多个组件的软件数据平面转发相互不影响

需要对不同角色的进程进行资源隔离。具体地，

一方面，各组件利用Docker实现，并进行绑核处理，不同组件分配不同的核，避免不同组件之间CPU资源的竞争；
另一方面，对于控制平面和数据平面均在同一个Docker中的组件，进行更细粒度的绑核，一部分核给控制平面，一部分核给数据平面，避免同一组件的控制平面和数据平面对CPU资源的竞争；此外，因为CPU资源有限，在系统设计时，让部分组件共享CPU资源（例如CGW agent、IGW agent），为保证达到功能和CPU资源之间的平衡，我们根据业务对CPU时间片使用情况，把CPU时间片使用较多的业务和CPU时间片使用较少的业务绑定在相同的核处理，充分利用CPU资源。

实验结果

融合网关将多种组件（Tofino、FPGA和x86）耦合在一起，能够承载多种业务。根据业务的特性，将不同业务放在不同组件处理，充分利用融合网关的资源。由于不同组件处理性能不同，导致不同业务的流量通过融合网关的吞吐量也不同。

阿里云云网络对几种典型的业务进行了吞吐量测试，在使用测试仪把融合网关的12个端口均打满100G流量(共1.2Tbps)的情况下：

对于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业务流量的转发。

此外，不同业务的流量在融合网关中所走的路径不一致，产生不同的时延。阿里云云网络对几种典型的业务进行了时延测试，packet size设置为512bytes：

对于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。

由上述结果可知，对于仅在Tofino中处理的业务，产生的时延差不多，保持在一个较低的水平，大约为3-4us。对于需要送往FPGA或x86处理的业务，产生的时延不仅要考虑两次经过Tofino的3个Pipeline的时间，还需要考虑在FPGA或x86处理的时间，相对较大。

总结

洛神云网关将整个公有云VPC设施融合进2U的机箱中，大大降低了公有云网络设施部署的成本和机柜空间占用，能够将更多的成本和机柜空间预留给租户的算力设备。接近一年的部署经验表明，洛神云网关在保留完整公有云网络功能的前提下，将公有云网络组件的成本降低了75%，机柜空间降低了87%，并保证了单个网关1.2Tbps的性能输出，展示了良好的技术竞争力。

技术始终是为业务服务的，随着业务的发展，特定时期的技术也会遇到问题，特别是在Tofino停止演进的背景下，阿里云云网络将会持续探索云网关在未来的技术形态

NSDI'24 | 阿里云飞天洛神云网络论文解读——《LuoShen》揭秘新型融合网关 洛神云网关

NSDI'24 | 阿里云飞天洛神云网络论文解读——《LuoShen》揭秘新型融合网关洛神云网关