UCloud 虚拟网络VPC技术演进之路

网络作为信息时代的重要载体，在云服务的快速发展下形成了独具特色的“虚拟网络”服务架构和模式。12月19日，2020中国云网络峰会于北京顺利召开，会上UCloud虚拟网络VPC负责人陈煌栋给大家带来了演讲《UCloud VPC技术演进之路》，着重介绍了UCloud在虚拟网络更新迭代过程中遇到的问题以及如何根据软硬件等方面进行改进的网络实践。

UCloud的VPC网络从2012年上线至今经历了三次大的技术演进，从最早的经典网络过渡到VPC网络，并形成了目前软硬件一体化的VPC 3.0架构。

早期的经典网络

和业界的发展历程类似，在早期，UCloud的数据中心网络实际以经典网络为主。云主机和宿主机都位于一个大二层网络中，网络转发依赖linux bridge，而隔离依赖控制面维护的iptables、ebtables规则。

随着网络规模不断扩大，经典网络也暴露了诸多问题：

• 规模问题：依赖大二层的经典网络规模受限于广播域，随着广播域扩大，广播风暴和交换机MAC地址表表项不足都会引起网络故障，从而限制网络规模；
• 性能问题：由于转发依赖linux bridge导致转发性能不高，且随着iptables隔离规则的增加导致匹配效率变差，引起性能问题；
• 组网问题：由于经典网络统一分配IP地址，导致客户无法决定自己的网络结构和网络地址空间；同时由于IP不能复用，导致地址空间不足。

VPC 2.0架构：基于SDN技术实现的VPC网络

正是存在以上问题，UCloud在2016年底开发并上线了基于VPC 2.0架构的VPC网络，并最终帮助客户无缝迁移到了VPC网络。

在VPC 2.0架构中，我们基于SDN技术实现了网络的虚拟化，通过在转发平面引入OpenVSwitch和OpenFlow完成Overlay流量的转发与隔离，在控制平面开发了SDN 控制器来完成Flow的管理。

在VPC 2.0中，我们通过Packet-In和Push相结合的方式来下发Flow规则。主动推送路由表、ACL相关的Flow，而点到点转发的Flow则依赖Packet-In机制上送到控制器完成Flow的下发。

此外，我们基于DPDK技术开发了诸多东西向和南北向网关，比如负载均衡网关、混合云网关、裸金属物理云网关等，这些网关会和VPC进行直接交互来完成流量的转发，实现VPC到异构网络访问。

在VPC 2.0的长期运营中，我们也发现了诸多问题：

• Packet-In机制导致首包时延：新建通信必须经过控制器计算才能完成Flow下发，导致首包存在转发时延，影响客户体验。而随着K8S、Serverless类的容器应用兴起，这部分时延对业务的影响会更大；
• 转发面和控制面流量耦合：正是因为Packet-In机制导致转发面的流量和控制面流量互相耦合，从而导致网络中的诸多DDoS攻击、内网扫描流量会穿透到控制面，从而对控制面造成巨大压力，影响服务稳定性；
• 异构网络耦合：在VPC 2.0架构中VPC需要和各个异构网络直接通信，因此各网关都需要感知VPC的路由细节，从而导致VPC控制面逻辑分散，网络边界变大，上线新特性往往牵一发而动全身，导致迭代周期变长；
• OVS转发性能不足：ovs转发依赖linux内核，而linux内核并非为网络转发所设计，存在较多的锁和队列，导致转发性能不足。

VPC 3.0架构：软硬件一体化的新一代VPC网络

为了解决VPC 2.0下的这些问题，我们做了很多虚拟网络技术方面的探索和改进，最终形成了软硬件一体化的VPC 3.0架构。

在VPC 3.0架构中，最大的特点就是软硬件协同，转发面引入了非常多的转发网元，包括内核版ovs、硬件卸载版ovs、智能网卡、P4和DPDK等，因此如何适配诸多转发面网元并保持良好的扩展性是控制面需要考虑的重要问题。

网元适配

在VPC 3.0控制平面中，我们引入了模型层(Model Layer)、中台层(Middle Layer)、映射层(Mapping Layer)和推送层(DataPath Layer)等概念和服务。在适配网元时，统一的业务对象（如Subnet）会在模型层生成，并在中台层被路由给映射层，在映射层完成业务对象到不同网元对象的映射，如OpenFlow对象、P4对象、TC对象。

而后网元对象会再次经过中台层路由给推送层。推送层则关心具体的转发网元，实现高效、高性能的转发对象推送。

动态学习

为了解决VPC 2.0架构中的Packet-In问题，我们引入了主动推送和动态学习相结合的Flow下发方式，以完成Flow的高效下发。我们基于P4和可编程芯片开发了VPC网关BGW，BGW会和位于计算节点的Datapath Controller运行DCP(Datapath Control Protocol)协议来完成流表的学习和流量的offload。

具体实现原理是：当ovs既有规则无法满足转发时，通过默认Flow转发给BGW，而BGW除了正确将流量转发至目的地之外，也会按照DCP协议构造一个UDP报文发送给源端Datapath Controller，而Controller也会根据该报文学习到下发Flow所需的关键信息，因此实现Flow的动态学习和流量从BGW向ovs的offload。

相比于VPC 2.0的Packet-In机制，动态学习带来了以下好处：

• 流表学习发生在转发面，性能远高于控制面下发；
• 流表学习期间流量仍可由BGW正常转发，不影响业务，无首包时延；
• 相比于全量推送，流表按需学习可以极大降低推送Flow的数量，提升推送的性能。

控制面中台

此外我们构建了控制平面的中台能力，通过中台层实现了诸多通用能力，包括对象路由、一致性缓存、对象分片、对象灰度等，使得在开发不同产品、适配不同转发面时都可以快速复用这些已经定义良好、实现良好的通用能力，以此提高控制面的可靠性和性能。

硬件卸载

在转发面演进中，我们也从软件逐步过渡到硬件。从早期的kernel bridge和kernel ovs转发，逐步切换到目前的硬件卸载ovs、智能网卡等硬件网元来加速转发性能。在快杰云主机中，通过卸载ovs，将网络转发能力提升到25G带宽、1000w pps和10G外网带宽。

同时，网关也逐渐从DPDK技术演进到目前基于P4的可编程芯片。在P4实践中，我们开发并上线了VPC网关BGW和负载均衡网关CGW。VPC网关主要支持VPC内的二三层流量转发和ARP代答，并支持Flow Offload。而负载均衡网关则支持无缝替换传统交换机ECMP实现网关集群，支持一致性hash（Maglev Hashing），并支持根据任意字段（vni，内存ip和端口）来计算哈希，支持ipv4/ipv6 overlay协议。对于CGW的使用场景之一就是实现网关集群的sharding和灰度。

异构网络

在VPC 3.0架构中，我们通过引入UXR这样的中心化网关来完成异构网络的解耦，使得异构网络在和VPC通信时可以彼此解耦，无需关心VPC的网络细节，从而缩小网络边界，使得网络更内聚。

此外，我们也引入了VPC网关来实现VPC内的流量转发和流表的动态学习。

同时，裸金属物理云产品也向智能网卡演进，我们基于智能网卡实现了kernel ovs的卸载和NVGRE隧道的卸载，并通过bonding技术提升网络带宽至40G。

服务架构：微服务化

在服务架构中，我们也从单体架构逐步演进到微服务架构。

在单体架构中，我们是基于自有框架和TCP、ProtoBuf实现的分布式系统，在长期维护过程中也出现诸多问题：

• 逻辑复杂：随着产品规模的增加和迭代，导致应用逻辑变得越来越复杂，单体应用变得“大而全”，迭代周期变长，灵活性变差；
• 扩缩容能力差：同时服务的部署和管理较为传统，扩缩容能力较差；
• 流程管理复杂：由于RPC调用是基于TCP和Protobuf，因此流量管理成本较高。为了实现灰度我们开发了内部灰度网关，为了支持业务重试、限流等逻辑也需要在代码内部实现。

因此，我们按照服务边界进行了拆分，将单体应用拆分成微服务，并引入了Istio、Kubernetes、gRPC等框架和组件。

在微服务架构中，我们取得了如下优点：

• 服务内聚，迭代速度快：在拆分的过程中，单个微服务逻辑足够内聚，足够简单，从而使得服务迭代速度更快，更易于灰度；
• 弹性伸缩能力强：通过借助kubernetes可以实现良好的弹性伸缩和部署能力；
• 精细化灰度能力：通过借助Istio，我们可以实现精细化的灰度能力，包括基于流量比例、客户、客户级别、VPC、甚至是VM级别的请求灰度；
• 基于Isito的流量管理：通过Istio我们在sidecar节点实现了对流量的管理，包括重试、限流、熔断等等。

在微服务化的过程中我们也遇到了很多挑战，维护一个大型微服务系统会给整体服务带来更多的复杂性和不确定性，也更考验我们的服务治理能力，因此微服务化的背后我们也做了很多努力。

Telemetry和故障定位

随着云计算的发展，云网络的规模也在不断扩大，为了在日益复杂的云网络环境中定位网络问题，我们往往要回答内网流量追踪的三大痛点：

• 通信是否正常：端到端的通信状态是否正常，是否有故障，故障发生在哪？
• 时延是否正常：端到端的通信时延是否正常？
• 流量走了哪条路径：如何在诸多ECMP和Hash中确定流量的实际路径？

为了解决以上问题，我们设计和开发了UCloud的全链路的高性能探测系统。

该系统的最大的特点是对网元的要求非常小，只需要overlay/underlay网元支持流量镜像、ERSPAN即可，而无需可编程能力。通过将INT Packet（特殊染色的TCP报文）在各网元的出入向镜像给Telemetry Cluster，我们可以构建出端到端的报文bitmap，并据此分析出通信结果（通信是否正常、是否丢包、丢在了哪里）、端到端的近似时延、以及端到端的实际通信链路。

此外，配合我们的活跃流分析系统，可以实现VPC内的活跃流快速探测。在变更时我们可以通过这样的机制快速验证变更前后的活跃流通信状态、通信链路是否发生异常，从而快速、可靠的发现潜在问题。

总结

在最新的VPC3.0架构下，UCloud VPC支持高性能网络转发（内网包量最高可达1000万PPS，单个EIP支持最大10Gb外网带宽），除IPv4外，UCloud VPC也提供了对IPv6的原生支持，帮助客户快速构建IPv6 VPC网络。同时，通过ACL和安全组的支持，用户可以实现对VPC内资源细粒度的安全访问控制。

未来，UCloud VPC团队将密切关注网络相关的软硬件发展，并消化吸收符合自身需求的新技术，持续为用户打造安全、稳定、高性能的VPC云服务。