DPDK全称为Date planedevelopment kit,是一个用来进行数据处理加速的软件库。与传统的数据包处理相比,DPDK具有以下特点:
1) 轮询: 在处理时避免中断上下文切换的开销,
2) 用户态驱动: 规避不必要的内存拷贝和系统调用,便于快速迭代优化
3) 亲和性与独占: 特定任务可以被指定只在某个核上工作,避免线程在不同核间频繁切换,保证更多的cache命中
4) 降低内存开销: 利用内存大页HUGEPAGE降低TLB miss,利用内存多通道交错访问提高内存访问有效带宽
5) 软件调优: cache行对齐,预取数据,多元数据批量操作
DPDK框架
![](/uploads/477d572e-8287-4e21-81bf-539181315080.jpg)
原型设计
针对这些问题,经过技术调研,也参考了国内外同⾏的已有解决方案,在过程中和 Intel 团队紧密合作,我们采用 OVS-DPDK 进⾏开发部署,并最终取得了不错的效果。如下是数据流模型:
![](/uploads/b88b3e65-6101-4255-97b1-989bb14ef500.jpg)
数据层面的⼏个重要改造
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 功能,因此我们这部分的实现是⽆状态的。这个拆解,特别是无状态的特性,在热升级的时候取得了不错的效果。
![](/uploads/4bc59509-973b-4eed-a4f3-c617d532618a.jpg)
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 的影响,为以后升级和迁移做准备。
方案优势
![](/uploads/4ed4584b-84e8-46bb-8566-0448492d3d47.jpg)