VMware vSphere 5.1 群集深入解析（六）

VMware vSphere

5.1

Clustering Deepdive

 

HA.DRS.Storage DRS.Stretched Clusters

 

 

 

Duncan Epping &Frank Denneman 

 

Translate By Tim2009 / 翻译：Tim2009

 

 

 

 

 

 

目录

版权

关于作者

知识点

前言

第一部分 vSphere高可用性

第一章 介绍vSphere高可用性

第二章 高可用组件

第三章 基本概念

第四章 重新启动虚拟机

第五章 增加高可用灵活性（网络冗余）

第六章 访问控制

第七章 虚拟机和应用监控

第八章 集成

第九章 汇总

第二部分 vSphere分布式资源调度

第一章 vSphere DRS介绍

第二章 vMotion和EVC

第三章 DRS动态配额

第四章 资源池与控制

第五章 DRS计算推荐

第六章 DRS推荐向导

第七章 DPM介绍

第八章 DPM计算推荐

第九章 DPM推荐向导

第三部分 vSphere存储DRS

第一章 vSphere存储DRS介绍

第二章 存储DRS算法

第三章 存储I/O控制（SIOC）

第四章 数据存储配置

第五章 数据存储架构与设计

第六章 对存储vMotion的影响

第七章 关联性

第八章 数据存储维护模式

第九章 总结汇总

第四部分 群集架构的扩展

第一章 群集架构的扩展

第二章 vSphere配置

第三章 故障排错

第四章 总结汇总

第五章 附录

第六章 访问控制

访问控制是时至今日最容易混淆的概念之一，因为它往往被禁用，当可用性需要得到保障时，接入控制是必须的，这是不是启用HA首先需要配置它的原因呢？

什么是HA接入控制呢？为什么HA包含一个接入控制的概念？“可用性指南”指出以下几点：

引用

vCenter Server使用接入控制，以确保群集中有足够资源提供故障保护，同时确保虚拟机有足够的预留资源。

请再次阅读一次引用，事实上vCenter负责接入控制，而与很多人以为的相反，虽然这可能看起来是个很平常的事实，但重要的是明白接入控制不是不允许HA触发重新启动，HA触发重新启动在主机这一层，且不通过vCenter。

正如所说，接入控制保证了HA触发故障转移时群集有足够的预留资源可用，它根据群集故障转移的可用资源计算所需容量。换句话说，如果一个主机被放置到维护模式或者被断开，则从计算公式中移除该资源，如果一台主机发生故障或者没有响应，但一直没有从群集中删除，那么该资源还是在计算公式中，“可利用资源”表示已经从总量中减去虚拟机开销的资源。

举个例子，VMkernel内存是指从内存总量减去虚拟机内存的可用内存，在你研究不同的接入控制策略时，这里有个难点值得你注意，当接入控制开启，HA是无法去限制它，也就是说，它永远确保这多台主机启动和运行策略，包括人工维护模式的主机。例如，VMware分布式电源管理（DPM），因此，如果主机在试图进入维护模式时被卡住，请记住，可能是HA不允许该主机在维护模式下运行，因为这违反了接入控制策略，在这种情况下，用户可以手工迁移该主机上的虚拟机，再关闭虚拟机，或者临时关闭接入控制，让主机进入维护模式。

在vSphere 4.1和之前的版本中，当你禁用掉接入控制，开启分布式电源管理，它可能会严重影响可用性，当接入控制被禁用，DPM会将所有的主机都关掉以降低电力消耗，除了1台待机模式的主机，当这台主机发生故障，就没有备用主机，这可能导致一些麻烦和告警，而在vSphere 5.0中，该行为有了变化，当分布式电源管理开启,HA将会确保随时至少有2台主机通电以保证故障群集转移的可用性。

vSphere 4.1中，当HA触发故障群集转移时，当主机退出待机模式，DPM还是相当智能去确保有足够的资源，如果资源不可用，HA会等待DPM提供足够的资源，然后尝试重新启动虚拟机，换句话说，重试次数（模式5次）不会在资源不够的情况下浪费。

如果你还是使用旧版本的vSphere，或者“上帝保护”的VI3版本，由于只有一台主机在待机状态，所以你应该考虑结束了它们，当特定主机发生故障或者资源比较紧张，它可能导致潜在的问题，可能没有能开启虚拟机的主机可用，这个场景描述可以看一下知识库的文章http://kb.vmware.com/kb/1007006.

接入控制策略

接入控制规定的机制，保证了HA启动群集故障转移时有足够的资源可用，本节给出接入控制策略的一个总体概述，在下面的部分中将描述每个策略的影响，包括我们的建议。HA有三种机制来保证虚拟机有足够的可用资源。

图26 接入控制策略

下面我们列出了目前可用的所有三个选项的接入控制策略。每一个选项都有不同的机制来确保资源可用于故障转移，每个选项都有其注意事项。

接入控制机制

每个接入控制策略都有自己的准入控制机制。了解这些准入控制机制非常重要，当在设计群集时你能够鉴别每一个策略的影响。例如预留特定的虚拟机资源来保证相应的比例，本节将通过接入控制策略和他们各自的机制和算法来更深入的了解它。

群集主机故障容忍

接入控制策略一直是围绕着“群集主机故障容忍”的策略，它也是比较复杂的接入控制机制。

虽然“群集主机故障容忍”接入控制机制本身并没有改变，一个限制被移除，在vSphere 5.0之前，由于主/备节点的机制，可以容忍的最大主机故障数是4，在vSphere 5.0中，这个机制被替换为master/slave节点机制，这是为了N-1的主机故障而设计的，也就是说，在群集里有32台主机的情况下，你可以设置“主机故障容忍”到31.

仅在vSphere 5.1的WEB客户端提供了一个新功能，它能够手工设置slot size，如下图所示，在vSphere 5.1 WEB 客户端还允许您查看虚拟机跨越多个slots，当slot size被明确指定后，这对我们非常有用，我们会解释为什么。

图27：主机故障

所谓“slot”机制，当选择“群集主机故障容忍”和接入控制策略时会经常用到，这一机制的细节过去已经改了好几次，它是一个最严格的策略，更可能是了解的最少的策略。

通常在vCenter大喊“资源不足”之前，slots决定了有多少虚拟机可以开启，一个slot代表一个虚拟机，接入控制不会限制HA重新启动虚拟机，它确保有足够的资源提供给虚拟机启动从而防止过度承诺。从技术来讲过度承诺是个不正确的术语，接入控制确保预留的资源能让虚拟机满意，尽管我们已经谈到这一点，HA启动故障转移不受接入控制限制，HA触发重启，在一个常见的场景中，直接在ESXi主机上执行，不需要使用vCenter，尽管有点跑题，问题是HA在哪个过程要求DRS（DRS是vCenter的一个任务）进行资源碎片整理？即使资源不足，vCenter会抱怨，但它还是不能终止重启操作。

让我们深入刚刚介绍到的这个概念 slots

引用

slot定义为：满足群集中任何虚拟机资源需求的逻辑CPU和内存资源

换句话说，群集中只预留了一个slots是最糟糕的，这直接导致“疑难杂症”

HA为群集内开启的虚拟机预留最高的CPU和内存，如果预留不超过32MHz，HA会使用默认的32MHz的CPU，请注意，这种行为已经改变：在vSphere 5.0之前的版本默认是256MHz，这个值被改变是因为有些人认为256MHz太激进，如果没有设置内存预留，HA会默认使用0MB+内存开销。（每个虚拟机配置的内存开销的详细信息，请参见VMware vSphere资源管理指南），下面的例子将阐述什么是“最坏的情况”。

例子：如果虚拟机VM1有2GHz的预留CPU和1024MB的预留内存，虚拟机VM2有1GHz的预留CPU和2048MB（加上内存开销值）的预留内存，slot size将设置成2GHz，它是两台虚拟机预留的最大资源，也决定了slot size值，尽管预留定义了资源池的级别，但不会影响HA slot size的计算。

基本设计原则

预留必须小心，如果没必要以每个虚拟机为单位，不用对其配置，尤其当使用群集主机故障容忍，如果预留是必须的，最好以资源池为单位。

当我们需要计算slot size，现在我们知道要将最坏的场景考虑在内，我们将描述决定了群集中的可用slots，决定了群集内能开启多少虚拟机。

首先，我们需要知道内存和CPU的slot size，接下来我们将区分CPU slot size和内存 slot size中的可用资源，这是留给我们的总数量slots的内存和CPU，最严格的数量（最坏的情况）也就是主机的slots 数量，换句话说，当你有25 CPU slots但是只有5 内存 slots，对于主机来说总的可用slot数量是5，HA一直把最坏的情况作为考虑原则，这样保证在发生故障时虚拟机有足够的资源开启。

我们收到很多问题是我怎么知道我的slot size是什么？详细的slot sizes是HA的一部分，当配置了接入控制策略时，群集监控选项的高级运行时间信息中可以查到它。

图28：群集监控HA部分

高级运行时间信息显示了slot size和更多的有用信息，包括slot的可用性等如图28

图29：HA高级运行时间信息

正如你所想象，在每一个虚拟机上使用预留，会导致非常保守的整合率，然后，在vSphere 5.1中，通过Web客户端可以配置一些东西，如果你有一个高预留的虚拟机，你有通过编辑群集服务来设置slot size，并制定接入控制策略，如图30所示

图30：虚拟机跨越多HA slots

请注意，因为内存的slot size已被手工设置为1024MB，由于4GB的内存预留一个虚拟机跨越多个插槽。正如你可能已经注意到了，没有一个主机有足够的预留资源来满足故障群集转移，尽管总的来说有足够的资源可用，但资源碎片零散分布，HA不能开启这台特定的虚拟机，但是可以要求DRS进行资源碎片整理，以适应该虚拟机的资源需求。

当slot size在高级设置中被手工定义，接入控制不考虑资源碎片整理，一定数量的可用slots来自于减少虚拟机的消耗，为确保故障转移它不会验证每个主机的可用slots，如前所述，HA将要求DRS进行碎片资源整理，这绝不是为了启动虚拟机的尝试。

基本设计原则

避开使用高级功能设置会减少slot size，同时会造成更多的停机时间和增加额外的复杂度，如果在大小和预留上有巨大的差异，我们建议您使用基于百分比的接入控制策略。

vSphere 5.1围绕虚拟机跨越多个slots增加了新的功能，如图27所示，我们强烈建议您定期查看本节内容，以更好的理解您的环境，确定主机发生故障的情况下哪些虚拟机需要重新启动。

不平衡配置及slot计算影响因素

硬件配置相似，这是行业创建群集的最佳实践。当虚拟化起初被介绍时，许多公司已经部署了小型的VMware群集虚拟化，随着时间的推移群集需要扩大，相同的硬件设备不再可用，问题是你新买的主机是添加到原有的群集还是新建个群集呢？

从DRS的角度来看，大群集时首选，因为它增加了负载均衡的机会，然后，同样对DRS也是一个提醒，本书中的DRS章节将会描述，对于HA，还有一个重要的提醒，当你了解并理解了HA，甚至具体到插槽算法，你可能会预料到未来的发展方向。

让我们先来定义“不平衡群集”

不平衡的群集，例如，群集中有3台主机，有一台主机的内存比其它两台更多。

让我们举个例子说明

例子

集群中有以下规格数量的插槽，会发生什么？

• 群集内三台主机

• 两台主机有16GB的可用内存

• 一台主机有32GB的可用内存

第三台是刚刚买的全新品牌的主机，购买了32GB的内存代替原有16GB内存的主机

群集上运行着一台1 vCPU，4GB内存的虚拟机，1024 MB作为虚拟机的预留内存。如前所述，预留决定了插槽大小，在这种情况下会导致内存插槽大小为1024MB+内存开销，为了简单起见，我们计算为1024MB。

图31 场景描述

当启用接入控制，同时选定主机允许发送故障的数量，计算每个主机和群集总的插槽数，结果如下：

表4：插槽数量预览表

由于启用了接入控制，最坏的情况也被要求考虑，当一个主机已经确认发生故障，这意味着大量的插槽数将被调出，换句话说，群集将得出以下结果：

ESXI-01 +ESXi -02 = 32 可用插槽

虽然你有一台内存翻了一倍的主机，你还是被迫接受32个插槽，您明白，当您设计的群集开启了接入控制，策略中主机故障数也已经选择，为群集内一台主机增加内存显然没有加分。

在我们的例子中，内存插槽大小是最严格的之一，然而，同样也适用于CPU插槽大小，它也是最严格之一。

基本设计原则

当使用接入控制，为了平衡群集资源，太过保守的预留会导致整合比率下降。

现在，当允许主机发生故障数为2，上图的场景会发生什么情况？在ESXi-03被抽出的情况下，任何一个剩下的主机被抽出，结果还是16个插槽。

你能不借助高级功能设置，来避免大量HA插槽大小被预留么？这是个问题，我们几乎每天都得到的答案是“群集资源预留百分比”准入控制机制。

群集资源预留百分比

在vSphere 4.0中，VMware推出了作为故障切换空间容量保留的群集资源的百分比，这是个CPU和内存公用的一个值，在vSphere 5.0中，它被改变了，它允许你选择CPU和内存的不同百分比。见图32所示。

图32：设置CPU和内存不同的百分比

基于百分比的接入控制策略的主要优点是，它避免了根据经验值导致预留插槽过大的问题。但是，如果它不使用插槽算法，它有什么用？

当你指定一个百分比，然后我们来假设现在CPU和内存的资源总量配置同样的百分比，这一比例为HA预留，首先HA会增加所有能发现的资源，看多少可以利用，然后，HA会计算当前保留了多少资源，然后提供它的CPU和内存资源给虚拟机启动。

对于没有预留资源的虚拟机，默认CPU 32MHz和0MB+内存开销的资源将用于该虚拟机，。

换句话说：

所有的可用资源 – 所有的预留资源/所有的可用资源 < = （HA需要预留的资源比率）

保留虚拟机资源包括CPU 32MHz和内存开销

让我们用个图表来使其更清晰。

图33：群集资源预留百分比

全部群集资源时24GHz（CPU）和96GB （MEM），这导致了下面的计算公式

((24 GHz - (2 GHz + 1 GHz + 32 MHz + 4 GHz)) / 24 GHz) = 69 % available

((96 GB - (1,1 GB + 114 MB + 626 MB + 3,2 GB)/96 GB= 85 % available

正如你所看到的，即使设置了资源预留，内存开销也算到资源预留中，图中的内存数量还是不同，这个例子也演示了如何保证同等CPU和内存的百分比，而导致了不平衡，理想的情况下，主机在这样的方法下被预分配，是没有CPU/内存的不平衡的，多年的经验证明，大多数环境中内存资源要用尽的时候，才考虑计算利用率的百分比，但是，这个趋势可能会因为内存越来越便宜而改变。（也就是说，内存便宜了，就可以多买些，提高预留资源）

为了确保虚拟总是可以重新启动，接入控制将不断的监控是否有违背策略的行为，请注意，接入控制是vCenter的一部分，而不是ESXi主机的一部分，当内存、CPU达到一个阈值，接入控制将不允许任何额外的虚拟机开启，这些阈值在群集概要的HA监控部分可以查看到。

图34：HA概要

如果你有一个不平衡的群集（主机由不同大小的CPU和内存资源），您的百分比应该等于或者大于主机提供的最大资源百分比，这样做是为了确保在发生故障时，虚拟机所在的主机有足够的资源让其重新启动。

正如前面解释到，接入控制策略不是用在插槽。因此，资源可能会分散在整个群集中，然而，vSphere 4.1中，DRS被通知重新平衡资源，以适应虚拟机的需求，但不能保证，我们建议为这些虚拟机选择最高的启动优先级（当然，根据不同的SLA）以确保它能够引导。

接下来的举例和图表（图35）将使其显而易见，你有3台主机，每台内存使用量大约为80%，并且您已经在HA选项中配置了20%的CPU和内存预留资源。主机发生故障时，所有的虚拟机将需要进行故障转移。这些虚拟机中有个4GB的内存预留，正如你所想象，HA将无法尝试启动电源，因为没有足够的内存资源来确保预留容量。那么会为这台虚拟机产生事件“这个虚拟机故障转移没有足够的资源”

图35：可用资源

基本设计原则

虽然vSphere 5.0利用DRS调配资源来满足虚拟机资源需求的不能给予，但任何一台主机上都有足够的资源开启高配置虚拟机，还是要为这些虚拟机考虑重启优先级。

故障切换主机

第三部分我们可以选择一个或者多个故障切换主机，这通常被称为“热备用机”，除了vSphere 5.0中增加了故障切换主机的数量，还要围绕着原理，告诉你的并不多。

图36：选择故障切换主机接入控制策略

它指的是“你看到的就是你得到的“。当您指定了故障切换主机时，他们不会参与到DRS中，并且您将无法在这些主机上运行虚拟机！这些主机是为故障转移预留的。HA首先尝试在这些虚拟机故障转移虚拟机，否则，任何原因，都是不成功的，它会在任何其它的主机上尝试故障转移，例如，当三个主机已经发生故障，包括指定的故障转移主机，HA仍会在剩下的主机上启动受影响的虚拟机，尽管这些主机不是指定的故障转移主机，HA会用它们来减少停机时间。

图37：选择多个故障切换主机

决策时间

你做的任何决定，都会对环境有影响。这个影响可能是积极的，也有可能是出乎意料的，尤其适用于HA接入控制。选择合适的接入控制策略，可能会导致更快的投资回报率和较低的总成本，在前面的章节中，我们描述了所有的算法和机制，形成了接入控制，在本节中，我们将更加注重为您或者您的客户环境中设计选择适当的接入控制策略。

需要作出的第一个决定，这将是准入控制是否将被启用。我们通常建议启用接入控制，保证发生故障后允许您的虚拟机重新启动，因为它是唯一的出路。重要的是我们的策略是经过精心挑选和适合您或您的客户的要求。

基本设计原则

为了保证虚拟机故障切换成功，接入控制要保证有足够的资源可用，我们同样建议您开启它。

虽然我们已经在前面的章节已经解释了每个策略的原理,我们将在本机中继续给与高度概括,列出所有的利弊,最重要的是,我们将扩展到让我们感受到灵活方便的接入控制策略,以及如何配置和计算.

群集主机故障容忍

这个选项是最常用的接入控制,大多数环境被设计成N+1冗余和N+2冗余,此接入控制使用的”插槽”是为了发生故障转移时有足够的资源容量,这是一个相当复杂的机制.插槽是基于虚拟机级别的,如果预留的不定义CPU默认值为是 32MHz, 不定义内存最大开销,那么虚拟机可以使用所有资源.

优点:

• 全自动(当一台主机被加入到群集,HA会自动重新计算群集内有多少插槽可用)

• 计算插槽大小,保证群集故障切换

缺点:

• 当规定了最大的预留插槽大小,会变得死板和僵化

• 不平衡的群集会导致资源浪费

• 管理计算插槽数会比较复杂

群集资源预留百分比

在vSphere 4.0中引入了基于百分比的接入控制策略,基于百分比的接入控制是基于每预留计算,从而代替插槽计算.基于百分比的接入控制策略比“主机故障”更保守，比“故障切换主机”更灵活。

优点：

• 准确计算每个虚拟机发生故障转移时的预留资源

• 当资源被添加时，群集会动态调整资源

缺点：

• 当群集内添加主机时，主机故障数保持不变，需要手工计算

• 当选择的资源比例太低或者资源被分散，不平衡的群集就有一些问题，这意味着无法保证虚拟机在故障转移时有足够的资源可用

虽然故障转移不被保证，还是有几个场景中虚拟机也不会被重新启动，虽然大多数群集有备用容量可考虑提供给虚拟机。虽然这是一个死角问题，在在实际环境中还是必须提供绝对的保证。

指定故障切换主机

接入控制策略中的“指定故障切换主机”，当一个或者多个主机发生故障，HA会尝试在指定故障主机上重新启动虚拟机，设计故障切换主机实质上是热备主机，换句话说，当群集资源不足或者群集资源不平衡的情况下，DRS不会迁移虚拟机到“指定故障切换主机”上。

优点：

• 简单明了

• 没有分散资源

缺点：

• 简单明了

• 在正常操作期间故障切换主机不会被使用。

建议

我们已经说很多遍，我们建议使用接入控制，很难回答每个策略孰优孰劣，不过，我们一般建议一个基于百分比的接入控制策略。这是一个非常灵活的策略，它实际保留了每个虚拟机的实际资源使用，从而代替主机发生故障时会产生的最坏情况，但是，在所有的情况下要保证主机的故障切换级别，基于百分比的限制较少，但在提供较低保证的情况下，HA将能够重新启动虚拟机，随着添加了HA和DRS的整合，我们相信，一个基于百分比的接入控制策略将是最适合环境的。

基本设计原则

我们建议使用按百分比的基本接入控制策略，因为它是最灵活的。

现在，我们已经建议使用哪个“接入控制策略”，下一步选择正确的百分比我们将围绕其提供指导，我们不能告诉你什么是理想的百分比，因为这完全取决于您的群集的大小，当然，在弹性模式下（N+1 vs N+2）我们还是能够的，但是，具体的指导标准取决于有多少资源可以计算，有多少资源需要避免浪费。

选择合适的百分比

它是一种常见的策略来选择单个主机百分之多少的资源预留故障切换，我们通常建议选择一个主机或者许多主机的百分比，让我们来解释如果不使用一个主机或者多个主机的相等的比例有什么影响。

让我们举个例子，一个群集存在8台ESXi主机，每台70GB可用内存，这听起来像一个尴尬的内存配置，但把事情简单化，我们已经减去2 GB的虚拟化开销。虽然虚拟化开销大概是小于2 GB，我们已经使用这个值使计算变得更容易，放大这个内存的例子，当然同样也适用于CPU。

这个群集我们内存和CPU设置群集资源预留20%，这样算出总的群集内存容量为448GB

(70 GB + 70 GB + 70 GB + 70 GB + 70 GB + 70 GB + 70 GB + 70 GB) * (1 – 20%)

总计112GB的容量用于故障切换预留。

一旦指定了预留百分比，该百分比的资源将不提供给虚拟机使用，因此设置一个百分比等于一个单一或者多个主机的资源时很有道理的，我们在随后的例子中将证明为什么这很重要。

上面的例子中，使用了20%的预留资源在8个主机的群集中，此配置保留了更多的资源比单个主机，HA的主要目标是提供物理服务器故障后虚拟机的自动恢复，出于这个原因，它是建议预留单个或者多个主机资源相等的资源，当在8个主机群集以每个主机为粒度，每个主机贡献的资源为12.5%，然而，百分比必须是个整数，所以保守的比例是13%。

图38：设置正确参数值

激进做法

我们已经看到许多环境中，这个百分比的设定值小于一台群集主机的一台的资源，虽然这种方法减少了大量的预留资源来适应主机故障，导致更高的整合率，当HA发生故障时它还提供了一个较低的保障重新启动虚拟机，可能有人会说，这种做法在大多数的环境中资源无会导致资源无法充分利用，但是它能在虚拟机出现故障后提供保证，难道这不是起初启用HA的原因么？

添加主机到群集

虽然群集计算容量的比例是动态的，当你扩大群集时，你选择的百分比值也需要相应变化，原因是故障转移预留资源可能不对应每个主机的贡献，结果导致浪费资源预留的资源量，例如，增加4台主机到8台主机的群集中，继续使用之前配置的13%的接入控制策略，这样将导致故障转移能力相当于1.5个主机，图39描述这样一个场景：8台主机群集扩展到12台主机的群集，每个主机拥有8核2GHz主频的CPU，70GB的内存，群集最初设置的接入控制策略为13%，相当于109.2GB内存和24.96GHz的CPU，如果要允许一个主机发生故障，7.68GHz和33.6GB将被浪费，如图39所示。

如何定义你的百分比

如前所述它完全依赖已经选定的N+X模式，我们建议选择一个百分比等于单台主机所代表的资源量，所以，在8个主机的群集和N+2弹性的情况下，这一比例应该设置如下：

2 / 8 (*100) = 25%

基本设计原则

为了避免浪费资源，我们建议你仔细选择你的N+X的弹性架构，基于这种架构计算所需的百分比。