Однажды ребята позвали создать общебанковский контур ETL Informatica (Data Integration) и вот что из этого вышло.

мем @ Мультфильм “Вовка в тридевятом царстве” студия Союзмультфильм

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

1. У нас будет много не связанных проектов

Классический способ разграничения проектов Informatica - это отдельный контур. Такое решение работает у многих заказчиков и проблемы с таким решением минимальны. Если случится авария, то пострадает только один проект. Этот подход дорог в реализации, так как требует команды админов, сопровождения да и самих серверов, если требуется развернуть полноценные контура разработки, тестирования, препрода и боя.

На старте пилота у нас был только один контур, но это только к лучшему.

Встал вопрос: Как изолировать проекты на одном сервере?

Тут есть следующие варианты:

Раздельные репозиторные сервисы, но общий файл с коннектами. Тут все просто, есть много сервисов, один odbc.ini, tnsnames - любой проект сможет переиспользовать коннект, но все сидят в своих репах.
С учетом 1 пункта нужно разбить odbc.ini, tnsnames на одельные файлы и указать их в Environment Variable для интеграционных сервисов - нормальная практика, так можно и нужно делать. Новые переменные в данном случае потребуют перезапуска сервиса. Сами коннекты можно добавлять на лету.
Environment Variable для интеграционных сервисов
Использовать OS Profiles. Тут все просто, но есть нюансы:
- Вешаем setuid и setgid на файл pmimpprocess:
  sudo chmod u+s $INFA_HOME/server/bin/pmimpprocess
  sudo chmod g+s $INFA_HOME/server/bin/pmimpprocess
- Создаем пользователя на уровне os для указания его при создании профиля, но это не является обязательным критерием, пользователь может быть и тем под которым запускается Informatica.
- Так же указываем Environment Variable, но в отличии от 2 пункта, переменные профиля подхватываются на лету и это очень удобно. Можно указать например кодировку.
  Environment Variable для OS Profile
- Раздаем права на использование профиля на группу или конкретных пользователей.
- Разрешаем использование на уровне интеграционного сервиса
  Настройка интеграционного сервиса
- Обязательно обьяснить разработчику, что нужно использовать OS Profiles, про разделение unicode/non-unicode потоков по папкам в репозитории, особые переменные.
Режим паранои: раздельные odbc.ini, tnsnames + OS Profiles + права на доступ к директории с файлами коннектов на уровне OS сервера. Создается директория для конфигов проектов, вешаем chmod 760. Но надо учесть так же то, что вам надо бекапить все это хозяйство и надо пользователю под которым запускается бекап добавить группу пользователя созданного для профиля конкретного проекта.

Все изменения odbc.ini и tnasnames обязательно дублируются в конфлюенс, очень дисциплинирует, как заказчика так и администратора.

Нам нужен доступ к файловой системе, дай доступ по SFTP!

У нас на сервер могут ходить только админы, но конечно же есть варианты, как сделать хорошо и не ~~обос..~~ выдать больше чем требуется. Тут нам поможет SSH Chroot. В целом, много инструкций в интернете, но из основного: создаем пользователя без права логина, но в группе пользователя informatica, создаем chroot директорию за пределами хомяка, даем доступ в /etc/ssh/sshd_config к этой папке для конкретного пользователя.

Match User techuser_projectname
ForceCommand internal-sftp
PasswordAuthentication yes
ChrootDirectory /chroot/techuser_projectname
PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

Биндим папку, например с Param файлами, не забыв раздать права на изменение на группу на конкретный файл или директорию. Всё, пользователь может зайти по SFTP, но команды выполнить не может.

Такой доступ может быть предоставлен только для DEV и TST среды. Для боевых сред возможен только доступ к логам потоков, при наличии функционального сопровождения проекта, чтобы не дергать администраторов каждый раз.

ps. а может пользователь загрузить исполняемый файл и захватит сервер вызвав его через Command task informatica? Теоритически может, но регламенты запрещают вызывать shell скрипты в разработке и такой релиз не пройдет ревью. Помним, что процессы в данном случае уже запускаются в изолированном профиле.

2. Замониторь нам всё

Админконсоль Informatica представляет минимальный набор для мониторинга сервисов. Либо он работает, либо он упал, никаких уведомлений она слать не умеет да и не должна. Сидеть с открытой админкой конечно же никто не будет.

Тут так же есть несколько способов мониторинга, начиная от проверки наличия процессов Informatica заканчивая тестовым коннектом, например к репозиторию. Каждый крутится, как может, вендор не дает на эту тему никаких инструкций и рекомендаций, хотя у них там и были какие то платные опции~~, которые за все время никто в РФ по моему так и не купил~~. Proactive Monitoring - дополнительный продукт Informatica для мониторинга всего, но его удасться использовать только если у вас репозитории на MS SQL или Oracle. В данном случае он нам не подошел, ждем апдейтов от вендора, будут они развивать этот продукт вместе с основными продуктами или похоронят в прошлом.

Выбор был не большим, прикрутить все к Zabbix!

У Informatica есть ряд ключевых процессов которые можно отследить. При отстувии которых, однозначно будет понятно, что сервис лег:

Корневой процесс ноды
Процесс Adminconsole
Процесс репозитория - pmrepagent
Процесс интеграционника - pmserver
WebWerviceHub, MRS, DIS и другие, доступно в документации

Но и тут всплыли нюансы, если у нас больше одного сервиса то мы увидим кучу процессов вида:

pmrepagent - RG9tYWluMTA1 vcxfvxfv bm9kZTAy XXXXXX 
pmserver RG9tYWluMTA1 dgxgxcgxcg== bm9kZTAy XXXXXXX

Так! Что это такое и как отследить что есть что? А все просто, вся эта абракадабра это base64 представление информации о сервисе, домене, ноде.

Нам требутеся только первые 3-4 значения: имя домена, имя сервиса и имя ноды, они идут друг за другом.

Нужно ли обьяснять как создавать шаблоны в Zabbix? Думаю нет. Создаете элементы данных, например по маске команды:

system.run["ps -ef | grep 'java -ea -Djava.security.krb5.conf' | grep -v grep | wc -l"]
system.run["ps -ef | grep 'AdminConsole' | grep -v grep | wc -l"]
system.run["ps -ef | grep 'pmserver RG9tYWluMTA1 SVNfSEFCUg== ' | grep -v grep | wc -l"] 
system.run["ps -ef | grep 'pmrepagent - RG9tYWluMTA1 UlNfSEFCUg== ' | grep -v grep | wc -l"]

Естественно, тут надо либо вручную кодировать имена сервисов для проверки элементов либо сделать предобработку с кодированием в base64.

И навешиваете тригерры, если значение изменилось на 0.

Важный момент! Если сервис падает, то не должно оставаться зомби процессов, в 99,99% случаев процесс киляется, в админконсоли будет указана ошибка или трейс в логах.

На основе всех этих данных уже можно строить дашборды, например в Grafana, слать email или сообщение в slack.

А так же, мониторьте директорию с кешем/шару для кеша. Админы Informatica часто ловят падение из-за забитого диска с кешем.

3. Стандартизация для движения разработки в бой

Тут все просто и мало слов: Максимально стандаритизируйте правила для разработки, что разрешено, что запрещено.

Как выше упомянул, у нас запрещены Command task вызовы shell скриптов. Нельзя использовать в именах коннектов тип среды, dev, tst и тд.

Рекомендованы: email уведомления для успешных и не успешных сессий в Post-Session Email, использование WSH для внешнего вызова потоков и их отслеживания внешним сервисом. Обязательно нужно максимально параметризировать все, что можно. Использовать WF для автогенерации параметров.

Обязательное ревью разработки перед установкой в TST на наличие захаркоженных ссылок, кривых имен коннектов, параметров. Даже простой просмотр xml файла выявляет болячки разработки.

Установите правила для админов: для именования сервисов, путей, конфигов, документирование нестандартных действий.

4. Масштабируйся

Используйте HA и GRID, где это позволяет инфраструктура. Добавление новых нод в домен не сложное действие, но учтите параметры конфигурации сервисов после добавления. Указывайте универсальные пути сетевых шар, разделов и кешей. Используйте один файл конфигурации на шаре, вместо локальных (звучит не очень), чтобы исключить разницу в файлах.

Для особо тяжелых и ресурсоемких проектов в рамках домена мы планируем добавлять новые ноды. Хороший ли это подход? Сможем проверить только на опыте. Главное иметь резервный Gateway!

В целом HA и GRID работает у многих, но есть инфраструктурные требования для резервирования. Это в некоторых случая доставляет неудобства. Пусть, например у вас HA настроен, но резерв простаивает из-за ограничений резервирования. Можно ли это обойти? Можно, если архитектурно будет защищено решение, что данный контур высокой доступности или масштабируется в GRID и потеря одной ноды не влияет на работу разработки. Например в Сбере отлично работал GRID, но в данном случае, мы еще небольшой пилот и таких задач у нас пока нет.

Выводы

Выводы очень простые: Informatica имеет большой встроенный потенциал, но чаще всего мы его не используем. Администратор на начальном этапе может себе облегчить жизнь, а может прострелить ногу и не дойти до финиша при росте проекта.

За последние 5 лет удалось посмотреть и потрогать руками большой спектр проектов заказчиков использующих продукты Informatica. Где то все хорошо, где то не очень.

Если статья будет кому-то полезна - отлично.

Полезные ссылки

Как мы общебанковскую Informatica пилили