Отказоустойчивый кластер Windows Server с SQL Server на виртуальных машинах Azure
Область применения: 
SQL Server на виртуальной машине Azure
В этой статье описывается, чем отличается использование компонента отказоустойчивого кластера Windows Server с SQL Server на виртуальных машинах Azure для обеспечения высокой доступности и аварийного восстановления (HADR), например для группы доступности Always On (AG) или экземпляров отказоустойчивого кластера (FCI).
Дополнительные сведения о компоненте Windows см. в документации по отказоустойчивому кластеру Windows Server.
Обзор
Решения для обеспечения высокой доступности для SQL Server в Windows, например группы доступности Always On (AG) или экземпляры отказоустойчивого кластера (FCI), используют базовую службу отказоустойчивой кластеризации Windows Server (WSFC).
Служба кластеров отслеживает сетевые подключения и работоспособность узлов в кластере. Этот мониторинг осуществляется в дополнение к проверкам работоспособности, которые SQL Server выполняет в рамках реализации группы доступности или экземпляра отказоустойчивого кластера. Если службе кластеров не удается связаться с узлом или роль AG или FCI в кластере становится неработоспособной, служба кластера инициирует соответствующие действия по восстановлению, чтобы восстановить приложения и службы и перевести их в оперативный режим на том же или на другом узле в кластере.
Мониторинг работоспособности кластера
Чтобы обеспечить высокий уровень доступности, кластер должен гарантировать работоспособность различных компонентов, входящих в состав кластерного решения. Служба кластеров отслеживает работоспособность кластера на основе ряда параметров системы и сети для обнаружения сбоев и реагирования на них.
Установка порогового значения для объявления сбоя важна для достижения баланса между своевременным реагированием на отказ и предотвращением ложных сбоев.
Существует две стратегии мониторинга.
| Наблюдение | Description |
|---|---|
| Агрессивная | Обеспечивает быстрое обнаружение сбоев и восстановление после жестких сбоев, что способствует достижению наивысшего уровня доступности. Служба кластеров и SQL Server менее устойчивы к временным сбоям и в некоторых ситуациях могут преждевременно инициировать отработку отказа для ресурсов при возникновении временных простоев. После обнаружения сбоя может потребоваться дополнительное время для выполнения корректирующего действия. |
| Нестрогая | Обеспечивает большую устойчивость при обнаружении сбоев с более высоким допуском кратковременных проблем сети. Предотвращает временные сбои, но при этом создает риск задержки обнаружения истинного сбоя. |
Агрессивные параметры в кластерной среде в облаке могут привести к преждевременному сбою и более длительным простоям, поэтому для отказоустойчивых кластеров на виртуальных машинах Azure рекомендуется использовать нестрогую стратегию мониторинга. Дополнительные сведения о настройке пороговых значений см. в рекомендациях по работе с кластерами.
Пульс кластера
Ниже приведены основные параметры, влияющие на пульс кластера и обнаружение его работоспособности между узлами.
| Параметр | Description |
|---|---|
| Задержка | Определяет частоту, с которой пульсы кластера передаются между узлами. Задержка — это количество секунд до отправки следующего пульса. Для одного и того же кластера можно настроить разные параметры задержки между узлами в одной подсети и узлами в разных подсетях. |
| За пороговое значение | Пороговое значение — это число пульсов, после пропуска которых кластер примет действие по восстановлению. Для одного и того же кластера можно настроить разные пороговые значения параметров между узлами в одной подсети и узлами в разных подсетях. |
Значения по умолчанию для этих параметров могут быть слишком низкими для облачных сред, что может привести к ненужным сбоям из-за временных проблем с сетью. Чтобы обеспечить большую устойчивость, используйте для отказоустойчивых кластеров на виртуальных машинах Azure менее строгие пороговые значения параметров. Дополнительные сведения см. в рекомендациях по кластерам.
Quorum
Хотя кластер с двумя узлами работает без ресурса кворума, клиентам необходимо использовать ресурс кворума для поддержки рабочей среды. Ни один кластер не пройдет проверку без ресурса кворума.
Технически кластер из трех узлов может перенести потерю одного узла (останется два) без ресурса кворума. Однако после сокращения кластера до двух узлов есть риск того, что кластерные ресурсы будут переведены в автономный режим для предотвращения сценария разделения в случае потери узла или сбоя связи между ними. Настройка ресурса кворума позволит ресурсам кластера сохранить подключение с единственным оставшимся в сети узлом.
Диск-свидетель — это наиболее устойчивый вариант кворума, но для его использования в SQL Server на виртуальной машине Azure требуется общий диск Azure, что накладывает некоторые ограничения на решение для обеспечения высокой доступности. Поэтому диск-свидетель следует использовать при настройке экземпляра отказоустойчивого кластера с общими дисками Azure. В противном случае по возможности используйте облако-свидетель.
В приведенной ниже таблице перечислены варианты кворума, доступные для SQL Server на виртуальных машинах Azure.
| Облако-свидетель | Диск-свидетель | Файловый ресурс-свидетель | |
|---|---|---|---|
| Поддерживаемые ОС | Windows Server 2016+ | Все | Все |
| Description | Облако-свидетель — это разновидность следящего кворума отказоустойчивого кластера, который использует Microsoft Azure для передачи голоса для кворума кластера. Размер по умолчанию составляет около 1 МБ, а его содержимым является только метка времени. Облако-свидетель идеально подходит для развертываний на нескольких сайтах, в нескольких зонах и в нескольких регионах. Облако-свидетель следует использовать по возможности во всех случаях, за исключением отказоустойчивого кластерного решения с общим хранилищем. | Диск-свидетель — небольшой кластеризованный диск, размещенный в группе службы хранилища, доступной для кластера. Это диск с высоким уровнем доступности и отработкой отказа между узлами. Он содержит копию базы данных кластера с размером по умолчанию менее 1 ГБ. Диск-свидетель предпочтительно использовать в качестве кворума для любого кластера с общими дисками Azure (или любого решения на основе общих дисков, например общего SCSI, iSCSI или оптоволоконной сети SAN). Кластеризованный общий том нельзя использовать в качестве диска-свидетеля. Настройте общий диск Azure в качестве диска-свидетеля. | Общая папка-свидетель — общая папка SMB, которая обычно настраивается на файловом сервере под управлением Windows Server. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера. В Azure можно настроить общую папку на отдельной виртуальной машине в пределах одной виртуальной сети. Используйте общую папку-свидетель, если в вашей среде недоступны ни диск-свидетель, ни облако-свидетель. |
Сведения о том, как приступить к работе, см. в статье Настройка кворума кластера.
Имя виртуальной сети (VNN)
Чтобы обеспечить соответствие локальной среды для подключения к прослушивателю группы доступности или экземпляру отказоустойчивого кластера, разверните виртуальные машины SQL Server в нескольких подсетях в одной виртуальной сети. Наличие нескольких подсетей позволяет исключить дополнительную зависимость от Azure Load Balancer для маршрутизации трафика в решение HADR. Дополнительные сведения см. в разделах Группа доступности с несколькими подсетями и Экземпляр отказоустойчивого кластера с несколькими подсетями.
В традиционной локальной среде такие кластерные ресурсы, как экземпляры отказоустойчивого кластера или группы доступности Always On, используют для маршрутизации трафика на соответствующий целевой объект (экземпляр отказоустойчивого кластера или прослушиватель группы доступности Always On) имя виртуальной сети. Виртуальное имя привязывает IP-адрес к DNS, так что для подключения к целевому объекту с высоким уровнем доступности клиенты могут использовать либо его, либо IP-адрес, независимо от того, какой узел в настоящее время владеет ресурсом. VNN — это имя и адрес сети, которыми управляет кластер. При отработке отказа служба кластера перемещает адрес сети от одного узла к другому. Во время сбоя адрес переводится в автономный режим на исходной первичной реплике и подключается к сети на новой первичной реплике.
В Виртуальных машинах Azure в одной подсети для маршрутизации трафика с клиента на кластерный ресурс с соответствующим именем виртуальной сети (экземпляр отказоустойчивого кластера или прослушиватель группы доступности) необходим дополнительный компонент. В Azure подсистема балансировки нагрузки содержит IP-адрес для VNN, используемый кластерными ресурсами SQL Server. Он также необходим для маршрутизации трафика к соответствующему целевому объекту с высоким уровнем доступности. Подсистема балансировки нагрузки также обнаруживает сбои сетевых компонентов и перемещает адрес на новый узел.
Подсистема балансировки нагрузки распределяет входящие потоки, поступающие на внешний интерфейс, а затем направляет трафик в экземпляры, определенные внутренним пулом. Поток трафика настраивается с помощью правил балансировки нагрузки и проб работоспособности. В SQL Server FCI экземпляры серверного пула — это виртуальные машины Azure под управлением SQL Server, а с группами доступности серверный пул — это виртуальные машины Azure, которые могут стать основной репликой прослушивателя. При использовании подсистемы балансировки нагрузки отработка отказа выполняется с небольшой задержкой, поскольку проба работоспособности по умолчанию выполняет проверку активности каждые 10 секунд.
Чтобы приступить к работе, узнайте, как настроить Azure Load Balancer для экземпляра отказоустойчивого кластера или группы доступности.
Поддерживаемые ОС: все
Поддерживаемые версии SQL: все
Поддерживаемое решение HADR: экземпляр отказоустойчивого кластера и группа доступности
Настройка VNN может оказаться обременительной, так как это дополнительный источник отказа, который может вызвать задержку при обнаружении сбоя и требует накладных расходов и затрат, связанных с управлением дополнительным ресурсом. Чтобы устранить некоторые из этих ограничений, SQL Server предоставляет поддержку для функции "Имя распределенной сети".
Имя распределенной сети (DNN)
Чтобы обеспечить соответствие локальной среды для подключения к прослушивателю группы доступности или экземпляру отказоустойчивого кластера, разверните виртуальные машины SQL Server в нескольких подсетях в одной виртуальной сети. Наличие нескольких подсетей позволяет исключить дополнительную зависимость от DNN для маршрутизации трафика в решение HADR. Дополнительные сведения см. в разделах Группа доступности с несколькими подсетями и Экземпляр отказоустойчивого кластера с несколькими подсетями.
Для виртуальных машин SQL Server, развернутых в одной подсети, функция "Имя распределенной сети" предоставляет клиентам SQL Server альтернативный способ подключения к экземпляру отказоустойчивого кластера SQL Server или прослушивателю группы доступности без использования подсистемы балансировки нагрузки. Функция DNN сейчас доступна начиная с версий SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8 в Windows Server 2016 и более поздней версии.
При создании ресурса DNN кластер привязывает DNS-имя к IP-адресам всех узлов в кластере. Клиент попытается подключиться к каждому IP-адресу в этом списке, чтобы найти ресурс для подключения. Вы можете ускорить этот процесс, указав MultiSubnetFailover=True в строке подключения. Этот параметр указывает поставщику, что необходимо пытаться использовать все IP-адреса параллельно, чтобы клиент мог мгновенно подключиться к экземпляру отказоустойчивого кластера или прослушивателю.
По ряду причин, которые приведены ниже, в подсистеме балансировки нагрузки рекомендуется по возможности использовать имя распределенной сети.
- Комплексное решение является более надежным, так как не нужно поддерживать ресурс подсистемы балансировки нагрузки.
- Устранение проверок подсистемы балансировки нагрузки сводит к минимуму длительность отработки отказа.
- DNN упрощает подготовку и администрирование экземпляра отказоустойчивого кластера или прослушивателя группы доступности с SQL Server на виртуальных машинах Azure.
Большинство функций SQL Server прозрачно работают с экземпляром отказоустойчивого кластера и группами доступности при использовании DNN, но есть определенные функции, которые могут потребовать особого внимания.
Поддерживаемые ОС: Windows Server 2016 и более поздней версии
Поддерживаемая версия SQL: SQL Server 2019 CU2 (FCI) и SQL Server 2019 CU8 (AG)
Поддерживаемое решение HADR: экземпляр отказоустойчивого кластера и группа доступности
Чтобы приступить к работе, научитесь настраивать ресурс имени распределенной сети для экземпляра отказоустойчивого кластера или группы доступности.
При использовании DNN с другими функциями SQL Server необходимо учитывать дополнительные факторы. Дополнительные сведения см. в статьях Взаимодействие FCI и DNN и Взаимодействие группы доступности и DNN.
Примечание.
Если в одном кластере имеется несколько групп AG или FCIs, и вы используете прослушиватель DNN или VNN, каждая группа доступности или FCI нуждается в отдельной независимой точке подключения.
Действия по восстановлению
При обнаружении сбоя служба кластеров выполняет корректирующие действия. Это может привести к перезапуску ресурса на существующем узле или сбою ресурса на другом узле. После инициирования корректирующих мер потребуется некоторое время для их выполнения.
Например, перезапущенная группа доступности переходит в режим подключения к сети в соответствии со следующей последовательностью:
- В режим подключения к сети переходит IP-адрес прослушивателя.
- В режим подключения к сети переходит имя сети прослушивателя.
- В режим подключения к сети переходит группа доступности.
- Отдельные базы данных проходят восстановление, что может занять некоторое время, зависящее от ряда факторов, например длины журнала повторов. Подключения перенаправляются прослушивателем только после полного восстановления базы данных. Дополнительные сведения см. в статье Оценка времени отработки отказа (RTO).
Так как восстановление может занять некоторое время, агрессивный мониторинг, настроенный для обнаружения сбоя в течение 20 секунд, может приводить к простоям в течение нескольких минут из-за временного события (например, обслуживания виртуальных машин Azure с сохранением памяти). Установка менее строгого значения, равного 40 секундам, может помочь избежать более длительного прерывания в обслуживании.
Дополнительные сведения о настройке пороговых значений см. в рекомендациях по работе с кластерами.
Расположение узла
Узлы в кластере Windows на виртуальных машинах в Azure могут быть физически разделены в пределах одного региона Azure или находиться в разных регионах. Расстояние может приводить к задержке в сети, подобно тому, как это происходит при рассредоточении узлов кластера между расположениями в вашей собственной инфраструктуре. В облачных средах различие заключается в том, что в пределах региона о расстоянии между узлами не всегда известно. Кроме того, задержку могут также повысить некоторые другие факторы, например физические и виртуальные компоненты, число прыжков и т. п. Если задержка между узлами создает проблему, рассмотрите возможность размещения узлов кластера в группе размещения близкого взаимодействия, чтобы гарантировать их близость в сети.
Ограничения ресурсов
При настройке виртуальной машины Azure вы определяете ограничения на вычислительные ресурсы для ЦП, памяти и числа операций ввода-вывода. Рабочие нагрузки, требующие больше ресурсов, чем у приобретенной виртуальной машины Azure, или ограничения дискового пространства могут вызвать проблемы с производительностью виртуальной машины. Снижение производительности может привести к сбоям при проверке работоспособности службы кластеров или функции высокой доступности SQL Server. Узкие места по ресурсам могут создавать впечатление, что узел или ресурс в кластере или на SQL Server вышел из строя.
Ресурсоемкие операции ввода-вывода SQL или операции обслуживания, например резервное копирование, индексирование или ведение статистики, могут привести к тому, что для виртуальной машины или диска будут достигнуты предельные значения пропускной способности, измеряемой числом операций ввода-вывода в секунду или в Мбит/с, в результате чего SQL Server может не реагировать на проверку IsAlive/LooksAlive.
Если в SQL Server происходит непредвиденная отработка отказа, обязательно выполните все рекомендации по производительности и проследите, не превышаются ли на сервере установленные ограничения на уровне диска или виртуальной машины.
Обслуживание платформы Azure
Как и в любых других облачных службах, в Azure периодически выполняется обновление платформы, чтобы повысить надежность, производительность и безопасность инфраструктуры узлов, в которой работают виртуальные машины. Причины этих обновлений разные: от исправлений программных компонентов в среде размещения до обновления сетевых компонентов или вывода оборудования из эксплуатации.
Большинство обновлений платформы не влияет на виртуальные машины клиента. Если обновление без такого влияния невозможно, Azure выбирает механизм обновления, который в наименьшей мере затрагивает виртуальные машины клиентов. Большинство форм обслуживания с ненулевым влиянием приостанавливают работу виртуальной машины менее чем на 10 секунд. В некоторых случаях Azure использует механизмы обслуживания с сохранением памяти. Эти механизмы приостанавливают работу виртуальной машины в течение 30 секунд и сохраняют память в ОЗУ. После возобновления работы часы виртуальной машины автоматически синхронизируются.
Обслуживание с сохранением памяти доступно более чем для 90 % виртуальных машин Azure. Оно не работает для серий G, M, N и H. В Azure все чаще используются технологии динамической миграции и вносятся улучшения в механизмы обслуживания с сохранением памяти, необходимые для уменьшения длительности приостановок. Когда виртуальная машина динамически перемещается на другой узел, для некоторых чувствительных рабочих нагрузок, например SQL Server, может наблюдаться небольшое снижение производительности в течение нескольких минут перед приостановкой работы виртуальной машины.
Узким местом в ресурсах при обслуживании платформы может быть кажущийся выход из строя группы доступности или экземпляра отказоустойчивого кластера в службе кластеров. Дополнительные сведения см. в этой статье в разделе об ограничениях ресурсов.
При использовании агрессивного мониторинга кластера продолжительная приостановка в работе виртуальной машины может активировать отработку отказа. Отработка отказа часто приводит к более длительному простою, чем приостановка обслуживания, поэтому рекомендуется использовать нестрогий мониторинг, чтобы избежать активации отработки отказа, пока виртуальная машина приостановлена для обслуживания. Дополнительные сведения о настройке пороговых значений кластера на виртуальных машинах Azure см. в рекомендациях по кластеру.
Ограничения
При работе с экземпляром отказоустойчивого кластера или группами доступности и SQL Server на Виртуальных машинах Azure учитывайте следующие ограничения.
MSDTC
Виртуальные машины Azure поддерживают координатор распределенных транзакций (Майкрософт) в Windows Server 2019 с хранилищем на общих томах кластера (CSV) и с Azure Load Balancer ценовой категории "Стандартный" или на виртуальных машинах SQL Server, использующих общие диски Azure.
Координатор распределенных транзакций (Майкрософт) не поддерживается на Виртуальных машинах Azure в Windows Server 2016 и более ранних версий с общими томами кластера по следующим причинам:
- Кластерный ресурс MSDTC нельзя настроить для использования общего хранилища. В Windows Server 2016, если вы создаете ресурс MSDTC, не будет отображаться доступное общее хранилище, даже если оно существует. Эта проблема устранена в Windows Server 2019.
- Load Balancer ценовой категории "Стандартный" не обрабатывает порты RPC.
Следующие шаги
Теперь, когда вы знакомы с различиями при использовании отказоустойчивого кластера Windows с SQL Server на виртуальных машинах Azure, ознакомьтесь с возможностями высокого уровня доступности: группами доступности и экземплярами отказоустойчивого кластера. Если вы готовы приступить к работе, обязательно ознакомьтесь с рекомендациями по настройке.