В 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 и выходят / входят во внешнюю базу клиентов, И иметь внутренний агент / серверы в назначенном анклаве. администраторы очередей для внутреннего обмена файлами.
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
Похожие вопросы
Новые вопросы
websphere-mq-fte
Управляемая передача файлов WebSphere MQ (WMQ MFT) - это продукт управляемой передачи файлов от IBM. WMQ MFT передает файлы между системами управляемым и проверяемым способом. Нет ограничений на размер файла для передачи и поддерживается на нескольких платформах. Это продукт, построенный на основе WebSphere MQ и, следовательно, наследующий надежность и безопасность, обеспечиваемые WebSphere MQ. Ранее продукт назывался WebSphere MQ File Transfer Edition (FTE).