Проблема подключения к кластеру IBM MQ

Question

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

Наш кластер имеет 100 менеджеров очереди, и у нас есть 2 хранилища.

Answer 1

Существует несколько различных проблем, которые могут вызвать это. Один из них - если есть явно определенные CLUSSDR каналы, указывающие на не-хранилище QMgr. Это приводит к тому, что сообщения репозитория поступают в не-repos QMgr, которые могут привести к смерти его репозитория amqrrmfa. Другое дело, что было несколько APARS (например, this one), что может привести к вымиранию процесса. Решения, соответственно, должны исправить проблемы с конфигурацией или применить последний пакет Fix Pack. Еще одна проблема, реже встречающаяся, заключается в том, что сообщение новому QMgr будет выходить из строя до того, как новый QMgr сможет разрешить локальный QMgr. В этом случае REFRESH фактически не приводит к удалению удаленного QMgr, он просто предоставляет время для завершения разрешения.

Отладка включает в себя выделение возможных причин. Убедитесь, что запущен amqrrmfa. Убедитесь, что у всех QMgrs без репозитория есть один и ТОЛЬКО один явно определенный канал CLUSSDR. Убедитесь, что все репозитории имеют один и ТОЛЬКО один явно определенный CLUSSDR для каждого другого репозитория. Если используются перекрывающиеся кластеры, обязательно НЕ перекрывайте каналы. Это означает отказ от названий каналов, таких как TO.QMGR и предпочитающих имена, такие как CLUSTER.QMGR. Проверьте это, застраховав каналы, не используя атрибут CLUSNL и вместо этого используйте атрибут CLUSTER. Наконец, примирите объекты как в репозиториях, так и в не-репозитории, выпуская DIS CLUSQMGR(*) и DIS QCLUSTER(*). Репозитории должны иметь идентичные инвентаризации объектов. Если это не так, есть проблема. Нерепозиторий должен иметь запись для каждого QMgr, с которым он ранее разговаривал.

Одна вещь, которую я видел в прошлом, заключалась в том, что администратор назначил REFRESH CLUSTER. Он думал, что это нужно сделать, чтобы исправить кластер, поэтому почему бы не запустить его на регулярной основе? Поэтому он планировал, что он будет работать ежедневно. Затем каждую ночь он заставлял QMgr забывать о других QMgrs в кластере, и в первый раз, когда приложение разрешало удаленный QMgr каждый день, раздавался трафик репозитория. Это вызвало достаточно задержки, что каждое утро было около 2087 ошибок. Не то, чтобы вы сделали. :-)