Группы доступности 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 не может участвовать в обоих.

Хотя зоны доступности могут обеспечить более высокую доступность, чем группы доступности (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;

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

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

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

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

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