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


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

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

Группы доступности AlwaysOn — это решение высокой доступности и аварийного восстановления, является альтернативой зеркальному отображению баз данных на уровне предприятия. Если БД не справляется с потоком запросов или есть опасения, что при сбое на сервере пропадут ценные данные, есть смысл использовать это решение. Группы доступности AlwaysOn могут отвечать за выполнение сразу двух задачи: высокий уровень доступности обеспечивает бесперебойную работу системы, а нагрузка по чтению из БД частично выполняется на репликах.

Создание группы доступности может понадобиться, если вам необходимо:

  • Создать избыточную доступность баз данных (в этом случае рекомендуем располагать ноды в геоудалённых дата-центрах, т.к. избыточная доступность предполагает доступность БД при любых технических неполадках на любой из нод);

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

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

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

Сначала необходимо создать виртуальную машину и пользователей. В VDC создаем 3 ВМ, даём имена согласно ролей, выполняем настройки кастомизации.

VDC


После этого переходим к этапу настройки контроллера домена. Устанавливаем роли AD, DNS, Failover Cluster.


roles Failover Cluster


select Failover Cluster


Устанавливаем роль контроллера домена


Создаём в AD компьютеры  ND01 и ND02.


Failover Cluster


На ВМ ND01 и ND02 ставим компонент Failover Cluster

компонент Failover Cluster

Теперь переходим к созданию кластера отказоустойчивости. На контроллере домена DC01 создаём кластер отказоустойчивости и добавляем в него наши ноды.

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


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

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


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

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


Создание кластера завершено.

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


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

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

Quorum Witness Share


В конфигурации свидетеля кворума указываем file share.

file share


file share2


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

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


Если после создания свидетеля у вас возникнет ошибка как на примере ниже,

Error


…то в этом случае необходимо проверить настройки прав доступа к сетевой директории, указанной в настройках свидетеля.

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


Переходим к установке MS SQL 2015 Enterprise на ноды в кластере. Перед установкой модуля необходимо отключить брандмауэр на работу в доменной сети на всех ВМ, участвующих в кластере.

Брандмауэр


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

MS SQL в standalone режиме


MS SQL в standalone режиме

Затем необходимо установить SQL Management Studio на обе ноды в кластере.


Получить консультацию об облачных сервисахЗаказать звонок





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

На ноде ND01 устанавливаем тестовый образец базы данных. Имя тестовой БД будет Bike-Store. Тестовая БД взята отсюда.

Создаём БД


Создаём БД


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

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


После открытия файла нажимаем «Выполнить»

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


Когда добавили новую базу, необходимо наполнить её. Для этого открываем файл BikeStores Sample Database - load data.sql  и добавляем его таким же методом. В конце операции должно появиться сообщение, что «Запрос успешно выполнен».

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


Важно! Перед развертыванием группы доступности обязательно делаем резервную копию БД, в противном случае не получится создать группу доступности

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

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

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

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


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

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


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

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

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

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

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

  • Автоматический переход – если база данных станет недоступна, Always On переведёт primary роль на другую реплику. Отмечаем чекбокс;

  • Режим доступности – возможно выбрать Synchronous Commit или Asynchronous Commit. При выборе синхронного режима транзакции, поступающие на primary реплику, будут отправлены на все остальные вторичные реплики с синхронным режимом. Primary реплика завершит транзакцию только после того, как реплики запишут транзакцию на диск. Таким образом исключается возможность потери данных при сбое primary реплики. При асинхронном режиме основная реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;

  • Вторичная реплика для чтения – параметр, задающий возможность делать select-запросы к вторичным репликам. При значении yes, клиенты даже при соединении без ApplicationIntent=readonly смогут получить read-only доступ;

  • Для фиксации требуются синхронизированные получатели – число синхронизированных вторичных реплик для завершения транзакции. Нужно выставлять в зависимости от количества реплик. Имейте в виду, что, если вторичных синхронизированных реплик станет меньше указанного числа (например, при аварии), базы данных группы доступности станут недоступны даже для чтения.

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


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

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


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

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


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

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

На этом первичная настройка группы доступности AlwaysON завершена. Вы можете провести тесты отказоустойчивости, попеременно отключая каждую ноду в кластере, а также давая простые запросы select, insert.

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


Полезный материал?
0
0
автор: Олег
опубликовано: 21.01.2021
Читайте нас: 
Последние статьи
Вверх!