Создание группы доступности на основе кластера Failover

Вкратце о сути: каждый узел группы доступности должен быть членом отказоустойчивого Windows-кластера. Отдельные экземпляры SQL Server могут содержать две и более групп доступности. Любая группа доступности может содержать в себе до 8 вторичных реплик.

Что это и зачем требуется

Группы доступности AlwaysOn — альтернативное решение высокой доступности и disaster recovery, позволяющее отказаться от зеркального отображения БД на уровне предприятия. Когда БД не способны справиться с объёмом запросов или существует риск потери важных данных при неисправностях на сервере, группы доступности AlwaysOn сохраняют бесперебойность работы системы, частично выполняя на репликах нагрузку по чтению из баз данных.

Группы доступности необходимы при следующих условиях:

  • Требуется избыточная доступность БД. Для этого ноды должны располагаться в ЦОД, которые географически разнесены по разным местам. Требование обусловлено необходимостью обеспечения доступности БД при возникновении неисправности на любой из нод.

  • Требуется повысить скорость ответов БД по принципу горизонтального расширения. При этом в кластере определяется мастер-нода, выполняющая операции запись и чтения. Другие ноды — слушатели, которые позволяют считывать информацию при запросах обращения.

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

Подготовка инфраструктуры

1.1 В виртуальном дата-центре необходимо создать ВМ и пользователей. Создайте три машины, присвоив им имена в зависимости от ролей, настройте кастомизацию.

VDC


1.2 Следующий этап: настройка контроллера домена. Укажите роли AD, DNS, Failover Cluster.

roles Failover Cluster


select Failover Cluster


1.3 Укажите роль контроллера домена

Deployment configuration


1.4 Создайте в Active Directory компьютеры ND01 и ND02.

Failover Cluster


1.5 Установите компонент Failover Cluster на ND01 и ND02

компонент Failover Cluster


1.6 Теперь нужно создать кластер отказоустойчивости на контроллере домена DC01. Добавьте в него ранее созданные ноды.

Кластер отказоустойчивости


1.7 Укажите имя кластера.

Даём имя кластеру


1.8 На этапе создания кластера рекомендуем не использовать опцию добавления массивов в каталог. Если забыли и оставили чекбокс включённым — не страшно, это можно сделать и позже.

Отмена добавления массивов в каталог


1.9 Кластер создан.

Кластер создан


Создание свидетеля (Quorum Witness Share)

2.1 Теперь можно перейти к настройке Quorum. Выполните действия, которые приведены на скриншоте.

Quorum Witness Share


2.2 Укажите file share у конфигурации свидетеля Quorum.

file share

file share2


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

Указываем UNC путь


2.4 На этом этапе у вас может возникнуть ошибка такого типа:

Error


Она означает, что в настройках свидетеля нужно перенастроить права доступа к сетевой директории.

Настройки прав доступа к сетевой директории


2.5 Следующий этап — установка MS SQL 2015 Enterprise на ноды в кластере. Убедитесь, что брандмауэр не будет блокировать работу в сети домена у всех компьютеров из кластера.

Брандмауэр


2.6 Установка MS SQL должна выполняться в standalone режиме. Не должно быть никаких дополнительных модулей. В качестве пользователя мы для примера указали Администратора доменной сети. Для рабочих серверов в целях безопасности создавайте отдельного пользователя.

MS SQL в standalone режиме

MS SQL в standalone режиме

2.7 Установите SQL Management Studio на обе ноды в кластере.

Добавление тестовой базы данных в MSSQL

3.1 Установите тестовую БД в ноде ND01. Присвойте ей название, например, Bike-Store. Мы взяли БД для теста отсюда.

Создаём БД

Создаём БД


3.2 Когда БД установится, выделите созданную базу данных и выберите файл БД комбинацией Ctrl+O.

Выбираем файл БД


3.3 Когда файл откроется, нажмите F5 или «Выполнить».

Выбираем файл БД


3.4 Новая база добавлена, теперь её нужно наполнить. Откройте файл BikeStores Sample Database — load data.sql и добавьте аналогичным способом. Если вы всё сделали правильно, в нижней части экрана появится сообщение «Запрос успешно выполнен».

Запрос успешно выполнен


3.5 Важно! Обязательно сделайте резервную копию базы данных перед тем, как приступать к развертыванию группы доступности. Если этого не сделать, группа доступности не будет создана.

Делаем резервную копию БД

Настройка Always On в MS SQL Server

4.1 Обязательно включите поддержку схемы AlwaysON в SQL Server Configuration Manager в свойствах экземпляра каждой ноды.

Включаем поддержку схемы AlwaysON в SQL Server Configuration Manager


4.2 Выберите узел «Always On High Availability» на ноде ND01 в SQL Server Management Studio и запустите Мастер настройки группы доступности (New Availability Group Wizard).

Мастер настройки группы доступности


4.3 Присвойте имя группе доступности. В нашем случае это BikeStores-AG.

Присваиваем имя нашей группе доступности

Если нажать «Добавить реплику», можно подключиться ко второму серверу SQL. Таким образом добавляется до 8 серверов.

Ключевые параметры

  • Исходная роль  — Primary или Secondary роль реплики на момент создания группы;

  • Автоматический переход — при недоступности БД, AlwaysOn присвоит primary роль другой реплике. Отметьте этот чекбокс;

  • Режим доступности  — есть два режима, Synchronous Commit и Asynchronous Commit. В первом транзакции, поступающие на основную реплику, отправляются на другие Secondary реплики с синхронным режимом. Когда они запишут транзакцию на диск, Primary реплика завершит транзакцию. За счёт этого при сбое основной реплики данные не будут утеряны. Во втором, асинхронном режиме, Primary реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;

  • Вторичная реплика для чтения — отвечает за возможность select-запросов к Secondary репликам. Когда стоит значение yes, клиенты даже при соединении без ApplicationIntent=readonly могут получить доступ только на чтение;

  • Для фиксации требуются синхронизированные получатели — число синхронизированных Secondary реплик для завершения транзакции. Выставляется в зависимости от количества реплик. Если их будет меньше заданного числа (такое может случиться при сбое), БД группы доступности окажутся недоступны даже для чтения.

Синхронизированные получатели


4.4 В параметрах резервного копирования можно указать, где выполняется резервное копирование. Рекомендуем оставить всё как есть: Предпочитать вторичную.

Параметры резервного копирования


4.5 Задайте DNS-имя прослушивателя группы доступности, порт и IP-адрес.

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


4.6 Этап тестирования покажет, всё ли было сделано верно. Если все тесты успешные, нажмите кнопку «Далее».

РезультатРабота мастера завершена

Готово. Вы завершили первичную настройку группы доступности AlwaysON.

В дальнейшем рекомендуем провести тесты отказоустойчивости, поочерёдно отключая каждую ноду в кластере, а также отправляя простые запросы select, insert. Это позволит убедиться в работоспособности системы, а также выявить возможные узкие места, если что-то было сделано неверно.

Надеемся, что наша инструкция по созданию групп доступности AlwaysOn поможет добиться высокого уровня отказоустойчивости вашей инфраструктуры. Если у вас остались вопросы или непонятны какие-то моменты – напишите о них. Технические специалисты Cloud4Y готовы помочь с решением задач разного уровня сложности. Благодарим за внимание!

Вверх!