J3qx

information archive

Создание SQL Cluster AlwaysOn с выделенным heartbeat интерфейсом

Posted by j3qx на Февраль 10, 2017

Данные примера

Sql1 – td-db-01

Sql2 – td-db-02

Fileserver – td-fs-01

Network cluster object td-cls-nco-110

HA listern for SQL td-cls-db-110

SQL Server Installation

SQL сервера устанавливаются и готовяться согласно регламенту.
На всех нодах будущего кластера должна быть идентичная конфигурация папок
SQL.
Для запуска служб желательно использовать один и тот же доменный аккаунт.
Для удобства при инсталляции можно воспользоваться сохраненным файлом конфигурации установки. Путь к нему можно увидеть на экране Ready to install при установке первой ноды (ConfigurationFile.ini):


 

При установке остальных нод выбираем Install based on configuration file пункта Advanced и подкладываем скопированный файл.


Создать доменную служебную УЗ вида s-sqlserver-##.
Добавить данную УЗ в группу администраторов сервера.
Указать при установке, что от имени данной УЗ необходимо запускать службы SQL Server и SQL Server Agent.

Создать доменную группу вида g_sql__sysadmin.
Указать при установке данную группу в качестве администраторов SQL сервера.

Heart-Beat Interfaces

На каждом сервере выбирается отдельный сетевой интерфейс, на нем можно отключить все опции кроме IPv4.

Каждому интерфейсу назначается IP-адрес из одной подсети, маска 255.255.255.0, шлюз не задается.

В дополнительных настройках снимается галочка о регистрации данного интерфейса в DNS.

В порядке обработки запросов данным интерфейсам настраивается более низкий приоритет, чем полноценным интерфейсам. Для этого необходимо в окне сетевых интерфейсов нажать и отпустить Alt, открыв таким образом файловое меню и выбрать пункт Advanced – Advanced Settings:

В появившемся окне выбрать внутренний интерфейс и опустить его ниже основного с помощью стрелочки:

Failover Clustering

На обоих SQL серверах устанавливается Failover Clustering Feature.
Для кластера выбирается имя согласно правилам именования (Инструкция №0001-IT).
Ноды будующего кластера должны находиться в одной подсети.
Заметка: кластерный объект создается в той же OU, где находиться первая нода кластера. При этом, объект будет заблокирован для удаления и, как следствие, не может быть перемещен. В нашем примере имя сетевого кластерного объекта td-cls-nco-110.
Создание кластера: на основной SQL ноде в оснастке Failover Cluster Manager запускаем Create Cluster. Имя кластерного объекта должно быть не более 15 символов.

ОБРАТИТЬ ВНИМАНИЕ НА ОПЦИЮ


После создания кластера необходимо разрешить клиентам подсоединяться ко внутренним интерфейсам:

Для этого необходимо зайти в свойства данной внутренней кластерной сети и установить соответствующую опцию:

Далее на каждой ноде, запускаем SQL Server Configuration Manager и заходим в свойства установленного инстанса SQL Server:


Включаем поддержку AlwaysOn High Availabitity Group на вкладке AlwaysOn High Availabitity


Поле этого SQL должен быть перезапущен.

Проверяем/обеспечиваем доступность всех серверов SQL по сети: включить в SQL конфигураторе TCP/IP:

На каждой ноде открыть в брандмауэре Windows TCP порты 1433, 5022

AlwaysOn High Availability

Создание в AD объекта Listener: создать в AD объект Computer с нужным именем в нужной OU (в нашем примере td-cls-db-110), объект отключить (disable). Данный объект будет использоваться для доступа к кластеру по сети. На объект даются полные права ранее созданному виртуальному объекту кластера (в данном случае td-cls-nco-110).


Общая папка для AlwaysOn HA quorum создается опционально, либо используется уже созданная ранее папка для кластерной службы.
На всех серверах SQL необходимо предоставить права подсоединения к endpoint-ам служебной УЗ, из-под которой запускаются SQL Server и агент: grant connect on endpoint::Hadr_endpoint to [LATEST\s-sqlservice-01].
Структуры папок с БД на всех серверах SQL должны быть одинаковыми.
Необходимо также создать временную общую папку под бекап для репликации БД, права за запись для сервисной УЗ, из-под которой запущены службы SQL Server и SQL Agent.

На основной ноде в SQL Management Studio создаем группу доступности:
AlwaysOn High Availability – Availability Group, в контекстном меню выбираем – New Availability Group Wizard…


Задаем имя группы (это имя не будет именем кластера!):


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


Добавляем вторичные ноды (Add Replica):


В свойствах реплик включаем Automatic Failover, Synchronous Commit, Readable Secondary выставляем в Yes.


В адресных строках Endpoint-ов прописываем IP-адреса внутренних heart-beat интерфейсов.


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


После проверок, вторичные ноды будут присоединены к группе, а базы будут синхронизированы.


Если объем базы большой, то автоматическая синхронизация может не пройти. В данном случае можно не создавать базу из мастера создания группы, а создать ее позже.
Для этого нужно вручную на основной ноде сделать полный бекап, затем бекап транзакшн-логов, и восстановить базу с логами на всех прочих нодах, не переводя ее в режим RECOVERY. Затем добавить ее в Availability Databases.

Availability Group Listener

В SQL Server Management Studio присоединяемся к главной ноде.

Переходим:  [AlwaysOn High Availability] – [Availability Groups] – [groupname]

Правой кнопкой мыши на [Availability Group Listener]. В контекстном меню – [ Add Listener…]


Заполняем:
— Listener DNS Name (имя объекта, который будет отвечать как SQL Server, совпадает с именем объекта листнера, ранее созданного в AD)
— Port: 1433
— Network Mode: Static IP
— IP: Добавляем два сетевых адреса листнера из обеих подсетей – и из heart-beat, и из рабочей


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

В консоли Failover Cluster Manager настроить зависимости листнера:



возможна настройка автовосстановления кластера (так и не пришли к мнению, что лучше):

Добавить в настройках кластера его адрес из внутренней подсети

Cluster — Cluster Core Resources — Server Name — IP Address Properties:

Network: 192.168.0.0/24
IP Address: 192.168.0.50
CLEAR box «Enable NetBIOS for this address»

Зайти в свойства кластерного объекта и на вкладке Dependencies добавить зависимость OR, что если или одна или другая подсеть доступны, то кластерный объект остается Online


Прописать в файл hosts на каждой ноде адрес кластерного объекта  td-cls-nco-110 с адресом из внутренней подсети 192.168.0.50, чтобы кластерный объект продолжал быть доступен во время разрыва связи с DNS.

Восстановление работы кластера после восстановления внешнего интерфейса

После восстановления работы внешнего интерфейса нужно зайти в консоли Failover Cluster Manager в Roles, выбрать роль, перейти на вкладку Resources, раскрыть серверный объект листнера и вернуть внешний интерфейс Online:

Настройка бекапа баз в группе AlwaysOn

В настройках группы высокой доступности по-умолчанию выставлен параметр Prefer Secondary. Что значит, что при запуске бекапа баз агентом SQL на основной ноде группы проводится проверка и в случае доступности Secondary Node предполагается, что бекапы выполняются на ней и на основной ноде бекапы не выполняются. При этом сам Job на основной ноде ошибок не выдает и завершается со статусом Success.

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

Реклама

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: