Недавно мне довелось в течение длительного времени помогать нескольким независимым друг от друга клиентам решать вопросы формирования и управления группами доступности AlwaysOn SQL Server. Мой опыт свидетельствует, что группы доступности AlwaysOn представляют собой мощное средство, позволяющее администраторам баз данных как обеспечивать высокий уровень доступности (high availability, HA), скажем, за счет повышения отказоустойчивости, так и решать некоторые задачи, связанные с восстановлением после аварийного сбоя (disaster recovery, DR), такие, как дистанционное обеспечение доступности с помощью единого интегрированного набора технологий и инструментальных средств. Однако нельзя забывать и о том, что группы доступности AlwaysOn характеризуются определенными ограничениями и имеют ряд недостатков, которым тоже нужно уделять внимание.

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

Лучшие методы и решения

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

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

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

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

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

AlwaysOn в широком контексте

AlwaysOn — это маркетинговый термин. Он используется для описания двух различных средств, разработанных инженерами Microsoft для обеспечения высокой доступности (high availability, HA) и восстановления после аварийного сбоя (disaster recovery, DR). Речь идет об экземплярах отказоустойчивых кластеров AlwaysOn Failover Cluster Instances (FCI), или о традиционных кластерах и о группах доступности AlwaysOn Availability Groups (AG), которые во многом напоминают продукт Database Mirroring 3.0.

Не вдаваясь в детали, отмечу, что и в FCI, и в AG реализуется общая для обеих технологий идея: распределение нагрузки осуществляется с помощью нескольких хостов SQL Server, что повышает отказоустойчивость (а в ситуациях, когда один или несколько хостов, участвующих в распределении нагрузок, размещены дистанционно, такой подход облегчает и решение вопросов восстановления после сбоя с использованием средств обеспечения доступности удаленных ресурсов).

Однако несмотря на сходные намерения и общие стратегические цели разработчиков обеих технологий (а также на то, что и AG, и FCI в своей работе активно используют средства обеспечения отказоустойчивости кластеров Windows Server), методы, реализуемые изделиями FCI и AG для обеспечения высокой доступности и восстановления после аварийных сбоев, различны.

Основные различия между AG и FCI

Попросту говоря, архитектурных и фундаментальных различий между группами доступности AlwaysOn и экземплярами отказоустойчивых кластеров AlwaysOn наберется достаточно для того, чтобы посвятить им несколько книг. Так что в одной статьей я никак не смогу воздать должное этой теме и потому ограничусь краткими замечаниями. В системе Failover Cluster Instances кластерная технология используется для создания одного либо нескольких узлов или объединенных хостов. Эти хосты координируют свою работу с контроллером домена, чтобы указать, какой из упомянутых физических узлов будет управлять виртуальным IP-адресом, виртуальным сетевым именем и виртуальным экземпляром SQL Server, который размещается на всех хостах, но в каждый момент может быть активным лишь на одном физическом хосте.

С другой стороны, в группах доступности AlwaysOn применяется метод зеркального дублирования (или взаимодействия «сервер — сервер» через конечные точки) с тем, чтобы отдельные копии данных на различных хостах оставались синхронизированными, а также для того, чтобы обеспечить координацию с контроллером домена. Такая координация позволит при желании сохранить ориентацию прослушивателей групп доступности на реплику Read/Write с целью налаживания обычного взаимодействия с базами данных, а также обеспечит возможность предоставления предназначенных только для чтения копий при выполнении сценариев расширения.

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

Группы доступности AlwaysOn

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

Против: Поскольку каждая реплика (или копия) базы данных обладает своими особенностями, с введением в топологическую группу AG каждого дополнительного сервера объем необходимого дискового пространства увеличивается на 1N (если ваши базы данных занимают 200 Гбайт пространства, для создания двух реплик дополнительно потребуется 400 Гбайт, трех реплик — 600 Гбайт и т.д.).

За: Вы получаете возможность выполнять сценарии масштабирования (или возможность развертывать дополнительные (полностью лицензионные) хосты SQL Server, которые позволят выполнять операции только для чтения, что позволит повысить общую масштабируемость системы).

За: Как правило, развертывание таких групп осуществлять чуть проще, чем развертывание экземпляров отказоустойчивых кластеров (FCI).

Против: Владение и управление группами доступности обычно обходится дороже, нежели владение и управление FCI (особенно когда речь идет о регистрации в системе, выполнении заданий и настройке других параметров\конфигурации на уровне сервера).

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

Экземпляры отказоустойчивых кластеров AlwaysOn

Против: Непростая процедура установки и настройки — вследствие необходимости обеспечивать средства хранения общего пользования (диск, разделяемый всеми узлами кворума).

За: Поскольку имеется лишь одна копия данных, общие требования к хранению данных (речь идет только о поступающих данных (1N))).

За: Управление и владение FCI проще, чем соответствующие процессы AG.

За: Обеспечивается отказоустойчивость для всего экземпляра SQL Server (все детали уровня сервера, такие, как учетные имена для регистрации в системе, прилинкованные серверы, конечные точки, задания и т.д. «синхронизируются» или управляются — при работе с AG дела обстоят иначе; в последнем случае синхронизации подлежат только сконфигурированные базы данных пользователей).

В дополнение к перечисленным аргументам за и против использования названных разновидностей технологий AlwaysOn отмечу, что и FCI, и AG обладают аналогичными преимуществами или ключевыми сильными сторонами, которые и делают их достойными выбора потребителей:

Автоматическое обеспечение отказоустойчивости. При надлежащей установке оба решения по сути обеспечивают «магическую отказоустойчивость» в том смысле, что если в тот или иной момент активный узел/реплика дает сбой, другие члены кластера выявляют этот сбой — обычно в течение нескольких секунд — и инициируют автоматическое аварийное переключение. Переключение (или передача эстафетной палочки от одного сервера другому) обычно осуществляется буквально за 1-2 секунды, в большинстве случаев на уровне WSFC, но тогда системе SQL Server придется набирать обороты на хосте, который стал теперь основным, и выполняться на протяжении всего процесса восстановления. В большинстве случаев все выполнение займет менее 60 секунд. Дополнительную информацию об этом можно найти в моей статье «Косвенные контрольные точки в SQL Server 2012» (опубликованной в Windows IT Pro/RE № 2 за 2014 год).

Сокращение времени простоя в процессе обслуживания. С точки зрения логики речь идет о той же проблеме или о том же преимуществе, что и в случае автоматического обеспечения отказоустойчивости. Различие состоит только в том, что администраторы могут использовать возможность форсированного переключения с одного хоста на другой как инструмент реализации покомпонентного обновления (rolling upgrade) или покомпонентного обслуживания (rolling servicing). Иными словами, если у вас возникла необходимость оснастить хост дополнительными модулями оперативной памяти или процессорами, установить пакет SQL Server Service Pack либо развернуть Windows Patches или решить какую-то аналогичную задачу, можете действовать по следующей схеме: установите модули коррекции/обновления на дополнительном сервере, вновь подключите его к сети, а затем выполните аварийное переключение на этот сервер (так, чтобы он стал основным), после чего осуществите коррекцию/обновление сервера, который первоначально выполнял функции основного — все это в порядке сокращения общего времени простоя. Если выполнять перечисленные манипуляции в периоды низкой загрузки, время восстановления SQL Server во многих случаях составляет порядка 10-15 секунд, то есть бесперебойная работа прерывается лишь на очень короткое время в момент собственно принудительного переключения.

Обеспечение доступности удаленных ресурсов. При работе с AG и с FCI мы можем оперировать понятиями эластичной доступности (stretch availability) или доступности удаленных ресурсов (remote availability). Оба эти понятия позволяют отойти от рассмотрения проблемы на уровне хостов и перейти к обеспечению отказоустойчивости или избыточности на уровне центров обработки данных. Это безусловно передовые решения, но здесь мы имеем дело с одним из самых серьезных аргументов в пользу применения как FCI, так и AG.

Вопрос контекста

Так какой же смысл рассматривать различия между FCI и AG в серии статей, посвященных группам доступности AlwaysOn SQL Server и заданий агента SQL Server? Ответ прост. Если вы используете экземпляры отказоустойчивых кластеров, тогда все проблемы, о которых мы будем говорить в данной серии статей, состоящие в том, чтобы обеспечить функционирование заданий агентов SQL Server при использовании групп доступности AlwaysOn, для вас просто несущественны. Или, иными словами, представьте, что по какой-то причине нам необходимо выполнять задание с использованием рабочей версии базы данных мини-приложений раз в 10 минут.

Если мы будем задействовать отказоустойчивые кластеры для обеспечения высокой доступности и настроим это задание так, чтобы оно использовало упомянутую базу данных мини-приложений, вопрос о том, с каким физическим хостом наш экземпляр SQL Server будет взаимодействовать, потеряет всякое значение — просто раз в 10 минут задание будет выполняться (ибо технология FCI обеспечивает защиту и синхронизацию на уровне экземпляра, поскольку существует только один активный или работающий агент SQL Server Agent и только одна копия базы данных msdb, содержащая метаданные графика и состояния для планирования и выполнения заданий агента SQL Server).

С другой стороны, если мы будем использовать простую группу доступности AlwaysOn из двух узлов и если нам нужно выполнять наше задание с применением базы данных мини-приложений раз в 10 минут, мы будем располагать не только двумя копиями (или репликами) соответствующей базы данных мини-приложений (одна в состоянии для чтения и записи, или в первичном состоянии, а вторая — в состоянии восстановления или выполняющая функции базы данных «горячего перехвата»). У нас будут выполняться два обособленных экземпляра SQL Server — я имею в виду два различных агента SQL Server Agent и две различные и обособленные копии базы данных msdb со своими сведениями о состоянии и метаданными с описанием заданий. Но здесь возникает проблема: на каком сервере будет расположен агент SQL Server Agent, который станет владельцем и исполнителем данного задания, выполняемого раз в 10 минут? Разумеется, для нас желательно, чтобы задание выполнялось на сервере, где размещается основная реплика. Однако все дело в том, что обеспечить функционирование системы в этой конфигурации сложнее, чем представляется на первый взгляд. Поэтому я и решил подготовить настоящую серию статей.

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

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

Конечно, группы доступности сегодня популярны, и они действительно позволяют эффективно осуществлять масштабирование (хотя, на мой взгляд, существуют гораздо более дешевые, нежели применение таких групп, методы достижения этой цели). Кроме того, их, возможно, несколько проще устанавливать и настраивать. Но нет никакого сомнения в том, что управление и владение группами доступности обойдется вам намного дороже. Поэтому используйте их лишь в тех случаях, когда это целесообразно на все 100%, а не только потому, что не хотите брать на себя хлопоты по развертыванию настоящего кластера.