Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения:
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
Хотя кластер с двумя узлами может функционировать без ресурса кворума, клиентам строго необходимо использовать ресурс кворума для поддержки рабочей среды. Ни один кластер не пройдет проверку без ресурса кворума.
Технически кластер из трех узлов может перенести потерю одного узла (останется два) без ресурса кворума. Однако после сокращения кластера до двух узлов есть риск того, что кластерные ресурсы будут переведены в автономный режим для предотвращения сценария разделения в случае потери узла или сбоя связи между ними. Настройка ресурса кворума позволяет ресурсам кластера оставаться в сети даже при наличии лишь одного активного узла.
Диск-свидетель является наиболее устойчивым вариантом кворума. Но для использования диска-свидетеля на виртуальной машине Azure с SQL Server необходимо использовать общий диск 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 работают прозрачно с FCI и группами доступности при использовании DNN, но существуют определенные функции, которые могут потребовать особого рассмотрения.
Поддерживаемые ОС: Windows Server 2016 и более поздней версии
Поддерживаемая версия SQL: SQL Server 2019 CU2 (FCI) и SQL Server 2019 CU8 (AG)
Поддерживаемое решение HADR: экземпляр отказоустойчивого кластера и группа доступности
Чтобы приступить к работе, научитесь настраивать ресурс имени распределенной сети для экземпляра отказоустойчивого кластера или группы доступности.
При использовании DNN с другими функциями SQL Server следует учитывать дополнительные рекомендации. Дополнительные сведения см. в статьях о взаимодействии FCI и DNN и взаимодействии AG и DNN.
Примечание.
Для каждой группы доступности или экземпляра отказоустойчивого кластера в одном кластере требуется собственная независимая точка подключения, будь то прослушиватель VNN или прослушиватель DNN.
Действия по восстановлению
При обнаружении сбоя служба кластеров выполняет корректирующие действия. Это действие может перезапустить ресурс на существующем узле или перенести ресурс на другой узел в случае отказа. После инициирования корректирующих мер потребуется некоторое время для их выполнения.
Например, перезапущенная группа доступности переходит в режим подключения к сети в соответствии со следующей последовательностью:
- В режим подключения к сети переходит 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, может наблюдаться небольшое снижение производительности в течение нескольких минут перед приостановкой работы виртуальной машины.
Узкое место в ресурсах во время обслуживания платформы может создать впечатление, что AG или FCI не функционируют для службы кластера. Дополнительные сведения см. в разделе об ограничениях ресурсов этой статьи.
Если вы используете агрессивный мониторинг кластера, расширенная приостановка виртуальной машины может активировать переключение на резерв. Переключение на резервную систему часто приводит к более длительному простою, чем приостановка обслуживания. Рекомендуется использовать ослабленный мониторинг, чтобы избежать срабатывания механизма аварийного переключения, пока виртуальная машина приостановлена в процессе обслуживания. Дополнительные сведения о настройке пороговых значений кластера на виртуальных машинах Azure см. в рекомендациях по кластеру.
Ограничения
При работе с экземпляром отказоустойчивого кластера или группами доступности и SQL Server на Виртуальных машинах Azure учитывайте следующие ограничения.
MSDTC
Виртуальные машины Azure поддерживают координатора распределенных транзакций Майкрософт (MSDTC) в Windows Server 2019 с хранилищем на кластеризованных общих томах (CSV) и Azure Standard Load Balancer или на виртуальных машинах SQL Server, использующих общие диски Azure.
Координатор распределенных транзакций (Майкрософт) не поддерживается на Виртуальных машинах Azure в Windows Server 2016 и более ранних версий с общими томами кластера по следующим причинам:
- Кластерный ресурс MSDTC нельзя настроить для использования общего хранилища. В Windows Server 2016, если вы создаете ресурс MSDTC, он не отображает общее хранилище, доступное для использования, даже если хранилище доступно. Эта проблема устранена в Windows Server 2019.