基于 DPDK 实现 VPC 和 IDC 间互联互通的高性能网关

随着云计算和网络技术的不断发展，越来越多的业务有着上云的需求。上云后，业务能够使用云上已有的服务提升开发效率，也可以利用云平台的弹性伸缩特性，及时应对业务的负载变化。实际生产环境中，用户的服务一部分部署在云平台上，另一部分部署在自己的 IDC 机房。

用户有从 VPC 访问 IDC 中服务的需求，且 IDC 内的服务需要支持负载均衡。为了实现 IDC 的平滑上云，必须打通 VPC 网络到 IDC 机房经典网络间的互联互通，其中最核心的设备是 VXLAN 网关，用来完成 VXLAN 网络和 VLAN 网络间的映射。虽然可以通过交换机完成 VXLAN 到 VLAN 的转换，但是业务的负载均衡需求无法满足。因此，360 虚拟化团队根据业务需求，决定自研 CLOUD-DPVS 设备支持负载均衡、VXLAN 隧道、BFD 探活等功能，来实现 VPC 网络到 IDC 网络的互联互通。

CLOUD-DPVS 网关整体架构

CLOUD-DPVS 工作在 VXLAN 网络和 VLAN 网络的中间层，来自 VPC 网络的用户请求被引流到 CLOUD-DPVS 网关，进行 VXLAN 解封装和 SNAT/DNAT 处理后，请求被发送至 IDC 内服务所在的机器上。回包同样会经过 CLOUD-DPVS 进行 SNAT/DNAT 后，进行 VXLAN 封装发送至 VPC，如下图 1 所示：

图 1

CLOUD-DPVS 网关整体架构选型

为了满足高性能，多主部署和负载均衡等需求，360 虚拟化团队在经过调研后决定在 DPVS 的基础上进行开发。

DPVS 是一个基于 DPDK 软件库加速 LVS 的高性能负载均衡器，通过使用网卡用户态驱动、零拷贝、大页内存和队列绑定等技术解决了 LVS 的性能瓶颈，同时保留 LVS 的负载均衡逻辑。基于 DPVS，我们只需要在现有逻辑的基础上增加 VPC 属性，支持 VXLAN 封装解封装等功能，就可以为每个 VPC 业务提供虚拟 IP 来访问 IDC 内的服务。选型完成后随即启动了 cloud-dpvs 的项目，其核心架构如下图 2 所示：

图 2

CLOUD-DPVS 网关方案概述

1.高可用方案的改进

传统的高可用方案大都采用 BGP+ECMP 的模式构建集群，用 ECMP 将数据包散列到集群中各个节点上，通过 BGP 协议保证单台机器故障后将这台机器的路由动态剔除出去，由此做到了动态 failover，组网结构如下图 3 所示：

图 3

服务器通过 BGP 将 VIP 发布到网络中，交换机学习到 VIP，形成 BGP 等价多路径路由（ecmp），然后根据哈希因子计算得到 hash lb key，进行 ECMP 下一跳链路数(Member-count)求余计算，再与 ECMP 基值进行加法运算得出转发下一跳 index，即确定了下一跳转发路由到达服务器。

这种方式要求服务器必须部署在三层网络中，需要与交换机建立 BGP 连接。另外服务器集群出现问题后，其恢复时间受限于 BGP 协议的收敛时间，这个时间值一般是秒级，根据以往在现网环境中的经验，集群的收敛时间一般在 6~9 秒左右。

为了提高收敛时间和减少对环境的依赖，360 虚拟化团队对上面提到的两点进行了改进，引入 BFD 协议将收敛时间减少到毫秒级别，并在 VPC 网络中增加调度器使其不再依赖底层网络就可以把流量 hash 到各台服务器上，如下图 4 所示：

图 4

支持 BFD 探测

BFD(Bidirectional Forwarding Detection) 双向转发检测协议，提供了一个通用的标准化的介质无关和协议无关的快速故障检测机制。具有以下优点：

1.对网络设备间任意类型的双向转发路径进行故障检测，包括直连物理链路、虚电路、隧道、MPLS LSP、多条路由路径以及单向链路等。

2.可以为不同的上层应用服务，提供一致的快速故障检测时间。

3. 提供小于 1s 的检测时间，从而加快网络收敛速度，减少应用中断时间，提高网络的可靠性。

利用 BFD 的优点，VPC 内的机器会周期性向 CLOUD-DPVS 各个节点发送 BFD 探测报文，根据探测结果动态更新 hash 计算结果，选择可用的 CLOUD-DPVS 服务器，从而保证服务的高可用。

在 CLOUD-DPVS 中，我们实现了 BFD 协议处理模块，并将其挂载在 INET_HOOK_PRE_ROUTING。当数据包进入 CLOUD-DPVS 后，优先判断其是否为 BFD 报文，并回复相应状态的 BFD 报文，如 STATE_INIT/STATE_UP。

2.负载均衡转发层适配

FULLNAT 模式

DPVS 支持 NAT、Tunnel、DR 和 FULLNAT 等几种负载均衡模式，但是 NAT、DR、Tunnel 这三种模式都有一定的限制，需要一定的环境的支持，才能正常的工作。

1.DR 模式的限制：RS 跟 Director Server 必须有一个网卡在同一个物理网络中

2.TUNNEL 必须在所有的 realserver 上绑定 VIP

3.NAT：RS 的网关必须指向 LVS 所在服务器

而 FULLNAT 模式通过对入报文做了 DNAT+SNAT，即将报文的目的地址改为 RS 的地址，源地址改为 DPVS 设备地址；RS 上不需要配置路由策略，回包到达 DPVS 设备后做 SNAT+DNAT，即将报文的源地址改为 DPVS 设备上的 VIP 地址，目的地址改为真实的用户地址，从而规避上面三种方式的限制，使其组网更加的灵活，适应性更强，因此 CLOUD-DPVS 网关使用的是 FULLNAT 模式。

引入 VPC 的概念

DPVS 社区最初设计的应用场景是 IDC 的经典网络，并不适用于云化场景。云化场景与 IDC 经典网络最核心的区别是：经典网络提供的是多用户共享的网络，而 VPC 提供的是用户专属的网络。VPC 内用户可以任意定义云主机的 IP 地址，而在经典网络模式下，大家挤在一个二层网络里面，IP 地址首先要保证不能重合。

图 5

如上图 5 所示，VIP:PORT 可以唯一表示一个服务，服务后面挂载了多个实例，但在云化场景下，其 VIP 地址是可以重复的，所以仍然使用 VIP:PORT 来表示一个具体服务就行不通了。因此 CLOUD-DPVS 转发层面不能继续沿用 DPVS 原有的处理逻辑，为了解决这个问题研发团队引入了租户 VPC 的概念，把服务和 VPC 关联起来，不同的 VPC 可以有相同的 VIP:PORT，这也与实际使用方式相吻合，改造后就变成了 VXLAN+VIP:PORT 来表示一个服务，具体如下图 6 所示：

图 6

cloud-dpvs 转发原理

为实现其转发功能，在 cloud-dpvs 上新增了服务器信息表和虚机信息表，其中服务信息表由 vxlan 和 VIP:PORT 以及 RS:PORT 等信息组成，表格式如表 1 所示：

   表 1：服务信息表

其中 Vxlan+VIP+vPort 代表 VPC 内的一个公共服务，用户 VPC 私有网络内的客户端可以通过访问 VIP+vPort 来使用其公共服务，客户端感知到 VIP 是私有网络内的私网 IP 地址，由 cloud-dpvs 实现私网 VIP 到 IDC 网络地址的映射，其映射关系和后端 Real-Sever 对用户无感知。

虚拟信息表由 vxlan、虚机 IP、虚机 MAC 以及宿主机 IP 地址组成，表格式如表 2 所示：

   表 2：虚拟信息表

在虚拟化 VPC 网络中，由于用户可以按需自定其私有 IP 地址，所有不同 VPC 内的虚机 IP 地址可能存在重复，故无法以 IP 地址来唯一确定一台服务器或者虚机，在 cloud-dpvs 的实现中采用了 Vxlan+虚机 IP 的方式来表示虚机或者服务器。

VPC 内的虚机访问 VIP:vPort 的流量通过 OVS 内流表规则引流到 Vxlan 隧道后流量到达 cloud-dpvs 网关，网关根据查询服务信息表查询服务挂在的后端 Real-Server,然后再根据一定的调度算法把流量分发给具体的 Real-Server 服务器，具体路径如下图 7 所示：

图 7

流量路径说明： 

增加 VXLAN 模块

云化场景下，所有来自 VPC 的请求都进行了 VXLAN 封装。CLOUD-DPVS 在转发层实现了 VXLAN 模块，用于解封 VPC 发来的 VXLAN 数据包，保证转发给 IDC 中服务器的为解封后的数据包，使得后端服务器对于 VPC 无感知。当后端服务器回包到达 CLOUD-DPVS 后，再由 CLOUD-DPVS 封装好 VXLAN 头部并转发给 VPC。

CLOUD-DPVS 后续工作

目前 CLOUD-DPVS 打通了 VPC 到 IDC 的路径，后续将继续实现 IDC 到 VPC 的打通。目前 VXLAN 模块是在转发层软件实现，下一步会计划使用智能网卡实现 OFFLOAD 相关工作。

参考文章：

1. https://github.com/iqiyi/dpvs

2. https://yq.aliyun.com/articles/497058

3. https://tools.ietf.org/html/rfc5880#section-6.8.5

本文转载自：360 技术（ID：qihoo_tech）

原文链接：基于DPDK实现VPC和IDC间互联互通的高性能网关