软硬件融合技术内幕 进阶篇 (4) ——云计算的六次危机(中)

在上期，我们发现了一个规律：

云计算数据平面发生危机，一般是因为计算机CPU性能的线性增长，难以跟上网络带宽的指数提升，及其带来的“数据中心税”的增加。

工程师们发现，虽然危机的根本原因在于网络带宽指数提升，与CPU性能线性增长之间的矛盾，但其表相是“数据中心税”的增加。因此，工程师们创造了VirtIO和vHost等技术，借此降低了数据平面虚拟化产生的“数据中心税”，从而解决了第一次和第二次危机。

当以太网速率从25G向100G发展的过程中，第三次危机到来了——

让我们回顾一下上期。

VirtIO通过在虚拟机操作系统中植入一个针对虚拟IO设备的驱动程序，避免了全虚拟化网卡(如E1000等)对网卡收发操作触发VM_Exit的开销，解决了虚拟化网络性能从1G到10G的危机；

vHost通过将VirtIO后端驱动数据平面的实现，从用户态的QEMU移入内核态，从而减少了一次用户态和内核态之间的切换，减少了大量数据包收发的开销，解决了虚拟化网络性能从10G到25G的危机；

那么，当虚拟化网络从25G演进到100G时，有没有办法进一步减少“数据中心税”呢？

工程师们想到了把vHost的数据平面搬回用户态——当然，顺带也把virtio的前端驱动也搬回用户态。这就是vhost-user技术。由于其开发使用了Intel的DPDK，因此，一般也称为DPDK vhost-user。

为了保证数据包的整个生命周期 (也就是所谓的Fast Path)都在用户态中处理，不进行user space到kernel mode的切换，我们还需要做两件事情：

1. 将虚拟机中的虚拟网卡驱动 (VirtIO前端驱动)迁移到用户态；
2. 宿主机上的vSwtich(如OVS)迁移到用户态；

1称为virtio-pmd。它是一套驱动程序抽象规范，实现基于轮询的网络驱动程序。pmd就是poll mode driver的缩写。其核心设计思想是利用轮询代替中断，避免中断带来的额外开销；

2称为OVS-DPDK。它是在用户态利用DPDK实现的OVS，同样地，它也依赖于物理机上网卡(NIC)为DPDK提供的用户态驱动，从而可以在用户态操纵物理网卡收发数据包。

下图是这种组合的数据平面流向。

当然，为了实现快速地将数据包从VM传输到host，再从host给OVS-DPDK，而不需要内存拷贝，还依赖于vIO-MMU的能力，使得VM可以与host使用不同的虚拟地址访问同一块物理内存，也就是GVA(Guest Virtual Addess)和HVA(Host Virtual Address)指向同一块物理内存HPA(Host Physical Address)。其具体实现可以看这里：《虚拟化与云计算硬核技术内幕 (8) —— “饭圈互撕”的末路》

最终，VM上virtio-pm发出的数据包，所在的物理内存地址，会作为物理网卡包描述符中的DMA地址，在DPDK驱动中直接操纵物理网卡MAC核从该地址读取数据并发送到网络线路上。

DPDK的引入，在大量小包的场景下规避了频繁中断及进出内核的开销，而在大包收发的场景下又通过基于vIO-MMU实现了零拷贝(zero-copy)，从而很轻易地将整机网络吞吐量提升到了双口100G的级别，解决了第三次危机。

然而，虽然DPDK大致解决了虚拟化数据平面收发的性能问题，另一朵乌云却开始笼罩在了网络虚拟化世界的天空……

我们知道，Intel设计DPDK的初心，是因为在通信设备市场上，MIPS、ARM和PowerPC等非x86处理器，结合定制化的通信硬件加速模块和用户面驱动，以较低成本的处理器能够实现较高的网络处理性能，从而对Intel造成了一定的冲击。

举一个例子：2009年，Broadcom出品的多核网络处理器XLP 832，以8个MIPS内核 (支持32个超线程)，能够轻松实现40Gbps的网络吞吐，而此时的Intel处理器+Linux操作系统，处理4Gbps的网络吞吐都较为困难。而在引入DPDK后，Intel使用双路8核，整机32个超线程，可以跑到200Gbps的三层转发吞吐量。这使得利用标准x86服务器实现负载均衡、防火墙、4G核心网等应用层网元，其性价比迅速超越了使用专用的多核处理器，也揭开了网元NFV化的序幕。

随着Intel处理器核数的增加，以及云计算的普及，工程师们更希望在同一台Intel x86服务器上，运行多个不同的NFV功能，针对云网络中虚拟VPC的编排提供灵活的NFV调度能力。

这样一来，就引发了第四次危机——

如图，如果我们把NFV部署在虚拟机中，数据的流向如下：

来自物理网卡的数据首先要通过vSwitch，也就是OVS-DPDK，然后才能够被NFV处理。这样就带来了三个问题：

1. OVS-DPDK会造成数据包处理的延时增加；
2. OVS-DPDK会占用一定的宿主机CPU核数，从而减少可分配给NFV的CPU数量；
3. OVS-DPDK还会占用更多的数据包buffer，浪费内存；

第四次危机就是，网络NFV化，与宿主机OVS之间的矛盾。

对于第四次危机，工程师们的思路也很简单直接——干掉OVS，把网卡直通给虚拟机，让虚拟机的数据直接出宿主机，如下图所示：

显然，宿主机上虚拟机的数量可能是比较多的，甚至多达100个以上。我们不可能为宿主机安装这么多物理网卡，需要让一张物理网卡同时被多个虚拟机所使用。

这就需要网卡硬件的配合了，也就是进一步通过软硬件融合的方式来降低数据中心税，以解决云计算数据平面的第四次危机。

请看下期。