SR-IOV在云计算数据中心的应用方法、价值和前景

2007年9月，PCI-SIG官方发布了《Single Root I/O Virtualization and Sharing Specification Revision 1.0》规范，定义了多个System Images如何共享PCI接口的I/O硬件设备，这里的设备可以是PCIe 网卡，一块PCIe SSD等等。

这就是今天要讨论的话题——SR-IOV，一种硬件角度出发的虚拟化解决方案，本文不仅会对这项技术的概念和原理进行介绍，还会结合AWS以及Memblaze的研究来探讨SR-IOV在云计算数据中心的应用方法、价值和前景。

SR-IOV及虚拟化系统中相关概念

在介绍之前，需要先明确一些SR-IOV相关的概念，一个典型的SR-IOV方案架构如下。

SR-IOV的实现模型

（来源：http://www.pcisig.com/）

System Image（SI），客户机，或者称虚拟机OS。

Virtual Intermediary（VI），虚拟机管理层，是物理机和虚拟机的中介，可以是hypervisor或者VMM。（SR-IOV的主要作用就是消除VI对I/O操作的干预，进而提升数据传输性能）。

SR-PCIM，配置和管理SR-IOV功能以及PF/VF的软件，SR-PCIM可以处理相关的错误和实现设备的整体控制（比如实现电源管理和热插拔，一个PCIe设备支持SR-IOV时，SR-PCIM就可以通过热插入的方式为物理主机添加VF设备，然后就可以配置VF给虚拟机使用。）

PF（Physical Function），SR-IOV中的关键概念， PF 是 PCIe一种物理功能，每个PF都可以被物理主机发现和管理。进一步讲，借助物理主机上的PF驱动可以直接访问PF所有资源，并对所有VF并进行配置，比如：设置VF数量，并对其进行全局启动或停止。

VF（Virtual Function），PF虚拟出来的功能。一个或者多个VF共享一个PF，其驱动装在虚拟机上，当VF分配给虚拟机以后，虚拟机就能像使用普通PCIe设备一样初始化和配置VF。如果PF代表的是一张物理网卡，那么VF则是一个虚拟机可以看见和使用的虚拟网卡。

一句话解释SR-IOV

SR-IOV通过将PF分为多个VF为上层虚拟机使用，相当于虚拟机绕过VI直接使用PCIe 设备处理I/O和传输数据。

值得一提的是，物理主机启动时不能简单的扫描SR-IOV设备并列举出所有VF，因为VF没有完整的PCIe配置空间。可以用Linux PCI热插拔API动态为物理主机增加VF，然后分配给虚拟机使用。

SR-IOV实现的价值

传统虚拟化系统中大量的资源和时间损耗在Hypervisor（或者VMM）软件层面，PCIe设备的性能优势因此无法彻底发挥。而SR-IOV的价值在于消除这一软件瓶颈，助力多个虚拟机实现物理资源共享，同时使得虚拟机可以使用到NVMe SSD的高性能。

在此我们可以总结得出SR-IOV优势：

实现SR-IOV之后，VMM把中断交给虚拟机处理,而不是VMM处理I/O，提高了性能；

虚拟机直接和PCIe设备交互减轻物理主机CPU负担，使之有能力承载更多虚拟机；

SR-IOV虚拟化技术可以减少客户所需PCIe设备数量，进而节省PCIe插槽；

SR-IOV可以与其他的I/O虚拟化技术进行结合提供一个更加完整的兼具高性能和安全性的解决方案。

以NVMe SSD为例，今天的一块NVMe SSD容量可以达到十几TB，而IOPS冲到了100万，同时有着微秒级的延迟。SR-IOV可以使NVMe SSD直接被上层多个VM所用，SSD的性能优势也可以直接被上层应用感知到。

可以看到虚拟化和云计算都是SR-IOV大显身手的领域。事实上，我们看到当前走在SR-IOV实践最前面的，就是云计算巨头AWS。接下来我们也将通过AWS公布的一些资料解读SR-IOV的实现和瓶颈。

从AWS实践看SR-IOV

AWS从全局的角度考虑，构建了一套基于Nitro System的方案，实现存储、网络等多种VF功能，为此，AWS在2015年收购了以3.5亿美元收购以色列芯片商Annapurna Labs。

下图展示了AWS在SR-IOV上的进展，可以看到AWS经历了从全虚拟化到半虚拟化，而后的2013年到2017年，通过使用SR-IOV技术使得虚拟机的网络和存储性能，逐步达到近似Bare-metal performance的水平。

从AWS产品服务来看，2013年的CR1的实现，不论存储和网络访问都是要过Amazon的hypervisor layer（Xen）的。

而到了2017年的C5，VM的EBS Storage和Network全部不通过Amazon Linux hypervisor layer，而通过Lightweight Nitro hypervisor。

对于这个Nitro Hypervisior，AWS给出的解释是这是一个new hypervisor，但是不仅仅是个hypervisor。基于Annapurna Labs这颗芯片，AWS实现了PCIe设备PV到VF的SR-IOV虚拟化功能，利用Nitro Hypervisior实现了QoS管理功能。看AWS的C5和C5D机型的配置，VF可以是50、100、200、400、900GB的大小。

Memblaze测试工程师申请了一个亚马逊AWS服务器以及一个c5d.large的NVMe SSD，从AWS官方看到实例配置可知c5d.large的IOPS读被限制在2万IOPS、写被限制在9000IOPS。

Memblaze申请的AWS服务器

Amazon EBS 和 NVMe

在基于 Nitro system的虚拟机上，EBS 卷显示为 NVMe 块储存设备，这些设备依赖于操作系统上的标准 NVMe 驱动程序。这些驱动程序通常在虚拟机启动期间，通过扫描 PCI 总线来发现连接的设备，然后根据设备响应的顺序创建设备节点。设备名称为 /dev/nvme0n1、/dev/nvme1n1，以此类推。

实测，可以看到AWS可同时给云主机提供EBS（上图Amazon Elastic Block Store）远程存储和本地NVMe SSD（上图Amazon EC2 NVMe Instance Storage），两者均被识别为一个PCIe设备。

分别测试两者的读和写延迟。测试结果如下：

AWS VM的Instance store(nvme1n1)读latency在96μs

AWS VM的Instance store(nvme1n1)写latency 99.95%都在24-37μs

通过Nitro 虚拟化后虚拟机仅增加了10μs延迟。AWS全局的SR-IOV设计理念在于，存储和网络都可以通过Nitro系统实现SR-IOV，分布式的EBS卷经Nitro Card到虚拟机就成为了一个NVMe块存储设备，而不需要底层的SSD支持SR-IOV。

但是全球只有AWS做到了这点，他的SR-IOV实践证明这项技术价值的同时也展示了其技术实力。

Memblaze在SR-IOV领域的研究现状

另一方面，SSD实现SR-IOV的同时，需要系统做相应的修改和调优处理，这里总结了企业客户实现SR-IOV的几点需求。

从安全性考虑，NVMe SSD需要实现多命名空间管理，并且满足使用命名空间的租户之间不能互相访问到数据，尤其是命名空间重新分配给云主机用户的时候。

从云主机业务性能QoS保障的角度，需要NVMe SSD实现不同VF之间的I/O隔离。而这里的I/O隔离同样需要基于多命名空间实现。

（关于多命名空间可以参看文末相关阅读中的《实锤，PBlaze5实力演绎multiple namespaces 功能》）

PCIe驱动以及NVMe驱动的修改。驱动是连接系统和SSD的关键，这里需要修改PCIe Driver对 VF BAR空间地址的分配机制以及修改NVMe Driver对VF I/O超时处理的机制

最后也是最重要的是合作，SR-IOV实现需要Memblaze与客户进行环境联调，以及大规模测试验证，以此保障SR-IOV功能的可靠性、性能表现等。