Группы доступности AlwaysOn и задания SQL Server: сохранение согласованности пакетов
Содержание:
1. Синхронизация пакетов SSIS, размещенных на разных серверах;
2.
3. Заключительные соображения относительно резервных копий.
Разумеется, цель синхронизации прежде всего в том и состоит, чтобы в случаях, когда администратор использует пакеты SSIS для управления резервными копиями или когда эти пакеты выполняются в качестве пакетных заданий (см. статью «Определение пакетных заданий»), обеспечивать контроль не только за тем, чтобы задания были идентичны на всех серверах, где размешаются группы доступности (то есть чтобы при их выполнении выполнялись идентичные логика, последствия или операции), но и за тем, чтобы упомянутые задания или операции выполнялись только на целевой или предпочтительной реплике. В предыдущей статье речь шла о том, как можно с легкостью дополнять пакеты SSIS логическими конструкциями, позволяющими осуществлять проверки на выполнение условий, чтобы обеспечивать выполнение тех или иных операций только на соответствующем сервере. Кроме того, выше я привел несколько ссылок и информацию о том, как осуществлять первоначальную синхронизацию пакетов или синхронизацию в ручном режиме при внесении изменений в тот или иной пакет.
Но в случае, когда основная логическая конструкция или операции размещаются на нескольких серверах, возникает проблема сохранения согласованности этих пакетов или заданий. Для иллюстрации представим такую ситуацию. Предположим, вы настроили группы доступности для обеспечения высокой доступности или восстановления после сбоя, но в то же время у вас имеется группа хранилищ данных, в которых регулярно выполняются процессы извлечения, преобразования и загрузки данных с использованием контента ключевых баз данных. В этом случае необходимо не только позаботиться о том, чтобы извлечение данных осуществлялось из идеальных или предпочтительных реплик, то есть перенос этого процесса на реплики, предназначенные только для чтения, на первом этапе, возможно, представляется вполне логичным — если не считать проблем лицензирования и логики «поддержания актуальности» операций записи, которые, возможно, в конце концов будут использоваться. Вдобавок к этому вам нужно обеспечить нормальное функционирование системы в случае, когда, скажем, младший разработчик ETL вносит некоторые изменения в пакет и выкладывает эти изменения только на сервер, где размещается, допустим, главная реплика одной из ваших баз данных, входящих в состав группы доступности. Если такая ситуация действительно возникнет, то в тот момент, когда произойдет аварийное переключение на другой хост, случится одно из двух. Либо вновь добавленное задание, выложенное разработчиком, не будет выполняться на новом сервере, либо — если внесенное в пакет SSIS соответствующее «изменение» представляет собой модификацию существующего пакета — во время исполнения к новой реплике будут применены старый пакет или прежняя логика.
Разумеется, ни один из перечисленных вариантов не дает результата, даже отдаленно напоминающего тот, который вам нужен. Конечно, вы можете создать политику или контрольный список мер, которые следует применять всякий раз, когда запускаются пакеты SSIS, но... Надеюсь, вы не сочтете меня безнадежным скептиком, если я выражу сомнение в том, что такой процесс будет выполняться безупречно всякий раз. Поэтому я предлагаю вашему вниманию следующий сценарий; можете регулярно использовать его для опросов (или проверок) пакетов SSIS, независимо оттого, идет ли речь об обычных пакетных заданиях SSIS или о пакетах SSIS, используемых в работе с планами обслуживания, и для отчетов по любым проблемам синхронизации.
Важно отметить, что приведенный код предназначен исключительно для проверок планов обслуживания — отсюда и его название. И, как отмечалось в предыдущей статье, если вы используете планы обслуживания для работы с какими-либо иными объектами, кроме резервных копий, самое время еще раз задуматься о том, что вы, собственно, делаете. А если вы используете планы обслуживания для работы с резервными копиями, вам, возможно, стоит взять на вооружение сценарий, который я предлагал в предыдущей статье. Имейте в виду, что код в листинге может служить справочным материалом по некоторым типам логических конструкций, которые вы можете использовать либо для работы с отдельными типами пакетов SSIS (определяемыми по именам или местоположению), либо для выполнения проверок во всех пакетах SSIS, если в том возникнет необходимость. А для того, чтобы получить представление о том, как используются описанные выше логические конструкции для проведения регулярных проверок синхронизации, вам будет полезно просмотреть и перечитать предыдущие статьи серии, где излагаются основные принципы таких проверок, а также приводится ряд конкретных примеров их реализации. Что же касается прочих аспектов проблемы, прошу вас иметь в виду, что, говоря здесь о задачах синхронизации SSIS, я демонстрирую всего лишь верхушку айсберга. Если угодно, вам предлагается описание подхода к решению вопроса в самом общем виде. Используя этот подход в рабочих средах, я добивался значительных успехов. Но при этом мне приходилось сталкиваться и с затруднениями, и со сбоями. Во многих случаях пакеты SSIS могут быть до абсурдного сложными (а также неустойчивыми и «ломкими»). Таким образом, даже если представленные на разных серверах экземпляры пакета идентичны, из этого отнюдь не следует, что пакет SSIS всегда будет выполняться на сервере, где он не был протестирован (просто потому, что детали подключения, пути к файлам либо папкам (или же правила безопасности, управляющие доступом к этим путям) могут быть абсолютно иными или не на 100% синхронизированными). В целом, если вы используете пакеты SSIS в сочетании с базами данных групп доступности, обязательно проследите за тем, чтобы при подключении к базам данных групп доступности использовались прослушиватели групп доступности, а также удостоверьтесь в том, что в пакетах применяется соответствующая логика if/else (или что вы просто активируете и деактивируете задания по мере необходимости). И еще одно замечание: единственный способ обеспечить выполнение перечисленных выше пунктов — с помощью тестирования. Но эта процедура наверняка уже стала для вас привычной, после того как в вашей среде появились группы доступности.
Далее мы обсудим некоторые соображения, касающиеся структур, не укладывающихся в схему «простых двухузловых» топологий групп доступности, и рассмотрим другие подходы к темам и задачам, о которых я писал в ранее опубликованных статьях.
Все, что вам следует понять из этой статьи - для SQL Server необходим надежный сервер! И выделенные сервера от Friendhosting (https://friendhosting.net/dedicated.php) идеально подходит для этой цели! Узнайте подробности прямо сейчас на friendhosting.net.
