NFV和NFC基础设施
DPDK为高性能数据面的处理提供了可能。DPDK已作为NFV和NFC(网络功能虚拟化和容器化)的重要组件,参与到NFV和NFC的基础设施建设中。
网络功能虚拟化
网络功能虚拟化的一个重要特征是软硬件解耦。网络功能从专用硬件向通用硬件平台乃至虚拟通用硬件平台转移时,作为承载各种网络功能的基础设施层(NFVi),其重要性也越发突出。
NFVi数据平面加速
对于一个VNF(虚拟化网络功能)应用,快速地从NFVi获取网络帧是后续业务逻辑的基础,涉及虚拟主机接口(Host I/O Interface)。
从NFVi的视角来看,虚拟主机接口是其面向虚拟主机提供的北向虚接口;VNF的视角来看,虚拟主机接口是承载其运行的主机I/O设备。
配合不同类型的虚拟主机接口,NFVi提供了不同的数据面策略,Bypass和Relay就是两种比较典型的数据面策略。从数据面的角度,前者依赖外部系统提供NFVi数据面,绕过了整个Host软件部分,后者则由Host软件提供NFVi数据面。
虚拟主机接口。网络设备按照不同的虚拟化实现方式,可以粗略地分为全模拟(Fully- Eumlauted)、半虚拟化(Para-Virtualized)和硬直通(Pass-thru)。
对于主流的VMM及其网络设备,DPDK支持相对都比较完善。全模拟和半虚拟化类型的虚拟主机接口主要与NFVi的Relay策略一起工作。而硬直通NFVi一般采用Bypass策略。
下图E1000就是VMM全模拟的设备接口,Virtio是QEMU/KVM下的半虚拟化设备,VF则是基于SR-IOV的功能,可用于直通。
不同的虚拟主机接口实现方式。
在网络功能虚拟化场景下,对网络宽带都有一定的要求。相对于全模式设备方式,半虚拟化和硬直通是更为主流的使用方式。
半虚拟化
Virtio是QEMU/KVM下的半虚拟化设备框架,支持多种设备类型。
Virtio-net是网卡设备类型的代表。由QEMU模拟。例如当Virtio-net基于PCIe总线时,QEMU通过Trap-Emulation的方式模拟了PCIe Bus、PCIe CSR、BAR Registers、Interrupt等行为。设备中传输的网络帧,本质是通过共享内存的方式,由虚拟主机内的前端设备驱动和后端设备双方按照队列规范进行了入队列和出队列的操作。
QEMU为Virtio后端设备的实现提供了一层vHost抽象,这样无论QEMU进程本身、Kernel,还是另外的独立进程,都可以有不同的适配。vHost-user就是一个独立于QEMU进程的Virtio设备后端的实现接口,QEMU进程和独立进程按照vHost协议通过Unix Socket互相交互。
交互分类:设备相关部分和设备无关部分。
设备相关部分:功能协商、设置多队列、MTU等
设备无关部分:主要是搭建前后端共享数据通道,即前端设备如何与后端共享内存并相互通知。
通过DPDK的vHost-user库,用户可以在自己进程中轻松地与虚拟主机进行网络帧传输。
在Open vSwitch中,DPDK模式的NETDEV(即OVS-DPDK)便是使用vHost-user构建其面向虚拟主机的虚接口。
由于Virtio的设备驱动默认后端是由软件在相同框架的CPU上进行数据入队列和出队列的操作,所以在半虚拟化设备中,随着Virtio硬化的出现,这种方式的边界也逐渐变得模糊。
Virtio的特点:
-
开放的标准化设备
-
相对较好的性能
-
硬件设备无关性
由于这类虚拟主机接口需要接入软件定义的NFVi数据面,这样天然地将VNF与硬件设备解耦。此外,由于其设备完全由软件模拟,状态热迁移也更可实现,在使用DPDK vHost后端实现对接QEMU的vHost-user后,其I/O性能提高了一个数量级,并可以随着CPU的数量线性提升,使得其在NFV场景下的可用性大大提升。
硬直通
硬直通讲一个硬件设备的能力直接赋予某一个虚拟主机,使得虚拟主机可以获得和裸机下极其相近的特性。但一台设备如果需要被赋予多个虚拟主机,就需要设备能够被切片,或者说能够有设备及总线级别的多路复用技术。
这就是为什么硬件直通通常和SR-IOV联系在一起的原因,SR-IOV是一种PCIe总线多路复用技术。支持SR-IOV的设备,可以将自身切成多个VF(Virtual Function),它们与PF(Physical Function)一样,在主机侧呈现为独立标准的PCIe设备。SR-IOV是一种总线虚拟化技术,或者多路复用技术,VF本身并不一定必须使用在虚拟人机里,真正将其与虚拟机结合的,是硬直通技术。
硬直通的本质是什么?主要解决三个部分的问题:设备BAR配置空间的访问、DMA内存请求直达、中断请求的送达。
第一部分可以用trap-emulation或者通过MMIO的页表映射解决。
第二部分和第三部分需要平台特性的支持(IOMMU)比如:Intel VT-d、AMD-Vi。
IOMMU支持DMA重映射和中断映射。DMA重映射支持一级甚至二级地址重映射,使得DMA请求可以使用虚拟I/O地址访问主存,不再要求DMA地址的物理连续性。
中断重映射支持将设备中断重定向到vCPU的虚拟中断控制器。所以说硬直通是直接得益于平台I/O虚拟化技术的。
DPDK驱动对网卡设备的驱动支持非常全,支持SR-IOV的大多数厂商都提供了VF驱动。
使用硬直通和SR-IOV技术的VF在VM中的特点:
-
几乎和裸机一致的性能。
-
设备驱动对运行环境(VM或Bare-Metal)无感知。
-
硬件设备依赖。
下一代虚拟主机接口
NFV剧烈地重构着网络形态,并依旧不断生长着。从技术角度来讲,有两个关键的因素驱使着各项技术的发展,分别是更高的速度和更好的云化。这两个因素有时又是一对矛盾体,更高的性能往往需要更多的硬件亲和,而云化从某种角度又要淡化硬件的特性。
对于半虚拟化虚拟主机接口,其本身云化能力已经非常完善。所以,改进主要集中在追求更好的网络带宽性能。
以Virtio为例,最新的Spec引入Packed Ring Layout,主要是以减少内存的访问次数为核心的优化方式。由于硬件通过总线访问内存延迟要远高于CPU访问内存,新Layout的引入同样使得Virtio的Ring格式对于硬件访问更友好。
针对vHost的数据平面,利用之前提到的平台I/O虚拟化特性、IOMMU的DMA和中断重映射,使得设备可以直接读写虚拟主机内存和投递中断。这样地址转换、帧buffer的复制及额外的中断中继开销可以进一步降低,比纯软件的零拷贝的中继效率更高。倘若硬件本身还能按照Virtio规范中定义的方式操作Ring,整个数据平面就完全地“硬直通”了。
虚拟主机接口数据平面的软硬之间无缝切换成为可能,硬件提供的是加速能力,而且被特定的硬件规范约束。这里NFV仍旧对Virtio Spec有依赖,但对于NFVi是否使用特定的硬件已经没有了依赖。
虚拟主机接口正在以不同的路径,朝着更好的NFV奔向同一个目标——下一代虚拟主机接口。其特征是NFVi根据VNF的选择提供虚拟主机接口,双方遵照服务质量协议,NFVi运营商可以根据自身需要使用额外无缝硬件加速功能。
从虚拟机到容器的网络I/O虚拟化
相比于基于ASIC等专有硬件的网络功能,虚拟化技术将网络功能与底层硬件彻底解耦,不仅为开发人员提供了更加灵活的开发环境,为产品更新提供了更短的迭代周期,更保证了网络功能的高度隔离性、易用性及安全性。
基于Hypervisor的虚拟技术与容器虚拟化技术有一定区别。基于Hypervisor的虚拟化技术通过一层中间软件将固定的硬件资源抽象为众多的虚拟化资源(通常称为虚拟机)。每一个虚拟机都具有独立的操作系统,运行于完全独立的上下文中。因此,通常一个虚拟机上运行多个操作系统。
而完全模拟硬件资源的Hypervisor虚拟化不同,容器虚拟化是一种资源隔离技术。利用操作系统的命名空间和Cgroups资源分配,容器虚拟化将用户程序隔离于不同的资源实体中运行,而每一个资源实体就称为容器。
在容器虚拟化中,同一主机上的所有容器共享主机操作系统,不对底层的硬件资源进行模拟。相比于虚拟机,容器是一种更加轻量级的虚拟化,能更高效地利用资源,有更快的启动时间,更易于部署和维护。
面向虚拟机的I/O加速方案
在基于Hypervisor的虚拟化中,I/O虚拟化包括两种方式。一种是基于SR-IOVde硬件虚拟化方案,另一种是基于Virtio的半虚拟化。针对这两种方案DPDK都提供了相应的两种用户态加速方案,分别为DPDK PF驱动、DPDK VF驱动和基于DPDK的软件交换机。
网卡的SR-IOV技术将一个网卡虚拟化成许多VF,并将VF暴露给虚拟机,是每个虚拟机都可以独享虚拟网卡资源,从而获得能够与本机性能媲美的I/O性能。为加速基于SR-IOV的网络,DPDK为其提供了相应的用户态的网卡驱动:PF驱动和VF驱动。通过在虚拟机中使用用户态的VF驱动,虚拟机就可以实现高效的网络I/O功能。
Virtio是一种半虚拟化技术的通信协议规范,已经广泛应用于虚拟化环境中。在Virtio环境中,前端的Virtio驱动和后端的vHost设备互联,利用主机的虚拟交换机实现网络通信。为加速基于Virtio的网络,DPDK为前端的Virtio PCI设备提供了用户态驱动(Virtio Polling Mode Driver),并且支持了用户态的vHost设备——vHost-user。通过在虚拟机中使用Virtio PMD和软件交换机中使用vHost-user,可以大幅度提高虚拟机的网络I/O性能。
面向容器的网络I/O加速方案
Linux为容器提供了十分丰富的网络I/O方案,如主机网络和Docker默认使用的网桥,然而基于内核的网络I/O方案在性能上往往无法满足追求高吞吐、低延时的NFV业务的需求。并且,因为虚拟机和容器是两种完全不同的虚拟化技术,因此面向虚拟机的网络I/O加速方案无法直接应用于容器网络。此外现有大部分的基于容器的应用都运行于Kubernetes环境下,这就要求I/O加速方案也能同时支持Kubernetes运行环境。
为了增强容器网络I/O的性能,Intel为Docker容器也提出了与虚拟化I/O加速方案类似的两个I/O加速方案:SR-IOV网络插件和Virtio-user。
SR-IOV插件将网卡的SR-IOV技术应用到容器中,通过将网卡VF加入容器的网络命名空间,容器运行时可以看到网卡。利用DPDK的用户态VF驱动,容器运行时可以实现高速的数据收发包。
Virtio-user是DPDK提出的一种遵循Virtio规范的用户态虚拟设备。与QEMU模拟的Virtio PCI设备相同的是,Virtio-user同样是Virtio的前端设备,可以和任何vHost后端设备,如DPDK vHost-user和Linux Kernel的vHost-net进行通信。
与Virtio PCI不同的是,Virtio-user是为容器量身定制的,并负责网络I/O。再使用Virtue-user的软件交换机方案中,每个容器运行时都有一个Virtio-user设备,此设备将DPDK使用的大页内存共享给后端软件交换机;在共享的内存空间中创建VIrtio Ring结构,并按照Virtio规范定义的Ring操作方式实现通信。
为支持更加灵活、用户自定义的网络模型,Kubernetes提供了符合Container Network Interface(CNI)容器网络规范的网络插件接口。为了将SR-IOV和Virtio-user应用到基于Kubernetes的容器环境中,Intel为两种I/O加速方案分别提供了SR-IOV CNI插件和vHost- user CNI插件。
NFVi平台设备抽象
NFVi需要为VM提供比较好的性能,所以其本身对性能的要求就更高。基于DPDK优化的NFVi是业内主流的方式。NFVi南向接口需要直接面对主机硬件,利用DPDK的硬件抽象框架,能帮助NFVi软件减少不同硬件带来的差异性。
DPDK提供多种设备抽象,已被支持的设备有ETHERDEV、EVENTDEV、CRYPTODEV、RAWDEV、BBDEV、SECURITYDEV等。这些设备大多面向功能进行设备抽象,其支持的硬件从功能固定的网卡、加解密加速卡,可编程的Smart-NIC、FPGA,甚至面向无限Base Band的设备都提供了支持。而很多抽象设备都有基于CPU ISA的实现,比如使用AES指令实现的CRYPTODEV实例和OPDL库实现的EVENTDEV。
CRYPTODEV是对加解密设备的抽象,提供一组API,加解密请求被封装在一组Context中,由DPDK应用实例向加解密设备发起加解密的请求。
EVENTDEV是一种抽象事件设备,其主要作用是为DPDK应用提供事件调度设备接口,便于应用采用事件驱动模型编程,而不需要理解调度设备的具体实现细节。
RAWWDEV为在DPDK中还未有改设备抽象的设备提供了一个选项。
Representor端口:
内嵌Switch功能的网卡通过SR-IOV方式暴露出多个端口,用户把Virtual Function直接分配(pass-through)给虚拟机,设备交由VM直接访问。在host上,可以通过PF内核驱动对VF做管理配置。
Representor端口和一般的以太网端口不同的是,由于它主要用来做管理配置,因此可以不实现收发包函数。如果需要处理Exception Path 的流量,则需要实现相应的收发包函数接收来自对应VF的异常报文。
通过VF Representor端口调用的Ethernet API最终都是通过PF driver实现的,Representor端口的作用就是封装了PF对VF的配置函数,使得用户可以通过标准的ethdev API对VF进行管理。