Поделиться через

Рекомендации по настройке HADR (SQL Server на виртуальных машинах Azure)

  • Статья

Область применения:SQL Server на виртуальной машине Azure

Отказоустойчивый кластер Windows Server используется для обеспечения высокой доступности и аварийного восстановления (HADR) в SQL Server на Виртуальных машинах Azure.

В этой статье приведены рекомендации по конфигурации кластера для экземпляров отказоустойчивого кластера (FCI) и групп доступности при их использовании с SQL Server на виртуальных машинах Azure.

Дополнительные сведения см. в других статьях этой серии: Контрольный список, Размер виртуальной машины, Хранилище, Безопасность, Конфигурация HADR, Сбор базовых показателей.

Контрольный список

Ознакомьтесь со следующим контрольным списком, содержащим краткий обзор рекомендаций по HADR, которые более подробно описываются далее в этой статье.

Возможности HADR (высокая доступность и аварийное восстановление), такие как группы доступности Always On и экземпляр отказоустойчивого кластера, основываются на технологии отказоустойчивости кластеров Windows Server. Изучите современные рекомендации по настройке параметров HADR для работы с облачной средой.

Для кластера Windows примените следующие рекомендации:

  • По возможности развертывайте виртуальные машины SQL Server в нескольких подсетях, чтобы не использовать Azure Load Balancer или имя распределенной сети (DNN) для маршрутизации трафика к решению HADR.
  • Измените параметры кластера на менее жесткие, чтобы избежать непредвиденных перерывов в работе из-за временных сбоев сети или обслуживания платформы Azure. Дополнительные сведения см. в разделе Параметры пульса и порога. Для Windows Server 2012 и более поздних версий используйте следующие рекомендуемые значения:
    • SameSubnetDelay: 1 секунда;
    • SameSubnetThreshold: 40 пульсов;
    • CrossSubnetDelay: 1 секунда;
    • CrossSubnetThreshold: 40 пульсов.
  • Разместите виртуальные машины в группе доступности или в разных зонах доступности. Дополнительные сведения см. в разделе Параметры доступности виртуальной машины.
  • Используйте один сетевой интерфейс для каждого узла кластера.
  • Настройте голосование кворума в кластере так, чтобы использовалось 3 или большее нечетное число голосов. Не назначать голоса регионам DR (аварийного восстановления).
  • Тщательно отслеживайте ограничения ресурсов, чтобы избежать непредвиденных перезапусков или переключений при отказе.
    • Используйте последние сборки ОС, драйверов и SQL Server.
    • Оптимизируйте производительность SQL Server на виртуальных машинах Azure. Ознакомьтесь с остальными разделами этой статьи, чтобы получить дополнительные сведения.
    • Сократите или распределите рабочую нагрузку, чтобы не допустить превышения ограничений для ресурсов.
    • Перейдите на виртуальную машину или диск с более высокими значениями ограничений, чтобы избежать их превышения.

Для группы доступности SQL Server или экземпляра отказоустойчивого кластера учитывайте следующие рекомендации:

  • При частом возникновении непредвиденных сбоев следуйте рекомендациям по повышению производительности, приведенным далее в этой статье.
  • Если оптимизация производительности виртуальной машины SQL Server не устраняет непредвиденные отработки отказа, рассмотрите ослабление мониторинга для группы доступности или экземпляра отказоустойчивого кластера. Однако это может не устранить источник проблемы и может скрыть симптомы, тем самым уменьшая вероятность сбоя. Чтобы устранить первопричину, потребуется провести дополнительный анализ. Для Windows Server 2012 или более поздней версии используйте следующие рекомендуемые значения:
    • Время ожидания аренды: используйте это уравнение для вычисления максимального значения времени ожидания аренды:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Начните с 40 секунд. Если вы используете рекомендованные ранее значения SameSubnetThreshold и SameSubnetDelay, не превышайте 80 секунд для таймаута аренды.
    • Max failures in a specified period (Максимальное число сбоев за указанный период). Задайте значение 6.
  • Если для подключения к решению HADR используется имя виртуальной сети (VNN) и Azure Load Balancer, укажите MultiSubnetFailover = true в строке подключения, даже если кластер включает только одну подсеть.
    • Если клиент не поддерживает MultiSubnetFailover = True, возможно, вам потребуется установить RegisterAllProvidersIP = 0 и HostRecordTTL = 300 для кэширования учетных данных клиента на более короткие промежутки времени. Но это может привести к увеличению числа запросов к DNS-серверу.
  • Чтобы подключиться к решению HADR с использованием распределенного сетевого имени (DNN), рассмотрим следующее:
    • Необходимо использовать драйвер клиента, поддерживающий MultiSubnetFailover = True. Этот параметр должен быть указан в строке подключения.
    • Используйте уникальный порт DNN в параметрах подключения при подключении к слушателю DNN для группы доступности.
  • Используйте строку зеркального подключения базы данных для базовой группы доступности, чтобы избежать необходимости в балансировщике нагрузки или DNN.
  • Проверьте размер сектора VHD перед развертыванием решения высокой доступности, чтобы избежать несогласованных операций ввода-вывода. См. KB3009974 для получения дополнительной информации.
  • Если для ядра СУБД SQL Server, прослушивателя группы доступности Always On или пробы работоспособности экземпляра отказоустойчивого кластера настроено использование порта в диапазоне от 49 152 до 65 536 (диапазон динамических портов по умолчанию для TCP/IP), добавьте исключение для каждого порта. Это позволяет предотвратить динамическое назначение другим системам того же порта. В следующем примере создается исключение для порта 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Чтобы сравнить контрольный список HADR с другими рекомендациями, ознакомьтесь с полным контрольным списком рекомендаций по производительности.

Параметры доступности виртуальной машины

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

  • Чтобы обеспечить минимальную задержку, используйте группы тесного размещения вместе с ускоренной сетью.
  • Размещайте узлы кластера виртуальных машин в отдельных зонах доступности для защиты от сбоев уровня центра обработки данных или в одной группе доступности в пределах того же центра обработки данных для избыточности и пониженной задержки.
  • Используйте управляемые диски категории "Премиум" для ОС и данных виртуальных машин в группе доступности.
  • Настройте все уровни приложений в отдельных группах доступности.

кворум

Хотя кластер с двумя узлами может функционировать без ресурса кворума, клиенты строго обязаны использовать ресурс кворума для получения поддержки в рабочей среде. Проверка кластера не пропускает кластер без ресурса кворума.

С технической точки зрения кластер с тремя узлами может выдержать потерю одного узла (остаться с двумя узлами) без ресурса кворума, но после того, как кластер сократится до двух узлов, если произойдет еще один сбой узла или связи, то есть риск того, что кластеризованные ресурсы выйдут из строя, чтобы предотвратить сценарий разделения кластера. Настройка ресурса кворума позволяет кластеру продолжать работу только с одним узлом в сети.

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

В приведенной ниже таблице перечислены варианты кворума, доступные для SQL Server на виртуальных машинах Azure.

Облако-свидетель Диск-свидетель Свидетель файлового ресурса
Поддерживаемые ОС Windows Server 2016+ Все Все
  • Облако-свидетель идеально подходит для развертываний на нескольких сайтах, в нескольких зонах и в нескольких регионах. Следует использовать облачный свидетель, когда это возможно, кроме случаев, когда используется кластерное решение с общим хранилищем.
  • Диск-свидетель — это наиболее устойчивый вариант кворума, который является предпочтительным для любого кластера с общими дисками Azure (или любого решения на основе общих дисков, например общего SCSI, iSCSI или оптоволоконной сети SAN). Кластеризованный общий том нельзя использовать в качестве следящего диска.
  • Общая папка-свидетель подходит, когда диск-свидетель и облако-свидетель недоступны.

Сведения о том, как приступить к работе, см. в статье Настройка кворума кластера.

Голосование кворума

Можно изменить кворумный голос узла, участвующего в отказоустойчивом кластере Windows Server.

При изменении параметров голоса для узла следуйте приведенным ниже рекомендациям.

Рекомендации по голосованию кворума
По умолчанию каждый узел не имеет голоса. Каждый узел должен иметь только один голос с явным обоснованием.
Включите голоса для узлов кластера, которые размещают первичную реплику группы доступности или являются предпочтительными владельцами экземпляра отказоустойчивого кластера.
Разрешите голосование для владельцев автоматического переключения на резервный узел. Каждый узел, который может размещать FCI или первичную копию в результате автоматического переключения при отказе, должен иметь голос.
Если в группе доступности несколько вторичных реплик, разрешите голосование только для реплик с автоматическим переключением.
Отключите голосование для узлов, находящихся на вторичных площадках аварийного восстановления. Узлы на вторичных сайтах не должны участвовать в решении об отключении кластера, если основной сайт работает нормально.
Число голосов кворума должно быть нечетным (минимум три). При необходимости в кластере с двумя узлами добавьте свидетеля кворума для получения дополнительного голоса.
Перераспределите назначение голосов после переключения на резервный сервер. Вы не хотите переключаться на конфигурацию кластера, которая не поддерживает здоровый кворум.

Подключение

Чтобы обеспечить соответствие локальной среды для подключения к прослушивателю группы доступности или экземпляру отказоустойчивого кластера, разверните виртуальные машины SQL Server в нескольких подсетях в одной виртуальной сети. Наличие нескольких подсетей устраняет необходимость в дополнительной зависимости от Azure Load Balancer или имени распределенной сети для маршрутизации трафика к прослушивателю.

Чтобы упростить решение HADR, при возможности разверните виртуальные машины SQL Server в нескольких подсетях. Дополнительные сведения см. в разделах Группа доступности для нескольких подсетей и Кластер отказоустойчивости для нескольких подсетей.

Если ваши виртуальные машины SQL Server находятся в одной подсети, вы можете настроить либо имя виртуальной сети (VNN) и Azure Load Balancer, или имя распределенной сети (DNN) для экземпляров отказоустойчивого кластера и прослушивателей группы доступности.

Имя распределенной сети — это рекомендуемый вариант подключения, если он доступен.

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

Необходимо учитывать следующие ограничения.

  • Драйвер клиента должен поддерживать параметр MultiSubnetFailover=True.
  • Функция DNN сейчас доступна начиная с версий SQL Server 2016 SP3, SQL Server 2017 CU25 и SQL Server 2019 CU8 в Windows Server 2016 и более поздней версии.

Дополнительные сведения см. в обзоре отказоустойчивого кластера Windows Server.

Сведения о настройке подключения см. в приведенных ниже статьях.

Большинство функций SQL Server работают прозрачно с FCI и группами доступности при использовании DNN, но существуют определенные функции, которые могут потребовать особого рассмотрения. Дополнительные сведения см. в статьях Взаимодействие FCI и DNN и Взаимодействие AG и DNN.

Совет

Задайте параметр MultiSubnetFailover=true в строке подключения даже для решений HADR, которые используют одну подсеть, чтобы в дальнейшем можно было добавлять подсети, не обновляя строку подключения.

Пульс и пороговое значение

Измените параметры пульса и пороговых значений кластера на менее строгие. Параметры пульса и пороговых значений по умолчанию для кластера предназначены для высокопроизводительных локальных сетей и не учитывают возможность увеличения задержки в облачной среде. Сеть передачи пульса работает через порт UDP 3343, который обычно менее надежен, чем TCP, и более подвержен незавершенным сеансам.

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

Настройки задержки и пороговых значений оказывают совокупное влияние на общую диагностику состояния системы. Например, если с помощью параметра CrossSubnetDelay настроить отправку пульса каждые две секунды, а с помощью параметра CrossSubnetThreshold задать восстановление после 10 пропущенных пакетов пульса, значит, в кластере будет допускаться общая задержка в 20 секунд, прежде чем будет предпринято действие по восстановлению. Как правило, предпочтительно продолжать часто отправлять сигналы heartbeat, но с использованием более высоких пороговых значений.

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

Настройка Windows Server 2012 или более поздней версии; Windows Server 2008 R2
ЗадержкаВТойЖеПодсети (SameSubnetDelay) 1 с 2 секунды
Порог одной подсети 40 пульсов 10 пульсов (максимум)
Задержка между подсетями 1 с 2 секунды
Порог для пересечения подсетей 40 пульсов 20 пульсов (максимум)

Используйте PowerShell для изменения параметров кластера.

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

Для проверки изменений используйте PowerShell.

get-cluster | fl *subnet*

Рассмотрим следующий пример.

  • Это изменение вступает в силу немедленно, перезапуск кластера или каких-либо ресурсов не требуется.
  • Значения в одной и той же подсети не должны превышать значения в разных подсетях.
  • Порог для той же подсети (SameSubnetThreshold) <= Порог для другой подсети (CrossSubnetThreshold)
  • Задержка на той же подсети <= Задержка на другой подсети

Выбирайте менее строгие значения с учетом приемлемого времени простоя и срока до выполнения корректирующего действия в зависимости от вашего приложения, потребностей бизнеса и среды. Если превышать значения по умолчанию для Windows Server 2019 нельзя, по возможности старайтесь по крайней мере их соблюдать.

Значения по умолчанию приведены для справки в таблице ниже.

Настройка Windows Server 2019 Windows Server 2016 Windows Server версий от 2008 до 2012 R2
SameSubnetDelay 1 с 1 с 1 с
Порог той же подсети 20 пульсов 10 пульсов 5 пульсов
CrossSubnetDelay 1 с 1 с 1 с
Порог пересечения подсетей 20 пульсов 10 пульсов 5 пульсов

Дополнительные сведения см. в статье Настройка пороговых значений сети отказоустойчивого кластера.

Ослабленный мониторинг

Если настройка частоты опроса кластера и пороговых значений, как рекомендуется, не обеспечивает достаточной терпимости, и вы по-прежнему наблюдаете переключения на резервный сервер из-за кратковременных сбоев, а не истинных сбоев, вы можете настроить мониторинг группы доступности или FCI для более снисходительного мониторинга. В некоторых сценариях может оказаться полезным временно расслабить мониторинг в течение определенного периода времени, учитывая уровень активности. Например, может потребоваться расслабить мониторинг при выполнении интенсивных рабочих нагрузок ввода-вывода, таких как резервное копирование баз данных, обслуживание индексов, DBCC CHECKDB и т. д. После завершения действия задайте для мониторинга менее расслабленные значения.

Предупреждение

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

Начните с увеличения следующих параметров из значений по умолчанию для расслабленного мониторинга и настройки по мере необходимости:

Параметр Значение по умолчанию Упрощенное значение Описание
Время ожидания проверки работоспособности 30 000 60 000 Определяет работоспособность первичной реплики или узла. Библиотека DLL sp_server_diagnostics ресурсов кластера возвращает результаты с интервалом, равным 1/3 времени ожидания контрольной проверки состояния. Если sp_server_diagnostics работает медленно или не возвращает информацию, библиотека DLL ресурсов ожидает полного интервала порога времени ожидания проверки работоспособности, прежде чем определить, что ресурс не реагирует, и инициирует автоматический переход на резервный ресурс, если это настроено.
Уровень условий сбоя 3 2 Условия, которые активируют автоматический переход на другой ресурс Существует пять уровней условий сбоя, которые варьируются от наименее ограничительного (уровень 1) до наиболее ограничительного (уровень 5).

Используйте Transact-SQL (T-SQL), чтобы изменить условия проверки работоспособности и сбоя для групп доступности (AGs) и экземпляров отказоустойчивого кластера (FCIs).

Для групп доступности

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Для экземпляров отказоустойчивого кластера

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

Для групп доступности начните со следующих рекомендуемых параметров и при необходимости скорректируйте их.

Параметр Значение по умолчанию Гибкое значение Описание
Время ожидания аренды 20000 40000 Предотвращает разделение.
Истекло время сеанса 10 000 20000 Проверяет наличие проблем связи между репликами. Время ожидания сеанса — это свойство реплики, которое определяет, сколько секунд эта реплика доступности будет ждать отклика на команду проверки связи, отправленную с подключенной реплики, перед тем, как признать попытку подключения неудачной. По умолчанию реплика ожидает ответа на команду ping 10 секунд. Это свойство реплики применимо только к подключению данной вторичной реплики к первичной реплике группы доступности.
Максимальное число сбоев за указанный период 2 6 Используется для предотвращения неопределенно долгого перемещения кластерного ресурса в случае сбоя нескольких узлов. Слишком низкое значение может привести к сбою группы доступности. Увеличьте это значение, чтобы избежать кратковременных перерывов в работе из-за проблем с производительностью, так как слишком низкое значение может привести к сбою AG.

Прежде чем вносить изменения, учтите следующее.

  • Не уменьшайте значения времени ожидания ниже значений по умолчанию.
  • Используйте это уравнение для вычисления максимального значения времени ожидания аренды: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay)
    Начните с 40 секунд. Если вы используете упрощённые значения SameSubnetThreshold и SameSubnetDelay, рекомендованные ранее, не превышайте 80 секунд для значения времени ожидания аренды.
  • Для реплик с синхронной фиксацией увеличение времени ожидания сеанса может увеличить задержки ожидания HADR_sync_commit.

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

Используйте диспетчер отказоустойчивости кластеров, чтобы изменить параметры времени ожидания аренды для группы доступности. См. документацию SQL Server по проверке состояния аренды группы доступности для подробных инструкций.

Тайм-аут сеанса

Чтобы изменить время ожидания сеанса для группы доступности, используйте Transact-SQL (T-SQL).

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

Максимальное число сбоев за указанный период

Используйте диспетчер отказоустойчивости кластеров для изменения значения Максимальное число сбоев за указанный период.

  1. На панели навигации выберите элемент Роли.
  2. В разделе Роли щелкните кластерный ресурс правой кнопкой мыши и выберите пункт Свойства.
  3. Перейдите на вкладку Отработка отказа и увеличьте значение Максимальное число сбоев за указанный период до нужного.

Ограничения ресурсов

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

  • Используйте анализ ввода-вывода (предварительная версия) в портале Azure для выявления проблем с производительностью диска, которые могут привести к переключению на резервный узел.
  • Используйте последние сборки ОС, драйверов и SQL Server.
  • Оптимизируйте SQL Server в среде виртуальных машин Azure, как описано в руководстве по производительности SQL Server на Виртуальных машинах Azure.
  • Использование
  • Уменьшите или распределите рабочую нагрузку, чтобы сократить использование без превышения лимитов ресурсов.
  • Настройте рабочую нагрузку SQL Server, если есть возможность, например,
    • добавьте или оптимизируйте индексы;
    • Обновляйте статистику при необходимости и если возможно, посредством полного сканирования.
    • используйте такие функции, как регулятор ресурсов (начиная с SQL Server 2014, только в выпуске Enterprise), чтобы ограничить использование ресурсов во время выполнения определенных рабочих нагрузок, таких как резервное копирование или обслуживание индекса;
  • перейдите на виртуальную машину или диск с более высокими ограничениями, чтобы удовлетворить требования рабочей нагрузки.

Сеть

По возможности развертывайте виртуальные машины SQL Server в нескольких подсетях, чтобы не использовать Azure Load Balancer или имя распределенной сети (DNN) для маршрутизации трафика к решению HADR.

Используйте один сетевой интерфейс для каждого сервера (узла кластера). Сеть Azure обладает физической избыточностью, что делает ненужными дополнительные сетевые адаптеры в кластере гостевых виртуальных машин Azure. Отчет проверки кластера предупреждает, что узлы доступны только в одной сети. Это предупреждение можно игнорировать в гостевых отказоустойчивых кластерах виртуальных машин Azure.

Ограничения пропускной способности для конкретной виртуальной машины совместно используются всеми сетевыми адаптерами, и добавление дополнительной сетевой карты не улучшает производительность группы доступности для SQL Server на виртуальных машинах Azure. Таким образом, нет необходимости добавлять второй сетевой адаптер.

Несовместимая с RFC служба DHCP в Azure может привести к сбою при создании определенных конфигураций отказоустойчивого кластера. Такой сбой происходит потому, что сетевому имени кластера назначается дублирующий IP-адрес, например адрес, соответствующий одному из узлов кластера. Это актуально, если используются группы доступности, зависящие от функции отказоустойчивого кластера Windows.

Рассмотрим сценарий, в котором вы создаете и подключаете к сети кластер с двумя узлами.

  1. Кластер подключается к сети, и узел NODE1 запрашивает динамически назначаемый IP-адрес для сетевого имени кластера.
  2. Служба DHCP не назначает других IP-адресов, кроме собственного IP-адреса узла NODE1, так как она распознает, что запрос поступает от самого узла NODE1.
  3. Windows обнаруживает, что адрес-дубликат назначен как узлу NODE1, так и сетевому имени отказоустойчивого кластера, поэтому группе кластера по умолчанию не удается подключиться к сети.
  4. Группа кластера по умолчанию перемещается на узел NODE2. Узел NODE2 рассматривает IP-адрес узла NODE1 как IP-адрес кластера и подключает группу кластера по умолчанию к сети.
  5. Если узел NODE2 пытается установить соединение с узлом NODE1, пакеты, направляемые на NODE1, не покидают узел NODE2, поскольку он разрешает IP-адрес узла NODE1 на самого себя. Узлу NODE2 не удается установить соединение с узлом NODE1, что приводит к потере кворума и завершению работы кластера.
  6. Узел NODE1 может отправлять пакеты на узел NODE2, но NODE2 не может ответить. Узел NODE1 теряет кворум и завершает работу кластера.

Этого можно избежать путем назначения сетевому имени кластера неиспользуемого статического IP-адреса, чтобы подключить сетевое имя кластера к сети и добавить IP-адрес в Azure Load Balancer.

Если ядро СУБД SQL Server, прослушиватель группы доступности AlwaysOn, проба работоспособности экземпляра отказоустойчивого кластера, конечная точка зеркального отображения базы данных, IP-ресурс кластера или любой другой ресурс SQL настроен для использования порта в диапазоне от 49 152 до 65 536 ( динамический диапазон портов по умолчанию для TCP/IP), добавьте исключение для каждого порта. Это предотвращает динамическое назначение других системных процессов тем же портом. В следующем примере создается исключение для порта 59999:

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

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

Чтобы убедиться, что исключения настроены правильно, используйте следующую команду: netsh int ipv4 show excludedportrange tcp

Установка этого исключения для порта IP-пробы группы доступности должна предотвратить такие события, как идентификатор события: 1069 с состоянием 10048. Это событие можно увидеть в событиях отказоустойчивого кластера Windows со следующим сообщением:

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**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Это может быть вызвано внутренним процессом, который использует тот же порт, что и порт проверки. Помните, что порт пробы используется для проверки состояния экземпляра внутреннего пула из Azure Load Balancer.
Если проба работоспособности не сможет получить ответ от внутреннего экземпляра, новые подключения не будут отправлены в этот серверный экземпляр до тех пор, пока проба работоспособности не будет выполнена повторно.

Известные проблемы

Ознакомьтесь с решениями некоторых распространенных проблем и ошибок.

Конкуренция за ресурсы (в частности, за операции ввода-вывода) вызывает переключение при отказе.

Исчерпание ресурсов ввода-вывода или ЦП у виртуальной машины может привести к переключению группы доступности. Определение конфликта, который происходит непосредственно перед переключением, является наиболее надежным способом установить причину автоматического переключения.

Использование анализа операций ввода-вывода

Используйте анализ ввода-вывода (предварительная версия) в портале Azure для выявления проблем с производительностью диска, которые могут привести к переключению отказа.

Мониторинг метрик I/O в хранилище виртуальных машин

Отслеживайте виртуальные машины Azure, чтобы просматривать показатели использования операций ввода-вывода хранилища и таким образом понять задержку на уровне виртуальной машины или диска.

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

  1. Перейдите к виртуальной машине в портале Azure, а не к виртуальным машинам SQL.

  2. Выберите метрики в разделе "Мониторинг", чтобы открыть страницу метрик.

  3. Выберите местное время, чтобы указать интересующий вас диапазон времени и часовой пояс , локальный для виртуальной машины или UTC/GMT.

    Снимок экрана страницы метрик в портале Azure, при выборе изменения временно́го интервала графика.

  4. Нажмите кнопку "Добавить метрику", чтобы добавить следующие две метрики , чтобы просмотреть график:

    • Процент потребления закэшированной пропускной способности виртуальной машины
    • Процент использования некэшированной пропускной способности для виртуальной машины.

Снимок экрана страницы метрик на портале Azure.

События узла виртуальной машины Azure вызывают отработку отказа

Возможно, что HostEvent виртуальной машины Azure приводит к переключению на резервный узел в группе доступности. Если вы считаете, что событие узла виртуальной машины Azure вызвало переключение при отказе, вы можете проверить журнал действий Azure Monitor и обзор работоспособности ресурсов виртуальной машины Azure.

Журнал действий Azure Monitor — это журнал платформы в Azure, который предоставляет аналитические сведения о событиях уровня подписки. Журнал действий содержит такие сведения, как когда был изменен ресурс или запущена виртуальная машина. Журнал действий можно просмотреть в портал Azure или получить записи с помощью PowerShell и Azure CLI.

Чтобы проверить журнал действий Azure Monitor, выполните следующие действия.

  1. Перейдите к виртуальной машине в портале Azure

  2. Выберите Журнал активности в панели "Виртуальная машина"

  3. Выберите Timespan и выберите интервал времени для переключения группы доступности. Выберите Применить.

    Снимок экрана: портал Azure с журналом действий.

Если в Azure есть дополнительные сведения о первопричине недоступности, вызванной платформой, эта информация может быть размещена на странице обзора "Azure VM - Работоспособность ресурсов" до 72 часов после начала первоначальной недоступности. В настоящее время эта информация доступна только для виртуальных машин.

  1. Перейдите в вашу виртуальную машину в портале Azure.
  2. Выберите Работоспособность ресурса в панели Состояние.

Снимок экрана страницы Работоспособность ресурсов в портале Azure.

Вы также можете настроить оповещения на основе событий состояния системы на этой странице.

Узел кластера удален из членства

Если параметры пульса и порогового значения кластера 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.

Дополнительные сведения см. в статье Устранение неполадки кластера с идентификатором события 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 — сбой регистрации связанного DNS-имени сетевого имени ресурса

  • Проверьте параметры NIC для каждого узла кластера, чтобы убедиться в отсутствии внешних записей DNS.
  • Убедитесь, что запись A для кластера существует на внутренних DNS-серверах. Если нет, создайте новую запись A в DNS-сервере для объекта управления доступом к кластеру вручную и установите флажок "Разрешить всем прошедшим проверку подлинности пользователям обновлять записи DNS с тем же именем владельца".
  • Переключите ресурс "Имя кластера" с IP-ресурсом в автономный режим и устраните проблему.

Событие 157 - Диск был неожиданно извлечён.

Это может произойти, если свойству "Дисковые пространства" AutomaticClusteringEnabled присвоено значение True для среды группы доступности. Укажите вместо него значение False. Кроме того, запуск отчета о проверке при использовании параметра "Хранилище" может привести к сбросу диска или неожиданному удалению. Троттлинг в системе хранения также может вызвать событие внезапного удаления диска.

Событие 1206 — ресурс сетевого имени кластера не может быть подключен к сети.

Не удалось обновить объект компьютера, связанный с ресурсом, в домене. Убедитесь, что у вас есть соответствующие разрешения на домен

Ошибки кластеризации Windows

При настройке отказоустойчивого кластера Windows или его подключении могут возникнуть проблемы, если у вас нет портов службы кластеров, открытых для связи.

Если вы находитесь в Windows Server 2019 и не видите IP-адрес кластера Windows, вы настроили имя распределенной сети, которое поддерживается только в SQL Server 2019. Если у вас есть предыдущие версии SQL Server, можно удалить и повторно создать кластер с помощью имени сети.

Ознакомьтесь с другими ошибками отказоустойчивой кластеризации Windows и их решениями

Следующие шаги

Дополнительные сведения см. на следующих ресурсах: