虛擬化中的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，固然我想本身恐怕是找不到支持的硬件了:(，等之後有機會再說吧。