Технологии Always On в SQL Server.

Технологии Always On в SQL Server

Битва за отказоустойчивость и надежность систем заставляет нас постоянно прибегать к новым технологиям, тестировать, искать нестандартные пути решения проблем. IT компаний используют Storage Spaces Direct, Hyper-V, Windows Server Failover Cluster, Always On в SQL Server, Cluster Shared Volume (CSV) для SQL Server и т.д. Мы тоже внедряем и активно используем передовые технологии.

Чтобы наладить взаимодействие многочисленных сервисов, разграничение прав пользователей, мы используем ПО, активно взаимодействующее с базой данных, так называемое “ядро”. Чего мы хотим от базы данных? Чтобы она была всегда высоко доступна с автоматической отработкой отказа. Этого можно добиться благодаря технологии Always On в SQL Server. Мы не будем подробно останавливаться на этой технологии, информации о ней предостаточно. Нам от Always On в SQL Server нужно было одно – обеспечение высокой доступности базы данных и автоматическая отработка отказа.

Использование ресурсов носителя, особенно ОЗУ, – удовольствие не из дешевых. Обычно, чтобы сэкономить, делают так: для первичной ноды Always On выделяется достаточное количество ОЗУ, а для вторичной – урезанное. Это в целом удобно, потому что вторичная нода используется редко, только во время сбоев. Но здесь есть и свой подводный подводный камень. А что будет если сработает автоматическая отработка отказа или необходимо провести плановые работы с первой нодой? Ресурсов на вторичной ноде будет недостаточно для комфортной и стабильной работы.

Решить эту проблему позволяет текущая технология Hyper-V, встроенная в Windows 2016 и Windows 2019. С ее помощью можно добавить ОЗУ выбранной ноде прямо на ходу. То есть, если у нас «отваливается» первая нода и база переезжает на вторую, то мы можем сразу докинуть ОЗУ на вторичную ноду и никто не почувствует разницы. Все классно, НО сама гостевая ВМ должна поддерживать эту возможность. То есть, гостевая ОС должна быть не ниже Windows 2016. А наши сервера с SQL для базы “ядра” располагались на ВМ с ОС Windows 2012, которые не поддерживают добавления ОЗУ “на лету”. Так что мы решили перейти на ОС Windows 2016. Вот только сделать это нужно было без остановки БД.

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

Реализация

Добавление нод Windows Server Failover Cluster

Always On работает с использованием встроенного механизма Windows Server Failover Cluster (WSFC). WSFC обеспечивает мониторинг узлов, участвующих в группе доступности, и может осуществлять автоматическую отработку отказа посредством голосования между узлами. Идея состояла в том, чтобы в Failover Cluster, состоящий из двух нод на ОС Windows 2012, добавить ещё две ноды, но не с Windows 2012, как на первых двух, а с ОС Windows 2016.

И сразу возник вопрос: а как поведет себя сам кластер Windows Server Failover Cluster, если у него ноды состоят из разных версии ОС? Параллельно хотелось бы обновить и SQL Так что мы решили развернуть тестовый WSFC:

1. Node1 - Windows 2012 R2 + SQL 2014 SP1
2. Node2 - Windows 2012 R2 + SQL 2014 SP1
3. Node3 - Windows 2016 + SQL 2014 SP3
4. Node4 - Windows 2016 + SQL 2014 SP3

Сначала мы собрали WSFC из Node1 и Node2. Настроили Always On в MS SQL Server. Проверили функционирование. Всё прекрасно работает. И вот теперь мы будем добавлять Node3 и Node4 в WSFC. Интересно, как поведет себя кластер, если у нод различные ОС?

Добавили две ноды. В событиях кластера появились предупреждения “Узел "Node3" установил связь с узлом "Node2" и обнаружил, что он использует другую, но совместимую версию операционной системы”. Значит, всё нормально. Первый этап мы завершили.

Настройка группы доступности Always On

Приступаем ко второму этапу. Будем включать и настраивать группы доступности Always On согласно плану. План у нас такой:

1. Ввести в группу доступности Alway On третью ноду на win2016
2. Изменить режим отработки отказа на второй ноде – "вручную"
3. Изменить режим отработки отказа на третьей ноде – "автоматически"
4. Исключить из группы доступности Alway On вторую ноду.
5. На первой ноде (Основная) выполнить "Отработку отказа". После этого третья нода станет Основной, а первая Дополнительной
6. Изменить режим отработки отказа на первой ноде - "вручную"
7. Ввести в группу доступности Alway On четвертую ноду на win2016
8. Изменить режим отработки отказа на четвертой ноде - "автоматически"
9. Исключить из группы доступности Alway On первую ноду. Получаем рабочие две ноды. Третья – основная, четвертая – дополнительная
10. Проверка работоспособности.
11. В диспетчере конфигурации SQL первой и второй ноды убрать галочку "Включить группы доступности AlwayOn"
12. Исключить из Server Failover Cluster первую и вторую ноды

План сработал. В тестовой среде всё прошло гладко. Теперь мы можем выполнить те же действия, но уже в “бета” среде, а последним шагом будет внедрение на “проде”.

Внедрение в бета среде

Порядок действий мы уже определили и проверили, так что на этом этапе уже проще. Приступаем к реализации данного сценария в бета среде. И вот здесь мы натыкаемся на непонятный “глюк”. При добавлении четвертой ноды (п.7 плана) база не синхронизировалась, и в панели мониторинга группы доступности эта нода была помечена желтым значком предупреждения. Мы начали искать решения и выработали следующий алгоритм:

на основной (Первичной) ноде удаляем базу из “группы доступности”
удаляем обе вторичные ноды (старую, она же – первая нода, и новую, она же – четвертая)
добавляем в группу доступности AlwayOn четвертую ноду на win2016 (синхронно, автоматически)
добавляем базу в группы доступности

После проведенных действий база синхронизировалась и работала в штатном режиме.

Внедрение в продакшн среде

Заключительный этап. На этом этапе мы столкнулись с аналогичной сложностью, что и в бета среде, но у нас уже было готовое решение. Применили – всё работает!

Цель достигнута. Теперь мы в любой момент можем увеличивать или сокращать объем выделенного ОЗУ для виртуальной машины.