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

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

Подключение

Чтобы обеспечить аналогичное локальному опыту подключение к прослушивателю группы доступности, разверните виртуальные машины 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 Native Client
• Подключение клиентов к сеансу зеркального отображения базы данных (SQL Server)
• Подключение к слушателю группы доступности в гибридной ИТ-среде
• Прослушиватели групп доступности, подключение клиентов и переключение на отказоустойчивость приложений (SQL Server)
• Использование строк подключения к зеркально отображаемой базе данных с группами доступности

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

При создании прослушивателя группы доступности на традиционном локальном отказоустойчивом кластере 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 библиотека ресурсов группы доступности (DLL) определяет работоспособность группы доступности (ГД) на основе механизма аренды ГД и определения работоспособности Always On. Библиотека AG DLL представляет работоспособность ресурсов с помощью операции IsAlive. Монитор ресурсов опрашивает IsAlive с интервалом сердцебиения кластера, который задается кластерными значениями CrossSubnetDelay и SameSubnetDelay. На основном узле служба кластера инициирует отказоустойчивость всякий раз, когда вызов IsAlive к библиотеке DLL ресурсов возвращает, что AG недоступна.

Библиотека ресурсов 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, некоторые с более высоким уровнем автоматизации, чем другие.

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

Связанный контент

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