NSDI'24 | 阿里云飞天洛神云网络论文解读——《Poseidon》揭秘新型超高性能云网络控制器

引言

网络系统设计和实现领域顶会 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>入选，这是洛神网络首次亮相并中稿NSDI，这代表洛神网络系统性创新能力再次得到领域专家广泛认可。

本文解读的论文<Poseidon: A Consolidated Virtual Network Controller that Manages Millions of Tenants via Config Tree>是由洛神网络团队与浙大合作的论文，Poseidon（波塞冬）首次向学术界披露了虚拟网络控制器的面临设计挑战，着重展示了随着云网络业务丰富性和用户规模的增加带来的各种部署问题。

论文系统介绍了云网络控制器为支持超大规模、超高弹性变配需求做出的一系列技术提升，以及部署多年的经验，系统的创新性和有效性被领域专家广泛认可。经过对其他Top5云厂商的相关性能进行测试，应用了波塞冬平台的阿里云性能远超其他厂商。我们启用数百个EIP时的完成时间比运行相同网络配置任务的供应商A（Top 5）和供应商B（Top5）分别小了1.8倍至55倍和2.6倍至4.8倍。

|| 注：NSDI是USENIX协会在网络系统设计和实现领域的顶会之一，与SIGCOMM并列居于计算机网络和系统研究领域会议之首，被计算机学会（CCF）评为推荐A类会议，Core Conference Ranking也给予A级别评价，具备极高的学会价值和影响力。

波塞冬平台作为阿里云飞天洛神云网络SDN控制器的底座，支撑了VPC、CEN、SLB、EC、NAT、PrivateLink等多款网元产品的构建，帮助用户构建超大规模云上网络以及提供极致弹性网络能力：

首先，波塞冬的设备管理服务，管理了百万级的不同形态不同功能的设备，包括裸金属、ECS、容器等形态，以及网关、网元、交换机等功能。这些设备通过统一的agent接入到波塞冬，进行生命周期和配置的管理。

其次，波塞冬的配置管理服务，使用基于有向无环图的通用配置模型，管理阿里云网络中海量租户的配置数据。然后通过基于分布式缓存的高性能配置计算引擎，可以快速验算出需要下发给设备的配置，以实现对用户调用的迅速响应。

最后，波塞冬设备代理服务，使用高吞吐低时延的通用配置下发通道，将配置下发给海量异构的设备。

当前，波塞冬为云网络的极致性能提供了保障：网卡插拔性能达到3k tps，单vpc 300w eni的超大规组网能力。同时，还提供了大规模网络路由快速收敛的能力，每秒可以完成3000条路由的收敛。

一、论文详解

论文背景

当今的云虚拟网络一般常由多个独立的控制器管理，这些控制器负责配置、监控和恢复云虚拟网络中的各个服务，如VPCs（虚拟私有云）、VMs（虚拟机）等。如图1所示，虚拟网络配置的工作流程一般包含以下三步：

1.1 租户意图映射到云控制API

当租户尝试配置他们的虚拟网络（例如，虚拟机的创建/释放，拓扑结构变化）时，他们使用云供应商提供的Cloud Control API来 “描述” 他们的意图。API是租户创建、读取、更新和删除他们的虚拟资源（如VMs）的标准接口。不同的供应商提供不同的云控制API套件。以VPC配置为例，在图1中，租户意图 “在VPC1中创建带有公共地址EIP1的VM4” 可以通过两个云控制API组合实现，分别是 “在VPC1中创建VM4” 和 “将EIP1分配给VM4”，这些API被输入到虚拟网络控制器中以便进一步处理。

图1 虚拟网络配置流程

1.2 设备配置changeset计算

在接收到租户的API调用后，控制器需要计算是否需要在基础设施上更新配置。这个过程包括以下步骤：

1. 识别所有依赖关系：以在VPC1中创建VM4为例（见图1）；因为VM4属于特定的VPC，要创建VM4，需要先确定VM4所属的VPC——即VPC1；此外，还需要识别VPC1的依赖配置——如ACL规则和路由表，这个步骤是通过执行SQL查询完成的；在这个过程中，会查询许多表，例如VPC-ACL、VPC-VM等等。
2. 确定托管虚拟网络设备的物理机器，任何虚拟网络设备都托管在物理机器上。在图1中，VM4由服务器2托管。
3. changeset计算：执行完步骤1后，可以知道一个API调用所需要的配置；通过步骤2，可以知道物理服务器上现有的配置。如果步骤1中的配置已经存在于物理服务器上，则不对物理服务器应用changeset；相反，两者之间的差异会被推送到物理服务器上。

在我们之前的控制器实现中，对于每个云控制API，我们编写了大量的SQL代码以及if-else控制块来执行changeset计算。随着设备数量、表大小和if-else逻辑的增长，changeset计算所耗的时间迅速增加。

1.3 虚拟网络设备配置

计算出的changeset需要被推送到虚拟网络设备。例如，在图1中，“在VPC1中创建VM4” 的意图最终被转化为以下设备配置：将PIP和VPC ID在vSwitch上进行配置，以便实现VM通信和VXLAN隧道封装；VPC的路由和ACL也被配置到vSwitch上，以规范VM流量；VM与服务器之间的映射关系被下发到vGateway上，以便对访问该VM的流量进行路由。除此之外，在生产环境中，我们需要处理不同型号和类型的硬件设备，例如基于x86的vGateway或基于tofino的vGateway。因此，虚拟网络控制器需要确保翻译后的配置能够及时且正确地配置在这些异构设备上。

二、挑战

根据多年的部署经验，阿里云云网络发现管理和配置大规模云虚拟网络面临以下挑战：

2.1 北向API调用和南向设备的快速增长

控制器需要处理由云客户、云网络运营商等产生的大量网络配置API调用。在2022年，我们的云控制器每天处理约17 Trillion个API调用。更糟糕的是，需要管理和配置的虚拟网络设备数量也在急剧增加。在阿里云中，单个ACL规则的变更可能导致跨10万台服务器的配置更新。

2.2 更复杂的查表逻辑和更大的表

虚拟网络服务（如VPC）通常依赖于其他服务（如ACL和路由）。在配置虚拟网络时，控制器需要查询与目标服务及其依赖服务相关的数据库。由于多年来服务数量的急剧增加，依赖关系变得十分复杂，以至于每个API调用的处理也变得更加耗时。此外，每个数据库中表的大小也随着用户数量和资源密度的膨胀而急剧增加，这使得API解析变得更加耗时。阿里云网络的经验表明，由于这两个因素，一年内，处理一个API调用的P90完成时间几乎翻倍。

2.3 云原生应用加剧了控制器性能要求

云原生应用需要极高的吞吐量来并发创建/删除资源，这使得控制器性能需求比传统基于控制台的网络配置有了大幅提升。例如，为了处理热点事件期间用户访问量的激增，社交媒体应用要求即使是成千上万的后端实例创建也应该在极短的时间内完成，否则业务可能会由于后端处理能力不足而出现中断。

2.4 管理独立控制器的高OpEx

为了确保各种服务的敏捷性和迭代开发，我们为每种业务构建并维护独立的控制器（与Andromeda采用相同的方法）。在过去几年中，随着网络服务的增长，控制器的数量激增至50多个，这些都需要由不同的业务团队进行维护，使得我们的OpEx大幅增加。

三、系统简介

图2 波塞冬系统架构

为了应对这些挑战，阿里云云网络提出了波塞冬——一种虚拟网络控制器，它可以管理拥有数百万租户的大规模云网络，并满足用户超高并发以及超短完成时间要求的API调用，它包含以下5个关键设计：

3.1 部分合并架构

为了减少开发和维护多个专用服务控制器的成本，波塞冬引入了一种分层设计，将不同业务控制器之间共享的逻辑合并到一个统一控制器中，如上图2所示。统一之后，可以将大量的工作统一纳管，由一个团队进行开发维护，极大地减少了我们的维护和开发成本。

3.2  Trident：与业务和设备无关的抽象

为了服务于统一的控制器架构，阿里云云网络提出了一种新的抽象方案——Trident，其具有与业务和设备无关的抽象能力。具体来说，基于Trident抽象，可以将逻辑各异的业务API对异构的底层设备的配置过程抽象成相同的处理逻辑。

3.3 高性能changeset验算方案

在有了Trident之后，changeset验算变得不再与业务和设备相关，从而可以集中力量进行相关性能的优化。阿里云云网络提出了基于树的changeset验算方案以及分布式缓存的高性能changeset计算引擎，使这一步骤不再是整个控制器的性能瓶颈。

（注：Trident抽象方法和前沿的高性能changeset验算方案将在NSDI论文中详细介绍）

四、部分合并架构

在本节中，首先讨论如何将多个控制器的所有功能合并成一个大控制器的问题；然后，介绍波塞冬采用的部分合并方案。

4.1 完全合并控制器的问题

为了减少多个控制器的开销，自然会考虑将它们的功能合并到一个大控制器中；然而，完全合并有重大的成本压力。在云上，每个业务的控制器都会为了满足不断变化的服务要求而快速迭代。在每次迭代上线之前，都需要对所有相关API及其参数进行全面的控制器测试。假设有x个控制器，每个月每个控制器迭代次，并且需要覆盖个测试用例才能上线，那么总测试成本是。相比之下，在控制器完全合并之后，迭代频率将是每个控制器迭代频率的总和。此外，在每次迭代中，所有测试用例都需要被检查，总测试成本增长到，这会阻碍云服务的快速迭代。

4.2 部分合并

完全合并的成本很高，但是控制器的某些部分是与服务无关的，可以在不产生高成本的情况下进行合并。具体来说，在控制器的北向接口，API解析逻辑与服务强相关，需要不断经历快速迭代。在中间部分，尽管不同API的changeset计算可能涉及不同表查询顺序的编排，但底层表查询机制却非常相似。在南向接口，控制器需要与设备交互。与不同设备交互的代码通常分享大量通用逻辑，如生命周期管理。此外，与服务迭代频率相比，设备更新频率通常要低得多，这使得南向逻辑更加稳定。

基于上述观察，为了在北向接口保持云服务灵活的迭代能力，并减少维护每个控制器中多套相似逻辑的开销，阿里云云网络对每个控制器与服务无关的部分进行了部分合并。具体来说，我们在中间层建立了一个与服务无关的抽象层，提供了一组原子操作，使得可以使用这些原子操作灵活地编排多样化的北向服务需求。

过去的控制器开发需要编写SQL + if-else来查询与云资源和设备相关的表，这对开发者对云网络机制的理解提出了高要求。有了这个新的抽象，开发者只需将API解析为这些既与服务无关又与设备无关的原子操作。在这个抽象层之下，阿里云云网络合并了不同控制器对changeset计算和虚拟网络设备配置的实现，以减少重复的开发和维护成本；如上图2所示，由一个统一的控制器接管所有业务的changeset验算帮助我们集中力量进行性能优化，而不像之前由各个控制器团队分别进行质量不一的优化。

实验结果

对于控制器来说，关键性能指标是其并发处理能力和相应的完成时间。由于通过水平扩展可以增强无关API调用的并发处理能力，我们关注的是相关API调用的处理性能。具体来说，阿里云云网络通过实验测量阿里云和Vendor A（Top 5）、Vendor B（Top 5）在公共云服务中两个最广泛使用的API的并发能力，即对同一VPC中的虚拟机启用和禁用EIP。

选择这两个API有两个特定的原因：

• 首先，这两个API使我们能够精确地衡量控制器处理一个API调用所需要的时间，排除任何在无关模块上花费的时间（比如使用虚拟机创建API时发生的虚拟机启动时间）。
• 其次，这两个API调用占我们为客户提供的1200个API中的10%，是主要的API。

利用主要云供应商提供的云控制API接口，以不同的TPS（每秒事务数）发起API调用，通过记录成功（用于测试启用EIP）或不成功（用于测试禁用EIP）的ping到这些EIP所用的时间，获得P50、P90和P99的完成时间。需要注意的是，计时从Vendor A、Vendor B和阿里云的控制器接收到API调用（返回成功的令牌，代表控制器收到API调用的确认）开始，这有效地消除了传输延迟对测量的影响。

图3 “启用EIP”的端到端完成时间对比

图3展示了启用EIP的P50、P90和P99完成时间。正如图中所示，Vendor A和Vendor B的完成时间分别是波塞冬的1.8~55和2.6~4.8倍。此外，波塞冬的系统在高并发场景下表现出更好的稳定性。即使在400TPS的情况下，波塞冬的P50仍然稳定在1.3秒（只测试Vendor B在200TPS以下的性能，是因为当尝试300TPS时，发生了不支持的错误提示）

此外，值得注意的是，在400TPS测试期间，Vendor A的大部分完成时间都在30秒以下。然而，有8个特定案例中启用EIP的过程超过了300秒。因此，Vendor A的P99远高于波塞冬（大约55倍）。这一观察表明，Vendor A的控制平面在高TPS场景下出现了不稳定性。

图4 “禁用EIP”的端到端完成时间对比

图4展示了在不同TPS（每秒事务数）下禁用EIP的完成时间。在禁用EIP的情况下，与波塞冬相比，Vendor A和Vendor B的完成时间分别是1.6~12倍和1.3~2.5倍。与Vendor A相比，波塞冬受TPS的影响较小。Vendor A的P50、P90和P99大幅增加（分别约为最低值的8倍、15倍和16倍）。同时，波塞冬的P50、P90和P99仅经历了轻微的增加，增加率分别为1.02倍、1.9倍和3.1倍。Vendor B的P50、P90和P99在所有测试中保持稳定，但它仍然无法测量超过200TPS的数据。此外，在较低的TPS下，Vendor A的性能优于Vendor B。

对于Vendor A来说，启用EIP的完成时间（如图3所示）高于禁用EIP的时间；而对于波塞冬和Vendor B来说，情况正好相反。在我们的云中执行启用和禁用EIP时，服务器和网关都需要配置。在启用EIP的情况下，两个设备都必须成功配置才能成功ping通。而在禁用EIP的情况下，当任一设备被配置后，就能无法ping通。因此，在阿里云中，禁用EIP的完成时间小于启用EIP的完成时间。

由于控制器的通用逻辑已被波塞冬统一控制器接管，因此与服务相关的控制器专注于将API转化为Trident操作，这导致控制器的代码行数（Lines of Codes，LOC）显著减少。如表2所示，代码行数的减少率为22%至41%，同时也意味着运营支出（OpEx）的下降。

表1 各种控制器接入波塞冬后代码减少量

此外，由于控制器的开发不再需要关注许多通用功能（例如，changeset计算和推送、一致性检查等），开发成本也得到了实质性的降低。通过比较两个具有相似业务逻辑的负载均衡控制器（LB controllers）的开发过程，我们发现开发成本减少了一半（在没有波塞冬统一控制器的情况下开发一个控制器，需要6人月的工作量，编写了66K行代码；而有了波塞冬，人力工作量减少到3人月，只需要编写30K行代码）。

需要注意的是，运营支出和开发成本的减少并没有增加到波塞冬上，因为波塞冬统一控制器的代码行数仅约150K，这比总的代码行数减少要小得多。

总结与展望

波塞冬控制器作为阿里云飞天洛神云网络连接用户和基础设施的关键组件，满足了用户对网络控制的高性能需求。云网络控制器历经多年，发展到今天离不开整个研发团队的一起努力，更离不开客户的信任和支持，客户的需求始终是产品演进的源动力。希望云网络在服务客户过程中积累的这些宝贵经验和技术创新能够对学术界、工业界有所启发，洛神网络也不会停止演进的步伐，继续为客户提供更广泛的连接、更可靠的网络。

在下一阶段，洛神网络将朝着下面的目标进行努力，为用户提供更好的控制体验：

1. 随着云原生容器网络的快速发展，对网卡插拔的性能越来越高。波塞冬规划和业务控制器一起，通过将服务进行水平拆分的方式，将网卡插拔的性能提升到10,000 tps以上。

2. 随着业务的规模越来越大，组网越来越复杂，客户业务对网络配置质量要求也越来越高。通过对配置计算引擎以及下发通道的进一步优化，将单VPC支持ENI的数量提升到500w，将路由收敛速度提升到1000条/s。

微信扫码关注该文公众号作者