浅谈Virtual Machine Manager(SCVMM 2012) cluster 过载状态检测算法

在咱们使用scvmm2012的时候，常常会看到群集状态变成了这样

点开看属性后，咱们发现是这样

、

发现了吗？Over-committed，若是翻译过来就是资源过载，或者说资源过量使用了，那么这个状态是怎么出现的呢？

出现这个状态之后会出现什么问题？怎么解决？

今天咱们就谈一谈在SCVMM中over-committed的算法，知道SCVMM是如何确认一个群集是否过载后，就知道如何避免它，带来种种问题也就能解决了

 

part 1. 算法概述

SCVMM 2012 群集的过载检查主要是用来确认整个群集是否能够在最大容许宕机节点数(这个值咱们暂时记为R)宕掉后，将运行在这些节点上的VM在其它可用节点上启动，值就是上图中配置的：Cluster reserve(nodes)。群集先将群集状态预设为overcommitted ，而后经过检查算法运算后，再确认群集状态是什么状况。

那么过载会有什么危险呢？

1.一个完美的系统，有!这种符号看上去就很不爽，因此我要解决它……好吧，我是强迫症

1.系统在overcommited后，此时若是发生了节点失败，业务就有可能不能正常failover，换句话说，有可能重要的VM根本没有资源启动了，想一想下场吧，谁管理这个系统谁就会死的很惨

2.在进行VMM的动态优化的时候，由于overcommited状态，动态优化就不能正常的工做……这个之后我再发一篇文章专门写VMM动态优化

3.……暂时还没想到

 

part 2.算法介绍

算法一共有四种，只要其中任意一种算法经过了检查，就将群集状态置为“OK”，不然保持“overcommitted ”状态。但要说明的是：overcommited这个状态，只是针对内存的，CPU使用咱们是无论的

如今我先把四种算法列出来，以下表：

 

能够看出来评估方法有两个，分别是proof和slot,检测策略也有两个，分别是simple和full，四种算法就是策略的评估方法的组合2*2=4种

下面分别说一下评估方法和策略，可是看说明可能不太明白我写的是什么是意思，你能够大概过一遍，而后看下面的算法详解，而后回来再看，应该就明白了

1.Proof Method

这个算法评估整个群集是否知足以下条件：在R节点上的VM除去最大内存开销的VM，都已经切换到群集中的其它节点上，以后最大开销内存的VM没有可用的主机进行切换，这是一种最差状况假设

2.Slot Method

经过一个将R节点上的最大VM作为一个标准SLOT，而后计算 H节点的可用SLOT数，以后评估是H节点是否能够放置R节点的全部SLOT

3.Simple check

简单检查算法不考虑具体节点，只在整个群集上作一个假设。在群集中选定最大VM作为标准（内存 or slot)。一样的，在进行余量（slot或者内存量）检测的时候，会在全部节点内选择最小的余量进行统计。须要注意的是，最大VM可能与最低slot是同一个节点，可是进行简单检查的时候不考虑这一点

4.Full Complexity Check

复杂检测算法是穷举群集中的每一种N（R，H）组合. 进行检测的时候， slot数 , 最大 VM , H节点的内存和SLOT统计都按具体指定的组合进行从新计算，此检查算法最大的风险就是N（R，H）组合量有可能变的很大，具体来讲就是有N^R种，为了不这种大量的运算，这个算法只会在 N^R < 5000才使用。

这里可能能够简单列一个群集组成作为参考

 

part 3.算法详解

这里先列出一些预约义值计算方法，下面算法中会用到

群集值

主机节点值

这些变量值会在每一个主机上进行计算，会预先计算出来后将值代入下面的计算公式中

 

有几点须要注意

1. 每一个VM须要额外的64MB用以hyper-v监控程序开销,可是为了方便计算，下面的算法不把这个值代入计算了

2. Stopped, saved state, paused 和running 状态的VM也都要参与计算.

3. 若是虚拟机使用的是动态内存，则用当前分配的值用以公式计算

 

part 4.算法

终于到了算法部分了，看上去好像计算复杂，其实看明白了以为这个算法也不是特别麻烦，下面把四种算法说明一下

4.1 Slot Simple

- SlotSize = 群集中VM配置的最大内存值

- 在每一个主机上计算：AvailableSlots, UsedSlots ，TotalSlots

- 计算TotalSlotsRemaining=sum(主机组中H个最小TotalSlots)  注意是所有节点按TotalSlots排序后，从小到大取H个TotalSlots
- If Sum(UsedSlots) <= TotalSlotsRemaining, 则群集没有过载，状态置为OK.

4.2 Slot full

须要计算各类R与H的每种组合状况

- SlotSize = R中最大内存开销VM

- 计算每一个主机上的AvailableSlots, UsedSlots ，TotalSlots
- TotalSlotsRemaining =H主机的TotalSlots 总数
- 若是Sum(UsedSlots) > TotalSlotsRemaining, 群集状态可能为 overcommitted. 
- 若是每种组合的Sum(UsedSlots) <= TotalSlotsRemaining , 群集状态则为OK

4.3 Proof Simple

- LargestClusterVM = 群集中最大内存开销VM

- 计算全部主机的AdditionalMemory, VM数
- TotalAdditionalSpace = sum(主机组中H个最小AdditionalMemory)  ，与Slot Simple算法中的TotalSlotsRemaining值计算方式同样

- TotalOrphanedVMs = sum(最大VM*R) – LargestClusterVM. 
- 若是 TotalOrphanedVMs <= TotalAdditionalSpace, 群集状态为OK.

特别注意: 若是 TotalOrphanedVMs =0, LargestClusterVM > 0 and TotalAdditionalSpace = 0, 群集可能为overcommitted

4.4 Proof Full

须要计算各类R与H的每种组合状况

- LargestClusterVM = R中最大内存开销VM 
- 在全部主机上计算AdditionalMemory, VM数

- TotalAdditionalSpace = Sum （H主机AdditionalMemory）

- TotalOrphanedVMs =Sum (R主机的vm内存) – LargestClusterVM. 
- 若是 TotalOrphanedVMs > TotalAdditionalSpace, 群集可能overcommitted. 
- 若是 TotalOrphanedVMs = 0, LargestClusterVM > 0 and TotalAdditionalSpace = 0, 可能overcommitted.

若是每种组合的 TotalOrphanedVMs < TotalAdditionalSpace , 群集状态为OK.

 

算法说完了，最后说一点：以上这些算法，通通都不会把群集状态标记为过载

…………

是否是以为白白浪费了时间看这篇文章了,那我这说什么梦话呢，明明是说怎么检测过载！

其实在一开始的时候已经说了，VMM对于群集状态都置都认为是overcommitted的，换句话说，就是默认值是过载的，状态算法只负责标记状态OK。因此若是上面的算法不能证实群集没有过载，SCVMM就会显示群集状态为overcommitted,反之，只要有任意一个算法证实群集未过载才会把状态置为OK

此外，这里还有一个处理逻辑：就是在进行Full Complexity检查中，只要有一组计算结果为可能过载或者过载（这里也说明了上面我在进行算法说明的时候，为何有几处写的是”可能”overcommit)，那么就当即中止本次检测，群集状态为overcommited

 

part 5 .demo

好了，终于到了例行的你们期待的demo了，若是只说算法不进行个演示，这个概念的确比较抽象，

场景:4节点群集，主机为 4x 32GB hosts. 系统保留内存 9GB. 64MB的hyper-v监控须要内存不参与计算（彻底就是图我方便）, Cluster reserve (R)为2,群集组成以下图，，即R=2，H=2，N=4：

 

Slot Simple Example

- Slot size = 8GB

- TotalSlotsRemaining = sum(2个最小slot)= (1+3) = 4 
- TotalUsedSlots = 7

判断：TotalUsedSlots > TotalSlotsRemaining, 此方法测试未经过

Slot Full Example

- TotalUsedSlots = 7

上表中每一行都表明一个组合的运算中间值和结果

判断：能够看到有部分TotalUsedSlots > TotalSlotsRemaining,因此这个方法检测未经过（这里说一句，其实不用都算出来，只要有一组数据检测没经过这个运算就已经结束了）

Proof Simple Example

- LargestClusterVM = 8GB

- TotalAdditionalSpace = sum(H个最小AdditionalMemory)= 0GB + 5GB = 5GB. 
- TotalOrphanedVMs = (8GB + 8GB) – 8GB = 8GB.

判断：TotalOrpanedVMs > TotalAdditionalSpace, 此方法检测失败

Proof Full Example

表中每一行仍是表明一组RH组合的运算中间值和结果

判断：能够看出每一组的 （Orphaned – LargestVM <= AdditionalMemory），条件都知足了,因此群集状态置为：“OK”