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

EN

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

永远不要检查或取消选中AG资源的首选或可能的所有者。当使用Server 2016时，可以上下移动首选所有者列表，以便在多个故障转移目标更改的情况下控制首选故障转移目标，但不要选中或取消选中任何包含可用性组的框。句号。

如果你检查和取消这样的事情，你的AG是不会正常工作的。当我教授可用性组类时，我总是展示它是如何工作的，为什么它能工作，为什么我们永远不想这样做(破坏者警告: AG很可能会失败，很难)。

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

首选和可能的所有者

这些值由Server根据可用性组的设置设置。集群有自己的元数据副本，说明应该如何工作，Server也有自己认为应该如何工作的副本。

这在大多数情况下是很棒的，因为没有人会改变任何东西，Server和集群都会继续嗡嗡作响。

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

三异步副本

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

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

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

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

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

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

这里是变化的地方，变得有趣！由于我们现在正在引入自动故障转移--这是WSFC的角色之一(以及健康检查、元数据分发等)--我们将希望拥有首选的和可能的所有者。

其他反应

最近我们更换CO 01服务器硬件时中断了5分钟.

你已经明确取消了CO的投票，只剩下了1名其他选民，然后意外的崩溃了。听起来就像它应该做的那样。

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

我要在这里残忍地诚实。可用性组不是一个灵丹妙药，它修复了所有HA & or .看来这项技术正在被使用，但是对于它是如何工作的或者为什么它同时在AG或WSFC级别上做这些事情并不了解太多，所以我完全同意它可能没有被正确地设置.然而，它正在工作，因为它是设置-我不能责怪集群做它应该做的事情。

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

如果您在可用性组中有这么多问题，那么我不会单独研究分布式可用性组。它可能适合您的用例，也可能不适合您的用例--但如果我是您，我会请一个帮助架构这些类型的解决方案并准备好您的用例的人。否则，你会再做一个这样的帖子。

我们还认为这将允许我们以最小的停机时间升级集群操作系统。

分布式可用性组的一个用例是用于极低停机时间的跨集群迁移，您是正确的。如果使用WindowsServer2012R2，则可以不需要执行分布式可用性组就可以执行滚动集群升级 2012年年不可用，必须为R2。

下面是StackOverflow_AG IP资源的默认设置

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