Начальные сведения о WebSphere Message Broker 6.1 для z/Linux

Брокер сообщений WebSphere® Message Broker от компании IBM® (далее «брокер сообщений», «Message Broker») помогает объединить компоненты корпоративной архитектуры как для интеграции приложений, так и для создания корпоративной сервисной шины (ESB) для поддержки сервис-ориентированной архитектуры (SOA). В этой статье обсуждаются преимущества Message Broker версии 6.1 для z/Linux, а также описываются его основные настройки для работы на z/Linux.

Message Broker версии 6.1 для z/Linux — 64-разрядная программа, которая может работать только на 64-разрядных образах z/Linux. Как и на всех поддерживаемых платформах, доступны все динамические компоненты брокера сообщений, за исключением графической среды разработки и администрирования (Toolkit). Поэтому для установки среды разработки и получения возможности администрирования вам потребуется платформа Intel® Linux® или Microsoft® Windows® . Подробности см. в системных требованиях для WebSphere Message Broker.

Message Broker для z/Linux предоставляет все возможности, доступные для других поддерживаемых платформ. Вы можете разрабатывать потоки сообщений и процедуры обработки в Intel Linux либо в Microsoft Windows и без дополнительных изменений работать с созданными элементами Message Broker в среде выполнения z/Linux.

Начальные сведения о z/Linux

z/Linux — это просто операционная система Linux, работающая на IBM System z™. Два самых популярных корпоративных дистрибутива поставляются компаниями SuSE и Red Hat, и оба они поддерживают Message Broker версии 6.1. Существуют как 31-, так и 64-разрядные версии z/Linux.

Чтобы определить, какой у вас образ z/Linux, 31- или 64-разрядный, введите в интерпретаторе командной строки команду uname –m. Если у вас 31-разрядный образ, то в выводе будет s390. Если 64-разрядный — то s390x. Вы должны убедиться, что команда выводит s390x, если хотите использовать Message Broker версии 6.1.

Почему нужно использовать Message Broker на z/Linux?

В этом разделе описываются преимущества работы с Message Broker на z/Linux. Технологии Integrated Facilities for Linux (IFL) и HiperSockets™ делают z/Linux экономичной, гибкой и высокопроизводительной коммуникационной платформой для Message Broker.

Integrated Facility for Linux (IFL)

IFL — это процессоры z/Series, предназначенные для запуска z/Linux. Они стоят дешевле стандартных процессоров общего назначения, поэтому позволяют экономически эффективно масштабировать System z для использования свободных аппаратных ресурсов. На процессорах IFL может работать z/VM, либо их можно разделить на логические разделы (LPAR) — в зависимости от ваших нужд, как показано ниже на рисунке 1. Эта гибкость позволяет легко создавать и загружать дополнительные образы z/Linux по мере перемены запросов вашего бизнеса. Чтобы еще больше расширить преимущества подобного подхода, архитектура System z позволяет при необходимости переназначать ресурсы, что дает возможность объединить ресурсы Linux и централизованно управлять ими на проверенной аппаратной платформе.

HiperSockets

Технология HiperSockets реализует высокоскоростные соединения TCP/IP в рамках центрального процессорного комплекса, исключая необходимость в каком-либо физическом соединении кабелями или внешнем сетевом соединении серверов, работающих на различных логических разделах (LPAR). Обмен данными производится через системную память процессора; серверы соединяются через «внутреннюю локальную сеть», что дает прирост в производительности в рамках центрального процессорного комплекса.

z/Linux может использовать преимущества соединений TCP/IP по технологии HiperSocket. Это означает, что вы можете настроить узлы Message Broker, использующие технологии, основанные на TCP/IP (такие как MQ или HTTP) на использование высокоскоростных соединений с другими технологиями TCP/IP в рамках процессорного комплекса, в том числе с подсистемами z/OS и другими образами z/Linux. Например, можно исполнять обработчик очереди брокера сообщений на z/Linux и при помощи каналов MQ, использующих HiperSockets, соединяться с другим обработчиком очереди, работающим на z/OS.

Производительность

Если вы сейчас используете предыдущую версию Message Broker (например, 6), советуем вам ознакомиться с отчетом по производительности для версии 6.1. Основная задача версии 6.1 - повышение производительности рабочей среды Message Broker, со значительными улучшениями в обработке XML, XSLT-преобразованиях, непрозрачном разборе (opaque parsing) XMLNSC и валидации XMLNSC. Подробности см. в отчете о производительности для продуктов семейства WebSphere MQ.

Настройка Message Broker версии 6.1 для работы на z/Linuxux

Системные требования

Брокер сообщений может работать только на 64-разрядных образах z/Linux. Поддерживаются следующие 64-разрядные операционные системы:

• Red Hat Enterprise Linux AS 4.0
• Red Hat Enterprise Linux AS 5.0
• SUSE Linux Enterprise Server (SLES) 9
• SUSE Linux Enterprise Server (SLES) 10

Кроме того, брокер сообщений зависит от WebSphere MQ и СУБД. При установке WebSphere MQ убедитесь, что устанавливается 64-разрядная версия. Брокер сообщений 6-й версии требовал СУБД DB2®, но брокер сообщений версии 6.1 работает как с DB2, так и с Oracle. Поддерживаются следующие версии:

• DB2 V8.2
• DB2 V9.1
• Oracle Database 9i R2
• Oracle Database 10g R1 and R2

Поддержка СУБД может меняться, поэтому перед принятием решения о конкретной установке следует проверить официальные системные требования продукта.

Если вы используете SUSE Linux Enterprise Server (SLES) версии 10, то вам потребуется WebSphere MQ версии 6.0.2.0 и выше.

Настройка Message Broker версии 6.1 для работы с DB2

Если вы хотите настроить брокер сообщений для работы с DB2 в качестве внутренней базы данных, то DB2 можно разместить на том же образе, либо на разных образах с брокером сообщений.

Конфигурация, показанная на рисунке 2 — стандартная установка Message Broker на одном образе, для которой необходимо, чтобы СУБД DB2 и менеджер очереди были созданы в соответствии с документацией для Message Broker. Те, кто работал с брокером сообщений 6-й версии, должны знать, что такая установка только на 64-разрядном z/Linux не была возможна из-за необходимости взаимодействия 31-разрядного Message Broker с 64-разрядной DB2. Теперь, когда брокер сообщений стал 64-разрядным, эта проблема больше не стоит.

Вам может понадобиться разместить базу данных брокера на отдельном образе просто для удобства управления или в случае, если вы переходите с подобной установки, где использовался брокер сообщений 6-й версии. Пример того, как это делается, показан на рисунке 3, где RTCL относится к клиенту среды исполнения DB2:

При такой установке необходимо задать определение удаленной базы данных для клиента среды исполнения. О том, как это делается, см. в документации DB2.

Теперь, когда брокер сообщений поддерживает не только DB2, но и другие СУБД, для подключения к базам данных главным образом используется ODBC (пара доступных узлов использует JDBC). Соответственно, чтобы брокер сообщений мог взаимодействовать с DB2, вам сначала требуется задать определения ODBC. Ранее этот шаг для z/Linux не требовался.

Настройка Message Broker версии 6.1 для работы с Oracle

Доступ к базе данных Oracle осуществляется через TCP/IP, поэтому ее можно установить либо на том же, либо на другом образе. В отличие от DB2, вам не требуется устанавливать клиент на том же образе, что и брокер сообщений, если вы решите разместить базу данных где-то в другом месте.

Как и в случае с DB2, чтобы брокер сообщений мог взаимодействовать с Oracle, вам требуется задать определения ODBC.

Настройка определений ODBC

Брокер сообщений подключается к базам данных через ODBC, поэтому для доступа к ним требуется настроить определения ODBC. В z/Linux, использующей Message Broker 6-й версии, этот шаг не требовался. Определения ODBC задаются в файле odbc64.ini. Шаблон-образец этого файла — <install dir>/ODBC64/V5.2/odbc64.ini. Скопируйте этот файл в выбранное место (например, /var/mqsi/odbc/odbc64.iniи отредактируйте соответствующим образом. Во-первых, поменяйте в соответствии с вашими данными раздел с обязательной информацией. Например,

[ODBC]
# Для включения трассировки ODBC укажите Trace=1
Trace=0
TraceFile/tmp/odbctrace64.out
TraceDll=/opt/ibm/mqsi/6.1/ODBC64/V5.2/lib/odbctrac.so
InstallDir=/opt/ibm/mqsi/6.1/ODBC64/V5.2
UseCursorLib=0
IANAAppCodePage=4
UNICODE=UTF-8

Если нужно добавить определение базы данных DB2, используйте в качестве примера раздел DB2DB:

[MQSIBKDB]
DRIVER=libdb2Wrapper.so
Description=MQSIBKDB DB2 ODBC Database
Database=MQSIBKDB

Также требуется добавить запись в раздел источников данных ODBC:

MQSIBKDB=IBM DB2 ODBC Driver

Аналогично, если вы хотите добавить определение базы данных Oracle, можно использовать в качестве примера раздел ORACLEDB:

[MQSIBKDB]
Driver=/opt/ibm/mqsi/6.1/ODBC64/V5.2/lib/UKora22.so
Description=DataDirect 5.2 64bit Oracle Wire Protocol
HostName=myoraclehost
PortNumber=1521
SID=mysid
CatalogOptions=0
EnableStaticCursorsForLongData=0
ApplicationUsingThreads=1
EnableDescribeParam=1
OptimizePrepare=1
WorkArounds=536870912
ProcedureRetResults=1
ColumnSizeAsCharacter=1

Также требуется добавить запись в разделе источников данных ODBC:

MQSIBKDB=DataDirect 5.2 64bit Oracle Wire Protocol

При редактировании этого файла следите, чтобы не было разделов с одинаковым именем. Для баз данных DB2 имя источника данных ODBC (раздела) соответствует алиасу для базы данных DB2, но для определений источников данных Oracle оно не обязательно должно совпадать с системным идентификатором Oracle (или с именем прослушивающего TCP/IP-сервиса Oracle).

При определении источника данных для Message Broker, например, при помощи флага -n команды mqsicreatebroker, следует указать имя раздела ODBC.

После создания этого файла требуется указать брокеру сообщений, чтобы определения считывались из него; для этого в командном интерпретаторе задается переменная среды ODBCINI . Например,

export ODBCINI=/var/mqsi/odbc/odbc64.ini

Если вы не установите эту переменную среды, то столкнетесь с ошибками при попытке запуска команды, требующей доступа к источнику данных. Чтобы избежать этих ошибок, добавьте переменную среды в свой пользовательский профиль либо создайте пользовательский профиль для работы с брокером сообщений, который будет автоматически задействоваться при обращении к скрипту mqsiprofile . Это можно сделать, создав в /var/mqsi/common/profiles пользовательский профиль, содержащий эту команду.

Настройка Message Broker для согласованных транзакций (XA)

Брокер сообщений можно настроить для использования согласованных транзакций (XA) при помощи согласованных потоков обработки сообщений. Согласованный поток сообщений гарантирует, что все обновления по защищенным ресурсам, таким, как сообщения MQ и данные в базе данных, совершаются или откатываются совместно в рамках одной транзакции.

Согласование транзакции потоков сообщений в z/Linux обеспечивается WebSphere MQ. Соответственно, вам требуется настроить обработчик очереди брокера для согласования баз данных, с которыми вы хотите работать. Чтобы сделать это, в файле qm.ini обработчика очереди WebSphere MQ определите для каждой базы данных раздел XAResourceManager . Если поток сообщений использует словари сообщений либо содержит узлы публикации, необходимо убедиться, что для внутренней базы брокера также имеется раздел XAResourceManager в файле qm.ini обработчика очереди WebSphere MQ.

Раздел, который добавляется в этот файл, зависит от типа используемой базы данных. Нужно добавить раздел для каждого источника данных, для которого согласуются транзакции.

Пример раздела для DB2 показан ниже. Здесь:

• MyDataSource -- имя синонима для базы данных DB2, к которой нужно подключиться,
• MyUserId -- имя пользователя, под которым нужно подключиться к источнику данных,
• MyPassword -- пароль для имени пользователя.

XAResourceManager:
 Name=MyDataSource
 SwitchFile=db2swit
 XAOpenString=db=MyDataSource,uid=MyUserId,pwd=MyPassword,toc=t
 XACloseString=
 ThreadOfControl=THREAD

Аналогично, ниже дан пример раздела для Oracle. Здесь:

• MyDataSource -- имя источника данных ODBC, к которому нужно подключиться.
• MyHostName -- имя хоста TCP/IP, на котором размещена база данных Oracle,
• MyPortNumber -- порт TCP/IP, который прослушивает база данных Oracle,
• MyServerName -- имя TCP/IP для сервера Oracle,
• MySID -- системный идентификатор Oracle для базы данных (или имя прослушивающего TCP/IP-сервиса Oracle).

XAResourceManager:
 Name=MyDataSource
 SwitchFile=oraswit
 XAOpenString=ORACLE_XA+SQLNET=MyServerName+HostName=MyHostName+PortNumber=MyPortNumber+
 Sid=MySID+ACC=P/MyUserId/MyPassword+SesTM=100+Threads=True+DataSource=MyDataSource+
 DB=MyDataSource+K=2+
 XACloseString=
 ThreadOfControl=THREAD

( XAOpenString на деле представляет собой одну строчку, здесь она отформатирована для удобства чтения.) Помимо настройки файла qm.ini , вам потребуется создать некоторые символьные ссылки в директории /var/mqm/exits64 . Проще всего это сделать скриптом mqsimanagexalinks , прилагающимся к Message Broker.

Для DB2 можно использовать примерно такую команду:

mqsimanagexalinks create DB29 <директория брокера> <директория db2>

которая создаст символьную ссылку вроде такой:

db2swit -> <директория брокера>/sample/xatm/db2swit
libdb2.so.1 -> <директория db2>/lib64/libdb2.so.1

Для Oracle можно использовать примерно такую команду:

mqsimanagexalinks create DD52 <директория брокера>

которая создаст символьные ссылки вроде таких:

libUKicu22.so -> <директория брокера>/ODBC64/V5.2/lib/libUKicu22.so
oraswit -> <директория брокера>/ODBC64/V5.2/lib/UKoradtc22.so
UKora22.so -> <директория брокера>/ODBC64/V5.2/lib/UKora22.so

Помимо настройки WebSphere MQ, для Oracle требуются следующие дополнительные действия

1. Убедитесь, что пользовательский идентификатор, используемый брокером сообщений для доступа к Oracle, располагает привилегией select для таблицы dba_pending_transactions table.
2. Убедитесь, что в вашей базе данных Oracle доступен пакет JAVA_XA . Это можно проверить через sqlplus и desc JAVA_XA. Если пакет не найден, установите его с помощью Oracle DBA; обычно это производится запуском скрипта $ORACLE_HOME/javavm/install/initxa.sql .

Настройка DB2 для доступа Message Broker к DB2 UDB в z/OS

Брокер сообщений можно настроить для доступа к базам данных DB2 в z/OS (или iSeries). Брокеру сообщений не требуется знать, что база данных находится в базовой системе, ее положение определяется средствами DB2. На рисунке 5 ниже показаны два самых распространенных способа доступа к базам данных, размещенным в системе z/OS.

Следующие этапы настройки требуются для определения каналов связи, показанных на рисунке 5 стрелками с номерами. При определении каналов связи соответствующие команды требуется запустить для установки DB2 на образе по левую сторону стрелки, потому как связь будет инициироваться слева направо.

Определение канала связи 1 с рисунка 5

Первый этап — настроить DB2, чтобы система могла подключаться через TCP/IP к другим экземплярам DB2.

Задайте имя сервиса TCP/IP в менеджере баз данных при помощикомандой: db2 update dbm cfg using svcename имя_сервиса, где имя_сервиса , где имя_сервиса — корректное имя сервиса из /etc/services(например, DB2_db2inst1).

Это изменение можно проверить, запустив db2 get dbm cfg.

Убедитесь при помощи команды db2set DB2COMM=TCPIP , что DB2 настроена для связи по TCP/IP.

Перезапустите DB2 и проверьте, что db2start не выводит каких-либо предупреждений.

Следующий этап — зарегистрировать базу данных. Чтобы задать удаленный сервер z/OS или iSeries, запустите нижеследующую команду, где myhost — имя хоста, на котором работает база данных z/OS или iSeries. Вместо номера порта можно указать имя сервиса (подробности см. в справочном центре DB2).

db2 catalog tcpip node mynode remote myhost server myport
db2 terminate

Далее вам нужно зарегистрировать базу данных сервера подключения к БД (DCS), как указано ниже. local_dcsname обозначает ваше локальное имя для базы данных z/OS или iSeries, а target_dbname — имя базы данных z/OS или iSeries (например, идентификатор расположения).

db2 catalog dcs database local_dcsname as target_dbname
db2 terminate

Далее можно зарегистрировать локальную базу данных, используя следующую команду (подставьте соответствующие значения для local_dcsname, MYDB и mynode :

db2 catalog database local_dcsname as MYDB at node mynode authentication dcs
db2 terminate

После того как базы данных зарегистрированы, вам нужно привязать утилиты и приложения к удаленному серверу. Это можно сделать следующим образом (предполагается, что пользователь bob имеет привилегию BINDADD :

db2 connect to MYDB user bob using mypwd
db2 bind db2_path_dir@ddcsmvs.lst blocking all sqlerror continue grant public
db2 connect reset

Здесь db2_path_dir обозначает каталог, где находятся DB2-файлы .lst — обычно /sqllib/bndв каталоге установки.

Далее необходимо настроить DB2 для использования концентратора соединений, который позволяет таким приложениям, как Message Broker, оставаться подключенными без затрат каких-либо ресурсов сервера с DB2. Вы можете иметь тысячи активных пользователей приложений и всего несколько активных потоков на сервере DB2. Концентратор соединений требуется задействовать, если вы хотите, чтобы база данных участвовала в согласованных транзакциях (XA). Этого можно добиться, обновив настройки менеджера базы данных таким образом, чтобы параметр MAX_CONNECTIONS (наибольшее число клиентских соединений) был больше, чем MAX_COORDAGENTS (наибольшее число агентов согласования). Это можно сделать командой

db2 update dbm cfg using MAX_CONNECTIONS max_number_of_connections

Подробности о концентраторе соединений DB2 см. ниже в разделе Ресурсы .

Если планируется использовать согласованные транзакции, то вам также потребуется настроить менеджер узлов синхронизации DB2. Для этого измените настройки менеджера баз данных таким образом, чтобы SPM_NAME был уникальным идентификатором в вашей сети. Обычно этот параметр задают в качестве имени локального хоста:

db2 update dbm cfg using SPM_NAME your_spm_name

Определение канала связи 2 с рисунка 5

До настоящего момента база данных z/OS определялась только для экземпляра DB2 ESE. Теперь требуется определить ее для DB2 RTCL, чтобы завершить цепочку слева направо. Аналогично тому, как вы регистрировали базу данных брокера, вы должны зарегистрировать синоним базы данных, который только что указали установке DB2 ESE для клиента среды исполнения (RTCL), размещенного на том же образе, что и брокер сообщений. Выполните следующие действия, подставив нужные значения:

• MYNODE — имя, которое вы дали узловому элементу DB2 RTCL для удаленного образа z/Linux,
• MYDB — имя, которое вы дали вашей базе данных z/OS (или iSeries) на удаленном образе z/Linux в команде выше db2 catalog database local_dcsname as MYDB ... .

db2 catalog database MYDB at node MYNODE
db2 terminate

Проверка правильности настроек DB2

Чтобы проверить, что DB2 настроена правильно, используйте в интерпретаторе команду db2, и убедитесь (указав соответствующее имя пользователя и пароль), что имеете доступ к таблицам, которые будет использовать экземпляр Message Broker. После создания своего брокера, используйте команду mqsisetdbparms для настройки Message Broker, чтобы он использовал для каждой базы данных подходящие учетные данные.

Соображения по переходу

Если у вас уже установлен брокер сообщений версии 6 и вы хотите перейти на версию 6.1, то схема перехода будет зависеть от архитектуры используемых образов z/Linux. Вы не можете перевести брокеры, работающие на 31-разрядных системах z/Linux, на версию 6.1. В этом случае требуется создать брокер в 64-разрядной системе z/Linux и перенести на него ресурсы. Если имеются какие-либо пользовательские расширения на C, то, прежде чем использовать с брокером версии 6.1, их необходимо пересобрать под 64-разрядную систему. Подробности о переходе на новую версию смотрите в соответствующих разделах справочного центра Message Broker.

Заключение

В этой статье были описаны различные варианты запуска WebSphere Message Broker версии 6.1 для z/Linux. Версия для z/Linux является функционально полной и совместима с версиями для других платформ. Среду можно достаточно гибко настраивать под ваши требования. Брокер сообщений может хранить свои данные как в DB2, так и в Oracle. Пользовательские данные могут храниться в системах DB2, Oracle и Informix. Кроме того, можно обращаться к данным DB2 в системах z/OS и iSeries через DB2 Connect.

Процессоры IFL позволяют снизить затраты на содержание WebSphere Message Broker. Вы получаете возможность использовать реализацию WebSphere Message Broker для Linux и одновременно пользоваться преимуществами надежности аппаратного обеспечения System z. Уникальная для System z технология HiperSockets дает быструю связь по протоколам, основанным на TCP/IP.

Указанные выше преимущества делают реализацию WebSphere Message Broker для z/Linux надежным и эффективным решением.