Группы доступности AlwaysOn, мой опыт

Добрый день уважаемые читатели, продолжаем с вами изучать серверные технологии, сегодня на повестке дня, мы рассмотрим вопрос, о группах доступности AlwaysOn, в SQL Server 2016. Поговорим, как создать отказоустойчивый кластер из него (Failover Cluster Instance). Уверен, что как только у вас появляется полезный сервис с высокой посещаемостью, то у вас остро встает вопрос, о том как обеспечить надлежащий уровень доступности, если да, то вы попали на правильную статью, тут все это рассматривается.

Что такое AlwaysOn в SQL Server 2016

Группы доступности AlwaysOn - это мощнейшее средство в составе дистрибутива SQL, дающее возможность для администраторов баз данных, реализовать очень высокий уровень доступности (HA, high availability) с помощью кластерных технологий и не обязательно иметь общую файловую область (Shared Storage), уменьшить время восстановления (disaster recovery, DR) после аварии или сбоя оборудования. Данная технология, является в моем понимании заменой предыдущей технологии по зеркалированию базы данных (Database Mirroring). Если вы ее уже пробовали на практике, то знаете, что это не синхронная репликация логов транзакций и базы данных.

AlwaysOn умеет в автоматическом или ручном режиме, переводить базу данных или даже группы баз данных на запасной (резервный) ресурс, есть поддержка до 4 вторичных реплик и автоматическое восстановление страниц при ошибках. В рамках этой технологии, можно производить создание кластеров БД, в разных подсетях или же сайтах, есть примеры реализации и между дата центрами.

Модель защиты AlwaysOn

Для того, чтобы что-то развернуть и управлять этим, необходимо разобраться в функциональных возможностях и тонкостях технологии, давай посмотрим за счет чего обеспечивается высокая доступность и отказоустойчивость БД в SQL Server 2016:

• Первое на что следует обратить внимание, это на уровень серверов (физическое железо + операционная система Windows Server 2012 R2), тут отказоустойчивость реализована, с помощью кластера WSFC (Windows Server Failover Cluster - отказоустойчивый кластер Windows). Именно данная технология мониторит состояние членов кластера и принимает решение о координации при отказе.
• Далее следует уровень SQL Server 2016, тут отказоустойчивость реализовывается возможностями отказоустойчивых кластерных экземпляров AlwaysOn (их еще называют инстансами). Он разворачивается на нужном количестве узлов кластера Windows Server, и в случае недоступности одного из узлов, будет производится переключение.
• Технология групп доступности AlwaysOn - реализуется на уровне баз данных, состоит из одной и более БД, которые будут переведены на дублирующий SQL Server в случае отказа.
• Еще хочу отметить уровень, на котором подключаются клиенты, тут соединение возможно, как напрямую к экземпляру SQL Server, либо же используя virtual network name (VNN, виртуального сетевого имени), оно служит для скрытия уровней отказоустойчивого кластера Windows Server и групп доступности AlwaysOn, так же делает перенаправление запросов клиентов на нужные экземпляры SQL Server 2016 и реплику БД

Что входит в группы доступности AlwaysOn

Если обратиться к сайту Microsoft, то там можно обнаружить вот такие вещи, AlwaysOn легко взаимодействует со средой баз данных доступности, данные группы доступности содержат набор баз данных получателей и источников. Реплики доступности, как раз и размещают базы данных доступности. Реплики доступности бывают вот такие:

1. Так называемая, первичная реплика, она содержит БД, являющиеся источником реплик
2. И вторая реплика, которая содержит набор БД получателей, напоминаю, их может быть до 4, о чем я уже писал выше.

Когда клиент обращается к данным, их доступность реализуется ну уровне БД, и если по какой-то причине происходит сбой на ее уровне, это не может быть причиной переключиться на другую реплику. Если рассмотреть первичную реплику, то в ней все присутствующие базы данных-источники предоставляются клиентам как на чтение, так и на запись. Когда идет синхронизация данных, то запускается механизм передачи журнала транзакций из БД-источника во все базы получателей. Там журнал будет закэширован и лишь, когда будет осуществлена передача, будет выполнена транзакция в БД-получателей. Из чего видно, что обмен осуществляется независимо, и сбои не затрагивают остальные базы данных получателей.

Как я и писал выше, вам потребуется развернуть отказоустойчивый кластер Windows Server Failover Cluster на Windows Server 2012 R2 и выше. Ваши реплики будут располагаться на разных его узлах, но в рамках одного Windows Server Failover Cluster, в группах доступности отсутствует роль следящего.

Подготовительные требования к группам доступности

Ниже я хочу написать требование, которые вам необходимо выполнить перед созданием кластера WSFC и AlwaysOn:

• Для выполнения нашей задачи вам потребуется редакция SQL Server 2016 Enterprise (подойдет и 2012, но так как он уже более старый, я использую следующие версии)
• Наличие WSFC (Windows Server Failover Cluster), так как без отказоустойчивых хостов, вам делать нечего
• Одинаковый SPN (кодировка на уровне SQL сервера)
• Созданные отдельные записи для запуска служб SQL сервера

Создание кластера высокой доступности без общих дисков

В моей реализации нет общих дисков для кворума и для сиквела, я буду использовать файловую шару для Quorum, а базы данных будут локальные. Давайте посмотрим основные требования к созданию кластера WSFC (Windows Server Failover Cluster):

• Хостов нужно как минимум два, думаю это понятно
• Если ваши хосты являются частью Active Directory, то создавать WSFC, необходимо из-под доменной учетной записи, в противном случае вы получите ошибку:

• Все узлы кластеризации, должны иметь одинаковые операционные системы, в моем случае, это самая стабильная на текущий момент Windows Server 2012 R2.
• Если вы используете общие диски с системы хранения данных или ISCSI диски с обычных серверов, то вам необходимо их подключить и разметить заранее.
• Из необязательных рекомендаций Microsoft, для лучшего управления и применения групповой политики, требуется создать отдельное организационное подразделение (OU)
• Убедитесь, что та учетная запись от имени которой вы будите создавать кластер, имеет права администратора на всех серверах, входящих в него.
• Убедитесь, что у данной учетной записи, есть права на создание объектов компьютеров в Active Directory, если их нет, то либо нужно получить права, либо попросить системного администратора создать их заранее, об этом я расскажу ниже.

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

Открываем пункт "Средства" в диспетчере серверов и находим там строку "Диспетчер отказоустойчивости кластеров".

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

На окне "Выбор серверов или кластера" указываем DNS имена ваших серверов (если хотите, то можете и ip адреса добавить)

На следующем шаге будет два пункта:

• Выполнить все тесты > актуально для первого раза
• Выполнить только выбранные тесты > удобно когда, точно знаете, что до этого исправляли и хотите проверить результат.

Мастер проверки конфигурации, покажет все тесты, которые будут произведены, обратите внимание она для вашего удобства, разбиты на категории.

Запускается тестирование, зеленым цветом, будут подсвечены удачные прохождения, красным, требующие внимания администратора.

Через короткое время вы увидите, результаты, можете ли вы создать кластер с такими серверами и настройками или нет, советую просмотреть отчет.

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

Все я добился того, что остались не значительные предписания, щелкаем правым кликом по значку диспетчера и из контекстного меню выбираем пункт "Создать кластер"

Добавляем нужные узлы.

Задаем имя кластера в виде 15 символьного имени NETBIOS и статический Ip адрес и нажимаем далее

На данном шаге вы можете увидеть ошибку:

Суть данного сообщения в том, что администратор домена, вам заранее создал объект имени кластера или CNO, но он включен, хотя по рекомендации Microsoft, должен быть отключен. (https://technet.microsoft.com/ru-ru/library/dn466519(v=ws.11).aspx) Про подготовку CNO я расскажу чуть ниже.

Жмем далее. У вас начнется собираться кластер, если у вас не выполнены все требования, то вы увидите сообщение:

Чаще всего это бывает из-за нехватки прав.

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

• Развертывание отсоединенного от Active Directory кластера, не требующего создания объекта компьютер в домене
• Либо при необходимости его внесения в домен, вам нужно создать требуемые условия, а именно подготовить объект имени кластера или CNO, чем мы и займемся ниже, это маленькое лирическое отступление, для тех людей у кого не хватает прав в AD, не выделенное заказчиком.

Подготовка объекта имени кластера или CNO

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

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

У пользователя, создающего кластер, есть разрешение на создание объектов-компьютеров для подразделения или контейнера, в котором размещаются серверы, которые войдут в кластер (https://technet.microsoft.com/ru-ru/library/dn505754%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396)

• Убедитесь, что выполнены вышеописанные требования к созданию кластера, в начале статьи
• Если прав вам не дадут, то необходимо выполнить подготовку к созданию точки административного доступа

Подготовка кластерных объектов-компьютеров в доменных службах Active Directory, начинается с CNO создания виртуальных объекты-компьютеров (VCO).

Откройте оснастку Active Directory - пользователи и компьютеры.  У вас в компании должна быть система именования учетных записей, и руководствуясь ей, вам необходимо заранее выбрать имя для кластера и имени учетно записи пользователя, от имени которого он будет создан, ей бы дадим сейчас права. Из рекомендаций Microsoft есть пожелание для кластерных объектов делать отдельную OU. Такие подразделения удобны для администрирования.

Создаем нужную OU, правым кликом по нужному месту в вашей иерархии AD.

Теперь создадим новый объект компьютера, это у нас будет (точка административного доступа CNO)

Указываем имя нашего кластера.

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

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

Теперь необходимо дать нужному пользователю права на организационную единицу. Щелкаем правым кликом по OU и выбираем свойства. Переходим на вкладку "Безопасность" и добавляем нужную группу безопасности или учетную запись пользователя.

Предоставляем ей полны доступ и сохраняем.

Теперь, когда подготовительные требования выполнены, вы спокойно соберете кластер.

Далее необходимо настроить кворум. В оснастке "Диспетчер отказоустойчивости", делаем правый клик по названию сервера и из контекстного меню выбираем "Дополнительные действия > Настроить параметры кворума кластера"

Далее выбираем свидетель кворума.

Говорим, что настройки будут лежать в общей сетевой папке "Настроить файловый ресурс-свидетель"

Задаем путь до сетевой папки.

Проверяем все настройки и подтверждаем их.

Если учетной записи не хватит прав на сетевую шару, то вы увидите ошибку: