HADR 配置最佳做法（Azure VM 上的SQL Server）

适用于：Azure 虚拟机上的 SQL Server

Windows Server故障转移群集用于在Azure虚拟机上运行的SQL Server的高可用性和灾难恢复（HADR）。

本文提供了在 Azure VM 上使用 SQL Server 时关于 故障转移群集实例（FCI） 和 可用性组 的群集配置最佳实践。

有关详细信息，请参阅本系列教程中的其他文章：清单、VM 大小、存储、安全性、HADR 配置和收集基线。

清单

请查看以下清单，以大致了解本文其余部分详细介绍的 HADR 最佳做法。

高可用性和灾难恢复（HADR）功能，如 Always On 可用性组 和 故障转移群集实例，依赖于基础 Windows Server 故障转移群集技术。 查看修改 HADR 设置以更好地支持云环境的最佳做法。

对于Windows群集，请考虑以下最佳做法：

• 尽可能将SQL Server VM 部署到多个子网，以避免依赖Azure 负载均衡器或分布式网络名称（DNN）将流量路由到 HADR 解决方案。
• 将集群更改为较温和的参数，以避免因暂时性网络故障或 Azure 平台维护导致的意外中断。 要了解详细信息，请参阅心跳和阈值设置。 对于Windows Server 2012及更高版本，请使用以下建议值：
  • SameSubnetDelay：1 秒
  • SameSubnetThreshold：40 个检测信号
  • CrossSubnetDelay：1 秒
  • CrossSubnetThreshold：40 个检测信号
• 将 VM 放置在可用性集或不同的可用性区域中。 要了解详细信息，请参阅 VM 可用性设置。
• 每个群集节点使用单个 NIC。
• 将群集仲裁投票配置为使用 3 个或更多奇数投票。 不要将投票分配给 DR 区域。
• 仔细监视资源限制，避免因资源限制出现意外重启或故障转移。
  • 确保 OS、驱动程序和SQL Server处于最新版本。
  • 优化Azure VM 上SQL Server的性能。 查看本文中的其他部分了解详细信息。
  • 减少或分散工作负荷，避免资源限制。
  • 移动到具有更高限制的 VM 或磁盘，以避免约束。

对于SQL Server可用性组或故障转移群集实例，请考虑以下最佳做法：

• 如果经常出现意外失败，请遵循本文其余部分中概述的最佳性能做法。
• 如果优化 SQL Server VM 性能无法解决意外的故障转移，请考虑为可用性组或故障转移群集实例放松监视。 但这样做可能无法解决根本问题，同时可能会降低失败可能性而掩盖症状。 你可能仍需要调查并解决根本原因。 对于Windows Server 2012或更高版本，请使用以下建议值：
  • 租用超时：使用此公式计算最大租用超时值：
    。
    首先从 40 秒开始。 如果使用之前建议的宽松 和 值，则租用超时值不要超过 80 秒。
  • 指定时间段内的最大失败数：将此值设置为 6。
• 使用虚拟网络名称（VNN）和 Azure 负载均衡器 连接到 HADR 解决方案时，请在连接字符串中指定 MultiSubnetFailover = true，即使群集仅跨越一个子网。
  • 如果客户端不支持 ，你可能需要设置 和 来缓存较短持续时间内的客户端凭据。 但这样做可能会导致对 DNS 服务器进行其他查询。

• 要使用分布式网络名称 (DNN) 连接到 HADR 解决方案，请考虑以下事项：
  • 必须使用支持 MultiSubnetFailover = True 的客户端驱动程序，并且此参数必须位于连接字符串中。
  • 连接到可用性组的 DNN 侦听器时，在连接字符串中指定一个唯一的 DNN 端口。
• 使用数据库镜像连接字符串为基本可用性组，以绕过对负载均衡器或 DNN 的需求。
• 在部署高可用性解决方案之前，请验证 VHD 的扇区大小，以避免 I/O 未对齐的情况。 有关详细信息，请参阅 KB3009974。
• 如果SQL Server数据库引擎、AlwaysOn 可用性组侦听器或故障转移群集实例运行状况探测配置为使用端口 49,152 到 65,536（ TCP/IP 的default 动态端口范围），请为每个端口添加排除项。 这样做可以防止其他系统被动态地分配到相同的端口。 下面的示例为端口 59999 创建一个排除项：
  netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

若要将 HADR 清单与其他最佳做法进行比较，请参阅全面的性能最佳做法清单。

VM 可用性设置

为了减轻停机造成的影响，请考虑以下 VM 最佳可用性设置：

• 将邻近放置组与加速网络结合使用，以降低延迟（可选，建议用于生产）。
• 将虚拟机群集节点放置在单独的可用性区域中，以防止数据中心级故障，或放置在单个可用性集中，以便在同一数据中心内实现低延迟冗余（生产 SLA 需要）。
• 对可用性集中的 VM 使用高级管理的 OS 和数据磁盘（建议用于生产）。
• 将每个应用程序层配置为单独的可用性集（应用程序级冗余所必需的）。

Quorum

尽管双节点群集即使没有仲裁资源也能正常工作，但我们严格要求客户使用仲裁资源来获得生产支持。 没有仲裁资源，群集验证不会通过任何群集。

从技术上说，如果没有仲裁资源，三节点群集可以在单个节点丢失（减少到两个节点）的情况下幸存下来，但在群集减少到两个节点后，如果出现另一个节点丢失或通信故障，则群集资源可能会脱机，以防止出现脑裂情况。 配置仲裁资源，将使群集在只有一个节点联机时可以继续联机。

磁盘见证是最具弹性的仲裁选项，但在Azure VM上的SQL Server中使用磁盘见证时，必须使用Azure共享磁盘，这对高可用性解决方案会施加一些限制。 因此，在使用 Azure 共享磁盘配置故障转移群集实例时，请使用磁盘见证；否则，请尽可能使用云见证。

下表列出了可用于Azure VM 上SQL Server的仲裁选项：

• 云见证（Windows Server 2016+，需要群集管理员）非常适合在多个站点、多个可用区和多个区域中进行部署。 除非使用的是共享存储群集解决方案，否则请尽量使用云见证。
• 磁盘见证（适用于所有 Windows Server 版本，需要群集管理员权限）是恢复能力最强的仲裁选项，对于任何使用 Azure 共享磁盘的群集或其他共享磁盘解决方案（如共享 SCSI、iSCSI 或光纤通道 SAN），它是首选。 群集共享卷不能用作磁盘见证。
• 适用于磁盘见证和云见证不可用的情况下，文件共享见证（需要群集管理员权限，适用于所有 Windows Server 版本）。

若要开始，请参阅配置群集仲裁。

法定人数投票

可以更改参与Windows Server故障转移群集的节点的仲裁投票权（需要群集管理员权限，高级配置可选）。

修改节点投票设置时，请遵循以下指导原则：

可以使用故障转移群集管理器或 PowerShell 调整仲裁投票：

Import-Module FailoverClusters  
  
$node = "AlwaysOnSrv1"  
(Get-ClusterNode $node).NodeWeight = 0  
  
$cluster = (Get-ClusterNode $node).Cluster  
$nodes = Get-ClusterNode -Cluster $cluster  
  
$nodes | Format-Table -property NodeName, State, NodeWeight  

还可以在提升的命令提示符中使用 cluster.exe：

cluster.exe Cluster001 node AlwaysOnSrv1 /prop NodeWeight=0  

连接

若要匹配连接到可用性组侦听器或故障转移群集实例的本地体验，请将SQL Server VM 部署到同一虚拟网络中的多个子网。 通过拥有多个子网，可以消除对 Azure 负载均衡器或分布式网络名称 (DNN) 的额外依赖，无需使用它们来将流量路由到侦听器。

若要简化 HADR 解决方案，请尽可能将SQL Server VM 部署到多个子网。 有关详细信息，请参阅多子网 AG 和多子网 FCI。

如果您的 SQL Server 虚拟机位于单个子网中，则可以为故障转移群集实例和可用性组侦听器配置虚拟网络名称（VNN）和 Azure 负载均衡器，或配置分布式网络名称（DNN）。

分布式网络名称（DNN）是建议的连接选项（如果可用）：

• 端到端解决方案更加可靠，因为不再需要维护负载均衡器资源。
• 消除负载均衡器探测可最大程度地缩短故障转移时间。
• DNN 简化了在 Azure VM 上使用 SQL Server 的故障转移群集实例或可用性组侦听器的预配和管理。

请考虑以下限制：

• 客户端驱动程序必须支持 参数。
• DNN 功能从 SQL Server 2016 SP3、SQL Server 2017 CU25 和 SQL Server 2019 CU8 开始提供，适用于 Windows Server 2016 及更高版本。

若要了解详细信息，请参阅 Windows Server 故障转移群集概述。

若要配置连接，请参阅以下文章：

• 可用性组：配置 DNN、配置 VNN
• 故障转移群集实例：配置 DNN、配置 VNN。

大多数SQL Server功能在使用 DNN 时与 FCI 和可用性组透明地工作，但某些功能可能需要特别考虑。 请参阅 FCI 和 DNN 互操作性 以及 AG 和 DNN 互操作性了解详细信息。

心跳和阈值

将群集检测信号和阈值设置更改为宽松设置。 默认检测信号和阈值群集设置适用于高度优化的本地网络，不考虑云环境中延迟增大的可能性。 心跳网络是通过 UDP 3343 维护的，传统上该协议的可靠性远低于 TCP，更容易导致通信不完整。

因此，当在 Azure VM 高可用性解决方案上运行SQL Server群集节点时，请将群集设置更改为更宽松的监视状态，以避免由于网络延迟或故障、Azure维护或达到资源瓶颈的可能性增加而导致暂时性故障。

延迟和阈值设置对总体健康检测产生累积影响。 例如，在执行恢复之前将 CrossSubnetDelay 设置为每隔 2 秒发送检测信号并将 CrossSubnetThreshold 设置为 10 个丢失的检测信号意味着，在执行恢复操作之前，群集总共可以容许 20 秒网络延迟。 一般而言，最好是继续发送频繁的心跳信号，但使用更高的阈值。

为了确保在合法的服务中断期间能够恢复，同时为暂时性问题提供更高的容许度，请将延迟和阈值设置放宽为下表中详述的建议值：

使用 PowerShell 更改群集参数：

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

get-cluster | fl *subnet*

CrossSubnetThreshold  : 40
SameSubnetThreshold   : 40

(get-cluster).SameSubnetThreshold = 10  # 10 heartbeats
(get-cluster).CrossSubnetThreshold = 20  # 20 heartbeats
(get-cluster).SameSubnetDelay = 2000  # 2000 milliseconds (2 seconds)
(get-cluster).CrossSubnetDelay = 2000  # 2000 milliseconds (2 seconds)

get-cluster | fl *subnet*

CrossSubnetDelay      : 2000
CrossSubnetThreshold  : 20
SameSubnetDelay       : 2000
SameSubnetThreshold   : 10

考虑以下情况：

• 此项更改会立即生效，无需重启群集或任何资源。
• 相同的子网值不应大于跨子网值。
• SameSubnetThreshold = CrossSubnetThreshold
• 同子网延迟 = 跨子网延迟

根据应用程序、业务需求和环境，基于可容许的停机时间以及在采取纠正措施之前问题可持续的时间选择宽松值。 如果无法超过默认Windows Server 2019值，请至少尝试匹配它们（如果可能）：

下表详细说明了默认值供用户参考：

有关详细信息，请参阅优化故障转移群集网络阈值。

放松监控

如果根据建议优化群集检测信号和阈值设置不能实现足够的容许度，并且仍然发现暂时性问题（而不是真正的服务中断）导致故障转移，则可以将 AG 或 FCI 监视配置为更宽松的设置。 在某些场景中，在活动级别一定的情况下，将监视暂时放宽一段时间可能很有利。 例如，在执行数据库备份、索引维护、DBCC CHECKDB 等 IO 密集型工作负载时，你可能想要放宽监视。活动完成后，将监视设置为不太宽松的值。

首先，将以下参数在其默认值的基础上增大以放宽监视，并根据需要进行调整：

使用 Transact-SQL（T-SQL、sysadmin 或 ALTER AVAILABILITY GROUP 权限）修改 AG 和 FCI 的运行状况检查和故障条件。

对于可用性组：

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT = 60000);  -- 60000 milliseconds (60 seconds)
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

预期输出：命令成功完成。

对于故障转移群集实例（需要 sysadmin 或 ALTER SETTINGS 权限）：

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;  -- 60000 milliseconds (60 seconds)
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

预期输出：命令成功完成。

具体对于可用性组而言，请从以下建议的参数开始，并根据需要进行调整：

在更改之前请注意以下事项：

• 不要将任何超时值降低到默认值以下。
• 使用以下公式计算最大租用超时值：。
  从 40 秒（40000 毫秒）开始。 如果您使用的是之前建议的宽松 和 值，租约超时值不应超过 80 秒（80000 毫秒）。
• 对于同步提交副本，将会话超时更改为较大值可以增大 HADR_sync_commit 等待时间。

租约超时

使用 故障转移群集管理器（需要群集管理员，仅在调优时为可选）修改可用性组的 租约超时 设置。 有关详细步骤，请参阅 SQL Server 可用性组租约运行状况检查文档。

会话超时

使用 Transact-SQL（T-SQL，sysadmin 权限或 ALTER AVAILABILITY GROUP 权限（仅在调整性能时可选））来修改可用性组的 会话超时设置：

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);  -- 20 seconds

预期输出：命令成功完成。

指定时段内的最大故障次数

使用故障转移群集管理器（需要群集管理员，调优为可选项）来修改 在指定时间段内的最大失败次数值：

1. 在导航窗格中选择“角色”。
2. 在“角色”下，右键单击群集资源并选择“属性” 。
3. 选择“故障转移”选项卡，并根据需要增大“指定时段内的最大故障次数”值。

资源限制

VM 或磁盘限制可能会导致影响群集运行状况并妨碍运行状况检查的资源瓶颈。

识别资源瓶颈

• 监视 存储 IO 利用率指标 ，以了解 VM 或磁盘级别的延迟。
• 确保 OS、驱动程序和SQL Server处于最新版本。

优化SQL Server环境

• 按照性能指南中有关在 Azure 虚拟机上优化 SQL Server 的说明，优化您的 Azure VM 环境。
• 减少或分散工作负荷以减少利用率，而不会超出资源限制。

优化SQL Server工作负荷

当有机会提高SQL Server工作负荷性能时：

• 添加或优化索引以提高查询效率。
• 如有需要并在可能的情况下，使用完全扫描更新统计信息。
• 使用资源调控器（从 2014 年 SQL Server 2014 开始，仅限企业）等功能限制特定工作负荷期间的资源利用率，例如备份或索引维护。

缩放 VM 或磁盘资源

迁移到限制更高的 VM 或磁盘，以满足甚至超过工作负载的需求。

网络

有关将SQL Server VM 部署到多个子网以避免依赖于Azure 负载均衡器或分布式网络名称（DNN）的指南，请参阅 Connectivity 部分。

每个服务器（群集节点）使用单个 NIC。 Azure网络具有物理冗余，这使得Azure虚拟机来宾群集上不需要额外的 NIC。 群集验证报告上有警告，提示你只能在一个网络上访问节点。 可以忽略Azure虚拟机来宾故障转移群集上的此警告。

特定 VM 的带宽限制在 NIC 之间共享，添加额外的 NIC 不会提高Azure VM 上SQL Server的可用性组性能。 因此，无需添加第二个 NIC。

Azure中不符合 RFC 的 DHCP 服务可能会导致创建某些故障转移群集配置失败。 失败的原因是为群集网络名称分配了重复的 IP 地址，例如与某个群集节点相同的 IP 地址。 这是一个在使用依赖于Windows故障转移群集功能的可用性组时出现的问题。

创建两节点群集并使其联机时，请考虑此应用场景：

1. 群集联机，NODE1 随后会为群集网络名称请求一个动态分配的 IP 地址。
2. DHCP 服务除了 NODE1 自身的 IP 地址以外不提供任何 IP 地址，因为 DHCP 服务可以识别请求是否来自 NODE1 自身。
3. Windows检测到重复地址被同时分配给NODE1和故障转移群集的网络名称，导致默认群集组无法上线。
4. 默认群集组会移动到 NODE2。 NODE2 将 NODE1 的 IP 地址作为群集 IP 地址，并使默认群集组联机。
5. 当 NODE2 尝试与 NODE1 建立连接时，针对 NODE1 的数据包从不离开 NODE2，因为后者将 NODE1 的 IP 地址解析为其自身。 NODE2 无法与 NODE1 建立连接，它会丢失仲裁并关闭群集。
6. NODE1 可向 NODE2 发送数据包，但 NODE2 无法回复。 NODE1 丢失仲裁并关闭群集。

可以通过将未使用的静态 IP 地址分配给群集网络名称来使群集网络名称联机，并将 IP 地址添加到 Azure 负载均衡器来避免这种情况。

配置探测端口

在使用 Azure 负载均衡器支持虚拟网络名称（仅限单一子网部署，且需要群集管理员）时，您必须将群集配置为响应 Always On 可用性组侦听器 或 故障转移群集实例 的运行状况探测请求。 如果运行状况探测无法从后端实例获取响应，则在 运行状况探测再次成功之前，不会向该后端实例发送新连接。

配置排除端口

如果使用虚拟网络名称 (VNN) 资源与 Azure 负载均衡器配合使用（适用于单个子网部署、需要 Windows Server 2012+ 及群集管理员），并且使用的健康探测端口介于 49,152 和 65,536（即 TCP/IP 的默认动态端口范围），那么必须为 Always On 可用性组侦听器 或 故障转移群集实例 配置端口排除。

设置端口排除可防止事件发生，例如 事件 ID：1069，状态为 10048，这可能是由于内部进程占用了定义为探测端口的端口而导致的。

以下示例显示了群集日志中状态为 10048 的事件 ID 1069：

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**

如果应用程序尝试将套接字绑定到已用于现有套接字的 IP 地址/端口，则会出现状态 10048。

已知问题

查看一些常见已知问题和错误的解决方法。

资源争用导致故障转移

VM 的 I/O 或 CPU 容量耗尽可能会导致可用性组进行故障转移。 确定在故障转移之前所发生的争用是确定导致自动故障转移的原因的最可靠方法。

监视 VM 存储指标

Monitor Azure 虚拟机 查看 Storage IO 使用率指标以了解 VM 或磁盘级别延迟。

按照以下步骤来查看Azure VM 总体 IO 耗尽事件（需要 Azure 参与者或读者角色）：

1. 在 Azure 门户中导航到 虚拟机 - 而不是 SQL 虚拟机。

2. 选择“监视”下的 “指标”以打开“指标”页。

3. 选择“本地时间”以指定你感兴趣的时间范围和时区（VM 本地时间或 UTC/GMT）。

   Azure 门户中“指标”页面的屏幕截图，选择更改图表的时间范围。

4. 选择“添加指标”，添加以下两个指标以查看图形：

   • 已使用的 VM 缓存带宽百分比
   • 已使用的 VM 未缓存带宽百分比

Azure VM HostEvents 会导致故障转移

Azure VM HostEvent 可能会导致可用性组进行故障转移。

检查Azure Monitor活动日志

Azure Monitor活动日志提供订阅级事件的见解，包括修改资源或启动虚拟机的时间。 可以在Azure门户中查看活动日志，或使用 PowerShell 和Azure CLI检索条目。

若要检查Azure Monitor活动日志（需要Azure读取者角色），请执行以下步骤：

1. 在 Azure 门户中导航到虚拟机

2. 在“虚拟机”窗格上选择“活动日志”

3. 选择“时间跨度”，然后选择可用性组故障转移的时间范围。 选择应用。

   Azure门户的活动日志屏幕截图。

检查资源健康

如果 Azure 有关于平台启动不可用的根本原因的更多信息，这些信息可能会在初始不可用后的 72 小时内发布在 Azure VM - 资源运行状况 概述页面上。 此信息目前仅适用于虚拟机。

若要检查资源运行状况，请执行以下步骤：

1. 在 Azure 门户中导航到虚拟机
2. 在Health窗格中选择资源运行状况。

您还可以根据此页面的健康事件配置警报。

从成员身份中删除了群集节点

如果 Windows 群集心跳和阈值设置对您的环境过于激进，您可能会遇到群集成员身份问题。

症状

系统事件日志中可能会经常看到以下消息：

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

有关详细信息，请查看排查事件 ID 为 1135 的群集问题。

租约过期错误

如果监视对环境过于咄咄逼人，则可能会看到频繁的可用性组或 FCI 重启、故障或故障转移。

症状

对于可用性组，可能会在SQL Server错误日志中看到以下消息：

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

决议

根据 “宽松监视 ”部分中所述调整监视设置。

连接超时错误

如果 会话超时 对可用性组环境过于咄咄逼人，则可能会遇到连接失败。

症状

你可能会经常看到以下消息：

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

决议

根据 “宽松监视 ”部分中所述调整会话超时。

未故障转移的组

如果“指定时段内的最大故障次数”值太小，并且暂时性问题导致了间歇性故障，则可用性组最终可能会进入故障状态。

症状

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

决议

调整监控、会话超时，并增加特定时间段内的最大故障次数值，以容忍更多的暂时性故障。

事件 1196 - 网络名称资源注册失败

决议

• 检查每个群集节点的 NIC 设置，确保不存在外部 DNS 记录。
• 确保群集的 A 记录存在于内部 DNS 服务器上。 否则，请在群集访问控制对象的 DNS 服务器中手动创建新的 A 记录，并检查“允许任何经过身份验证的用户使用相同的所有者名称更新 DNS 记录”。
• 将带有 IP 资源的资源“群集名称”脱机并修复它。

事件 157 - 磁盘已意外删除

原因

这种情况可能发生在以下情况下：

• 存储空间属性 在 AG 环境中设置为 。
• 使用“存储”选项运行验证报告可能会触发磁盘重置或意外删除事件。
• 存储系统 限制 可能会触发磁盘意外删除事件。

决议

将存储空间属性 更改为 .

事件 1206 - 群集网络名称资源无法联机

原因

与资源相关联的计算机对象无法在域中更新。

决议

请确保你 对域具有适当的权限。

Windows 群集错误

群集连接问题

如果没有打开 群集服务端口以进行通信，在设置 Windows 故障转移群集或其连接时可能会遇到问题。

Windows Server 2019 上缺少 Windows 群集的 IP 地址

如果您使用的是 Windows Server 2019 并且没有看到 Windows 群集 IP，那么您已配置了Distributed Network Name，该名称仅在 SQL Server 2019 上受支持。 如果您有以前版本的SQL Server，您可以使用网络名称移除和重新创建群集。

其他资源

查看其他 Windows 故障转移群集系统日志事件及其解决方案。

后续步骤

若要了解更多信息，请参阅以下文章：

• Azure VM 上SQL Server的 HADR 设置
• 在 Azure 虚拟机上运行 SQL Server 的 Windows Server 故障转移群集
• 带有 SQL Server 的 Azure VM 上的 Always On 可用性组
• 在 Azure 虚拟机上运行 SQL Server 的 Windows Server 故障转移群集
• 在 Azure VM 上具有SQL Server的Failover 群集实例
• 故障转移群集实例概述