J3qx

information archive

SQL clsuter с выделенными интерфейсами

Posted by j3qx на Апрель 2, 2016

Дано

Tmo-dc-35v – тестовый домен контролер

Tmo-db-21v – SQL nodeA

Tmo-db-22v – SQL node B

Network cluster object – nco-01

Lister Object – db-01

Служебная УЗ — s-sqlservice-01

Внешняя сеть 10.12.170.0 /24

Внутренняя сеть heartbeat – 192.168.12.0 /24

LAN1_vlan170 – внешний интерфейс

LAN2_heartbeat – внутренний интерфейс

NCO-01 IP адрес 10.12.170.150

NCO-01 IP адрес внутренний 192.168.12.150

LST-01 IP адрес 10.12.170.155

LST-01 внутрений адрес 192.168.12.155

db-test-01 – пустая тестовая база

AG-01 – имя группы высокой доступности

Вся установка будет производиться на SQL server 2014 Developer edition, при установки у себя, сразу проверяйте ограничения вашей версии SQL.

Далее все настройки производятся УЗ, имеющей права локального администратора на tmo-db-21v; tmo-db-22v. UAC – включен, производится при относительно default настройках

Ноды кластера должны находиться в одной подсети

Домен контроллер, в нашем тесте – использоваться Windows Server 10 Technical Preview, но это особой роли не играет

Установка SQL 2014 DEV

Requirements

Покажем на приме tmo-db-21v

Устанавливаем NetFramework 3.5

Устанавливаем роль Failover Cluster

 

Создаем в AD служебную запись SQL — s-sqlservice-01

Выдаем служебной УЗ права локального администратора на серверах tmo-db-21v; tmo-db-22v, путем добавления в ранее созданные группы АД, которые добавлены в локальные администраторы серверов

Выдача прав администратора на серверах SQL — это нужно не всегда и не во всех сценариях, но конкретно в нашем примере, мы будем делать так

Производим установку SQL 2014

Далее везде Next, на шаге Install Rules, мы видим предупреждение о необходимости настроить Firewall, это мы сделаем позднее, сейчас жмем next

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

Выбираем имя инстанса, в нашем примере оно по умолчанию

На шаге Server Configuration, делаем запуск сервиса DATABASE ENGINE и SQL Agent от имени нашей служебной УЗ s-sqlservice-01, так же меняем тип запуска SQL Server agent на «automatic»

Проверяем настройки Collation, в большинстве случаев должно быть «Cyrillic_General_CI_AS»

На шаге «Database Engine Configuration» — в нашем случае выбираем mixed Mode, добавляем администраторов. Хорошой практикой является добавление сразу группы администраторов серверов SQL, которые в вашей компании обслуживаю СУБД

Определяем пути для хранения файлов, в нашем случае будет как на скриншоте

Итоги установки, все должно быть удачно

Настройка Firewall

Делаем правило для SQL портов – 1433 и 5022. 1433 – стандартный порт подключения SQL, 5022 – порт подключения кластера

Профиль сети можно выбрать под ваши нужды, но на тесте мы выберем все

Настройка SQL после установки

Запускаем SQL server configuration manager. По умолчанию SQL 2014 DEV – не принимает соединения с удаленных хостов, исправим это

После чего рестартим инстанс SQL

Те же шаги повторяем на tmo-db-22v

Failover cluster

Подготовка

Внешняя сеть 10.12.170.0 /24

Внутренняя сеть heartbeat – 192.168.12.0 /24

По логике нашего демо стенда, кластер работает следующим образом. Есть две ноды SQL и внешние пользователи, они работают через сеть 10.12.170.0 /24. Обмен данными кластера идет через внутреннюю сеть heartbeat – 192.168.12.0 /24, в нашем примере, это два сервера напрямую подключенную сетевым кабелем минуя сетевое оборудование. Указанная сеть heartbeat – 192.168.12.0 /24 – клиентам не доступна

Проверяем и именуем правильно интерфейсы, правой кнопкой мыши на логотипе Microsoft

Явно задаем IP адрес 192.168.12.101 для tmo-db-21v; 192.168.12.102 для tmo-db-22v. Отключаем регистрацию DNS суфикса для внутреннего интерфейса

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

В настройка Network connection меняем порядок работы интерфейсов, чтобы сначала был внешний, потом внутрений. Чтобы вызвать верхнее меню, нужно нажать alt

Установка Failover Cluster. Step 1

Запускаем оснастку Failover Cluster

Заметка: кластерный объект создается в той же OU, где находиться первая нода кластера. При этом, объект будет заблокирован для удаления и, как следствие, не может быть перемещен. В нашем примере имя сетевого кластерного объекта nco-01.

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

Указываем имя наших серверов tmo-db-21v; tmo-db-22v;

На тесте мы откажемся от проверки валидации кластера в продуктиве – решайте сами, вы должны четко понимать что вы валидируете и под какие роли

Указываем кластерное имя NCO-01 и присваиваем ему IP адрес 10.12.170.150

ОГРОМНОЕ ВНИМАНИЕ НА ОПЦИЮ
по умолчанию она активна и молча заберет ваш диск с данными

Ждем окончания создания кластера, где видим, что кластер создался, но warning – связан с отсуствием свиделетя на кластере. Жмем Finish

Смотрим на наш кластер, должно выглядеть примерно так.

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

Подготовка SQL для работы AlwaysON

Снова запускаем SQL Server configuration manager, два раза левой кнопкой мыши на инстансе SQL и включаем поддержку AlwaysOn, после чего рестартим сервис

Повторяем те же настройки SQL на tmo-db-22v

Создание Availability Group

В нашем примере, мы создадим группу доступности используя wizard. В нашем случае мы создали пустую db-test-01. Модель восстановления full.

Так же, с базы должен быть хоть раз снят full backup. После чего запускаем wizard

Указываем имя availability group, в нашем случае оно AG-01

Выбираем базу, которую будем добавлять, в нашем случае она единственная, но настоятельно рекомендую, в продуктиве так же выбирать только самую маленькую, остальные добавлять потом через Join

Следующий шаг, самый важный, выбираем сервера для репликации и пути. В нашем случае второй сервер это tmo-db-22v. Так же тут же определяется модель failover – автоматически переключаться или нет, а так же режим синхронизации

Указываем на вкладке Endpoint, адреса наших серверов через внутренний heartbeat address. В нашем случае это 192.168.12.101 для tmo-db-21v; 192.168.12.102 для tmo-db-22v

было

СТАЛО


Явно указываем где должен сниматься бекап у кластера, в нашем случае на primary ноде

Listener пока не создаем и жмем NEXT

Следующий шаг синхронизация баз данных, мы его пропустим, выбрав соотвествующий пункт. Синхронизацию данных мы произведем позднее, методом Join only

На следующем шаге жмем next, игнорируя предупреждение о listener, мы его создадим позднее

На следующем шаги жмем Finish и смотрим как создается наша availability group

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

Удаляем базу из группы высокой доступности, это не удаляет саму базу, она будет продолжать работать и раньше, правой кнопкой на базе в списке availability databases и выбираем remove databases from Availability group

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

Присоединения баз к группе высокой доступности

Теперь сделаем нашу базу высоко доступной, для этого нужно

  1. Снять full backup ее на основной ноде
  2. Снять trn бекап на основной ноде
  3. Восстановить базу на ноде Б из full в режиме norecovery
  4. Восстановить базу на ноде Б из trn в режиме norecovery
  5. Присоеденить базу к группе высокой доступности

Почему мы пошли этим путем join only ? этот путь является рекомендуемым для больших и ОЧЕНЬ больших баз. Так же он позволяет иметь разные пути до баз серверов на нодах

Приступаем

Full копия у нас была снята ранее, снимаем trn

Перебрасываем получившийся бекапы на nodeB — tmo-db-22v

Все шаги по восстановлению ниже, будут происходить на nodeB – tmo-db-22v

Восстанавливаем сначала FULL копию

Выбираем наш файл с full бекапом и переходим на вкладку Options

Выбираем режим восстановления в RESTORY WITH NORECOVERY и жмем ОК

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

Теперь восстановим trn файлы

Выбираем бекап с транзакционными логами и так же переходим на вкладку options

Так же выбираем режим RESTORE WITH NORECOVERY и жмем ОК

В итоге база у нас так же остается в состоянии restoring

Настало время подключить базу к группе высокой доступности, подключаемся к главной ноде– tmo-db-21v.

Заходим в availability group-> availability database, правой кнопкой выбираем add database

Выбираем базу, которую мы подготовители ранее

На вкладке синхронизации выбираем JOIN ONLY и жмем NEXT


Подключаемся к nodeB –tmo-db-22v и жмем NEXT

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

Дополнительным методом контроля, будет запуск dashboard нашей группы доступности, на главной ноде, правой кнопкой по нашей группы доступности AG-01 и выбираем show dashboard

Должно быть что-то типа как на рисунке ниже

Создание listener с двумя интерфейсам

LST-01 IP адрес 10.12.170.155

LST-01 внутрений адрес 192.168.12.155

Пришло время создать listener, чтобы к нашим базам, могли подключаться пользователи и приложения.

Перед созданием listener нужна подготовительная работа. Вы должны обладать соответствующими права в домене, либо провести манипуляции ниже, должен будет ваш коллега администратор домена. В данном случае все манипуляции делались с правами domain admins

Подготовка listener

Создаем в AD объект компьютер с именем создаваемого listener, в нашем случае lst-01

Отключаем вновь созданный объект

Переводим оснастку AD в расширенный режим, это нам необходимо, чтобы увидеть вкладку security у объекта

И открываем свойства объекта lst-01, переходим на вкладку security

Добавляем полные права на lst-01, ранее созданный объект кластера NCO-01, для чего указываем, тип computer и вводим имя ранее созданого объекта NCO-01

Создание listener

Возвращаемся снова на nodeA – tmo-db-21v и создаем listener

Для чего в свойствах нашей группы доступности AG-01 правой кнопкой на availability groups listeners

В появившемся окне заполняем поля, имя listener – должно совпадать с тем, которое мы создали на этапе подготовки, в нашем случае LST-01, порт 1433 – стандартный порт SQL, адрес – в нашем случае мы явно его задаем и указываем 10.12.170.155

Нажимаем ОК и ждем результата.

Если все прошло хорошо, вы должны увидеть свой новый listener

А объект LST-01 в AD, станет включенным (description я дописал сам)

Попробую подключится к нашему кластеру по вновь созданному адресу lst-01, должно подключатся нормально.

Вновь возвращаемся на primary node A – tmo-db-21v открываем свойства listener

Нам нужно добавить еще один адрес, уже во внутреней heartbeat сети, жмем ADD и добавляем 192.168.12.155

На этом настройку Listener можно считать законченной

Настройка failover cluster для heartbeat

Теперь у нас имеется

Внешняя сеть 10.12.170.0 /24 – сеть откуда подключатся клиенты и приложения

Внутренняя сеть 192.168.12.0 /24 – сеть обмена данными кластером через выделенный сетевой интерфейс

Так же есть сетевой объект кластера NCO-01 имеющий адрес во внешней сети 10.12.170.150 и роль Availability group с именем AG-01, имеющая адреса в двух сетях LST – 10.12.170.155 (внешняя) и 192.168.12.155 (внутренняя). Мы хотим добиться ситуации, что при сбое сетевого оборудования и недоступности внешней сети 10.12.170.0 /24 кластер работал штатно и не проводил внепланового переключения ноды. В данном конкретном примере мы не используем witness шары – так как нет смысла, disk witness – нет технической возможности добавить в пример, но нам оно и не важно для нашего сценария отказа внешней сети

Нам осталось

  1. Добавить внутреннюю сеть в свойство сетевого объекта кластера NCO-01
  2. Проверить зависимости объектов кластера и роли.

Добавляем доп сеть в объект кластера

Заходим в оснастку Failover Cluster и открываем свойство кластерного объекта

Добавляем вторую сеть

Добавляем сетевой адрес внутренней сети, в нашем случае это 192.168.12.150

Жмем ОК

В итоге должно получится так

Снова заходим в свойства объекта NCO-01 и проверяем dependencies, что там есть обе сети и логическое правило ИЛИ

Убираем регистрацию netbios имени объекта для внутренней сети

Теперь идем в свойства роли, проверяем ее настройки

Убеждаемся что там все правильно.

Так же снимаем регистрацию netbios имени для внутреннего интерфейса

Собственно на этом можно считать настройку AlwaysON кластера из двух нод с выделенным интерфесом под heartbeat законченным. Но на бонус, я покажу что будет при отказе оборудования

Отказ внешней сети

Эмулируем отказ внешних интерфейсах на обоих нодах кластера

При этом сам кластер чувствует себя замечательно (так как у нас отпала внешняя сеть, то подключаться нужно не по имени, которое ведет в 10.12.170.101, а через локальный адрес, например 127.0.0.1

При этом кластер видит, что потерял один из интерфейсов внешней сети, но сам объект считается online (так как работает внутренняя сеть)

При этом все ноды считаются онлайн

В свойствах роли, мы так же видим что она онлайн, хотя внешний интерфейс и недоступен

Как следствие никакого неавторизованного переключения кластера не происходит как и split brain.

ВАЖНЫЙ момент: после такого сбоя, надо зайти руками и запустить внешние интерфейсы, чтобы ваши клиенты смогли работать. По умолчанию политика настроена на попытку старта через 15 минут

Тоже самое надо сделать и в роли

На этом все. За пределами руководства остались вопросы диска свидетеля и шары свидетеля, но для подобной конфигурации кластера из двух нод связанных на прямую кабелем heartbeat они и не нужны, так как появляются только дополнительные административные издержки

Реклама

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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