VMware vSphere资源分配管理观念入门

善用虛擬化特性

VMware vSphere資源分配管理觀念入門

在虛擬化的世界裡，資源的分配與管理是很重要的課題，但也最容易被忽略或誤解。在此要介紹的是一些有關VMware vSphere 虛擬化資源的重要觀念，主要內容為Virtual CPU、Memory的運作概念，以及VM的資源設定配置基礎，還有了解何謂資源池（Resource Pool）。

本篇文章重點不在VMware vSphere資源分配管理的操作與設定，而是著重於虛擬化資源分配的初步理解。首先，就從Virtual CPU 的運作概念開始說起。

Virtual CPU的運作概念

要了解Virtual CPU的運作概念，可從實體運算資源如何分配與對應、Logical CPU、Hyper Threading、Multicore Virtual CPUs 來加以說明。

實體運算資源如何分配與對應

在以往傳統的運作模式，一部實體伺服器可能配備有一顆或多顆實體的處理器（Physical CPU），但是卻只有一個作業系統在使用這些CPU。

作業系統並非時常要使用這些CPU的運算能力，可能只有某段時間才需要運算能力，過了一陣子又不需要。

這種情形往往造成CPU大部分的時間都處於閒置的狀態，整體時間拉長來看，處理器的使用效率非常的低落。

有沒有想過，一個資料中心有著數百數千部伺服器散落於各個角落，平時這些伺服器所要利用到的CPU資源，可能都只是一整天當中的某一小段時間，其他時候，這些已開機卻閒置的CPU資源，形成了多大的浪費呢？

正因運算資源閒置的時間太長、太零散，所以如果有一種方法可以統籌這些運算資源，透過疏導與分配的方式，讓很多的OS排隊來利用這些閒置的資源，當有需要時，就來請求使用，不需要時，就不要霸佔著位置不放。虛擬化就是一帖良方，可以有效拉高運算資源的使用率。

首先，要探討的是Virtual CPU（vCPU）的概念。以一個VM來說，當你給了它兩顆vCPU的時候，並不是代表這個VM真的擁有兩個實體CPU的運算能力。

因為它的CPU是虛擬出來的，每個VM上的Guest OS所看到的CPU，其實都不是真的，沒有實際的運算能力。那麼，要如何讓這個VM真正擁有運算能力呢？

當虛擬的CPU能夠「對應」到一個實體運算單位（Logical CPU，或稱為Hardware Execution Context、HEC）的時候，它就真正取得了實體的運算能力。

我們知道一個實體CPU在同一時間，是不可能幫多個OS作運算的，在一個CPU Cycle單位時間內，一次只能處理一個執行緒，沒辦法被切成兩半，分割資源給VM_A，同時又切割給VM_B來使用。

所以，假設要讓一個4GHz的實體CPU分給兩個VM同時來使用，希望VM_A拿到3GHz運算資源，另一個VM拿到1GHz運算資源，那Hypervisor該怎麼做呢？答案就是剛剛所說的，利用虛擬「對應」實體的方式來達成目的。

Hypervisor採用CPU Mapping的方式分配運算資源，實體CPU先四分之三的時間對應給VM_A，然後再將四分之一的時間對應給VM_B，實體CPU（或核心）一次只服務一個VM，並且這段時間是全速來幫它做運算。

靠著時間分配快速切換於不同的VM之間，這樣子等於VM_A掌握了75%的運算資源，而VM_B則拿到25%，看起來VM_A就像是有3GHz的效能，而VM_B則是1GHz。

Logical CPU

Logical CPU表示一個真實的運算單位（處理器或核心），例如一顆4核心的CPU，表面上看起來是一個處理器，但是因為內含有4個核心（Cores），而這些核心都是具有實體運算效能，所以真正的Logical CPU有4個。

圖1表示了vCPU與LCPU之間的對應關係因為是單顆處理器但是有4個核心，所以一個VM最多可虛擬出4個Virtual CPU（當然也要看OS限制）。

▲圖1 vCPU與LCPU之間的對應關係（1）

若先不考慮多個VM在一個實體機器上互相競爭的問題，假設是單一VM：在圖1的例一中，VM有一個vCPU，對應到一個LCPU

即可運算；例二，VM為雙CPU，頇一次對應2個核心才能做平行運算處理（Virtual SMP）；例三，VM為四CPU，頇一次對應4個核心，才能做平行運算處理（Virtual SMP）。

假設在這個單顆4核心的實體伺服器上，搭載10個VM，每個VM都給予一個vCPU，那麼就會有10個vCPU隨時要對應這4個Logical CPU來取得運算資源。

當這10個VM要使用運算資源時，透過VMkernel CPU Scheduler的分配來mapping目前閒置的Logical CPU，取得實體運算單位的資源，若是此時4個Logical CPU都是忙碌狀態，VM就得排隊，運算資源依照比重來切換給每個VM運作。

vCPU必頇要對應到LCPU，才能真正擁有實體運算能力，而對應事件是無時無刻在發生的，當VM的vCPU對應LCPU1，下一秒它不使用了，資源就釋放出來給別的VM來mapping，隔一分鐘又需要用到，此時VMkernel就會安排另一個空閒的LCPU來服務這個VM。

再看圖2，如果實體機器是2顆雙核心的CPU呢？那就是2個實體CPU乘以雙核心，伺服器一樣有4個Logical CPU可以提供給VM來mapping。

▲圖2 vCPU與LCPU之間的對應關係（2）

Hyper Threading

Hyper Threading（超執行緒）是Intel CPU的一項技術，在一個實體核心整合兩個邏輯處理單元，在某些有支援超執行緒的OS 與程式下運作，可以同時處理兩個執行緒，提升運作效能（但在某些不支援的狀態下，反而會造成效能下降）。

如果在實體伺服器BIOS開啟HT的功能，就會發現LCPU多了一倍出來，例如雙核心的CPU會變成了有4個Logical CPU。VMkernel 會儘量避免讓一個VM的多個vCPU因為開啟HT的關係而對應在同一個核心上，因為這並非是一個真正SMP的狀態。

圖3中的例二與例三，VM多處理器架構的vCPU都是對應於處理器不同的核心，用以取得真正的平行運處理能力。

▲圖3 vCPU與LCPU之間的對應關係（3）

在不得已的情況之下，vCPU才會被對應到同一個實體核心的另一個LCPU，但這個時候的VM因為vCPU都在同一核心運作，所以無法發揮出SMP應有的效能。

另外，如果是ESX host，因為有Service Console的緣故，當它要使用CPU運算資源時，也會mapping到實體的CPU，因為COS 也是一個VM，也需要運算能力。

比較特別的是，當COS需要運算資源的時候，永遠會佔用第一顆實體CPU的第一個Logical CPU，而不會被VMkernel安排到別的地方，這時候若是這個LCPU有被佔用的話，由於COS擁有最高的順位，其他VM就要讓出這個LCPU給它使用，暫時被安排到其他LCPU，或是排隊等候Logical CPU閒置出來。

Multicore Virtual CPUs

各位可能有發現到一些端倪，如果VM的vCPU對應的是Logical CPU，那麼就有可能發生下列的情形：

VM想要使用一個實體的四核心CPU運作，但在Guest OS會被辨識成4個Virtual CPU（Virtual SMP），可能就會造成軟體授權額外收費的問題。假使VM只使用1個vCPU，又會產生實際上只運用到多核心的其中一核的問題。

在vSphere 4.1之後，新增一個Multicore Virtual CPUs功能，可以透過設定讓VM「知道」它實際正使用一個實體的CPU，但上面有四核心，就可以有效運用Virtual SMP，讓Virtual SMP來做平行運算，以增加效能（不過，還是得看應用軟體授權是否合法）。

Memory Virtualization的運作概念

Memory Virtualization的運作概念，可以從Memory over-commit、Transparent Page Sharing（TPS）、Memory Ballooning 三方面來加以說明。

Memory over-commit

有經驗的人可能會發現，在虛擬化的環境下，CPU的運算資源並非是首要最吃緊的，除非一開始規劃配置失當，例如錯估VM型態或實體CPU運算能力，造成瓶頸。否則絕大多數的情況下，CPU運算資源分配應該都游刃有餘。

但記憶體就不是這麼一回事了。由於虛擬化環境要達成伺服器統合的需求，越高比例的VM集中在實體機器上，往往需要的實體記憶體就越大。

但因實體記憶體資源有限，不可能永無止盡地供應給VM，因此可以利用某些方式來活化記憶體資源，有效率、動態地利用它來達成「以更少、做更多」的目標。

接下來為各位介紹的，是在VMware vSphere虛擬化環境裡，記憶體虛擬化的技術。VMware在虛擬化記憶體配置的部分下了很大的功夫，讓大家在伺服器裡有限的實體記憶體，可以發揮出最大的使用價值。這就是所謂的「Memory overcommitment」，讓VM 使用超額的記憶體。

舉個例子，如果你準備將公司機房的老舊伺服器改成虛擬化的方式運作，在評估導入的階段，決定先採購一台全新的實體伺服器，並且將幾個不是擔任重要任務的老舊伺服器，以P2V的方式移轉成VM，如果成效好的話，再逐步地將重要關鍵的伺服器線上P2V轉移過去。

假設這些老舊伺服器當初購買的配置都是2GB的RAM，我們現在打算先移轉5台老舊伺服器變成VM，集中在新採購的伺服器上運作，那麼新伺服器在購買的時候應該配置多少記憶體呢？

既然要將5部老舊主機P2V，而這些老舊主機每部都是配置2GB記憶體，所以採購新伺服器的時候，假設一口氣安裝了10GB的實體記憶體（在此排除TPS、COS、VMkernel memory、VM memory overhead等因素）。

等到你真正地完成5部老舊伺服器的P2V動作，然後從Virtual Hardware、Guest OS的工作管理員資訊中，確定每個VM都分配到2GB的記憶體。5個VM經過幾天測試也都運作得很順暢，甚至效能比以前更好。

整體運作效能提升可以理解，畢竟多年前的老舊伺服器，可能當時需要4顆CPU才跑得順的應用，現在只要一顆CPU就能應付得了。但是你同時也發現了另外一件事，透過vSphere Client顯示ESX/ESXi host的資訊，配備10GB實體記憶體的新伺服器，居然只被用了一半（5GB）左右。

這到底是怎麼一回事呢？明明每個VM的Virtual Hardware配置的都是2GB，在Windows OS看到的可用記憶體也都是2GB，但為什麼5個VM運作時只吃了總共5GB的實體記憶體？

這就是虛擬化的好處。每個VM雖然配置了2GB記憶體，但是它不見得實際需要用到這麼多。由於實體的記憶體是由VMkernel 統籌分配，VM需要用多少才給多少，不需要使用就不給，甚至收回。

假設VM1開機後運作提供服務，只使用了500MB、VM2實際使用1GB、VM3實際使用700MB、VM4實際使用2GB、VM5實際使用800MB，那Hypervisor就分配5,000MB即可讓所有的VM運作正常。

這在以往實體環境裡很難辦到，因為老舊的實體伺服器，記憶體插了2GB的RAM，就算OS只用了一半不到，剩下的也無法挪為他用。

Memory over-commit可以在Host上容納更多的VM而不增加記憶體成本。不需要很狹隘地依照Virtual Hardware的配置，每個VM通通先切2GB出去，將實體伺服器的記憶體全部分配完，VM就算用不到額外的RAM，也不會釋放出來，使hypervisor回收再利用。

圖4的範例顯示，5個VM實際使用了多少記憶體，要多少才給多少，雖然在Guest OS的工作管理員看到的Available Memory 是2GB，但是只要實際上沒有用這麼多，就先不給。

▲圖4 5個VM使用記憶體，要多少才給多少。

TPS（Transparent Page Sharing）

承上題，當你發現採購的新伺服器只使用了一半的記憶體，當然會想再P2V多一點VM來耗用這些記憶體，假設一切條件不變，你有另外5部老舊伺服器，配置都是2GB。

但經過精算評估後，發現恰好他們實際記憶體用量總共也是約5GB左右，於是你就將另外這5部老舊機器再虛擬化到這個新的伺服器上。

如此一來，現在就有了10個VM在這個ESX/ESXi host上了。想說這樣應該可以將10GB的記憶體全部佔滿了吧？經過幾天測試確認VM運作正常後，以vSphere Client去查看ESXi host資訊，很驚訝地發現，實體記憶體只被用掉7.5GB，還剩下約25%的記憶體資源沒有使用到。

怎麼會這樣呢？多出來這25%的記憶體資源怎麼來的？

這就是現在要為大家介紹的TPS（Transparent Page Sharing）功能。如果公司機房的伺服器OS長的都差不多的話（例如都是Windows Server 2003），那麼虛擬化到同一個ESXi host運作之後，VM彼此之間的許多Instances、應用程式以及核心管理程式的載入，有很多的地方都是相同、類似的。

這些相同的地方呢，其實可以讓VM的Memory Page共用同一份，避免太多相同重複的實體RAM佔用，而VMkernel會去掃描VM 的RAM是否有相同重複的部分，如果有就對應到相同的記憶體區塊。如此一來，又可節省了不少記憶體出來。

圖5的範例是整合了10個VM的ESX(i) host，因有了TPS技術，所以10GB的實體RAM並沒有被佔滿，依然還剩下25%可再利用。

▲圖5 整合10個VM的ESX(i) host。

Memory Ballooning

承上題，現在有10個VM在新採購的伺服器上運作，考量到實體記憶體還沒有被用滿，你決定再轉移5部老舊機器，P2V到新伺服器上。如今，這個ESX/ESXi host已經承載到15個VM。

假設這5部老舊機器的條件都不變，一樣需要耗費5GB的記憶體容量，照道理說，新伺服器只剩下25%（2.5GB）左右的記憶體，鐵定會造成實體記憶體不足的情況。

但是連續幾天的實際使用狀況，這15個VM依然運作順暢，沒有因為Memory導致的效能問題產生（在此不考慮Network、Disk I/O 等其他因素）。這就令人更納悶了，為何會這樣？

這就是接下來要探討的問題—Balloon driver，也稱為Vmmemctl Driver。

在圖6裡，我們可以知道目前記憶體的使用量已經超過，可能在95%～105%之間遊走，而一旦使用超過實體的RAM，就必頇要拿硬碟空間來當作Swap，這意味著有部分VM的記憶體使用，其實是在硬碟上運作（黑色陰影部分）。

▲圖6 記憶體使用量在95%～105%之間遊走。

試想一下，如果是一般的PC使用情形，當電腦記憶體不足的時候，OS就會嘗試著將RAM裡面的資料放置到硬碟上暫存，自行做記憶體管理。

如果記憶體一直持續不足，就必頇一直在硬碟做存取置換的動作，造成效能下降的狀況。當記憶體空間釋放出來以後，暫存於硬碟上的Page file就可以再寫回實體RAM，此時PC的效能就會回復正常。

但是，圖6（範例3）的情形由於已經是虛擬化的狀態，實體記憶體資源並非OS掌控。假設hypervisor分配給它2GB，VM就會認為自己有2GB的實體記憶體，但是一旦hypervisor沒有辦法給它這麼多，VM完全不會察覺自己已經沒有記憶體，它會持續的一直使用下去，而不會自行記憶體管理。

當它在沒有察覺到RAM不足的情況之下，此時VM「自認」還有足夠的記憶體而持續使用的部分，通通跑進硬碟裡。在硬碟的哪裡呢？就是vswp這個檔案（也稱為VMkernel Swap或Virtual Swap）。

這個檔案的大小恰好等於VM所配置的記憶體，而且當VM開機vswp檔案就會出現，VM關機就消失。這是hypervisor為了保證在Memory over-commit的情況之下，假使最壞的狀況，所有VM都還是能維持運作的一種手段。

不見得會用到，我們也不希望用到，但是必頇先預留硬碟空間，以防止最壞的狀況：實體已經沒有一絲一毫的記憶體，但是VM 仍要開機，這時運作的vRAM就全部在vswp這個檔案。

一旦大量的vRAM進入VMkernel Swap之後，這個時候的VM運作速度就會異常的緩慢，效能便會變非常的差。

為什麼呢？因為有些屬於核心程式是一定要保留在實體記憶體中運作，不應該在硬碟上面運作，但是由於VM不曉得記憶體不夠用，所以它並不會自行Paging，將該留在RAM的東西保留住。

那麼有沒有辦法讓VM察覺到自己的RAM不夠，而自己主動先做Paging機制呢？

Balloon driver的作用這時候就可以發揮了，當VM安裝好VMware tools的時候，就會有Balloon driver，平常這個氣球（Balloon）在實體記憶體充足的時候是不會啟動的。

當VM的RAM越要越多，VMkernel沒辦法再供應足夠實體記憶體的時候，這時它就會通知VMware tools現在記憶體是吃緊的狀態，無法再供應記憶體了，請VM自行先做記憶體管理吧！

這個時候VMware tools就會開始將氣球膨脹，慢慢越變越大，不斷地佔據VM的Available Memory，Guest OS就會發現到有一個應用程式一直在吃掉它的記憶體，就真正察覺到記憶體已經不夠用，便會自行先Paging，將部分vRAM的資料放置到硬碟Local Swap上面（例如Windows預設是「C:\pagefile.sys」），這樣的好處是不會先進VMkernel Swap，雖然結果都是在硬碟上面，但是效能卻是差很多。

這個氣球是空心的，當它就開始膨脹，就會佔據Guest OS原本的記憶體，使Guest OS自己開始做Swap，將部分資料放置於Disk，等到VMkernel又開始有實體記憶體可以分配給VM的時候，氣球就可以縮小體積，Guest OS便會察覺自己又有RAM了，於是會將硬碟上的資料再搬回來，恢復正常的效能（圖7）。

▲圖7 VMware Resource Management Guide

所以Balloon driver也可以用於當VMkernel要收回某個VM的記憶體而拿來支援別的VM時，VMkernel會去掃描是否有VM的RAM正處於閒置狀態，再藉由吹氣球的方式，強迫Guest OS釋放部分閒置的記憶體（Idle Memory）。

現在這個範例已經有15個VM在新的伺服器上面，並且都能夠運作的非常順暢，藉由Memory overcommitment、TPS、Balloon driver、Idle Memory tax的幫助，使得平時記憶體資源在VM不是同時忙碌時都能應付自如，偶爾15個VM同時忙碌到了極限，也可以

先暫時Page out一些到硬碟，效能不致影響太大。

等到某些VM閒置時再由VMkernel收回重分配，讓VM可以Page in回vRAM，動態地達到最佳的利用率。