大大

╰半橙微兮° 2022-10-02 02:49 93阅读 0赞

[http://delxu.blog.51cto.com/975660/283522][http_delxu.blog.51cto.com_975660_283522]

因为本人用的系统是英文版，截图也都是英文的，所以文中表述常常会中英混杂，只是为自己方便，还请见谅。  
  
为方便描述，本文中的资源池(Resource Pool)都简写为RP。VM=虚机，Shares=份额，vCPU=虚机的CPU，Limit=限额或上限，Reservation=保留。

资源池(Resource Pool, RP)有2种，CPU资源池和Memory资源池。其概念还是很容易理解的。

下图截取自官方的《vSphere Resource Management Guide》第36页  
![201003131268478829864.jpg][]  
图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可用到的资源还受到单台主机物理资源上限的影响。

同VM一样，资源池也有Shares, Reservation和Limit这3个配置项。（见下图）  
  
![201003131268478878953.jpg][]  
图2：编辑资源池属性

【Limit】

RP的Limit和VM的Limit类似，不同的就是这个limit是RP中所有VM可用物理资源的上限值。

虽然Limit不会限制VM的创建，但是它限定了可用物理资源，影响了RP中运行中VM的性能。

【Shares】

资源池的资源通常通过份额来分配。 有3种预设的份额分配方式，High，Normal和Low，比重分别为4:2:1。反映在Shares数字上则如下表

<table style="padding:0px; margin:0px auto 10px; font-size:12px; border-collapse:collapse"> 
 <tbody style="padding:0px; margin:0px"> 
  <tr style="padding:0px; margin:0px"> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 份额(Shares)类型<br style="padding:0px; margin:0px"> </td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> High</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> Normal</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> Low</td> 
  </tr> 
  <tr style="padding:0px; margin:0px"> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 比重<br style="padding:0px; margin:0px"> </td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 4</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 2</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 1</td> 
  </tr> 
  <tr style="padding:0px; margin:0px"> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> CPU<br style="padding:0px; margin:0px"> </td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 8000</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 4000</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 2000</td> 
  </tr> 
  <tr style="padding:0px; margin:0px"> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> Memory<br style="padding:0px; margin:0px"> </td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 327680</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 163840</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 81920</td> 
  </tr> 
  <tr style="padding:0px; margin:0px"> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 如果各一个RP的%<br style="padding:0px; margin:0px"> </td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 57.1%</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 28.6%</td> 
   <td style="padding:5px 10px; margin:0px; border:1px solid rgb(221,221,221)"> 14.3%</td> 
  </tr> 
 </tbody> 
</table>

比如说一个集群有5个资源池，1个High，2个Normal，2个Low，那么High的RP可以获得4/(4+2\*2+1\*2)=40%的资源，Normal的RP各可以获得20%，Low的RP各可以获得10%资源。

资源池下可以建子资源池。资源按份额的比例分配。

看图很容易理解。

![201003131268478924235.jpg][]  
图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  
![201003131268478958188.jpg][]

图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。

内存资源的份额和VM的配置内存大小(configured memory size)有关。Normal类型下，每1MB的内存占10份额。也就是说每1GB(1024MB)就是10240份额。  
  
例如：同一个RP下的VM，都设了normal，1GB内存的VM的份额是10240，2GB内存的Test01虚机就有20480份额。

![201003131268478981909.jpg][]  
图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  
  
![201003131268479020229.jpg][]  
图6：例子2  
  
所以，如果某服务器特别重要，需要特别多的份额，那就直接放在cluster底下，可以不用放进任何RP

Normal类型的资源池，其内存份额是163840，CPU份额是4000，相当于一台配置了4vCPU和16GB内存的VM。（为便于记忆这么类比）

(3)  将VM从某一个RP移走，份额总数会减少，意味着每一单位份额的资源增加了；VM移入某个RP，总份额会增加，意味着每一单位份额的资源减少了。

![201003131268493527958.jpg][]  
图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%.

![201003131268479086768.jpg][]  
图8：例子3-加入VM对资源分配的影响

重要！强调一点，份额(Shares)必须是在有资源争用(Contention)的情况下才起作用。  
  
千万不要被图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的变化。

![201003131268479117064.jpg][]  
图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 Tech Notebook][]” 博客，请务必保留此出处[http://delxu.blog.51cto.com/975660/283522][http_delxu.blog.51cto.com_975660_283522]

[http_delxu.blog.51cto.com_975660_283522]: http://delxu.blog.51cto.com/975660/283522
[201003131268478829864.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268478829864.jpg
[201003131268478878953.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268478878953.jpg
[201003131268478924235.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268478924235.jpg
[201003131268478958188.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268478958188.jpg
[201003131268478981909.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268478981909.jpg
[201003131268479020229.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268479020229.jpg
[201003131268493527958.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268493527958.jpg
[201003131268479086768.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268479086768.jpg
[201003131268479117064.jpg]: http://delxu.blog.51cto.com/attachment/201003/201003131268479117064.jpg
[delxu Tech Notebook]: http://delxu.blog.51cto.com/