英语原文共 4 页，剩余内容已隐藏，支付完成后下载完整资料
在Docker下运行带TSO功能的OVS-DPDK
牟惠阳* 黄一华%
*中国广州中山大学信息技术学院
yangmh23@mail2.sysu.edu.cn
%中国广州中山大学电子信息技术学院
huangyih@mail.sysu.edu.cn
摘要：网络功能虚拟化（NFV）的目标是使用标准IT虚拟化技术将网络工作功能从专用和专用网络设备中分离出来，并使用标准x86体系结构来执行这些网络功能。在NFV场景中，虚拟交换机用于为虚拟网络功能（VNF）或虚拟机（VM）提供数据交换服务和传输功能。开放式虚拟交换机（ovs）是现有虚拟交换机解决方案中一种高质量、广泛使用的开放源码虚拟交换机，但其性能不能满足目前千兆网络的需求。为了克服这一限制，数据平面开发工具包（DPDK）已集成到OVS中，以利用绕过内核空间以获得高性能的能力。但目前的OVS-DPDK暂时不支持TCP段卸载（TSO）功能，需要vm的cpu来完成较大的包碎片。另外，OVS-DPDK不方便部署在不同的环境中，二次开发也比较麻烦。本文将OVS-DPDK与轻量级虚拟化技术Docker相结合。此外，我们还启用了TSO功能。实验数据表明，采用TSO特性的OVS-DPDK在Docker下可以显著提高系统的性能。
关键词：NFV；OVS；DPDK；TCP段卸载；DOCKER
- 引言
目前，将传统的网络功能与专用的网络设备脱钩，利用普通的网络计算或存储设备来实现这些功能是网络发展的趋势。网络功能虚拟化（NFV）[1]起源于电信运营商。NFV的初衷是通过符合行业标准的高性能、大容量、标准硬件，而不是通过专用设备，使用标准IT虚拟化技术提供网络功能。在这个平台上，软件定义的网络功能可以在不同的网络位置上任意创建、迁移、备份和删除，而不需要改变物理设备的部署。
网络功能虚拟化基础设施（NFVI）是虚拟交换机的重要组成部分。虚拟交换机是运行在同一数据中心（DC）或跨DC上的软件模块，用于连接虚拟机或VNFS。虚拟交换机有许多开源和商业版本，如：OVS[2]、INDIGO虚拟交换机[3]、OPENCONTAIL[4]、LAGOPUS[5]、MSWITCH[6]等，我们的分析基于OVS，因为它的可用性、成熟的体系结构和广阔的开发空间。但OVS也存在缺陷：传统的OVS工作在内核空间下，因此运行在同一个DC上的虚拟机传输的数据包必须在内核空间和用户空间之间多次移动，严重降低了吞吐量，增加了延迟。为了克服这个缺点，英特尔开发了一个用户空间虚拟开关OVDK[7]，它将数据平面开发（英特尔 DPDK）[8]集成到OVS中。
与标准的Linux内核网络栈相比，由一组用于高性能数据包处理的开放源代码API和驱动程序组成的DPDK可以绕过内核（Linux或FreeBSD）网络栈以获得更高的性能。DPDK提供了用于高速数据包处理、无锁缓冲环、零拷贝方法和多核处理的轮询模式驱动程序（PMD）。开发人员不仅可以开发各种类型的高速网络应用，还可以集成各种商用数据平面交流加速解决方案。DPDK由用户空间中的许多库组成，包括核心库、平台、PMD本机 amp;VIRTUAL、QOS、包转发分类和其他主要类别，如图1所示。用户可以使用这些独立的库进行二次开发。
图1 英特尔DPDK体系结构
OVS-DPDK（Intel DPDK加速的开放式VSwitch）是基于DPDK的加速思想来转换和优化本机OVS架构的。它将数据包处理从内核空间移动到用户空间，降低了CPU的消耗，在虚拟机到虚拟机或主机到虚拟机的情况下实现了零拷贝，提高了网络的传输性能。但是，在服务器上直接部署OVS-DPDK仍然存在一些缺点，如：（1）部署应用程序需要很长时间；（2）OVS-DPDK严重依赖于编译环境；（3）应用程序开发和维护困难。此外，传统的物理网络设备严格限制了数据帧的大小，大型以太网帧（大于网络MTU，1500字节）在传输前需要划分为多个帧。TCP分段卸载（TSO）是一种功能，它使Linux内核网络栈能够将大型以太网帧推送到网卡（NETWORK INTERFACE CARD），然后通过网卡进行TCP分段，以减少CPU负载。在[9]中，作者描述了TSO技术是一种降低CPU功耗的好方法。最新的OVS-DPDK没有实现TSO功能，因此大型以太网帧在被推送到OVS-DPDK之前仍需要被软件分割，这种方法不仅会增加VM的CPU负载，而且会影响网络传输的性能。
- 设计思想
为了克服在物理主机上直接部署OVS-DPDK的困难，使用了一个名为Docker[10]的虚拟容器。与其他虚拟化技术相比，Docker不需要虚拟机监控程序来实现硬件虚拟化，在Docker下运行的软件能够直接利用物理机的硬件资源。因此，Docker在CPU和内存利用率方面具有一定的优势。在[11]中，作者比较了Docker、虚拟机和物理主机的计算效率。结果表明，Docker对CPU和内存性能的开销可以忽略不计。此外，在NFV场景中，在同一物理主机上运行的虚拟机通常需要大量的数据通信（例如，ftp），因此虚拟机之间交换的数据包不必通过物理网络工作设备传递。换句话说，在同一主机上运行的虚拟机之间交换的数据包本质上是主机上的一种内存拷贝。这可以用图2来解释，例如，如果vm1需要将数据传输到vm2，vm1只需要将数据传输到OVS-DPDK，则OVS-DPDK将数据传输到vm2。理论上，vm1和vm2之间交换的数据包的大小不应受到网络MTU值的限制。但是如上所述，OVS-DPDK目前不支持TSO特性，即TSO特性将在编译前自动禁用。因此，在同一主机上运行的虚拟机之间数据交换的最大包大小仍然受到MTU的限制。为了打破MTU限制，将最大帧长度增加到64K字节，我们强制在OVS-DPDK编译过程开始时启用TSO功能。然后通过发送方虚拟机将大型以太网帧直接发送到OVS-DPDK，再通过零拷贝技术由OVS-DPDK传输到接收机，大大提高了网络传输性能。
- 详细设计及性能评价
本部分首先阐述了在Docker下运行的OVS-DPDK的设计思想和原理，然后介绍了实验平台的建立，最后对实验方法和结果进行了讨论和分析。在这里，我们的性能测试关注两个参数，即吞吐量和延迟。
图2 试验台说明
- 详细设计
图2显示了系统架构的设计。OVS-DPDK在编译时有两种模式可供选择，即IVSHMEM（VM间共享内存设备）和vhost用户。如图2所示，DPDK的IVSHMEM库允许将多个Hugepage映射到单个IVSHMEM设备。主机和虚拟机可以同时访问共享层的数据，减少了内存复制次数，是最有效的数据传输方式。为了达到最佳性能，我们的设计采用了IVSHMEM模式。为了方便主机与在docker下运行的OVS-DPDK之间的交互，使用docker的数据卷机制。然后，容器可以使用主机HUGEPAGE文件系统，同时容器ER下的OVS-DPDK创建的网桥端口可以通过主机的VMS连接。由于当前的OVS-DPDK不支持TSO功能，TCP段应由VM承担。然而，在一般的NFV场景中，虚拟机之间的数据传输同一物理主机不需要通过物理NIC。在这种情况下，OVS-DPDK可以将大帧（大于1500字节）直接传输到VMS，这将大大降低CPU的负载，并给网络传输性能带来很大的好处。为了观察强制启用TSO功能后，在物理主机和Docker上运行的OVS-DPDK的性能，我们修改了两个功能，即virtio-net-f-u-host-tso4和virtio-net-f-csum，由OVS-VHOST后端支持，然后将包的最大大小从1500字节增加到64K字节。因此，虚拟机发送的大帧可以直接到达OVS-DPDK，而不必被软件分割。
- 试验台说明
在这个实验中，主机的处理器配置是Intel Core i7-4790（3.6GHz），总共有8个内核（加上HY-PERTHREADING、8MB缓存）和8GB的RAM（DDR31600MHz）。带有Linux内核4.4.0和Docker 1.12.4的UbuntuXenial16.04[LTS]64位安装在物理主机上。我们的代码基于OVS 2.6.1和DPDK 16.07.1。两个虚拟机使用QEMU-KVM（2.5版）虚拟化技术，每个虚拟机在启动时配置两个逻辑CPU，1GB RAM和1GB Hugepage。一个虚拟机充当服务器，另一个虚拟机充当客户端，向服务器发送网络请求。为了保持一致性，Docker容器使用Ubuntu 16.04作为基映像，两个虚拟机也使用Ubuntu 16.04作为操作系统。
- 实验结果与讨论
对不同包大小（小于1500字节）的OVS-DPDK在Docker和主机下进行了吞吐量测试。从图3可以看出，docker下的OVS-DPDK几乎可以达到与物理主机相同的性能（例如，对于64字节的PACK-ETS，Docker吞吐量为1415Mbps，而物理主机吞吐量为1418Mbps）。此外，随着包大小的增加，吞吐量呈线性增长。这种现象的解释是，每个包（小于1500字节）的VMS处理时间几乎相同，因此随着包大小的增加，单位时间内传输的数据量也会增加。此外，Docker下的OVS-DPDK在64、256、512和1024字节上的性能非常好，但在数据包大小等于或大于1500字节时（例如，主机上：8000Mbps，Docker下：7800Mbps，图4中也存在同样的情况），性能稍差。这种开销可能来自额外的CPU周期和Docker处理巨型帧时的I/O操作。
图3 性能比较（小于1500字节的数据包）
图4 性能比较（从2K到64K字节的数据包）
图4描述了在传输巨型帧时，TSO特性对吞吐量的影响。当包大小为2K字节时，TSO特性对性能的影响不明显。OVS-DPDK在主机上的吞吐量约为13Gbps（TSO开启）和8Gbps（TSO关闭），Docker下的OVS-DPDK的吞吐量约为10Gbps（TSO开启）和9Gbps（TSO关闭）。可能的原因是，尽管此时虚拟机已经打开了TSO功能，但是CPU仍然有足够的资源来完成TCP分段（2K字节），因此TSO功能对性能的影响很小。当数据包大小超过2K字节，而虚拟机关闭TSO功能时，物理主机和Docker的吞吐量略有增加，当数据包大小大于8K时则趋于平稳（约12Gbps），性能瓶颈来自于TCP分段的开销。但是，在打开TSO功能之后，当数据包的大小是MTU的两倍（3K字节）时（1500字节），吞吐量得到了极大的提高。当数据包大小约为4K字节时，OVS-DPDK的主机级吞吐量为关（40Gbps），而当数据包大小约为8K字节时，Docker级吞吐量为关（38Gbps）。这种情况的原因是发送方虚拟机不需要将大帧划分为多帧，然后大帧可以通过OVS-DPDK快速传输到接收方虚拟机。
图5 TSO对延迟的影响（对物理主机）
图6 TSO对延迟的影响（在Docker下）
图5显示了TSO对延迟的影响（在物理主机上），图6显示了TSO对延迟的影响（在Docker下）。显然，OVS-DPDK对物理主机和OVS-DPDK在Docker下的延迟几乎相同：当vm发送小数据包ETS（小于1K字节）时，延迟水平降低（约6mu;s），因为虚拟机解析数据包（小于1500字节）的能力几乎是恒定的，它们的平均延迟是稳定的。但是，当数据包的大小超过1500字节时，延迟开始呈指数增长。最大延迟分别为45mu;s（tso关闭）和25mu;s（tso打开）。但是，当数据包的大小从1500字节到64K字节时，TSO功能打开时的平均延迟低于TSO功能关闭时的平均延迟。这可以由两个原因来解释：第一，巨型帧会影响OVS-DPDK的性能；第二，在巨型帧的分割上，花费了更多的CPU资源和虚拟机内存。第二个原因导致了网络性能的主要开销。
- 结论
本文提出了一种设计思想，使OVS-DPDK能够在虚拟化容器码头内运行，并在启用TSO功能时评估网络性能。从实验结果可以看出，与物理主机上的ovs-dpdk相比，Docker下的ovs-dpdk对吞吐量和延迟的影响可以忽略不计。另外，docker除了具有稳态性能外，还具有启动快、部署方便、测试方便、二次开发能力强等一系列优点，而且ovs-dpdk不仅可以部署在各种环境中，还可以作为一种docker镜像，通过单一的服务在网络的任何部分进行部署。ER到整个数据中心。TSO是一种可以从物理网卡上卸载TCP碎片功能的技术，它可以显著降低CPU的过载。在我们的实验中，当两个虚拟机上都启用了TSO功能时，发送方虚拟机直接将大数据包转发给OVS-DPDK，然后OVS-DPDK使用零拷贝技术将完整的数据包传递给接收方虚拟机。实验结果表明，在传输巨型帧时，本文提出的方法可以有效地提高网络的吞吐量，大大降低网络延迟。
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[19928]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
