Отказоустойчивость в Microsoft SQL Server 2012. AlwaysOn

В версии Microsoft SQL Server 2012 были усовершенствованы механизмы аварийного восстановления и появились новые решения высокого уровня доступности, объединенные наименованием AlwaysOn. К ним относятся группы доступности AlwaysOn (Availibility group) и отказоустойчивые кластерные экземпляры (инстансы) AlwaysOn (Failover Cluster Instance).

Группы доступности AlwaysOn значительно расширяют функциональность зеркалирования баз данных и обеспечивают высоких уровень доступности баз данных приложений с нулевой потерей данных в случае отказа. Эта технология обеспечивает автоматический и ручной перевод базы данных или групп баз данных на резервный ресурс, поддерживает до четырех вторичных реплик и автоматическое восстановление страниц при ошибках.

Отказоустойчивые кластерные экземпляры (инстансы) AlwaysOn являются расширением кластерной технологии для MS SQL Server, позволяя создавать кластеры баз данных между различными подсетями, сайтами и датацентрами.

Для получения комплексного представления об обеспечении высокой доступности и отказоустойчивости в СУБД Microsoft SQL Server 2012, следует рассмотреть многоуровневую модель защиты AlwaysOn:

• На уровне серверов отказоустойчивость достигается использованием технологии отказоустойчивого кластера Windows Server, которая обеспечивает мониторинг состояния узлов кластера и координирует действия при отказе.
• На уровне экземпляров SQL Server отказоустойчивость обеспечивается технологией отказоустойчивых кластерных экземпляров (инстансов) AlwaysOn – такой экземпляр SQL Server разворачивается на нескольких узлах кластера Windows Server и переводится на резервные узлы кластера в случае отказа.
• На уровне баз данных отказоустойчивость обеспечивается применением технологии групп доступности AlwaysOn – такая группа может состоять из одной или нескольких баз данных, которые в случае отказа переводятся на резервный экземпляр SQL Server вместе. Каждая группа состоит из одного первичного экземпляра и 1-4 вторичных экземпляров (экземпляры могут быть как обычные, так и отказоустойчивые AlwaysOn).
• На уровне подключения клиентов установка соединения возможна как напрямую к экземпляру SQL Server, так и с помощью виртуального сетевого имени (virtual network name, VNN), служащий для скрытия уровней отказоустойчивого кластера Windows Server и групп доступности AlwaysOn, и для перенаправления запросов клиентов на соответствующие экземпляр Sql Server и реплику базы данных.

ГРУППЫ ДОСТУПНОСТИ ALWAYSON

Группы доступности AlwaysOn поддерживают среду обработки отказов для дискретного набора баз данных, которые получили название баз данных доступности. В состав группы доступности входят набор баз данных-источников и набор баз данных-получателей.

Наборы баз данных доступности размещаются с помощью реплик доступности, которые существует двух типов:

• первичная реплика, в которой размещаются базы данных, служащие источником реплик;
• вторичная реплика, в которой располагается набор баз данных-получателей и их может быть до четырех.

Каждая вторичная реплика является потенциальной точкой отработки отказа. Доступность данных для клиента достигается на уровне баз данных и сбой на уровне БД не может являться причиной переключения на другую реплику. Таким образом, например, обозначение базы данных как подозрительной не может являться причиной отработки отказа.

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

Для развертывания группы доступности AlwaysOn необходим отказоустойчивый кластер Windows Server Failover Cluster (WSFC). Все реплики доступности должны находиться в пределах одного кластера WSFC, но на разных его узлах.

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

Рис. 1. Схема расположения реплик доступности на кластере WSFC.

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

Таким образом, каждая группа доступности состоит из реплик доступности. На каждой реплике доступности размещается база данных доступности. Каждая реплика доступности должна находиться на своем экземпляре SQL Server и размещаться на узлах Windows Server Failover Cluster. На каждом из экземпляров кластера должна быть включена опция AlwaysOn.

Этот экземпляр сервера может размещать только одну реплику для отдельной группы доступности, но каждый сервер может быть использован для хранения нескольких групп доступности. Этот сервер может быть как изолированным экземпляром, так и входить в состав кластера SQL Server, если необходима избыточность на уровне сервера.

В соответствии с ролями реплик доступности наследуются роли баз данных и определяются атрибуты чтения/записи для них. В случае с первичной базой данных – это атрибуты на чтение и запись, для вторичных баз – только чтение.

Для синхронизации реплик существуют два режима доступности. Они определяют, ждет или нет первичная реплика окончания записи транзакций в журнал вторичной репликой перед фиксацией транзакций в базе данных. Данные режим доступности рассмотрены ниже:

• Режим асинхронной фиксации. В этом режиме первичная реплика посылает на запись транзакцию вторичным репликам и, не дожидаясь окончания их записи в журнал транзакцией, фиксирует ее. Режим асинхронной фиксации минимизирует время выполнения синхронизации реплик, но создает риск возможной потери данных.
• Режим синхронной фиксации. В этом режиме первичная реплика посылает транзакцию вторичным репликам и дожидается окончания ее записи в журнал транзакций каждой из реплик. Во время работы в режиме синхронной фиксации данные полностью защищены, что достигается увеличением времени транзакций.

В определенные моменты сеанса, первичная и вторичная реплики становятся взаимозаменяемыми в процессе, который называется отработка отказа. Во время этого процесса, вторичная реплика принимает на себя роль первичной и переводит свои базы в режим чтения и записи. Выполняет откат всех незафиксированных транзакций. Прежняя первичная реплика, когда становится доступна, принимает вторичную роль и становится вторичной репликой. Ее базы данных, которые были источниками, становятся базами данных-получателями и синхронизация возобновляется.

Поддерживаемые вторичной репликой формы отработки отказа зависят от режима синхронной фиксации. И при отработке отказа существует три вида перехода на использование другого ресурса:

• Автоматическая отработка отказа. Переход на другой ресурс возникает в результате сбоя, в момент перехода вторичная реплика принимает на себя роль первичной. А после восстановления работоспособности, первичная реплика становится вторичной. Для автоматического перехода требуется, чтобы первичная и вторичная реплики работали в режиме синхронной фиксации, а режим отработки отказа был настроен для автоматического перехода.
• Отработка отказа вручную, или переход на другой ресурс вручную. Этот переход осуществляется после команды администратора баз данных и возможен только в режиме синхронной фиксации (без потери данных). После команды, вторичная реплика завершает синхронизацию транзакций и принимает на себя роль первичной, а первичная реплика – вторичную роль.
• Принудительное обслуживание. Для асинхронного режима фиксации возможен только один переход на другую реплику – принудительное обслуживание или принудительная обработка отказа, которая может быть инициирована только вручную. Принудительная обработка отказа является аварийным восстановлением и это единственная форма восстановления, если целевая вторичная реплика не синхронизирована с первичной.

Группы доступности AlwaysOn поддерживают так называемые активные вторичные реплики, которые могут выполнять следующие функции:

• Операции резервного копирования вторичных реплик. С помощью вторичных реплик возможно создание резервных копий журналов транзакций и баз данных (всей базы данных, файлов или файловых групп). Для этого необходимо настроить группу доступности, указав предпочтение, где необходимо выполнять резервное копирование.
• Доступ для чтения к одной или нескольким репликам. Любую реплику доступности можно настроить на получение доступа к ее локальным базам данных. С целью уменьшения нагрузки чтения на основную реплику, создается прослушиватель группы доступности и настраивается маршрутизация только для чтения. К прослушивателю могут подключаться клиента для получения данных из баз данных. Их запросы направляются не только на первичную, но и на все вторичные реплики, на которых настроена маршрутизация только для чтения.

Можно обеспечить клиентское соединение с базой данных определенной группы доступности, создав прослушиватель группы доступности. Прослушиватель группы доступности ― это виртуальное сетевое имя (VNN), к которому могут подключаться клиенты, чтобы получить доступ к базе данных из первичной или вторичной реплики группы доступности AlwaysOn. Прослушиватель группы доступности позволяет клиенту подключаться к реплике доступности, не зная имени физического экземпляра SQL Server, с которым устанавливается соединение. Изменять строку подключения клиента, чтобы установить соединение с текущим расположением текущей первичной реплики, не требуется.

Прослушиватель группы доступности состоит из службы доменных имен прослушивателя (DNS), обозначения порта прослушивателя, а также одного или нескольких IP-адресов. Для работы прослушивателя группы доступности поддерживается только протокол TCP. DNS-имя прослушивателя должно быть уникальным в домене и в NetBIOS. При создании нового прослушивателя группы доступности он становится ресурсом кластера с соответствующим виртуальным сетевым именем (VNN), виртуальным IP-адресом (VIP) и зависимостью группы доступности. Клиент с помощью DNS разрешает VNN в несколько IP-адресов, а затем пытается подключаться по каждому адресу, пока запрос подключения не завершится успехом или не истечет время ожидания.

Если для одной или нескольких вторичных реплик для чтения настроена маршрутизация только для чтения, то клиентские соединения с первичной репликой с намерением чтения направляются во вторичную реплику для чтения. Кроме того, если первичная реплика переходит в режим «вне сети» на одном экземпляре SQL Server, а на другом экземпляре SQL Server новая первичная реплика переходит в режим «в сети», то прослушиватель группы доступности позволяет клиентам подключаться к новой первичной реплике.

Особенности построения отказоустойчивого решения на два сайта, с применением как FCI так и AG (см. Рис 2), описаны в документе  AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups.

Рис. 2. Схема отказоустойчивого решения на два сайта, с применением FCI так и AG