在之前的博文中(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属性有几列字段需要重点关注一下:
首先“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 �CName NIC1, NIC2 �CBaseProcessorNumber 0 �CMaxProcessors 8”(两块NIC都需要调用LP0~LP8,它们是复用的)
sum of queues
“Set-NetAdapterVMQ �CName NIC1 �CBaseProcessorNumber 0 �CMaxProcessors 4”(NIC1将调用LP0~LP3)
“Set-NetAdapterVMQ �CName NIC2 �CBaseProcessorNumber 4 �CMaxProcessors 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,当然我想自己恐怕是找不到支持的硬件了:(,等以后有机会再说吧。