Группы доступности Always On для SQL Server на виртуальных машинах Azure

Применимо к: SQL Server на виртуальной машине Azure

В этой статье представлены группы доступности AlwaysOn (AG) для SQL Server на виртуальных машинах (ВМ) Azure.

Чтобы приступить к работе, см. руководство по группе доступности.

Обзор

Группы доступности AlwaysOn на виртуальных машинах Azure аналогичны локальным группам доступности AlwaysOn и зависят от базового отказоустойчивого кластера Windows Server. Но виртуальные машины размещаются в среде Azure, а значит придется учесть ряд дополнительных аспектов, например избыточность виртуальных машин и маршрутизация трафика в сети Azure.

На следующей схеме показано использование группы доступности SQL Server на виртуальных машинах Azure:

Группа доступности

Примечание

Теперь можно поднять и перенести решение группы доступности на SQL Server на виртуальных машинах Azure с помощью Azure Migrate. Дополнительные сведения см. в разделе Перенос группы доступности.

Избыточность виртуальных машин

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

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

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

При создании виртуальных машин Azure необходимо выбрать между настройкой групп доступности и зон доступности. Виртуальная машина Azure не может входить в обе группы.

Хотя Зоны доступности могут обеспечить лучшую доступность, нежели наборы доступности (99,99% по сравнению с 99,95%), также следует учитывать и производительность. Виртуальные машины в группе доступности могут быть помещены в группу размещения поблизости, которая гарантирует, что они находятся близко друг к другу, сводя к минимуму задержку в сети между ними. Виртуальные машины, расположенные в разных Зонах доступности, будут иметь большую задержку в сети между собой, что может увеличить время, необходимое для синхронизации данных между первичной и вторичной репликами. Это может вызвать задержки в первичной реплике, а также увеличить вероятность потери данных в случае незапланированного переключения при отказе. Важно протестировать предлагаемое решение под нагрузкой и убедиться, что оно соответствует SLA как по производительности, так и по доступности.

Соединение

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

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

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

Кроме того, имеются некоторые различия в поведении между функциями прослушивателя VNN и прослушивателя DNN, которые важно отметить:

  • Время восстановления после отказа: время восстановления после отказа сокращается при использовании прослушивателя DNN, поскольку нет необходимости ждать, пока балансировщик сетевой нагрузки обнаружит событие сбоя и изменит свою маршрутизацию.
  • Существующие подключения: подключения, выполненные с конкретной базой данных в группе доступности для аварийного переключения, будут закрыты, но другие подключения к первичной реплике останутся открытыми, поскольку DNN остается в сети во время аварийного переключения. Это отличается от традиционной среды VNN, где все подключения к первичной реплике обычно закрываются при отказе группы доступности, приемник отключается, а первичная реплика переходит к вторичной роли. При использовании прослушивателя DNN вам может потребоваться настроить строки подключения приложения, чтобы обеспечить перенаправление подключений к новой первичной реплике при отработке отказа.
  • Открытые транзакции: открытые транзакции для базы данных в группе доступности с аварийным переключением будут закрыты и откатятся, и вам потребуется вручную повторно подключиться. Например, в SQL Server Management Studio закройте окно запроса и откройте новое.

Для настройки прослушивателя VNN в Azure требуется балансировщик нагрузки. В Azure присутствует два основных варианта балансировщиков нагрузки: внешний (общедоступный) или внутренний. Внешний (общедоступный) балансировщик нагрузки подключен к Интернету и связан с общедоступным виртуальным IP-адресом, доступным через Интернет. Внутренний балансировщик нагрузки поддерживает клиентов исключительно в рамках одной виртуальной сети. Для любого типа балансировщика нагрузки необходимо включить Прямой возврат сервера.

Вы по-прежнему можете подключаются к отдельным репликам доступности, напрямую подключаясь к экземпляру службы. Кроме того, поскольку группы доступности обратно совместимы с клиентами зеркального отображения базы данных, можно подключаться к репликам доступности таким как участники зеркального отображения, пока реплики настроены аналогично зеркальному отображению базы данных:

  • имеется по одной первичной и вторичной реплике;
  • вторичная реплика настроена как недоступная для чтения (для параметра Вторичная реплика для чтения установлено значение Нет).

Ниже приведен пример строки подключения клиента, соответствующей этой конфигурации зеркального отображения базы данных с использованием ADO.NET или SQL Server Native Client.

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

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

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

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

Библиотека ресурсов AG отслеживает состояние внутренних компонентов SQL Server. Sp_server_diagnostics сообщает SQL Server о работоспособности этих компонентов с интервалом, контролируемым параметром HealthCheckTimeout.

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

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

Сетевая конфигурация

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

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

Базовая группа доступности

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

Например, для явного подключения с помощью TCP / IP к базе данных AG AdventureWorks на Replica_A или Replica_B базовой группы доступности (или любой группы доступности, которая имеет только одну вторичную реплику и доступ для чтения во вторичной реплике запрещен), клиентское приложение может предоставить следующую строку подключения зеркального отображения базы данных для успешного подключения к группе доступности

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Параметры развертывания

У вас есть несколько вариантов с разным уровнем автоматизации для развертывания групп доступности в SQL Server на виртуальных машинах Azure.

В следующей таблице собраны данные о доступных вариантах для сравнения.

Портал Azure, Azure CLI / PowerShell Шаблоны быстрого запуска Вручную (одна подсеть) Вручную (несколько подсетей)
Версия SQL Server 2016 и выше 2016 и выше 2016 и выше 2012 и выше 2012 и выше
Выпуск SQL Server Enterprise Enterprise Enterprise Enterprise, Standard Enterprise, Standard
Версия Windows Server 2016 и выше 2016 и выше 2016 и выше Все Все
Автоматическое создание кластера Да Да Да Нет Нет
Создает группу доступности и прослушиватель Да Нет Нет Нет Нет
Независимое создание прослушивателя и подсистемы балансировки нагрузки Недоступно Нет Нет Да Н/Д
Возможность создать прослушиватель DNN Недоступно Нет Нет Да Н/Д
Конфигурация кворума WSFC Облако-свидетель Облако-свидетель Облако-свидетель Все Все
Аварийное восстановление в нескольких регионах Нет Нет Нет Да Да
Поддержка нескольких подсетей Да Нет Нет Недоступно Да
Поддержка существующего каталога AD Да Да Да Да Да
Аварийное восстановление с несколькими зонами в одном регионе Да Да Да Да Да
Распределенная группа доступности без домена приложения Нет Нет Нет Да Да
Распределенная группа доступности без кластера Нет Нет Нет Да Да
Требуется подсистема балансировки нагрузки или DNN Нет Да Да Да Нет

Дальнейшие действия

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

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