Механизмы и рекомендации по тайм-аутам аренды, кластера и проверки работоспособности для групп доступности Always On

Различия в оборудовании, программном обеспечении и конфигурации кластеров, а также различные требования ко времени бесперебойной работы и производительности приложений обуславливают различные значения времени ожидания для аренды, кластера и проверки работоспособности. Для определенных приложений и рабочих нагрузок требуется более интенсивный мониторинг с целью снижения времени простоя после серьезных сбоев. Для других приемлемы большая устойчивость к кратковременным сетевым сбоям и задержкам из-за высокой нагрузки на ресурсы, а также более медленное переключение при отказе.

Для выявления сбоев на каждом узле работает несколько служб. Служба кластера может обнаружить потерю кворума, библиотека DLL ресурса может обнаружить проблему, выявленную механизмом проверки работоспособности Always On, или ручное переключение при отказе может быть инициировано непосредственно на основном экземпляре. Служба кластера, хост ресурса и экземпляр SQL Server синхронизируются друг с другом через RPC, общую память и T-SQL. В большинстве случаев эти службы успешно взаимодействуют, однако эта связь не является совершенно надежной даже между службами на одном компьютере. Кроме того, группа доступности (AG) должна выдерживать сбои, затрагивающие всю систему, такие как сбои сети и дисковой подсистемы, которые могут препятствовать обмену данными или нарушать работу. Из-за разнообразия вариантов сбоев и отсутствия надежного способа взаимодействия между службами группа доступности использует различные механизмы обнаружения перехода на другой ресурс, способные определять сбои и реагировать на них независимо друг от друга, таким образом, состояние кластера всегда является согласованным для всех узлов.

Диагностика тайм-аута проверки работоспособности в SQL Server 2025 была улучшена.

Ограничения ресурсов, такие как высокая загрузка ЦП, задержка дисковой системы или исчерпание памяти, могут вызвать таймаут аренды в группе доступности Always On. Когда время ожидания аренды сообщается в журнале кластера, последние данные мониторинга производительности, такие как использование ЦП, использование памяти и задержка операций чтения и записи на дисках, фиксируются в журнале отказоустойчивости кластера Windows вместе с временем ожидания аренды.

Аналогичным образом, ограничения ресурсов также могут привести к тайм-ауту проверки состояния. Начиная с 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, предоставляют пользовательские интерфейсы для монитора ресурсов с использованием библиотек ресурсов. Библиотека ресурсов реализует сетевые и автономные операции и мониторинг работоспособности для пользовательских ресурсов. Хост ресурса — это дочерний процесс службы кластера и принудительно завершается всякий раз, когда завершается служба кластера.

Для SQL Server библиотека ресурсов AG определяет работоспособность AG на основе механизма аренды AG и механизма обнаружения работоспособности Always On. DLL ресурсов AG предоставляет данные о состоянии работоспособности ресурса через операцию IsAlive. Монитор ресурсов опрашивает IsAlive с интервалом пульса кластера, который задаётся общекластерными значениями CrossSubnetDelay и SameSubnetDelay. На основном узле служба кластера инициирует переключение при отказе всякий раз, когда вызов IsAlive к библиотеке DLL ресурса возвращает, что группа доступности неисправна.

Служба кластера отправляет сигналы активности другим узлам кластера и подтверждает получение сигналов активности от них. Если после серии неподтверждённых heartbeat-сообщений узел обнаруживает сбой связи, он рассылает широковещательное сообщение, побуждая все достижимые узлы согласовать свои представления о состоянии работоспособности узлов кластера. Это событие, которое называется событием перегруппирования, поддерживает согласованное состояние кластера для всех узлов. После события перегруппировки при потере кворума все ресурсы кластера, включая группы доступности (AG) в этом разделе, переводятся в автономный режим. Все узлы в этом разделе переведены в состояние разрешения. Если существует раздел, обладающий кворумом, группа доступности назначается одному из узлов в этом разделе, и этот узел становится первичной репликой, а все остальные узлы становятся вторичными репликами.

Проверка работоспособности Always On

DLL библиотеки ресурсов Always On отслеживает состояние внутренних компонентов SQL Server. sp_server_diagnostics передает сведения о работоспособности этих компонентов SQL Server с интервалом, определяемым HealthCheckTimeout. sp_server_diagnostics сообщает о состоянии пяти компонентов уровня экземпляра: система, ресурсы, обработка запросов, подсистема ввода-вывода и события. Также сообщает о состоянии каждого AG. После каждого изменения библиотека ресурсов обновляет состояние работоспособности ресурса группы доступности на основе уровня сбоя группы доступности. Когда данные возвращаются sp_server_diagnostics, каждый компонент отображается как находящийся в исправном, предупреждающем, ошибочном или неизвестном состоянии, при этом некоторые XML-данные описывают состояние компонента. При проверке работоспособности библиотека ресурсов предпринимает действия только в том случае, если компонент находится в состоянии сбоя.

Если проверка работоспособности не сообщает об обновлении DLL ресурса в течение нескольких интервалов, AG считается неработоспособной и будет сообщать об ошибках при вызовах IsAlive.

Механизм аренды

В отличие от остальных механизмов перехода на другой ресурс, в работе механизма аренды активную роль играет экземпляр SQL Server. Механизм аренды служит для проверки работоспособности "Looks-Alive" между узлом-владельцем ресурса кластера и процессом SQL Server. Этот механизм используется для обеспечения того, чтобы обе стороны (служба кластеров и служба SQL Server) регулярно поддерживали связь, проверяя состояние друг друга и в конечном итоге предотвращая сценарий split-brain. При переводе группы доступности в оперативный режим в качестве первичной реплики экземпляр SQL Server запускает выделенный рабочий поток аренды для группы доступности. Рабочий процесс аренды совместно с узлом ресурса использует небольшой участок памяти, в котором содержатся события продления аренды и остановки аренды. Рабочий процесс аренды и хост ресурса работают циклически: каждый подает сигнал о своем событии продления аренды, а затем переходит в режим ожидания, пока другая сторона не подаст сигнал о своем событии продления аренды или событии остановки. Как у узла ресурса, так и у рабочего потока аренды SQL Server есть срок жизни. Значение срока жизни изменяется каждый раз, когда поток выходит из спящего режима, получив сигнал от другого потока. Если время жизни истекает во время ожидания сигнала, аренда истекает, а затем реплика переходит в состояние разрешения для этой конкретной группы доступности. Если поступает сигнал о прекращении аренды, реплика переходит в состояние разрешения.

Механизм аренды использует принудительную синхронизацию между SQL Server и отказоустойчивым кластером Windows Server. Когда выдается команда переключения при отказе, служба кластера выполняет вызов Offline к библиотеке DLL ресурсов текущей основной реплики. Библиотека DLL ресурса сначала пытается перевести группу доступности в автономный режим с помощью хранимой процедуры. Если эта хранимая процедура завершается сбоем или истекает время ожидания, сообщение об ошибке передается службе кластера, которая затем выдает команду завершения. При повторном завершении система снова пытается выполнить ту же хранимую процедуру, но на этот раз кластер не ожидает, пока библиотека ресурсов DLL сообщит об успехе или сбое, прежде чем перевести группу доступности в оперативный режим на новой реплике. Если этот второй вызов процедуры завершается неудачей, хост ресурса должен полагаться на механизм аренды, чтобы перевести экземпляр в автономный режим. При вызове библиотеки ресурсов для перевода группы доступности в автономный режим библиотека ресурсов отправляет событие прекращения аренды, которое выводит рабочий поток аренды SQL Server из спящего режима, и он переводит группу доступности в автономный режим. Даже если сигнал об этом событии остановки не будет получен, срок аренды истечет, а реплика перейдет в состояние разрешения.

Аренда в первую очередь является механизмом синхронизации между основным экземпляром и кластером, но она также может создавать условия отказа даже тогда, когда в противном случае аварийное переключение не потребовалось бы. Например, высокая загрузка ЦП, состояния нехватки памяти (нехватка виртуальной памяти, активная подкачка), отсутствие ответа процесса SQL во время создания дампа памяти, отсутствие ответа системы, а также переход кластера (WSFC) в автономный режим (например, из-за потери кворума) могут помешать продлению аренды экземпляром SQL Server и вызвать перезапуск или аварийное переключение.

Рекомендации по значениям времени ожидания кластера

Тщательно проанализируйте компромиссы и последствия при использовании менее интенсивного мониторинга вашего кластера SQL Server. Увеличение значений времени ожидания кластера повышает допустимость временных проблем сети, но замедляет реакции на жесткие сбои. Увеличение времени ожидания для решения проблем с давлением ресурсов или большой географической задержкой увеличит время восстановления от сложных или невосстановимых сбоев. Хотя это приемлемо для многих приложений, это не идеально во всех случаях.

Параметры по умолчанию оптимизированы для быстрой реакции на симптомы серьезных сбоев и сокращения времен простоя, но эти параметры также могут быть слишком агрессивными для некоторых рабочих нагрузок и конфигураций. Не рекомендуется уменьшать значения LeaseTimeout, CrossSubnetDelay, CrossSubnetThreshold, SameSubnetDelay, SameSubnetThreshold или HealthCheckTimeout ниже значений по умолчанию. Правильные параметры для каждого развертывания различаются и, скорее всего, требуют более длительного периода точной настройки для обнаружения. При внесении изменений в любые из этих параметров делайте это постепенно, с учетом связей и зависимостей между этими параметрами.

Связь между тайм-аутом кластера и тайм-аутом аренды

Основная функция механизма аренды состоит в том, чтобы перевести ресурс SQL Server в автономное состояние, если служба кластера не может взаимодействовать с экземпляром во время переключения при отказе на другой узел. Когда кластер переводит ресурс кластера AG в автономный режим, служба кластера выполняет вызов RPC к rhs.exe, чтобы перевести этот ресурс в автономный режим. Библиотека ресурсов DLL использует хранимые процедуры, чтобы дать SQL Server команду перевести группу доступности (AG) в автономный режим, но эта хранимая процедура может завершиться с ошибкой или по тайм-ауту. Хост ресурса также останавливает собственный поток продления аренды во время вызова перевода в автономный режим. В худшем случае SQL Server вызывает истечение срока аренды через 1/2 * LeaseTimeout и переводит экземпляр в состояние разрешения. Переключение при отказе может быть инициировано различными сторонами, но крайне важно, чтобы представление о состоянии кластера было согласованным во всём кластере и между экземплярами SQL Server. Например, представьте себе ситуацию, в которой основной экземпляр теряет соединение с остальной частью кластера. Каждый узел в кластере обнаруживает сбой примерно в одно и то же время из-за значений тайм-аута кластера, но только первичный узел может взаимодействовать с первичным экземпляром SQL Server, чтобы принудительно заставить его отказаться от первичной роли.

С точки зрения основного узла служба кластера потеряла кворум и служба начинает завершаться. Служба кластера выдает вызов RPC к узлу ресурсов, чтобы завершить процесс. Этот вызов terminate переводит AG в автономный режим на экземпляре SQL Server. Этот вызов в автономном режиме выполняется через T-SQL, однако невозможно гарантировать, что подключение между SQL и DLL ресурса будет успешно установлено.

С точки зрения остальной части кластера в настоящее время нет первичной реплики, поэтому кластер голосует и устанавливает один новый первичный объект для оставшихся узлов в кластере. Если хранимая процедура, вызванная библиотекой DLL ресурсов, завершается сбоем или истекает время ожидания, кластер может быть уязвим для сценария разделения мозга.

Время ожидания аренды позволяет избежать сценария с разделением вычислительных мощностей в случае ошибок связи. Даже при полном нарушении обмена данными процесс библиотеки ресурсов будет завершен и не сможет обновить аренду. После истечения срока аренды группа доступности автоматически переводится в автономный режим. Перед тем как кластер установит новую первичную реплику, экземпляр SQL Server должен знать, что он больше не размещает первичную реплику. Поскольку остальные узлы кластера, отвечающие за выбор новой первичной реплики, не имеют возможности координироваться с текущей первичной репликой, значения тайм-аутов гарантируют, что новая первичная реплика не будет назначена до того, как текущая первичная реплика переведёт себя в автономный режим.

Когда в кластере происходит переключение при отказе, экземпляр SQL Server, на котором размещалась предыдущая первичная реплика, должен перейти в состояние RESOLVING до того, как новая первичная реплика станет доступной. У потока lease в SQL Server в любой момент остаётся время жизни, равное ½ * LeaseTimeout, поскольку при каждом продлении lease новое время жизни обновляется до значения LeaseInterval или ½ * LeaseTimeout. Если служба кластера или узел, размещающий ресурс, перестает отвечать или завершает работу, не сигнализируя о событии прекращения аренды, кластер объявит основной узел недоступным через SameSubnetThreshold\ SameSubnetDelay мс. За это время срок аренды должен истечь, чтобы гарантированно было известно, что основной узел недоступен. Поскольку максимальное время жизни тайм-аута аренды составляет ½ * LeaseTimeout, ½ * LeaseTimeout должно быть меньше SameSubnetThreshold * SameSubnetDelay.

Условия SameSubnetThreshold \<= CrossSubnetThreshold и SameSubnetDelay \<= CrossSubnetDelay должны быть справедливы для всех кластеров SQL Server.

Операция тайм-аута проверки работоспособности

Тайм-аут проверки состояния более гибко настраивается, поскольку от него напрямую не зависит ни один другой механизм аварийного переключения. Значение по умолчанию 30 секунд задает sp_server_diagnostics интервал в 10 секунд с минимальным значением в течение 15 секунд для времени ожидания и 5-секундного интервала. В общем, sp_server_diagnostics интервал обновления всегда равен 1/3 * HealthCheckTimeout. Если библиотека DLL ресурсов не получает новый набор данных о работоспособности в течение очередного интервала, она продолжает использовать данные о работоспособности из предыдущего интервала для определения текущего состояния работоспособности AG и экземпляра. Увеличение значения тайм-аута проверки работоспособности делает основной узел менее чувствительным к высокой загрузке ЦП, которая может помешать sp_server_diagnostics предоставлять новые данные при каждом интервале, однако при этом он дольше опирается на устаревшие данные проверок работоспособности. Независимо от значения времени ожидания, как только будут получены данные, указывающие на то, что реплика неисправна, при следующем вызове IsAlive будет возвращено, что экземпляр неисправен, а служба кластера инициирует переключение при отказе.

Уровень условий сбоя AG изменяет условия сбоя для проверки работоспособности. Для любого уровня сбоя, если элемент AG помечен как неработоспособный компонентом sp_server_diagnostics, проверка работоспособности завершается сбоем. Каждый уровень наследует все условия отказа от нижележащих уровней.

Обновление значений тайм-аута для кластера и Always On

Значения кластера

В конфигурации WSFC есть четыре значения, которые отвечают за определение значений времени ожидания кластера:

• ЗадержкаВТойЖеПодсети (SameSubnetDelay)
• Порог одной подсети
• Задержка между подсетями
• Порог для пересечения подсетей

Значения задержки определяют время ожидания между пульсами из службы кластера, а пороговые значения задают количество пульсов, которые не могут получать подтверждения от целевого узла или ресурса, прежде чем объект объявляется мертвым кластером. Если между узлами в одной подсети нет успешного пульса в течение более чем SameSubnetDelay \* SameSubnetThreshold миллисекунда, узел определяется мертвым. То же самое верно и для межподсетевого взаимодействия с использованием значений для связи между подсетями.

Чтобы перечислить все текущие параметры кластера, на любом узле в целевом кластере откройте консоль PowerShell с повышенными привилегиями. Выполните следующую команду:

 Get-Cluster | fl *

Чтобы изменить любой из этих параметров, выполните следующую команду в консоли PowerShell с повышенными привилегиями:

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

При увеличении произведения параметров «Задержка» * «Пороговое значение», чтобы сделать тайм-аут кластера менее чувствительным, эффективнее сначала увеличить значение задержки, а уже затем — пороговое значение. При увеличении задержки увеличивается интервал между сигналами heartbeat. Больше времени между пульсами дает больше времени для временных сетевых проблем, чтобы устранить себя и уменьшить перегрузку сети относительно отправки большего количества пульса в тот же период.

Тайм-аут аренды

Механизмом аренды управляет один параметр, определяемый для каждой группы доступности в кластере WSFC. Истечение времени аренды может вызвать следующие ошибки:

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. В всплывающем окне перейдите на вкладку свойств, чтобы просмотреть список значений, относящихся к этой группе доступности. Выберите значение LeaseTimeout, чтобы изменить его.

   

   В зависимости от конфигурации группы доступности могут существовать дополнительные ресурсы для прослушивателей, общих дисков, общих папок и т. д. Эти ресурсы не требуют дополнительной настройки.

Значения проверки состояния

Проверку работоспособности AlwaysOn определяют два параметра: FailureConditionLevel и HealthCheckTimeout. FailureConditionLevel указывает уровень допустимости для определенных состояний отказа, о которых сообщает sp_server_diagnostics, а параметр HealthCheckTimeout задает интервал времени, в течение которого библиотека DLL ресурса может не получать обновления от sp_server_diagnostics. Интервал обновления sp_server_diagnostics всегда равен HealthCheckTimeout / 3.

Чтобы настроить уровень условия переключения при отказе, используйте параметр FAILURE_CONDITION_LEVEL = <n> инструкции CREATE или ALTERAVAILABILITY GROUP, где <n> — целое число от 1 до 5. Следующая команда устанавливает уровень условия сбоя равным 1 для AG "AG1":

ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);

Чтобы настроить время ожидания проверки работоспособности, используйте опцию HEALTH_CHECK_TIMEOUT в инструкции CREATE или ALTERAVAILABILITY GROUP. Следующая команда задает время ожидания проверки работоспособности в 60 000 миллисекунд для AG AG1:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);

Сводка рекомендаций по тайм-аутам

• Снижение значений времени ожидания ниже значений по умолчанию не рекомендуется.

• Интервал аренды (½ * LeaseTimeout) должен быть меньше, чем SameSubnetThreshold * SameSubnetDelay

• Порог для той же подсети (SameSubnetThreshold) <= Порог для другой подсети (CrossSubnetThreshold)

• Задержка на той же подсети <= Задержка на другой подсети

Связанный контент

• Активные вторичные реплики: резервное копирование на вторичных репликах (группы доступности Always On)
• ALTER AVAILABILITY GROUP (Transact-SQL)