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则都不会感知到群集，默认状况下都会形成必定的更新宕机时间