Windows群集仲裁

群集仲裁的意义

群集仲裁的目的之一是防止群集出现网络分区的时候导致群集脑裂，脑裂是群集出现分区（或者叫分组）的结果，群集分区意味着两个分区都认为对方已经不存在或者失效，于是会争夺群集资源的控制权。脑裂的后果是两个分区各自同时且独立读写共享磁盘而导致磁盘数据混乱。

仲裁的目的之二是限制群集所能承受的最大故障数，仲裁要求群集有多数投票存在，否则群集将失效，比如一个5节点的群集可以忍受最多两个节点同时发生故障。

群集投票

投票算法基于投票结果少数服从多数，群集中各个节点需要心跳机制来通报彼此的"健康状态”，每收到一个节点的"通报"代表一票。对于三个节点（假设三个节点为A,B,C）的群集，正常运行时，每个节点都会有三票。当结点A心跳出现故障但仍在运行，B和C心跳正常，这时整个群集就会分裂成两个分区。节点A在一个分区，B和C在另外一个分区。这时必须剔除一个分区才能保障群集的健康运行。按照投票算法，B和C在一个分区，有两票，A只有一票，B和C组成的群集获得控制权，A被剔除。

群集节点、磁盘见证资源、文件共享资源都可以分配投票权，可以在群集管理器里进行投票权的分配。一个群集节点可以分配一个投票，同样，一个磁盘见证或者文件共享见证资源也可以分配一个投票。

拥有投票权不代表就能参与投票仲裁，必须要确保投票的有效性。在群集管理器里可以查看到是否分配投票权以及是否具有有效的投票，只有已分配的投票才有效，如图1所示。

<图1 群集投票权和有效投票>

仲裁见证

如果群集只有两个节点，因为每个节点上都只有一票，所以投票算法就起不了作用，群集分区后每个区都各一个有效投票导致群集脑裂。同理，如果群集节点是偶数，而且刚好群集分区后遇到刚好各占半数节点的情况时导致群集脑裂。为了防止此类的情况发生，需要引入第三个设备：仲裁见证。仲裁见证的目的和生活中的增加投票的例子类似，共享磁盘和共享文件夹资源都可以充当仲裁见证，共享磁盘被用于仲裁时也叫做仲裁磁盘。用于仲裁的见证的磁盘和共享文件也能分配一个投票，当在两结点的群集里节点间心跳出现问题时，两个节点同时去争取仲裁见证这一票，最早到达的请求先被满足。在分区后偶数节点对半分的群集也是如此，所以先获得仲裁见证的节点和分区就获得超过半数的投票，另一个节点或者分区就会被剔除。

在WindowsServer群集里，默认为每个节点分配投票权，当群集服务器节点为奇数且不巧出现网络分区时，因为投票结果可以形成多数节点分区，因此群集会剔除少数节点分区的节点。但是如果群集节点为偶数且出现网络分区时，群集可能出现节点对半分的情况，这时候就最好能为群集配置仲裁见证。

仲裁模型

目前，群集支持4种仲裁模型，包括节点多数、节点和磁盘多数、节点和文件共享多数以及仅磁盘（传统模型）。节点多数模型只为群集节点分配投票，节点和磁盘（文件共享）多数模型既为群集节点也为群集磁盘（文件共享）分配投票，仅磁盘这种模型是传统的模型。

这4种仲裁模型的投票数和仲裁说明对应表如下：

见证资源

共享磁盘和共享文件夹都可以作为仲裁见证资源，但是两者略有不同，磁盘见证除了可以为仲裁提供投票，作为仲裁见证的磁盘还存储持续更新的群集数据库副本，帮助群集在某个节点失效的情况下维护群集正常状态和配置信息，确保各节点保存最新的数据库副本。而文件共享仲裁见证不能存储群集数据库。

群集仲裁演进

仲裁技术随着Windows Server的迭代更新和环境的复杂程度不断发展，从最初的群集开始到Windows Server 2016群集，仲裁模型发生了不小的变化。接下来简单说明Windows Server群集仲裁方式的演进。

（1）仅磁盘仲裁

早期的Windows Server群集仲裁里，磁盘具有唯一的仲裁投票，如果磁盘见证资源失败，群集也会失败，这种仲裁模型对群集磁盘依赖过大，已经很少被采纳。虽然现在在群集里面还保留了磁盘仲裁机制，但是这种仲裁机制逐渐被放弃了。只有在磁盘网络很稳定，但是节点之间的网络不稳定导致网络和节点通信间歇性失败的时候才会考虑用这种仲裁机制，这种情况已经非常鲜见。

（2）见证和节点仲裁

Windows Server群集开发组发现仅磁盘仲裁无法适应大多数环境，于是开始着手研究新的仲裁机制。从Windows Server2008开始群集节点也具有了投票权，可以按照需要选择为节点分配投票权，不仅如此，节点和资源见证还可以组合成更加灵活的投票模型。节点投票和磁盘投票组合成节点多数、节点和磁盘多数、节点和文件共享多数等几种仲裁选项。

（3）动态仲裁

在Windows Server 2012R2中引入了动态见证仲裁，群集默认配置为动态仲裁，群集基于当前群集投票节点数量进行动态投票调整。动态仲裁意味着群集在增加、删除、关闭、开启群集节点，或者增加删除见证资源时，群集会动态调整投票数和投票的有效性，让自己的有效投票数始终保持为奇数。仲裁见证投票还会基于见证资源状态进行动态调整，如果见证资源离线或者失败，群集会把该见证投票设置为0，意味着该见证不再参与投票。

比如在一个4节点群集里，虽然4个节点都分配了投票，但是群集为了让自己的投票数保持为奇数，“拿走”了一个节点的投票，剩下3个有效投票，如图2所示。

<图2 动态仲裁中的投票数和有效投票数>

如果这时为群集配置磁盘见证或者文件共享见证仲裁，如图3所示，那么群集里分配的投票将达到5个，有效的投票为4个，这时候群集为了让自己的有效投票数保持为奇数，于是将之前“拿走”的投票“归还”给节点。这时候4个节点加上1个见证资源仲裁，一共有5个投票，如图4所示。

<图3 群集增加共享见证>

<图4 动态仲裁中重新调整的投票数>

如果这时手动关闭一个节点，那么群集里分配的有效投票将剩下4个，这时候群集为了让自己的有效投票数保持为奇数，于是再“拿走”一个节点的投票，只剩下两个节点具有有效投票。这时候两个节点加上一个见证资源仲裁，一共有3个投票，如图5所示。

<图5 关闭节点动态仲裁重新调整的投票数>

（4）云仲裁

在WindowsServer 2016中引入了云仲裁模型，如图6所示。云仲裁模型可以使用Azure的Blob存储作为Windows Server 2016的群集仲裁见证资源，如图7所示。

<图6 新增云仲裁见证>

<图7 配置云仲裁见证>