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

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

浅谈Virtual Machine Manager(SCVMM 2012) cluster 过载状态检测算法 images/loading.gif' data-original="http://images0.cnblogs.com/blog/663420/201507/161434301886914.png" width="258" height="143" border="0" />

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

、

发现了吗？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