Самая типичная организация работы системы BI - это наличие минимум двух серверов баз данных. Один - тестовый, второй - основной. В идеальном случае эти сервера должны быть одинаковы. Тогда при тестировании решений на тестовом сервере можно видеть как система будет работать на основном. При разработке решений SSIS в среде с несколькими серверами необходимо использовать механизм конфигураций. Чаще всего используются 2 типа конфигураций: SQL server и XML.
В нашей системе использовалась SQL server конфигурация. На основном сервере была специальная база, где хранились конфигурации и на которую ссылались все пакеты. Как правило, в таблицах конфигурации сохранялись имена серверов и баз данных для конкретных пакетов. В завимости от значений, которые хранились в таблицах конфигурации, пакет выполнялся либо на основном сервере, либо на тестовом. Но, для того, чтоб выяснить где он должен выполняться, пакет всегда обращается к основному серверу. Таким образом с данным типом конфигурации возникает 2 проблемы:
1. Перед выполнением пакета необходимо обновить значения в таблицах конфигурации и указать там сервер на который должен использовать пакет.
2. Нельзя параллельно запускать один и тот же пакет на двух серверах (по причине того, что в таблице конфигурации будет указан один и тот же сервер).
Для того, чтобы иметь возможность побороть проблему 2, а так же забыть про проблему 1, можно использовать XML конфигурацию. Для этого нужно определить специальную папку для хранения конфигураций. Эта папка должна быть на всех серверах, где предполагается использовать пакеты и в ней должны быть все конфигурации. Кроме того, такая же папка должна быть на компьютерах разработчиков.
Если в пакете используется несколько коннекшнов к базам данных и для всех этих конекшнов необходимо менять сервера (основной, тестовый), то логично было бы использовать файл конфигурации, в котором сохранялось бы значение серверов для используемых конекншнов, однако тогда возникает проблема с использованием данного файла конфигурации - все конекшны, которые определены в файле должны быть определены во всех пакетах, где предполагается использовать данный файл конфигурации.
Решение данной проблемы - использование отдельного файла конфигурации для каждого конкшна. Данный подход позволяет унифицировать процесс разработки пакета и упростить задачу программиста при определении конфигураций.
"Подводные камни":
1. Если над разработкой пакетов работает много программистов, необходимо договориться о нотации (как называть конекшны в пакете, как называть файлы конфигурации и т.д.). Названия переменных, хранимых в файле конфигурации case sensitive поэтому нужно быть внимательным при их определении. В этом плане очень помогает BIDSHelper - видно какие конекшны работают с файлом конфигурации.
2. Постоянно синхронизировать файлы на сервере с локальными.
Нужно помнить, что при запуске пакета на локальном компьютере он будет исполняться локально и будет использовать локальные файлы конфигурации. В случае, если для какого то конекшна не окажется соответствующего файла, будут применены настройки пакета по умолчанию (те значения, что указывались при разработке).
Тут описан этот подход с картинками : Использование XML конфигурации в SSIS в картинках
В нашей системе использовалась SQL server конфигурация. На основном сервере была специальная база, где хранились конфигурации и на которую ссылались все пакеты. Как правило, в таблицах конфигурации сохранялись имена серверов и баз данных для конкретных пакетов. В завимости от значений, которые хранились в таблицах конфигурации, пакет выполнялся либо на основном сервере, либо на тестовом. Но, для того, чтоб выяснить где он должен выполняться, пакет всегда обращается к основному серверу. Таким образом с данным типом конфигурации возникает 2 проблемы:
1. Перед выполнением пакета необходимо обновить значения в таблицах конфигурации и указать там сервер на который должен использовать пакет.
2. Нельзя параллельно запускать один и тот же пакет на двух серверах (по причине того, что в таблице конфигурации будет указан один и тот же сервер).
Для того, чтобы иметь возможность побороть проблему 2, а так же забыть про проблему 1, можно использовать XML конфигурацию. Для этого нужно определить специальную папку для хранения конфигураций. Эта папка должна быть на всех серверах, где предполагается использовать пакеты и в ней должны быть все конфигурации. Кроме того, такая же папка должна быть на компьютерах разработчиков.
Если в пакете используется несколько коннекшнов к базам данных и для всех этих конекшнов необходимо менять сервера (основной, тестовый), то логично было бы использовать файл конфигурации, в котором сохранялось бы значение серверов для используемых конекншнов, однако тогда возникает проблема с использованием данного файла конфигурации - все конекшны, которые определены в файле должны быть определены во всех пакетах, где предполагается использовать данный файл конфигурации.
Решение данной проблемы - использование отдельного файла конфигурации для каждого конкшна. Данный подход позволяет унифицировать процесс разработки пакета и упростить задачу программиста при определении конфигураций.
"Подводные камни":
1. Если над разработкой пакетов работает много программистов, необходимо договориться о нотации (как называть конекшны в пакете, как называть файлы конфигурации и т.д.). Названия переменных, хранимых в файле конфигурации case sensitive поэтому нужно быть внимательным при их определении. В этом плане очень помогает BIDSHelper - видно какие конекшны работают с файлом конфигурации.
2. Постоянно синхронизировать файлы на сервере с локальными.
Нужно помнить, что при запуске пакета на локальном компьютере он будет исполняться локально и будет использовать локальные файлы конфигурации. В случае, если для какого то конекшна не окажется соответствующего файла, будут применены настройки пакета по умолчанию (те значения, что указывались при разработке).
Тут описан этот подход с картинками : Использование XML конфигурации в SSIS в картинках
А можно в таблице с конфигурациями задать несколько конфигураций - тестовая, рабочая или для разработчика. В пакете нужно определить переменную, в которой будет храниться имя сервера, которое потом подставляется в строку соединения к нашему гипотетическому источнику. И самый последний шаг - выстроить последовательность загрузки конфигураций - последняя в списке Package Configuration Organizer и будет рабочей для пакета (на мой взгляд странное решение :) ). Соответственно, меняя последовательность загружаемых конфигураций в пакете, получаем разные источники, не затрагивая при этом пакеты, развернутые на продакшене и тесте.
ОтветитьУдалитьЧто-то как то слишком заморочено и не совсем понятно, как ты поменяешь последовательность загружаемых конфигураций не меняя пакет и не деплоя его на сервер.
ОтветитьУдалитьВ моем подходе весь фокус в простоте и отсутствии дополнительных действий пользователя. А если учесть, что у нас много разработчиков и опыт у них еще не очень большой, то чем больше им нужно будет выполнять действий, тем более вероятна ошибка.
Сергей: может я не так понял задачу ?
ОтветитьУдалитьсуть в том, что не все конфиги хранятся в одном месте (таблице) и в этой таблице ничего менять не надо
т.е. у тебя есть пакет развернутый на сервере. Ты его открыл в BIDS и хочешь выполнить на тесте, так ?
я: Нет. У меня есть куча пакетов, которые разрабатывают юзеры.
Пока они разрабатывают, эти пакеты запускаются на тестовом сервере. При разработке у них вообще нет конфигурации т.е. конекшны указывают на тестовый сервер.Потом, когда нужно вводить пакет в работу, делается конфиг
Для конфига во ВСЕХ пакетах есть один служебный конекшн к базе данных на продакшн сервере - в ней лежат все конфиги.
Как правило, хранятся свойства остальных конекшнов пакета, т.е. названия серверов
Сергей: пока все понятно :)
я: Потом готовый пакет деплоится на тест сервер и на продакшн.
Выполнять работу пакет будет для того сервера, который прописан в конфиге, независимо от того, где он запускается.
Поэтому перед каждым запуском пакета нужно обновить значения в таблице конфигураций на продакшне.
Сергей: понятно. строка конфигурации для пакета одна, верно ?
я: Нет. Сколько тебе нада. Более того - у нас могут быть даже разные таблицы для разных пакетов. Чаще всего группируются подсистемы.
Сергей: ок. Но ты пишешь, что если надо пакет выполнить в другой среде, то руками меняется конфиг это раз, и два - то что этот конфиг действует для всех кто будет запускать этот пакет. так ?
я: Во первых - когда производится запуск при разработке, ничего менять не нужно, тк нет конфигурации еще. Во вторых - значения меняются не совсем вручную. При запуске пакета в работу создается джоб на сервере первым шагом которого является смена значений конфигурации на требуемые. Это обычный update.