多数节点设置仲裁

    针对上面提到的两种局限，设计出一些第三方解决方案。同时，在基于服务器集群的Windows 2003 sever发布时，微软也以多数节点设置（MNS）仲裁的形式提出了自己的补救方案。象本地仲裁一样，MNS定义为一个独立的源，在用New Server Cluster Wizard作集群设置的过程中必需选择。同本地仲裁模式一样，NMS对运行仲裁源的共享存储器的依赖性也被消除了，且不会对高可用性产生负面影响。

    在每个本地节点存储仲裁的一个副本（在%SystemRoot%ClusterMNS.%ResourceGUID%$%ResourceGUID%$MSCS文件中，%ResourceGUID%在创建时指派了一个分配给集群的128位唯一标志）可以使冗等级得到提升。正如你可以料到的，有多个仲裁实例时，需要不同的方法来防止“首脑分裂” 场景的出现。通过定义一个独立的规则来确定集群何时可操作（相应的，这对于使客户也能访问其资源也是必需的），该问题可以得到处理。为实现这种情况，要求必须有超过半数的集群节点能运行正常且能和其他节点通信，用来计算这个节点数目的公式如下：

[(MNS集群里总节点数目)/2] + 1

    公式中，方括号表示取顶函数，返回大于或等于括号内结果的最小整数。例如，对于5个节点的集群，需要3个节点运行所有的可用源（这同样适用于4节点集群）。很明显，建立一个2节点MNS集群虽然在技术上是可行的，但从可用性的观点来看，这没有任何意义（因为一个节点的瘫痪将使另一个关闭其所有源）。要使一个MNS集群工作，至少要有两个服务器（在3节点集群中）是运行正常的（注意，对于单共享仲裁而言，即使只剩一个节点，它也有能力支持其源）。

    这个规则有效的保证了在任何一个给定点，每个集群源都只有一个实例。每个节点的集群服务配置成在导入时间开始运行，并尝试与其他大多数节点建立通信。如果初始化失败，该过程每分钟重复一次。

    该解决方案带来了另外的要求，因其体系结构意味着存在多份集群数据拷贝（这不像单共享仲裁模式），需要不断的维护。尽管集群软件本身负责拷贝所有节点间的仲裁配置，但它不能用于业务数据和特定应用数据。通常，有两种方法处理该任务。第一种依赖于嵌入应用的机制（比如SQL Server 2000/2005部署的运行日志）。第二种方式涉及到在文件系统或磁盘块级别上建立的复制。这可以通过软件或硬件得到处理，我们计划在下一篇文章详细阐述该主题。

    另外，因为集群源是虚拟的，在单共享仲裁模式下的一些限制仍然存在。特别是对于源失效情况发生时，节点必须能够在没有心跳信号的情况下，检测到其他节点故障。这就要求节点间的往返延迟不能超过500毫秒-这影响到相应的节点之间的最大允许距离。这些节点还必须是属于同一个域且他们的公开与私有网络接口必需各自位于相同的子网（这可以通过设置跨越多个物理位置的集群节点的两个VLAN来实现）。

    此外，因为仲裁的更新是通过一个叫%ResourceGUID%$（与先前所列的仲裁位置相关）的网络文件共享来处理的，所以服务器和工作站服务（分别为LanManServer和LanManWorkstation）必须运行在所有集群节点之上，并且为Microsoft 网络共享的文件和打印机必须在私有与公开网络连接上能够打开。

    因此，当设计这样一种构架时，紧记该构架的设计将对MNS集群的可用性产生的影响是很重要的。例如，在拥有相同节点数目、由网络连接分开的两点间搭建时，如果两个站点之间的通信量很大（因两边都包含多数接点），这会导致两边都会失效。在这种情况下，建立第三个只有单集群节点的站点（与其他两个站点有专用的网络连接）是很有好处的，可以在需要时专门建立多数节点计数。此外，你也可以强制部分集群节点运行源，虽然这需要手工干涉。