Как подключить администраторы очередей для распределенной публикации / подписки WebSphere MQ 7.0 - PullRequest
Новая
       14

Как подключить администраторы очередей для распределенной публикации / подписки WebSphere MQ 7.0

1 голос
/ 19 марта 2012

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

У меня есть два (IBM i) сервера, каждый с одним менеджером очередей WMQ 7.0. У меня есть два канала между ними - по одному в каждом направлении.

У меня есть тема, определенная на «сервере А» с областями публикации и подписки «Все» и поведением подписки прокси-сервера «Force».

У меня есть подписка, определенная на "сервере B" с областью действия "Все".

Все работает и работает, но когда я помещаю сообщение в тему на сервере A (с помощью MQ Explorer), на сервере B ничего не появляется.

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

Любая помощь приветствуется. Я зашел так далеко (раньше никогда не использовал паб / саб) только для того, чтобы преодолеть это препятствие.

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

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

Предполагая, что администратор очередей на A является родительским, а администратор очередей на B - дочерним, вы должны выполнить «ALTER QMGR PARENT ()» в приглашении RUNMQSC администратора очередей на B. Это создаст иерархию между двумя администраторами очередей. Как только подписка создается в администраторе очередей на B, прокси-подписка автоматически перенаправляется на администратор очередей на A. Предполагая, что администратор очередей на A является родительским, а администратор очередей на B - дочерним, вы должны выполнить «ALTER QMGR PARENT ()» в приглашение RUNMQSC администратора очередей на B. Это создаст иерархию между двумя администраторами очередей. Как только подписка создается в администраторе очередей на B, прокси-подписка автоматически перенаправляется на администратор очередей на A.

РЕДАКТИРОВАТЬ: более подробно о моей конфигурации (с чуть более значимыми - для меня - имена серверов)

На сервере A7: 

Queue manager A7.QUEUE.MANAGER 
Sender channel A7.TO.A2 with transmission queue A7.TO.A2 
Alias queue A2.QUEUE.MANAGER pointing to A7.TO.A2 
Receiver channel A2.TO.A7

На сервере A2: 

Queue manager A2.QUEUE.MANAGER 
Sender channel A2.TO.A7 with transmission queue A2.TO.A7 
Alias queue A7.QUEUE.MANAGER pointing to A2.TO.A7 
Receiver channel A7.TO.A2 
I then issued ALTER QMGR PARENT('A7.QUEUE.MANAGER')

У меня есть тема на A7 и после выпуска ALTER (выше) я добавил подписку на A2 в тему. 

display pubsub type(ALL)                               
3 : display pubsub type(ALL)                      
AMQ8723: Display pub/sub status details.               
QMNAME(A2.QUEUE.MANAGER) TYPE(LOCAL) 

display pubsub type(ALL)                               
1 : display pubsub type(ALL)                      
AMQ8723: Display pub/sub status details.               
QMNAME(A7.QUEUE.MANAGER) TYPE(LOCAL)

Ответы [ 2 ]

3 голосов
/ 19 марта 2012

Сгруппируйте два QMgrs и объявите тему в кластере.Затем WMQ сделает публикации доступными по всему кластеру.

В QMGR01 

# Make the QMgr a cluster repository
ALTER QMGR REPOS('CLUSTERNAME')

# Create CLUSRCVR and advertise to cluster
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR01) CHLTYPE(CLUSRCVR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1414)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

# Create topic object and advertise to cluster
DEF TOPIC('ROOT') TOPICSTR('ROOT') CLUSTER('CLUSTERNAME') REPLACE

В QMGR02 

# Always create CLUSRCVR first and advertise to cluster
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR02) CHLTYPE(CLUSRCVR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1415)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

# Then conecct to the repos and advertise the CLUSSDR to the cluster too
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR01) CHLTYPE(CLUSSDR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1414)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

Теперь вы можете опубликовать в теме, которая была объявлена ​​в кластере:

В QMgr01 

amqspub ROOT/Whatever QMGR01

В QMgr02 

amqssub ROOT/Whatever QMGR02

Вам не нужно называть свойобъект ROOT или использовать его как верхнюю часть пространства имен темы.Это был произвольный пример, и вы можете использовать все, что захотите.В Production у вас, вероятно, есть несколько тематических объектов на 2-м или 3-м уровне иерархии тем, из которых можно повесить списки контроля доступа.Обычно именно эти объекты используются для объявления тем в кластере.

Некоторые дополнительные примечания:

  • Вы не можете рекламировать SYSTEM.BASE.TOPIC или SYSTEM.DEFAULT.TOPIC в кластере.
  • Кластерная тема должна быть определена только на одном узле в кластере.Это может быть любой узел, но рекомендуется размещать его в основном полном хранилище.Таким образом, вы узнаете, где все ваши кластерные тематические объекты определены в одном месте, и хранилище является (или должно быть) высокодоступным.
  • Если существуют локальные и кластерные тематические объекты, которые перекрываются, локальный имеет приоритет.

См. Создание новой темы кластера для получения дополнительной информации.Кроме того, Создание и настройка кластера администратора очередей имеет задачи по созданию кластера и добавлению в него QMgrs.Тем не менее, я протестировал с вышеупомянутым на моем хосте Windows, и в этом минимальном кластере pub / sub работал отлично.

2 голосов
/ 19 марта 2012

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

Предполагая, что администратор очередей на A является родительским, а администратор очередей на B - дочерним, вы должны выполнить «ALTER QMGR PARENT ()» в приглашении RUNMQSC администратора очередей на B. Это создаст иерархию между двумя администраторами очередей. Как только подписка создается в администраторе очередей на B, прокси-подписка автоматически перенаправляется на администратор очередей на A.

...