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

  • Статья

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

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

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

Обзор

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

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

Availability Group

Примечание.

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

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

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

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

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

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

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

Соединение

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

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

  • имеется по одной первичной и вторичной реплике;
  • Вторичная реплика настроена как нечитаемая (параметр "Дополнительный для чтения " имеет значение No).

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

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

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

Для одной подсети требуется подсистема балансировки нагрузки

При создании прослушивателя группы доступности на традиционном локальном отказоустойчивом кластере Windows Server (WSFC) запись DNS создается для прослушивателя с указанным IP-адресом, и этот IP-адрес сопоставляется с MAC-адресом текущей первичной реплики в таблицах ARP коммутаторов и маршрутизаторов в локальной сети. Кластер делает это с помощью Gratuitous ARP (GARP), где он передает последнее сопоставление IP-адресов в MAC в сеть всякий раз, когда новый первичный выбран после отработки отказа. В этом случае IP-адрес предназначен для прослушивателя, а MAC — текущей первичной реплики. GARP принудительно выполняет обновление записей таблицы ARP для коммутаторов и маршрутизаторов, а также для всех пользователей, подключающихся к IP-адресу прослушивателя, легко направляется в текущую первичную реплику.

По соображениям безопасности трансляция в любом общедоступном облаке (Azure, Google, AWS) не разрешена, поэтому использование ARPs и GARPs в Azure не поддерживается. Чтобы преодолеть эту разницу в сетевых средах, виртуальные машины SQL Server в одной группе доступности подсети используют подсистемы балансировки нагрузки для маршрутизации трафика на соответствующие IP-адреса. Подсистемы балансировки нагрузки настраиваются с интерфейсным IP-адресом, соответствующим прослушивателю, и порт пробы назначается таким образом, чтобы Azure Load Balancer периодически опрашивает состояние реплик в группе доступности. Так как только первичная реплика SQL Server отвечает на проверку TCP, входящий трафик затем направляется на виртуальную машину, которая успешно отвечает на пробу. Кроме того, соответствующий порт пробы настраивается в качестве IP-адреса кластера WSFC, обеспечивая реагирование основной реплики на пробу TCP.

Группы доступности, настроенные в одной подсети, должны использовать подсистему балансировки нагрузки или распределенное сетевое имя (DNN) для маршрутизации трафика в соответствующую реплику. Чтобы избежать этих зависимостей, настройте группу доступности в нескольких подсетях, чтобы прослушиватель группы доступности был настроен с IP-адресом для реплики в каждой подсети и может соответствующим образом направлять трафик.

Если вы уже создали группу доступности в одной подсети, ее можно перенести в среду с несколькими подсетами.

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

Для 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

Варианты развертывания

Совет

Устраните необходимость в azure Load Balancer или распределенном сетевом имени (DNN) для группы доступности AlwaysOn путем создания виртуальных машин SQL Server в нескольких подсетях в одной виртуальной сети Azure.

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

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