![处理延伸(地理)集群节点故障](https://linux22.com/image/799249/%E5%A4%84%E7%90%86%E5%BB%B6%E4%BC%B8%EF%BC%88%E5%9C%B0%E7%90%86%EF%BC%89%E9%9B%86%E7%BE%A4%E8%8A%82%E7%82%B9%E6%95%85%E9%9A%9C.png)
设想:
Windows Server 2012 上的三节点(无共享)集群。主数据中心中的两个节点均有投票(节点权重 = 1),并有一个文件共享见证。第三个节点位于远程数据中心,没有投票(节点权重为 0)。
问题:一个集群节点(拥有集群名称)因自动更新而关闭。集群名称无法连接到远程数据中心节点,而远程节点能够锁定文件共享见证文件。此时,我们的 VPN 隧道断开。主数据中心中处于运行状态(并且正在运行服务)的一个节点注意到远程集群节点已关闭,并尝试使集群名称联机。文件共享见证文件仍被远程节点锁定,主数据中心中一个可见的正在运行的集群节点无法使集群名称联机,并且它自行关闭了集群服务。
注意事项:由于其他进程使用远程节点的文件共享,因此无法使用防火墙来保护该文件共享。
我曾考虑尝试从集群名称的可能所有者中删除远程集群节点,但我之前没有这样做过或测试过,而且我不想破坏我的生产集群。是否可以从集群名称的可能所有者中删除集群节点?如果我们必须将服务故障转移到远程数据中心,则需要协调许多移动部件,因此我不希望“自动”将服务故障转移到远程数据中心。远程节点位于集群中的原因完全是为了 SQL Server 可用性组管理到远程节点的复制。
我还考虑过删除文件共享见证并让远程节点投票。如果一个节点因重新启动而关闭并且与远程数据中心的网络连接丢失,新的动态仲裁“应该”会使集群保持在线状态。
考虑到我的情况,哪个选项(或其他替代方案)可以为我提供最高的可用性。
答案1
我其实喜欢给远程节点投票,因为这样可以让计划的故障转移变得更容易。你可以将数据库和资源迁移到远程数据中心,然后逐渐关闭主数据中心的节点,这样你就不必费心投票来让它正常工作。另外,你不必担心文件共享的高可用性。
答案2
所以我和 Brent 意见一致。除非你 100% 确定你不在乎某个节点,否则我从来不会支持删除该节点作为投票者。你应该努力做的一件事是将 WSFC 集群组保留在你的主副本所在的位置,以避免出现脑裂。
从 WSFC 中删除集群节点作为可能的所有者不是一个好主意。如果需要这样做,请从集群中逐出该节点。非常糟糕。
使用 Windows Server 2012,您还具有动态仲裁,因此,除非您的故障都是同时发生的,否则您几乎可以找到最后一个站着的人(当然会发出警告)。
此外,我还会解决任何网络问题。正如您所见,在地理位置分散的情况下,这些问题会非常严重。