当然，虚拟化技术以及云计算平台已经发展的越来越快，相关的硬件加速技术也是有很多种选择，并且在不同的场合需要用户选取适合自己的解决方案，而不是盲目跟风，究竟哪些功能有用，哪些功能之间又互相冲突，都需要仔细的去评估，今天就想聊一聊有关虚拟化环境中的另外两个硬件辅助功能，RSS（接收端扩展）与VMQ（虚拟机队列）。
######################################################################
首先在开始之前先说明一下我的演示环境：
操作系统：Windows Server 2012 R2
物理机：HP DL160 G6
网卡：Intel千兆（支持RSS及VMQ）
这里十分遗憾的是我的网卡是1Gi速率的而不是10Gi的，没办法屌丝只能这样了，因此无法完全说明开启VMQ之后的效果（具体缘由在文章后面会提到）
######################################################################
好的，现在开始进入正题，为什么要把RSS和VMQ拿到一起来说呢，因为这两个功能的初衷是比较类似的，先说RSS，它通常是在纯物理环境下启用的，RSS所实现的效果非常简单明了，如下图：
在物理NIC不支持RSS功能的时候，网络流量的负载是通过一颗逻辑CPU来处理的，是的你没有看错，即便你的CPU能力很屌，多路N线程也只会调用一颗LP（logical processor）来干活儿，那么就会出现一个瓶颈问题，而RSS正是通过调用全部LP来处理网络负载来解决了这一性能问题。好就好在什么呢？如果是1Gi速率的话，目前这个年代单颗LP处理起来还是富富有余的，但众所周知，以太网发展十分迅速，10Gi速率的出现彻底打破了这一局面，当下OS（以Windows为例）调用单颗LP只能run到3.5~4.5Gi的能力，是的没错，也就意味着在万兆环境下，若没有RSS或VMQ的辅助，那么必将损失掉很多性能。
#####################################################################
在我的DL160上，首先来看一下当前网卡的工作模式，RSS属性默认都是开启的（这已经是服务器级别最基本的一个功能了），为了对比效果我先禁用它，如下图：
之后要确认一下我的环境尚未开启hypervisor，也就是以Windows平台为例，我没有开启Hyper-V功能（虚拟化层），为什么要确认这一步呢，因为RSS在虚拟化环境中将不起作用，尽管它可能处于启用状态，但始终是无效的，为什么一会儿再说。
接下来我通过网络共享做一个拷贝的动作，眼尖的童鞋可能会发现我的速率是百兆的。。。是的你没看错。。。:(
此时在DL160这台服务器上，大部分负载都是通过LP0来run的，通过性能计数器可以看的更明显，如下图：
我重新启用RSS功能做一个对比
仍然是刚才的拷贝，此时服务器已经在调用所有CPU来处理了，我的这个截图可能看上去不是特别的明显，因为理论上来讲，RSS功能在千兆网卡上可能也不会起作用，正如上面所讲的，单颗LP足以应付1Gi速率的负载。
####################################################################
那么在了解了RSS功能之后，再来看看VMQ，虚拟机队列顾名思义是适用于虚拟化环境下的，那为什么不能直接用RSS呢？看下图：
以Windows平台为例，在启用了hypervisor之后，整个基础架构发生了很大变化，首先是产生父子区域，即主机OS与Guest OS，其次就是最要命的——“虚拟交换机”，virtual switch通过路由、过滤、扩展、访问控制列表、转发、VM Bus等堆栈组合而成，首先从系统层面的视角来看，主机host与VM之间的流量是平起平坐的，那么此时从外面进来的流量通过物理NIC之后需要分发到不同的目的地，例如主机OS或者转发到某一台VM上，也就是说不存在针对物理机来调用所有LP了，那么RSS功能就失效了，你就算开着它也没用。
因此回到本篇的议题，为什么要把RSS与VMQ拿到一起说，因为VMQ正是为了解决在虚拟化环境中出现的性能瓶颈问题而诞生的，如上图所示，首先物理NIC需要硬件支持VMQ功能，然后不同厂商的不同型号，一个NIC口可以支持若干个队列，每一个队列将会关联到一颗LP上，然后这条路径将会对应到唯一的目的地，即主机OS或者某一台VM。
这样一来首先入方向流量的转发和路由功能将会在NIC上完成，不需要在虚拟交换机上做过多的停留，此外每条路径在万兆（10Gi）条件下可以发挥最高将近5Gi的能力，而不是所有资源共享一条5Gi左右链路（若不启用VMQ功能整个主机只由一颗LP负载所有VM和父OS流量）。
#####################################################################
那么可能有的童鞋会想说，虽然我有了VMQ可以解决一部分性能问题了，但是我的VM可能有很多颗VP（virtual processor），如何发挥最大性能呢？很可喜的是，在Windows Server 2012 R2中，Hyper-V已经支持一项叫做vRSS的功能了，顾名思义，现在在虚机中我们也可以实现RSS的效果了。
想要实现vRSS的前提是，物理NIC要支持VMQ功能，并且在Hyper-V的设置用，确保虚拟机的vNIC启用了“虚拟机队列”功能。如下图：
接下来看一下对比，实际想过和物理机测试RSS的差不多的，在Guest OS中查看虚拟机的vNIC属性，当前vNIC的RSS功能默认是关闭的。如下图：
接下来查看一下宿主机上物理NIC的VMQ属性，以我的环境为例，我把“以太网”和“以太网2”做了Teaming，因此只需要关注两块NIC是否启用了VMQ即可。如下图：
在这里要说明一下，通过PowerShell返回的结果来看，我的网卡VMQ属性有几列字段需要重点关注一下：
首先“basevmqprocessor 0:0”是指当前“以太网”这块NIC会从“CPU组0”当中的“LP0”开始分配队列，这个组一般来讲会容纳64个LP，物理机超过64个LP就会分配到下一个组。
其次“maxprocessors 8”是指当前该NIC会调用最多8个LP，那么从上一条basevmqprocessor 0:0来推算，这个队列会调用到LP7,（从LP0~LP7总共8颗LP）。
最后“numberofreceivequeue 7”就是说最多支持7个队列，因此可以看出，并不是说NIC能调用8个LP就一位着它能处理8个队列。
接下来在没有启用虚拟机RSS功能（也就是vRSS）的前提下进行一个拷贝动作，可以再Guest OS看到当前只调用了VP0。如下图：
通过物理机的性能计数器来观测VP使用情况会更明显，如下图：
接下来启用虚拟机的RSS功能，即vRSS，如下图：
继续进行一个拷贝工作，观察Guest OS内CPU使用情况，如下图：
同样在物理机上通过性能计数器观察VP使用率，如下图：
若在万兆条件下测试效果会更直观
######################################################################
上面主要看了一下RSS与vRSS的一些演示，特别是vRSS也是要基于VMQ功能才可以启用的，那么下面就看一看VMQ的效果。
在此之前还是想多说一说有关VMQ的概念性问题，因为在我看来，实际体验一项功能之前，十分有必要去了解它的运行机制和工作原理以及关键的要点。
在Windows Server 2012中，VMQ变得更加智能化，微软称之为动态VMQ，也就是如下图所示：
原来LP1与LP2是分别处理VM1与VM2负载的。
当网络负载变小的时候，VMQ会合并队列，将VM1与VM2的负载整合到LP1上去run。
####################################################################
上面提到的是动态VMQ，而当用户想将VMQ与SRIOV复用时，就需要注意了——鱼与熊掌不可兼得，为什么呢？看下图：
之前的博文提到过（点击开头传送门），SRIOV通过物理NIC实现VF功能，使得网络流量越过虚拟化堆栈，也就是跳过了虚拟交换机这一环，特别是extension这一项，那么VMQ的存在就没有意义，因此SRIOV与VMQ只能二选其一，这个要视用户的场景来取舍了。
####################################################################
还有一种场景需要特别提及一下，就是VMQ与NIC Teaming配合使用时，需要注意以下问题：
NIC Teaming有多重模式和算法，当使用交换机依赖模式时（switch dependent），无论负载平衡算法是地址哈希（address hash）、动态（dynamic）还是Hyper端口（Hyper-V port），那么此时VMQ都将处于一种叫做“min queues”的模式下，如下图：
这种模式的特点是什么呢，因为入方向流量不固定，也就是这次可能走NIC1进来，下次可能就从NIC2进来了，那么VMQ的队列数就无法最大化利用，因为需要确保针对VM1的队列，在NIC1和NIC2上都要一致，比如在两块NIC上都需要复用同一颗LP，简单的理解就相当于一个mirror模式。
2. 当使用非交换机依赖模式时（switch independ），只有当算法选用地址哈希（address hash）时会处于“min queues”，其它两种算法都会变更为“sum of queues”模式，如下图：
这种模式下就不会出现mirror的效果，NIC队列数量将会最大化的被利用，因为此时入方向流量是固定的，只会出现在一块NIC上。
那么根据上面的说明，就可以看出，在NIC Teaming模式下启用VMQ，不同的算法会导致不同的性能结果，那么就需要针对VMQ多做一些额外配置，此外还需特别注意：
VMQ针对于主机host或某一台虚机，有且只能有一颗LP来承载，不可能超过一颗。
在开启了超线程后，VMQ只在偶数节点上起作用，因此通常建议用户把“HT”（hyper-threading）功能关掉。
接下来看个示例，假设我的物理服务器有8核（即8LP），两块NIC组成Teaming模式，在min queues与sum of queues两种模式下配置会有所区别：
min queues
“Set-NetAdapterVMQ –Name NIC1, NIC2 –BaseProcessorNumber 0 –MaxProcessors 8”（两块NIC都需要调用LP0~LP8，它们是复用的）
sum of queues
“Set-NetAdapterVMQ –Name NIC1 –BaseProcessorNumber 0 –MaxProcessors 4”（NIC1将调用LP0~LP3）
“Set-NetAdapterVMQ –Name NIC2 –BaseProcessorNumber 4 –MaxProcessors 4”（NIC2将调用LP4~LP7）
这里希望不要把大家绕晕，其实有兴趣的童鞋可以自己用PowerShell看一看VMQ的相关command以及一些重要属性，下面几个图示比较清晰的阐述了这些参数之间的关系：
以6颗LP的主机为例（LP0~LP5，抱歉水印挡住了视线），它们的关系是这样的：
baseprocessornumber：0
maxprocessornumber：5
maxprocessor：6
2. 当“可被调用的最大LP号”发生变化时，只有LP0~LP3可以被使用，即使“最大处理器数量”仍然是6，但是优先级也要服从于“maxprocessornumber”。
baseprocessornumber：0
maxprocessornumber：3
maxprocessor：6
3. 当“最大处理器数”发生变化时，虽然“maxprocessornumber”是5，但是此时“maxprocessor”值的优先级更高
baseprocessornumber：0
maxprocessornumber：5
maxprocessor：3
#####################################################################
下面来看一下测试环境中VMQ的实际效果，因为我的屌丝环境没有10Gi网卡，只能拿1Gi的凑合了，然而操作系统默认是不会启用千兆环境下的VMQ功能的，所以我要先修改一***册表，在“HKLM\system\currentcontrolset\services\VMSMP\parameter”下添加一行dword值“BelowTenGigVmqEnable”并赋值为“1”，然后重启物理机就可以了，如下图：
接下来通过PowerShell查看当前物理NIC的VMQ属性，以我的环境为例，以太网和以太网2都是启用的，并且因为我的Teaming模式是switch independent以及dynamic算法，所以当前处于“sum of queues”模式，因此根据物理机条件（8核）进行配置，将以太网绑定到LP0~LP3上，以太网2绑定到LP4~LP7上，每个NIC各4条通道，之后再通过PowerShell查看VMQ队列分配情况，如下图：
以太网和以太网2都有一条队列ID为0的数据，它们是分配给默认队列的，所谓默认队列就是既不属于某台VM也不属于主机host的流量将被转发到默认队列中进行处理。
在以太网中，队列ID为1的条目已经被分配给了MAC地址为“00-26-55-86-10-08”的主机host。
在以太网2中，队列ID为1的条目已经被分配给了MAC地址为“00-15-5D-0A-4F-00”的虚拟机demoDC。
而下面这张图显示了，当前是由LP4来处理demoDC这台虚机的流量负载的。如下图：
通过主机的性能计数器可以清楚的看到，目前demoDC正在通过网络拷贝文件，负载都在LP4上
####################################################################
RSS与VMQ这两项硬件加速技术对于云计算平台的性能改进是巨大的，特别是在万兆网络条件下，用户肯定是希望能够资源利用最大化的，此外除了网络，在存储方面也有一些辅助功能，例如ODX，当然我想自己恐怕是找不到支持的硬件了:(，等以后有机会再说吧。
本文转自maomaostyle 51CTO博客，原文链接：http://blog.51cto.com/maomaostyle/1547616，如需转载请自行联系原作者
