WSFC日常管理操作

   在本篇文章中，老王将为大家介绍一些WSFC日常管理的功能，相对来说会轻松一些，其中有的功能可能您之前看到过，但是不知道什么意思，或者一直没用过，老王希望通过这篇文章能够让更多的人知道WSFC原来还有这些管理功能，应该如何去操作使用。

   老王主要会围绕着两个层面来讲，一个层面是WSFC的运行放置，一个层面是WSFC的维护更新

   说起WSFC的放置策略，首先想和大家聊聊所有者这个概念，在WSFC中，不论是我们做计划内的维护，或是计划外的故障转移，群集总是要把维护故障节点上的资源迁移走，那么迁移到哪里去呢，这里首先要考虑的概念就是所有者，默认情况下，如果安装好一个群集什么也不额外设置，那么当一个节点发生故障时候，它上面的资源是会被随机的放在群集里面其它活着的节点上，因为对于该节点上面的群集资源来讲，所有存活节点都是一样的，我那个节点都可以去。

   到了2008R2时×××始，WSFC群集开始实行智能放置，即是说，如果没有做任何群集应用的管理配置，默认情况下，当节点发生计划内维护，或计划外故障转移时，群集会去评估看看那个节点上的群集资源少，群集会尽可能的帮我们把故障节点的资源转移至群集资源负载少的节点上继续运行。

   以2008R2为例，目前我们有三个节点，两个群集应用，分别是devtestdtc和devtestdtc1，devtestdtc1当前在Node3运行，devtestdtc当前在Node1运行

直接断电Node1，可以看到devtestdtc并没有去Node3，而是去了没有任何负载的Node2

    首先要给大家介绍的所有者概念是首选所有者，刚才和大家说过，默认情况下如果什么都不做，则对于群集应用来说，发生故障的时候，它转移到那个节点运作都是一样的，但是一旦我们设置了首选所有者，就相当于我们告诉了应用，当发生计划内维护或计划外迁移的时候，你应该首先去这个首选节点，你在这上面会运行的更好    

    打开群集应用属性可以看到首选所有者设置，默认并没有勾选，即对于群集应用所有节点都一样

在本例中，我们将devtestdtc的首选所有者手动设置为Node3

当前devtestdtc首选所有者设置为Node3，Node3上面已有应用devtestdtc1运行

在这里我们选择将devtestdtc移动至另一个节点，选择最佳，最佳则意味着，让群集去根据放置策略评估，帮我们选择最适合的节点

默认情况下应该是根据智能放置，选择没有负载的Node2，但是由于我们手动设置了devtestdtc的首选所有者为Node3，因此devtestdtc会被放置在Node3

由此可以看出，首选所有者的执行会优于群集默认智能放置的执行，群集会感知到这里存在我们手动的指定，因此会以首选所有者为准。

另外一个重要的概念则是可能所有者，这两个概念在2003时代就有了，可能所有者的概念即是说，对于一个群集应用来讲，当你做计划内维护，或计划外故障转移时，你有哪些节点可以转移，默认情况下对于群集应用来说所有节点都可以去，但是我们可以通过手动编辑可能所有者列表，让群集应用只可以被联机上线到指定的节点，如果指定节点不在，则应用不要联机运行。

在本实例中，我们使用四台群集服务器，devtestdtc托管于node1，devtestdtc1托管于Node3

当前devtestdtc的首选所有者为Node3

直接断电Node1，可看到按照我们预想的devtestdtc去了Node3，因此首选所有者设置无论是在计划内维护或是计划外故障转移都会生效。

打开devtestdtc属性，高级策略可以看到，当前所有群集节点都是可能所有者，因此，即使首选所有者Node3不可用，devtestdtc也可以去其它节点。

接下来我们看另外一个例子，当前devtestdtc和devtestdtc1都在Node1运行，devtestdtc的首选所有者设置为Node1，Node2，Node3，但是可能所有者只有Node1和Node2，devtestdtc1不做任何设置

devtestdtc首选所有者

devtestdtc可能所有者

devtestdtc1不做任何设置

这时直接断电HV01和HV02，可以看到，devtestdtc1由于没有做任何设置，因此会根据智能放置随机放在Node3，devtestdtc只是被转移到了节点，但是并没有办法联机上线，因为没有合格的可能所有者

  虽然我们设置了devtestdtc首选所有者为Node3，但是因为devtestdtc的可能所有者只有Node1和Node2，因此devtestdtc并不会在Node3首选所有者上线，可以看出，不论是群集默认的智能放置，或是首选所有者，但只要没有合格的首选所有者，应用都将无法联机上线，可能所有者的设置会盖过首选所有者和智能放置来执行。

   至此，我们已经了解了首选所有者和可能所有者，老王认为这两个概念看似很普通，但是掌握好了也各有个的用途，例如，如果你知道，你的群集应用在某些节点上面运行的很好，那么你就可以设置首选所有者，确保计划内维护或计划外故障时，只要看到这个首选节点活着，应用就优先去它上面运行。如果你知道群集里面有的节点硬件很老的，执行效率很低，那么你就可以设置一些关键群集应用的可能所有者，设置只在性能好的节点上面执行，永远也不让关键应用在老旧节点执行。

  除了首选所有者和可能所有者，在2008R2时代，群集还新增了一个资源属性，保持模式，老王也叫它默认所有者

   那么什么是默认所有者呢，简单来说，就是一旦你针对于群集资源勾选了这个属性，那么群集就会去记住，这个资源在下一次冷启动之前运行的是哪个节点，当发生故障转移之后，再次冷启动时，会让应用回到故障转移之前的节点上面运行，通过这个属性，你可以控制一些对于节点有粘合性的应用，例如一些关键的VM，希望它们可以始终在这个节点上面运行，那么你可以启动保持模式

    在2012时×××始这个功能在GUI界面被隐藏，可以通过powershell命令控制，2012时代针对于VM默认启用该功能。

当前devtestdtc1并没有设置首选所有者和可能所有者，只是勾选了启用保持模式

Node3发生故障时，devtestdtc1被转移到node1

当Node3恢复，这时重新启动Node1的群集服务，模拟节点冷启动

可以看到应用回到Node3运行，默认所有者设置生效

在实际使用中老王发现默认所有者有以下节点需要注意的地方

1.如果针对于启用保持模式的应用，手动移动至其它节点，例如devtestdtc1当前运行在Node3，你手动把它移动至node1，当群集节点冷启动后，devtestdtc1并不会再回到Node3运行，因为当你手动移动的时候，群集就又会重新记忆devtestdtc1的默认所有者为node1

2.默认所有者设置，并不会在节点恢复后立刻生效，需要在转移后节点重新启动群集服务，或重新开机后，才可以回到默认节点

3.如果资源设置了首选所有者，则首选所有者设置优于默认所有者执行，例如，devtestdtc1的首选所有者设置为Node1，那么当Node3发生故障后，devtestdtc1将一直在Node1运作，不会再回到Node3。

4.默认所有者可以看成是可能所有者中的最优节点，如果群集应用有指定首选所有者则优先考虑首选所有者，如果首选所有者不可用，则考虑默认所有者

5.不论是默认所有者设置或是首选所有者设置，都需要按照可能所有者的列表来执行，如果可能所有者列表发生变化，例如应用的默认所有者被剔除，则不会再回去默认所有者节点，而是按照可能所有者列表，选择其它可用的节点放置

 在2008R2中，WSFC针对于资源放置还新增一个属性，ClusterGroupWaitDelay，如果我们设置了首选所有者或使用了保持模式，则每次群集冷启动时，群集会等待应用的首选所有者或保持节点上线，然后优先把应用放在首选所有者和保持节点，这样可以一定程度上保证应用始终回到我们想要它在的节点上

 2008R2时代默认每个群集应用的ClusterGroupWaitDelay属性为30秒，2012R2中是120秒，可以通过powershell命令自行设置，冷启动后，如果在这段时间内，首选所有者或默认所有者还没上线，则群集会选择其它可能的所有者进行上线应用

 你也可以针对群集应用设置允许故障回复，这样即便是ClusterGroupWaitDelay时间内，首选所有者和默认所有者没有上线，应用在其它可能所有者上面运行了，但是当首选所有者或默认所有者恢复，也可以通过故障回复回到原来的节点上

  #手动修改ClusterGroupWaitDelay时间

（Get-Cluster devcluster）.ClusterGroupWaitDelay = 300

   总结一下，所有者概念是我们看群集放置的第一个概念，其中，首选所有者和默认所有者，都可以理解为增强×××，一旦我们设置之后，不论是计划内维护或计划外故障转移时，群集都会尝试帮我们把资源放在首选所有者上面，如果首选所有者不可用，则放置在默认所有者上面，如果没有设置首选所有者，则默认所有者设置直接生效。

   如果最终经过等待，首选所有者和默认所有者节点都无法联机，群集应用也会去尝试使用其他可能所有者节点上线，并不会因为首选所有者和默认所有者不在，而导致应用没办法联机，群集默认是希望所有应用都能够持续的联机可用，但是如果我们希望应用始终不要在指定的节点上面运行也可以通过手动修改可能所有者列表进行实现，可能所有者是强制×××，会盖过首选所有者，默认所有者，智能放置来执行。

   说完所有者的概念之后，我们再来看看优先级，优先级对于群集放置来说也是个重要的概念，默认情况下，如果不设置优先级，那么当节点开关机的时候，或者故障转移的时候，应用会随机争抢资源，因为大家都一样，没什么区别，我们都是要抢到资源，快速联机上线，但是这时候，就有可能会发生一个启动风暴的问题。

    例如，如果说，你的节点服务器资源有限，单个节点不能承载所有应用的联机上线，那么当发生故障转移的时候，如果只剩下这个节点，那么就很有可能会发生，很多重要的群集应用，没有上线，而不那么重要的群集应用联机上线了，把资源都给抢占没了，导致重要应用计算资源不足，没办法上线。

    如果你设置了群集资源的优先级，则可以避免这个问题，优先级设置会在以下场景中生效

1. 群集节点关机开机时，优先联机上线高优先级应用

2. 节点置为维护模式时，优先迁移处理高优先级应用

3. 节点故障转移时，优先转移高优先级应用

   优先级功能在2008R2时代被引入，在2008R2时代，我们仅可以设置资源是否要自动启动，可以通过设置一些不重要资源，让他们在冷启动或故障转移后，不要自动启动，等待管理员手动把它们联机，这样初步可以确保重要的应用不会被不重要的应用抢占资源。

  到了2012时代，优先级功能得到完善，走向成熟，在2012时代，我们不仅可以设置资源是否自动启动，还可以设置资源的优先级为高中低，这样可以从一个更加细粒度的层面帮我们控制启动风暴的问题

  例如，当节点重新开机，计划内维护，或故障转移时，会优先帮我们处理高优先级的资源，确保高优先级的资源会首先转移联机上线，然后再处理中优先级的，最终处理低优先级的，如果高优先级和中优先级把节点CPU和内存资源占满，则低优先级应用不会上线与高中优先级应用抢占资源，设置为不自动启动的资源，则在故障转移后，需要管理员手动启动上线，在2012虚拟化场景下，如果在高优先级虚拟机所在节点发生故障，故障转移时，如果其它服务器上没有可用内存，会抢占低优先级虚拟机的资源，释放脱机低优先级虚拟机，而让高优先级虚拟机上线。

 除了可以帮助我们很好的处理启动风暴，转移风暴的问题，通过优先级还可以帮我们解决一些依赖性场景，例如，当前群集跑了一套sharepoint环境，有AD域，sharepointdb，sharepointweb，在资源充足的情况下，我们可以设置AD域的优先级为高，数据库的优先级为中，web的优先级为低，这样当节点开机关机时，AD会首先联机，其次是数据库，最后Web再联机，计划内维护或故障转移时，也会优先转移AD，其次是DB，最后Web。

实验验证，当前群集一共有两个节点，四个群集应用，优先级分别是高中低，不自动启动，当前所有应用托管于HV01节点

HV01忽然宕机，可以看到，群集应用按照优先级顺序，处理上线，针对于设置为不自动启动的devtestdtc2，则并不会联机上线，需管理员确认有足够资源后，手动给予联机上线。

优先处理高优先级Test1

处理中优先级devtestdtc

处理低优先级Test2

处理不自动启动devtestdtc2

  任何一项技术都有它存在的意义，关键在于人们是否能深入挖掘到它的用途，老王认为优先级设置的意义就在于帮助处理启动风暴的问题，或者帮助处理依赖性启动的问题

  如果您的群集资源规划的很好，节点资源很充足，单台节点宕机，或只剩下最后一个节点时，节点可以支撑起所有应用，那么你可能并不需要优先级设置，除非您的环境涉及到依赖性启动，那么您也可以利用优先级设置。

  如果您的服务器资源有限，或者的群集上面有很重要的应用，那么老王建议您可以使用优先级功能，逐步规划资源的优先级，确保发生故障或冷启动时重要的应用优先上线，优先级设置不论是针对群集角色或虚拟机都可以生效，虽然使用优先级设置，有时候会牺牲低优先级的可用性，来保证高优先级资源的可用，但是至少在资源不足的情况下，能够保证关键应用优先在线，等到资源充足时，再重新规划资源，确保所有应用都可以一直在线

  在放置策略中另外一个要考虑到的因素则是反相关性，什么是反相关性呢，简单来说，默认情况下，如果我们使用首选所有者，默认所有者，可能所有者，智能放置等策略，都可能没办法避免一种情况，即两个资源同时在一个节点上运行，一旦出现两个资源都在一个节点运行的情况，那么当这个节点宕机，就需要整个应用的故障转移，应用也会出现宕机时间

  例如，我们在WSFC群集中部署了AD域控制器，两台域控制器，DC1，DC2，假设现在两个虚拟机都在同一个节点运作，这个节点忽然断电，两个虚拟机都需要故障转移至其它节点，在故障转移这段时间，用户是没办法登录到域控的

  反相关性则可以解决这个问题，我们可以设置两个资源，具备同样的反相关性属性，这样不论是手动移动至最佳节点，或是维护模式，故障转移，只要其中一个资源看到另外一个资源上面有相同反相关性属性的资源，就不会转移过去，确保两个相同反相关性的资源，始终不在同一个节点上面运行，这样从一些程度来说会帮助减少应用的停机时间。

  在WSFC群集中，反相关性在2008R2时代可以通过自定义类实现，2012时×××始新增了powershell设置命令，更加简单，把自定义类的过程封装了起来，但是并不能在GUI界面配置，在SCVMM和Azure中，实现为GUI界面可用性集，也是为了增加应用的可用性而用。

实验验证

当前群集内共三个节点，两个协同工作的DTC应用，分别运作在HV01和HV03

当前并没有设置首选所有者，HV01直接宕机，devtestdtc会根据内存智能放置，而被放置在HV02

将devtestdtc重新移动回HV01，设置HV03为首选所有者

HV01再次宕机，可以看到资源并没有按照内存智能放置策略放置在HV02，而是根据首选所有者策略放置在了HV03，首选所有者盖过了默认的内存智能放置。

再次将devtestdtc移动回HV01，首选所有者依然设置为HV03

#设置devtestdtc和devtestdtc2相同反相关性属性

(Get-ClusterGroup devtestdtc).AntiAffinityClassNames = "DTC"

(Get-ClusterGroup devtestdtc2).AntiAffinityClassNames = "DTC"

反相关性属性可以针对于群集角色或群集虚拟机生效，同一个群集角色或群集虚拟机可以有多个反相关性属性

再次宕机HV01，可以看到devtestdtc并没有去首选所有者HV03，而是去了HV02，反相关性策略生效

查看clusterlog，可以看到当群集评估放置策略的时候，会看到Node 2 即 HV03上面具备自定义class类，即AntiAffinityClass属性DTC，因此RCM取消放置在它上面，最终决定放置在Node4 即HV02

因此大家可以看出，反相关性在一些场景下会起到作用，例如如果你是一个虚拟化集群，里面你跑了两台AD，或两台DHCP，或两台DNS，两台SQL，等两个节点协作完成的应用，你希望始终可以有一台虚拟机能够对外提供服务，那么就可以利用反相关性，设置两台虚拟机的相同反相关性，以确保在正常情况下两台虚拟机始终分散在不同节点上，防止单个节点故障带来整个应用的故障转移。

通过实践老王总结出一些关于反相关性的理论

1. 反相关性设置优先于首选所有者执行，优先默认所有者执行，优于内存智能放置执行

2. 反相关性，首先所有者，默认所有者，智能放置，都需要可能所有者支持

3. 反相关性设置同样是一项增强性设置，仅在群集有多于一个节点时起作用，如果群集只剩下最后一个节点，则两个相同反相关性属性的应用同样会在这个节点上线，在只剩下最后一个节点的情况下，并不会因为反相关性而阻止两个应用上线

对于反相关性我们还有很多话要说，等后面我们完成维护模式和故障回复的部分再回过头来看它

在群集中我们可能会经常看到一个概念，即最佳节点，很多朋友可能会很好奇，到底什么是最佳节点，这个最佳到底是怎么评定出来的，事实上最佳，则是所谓最佳，就是群集帮我们选择的最合适的节点，当我们点击下去最佳的时候，事实上群集会去根据反相关性，首选所有者，可用所有者，智能放置策略来综合考虑，最终决定出最合适的节点

最初始的情况，如果没有做过任何额外的配置，在2008R2时代，点击移动至最佳，群集会根据智能放置策略，帮助我们选择其它活着节点上面，当前承载群集应用负载最少的节点

在2012时代，点击移动至最佳，则不仅仅会考虑节点应用负载，也会考虑节点剩余内存，2012时代的智能放置，也叫做内存智能放置，会根据节点群集应用负载和内存负载，来尽可能的帮助我们选择，当前剩余内存多，上面负载又少的节点作为最佳。

如果群集应用额外做了设置，则群集又会去重新评估最佳节点

1. 如果应用设置了首选所有者，则首先去到首选所有者为最佳

2. 如果应用设置了首选所有者和反相关性，则反相关性优先执行，继续根据内存智能放置选择其它节点为最佳

3. 如果应用设置了首选所有者，反相关性，可能所有者，若反相关性判定的节点没有合格的可能所有者投票，则继续根据内存智能放置选择其它节点为最佳

在WSFC群集中，除了最佳节点会调用内存智能放置来判断最佳节点，当计划内维护，或计划外故障转移时，默认情况下群集也会优先根据内存智能放置来放置群集应用到合适的节点，如果检测到了有首选所有者，反相关性，可能所有者等设置，则再一层一层的过滤，但是在默认情况下，群集的意识始终都是为了能够让应用不论是计划内或计划外都能始终尽快的上线，因此群集对于负载的平衡，2012时代中WSFC故障转移默认情况下至多只能是根据上面的内存负载和群集应用负载来进行考虑。

如果在您的环境中有SCVMM，通过SCVMM管理群集，则SCVMM的动态优化功能可以和群集的内存智能放置相互配合，默认情况下群集节点故障转移，根据内存智能放置策略快速把虚拟机转移走进行上线，稍后SCVMM检测到各节点负载发生变化，又会根据CPU，内存，硬盘IO，网络等综合指标，来重新动态平衡各节点的负载，实现更加深入准确的负载均衡控制

SCVMM在执行动态优化的时候如果感知到了群集的首选所有者，反相关性，可能所有者，仲裁等设置，也会遵守执行

WSFC群集更侧重的是故障转移后让应用快速上线联机使用，执行简单的应用和内存负载调度，而SCVMM则更侧重整个虚拟化集群环境的负载均衡，因此把WSFC群集和SCVMM相结合可以实现真正的虚拟化资源负载均衡。

在使用最佳节点这项功能时，有一点需要注意，之前我们点击移动最佳节点，是点击单个角色，选择移动至最佳节点，如果这时应用了内存智能放置策略，会帮我们选择内存和负载尽可能少的节点，但是如果我们一次选择了多个角色，一起移动至最佳节点，则并不一定都会移动至同样的节点，因为内存智能放置的处理，一次只能处理一个角色或一个虚拟机，可能对于这个虚拟机来说，它移动至HV01节点为最佳，因为HV01节点没有负载，但是下一台虚拟机要移动的时候又会重新评估，当前HV01和HV02节点都有一个群集资源，我应该是那个节点为最佳呢，这时候又会根据内存使用情况去选择，如果最终内存使用情况也一致，则会再根据可能所有者列表选择其它节点为最佳。

以上我们看了群集运行放置中设置到的一些概念，内存智能放置，首选所有者，保持模式，可能所有者，优先级，反相关性，可以说几乎已经涵盖了运行放置中绝大部分要考虑的点，下面我们再综合看下在不同的放置场景下，这些概念的应用。

手动移动至指定节点

优先级失效，内存智能放置失效，首选所有者失效，反相关性失效，在手动移动至指定节点时，群集只会评估目标节点是否是可能所有者节点，如果在可能所有者列表内，节点资源充足，则可以移动

手动移动至最佳节点

优先级生效，群集会按照优先级设置进行处理，先移动处理高优先级应用，确保高优先级应用会首先被上线，优先级确认好了处理顺序后，放置策略再根据处理顺序，逐步评估每个应用的放置，群集默认会基于可能所有者列表进行内存智能放置评估，如果检测到应用有首选所有者设置，则移动至首选所有者节点为最佳节点，忽略内存智能放置的决定。如果设置了反相关性，则反相关性优于首选所有者执行，忽略首选所有者决定，群集会再根据内存智能放置选择其它节点为最佳。

群集整体冷启动

优先级生效，群集节点会根据优先级顺序，优先联机上线高优先级的应用，如果仅剩下最后一个节点，则高优先级会被优先联机上线，紧接着在处理中，低优先级应用，如果最终低优先级应用没有计算资源可用，则不会上线。随着节点逐步上线，当检测到应用有设置首选所有者，且故障回复，则应用会故障回复到到首选所有者运行，但如果检测到目标节点已有反相关性资源，则重新选择其它节点。

在只剩下最后一个节点启动的情况下，只要该节点是合格的可能所有者，那么即便它不是应用的首选所有者，即便会让两个相同反相关性的应用一起在它上面，应用也会联机

群集节点故障转移

优先级生效，群集会根据优先处理，优先处理高优先级的应用，将高优先级的应用进行优先转移上线，其它优先级排队等待，确认好了处理顺序后，群集会再根据放置策略进行评估，首先根据可能所有者列表考虑内存智能放置策略，优先尝试把高优先级应用放置在内存和应用负载少的节点上，如果感知到了应用有设置首选所有者，且首选所有者活着，则直接把应用放置到首选所有者节点，如果检测到应用设置了反相关性，则反相关性设置会优于首选所有者，故障转移时，在多于1个可能节点的情况下，并不会把相同反相关性的资源放在一起，而是会根据可能所有者列表和内存智能放置策略选择，确保反相关性得到应用。

 通过以上场景，我们可以看出，优先级设置，被应用在群集处理放置策略之前，优先级设置帮助我们确定出应该处理的顺序，然后放置策略会再根据内存智能放置，首选所有者，反相关性，去帮助我们选择每个顺序应用合适的节点，但是内存智能放置，首选所有者，反相关性都只是增强属性，如果群集只剩下最后一个节点，则应用同样会转移到该节点上运行，而忽略遵守内存智能放置，首选所有者，反相关性，如果内存智能放置，首选所有者，反相关性选择出的节点，并不是可能所有者列表，则重新选择，最终放置节点一定要在可能所有者列表才可以放置。

 在群集中，除了手动移动，最佳节点，冷启动，故障转移，还有一种放置行为，即维护模式，也就是计划内维护，什么是计划内维护呢，计划内维护就是我们知道将会发生维护行为，有节点将要宕机被维护，可能是更换硬件，或者处理性能问题，在这种我们知道会发生问题的场景下，我们就可以收到把节点上面的应用迁移走，等到都迁移完成后再进行关机更换配置维护

 而计划外故障则是说，在我们没有预料的情况下，节点忽然因为网络或存储等原因宕机，这时候节点上面的应用会被故障转移走

 计划内维护和计划外故障转移的区别就在于，计划内维护我知道宕机将会发生，那么我们就可以通过最少停机时间的方式，把上面应用都尽可能平滑的迁移走。而计划外故障转移发生时，则会涉及到群集组的离线上线，群集磁盘的重新挂载上线，因此，通常情况下，计划内维护的停机时间会很短

 在以前如果群集本身没有计划内维护的技术，我们需要自己做规划，例如规划周四晚上，我们要针对群集做计划内维护，给节点上配置，那么到了周四晚上，我们就需要手动的移动节点上的资源，确保都移动走了之后，关机上配置，再开机，然后一台一台执行。

 在2008时代群集有暂停模式，我们可以通过点击节点暂停，但是暂停的功能，只会告诉其它节点，我当前置为暂停模式，你们的资源不要迁移到我上面，但仍然需要管理员手动把暂停节点的资源移动走，这在群集更新的场景下特别有用，如果没有暂停模式，我们对节点打补丁还需要担心这时候其它资源可千万不要过来，否则打补丁说不好就重启，故障转移又会有宕机时间，有了暂停模式就需要担心啦，把节点置为暂停模式，手动漂移走上面的资源，就可以放心的对节点打补丁了，这时候其它任何资源在放置的时候都不会考虑到暂停节点

到了2012时代，群集则更加智能，2012WSFC实现了，当我们对节点进行暂停时，不仅可以阻止其它资源放置到当前节点，还可以根据放置策略，评估内存智能放置，首选所有者，反相关性，可能所有者，自动的帮助我们把暂停节点上面资源排水迁移走，同时最小化宕机时间，当我们针对节点进行暂停维护时，针对于虚拟机会执行无停机的实时迁移，针对于群集角色会采用群集组交换的方式，交换群集组所有者，可能会涉及到群集角色短暂的的脱机再联机，计划内维护时只有这部分会出现宕机时间。

实验验证

在本例中老王将为大家呈现一个综合性的实验，当前群集一共HV01，HV02，HV03三个节点工作，上面跑了五个应用，这五个应用的放置策略如下，稍后我会对HV02节点置为维护模式

Test1：首选所有者HV01，因此维护模式后会直接去HV01节点

Test2：首选所有者HV02，HV03，但是可能所有者只有HV01和HV02，因此维护模式后会试图去HV03节点，但发现不是合格可能所有者，而会被移动至HV01

devtestdtc：首选所有者HV01，但因为和devtestdtc2相同反相关性DTC，因此会被移动至HV03

devtestdtc3：未设置首选所有者，因此会被根据内存智能放置策略放置在HV03，但刚放置并不会自动启动

在节点的位置，点击HV02，点击暂停，排出角色，则会按照我们所说的根据放置策略放置节点，如果点击不排出角色，则和2008时代一样，只是宣告当前节点不接受资源的放置，但管理员可以手动移走

我们点击排出角色，可以看到节点首先会被置为正在耗尽

按照放置策略都排出成功会显示已暂停，如果某些角色未排出成功，也会给出提示。

可以看到，群集应用已经按照我们预想的情况被放置

优先处理高优先级Test1虚拟机

处理中优先级虚拟机Test2

处理中优先级角色devtestdtc

Test1虚拟机处理策略

打开cluster log，大家可以看到，对于群集的资源放置，我们已知的概念，内存智能放置，首选所有者，可能所有者，反相关性都被实现成了一个个的filter，当我们要对资源进行维护模式时，实际上HV02会先等待RCM-plcmt组件去根据filter逐条评估各节点放置策略，最终得出结论placement manager result，则RCM把得到的结果返回给HV02维护模式节点，维护模式节点根据RCM-plcmt得出的结论去放置节点

HV01根据RCM放置组件得出，Test1应该直接去首选所有者节点HV01

HV02会等待RCM返回放置结果，收到放置结果后，按照结果进行移动，放置Test1虚拟机至首选所有者HV01

Test2 放置策略

Test2首选所有者设置为HV02，HV03，因此HV02维护之后，它会首先尝试实时迁移至HV03，但是在HV03上面可以看到，由于Test2虚拟机可能所有者只有Node1 即HV01，Node4即HV02，而不能被放置在Node2 即 HV03，因此HV03上面RCM放置组件重新判定Test2应该被移动至可能所有者HV01

HV02收到HV03传回的RCM放置结果，重新决定把Test2虚拟机移动至HV01节点，而非首选所有者HV03

devtestdtc3放置策略

查看clusterlog可以看到，当HV02需要处理devtestdtc3时，首先询问RCM放置组件，应该放置在哪里，经过filter筛选，最终决定devtestdtc3应该按照内存智能放置策略放置在Node2即HV03

HV02收到RCM放置结果，开始操作移动devtestdtc3角色至HV03节点

devtestdtc3会首先被置为不自动启动离线状态，但稍后如果资源充足仍会尝试联机。

devtestdtc放置策略

因为devtestdtc首选所有者为HV01，因此发生故障转移时会优先转移至HV01，但是HV01上面，RCM-plcmt根据filter评估，HV01上面有自定义class即反相关资源devtestdtc2，因此取消放置在HV01的决定，placement manager 最终决定应该放置在Node2即HV03

HV02 收到RCM返回结果，于是操作devtestdtc移动至HV03，在HV03上面可以看到收到HV02的移动请求，接受请求，并且完成执行devtestdtc角色迁移，最终devtestdtc运行于HV03。

当我们完成排除角色后，当前维护节点上面负载为空，且被置为暂停模式，其它节点资源再想移动至维护节点会发现没办法移动

这时候我们就可以针对维护节点该加配置加配置，该打补丁打补丁，不会影响到任何的群集应用

在微软产品体系中，维护模式这个概念贯穿了很多产品，如果通过SCVMM管理了群集，那么可以在SCVMM中对节点进行维护模式操作，如果VMM检测到当前节点属于群集，会按照群集放置策略实时迁移虚拟机，如果VMM检测到当前节点不属于群集，则置为维护模式时会通过快速迁移的方式把虚拟机迁移到其它节点。VMM也可以和SCOM整合，整合之后，如果节点被VMM置为维护模式，则SCOM中也会联动将节点置为维护模式，避免维护期间产生警报，SCOM中的维护模式主要是为了防止维护时警报产生，并不起到实际操作作用，SCCM中我们也可以针对于集合设置维护模式，这样如果我们应用要求必须在指定时间安装，处于维护模式的集合不会安装可以得到延迟。如果SCOM,SCVMM,SCSM相结合，SCVMM置节点为维护模式，SCOM会联动置为维护模式，SCSM如果配置针对SCOM警报产生事件，则不会针对于维护模式而产生事件。真正在维护模式中会把节点上面资源迁移走的只有SCVMM和WSFC群集

当我们维护完成该节点后，通常有这样几种选择，如果你只是要维护这一个节点的话，当你维护它时，应用会漂移到其它节点继续运行，节点维护完成后，你可以选择恢复或不恢复，恢复则意味着把之前漂移出去的应用再漂移回来，不恢复则意味着不需要应用再回来维护节点，你们先在其它节点运作也可以。如果是针对于群集所有节点的维护，老王认为您可以选择恢复角色，这样子可以一台一台的执行维护，维护好了恢复角色，再维护下一台，也可以确保应用还回到原来的节点运作。

在2012WSFC中，故障回复分为两种，一种是维护模式里面的回复，一种是应用自带的故障回复，两者区别是，如果是维护模式里面的故障回复，不论你的应用是否设置了首选所有者，都会被回复到原来的节点上运作，除非检测到应用当前就在首选所有者，则不会移动。如果是应用自带的故障回复，则一定要看首选所有者，如果首选所有者未设定，则不会故障回复。

两者的相同点在于，2012时代中，不论是故障回复，或维护模式回复，对于虚拟机都是采取实时迁移的方式回复，针对于群集角色则采取群集组离线上线移动的方式回复

点击暂停节点 - 恢复 - 则可以看到回复或不回复的选项，如果点击回复，则会把之前该节点运行的应用试图迁移回来，除非检测到应用已经在首选所有者运行，否则都会被移动回来

实际测试老王发现维护模式故障回复是单独的回复机制，和单纯的应用故障回复并不相同，也并不会自动勾选应用的故障回复选项，即便你的群集应用都没有勾选故障回复的选项，维护模式也会帮你恢复的原来的节点上

说起故障回复，这里也许有的朋友没有使用过，不仅仅是2012，在之前的群集中，我们如果点开一个虚拟机或一个群集角色，在属性中都可以看到故障回复的选项，到底什么是故障回复呢，到底要不要故障回复，这在2008时代也是很值得思考的一个话题，那时候群集里面只有一种故障回复，就是当节点发生故障之后，上面应用会被迁移到其它节点，当节点恢复正常后，应用要不要回来

在2008时代，是否故障回复会涉及到应用宕机时间的问题，因为2008时代发生故障时，针对于虚拟机时采取快速迁移的方式，针对于角色也是直接整个群集组离线再上线，本身故障转移的宕机时间就有点长，好不容易转移过去之后已经可以正常提供服务了，你又要故障回复，在2008时代如果设置了应用故障回复，那么应用会再把应用和虚拟机通过快速迁移和群集组离线上线的方式迁移一次，又会有宕机时间，所以在2008时代，应用到底要不要故障回复，除非是粘合性应用，只在原来节点可以工作很好，否则一般我们都不选故障回复，即便选了故障回复，我们通常会进行另外一项设置，即设置故障间隔，选择一个时间段，例如半夜1点到3点，没有用户访问的时候再故障回复，而不是立即回复

在2012时×××始，故障回复的宕机考虑变得不再重要，因为在2012时×××始，针对于故障回复时，虚拟机是采用实时迁移的方式回到原来节点，传统群集组的故障回复时间也得到了优化

在2012R2中，还新增了另外一个属性，即DrainOnshutdown，2012R2中，如果我们是正常关机的节点，那么针对于上面的虚拟机会采取实时迁移的方式迁移走，再进行关机，在过去如果我们维护一个节点时，忘记了暂停模式，直接在上面更新操作，然后关机，虚拟机会采取快速迁移的方式迁移走，产生宕机时间，2012R2则帮我们设置了这样一个保护伞，一旦我们忘记暂停模式，针对于虚拟机也会实时迁移走，除非忽然断电来不及实时迁移，则依然会快速迁移，但还是建议大家维护时使用暂停模式，这真的是一项很不错的功能。

实验验证故障回复

当前所有群集角色都在HV02节点运作，无反相关性设置，无首选所有者设置，但勾选所有应用允许故障回复，立即

直接断电HV02节点，可以看到应用分散去了其它节点上运行

当HV02回复正常时，可以看到，并没有按照我们预想的一样，应用全部故障回复HV02节点，因为我们并没有设置首选所有者，所以故障回复失效！

再次把应用都迁移回HV02，然后设置应用首选所有者都为HV02

HV02再次断电，应用迁移至其它节点

HV02恢复，所有群集应用因为设置了首选所有者，所以故障回复生效，回到HV02节点。

以上老王介绍了群集中的放置策略，维护回复，在群集中放置，维护概念也需要配合仲裁来启动，设想一下，仲裁主要是为了确保群集的可用，当节点发生变化，新增，宕机，分区时，是否影响群集仲裁模型，宕机节点数量是否影响了群集的正常工作，如果只剩下最后一个节点，仲裁失败，我们又需要执行强制仲裁启动起来让群集可用，而我们将的放置，维护，都是在仲裁判定群集可用的情况下才有效果，因此，仲裁和放置是相辅相成的，没有仲裁，群集没办法启动，放置也就没有意义，只有仲裁，但是没有放置策略，群集管理也没有意义。

最后还有一些小菜和大家分享，是老王通过实践得出的一些，关于放置策略和维护的容易被忽略的点

不自动启动到底自不自动启动

老王实际验证发现不自动启动，只在一种场景下生效，即故障转移后，不自动启动应用，不会被启动自动，必须要管理员手动启动

在手动移动，维护模式，维护模式回复，故障回复的场景下，不自动启动会等待高中低级别应用启动完，如果节点还有剩余资源则会自动尝试启动联机！

故障恢复到底回不回复

针对于维护模式排出角色，没有设置首选所有者都会恢复到原节点，如果检测到在首选所有者节点，则不会回复

针对于故障时应用故障回复，按照首选所有者故障回复，如果没有设置首选所有者，不会回复原节点

维护模式不会自动设置应用故障回复属性

反相关性到底反不反

不会反的情况：

维护模式

如果维护前两个反相关性应用都在HV01，首选者设置为HV02，则反相关失效，两个应用都会去HV02

如果维护前两个反相关性应用都在HV01，未设置首选所有者，则根据内存放置策略随机放置，两个反相关性应用仍有几率被放在同一节点

这里关键在于维护模式中，反相关应用需要有参照，如果目标节点上面已有反相关性应用，则不会迁移过去，如果目标节点都为空，则无法参照，反相关性失效。

维护模式故障回复

如果维护前两个反相关性资源都在HV01，首选所有者设置为HV01，置为维护模式后由于内存智能放置仍有几率被放置在一起，如果维护完成后选择恢复角色，则两个应用都会回复到HV01，反相关性失效，因为HV01，当前为空，维护模式恢复没有找到参照

如果维护前两个反相关性资源都在HV01，均未设置首选所有者，置为维护模式后由于内存智能放置随机放置扔有几率被放置在一起，维护完成后选择恢复角色，两个角色都会回复到HV01，反相关性生效，理由同上，维护模式故障回复没有找到参照，即便没设置首选所有者也一起回到原节点

故障转移

如果故障前两个反相关性资源都在HV01，首选所有者设置为HV02，HV02上面当前为空没有参照，则发生故障时两个应用都会转移至HV02，反相关性失效。

如果故障前两个反相关性资源都在HV01，未设置首选所有者，其它节点上面没有可以参照的反相关性资源，群集会根据默认内存智能放置策略评估，两个反相关性资源仍然有很大几率被放置在同一节点

故障转移后故障回复

如果两个资源设置了相同反相关性，相同首选所有者，当故障转移后，需要执行故障回复时，如果首选所有者节点为空，则失去参照，不考虑反相关性，反相关性资源都会回去首选所有者

只剩下最后一个节点时，反相关性失效

会反的情况：

反相关性参照生效

不论是手动移动至最佳节点，维护模式，维护模式回复，故障转移，故障回复，只要检测到目标节点上面有相同反相关性资源，则不会移动至该节点

神奇的跳动

在一些场景下会发生些神奇的事情，例如针对于相同反相关性设置了同样的首先所有者HV02，当前它们都运行在HV01，HV02节点上面资源为空，没有反相关性参照资源的情况下，不论我们执行维护模式，或故障转移，它们都会去到首先所有者HV02。正常来说，不论是维护模式的回复，或是应用自带的故障回复，如果检测到应用当前运行在首选所有者节点，则不会移动回原节点。但是如果是相同反相关资源在首选所有者则不同，当HV01恢复正常加入群集时，或再有其它节点加入群集时，反相关性资源会尝试分散至新节点，但按照正常逻辑来说，已经在首选所有者节点，不应该再有这种尝试，因此老王管它叫做神奇的跳动。

到这里，本篇文章也就接近尾声啦，不知道会不会有能够坚持看到最后的朋友呢，本篇文章中，老王不仅为大家介绍了群集运行放置和维护管理的功能，我们还通过群集日志深入去探索放置执行的底层过程，老王相信，只要是热爱群集技术的朋友看到最后都能够有自己的收获，我们学习技术不仅要学会用，更多时候我们应该去关注Why的层面，当我们执行移动至最佳节点，故障转移，故障回复时，为什么会产生这样的效果，为什么会放置在这节点，这个放置是否是我期望的，我可以通过那些功能控制，知道了解老王介绍的这些技术后，相信您脑袋中会有自己的答案，最终希望通过这篇文章可以让更多朋友知道群集有这些管理功能，有这些思考的地方，也希望能够让对于放置功能已经有所了解朋友能够更加加深一层印象！

彩蛋

当当当当~彩蛋到，嘿嘿，为了奖励看到最后的朋友们，老王特地准备了小彩蛋，在文章开头老王和大家说过，本篇文章主要会围绕群集的运行放置和维护更新来讲，其实放置的部分叫做放置策略似乎更合适一些，但是之所以老王叫做运行放置，是因为放置，只有发生在仲裁判定群集可用时才有意义，只有群集通过正常仲裁也好，强制仲裁也好，整个群集启动起来了可以对外提供服务，才能到达放置这个步骤，因此老王取名运行放置就是希望大家能够明白这个概念

这篇文章中我们涉及了放置策略，涉及了维护模式，故障回复，但是唯独对于更新没有过多的讲解，既然开头已经说了，怎么会不讲呢，于是老王决定在彩蛋中和大家聊聊群集的更新。

如果说您的环境中当前是没有群集的虚拟化环境，或者群集没有使用暂停模式的情况下，在一个理想的情况下，更新流程应该是这样进行的，首先，通过WSUS建立补丁策略，补丁这个东西，老王建议只打系统级别的关键更新，安全更新，定义更新，如果说是Hyper-V服务器，或SQL节点，则针对于应用补丁的下载应该谨慎。

应该建立一套接近生产环境的测试环境，WSUS检测到补丁，首先在测试环境打，测试环境打完如果没问题，再去生产环境打，总结就是WSUS只下载重要的更新，而不要什么补丁都下，最好可以建立测试环境，新补丁先在测试环境通过，再去生产环境打。

如果在2012环境下，流程应该是WSUS测试环境通过，审批到生产环境，节点收到补丁，但是不应该自动安装，应该是通知安装，但是可以推迟时间。如果没有群集的虚拟化环境，可以手动把虚拟机实时迁移走，然后再针对于宿主机打补丁，重启，如果有必要可以实现记录下来节点的虚拟机，迁移走后，维护完成再迁移回来，一切都手动完成。但是在一个理想的环境下，所有虚拟化节点应该被类似于VMM这种VIM系统管理，当做一个整体的资源池来看待，虚拟机去哪个节点都没关系，VIM系统会重新平衡负载。

如果是群集环境下，没有使用群集暂停模式，过程和上面一样，2012时代可以实时迁移把虚拟机资源移走，其它传统群集角色则离线上线群集组，在群集环境中打补丁，存在一个问题，即放置策略带来的隐患，例如，我们当前要对这个节点打补丁，我们只是手动把资源移动走了，但是这时候如果其它节点上面发生放置操作，也会考虑移动到我们打补丁的节点，这时候可能我们打完补丁需要重启，移过来的群集应用又会故障转移，导致产生宕机时间，因此，在2008时代，我们如果要对群集打补丁，或者关机上配置，资源都手动移动走后，把节点置为维护模式，这样其它节点再执行放置策略的时候就不会考虑维护节点，可以放心的进行更新配置了，如有必要，可以记录下节点维护迁移之前承载的角色和虚拟机，更新完成后再手动迁移回来。

大家可以看到，不论是在2008R2群集，还是没有群集的环境，当我们要执行群集更新时，不可避免的要执行很多手动操作，手动把资源都移动走，置为暂停节点，甚至可能还要手动记录下节点之前承载的角色，维护完了再迁移回来，每次要更新对于管理员来也是个不小的麻烦事

在2012时代这些都发生了改变，首先是2012里面的维护模式变了，变得超级智能，置为维护模式，可以自动把资源按照放置策略移走，维护完成后，还可以选择故障回复，再把所有角色漂移回来，既不用手动移动，也不用手动记下来维护节点承载应用了，只要维护时点击维护，维护好了点击恢复就可以了，就这么简单，点击维护后，节点都清空，宣告我是暂停节点，不要迁移到我了，管理员就可以手动应用WSUS测试后审批下来的补丁，更新完成后重启开机，点击恢复，则就会把之前角色再迁移回来，然后再执行下个节点，这里我们要做的，就是手动选择更新，安装有用的更新

最终形态，在2012时代中，群集还新增了一项专门用于群集节点更新的功能，叫做CAU，Cluster Aware Updating，群集感知更新，用一句话来概括它的话老王会说：在保持群集应用持续可用性的情况下，对群集进行补丁更新管理的工具，将08 03时代群集更新的重复性手动工作采用了自动化的方式。

简单来讲，CAU就是一种可以配合维护模式来完成更新的一种群集更新协调工具，大家可以这样以为它，CAU本身并不下载补丁，它的补丁可以可以来自于直接和microsoft同步，WSUS，或SCCM，CAU做的只是协调，和标准化，确保群集更新按照我的协调来完成，完成后我要输出标准的报告。

协调，就是当我们触发CAU维护操作，CAU收到WSUS补丁就会开始按照排水逻辑更新，针对于虚拟机资源都按照放置策略实时迁移走，资源都迁移走后更新补丁，重启检测，是否有依赖补丁未安装，确认没有安装完成，自动执行恢复操作，再把节点之前的负载迁移回来。

可以看到，CAU直接帮我们自动做了三件事 ，自动置为维护模式 - 安装补丁 - 自动故障恢复，之前我们需要手动点一下维护，手动点一下安装补丁，手动点一下故障回复，现在这三下你也不用点了，CAU直接全帮你做了，你要做的就是点一下，开始CAU更新就好了。

CAU的工作模式有两种，一种是老王说的这种，点一下，还是由我们去选择在一个合适的时间节点触发群集进行CAU更新流程， 每次手动触发更新的时候，CAU会随机选择一个节点做协调器，这时候CAU Update Coordinator会暂时驻留在一个节点上，之后群集节点都会按照CAU的指示一台一台的完成更新，维护模式，然后自动恢复。这里手动触发模式关键的点在于，可以由管理员选择一个合适的时间节点更新，可以由管理员仔细核对补丁后再确认触发更新。

另外一种则是采取完全自动化的更新方式，CAU会在群集里面长出来一个VCO角色，由这个VCO角色担任CAU更新协调器的功能，完全自动化的更新方式，你只需要指定一个时间段，剩下的就什么也不需要管了，每次到了那个时间段，CAU就会自动按照排水逻辑去进行更新。

不论是手动触发更新，或是完全自动化更新，都会在完成群集整体更新后生成一份报告，会详细列出执行CAU更新时，是否全部按照CAU的协调流程执行，期望的补丁是否都已经安装，安装过程有那些异常，都会看到，老王认为这个就是CAU的意义所在，可以配合维护模式协调实现持续可用的群集更新，完成更新后也可以输入标准化的报告，既解放管理员双手，也标准化工作，关于CAU老王这里只把涉及到的主要理论进行介绍，我的好朋友ZJUNSEN张俊森，写了CAU实际操作方面很不错的博客，大家感兴趣可以去看。

在微软的更新体系中，可以侦测到当前架构中存在群集，并可以采用排水逻辑实现零宕机的更新方式，目前只有SCVMM 和 CAU ，VMM更新也会采取符合性基线的方式去协调更新过程，逐个排水确保群集可用，其它更新方式WSUS，SCCM，VMST，MBSA则都不会感知到群集，默认情况下都会造成一定的更新宕机时间