如前文中所述,SR-IOV 通过直接从 VNF 访问物理 NIC 来提供较高的网络吞吐量。使用 SR-IOV 的 VNF 需要 VF 驱动程序来支持特定物理 NIC,这导致虚拟机监控程序一端缺少软件抽象。在 OVS-DPDK 中,VNF 不需要任何驱动程序来知晓所采用的物理 NIC,因而能提供所需的抽象。SR-IOV 仅限于 PF 所支持的 VF 数量。总体而言,OVS-DPDK 版本 2.6 具有以下适用于 NFV 的增强功能:
提供巨型帧支持。
提供多队列 vhost-user
端口支持。vhost-user
多队列允许虚拟机中的一个 vNIC 存在多个传输和接收队列。
支持实时迁移。
支持安全组。
OVS-DPDK 提供一个名为 testpmd
的应用,可用于检查基于 DPDK 的不同网络设备的性能和功能。该应用随 dpdk 软件包分发。testpmd
的主要用途是在基于 DPDK 的网络设备上的以太网端口之间转发数据包。这使得用户可以测试不同网络工作负载下的网络吞吐量和功能。
红帽已经为 OVS-DPDK 测试了下列原装 Intel NIC:82598、82599、X520、X540、X550、X710、XL710、X722。
在另一个实例上运行 iperf3 客户端。
将报告的网络带宽与非 DPDK 实例的数据相比较。
OVS-DPDK 实例报告的网络带宽应当高于非 DPDK 实例。
DPDK的主要优势是提高吞吐量、降低延时。接下来,我们看一下实测效果。
一套OpenStack,我们使用其中两个计算节点。第一个节点有DPDK,上面有两个VM。第二个节点没有DPDK,有两个VM。接下来测试。
我们看到,DPDK的吞吐量是非DPDK的三倍。
最后,我们展示一个比较完整的在OpenStack上为VM分配DPDK网络的步骤。
验证 compute0 节点上的 NUMA 配置。
以 root 用户身份登录 compute0。
[root@compute0 ~]# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3
node 0 size: 9999 MB
node 0 free: 732 MB
node distances:
node 0
0: 10
确保配有 OVS-DPDK 端口的计算节点已正确调优。
验证为 compute0 节点传递的内核参数。确保 isolcpus 和 hugepages 参数已正确定义。
[root@compute0 ~]# cat /proc/cmdline
这里我们稍微展开介绍一下isolated_cores:
为了给应用程序线程提供尽可能多的执行时间,你可以隔离CPU,这意味着尽可能多地从CPU上删除无关的任务。隔离CPU通常包括
删除所有用户空间的线程。
删除任何未绑定的内核线程(绑定的内核线程与特定的CPU绑定,可能无法移动)。
通过修改系统中每个中断请求(IRQ)编号N的/proc/irq/N/smp_affinity属性来删除中断。
也就是说,cpu core 1,2,3留着给DPDK用。
确认 OVS-DPDK 已初始化,并且属性已设置。另外,还要验证 DPDK 接口类型受到当前 OVS-DPDK 部署的支持。使用 ovs-vsctl 命令,确保 OVS-DPDK 已初始化,并且它的其他参数也已设置。
使用 crudini,检查 NUMATopologyFilter
过滤器已添加至 /etc/nova/nova.conf
中的 scheduler_default_filters
选项。
确保已使用 dpdk物理网络创建了一个内部网络,并且一个端口已作为接口附加至 router1 路由器。
启动名为 dpdk-server1
的实例,该实例使用 default
类别和 dpdk-net1
网络。注意 OS-EXT-SRV-ATTR:instance_name
和 OS-EXT-SRV-ATTR:hypervisor_hostname
字段的值。在以下输出中,compute0.overcloud.example.com
虚拟机监控程序上已启动了 instance-00000008
实例。
将 172.25.250.101
浮动 IP 地址关联到 dpdk-server1
。
原文链接:https://mp.weixin.qq.com/s/FSNp-vSivPhgKBe2u13qJQ