SQL Server Always On 文件共享见证（仲裁投票）在不同子网上到其他节点

Question

我目前遇到一些可用性组的问题，其中节点 1 和节点 2 彼此之间的连接松散“先前建立的与可用性副本的连接发生连接超时”。

故障转移群集管理器中的错误显示“文件共享见证资源‘文件共享见证’未能仲裁文件共享”文件共享所在的服务器尚未重新启动或出现任何问题，并且所有权限都在工作。

我唯一能看到的是文件共享服务器与集群中的其他 2 个 SQL Server 节点位于不同的子网上。

有人可以确认在 AlwaysOn 环境中将文件共享服务器放在不同的子网上是一个大问题吗？所有防火墙规则都已就绪，因为它可以与其他节点通信，但在几个小时之外（通常）它会失去连接。

另一个奇怪的事情是包括文件共享在内的仲裁中有 3 票，因此即使文件共享失去与故障转移集群的连接，节点 1 和节点 2 也不应该失去彼此之间的连接，因为有足够的投票支持仲裁 (2)

Answer 1

有人可以确认在 AlwaysOn 环境中将文件共享服务器放在不同的子网上是一个大问题吗？

将 FSW 放在不同的子网上完全没问题，这绝对没有错。没有必要将它放在同一个子网上，事实上有一个 Azure 见证，它绝对不会在同一个子网上，它可以正常工作。

“先前与可用性副本建立的连接发生连接超时”

似乎是指网络中的某些问题存在问题，或者如果这是在虚拟机上，来宾/主机发生了某些事情，这给您带来了麻烦。鉴于在主机、来宾和操作系统级别有大量深入的配置设置可以对此做出贡献，我不会进一步深入，因为它超出了本站点的范围。

故障转移群集管理器中的错误显示“文件共享见证资源‘文件共享见证’未能仲裁文件共享”文件共享所在的服务器尚未重新启动或出现任何问题，并且所有权限都在工作。

这意味着任何试图为见证人进行仲裁的人都只是拥有集群法定人数的一票。由于它是一个双节点集群，如果节点无法相互通信，它们就会处于这种确切的情况。

如果两个节点都不能相互通信（显然是一个问题）并且两个节点都不能与 FSW 通信（另一个问题），这让我想知道基础设施中有什么问题 - 再次，在虚拟层或物理（网络）层。很明显，某些事情正在导致这种情况，并且特定于您的环境，而不是 SQL Server。

另一个奇怪的事情是包括文件共享在内的仲裁中有 3 票，因此即使文件共享失去与故障转移集群的连接，节点 1 和节点 2 也不应该失去彼此之间的连接，因为有足够的投票支持仲裁 (2)

是的，但是我打赌节点之间失去了连接。集群日志中可能有一些关于丢失心跳、连接到 ~3343、重新组合等的条目。

连通性并不意味着投票，连通性意味着健康检查。一旦健康检查失败，节点就会被分区，这就是这些事件发生的时候。您需要了解在发生这种情况时您的环境中发生了什么。如果它经常发生并且按计划发生，那么它是环境中的某些任务或软件，如果它是随机发生的，那么它很可能是基础设施问题，例如网络或主机/访客/操作系统设置，如果它是在负载下发生的。