В QMGR A есть агент MFT под названием AgentA. В QMGR B есть агент MFT под названием AgentB. В QMGR C есть агент MFT под названием AgentC. Это все развертывания сервера MFT, а не «клиент».

QMGR A и B являются членами кластера MQ, который называется FTECluster.

QMGR C подключается к QMGR B через простую пару отправитель / получатель (вне кластера).

Пользователи MFT на сервере, на котором выполняется QMGR A, хотят отправить файл С этого сервера на сервер, на котором выполняется QMGR C.

QMGR B - это назначенный Qmgr координации, поэтому, если при подключении к нему через проводник я создаю передачу, используя

QMGRA в качестве источника и QMGRC в качестве назначения, всегда ли я буду ожидать, что агент столкнется с ошибкой 2087 (это то, что я получаю), что целевая удаленная очередь неизвестна? Или есть какие-то «лишние» настройки, чем нужно, чтобы познакомить QMGRA с QMGRC посредством QMGRB?

Приложение таково: у меня есть администраторы очередей на основе анклава (QMGRA), которые находятся за DMZ (шлюз, QMGR B), и я хотел бы переместить файлы для внешних партнеров тем, кто находится внутри / вне анклава через MFT, в отличие от того, что мы используем очереди для перемещения сообщений из перекрывающихся кластеров или из диспетчеров очередей в / из кластера в сообщения из / в соседний кластер. ИЛИ, чтобы разрешить передачу файлов МЕЖДУ пользователями MFT ВНУТРИ анклава, чтобы трафик не передавался в DMZ для внутренней передачи.

Если это невозможно, тогда нам необходимо иметь передачи MFT, которые создаются между клиентами на серверах внутреннего анклава, через серверы MFT на основе DMZ и выходят / входят во внешнюю базу клиентов, И иметь внутренний агент / серверы в назначенном анклаве. администраторы очередей для внутреннего обмена файлами.

2
John Edelmann 26 Сен 2012 в 21:09

1 ответ

Лучший ответ

Агенты FTE могут использовать стандартную маршрутизацию и псевдонимы QMgr. Учебный способ сделать это - назвать очереди передачи после QMgr назначения и добавить псевдонимы. Например, в QMGRA вы должны определить:

* On QMGRA
DEFINE QL(QMGRB) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRB) RQMNAME('') RNAME('')

Теперь любые сообщения, адресованные QMGRC, проходят обычное разрешение имен. QMgr находит маршрут к QMGRC через QMGRB из-за QRemote. По этой причине определение QRemote с пустым RNAME называется псевдонимом QMgr.

Тогда в QMGRB у вас будет очередь передачи, ведущая к QMGRC и по совпадению названная QMGRC. Обратное применимо для получения сообщений обратно. Вам понадобится псевдоним QMgr на C, указывающий на B.

Если в ваших очередях XMit не используется имя удаленного QMgr, вам потребуются дополнительные псевдонимы QMgr. Например, многие люди добавляют строку XMITQ к имени очереди XMit (что, на мой взгляд, вызывает больше проблем, чем решает), и в такой системе вам понадобится следующее:

* On QMGRA
DEFINE QL(QMGRB.XMITQ) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRB.XMITQ) RQMNAME('') RNAME('')


* On QMGRB
DEFINE QL(QMGRC.XMITQ) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRC.XMITQ) RQMNAME('') RNAME('')

Первая часть работает так же, как и раньше. WMQ ищет QMGRC, находит QRemote и помещает сообщение в названный XMitQ. Но когда сообщение поступает в QMGRB, оно не может разрешиться напрямую в очередь передачи, потому что имя не соответствует удаленному QMgr. Итак, мы определяем новый QRemote, который преобразует имя QMGRC в XMitQ, ведущее к QMGRC.

Вы также можете использовать разрешение кластера между QMGRA и QMGRB. В этом случае вам, вероятно, удастся установить RQMNAME и оставить поле XMitQ пустым в псевдониме QMgr на A. Или установите оба параметра. Другой вариант - создать псевдоним QMgr с именем QMGRC на B и объявить его кластеру.

Использование выделенного канала удерживает трафик передачи файлов вне кластера XMitQ и из канала кластера и, таким образом, обеспечивает класс изоляции сервиса от обычного трафика. Тем не менее, трафик передачи файлов является непостоянным, и на XMitQ за один раз будет загружаться не более одного кадра на файл, поэтому вам может не понадобиться этот уровень изоляции. (С WMQ V7.5 можно было бы сделать то же самое с перекрывающимся кластером и разделенным кластером XMitQ!)

Для проверки вам не нужны агенты FTE, просто используйте программу Q из SupportPac MA01 и укажите локальный QMgr и имя удаленного QMgr при подключении.

ОБНОВЛЕНИЕ из цепочки писем:
Хорошо, вот определения, которые я использовал, чтобы смоделировать это с помощью кластерного сценария. Я определил 3 QMgrs, создал кластер с QMGRA в качестве репозитория, QMGRB в качестве члена и шлюз между QMGRB и C с использованием каналов SDR / RCVR. Любые сообщения, поступающие на B от A, адресованные C, разрешаются в XMitQ. A знает о C из-за псевдонима QMgr с именем QMGRC, указывающего на QMGRC.XMITQ. (Я попытался объявить кластеру XMitQ под названием QMGRC, но похоже, что кластер распознает его как локальную очередь и не выполняет для него разрешение имени QMgr. Определение его как QMGRC.XMITQ и создание псевдонима QMGRC QMgr над ним позволяет QMGRC разрешить локально и из кластера.)

После их запуска я смог подключиться с помощью программы Q без преимуществ определений QREMOTE, которые указывают RNAME, и отправлять сообщения от C к A и от A к C в очереди с именем TEST.NAME.RESOLUTION следующим образом:

C:\Users\T.Rob>q -m QMGRA -oQMGRC/TEST.NAME.RESOLUTION
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May  1 2012 ]
Connecting ...connected to 'QMGRA'.
>Testing A to C
>^C
C:\Users\T.Rob>q -m QMGRC -oQMGRA/TEST.NAME.RESOLUTION
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May  1 2012 ]
Connecting ...connected to 'QMGRC'.
>Testing C to A
>^C

Да, имя кластера - «EDELMANN», и в этом смысле оно произносится так же, как Джерри Сайнфельд произносил «Ньюман». ;-)

* On QMGRA:
ALTER QMGR +
   REPOS(EDELMANN)

DEFINE QLOCAL('TEST.NAME.RESOLUTION') +
   DEFPSIST(YES) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRA') +
   CHLTYPE(CLUSRCVR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3414)') +
   TRPTYPE(TCP) +
   REPLACE


* On QMGRB:
DEFINE QREMOTE('QMGRC') +
   CLUSTER('EDELMANN') +
   RQMNAME('QMGRC') +
   XMITQ('QMGRC.XMITQ') +
   REPLACE

DEFINE QLOCAL('QMGRC.XMITQ') +
   INITQ('SYSTEM.CHANNEL.INITQ') +
   TRIGGER +
   TRIGDATA('QMGRB.QMGRC') +
   USAGE(XMITQ) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRA') +
   CHLTYPE(CLUSSDR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3414)') +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRB') +
   CHLTYPE(CLUSRCVR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3415)') +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('QMGRB.QMGRC') +
   CHLTYPE(SDR) +
   CONNAME('localhost(3416)') +
   TRPTYPE(TCP) +
   XMITQ('QMGRC.XMITQ') +
   REPLACE

DEFINE CHANNEL('QMGRC.QMGRB') +
   CHLTYPE(RCVR) +
   TRPTYPE(TCP) +
   REPLACE

* On QMGRC:
DEFINE QREMOTE('QMGRA') +
   RQMNAME('QMGRA') +
   XMITQ('QMGRB') +
   REPLACE

DEFINE QLOCAL('QMGRB') +
   INITQ('SYSTEM.CHANNEL.INITQ') +
   TRIGGER +
   TRIGDATA('QMGRC.QMGRB') +
   USAGE(XMITQ) +
   REPLACE

DEFINE QLOCAL('TEST.NAME.RESOLUTION') +
   REPLACE

   DEFINE CHANNEL('QMGRB.QMGRC') +
   CHLTYPE(RCVR) +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('QMGRC.QMGRB') +
   CHLTYPE(SDR) +
   CONNAME('localhost(3415)') +
   TRPTYPE(TCP) +
   XMITQ('QMGRB') +
   REPLACE
2
T.Rob 27 Сен 2012 в 23:10
Однако, если A и B находятся в кластере MQ, я предполагаю, что xmitq QMGR2 не нужно определять в QMGRA правильно? Я не хочу использовать xmitq и канал отправителя триггера от A до B ...
 – 
John Edelmann
27 Сен 2012 в 16:30
Да, вы можете использовать разрешение кластера. В этом случае вам, вероятно, удастся установить RQMNAME и оставить поле XMitQ пустым. Или установите оба. Использование выделенного канала удерживает трафик XFer файла вне кластера XMitQ и из канала кластера и, таким образом, обеспечивает класс изоляции сервиса от обычного трафика. Файловый трафик XFer является непостоянным, и на XMitQ за один раз будет помещаться не более одного кадра на файл, поэтому вам может не понадобиться такой уровень изоляции. (С WMQ V7.5 можно было бы сделать то же самое с перекрывающимся кластером и разделенным кластером XMitQ!)
 – 
T.Rob
27 Сен 2012 в 16:53
На самом деле это настройка администратора очередей для FTE, чтобы он был полностью изолирован от нашего обычного трафика MQ, хотя Лен МакВильямс заверил меня, что FTE предназначен для работы с неинвазивным более низким приоритетом. ТАКЖЕ: не понадобится ли qmgrc аналогичное удаленное определение НАЗАД к QMGRA?
 – 
John Edelmann
27 Сен 2012 в 17:22
Честно говоря, я сказал: «Обратное применимо для получения сообщений обратно», но я обновил ответ, чтобы уточнить. Также перенесена информация о кластере в ответ для тех, кто не читает комментарии.
 – 
T.Rob
27 Сен 2012 в 17:30
Действительно, вы это сделали. Я пропустил это в своем рьяном волнении, чтобы заставить это работать. Однако я должен подать прошение о применении этого определения к queumgr на удаленной стороне. Благодарность!
 – 
John Edelmann
27 Сен 2012 в 17:36