最近看到有国内厂家打出“虚拟化网卡”的概念，我认为这个提法是非常有价值的，可以让更多的人开始思考网络I/O在虚拟化发展中的重要性，但什么才是“虚拟化网卡”？“虚拟化网卡”有何作用？也许这个概念本身并不清晰，在更多的场合仅被作为一个忽悠的工具在使用。另一方面，今天的服务器网卡确确实实在发生一些重要的变化，这些变化将对整个数据中心产业今后的发展产生至关重要的影响。
我希望通过自己的理解，引来更多高手的讨论，最终对这个概念提出一个明确、清晰的认识。毕竟，技术名词是要落地的，我们需要的是“云计算”而不是“晕计算”。
关键词：虚拟化网卡
厂商：Cisco、Intel 。。。
领域：数据中心网络
模糊程度：四星
缘起：虚拟化的最后一公里
在推动虚拟化轰轰烈烈发展的众多因素中，资源的再利用是很重要的一点，当一台服务器只运行一个业务时，其CPU资源往往没有被充分利用，花大价钱购买的CPU就这样沉睡在机架上，干耗电不干活。大多数客户都希望在部署虚拟化之后，将原来服务器可怜的CPU利用率尽可能提高一些。虚拟化软件（如VMWare vsphere、XEN、KVM等）很好地解决了这个问题，在虚拟化软件中，一颗CPU能够被分配给多个虚机同时使用，部署了虚拟化软件的服务器，其CPU利用率往往能够从不到10%增长到70%左右。
这当然非常棒，可任何新技术的发展都是一个以点带面的过程，好像抗生素的发明虽然挽救了成千上万的生命，但人类至今仍在为对抗其带来的副作用而努力。虚拟化技术也不是真空中的产物，它需要同数据中心内部的主机、存储、硬件等方方面面发生关系，当操作系统的运行方式发生变化时，原先的基础架构并不一定能适应这种变化，新的挑战开始浮出水面，
首先告急的就是内存，当CPU主频在Intel和AMD的竞争中，如脱缰野马一般往前发展时，其他部件并没有以相同的速率前进。内存大小就一度制约了单台服务器上虚拟机–也就是VM（Virtual Machine）–数量的增加，由于大量OS实例同时运行在内存中，服务器的内存容量很快捉襟见肘。为了解决这个问题，各个服务器厂家开始疯狂增加DIMM槽容量，现在单台X86服务器最大内存已经可以达到令人匪夷所思的1TB！
内存警报暂时解除后，网络逐渐成为新的瓶颈。当越来越多不同性质的虚拟机跑在一台物理服务器上时，他们的进出数据都会拥挤在一个I/O通道上，这显然是不合理的。以Cisco为首的网络厂家提出了VN-Tag/VEPA等解决方案，来规范虚拟机流量的转发机制，通过在全网部署VN-Tag，不同虚拟机的流量能够被识别，并且在上联交换机上得到很好的QoS保证和安全隔离，但这只解决了一部分问题，虽然VN-TAG能够区分出来自不同虚拟机的流量，但普通服务器网卡只提供一个PCIe通道，在出口网卡上，这些流量仍然混杂在一块。
单一通道造成问题的典型例子是高性能计算环境。
虚拟软件平台也就是Hypervisor往往集成了一个软件交换机，这个软件交换机通过CPU模拟出简单的二层转发功能。传统的解决方案中，多台虚拟机通过一个Hypervisor软件交换机连接到一张物理网卡上，流量进入软件交换机不但消耗CPU资源还产生了时延，这还不要紧，在高性能计算环境中，上层业务对网络I/O的设置有非常敏感的反应，虚拟机往往要求特殊的端口队列模型，如果模型不对，性能可能大幅下降甚至不可用，而单一的物理网卡无法对上层多个操作系统提供不同的队列服务，进一步影响了性能。
既然软件交换机是问题，最直接的思路就是绕过软件交换机。因此，VMWare、Intel、AMD等提出了Hypervisor Bypass方案，也就是说虚拟机绕过软件交换机直接同网卡打交道，这样做的好处是一个虚拟机独享一个PCIe通道，想怎么玩就怎么玩，能够实现接近于访问物理PCIe设备的功能和性能。这个方案在主流平台上有不错的支持，VMWare VMDirectPath和Intel VT-d/AMD IOMMU等相关技术都有比较广泛的部署。
上面这种形式的Hypervisor Bypass满足了虚拟机对I/O性能的要求，但它远非一个一劳永逸的办法，基本是个半拉子工程，其思路是利用物理网卡为VM直接服务，从而暂时回避了传统I/O跟不上虚拟化发展的问题。最大的缺陷就是每个虚拟机都独占一个PCIe插槽，而插槽意味着什么呢？意味着money！在不断扩张的服务器机房内，每一个PCIe插槽都牵动着能耗、散热和空间的支出，更不用说单台服务器上PCIe插槽的数量上限了。这种以大量占用物理网卡数量为代价的方式很快就会遇到PCIe插槽数量的极限，不是一个可持续发展的方案。
也许有人会问，能不能通过优化Hypervisor的网络功能来解决这个难题呢？首先，网络不是虚拟化软件目前的开发重点；其次，软件的开销太大，普通万兆网卡在多VM的传输环境下已经占用了不少系统资源，如果还要精确、高效地模拟不同虚拟机的传输队列，将会消耗大量CPU资源；最后，软件实现的效率也不高。
随着邮件、OA等简单应用在虚拟化平台上的成功运行，越来越多的重要业务将开始向虚拟化迁移，这些业务中很大一部分都对网络I/O有着严格要求。我们搞定了CPU，搞定了存储，搞定了内存，搞定了交换机，却没来及搞定服务器上一块小小的网卡，当其他所有都不再是限制的时候，I/O这块短板开始慢慢显现，成为阻碍虚拟化发展的最后一个瓶颈，也就是接通虚拟化世界的最后一公里。
所以我们看到”虚拟化网卡”应运而生了，这个概念出现在这个时间点是一件自然而然的事，是技术进化到一个阶段的必然产物，只有跨过这个坎，虚拟化才可能开始向更高的段位发展。
那么，下一个问题就是：什么是虚拟化网卡？
什么是虚拟化网卡？
除了基本的数据转发，上层业务对网络的需求可以归纳为以下两点：
1）安全隔离；
2）服务质量保证QoS
实现这两点的前提都是对数据流量进行清晰的区分，只有区分出不同的流量，才能根据业务类型配以不同的保障等级。如果以服务器出口为界，我们可以将数据流过的路径划分为外部和内部两部分。
对于服务器外部网络：VN-TAG/VEPA可以区分出不同虚拟机的流量，并在整个数据中心内部署有针对性的隔离和QoS策略，我们称为“虚拟接入”；
对于服务器内部：虚拟化网卡要在不破坏现有业务机制的前提下，为每个虚拟机提供一个模拟真实的网络通道，这个模拟出来的虚拟通道不仅仅要对VM透明，而且要尽可能重现在非虚拟化环境中的一切网络机制，我们称为“虚拟通道”。只有在这样的环境中，上层业务在向虚拟化迁移的过程中，才不必因为网络环境的变更而做出改动，从而尽量减小迁移成本，加快迁移流程。虚拟机产生的数据通过独立通道进入网卡 ，紧接着被打上标签送往外部网络，反向亦然，对于上层业务来说，感受不到I/O的变化，所有的数据行为同运行在一台独立物理服务器上无异。
因此，我们可以定义虚拟化网卡的核心是“虚拟接入”和“虚拟通道”，只有补上这两块短板，才真正打通了服务器网卡的虚拟化瓶颈，彻底解决了服务器端的网络I/O限制。
在这里有很多针对虚拟接入的非常棒的讨论，下面介绍虚拟通道技术。
SR-IOV
虚拟通道的实现方式有很多，由于其在未来虚拟化环境中的重要性，大佬们纷纷提前卡位，其中PCI-SIG制定的SR-IOV影响力最大，其背后推手是Intel、Broadcom等巨头。
大多人认识虚拟通道都是从SR-IOV开始，SR即Single Root，IOV为I/O Virtualization，合起来就是将单个PCIe设备（Single Root）–如一个以太网卡–对上层软件虚拟化为多个独立的PCIe设备。
SR-IOV虚拟出的通道分为两个类型，PF（Physical Function）和VF（Virtual Funciton）。
- PF是一个完整的PCIe设备，包含了全面的管理、配置功能，当Hypervisor识别出一块SR-IOV网卡后，会通过PF来管理和配置网卡的所有I/O资源；
- VF是一个简化的PCIe设备，仅仅包含了I/O功能，无法通过VF对物理网卡进行管理，所有的VF都是通过PF衍生而来，一块SR-IOV网卡最多可以生成256个VF
每一个VF都好象物理网卡硬件资源的一个切片，对于虚拟化软件平台Hypervisor来说，这个VF同一块普通的PCIe网卡一模一样，安装相应驱动后就能够直接使用。假设一台服务器上安装了一个单端口SR-IOV网卡，这个端口生成了4个VF，则Hypervisor就得到了四个以太网连接。
SR-IOV的实现依赖硬件和软件两部分，首先，SR-IOV需要专门的网卡芯片和BIOS版本，其次上层Hypervisor还需要安装相应的驱动。这是因为，只有通过PF才能够直接管理网卡的I/O资源和生成VF，而Hypervisor要具备区PF和VF的能力，从而正确地对网卡进行配置。
在SR-IOV的基础上，通过进一步利用Intel VT-d或AMD IOMMU（Input/output memory management unit），直接在VM和VF之间做一对一的映射，在这个过程中，Hypervisor的软件交换机被完全Bypass掉了，同传统的VM DirectPath相比，这种方式即实现了VM对VF硬件资源的直接访问，又无需随着VM数量的增加而增加物理网卡的数量。
在业界厂家的大力推广下，SR-IOV已经成为虚拟化数据中心一个非常重要的演进方案，支持SR-IOV的网卡开始大量出现，其中不得不谈谈的就是Cisco名声大噪的Palo卡。
Cisco Palo
Cisco这块红得发紫的网卡大名M81KR，昵称Palo。
Palo是一块SR-IOV网卡，但它又不是一块标准的SR-IOV网卡（×_×！），这句话翻译成人类的语言就是，Palo能够兼容SR-IOV的所有行为，但无需Hypervisor对SR-IOV的支持。
之所以Cisco要玩得这么特立独行，是因为PCI-SIG自推出SR-IOV后，其市场推广并不是太给力，前面说过，要实现多个虚拟通道需要在Hypervisor上安装对应的驱动，但目前为止只有XEN和KVM等开源系统比较积极地提供了对SR-IOV的支持，VMWare vsphere和Microsoft Hyper-v这类主流平台迟迟不见动静。
数据中心市场经过一轮大浪淘沙，已经逐渐明确了未来的发展方向，谁越早拿出一个切实可行的解决方案，客户就会跟谁走。Cisco在数据中心市场提前数年布局，投入不可谓不重，目前看来，思科是是唯一在各个方面有充足储备的厂家，其他人的下一代数据中心网络产品线还很模糊。尽管Nexus平台优势明显，但后面的追兵一刻也没松懈，大家都在争分夺秒地划分地盘，HP已经在给802.1qbg拼命造势，如果这个节骨眼上，客户因为SR-IOV的不成熟限制了虚拟化的部署，拖累了整个市场向虚拟化的转型，相当给了其他厂家喘息的机会，这是Cisco最不希望看到的局面。
因此，思科在Palo上又一次采取了以往屡试不爽的策略，一方面提供对公开标准的支持，一方面抢先推出自己的实现版本，以促进市场尽快成熟。同SR-IOV类似，Palo最大能够实现128个以太或存储通道，但Hypervisor无需支持SR-IOV，思科会单独推出Palo在各个平台上的驱动。能做到这点，一方面是因为思科自身迫切的需求，另一方面，其网络大佬的影响力，也推动了软件厂家的合作。
Palo作为市面上第一块真正意义上的虚拟化网卡，同时实现了基于VN-Tag/802.1qbh的虚拟接入和类似SR-IOV的虚拟通道功能，第一次将网络接入延伸到VM层面。在部署了Palo卡的刀片服务器上，VMWare vsphere上VM的流量被直接发送到一个独立的PCIe通道，这些数据在此随即被打上VN-Tag标记，然后送往上联交换机。在这个环境中，上联交换机、服务器网卡、甚至刀片机框IO模块不再是分裂的对象，而是合并为一个逻辑上统一的接入交换机，这个接入交换机能够直接看到VM的端口，对单个VM的数据流量进行安全隔离，对以太和FCoE流量实施QoS策略，而Hypervisor无需再维护一个软件交换机，原来被软件交换机占用的CPU资源能够用来运行更多的虚拟交换机。
虚拟接入和虚拟通道相辅相成，在Cisco Palo上第一次实现了同物理机类似的虚拟机接入。
后面的故事
近年来，数据中心的发展如火如荼，VN-Tag、FCoE等新技术层出不穷，新一代数据中心架构逐渐成形，虚拟化网卡是这个拼图的最后一块。Cisco Palo作为这个领域的第一个尝试，拉开了服务器网卡的升级序幕，网卡厂家将开始新一轮的技术竞争，MR-IOV、Hypervisor Bypass情况下的虚拟机动态漂移等领域将成为下一代技术热点。而随着虚拟化网卡的不断完善，数据中心的转型将开上一条真正的快车道。
五分钟Q&A
1）什么是虚拟化网卡？
虚拟化网卡要能够对不同的虚拟机提供独立接入，区分不同虚拟机的流量，以提供相应的安全和QoS策略。在实现方式上，虚拟网卡要支持”虚拟接入”和“虚拟通道”技术。
2）什么是“虚拟接入”？
“虚拟接入”技术利用标签，在全网范围内区分出不同的虚拟机流量。
3）什么是“虚拟通道”？
“虚拟通道”在物理网卡上对上层软件系统虚拟出多个物理通道，每个通道具备独立的I/O功能。
4）什么是SR-IOV？
SR-IOV是PCI-SIG推出的一项标准，是“虚拟通道”的一个技术实现，用于将一个PCIe设备虚拟成多个PCIe设备，每个虚拟PCIe设备如同物理物理PCIe设备一样向上层软件提供服务。
5）SR-IOV在网络虚拟化方面有和用处？
SR-IOV网卡能对上层操作系统虚拟出多个PCIe网卡，每个网卡可以实现独立的I/O功能。独立的通道能够实现更强的安全隔离、更完善的QoS和更高的传输效率。SR-IOV目前支持在一块PCIe网卡上虚拟出256个通道，是实现虚拟化网卡的基础之一。
6）部署SR-IOV需要什么条件？
部署SR-IOV需要支持SR-IOV的硬件网卡，和支持SR-IOV的软件操作系统。
7）SR-IOV同Hypervisor Bypass是一个玩意吗？
不是。
尽管SR-IOV常常同Intel VT-d等Hypervisor bypass技术配合使用，但两者各自独立，SR-IOV的功能是虚拟出多个PCIe设备，Hypervisor Bypass实现的是虚拟机对底层硬件的直接访问。
8）什么是Cisco Palo？
Palo是Cisco推出的兼容SR-IOV的虚拟化网卡，能对上层虚拟出128个以太或存储通道，并且支持VN-TAG/802.1qbh虚拟接入技术。
10）SR-IOV是实现虚拟网卡的唯一方式吗？
No
市场还有很多公司提供类似的I/O虚拟化解决方案，如Xsigo等。
本文由自动聚合程序取自网络，内容和观点不代表数字时代立场
