Русские Блоги
Общее введение
DataPower в основном служит на этапах тестирования и проверки продукта, а также на этапах эксплуатации и обслуживания. Он может предоставлять функции хранения, просмотра, извлечения и анализа различных ресурсов данных, чтобы улучшить возможности управления данными и повысить эффективность работы пользователей. , Чтобы пользователи, занимающие разные должности или роли, могли обмениваться ресурсами данных, устранять информационные островки и в то же время обогащать методы анализа данных пользователей, помогать пользователям получать опыт и знания в области бизнеса из ресурсов данных, улучшать и улучшать качество продукции и оптимизировать услуги по эксплуатации и техническому обслуживанию. Уровень.
Функциональная ценность DataPower
Ключевая особенность
Ключевые особенности DataPower воплощены в шести аспектах: одновременный доступ пользователей, общий объем данных, скорость хранения в реальном времени, возможности анализа данных, хранение резервных копий данных и надежная работа системы.
Ключевые показатели DataPower
Метод извлечения данных DataPower 
Обучающий курс по DataPower
В 2017 году, когда начинался наш проект во Вьетнаме, мы столкнулись с новым для нас зверем IBM DataPower. IBM DataPower – продукт, представляющий собой gateway между клиентами и бэкендами, предназначенный для фильтрации, маршрутизации, обогащения или других преобразований проходящих через него сообщений (далее – запросов). Обучаться нужно было быстро, времени на раскачку не было, поэтому нам было предложено самостоятельно ознакомиться с ним, после чего были многочасовые конференции по скайпу с нашим коллегой из Москвы, который передавал нам свои знания и опыт работы с этим продуктом.
Самостоятельное обучение основывалось на изучении документации и просмотре обучающих видео из интернета – и тут меня ждал подвох. Мне практически не удалось найти информации на русском языке. К слову, мои знания английского языка на тот момент были не на высшем уровне, к тому же это был мой первый проект и, наверное, именно эти факторы усложнили мне жизнь. Это сподвигло меня написать обучающую статью на русском языке и в максимально простом изложении для начинающих разработчиков, которые столкнулись с этим продуктом и пытаются оперативно понять его азы. Статья не освободит вас от чтения документации, но облегчит жизнь на первых этапах понимания «как это работает».
Стоит также заметить, что приведенная в практике структура будет приближена к реальному проекту, что позволит вам использовать ее как базу, расширяя и дополняя под ваши требования. В заключение к разделам «Теория» будет приведено несколько слов об уже реализованном проекте, а также некоторые особенности, на которые стоит обратить внимание.
Часть 1. Установка DataPower средствами Docker Toolbox
Установите и запустите приложение Docker Toolbox. Сразу после запуска вы увидите IP адрес машины, по которому в дальнейшем будет доступен DataPower:
Для запуска образа необходимо изменить некоторые настройки виртуальной машины (актуально для версии IDG.2018.4.1.0) и перезапустить ее:
-
Останавливаем докер-машину командой:
Примечание. Если будет предложено перезапустить «docker-machine env» — выполните:
Часть 2. Домены
2.1. Теория
Домены в DataPower позволяют разделить средства администрирования и разработки, а также обеспечить безопасность.
После установки существует только домен default, из которого могут быть созданы домены приложений. Для каждого домена существует своя конфигурация параметров.
Некоторые общие ресурсы и параметры можно определить только в default домене, к ним относятся сетевые интерфейсы, пользователи и управление доступом, домены приложений и другие.
Домен приложений – это раздел разработки для служб, обрабатывающих запросы. Службы, определенные в нём, не могу быть общими с другим доменом приложений. Домены приложений могут перезапускаться отдельно и независимо друг от друга, без необходимости полного перезапуска DataPower.
Вы можете создавать, перезапускать, сбрасывать, приостанавливать, возобновлять или удалять домены. Более подробную информацию обо всех возможностях администрирования вы можете найти в официальной документации.
Немного о реализованном проекте. Мы использовали 3 домена:
- default – домен по умолчанию, содержащий общие ресурсы и параметры;
- trunk – основной домен, содержащий все необходимое для обработки запросов;
- settings – домен настроек и безопасности, в локальных файлах содержится информация о правилах маршрутизации сервисов и параметрах безопасности.
Необходимость перенести все настройки в отдельный домен возникла в связи с поиском более простого пути развертывания. Как и во многих проектах среды dev, test и prod у нас были разделены, а вынос в отдельный домен настроек позволил устанавливать все основные домены из dev среды в других средах посредством экспорта/импорта, без риска потерять настройки среды.
2.2. Практика
- В поле поиска введите «domain», выберите «Application Domain» и нажмите «Добавить»
- Здесь вам необходимо указать название домена, комментарий (при желании) и активировать auditing и logging. Заполните поля и примените изменения
- Аналогично добавьте еще один домен «trunk»
- Перейдите в Review changes
- и сохраните конфигурацию домена
- Проверить состояние созданных объектов вы можете, перейдя в default домене по дереву навигации в Status -> Main -> Object Status
- Выберите View by: types
- Найдите в списке Application Domain и проверьте состояние объектов: каждый из них должен быть сохранен, включен и в состоянии up. Если всё так – переходите к следующей главе
Часть 3. Менеджеры очередей
Менеджер очередей не является обязательным компонентом IBM DataPower, но именно на примере с MQ можно показать всю мощь этого продукта. MQ будем использовать от компании IBM. Во время тестирования, описанного в 6 главе, нам будет необходимо отправлять сообщение в локальный менеджер очередей. В данной статье я сделаю это с помощью утилиты rfhutil, но вы можете использовать любой доступный вам способ. Для тестирования необходимо будет создать коннект из DP к вашему локальному менеджеру очередей с помощью MQ Queue Manager.
3.1. Теория
Менеджер очередей обеспечивает обмен данными между шлюзом и удаленными администраторами очередей.
Вы также можете настроить MQ Queue Manager Group, что позволит повысить отказоустойчивость системы. Это может быть полезно, например, если вы хотите подключать клиента к любому из набора работающих администраторов очередей и еще в ряде случаев, с которыми вы можете ознакомиться в официальной документации.
Из опыта проекта стоит отметить только одну особенность: в свое время мы хотели попробовать реализовать балансировку нагрузки средствами DataPower, в частности, с использованием групп менеджеров очередей, но на практике не обнаружили такой возможности. Альтернативное решение – создание кластера менеджеров очередей.
3.2. Практика
3.2.1. Подготовка
- Установите WebSphere MQ;
- Создайте локальный менеджер очередей LOCAL_DP_QM, доступный по порту 3630;
- Настройте канал DP.SVRCONN;
При создании канала вам могут быть полезны следующие команды:
3.2.2. Создание IBM MQ Queue Manager
- Перейдите в домен trunk.
- В поиске наберите MQ, выберите IBM MQ Queue Manager и нажмите добавить.
- Вам необходимо указать название(TEST_QM), хостнейм менеджера очередей, имя менеджера очередей и имя канала, а также таймаут. Выполните настройку и сохраните изменения.
Проверьте состояние объекта менеджера очередей аналогично проверке статуса доменов. Для этого из домена trunk выберите Object Status и фильтр View by: types. В разделе «IBM MQ Queue Manager» отыщите соответствующий объект и проверьте его состояние.
Часть 4. Многопротокольные шлюзы
4.1. Теория
Multi-Protocol Gateway (MPG) – многопротокольный шлюз, позволяющий принимать запросы от клиентов по различным протоколам, а затем по различным протоколам передавать их на удаленный сервер. Протокол, используемый клиентом может не совпадать с протоколом, используемым сервером удаленного доступа.
В основных настройках MPG вы можете определить следующие компоненты:
- XML Manager – управляет компиляцией и кэшированием таблиц стилей(xsl,xslt), кэшированием документов.
- Policy – состоит из правил, каждое из которых определяет набор действий, применяемых к сообщению, проходящему через шлюз.
- Настройки front и back side (настройка url, типов входящего и исходящего сообщений, таймаутов и другого).
Пара слов о проекте:
В реализации проекта используется 4 многопротокольных шлюза (маршрутизирующий, 2 трансформационных для разных конечных систем и дополнительный, предназначенный для получения файлов из домена settings). На схеме ниже представлена общая схема взаимодействия:
Количество MPG может варьироваться в зависимости от архитектуры решения в целом. В нашем случае DataPower стоит перед интеграционной шиной (IIB) и микросервисами, которые имеют существенные различия в интерфейсах(json/http против xml/mq), поэтому трансформационные MPG было решено делать под каждый специфический бэкенд и называть его соответствующе. Для всех клиентов мы работаем по json/http, поэтому маршрутизирующий MPG – один. Основные MPG состоят из 3 правил обработки сообщений – запроса, ответа и ошибок. Каждое правило состоит из необходимых действий, таких как transformation, logging, routing и прочие.
Из особенностей – если в policy вы используете действие ConvertQueryParamToXML, то будьте внимательны к InputConversion. Если вы зададите Default Encoding значение JSON и попытаетесь отправить GET-запрос, то будете удивлены, обнаружив, что сообщение не претерпело никаких трансформаций, указанных вами и не обнаружите никаких его следов. Данную особенность поможет преодолеть создание отдельного правила для GET-запросов.
4.2. Практика
4.2.1. Подготовка
Все необходимые для работы файлы вы можете найти по ссылке https://github.com/EvgenyaVlasenko/IBM_DataPower.git
4.2.1.1. Домен trunk
- Перейдите в домен trunk.
- На панели управления выберите File Management.
- В каталоге local создайте следующую структуру каталогов и поместите в нее соответствующие файлы (в каждом файле содержится краткое описание того, какие функции он выполняет, а также более подробно остановимся на этом далее в статье).
4.2.1.2. Домен settings
- Перейдите в домен settings.
- На панели управления выберите File Management.
- В каталоге local создайте следующую структуру каталогов и поместите в нее соответствующие файлы (внутри файлов также содержится их краткое описание).
4.2.2. Создание GetFileMPG
Для начала создадим простой вспомогательный MPG, который будет возвращать файлы из домена settings.
- Перейдите в домен settings.
- На панели управления выберите Multi-Protocol Gateway и нажмите создать.
- Укажите имя (GetFileMPG), описание(по желанию) и тип бэкенда (dynamic). На самом деле, так как вызова бэкенда фактически не будет, а будет только возвращаться файл из локальной системы, то в данном примере тип бэкенда можно указать любой.
- Задайте типы запроса и ответа. Явное указание типов позволит сократить количество встроенных проверок. Указание типа Pass through позволит не создавать правило (в данном случае для трансформации ответа). В случае, если мы укажем Request Type тоже Pass through, то не сможем никак обработать сообщение. Этот вариант нам не подходит, поэтому ограничиваем тип запроса с помощью Non-XML.
4.2.3. Создание RoutingMPG
Теперь создадим RoutingMPG. На основании входного запроса и правил маршрутизации он определит, куда и с какими параметрами следует отправить запрос.
- Перейдите в домен trunk.
- Создайте новый Multi-Protocol Gateway в соответствии с пунктами 2-10 раздела 4.2.2, используя следующие значения:
- 3 – имя: RoutingMPG, тип бэкенда: Dynamic (для возможности маршрутизации запросов в разные MPG при необходимости).
- 4 – Rq: Non-xml, Rs: Non-xml.
- 6 – имя: RoutingHTTP_FSH, ip: 0.0.0.0, порт: 7170, + Get method.
- 8 – имя: RoutingPolicy.
- 9 – имя: RoutingPolicy_rule_req, направление: Client to Server.
- Добавьте еще одно действие для маршрутизации запроса, для этого перетащите на правило действие «Route», дважды щелкните на нем для настройки, заполните поля и примените изменения. Файл route.xsl получает файл настроек роутинга из домена settings через созданный ранее GetFileMPG. После этого на основании URI выделяются из файла уже те настройки, которые необходимы для данной операции. Часть из них используется для маршрутизации, а часть добавляется в хедеры для использования в других MPG. Параметры input и output определяют способ работы только с телом сообщения и никак не влияют на хедеры и переменные. Поэтому: вход из null – так как для роутинга не используется информация из тела сообщения. Вывод в null – так как результатом трансформации является только изменение служебной информации.
- Направление: Сервер-клиент, имя: RoutingPolicy_rule_resp;
Трансформация: Input INPUT, Output NULL, файл трансформации local:///RoutingMPG/transform/resp.xslt. Файл resp.xslt получает http-статус ответа трансформационного MPG и в явном виде устанавливает его в ответ RoutingMPG. Если этого не сделать, то по умолчанию будет выставлен код 200, даже если в трансформационном MPG возникла ошибка. - Направление: Error, имя: RoutingPolicy_rule_error;
Трансформация: Input INPUT, Output PIPE(согласно документации, использование PIPE между двумя смежными узлами действий в качестве INPUT и OUTPUT способно устранить дополнительную обработку и снизить объём используемой памяти), файл трансформации local:///RoutingMPG/transform/errors.xsl. Файл errors.xsl получает код и текст ошибки из ответа от трансформационного MPG и формирует JSON-сообщение об ошибке в ожидаемом клиентом формате.
4.2.4. Создание IIBMPG
Следующий шаг – создание трансформационного MPG. Предположим, внешняя система имеет формат запроса JSON, а внутренняя — XML. Нам необходимо преобразовать входное сообщение так, чтобы его смогла понять внутренняя система. Стоит заметить, что это не всегда простое преобразование сообщения целиком. Часто требуется передать усеченное или дополненное сообщение, иногда с полностью переработанной структурой.
- Перейдите в домен trunk.
- Создайте новый Multi-Protocol Gateway в соответствии с пунктами 2-10 раздела 4.2.2, используя следующие значения:
- 3 – имя: IIBMPG, тип бэкенда: Dynamic
- 4 – Rq: JSON, Rs: XML
- 6 – имя: IIBHTTP_FSH, ip: 127.0.0.1(только запросы с этого же DataPower), порт: 7172, + Get method
- 8 – имя: IIBPolicy
- 9 – имя: IIBPolicy_rule_req, направление: Client to Server
- Добавьте описание. Файл IIBRuleRoute.xsl на основании X-DP-Transform-Name в headers запроса получает из файла local:///IIB/route/IIBRouteRules.xml названия файлов трансформации запроса, ответа и ошибки для этого сервиса и устанавливает их значения в соответствующие контекстные переменные var://context/IIB/reqTransform, var://context/IIB/ansTransform, var://context/IIB/errTransform. Также в контекстные переменные помещаются другие значения из headers(url,uri,expire,timeout).
- Направление: Сервер-клиент, имя: IIBPolicy_rule_resp;
Трансформация: Input INPUT, Output PIPE, файл трансформации var://context/IIB/ansTransform(контекстная переменная для подстановки трансформации респонса «на лету»). - Направление: Error, имя: IIBPolicy_rule_error;
Трансформация: Input NULL, Output PIPE, файл трансформации var://context/IIB/errTransform(контекстная переменная для подстановки трансформации ошибки «на лету»).
Часть 5. Тестирование
5.1. Подготовка
- Скачайте, например, утилиту rfhutil для чтения и записи сообщений в очередь;
- Тестовые файлы находятся в папке tests той же директории, что и файлы проекта.
5.2. Проверка работоспособности
-
Отправьте запрос помощью утилиты curl (для запроса ниже текущая директория должна быть той же, где лежит example.json).
Часть 6. Логирование
6.1. Теория
Log Targets фиксируют различные сообщения, происходящие в системе и сохраняют их в указанном виде.
На проекте мы создали Log Targets для каждого шлюза отдельно. Логи хранятся в текстовом виде, для каждого шлюза отведено по 4 файла для логов объемом 1000Kb, при превышении лимита файлы перезаписываются циклически. При средней активности с такими параметрами информацию о запросе можно извлечь в течение 2-4 дней после его выполнения. В идеале лучше сделать внешние сборщики логов, так как при малейшем повышении нагрузки все перезапишется. Помимо этого, DataPower, как минимум, виртуальный, имеет тенденцию умирать, когда у него закончится место на жестком диске, что можно заметить далеко не сразу, а только когда заполнятся логи какого-нибудь тихого MPG, про который все давно забыли.
6.2. Практика
- Перейдите в домен trunk;
- В поиске наберите Log Target и нажмите добавить;
- На главной вкладке заполните следующие поля:
- Название(IIB_LOG);
- Тип(File);
- Формат (Text);
- Формат timestamp(zulu);
- Имя файла (logtemp:///IIB.log — для IIBMPG);
- Размер файла(1000).
- Добавьте фильтр объектов. В нашем случае мы хотим следить за MPG с именем IIBMPG.
-
В случае успеха вы ничего не увидите в логах или увидите следующие сообщения, означающие, что вы работаете в режиме отладки и вредите производительности.
Часть 7. Если что-то пошло не так
- Если вам удалось дойти до логирования – вы знаете, где искать логи. Если их недостаточно – логируйте тело, хедеры и все, что могло бы вам как-то указать на причину ошибки.
- Часто не обойтись без системных логов. Перейдите на панели управления в раздел View Logs. Здесь всегда можно найти системные ошибки, вроде «не найден файл», «не удалось распарсить ответ» и всякая всячина подобного рода.
- Для начинающих будет очень полезен режим дебага. Он позволяет пошагово проследить ваше сообщение при прохождении через каждое действие. Для активации перейдите в нужный вам MPG и в верхнем меню справа нажмите Show Probe -> Enable Probe. После отправки запроса обновите список и нажмите на лупу. Переходя через действия, вы можете наблюдать за всеми трансформациями вашего запроса.
WebSphere DataPower SOA Appliances
IBM WebSphere DataPower — это специализированные программно-аппаратные комплексы, которые созданы для решения интеграционных задач.
Преимущества данного продукта:
- Созданная для конкретных задач, настраиваемая аппаратная платформа
- Предоставляется высокоуровенная, сертифицированная безопасность
- Высокая производительность
-Трансформация XML
-Терминация SSL
-Шифрование данных - Множество функций, включенных в одно устройство
-Управление качеством сервиса
-Динамическая маршрутизация и распределение нагрузки
-Пограничная защита
-Политики доступа и SLA
-Трансформация транспорта и контента - Упрощенная модель обслуживания
-форм-фактор для стойки 1U/2U
-Защита трафика в считанные минуты
-Комплексное обновление
-Быстрая Интеграция
-Простое управление/мониторинг
Особенности IBM WebSphere DataPower:
Защищённая аппаратная платформа
- Аппаратная платформа с физической защитой
-Корпус с индикацией несанкционированного
вскрытия
-Нет внешних дисков и т.п.
-«Заблокированная» конфигурация по-умолчанию
-Подробный журнал аудита - Сторонние сертификации
-Common Criteria EAL4
-FIPS 140-2 Уровень 3 (с HSM)
-Drummond Group AS2 - Pащищенный образ прошивки
-Подписан и зашифрован IBM
-Обновление в течение нескольких минут
-Оптимизированная, встроенная ОС DPOS
-Нет произвольного стороннего ПО или Java
- Применения цифровой подписи
- Шифрование любого содержимого
- Шифрование XML на разных уровнях
-На уровне сообщения
-На уровне отдельных полей
-Заголовки - Защита от XML-атак
-Entity Expansion/Recursion Attacks
-Public Key DoS
-XML Flood
-Resource Hijack
-Message/Data Tampering
-Message Snooping
-XPath or SQL Injection
-XML Incapsulation
-XML Virus
-и др.
Функции ESB в аппаратном устройстве
- Интеграция разных транспортных протоколов
-HTTP(s), WebSphere MQ, WebSphere JMS,
-Tibco EMS,
-SFTP, FTP(s), NFS,
-IMS, Database (DB2, Oracle, Sybase, SQL Server) - Трансформация формата сообщений
-XML, и не-XML форматы
-WebSphere Transformation Extender
для мэппинга данных - Синхронное/асинхронное
взаимодействие - Аудит
- Отсутствие программирования
- Интуитивная обработка в виде
последовательности действий - Импорт/экспорт конфигураций между разными
площадками - Режим просмотра транзакций показывает
содержимое сообщений между действиями
WebSphere Appliance Management Center
- Управление несколькими устройствами с
одной консоли
-Установка новых прошивок
-Разнесение измененных конфигураций - Поддержка Политик размещения
- Выполнение защищенного создания
резервной копии и восстановления - Просмотр работы устройств в реальном
времени - Использование навигации на основе ролей
для упрощения основных задач - Слежение за версиями прошивок и
конфигураций с помощью встроенного
управления версиями
Редакции IBM WebSphere DataPower
IBM DataPower XI52 — Интеграция
- Аппаратная шина ESB
- Конвертация всего-во-всё налету
- Интеллектуальное распределение нагрузки и динамическая
- Безопасность веб-сервисов
- Аутентификация и авторизация
- Централизованное управление политиками
IBM DataPower XG45 — 1U устройство
WebSphere DataPower Integration Appliance XI50B & XI50z
- XI50B, и XI50z доставляет и преобразует общие сообщения
- интеграция и маршрутизация в форм-факторе снижает расходы и повышает производительность.
IBM DataPower XB62 — B2B шлюз
IBM DataPower XE82 — Пограничное устройство
SOA-устройства IBM WebSphere DataPower
IBM WebSphere DataPower SOA Appliances — это семейство готовых и предварительно настроенных сетевых устройств для монтажа в стойку ( XML-устройства ), которые могут помочь ускорить развертывание XML и веб-служб при расширении инфраструктуры SOA . Первоначально эти устройства были созданы компанией DataPower Technology Inc., которая была приобретена IBM в октябре 2005 г. [1]
Это семейство WebSphere состоит из монтируемых в стойку сетевых устройств, блейд-устройств, устройств, стоящих внутри мейнфрейма z/OS , и виртуальных устройств .
Список устройств
На основе аппаратной модели 9235
- Устройство кэширования WebSphere DataPower XC10
- XML-ускоритель WebSphere DataPower XA35
- Устройство безопасности WebSphere DataPower XS40
- Устройство интеграции WebSphere DataPower XI50
- Устройство WebSphere DataPower B2B XB60
- Устройство обмена сообщениями WebSphere DataPower XM70
Эта аппаратная модель представляет собой монтируемое в стойку устройство высотой 1U с 4 подключениями Ethernet по 1 Гбит/с. [2]
На основе аппаратной модели 7198
Эта модель представляет собой монтируемое в стойку устройство высотой 1U, имеющее 4 подключения Ethernet по 1 Гбит/с и 2 подключения Ethernet по 10 Гбит/с. [3]
На основе аппаратной модели 7199
Эта модель представляет собой монтируемое в стойку устройство высотой 2U, имеющее 8 подключений Ethernet 1 Гбит/с и 2 подключения Ethernet 10 Гбит/с. [4]
На основе аппаратной модели 8436
Эта модель представляет собой монтируемое в стойку устройство высотой 2U, имеющее 8 подключений Ethernet 1 Гбит/с и 2 подключения Ethernet 10 Гбит/с. [5]
Технические характеристики
Устройства DataPower содержат множество аппаратных компонентов, в том числе IPS на основе ASIC , специальные зашифрованные диски RAID и (дополнительно) аппаратные модули безопасности .
Устройства DataPower работают на единой микропрограмме с цифровой подписью , содержащей операционную систему на базе Linux и стек приложений. Его прошивка выполняется на флэш-накопителе . IBM обновляет образ прошивки каждые 10–20 недель. Пользователи не могут запускать сторонние приложения на DataPower, поскольку им потребуется традиционный сервер и операционная система . Вместо традиционной файловой системы он работает с набором изолированных виртуальных файловых систем, называемых «домены приложений». В результате для клиентских подключений он может выглядеть как сетевая файловая система любого типа с любым типом папок и ссылок.
Микропрограмма DataPower в основном используется для выполнения функций обмена электронными сообщениями, таких как преобразование и маршрутизация сообщений в качестве сервисной шины предприятия, или для защиты интерфейсов веб-служб и лежащей в их основе архитектуры. Он помогает интегрировать любые два приложения, рассматривая их как сервисы, и не зависит от платформы и языка.