基于OVS-DPDK,的docker,网络性能提升方案*

涂俊亮，陈 伟

（中国电子科技集团公司第三十研究所，四川 成都 610041）

当前，云服务商大多采用虚拟交换机来管理、隔离不同租户间的通信[1]，应用最广泛的是Nicira公司的开源虚拟交换机（Open vSwitch，OVS）项目[2]。OVS 具备基础的网络隔离和报文转发功能，但在大网络流量下存在性能瓶颈。OVS 对报文的接收、处理主要在内核态进行，操作过程中内存会多次移动或拷贝报文，浪费内核资源，导致转发效率低下。此外，OVS 组网时，多容器（docker）的网络并发性能不佳，带宽分配不均匀。因此原生OVS 难以满足大规模云平台对网络边缘设备的性能需求。

英特尔公司推出的数据平面开发包（Intel Data Plane Development Kit，DPDK）[3]为用户态快速处理数据包提供了丰富的库函数和灵活的驱动支撑。DPDK 结合OVS 后，性能变得高效且方便开发，但直接部署还存在一些困难，如环境相关性高，运维困难，且对传输控制协议（Transmission Control Protocol，TCP）分片卸载的支持度不高。TCP 大包需要先分片变小后才能被送至网卡，导致虚拟机负载加剧，网络传输性能降低[4]。有研究表明，将OVS-DPDK 部署在docker[5]环境中会明显改善性能，因为在容器中，OVS 共享宿主机文件系统，宿主机和虚拟机间的连接采用OVS-DPDK 的桥接端口，从而无须通过物理网卡，TCP 分片卸载问题也不复存在。因此，本文选择在docker 环境下研究OVSDPDK 提升网络性能的效果。

本文首先介绍OVS 和DPDK 的原理及核心技术；
其次针对实验瓶颈，利用二者联合部署解决；
最后，从3 层转发、应用层传输两方面进行测试，研究OVS+DPDK 在生产环境中的优缺点及优化方向。

1.1 OVS 结构

OVS 由核心组件ovs-vswitchd、数据库组件ovsdb-server、内核模块openvswitch.ko 3大要素构成，结构如图1 所示。

图1 OVS 内部组成

ovs-vswitchd 是OVS 的核心模块，在用户空间运行，负责地址学习、物理端口绑定、逻辑转发等基本功能。可利用OVS 自带的工具ovs-ofctl，基于openflow 协议进行交换机配置管理。

ovsdb-server 是存储OVS 配置、状态和日志等信息的轻量级数据库服务，ovsdb 是一个可持久化的数据库，交换机的配置信息均保存在其中，即使设备掉电也不会丢失。ovsdb-server 与ovs-vswitchd间采用OVS 数据库（OVS Data Base，OVSDB）管理协议通信，其内容包含但不限于配置信息加载、运行过程中变化的OVS 相关信息。

openvswitch.ko 组件作为快速转发平面运行在内核空间，实现修改报文、匹配流表、封装隧道、维护转发表等功能。在OVS 中，报文先经该组件封装或解析，然后进行转发规则匹配，匹配成功则直接转发，否则转交给用户空间的ovs-vswitchd 组件处理。它与ovs-vswitchd 采用NetLink 协议规范进行内核态和用户态进程间的通信。

1.2 OVS 网络应用

OVS 以软件形态存在于虚拟网络中，角色类似于物理交换机，具有局域网划分、隧道搭建、路由模拟3 大功能，其典型网络应用如图2 所示。图中虚拟交换机OVS0 是中心交换机，作为网络中心连接OVS1、OVS2、OVS3、OVS4 这4 个边缘交换机。边缘交换机与虚拟机直连，负责同网络的虚拟机间通信和跨网络的虚拟机间包转发。

1.2.1 局域网划分

通过划分虚拟局域网（Virtual Local Area Network，VLAN），可以实现同网络的虚拟机间局域网隔离。通过给中心交换机端口配置不同的VLAN 号，使边缘OVS 属于不同VLAN，隔断边缘OVS 间二层通信，实现跨网络的虚拟机间局域网隔离。本文便是利用该功能实现docker 间网络隔离。

1.2.2 隧道搭建

边缘OVS 可搭建隧道。在虚拟扩展局域网（Virtual Extensible Local Area Network，VXLAN）隧道应用中，OVS 能实现其中的由虚拟网段隧道终结点（VXLAN Tunnel End Point，VTEP）负责的VXLAN 报文解析封装、转发、地址学习等功能[6]。

1.2.3 路由模拟

OVS 结合控制器可模拟路由转发功能，实现在不同局域网中主机的数据转发。图2 中虚拟机B和F 所直连的边缘OVS（OVS1 和OVS3）属于两个局域网，不能进行二层转发。配合控制器，首先，将局域网中的地址解析协议（Adress Resolution Protocol，ARP）报文上报到控制端；
其次，控制端感知OpenFlow中网络节点，获得所有设备网络信息；
最后，将对应ARP 流表下发到OVS 上，有了流表信息，不同局域网的主机B 和F 便可通信。

图2 OVS 在网络中的应用

1.3 OVS 与网桥对比

相较于网桥（Linux-Bridge），OVS 图形化工具更方便管理员对云环境中的网络状态、数据流量等信息进行监管。相比网桥单纯基于媒体访问控制（Media Access Control，MAC）地址学习的转发规则，OVS 引入流缓存机制，可提高数据包转发效率。网桥仅支持通用路由封装隧道，OVS 则支持更多的隧道协议，如VXLAN、互联网安全协议（Internet Protocol Security，IPsec）。此外，OVS 作为软件定义网络（Software Defined Network，SDN）生态的一部分，其扩展性更高和应用范围更广。

OVS 也存在局限，其稳定性和可靠性不及网桥，其复杂的内部结构导致OVS 安装复杂、运维困难，并且OVS 与操作系统的集成友好度也不如网桥。

2.1 DPDK 特点

DPDK 的设计理念是基于通用服务器，采用软件方式优化，以代替原用于网络设备的专用网络处理器。经过多次适配迭代，DPDK 目前已支持x86、精简指令集机器（Advanced RISC Machine，ARM）、无内部互锁流水级的微处理器（Microprocessor without Interlocked Piped Stages，MIPS）等架构，应用广泛[7]。DPDK 的主要技术特点有：

（1）用户态输入/ 输出（Userspace Input/Output，UIO），直接在用户态实现网卡I/O，实现零拷贝数据。

（2）CPU 预分配、并行处理，内存无须多次申请和释放，缓存高效工作，包时延锐减。

（3）CPU 和程序亲和性关联。把不同CPU 核与控制面及数据面线程绑定，减少核间切换，并调度热点代码段一直处于高速缓存中。

（4）无锁（LOCKLESS）环形缓存管理，去掉锁开销。

（5）内存大页方案，增大程序基础内存块容量，提高缓存命中和访问内存效率。

（6）轮询驱动（Poll Mode Driver，PMD）。用户态轮询，减少中断沉睡唤醒、上下文切换开销。

2.2 DPDK 架构

DPDK 是由在用户空间运行的数据处理、访问底层硬件资源与内核通信等接口库组成的集合，其内部结构如图3 所示。

图3 DPDK 库结构

样例App、用户App和独立软件开发商（Independent Software Vendors，ISV）系统App 作为应用运行在顶层。中层是各种库函数，其中核心库提供内存池、无锁环和大页内存等基础功能；
扩展库函数提供扩展功能，如定时器；
PMD 库匹配原生和虚拟网卡，通过轮询、线程绑定等技术获得网卡高速转发性能；
Classify 支持如前缀最长匹配、通配符匹配的查表操作；
QoS 库提供网口限速、流控和调度等功能。底层的内核网卡接口（Kernel NIC Interface，KNI）、虚拟功能输入输出（Virtual Function I/O，VFIO）等技术将I/O、直接存储器访问（Direct Memory Access，DMA）、中断等内核功能安全有效地向上提供给用户空间调用，并支持将报文向下注入内核协议栈。

2.3 DPDK 关键技术

本文的性能提升主要涉及UIO、内核网卡接口（Kernel NIC Interface，KNI）、PMD 技术，具体如下文所述。

2.3.1 UIO 技术

UIO 用户空间I/O 技术是指把内核中的大部分I/O 功能迁移至用户态完成，即绕过内核协议栈，直接从网卡收发数据包，减少内核资源消耗，其工作原理如图4 所示。

图4 UIO 技术工作原理

设备驱动由内核空间驱动和用户空间驱动组成，内核空间只负责UIO 设备注册、资源分配及少部分中断，其余大部分驱动工作在用户空间中完成。利用接口将UIO 驱动注册到内核后，会生成一个含有设备物理地址信息的地图文件，用户进程读取此文件，将内核空间地址映射到用户空间。操作用户空间便等同于直接映射操作其内存空间，以此避免数据在内核缓冲区和应用程序缓冲区的多次拷贝。

2.3.2 KNI 组件

KNI 组件能将数据重入内核协议栈，高效利用传统内核协议栈已有的成熟功能。DPDK 对包的处理旁路了内核，若在用户空间构建一套新的完整独立的协议栈是很复杂的；
因此，可以在用户空间实现某些特殊的协议功能，再利用KNI 重载进入内核，而常用的普通协议无须重复造轮。KNI 通信机制如图5 所示。

图5 KNI 通信机制

虚拟网卡上的KNI 虚拟接口是用户空间和内核协议栈间通信的桥梁。网卡收到的数据包通过应用程序转发到用户空间，再通过KNI 虚拟接口到达内核协议栈进行处理，处理后若有响应报文，则再交由KNI 虚拟接口返回给应用程序。通信中的发送线程及接收线程，由两个逻辑核（如图5 所示CoreA0和CoreB0）独立处理，从而达到互不阻塞、提高效率的目的。

2.3.3 PMD 轮询

PMD 提供了一系列高优先级的配置设备、队列的接口，还能以屏蔽中断的形式访问、发送和接收描述符，因此用户态应用可以实时地收发包，甚至以最高优先级处理包。通过PMD 的轮询机制从网卡收包，屏蔽了中断，提高了大流量下的实时效率。显然这也导致CPU 核的占用率一直很高，不够节能，且不能直观看到CPU 负载状况。

3.1 实验环境介绍

在万兆服务器上创建多个虚拟机（docker），提供租户隔离的云服务，每个docker 上运行业务服务端程序，期望在高并发下获得高效的网卡性能。网桥部署下的实验场景如图6 所示，实验环境相关信息如表1 所示。

图6 网桥部署下的实验环境

表1 实验环境信息

测试端n个用户t1～tn通过运行业务客户端程序，访问对应的虚拟机docker-0～docker-N。虚拟机配置双网卡，分别桥接到服务器的bridge-0和bridge-1，两个桥分别绑定在实际网卡Net-0 和Net-1 上，网络包从一个网口进入虚拟机，从另一个网口返回客户端。为充分测试性能，客户端上业务程序均是多线程满负载并发执行，统计此情况下随着测试客户端的增加，物理网卡Net 上的总带宽和服务器的CPU 占用率。实验数据如图7 所示。

图7 不同docker 数时带宽和CPU 占用率

由图7可知，采用桥接模式时，随着docker增加，CPU 占用率逐渐增大，总网卡带宽在docker 为5 时达到峰值8.9，随后呈现下降趋势，无法达到万兆标称值，且单个docker 的带宽分配也不均匀，存在随机性。此外随着docker 增加，服务器上线程呈倍数级上涨，中断过多，任务切换开销大，内核负载增加，然而实验中发现内存使用并未显著增加；
因此，当前瓶颈主要在CPU。基于DPDK 网络性能优势，考虑采用OVS-DPDK 组网。

3.2 OVS-DPDK 改进方案

本文设计的OVS-DPDK 架构如图8 所示。系统自下而上由OVS 内核态进程、DPDK 平台管理层、用户空间协议栈、OVS 用户空间核心进程共4 个模块组成。OVS 内核进程负责内核态报文转发和流表匹配。OVS 用户空间的核心进程负责用户态包传递，将报文传入用户空间协议栈，然后根据用户态流表匹配返回的结果进行相应处置（转发或丢弃）。用户空间协议栈则按各层协议进行封装或解析。

改进重点在于加入了DPDK 平台管理层，承上启下，对上层模块屏蔽底层硬件资源，并通过对上层提供接口实现对底层资源如内存、网卡、缓存等的管理。

如图8 所示，图中标注“1”“2”“3”的位置代表主要模块间的交互。

图8 基于DPDK 平台的OVS 架构

“1”表示数据收发管理线程和用户空间协议栈交互，涉及包发送或接收，报文按协议封装或解析。“2”中用户空间协议栈处理报文时，向网络缓存管理模块申请报文缓存区，用完后立刻释放，提高内存使用率。“3”中数据收发管理线程和流表匹配模块交互，依据报文头匹配结果进行相应的返回操作，本文设计流表能加快包在用户态转发，且旁路内核。

本文所提OVS-DPDK 架构与原生OVS 的区别在于，OVS-DPDK 架构指定CPU 核，通过OVS 配置的端口收到数据包，报文跳过内核态openvswitch.ko 操作，经DPDK 轮询机制直接实时送达用户态ovs-vswitchd 里处理。原生OVS 和OVS-DPDK 包交换对比如表2 所示。

表2 原生OVS 和OVS-DPDK 的比较

本文实验中使用到的关键软件版本为OVS(v2.8.0)+DPDK(v16.11)，OVS-DPDK 环境安装和配置过程简述如下：

（1）相关编译环境、依赖库安装，包括但不限于gcc、libpcap、libnet 等。

（2）确定网卡型号是否支持DPDK，脚本为：lspci -nn |grep Ethernet #得到网卡类型为“xxx”进入dpdk目录，grep --include=*.h -rn -e ‘xxx’

（3）编译安装OVS 和DPDK。

（4）操作系统配置：

①系统BIOS 需打开VT-d，并通过grub 配置iommu 和intel_iommu 参数来支持VFIO 驱动；

②配置大页，系统每个page 默认占2 MB，本文配置1 000 个大页，大页共占用2 GB 内存。

（5）设置dpdk 驱动，脚本为：

modprobe vfio-pci #加载dpdk 驱动

网卡绑定到dpdk dpdk-devbind --bind=vfio-pci enp4s0f1（网卡名）

（6）启动OVS 进程。

（7）初始化DPDK，开启DPDK 功能。从ovs-v2.7.0 开始，不能通过vswitchd 进程启动时指定DPDK 等参数开启DPDK 功能，需通过设置ovsdb 来实现。主要配置3 个参数，具体如下：

ovs-vsctl --no-wait set Open_vSwitch .other_config:dpdk-init=true #设置dpdk 初始化启动

ovs-vsctl --no-wait set Open_vSwitch .other_config:dpdk-socket-mem=”2056,0” #指定的sockets 从大页预先分配的内存，大小为2 GB

ovs-vsctl set Open_vSwitch .other_config:pmdcpu-mask=0x02 #指定在某些core 上运行，该命令表示在02 号核上运行

（8）配置OVS，主要有创建OVS 网桥、网桥上新增DPDK 端口、配置模式，连接控制器、新增流表等。本文使用vhostuser 方式配置，主要脚本摘录如下：

创建两个dpdk 的虚拟桥

ovs-vsctl add-br br0 --set bridge br0 datapath_type=netdev

通过mac 地址接管网卡，并加入到br0 中

ovs-vsctl add-port br0 dpdk0 --set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:04:00.1

使用vhostuser 配置

ovs-vsctl add-port br0 vnic0 --set Interface vnic0 type=dpdkvhostuserclient options:vhost-server-path=/tmp/dpdkvhostclient0

（9）创建docker，配置其网络，进行实验。

5.1 OVS-DPDK 的3 层转发能力测试分析

本文主要使用OVS_DPDK 的3 层转发能力，先使用DPDK 自带的收发包测试工具进行3 层转发测试。OVS+DPDK 3层转发测试平台拓扑如图9所示。

如图9 所示，服务器1 作转发服务器，服务器2 作测试服务器。在服务器1 上安装OVS+DPDK，创建并启动虚拟机，配置vhost-user 接口模式，并与虚拟机网口对应绑定连接到虚拟交换机上。虚拟机中安装DPDK 自带的3 层转发应用程序DPDK L3 Forwarding，它能实现3 层IP 间的包转发。修改OVS 流表规则配置，将eth0 上的包转到Vhostuser1 口，L3 Forwarding 可配置两个虚拟网卡的IP分别为192.168.1.1 和192.168.1.2。服务器2 上安装收发测试应用程序Pktgen。测试过程中数据包的流向：服务器2 PDK Pktgen—eth0 —Vhost-user1—virtio—L3 Forwarding—virtio—Vhost-user2—eth1—服务器2 DPDK Pktgen。闭环返回到Pktgen 应用程序中，并由其度量性能。

图9 OVS+DPDK 的3 层转发能力测试拓扑

测试转发大小递增的数据包，转发性能统计数据如表3 所示。

表3 不同大小包下3 层转发性能统计

测试结果表明，在3 层包的处理上，OVS+DPDK 比OVS+linux kernel 有明显性能提升。原生OVS 在小包转发时出现丢包现象，而OVS+DPDK在测试中未出现该现象，这得益于PMD 和大页内存的使用，提高了OVS 的收包能力。OVS 结合DPDK 后在3 层转发性能上是原生OVS 的4～7倍，当包大小为256 byte 时，性能提升最明显，且OVS+DPDK 可避免小包丢包现象。

5.2 OVS-DPDK 的应用层面能力测试分析

基于以上理想状态下的测试结果，在实际业务应用层面上进行性能测试，实验网络拓扑参考图7配置，将linux-bridge 模式换成OVS+DPDK 部署，使用单CPU 双核心模式，进行业务并发测试，结果如表4 所示。

表4 不同配置下的网络性能测试统计

数据绘制在双坐标轴中如图10 所示。使用OVS-DPDK 在容器数量从1 增加到10 的过程中，总带宽比较平稳，在9 GB 左右，网卡基本满载，CPU 的变化曲线相较网桥也更平稳，在docker 数量较少时，能高效利用CPU 性能，带宽利用也比普通桥接高8%～10%。docker 数量为10 时，OVSDPDK 带宽是网桥的1.3 倍，可以看出在容器数量增多的情况下，OVS-DPDK 的网卡利用性能更充分。OVS-DPDK 的CPU 占用率一直比普通桥接高，也印证了上文2.3.3 节中，CPU 核心的占用率会一直很高、不够节能的观点。

图10 OVS+DPDK 和linux_bridge 网络性能对比

给OVS 分配2 个CPU、4 个处理器逻辑核心后，OVS-DPDK 带宽测试结果可达到网桥的1.86 倍，但将核心继续增加到8 个和16 个时，OVS-DPDK带宽测试结果并没有比4 个的情况更好，这与核心数过多，任务调度消耗资源增多有关。

测试可得：在OVS-DPDK 架构下，使用virtio 驱动和vhost-user 接口配置虚拟机网卡，可有效提升网络性能，服务器网卡的性能损耗也明显降低，且在4 核时网络性能提升最大，网卡总带宽是原生桥接的1.86 倍。

DPDK 自带的3 层测试工具显示网卡吞吐率是网桥的4～7 倍，在实际应用层面上带宽只有1.3～1.86 倍，二者数值上有一定差距，吞吐率是瞬时收发性能的体现，带宽则是实际传输能力的衡量。从传输层到应用层之间还存在性能损耗，这与实验中流表配置是否合适、大页分配是否合理、包分片大小、CPU 绑定情况以及业务程序代码逻辑等均有很大关系。目前，1.86 倍的应用层带宽提升有一定效果，3 层测试工具吞吐率的4～7 倍提升是基于测试程序的底层极限性能提升，后续带宽优化到网桥的2 倍或接近万兆总带宽是可行的研究 目标。

本文首先介绍了现阶段云网络方案，分析了OVS 性能瓶颈；
其次引入DPDK；
最后根据实际业务场景进行了OVS+DPDK 和网桥的3 层转发能力实验对比。理论上OVS+DPDK 的吞吐率是网桥的4～7倍，实际业务场景下带宽则是网桥的1.3～1.86倍。DPDK 在处理高速数据报文中有较大作用，但其配置复杂，且对CPU 的亲和性有一定要求。此外，从理论上的传输层到实际中的应用层间的性能兑现还需更多研究。

部分学者提出了OVS+DPDK 的优化方向，主要有开发用户态网络协议栈、添加DPDK 中断优先级、支持动态配置大页内存[8]3 个方面。OVS+DPDK 模式为云的网络性能优化提供了有效方案，后续希望能从以上3 个方面进行深入研究，结合实际业务需求，以期在应用层面上获得更大的网络性能提升。

猜你喜欢 网卡内核报文 基于J1939 协议多包报文的时序研究及应用汽车电器(2022年9期)2022-11-07多内核操作系统综述①计算机系统应用(2022年5期)2022-06-27强化『高新』内核 打造农业『硅谷』今日农业(2021年9期)2021-07-28活化非遗文化 承启设计内核现代装饰(2021年1期)2021-03-29低轨星座短报文通信中的扩频信号二维快捕优化与实现空间科学学报(2021年6期)2021-03-09CTCS-2级报文数据管理需求分析和实现铁道通信信号(2020年4期)2020-09-21部署Linux虚拟机出现的网络故障网络安全和信息化(2020年3期)2020-04-20浅析反驳类报文要点中国外汇(2019年11期)2019-08-27微软发布新Edge浏览器预览版下载换装Chrome内核中国计算机报(2019年12期)2019-06-21Server 2016网卡组合模式网络安全和信息化(2019年1期)2019-02-15

推荐访问:提升 性能 方案