基于主机Overlay和自研虚拟化网关的VPC在360的落地

01

背景

1.1 概述

随着公司业务的不断发展，用户对网络也提出了更多的需求。一方面360公司25G机房逐步上线，交换机架构升级，导致原有的虚拟化网络方案无法支持虚机的跨交换机迁移，而且部分特殊业务线对网络有着隔离的需求。另一方面，之前的网络Overlay架构与交换机耦合太严重，在稳定性、运维和问题排查方面都不太理想。

综合上述情况，虚拟化团队选择了主机Overlay的方案，与交换机解耦，支持专有网络（Virtual Private Cloud，简称VPC），保证不同用户间隔离，保障云上资源的安全性，并上线至公司内部私有云平台HULK，丰富了HULK的服务类别。

1.2 架构思路

在私有云内做VPC的需求，最初团队内部是存在一定争议的。考虑到私有云的每个IDC本身就是一个独立的VPC，IDC内VLAN隔离，三层互通，再去做VPC是否有必要？

业务发展过程中，集团的部分事业部逐渐子公司化，其安全要求是与集团独立的。当前公司都是采用IDC VLAN隔离网段 + 核心ACL控制等方式，来限制关联公司与集团的互访。每当有隔离需求，都需要网络运维部门单独去分配段或设置三层隔离等，不够灵活，IP段无法定制，限制比较死。所以需要集团内部私有云平台去支持公有云的VPC，通过逻辑划分的VPC，业务可以实现自定义交换机、IP段、路由表，以及自定义VPC之间的互联互通等。所有的VPC的概念都可以和IDC的物理机逻辑相映射，例如子网对应接入交换机，路由表对应三层核心交换机和路由器，VPC内的VM对应IDC的物理机等。软件定义网络，本质上依然是物理网络的逻辑映射。

在开始摸索VPC之前，公司集团都是网络Overlay，主机侧走VLAN模式，接入交换机做VLAN封装，实现大二层网络，保证VM跨交换机迁移等。但是存在网络侧工作量很大的痛点，每次上线部署都需要和网络运维部门联调VLAN配置。并且交换机侧做Overlay，对交换机侵入性比较大，需要网络运维部门参与配置，对交换机的选型和品牌都有要求，优势是性能好，都是硬件交换机做VXLAN解封装。

在综合考虑之后，我们实施了主机Overlay的方案。当前业界主流云厂商基本都是将VXLAN解封装放到了主机侧，优势就是和网络设备解绑，除了主机的包都是IP包，交换机做好纯转发即可。OpenStack社区Neutron也支持主机Overlay，基于OVS做解封装，再加上DVR分布式路由方案消灭集中式Neutron网络节点Vrouter性能瓶颈，主机路由Vrouter来处理南北东西流量。而我们的方案是DVR+自研虚拟化网关，DVR处理东西流量，南北流量都统一走基于DPVS开发的虚拟化网关，既能区分VPC的负载均衡NAT网，也能达到最高单机性能和降低计算节点主机路由负载等目标。

自研虚拟化网关的技术背景是，虚拟化团队同时维护和开发着公司的基于DPVS的负载均衡，专有网络的NAT网关和FIP浮动IP本质上就是VPC内的SNAT和DNAT，所以需要在DPVS上增加VPC的区分和标识。这是自研的关键点。具体细节信息可参考下文中的SNAT虚拟化网关和FIP虚拟化网关架构章节。

这一套基于自研虚拟化网关的主机Overlay方案已经在线上25G机房运行接近一年之久，运行稳定，架构高可用性可体现在：在网关与交换机的对接中，网关设备采用了双活冗余方案，每台交换机下一组6台25G网卡的网关集群，整体VPC流量峰值在200Gbps左右。后续考虑100G网卡来做网关，但有利有弊，利是网关机器数少了，弊是故障域大了。计算节点侧都采用了双发ARP的bond方案，上层对接去堆叠的双线双交换机，综上在网关侧和主机侧都做了高可用保证。

该方案的收益：

• 对业务方来说，业务可从公司私有云平台上进行自定义VPC、创建二层隔离网络、自定义IP段等操作；

• 对网络运维部门