Как настроить IBM MQ в качестве кластера высокой доступности?

Я хочу создать кластер высокой доступности. Но я не могу найти никаких шагов для его создания из документации IBM.

Я следил за этим Руководство по созданию кластера.

Оба QM развернуты с помощью docker-compose:

version: '3.7'
services:
  london:
    build:
      context: ./config/london
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "QM1"
      MQ_ENABLE_METRICS: "true"
    ports:
      - 9443:9443 # web view
      - 9157:9157 # metrics

  newyork:
    build:
      context: ./config/newyork
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "QM2"
      MQ_ENABLE_METRICS: "true"
    ports:
      - 9553:9443 # web view
      - 9158:9157 # metrics
    depends_on:
      - london

Dockerfile для обоих образов:

FROM ibmcom/mq

COPY init.mqsc /etc/mqm/20-init.mqsc

Вот конфигурация экземпляра london MQ:

* cluster config
ALTER QMGR +
      REPOS(INVENTORY) +
      PSCLUS(ENABLED)

DEFINE LISTENER(LONDON_LS) +
       TRPTYPE(TCP) +
       CONTROL(QMGR)

DEFINE CHANNEL(INVENTORY.LONDON) +
       CHLTYPE(CLUSRCVR) +
       TRPTYPE(TCP) +
       CONNAME('london(1414)') +
       CLUSTER(INVENTORY) +
       DESCR('TCP Cluster-receiver channel for queue manager LONDON')

DEFINE CHANNEL(INVENTORY.NEWYORK) +
       CHLTYPE(CLUSSDR) +
       TRPTYPE(TCP) +
       CONNAME('newyork(1414)') +
       CLUSTER(INVENTORY) +
       DESCR('TCP Cluster-sender channel from LONDON to repository at NEWYORK')

SET CHLAUTH('INVENTORY.LONDON') +
    TYPE(QMGRMAP) +
    QMNAME(QM2) +
    USERSRC(CHANNEL) +
    ADDRESS('*')

и здесь для экземпляра newyork:

* cluster config
ALTER QMGR +
      REPOS(INVENTORY) +
      PSCLUS(ENABLED)

DEFINE LISTENER(NEWYORK_LS) +
       TRPTYPE(TCP) +
       CONTROL(QMGR)

DEFINE CHANNEL(INVENTORY.NEWYORK) +
       CHLTYPE(CLUSRCVR) +
       TRPTYPE(TCP) +
       CONNAME('newyork(1414)') +
       CLUSTER(INVENTORY) +
       DESCR('TCP Cluster-receiver channel for queue manager NEWYORK')

DEFINE CHANNEL(INVENTORY.LONDON) +
       CHLTYPE(CLUSSDR) +
       TRPTYPE(TCP) +
       CONNAME('london(1414)') +
       CLUSTER(INVENTORY) +
       DESCR('TCP Cluster-sender channel from NEWYORK to repository at LONDON')

SET CHLAUTH('INVENTORY.NEWYORK') +
    TYPE (QMGRMAP) +
    QMNAME(QM1) +
    USERSRC(CHANNEL) +
    ADDRESS('*')

Я хочу иметь тему, в которой мои приложения могут писать/читать независимо от QM, к которому они подключены. Возможно ли это вообще, и если да, не могли бы вы поделиться командами MQSC или ссылкой на пример настройки.


person max    schedule 25.05.2020    source источник
comment
Если вы создаете кластер, у вас есть кластер публикации/подписки. И теперь вы уже можете подписаться на оба менеджера очередей, чтобы читать сообщения, опубликованные на любом из них. Но вы получите два сообщения, одно из Лондона и одно из Нью-Йорка.   -  person Seyf    schedule 25.05.2020
comment
При создании темы в одном из QM эта тема используется совместно, но сообщения не передаются. Вот чего я пытаюсь добиться   -  person max    schedule 25.05.2020
comment
Ваши комментарии прояснили некоторые моменты. Спасибо за ваше время   -  person max    schedule 26.05.2020
comment
это было бы замечательно   -  person max    schedule 26.05.2020
comment
Добавил всю информацию из комментариев в ответ. Дайте мне знать, если у вас есть еще вопросы.   -  person JoshMc    schedule 28.05.2020


Ответы (1)


Кластеризация MQ связана с балансировкой нагрузки при подключении между администраторами очередей.

  • У вас может быть, например, кластеризованная очередь, определенная в LONDON и NEWYORK, она может быть PUT(ENABLED) для обеих (горячая/горячая), и сообщение, отправляемое в эту очередь членами кластера, будет проходить циклически между двумя экземплярами.
  • Если вы хотите, чтобы он был горячим/теплым, то вы должны ПОСТАВИТЬ (ОТКЛЮЧИТЬ) один из двух экземпляров, например, ЛОНДОН, затем вы направите свое приложение на подключение и чтение из NEWYORK, если NEWYORK выйдет из строя, вы можете PUT (ENABLED) очередь в ЛОНДОН, и сообщение с этого момента будет отправлено в ЛОНДОН, и вы можете направить свое приложение в ЛОНДОН (обратите внимание, что любое сообщение, которое находилось в очереди в NEWYORK, будет доступно только после восстановления NEWYORK. MQ не реплицирует сообщения обоим администраторам очередей.

С pub/sub это немного отличается тем, что все диспетчеры очередей в кластере будут знать о кластерных темах, и если какой-либо подписчик на любом QM в кластере подпишется на эту TOPIC, подписка на прокси будет сделана подписчиком QM, если кто-либо публикует произойдет с этой темой в любом диспетчере очередей, копия будет направлена ​​каждому локальному подписчику, а также любым QM с действующей подпиской на прокси, затем QM подписчика доставит сообщение всем локальным для него подписчикам (так что только один прокси-подписчик даже если несколько подписчиков на одном и том же QM).

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

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

person JoshMc    schedule 28.05.2020