使用多子网集群的可用性组：角色的首选所有者和 AG 侦听器 IP 的可能所有者

Question

我们在 Windows Server 2012 多子网故障转移群集上使用 SQL Server 2016 可用性组 (AG) 来实现 HA/DR。我们的纽约数据中心（10.7.xx 子网）中有两个节点，我们的科罗拉多数据中心（10.8.xx 子网）中有一个节点。科罗拉多服务器主要用于灾难恢复或纽约离线的扩展维护，因此我们目前将 CO-SQL01 节点的 Quorum NodeWeight/Votes 设置为零，以防止它在出现任何问题时自动获得集群或 AG 的所有权.

我的问题是：我们是否应该更改故障转移群集管理器中的默认设置，特别是 AG 角色的首选所有者和 AG 侦听器 IP 资源的可能所有者？使用的默认值似乎与我们在纽约使用两个节点并仅使用 CO 节点进行灾难恢复的高可用性目标相冲突。

以下是我们多子网 AG 的首选所有者的默认设置：

我们是否应该在 NY-SQL02 旁边添加一个检查并将其移动到 CO-SQL01 之上，以便它成为首选？其他角色呢，我们可以设置核心集群资源的首选所有者吗（比如集群名称）？

以下是 SQL-StackOverflow_AG IP 资源的默认设置：

我们是否应该删除与该 IP 地址位于不同子网中的服务器旁边的复选标记？

这个问题是在最近的办公时间提出的，但是当我们的集群出现问题时，我们可能会帮助防止停机。我们最近在更换 CO-SQL01 服务器硬件时发生了 5 分钟的中断，它被添加回故障转移集群（但不是 AG）而没有删除它的投票。CO-SQL01 服务器随后发生了严重崩溃（我们认为这是重负载下的 NVMe/PCIe 驱动程序错误）并设法将 AG 与它一起删除（我们认为 CO-SQL01 在它出现时获得了核心集群资源的所有权重新上线）。

老实说，我们在使用多子网故障转移群集可用性组时遇到了许多意外问题，似乎默认首选角色所有者和可能的资源所有者可能不正确，或者至少不是我们方案的最佳选择。我们目前正在考虑使用SQL Server 2016 中新的分布式可用性组功能将我们的多子网 AG 拆分为两个单个子网 AG（每个数据中心一个），以防止将来出现这些问题。我们还认为这将使我们能够以最少的停机时间升级集群操作系统。

Answer 1

我的问题是：我们是否应该更改故障转移群集管理器中的默认设置，特别是 AG 角色的首选所有者和 AG 侦听器 IP 资源的可能所有者？

切勿选中或取消选中 AG 资源的首选或可能的所有者。当使用SQL Server 2016首选所有者列表可以移动上下控制首选故障转移目标给出的多个故障转移目标的变化，但不选中或取消选中任何框，以往，与可用性组。时期。

如果您选中和取消选中此类内容，则 AG 将无法正常工作。当我教 Availability Group 课程时，我总是展示它是如何工作的，它为什么工作，以及为什么我们永远不想这样做（剧透警告：AG 很可能会失败，很难）。

不过，让我解释一下，让它更清楚一点。

首选和可能的所有者

这些值由 SQL Server 根据可用性组的设置进行设置。集群有自己的关于事物应该如何工作的元数据副本，SQL Server也有一份它认为事物应该如何工作的副本。

这在大多数情况下都很棒，当没有人更改任何内容并且 SQL Server 和集群继续嗡嗡作响时。

但是，SQL Server 知道它认为什么应该和不应该是基于 AG 设置的资源所有者，并通过调用群集 API 来设置预期行为来反映这一点。您会在HADR_CLUSAPI_CALL等待类型中看到这一点。

三个异步副本

让我们看看带有 AG 设置的 SQL Server，以便有三个异步提交副本。如果我们这样做，我们的 AG 和角色资源应该如下所示：

请记住，异步提交副本不能具有自动故障转移。因此，这是有道理的；我们当前的角色所有者是唯一可能和首选的所有者。由于 SQL Server 已设置，因此故障转移的唯一方法是强制执行它，因此我们不希望任何其他副本选择并开始运行，因此在集群级别强制执行此操作。

两个同步手动故障转移，一个异步 - 演示

结果将与三异步演示相同。为什么？

这与三个异步副本的解释相同，我们还没有自动故障转移，所以我们不希望任何人自动接管。因此，设置是相同的。

两个异步自动故障转移，一个异步 - 演示

这就是事情发生变化并变得有趣的地方！由于我们现在正在引入自动故障转移——这是 WSFC 的角色之一（以及健康检查、元数据分发等）——我们希望拥有首选和可能的所有者。

其他回复

我们最近在更换 CO-SQL01 服务器硬件时发生了 5 分钟的中断......

你已经明确地从 CO 中删除了投票，只剩下 1 个投票者，然后发生了意外崩溃。听起来它像它应该的那样工作。

老实说，我们在使用多子网故障转移群集可用性组时遇到了许多意外问题，似乎默认首选角色所有者和可能的资源所有者可能不正确，或者至少不是我们方案的最佳选择。

我将在这里说实话。可用性组不是灵丹妙药，可以解决所有 HA 和 DR。似乎正在使用该技术，但对其工作原理或为什么在 AG 级别或 WSFC 级别执行这些操作知之甚少，所以我完全同意它可能没有正确设置......但是，它在设置时正常工作 - 我不能指责集群做它应该做的事情。

目前正在考虑使用 SQL Server 2016 中新的分布式可用性组功能将我们的多子网 AG 拆分为两个单个子网 AG（每个数据中心一个），以防止将来出现这些问题。

如果你有这样与可用性组的许多问题我会不会进军在自己的分布式可用性组。它可能适合也可能不适合您的用例 - 但如果我是您，我会请人帮助构建这些类型的解决方案并准备好您的用例。否则，您将制作另一篇这样的帖子。

我们还认为这将使我们能够以最少的停机时间升级集群操作系统。

分布式可用性组的用例之一是极低的停机时间跨集群迁移，您是对的。如果您使用的是 Windows Server 2012R2，则可以进行滚动集群升级[2012 年不可用，必须是 R2]，而无需进行分布式可用性组。

以下是 SQL-StackOverflow_AG IP 资源的默认设置

是的，不要碰它们 :) 保持原样。