UCloud 下一代 VPC 架构平滑演进方案和技术详解

前言

2 月 27 日，UCloud 推出了下一代 VPC 网络（下面简称 VPCng）。VPCng 旨在解决客户网络使用场景中的痛点，如 IP 网段的自主规划、跨可用区容灾、VIP 跨区高可用方案、混合云和公有云的无缝连接等。

UCloud 认为 VPC（Virtual Private Cloud）是隶属于租户的虚拟网络。在虚拟网络中租户能完全掌控网络环境，自主管理所有的云服务资源，并能灵活扩展混合云能力，VPC 的最终目标是给用户提供和传统网络完全一致的功能。

这次推出的新特性如灵活的地址空间管理、VIP 跨可用区都是业界首创。不过用户看不见的是，我们在后台服务做了大量工作，许多控制面和转发面的逻辑被重构。这些新功能不仅部署在新机房，UCloud 在存量机房通过平滑升级，使得用户大量的已部署业务也能享受到这些新功能。

存量机房的原地升级和新机房部署是完全不同的工作。前者要考虑复杂的现网环境，存量机房往往包含多个历史版本，还有针对某些客户做的定制化逻辑，新特性的实现要考虑到各种场景下的兼容性。现网的控制数据也要转换成新格式。网络作为系统级的底层服务，几乎被所有的云服务所使用，其原地升级要比其他产品更为复杂，堪称是云计算中的移花接木。另外，网络原地升级必须要保证用户的业务不受哪怕 1 秒钟的中断。为了控制风险，全网一次性的升级是万万不可的，只能通过渐进的、蚂蚁搬家式的灰度升级才能做到平稳运营，才能做到步步为赢。

接下来，一起看下 UCloud VPCng 平滑升级的架构方案和技术细节。

VPCng 架构

VPCng 的网络架构如下图所示，主要由 VPC、Subnet、RouteTable 三大核心模块组成：

• VPC 是隶属于某一租户的虚拟网络，租户可以自定义网段。VPCng 考虑到用户使用场景，对已经创建好的 VPC 也可以新增网段。值得一提的是，公共服务和混合云作为单独 VPC 来处理，从架构上清晰很多。
• Subnet 是 VPC 资源管理的最小单位，用来管理云主机、物理云主机、云数据库、容器等资源，VPCng 的一大亮点是 Subnet 可以跨可用区，对于跨可用区灾备提供有力保障。
• RouteTable 是 VPCng 设计的核心，负责分布式虚拟路由（DVR）的管理。每个子网都需要关联一张路由表。

图 1 VPCng 整体架构

分布式虚拟路由（DVR）

现有的 VPC 网络中，部分产品在使用自定义子网时需要先去创建一个虚拟路由器（VRouter）。路由器具备三个特性：多主机共享出外网、指定端口转发、子网间内网互通。东西向和南北向的流量都要经过虚拟路由器。两个子网互通需要经过 VRouter，子网访问外网也需要穿越 VRouter，这样不仅物理路径上多了一跳，并且 VRouter 本身会成为性能瓶颈。

图 2 集中式路由器架构

VPCng 重构了路由定义，并抽象为分布式虚拟路由 DVR。DVR 的载体是分散在各个计算节点上的虚拟交换机，而路由表是其核心。如下图，东西向流量通过虚拟交换机进行分发，实现点对点通信。而 NATGW 只是作为外网访问的网关设备，提供多子网共享出外网能力。在路由表设计上，支持多种路由类型，包括直连路由、缺省路由、混合云路由、主机路由等等，除此之外还支持策略路由以及定义路由优先级。

图 3 分布式虚拟路由（DVR）架构

DVR 作为 VPCng 设计的核心，平滑升级尤为重要。VPCng 设计之初就考虑到上线过程要做到对用户透明，在不影响现有业务情况下，平滑升级到新架构中，所以在升级方案设计上也比较复杂。

整个升级过程拆分成四个阶段。

Stage1 路由表数据迁移

大型分布式系统的平滑升级，最难做到的是控制数据的无缝迁移。VPCng 的路由表结构变动很大，在此我们借鉴了可用区升级中经典的“双写方案”，先将存量数据转换为新表结构，然后改造现有管理服务模块，使其具备新老表双写能力。这个阶段数据一致性是最重要的，必须时要通过对账进行一致性校验。

Stage2 SDN 转发面服务升级

转发面服务直接影响到存量用户的现网服务，所以升级过程必须慎之又慎。 路由表和控制器模块是本次 SDN 转发面服务升级的重心，我们通过设计一层转发 Proxy 实现了按用户灰度的能力，只有灰度用户才能走到新转发逻辑，有效控制灰度影响范围。

Stage3 SDN 控制面服务升级

为了满足 VPCng 的功能和性能需求，这个阶段我们做了大量重构，原有控制面架构采用分层结构，可扩展性不好。新加特性涉及多处改动，而且容易造成脏数据。UVPCFE 是一套基于 Golang 语言开发微服务系统，稳定、快速，可扩展性好。UVPCFE 通过 APIGW 灰度系统同样做到用户级别的灰度。这个阶段由于前端尚未开放，所以仍然需要保证数据的“双写”。

Stage4 前端开放升级

前三个阶段完成后，存量用户后台已经运行在新的网络架构下。所以 Stage4 阶段要做的事情变的简单，只要把 VPCng 的控制台开放给用户即可。图中绿色部分表示 VPCng 业务逻辑，蓝色部分表示原有逻辑，这两套逻辑在灰度过程中长期存在，一旦发现新逻辑有缺陷，可以立即回滚到原有逻辑，现有业务不受影响。

图 4 VPCng 灰度方案

详细的升级方案让平滑升级过程变得可行、可控、可回滚，在实际操作中也会遇到各种问题。底层网络架构升级，对各个业务（云主机，云数据等）的管理服务都会产生影响，必然会存在业务间的耦合，即便是网络系统内部模块也会存在灰度时序问题。如何做到解耦合？如何控制好灰度发布节奏？这些问题都离不开系统化的统筹和精细化的运营，这是考验一支团队是否具备大型分布式系统持续运营的能力。

公共服务

UCloud 云平台提供了许多公共服务如内网 DNS、NTP、软件源等，这些公共服务对所有租户开放。不同租户的 IP 可能相同，他们都可能去访问公共服务后端服务器，所以后端服务器无法通过路由表决定返回哪个租户。举例来说：租户 A 和租户 B 云主机的 IP 地址均为 172.16.0.16，当访问内网 DNS 时，DNS 服务器回复时无法决定是送到租户 A 还是 B。

图 5 公共服务集中式 NAT 架构

现有 VPC 网络是通过 NAT 转换来实现的，这也是业界主流的解决方案，这需要解决两个问题：

首先，要解决用户子网和公共服务子网网段重叠导致路由冲突问题。考虑到公共服务子网规模不大，通常采取预留网段的方式，确保公共服务网段不被用户使用。

其次，要解决 NAT 转换的问题。

UCloud 团队论证了多种 NAT 可行方案，这里介绍两种：

• NAT 网关采用 namespace 方案，为每个租户创建独立的 namespace，在 namespace 里面进行 SNAT 转换，通过 SNAT 后的 IP 去访问公共服务。公共服务响应的报文在 namespace 里面进行 DNAT 转换，送回给租户，从而达到访问公共服务目的。
• NAT 网关会将租户 ID 信息保存到 SKB 的 mark 上，通过内核 netfilter 模块做 SNAT 转换，同时 connection track 中会维护 mark 对应关系。NAT 网关收到公共服务响应报文后匹配 connection track，得到 mark，然后通过 netfilter 做 DNAT 将 mark 对应报文返回给租户。

这些 NAT 方案存在两个问题，一是源地址不可见，如果公共服务依赖源地址，则此方案不可行；二是 NAT 网关是性能瓶颈，特别是针对大流量的公共服务（如 UFile），需要搭建多台服务器方能支撑。

VPCng 吸收了分布式 NAT 理念，将集中式的 NAT 网关分散到各个计算节点的虚拟交换机上，解决了网关性能的问题，并自主研发一套 NAT Plugin 来解决源地址问题，不同租户即使 IP 相同也能正常访问公共服务。分布式 NAT 架构图如下：

图 6 公共服务分布式 NAT 架构

混合云

混合云连接传统 IT 和公有云，博采众之所长，目前已是云计算发展的主流趋势之一。在传统的混合云方案中，混合云只是作为若干网段接入公有云，用户的诸多日常需求比如路由管理、带宽容量管理，混合云日常运维需要大量人力和沟通成本，亟需优化。

在 VPCng 的设计方案中，混合云抽象为租户的一个独立 VPC，其中包含多个子网，子网可以是托管设备网段，也可以是通过光纤、数字链路、VPN 连接到公有云 POP 点的自建 IDC 网段。混合云 VPC 的架构图如下：

图 7 混合云 VPC 架构

为了在功能上完全兼容 VPCng，混合云需要支持用户自定义混合云网段、用户自定义混合云路由策略、用户自主控制混合云的连通权限等特性，因此混合云系统的控制面需要完全重构，另外对于作为转发面核心的混合云网关提出了转发能力、路由控制能力、鉴权能力等全方位的新需求。此外，我们还必须保证让用户无感知地从传统混合云升级到混合云 VPC。

控制面

我们设计了与旧混合云控制系统完全解耦的新系统，数据库、控制程序均与旧版本独立。在用户添加路由、修改网段等动作时，API 层利用消息队列对 DB 进行双写，同时通过 DB 对账保证数据的一致性。新旧系统分别拥有独立的转发面，分别独立拉取后台配置，确保新旧系统除了双写动作其他操作均解耦。

转发面

为了支持混合云 VPC，我们开发了新版本的混合云网关。通过拉取后台配置，网关执行相关报文的鉴权、转发、封装和解封装等操作。同时，网关集群拥有 scale out 的能力，可无缝扩容，最高支持高达数百 G 的流量转发。

混合云网关的无缝切换是升级的核心步骤。我们开发了多个工具以辅助这个关键过程：

1. 基于 Netconf 的交换机配置 API，用于切换及回退交换机侧路由配置。
2. 基于 VPCng 的路由切换 API，VPCng 控制后台结合推送与拉取，可以在 10s 内更新全网三层路由流表。该 API 用于切换及回退公有云侧的路由配置。
3. 基于 OVS PacketOut 的连通性检查工具，通过拼接 ICMP 报文，注入到公有云宿主机的 OVS Virtual Interface 上，可以模拟用户的业务互通，并基本覆盖用户的连通性黑盒检查场景。
4. 基于交换机统计数据、混合云网关统计数据的流量统计工具，可以从统计角度确认用户切换前后的流量状况。

转发面的切换过程如下图所示：

图 8 混合云 VPC 转发面切换流程

步骤一：调用交换机侧路由切换 API，切换 PE 的路由，此时，混合云侧向公有云侧的流量已经切换至新混合云网关，而公有云侧到混合云侧的流量则仍然给到旧混合云网关。我们在网关类产品设计的一条基本理念就是路由交换网关一定要是无状态的，因此用户的服务不会受到任何影响。切换之后，利用连通性检查工具和流量统计工具进行检查，如发现异常立即回退。

步骤二：调用公有云侧路由切换 API，切换公有云侧路由。切换完成后，新混合云网关将承载全部流量。同样利用工具进行检查，发现异常则回退。

我们按照上述策略对多个用户的混合云系统进行了成功升级，从实践来看，用户完全无感知。

结束语

云网络是大型公有云平台的基石，网络架构调整是对云服务商研发、交付、运营等综合能力的考验。从系统设计、灰度方案，到每个阶段实施、变更发布、最后交付，UCloud VPCng 最大化做到了平滑演进。

另外，在本篇技术分享中，我们也详细介绍了 VPCng 在升级过程中遇到的几个关键问题以及应对之策，当然 VPCng 升级复杂度还不止这些，欢迎大家就相关技术细节进行讨论。

作者介绍

钟春山，UCloud 高级网络研发工程师，下一代 VPC 网络的负责人，曾参与 UCloud 可用区的设计和研发。在超大规模 SDN 网络构建、分布式系统研发、海量数据运营等方面有着丰富的实战经验。

冯业浩，UCloud 网络研发工程师，混合云网络负责人，先后负责 UCloud 负载均衡、虚拟路由、跨域网关、混合云网关等产品的设计和研发。

感谢孟夕对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。