Опубликован: 10.06.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Компания IBM
Лекция 10:

Построение инфраструктуры WebSphere MQ: практическое руководство

10.3.13. Определение очереди ответов для периферийного менеджера очередей

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

Ниже рассказывается, как создать модельную очередь для динамической генерации очереди ответов при поступлении запросов. Для этого применяют WebSphere MQ Explorer и команды MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

  1. Щелкните правой кнопкой папку Queues для host2/spoke и выберите New\Model Queue.
  2. Введите echo.replies в поле Name.
  3. Щелкните Finish.
Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей host2/spoke:

DEFINE QMODEL('echo.replies')

10.3.14. Запрос службы echo с периферийного менеджера очередей

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

Примечание Здесь предполагается, что менеджер очередей host1/echo.hub по-прежнему настроен для предоставления доступа к работающей в нем службе. Также важно наличие у очереди инициации echo.initq активного триггерного монитора. Желательно также, чтобы службу могли запрашивать и локальные приложения, подключенные к менеджеру host1/echo.hub (см. "Обмен сообщениями с использованием WebSphere MQ: практическое введение" ).
  1. Выполните следующую команду WebSphere MQ:
    amqsreq echo host2/spoke echo.replies
    Эта команда содержит следующие параметры:
    • echo – имя очереди, разрешаемое локальным менеджером очередей. Благодаря наличию локального определения удаленной очереди сообщения, адресованные echo, маршрутизируются менеджеру host1/echo.hub через транспортную очередь и пару открытых каналов (sender- и receiver-каналы);
    • host2/spoke – имя локального периферийного менеджера очередей, к которому подключается приложение;
    • echo.replies – имя модельной очереди, открытой для динамического создания очереди ответов для приложения.
    Примечание В команде amqsreq не указано имя менеджера очередей host1/echo.hub, предоставляющего доступ к службе. Инфраструктура сконфигурирована для автоматической маршрутизации запросов, осуществляемой незаметно для запрашивающего приложения.
  2. Введите сообщение и нажмите Enter.
  3. Не вводя сообщения, нажмите Enter.
  4. Подождите 10 секунд.
  5. Если все прошло нормально, вывод команды будет содержать введенное ранее сообщение:
    response <текст_тестового_сообщения>
Примечание Если вы столкнетесь с трудностями, обратитесь к "Обмен сообщениями с использованием WebSphere MQ: практическое введение" .

10.4. Создание кластеров менеджеров очередей

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

В этом разделе рассказывается о том, как применение кластеров позволяет снизить нагрузку на администраторов по добавлению менеджеров очередей к инфраструктуре WebSphere MQ. Это возможно благодаря тому, что каждый менеджер очередей в составе кластера автоматически получает сведения и объединяется каналами связи с остальными менеджерами кластера.

В этом разделе используется кластер-пример с именем example.cluster.

10.4.1. Создание менеджеров очередей

Создайте четыре менеджера с активными слушателями.

Имена менеджеров очередей отражают их роли в составе кластера (см. табл. 10.1, в которой перечислены имена менеджеров очередей и порты, к которым привязаны их слушатели).

Таблица 10.1. Менеджеры очередей в составе кластера example.cluster
Имя Хост-имя Порт слушателя Репозиторий Имя канала
host1/full host1.example.com 9031 Полный clus.host1/full
host1/partial host1.example.com 9032 Частичный clus.host1/partial
host2/full host2.example.com 9033 Полный clus.host2/full
host2/partial host2.example.com 9034 Частичный clus.host2/partial

Два из этих менеджеров обслуживают полные репозитории для кластера, которые содержат всю информацию о кластере, а остальные два – частичные, содержащие лишь необходимые им сведения.

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

Примечание Мы не рекомендуем использовать имя localhost или IP-адрес 127.0.0.1 в рабочих кластерах. Впрочем, для данного примера это имя и адрес подходят, если все менеджеры очередей работают на одном компьютере.

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

10.4.2. Назначение менеджеров очередей с полными репозиториями

Эти действия выполняются в отношении менеджеров очередей host1/full и host2/full.

Данные менеджеры очередей будут настроены так, что в них будут полные репозитории для кластера example.cluster.

Эти действия выполняются с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

  1. Щелкните правой кнопкой значок менеджера очередей в окне навигатора и выберите Properties.
  2. Перейдите в секцию Repository окна свойств менеджера очередей.
  3. Выберите Full repository for a cluster.
  4. Введите example.cluster в поле, которое станет доступным.
  5. Щелкните OK.
Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей:

ALTER QMGR REPOS('example.cluster')
Михаил Завалко
Михаил Завалко
Беларусь, Минск
Artem Bardakov
Artem Bardakov
Россия