Always On 可用性组的租约、群集和运行状况检查超时机制与指南

硬件、软件和群集配置的差异以及运行时间和性能的不同应用程序要求需要针对租用、群集和运行状况检查超时值进行特定配置。 某些应用程序和工作负载需要更积极的监控才能限制硬故障后的停机时间。 另一些则需要对暂时性的网络问题以及因资源使用率高而产生的等待有更高的容忍度,并且可以接受较慢的故障转移。

每个节点上的多个服务都可以检测故障。 群集服务可以检测仲裁丢失,资源 DLL 可以检测由 Always On 运行状况检测呈现的问题,也可以直接在主实例上启动手动故障转移。 群集服务、资源主机和 SQL Server 实例通过 RPC、共享内存和 T-SQL 相互同步。 在大多数情况下,这些服务能够成功通信,但即使在同一台计算机上的服务之间,该通信也不是完全可靠的。 此外,可用性组 (AG) 需要能够承受系统范围的事件(如网络和磁盘故障),这可能会阻止通信或中断功能。 由于许多故障情况和服务之间没有完全可靠的通信,AG 依赖于各种故障转移检测机制来相互独立地检测和响应故障,因此群集状态对于所有节点来说始终保持一致。

SQL Server 2025 运行状况检查的超时诊断能力得到改进

CPU、磁盘延迟或内存耗尽等资源约束可能会触发 AlwaysOn 可用性组租约超时。 在群集日志中报告租约超时时,Windows 故障转移群集日志中报告 CPU 利用率、内存利用率和磁盘读取和写入延迟的最新性能监视器数据以及租约超时。

同样,资源限制也可能引发健康检查超时。 从 SQL Server 2025(17.x)开始,当检测到运行状况检查超时时,Windows 故障转移群集日志现在会报告相同的性能监视计数器,这与租用超时诊断输出类似。

下面是针对健康检查超时的改进版 Windows 故障转移群集日志输出示例:

[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 ERR   [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] AG health check failed, logging perf counter data collected so far
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:25.0, 21.857418, 3248349184.000000, 0.000000, 0.000253
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:35.0, 11.442071, 3255394304.000000, 0.000907, 0.000382
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:45.0, 9.979768, 3253981184.000000, 0.000415, 0.000549
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:55.0, 9.762850, 3251232768.000000, 0.001989, 0.000638
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:56:5.0, 9.827234, 3250462720.000000, 0.002250, 0.001418

群集节点和资源检测

群集中的每个节点都运行一个群集服务,该服务运行故障转移群集并监视所有群集资源。 资源主机作为单独的进程运行,并且是群集服务和群集资源之间的接口。 资源主机在群集服务调用时对群集资源执行操作。 群集感知应用程序(如 SQL Server)通过资源 DLL 提供到资源监视器的自定义接口。 资源 DLL 实现自定义资源的联机和脱机操作和运行状况监视。 资源主机是群集服务的子进程,并在群集服务终止时被终止。

对于 SQL Server 而言,AG 资源 DLL 会根据 AG 租约机制和 Always On 运行状况检测来确定 AG 的运行状况。 AG 资源 DLL 通过 IsAlive 操作提供资源运行状况信息。 资源监视器按照群集心跳间隔轮询 IsAlive,该间隔由 CrossSubnetDelaySameSubnetDelay 这两个群集范围的值设置。 在主节点上,每当对资源 DLL 的 IsAlive 调用返回 AG 处于不正常状态时,群集服务就会发起故障转移。

群集服务向群集中的其他节点发送心跳,并确认收到它们发来的心跳。 当一个节点通过一系列未获确认的心跳检测到通信故障时,它会广播一条消息,使所有可达节点就集群节点健康状态的看法达成一致。 这个称为 “重组事件”的事件会保持所有节点的群集状态的一致性。 发生重新编组事件后,如果失去仲裁,则此分区中的所有群集资源(包括 AG)都将转为脱机状态。 该分区中的所有节点都转换为解析状态。 如果存在一个保留仲裁的分区,则 AG 将分配给该分区中的一个节点并成为主副本,而所有其他节点将成为辅助副本。

Always On 运行状况检测

Always On 资源 DLL 监视内部 SQL Server 组件的状态。 sp_server_diagnostics 在由 HealthCheckTimeout 控制的时间间隔内报告这些 SQL Server 组件的运行状况。 sp_server_diagnostics 报告五个实例级别组件的运行状况:系统、资源、查询处理、io 子系统和事件。 它还报告每个 AG 的运行状况。 每次更新时,资源 DLL 根据 AG 的故障级别更新 AG 资源的运行状况。 当数据由 sp_server_diagnostics 返回时,它会将每个组件显示为干净、警告、错误或未知状态,并使用一些描述组件状态的 XML 数据。 对于运行状况检测,资源 DLL 仅在组件处于错误状态时才采取行动。

如果运行状况检测无法报告资源 DLL 在多个时间间隔内的更新,那么 AG 将被视为运行不正常,并将报告有关 IsAlive 调用的故障。

租用机制

与其他故障转移机制不同,SQL Server 实例在租用机制中发挥着积极的作用。 租约机制用作群集资源主机与 SQL Server 进程之间的“Looks-Alive”验证。 该机制用于确保双方(群集服务器和 SQL Server 服务)通信频繁,检查彼此的状态并最终避免出现裂脑情况。 将 AG 作为主副本联机时,SQL Server 实例会为 AG 创建一个专用的租约工作线程。 租约工作进程与资源主机共享一小块内存区域,其中包含租约续订和租约停止事件。 租约工作线程和资源宿主以循环方式运行,分别发出各自租约续订事件的信号,然后进入休眠状态,等待对方发出其租约续订事件或停止事件的信号。 资源主机和 SQL Server 租用线程都会维护一个生存时间值,每次线程在由另一个线程发出信号后唤醒时都会更新这个值。 如果在等待信号期间达到生存时间 (TTL) 上限,则租约会到期,随后副本对于该特定 AG 将转入解析状态。 如果发出信号通知租用停止事件,则副本将转换为解析角色。

显示资源运行状况 DLL 与 SQL Server 之间的通信的关系图。

租用机制强制执行 SQL Server 和 Windows Server 故障转移群集之间的同步。 发出故障转移命令时,群集服务会对当前主副本的资源 DLL 进行 Offline 调用。 资源 DLL 首先尝试通过存储过程将 AG 置于脱机状态。 如果此存储过程失败或超时,则会将失败报告回群集服务,然后发出终止命令。 终止操作会再次尝试执行相同的存储过程,但这一次,群集不会等待资源 DLL 报告成功或失败,就会在新的副本上将 AG 联机。 如果第二个过程调用失败,那么资源主机将不得不依赖租用机制使实例脱机。 当资源 DLL 被调用以使 AG 脱机时,资源 DLL 会发出租约停止事件信号,从而唤醒 SQL Server 租约工作线程以使 AG 脱机。 即使未发出停止事件的信号,租用也将过期,并且副本将转换为解析状态。

租约主要是主实例与群集之间的一种同步机制,但它也可能在原本无须进行故障转移的情况下导致故障。 例如,高 CPU 使用率、内存不足情况(虚拟内存低、进程分页)、SQL 进程在生成内存转储时无响应、系统无响应、群集 (WSFC) 脱机(例如由于失去仲裁)等,都可能阻止 SQL 实例续订租约,并导致重启或故障转移。

群集超时值指南

仔细考虑权衡之策并了解对 SQL Server 群集进行不太积极的监视的后果。 增加群集超时值将增加对临时网络问题的容忍度,但会减慢对硬故障的反应。 为了应对资源压力或较大的地理延迟而增大超时时间,也会增加从严重故障或不可恢复故障中恢复所需的时间。 虽然这对许多应用程序都是可以接受的,但在任何情况下都不是理想之选。

默认设置经过优化,可以快速响应硬故障症状并限制停机时间,但这些设置对于某些工作负载和配置也可能过于积极。 不建议将 LeaseTimeoutCrossSubnetDelayCrossSubnetThresholdSameSubnetDelaySameSubnetThresholdHealthCheckTimeout 中的任何一项降低到默认值以上。 每个部署的正确设置会有所不同,可能需要较长时间的微调才能发现。 在对这些值进行更改时,请逐步进行并考虑这些值之间的关系和依赖关系。

群集超时与租约超时之间的关系

租约机制的主要功能是:如果群集服务在执行到另一节点的故障转移过程中无法与该实例通信,则使 SQL Server 资源脱机。 当群集对 AG 群集资源执行脱机操作时,群集服务会对 rhs.exe 执行 RPC 调用以使资源脱机。 资源 DLL 通过存储过程通知 SQL Server 将 AG 置于脱机状态,但该存储过程可能会失败或超时。资源主机还会在执行脱机操作调用期间停止其自身的租约续订线程。 在最坏的情况下,SQL Server 将导致租用在 ½ * LeaseTimeout 内过期并将实例转换为解析状态。 故障转移可由多个不同的参与方发起,但至关重要的是,在整个群集内以及各 SQL Server 实例之间,对群集状态的认知必须保持一致。 例如,假设主实例与群集其余部分失去连接。 由于群集超时值,群集中的每个节点都会在相似时间确定故障,但只有主节点可以与主 SQL Server 实例交互以强制它放弃主角色。

从主节点的角度来看,群集服务将丢失仲裁,服务将开始自行终止。 群集服务将对资源主机发出一个 RPC 调用来终止该进程。 此终止调用负责让 AG 在 SQL Server 实例上脱机。 此脱机调用通过 T-SQL 完成,但不能保证 SQL 和资源 DLL 之间的连接将成功建立。

从集群其余部分的角度来看,当前不存在主副本,因此集群会进行投票,并在集群中的其余节点中选出一个新的主副本。 如果由资源 DLL 调用的存储过程失败或超时,则群集可能容易受“裂脑”情况的影响。

租约超时可防止在发生通信错误时出现脑裂情况。 即使所有通信都失败,资源 DLL 进程也会终止并无法更新租用。 一旦租约到期,它会自动使 AG 脱机。 SQL Server 的实例需要知道,在群集建立新副本之前,它不再托管主副本。 由于负责选择新的主副本的群集的其余部分无法与当前的主副本协调,因此超时值可确保在当前的主副本自行脱机之前不会创建新的主副本。

当群集发生故障转移时,承载先前主副本的 SQL Server 实例必须先进入解析状态,然后新的主副本才能联机。 任何时候 SQL Server 租用线程的剩余生存时间为 ½ * LeaseTimeout,因为无论何时续租,新的生存时间将更新为 LeaseInterval 或 ½ * LeaseTimeout。 如果群集服务或资源主机无响应或终止,且未发出租约停止事件信号,则群集将在 SameSubnetThreshold\ SameSubnetDelay 毫秒后宣布主节点已失效。 在此期间,租约必须到期,以确保主节点必定已离线。 由于租约超时的最大生存时间为 ½ * LeaseTimeout,因此 ½ * LeaseTimeout 必须小于 SameSubnetThreshold * SameSubnetDelay

SameSubnetThreshold \<= CrossSubnetThresholdSameSubnetDelay \<= CrossSubnetDelay 应适用于所有 SQL Server 群集。

运行状况检查超时操作

运行状况检查超时更具灵活性,因为没有任何其他故障转移机制直接依赖它。 默认值 30 秒将 sp_server_diagnostics 间隔设置为 10 秒,超时和间隔的最小值分别为 15 秒和 5 秒。 一般来说,sp_server_diagnostics 更新间隔始终为 1/3 * HealthCheckTimeout。 如果资源 DLL 在一个时间间隔内都没有收到一组新的运行状况数据,则它将继续使用前一时间间隔的运行状况数据来确定当前的 AG 和实例运行状况。 增加运行状况检查超时值会增加主群集对 CPU 压力的容忍度,这可能会阻止 sp_server_diagnostics 在每个时间间隔内提供新数据,但它依赖过时数据运行状况检查的时间更长。 无论超时值如何,收到数据表明副本不正常后,下个 IsAlive 调用将返回实例不正常,群集服务将启动故障转移。

AG 的故障条件级别更改了健康检查的故障条件。 对于任何失败级别,如果 AG 元素被 sp_server_diagnostics 报告为不正常,则运行状况检查将失败。 每个级别从它下面的级别继承所有失败条件。

级别 实例被视为失效的条件
1: OnServerDown 如果除 AG 之外的资源出现故障,运行状况检查不会采取任何措施。 如果在 5 个间隔内未接收到 AG 数据,或 5/3 * HealthCheckTimeout
2: OnServerUnresponsive 如果在 HealthCheckTimeout 时间内未从 sp_server_diagnostics 收到数据
3: OnCriticalServerError (默认)如果系统组件报告错误
4: OnModerateServerError 如果资源组件报告错误
5:在任一符合条件的失败情况下 如果查询处理组件报告错误

更新群集和 Always On 的超时值

群集值

WSFC 配置中有四个值负责确定群集超时值:

  • 同子网延迟
  • 同一子网阈值
  • 跨子网延迟
  • 跨子网阈值

延迟值决定群集服务心跳信号之间的等待时间,而阈值则用于设置这样的心跳次数:如果来自目标节点或资源的心跳在达到该次数前仍未收到确认,群集就会将该对象判定为失效。 如果同一子网中的节点之间持续超过 SameSubnetDelay \* SameSubnetThreshold 毫秒没有成功的心跳,则该节点会被判定为已失效。 使用跨子网值进行的跨子网通信也是如此。

要列出当前所有群集值,请在目标群集的任何节点上打开提升的 PowerShell 终端。 运行以下命令:

 Get-Cluster | fl *

要更新其中任意值,请在提升的 PowerShell 终端中运行以下命令:

(Get-Cluster).<ValueName> = <NewValue>

为提高集群超时的容忍度而增大延迟与阈值的乘积时,最好先增大延迟值,再增大阈值。 通过增加延迟,每次心跳之间的时间间隔会增加。 心跳之间的间隔越长,暂时性的网络问题就越有时间自行恢复;而且与在同一时间段内发送更多心跳相比,这样还能减少网络拥塞。

租约超时

租约机制由 WSFC 群集中每个 AG 特有的单个值控制。 租约超时可能会引发以下错误:

Error 35201:
A connection timeout has occurred while attempting to establish a connection to availability replica 'replicaname'
Error 35206:
A connection timeout has occurred on a previously established connection to availability replica 'replicaname'

若要修改租约超时值,请使用故障转移群集管理器,并按照以下步骤操作:

  1. 在“角色”选项卡中,找到目标 AG 角色。 选择目标 AG 角色。

  2. 右键单击窗口底部的 AG 资源,然后选择“属性” 。

    故障转移群集管理器的屏幕截图。

  3. 在弹出窗口中,导航到“属性”选项卡,即可查看一个特定于此 AG 的值列表。 选择 LeaseTimeout 值以更改它。

    可用性组属性的屏幕截图。

    根据 AG 的配置,可能会为侦听器、共享磁盘、文件共享等提供额外资源,这些资源不需要任何其他配置。

注意

属性“LeaseTimeout”的新值将在资源脱机并再次联机时生效。

运行状况检查值

两个值控制 AlwaysOn 运行状况检查:FailureConditionLevel 和 HealthCheckTimeout。 FailureConditionLevel 指示由 sp_server_diagnostics 报告的特定故障条件的容差级别,HealthCheckTimeout 配置资源 DLL 可以在没有从 sp_server_diagnostics 接收更新的情况下运行的时间。 sp_server_diagnostics 的更新间隔始终为 HealthCheckTimeout/3。

要配置故障转移条件级别,请使用 FAILURE_CONDITION_LEVEL = <n>CREATEALTER 语句的 AVAILABILITY GROUP 选项,其中 <n> 是 1 到 5 之间的整数。 以下命令将 AG 'AG1' 的故障条件级别设置为 1:

ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);

要配置运行状况检查超时,请使用 CREATEALTERAVAILABILITY GROUP 语句的 HEALTH_CHECK_TIMEOUT 选项。 以下命令将 AG AG1 的运行状况检查超时设置为 60000 毫秒:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);

超时指南概述

  • 建议不要将任何超时值降低到默认值以下。

  • 租用时间间隔 (½ * LeaseTimeout) 必须短于 SameSubnetThreshold * SameSubnetDelay

  • SameSubnetThreshold = CrossSubnetThreshold <

  • 同子网延迟 <= 跨子网延迟

超时设置 目的 介于 用途 IsAlive 和 LooksAlive 原因 结果
租约超时
默认值:20000
防止脑裂 主站点到群集
(HADR)
Windows 事件对象 用于两者 OS 无响应、虚拟内存不足、工作集分页、生成转储、限定 CPU、WSFC 故障(失去仲裁) AG 资源脱机-联机、故障转移
会话超时
默认值:10000
就主副本和辅助副本之间的通信问题进行通知 从辅助切换到主
(HADR)
TCP 套接字(通过 DBM 端点发送的消息) 二者都不使用 网络通信,
辅助节点问题 - 宕机、操作系统无响应、资源争用
次要 - 已断开连接
健康检查超时
默认值:30000
指示尝试确定主副本的运行状况时超时 群集到主副本
(FCI 和 HADR)
T-SQL sp_server_diagnostics 二者均使用 满足故障条件、操作系统无响应、虚拟内存不足、工作集收缩、生成转储、WSFC(失去仲裁)、调度程序问题(发生死锁的调度程序) AG 资源脱机-联机或故障转移、FCI 重启/故障转移