主流的网络i/o虚拟化技术

2016-05-26 01:12:53 anxpp 阅读数 28719
  • Compose常用选项与命令

    利用Docker Compose编排容器,集中管理 掌握Swarm和Kubernetes容器集群系统,集群部署应用程序 熟悉持续集成,持续部署概念,完善企业CI/CD架构

    0课时 0分钟 222人学习 李振良
    免费试看

转载请注明出处:http://blog.csdn.net/anxpp/article/details/51503329,谢谢!

1、介绍

    Linux 的内核将所有外部设备都看做一个文件来操作(一切皆文件),对一个文件的读写操作会调用内核提供的系统命令,返回一个file descriptor(fd,文件描述符)。而对一个socket的读写也会有响应的描述符,称为socket fd(socket文件描述符),描述符就是一个数字,指向内核中的一个结构体(文件路径,数据区等一些属性)。

    根据UNIX网络编程对I/O模型的分类,UNIX提供了5种I/O模型。

    1.1、阻塞I/O模型

    最常用的I/O模型,默认情况下,所有文件操作都是阻塞的。

    比如I/O模型下的套接字接口:在进程空间中调用recvfrom,其系统调用直到数据包到达且被复制到应用进程的缓冲区中或者发生错误时才返回,在此期间一直等待。

    进程在调用recvfrom开始到它返回的整段时间内都是被阻塞的,所以叫阻塞I/O模型。

    图示:

    01

    1.2、非阻塞I/O模型

    recvfrom从应用层到内核的时候,就直接返回一个EWOULDBLOCK错误,一般都对非阻塞I/O模型进行轮询检查这个状态,看内核是不是有数据到来。

    图示:

    02

    1.3、I/O复用模型

    Linux提供select/poll,进程通过将一个或多个fd传递给select或poll系统调用,阻塞在select操作上,这样,select/poll可以帮我们侦测多个fd是否处于就绪状态。

    select/poll是顺序扫描fd是否就绪,而且支持的fd数量有限,因此它的使用受到了一些制约。

    Linux还提供一个epoll系统调用,epoll使用基于事件驱动方式代替顺序扫描,因此性能更高。当有fd就绪时,立即回调函数rollback。

    图示:

    03

    1.4、信号驱动I/O模型

    首先开启套接口信号驱动I/O功能,并通过系统调用sigaction执行一个信号处理函数(此系统调用立即返回,进程继续工作,非阻塞)。当数据准备就绪时,就为改进程生成一个SIGIO信号,通过信号回调通知应用程序调用recvfrom来读取数据,并通知主循环函数处理树立。

    图示:

    04

    1.5、异步I/O

    告知内核启动某个操作,并让内核在整个操作完成后(包括数据的复制)通知进程。

    信号驱动I/O模型通知的是何时可以开始一个I/O操作,异步I/O模型有内核通知I/O操作何时已经完成。

    图示:

    05

2、I/O多路复用技术

    I/O编程中,需要处理多个客户端接入请求时,可以利用多线程或者I/O多路复用技术进行处理。

    正如前面的简介,I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上,从而使得系统在单线程的情况下可以同时处理多个客户端请求。

    与传统的多线程模型相比,I/O多路复用的最大优势就是系统开销小,系统不需要创建新的额外线程,也不需要维护这些线程的运行,降低了系统的维护工作量,节省了系统资源。

    主要的应用场景:

  •     服务器需要同时处理多个处于监听状态或多个连接状态的套接字。
  •     服务器需要同时处理多种网络协议的套接字。

    支持I/O多路复用的系统调用主要有select、pselect、poll、epoll。

    而当前推荐使用的是epoll,优势如下:

  •     支持一个进程打开的socket fd不受限制。
  •     I/O效率不会随着fd数目的增加而线性下将。
  •     使用mmap加速内核与用户空间的消息传递。
  •     epoll拥有更加简单的API。

3、Java中的网络IO编程

    如果只是做Java开发,以上内容只需了解即可,不必深究(随便说说而已)。

    已专门出了文章介绍:Java 网络IO编程总结(BIO、NIO、AIO均含完整实例代码)

2014-07-13 15:32:16 speakingcamp 阅读数 746
  • Compose常用选项与命令

    利用Docker Compose编排容器,集中管理 掌握Swarm和Kubernetes容器集群系统,集群部署应用程序 熟悉持续集成,持续部署概念,完善企业CI/CD架构

    0课时 0分钟 222人学习 李振良
    免费试看

为了提升网络I/O性能,虚拟化的网络I/O模型也在不断的演化:

1,全虚拟化网卡(emulation),如VMware中的E1000用来仿真intel 82545千兆网卡,它的功能更完备,如相比一些半虚拟化的网卡(如vmnet3)会对vlan的支持更好。纯软件模拟不需要硬件支持,通过CPU计算来模拟,跟宿主机的物理网卡隔离,没有平台要求,对虚拟机的操作系统也不需要修改(因为模拟的都是一个常见的硬件网卡,如IntelE1000,主流操作系统一般都自带这些驱动,因此默认情下虚拟机不需要再安装驱动。缺点就是性能差了。

2,半虚拟化网卡,如上面提到的VMware中的vnet3,以及KVM中的virtio等。在半虚拟化模型中,物理硬件资源是统一由Hypervisor来管理的,这样虚拟机和Hypervisor之间通信有可能直接接触到硬件,因此性能相对较高。缺点就是需要修改虚拟机操作系统需要安装这些半虚拟化网卡的驱动程序。

3,Pass-through直通方式,Hypervisor直接把硬件PCI设备分配给虚拟独占使用,性能当然好啦。但是浪费硬件设备,且配置复杂,首先需要在hypervisor指定通过PCIid方式分配给指定的虚拟机,然后虚拟机再识别到设备再安装驱动来使用。OpenStack中如何使用它可参见:https://wiki.openstack.org/wiki/Pci_passthrough

4,SR-IOV(Single Root I/O Virtualization and Sharing Specification),用来解决虚拟最后一公里的问题,即多个虚机可以同时共享使用同一个PCI硬件。它需要专门支持SR-IOV的硬件网卡,它会在Hypervisor里注册成多个网卡(每个网卡都有独立的中断,收发队列,QoS等机制),将虚拟网卡中的数据分类功能挪到了硬件SR-IOV网卡中实现。参考:http://www.openstack.cn/p2129.html

2016-04-26 14:24:28 U201017971 阅读数 3147
  • Compose常用选项与命令

    利用Docker Compose编排容器,集中管理 掌握Swarm和Kubernetes容器集群系统,集群部署应用程序 熟悉持续集成,持续部署概念,完善企业CI/CD架构

    0课时 0分钟 222人学习 李振良
    免费试看

网络I/O不但是物理服务器最容易出现的瓶颈,也是现在虚拟化技术最大的硬伤。随着硬件虚拟化对网络I/O的支持,虚拟化的网络I/O模型也不断的进化,虚拟化的I/O性能也不断提升。

  这4个主流网络I/O模型分别是:

  1、Emulation

  原理:仿真(emulation)是一个完全通过软件程序来模拟硬件的技术。早期虚拟化都才采用这种方案来虚拟网络设备。常见仿真软件有QEMU、VMwareWorkStation、VirtualBox。Emu

  不同虚拟化厂商的虚拟网卡产品都不尽相同。

  VMwareEmulation类型网卡有:E1000(仿真intel82545M千兆网卡)、Flexible、Vlance(仿真AMC79C970PCnet32LANCE10M网卡)、VMXNET(VMXNET一共有3个版本,分别是VMXNET、VMXNET2、VMXNET3;暂时没有找到VMware的明确资料对这三个版本进行分类。个人暂把VMXNET定为emulation、VMXNET2和VMXNET3定义为para-virtualization类型。VMXNET3也支持部分SR-IOV功能)。

  Redhat的KVM和Citrix的XEN这类型网卡都是采用QEMU实现,在KVM和XEN上面可用的emulation网卡有:RTL8139(仿真RealTekLink8139100M网卡)、E1000(仿真intel82545M千兆网卡)。

  MicrosoftHyper-VEmulation类型网卡有:Intel/DEC21140100M网卡

  优点:软件模拟不需要硬件支持,通过CPU计算来模拟,跟宿主机物理网卡隔离,没有平台要求。

  虚拟机操作系统不需要修改,模拟的都是常见网卡(比如:IntelE1000、RTL8139等),主流操作系统都已经自带这些驱动,因此默认情况下虚拟机不需要再安装驱动。

  缺点:CPU资源消耗大,尤其当虚拟机数量多的时候。网卡性能一般,由于是软件模拟,只能模拟常见的、功能比较简单的网卡。

  虚拟机迁移支持:

  剥离了硬件要求,使用这类型可迁移性强。由于XEN和KVM都是使用qemu仿真,所以这类型虚拟机在XEN和KVM之间混合迁移实现难度也不大。

  2、para-virtualization

  原理:Para-virtualization又称半虚拟化,最早由Citrix的Xen提出使用。在半虚拟化模型中,物理硬件资源统一由Hypervisor管理,由Hypervisor提供资源调用接口。虚拟子机通过特定的调用接口与Hypervisor通信,然后完整I/O资源控制操作。

  Para-virtualization又称半虚拟化,最开始由XEN提出的,XEN本身就是从虚拟化起家的。Para-virtualization模型下,虚拟子机的网卡驱动只能有Hypervisor厂商来开发,Redhat、VMware、Citrix、Microsoft这几大虚拟厂商都有各自的para-virtualization驱动。比如Redhat的KVM就叫virtio,VMware的有VMXNET2、VMXNET3,Citrix的XEN叫xen-pv,Mircrosoft暂时没有找到(欢迎朋友们补充)。

  优点:个人认为是一种改进版的emulation模型,但是由于子机和Hypervisor之间通信,性能比emulation要很多。

  缺点:需要修改虚拟子机操作系统内核,添加不同Hypervisor厂商的网络驱动。比如Linux(Redhat和Novell)就在发行版里面添加了Mircosoft的para-virtualizaiton网络驱动,同样Microsoft也在自己发行版里面添加对KVM的virtio和xen-pv驱动支持。

  虚拟机迁移支持:虽然不同虚拟化厂商的para-virtualization方案都不相同,由于主流操作系统都同时提供对这些方案的支持;所以这类型虚拟子机可迁移性也比较容易实现。

  3、pass-through

  原理:Hypervisor将一个PCI设备(可以是网卡、USB、光驱)直接分配给指定虚拟子机单独访问。为了安全和稳定性考虑,pass-through使用通常结合intelVT-D(AMD也有类似技术)来使用,通过iommu保证虚拟子机之间内存访问不冲突。这种技术在VMware上叫VMDirectPathI/O,其他方案中没有找到相关专门名词。

  优点:性能好。单独PCI设备分配给虚拟子机,虚拟子机直接跟物理设备通信。

  缺点:设备只能被一个虚拟子机使用,配置也比较复杂,首先需要在hypervisor将指定设备通过PCIid方式分配给指定虚拟子机,然后虚拟子机识别到设备再安装驱动来使用。

  迁移性:迁移性方面待研究,有兴趣的朋友可以补充完善。

  4、SR-IOV

  背景:pass-through模型让虚拟子机直接使用物理设备,这样使得虚拟子机的网络性能达到最优。SR-IOV主要用来解决pass-through只能被一台虚拟子机访问的问题。SR-IOV标准由PCI-SIG,这个标准实现需要CPU、芯片组和PCI设备(主要是网卡等I/O资源)协同在硬件层面实现,SR-IOV被很多人认为是解决了虚拟化最后一公里的问题。

  原理:SR-IOV需要网卡硬件支持,支持SR-IOV功能的网卡可以在Hypervior里面注册成多个网卡(每个网卡都独立的中断ID、收发队列、QOS管理机制)。每个设备可以通过pass-through方式分配给虚拟子机。

  产品:常见就是基于intel82599和82598芯片组的10Gb网卡。VMware、Redhat、Citrix和Microsoft都已经或者正在Hypervisor里面添加这个功能的支持。下面是一篇基于KVM的SR-IOV性能测试报告。不同厂商虚拟化方案都不尽相同,有兴趣可以在google里面搜索到更多资料。

  优点:优点不用说,X86虚拟化最新的IO虚拟化模型;虚拟机不但性能好,而且结合硬件功能,为虚拟机IO管理提出了一个新方案。

  缺点:待定

  迁移性:SR-IOV同时需要硬件和软件两个层面支持,虚拟子机在相同网卡主机之间迁移时理论上不会有问题。具体还要看虚拟化厂商实现。

转载地址:http://virtualization.ctocio.com.cn/177/12476177.shtml


2014-12-11 14:23:44 lkn910907 阅读数 5509
  • Compose常用选项与命令

    利用Docker Compose编排容器,集中管理 掌握Swarm和Kubernetes容器集群系统,集群部署应用程序 熟悉持续集成,持续部署概念,完善企业CI/CD架构

    0课时 0分钟 222人学习 李振良
    免费试看

1、I/O虚拟化简介 

      I/O虚拟化(Input/output virtualization,简称IOV)是虚拟化的一种新形式,是来自物理连接或物理运输上层协议的抽象,让物理服务器和虚拟机可以共享I/O资源

       在现实生活中,可用的物理资源往往是有限的,虚拟机的个数往往会比实际的物理设备个数要多。为了提高资源的利用率,满足多个虚拟机操作系统对外部设备的访问需求,虚拟机监视器必须通过I/O虚拟化的方式来实现资源的复用,让有限的资源能被多个虚拟机共享。为了达到这个目的,监视器程序需要截获虚拟机操作系统对外部设备的访问请求,通过软件的方式模拟出真实的物理设备的效果,这样,虚拟机看到的实际只是一个虚拟设备,而是真正的物理设备,这种模拟的方式就是I/O虚拟化的一种实现,下图所示就是一个典型的虚拟机I/O模型。


       如上图所示,虚拟化技术通过在物理硬件上抽象出一个虚拟化层,来实现对整个物理平台的虚拟化,这个虚拟化层通常被称为虚拟机监视器(VMM)。通过对硬件层的模拟,将一台物理计算机抽象成了多台虚拟计算机,每个虚拟机都运行独立的操作系统,有各自的I/O子系统。I/O虚拟化并不需要完整地虚拟化出所有外设的所有接口,究竟怎样做完全取决于设备与VMM的策略以及客户机操作系统的需求

2、I/O虚拟化的基本要求

        I/O虚拟化虽然有着显著的优点,但是具体实现并没有那么简单,要考虑的因素也很多的,基本要求主要有以下的三点:

(1) 保真性,要求在虚拟化平台下进行的I/O访问与非虚拟化条件下的I/O访问除了完成时间差别外,其它效果相同;

(2) 安全性,要求各虚拟机操作系统只能访问虚拟机监视器分配给其的I/O资源,而各I/O设备也只能与属于同一个虚拟机的其它资源进行交互,如存储空间和CPU,而不能越界访问属于其它虚拟机的资源;

(3) 性能,要求虚拟化系统下I/O访问的性能与非虚拟化系统下的I/O访问性能接近。

在这三个基本要求之中最为重要的就是安全性方面的要求,这是保证虚拟化环境可以正常运行的根本,只有首先满足这一要求才能保证虚拟化I/O的保真性,对于性能的要求才会有意义。虚拟化环境下之所以会出现安全性的问题是因为虚拟机操作系统可见的地址并不是实际的机器物理地址,而是客户物理地址,设备若无法获知客户物理地址和机器物理地址间的转换关系,会直接使用客户物理地址进行内存访问,这会导致非法地址访问、破坏正常数据。

       正是由于I/O虚拟化对于I/O空间安全隔离性方面的要求,所以对于虚拟机操作系统的I/O访问操作一般都需要虚拟机监视器的干预,而不允许虚拟机操作系统与I/O设备直接进行交互,这也就使得虚拟化系统下的I/O性能与非虚拟化系统的I/O性能有着较大的差距。在设备直接分配模型中,有IOMMU的硬件辅助,实现了域间隔离和设备地址转换,保证被分配给虚拟机的设备不会访问不属于该虚拟机的存储器空间。

3、I/O虚拟化的性能

       因为I/O虚拟化安全性的要求,导致虚拟机操作系统的I/O访问会受到虚拟机监视器干预,导致性能与非虚拟化环境有较大差距。而虚拟机监视器介入之所以会导致性能严重损失的根本原因就是发生了上下文切换。

      上下文切换分为两种,虚拟机与虚拟机之间发生的上下文切换以及虚拟机与虚拟机监视器之间发生的上下文切换。在I/O虚拟化中影响性能的就是虚拟机和虚拟机监视器之间的上下文切换。虚拟机操作系统产生的I/O请求会被监视器截获,监视器将I/O请求交由驱动域去处理,驱动域完成I/O请求要返回执行结果,这些过程都是造成上下文切换。虚拟机和监视器之间的上下文切换的开销主要分为以下三个部分:

(1)直接开销,这个部分主要由CPU的切换造成,CPU需要停滞虚拟机切换到虚拟机监视器去执行,之后又要从监视器程序转回虚拟机执行下一条指令;

(2)间接开销,两种环境的切换导致需要保存上下文环境。

(3)同步开销,这个部分主要是虚拟机监视器处理VM EXIT造成的。

因此,一旦发生大量的上下文切换,将严重影响I/O虚拟化的性能,尤其在I/O密集型的任务中,上下文切换导致的开销往往是无法忍受的

4、主流的I/O设备虚拟化模型

(1)模拟模型   

      模拟模型是使用最为广泛的I/O设备虚拟化模型,该模型采用软件的方式模拟设备行为,为虚拟机模拟出与底层硬件完全一致的虚拟化环境,保证虚拟机操作系统的行为与非虚拟化环境下完全一致。在模拟模型中,虚拟设备必须以某种方式让虚拟机可以发现,导致虚拟机被“欺骗”。当虚拟机访问虚拟设备时,访问请求被虚拟机监视器截获,然后监视器程序将I/O请求交由domain0来模拟完成,最后将结果返回给虚拟机。如下图所示是一个基于设备模拟的xen的I/O虚拟化模型。


       模拟模型最大的优点在于不需要对操作系统内核做修改,也不需要为其改写驱动程序,因此,全虚拟化下的模拟模型成为了可移植性与兼容性最佳的一种I/O设备虚拟模型,这也是它被如此广泛使用的主要原因。

       但是设备模拟模型有一个很大的不足之处,即性能不够高,主要原因有两方面:第一、模拟方式是用软件行为进行模拟,这种方式本身就无法得到很高的性能;第二、这种模型下I/O请求的完成需要虚拟机与监视器程序多次的交互,产生大量的上下文切换,造成巨大开销。

(2)泛虚拟化模型

        泛虚拟化模型是被广泛使用的另一种I/O设备虚拟化模型。相比于设备模拟模型而言,泛虚拟化模型在性能上有很大的提升。主要有以下两个原因:

(1)该模型采用了I/O环机制,减少了虚拟机与虚拟机监视器之间的切换;

(2)该模型摒弃了传统的中断机制,而采用事件或回调机制来实现设备与客户机间的通信。进行中断处理时,传统的中断服务程序需要进行中断确认和上下文切换,而采用事件或回调机制,无需进行上下文切换。

如下图所示是一个基于泛虚拟化的Xen的I/O虚拟化模型。


       泛虚拟化模型虽然在性能上比模拟模型要好,但是这种I/O模型有一个很大的缺点,要修改操作系统内核以及驱动程序,因此会存在移植性和适用性方面的问题,导致其使用受限。

(3)设备直接分配模型

       传统的实现I/O虚拟化的技术中,所有的虚拟机都共享物理平台上的硬件设备。如果物理条件好,有足够的硬件,就可以考虑让每个虚拟机独占一个物理设备,这样无疑会提高系统的性能。把某一个设备直接分配给一个虚拟机,让虚拟机可以直接访问该物理设备而不需要通过虚拟机监视器或被虚拟机监视器截获,这就是设备直接分配技术。如下图所示为设备直接分配的I/O模型。



      在设备直接分配模型中,虚拟机操作系统可直接拥有某一物理设备的访问控制权限,虚拟机监视器不再干涉其访问操作。因此,该模型可以较大地改善虚拟化设备的性能,降低监视器程序的复杂性,易于实现,并且不需要修改操作系统,保证了高可用性。

     设备直接分配模型虽然在性能上相比主流的两种I/O设备虚拟化模型有着很大的提升,但是该模型的使用也是有一定限制的。因为该模型将一件物理设备直接分配给了一个虚拟机,其它虚拟机是无法使用该设备的,所产生的一个问题就是如果其它虚拟机需要访问该设备则无法满足需求,解决的办法就是服务器上还有一个同样的设备以供其它虚拟机使用。因此,设备直接分配模型的使用必须满足物理资源较为充足的前提条件,对于那些紧缺的物理资源,该模型是不适用的。

(4)SR-IOV

       为降低虚拟机I/O的性能开销,学术界和工业界从软硬件方面对虚拟机I/O模型做了大量的改进。Intel VT-d技术和Passthrough技术通过降低I/O操作中VMM的参与提升了虚拟机的I/O性能, SR-IOV标准在此基础上支持虚拟机对I/O设备的原生共享。

        SR-IOV标准定义了设备原生共享所需的软硬件支持。硬件支持包括芯片组对SR-IOV设备的识别,BIOS为SR-IOV分配足够的资源,此外为保证对设备的安全、隔离访问还需要北桥芯片的VT-d支持。软件方面,VMM将驱动管理权限交给域0,域0操作系统必须支持SR-IOV功能。域0通过物理功能(physical function,PF)驱动发现设备的SR-IOV功能后将包括发送、接收队列在内的物理资源依据VF数目划分成多个子集,然后PF驱动将这些资源子集抽象成设备即系统中所见的虚拟功能(virtual function,VF)设备,创建VF设备后,域0可将VF设备以Passthrough方式分配给虚拟机。

       SR-IOV的软件架构如下图所示,分成四个部分:PF、VF、控制面板以及PF和VF间的通信机制。其中,PF是域0中负责管理SR-IOV设备的特殊驱动,其主要功能是为特权域0提供设备访问功能和全局贡献资源配置的功能,虚拟机所有影响设备状态的操作均需通过通信机制向PF发出请求完成。VF是轻量级的PCIe功能,其功能包含三个方面:向虚拟机操作系统提供的接口;数据的发送、接收功能;与PF进行通信,完成全局相关操作,由于VF的资源仅是设备资源的子集,因此VF驱动能够访问的资源有限,对其它资源的访问要求通过PF完成。控制面板同PF一样位于特权域0中,其主要功能是负责生成PCIe配置空间并将VF抽象成PCIe设备,并向用户提供VF分配、回收等接口。

     

       尽管Intel VT-d技术和Passthrough技术消除了虚拟机I/O中VMM干预引起的额外开销,但在I/O操作中I/O设备会产生大量的中断,出于安全等因素考虑,虚拟机无法直接处理中断,因此中断请求需要由VMM安全、隔离地路由至合适的虚拟机。若CPU运行虚拟机时接收中断请求,Xen将强制将虚拟机切换出来并且陷入到VMM中执行中断处理程序,待处理完毕后再恢复虚拟机的执行,因而增加了虚拟机的I/O延迟。






2017-12-21 10:37:52 wangcg123 阅读数 10351
  • Compose常用选项与命令

    利用Docker Compose编排容器,集中管理 掌握Swarm和Kubernetes容器集群系统,集群部署应用程序 熟悉持续集成,持续部署概念,完善企业CI/CD架构

    0课时 0分钟 222人学习 李振良
    免费试看
网络I/O虚拟化,SR-IOV技术

1、简介

网络I/O虚拟化是服务器虚拟化技术的重要组成部分,在服务器虚拟化技术领域,计算虚拟化(如CPU和内存虚拟化)已经日趋成熟,但是,网络I/O虚拟化技术的发展相对比较滞后。当前,主流的网络I/O虚拟化技术有三种:软件模拟、网卡直通和SR-IOV。这三种虚拟化技术在不同程度上实现了网络I/O设备的虚拟化功能。其中,软件模拟是通过虚拟化Hypervisor层模拟虚拟网卡,实现与物理设备完全一样的接口,虚拟机操作系统无须修改就能直接驱动虚拟网卡,其最大的缺点是性能相对较差;网卡直通支持虚拟机绕过Hypervisor层,直接访问物理I/O设备,具有最高的性能,但是,在同一时刻,物理I/O设备只能被一个虚拟机独享;SR-IOV是Intel在2007年提出的解决虚拟化网络I/O的硬件技术方案,该技术不仅能够继承网卡直通的高性能优势,而且同时支持物理I/O设备的跨虚拟机共享,具有较好的应用前景。

2007年10月,PCI-SIG发布了PCI-SIG Single Root I/O Virtualization(SR-IOV)规范,其中详细阐述了硬件供应商在多个虚拟机中如何共享单个I/O设备硬件。

图1 硬件SR-IOV虚拟化技术原理图

图1 硬件SR-IOV虚拟化技术原理图

SR-IOV引入了两个新的功能类型:

  • PFs(Physical Functions,物理功能):物理网卡所支持的一项PCI功能,一个PF可以扩展出若干个VF。
  • VFs(Virtual Functions,虚拟功能):支持SR-IOV的物理网卡虚拟出来的实例,以一个独立网卡的形式呈现,每个VF有独立的PCI配置区域,并可以与其它VF共享同一个物理资源(共用同一个物理网口)。

一旦在PF中启用了SR-IOV,就可以通过PF的总线、设备和功能编号(路由ID)访问各个VF的PCIe配置空间。每个VF都具有一个PCIe内存空间,用于映射其寄存器集。VF设备驱动程序对寄存器集进行操作以启用其功能,并且显示为实际存在的PCIe设备。创建VF后,可以直接将其指定给I/O来宾域或各个应用程序。此功能使得虚拟功能可以共享物理设备,并在没有CPU和虚拟机管理程序软件开销的情况下执行I/O。

由此可见,SR-IOV网卡通过将SR-IOV功能集成到物理网卡上,将单一的物理网卡虚拟成多个VF接口,每个VF接口都有单独的虚拟PCIe通道,这些虚拟的PCIe通道共用物理网卡的PCIe通道。每个虚拟机可占用一个或多个VF接口,这样虚拟机就可以直接访问自己的VF接口,而不需要Hypervisor的协调干预,从而大幅提升网络吞吐性能。
需要注意的是,SR-IOV作为一种新技术,目前仍不完善的地方:

  • 单个物理网卡支持的虚拟机个数有限制;
  • SR-IOV特性需要物理网卡硬件支持,并非所有的物理网卡都支持SR-IOV特性。
检查是否支持SR-IOV:  lspci -s <NIC_BDF> -vvv | grep -i "Single Root I/O Virtualization"

2、产品规格

2.1 兼容性列表

H3C CAS云计算管理平台兼容多种支持硬件SR-IOV的网卡及虚拟机操作系统。下表为进行了详细兼容性验证的硬件网卡类型及对应操作系统的版本,对于未在列表中的网卡和操作系统可能可以支持,但在项目实施之前,需要进行适当的适配与验证工作。

网络IO虚拟化,SR-IOV技术 图2

说明:

  • 如果虚拟机操作系统为Windows类型,都必须在操作系统内安装SR-IOV网卡的VF驱动程序,您可以联系服务器或网卡供应商获取相应的软件驱动安装文件。
  • 如果虚拟机操作系统为Linux类型,对于Intel 82599网卡,只支持内核版本为2.6以上的Linux操作系统,对于BCM57810网卡,只支持内核版本为3.9以上的Linux操作系统。

2.2 注意事项

  • 物理主机必须支持并开启I/O内存管理单元(IOMMU)功能。
  • 物理主机必须支持SR-IOV,并且在BIOS中启用了SR-IOV。
  • PF驱动程序必须安装在CVK虚拟化内核系统中。对于Intel 82599和BCM57810等主流网卡,H3C CAS CVK虚拟化内核系统提供默认驱动程序。
  • VF驱动程序必须与物理网卡兼容,必须安装在虚拟机操作系统内。对于某些网卡,操作系统版本中包含默认驱动程序(例如,内核版本高于3.9的Red Hat Enterprise Linux Server 7.0操作系统,默认自带BCM57810网卡的VF驱动程序),而对于其它网卡,则必须从网卡供应商或主机供应商所提供的位置下载并安装驱动程序。
  • 支持SR-IOV的网卡必须插在总线带宽X8以上的扩展槽中。以HP ProLiant DL380p Gen8服务器为例,该服务器的3个扩展槽的总线带宽是不一样的,2×10G的网卡必须插在X8或X16的槽位,才能提供足够的带宽。插槽1提供X16总线带宽,插槽2提供X8总线带宽,插槽3提供X4总线带宽,因此,插槽3不支持SRIOV网卡。

3、配置前提

本文档中的配置均是在实验室环境下进行的配置和验证,配置前服务器和软件的所有参数均采用出厂时的缺省配置。如果您已经对被测试对象进行了配置,为了保证配置效果,请确认现有配置和以下举例中的配置不冲突。

4、配置环境

4.1 服务器

本文档不严格与具体硬件服务器型号对应,如果使用过程中与产品实际情况有差异,请参考相关产品手册,或以设备实际情况为准。本文档使用的服务器型号与配置如下表所示,该环境不作为实际部署时的强制环境或推荐环境,只需要服务器能够兼容H3C CAS云计算管理平台即可完成本配置。

网络IO虚拟化,SR-IOV技术 图3

4.2 软件

网络IO虚拟化,SR-IOV技术 图4

5、组网需求

图2 硬件SR-IOV网卡逻辑组网图

图2 硬件SR-IOV网卡逻辑组网图

  • 服务器 0安装H3C CAS CVM虚拟化管理平台,服务器 1安装H3C CAS CVK虚拟化内核系统。在HP StoreVirtual P4730(iSCSI)存储设备上划分了一个500GB的LUN,并将这个LUN作为iSCSI共享存储设备挂载给服务器 1使用。
  • 在服务器 1上创建2个虚拟机,分别安装Windows Server 2008 R2数据中心版64位和Red Hat Enterprise Linux Server 7.0 64位操作系统。
  • 在服务器 1的BCM57810网卡上开启SR-IOV功能,并分别分配1个VF接口给VM 1和VM 2。

主要验证项包括:

  • VM1和VM2操作系统内是否能看到分配的SR-IOV网卡。
  • VM1和VM2分别使用Virtio网卡和SR-IOV网卡进行网络流量压力测试,对比Virtio网卡转发与SR-IOV网卡转发时的I/O吞吐量。

6、测试步骤

6.1 检查服务器硬件配置

步骤1 检查服务器的CPU是否启用了VT-d技术。

启动服务器 1,在启动过程中,按[F9]键进入BIOS设置。

在BIOS设置中,依次选择“System Options”->“Processor Options”->“Intel(R) VT-d”,将其值设置为“Enabled”,表示开启CPU的VT-d功能。

图3 在服务器BIOS中开启Intel VT-d技术

图3 在服务器BIOS中开启Intel VT-d技术

依次选择“Advanced Options”->“SR-IOV”,将其值设置为“Enabled”,表示开启物理网卡的SR-IOV功能。

图4 在服务器BIOS中开启SR-IOV功能

图4 在服务器BIOS中开启SR-IOV功能

步骤2 保存BIOS配置后,重启服务器。

6.2 开启服务器IOMMU功能

系统管理员登录H3C CAS CVM虚拟化管理平台,在导航菜单中选中被测试虚拟机所在的服务器主机,在右侧配置窗口中点击“高级设置”标签页。

图5 服务器IOMMU配置

图5 服务器IOMMU配置

默认情况下,服务器主机的IOMMU状态为“禁用”。点击<修改>按钮,在弹出的“IOMMU配置”对话框中,修改“IOMMU状态”为“启用”,并点击<确定>按钮。

图6 修改服务器IOMMU状态

图6 修改服务器IOMMU状态

将服务器主机进入维护模式,并重启服务器使IOMMU配置生效。

图7 重启服务器主机使IOMMU配置生效

图7 重启服务器主机使IOMMU配置生效

注意
在配置IOMMU之后,由于必须重新启动服务器生效,如果被测试服务器主机上已经存在虚拟机,强烈建议:服务器主机进入维护模式,将处于运行状态的虚拟机在线迁移到其它服务器主机上,然后再重启服务器主机,以最大程度规避因为主机重启而导致虚拟机数据丢失。

服务器主机启动完成之后,在H3C CAS CVM虚拟化管理平台上将服务器主机退出维护模式,检查其IOMMU配置是否为“启用”状态。

图8 检查服务器IOMMU配置状态

图8 检查服务器IOMMU配置状态

6.3 准备测试虚拟机

步骤1 创建虚拟机。
在H3C CAS CVK虚拟化内核系统(服务器 #1)上创建2个新的虚拟机,两个虚拟机的虚拟硬件资源配置相同,如下表所示。

网络IO虚拟化,SR-IOV技术 图5

说明
上述虚拟机资源配置仅为测试环境下的配置,不作为生产环境中业务虚拟机的推荐配置。生产环境中的虚拟机配置应该根据业务本身对CPU、内存、磁盘和网卡等资源的实际需求进行评估和测试后最终确定。

步骤2 通过控制台(VNC),分别为两个虚拟机安装Windows Server 2008 R2数据中心版64位操作系统和Red Hat Enterprise Linux Server 7.0 64位操作系统。

步骤3【可选】在H3C CAS CVM虚拟化管理平台中,在线修改虚拟机,分别为两个虚拟机挂载CAStools工具,并在操作系统内安装CAStools工具。

步骤4 在操作系统内安全关闭虚拟机。

6.4 虚拟机配置SR-IOV网卡

步骤1 开启物理主机物理网卡SR-IOV功能。

在H3C CAS CVM虚拟化管理平台导航菜单中,选中被测试虚拟机所在的服务器主机,在右侧配置窗口中点击“物理网卡”标签页。

在“物理网卡”列表中,选中支持SR-IOV功能的物理网卡(本文档以Broadcom公司的NetXtreme II BCM57810万兆网卡为例),在“高级设置”中,点击“SR-IOV”标签页,修改“SR-IOV状态”为“启用”,输入“虚拟网卡个数”为“2”个,点击<保存>按钮。

图9 配置物理网卡的SR-IOV功能

图9 配置物理网卡的SR-IOV功能

步骤2 为VM 1和VM 2配置SR-IOV网卡。

在“修改虚拟机”界面中,点击<增加硬件>按钮,准备为虚拟机增加SR-IOV网卡。

在弹出的“增加新的虚拟机硬件”配置向导中,选择“硬件类型”为“网络”,点击<下一步>按钮。

图10 为虚拟机增加虚拟硬件配置向导第一步 – 选择硬件类型

图10 为虚拟机增加虚拟硬件配置向导第一步 – 选择硬件类型

选择“设备型号”为“SR-IOV直通网卡”,驱动类型为“VFIO”,点击“物理网卡”后的“ ”按钮,选择支持SR-IOV功能的网卡,点击<下一步>按钮。

图11 为虚拟机增加虚拟硬件配置向导第二步 – 选择SR-IOV网卡

图11 为虚拟机增加虚拟硬件配置向导第二步 – 选择SR-IOV网卡

确认配置之后,点击<完成>按钮。

图12 为虚拟机增加虚拟硬件配置向导第三步 – 配置确认

图12 为虚拟机增加虚拟硬件配置向导第三步 – 配置确认

说明

  • KVM:基于KVM内核的PCI设备分配方式,是一种较老的PCI设备分配方式,在较老的Linux操作系统内核中支持。
  • VFIO(Virtual Function I/O,虚拟化功能输入输出):基于VFIO的PCI设备分配方式。VFIO是一套用户态驱动框架,在虚拟化场景下,可以用来在用户态实现PCI设备分配,与基于KVM内核的PCI设备分配方式相比,具有更好的兼容性,在实际部署时,建议配置为VFIO类型分配方式。

步骤3 从HP官网下载BCM57810网卡在Windows类型操作系统下的VF驱动程序,下载网址为:http://h20564.www2.hpe.com/hpsc/swd/public/detail?sp4ts.oid=5282673&swItemId=MTX_06339e112ace404aaab82b2b0a&swEnvOid=4064。

注意
仅Windows类型操作系统需要安装VF驱动程序,对于BCM57810网卡,Linux内核版本3.9以上的操作系统都不需要安装VF驱动程序。

步骤4 启动虚拟机VM 1,并在虚拟机操作系统内完成驱动程序的安装。驱动程序安装成功之后,在Windows操作系统的“设备管理器”中,可以看到SR-IOV网卡已经被操作系统识别到。

图13 在Windows Server 2008 R2虚拟机上识别到的SR-IOV网卡

图13 在Windows Server 2008 R2虚拟机上识别到的SR-IOV网卡

步骤5 在VM 2虚拟机上,无需安装VF驱动程序,Red Hat Enterprise Linux Server 7.0操作系统默认已经支持BCM57810的网卡驱动程序。在“Settings”->“Network”中,可以看到被操作系统识别到的SR-IOV网卡。

图14 在Red Hat Enterprise Linux Server虚拟机上识别到的SR-IOV网卡

图14 在Red Hat Enterprise Linux Server虚拟机上识别到的SR-IOV网卡

6.5 验证SR-IOV网卡的互通性

步骤1 配置虚拟机SR-IOV网卡IP地址。

在Windows虚拟机操作系统内,配置SR-IOV网卡IP地址为192.168.100.101。

图15 配置Windows Server 2008 R2虚拟机SR-IOV网卡IP地址

图15 配置Windows Server 2008 R2虚拟机SR-IOV网卡IP地址

在Red Hat Enterprise Linux虚拟机操作系统内,配置SR-IOV网卡IP地址为192.168.100.102。

图16 配置Red Hat Enterprise Linux 7.0虚拟机SR-IOV网卡IP地址

图16 配置Red Hat Enterprise Linux 7.0虚拟机SR-IOV网卡IP地址

在VM1操作系统内命令行窗口,Ping VM2的IP地址,观察是否能Ping通。

图17 验证配置了SR-IOV网卡的虚拟机之间的IP互通性

图17 验证配置了SR-IOV网卡的虚拟机之间的IP互通性

6.6 验证SR-IOV和Virtio网卡I/O吞吐量

步骤1 从iperf官方网站下载Windows版本和Linux版本的iperf工具软件,并分别在VM #1和VM #2虚拟机操作系统内安装。下载网址为:https://iperf.fr,本文档使用2.5.0版本为例。

步骤2 以VM1(Windows Server 2008 R2)为服务端,VM2(Red Hat Enterprise Linux Server 7.0)为客户端,两个虚拟机通过SR-IOV网卡进行网络吞吐量加压测试。为了防止偶然因素影响测试结果,总共测试5次取均值,结果约为2.13Gbps,下图为具体测试结果。

图18 SR-IOV网卡性能测试结果

图18 SR-IOV网卡性能测试结果

步骤3 两个虚拟机通过Virtio网卡(关闭内核加速)进行网络吞吐量加压测试,同样测试5次取均值,结果约为614Mbps,下图为具体测试结果。

图19 Virtio网卡(关闭内核加速)性能测试结果

图19 Virtio网卡(关闭内核加速)性能测试结果

步骤4 两个虚拟机通过Virtio网卡(开启内核加速)进行网络吞吐量加压测试,同样测试5次取均值,结果约为2.3Gbps,下图为具体测试结果。

图20 Virtio网卡(开启内核加速)性能测试结果

图20-Virtio网卡(开启内核加速)性能测试结果

注意
Virtio类型虚拟网卡是通过软件来模拟的网络转发模型,在实际运行时,请性能与服务器的CPU性能、当前服务器物理CPU利用率、虚拟化内核软件处理效率都有关系。

6.7 对比验证结果

根据上述测试结果,可以看出,在给定的服务器HP ProLiant DL380p Gen8(2路6核,Intel Xeon E5-2630 0 @ 2.30GHz)和物理SR-IOV网卡(Broadcom NetXtreme BCM57810 10 Gigabit Ethernet)条件下,在不同的虚拟网卡配置情况下的网络I/O转发性能对比如下图所示。

图21 SR-IOV与Virtio网卡IO吞吐量性能对比

图21 SR-IOV与Virtio网卡IO吞吐量性能对比

参考:

  http://www.sdnlab.com/14403.html

  http://www.linux-kvm.org/page/10G_NIC_performance:_VFIO_vs_virtio