在日常运维中，如果你的 Windows Cluster 需要升级、重启、意外宕机、网络中断等，你知道该怎么操作才能保证集群的可用性吗？按什么样的顺序怎样关闭或启动集群节点吗？怎么快速恢复你的集群呢？
接下来，我们就以实践操作来解决这几个疑问。首先要知道，Windows Server 2012 R2 提供了动态仲裁功能，以保证集群（投票权）为奇数节点。现在，假设一个Windows Server 故障转移集群 (WSFC) 有三个节点A、B、C（A为当前主节点），我们根据不同的见证（即仲裁）类型做以下测试。
多数节点
关闭节点A，节点上的所有资源都故障转移到节点B，由于动态仲裁作用投票为0。(数字为投票权)
关闭节点B，节点上的所有资源都故障转移到节点C。
关闭节点C，所有节点都已关闭，集群即关闭，无人可访问。
此时，当我们启动节点A时，发现集群报错并未恢复。当我们继续启动节点B时，集群仍然报错并未恢复。两个节点都在尝试连接到节点 C，即使我们有两个节点（A 和 B）并且配置为 Node Majority，集群也没有恢复。最后我们启动节点 C，集群则恢复，集群 Paxos Tag 的Epoch则发生改变并记录下来（集群算法请看上一篇文章）。
为什么会发生这种情况呢？
当一个节点A关闭时，它在集群注册表中的投票变为 0。当一个节点去启动集群服务时，它会检查它的投票。如果为0，则只会加入一个Cluster。如果为1，则首先尝试加入一个Cluster，如果无法连接到该Cluster加入，则自己恢复Cluster。当然，如果节点C永远无法恢复，启动节点A或B集群服务时，使用 ForceQuorum (FQ)开关来强制恢复集群。恢复后，其他节点都可以不考虑顺序加入了。
net start clussvc /forcequorum磁盘见证
与上面的测试一样，按顺序关闭节点A、B、C，由于动态仲裁的作用，集群会保留为奇数投票节点。结果如下图。
此时首先恢复节点B或C，集群都能正常恢复，因为磁盘仲裁存储有集群配置信息。你可以通过命令查看节点投票权 (Get-Cluster).WitnessDynamicWeight，因为它有投票权，所以集群恢复。虽然磁盘存储集群数据，但是节点A无投票权，所以无法恢复集群。
文件共享见证
与上面的测试一样，按顺序关闭节点A、B、C，由于动态仲裁的作用，集群会保留为奇数投票节点。结果如下图。
在之前的磁盘见证情况下，我们可以启动节点B、C并恢复集群，这是因为节点有投票权，并且磁盘存储着群集数据库副本。但文件共享见证不同，它不持有集群数据库的副本。当剩下C节点的时候，C节点的集群数据是最新的。即使B、C、文件共享见证都有投票权，但节点A和B都没有新集群数据，这是因为文件共享见证不存储集群数据。若启动了节点A和B，集群都是无法正常恢复的。正常恢复集群只能先启动节点C（或者直到启动到节点C）。当然，启动节点A或B时，也可以使用 ForceQuorum (FQ) 开关来强制恢复集群。若使用ForceQuorum启动集群，当节点C启动时，发现已有了集群，则加入到集群中。
当我们在集群中启动一个节点以恢复集群时，节点将比较它的 paxos 与见证磁盘上的 paxos。如果节点 paxos 早于在磁盘见证上的数据，则它将最新副本下载到节点并使用它。如果本地节点较晚，它会将集群数据上传到磁盘见证。所以，了解了这些启动问题，当集群出现意外的时候，你就可以知道如何处理以快速恢复了。这对于安装有 SQL Server 高可用的集群非常重要。
附加说明：Windows Server 2016 故障转移群集遵循相同的设计，同时也引入了云见证。