SR-IOV技术在数据中心网络中的应用

汤 泳，郭 宁（中讯邮电咨询设计院有限公司，北京 100048）

0 前言

云计算技术经过十多年发展已经逐渐成熟，由于其能够给企业IT 运营、业务创新等带来明显效用，上云已经成为企业常态。近几年公有云、私有云、混合云、行业云的建设如火如荼，但是随着云计算的深入使用，应用规模不断增加，现有数据中心网络应用在达到一定规模后遇到性能瓶颈。

1 网络虚拟化技术

虚拟化技术将计算机物理资源如服务器、网络、内存及存储等映射为虚拟资源，实现多用户共享物理资源。虚拟化是实现云计算的基本技术，目前主流VM 的网络虚拟化都是使用虚拟交换机技术，借助虚拟交换机，可以为服务器上运行的VMs 或容器提供逻辑的虚拟以太网接口，这些逻辑接口都连接到虚拟交换机上。比较流行的虚拟交换机包括VMware virtual switch、Cisco Nexus 1000V 和Open vSwitch。其中Openvswitch（简称OVS）是一个优秀的开源软件交换机，支持绝大多数的交换机功能如二层交换、网络隔离、QoS、流量监控、3 层路由控制等，同时支持多种Linux 虚拟化技术，包括Xen、KVM 以及VirtualBox，所以在市场上应用较为广泛。一般基于虚拟交换机技术的典型的数据中心IaaS云计算网络如图1所示。

图1 基于虚拟交换机数据中心网络组织架构图

数据中心云计算网络一般采用分层设计，底层网络采用Spine-Leaf 两层扁平化网络架构，以保证节点内的任意2个端口之间可提供延迟非常低的无阻塞性能；同时考虑数据中心网络的扩展性会在数据转发平面引入VxLAN 技术，在控制层面引入EVPN 技术以构建一个全互通的大二层的底层网络架构。

业务网络则通过虚拟网络技术以Overlay 底层网络的方式来实现网络的部署。从图1可以看出网络业务控制主要由计算资源上部署的软件虚拟交换机来实现。宿主机除了分配提供虚拟机外，还需要承担虚拟交换机的任务。通过开启虚拟交互机服务在服务器端模拟物理交换机的功能，在虚拟机之间、虚拟机和外部网络之间实现网络的连通。

随着管理节点的扩充，相关的网络管理控制功能会消耗更多的计算资源，导致整个平台的运行效率下降。有资料表明当管理节点数量超过200 个时，网络性能开始明显下降，但底层的网络利用率却不是很高，造成资源的浪费。经过分析网络性能下降的原因主要有以下2方面。

a）采用软件虚拟交换机方式应用部署比较方便，但是软件的运行效率比专用的网络设备差。

b）在传统网桥模式下，网络稳定一般是没有问题的，但网桥模式本身会消耗宿主机的CPU，在实际场景下，随着节点资源的增加，虚拟化平台所需的计算资源也会大幅增加，虚机交换机的计算资源也会增加，当宿主机的CPU 压力（＞60%）比较大时，虚拟机内部网卡的发包率（PPS）会下降，极端情况会出现丢包现象。

为了保证云平台系统的线性扩展能力，将网络虚拟化能力从计算资源中剥离，采用专用的网络设备进行替代是一个思路；如何有效保证网络虚拟化带来的快速灵活部署能力，高效实现云网结合涉及到多个方面的问题，本文主要关注VM网络虚拟化的解决方案。

2 基于硬件的网络虚拟化技术

2.1 SR-IOV技术介绍

为了解决网络性能问题，首先可以考虑网卡直通技术，这项技术能让VM 独占物理网卡，以达到最优性能，建议在网卡性能要求非常高的场景中使用。然而一台服务器主板上的空间比较有限，允许添加的PCI和PCIe 设备是有限的，如果一台宿主机上的VM 数量较多，那主机很难向每台VM 都分配独立网卡。另外，分配大量网卡给客户机独立使用会增加硬件投资成本。为解决物理网卡数量和成本问题考虑使用虚拟化网络I/O 的硬件技术方案SR-IOV（Single Root I/O Virtualization）。

SR-IOV 技术是一种基于硬件的网卡虚拟化解决方案，允许在虚拟机之间高效共享PCIe 设备，这样每个VM 都可访问唯一的虚拟资源；因此启用了SRIOV 并且具有适当的硬件和OS 支持的PCIe 设备（如网卡）可以显示为多个单独的物理设备。SR-IOV 技术原理如图2所示。

SR-IOV 技术引入了以下3 个功能（function）类型。

a）物理功能（PF——Physical Function）：拥有包含SR-IOV 扩展能力在内的所有完整的PCIe 功能，简单说PF 就是一个普通的PCIe 设备，可以放在宿主机中配置和管理其他VF，它本身也可以作为一个完整独立的功能使用。

b）虚拟功能（VF——Virtual Function）：由PF衍生而来的“轻量级”的PCIe 功能，包含数据传送所必需的资源，但是仅拥有最小化的配置资源。简言之，VF 通过PF的配置之后，可以分配到客户机中作为独立功能使用。SR-IOV 为VM 中使用的VF 提供了独立的内存空间、中断、DMA 流，从而不需要Hypervisor 介入数据的传送过程。SR-IOV 架构设计的目的是允许一个设备支持多个VF，同时也尽量减小每个VF的硬件成本。

图2 SR-IOV 技术原理图

c）交换功能（Layer 2 switch）：交换机功能其实是物理网卡内置的。流量进入物理网卡后，经过这个交换机后分发到不同的VF上。

2.2 基于虚拟网卡的网络功能

对宿主机来讲，网络虚拟化要解决虚拟网络在宿主机内/外的隔离和互通2 个问题。引入SR-IOV 技术可以使每个VM 拥有专有网络硬件资源，可以使网络层面的隔离更彻底。但如何实现多VM 之间的网络控制管理就没有那么简单了。

传统的OVS 只有一个虚拟交换机，所以网络控制比较容易。由于VM 直接操作专属网卡，可以通过引入外部的物理交换机的方式进行控制，比如可以为每个VM 虚拟网卡创建对应交换机的子端口，然后对每个VM 的流量打上VLAN-ID 标识来区分不同虚拟机的流量，从而实现网络控制。宿主机内部同网段的VM 的互通可以通过SR-IOV 内置的交换功能实现。虚拟机网络之间的连接如图3所示。

目前很多主流的中高端网卡都支持SR-IOV，如Intel 82576 网卡、I350 网卡、82599 网卡、X540 网卡等。在宿主机Linux环境中，可以通过“lspci-v-s$BDF”的命令来查看网卡PCI 信息的“Capabilities”项目，以确定设备是否具备SR-IOV 的能力。同时主流的虚拟化平台/方案（如KVM、Xen、VMware、Hyper-V 等）都实现了对SR-IOV技术的支持，在平台中可以将1个或多个VF 分配给1 个客户机，客户机通过自身的VF 驱动程序直接操作设备的VF而不需要Hypervisor的参与。

图3 虚机网络之间连接模式

SR-IOV技术有以下优点。

a）良好的性能，虚拟机可以绕过虚拟化层和系统，直接访问硬件，没有虚拟化层软件模拟的开销。

b）降低成本，减少了设备数量，例如网卡的SRIOV 减少了网卡数量、交换机端口和网线。既能提高访问效率，又能提高网卡的利用率。

1 个设备可支持多个VF，PCI-SIG 的SR-IOV 规范指出每个PF 最多能拥有256 个VF，而实际支持的VF数量是由设备的硬件设计及其驱动程序共同决定的。例如使用“igb”驱动的82576、I350 等千兆以太网卡的每个PF 最多支持7 个VF，而使用“ixgbe”驱动的82599、X540等万兆以太网卡的每个PF最多支持63个VF。目前的服务器主流配置都是支持63 个VF 的网卡，基本可以满足虚拟化平台创建VM的需求。

3 SR-IOV技术应用示例

在SR-IOV 的实际应用中硬件平台需要支持Intel VT-x 和VT-d（或AMD 的SVM 和IOMMU），另外还需要支持SR-IOV 规范的设备。下面举例说明如何在Centos7上的KVM 虚拟化环境中用SR-IOV 技术为VM绑定虚拟网卡并打上VLAN-ID。需要说明的是后续配置中使用的网卡是Intel Corporation 82599ES。

3.1 环境准备

首先检查网卡是否支持SR-IOV，然后通过yum命令进行KVM 虚拟化环境的安装，开启libvirtd 服务并设置为开机自启动模式。

3.2 配置SR-IOV创建VF

在BIOS 中启用英特尔VT-d 功能，重新生成配置文件grub2.cfg；运行lspci命令进行网络信息查看，确保对应网络设备可以被系统识别。同时根据网卡的驱动参数在/etc/udev/rules.d/目录下创建以.rules 为后缀的配置文件，完成VF的创建。

3.3 虚拟机分配VF

首先需要将VF从宿主机中解绑，同时编辑虚拟机的XML 文件，进行参数配置；使用编辑的XML 文件启动虚拟机。经过以上步骤，一个基于SR-IOV 网卡就与对应的虚拟机绑定成功。

其中网卡部分配置示例如下：

3.4 SR-IOV 性能验证

本文对比测试万兆网络中SR-IOV 虚拟机和OVS虚拟机在网络负载较高情况下的虚拟网络表现，也为后续SR-IOV 虚拟机和其他类型的虚拟机对比给出参考。

3.4.1 测试环境

宿主机配置：2 个Intel（R）Xeon（R）Gold 5218 CPU，内存576 G，1 个Ethernet Connection X722 for 1GbE 网卡用于管理宿主机，2 块82599ES 10-Gigabit SFI/SFP+Network Connection 网卡用于流量测试，这2块网卡都接入到同一台交换机上，交换机配置为CE6855-48S6Q-HI。

3.4.2 网络吞吐率性能测试

在宿主机上创建2 台VM 分别发包和收包来进行网络吞吐的压力测试。VM 配置均为4 核4G，测试工具为modprobe pktgen，测试包为UDP 包，大小为64 B。测试场景如图4 所示。场景1 为SR-IOV+VF 直通方式，2台VM分别使用1块物理网卡；场景2为SR-IOV+VF 直通方式，2 台VM 共同使用1 块物理网卡；场景3为OVS+虚拟网卡方式，2 台VM 分别使用1 块物理网卡；场景4 为OVS+虚拟网卡方式，2 台VM 共同使用1块物理网卡。

图4 性能测试场景示意图

通过测试工具分别统计不同场景下的发包性能和收包性能，结果如表1所示。

表1 网络吞吐数据统计表

本次测试得出以下结论。

a）采用SR-IOV+VF 直通方式可以显著提升转发率，相同配置条件下，发包提升865%，收包提升470%。

b）SR-IOV+VF 直通方式在1 块物理网卡和2 块物理网卡的表现基本一致，证明VF性能可以实现线性增长。

c）OVS+虚拟网卡方式下，同一物理网卡的转发性能相比于不同物理网卡的转发性能有略微提升。

4 主机CPU资源占用测试

对1 台宿主机上的1 对或多对VM 进行网格吞吐测试，对比SR-IOV 及OVS 方式在主机CPU 占用率和网络吞吐率方面的表现。

在宿主机上创建12 台VM（配置均为2 核4G），每台VM 一块网卡，2 台VM 一组共6 组，组内分A、B 两端，其中A 端的VM 发包，B 端的VM 收包，每组A 端的VM 使用同一块网卡，每组B 端的VM 使用另一块网卡。依据使用的技术和网卡分配方式不同分以下2个场景分别进行测试。测试包规格为UDP包256 B。

a）场景1：12 台VM 都使用SR-IOV+VF 直通方式，第1 次使用1 组VM 收发包（共涉及VM 2 台），第2次使用2组VM 收发包（共涉及VM 4台），第3次使用3组VM 开始收发包，依次类推直到6 组VM 都开始收发包，分别观察流量及宿主机CPU使用率。

b）场景2：12 台VM 都使用OVS+虚拟网卡方式，第1次使用1组VM收发包（共涉及VM 2台），第2次使用2 组VM 收发包（共涉及VM 4 台），第3 次使用3 组VM 收发包，依次类推直到6 组VM 都开始收发包，分别观察流量及宿主机CPU使用率。

具体采集数据如表2所示。

由表2 可以看出使用SR-IOV+VF 直通方式可以明显减少CPU 使用率；同时SR-IOV+VF 直通方式每增加1 组VM，宿主机CPU 使用率增长9.5%左右，而OVS+虚拟网卡方式每增加1 组VM，宿主机CPU 使用率增长12%左右。

表2 主机CPU资源占用率统计表

同时采用SR-IOV+VF直通方式网络吞吐率更高，1 组VM 时流量为4 602.5 Mbit/s；在3 组VM 时流量已达到9 006 Mbit/s 左右，接近万兆网卡的最大带宽，此时CPU 负载为28.2%，网卡吞吐能力成为了瓶颈。OVS+虚拟网卡方式1 组VM 时，流量仅为875 Mbit/s，直到6 组VM 时，流量为4 643.5 Mbit/s，而此时宿主机CPU使用率已达70.95%。

从以上测试中可以发现，相比OVS 方式，SR-IOV对网络性能的提升更明显，同时SR-IOV 方式可以减少对主机CPU的占用。

5 数据中心网络方案建议

引入SR-IOV 技术后可以实现为每一个虚机创建一个独立的网卡，数据中心的网络初步具备了以传统网络设备为基础进行整个IaaS层网络管理的条件。数据中心的网络架构可以调整为如图5所示的模式。

图5 基于网络设备数据中心网络组织架构图

从图5可以看出，网络的组织架构变化很小，但是网络运行发生了实质的改变。传统网络的具体业务处理都是由虚拟化平台（IT 方式）进行处理，有较为成熟的解决方案但IT 方案标准化程度低，多虚拟化平台网络互通一直是困扰数据中心建设的一个问题。而网络设备的规范性高，设备互通性好，通过以网络设备为核心的方式可以彻底解决多个虚拟化平台的网络互通问题。用专用的网络设备实现数据包的转发、控制可以进一步提高数据中心网络的效率，同时可以省去宿主机的计算资源，提供给业务应用，从而进行一步提升服务器资源的利用率。

但以网络设备为核心的架构中，需要使用网络设备实现业务网络的管理控制，为了保证业务开通的灵活性和业务开通的效率，必须引入SDN 等技术。本文提出一个分层的数据中心的整体结构，把计算资源与网络资源分层，云管平台负责管理计算资源，并且可以通过网络接口调用SDN 网络控制器，从而在实现数据中心高效管理的同时保持网络的弹性和性能，具体架构如图6所示。

图6 数据中心分层组织架构示意图

6 结束语

本文通过对数据中心网络现状进行分析，总结数据中心网络虚拟化在实际应用中所面临的问题，提出通过SR-IOV 技术实现VM 网络虚拟化的思路，并给出了SR-IOV 技术具体应用示例及性能测试结果，验证了SR-IOV 技术应用的效果，最后提出云网一体分层的网络构建思路。