Краткий ответ
- Кластеризация MQ - это , а не , используемая для приложения-потребителя для поиска очереди на получение сообщений GET.
- Кластеризация MQ - это используется, когда приложение-поставщик помещает сообщения, чтобы направить их к месту назначения.
Дальнейшее чтение
Кластеризация используется при отправке сообщений, чтобы помочь обеспечить балансировку нагрузкии несколько экземпляров кластеризованной очереди.В некоторых случаях люди используют это для горячего / холодного переключения при сбое, имея два экземпляра очереди и сохраняя только один PUT(ENABLED).
Если приложение является производителем, который помещает сообщения в кластерную очередь, оно толькодолжен быть подключен к администратору очередей в кластере и иметь разрешения для помещения в эту кластерную очередь.MQ, основанный на множестве разных вещей, будет определять, куда отправлять это сообщение.
До v7.1 было только два способа предоставления доступа к удаленным кластеризованным очередям:
Использование QALIAS:
Определение локального QALIAS, для которого TARGET задано имя кластерной очереди
Обратите внимание на этоQALIAS само по себе не нужно кластеризовать.
- Предоставить разрешение на локальный
QALIAS.
- Предоставить разрешения для PUTна
SYSTEM.CLUSTER.TRANSMIT.QUEUE.
Первый вариант позволяет предоставить гранулярный доступ к приложению для определенных кластеризованных очередей в кластере.Второй вариант позволяет приложению помещать в любую кластеризованную очередь в кластере.
В версии 7.1 IBM добавила новое необязательное поведение, это было предоставлено с параметром ClusterQueueAccessControl=RQMName в разделе Security в qm.ini.Если это включено (это не значение по умолчанию), то вы можете фактически предоставить разрешение приложению на PUT для удаленных кластерных очередей напрямую, без необходимости локального QALIAS.
Что такое кластеризация , а не , для которой используются приложения, такие как ваш пример JMSListener.
Приложение, которое будет использовать из любого QLOCAL (кластеризованного илинет) должен быть подключен к администратору очередей, где определен QLOCAL.
Если у вас есть ситуация, когда существует несколько экземпляров кластеризованного QLOCAL, которые равны PUT(ENABLED), вам необходимо убедиться, что у вас есть потребители, подключенные напрямую к каждому администратору очередей, на котором размещен экземпляр.
На основании вашего комментария у вас есть CCDT с записью, такой как:
CHANNEL('MyCHL') CHLTYPE(CLNTCONN) QMNAME('MyQMGR') CONNAME('node1url(port1),node2url(port2)')
Если есть два разных администратора очередей с разными именами администратора очередей, которые прослушивают node1url(port1) и node2url(port2), то у вас есть разные способы сделать это со стороны приложения.
Когда вы укажете QMNAME для подключения к приложению, вы будете ожидать, что имя будет соответствовать администратору очередей, к которому вы подключаетесь, если только он не соответствует одному изследующее:
- Если вы укажете
*MyQMGR, он найдет канал или каналы с QMNAME('MyQMGR'), выберет один и подключится, и не будет принудительно указывать, что имя удаленного администратора очередей должно совпадать. - Если в вашем CCDT
QNAME('') установлено значение NULL, то в вашем приложении вы можете указать пустое имя администратора очередей или только пробел и егонайдет эту запись в CCDT и не обеспечит соответствие имени удаленного администратора очередей. - В вашем приложении вы задаете имя администратора очередей как
*, MQ будет использовать любой канал в CCDT и будетне предписывать, чтобы имя удаленного администратора очередей совпадало.
Одним из ограничений CCDT является то, что имя канала должно быть уникальным в CCDT.Даже QMNAME отличается, у вас не может быть второй записи с тем же именем канала.
Когда вы подключаетесь, вы нажимаете на запись с двумя CONNAME и подключаетесь к первой IP(port), вы попадете ко второму IP(port), только если при подключении первое недоступно, MQ попробует второе, или если вы подключены и у вас включена функция RECONNECT, а затем первый выключен, MQ попытается подключиться к первомузатем второй.
Если вы хотите, чтобы обе кластеризованные очереди PUT(ENABLED) принимали трафик, вы хотите иметь возможность специально подключаться к каждому из двух администраторов очередей для чтения этих очередей.
Я бы предложил добавитьновый канал в каждом администраторе очередей, который имеет другое конкретное имя QM, которое также отличается от существующего имени, примерно так:
CHANNEL('MyCHL1') CHLTYPE(CLNTCONN) QMNAME('MyQMGR1') CONNAME('node1url(port1)')
CHANNEL('MyCHL2') CHLTYPE(CLNTCONN) QMNAME('MyQMGR2') CONNAME('node2url(port2)')
Это будет в дополнение к существующей записи.
Для размещения компонентов вы можете продолжать использовать канал, который может подключаться к любому администратору очередей.
Для получения компонентов вы можете настроить как минимум два из них, по одному для подключения к каждому администратору очередей с использованием новой очереди.специфичная для менеджера запись CCDT, таким образом используются обе очереди.