前言
2月27日，UCloud推出了下一代VPC网络（下面简称VPCng）。VPCng旨在解决客户网络使用场景中的痛点，如IP网段的自主规划、跨可用区容灾、VIP跨区高可用方案、混合云和公有云的无缝连接等。
UCloud认为VPC（Virtual Private Cloud）是隶属于租户的虚拟网络。在虚拟网络中租户能完全掌控网络环境，自主管理所有的云服务资源，并能灵活扩展混合云能力，VPC的最终目标是给用户提供和传统网络完全一致的功能。
这次推出的新特性如灵活的地址空间管理、VIP跨可用区都是业界首创。不过用户看不见的是，我们在后台服务做了大量工作，许多控制面和转发面的逻辑被重构。这些新功能不仅部署在新机房，UCloud在存量机房通过平滑升级，使得用户大量的已部署业务也能享受到这些新功能。
存量机房的原地升级和新机房部署是完全不同的工作。前者要考虑复杂的现网环境，存量机房往往包含多个历史版本，还有针对某些客户做的定制化逻辑，新特性的实现要考虑到各种场景下的兼容性。现网的控制数据也要转换成新格式。网络作为系统级的底层服务，几乎被所有的云服务所使用，其原地升级要比其他产品更为复杂，堪称是云计算中的移花接木。另外，网络原地升级必须要保证用户的业务不受哪怕1秒钟的中断。为了控制风险，全网一次性的升级是万万不可的，只能通过渐进的、蚂蚁搬家式的灰度升级才能做到平稳运营，才能做到步步为赢。
接下来，一起看下UCloud VPCng平滑升级的架构方案和技术细节。
VPCng架构
VPCng的网络架构如下图所示，主要由VPC、Subnet、RouteTable三大核心模块组成：
Subnet是VPC资源管理的最小单位，用来管理云主机、物理云主机、云数据库、容器等资源，VPCng的一大亮点是Subnet可以跨可用区，对于跨可用区灾备提供有力保障。
RouteTable是VPCng设计的核心，负责分布式虚拟路由（DVR）的管理。每个子网都需要关联一张路由表。
图1 VPCng整体架构
分布式虚拟路由（DVR）
图2 集中式路由器架构
图3 分布式虚拟路由（DVR）架构
DVR作为VPCng设计的核心，平滑升级尤为重要。VPCng设计之初就考虑到上线过程要做到对用户透明，在不影响现有业务情况下，平滑升级到新架构中，所以在升级方案设计上也比较复杂。
整个升级过程拆分成四个阶段。
Stage1 路由表数据迁移
大型分布式系统的平滑升级，最难做到的是控制数据的无缝迁移。VPCng的路由表结构变动很大，在此我们借鉴了可用区升级中经典的“双写方案”，先将存量数据转换为新表结构，然后改造现有管理服务模块，使其具备新老表双写能力。这个阶段数据一致性是最重要的，必须时要通过对账进行一致性校验。
Stage2 SDN转发面服务升级
转发面服务直接影响到存量用户的现网服务，所以升级过程必须慎之又慎。 路由表和控制器模块是本次SDN转发面服务升级的重心，我们通过设计一层转发Proxy实现了按用户灰度的能力，只有灰度用户才能走到新转发逻辑，有效控制灰度影响范围。
Stage3 SDN控制面服务升级
为了满足VPCng的功能和性能需求，这个阶段我们做了大量重构，原有控制面架构采用分层结构，可扩展性不好。新加特性涉及多处改动，而且容易造成脏数据。UVPCFE是一套基于Golang语言开发微服务系统，稳定、快速，可扩展性好。UVPCFE通过APIGW灰度系统同样做到用户级别的灰度。这个阶段由于前端尚未开放，所以仍然需要保证数据的“双写”。
Stage4 前端开放升级
图4 VPCng灰度方案
详细的升级方案让平滑升级过程变得可行、可控、可回滚，在实际操作中也会遇到各种问题。底层网络架构升级，对各个业务（云主机，云数据等）的管理服务都会产生影响，必然会存在业务间的耦合，即便是网络系统内部模块也会存在灰度时序问题。如何做到解耦合？如何控制好灰度发布节奏？这些问题都离不开系统化的统筹和精细化的运营，这是考验一支团队是否具备大型分布式系统持续运营的能力。
公共服务
图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），需要搭建多台服务器方能支撑。
图6 公共服务分布式NAT架构
混合云
混合云连接传统IT和公有云，博采众之所长，目前已是云计算发展的主流趋势之一。在传统的混合云方案中，混合云只是作为若干网段接入公有云，用户的诸多日常需求比如路由管理、带宽容量管理，混合云日常运维需要大量人力和沟通成本，亟需优化。
图7 混合云VPC架构
为了在功能上完全兼容VPCng，混合云需要支持用户自定义混合云网段、用户自定义混合云路由策略、用户自主控制混合云的连通权限等特性，因此混合云系统的控制面需要完全重构，另外对于作为转发面核心的混合云网关提出了转发能力、路由控制能力、鉴权能力等全方位的新需求。此外，我们还必须保证让用户无感知地从传统混合云升级到混合云VPC。
控制面
我们设计了与旧混合云控制系统完全解耦的新系统，数据库、控制程序均与旧版本独立。在用户添加路由、修改网段等动作时，API层利用消息队列对DB进行双写，同时通过DB对账保证数据的一致性。新旧系统分别拥有独立的转发面，分别独立拉取后台配置，确保新旧系统除了双写动作其他操作均解耦。
转发面
为了支持混合云VPC，我们开发了新版本的混合云网关。通过拉取后台配置，网关执行相关报文的鉴权、转发、封装和解封装等操作。同时，网关集群拥有scale out的能力，可无缝扩容，最高支持高达数百G的流量转发。
混合云网关的无缝切换是升级的核心步骤。我们开发了多个工具以辅助这个关键过程：
基于Netconf的交换机配置API，用于切换及回退交换机侧路由配置。
基于VPCng的路由切换API，VPCng控制后台结合推送与拉取，可以在10s内更新全网三层路由流表。该API用于切换及回退公有云侧的路由配置。
基于OVS PacketOut的连通性检查工具，通过拼接ICMP报文，注入到公有云宿主机的OVS Virtual Interface上，可以模拟用户的业务互通，并基本覆盖用户的连通性黑盒检查场景。
基于交换机统计数据、混合云网关统计数据的流量统计工具，可以从统计角度确认用户切换前后的流量状况。
图8 混合云VPC转发面切换流程
步骤一：调用交换机侧路由切换API，切换PE的路由，此时，混合云侧向公有云侧的流量已经切换至新混合云网关，而公有云侧到混合云侧的流量则仍然给到旧混合云网关。我们在网关类产品设计的一条基本理念就是路由交换网关一定要是无状态的，因此用户的服务不会受到任何影响。切换之后，利用连通性检查工具和流量统计工具进行检查，如发现异常立即回退。
步骤二：调用公有云侧路由切换API，切换公有云侧路由。切换完成后，新混合云网关将承载全部流量。同样利用工具进行检查，发现异常则回退。
我们按照上述策略对多个用户的混合云系统进行了成功升级，从实践来看，用户完全无感知。
结束语
云网络是大型公有云平台的基石，网络架构调整是对云服务商研发、交付、运营等综合能力的考验。从系统设计、灰度方案，到每个阶段实施、变更发布、最后交付，UCloud VPCng最大化做到了平滑演进。
另外，在本篇技术分享中，我们也详细介绍了VPCng在升级过程中遇到的几个关键问题以及应对之策，当然VPCng升级复杂度还不止这些，欢迎大家就相关技术细节进行讨论。
网友评论