云布道师
网络系统设计和实现领域顶会 NSDI‘24 于 4 月 16-18 日在美国加州圣塔克拉拉市（SANTA CLARA, CA, USA）举办，来自世界各地的研究人员、开发工程师、系统架构师等齐聚一堂，分享他们的最新的研究成果并交流设计思考，共同推进网络系统领域的发展。
阿里云飞天洛神云网络（下文简称洛神网络）领域两篇论文和入选，这是洛神网络首次亮相并中稿NSDI，这代表洛神网络系统性创新能力再次得到领域专家广泛认可。
本文解读的论文是由洛神网络团队与浙大合作的论文，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 调用后，控制器需要计算是否需要在基础设施上更新配置。这个过程包括以下步骤：
- 识别所有依赖关系：以在 VPC1 中创建 VM4 为例（见图1）；因为VM4属于特定的 VPC，要创建 VM4，需要先确定 VM4 所属的 VPC——即 VPC1；此外，还需要识别 VPC1 的依赖配置——如 ACL 规则和路由表，这个步骤是通过执行SQL 查询完成的；在这个过程中，会查询许多表，例如 VPC-ACL、VPC-VM 等等。
- 确定托管虚拟网络设备的物理机器，任何虚拟网络设备都托管在物理机器上。在图 1 中，VM4 由服务器 2 托管。
- 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。
