WSFC仲裁模型选择
今天我们再来详细讨论下关于WSFC的仲裁模型，主要仲裁模型的优缺点，应该如何去思考选择最佳合适方案
创新互联公司专业成都网站设计、成都网站建设、外贸网站建设，集网站策划、网站设计、网站制作于一体，网站seo、网站优化、网站营销、软文平台等专业人才根据搜索规律编程设计，让网站在运行后，在搜索中有好的表现，专业设计制作为您带来效益的网站！让网站建设为您创造效益。
WSFC引入仲裁，主要有两个目的
跟踪群集当前运作票数是否符合仲裁模型协定，如果低于最少允许节点，则决定关闭群集（2012之前）
当发生分区时，确保由多数一方负责接管群集提供服务，少数票数方将关闭
回顾一下历史，在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端口
虽然文件共享见证和云见证没有群集数据库，但是这两种仲裁模型也可以支持动态见证仲裁模型，帮助群集支撑到最后一个节点，避免脑裂分区问题。
不论是文件共享见证，还是云见证，还是磁盘见证，异地数据中心最主要关注的还是链路问题，各节点到见证设备的链路不需要很快，但一定要保证质量。
当前名称：WSFC仲裁模型选择
URL分享：http://scyanting.com/article/jhjheh.html
