Hyper-V和NUMA架構(gòu)那點事兒
最近連續(xù)做了幾個微軟虛擬化解決方案的售前演示，其實對于大部分客戶來講不會對一整套“相對完善”的方案在***時間就看的很深入，反而通常會更在意一些最基礎(chǔ)的功能和配置選項，特別是技術(shù)崗位的人往往都會有“先入為主”的情緒，這很正常，假設(shè)客戶使用了N多年的VMware或者他是思杰鐵粉兒，那么你懷揣著一套microsoft環(huán)境去給人家講的時候，可能對方會先問一些hyper-v管理器的功能，甚至?xí)柕暮芗?xì)，不要小看這些看似“不起眼”的功能選項，恰恰會成為不同廠商之間競爭的有力砝碼或成為整套方案基礎(chǔ)架構(gòu)的核心支柱
#################################################################################
這篇文章主要以Hyper-V當(dāng)中的NUMA功能來做一些說明，我本人也是這兩天花時間查閱了一些資料，希望能給有需要的朋友提供一些幫助
【非統(tǒng)一內(nèi)存訪問（NUMA）是一種用于多處理器的電腦記憶體設(shè)計，內(nèi)存訪問時間取決于處理器的內(nèi)存位置。 在NUMA下，處理器訪問它自己的本地存儲器的速度比非本地存儲器（存儲器的地方到另一個處理器之間共享的處理器或存儲器）快一些?！?/span>
以上就是就是NUMA架構(gòu)的大致意思，有關(guān)這項技術(shù)的更多概念，大家可以很輕松的在百度或者維基上查閱到。那么它的優(yōu)點和價值在何處呢？
我們以SQL服務(wù)來舉例說明，在此我會轉(zhuǎn)載一些SQL支持組官方博客的文章http://blogs.msdn.com/b/apgcdsd/archive/2011/11/16/sql-server-numa.aspx
下圖就描述了一個比較形象的NUMA架構(gòu)：
我們有兩個NUMA結(jié)點。每個NUMA結(jié)點有一些CPU, 一個內(nèi)部總線，和自己的內(nèi)存，甚至可以有自己的IO。每個CPU有離自己最近的內(nèi)存可以直接訪問。所以，使用NUMA架構(gòu)，系統(tǒng)的性能會更快。在NUMA結(jié)構(gòu)下，我們可以比較方便的增加CPU的數(shù)目。而在非NUMA架構(gòu)下，增加CPU會導(dǎo)致系統(tǒng)總線負(fù)載很重，性能提升不明顯。
每個CPU也可以訪問另外NUMA結(jié)點上的內(nèi)存，但是這樣的訪問，速度會比較慢。我們要盡量避免。應(yīng)用軟件如果沒有意識到這種結(jié)構(gòu)，在NUMA機器上，有時候性能會更差，這是因為，他們經(jīng)常會不自覺的去訪問遠(yuǎn)端內(nèi)存導(dǎo)致性能下降。
####################################################################################
對NUMA架構(gòu)有了大致了解后，我們來說一說Hyper-V中的虛擬NUMA節(jié)點配置，下圖是我個人電腦上的CPU屬性，很難過的是——它不支持硬件NUMA架構(gòu)；但是對于某些服務(wù)，我們可以實現(xiàn)軟件模擬多NUMA節(jié)點，比如SQL可以通過修改注冊表來實現(xiàn)，大家可以在本文上部的鏈接中查閱
同樣在性能監(jiān)視器中（perfmon.exe），我們可以添加本機的“hyper-v VM vid NUMA node”來查看當(dāng)前hyper-v使用的節(jié)點數(shù)量，下圖還是我的個人電腦，只顯示了一個node0，并且頁面數(shù)量1025851000；用頁面數(shù)量*頁面大?。?k）=4GB，這個就是我這臺電腦的實際物理內(nèi)存
####################################################################################
接下來咱們換一臺服務(wù)器看看，CPU是兩顆，雙核，支持超線程；那么2*2*2=8，你會看到8個邏輯CPU
同樣我們可以看到這臺設(shè)備支持硬件NUMA；并且是兩個節(jié)點；這樣我們就能自己算一下,32G內(nèi)存+8個邏輯CPU，分成兩份兒，那么一個節(jié)點就是16G內(nèi)存+4邏輯CPU
同樣我們在性能監(jiān)視器中可以看到兩個節(jié)點；即node0與node1，并且下面對應(yīng)的頁面數(shù)量和處理器數(shù)量分別是16GB和4顆LCPU
接下來我們找一臺虛擬機，在設(shè)置中找到“處理器”下面的“NUMA”；我們可以看到有一個硬件拓?fù)?，如果選擇了“硬件拓?fù)?rdquo;，則系統(tǒng)會把這臺服務(wù)器的NUMA架構(gòu)直接映射過來，以這臺服務(wù)器為例，也就是“每節(jié)點16G+4LCPU”；但是如果你的這臺虛擬機上確實要跑一些高性能的并行運算且需要NUMA架構(gòu)支持，那么簡單的映射物理服務(wù)器配置可能不是***選擇；
以下圖為例：這臺虛機中有一個SQL實例，虛機配置是4G+4vCPU；我將它配置成了2個虛擬NUMA節(jié)點，那么每節(jié)點就是2vCPU+2G內(nèi)存；且每個CPU插槽默認(rèn)最多支持1個節(jié)點，于是我這臺VM就有兩個socket（插槽）；如果你把這臺虛機看成物理機的話，那么它就是一臺擁有“兩顆物理CPU，每顆CPU雙核或單核雙線程，4G內(nèi)存”的機器
這樣一來，我們這臺虛機就是一臺支持NUMA架構(gòu)的機器了，如果結(jié)合本文開篇提到的SQL NUMA環(huán)境；那么我們就能更加靈活的來對數(shù)據(jù)庫服務(wù)進行調(diào)優(yōu)
我們啟動這臺虛機，進入系統(tǒng)之后查看windows應(yīng)用程序日志，找到對應(yīng)的SQL 17152日志，可以看到有兩條，分別顯示了兩個節(jié)點的配置狀態(tài)，node0與node1；這就說明這臺虛機已經(jīng)按照之前的規(guī)劃成功的實現(xiàn)了NUMA架構(gòu)的模擬
同樣在SQL服務(wù)器屬性中，可以在“處理器”選項中看到當(dāng)前識別到的NUMA節(jié)點；你可以讓SQL自動的關(guān)聯(lián)，或者手動關(guān)聯(lián)
對比一下我本機的SQL配置，只有一個節(jié)點
######################################################################################
講到這里，我再轉(zhuǎn)載一下SQL開發(fā)小組的文章：
SQL Server 不僅僅在引擎上支持NUMA, 而且在連接層面上也支持NUMA。如果沒有在連接層面上對NUMA進行設(shè)置的話，那么每一個連接進來，SQL Server會根據(jù)round-robin方式，選擇NODE 進行處理。在NODE內(nèi)部，SQL Server會選擇CPU負(fù)載***的一個CPU進行處理。這種方法的缺點是，有可能某一個NODE內(nèi)的所有CPU都很忙，但是另外一個NODE內(nèi)的所有CPU都很空。導(dǎo)致資源不均衡。這種情況下，使用NUMA架構(gòu)性能反而會下降，還不如使用非NUMA架構(gòu)。系統(tǒng)能均衡分配CPU資源。
如下圖所示，我們用round-robin方式，可能NUMA NODE0會非常繁忙，而NUMA NODE1會非?？臻e，系統(tǒng)資源不能充分利用。重要的連接可能會被分配到NODE0, 導(dǎo)致不能得到及時處理，性能受到影響
為此，在連接上，我們可以做設(shè)置。對于重要的操作，我們使用端口1450, 該端口會綁定NUMA結(jié)點0, 1, 2, 而對于不重要的操作（可能需要耗費大量資源，但不重要的），我們使用端口1433, 該端口會綁定NUMA結(jié)點3, 這樣，不重要的操作不會對重要的操作在性能上有所影響
如何設(shè)置端口對NUMA結(jié)點的綁定呢？我們可以在偵聽的端口后面加NUMA結(jié)點信息；還是拿剛才演示的那臺虛機來說；有2個NUMA結(jié)點，如果要使用NUMA結(jié)點0 那么根據(jù)轉(zhuǎn)換二進制的方式，相應(yīng)的數(shù)值是1；這個就跟我們計算子網(wǎng)掩碼時候一樣，在對應(yīng)的節(jié)點數(shù)下面寫1，然后轉(zhuǎn)換成二進制就好
|
NUMA NODE NUMBER |
1，0 |
|
Mask for 1 |
0，1 |
然后把算好的值加在你要監(jiān)聽的端口后面就行了，比如我要某一項服務(wù)在0,1節(jié)點上都跑，那么在1433端口后面加個[3]就行了
#######################################################################################
接下來我們在回到Hyper-V的話題上，宿主機支持NUMA架構(gòu)的話，那么系統(tǒng)會自動把虛機分配到某一個節(jié)點上跑，我們還是拿剛才這臺SQL服務(wù)器來說明；先安裝一個winrar，然后運行自帶的性能測試來給CPU加壓
可以看到虛機的CPU使用率負(fù)載馬上出現(xiàn)了變化
這個時候再來看一下宿主機，在性能監(jiān)視器中添加“hyper-v VM vid partition”，可以看到當(dāng)前這臺“10.12_TFS_DB”的虛機跑在了節(jié)點1下（參考preferred NUMA node index=1），并且邏輯CPU使用率只占用了4個
######################################################################################
那么這里就會出現(xiàn)一個問題，一個NUMA節(jié)點的資源畢竟是有限的，這種架構(gòu)說白了就是給物理資源進行了一個分組；把若干個邏輯CPU和若干大小的內(nèi)存進行了綁定，以此來提高CPU對內(nèi)存訪問的命中率，有效減少了前端總線的瓶頸；但若此時多臺虛機被分配到了同一節(jié)點時，可偏偏這個節(jié)點的資源又被吃滿了怎么辦？
其實這種場景下CPU通常不會是瓶頸，出問題的往往又是內(nèi)存；于是乎總有一臺突破臨界點的虛機要去跨節(jié)點訪問內(nèi)存了；這時候問題就來了，NUMA架構(gòu)就是為了劃分節(jié)點邊界，使數(shù)據(jù)交互盡量保持在各自節(jié)點內(nèi)進行，結(jié)果這么一跨訪問；又會出現(xiàn)性能下降的問題了，而且不光本節(jié)點的這臺虛機受影響，還會侵占被訪問節(jié)點的資源；那么有沒有什么辦法來人為控制一下呢？肯定是有的，先來看一下跨節(jié)點訪問時的效果吧
我們同時開啟多臺虛機，盡可能分配一些大內(nèi)存；如下圖所示
這時有意思的事情出現(xiàn)了，我們?nèi)_虛機DC、DB還有WEB都跑在了節(jié)點1上面，但是呢DC這臺機器的“remote physical pages”出現(xiàn)了數(shù)值，這就是遠(yuǎn)程訪問其他節(jié)點的內(nèi)存；我們這臺宿主機就倆節(jié)點，所以它一定是用到了節(jié)點0的資源；并且你可以通過頁面大小來計算出它吃了多少非本地內(nèi)存
####################################################################################
為了盡可能避免上述情況的發(fā)生，特別是面對一些對性能指標(biāo)很敏感的需求時，我們就要手動的來限制一下；下面這個腳本是從msdn博客上挖來的，可以指定某臺虛機與某個numa節(jié)點來做綁定，鏈接如下：
直接執(zhí)行腳本會出現(xiàn)提示，支持三個參數(shù)：/list列出當(dāng)且宿主機上的虛機名稱；/set來做綁定；/clear來解除綁定
下面針對DC這臺虛機來做一個綁定，讓它去節(jié)點0上面跑，而不要跨節(jié)點的占用資源（關(guān)閉虛機后運行/set參數(shù)）
再回到性能監(jiān)視器，可以看到此時“10.11_DC”這臺虛機已經(jīng)轉(zhuǎn)移到了節(jié)點0上面了
再回到宿主機上觀察CPU使用率，可以看到目前所有邏輯處理器基本都以被占用了（說明節(jié)點0正在專注的為DC虛機提供服務(wù)）
######################################################################################
有關(guān)hyper-v上面的虛擬NUMA節(jié)點先說這么多，在一些有針對性的需求時，還是很有意義的；這篇文章我也是參考了許多中英博文總結(jié)出來的，個人感覺很有意義并且認(rèn)為很有必要分享出來，感興趣的朋友們可以抽空測一測，歡迎隨時與我交流，謝謝!
