Почему мой кластер не поддерживает CLWLPRTY?

Question

У меня есть следующие настройки:

• Четыре диспетчера очереди MQ в кластере (QM1 (полное репо), QM2 (полное репо), QM3 (частичное репо),QM4 (частичное репо))
• Все каналы отправителя / получателя кластера имеют одинаковый ранг и приоритет
• каждый администратор очередей имеет некластеризованную очередь псевдонимов (ALIAS.TO.CLQ)
• ALIAS.TO.CLQ имеет базовый объект ALIAS.TO.FLOW, который является кластеризованной очередью псевдонимов
• ALIAS.TO.FLOW имеет базовый объект L.TO.FLOW, который является локальной очередью.
• Каждый из четырех администраторов очередей настроен как CLWLUSEQ(ANY).
• Кластерные очереди псевдонимов имеют DEFBIND из NOT FIXED.Сообщения пишутся с помощью IIB (MQ Output Node), что, я считаю, учитывает это - хотя я наблюдаю то же поведение при использовании MQ Explorer или RFHUtil.
• Сообщения помещаются MQ Output Node без указания диспетчера очереди.name
• Каждая из четырех очередей псевдонимов кластера имеет разные CLWLPRTY, но одинаковые CLWLRANK.

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

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

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

Что здесь происходит, и как я могу заставить его всегда соблюдать приоритет независимо от того, куда помещено сообщение?Я просмотрел страницу «Алгоритм управления рабочей нагрузкой кластера» в документации IBM (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.con.doc/q082390_.html), но не могу понять, в чем проблема.

- Обновление -

Я попытался создать новый набор очередей в том же формате, но только на одном из администраторов очередей кластера - так, ALIAS.TEST -> AL.TEST (кластер, но существует только один экземпляр) -> L.TEST. Когда я задаю ALIAS.TEST, я получаю сообщение об ошибке:

Был выполнен вызов MQOPEN или MQPUT1, указав очередь псевдонимов в качестве цели, но BaseObjectName в определении очереди псевдонимов разрешаетсяв очередь, которая не является локальной или локальным определением удаленной очереди. (AMQ4480) Был выполнен вызов MQOPEN или MQPUT1, в котором в качестве цели указана очередь псевдонимов, но BaseObjectName в определении очереди псевдонимов преобразуется в очередь, котораяне является локальной очередью или локальным определением удаленной очереди. (AMQ4480)

Уровень серьезности: 20 (ошибка)

Ответ: Исправьте определения очереди.

Но я могу поставить тo AL.TEST очередь без проблем.

- Правка -

OK, ответ на вопрос, почему это происходит, появляется здесь: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003120_.html

Псевдоним не может быть напрямую преобразован в другой псевдоним в том же администраторе очередей.

Итак, как мне получить требуемое поведение?

Answer 1

На основе следующего потока, в котором каждый экземпляр IIB помещается в локальный администратор очередей:

IIB1 -> QM1 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(4) CLWLUSEQ(ANY)
IIB2 -> QM2 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(3) CLWLUSEQ(ANY)
IIB3 -> QM3 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(2) CLWLUSEQ(ANY)
IIB4 -> QM4 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(1) CLWLUSEQ(ANY)

* Предполагается, что CLWLRANK, CLWLPRTY и NETPRTY на всех CLUSRCVR каналаходинаково для всех четырех администраторов очередей.

Сообщения PUT любого из четырех экземпляров IIB всегда будут поступать в доступную очередь с наибольшим значением CLWLPRTY.

Экземпляр очереди может бытьнедоступен с точки зрения алгоритма управления рабочей нагрузкой кластера по ряду причин.Я ссылался на Центр знаний в конце этого поста, в котором содержалось подробное объяснение алгоритма.Две общие причины:

1. Менеджер очереди не работает

2. Очередь PUT(DISABLED)

---

Каждый экземпляр IIB будет только GET из локальной очереди того же администратора очередей, к которому подключен также экземпляр IIB.В приведенной выше настройке это означало бы, что при нормальных условиях, если все четыре администратора очередей работают, только сообщения IIB, подключенные к QM1, будут получать сообщения.

---

Что может сделатьэкземпляр недоступной очереди находится на странице центра знаний IBM MQ v9.0 " Справочник> Справочник по конфигурации> Команды кластера IBM MQ> Балансировка рабочей нагрузки в кластерах> Алгоритм управления рабочей нагрузкой кластера ", я предоставилте, которые могут применяться к настройке, описанной в вашем вопросе:

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

1. Если указано имя очереди или темы:

   a.Очереди, которые не включены, исключаются как возможные пункты назначения.

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

• Для локально определенных очередей, которые определены с помощью CLWLUSEQ (ANY) или которые наследуют эту же настройку отадминистратор очереди, следующие пункты верны, в рамках более широкого набора условий:

  a.Локальная очередь выбирается в зависимости от состояния локально определенных каналов CLUSRCVR в том же кластере, что и очередь.Это состояние сравнивается с состоянием каналов CLUSSDR, которые отправляют сообщение в удаленно определенные очереди с одинаковыми именами.

  Например, в одном кластере, в котором находится очередь, есть один CLUSRCVR.Этот CLUSRCVR имеет статус STOPPING, тогда как другие очереди с таким же именем в кластере имеют статус RUNNING или INACTIVE.

  В этом случае будут выбраны удаленные каналы, а локальная очередь не используется.

  b.Локальная очередь выбирается в зависимости от количества каналов CLUSRCVR при любом сравнении с каналами CLUSSDR с одинаковым статусом, которые доставляют сообщение в удаленно определенные очереди с одинаковым именем.

  Например, существует четыреКаналы CLUSRCVR в том же кластере, что и очередь, и один канал CLUSSDR.Все каналы имеют одинаковое состояние либо НЕАКТИВНО, либо ВЫПОЛНЕНО.

  Поэтому существует пять каналов на выбор и два экземпляра очереди.Четыре пятых (80 процентов) сообщений отправляются в локальную очередь.

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

Если более одного удаленного экземпляра очереди илитема остается, все каналы, которые неактивны или работают, включены.Перечислены константы состояния:

• MQCHS_INACTIVE

• MQCHS_RUNNING

Если не осталось удаленного экземпляра очереди или темы, включаются все каналы, которые находятся в состоянии привязки, инициализации, запуска или остановки.Перечислены константы состояния:

• MQCHS_BINDING

• MQCHS_INITIALIZING

• MQCHS_STARTING

• MQCHS_STOPPING

Если не осталось удаленного экземпляра очереди или темы, все каналы, которые используютсяпопробовал еще раз включены.Константа состояния указана:

• MQCHS_RETRYING

Если не осталось удаленного экземпляра очереди или темы, все каналы в запросе приостановленыили остановленное состояние включены.Перечислены константы состояния:

• MQCHS_REQUESTING

• MQCHS_PAUSED

• MQCHS_STOPPED