WSFC 仲裁模型选择

今天咱们再来详细讨论下关于WSFC的仲裁模型，主要仲裁模型的优缺点，应该如何去思考选择最佳合适方案

WSFC引入仲裁，主要有两个目的

1.   跟踪群集当前运做票数是否符合仲裁模型协定，若是低于最少容许节点，则决定关闭群集（2012以前）

2.   当发生分区时，确保由多数一方负责接管群集提供服务，少数票数方将关闭

回顾一下历史，在2003时代以前，群集只有一种仲裁模型，即仅磁盘仲裁，在这种模型下，只有磁盘见证会存放群集数据库，全部节点启动前必须可以联机到磁盘见证获取群集数据库才能够启动，当发生分区时，那一侧能够联系到磁盘见证，则获胜，若是在全部节点都正常链接到磁盘见证的状况下，群集能够支撑到最后一个节点，可是在此模式下磁盘见证成为单一故障点，一旦磁盘见证失联，群集将关闭，由于仅有磁盘见证有决定群集是否存活的资格，那时候还没投票这个概念，只要磁盘见证在，群集就能够存活

后来2003时代 开始，MSCS在企业版和数据中心版引入了多数节点集，MNS仲裁模型，这种模型的好处是去中心化，可让每一个群集节点本地磁盘也可以存放群集数据库，这样就没必要每次每次群集启动都必需要联系见证磁盘，经过MNS仲裁模型，能够容许群集大部分节点存活，每一个节点均可以有决定群集是否存活的资格，即后来多数节点仲裁的前身。

2003 SP1时代 开始，群集引入了文件共享见证机制，为了解决两个节点MNS仲裁模型下，任何一个节点宕机，都将致使群集关闭，那时引入的文件共享见证和后来的同样，文件共享见证最开始就不包含群集数据库，仅起到一个投票的做用，当群集当前MNS模型，两节点加一个文件共享见证，一个节点宕机，另一个节点能够联系到文件共享见证，就能够存活，由于获取到了多数节点资格，另外也能够阻止脑裂，当两个节点发生分区，都试图争夺资源时，那一方能够联系到文件共享见证便可以获胜维持运行。

从2003SP1推出功能开始，你们就开始在尝试在MNS仲裁模型+FSW见证上面部署各类群集应用，当时用的最多的是2003SP1+EX2007 CCR，随着使用，你们意识到了一个问题，个人FSW共享见证依然是个单一故障点，能不能有什么机制可让这个文件共享也高可用，由于默认状况下，一个理想的场景应该是有第三台服务器，非群集节点的服务器来承担文件共享，其实就是在上面跑一个共享目录，并不占用什么系统资源，可是一旦这台服务器宕机，那我群集运做就又没了保证，因而你们开始想办法维持FSW服务器的高可用，通过实践你们一致认为可行的方案，只有作fileserver cluster，（若是到2012时代应该是传统群集文件服务器，而非SOFS），可以维持FSW的高可用，也有人试图使用DFS，可是后来你们发现了弊端，其主要缘由在于，DFS的意义在于逻辑的屏蔽物理层，例如，对MSCS提供了一个DFSN路径，可是复合组呢，是两个站点各自的DFSR服务器，而后每一个站点又各自有一台群集节点，当发生分区的时候，每一个站点均可以访问到文件共享，仍是会出现脑裂分区的问题，由于投票资格仍是一致的，由于DFS全部节点都是AA的，又有这种站点感知设计，因此它并不适合群集FSW，FSW须要的应该是一个同一时间，只有一个共享服务器提供服务，且发生灾难时可以决出分区胜者的。

不过虽说是这样说，可是真真正正在企业里面专门为了群集文件共享见证而作一个file cluster的仍是少见，但这确实也应该是一个考虑点，若是企业里面有几十套群集，那么何尝也不可专门部署一套file cluster提供高可用的文件共享见证，一般国内若是单台构建文件共享见证，会在DC，DHCP等稳定的服务器进行构建，或单独构建服务器。

到了2008时代，群集从MSCS变成了WSFC，仲裁模型也有了新的变化，首先是引入了投票这个概念，把投票引入了群集仲裁管理器，每一个节点和见证都多了一个投票的属性，群集的存活和分区处理开始由投票数决定，虽然机制和2003相似，都是维持多数，可是变的更为明朗，把之前看不见的东西拿了上来。2008开始仲裁模型分为四种：仅磁盘，多数节点，多数节点加见证磁盘，多数节点加文件共享，2008时代强制仲裁这一功能也发生了改变，在2003时代若是要执行强制仲裁，须要在群集关闭的状况下执行，而且须要给定强制启动节点列表，2008开始能够在群集开启的状况下执行强制仲裁，另一点，2008时×××始各个节点和群集见证磁盘均可以存放群集数据库，并且见证磁盘并不是单一故障点，每一个节点的群集数据库都是最新的，见证磁盘群集数据库不是最新也能够和其它节点进行同步，这点很是重要。

2008时代虽然引入了四种仲裁模型，但其实2008时代的仲裁仍是比较死板，依然主要强调群集节点存活必须符合仲裁模型最少节点协定

例如，若是是奇数节点，选择多数节点仲裁，须要存活至 (节点票数)/2+1，即3节点必需要有两个节点存活。若是奇数节点选择磁盘见证或文件共享见证，则一样智能坏掉一个节点，并不会由于多出见证一票而容许存活至最后一个节点，缘由是若是3节点加磁盘见证，则为4票，一样算法除袭来仍然必需要三票存活，宕机一个节点后，见证一票加节点两票已到极限。

若是偶数节点，选择多数节点+磁盘见证或多数节点+共享见证，在见证设备在线的状况下能够存活至半数节点，若是见证节点不在线，或采用多数节点仲裁，则须要存活 （节点票数/2 )+1，便是说四节点多数节点，至多只能宕机一台

所以在2008时代选择群集仲裁模型基本上是固态的，若是你但愿群集可以尽量多的时间提供服务，那么若是你是奇数节点就选择多数节点仲裁，偶数节点就选择多数节点加磁盘见证或文件共享见证，偶数节点不能选多数节点，奇数节点不能选见证设备，不然就会浪费一个节点

到了2012时代 开始这种固态的仲裁思惟被打破，群集开始没必要遵照仲裁模型的最少节点协定，而是能够动态调整节点的票数至最后一个节点，微软于WSFC 2012引入了动态仲裁功能，即动态调整各节点票数，举个例子，若是5个奇数节点，宕机一个节点后，群集会再去掉一个节点票数，确保群集为3票，再宕机一个节点，正好是3个节点则不作操做，若是是剩下两个节点，则随机去掉一个节点的投票，在正常关机，或非票数节点宕机的场景下，能够存活至最后一个节点，若是票数节点宕机来不及交换投票，则群集关闭，所以2012动态仲裁存活至最后一个节点的概率为百分之66。偶数节点一样，若是四节点，群集会上来就动态仲裁去掉一个节点的投票，宕机一台再去掉一票，存活至最后一个节点的概率为百分之66。

经过动态仲裁始终让群集维持奇数投票，从2012开始，群集再也不维持多数，而是维持奇数，仲裁的目的更多的是帮助咱们存活至最后一个节点，避免脑裂分区

若是咱们在2012时代选择配置为偶数节点+见证设备，那么在见证设备在线的状况下，群集能够存活至最后一个节点，见证设备脱机，则能够存活为(节点票数)/2+1

若是咱们在2012时代选择配置为奇数节点+见证设备，在宕机一个节点+见证设备脱机的状况下，群集将关闭，例如群集当前三节点，1个节点和见证设备宕机，则群集会由于剩下两个投票，没法决出胜者而关闭，所以，2012时代奇数节点仍是要使用多数节点仲裁模型，2012奇数节点并不会由于见证设备而带来存活优点

到了2012R2时代，WSFC动态仲裁的基础上又演变为动态见证，即群集始终建议配置磁盘见证或文件共享见证，由于见证设备能够动态的调整票数，例如3节点+见证磁盘，群集会自动去掉见证磁盘的一票，如今群集是三个投票，若是坏掉一个节点，群集是2个投票，群集会自动再加上见证的一票，如今群集又是三票，仍是奇数，这时候若是再坏一个节点，还剩下最后一个节点和见证，群集依然能够存活。便是说，只要群集见证设备设备，不论当前是奇数仍是偶数节点均可以存活至最后一个节点，总之始终为群集配置一个见证设备就对了。

以前说过2012开始引入动态仲裁功能，能够在偶数节点的状况下，自动去掉一个节点投票，始终维持群集为奇数票数，2012R2开始能够经过LowerQuorumPriorityNodeID属性指定，始终去掉那个节点的票数

例如，我偶数节点四个节点，分布在两个站点，那么我就能够指定群集自动去掉备站点一个节点的投票，这样备站点仅剩下1票，主站点2票，若是两个站点发生分区，则主站点直接获胜，若是主站点所有宕机，备站点也有百分之66的概率能够直接接管。在2012R2以前，一般咱们会手动直接去掉备站点节点的票数，已达到此效果，可是只有2012是有百分之66的概率备站点能够自动接管，2012以前都须要手动强制启动备站点接管。可是也有一些企业会故意设计成手动故障转移这种架构，缘由是群集上层跑的应用故障转移时间太长，故障转移以后还须要执行一些操做应用才能提供服务，这种状况下适用于手动故障转移。

虽然2012R2说的很好，群集能够存活至最后一个节点，可是这句话有一个前提，见证设备在线的状况下，一旦见证设备脱机，群集变成百分之五十存活至最后一个节点，这个实验老王前面的文章已经作过，当前群集宕机至3节点+见证设备，若是这时候见证设备和一个节点宕机，群集并不会自动调整投票，仍是2个节点+1个见证投票，但其实这时候应该自动从动态见证切换至动态仲裁，3票变1票，但群集没变，若是变了还能够百分之66存活至最后一台，但没变，没变的话，若是剩下两个节点，任意一台宕机，则群集关闭。

这里关键的问题仍是3剩2的时候，一个节点和见证设备脱机，群集不能从动态见证切换至动态仲裁，致使群集仲裁不许，其实这时候群集应该是先变成2票，而后再动态仲裁去掉1票，可是群集没有，没有自动调整失败的见证票数，也没有调整节点的票数，致使的结果就是两个节点任意一个宕机，群集关闭。

2012是奇数节点加见证设备，见证设备和节点脱机，一旦群集变成2节点偶数投票，群集会直接关闭

2012R2是当剩下奇数节点+见证设备，见证设备和节点脱机，一旦群集变成2节点偶数投票，坏掉任何一个节点，群集都会关闭。

说到底，都是见证设备脱机后不能切换为动态仲裁的缘由

所以2012R2时代见证设备特别重要，只有见证设备在(各个群集节点能够访问)，才能够存活至最后一个节点

OK，咱们从WSFC仲裁岁月的小河终于说到了近代，在这条漫长的小河中，曾出现过一个激流，这个激流至今也影响着WSFC，它就是群集数据库

2008时代 开始WSFC群集数据库引入了paxos机制，群集数据库在各个节点同步，每一个节点均可以对群集进行更新，其它节点会跟随最新修改的节点进行同步，跟随过程主要对比paxos标记，发现对方的比个人新，则与之同步，群集数据库除了在各节点记录群集信息一致性用于故障转移，也用于群集服务启动检查，每次节点群集服务启动时都会检查自身的群集数据库是否为最新，是否和其它节点一致，若是非最新，则须要和其它节点同步后才能上线。

须要注意的是若是群集使用了见证磁盘，则各节点同步后也会把群集数据库同步至见证磁盘一份，见证磁盘的群集数据库会在磁盘所在节点被加载。仅磁盘见证里面会有群集数据库，而共享见证和2016云见证里面，仅记载着当前群集最新paxos标记是多少。

当出现一个时间分区的场景时就能看出究竟那种仲裁模型更优秀

时间节点1 节点1 节点2 文件共享在线

时间节点2 节点1宕机

时间节点3 节点2修改群集数据

时间节点4 节点2宕机

时间节点5 节点1启动

若是使用的是文件共享见证，这时候节点1会由于当前节点没有最新的群集数据库而没法启动，群集启动时和文件共享里面的paxos标记对照，发现为旧，则群集成员管理器阻止该节点启动，这时候只有等待节点2开机后，节点1才能够与其同步群集数据库后启动，若是不等待节点2开机，强制在节点1启动，则节点1的群集数据库将会被提高为黄金副本，节点2启动后会被节点1的黄金副本覆盖，致使以前修改的群集数据丢失，云共享见证一样。

若是使用的是磁盘见证，时间节点5的时候，节点1启动，启动后会联系到见证磁盘，由于群集数据库也会在见证磁盘同步，时间节点3修改时，群集见证磁盘也会同步到，因此节点1能够从见证磁盘获取到最新paxos标记的群集数据库，而正常启动。

基于此，老王的建议是2012R2的群集，不管是奇数节点或偶数节点，都配置见证磁盘

您也能够选择多数节点，可是多数节点动态仲裁的弊端在于：百分之六十六支持到最后一个节点

多数节点加见证磁盘，您须要维护确保见证磁盘始终在线

二者都须要有一个权衡的点

进一步讨论的话，老王认为若是是在同一个数据中心内的话，见证磁盘加多数节点，毫无疑问，首先就应该选择它，只要见证磁盘在线，群集就百分百可以挺到最后一个节点，至于见证磁盘的可靠性，能够在阵列上面经过配置Raid，配置各节点到阵列的多路径，以保证见证磁盘的持续可用，或者底层直接由超融合软件，例如S2D，VSAN跨机架构建起虚拟磁盘，再使用虚拟磁盘建立群集见证磁盘。

若是是异地数据中心的话，在条件容许的状况下，老王仍然建议使用见证磁盘，见证磁盘加多数节点 2012R2以后永远是最佳方案，异地数据中心的群集架构，一般架构师会推荐两种方案，一种是第三个数据中心存放见证设备，两数据中心链接第三个数据中心，可是这样作的话，又须要额外考虑两个数据中心到第三个数据中心之间的链路问题，带来额外的成本，另一种是如今用的比较多的，存储复制，即在两个数据中心各一个存储设备，互相作同步复制，通常是硬件设备直接实现，或软件实现，一个站点宕机后，直接另一个站点存储和计算都启动起来，须要注意，若是涉及到见证磁盘的复制，目前2016的存储复制仍是不能实现，2016存储复制只能复制CSV和角色磁盘，不能复制见证磁盘。

说到底仍是成本的问题，若是资金容许的状况下能够在第三个站点分配见证磁盘到两个数据中心，或直接两个站点同步存储复制阵列

若是资金不容许的状况下，能够在第三个站点找一台文件服务器，作文件共享见证，分配到两个数据中心，这样作也能够，只须要规避掉时间分区的问题就能够了，例如已经出现有节点宕机的状况下，不在现有节点上面修改群集数据

或者若是连第三个站点也没有的状况下，可使用2016的云共享见证，在Azure上面开个blob用于群集仲裁，但须要开通本地数据中心到Azure的443端口

虽然文件共享见证和云见证没有群集数据库，可是这两种仲裁模型也能够支持动态见证仲裁模型，帮助群集支撑到最后一个节点，避免脑裂分区问题。

不管是文件共享见证，仍是云见证，仍是磁盘见证，异地数据中心最主要关注的仍是链路问题，各节点到见证设备的链路不须要很快，但必定要保证质量。