虚拟化中的RSS与VMQ

在以前的博文中（http://maomaostyle.blog.51cto.com/2220531/1439651）聊过虚拟化中的SRIOV技术，即单根虚拟化，在启用了SRIOV以后，虚拟机经过硬件实现VF（Virtual Function）能力，使得性能近乎于物理机效果。

 

固然，虚拟化技术以及云计算平台已经发展的愈来愈快，相关的硬件加速技术也是有不少种选择，而且在不一样的场合须要用户选取适合本身的解决方案，而不是盲目跟风，究竟哪些功能有用，哪些功能之间又互相冲突，都须要仔细的去评估，今天就想聊一聊有关虚拟化环境中的另外两个硬件辅助功能，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属性有几列字段须要重点关注一下：

1. 首先“basevmqprocessor 0:0”是指当前“以太网”这块NIC会从“CPU组0”当中的“LP0”开始分配队列，这个组通常来说会容纳64个LP，物理机超过64个LP就会分配到下一个组。

2. 其次“maxprocessors 8”是指当前该NIC会调用最多8个LP，那么从上一条basevmqprocessor 0:0来推算，这个队列会调用到LP7,（从LP0~LP7总共8颗LP）。

3. 最后“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配合使用时，须要注意如下问题：

1. 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多作一些额外配置，此外还需特别注意：

1. VMQ针对于主机host或某一台虚机，有且只能有一颗LP来承载，不可能超过一颗。

2. 在开启了超线程后，VMQ只在偶数节点上起做用，所以一般建议用户把“HT”（hyper-threading）功能关掉。

接下来看个示例，假设个人物理服务器有8核（即8LP），两块NIC组成Teaming模式，在min queues与sum of queues两种模式下配置会有所区别：

1. min queues

   “Set-NetAdapterVMQ –Name NIC1, NIC2 –BaseProcessorNumber 0 –MaxProcessors 8”（两块NIC都须要调用LP0~LP8，它们是复用的）

2. 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以及一些重要属性，下面几个图示比较清晰的阐述了这些参数之间的关系：

1. 以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队列分配状况，以下图：

1. 以太网和以太网2都有一条队列ID为0的数据，它们是分配给默认队列的，所谓默认队列就是既不属于某台VM也不属于主机host的流量将被转发到默认队列中进行处理。

2. 在以太网中，队列ID为1的条目已经被分配给了MAC地址为“00-26-55-86-10-08”的主机host。

3. 在以太网2中，队列ID为1的条目已经被分配给了MAC地址为“00-15-5D-0A-4F-00”的虚拟机demoDC。

而下面这张图显示了，当前是由LP4来处理demoDC这台虚机的流量负载的。以下图：

经过主机的性能计数器能够清楚的看到，目前demoDC正在经过网络拷贝文件，负载都在LP4上

####################################################################

RSS与VMQ这两项硬件加速技术对于云计算平台的性能改进是巨大的，特别是在万兆网络条件下，用户确定是但愿可以资源利用最大化的，此外除了网络，在存储方面也有一些辅助功能，例如ODX，固然我想本身恐怕是找不到支持的硬件了:(，等之后有机会再说吧。