Группы доступности AlwaysOn и задания SQL Server: синхронизация пакетов SSIS
Содержание:
1. Управление заданиями с помощью главных серверов (Вы читаете данный раздел);
2. «Продвинутые» системы ;
3. Дополнительные способы аварийных переключений заданий;
4. Еще один способ работы с аварийными переключениями и активацией заданий.
Ключевая идея данной серии статей состоит в том, что вы должны стараться синхронизировать задания агента SQL Server на ряде хостов группы доступности AlwaysOn, чтобы вне зависимости от того, идет ли речь о резервных копиях или о пакетных заданиях, вы всегда могли быть уверены, что задания выполняются: во-первых, в тот момент, когда это необходимо, и, во-вторых, на определенном хосте (или в отношении такого хоста) в соответствии с вашим замыслом. Чтобы помочь вам реализовать данную потребность, я описал ряд приемов синхронизации настроек заданий, деталей исполнения и других параметров на ряде серверов — все это с помощью сценариев или как бы «вручную». Примечательно, что в системе SQL Server, в сущности, реализован фантастический механизм для удовлетворения потребностей в «синхронизации» без предварительной настройки, то есть пользователю нет нужды составлять особый код. И работа с данным механизмом осуществляется посредством настройки Multi-Server Administration или с использованием идеи, согласно которой вы можете взять один агент Single SQL Server Agent и наделить его статусом главного сервера Master Server (MSX), тогда последний может «направлять» или контролировать выполнение заданий и других деталей агента SQL Server на управляемых серверах, именуемых целевыми Target Servers (TSX). Если вы познакомились со всеми предыдущими статьями серии и вам до сих пор не доводилось слышать о механизме Multi Server Administration (а может быть, вы слышали, но просто забыли о нем, как и большинство пользователей), для вас, возможно, стала откровением идея управления заданиями агентов SQL Server с помощью серверов MSX/TSX.
Да, их действительно можно использовать именно для этой цели. Но, как вы, вероятно, предположили, здесь имеется ряд ограничений. На первый взгляд управление заданиями агентов SQL Server с помощью главного сервера осуществляется довольно просто. Вам нужно только выполнить следующие действия.
• Настройте серверы MSX/TSX (хосты группы доступности должны быть настроены как целевые серверы, причем здесь вы можете указать, что каждое из заданий агента SQL Server, которое потребуется запустить, нужно выполнять на всех целевых серверах в одно и то же время и с абсолютно идентичной логикой/кодом.
• Настройте или модифицируйте ваши «мульгисерверные» задания таким образом, чтобы они включали логические конструкции для выявления предпочтительных реплик для резервных копий (когда будете работать с ними); руководствуйтесь при этом данными ранее рекомендациями или логическими конструкциями для выявления основной реплики при работе с пакетными заданиями; в этом случае ориентируйтесь на рекомендации из соответствующей статьи.
• Предоставьте событиям развиваться своим чередом — без непроизводительных затрат и проблем, связанных с синхронизацией, которые были описаны в предыдущих статьях.
Разумеется, мы рассматриваем ситуацию, что называется, в самом общем виде. При этом я ни в коем случае не сбрасываю со счетов комбинацию MSXTSX, поскольку это, без сомнения, наилучший механизм управления заданиями агентов SQL Server при работе с хостами или базами данных групп доступности AlwaysOn.
Впрочем, имеется ряд обстоятельств, которые вам следует держать в поле зрения, если вы решите идти по этому пути. Все это довольно очевидные ловушки, однако мне хотелось бы о них упомянуть.
• Не размешайте главный сервер Master Server на одном из хостов своей группы доступности, ибо это поставит под угрозу отказоустойчивость ваших заданий/резервных копий. Сформулирую свою мысль иначе. Идея групп доступности состоит в том, чтобы объяснить следующий факт: отдельный экземпляр SQL Server (то есть хост группы доступности) может дать сбой и обязательно выйдет из строя. Поэтому размещение на одном из хостов эквивалента «главного контроллера» агента SQL Server, координирующего выполнение всех заданий, служит гарантией того, что в конечном счете вы на каком-то этапе потеряете главный сервер, отчего пострадают задания, средства предупреждения и т.д.
• Если выполнение заданий и резервных копий является для вас важной задачей (как это бывает в большинстве случаев), имеет смысл преобразовать в кластер ваш сервер MSX или главный сервер. Иными словами, если вы установите новый «контроллер» (то есть главный сервер) с целью координации выполнения заданий на нескольких отказоустойчивых системах SQL Server, размещающих базы данных группы доступности, то получите единственную точку отказа при выполнении потенциально жизненно важных операций: получение резервных копий и выполнение заданий. Тогда вам нужно будет превратить в отказоустойчивый ваш сервер MSX, что сделать довольно легко: нужно, чтобы ваш агент SQL Server, выступающий в роли главного сервера, был развернут в составе экземпляра отказоустойчивого кластера AlwaysOn — так, чтобы он тоже стал в достаточной степени отказоустойчивым.
• Синхронизация. Системы MSX/TSX могут функционировать безукоризненно, но иногда они теряют согласованность.
• Пакеты SSIS. Предполагается, что системы MSX/TSX могут работать с пакетами SSIS (в виде планов обслуживания SQL Server) без предварительной настройки. Однако я подозреваю, что здесь вы со временем столкнетесь с проблемами — как, впрочем, и при работе с другими заданиями и пакетами SSIS. К сожалению, я не могу подкрепить это соображение количественными аргументами или дать какие-либо ссылки, так что я, возможно, неправ, но у меня остались смутные воспоминания о том, что несколько лет назад мне самому приходилось сталкиваться с некоторыми трудностями в этой сфере, и я решил отнести работу с пакетами SSIS к разряду потенциальных проблем.
В остальном же, если вы располагаете серверами (я имею в виду как аппаратную часть, так и лицензии SQL Server), необходимыми для обеспечения функционирования Multi-Server Administration, это будет для вас одним из наиболее подходящих вариантов организации управления заданиями агентов SQL Server, а также выполнения таких заданий при использовании групп доступности AlwaysOn.
1.
2. «Продвинутые» системы ;
3. Дополнительные способы аварийных переключений заданий;
4. Еще один способ работы с аварийными переключениями и активацией заданий.
Ключевая идея данной серии статей состоит в том, что вы должны стараться синхронизировать задания агента SQL Server на ряде хостов группы доступности AlwaysOn, чтобы вне зависимости от того, идет ли речь о резервных копиях или о пакетных заданиях, вы всегда могли быть уверены, что задания выполняются: во-первых, в тот момент, когда это необходимо, и, во-вторых, на определенном хосте (или в отношении такого хоста) в соответствии с вашим замыслом. Чтобы помочь вам реализовать данную потребность, я описал ряд приемов синхронизации настроек заданий, деталей исполнения и других параметров на ряде серверов — все это с помощью сценариев или как бы «вручную». Примечательно, что в системе SQL Server, в сущности, реализован фантастический механизм для удовлетворения потребностей в «синхронизации» без предварительной настройки, то есть пользователю нет нужды составлять особый код. И работа с данным механизмом осуществляется посредством настройки Multi-Server Administration или с использованием идеи, согласно которой вы можете взять один агент Single SQL Server Agent и наделить его статусом главного сервера Master Server (MSX), тогда последний может «направлять» или контролировать выполнение заданий и других деталей агента SQL Server на управляемых серверах, именуемых целевыми Target Servers (TSX). Если вы познакомились со всеми предыдущими статьями серии и вам до сих пор не доводилось слышать о механизме Multi Server Administration (а может быть, вы слышали, но просто забыли о нем, как и большинство пользователей), для вас, возможно, стала откровением идея управления заданиями агентов SQL Server с помощью серверов MSX/TSX.
Да, их действительно можно использовать именно для этой цели. Но, как вы, вероятно, предположили, здесь имеется ряд ограничений. На первый взгляд управление заданиями агентов SQL Server с помощью главного сервера осуществляется довольно просто. Вам нужно только выполнить следующие действия.
• Настройте серверы MSX/TSX (хосты группы доступности должны быть настроены как целевые серверы, причем здесь вы можете указать, что каждое из заданий агента SQL Server, которое потребуется запустить, нужно выполнять на всех целевых серверах в одно и то же время и с абсолютно идентичной логикой/кодом.
• Настройте или модифицируйте ваши «мульгисерверные» задания таким образом, чтобы они включали логические конструкции для выявления предпочтительных реплик для резервных копий (когда будете работать с ними); руководствуйтесь при этом данными ранее рекомендациями или логическими конструкциями для выявления основной реплики при работе с пакетными заданиями; в этом случае ориентируйтесь на рекомендации из соответствующей статьи.
• Предоставьте событиям развиваться своим чередом — без непроизводительных затрат и проблем, связанных с синхронизацией, которые были описаны в предыдущих статьях.
Разумеется, мы рассматриваем ситуацию, что называется, в самом общем виде. При этом я ни в коем случае не сбрасываю со счетов комбинацию MSXTSX, поскольку это, без сомнения, наилучший механизм управления заданиями агентов SQL Server при работе с хостами или базами данных групп доступности AlwaysOn.
Впрочем, имеется ряд обстоятельств, которые вам следует держать в поле зрения, если вы решите идти по этому пути. Все это довольно очевидные ловушки, однако мне хотелось бы о них упомянуть.
• Не размешайте главный сервер Master Server на одном из хостов своей группы доступности, ибо это поставит под угрозу отказоустойчивость ваших заданий/резервных копий. Сформулирую свою мысль иначе. Идея групп доступности состоит в том, чтобы объяснить следующий факт: отдельный экземпляр SQL Server (то есть хост группы доступности) может дать сбой и обязательно выйдет из строя. Поэтому размещение на одном из хостов эквивалента «главного контроллера» агента SQL Server, координирующего выполнение всех заданий, служит гарантией того, что в конечном счете вы на каком-то этапе потеряете главный сервер, отчего пострадают задания, средства предупреждения и т.д.
• Если выполнение заданий и резервных копий является для вас важной задачей (как это бывает в большинстве случаев), имеет смысл преобразовать в кластер ваш сервер MSX или главный сервер. Иными словами, если вы установите новый «контроллер» (то есть главный сервер) с целью координации выполнения заданий на нескольких отказоустойчивых системах SQL Server, размещающих базы данных группы доступности, то получите единственную точку отказа при выполнении потенциально жизненно важных операций: получение резервных копий и выполнение заданий. Тогда вам нужно будет превратить в отказоустойчивый ваш сервер MSX, что сделать довольно легко: нужно, чтобы ваш агент SQL Server, выступающий в роли главного сервера, был развернут в составе экземпляра отказоустойчивого кластера AlwaysOn — так, чтобы он тоже стал в достаточной степени отказоустойчивым.
• Синхронизация. Системы MSX/TSX могут функционировать безукоризненно, но иногда они теряют согласованность.
• Пакеты SSIS. Предполагается, что системы MSX/TSX могут работать с пакетами SSIS (в виде планов обслуживания SQL Server) без предварительной настройки. Однако я подозреваю, что здесь вы со временем столкнетесь с проблемами — как, впрочем, и при работе с другими заданиями и пакетами SSIS. К сожалению, я не могу подкрепить это соображение количественными аргументами или дать какие-либо ссылки, так что я, возможно, неправ, но у меня остались смутные воспоминания о том, что несколько лет назад мне самому приходилось сталкиваться с некоторыми трудностями в этой сфере, и я решил отнести работу с пакетами SSIS к разряду потенциальных проблем.
В остальном же, если вы располагаете серверами (я имею в виду как аппаратную часть, так и лицензии SQL Server), необходимыми для обеспечения функционирования Multi-Server Administration, это будет для вас одним из наиболее подходящих вариантов организации управления заданиями агентов SQL Server, а также выполнения таких заданий при использовании групп доступности AlwaysOn.
