背景

滴滴云初期采⽤学习OpenStack的思路，采用内核态的OVS实现了SDN OverLay网络。这个实践过程中，我们也遇到了一些问题，可以归纳为以下几个⽅面：

性能不高
⽆法热升级
开发难度⼤
维护成本高

原型设计

针对这些问题，经过技术调研，也参考了国内外同⾏的已有解决方案，在过程中和Intel团队紧密合作，我们采用OVS-DPDK进⾏开发部署，并最终取得了不错的效果。如下是数据流模型：

| 数据层面的几个重要改造

1. 底层：⽹卡硬件相关

· 基于VF的数据流改造

借助硬件将OverLay的流量与宿主机的其他⽹络流量进⾏分离。通过flow classification命令将前者导⼊到VF上，而后者仍然是通过PF口到内核进行处理，保持原有处理逻辑不变。OVS- DPDK只接管VF⽹口，⽽不触碰PF口上的非SDN OverLay⽹络流量。这样既简化了OVS-DPDK的处理逻辑，同时也避免了因OVS-DPDK本身的稳定性，而影响其他⾮SDN⽹络模块的稳定性。

2. 中间层：OVS 报⽂处理

· 无状态的转发功能

⽬前，我们对计算节点⽹络层面的需求，可以分为两大类：VM流量的转发和VM网络的安全监控。其中后者是内部开发的，暂时略过。

针对VM流量转发的这个需求，⼜拆解为两部分：

OverLay外层头的处理，和内层报文的转发。借助OVS-DPDK的flow表实现这两部分功能。因为没有启⽤conntrack功能，因此我们这部分的实现是⽆状态的。这个拆解，特别是无状态的特性，在热升级的时候取得了不错的效果。

· OVS单网桥

之前参考OpenStack的模型，我们使⽤了br-int，br-tunnel两个网桥。在这个模型里，OVS⽹桥的使⽤方式跟传统的Bridge使⽤⽅式差别不大，没有充分发挥OVS⽹桥的优势。

在我们的模型中，把两个网桥整合为一个网桥，将vxlan⼝和vhost-user的⼝都放到⽤⼀个网桥上。VM发出的报⽂经过OVS转发处理后，携带外层头信息进入vxlan驱动，经过vxlan网口的封装后，发送给VF网口。

根据我们的数据模型，进入VF⼝的报⽂只可能是发往VM的vxlan类型的报文。这些报文，在被剥除vxlan头后，经过vxlan⼝进⼊网桥，经过⽹桥转发到各个VM的vport。

· 降低与内核的耦合性

原有的OVS桥的路由和ARP表需要去内核查询，跟内核的耦合性很强。我们通过SDN控制器下发到OVS-DPDK，来规避直接与内核的交互。这样⼀方⾯简化了Bridge的配置(不用单独设置IP地址等)，降低了内核的耦合性，另⼀方⾯也降低了热升级时候的复杂度。

3. 上层vhost-user与VM交互层

· vhost-user增强

我们使用的是QEMU作为vhost-user的Server端，OVS-DPDK进程通过unixsocket连接到QEMU。QEMU默认仅支持一个这样的连接，改造QEMU后，使得QEMU支持两个主备倒换的连接，这样热升级的时候，可以通过控制OVS-DPDK端的开关，轻松的在新⽼两个进程间切换。

· 内存模型采用2M/4k。

尽量减少对现有VM的影响，为以后升级和迁移做准备。

方案优势

1. 升级时间短

业内⽬前的热升级方案基本都是秒级的，切换时间⽐较长。而在我们的框架下，每个VM的热升级时间大约80ms左右，极大的缩短了VM的网络中断时间，基本做到⽤户无感知。

2. 可扩展性好

热升级过程中，VM⽹络中断时间跟VM规模无关。热升级的时候，我们逐个把VM的流量从⽼的OVS-DPDK进程里，切换到新的进程里。这种逐个切换的模式，使得单个VM的流量切换，不会影响其他的VM网络功能。即使上百个VM，总的升级时间达到⼏秒甚至⼏十秒的情况下，单个VM的⽹络中断时间仍然是80ms。

3. 故障恢复快

我们热升级的模型中采⽤的是两个独⽴的OVS-DPDK进程，因此提前启动一个新的OVS-DPDK进程作为后备进程，这个进程完成所有热升级相关的初始化，比如初始化vf2。这样当原有OVS-DPDK进程Crash后，新的进程可以做快速的切换，实验室环境下，单VM测试可以做到跟热升级时间差不多。

附上测试数据

性能：单核性能400wpps左右

热升级：单VM网络中断时间 80ms 左右

DPDK version：17.11

OVS version：2.9.0

QEMU version：2.9

CPU：Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz kernel:3.10.0-514.16.1.el7.x86_64

NIC：Ethernet Controller X710 for 10GbE SFP+ 1572

张军伟，网络工程师，2017年加入滴滴，负责滴滴sdn网络建设