网卡虚拟化技术：VMDq和SR-IOV

网卡虚拟化技术：VMDq和SR-IOV

时间:
2015-02-28 21:37

作者:
lsgxeva

分类:
我的笔记>>工作学习>>ADC

摘要:
网卡虚拟化技术：VMDq和SR-IOV

标签:
网卡虚拟化技术：VMDq和SR-IOV

提示:
文章均来自网络,版权为原作者所有,如有侵犯权益,请联络我们.

网卡虚拟化技术：VMDq和SR-IOV

随着云计算技术的发展，跟传统的服务器上直接跑应用相比，服务器上运行虚机，虚机里面跑应用的场景已经越来越普遍。

这种情况下，网络往往成为最关键的性能瓶颈，特别是不同虚机之间的高速网络流量如何进行有效的交换。

要解决大流量交换的问题，基本上有两套简单思路，一个是软交换，即放在服务器里面，让软件来实现，典型的代表有各种虚拟交换的解决方案，例如OpenvSwitch。

另外一个是流量对服务器透明，全部扔到服务器外面的物理交换机做，主要是现在讨论的IEEE Edge Virtual Bridging (EVB)标准，包括802.1qbg and 802.1qbh。

软交换比较容易实现。

VMM为每个虚机创建一个虚拟网卡，对应到软件交换机的一个端口。服务器的物理网卡也接到软件交换机的一个接口上。所有的交换由软件交换机完成。

这种方案的优点是虚机之间转发性能非常好，并且在软件交换机容易实现各种控制功能。但问题就是对服务器os的cpu资源消耗多，并且对外交换时容易出现性能瓶颈。

EVB标准则试图将虚机发出的所有流量都导入到外面的交换机上进行决策。优势是可以利用外面硬件交换机的性能和复杂控制特性，缺点是一进一出带宽效率低，需要改动服务器上的驱动支持。

本文来谈谈虚机跟服务器物理网卡的交互问题。

通常情况下，一个服务器上跑几十个虚机，对计算和网络的需求是很惊人的。前者促生了当下的多核技术发展，后者则不能简单的用多网卡来实现。

试想，每个虚机如果都需要10G的交换能力，服务器要配置几十块物理网卡，且不说主板是否支持这么多的接口，光成本上就难以接受。

另外，如果给vm分配的接口都是软件交换机的虚拟接口，维护这些接口和转发本身就要消耗大量的服务器计算资源。

因此，业界推出了VMDq和SR-IOV技术来提升虚机的网络性能。

VMDq

VMM在服务器的物理网卡中为每个虚机分配一个独立的队列，这样虚机出来的流量可以直接经过软件交换机发送到指定队列上，软件交换机无需进行排序和路由操作。

但是，VMM和虚拟交换机仍然需要将网络流量在VMDq和虚机之间进行复制。

SR-IOV

对于SR-IOV来说，则更加彻底，它通过创建不同虚拟功能（VF）的方式，呈现给虚拟机的就是独立的网卡，因此，虚拟机直接跟网卡通信，不需要经过软件交换机。

VF和VM之间通过DMA进行高速数据传输。

SR-IOV的性能是最好的，但是需要一系列的支持，包括网卡、主板、VMM等。

SR-IOV 简介

SR-IOV 技术是一种基于硬件的虚拟化解决方案，可提高性能和可伸缩性。SR-IOV 标准允许在虚拟机之间高效共享 PCIe（Peripheral Component Interconnect Express，快速外设组件互连）设备，并且它是在硬件中实现的，可以获得能够与本机性能媲美的 I/O 性能。SR-IOV 规范定义了新的标准，根据该标准，创建的新设备可允许将虚拟机直接连接到 I/O 设备。
SR-IOV 规范由 PCI-SIG 在 http://www.pcisig.com 上进行定义和维护。
单个 I/O 资源可由许多虚拟机共享。共享的设备将提供专用的资源，并且还使用共享的通用资源。这样，每个虚拟机都可访问唯一的资源。因此，启用了 SR-IOV 并且具有适当的硬件和 OS 支持的 PCIe 设备（例如以太网端口）可以显示为多个单独的物理设备，每个都具有自己的 PCIe 配置空间。
下图介绍了针对 PCIe 硬件的 SR-IOV 技术。

图 21-1 SR-IOV 技术



SR-IOV 中的两种新功能类型是：

物理功能 (Physical Function, PF)

用于支持 SR-IOV 功能的 PCI 功能，如 SR-IOV 规范中定义。PF 包含 SR-IOV 功能结构，用于管理 SR-IOV 功能。PF 是全功能的 PCIe 功能，可以像其他任何 PCIe 设备一样进行发现、管理和处理。PF 拥有完全配置资源，可以用于配置或控制 PCIe 设备。

虚拟功能 (Virtual Function, VF)

与物理功能关联的一种功能。VF 是一种轻量级 PCIe 功能，可以与物理功能以及与同一物理功能关联的其他 VF 共享一个或多个物理资源。VF 仅允许拥有用于其自身行为的配置资源。

每个 SR-IOV 设备都可有一个物理功能 (Physical Function, PF)，并且每个 PF 最多可有 64,000 个与其关联的虚拟功能 (Virtual Function, VF)。PF 可以通过寄存器创建 VF，这些寄存器设计有专用于此目的的属性。
一旦在 PF 中启用了 SR-IOV，就可以通过 PF 的总线、设备和功能编号（路由 ID）访问各个 VF 的 PCI 配置空间。每个 VF 都具有一个 PCI 内存空间，用于映射其寄存器集。VF 设备驱动程序对寄存器集进行操作以启用其功能，并且显示为实际存在的 PCI 设备。创建 VF 后，可以直接将其指定给 IO 来宾域或各个应用程序（如裸机平台上的 Oracle Solaris Zones）。此功能使得虚拟功能可以共享物理设备，并在没有 CPU 和虚拟机管理程序软件开销的情况下执行 I/O。

SR-IOV 的优点

SR-IOV 标准允许在 IO 来宾域之间高效共享 PCIe 设备。SR-IOV 设备可以具有数百个与某个物理功能 (Physical Function, PF) 关联的虚拟功能 (Virtual Function, VF)。VF 的创建可由 PF 通过设计用来开启 SR-IOV 功能的寄存器以动态方式进行控制。缺省情况下，SR-IOV 功能处于禁用状态，PF 充当传统 PCIe 设备。
具有 SR-IOV 功能的设备可以利用以下优点：

性能－从虚拟机环境直接访问硬件。

成本降低－节省的资本和运营开销包括：

节能

减少了适配器数量

简化了布线

减少了交换机端口

来源: <
http://docs.oracle.com/cd/E38902_01/html/E38873/glbzi.html>

intel网卡-虚拟化中的SR-IOV教程
虚拟化环境中有很多的硬件加速技术，这些技术标准来源于行业内的领导者或各种组织机构，但是在实际项目落地时又有哪些会被启用呢？哪些启用的功能带来了性能上明显的提升呢？那么这些加速技术如果不痛不痒的话那么它们的存在究竟意义有多大呢？
无论哪家解决方案，若想启用一些加速功能，势必需要硬件的支持，这就导致在一些项目前期的调研或者POC环境里不太容易实现，毕竟有些要求是十分昂贵和苛刻的，比如RDMA。相对于一些需要资金投入的技术来说，SRIOV无疑是比较亲民且易于实现的，今天就选它来一探究竟。本篇将全部采用微软Hyper-V环境进行说明
SRIOV，即单根虚拟化。Intel在早期为了支持虚拟化环境，在CPU和PCI总线上提供了三层虚拟化技术，它们分别是：

基于处理器的虚拟化技术VT-x

基于PCI总线实现的IO虚拟化技术VT-d

基于网络的虚拟化技术VT-c

从SRIOV的中文字面不难理解，它属于VT-d技术的一个分支，要实现SRIOV功能，前提条件就是你的网卡首先要支持SRIOV，你的主板要支持VT-d技术（支持VT-d自然也就支持SRIOV）
那么SRIOV究竟是干嘛用的呢？它能给虚拟化平台带来多么可观的性能提升呢？还是上一张架构图来看看吧：

以上图为例逐个解释关键词：1. PF就是物理网卡所支持的一项PCI功能，PF可以扩展出若干个VF2. VF是支持SRIOV的物理网卡所虚拟出的一个“网卡”或者说虚出来的一个实例，它会以一个独立网卡的形式呈现出来，每一个VF有它自己独享的PCI配置区域，并且可能与其他VF共享着同一个物理资源（公用同一个物理网口）3. PF miniport driver即PF驱动是工作于Hyper-V虚拟化平台父区域的，并在VF之前最先加载4. VF miniport driver即VF驱动是工作于Hyper-V虚拟化平台子区域的，即guestOS；需要注意的是，VF及PF之间是隔离的，任何经由VF驱动或所执行的结果都不会影响到其他的VF或PF5. Network Interface Card即物理网卡，在启用SRIOV之后会生成若干vport，物理NIC所要做的就是转发physical port与vport之间的流量6. physical port顾名思义就是物理网口，在SRIOV场景中physical port充当一个面向对外的网络媒介7. VPort是个抽象出来的接口，类似于物理网口，它们被映射给每一个VF或者PF，供parentOS或guestOS来使用
通过以上架构的描述就可以看出，启用SRIOV之后，物理NIC将通过VF与虚拟机（VF driver）进行数据交互，反之亦然。那么这样一来即可跳过中间的虚拟化堆栈（即VMM层），以达到近乎于纯物理环境的性能；这一点也是SRIOV最大的价值所在，他有别于以往虚拟机通过仿真设备和虚拟化层进行流量传递的情况，那么究竟SRIOV与传统环境相比能提升多少，我来做个实验：宿主机OS：windows server 2012R2虚拟机OS：windows server 2012R2服务器型号：DELL R720网卡：intel x520 series######################################################################################首先在服务器BIOS设置中将SRIOV功能开启


物理机确认开启了SRIOV功能之后，接下来在操作系统层面操作，首先Hyper-V若要使用SRIOV，有两处需要修改，一个是虚拟交换机，如下图确认在创建虚拟交换机时开启了SRIOV（单根虚拟化），需要注意的是虚拟交换机一旦创建后，SRIOV功能无法在修改，也就是说你要是忘了开启那对不起，麻烦您删了重来

虚拟交换机启用SRIOV之后，就要在我测试的虚拟机上操作了，在虚拟机的vNIC（虚拟网卡）上开启SRIOV，如下图所示，这里是可以随时开关的


确认了上面的操作之后，通过powershell可以进一步确认系统是否识别了我的设置，在当前宿主机执行（get-vmhost）.iovsupport或iovsupportreasons来查看返回结果，有关powershell中对象的属性可以通过管道符“|gm”来查看另外如下图所示，通过get-netadaptersriov来查看当前主机上支持sriov的物理网卡有哪些，并且从返回结果来看，我的x520-2网卡最多支持62的vf。顺带提一句Peripheral Component Interconnect Special Interest Group(外围部件互连专业组)，简称PCISIG，这个组织定义了每个设备最多可支持的vf数量为256个

在正确且成功开启了sriov功能之后，我启动这台测试虚拟机SRIOV_2012，可以看到hyper-v下方显示当前SRIOV是活动状态，但奇怪的是我发现有两个IP。。怎么回事呢？

进入到虚拟机系统里来看设备管理器，发现多了一块网卡，叫做“Intel(R）82599虚拟功能”，其实我这块Intel x520 series网卡是基于Intel 82599控制芯片的，后面的虚拟功能翻译过来就是virtual function，也就是虚出来的一个VF，它以一块虚拟网卡的形式呈现在虚机操作系统里了，因此我刚才看到了两个IP地址

这里可能有个小bug，就是我需要重新配一次IP，这样这台虚拟机才不会出现两个IP地址，如下图目前这个正常的测试IP显示的是（复制）

重新输一遍之后就恢复正常了，也就是说原先的IP地址没有直接映射到我的VF上面，下图显示当前IP已经恢复正常了，只有一个6.6.6.0的IP

同样通过powershell命令“get-netadaptersriovvf”可以看到当前生成的VF信息

######################################################################################下面开始一个拷贝测试，通过网络传输一个iso文件，在启用SRIOV的情况下，传输速度大约460MB/S

在传输文件同时，我使用工具（burnintest）对虚拟机CPU进行加压，以尽量模拟实际情况，观察结果如下图，通过性能监视器看到CPU使用率最小值不到2%，最大值11%多，相差约9.5%

接着关掉这个虚拟机的SRIOV功能


可以看到VF没有了，如下图

通过powershell确认VF的确离我们远去了~

同样再通过网络拷贝一次文件，依旧是iso文件（这里不用考虑缓存因素，我在每次拷贝之前都会进行一些复制操作以便尽量充满缓存），传输速率大概在410MB/S左右


同样传输期间对虚拟机CPU进行加压，观察性能监视器结果，CPU负载最小值不到2%，最大值接近17%，相差约15%

综合上述情况来看，对比SRIOV功能开启与关闭，拷贝同样iso文件以及相同的CPU加压方式，结果如下：

	开启SRIOV	关闭SRIOV	差值
CPU使用率	9.5%	15%	5.5%
传输速率	460MB/S	410MB/S	50MB/S

########################################################################################通过上面的测试可以看出在SRIOV开启或关闭的不同情况下，对比还是有一定效果的，我的测试环境还是不够严谨的，因为在实际生产环境中还要考虑诸多因素，例如磁盘的IO，虚拟机的CPU配置等等情况，但是即便比较粗陋，这个数据还是具有一定参考价值的，将近6%左右的CPU负载以及相差50MB/S的速率我想对于任何一个有大批量并发请求的虚拟化平台用户来讲都是相当可观的，所以说SRIOV对于当前私有云用户来讲还是很有价值的。关于虚拟化的硬件加速功能还有很多，如果以后有条件了会一并奉上与大家分享。本文出自 “技术不宅” 博客，请务必保留此出处http://maomaostyle.blog.51cto.com/2220531/1439651

来自为知笔记(Wiz)