Интеграция приложений на основе WebSphere MQ

Дополнительные средства администрирования

Разбить на страницы
Показывать лекцию целиком

Очередь недоставленных сообщений и восстановление данных

Практически все события, за исключением обработки non persistent сообщений, фиксируются в различных лог файлах WebSphere MQ. Существует два вида лог файлов. В первый записываются сообщения об ошибках, а во второй все изменения состояния объектов менеджера, включая обработанные persistent сообщения. Файл ошибок имеет формат, который легко прочитать с помощью любого текстового редактора. В него записываются события, связанные со стартом или остановкой менеджера и каналов, ошибки установки соединения, ошибки приема или отправки сообщений, например с некорректным форматом или ошибки конвертации, связанные с кодовой страницей. Одним словом, все события, связанные с обеспечением деятельности всех менеджеров очередей, созданных на данном компьютере. Расположение этих файлов задается при первоначальной установке WebSphere MQ. Например, для платформы Windows по умолчанию они расположены в каталоге C:\Program Files\IBM\WebSphere MQ\Errors и имеют название amqerrXX.LOG, где ХХ – номер файла. Второй тип файлов имеет специальный формат и представляет собой журнал изменений свойств объектов. Кроме этого в него записываются все persistent сообщения, обработанные менеджером очередей. Для каждого локального менеджера создаются свои файлы. Например, для менеджера очередей QM_Win2000 на платформе Windows они расположены в C:\Program Files\IBM\WebSphere MQ\log\QM_Win2000\active\ и имеют имя s000000X.log, где X – номер файла. Напомним, что существует два вида логирования сообщений и изменений свойств объектов – линейный и круговой. Линейный вид логирования, в отличие от кругового, позволяет как записывать, так и восстанавливать состояние менеджера в определенный момент времени. Запись образа объектов менеджера производится с помощью команды rcdmqobj . Синтаксис команды имеет вид:

rcdmqobj -m QmgrName -t ObjectType
  GenericObjName

где:

QmgrName – имя менеджера.

ObjectType – тип объекта. Может принимать значения nl или namelist для списка кластеров, prcs или p rocess для процессов, q или queue для всех типов очередей, ql или qlocal для локальных очередей, qa или qalias для alias очередей, qr или qremote для удаленных локальных очередей, qm или qmodel для модельных очередей, qmgr для менеджера, * или all для всех объектов.

GenericObjName – имя объекта.

Встречаются ситуации, когда необходимо удалить файл очереди, содержащий сообщения. Это необходимо, например, при заполнении свободного пространства дисковой системы (тома), выделенной под WebSphere MQ на UNIX платформах. В этом случае WebSphere MQ сообщит, что объект данной очереди поврежден. Восстановить поврежденные как сознательно, так и в результате сбоя дисковой системы, объекты при условии линейного логирования, можно с помощью команды rcrmqobj . Синтаксис команды имеет вид:

rcrmqobj -m QmgrName -t ObjectType
  GenericObjName

где:

QmgrName – имя менеджера;

ObjectType – тип объекта;

GenericObjName – имя объекта.

В результате выполнения этой команды восстанавливаются не только очереди, но и persistent сообщения в очередях. Это возможно благодаря тому, что для каждого объекта менеджера ведется запись изменений его состояния, и так называемые точки checkpoint . Команда rcrmqobj повторяет все события, которые были с поврежденным объектом от последнего checkpoint до конца лог файла. Поскольку not persistent сообщения в файл не записываются, то они и не восстанавливаются.

При использовании кругового логирования поврежденные объекты следует удалить, а затем создать заново.

Кроме технических ошибок бывают еще и логические ошибки, связанные с неправильными настройками объектов. Если в локальной удаленной очереди указано неверное имя удаленного менеджера или очереди назначения, то сообщения все равно будут доставлены на менеджер, расположенный по адресу, указанному в канале отправителе, который использует соответствующую трансмиссионную очередь. Для обработки ошибочных или недоставленных сообщений существует специальная очередь недоставленных сообщений, которая указывается в атрибуте менеджера Dead-letter Queue в закладке Extended. Изменим пример из лекции 5, в котором при создании на менеджере QM_Win2000 локальной удаленной очереди Win2000_HPUX.RQ будет неправильно указана очередь, в которую нужно доставить сообщения:

ALTER QREMOTE ('Win2000_HPUX.RQ') +
       XMITQ('Win2000_HPUX.TQ') +
       RNAME('Win2000_AIX.Q') +
       RQMNAME('QM_HPUX')

Очереди назначения Win2000_AIX.Q на менеджере QM_HPUX не существует, однако сообщение все равно будет доставлено на этот менеджер в очередь DEAD_LETTER. Его можно просмотреть с помощью WebSphere MQ Explorer (рис. 7.1).

Просмотрев свойства сообщения, в закладке Dead-Letter Header можно увидеть код ошибки 2085, который говорит о том, что в заголовке сообщения существует неизвестный объект. В поле Destination Queue можно увидеть, что очередью назначения является несуществующая очередь Win2000_AIX.Q. Из данной ситуации есть три выхода:

  • Создать очередь Win2000_AIX.Q на менеджере QM_HPUX и перенаправить сообщение из DEAD_LETTER в нее с помощью команды:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести команду:

    ACTION(RETRY)

    и нажать <Ctrl+d> (для платформы Windows <Ctrl+z> <Enter> и еще раз <Ctrl+z> <Enter> ) и выйти из команды runmqdlq нажав <Ctrl+c>. В результате выполнения данной команды WebSphere MQ попытается заново инициировать помещение сообщения с указанными атрибутами из очереди DEAD_LETTER. Этот способ следует применять в случае переполнения существующей очереди назначения. Напомним, что если количество

    (рис 7.1) Свойства недоставленного сообщения

    сообщений в очереди превышает ее атрибут Maximum Queue Depth, то вновь поступающие сообщения также будут помещаться в очередь недоставленных сообщений.

  • Перенаправить сообщение в другую очередь, например в Win2000_HPUX.Q. В данном случае синтаксис команды runmqdlq будет выглядеть следующим образом:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести:

    ACTION(FWD) FWDQ('Win2000_HPUX.Q')
  HEADER(NO)

    и нажать Ctrl+d. Сообщения из очереди DEAD_LETTER будут помещены в очередь Win2000_HPUX.Q.

  • Удалить сообщение из DEAD_LETTER, исправить свойства локальной удаленной очереди Win2000_HPUX.RQ на менеджере QM_Win2000:

    ALTER QREMOTE ('Win2000_HPUX.RQ')
   RNAME('Win2000_HPUX.Q')

    и послать сообщение заново.

    •

    Второй способ можно использовать, когда переполнена как очередь назначения, так и очередь недоставленных сообщений. Если это не удается, то можно поступить следующим образом. Назначить в качестве очереди недоставленных сообщений новую очередь и перестартовать менеджер. Вновь поступающие сообщения будут помещаться уже в нее. Однако следует не допускать переполнения очередей недоставленных сообщений. Кроме этого, следует отметить, что простое перекладывание сообщения из очереди недоставленных сообщений в очередь назначения не даст нужного результата, поскольку недоставленные сообщения имеют свой собственный (MQDEAD) формат.

    Иногда встречается случай, когда после перезагрузки менеджера очередей пропадают сообщения из трансмиссионной (transmission) очереди, несмотря на то, что ее атрибут Default Persistence установлен в persistent. В таком случае следует проверить этот атрибут в соответствующей локальной удаленной (remote) очереди и также установить его в persistent.

    Дополнительные средства администрирования

    В каждом случае при возникновении ошибок WebSphere MQ дает ее номер.

    С помощью документации , или программы WebSphere MQ Messages and Codes Helper, доступной по адресу , можно выяснить суть ошибки и исправить ее. Внешний вид программы представлен на рис.7.2.

    (рис 7.2) Внешний вид программы WebSphere MQ Messages and Codes Helper

    Кроме расшифровки кода самой ошибки, данная программа дает варианты причин, по которым могла произойти ошибка и методы устранения ее.

    Помимо вышеуказанной программы существует множество программ, облегчающих работу с объектами менеджеров очередей. Рассмотрим программу WebSphere MQ Administrator (Support Pac MO71). Программа имеет графический интерфейс и позволяет производить любые действия с объектами как локальных, так и удаленных менеджеров. Внешний вид программы представлен на рис.7.3.

    (рис 7.3) Внешний вид программы WebSphere MQ Administrator

    Добавить в список доступных менеджеров для управления новый удаленный менеджер можно, выполнив пункт меню File => Add Location. На экране появится форма, изображенная на рис.7.4.

    (рис 7.4) Форма добавления удаленного менеджера очередей

    В поле Location нужно ввести имя отображения в списке менеджеров, доступных для управления, а в поле Queue Manager - имя удаленного менеджера, выставить флажок в поле Client и нажать кнопку Configured.

    В открывшейся форме (рис.7.5) в поле Channel Name нужно ввести имя канала типа Server Connection или Client Connection (данный канал должен быть создан на удаленном менеджере), с помощью которого будет осуществляться подключение к менеджеру, IP адрес с указанием номера порта для службы listener и нажать кнопку Ok.

    (рис 7.5) Конфигурация параметров подключения к удаленному менеджеру

    После того, как форма закроется, нажать кнопку Add в предыдущей форме. Подключаемый удаленный менеджер должен отобразиться в форме, показанной на рис.7.3 под именем QM_HPUX. Рассмотрим пример, показывающий как можно оперировать с сообщениями, находящимися в очереди на этом удаленном менеджере. Допустим, нужно переложить второе сообщение из очереди Win2000_HPUX.Q в очередь TEMP.Q. Для выполнения операций просмотра, удаления или перемещения сообщений нужно выполнить следующие действия.

    Поместив курсор на менеджер QM_HPUX выполнить пункт меню Commands => Queue List.

    В открывшейся форме (рис.7.6) при нажатии на кнопку Refresh появится список очередей менеджера QM_HPUX.

    Выбрав очередь Win2000_HPUX.Q нажать кнопку Browse и в открывшейся форме (рис. 7.7) нажать Refresh.

    Поместить курсор на второе сообщение, в поле Target Queue ввести имя очереди, в которую нужно переместить сообщение (в нашем случае это TEMP.Q ) и нажать кнопку Move. После этого второе сообщение будет перемещено в очередь TEMP.Q. Соответственно для копирования сообщения нужно нажать на кнопку Copy, для удаления – Delete. Кроме этого, данная программа в отличие от Message Browser утилиты WebSphere MQ, позволяет просматривать до 10000 сообщений, причем на экран можно вывести полный текст сообщения с помощью кнопки Open, а с помощью кнопки Detail свойства сообщения. Вставить сообщение между другими сообщениями в очереди нельзя.

    (рис 7.6) Список очередей менеджера QM_HPUX(рис 7.7) Список сообщений очереди Win2000_HPUX.Q

    Для этого следует переместить все сообщения после требуемого в другую очередь, затем поместить нужное сообщение и вернуть все перемещенные обратно. Несомненным преимуществом программы является возможность удаления сообщений даже если очередь эксклюзивно открыта другим приложением. Отображение списка объектов в данной программе статично, то есть для получения списка объектов в данный момент времени следует нажимать кнопку Refresh. Последняя версия программы доступна по адресу: .

    Существуют программы, позволяющие перемещать текст сообщения в файл и наоборот, текст, содержащийся в файле помещать в тело сообщения. Примером такой программы может служить программа rfhutil, являющаяся частью Support Pac IH03 (IBM WebSphere Business Integration Message Broker display, test and performance utilities). Программа доступна по адресу: .

    Внешний вид программы представлен на рис.7.8. Данная программа может быть полезна в случае, когда надо исправить текст внутри сообщения, находящегося в очереди. Для этого можно переместить текст сообщения в файл, исправить его, а затем положить обратно в очередь. Следует учесть, что данная программа при считывании сообщения удаляет его из очереди. Поэтому, во избежание потери текста сообщения, желательно скопировать его в какую-нибудь промежуточную очередь с помощью программы WebSphere MQ Administrator ( mqmonntp ) и оперировать с ним.

    (рис 7.8) Внешний вид программы rfhutil

    Остановимся еще на одной важной программе saveqmgr , позволяющей записывать все объекты менеджера очередей в файл в формате команд MQSC для командного процессора runmqsc. Синтаксис команды выглядит следующим образом:

    saveqmgr  -m[-r] QmgrName –f FileName
  -h -v -s -i

    где:

    -m – создается скрипт для локального менеджера.

    -r - создается скрипт для удаленного менеджера. Для подключения к удаленному менеджеру достаточно создать трансмиссионные очереди и каналы в обе стороны.

    QmgrName – имя менеджера.

    –f FileName – имя файла, в который будет записан скрипт. По умолчанию saveqmgr.tst.

    -h – выводит справочную информацию на экран.

    -v – указывает в какой версии MQSC нужно формировать команды для создания объектов. Может принимать значения 1, 2, 5, 51, 52 или 53.

    -s – не создает команды MQSC для объектов, начинающихся на SYSTEM*.

    -i – пропускает создание команд для поврежденных объектов.

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

    Вопросы производительности

    Кроме выяснения причин ошибок передачи и их устранения, администратор WebSphere MQ должен планировать и рассчитывать схемы передачи данных от одной платформы до другой. Рассмотрим простой пример передачи сообщения, содержащего информацию из строки таблицы из одной базы данных DataBase1 в другую базу DataBase2, расположенную на другой платформе. Интерфейс передачи данных можно разбить на три части (рис. 7.9).

    (рис 7.9) Схема интерфейса передачи данных

    Первая часть – программа А, помещающая сообщения в исходящую очередь RQ1, вторая – передача сообщений от одного менеджера очередей к другому в очередь назначения Q2, третья – программа B, помещающая сообщения из очереди назначения Q2 в таблицу базы данных.

    В данной схеме нужно учитывать, что скорость разбора сообщений из очереди назначения Q2 и помещения их в DataBase2 (участок 3 ) должна быть больше скорости поступления сообщений в эту очередь. Если же сообщения генерируются в исходящую очередь из базы DataBase1 не линейно, то необходимо учитывать характер нелинейности и возможные "узкие" места интерфейса. В любом случае не следует допускать переполнения очередей.

    Часто встречаются задачи, в которых требуется при изменении информации в одной системе передать произошедшие изменения в другие системы, причем формат изменяемых данных на разных платформах может иметь различный вид. При этом обработку информации целесообразно сосредоточить в одном месте, так как алгоритмы преобразования данных из DataBase1 в DataBase2, DataBase3 и т.д. очень похожи и имеют много общего, а часто являются подмножествами друг друга. В этом случае мы имеем интерфейс передачи данных с централизованной обработкой сообщений, схема которого показана на рис.7.10.

    (рис 7.10) Схема интерфейса с централизованной обработкой сообщений

    В качестве инструментального средства для центра обработки сообщений рекомендуется Брокер сообщений WebSphere BI Message Broker. Это достаточно эффективный инструмент, являющийся интегрированной средой для визуального проектирования программ обработки сообщений. При проектировании более сложных, разветвленных потоков передачи и распространения информации, которая на пути от источника к приемнику может меняться и дополняться, следует также учитывать производительность всех точек входа и выхода сообщений и соизмерять скорости выгрузки сообщений со скоростью их передачи и обработки.

    Приведем еще несколько приемов настройки и тестирования интерфейсов.

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

    Потребность в этом приеме может возникнуть когда необходимо посылать "пачки" сообщений, например, с QM_AS400 на QM_HPUX. Доступ к запуску приложений на AS400 временно закрыт. Но WebSphere MQ работает. Самое простое решение (рис.7.11) с сервера WindowsNT направляем необходимую "пачку" сообщений на AS400 в локальную удаленную очередь (remote queue), нацеленную на HP_UNIX. Этот же прием может использоваться, если доступ к менеджеру QM_HPUX открыт только с определенного IP адреса.

    (рис 7.11) Перенаправление потоков

    "Вечный двигатель"

    Этот прием весьма полезен при тестировании интерфейсов для проверки стабильности и надежности работы программ. Схема "вечного двигателя" изображена на рис. 7.12. В очереди Remote Queue rq1 на сервере WindowsNT в качестве параметра Remote Queue Name указывается rq2, а на сервере HP_UNIX в очереди Remote Queue rq2 соответственно rq1.

    (рис 7.12) "Вечный двигатель"

    И еще один прием, точнее святая обязанность администратора WebSphere MQ, это документирование интерфейсов. Весьма удобно иметь документированные интерфейсы в графическом виде, и программных средств для этого более чем достаточно (Visio, Bpwin и т.д.). Но по мере сложности интерфейсов их графическое представление становится не наглядным. В этом случае может быть рекомендован Excel, с помощью которого в колонках таблиц прописываются параметры настройки интерфейсов.

    По мере возрастания количества интерфейсов, менеджеров и их объектов может возникнуть ситуация, когда администратор WebSphere MQ по названию объекта не сможет определить его сущность. Во избежание этого рекомендуется с самого начала разработать некоторые правила, по которым следует называть все объекты на разных менеджерах. Например, если простые локальные очереди (local queue) будут оканчиваться на .Q, трансмиссионные (transmission queue) на .TQ, локальные удаленные (remote queue) на .RQ, каналы на .CH, процессы на .P и так далее, то по окончанию сразу можно определить тип объекта. То же касается направления передачи и сущности передаваемых сообщений. Например, надо передать курсы валют из системы ABS1 в систему ABS2.

    Создаваемые объекты в системе ABS1 можно назвать:

    ABS1_ ABS2_CV.RQ – локальная удаленная очередь;

    ABS1_ ABS2_CV.TQ – локальная трансмиссионная очередь;

    ABS1_ ABS2_CV.CH – канал отправитель.

    В системе ABS2:

    ABS1_ ABS2_CV.Q – локальная очередь;

    ABS1_ ABS2_CV.CH – канал получатель.

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

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

    В первой группе решающую роль играет собственно, сетевое оборудование и качество линий связи. Скорость передачи данных от менеджера до менеджера сопоставима со скоростью передачи данных в сети. Ко второй группе можно отнести следующие факторы.

    Серверное оборудование – чем мощнее сервера, тем быстрее будет работать программное обеспечение.

    Размеры баз данных – чем больше база, тем дольше выполняются запросы.

    Алгоритмы обработки сообщений – если требуется просто вставить запись в таблицу, то это может быть относительно высокая скорость, а если требуется выполнение операторов SELECT и проверка условий, на основе которых принимается решение о добавлении или изменении записи, то скорость обработки сообщений уменьшается.

    Программное обеспечение – корректно написанная программа работает быстрее, к тому же выбор языка программирования играет важную роль. Замечено, что один и тот же алгоритм, реализованный на C и Visual Basic, дает существенно разные результаты. Например, простое перекладывание persistent сообщений размером 1Кб из очереди в очередь на одном и том же менеджере (NT платформа, процессор Pentium IV с тактовой частотой 1.8 ГГц) с помощью программы, написанной на С, дает результат 400 сообщений в секунду, а с помощью программы на Visual Basic только 140.

    Тип хранения сообщений в очереди – сообщения persistent обрабатываются медленнее, чем not persistent. Not persistent сообщения из предыдущего примера перекладывались со скоростями 1000 и 200 сообщений в секунду, соответственно.

    Наличие механизмов шифрования и сертификации также влияет на скорость обработки сообщений. Так использование SSL механизма может отнять до 10% производительности в зависимости от длины ключа и алгоритма шифрования данных.

    Страницы:

    Очередь недоставленных сообщений и восстановление данных

    Практически все события, за исключением обработки non persistent сообщений, фиксируются в различных лог файлах WebSphere MQ. Существует два вида лог файлов. В первый записываются сообщения об ошибках, а во второй все изменения состояния объектов менеджера, включая обработанные persistent сообщения. Файл ошибок имеет формат, который легко прочитать с помощью любого текстового редактора. В него записываются события, связанные со стартом или остановкой менеджера и каналов, ошибки установки соединения, ошибки приема или отправки сообщений, например с некорректным форматом или ошибки конвертации, связанные с кодовой страницей. Одним словом, все события, связанные с обеспечением деятельности всех менеджеров очередей, созданных на данном компьютере. Расположение этих файлов задается при первоначальной установке WebSphere MQ. Например, для платформы Windows по умолчанию они расположены в каталоге C:\Program Files\IBM\WebSphere MQ\Errors и имеют название amqerrXX.LOG, где ХХ – номер файла. Второй тип файлов имеет специальный формат и представляет собой журнал изменений свойств объектов. Кроме этого в него записываются все persistent сообщения, обработанные менеджером очередей. Для каждого локального менеджера создаются свои файлы. Например, для менеджера очередей QM_Win2000 на платформе Windows они расположены в C:\Program Files\IBM\WebSphere MQ\log\QM_Win2000\active\ и имеют имя s000000X.log, где X – номер файла. Напомним, что существует два вида логирования сообщений и изменений свойств объектов – линейный и круговой. Линейный вид логирования, в отличие от кругового, позволяет как записывать, так и восстанавливать состояние менеджера в определенный момент времени. Запись образа объектов менеджера производится с помощью команды rcdmqobj . Синтаксис команды имеет вид:

    rcdmqobj -m QmgrName -t ObjectType
  GenericObjName

    где:

    QmgrName – имя менеджера.

    ObjectType – тип объекта. Может принимать значения nl или namelist для списка кластеров, prcs или p rocess для процессов, q или queue для всех типов очередей, ql или qlocal для локальных очередей, qa или qalias для alias очередей, qr или qremote для удаленных локальных очередей, qm или qmodel для модельных очередей, qmgr для менеджера, * или all для всех объектов.

    GenericObjName – имя объекта.

    Встречаются ситуации, когда необходимо удалить файл очереди, содержащий сообщения. Это необходимо, например, при заполнении свободного пространства дисковой системы (тома), выделенной под WebSphere MQ на UNIX платформах. В этом случае WebSphere MQ сообщит, что объект данной очереди поврежден. Восстановить поврежденные как сознательно, так и в результате сбоя дисковой системы, объекты при условии линейного логирования, можно с помощью команды rcrmqobj . Синтаксис команды имеет вид:

    rcrmqobj -m QmgrName -t ObjectType
  GenericObjName

    где:

    QmgrName – имя менеджера;

    ObjectType – тип объекта;

    GenericObjName – имя объекта.

    В результате выполнения этой команды восстанавливаются не только очереди, но и persistent сообщения в очередях. Это возможно благодаря тому, что для каждого объекта менеджера ведется запись изменений его состояния, и так называемые точки checkpoint . Команда rcrmqobj повторяет все события, которые были с поврежденным объектом от последнего checkpoint до конца лог файла. Поскольку not persistent сообщения в файл не записываются, то они и не восстанавливаются.

    При использовании кругового логирования поврежденные объекты следует удалить, а затем создать заново.

    Кроме технических ошибок бывают еще и логические ошибки, связанные с неправильными настройками объектов. Если в локальной удаленной очереди указано неверное имя удаленного менеджера или очереди назначения, то сообщения все равно будут доставлены на менеджер, расположенный по адресу, указанному в канале отправителе, который использует соответствующую трансмиссионную очередь. Для обработки ошибочных или недоставленных сообщений существует специальная очередь недоставленных сообщений, которая указывается в атрибуте менеджера Dead-letter Queue в закладке Extended. Изменим пример из лекции 5, в котором при создании на менеджере QM_Win2000 локальной удаленной очереди Win2000_HPUX.RQ будет неправильно указана очередь, в которую нужно доставить сообщения:

    ALTER QREMOTE ('Win2000_HPUX.RQ') +
       XMITQ('Win2000_HPUX.TQ') +
       RNAME('Win2000_AIX.Q') +
       RQMNAME('QM_HPUX')

    Очереди назначения Win2000_AIX.Q на менеджере QM_HPUX не существует, однако сообщение все равно будет доставлено на этот менеджер в очередь DEAD_LETTER. Его можно просмотреть с помощью WebSphere MQ Explorer (рис. 7.1).

    Просмотрев свойства сообщения, в закладке Dead-Letter Header можно увидеть код ошибки 2085, который говорит о том, что в заголовке сообщения существует неизвестный объект. В поле Destination Queue можно увидеть, что очередью назначения является несуществующая очередь Win2000_AIX.Q. Из данной ситуации есть три выхода:

  • Создать очередь Win2000_AIX.Q на менеджере QM_HPUX и перенаправить сообщение из DEAD_LETTER в нее с помощью команды:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести команду:

    ACTION(RETRY)

    и нажать <Ctrl+d> (для платформы Windows <Ctrl+z> <Enter> и еще раз <Ctrl+z> <Enter> ) и выйти из команды runmqdlq нажав <Ctrl+c>. В результате выполнения данной команды WebSphere MQ попытается заново инициировать помещение сообщения с указанными атрибутами из очереди DEAD_LETTER. Этот способ следует применять в случае переполнения существующей очереди назначения. Напомним, что если количество

    (рис 7.1) Свойства недоставленного сообщения

    сообщений в очереди превышает ее атрибут Maximum Queue Depth, то вновь поступающие сообщения также будут помещаться в очередь недоставленных сообщений.

  • Перенаправить сообщение в другую очередь, например в Win2000_HPUX.Q. В данном случае синтаксис команды runmqdlq будет выглядеть следующим образом:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести:

    ACTION(FWD) FWDQ('Win2000_HPUX.Q')
  HEADER(NO)

    и нажать Ctrl+d. Сообщения из очереди DEAD_LETTER будут помещены в очередь Win2000_HPUX.Q.

  • Удалить сообщение из DEAD_LETTER, исправить свойства локальной удаленной очереди Win2000_HPUX.RQ на менеджере QM_Win2000:

    ALTER QREMOTE ('Win2000_HPUX.RQ')
   RNAME('Win2000_HPUX.Q')

    и послать сообщение заново.

    •

    Второй способ можно использовать, когда переполнена как очередь назначения, так и очередь недоставленных сообщений. Если это не удается, то можно поступить следующим образом. Назначить в качестве очереди недоставленных сообщений новую очередь и перестартовать менеджер. Вновь поступающие сообщения будут помещаться уже в нее. Однако следует не допускать переполнения очередей недоставленных сообщений. Кроме этого, следует отметить, что простое перекладывание сообщения из очереди недоставленных сообщений в очередь назначения не даст нужного результата, поскольку недоставленные сообщения имеют свой собственный (MQDEAD) формат.

    Иногда встречается случай, когда после перезагрузки менеджера очередей пропадают сообщения из трансмиссионной (transmission) очереди, несмотря на то, что ее атрибут Default Persistence установлен в persistent. В таком случае следует проверить этот атрибут в соответствующей локальной удаленной (remote) очереди и также установить его в persistent.

    Дополнительные средства администрирования

    В каждом случае при возникновении ошибок WebSphere MQ дает ее номер.

    С помощью документации , или программы WebSphere MQ Messages and Codes Helper, доступной по адресу , можно выяснить суть ошибки и исправить ее. Внешний вид программы представлен на рис.7.2.

    (рис 7.2) Внешний вид программы WebSphere MQ Messages and Codes Helper

    Кроме расшифровки кода самой ошибки, данная программа дает варианты причин, по которым могла произойти ошибка и методы устранения ее.

    Помимо вышеуказанной программы существует множество программ, облегчающих работу с объектами менеджеров очередей. Рассмотрим программу WebSphere MQ Administrator (Support Pac MO71). Программа имеет графический интерфейс и позволяет производить любые действия с объектами как локальных, так и удаленных менеджеров. Внешний вид программы представлен на рис.7.3.

    (рис 7.3) Внешний вид программы WebSphere MQ Administrator

    Добавить в список доступных менеджеров для управления новый удаленный менеджер можно, выполнив пункт меню File => Add Location. На экране появится форма, изображенная на рис.7.4.

    (рис 7.4) Форма добавления удаленного менеджера очередей

    В поле Location нужно ввести имя отображения в списке менеджеров, доступных для управления, а в поле Queue Manager - имя удаленного менеджера, выставить флажок в поле Client и нажать кнопку Configured.

    В открывшейся форме (рис.7.5) в поле Channel Name нужно ввести имя канала типа Server Connection или Client Connection (данный канал должен быть создан на удаленном менеджере), с помощью которого будет осуществляться подключение к менеджеру, IP адрес с указанием номера порта для службы listener и нажать кнопку Ok.

    (рис 7.5) Конфигурация параметров подключения к удаленному менеджеру

    После того, как форма закроется, нажать кнопку Add в предыдущей форме. Подключаемый удаленный менеджер должен отобразиться в форме, показанной на рис.7.3 под именем QM_HPUX. Рассмотрим пример, показывающий как можно оперировать с сообщениями, находящимися в очереди на этом удаленном менеджере. Допустим, нужно переложить второе сообщение из очереди Win2000_HPUX.Q в очередь TEMP.Q. Для выполнения операций просмотра, удаления или перемещения сообщений нужно выполнить следующие действия.

    Поместив курсор на менеджер QM_HPUX выполнить пункт меню Commands => Queue List.

    В открывшейся форме (рис.7.6) при нажатии на кнопку Refresh появится список очередей менеджера QM_HPUX.

    Выбрав очередь Win2000_HPUX.Q нажать кнопку Browse и в открывшейся форме (рис. 7.7) нажать Refresh.

    Поместить курсор на второе сообщение, в поле Target Queue ввести имя очереди, в которую нужно переместить сообщение (в нашем случае это TEMP.Q ) и нажать кнопку Move. После этого второе сообщение будет перемещено в очередь TEMP.Q. Соответственно для копирования сообщения нужно нажать на кнопку Copy, для удаления – Delete. Кроме этого, данная программа в отличие от Message Browser утилиты WebSphere MQ, позволяет просматривать до 10000 сообщений, причем на экран можно вывести полный текст сообщения с помощью кнопки Open, а с помощью кнопки Detail свойства сообщения. Вставить сообщение между другими сообщениями в очереди нельзя.

    (рис 7.6) Список очередей менеджера QM_HPUX(рис 7.7) Список сообщений очереди Win2000_HPUX.Q

    Для этого следует переместить все сообщения после требуемого в другую очередь, затем поместить нужное сообщение и вернуть все перемещенные обратно. Несомненным преимуществом программы является возможность удаления сообщений даже если очередь эксклюзивно открыта другим приложением. Отображение списка объектов в данной программе статично, то есть для получения списка объектов в данный момент времени следует нажимать кнопку Refresh. Последняя версия программы доступна по адресу: .

    Существуют программы, позволяющие перемещать текст сообщения в файл и наоборот, текст, содержащийся в файле помещать в тело сообщения. Примером такой программы может служить программа rfhutil, являющаяся частью Support Pac IH03 (IBM WebSphere Business Integration Message Broker display, test and performance utilities). Программа доступна по адресу: .

    Внешний вид программы представлен на рис.7.8. Данная программа может быть полезна в случае, когда надо исправить текст внутри сообщения, находящегося в очереди. Для этого можно переместить текст сообщения в файл, исправить его, а затем положить обратно в очередь. Следует учесть, что данная программа при считывании сообщения удаляет его из очереди. Поэтому, во избежание потери текста сообщения, желательно скопировать его в какую-нибудь промежуточную очередь с помощью программы WebSphere MQ Administrator ( mqmonntp ) и оперировать с ним.

    (рис 7.8) Внешний вид программы rfhutil

    Остановимся еще на одной важной программе saveqmgr , позволяющей записывать все объекты менеджера очередей в файл в формате команд MQSC для командного процессора runmqsc. Синтаксис команды выглядит следующим образом:

    saveqmgr  -m[-r] QmgrName –f FileName
  -h -v -s -i

    где:

    -m – создается скрипт для локального менеджера.

    -r - создается скрипт для удаленного менеджера. Для подключения к удаленному менеджеру достаточно создать трансмиссионные очереди и каналы в обе стороны.

    QmgrName – имя менеджера.

    –f FileName – имя файла, в который будет записан скрипт. По умолчанию saveqmgr.tst.

    -h – выводит справочную информацию на экран.

    -v – указывает в какой версии MQSC нужно формировать команды для создания объектов. Может принимать значения 1, 2, 5, 51, 52 или 53.

    -s – не создает команды MQSC для объектов, начинающихся на SYSTEM*.

    -i – пропускает создание команд для поврежденных объектов.

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

    Вопросы производительности

    Кроме выяснения причин ошибок передачи и их устранения, администратор WebSphere MQ должен планировать и рассчитывать схемы передачи данных от одной платформы до другой. Рассмотрим простой пример передачи сообщения, содержащего информацию из строки таблицы из одной базы данных DataBase1 в другую базу DataBase2, расположенную на другой платформе. Интерфейс передачи данных можно разбить на три части (рис. 7.9).

    (рис 7.9) Схема интерфейса передачи данных

    Первая часть – программа А, помещающая сообщения в исходящую очередь RQ1, вторая – передача сообщений от одного менеджера очередей к другому в очередь назначения Q2, третья – программа B, помещающая сообщения из очереди назначения Q2 в таблицу базы данных.

    В данной схеме нужно учитывать, что скорость разбора сообщений из очереди назначения Q2 и помещения их в DataBase2 (участок 3 ) должна быть больше скорости поступления сообщений в эту очередь. Если же сообщения генерируются в исходящую очередь из базы DataBase1 не линейно, то необходимо учитывать характер нелинейности и возможные "узкие" места интерфейса. В любом случае не следует допускать переполнения очередей.

    Часто встречаются задачи, в которых требуется при изменении информации в одной системе передать произошедшие изменения в другие системы, причем формат изменяемых данных на разных платформах может иметь различный вид. При этом обработку информации целесообразно сосредоточить в одном месте, так как алгоритмы преобразования данных из DataBase1 в DataBase2, DataBase3 и т.д. очень похожи и имеют много общего, а часто являются подмножествами друг друга. В этом случае мы имеем интерфейс передачи данных с централизованной обработкой сообщений, схема которого показана на рис.7.10.

    (рис 7.10) Схема интерфейса с централизованной обработкой сообщений

    В качестве инструментального средства для центра обработки сообщений рекомендуется Брокер сообщений WebSphere BI Message Broker. Это достаточно эффективный инструмент, являющийся интегрированной средой для визуального проектирования программ обработки сообщений. При проектировании более сложных, разветвленных потоков передачи и распространения информации, которая на пути от источника к приемнику может меняться и дополняться, следует также учитывать производительность всех точек входа и выхода сообщений и соизмерять скорости выгрузки сообщений со скоростью их передачи и обработки.

    Приведем еще несколько приемов настройки и тестирования интерфейсов.

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

    Потребность в этом приеме может возникнуть когда необходимо посылать "пачки" сообщений, например, с QM_AS400 на QM_HPUX. Доступ к запуску приложений на AS400 временно закрыт. Но WebSphere MQ работает. Самое простое решение (рис.7.11) с сервера WindowsNT направляем необходимую "пачку" сообщений на AS400 в локальную удаленную очередь (remote queue), нацеленную на HP_UNIX. Этот же прием может использоваться, если доступ к менеджеру QM_HPUX открыт только с определенного IP адреса.

    (рис 7.11) Перенаправление потоков

    "Вечный двигатель"

    Этот прием весьма полезен при тестировании интерфейсов для проверки стабильности и надежности работы программ. Схема "вечного двигателя" изображена на рис. 7.12. В очереди Remote Queue rq1 на сервере WindowsNT в качестве параметра Remote Queue Name указывается rq2, а на сервере HP_UNIX в очереди Remote Queue rq2 соответственно rq1.

    (рис 7.12) "Вечный двигатель"

    И еще один прием, точнее святая обязанность администратора WebSphere MQ, это документирование интерфейсов. Весьма удобно иметь документированные интерфейсы в графическом виде, и программных средств для этого более чем достаточно (Visio, Bpwin и т.д.). Но по мере сложности интерфейсов их графическое представление становится не наглядным. В этом случае может быть рекомендован Excel, с помощью которого в колонках таблиц прописываются параметры настройки интерфейсов.

    По мере возрастания количества интерфейсов, менеджеров и их объектов может возникнуть ситуация, когда администратор WebSphere MQ по названию объекта не сможет определить его сущность. Во избежание этого рекомендуется с самого начала разработать некоторые правила, по которым следует называть все объекты на разных менеджерах. Например, если простые локальные очереди (local queue) будут оканчиваться на .Q, трансмиссионные (transmission queue) на .TQ, локальные удаленные (remote queue) на .RQ, каналы на .CH, процессы на .P и так далее, то по окончанию сразу можно определить тип объекта. То же касается направления передачи и сущности передаваемых сообщений. Например, надо передать курсы валют из системы ABS1 в систему ABS2.

    Создаваемые объекты в системе ABS1 можно назвать:

    ABS1_ ABS2_CV.RQ – локальная удаленная очередь;

    ABS1_ ABS2_CV.TQ – локальная трансмиссионная очередь;

    ABS1_ ABS2_CV.CH – канал отправитель.

    В системе ABS2:

    ABS1_ ABS2_CV.Q – локальная очередь;

    ABS1_ ABS2_CV.CH – канал получатель.

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

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

    В первой группе решающую роль играет собственно, сетевое оборудование и качество линий связи. Скорость передачи данных от менеджера до менеджера сопоставима со скоростью передачи данных в сети. Ко второй группе можно отнести следующие факторы.

    Серверное оборудование – чем мощнее сервера, тем быстрее будет работать программное обеспечение.

    Размеры баз данных – чем больше база, тем дольше выполняются запросы.

    Алгоритмы обработки сообщений – если требуется просто вставить запись в таблицу, то это может быть относительно высокая скорость, а если требуется выполнение операторов SELECT и проверка условий, на основе которых принимается решение о добавлении или изменении записи, то скорость обработки сообщений уменьшается.

    Программное обеспечение – корректно написанная программа работает быстрее, к тому же выбор языка программирования играет важную роль. Замечено, что один и тот же алгоритм, реализованный на C и Visual Basic, дает существенно разные результаты. Например, простое перекладывание persistent сообщений размером 1Кб из очереди в очередь на одном и том же менеджере (NT платформа, процессор Pentium IV с тактовой частотой 1.8 ГГц) с помощью программы, написанной на С, дает результат 400 сообщений в секунду, а с помощью программы на Visual Basic только 140.

    Тип хранения сообщений в очереди – сообщения persistent обрабатываются медленнее, чем not persistent. Not persistent сообщения из предыдущего примера перекладывались со скоростями 1000 и 200 сообщений в секунду, соответственно.

    Наличие механизмов шифрования и сертификации также влияет на скорость обработки сообщений. Так использование SSL механизма может отнять до 10% производительности в зависимости от длины ключа и алгоритма шифрования данных.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^