场景：
Windows Server 2012上的三个节点（无共享）集群。主数据中心中的两个节点都具有投票（节点权重= 1）和文件共享见证。 第三个节点位于远程数据中心，没有票（节点权重为0）。
问题：一个群集节点（拥有群集名称）自动更新。 远程数据中心节点的集群名称失败，并且远程节点能够获取文件共享见证文件的locking。 那时候，我们的VPN隧道掉线了。 主数据中心中的一个节点（并且服务正在运行）注意到远程集群节点已closures，并试图使集群名称联机。 文件共享见证文件仍然被远程节点locking，并且主数据中心中的一个可见运行群集节点无法使群集名称联机，并closures群集服务。
注意事项：由于使用它的其他进程，防火墙从远程节点的文件共享不是一个选项。
我已经考虑尝试从集群名称的可能所有者中删除远程集群节点，但是我之前没有做过或testing过，我不想炸掉我的生产集群。 是否可以从集群名称的可能所有者中删除集群节点？ 如果我们不得不将服务交给远程数据中心，那么需要协调一些移动部分，所以我不希望将服务“自动”故障转移到远程数据中心。 远程节点完全在群集中的原因是为了SQL Server可用性组，来pipe理到远程节点的复制。
我也考虑删除文件共享见证，并给远程节点投票。 如果一个节点发生重新启动并且远程数据中心的networking连接丢失，则新的dynamic仲裁“应该”保持群集联机。
根据我的情况，哪个选项（或其他select）会给我最高的可用性。
我实际上喜欢给远程节点投票，因为它会使计划中的故障转移更容易。 您可以将数据库和资源迁移到远程数据中心，然后逐渐closures主数据中心中的节点，并且不必为了使其工作而投票。 另外，您并不担心文件共享上的高可用性。
所以我在这里与布伦特。 除非你完全确信你不关心它，否则我从来没有像选举人一样去除节点。 您应该努力做的一件事就是将WSFC群集组保留在主要副本的位置，以避免分裂大脑。
从WSFC移除作为可能所有者的集群节点是一个坏主意。 如果您需要这样做，请从集群中逐出节点。 坏，坏的魔咒。
在Windows Server 2012中，您也拥有dynamic法定人数，除非您的失败都是同时发生的，否则您可以轻而易举地完成最后一个任务（当然有警告）。
另外，我会解决任何networking问题。 你可以知道，它们会在地理上分散的情况下成为杀手。