Настройка AlwaysOn на MS SQL2012 без общего хранилища.

Доброго времени суток, коллеги.

В этой статье рассмотрим настройку групп доступности AlwaysOn на сервере MS SQL 2012 в связке с сервером 1С Предприятие 8.2. Что такое AlwaysOn можно прочитать в официальной документации тут. 

Ни для кого не секрет, что для работы нормальной работы MS SQL нужна нормальная дисковая подсистема, с хорошим контроллером и быстрыми дисками. Ибо на каждый запрос SQL сервер взаимодействует (запись/чтение) сразу с четырьмя файлами БД: tempdb.mbf и templog.ldf, base.mbf и base.ldf. Не трудно догадаться, что в отчетные периоды, при высоких транзакциях, производительность дисковой подсистемы, а в следствие и SQL, падает.

Статья расскажет, как можно увеличить производительность работы MS SQL 2012, не в ущерб отказоустойчивости, используя группы доступности AlwaysOn. Для тестирования производительности возьмем программный продукт 1С Предприятие, т.к. при больших проводках сервер сильно грузит базу tempdb. В качестве тестируемой конфигурации будем использовать тест Гилева.

Группы доступности AlwaysOn не требуют общего хранилища для баз данных, поэтому можно приобрести несколько SSD дисков, собрать их в Raid 0 и разместить там БД. А резервный SQL (реплику) и прочие ресурсы будут находиться на удаленном хранилище. Тем самым мы повысим скорость дисковой подсистемы за счёт SSD, и увеличим отказоустойчивость и доступность баз данных, за счёт реплики, при выходе из строя дисков SSD.

Воспользуемся следующим планом:

1. Установка кластера WSFC Windows Server.
2. Установка SQL Server 2012 на каждом узле кластера. Создание и настройка групп обеспечения доступности AlwaysOn.
3. Добавление баз данных 1С в группу доступности
4.  Проверка работоспособности, имитируя отказ основного сервера.

Для работы Группы доступности AlwaysOn требуется развернуть WSFC-кластер. Именно WSFC-кластер следит за доступностью узлов и экземпляров SQL. Кластер WSFC требует наличие общей внешней сетевой папки, где будет находиться Quorum. На каждом узле кластера необходимо установить SQL сервер. Клиентская программа будет подключаться к WSFC-кластеру, видя его как отдельный инстанс SQL.

Подробнее про WSFC-кластер можно прочитать тут. 

Устанавливаем WSFC-кластер.

Запускаем «Диспетчер сервера» и добавляем компоненту «Failover Clustering»:

Перед созданием кластера, советую протестировать правильность всех настроек. Открываем «Failover Cluster Manager console», запускаем «Validate a configuration»:

Добавляем имена тестируемых серверов:

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

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

Нажимаем «Create a Cluster», добавляем нужные нам сервера (dbsql01.test.local и dbsql02.test.local) и указываем имя кластера dbclt01.test.local.

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

Добавляем кворум.

Щелкаем правой кнопкой мыши на имя кластера и выбираем «More Action->Configure Cluster Quorum Settings»

Выбираем «Node and File Share Majority».

Указываем сетевую папку для Quorum’а и нажимаем Finish.

Приступим к настройке и установке SQL сервера.

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

После установки, открываем SQL Server Configuration Manager, в меню SQL Server Services переходим к свойствам SQL (MyInstance) и ставим галку напротив AlwaysOn High Availability.

Проделываем данную процедуру на каждом SQL сервере.

Перезапускаем службу.

Открываем SQL Server Management Studio, подключаемся к серверу и создаем базу данных Test_db, указывая модель восстановления full. Делаем полный бэкап базы. Это необходимое условие.

 

Обратите внимание, что группы доступности будут работать с любым параметром Compatibility level.

Создаем новую группу доступности, щелкнув правой кнопкой мыши по AlwaysOn High Availability и перейдя в New Availability Group Wizard..

Присваиваем имя группе Test_group_1

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

Добавляем сервер с общим хранилищем dbsql02.test.local: нажимаем на Add Replica и подключаемся к серверу.

Устанавливаем необходимые галочки. В нашем случае это:

Переходим во вкладку Listener и производим соответствующую настройку:

Указываем метод синхронизации «Full» и прописываем путь к сетевой папке. Произойдет полное резервное копирование на шару и восстановление базы на сервер dbsql02.test.local.

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

Заходим в менеджмент консоль, видим группу доступности Test_group_1 и защищенную базу данных Test_db с пометкой «Synchronized».

Теперь подключаемся к кластеру WSFC dbclt01.test.local

Видим, что в кластере база Test_db также доступна.

Проверяем работоспособность. 

Создим таблицу и заполним ее.

 CREATE TABLE Dzen (

  number INTEGER,

  test TEXT,

  nickname TEXT,

  ter INTEGER,

  )

INSERT INTO Dzen (number,test,nickname,ter)

VALUES

  (1000,'Test', 'Munsera',42),

  (1001,'Test2','Yulkau',40),

  (1002,'Test4','Djeka',13),

  (1003,'Test4','Fritzfak',45),

  (1004,'Test5','Monax',11);

--COMMIT;

Проверяем что таблица создана и заполнена:

SELECT * FROM Dzen

Теперь выключаем сервер dbsql01.test.local, он был primary сервером. Проверяем:
  SELECT number FROM Dzen

База доступна, теперь внесем изменения в таблицу Dzen:

INSERT INTO Dzen (number,test,nickname,ter)

VALUES

  (1005,'Test5','Dismas',98)

 --COMMIT;

Проверяем: SELECT * FROM Dzen

Включаем сервер dbsql01.test.local, заходим в консоль SQL Server Management Studio сервера Dbsql01.test.local и проверяем:

SELECT * FROM Dzen

Данные сохранились. Выключаем сервер dbsql02.test.local и проверяем из консоли dbclt01.test.local

Все работает.

Проверяем работоспособность базы данных используя конфигурацию 1С: Тест Гилева. Запускаем тест и отключаем Primary сервер. Видим:

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

Заходим в консоль управления WSFC-кластера. Переходим в ветку Test_Group_1

Далее правой кнопкой мыши по ресурсу Test_group_1, переходим во вкладку Properties и изменяем параметр HealthCheckTimeout на 15000, это 15 секунд.

 Меньше число, к сожалению, поставить невозможно. Но т.к. таймаут опроса 1С сервером сервера SQL составляет 20 секунд, то при незагруженной работе, падение первичного SQL сервера, сервер 1С может пережить спокойно.

Приступим к тестированию производительности.

Запускаем тест Гилева:

Отключаем сервер с SSD дисками.

Как видно из тестов, можно увеличить производительность работы 1С практически в два раза за счет использования групп доступности AlwaysOn.

На этом предлагаю закончить.

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

Удачного тестирования