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

Начните с главного

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

  • Резервные копии. Если в вашей системе резервные копии не выполняются на все 100% с помощью инструментов сторонних производителей с собственными средствами планирования, вы будете выполнять резервные копии с использованием агента SQL Server, так что для вас задания по созданию резервных копий — это данность, которую необходимо принимать во внимание. Работать с резервными копиями не так уж сложно; речь об этом идет в предыдущих статьях цикла.
  • Пакетные задания. В данной серии статей я определяю пакетные задания как задания агентов SQL Server, выполняемые в целевых базах данных с задачей удовлетворить некую коммерческую потребность, или оценить бизнес-правила, или выполнить «логическое обслуживание» базы данных, то есть сделать нечто отличное от того, что определяется как типичные «задачи по обслуживанию» уровня администратора баз данных. Более подробную информацию можно найти в разделе «Определение пакетных заданий». Если вы будете заниматься такими заданиями, ваша задача несколько усложнится — ниже я остановлюсь на этом подробнее.
  • Задания по обслуживанию. Вам придется решать такие задачи, как обслуживание индексов, инструкции DBCC CHECKS и другие задания «системного уровня», выполняемые в пользовательских базах данных. Точно так же вы должны быть готовы к выполнению заданий по очистке истории резервирования, истории заданий и других ключевых операций по обслуживанию, как на системном уровне, так и в базе данных msdb. Эти типы заданий вы будете выполнять на всех хостах групп доступности — в отличие от пакетных заданий, которые обычно выполняются в основной реплике (если только речь идет не об отчетах, предназначенных исключительно для чтения).
  • Задания SSIS/ETL. Если вам нужно выполнять задания по извлечению, преобразованию и загрузке данных (или любые задания, реализуемые с помощью служб интеграции SQL Server), тогда в процессе управления заданиями вам придется принимать в расчет ряд других деталей. Очевидно, все эти задания нужно модифицировать таким образом, чтобы их целевым объектом стал прослушиватель группы доступности (а не непосредственно серверы или базы данных), но вам все равно придется в конечном итоге определяться с тем, где в конце концов будут выполняться эти задания. Теоретически их можно выполнять на другой системе или, скажем, на главном сервере, который не является членом данной группы доступности. А может быть, вам нужно, чтобы эти задания выполнялись на одном из хостов соответствующей группы доступности. И если это так, вам нужно будет либо модифицировать задания агента SQL Server, где «размещаются» задания ETL/SSIS — в соответствии с рекомендациями, чтобы включить логику if/else в само задание агента SQL Server, либо модифицировать пакеты SSIS таким образом, чтобы они выполнялись лишь при запуске на желаемом хосте.

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

Подведем итоги

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

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

Наконец, для тех, кто хотел бы получить список возможных и рекомендуемых мер в формате «если.., то…», я задумал написать отдельную статью, в которой содержались бы подобные рекомендации с той или иной степенью детализации. Но здесь у меня возникли две проблемы. Во-первых, у потребителей может быть множество различных потребностей и, соответственно, имеется множество способов удовлетворить их. Отсюда следует, что статья, посвященная соответствующим проблемам, будет довольно объемной и сложной. Во-вторых, я ведь не брался за составление исчерпывающего руководства с подробнейшим описанием того, как работать с заданиями и группами доступности. Передо мной стояла другая задача: показать, что в данной сфере действительно накопился ряд нетривиальных проблем, которые специалисты Microsoft игнорируют, и изложить отдельные идеи, логические обоснования и пояснения для предлагаемых мною путей удовлетворения некоторых из этих потребностей. В процессе работы я получил ряд замечательных комментариев с описанием других вариантов и подходов, и я думаю, это означает, что имеется множество путей решения данной проблемы и что выбор оптимального решения определяется конкретными потребностями организации, корпоративной культурой и настройками эксплуатируемой группы доступности. Поэтому попытка получить некое универсальное решение, на мой взгляд, просто неоправданна. Что ж, будем надеяться, что данная серия статей пошла на пользу специалистам, которые занимаются решением этих вопросов.