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

Обновлено 03.07.2017

Группы доступности 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, в группах доступности отсутствует роль следящего.

схема AlwaysOn

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

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

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

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

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

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

Для управления отказоустойчивым кластером следует войти в систему с использованием учетной записи пользователя домена. Эта учетная запись необходима для доступа к доменным службам Actvie Directory и всем серверам кластера, включая удаленные серверы

ошибка создания WSFC

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

Подробнее на Microsoft https://technet.microsoft.com/ru-ru/library/dn505754%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

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

добавляем отказоустойчивую кластеризацию

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

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

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

проверка железа для кластера

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

добавление серверов для тестирования

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

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

Параметры тестирования серверов кластера

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

Выбор тестов WSFC

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

выполнение тестирования WSFC

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

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

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

Полученные результаты

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

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

нехватка прав учетной записи WSFC

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

Создаем кластер WIndows

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

добавление узлов в кластер hyper-v

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

задаем имя и ip адрес кластеру

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

Найдена включенная учетная запись компьютера (объект-компьютера) для "имя кластера". Как правило, это означает, что указанное имя используется другим компьютером или является сетевым именем кластера. Если это не так, отключите или удалите учетную запись

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

ошибка учетной записи WSFC

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

Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста подождите

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

ошибка при создании кластера

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

Произошло нарушение ограничения

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

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

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

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

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

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

В Windows Server 2012 R2 есть возможность создать отсоединенный от Active Directory кластер. При этом ни CNO, ни VCO в AD DS не создается. Эта возможность предназначена для определенных типов развертывания кластера. Об этом ниже

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

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

Если вы создали CNO в контейнере компьютеров по умолчанию, а не в подразделении, вам не нужно выполнять последний шаг с VCO. В этом сценарии администратор кластера может создать до 10 VCO без какой-либо дополнительной настройки

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

Создание организационной единицы AD

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

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

Задаем имя компьютеру

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

Отключаем учетку кластера в AD

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

выключенная CNO

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

Назначение прав на OU кластера

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

Предоставление полных прав

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

Созданный кластер

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

Настройка кворума в кластере

 

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

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

настроить файловый ресурс-свидетель

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

указываем unc путь папки кворума

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

создание шары для кворума

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

Ошибка при изменении параметров кворума. Параметры кворума кластера не изменены. Ошибка при настройке ресурса-свидетеля. Не удалось сохранить изменения свойств для "Файловый ресурс-свидетель" Не верное имя пользователя или пароль.

Ошибка создания кворума

Автор - Сёмин Иван

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

  1. Mike:

    Статья не закончена?( с WSFC все понятно, интересно с AlwaysOn

  2. Иван Семин:

    Да, все никак не доходят руки

  3. DENis:

    Где можно изучить вторую часть с Always On?Статья однозначно полезная,жаль нету второй части(.Может автор запилит вторую часть:))

  4. Иван Семин:

    Она в процессе, лежит пока не дописанная на половину, я думаю, что заставлю себя это сделать за это лето.

  5. DENis:

    Ок,автору респект,будем ждать))

  6. Андрей:

    статья резко закончилась на самом интересном месте )
    лето прошло, ждём с нетерпением…

  7. bammbr:

    Так и не было окончания статьи?

  8. Владимир:

    Да что там того Always On … некст-некст-финиш.
    Делаете все по умолчанию и будет вам счастье.

  9. Алибаба:

    на файловую шару (вместо диска-свидетеля), видел рекомендации добавлять ПОЛНЫЕ права для каждой ноды кластера, либо группы безопасности с нодами.

  10. big:

    Автор, где вторая часть? 3 года руки не доходят написать? уже sql 2022 скоро выйдет. Раз уж скал, что допишешь, мог бы слово и сдержать.

  11. sabo:

    автор где 2я часть ? уже 2023 год наступит скоро. До сих пор руки не доходят написать статью? или руки отвалились?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *