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

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

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

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

图2

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

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模式。

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

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

为实现其转发功能，在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

流量路径说明： 

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

目前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