Устранение неполадок

12.3. Общие проблемы при построении инфраструктуры

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

12.3.1. Устранение неполадок распределенных каналов сообщений

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

1. Проверьте, соответствуют ли имена объектов-каналов на обоих концах соединения; учтите, что имена каналов чувствительны к регистру.
2. Убедитесь, что на обоих концах соединения в менеджере очередей нет записей состояния STOPPED для данных каналов. Такая запись свидетельствует о том, что канал отключен. Чтобы включить канал, запустите его соответствующей командой, отданной объектам канала в менеджерах очередей, содержащих записи состояния STOPPED. Для просмотра всех записей состояния канала в WebSphere MQ Explorer щелкните канал правой кнопкой и выберите команду Status\Current Status.
3. Убедитесь в совместимости типов объекта MCA отправителя, извлекающего сообщения из транспортной очереди, и MCA получателя, доставляющего сообщения в очереди менеджера-адресата (см. "раздел 7.4.10" ).
4. Проследите, чтобы в атрибуте "имя подключения" ( CONNAME ) объекта канала MCA, используемого для соединения, был указан IP-адрес или хост-имя машины, на которой работает менеджер очередей, с которым нужно наладить взаимодействие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).
5. Убедитесь, что в атрибуте "имя подключения" ( CONNAME ) объекта канала MCA, используемого для соединения, указан порт, соответствующий порту слушателя менеджера очередей, с которым нужно наладить взаимодействие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).
6. Выполните команду WebSphere MQ ping для проверки связи через канал. Если эта проверка окончится неудачей, проверьте журналы ошибок обоих менеджеров очередей.
7. Убедитесь, что в атрибуте "транспортная очередь" ( XMITQ ) объекта канала, определяющего MCA отправителя, указано имя объекта локальной очереди, объявленного в том же менеджере очередей (учтите, что имена объектов чувствительны к регистру).
8. Убедитесь, что атрибут USAGE этого объекта локальной очереди определяет эту очередь как транспортную (имеет значение XMITQ ).
9. Попытайтесь запустить канал вручную.
10. Если канал не запускается, проверьте журналы ошибок обоих менеджеров очередей.
11. Проверьте, существует ли очередь недоставленных сообщений в менеджере очередей, в котором работает MCA получателя. Если в транспортной очереди накапливаются постоянные сообщения, которые не могут быть переданы получателю из-за ошибок доставки, то в отсутствие очереди недоставленных сообщений канал переходит в состояние RETRYING, а затем – в состояние STOPPED.
12. Проверьте, не указана ли одна и та же транспортная очередь у двух объектов канала в данном менеджере очередей.
13. Если для данных каналов есть запись о статусе, проверьте, не содержит ли ее атрибут "неоднозначное состояние" ( INDOUBT ) значение YES.

12.3.2. Устранение неполадок инициации каналов сообщений

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

1. Убедитесь, что атрибут "управление триггером" ( TRIGGER ) задан для объекта локальной очереди, использующейся в качестве транспортной очереди, из того же менеджера очередей, что используется объектом канала отправителя. В данном случае этот объект представляет транспортную очередь.
2. Проследите, чтобы атрибуту "тип триггера" ( TRIGTYPE ) транспортной очереди было присвоено значение FIRST или DEPTH.
3. Если триггер срабатывает на определенную длину очереди ( DEPTH ), убедитесь, что значение TRIGDPTH настроено соответствующим образом.
4. Убедитесь, что атрибуты "данные триггера" ( TRIGDATA ) и "процесс" ( PROCESS ) транспортной очереди содержат имя объекта канала отправителя (имена объектов чувствительны к регистру).
5. Проследите, чтобы атрибуту "очередь инициации" ( INITQ ) транспортной очереди было присвоено значение SYSTEM.CHANNEL.INITQ.
   Примечание. Допускается использование собственных очередей инициации, но инициатор каналов для них нужно запускать вручную.
6. Убедитесь, что инициатор каналов в менеджере очередей активен. В WebSphere MQ V6.0 для этого используется команда MQSC DISPLAY QMSTATUS CHINIT, альтернативный вариант – щелкнуть правой кнопкой менеджер очередей в WebSphere MQ Explorer и выбрать Status.
7. Проверьте, правильно ли установлен атрибут "интервал отключения" ( DISCINT ) объекта канала отправителя.
8. Вручную запустите канал, чтобы передать все сообщения из транспортной очереди удаленному менеджеру очередей.
9. Дождитесь истечения интервала отключения канала либо остановите его вручную, установив целевой статус ( STATUS ) канала в INACTIVE.
10. Добавьте сообщение в очередь удаленного менеджера очередей. В результате сообщение будет добавлено в транспортную очередь, и менеджер очередей автоматически запустит канал.

12.3.3. Устранение неполадок кластерных каналов сообщений

Ниже рассказывается о разрешении проблем, возникающих при добавлении менеджера очередей к кластеру (см. "раздел 8.3.3" ), удалении менеджера очередей из кластера ( "см. раздел 8.3.4" ). В частности, освещается устранение неполадок кластерных каналов сообщений. Чаще всего они возникают из-за неверной настройки атрибутов объектов кластерных sender- и receiver-каналов.

Общий симптом таких проблем — наличие строк следующего вида в выводе команд DISPLAY CLUSQMGR либо в папке Clusters, отображаемой WebSphere MQ Explorer.

SYSTEM.TEMPQMGR.имя_хоста(порт)

Обычно они возникают из-за проблем с подключением к кластеру либо повторным подключением с помощью команды REFRESH CLUSTER с параметром REPOS(YES).

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

Чтобы изменить имя этого подключения, удалите менеджер очередей из всех кластеров, в которые он входит, используя объект кластерного receiver-канала, внесите изменения и верните менеджер очередей в кластер. Не рекомендуется изменять имя объекта кластерного receiver-канала, пока этот объект опубликован в кластере.

Для кластерных каналов верно многое из того, что сказано о распределенных sender-каналах. Всегда начинайте с проверки каналов между менеджерами очередей полных репозиториев кластера. Далее проверьте каналы между менеджерами очередей частичных и полных репозиториев кластера. Лишь убедившись в работоспособности этих каналов, переходите к проверке каналов между менеджерами очередей частичных репозиториев.

Для каждой пары менеджеров очередей кластера проверьте следующее:

• для менеджера очередей с полным репозиторием проверьте, что атрибуты "репозиторий" ( REPOS ) или "список имен репозиториев" ( REPOSNL ) объекта менеджера очередей содержат верные имена кластера или объекта списка имен ( namelist ). Имена этих объектов чувствительны к регистру. Если используется список имен, проверьте наличие имени кластера в его атрибуте "имена" ( NAMES );
• убедитесь, что у обоих менеджеров очередей имеется активный слушатель;
• проверьте, содержат ли атрибуты "кластер" ( CLUSTER ) или "список имен кластеров" ( CLUSNL ) объектов кластерных sender- и receiver-каналов верные имена кластера и объекта списка имен. Если используется список имен, проверьте наличие имени кластера в его атрибуте "имена" ( NAMES );
• исполните MQSC-команду DISPLAY CLUSQMGR(*) на обоих менеджерах очередей. Убедитесь, что в выводе команды отсутствуют строки вида SYSTEM.TEMPQMGR.имя_хоста(порт). Их наличие свидетельствует о неудаче добавления менеджера очередей к кластеру по одной из двух причин.
  • Сбой кластерного sender-канала, объявленного вручную. Эти неполадки препятствуют подключению к менеджеру очередей, обслуживающему полный репозиторий. Убедитесь, что имя объекта кластерного sender-канала соответствует имени объекта кластерного receiver-канала, объявленного в менеджере очередей, обслуживающем полный репозиторий. Проверьте, пригодно ли заданное хост-имя, IP-адрес и порт для связи с менеджером очередей, обслуживающим полный репозиторий.
    Примечание. Конкретный экземпляр полного репозитория, с которым осуществляется связь, не имеет значения. Имя подключения, а также имя канала должно соответствовать аналогичным параметрам менеджера очередей, обслуживающего полный репозиторий, в противном случае запустить канал не удастся.
  • Сбой кластерного receiver-канала. Эти неполадки препятствуют подключению менеджера очередей, обслуживающего полный репозиторий. Проверьте имя подключения, заданного для объекта кластерного receiver-канала. Рекомендуется сбросить атрибуты CLUSTER и CLUSNL (записав в них пустую строку) до внесения любых изменений в имя подключения;
• убедитесь в доступности хост-имени и IP-адреса, заданного в атрибуте "имя подключения" ( CONNAME ) объекта кластерного receiver-канала в обоих менеджерах очередей. Для проверки связи можно использовать команду ОС ping. Проверьте также порты слушателей менеджеров очередей;
• проверьте журналы ошибок обоих менеджеров очередей;
• выполните команду MQSC DISPLAY CHSTATUS(*) над обоими менеджерами очередей. Попробуйте найти каналы, у которых статус отличается от RUNNING (например, каналы в состоянии RETRYING ), а также каналы, атрибут состояния INDOUBT у которых равен "YES" ;
• если пара менеджеров очередей обслуживают частичные репозитории, они могут иметь доступ к менеджерам, обслуживающим полные репозитории кластера, и не иметь доступа друг к другу. Чтобы открыть доступ к удаленному частичному репозиторию, следует объявить на нем объект локальной очереди. Чтобы опубликовать этот объект в кластере, запишите имя кластера в его атрибут "кластер" ( CLUSTER ). Добавьте сообщение в эту очередь, используя программу-пример amqsput, подключившись к локальному частичному репозиторию. Если эта операция завершилась успешно, команда DISPLAY CLUSQMGR(*), отданная на локальном частичном репозитории, отображает сведения об удаленном частичном репозитории.