Настройка постоянно действующих групп высокой доступности на SQL Server

В этой статье мы познакомим вас с пошаговым руководством по установке и настройке групп доступности Always On на SQL Server, работающем под управлением Windows Server 2019, обсудим сценарии аварийного переключения и некоторые другие связанные темы.

Группы доступности Always On обеспечивают высокую доступность в Microsoft SQL Server. Always On появился в выпуске MSSQL 2012.

Возможности групп доступности AlwaysOn в SQL Server

Для чего вы можете использовать группы доступности SQL Server?

• Высокая доступность MS SQL и автоматическое переключение при сбое;

• Балансировка нагрузки запросов SELECT между узлами (вторичные реплики могут быть доступны для чтения);

• Резервное копирование со вторичных реплик;

• Избыточность данных. Каждая реплика хранит копии базы данных группы доступности.

Always On основан на отказоустойчивом кластере Windows Server (WSFC). WSFC отслеживает узлы группы доступности и обеспечивает автоматическое переключение при сбое. Начиная с MS SQL Server 2017, Always On можно использовать без WSFC, а также на хостах Linux. При создании кластера на базе Linux вместо WSFC можно использовать Pacemaker.

Функция Always On доступна в версии Standard, но имеет некоторые ограничения:

• Он ограничен двумя репликами (первичной и вторичной);

• Вторичную реплику нельзя использовать для чтения данных;

• Вторичную реплику нельзя использовать для резервного копирования MS SQL;

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

В версии Enterprise ограничений нет.
Рассмотрим условия.

• Группа доступности Always On — набор реплик и баз данных;

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

Always On основан на WSFC. Каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. Каждая группа доступности может иметь до 8 вторичных реплик.

В случае сбоя первичной реплики кластер проголосует за новую первичную реплику, а Always On сделает одну из вторичных реплик первичной. Поскольку при работе с Always On пользователи подключаются к Listener (специальному IP-адресу кластера и соответствующему DNS-имени), появится возможность снова выполнять запросы на запись. Прослушиватель также отвечает за балансировку запросов SELECT между вторичными репликами.

Настройка отказоустойчивого кластера Windows для группы доступности AlwaysOn

Прежде всего, мы должны настроить отказоустойчивый кластер на всех узлах, используемых Always On.

Вот моя конфигурация:

• 2 виртуальные машины под управлением Windows Server 2019

• 2 экземпляра SQL Server 2019 Enterprise

• Имена хостов узлов — testnode1 и testnode2. Имена экземпляров SQL Server — node1 и node2.

Добавьте роль Отказоустойчивая кластеризация с помощью диспетчера серверов или установите ее через PowerShell:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Установка происходит автоматически, и вам пока не нужно ничего настраивать. Запустите оснастку Диспетчер отказоустойчивого кластера (

FailoverClusters.SnapInHelper.msc

) и создайте новый кластер.

Добавьте имена хостов, которые вы хотите присоединиться к вашему кластеру.

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

Укажите имя кластера, выберите сеть и IP-адрес кластера. Имя кластера появится в DNS автоматически; вам не нужно создавать запись DNS вручную. В моем случае имя кластера — ClusterAG.

Снимите флажок с параметра Добавить все подходящее хранилище в кластер, поскольку мы сможем добавить диски позже.

В кластере всего два узла, поэтому необходимо настроить Кворум кластера. Кворум кластера является решающим голосом. Например, если один из узлов кластера становится недоступным, кластер должен определить, какие узлы действительно находятся в сети и могут видеть друг друга. Кворум кластера обеспечивает согласованность кластера (Кластер -> Дополнительные действия -> Настройка параметров кворума кластера).

Выберите вариант свидетеля кворума.

Затем выберите тип свидетеля: файловый ресурс-свидетель.

Укажите UNC-путь к общей папке. Создайте каталог самостоятельно. Он должен присутствовать на сервере за пределами вашего отказоустойчивого кластера.

При настройке кластера вы можете увидеть следующую ошибку:

There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.

Вероятно, учетная запись пользователя, под которым работает кластер, не имеет NTFS-прав на доступ к общей папке. По умолчанию кластер работает под учетной записью локального пользователя. Вы можете предоставить права доступа к папке всем компьютерам кластера или изменить учетную запись службы кластера и предоставить ей соответствующие права.

Базовая настройка отказоустойчивого кластера Windows завершена.

Настройка группы доступности Always On на MS SQL Server

После стандартной установки экземпляра SQL Server вы можете включить и настроить группы доступности Always On. Включите их в свойствах экземпляра Диспетчера конфигурации SQL Server. Как вы можете видеть на скриншоте, SQL Server уже определил свою принадлежность к кластеру WSFC. Установите флажок Включить группы доступности Always On и перезапустите службу экземпляра MSSQL. Сделайте то же самое для второго экземпляра.

Запустите SQL Server Management Studio, подключитесь к своему хосту, нажмите Always On High Availability и запустите Мастер создания группы доступности.

Укажите имя для своей группы доступности Always On и выберите Обнаружение работоспособности на уровне базы данных. Используя эту опцию, Always On сможет определять, когда база данных неработоспособна.

Выберите базы данных SQL Server, чтобы добавить их в группу доступности Always On.

Нажмите Добавить реплику и подключите второй SQL-сервер. Таким образом вы можете добавить до 8 серверов.

• Начальная роль — это роль-реплика к моменту создания группы. Он может быть первичным или вторичным;

• Автоматическое переключение при отказе - если база данных становится недоступной, Always On перенесет основную роль на другую реплику. Проверьте этот пункт;

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

• Readable Secondary — параметр, позволяющий выполнять запросы SELECT к вторичным репликам. Если значение равно «да», клиенты смогут получить доступ только для чтения, даже если они подключатся без

  ApplicationIntent=readonly

• Необходимые синхронизированные вторичные реплики для фиксации — это количество синхронизированных вторичных реплик для завершения транзакции. Установите его в зависимости от количества реплик, я поставлю 1.

Ничего не редактируйте на вкладке Конечная точка.

На вкладке Настройки резервного копирования вы можете выбрать, откуда будут создаваться резервные копии. Оставьте здесь настройки по умолчанию: Предпочитать вторичный.

Укажите имя, порт и IP-адрес прослушивателя группы доступности.

Оставьте настройки Маршрутизация только для чтения без изменений.

Выберите тип синхронизации реплики. Я оставляю первый пункт (Автоматическое заполнение) отмеченным.

Затем ваши настройки должны быть подтверждены. Если ошибок нет, нажмите «Готово», чтобы применить изменения.

В моем случае все тесты прошли успешно, но на этапе «Результаты» после установки мастер показал ошибку создания прослушивателя группы доступности. В журналах событий кластера появилась ошибка EVENTID 1194:

Cluster network name resource failed to create its associated computer object in the domain.

Это означает, что у кластера недостаточно прав для создания прослушивателя. В документации указано, что объекту вашего кластера достаточно предоставить право на создание объектов компьютерного типа. Проще это сделать с помощью делегирования привилегий в AD (или быстрого, но небезопасного варианта — временно добавить объект CLUSTERAG$в группу «Администраторы домена»).

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

Укажите IP-адрес, порт и DNS-имя прослушивателя.

Убедитесь, что прослушиватель появился в разделе Прослушиватели группы доступности вашей группы Always On.

Таким образом, вы завершили базовую настройку группы доступности Always On.

SQL Server Always On: проверка работоспособности и аварийное переключение

Давайте посмотрим на панель мониторинга группы доступности (Показать панель мониторинга).

Все ок, группа создана и работает.

Давайте попробуем сделать node2 основным экземпляром вручную. Щелкните правой кнопкой мыши группу доступности и выберите Отработка отказа.

Обратите внимание на значение Готовность к аварийному переключению. Без потери данных означает, что никакие данные не будут потеряны.

Подключитесь к узлу2.

Нажмите «Готово».

Убедитесь, что node2 стал первичной репликой (первичным экземпляром) в группе доступности.

Убедитесь, что слушатель работает правильно. Укажите DNS-имя и порт прослушивателя, разделенные запятой, в SSMS:

ag1-listener-1,1445

Запустите простую вставку, выберите и обновите SQL-запросы в вашей базе данных.

Затем проверьте автоматический переход на другой ресурс первичной реплики. Просто завершите процесс sqlservr.exe на TESTNODE2.

Проверьте состояние группы доступности на оставшемся узле: TESTNODE1\NODE1.

Кластер автоматически изменил статус testnode1\node1 на основной, поскольку testnode2\node2 стал недоступен.

Проверьте состояние прослушивателя, поскольку клиенты будут использовать его для подключения.

В моем случае я успешно подключился к прослушивателю, но при попытке доступа к базе данных получил следующую ошибку:

Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.

Ошибка возникла из-за параметра Требуются синхронизированные вторичные серверы для фиксации. Поскольку при настройке мы установили для него значение 1, Always On не позволяет ему подключаться к базе данных, поскольку у нас осталась только одна первичная реплика.

Установите значение 0 и попробуйте выполнить запрос еще раз.

Testnode1 сохранил статус основного экземпляра, а testnode2 стал вторичным. Данные, которые мы изменили на тестовом узле 1, когда тестовый узел 2 был выключен, успешно синхронизировались после включения компьютера.

Итак, мы убедились, что все работает корректно и данные будут доступны для чтения/записи в случае критического сбоя.

Вы можете легко настроить группы доступности Always On. Если вы хотите создать решение для отработки отказа на базе SQL Server, группы доступности справятся с этим хорошо.