因爲本人用的系統是英文版，截圖也都是英文的，所以文中表述常常會中英混雜，只是爲自己方便，還請見諒。
爲方便描述，本文中的資源池(Resource Pool)都簡寫爲RP。VM=虛機，Shares=份額，vCPU=虛機的CPU，Limit=限額或上限，Reservation=保留。
爲方便描述，本文中的資源池(Resource Pool)都簡寫爲RP。VM=虛機，Shares=份額，vCPU=虛機的CPU，Limit=限額或上限，Reservation=保留。
資源池(Resource Pool, RP)有2種，CPU資源池和Memory資源池。其概念還是很容易理解的。
下圖截取自官方的《vSphere Resource Management Guide》第36頁
圖1：資源池
其中1臺主機有6GHz CPU資源和3GB可用內存資源。並且創建了2個資源池，RP-QA獲得2/3的資源，也就是4GHz CPU資源和2GB內存資源。RP-Marketing獲得剩下的1/3的資源。
一個集羣(Cluster)的資源池包含集羣中所有主機(Host)的資源總和。比如一個2主機的集羣，每個主機都有16GHz CPU和16GB內存，那麼這個集羣的資源總和就是32GHz的CPU和32GB的內存。在這個集羣中創建的資源池就從這個總的可用資源中分配。
集羣的可用資源總是小於集羣的總資源，這是因爲每臺主機都會佔用一部分CPU和內存資源，保留給自己的Hypervisor和COS用(如果是ESX的話)。
雖然集羣資源池是所有主機資源的總和，但是並不意味着某一VM可以使用超過某一主機的資源。比如，2臺16GB內存的主機組成集羣，集羣中創建了一個30GB內存的資源池，但是任何單臺VM都不能使用超過16GB pRAM的，因爲VM不能跨主機使用資源，VM可用到的資源還受到單臺主機物理資源上限的影響。
|
|
思考題1：請問這樣的描述正確嗎？因爲VM不能跨主機使用資源，所以在上面例子中30GB內存的資源池中將不能創建1臺20GB內存的VM，因爲20GB大於單臺主機的物理內存。(答案點這裏) |
同VM一樣，資源池也有Shares, Reservation和Limit這3個配置項。（見下圖）
圖2：編輯資源池屬性
【Limit】
RP的Limit和VM的Limit類似，不同的就是這個limit是RP中所有VM可用物理資源的上限值。
雖然Limit不會限制VM的創建，但是它限定了可用物理資源，影響了RP中運行中VM的性能。
【Shares】
資源池的資源通常通過份額來分配。有3種預設的份額分配方式，High，Normal和Low，比重分別爲4:2:1。反映在Shares數字上則如下表
| 份額(Shares)類型 |
High | Normal | Low |
| 比重 |
4 | 2 | 1 |
| CPU |
8000 | 4000 | 2000 |
| Memory |
327680 | 163840 | 81920 |
| 如果各一個RP的% |
57.1% | 28.6% | 14.3% |
比如說一個集羣有5個資源池，1個High，2個Normal，2個Low，那麼High的RP可以獲得4/(4+2*2+1*2)=40%的資源，Normal的RP各可以獲得20%，Low的RP各可以獲得10%資源。
資源池下可以建子資源池。資源按份額的比例分配。
看圖很容易理解。
圖3：資源池與子資源池
下面通過幾個例子來說明問題。在我的例子中有2個RP，一個叫IT-RP，另一個叫QA-RP。有3臺VM，其中Test01分配了2個vCPU和2GB內存；虛機thick-dp和thin-dp都只有1個vCPU和1GB內存。
(1) CPU資源的份額(shares)和vCPU個數有關，Normal類型下，每個vCPU 1000份額。
例如：同一個RP下的VM，都設了normal，1個vCPU的thick-dp和thin-dp都只佔share 1000，2個vCPU的Test01佔share 2000
圖4：例子1-CPU
Worst case allocation是最壞情況下該VM會佔用的資源數量，這個最壞情況是指VM，而不是RP，換一句話說就是VM在運行一個耗CPU的程序，已經達到了100% CPU佔有率。這個值是根據當前資源狀況動態計算出來的。我的例子中因爲沒有爭用，所以耗CPU的VM可以跑滿2個vCPU，我的host用的是XEON E5405，是四核且每核2GHz，因此2個vCPU可以用足4000MHz，2個vCPU的thick-dp可以用足2000MHz。thin-dp這臺VM因爲設置了CPU Limt爲1000MHz，因此它的Worst Case Allocation是1000MHz。
Worst case allocation是最壞情況下該VM會佔用的資源數量，這個最壞情況是指VM，而不是RP，換一句話說就是VM在運行一個耗CPU的程序，已經達到了100% CPU佔有率。這個值是根據當前資源狀況動態計算出來的。我的例子中因爲沒有爭用，所以耗CPU的VM可以跑滿2個vCPU，我的host用的是XEON E5405，是四核且每核2GHz，因此2個vCPU可以用足4000MHz，2個vCPU的thick-dp可以用足2000MHz。thin-dp這臺VM因爲設置了CPU Limt爲1000MHz，因此它的Worst Case Allocation是1000MHz。
內存資源的份額和VM的配置內存大小(configured memory size)有關。Normal類型下，每1MB的內存佔10份額。也就是說每1GB(1024MB)就是10240份額。
例如：同一個RP下的VM，都設了normal，1GB內存的VM的份額是10240，2GB內存的Test01虛機就有20480份額。
例如：同一個RP下的VM，都設了normal，1GB內存的VM的份額是10240，2GB內存的Test01虛機就有20480份額。
圖5：例子1-Memory
內存的Worst Case Allocation和CPU的類似，是指運行一個耗內存的程序時VM最多能佔用的pRAM的數量。大家會發現這個最壞情況佔用比配置內存/內存上限還要大一點，多的那部分就是用於memory overhead的。memeory overhead的大小和VM被配置了多少個vCPU和多少vRAM有關，關於memory overhead的具體信息，詳見拙文：《VMware內存配置再探》。
(2) 在cluster根一級的VM和其下的第一層Resource Pool共同分享所有資源。
Normal RP默認份額是4000，單vCPU的VM的Normal份額是1000，2個vCPU的是2000
![]()
圖6：例子2
所以，如果某服務器特別重要，需要特別多的份額，那就直接放在cluster底下，可以不用放進任何RP
Normal RP默認份額是4000，單vCPU的VM的Normal份額是1000，2個vCPU的是2000
圖6：例子2
所以，如果某服務器特別重要，需要特別多的份額，那就直接放在cluster底下，可以不用放進任何RP
Normal類型的資源池，其內存份額是163840，CPU份額是4000，相當於一臺配置了4vCPU和16GB內存的VM。（爲便於記憶這麼類比）
(3) 將VM從某一個RP移走，份額總數會減少，意味着每一單位份額的資源增加了；VM移入某個RP，總份額會增加，意味着每一單位份額的資源減少了。
圖7：例子3-移除VM對資源分配的影響
這個例子中，總份額數從8000下降到了6000，原先有16GHz CPU資源，每一份是2MHz，現在增加到了2.67MHz。因此每個RP的總資源也增加了。
VM移動到另一個RP的時候，其Limit和Reservation值保留。其份額如果是以Normal, High, Low表示的話，將在目的RP中佔有相應的比例。並且影響到目的RP的總份額數。下圖例子中，Test01的加入導致該RP中總份額由2000增加到了4000，因此單位份額的CPU資源下降了一半，原先每臺VM的可用資源比例也從50%下降到了25%.
圖8：例子3-加入VM對資源分配的影響
重要！強調一點，份額(Shares)必須是在有資源爭用(Contention)的情況下才起作用。
千萬不要被圖1所迷惑了，錯以爲6GHz的CPU就應該按照Normal比Low的2:1的比例分配給2個RP，其中1個4GHz，另外一個2GHz。錯！大錯特錯！真實的情況是，在沒有發生爭用的時候，不管其中哪1臺VM(例如VM-Marketing1)都可以用5GHz甚至更多的CPU資源。
千萬不要被圖1所迷惑了，錯以爲6GHz的CPU就應該按照Normal比Low的2:1的比例分配給2個RP，其中1個4GHz，另外一個2GHz。錯！大錯特錯！真實的情況是，在沒有發生爭用的時候，不管其中哪1臺VM(例如VM-Marketing1)都可以用5GHz甚至更多的CPU資源。
【Reservation】
RP的reservation不是決定其中的VM能用多少CPU/內存資源，而是用來分配給VM的Reservation用的。如果RP的可用保留(Available Reservation)不夠VM Reservation需要的量，VM將不能被啓動，或者正在運行中的VM不能被移動到該RP中。這種檢查叫做准入控制(Admission Control)。
比如資源池中可用內存保留是1500MB。位於該RP中的VM1和VM2的內存保留都是1024MB，當我們啓動VM1的時候，可以正常啓動。但是再啓動VM時，剩下的可用內存保留只有476MB，不夠1024MB，於是VM2無法啓動，用戶將收到Insufficient Memory Resource的報錯。
資源池有2種類型，Fixed和Expandable。在上面的截圖中可以看見，CPU和Memory資源都可以勾選Expandable Reservation，默認是勾選的。如果手工去掉這個勾，就可以更改爲Fixed。
Fixed類型就是其中的VM的Reservation只能使用自己的Reservation，而Expandable的RP Reservation就是不僅可以使用自己的Reservation，而且當RP中的可用保留(Available Reservation)不夠VM用的時候，可以使用父RP中的可用保留。
下圖就是將Memory Reservation類型從Fixed改成Expandable後，Available Reservation的變化。
圖9：資源保留的類型Fixed和Expandable
VM開機纔會有Reservation，關機的時候就把這部分Reservation還回資源池了。
RP Reservation中的內存/CPU資源並非被這個RP獨佔，而其他RP無法使用。如果某一個RP Reservation中的內存沒有被用掉，而其他RP的VM還是可以使用這部分內存的。
舉例，Host有3GB內存，完全競爭下RP1獲得1GB，RP2獲得2GB。RP1設了1GB的Reservation，但是其中沒有VM。RP2中有且僅有一臺VM配置了2.5GB內存，運行一個耗內存的程序，那麼這個VM可以獲得2.5GB的pRAM，其中0.5GB來自RP1，而無視其Reservation。
但是，增加某個RP的Reservation就減少了其他RP可以獲得的Reservation。
還是上例中，Host有3GB內存，RP1 Normal，reservation 1GB，RP2 Low，reservation 0.5GB。那麼Host還剩下1.5GB的 Available Reservation。如果RP1和RP2都是expandable的，那麼RP1的Available Reservation有2.5GB，RP2的Available Reservation會顯示有2GB。此時，增加RP1的Reservation到2GB，你會發現RP1的Available Reservation還是2.5GB，但是RP1的卻只有1GB了。
開啓一臺VM所需要的物理內存，不僅和Memory Reservation有關，也和Memory Overhead有關。當Available Reservation小於開啓一臺VM所需的需求(等於Memory Reservation和Overhead的和)時，VM就無法啓動。
舉例，如上圖9中，Fixed的時候，可用保留只剩下132MB了，此時啓動1臺2vCPU，2GB內存，0內存保留的VM，是否能啓動呢？答案是不能，因爲雖然此VM內存保留設爲了0，但是Memory Overhead還需要198MB可用內存保留。因此無法啓動。
現在揭曉思考題1的答案：不對。這臺VM可以被創建，也可以被運行。雖然這臺VM不能跨主機使用資源，也就是它最多可以用到16GB的pRAM，但是別忘記它還有swap，因此，20GB的swap保證了Guest OS的運行。
本文出自 “delxu的Live記事本” 博客，請務必保留此出處http://delxu.blog.51cto.com/975660/283522