Как развернуть отказоустойчивый кластер MS SQL Server 2012 на Windows Server 2012R2 для новичков

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

Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.

P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.

Этап 1 — Подготовка


Основные требования к аппаратному и программному обеспечению:
  • Наличие минимум 2-х узлов(физических/виртуальных), СХД
  • MS Windows Server, MS SQL ServerСХД
  • СХД
    1. Доступный iSCSI диск для баз данных
    2. Доступный iSCSI диск для MSDTC
    3. Quorum диск


Тестовый стенд:
  • Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD)
  • Хранилище iSCSI*
  • 2xWindows Server 2012R2(для кластера WS2012R2C1 и WS2012R2C2)
  • Windows Server 2012R2 с поднятой службой сервера 1С (WS2012R2AC)

*как вариант можно использовать Роль хранилища на Windows Server 2012R2, софтверное решение от StarWind или реальное сетевое устройство iSCSI

Технически можно обойтись 3 серверами совместив все необходимые роли на домен контроллере, но в полевых условиях так поступать не рекомендуется.

Вначале вводим в домен сервера WS2012R2C1 и WS2012R2C2; на каждом из них устанавливаем роль «Отказоустойчивая кластеризация».
После установки роли, запускаем оснастку «Диспетчер отказоустойчивости кластеров» и переходим в Мастер создания кластеров, где конфигурируем наш отказоустойчивый кластер: создаем Quorum (общий ресурс) и MSDTC(iSCSI).

Этап 2 – Установка MS SQL Server


Важно: все действия необходимо выполнять от имени пользователя с правом заведения новых машин в домен. (Спасибоminamoto за дополнение)
Для установки нам понадобится установочный дистрибутив MS SQL Server. Запусткаем мастер установки и выбераем вариант установки нового экземпляра кластера:



Далее вводим данные вашего лицензионного ключа:



Внимательно читаем и принимаем лицензионное соглашение:



Получаем доступные обновления:



Проходим проверку конфигурации (Warning MSCS пропускаем):



Выбираем вариант целевого назначения установки:



Выбираем компоненты, которые нам необходимы (для поставленной задачи достаточно основных):



Еще одна проверка установочной конфигурации:



Далее — важный этап, выбор сетевого имени для кластера MSSQL (instance ID – оставляем):



Проверка доступного пространства:



После чего — список доступных хранилищ, данных (сконфигурировано на этапе подготовки):



Выбираем диск для расположения баз данных кластера:



Конфигурацию сетевого интерфейса кластера рекомендуется указать адрес вручную:



Указываем данные администратора (можно завести отдельного пользователя для MSSQL):



Еще один важный этап – выбор порядка сортировки (Collation). После инсталляции изменить крайне проблематично:



Параметры аутентификации на сервере (в нашем случае выбран смешанный вариант, хотя безопаснее использовать только доменную аутентификацию):



Выбор директорий хранения общих файлов кластера (в версиях MS SQL Server 2012 и старше TempDB можно хранить на каждой ноде и не выносить в общее хранилище):



Еще пару проверок:




Наконец приступаем к установке (процесс может занять длительное время):



Настройка и установка базовой ноды закончена, о чем нам сообщает «зеленый» рапорт



Этап 3 – добавление второй ноды в кластер MSSQL


Дальше необходимо добавить в кластер вторую ноду, т.к. без нее об отказоустойчивости говорить не приходится.
Настройка и установка намного проще. На втором сервере (ВМ) запускаем мастер установки MS SQL Server:



  • Проходим стартовый тест
  • Вводим лицензионный ключ:
  • Читаем и принимаем лицензионное соглашение:
  • Получаем обновления:
  • Проходим тесты по выполнению требований для установки ноды (MSCS warning – пропускаем):


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



Просматриваем и принимаем сетевые настройки экземпляра кластера:



Указываем пользователя и пароль (те же, что и на первом этапе):



Снова тесты и процесс установки:

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



Поздравляю, установка закончена.

Этап 4 – проверка работоспособности


Удостоверимся, что все работает как надо. Для этого перейдем в оснастку «Диспетчер отказоустойчивого кластера»:



На данный момент у нас используется вторая нода(WS2012R2C2) в случае сбоя произойдет переключение на первую ноду(WS2012R2C1).
Попробуем подключиться непосредственно к кластеру сервера MSSQL, для этого нам понадобится любой компьютер в доменной сети с установленной Management Studio MSSQL. При запуске указываем имя нашего кластера и пользователя (либо оставляем доменную авторизацию).



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



Данный экземпляр отказоустойчивого кластера полностью готов к использованию с любыми базами данных, например, 1С(для нас ставилась задача развернуть такую конфигурацию для работы именно 1С-ки). Работа с ним ничем не отличается от обычной, но основная особенность — в надежности такого решения.

В тестовых целях рекомендую поиграть с отключением нод и посмотреть как происходит миграция базы между ними; проконтролировать важные для вас параметры, например, сколько по времени будет длиться переключение.
У нас при отказе одной из нод – происходит разрыв соединения с базой и переключение на вторую (время восстановления работоспособности: до минуты).
В полевых условиях для обеспечения надежности всей инфраструктуры необходимо обработать точки отказа: СХД, AD и DNS.

P.S. Удачи в построении отказоустойчивых решений.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 17

    +2
    Какие риски вы снижаете таким решением? Это не отказоустойчивый кластер, а просто failover конфигурация, вроде.

    Из SPOF виднеются, как минимум СХД и, вероятно, AD. Кроме того не очевидно дублируются ли пути до AD, пути до СХД.

    С MSSQL дел не имел, потому задам пару глупых вопросов:
    — эта конфигурация active/passive или active/active?
    — какое поведение при падение активной ноды?
    — бывает ли split brain сценарий?
      0
      Какие риски вы снижаете таким решением? — как минимум увеличивается доступность базы в случае выхода из строя одного из узлов. Пользователи работают, мы восстанавливаем работоспособность. В планах еще разобраться с AlwaysOn
      Из SPOF виднеются, как минимум СХД и, вероятно, AD. Кроме того не очевидно дублируются ли пути до AD, пути до СХД.
      В описании тестового стенда указано, что есть Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD). На счет путей не понял, что Вы имели ввиду.
      — эта конфигурация active/passive или active/active? — active/passive
      — какое поведение при падение активной ноды? — происходит разрыв и переключение на вторую ноду (в нашем случае это занимает 10-25сек), пользователю 1С нужно было перезайти в базу.
      — бывает ли split brain сценарий? — если правильно понял, то возможно что б роли кластера жили на разных нодах, т.е. на Н1 — MSDTC, а на Н2 — MSSQL
        0
        На счет путей не понял, что Вы имели ввиду.
        Имелось ввиду дублирование по сетевым картам, коммутаторам, физическим кроссам и т. п. Exempli gratia 2 сетевые карты по 2 порта, с каждой по пути к каждому из двух свитчей, эти пути проходят через разные коммутационные шкафы. Избыточность, конечно, определяется рисками, которые хочется минимизировать и доступной инфраструктурой.

        происходит разрыв и переключение на вторую ноду (в нашем случае это занимает 10-25сек), пользователю 1С нужно было перезайти в базу.
        Id est о HA речи даже близко нет.

        если правильно понял, то возможно что б роли кластера жили на разных нодах, т.е. на Н1 — MSDTC, а на Н2 — MSSQL
        Нет. Имелась ввиду возможность недостижения кворума (я не очень понял, почему у вас хранилище «Quorum» является опциональным), когда каждая из нод не может достучаться до другой, тогда обе ноды считают себя слейвами; или обратная ситуация, когда обе ноды считают себе мастерами.
          0
          С «путями» — несомненно нужно минимизировать эти риски. Но — это за рамками статьи(добавлю об этом пару строк)
          «Id est о HA речи даже близко нет.» — да. Решение строилось исходя из требований и возможностей
          По "«Quorum»" — опциональность обусловлена всего лишь возможностью работы без него, но понятно, что это не добавляет плюс к надежности. Думаю стоит добавить в туторириал это уточнение.
            0
            А кто говорил про HA? Автор вроде бы пишет об отказоустойчивом (failover) кластере. Для HA идет следующий шаг — AlwaysOn Availability Groups.
        +2
        Добавьте подводные камни — в частности то, что запускать установку следует из-под пользователя, имеющего права на заведение новых машин в домен, поскольку при создании кластера сетевое имя приложения MSSQL будет регистрироваться в домене, и если прав не хватит, то вы можете получить проблему (я на 2008R2 ее себе получил, пришлось сносить и устанавливать все заново).
          0
          Спасибо! Вечером добавлю пару моментов
          0
          Не читал всю статью, только по диагонали.
          Еще на 2003 винде поднимал MSSQL active/passive с общим хранилищем, ничего сложного, все по докам.
          Давно с видой не работаю и встала задача поднять MSSQL кластер не с общим хранилищем. Для мааааленькой БД подключения терминальных клиентов, потому что в 2012 для этого теперь просто необходим MSSQL. Вот здесь я получил затык. Не могу найти для чайников документации. А хочется. Хочется MSSQL для такой маленькой но очень важной задачи разнести на две отдельные виртуалки на двух разных серверах виртуализации. Естественно ни о каком общем СХД речи и не идет.

          Если есть опыт, поделитесь!!!
            0
            Копайте в сторону AlwaysOn Availability — появились в SQL Server 2012.

            Это если нужна одна активная на запись нода (остальные — только для чтения). Если нужны записи во все базы — то в сторону репликации.
              0
              Спасибо. Покопаю.
              0
              Да несомненно особо сложного нет, больше промучался с хранилищем, но сложности были поэтому и появился сей туториал.
              По Вашему вопросу, согласен с комментарием ниже про AlwaysOn Availability. На счет СХД — можно сделать софтверно на базе ВМ с доступными ресурсами.
                0
                Еще одна ВМ это еще одна точка отказа. Так что это не вариант.
              0
              Приведенная конфигурация содержит слишком много точек отказа. Ключевой момент — резервирование СХД.
              Прочие штуки вроде нескольких сетевух через разные свитчи и инфраструктуры вроде AD и DNS само собой также нуждаются в резервировании, но это тривиально и не дорого.
              СХД, которые могут работать в режиме риалтаймовой репликации стоят космических денег, плюс требуют инфраструктуры для резервирования путей (2x FC или Ethernet свитча), и что самое грустное — работают медленнее локального хранилища (если сравнивать по цене, Violin Memory в расчет не берем).

              Мы выбрали AlwaysOn для отказоустойчивости. Он не требует СХД, так как использует локальное хранилище. Есть синхронный режим работы, в котором транзакция коммитится только после записи данных на резервный сервер.

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

              Синхронный режим дает примерно 5-10% просадки производительности на медном гигабите. Если использовать 10Г оптику — задержка должна уйти совсем.

              Для работы требуется режим восстановления FULL.
                0
                Для кворума достаточно сетевой шары (к сожалению, зарезервировать сетевую шару никак нельзя, поэтому стоит делать ее на максимально доступном сервере)

                Почему же нельзя, сетевая шара «кладется» на кластерный файловый сервис. Это даже в каком-то Best Practice по кластерам Microsoft было написано.
                  0
                  Для такого кластера нужна СХД.
                0
                  0
                  Скорректировал немного топик, добавил пару поясняющих моментов.

                  Only users with full accounts can post comments. Log in, please.