WSFC动态仲裁及投票调整2

  OK~ WSFC 2012 R2 年度盛宴开始~ 在本文中，老王将用一系列的场景，把动态仲裁，动态见证，票数调整，LowerQuorumPriorityNodeID，阻止仲裁等群集仲裁技术串起来，完成一个又一个复杂的场景，本篇文章可能并不太适合对于WSFC不了解的朋友，适合对于WSFC群集仲裁技术及2012动态仲裁技术有必定初步了解的朋友，若是您还不了解WSFC，建议您去先看下老王写过的博客，或者其它地方相关的资料，若是您对于WSFC仲裁，动态仲裁技术已经有了初步的了解，相信跟着老王这篇文章中的场景会帮助您更加深刻的理解群集投票，动态仲裁等知识，话很少说，咱们如今就开始，跟着老王上车吧，过山车开了~滴

 

 开始以前先介绍环境，为了准备此次的博客，老王一共开了七台虚拟机，主要是为了重现一些真实的分区场景，以前在2008R2的时候，咱们用了六台服务器，两边各两个节点，一台域控+ISCSI，一台路由服务器，可是只有一侧有域控，另一侧没有域控，所以发生分区时，没有域控的一方是没办法上线联机抢夺群集的，虽然效果是同样的，最终两端出现分区，群集都没法使用，咱们强制选择其中一方启动，在此次的环境里面老王特意用了七台服务器，两端都有域控，均可以造成群集的一个场景

  环境介绍

  北京站点

   HV01

   MGMET：80.0.0.2  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20 

   ISCSI：90.0.0.2

   CLUS：70.0.0.2

   HV02

   MGMET：80.0.0.3  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20

   ISCSI：90.0.0.3

   CLUS：70.0.0.3

   BJDC&ISCSI

   Lan：80.0.0.1 GW：80.0.0.254

   ISCSI：90.0.0.1

  佛山站点

   HV03

   MGMET：100.0.0.4  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.4

   CLUS：70.0.0.4

   HV04

   MGMET：100.0.0.5  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.5

   CLUS：70.0.0.5

   FSDC

   Lan：100.0.0.20 GW：100.0.0.254

 Router 

   

    03Route

    Beijing:80.0.0.254

    Fuosha:100.0.0.254

 

   首先咱们先来看一道开胃小菜，在这个场景中咱们将模拟，一个四个节点的跨站点群集，在见证磁盘始终在线的状况下节点逐个宕机的场景，如下是老王已经组建起来的一个多站点群集，其中的群集名称和群集IP，可能在后面的图会变，由于实验过程当中老王拆了又建了几回群集，不过其余架构都按照规划好的不会改变。

能够看到咱们在群集中跑了一个DTC应用，当前DTC应用绑定了两个IP地址，它们之间是OR关系

  

   在多站点群集的设计规划中有不少须要考虑的地方，例如存储复制，网络检测，加密处理，AD的同步，DNS的缓存等都会影响到多站点的故障转移时间，后续会单独写博客来详细讲，这里简单讲两个影响客户端直接访问的地方

   默认状况下在多站点群集中，例如咱们的DTC应用当前在北京站点运行，它的联机地址会是80.0.0.89，当它转移到佛山站点，联机地址会是100.0.0.89，可是这时候，客户端能不能访问DTC服务呢，不必定

    设想一下，北京和佛山站点作了AD多站点，它们的DNS会相互同步，当DTC在北京站点时它是80.0.0.89，通过一段时间它同步到了佛山站点，佛山的DNS也知道了DTC是80.0.0.89这个地址，那么当北京站点宕机，转移到佛山站点了，虽然这时候DTC应用已经联机，可是当客户端访问DTC，会返回80.0.0.89这个地址，并不会返回100.0.0.89的可用地址，这也致使了停机时间的延迟

    缘由是由DNS的缓存机制致使，默认状况下群集应用联机后注册的主机记录都是会有1200秒的TTL，便是说，客户端若是请求了这个VCO的主机记录，1200秒之内，不会再从新请求了，会使用缓存中的地址

    2008时代WSFC新增了用于多站点的HostRecordTTL属性，使咱们能够设置VCO记录注册到DNS时的TTL，TTL生命周期如今能够进行缩短，微软建议缩短为300秒，即五分钟以后从新请求DNS新的地址

    打开佛山站点的客户端，输入ipconfig /display能够看到被缓存的VCO记录和生存时间(TTL)

    

   另一个2008时代新增用于多站点的属性则是RegisterAllProvidersIP，正常状况下，咱们的VCO即便你设计了多个地址，它们默认会是OR的关系，即始终只注册一个群集IP地址，当前在北京站点就是80网段的地址，当联机到佛山站点，则会有CNO替VCO去注册更新成100网段的地址，同一时间VCO默认只有一个站点的地址在线，经过RegisterAllProvidersIP属性咱们可让CNO去帮咱们注册全部的VCO地址，可是这就要求群集应用支持地址重试

   一个完美的场景应该是群集应用默认链接到80网段的地址，当80网段不可用，自动重试链接到100网段联机使用，由于全部地址都已经注册至DNS，因此能够减小因为DNS缓存致使的停机时间，在群集应用支持自动重试的话，可使用这个属性 ，SQL Server 2012开始支持在链接字符串加入MultiSubnetFailover=True参数和RegisterAllProvidersIP配合使用，当链接其中一个地址不通，会自动链接另一个

 

这里咱们遵循微软的建议，配置DTC应用的HostRecordTTL为300

设置方法以下

#获取群集应用资源名称 

Get-ClusterResource | Select Name, ResourceType

#获取群集应用资源属性

Get-ClusterResource "devtestdtc" | Get-ClusterParameter

#修改HostRecordTTL属性，脱机再联机能够看到设置已经生效

Get-ClusterResource "devtestdtc" | Set-ClusterParameter HostRecordTTL 300

辅菜说完，下面来看咱们的正菜，能够看到目前咱们是四个节点的群集，见证磁盘能够正常参与投票

#查看节点投票数

Get-ClusterNode | ft ID, NodeName, NodeWeight, DynamicWeight, State -AutoSize

#查看见证投票数

(Get-Cluster).WitnessDynamicWeight 

这两个命令后面咱们会常常用到

当前群集DTC正常运行在HV01

咱们直接将HV01进行断电操做，能够看到群集应用自动转移至HV02，HV01已下线因此去掉了它的投票，同时因为如今是4票，因此自动去掉了见证磁盘的一票，始终保证投票数为奇数。

直接将HV02也断电，咱们完全失去了北京站点，能够看到如今又自动加上了见证磁盘的一票，如今群集仍是三票，我直接强制DNS服务器更新，而后在客户端ipconfig /flushdns了，此时再尝试联devtestdtc则会返回100网段的地址，若是不清除DNS缓存，能够等300秒时间到了，再次请求自动更新至100网段

DTC当前在HV03上面运行，咱们再把HV03也断电，如今群集只剩下HV04，能够看到如今群集会显示三票，但其实已经不重要了，由于咱们只剩下一个节点，他能够和见证磁盘联系，所以能够存活至最后。

以上是咱们的第一道小菜，怎么样，还算简单开胃把，能够看出在见证磁盘在状况下，群集节点逐步宕机，WSFC2012R2会始终动态的调整群集投票，确保群集投票始终是奇数，即始终一方能够存活，最后能够只剩下一个节点和见证存活。

接下来咱们来模拟第二个场景，北京站点和佛山站点的管理网络失去联系，即80网络和100网络不通，咱们直接关掉路由服务器，为了防止其中一方联系到见证磁盘获胜，咱们也模拟见证磁盘失去联系

这时候咱们能够看到，群集检测到见证磁盘失效，已经自动调整三个节点投票数为奇数

另外能够看到咱们把管理网络断开了，群集依然能够正常工做，为何呢，由于群集内置的网络拓扑生成器会实时自动生成调整全网检测的拓扑，管理网络既能够对外访问也能够作心跳检测，心跳网络只能够作心跳检测，所以只要不影响群集节点之间心跳检测，是不会有任何反应的。

 

群集并不会知道你的管理网络故障，由于在北京站点管理网络能够正常访问，在佛山站点管理网络也能够正常访问，群集就觉得它是好的，心跳检测还有其它卡能够进行嘛

  假设如今这家公司的员工都从佛山出差来北京办公，即全部的用户都要在北京80网段的客户端访问，可是若是这时候群集DTC突然漂移佛山去了，虽然它在佛山也能够正常工做，可是北京站点的用户都访问不到那边，由于咱们知道佛山站点100网段已经和外界失去联系

   默认若是不作调整群集应用，DTC是应用是随机漂移的，不必定会漂到那个节点去，可能看那个节点内存多，它就过去哪里了，一旦漂到佛山站点的服务器就惨了

   这时咱们能够经过如下手段进行控制，首先设置DTC的习惯节点为HV01，HV02，这样若是当前DTC托管在北京，当它发生故障转移的时候，会优先考虑转移到HV01或HV02

   可是仅仅设置首选全部者仍是不够的，由于设置首选全部者，只是在没有发生分区的状况下会有用，当发生了一个网络分区，HV01 HV02没办法与HV03 HV04联系，这时因为HV01没有投票数，而HV03 HV04一方有投票数，因此应用仍是会转移到佛山站点运行

   应对这种场景，咱们能够完全去掉HV03，HV04站点的投票数，这样作了以后，即使发生一个网络分区，北京站点剩下一票，佛山站点两票，但由于咱们去掉了佛山站点两台服务器的投票数，因此佛山站点会尝试造成群集，可是始终是没办法成功的，由于他们没有合法的票数。

   便是说咱们经过手动去掉投票数，让佛山的两个节点永远也没办法造成群集，要否则就访问北京的节点，北京的节点一旦没法启动，群集应用就中止访问或强制启动。

#手动去掉群集投票数

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

在2008和2008R2中能够经过添加一个Hotfix来得到手动控制节点的投票的功能，2012及以后则WSFC自带

   以上是手动调整群集投票数的场景之一，即咱们知道一方的站点已经没法对外提供访问服务，须要让该站点始终中止对外服务，直到网络恢复再从新赋予投票数

   手动调整投票数老王认为是颇有用处的一项技术，除了这种已知站点没法对外提供的场景，在其它不少场景下也都有用武之地

   例如在一个彻底手动故障的场景，有北京，天津，河北三个站点，只有北京站点的节点有投票，手动取消了天津和河北的投票，由于当故障发生时，可能要举行一个灾难恢复会议，商讨一下，当前由那个站点继续承担群集更合适，例如商讨天津站点当前更合适承担群集，手动赋予天津站点节点票数，节点检测到当前有投票，因而天津站点启动造成群集，继续对外提供服务

   或者还有一个场景，假设当前有北京站点，河北站点两个站点，两个节点各有两个节点，当前群集一共四个节点，我手动去掉了河北站点其中一个节点的投票，让它始终不参与群集投票，这时假设群集发生了故障，北京站点和河北站点的三个节点都已经没法启动提供服务，咱们能够强制启动去掉投票的节点，从新赋予它票数，让它继续对外提供服务，或者北京站点宕机，强制仲裁后全部业务都跑到河北站点的一个节点运行，已经把机器的负载跑满，这时候能够把去掉投票的节点从新赋予投票，一块儿承担负载，这样做为一个灾备节点来使用。

    接下来咱们假设当前群集是动态仲裁，群集见证磁盘先失效，继而管理网络也失效，心跳网络也失效，出现一个分区时的场景

   针对网络分区，咱们到时除了把路由服务器关了，也把HV03 HV04的心跳网卡直接改了个网络

    针对见证磁盘失效，咱们仍是依旧采用直接ISCSI上面禁用磁盘的方式，能够看到大概过了30秒左右，仲裁检测到了见证磁盘已经处于非联机状态，因而自动去掉了它的票数，同时也随机去掉了一个节点的票数，如今群集变成了三票

仲裁磁盘会按照故障转移策略，在各个节点尝试联机挂起

都尝试失败后会显示为失败状态，过一段时间会在尝试联机挂起，但始终不会成功

能够看到如今因为见证磁盘失败，仲裁已经动态的调整了投票数，又随机去掉了一个节点的投票数，如今群集仍是奇数三个投票

  若是这时一个网络分区发生，北京站点与佛山站点没办法心跳检测，没有网卡能够用于检测，这时候佛山的站点会获胜，继续对外提供服务，而北京站点则会关闭

  由于北京站点被选中去掉了一个投票，只有一票，而佛山站点有两票，因此佛山站点能够造成群集，造成群集后佛山站点又自动去了一票，如今佛山站点也是奇数投票数

  你们能够看到，这里的核心在于，群集选择去掉那个站点的投票，被去掉投票的站点，当发生投票时会被关闭，默认状况下群集会根据各个节点的状态变化，网络监测状况，不断的去调整票数，每次都会随机选择去掉投票站点的节点是谁，这有点像是每次都要随机抓一个倒霉蛋，反正都是抓，那么咱们可不能够控制每次固定抓一我的呢，答案是能够的

  经过2012R2里面新增的LowerQuorumPriorityNodeID属性，咱们能够控制在偶数节点下，让动态仲裁始终去掉指定节点的投票，实现当发生50/50网络分区时始终是咱们想要的站点获胜，或者在两个节点的状况下，最终动态仲裁要随机去掉一个节点的投票，咱们也能够根据状况事前指定，始终去掉指定节点的投票。

#查看当前LowerQuorum节点，默认是0，即每次发生变化时随机调整

(Get-Cluster).LowerQuorumPriorityNodeID

 #获取节点ID，手动设置每次偶数投票数时丢弃HV04节点投票，每次都确保北京站点获胜

(Get-Cluster).LowerQuorumPriorityNodeID=3

当再次发生网络分区时能够看到，佛山站点关闭，北京站点存活下来，并自动调整为奇数投票

群集应用也始终正常运行着

以上为老王给朋友们上来的第二道菜和第三道菜

    第二道菜咱们在一个已知站点故障的状况下，手动取消了该站点的投票，阻止应用迁移到上面提供服务，这里咱们是假设的一个没有分区的场景，由于两端仍是能够经过心跳网卡互相作心跳检测的，咱们在北京站点设置取消佛山站点的投票，佛山站点是能够知道的，若是是心跳网卡也发生了故障，即两边没办法进行进行心跳检测，这时候就要分状况来看，若是分区以前咱们已经设置好了取消投票的站点，那么很好，群集会选择没被设置取消投票的站点启动，若是已经出现分区以后，那么只有强制启动须要的少数站点，启动以后再设置取消另外站点的投票，当另外站点上线时会以强制仲裁方为主。

    第三道菜呢，默认状况下在见证磁盘失效的动态仲裁场景中，当发生偶数投票节点的状况下会动态随机为咱们去掉一个节点的票数，咱们能够经过LowerQuorumPriorityNodeID属性来手动降低一个站点，确保当中间网络分区发生时，始终是本身想要的站点获胜

   所以你们能够看出，在动态仲裁存在的场景下，咱们几乎不多会用到强制仲裁，由于咱们有不少新的技术能够选择，例如LowerQuorumPriorityNodeID，事前手动调整投票数，强制仲裁在一些场景下也或许有用，尤为是2012R2以后，阻止仲裁技术发生了改变，多数节点一方检测到少数节点一方存在仲裁会自动执行阻止仲裁操做，即确保认可强制仲裁一方为群集，与其群集数据库同步至最新后，才会启动自身群集服务，在以前2008时代，若是遇到强制仲裁的场景下，大多数时间都须要手动去执行阻止仲裁，不然会出现群集数据库覆盖等状况，到了2012R2则会自动帮助咱们作这件事

   因此老王给你们的建议是，按照场景选择合适的技术，能经过手动调整投票解决或者经过LowerQuorumPriorityNodeID解决就尽可能不用强制仲裁，2012R2以前使用强制仲裁须要考虑阻止仲裁问题，2012R2不须要考虑。

   实际上在动态仲裁启动的状况下，绝大部分场景动态仲裁都能帮助咱们保证群集的可用性，始终让群集保持奇数投票，即使动态仲裁默认选择的站点你不满意，也能够用LowerQuorumPriorityNodeID，票数调整，强制仲裁等技术切换到满意的站点，像是之前50/50的脑裂分区场景，在动态仲裁的状况下是很难见到了，所以若是想看到脑裂场景最好的办法就是关闭动态仲裁

    在第四道菜中，咱们将模拟一个脑裂场景，北京佛山两个站点，关闭动态仲裁的状况下，禁用见证磁盘，两端出现网络分区时心跳网络和管理网络都已关闭，没办法进行站点间心跳检测

     

#确认群集动态仲裁状态，默认为1，修改成0

(Get-Cluster).DynamicQuorum = 0

紧接着咱们触发网络分区，修改HV03和HV04心跳网卡为其它网段，而后暂停路由服务器，让两端管理网络和心跳网络都不能互相作站点间的心跳检测，可是在各自站点内又均可以正常和AD通讯

这时打开各个节点上面能够看到日志，提示群集网络已分区

运行查看投票数节点命令，能够看到当前全部节点，都在各自站点尝试造成加入群集

可是这种状态仅维持不到20秒，再次运行命令就会看到群集服务已经中止

在每一个节点的事件管理器均可以看到关于群集服务中止的系统日志

可见当出现脑裂分区时，群集会出现短暂的争夺阶段，紧接着群集仲裁会检测到当前发生分区，以后会关闭全部群集节点，老王并无看到网上说的发生仲裁时各个分区各自生成群集，而后争夺写入群集磁盘的场景，或许时间过短了没有看到，或许是2012开始针对于脑裂分区作了优化，检测到脑裂会自动关闭，不过老王实际看到的效果就是这样，我感受这样都关了也好，谁也别抢，让管理员手动选择

假设这时管理员断定当前权威站点应该是北京站点，手动在HV01上面执行强制启动命令

#强制启动HV01

net stop clussvc

net start clussvc /FQ

HV01上面首先运行查看节点投票数命令，首先会看到HV01的投票，紧接着HV02因为和HV01是一个分区内，检测到这一方发生强制仲裁，他会优先融入进来，状态会先是Joining，最终变成Up

实际上在这一步的时候，老王是但愿看到一个东西的效果，什么呢，就是阻止仲裁的效果，老王在10/90这种比例下，强制仲裁了10的一方以后，当剩下的90网络联机以后，能够在日志看到阻止仲裁的日志，可是在50/50比例下，当各节点网络恢复正常后，老王没看到这个日志

可是当老王尝试用命令查看节点阻止仲裁状态的时候却能够看到

#查看各阻止仲裁状态 1表明节点目前须要阻止仲裁，0表明节点当前不须要阻止仲裁

(Get-ClusterNode -Name HV02).NeedsPreventQuorum

(Get-ClusterNode -Name HV03).NeedsPreventQuorum

(Get-ClusterNode -Name HV04).NeedsPreventQuorum

能够看到节点2已经去掉了阻止仲裁的状态，3和4节点仍须要阻止仲裁

什么是阻止仲裁呢，在上面老王也提到过一点，阻止仲裁简单来说，就是让其它节点遵照强制仲裁分区的技术，咱们用强制仲裁以后，会把强制仲裁节点的paxos标记提至最高，即成为群集内最权威的存活节点，大家其它全部节点的群集数据库都要以个人为准，阻止仲裁就是为了配置强制仲裁的这个目标，当其它节点网络连通后能够和强制仲裁节点通讯，节点会检测到当前环境内存在强制仲裁的节点，我应该以他为首，我不该该造成群集，即便我是多数节点的一方，而后群集服务会暂时中止，直到能够阻止仲裁节点的群集数据库彻底和强制仲裁一方同步一致以后，才能够从新加入强制仲裁启动节点造成的群集分区

在2012R2以前，遇到阻止仲裁的场景，尤为是10/90场景，你强制启动了少数，是须要手动在其余站点执行阻止仲裁的，2012R2开始支持这种检测到强制仲裁，自动阻止仲裁。

能够看到当佛山节点恢复和北京站点通讯后，通过一段时间，节点的阻止仲裁状态也变成了0，而且正常上线加入了强制仲裁方造成的群集分区

最后一道菜咱们来尝试一个反转性的场景，假设当前北京站点有1个节点，佛山站点有3个节点，佛山站点发生了网络故障，虽然佛山内部三个节点能够通讯，可是它们没法对外提供服务，咱们须要强制反转至北京节点提供服务，本场景见证磁盘禁用，群集启用动态仲裁

#从新启用群集动态仲裁

(Get-Cluster).DynamicQuorum = 1

修改HV02为100.0.0.3，网关为100.0.0.254，DNS设置为100.0.0.20 80.0.0.1

#从新注册网卡DNS记录

ipconfig /registerdns

确保两个站点的DNS上面都记录了HV02的新地址

直接将HV02 HV03 HV04三个节点的群集网卡都改到同一个网络，而后暂停路由服务器

这时候在HV01上面运行查看群集节点投票数的命令能够看到群集服务已中止

若是在HV03上面运行查看群集投票的命令则能够看到当前群集已经在佛山站点顺利造成，由于这边占据多的投票数，因此北京站点的群集目前会被关闭

#使用命令强制仲裁启动北京站点的群集

net stop clussvc

net start clussvc /FQ

启动完成后能够看到，在北京站点如今能够看到群集节点投票状态了，同时也提高了paxos标记，更新HV01的群集数据库为最新

因为HV02 HV03 HV04尚未和HV01联网，没办法知道北京站点那边发生了强制仲裁，因此还会尝试造成群集，在HV03上面查看群集投票状态，能够看到仍是旧的记录

这时咱们在北京站点上面须要作一件事，因为如今北京站点和佛山站点依然均可以访问存储，因此当应用在北京站点联机的时候，可能会出现失败的状况，由于佛山有三个节点也在和我抢群集磁盘，因此当务之急是取消掉佛山站点的投票数，防止和北京站点抢占资源

#手动取消佛山站点节点投票数

(Get-ClusterNode -Name hv02).NodeWeight = 0

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

须要注意的一点，这里若是须要执行去掉节点投票的操做，必定要在强制仲裁方进行，由于一旦在多数节点方执行，当再次网络通讯的时候也会被强制仲裁方的记录盖掉，不会生效。

以后咱们再次将群集应用联机，能够看到这时候实际上HV01已经从佛山站点抢夺过来了群集磁盘，佛山的三个站点再也没办法抢占群集资源，由于群集磁盘已经在权威一方从新上线，如今群集应用能够始终在北京站点运行

当佛山三个站点网络修复完成后，试图加入北京站点的群集分区时，能够在日志中看到阻止仲裁的日志，目前节点状态不会是UP，只有当佛山三个站点认可北京站点为权威一方，而且群集数据库已经和北京站点同步一致后，才能够正常加入群集。

通过一段时间后，能够看到佛山节点已经都完成阻止仲裁，正常加入群集，最后咱们再从新为佛山节点赋予投票，让佛山节点能够正常参加故障转移，赋予投票后，群集仲裁会检测到当前恢复四个节点，又将根据动态仲裁机制自动选择节点去掉一票，实现始终奇数投票。

以上为老王经过实践得出的一点经验之谈，写这篇文章时老王的愿景是经过不断的实验把动态仲裁，动态见证，票数调整，LowerQuorumPriorityNodeID，阻止仲裁这些技术反复验证实白，而后经过场景的形式尽量形象的讲出来，告诉朋友们具体都是什么样的功能，应该如何使用，但愿可以用更多的人知道2012R2群集的这些技术，愈来愈多的人来真正的使用群集，研究群集，群集毫不只是一根心跳线，一个存储，把节点连起来就完了，里面不少东西都值得咱们花心思去研究，用心去研究技术，天然会找到乐趣。