豆子使用学习windows 2012 Hyper-V的集群大概半年多了，这阶段看了很多人的博客，自己也搭建过实验环境，最后工作环境中也搭建了一个，但是直到上周，才发现双节点集群的在高可用方面的限制性。

上周末，豆子需要升级 Hyper-V 节点的firmware，心里想的很简单啊，首先做个live migration把虚拟机都挪到另外一个节点，然后关机，升级firmware，开机，另外一台主机上重复以上操作。但是呢，事实和豆子考虑的是有出入的~~  第一台主机成功升级了，但是操作第二台的时候，悲剧发生了，尽管SCVMM的migration操作显示成功了，但是当我关机以后，集群上面所有的VM都一起歇菜了~ 最开始 我以为是SAN的问题，因为我并不是使用传统的共享SAN，而是通过starwind软件把本地硬盘强行模拟成共享SAN，后来在另外一个实验环境里面使用了共享SAN，居然也发现了同样的问题，最后终于发现这个事故的罪魁祸首是Witness Disk的局限性造成的。

http://technet.microsoft.com/en-us/library/cc770620(v=ws.10).aspx

配置witness disk有4种模式，如下所示。

• Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majority of the votes, that is, more than half.

• Node and Disk Majority: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

• Node and File Share Majority: Each node plus a designated file share created by the administrator (the “file share witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

• No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk in the cluster storage.

当初我也没怎么考虑，直接用的是软件的自动最佳配置，我使用的是Nodes and Disk majority。经过分析，如果我只有2个节点和1个witness disk，那么总共有3票（votes），任何时候如果有2票通过，那么集群就会正常运作。很不幸的是，witness disk总是位于其中一台节点上的，如果刚好是这台主机重启，那么就意味着有2票同时都没了，cluster会立刻紊乱，上面的虚拟机自然也就会出现各种异常，自动关机了。如果是那台没有witness的主机重启，剩下还有2票工作，自然是没有问题的，这就是为什么豆子的第一个操作是成功的，而第二个却失败了。

那怎么解决这个问题呢，按照这4个配置选项，我可以使用选项3 Node and File Share majority，重新找个服务器，上面设置共享，这样一来，因为这个共享文件始终在线，任何一台主机重启，都能保证2个投票，那肯定是一直工作的；或者呢，豆子有钱的话，在现有的集群里面再安装一个节点，那么可以使用选项1 Nodes Majority以便保证2个投票；如果更有钱，能够安装一共4个节点的集群，那么才可以使用Node and Disk Majority。

这些选项考试和配置实验的时候豆子都遇见过，可是当时都没在意，考试嘛很容易就过了，实验默认配置啊 Failover, Live Migration好像也都工作。不少老师前辈的博客实验一般也是搭建个双节点的集群，貌似也就测试一下live migration就表示实验成功。

不足之处 欢迎拍砖！