Кластеры менеджеров очередей

8.1.7. Совместный доступ к объектам-очередям в кластерах

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

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

Совместный доступ допускают следующие типы объектов-очередей.

• Объекты локальных очередей:

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

  Примечание Осуществить в кластере совместный доступ к динамически сформированным локальным очередям посредством коллективного пользования определением модельной очереди, на базе которой они построены, невозможно.

  Однако, если приложение размещает сообщение в очереди с произвольным названием с указанием конкретного менеджера, который является членом кластера, сообщение доставляется этому менеджеру. Сказанное означает, что приложение может послать ответ в динамически организованную очередь для ответов, используя название очереди ответов и ее менеджера, указанные в дескрипторе сообщения-запроса. Название менеджера очереди ответов автоматически подставляется тем менеджером очередей сообщений, к которому было подключено приложение-инициатор запроса.

  В итоге приложения могут производить обмен сообщениями по принципу "запрос – ответ" со службой на основе разделяемой очереди в составе кластера аналогично тому, как если бы эта очередь находилась под управлением менеджера, к которому подключено приложение.
• Объекты очередей-псевдонимов.

  Наличие в кластере очереди-псевдонима с совместным доступом позволяет менеджеру очередей сообщений обобществить в нем имеющийся в составе менеджера объект-очередь под другим именем. Локальное по отношению к менеджеру название очереди определяется атрибутом "целевая (базовая) очередь" ( TARGQ/base queue ), названием же объекта очереди-псевдонима служит название, под которым очередь доступа в составе кластера.
• Объекты удаленных очередей.

  Совместный доступ к различным типам входящих в кластер объектов удаленных очередей, описанных в "Технические основы организации очередей сообщений" "Объекты удаленных очередей", дает различные результаты. Типичные примеры их использования следующие.

  • Локальное определение удаленной очереди.

    Предоставляет входящим в кластер менеджерам возможность совместно использовать очередь сообщений, находящуюся вне кластера, то есть в составе менеджера, который не является его членом. Названием объекта удаленной очереди является название, под которым организован совместный доступ к ней внутри кластера. Название целевой очереди в составе менеджера очередей назначения определяется атрибутом "удаленное имя" ( RNAME ), название управляющего ею менеджера – атрибутом "название удаленного менеджера очередей сообщений" ( RQMNAME ). Название транспортной очереди менеджера, на котором описана удаленная очередь, может быть задано атрибутом "транспортная очередь" ( XMITQ ) или по умолчанию принято равным названию удаленного менеджера.
  • Псевдоним менеджера очередей сообщений.

    В данном случае атрибут RNAME объекта удаленной очереди остается пустым. При этом возможны две ситуации.

    • Внутри кластера менеджер очередей может выбрать альтернативное имя. Им станет название обобществленного в кластере объекта удаленной очереди; реальное же название менеджера будет указано в атрибуте "название удаленного менеджера очередей сообщений" ( RQMNAME ).
    • Название менеджера вне кластера может быть известно внутри него, а транспортная очередь к этому менеджеру – задаваться в составе менеджера очередей сообщений, предоставляющего совместный доступ к определению объекта удаленной очереди. Название, под которым менеджер очередей сообщений должен быть известен в составе кластера, – это название обобществленного в нем объекта удаленной очереди. Название менеджера очередей вне кластера определяется атрибутом RQMNAME. Название транспортной очереди менеджера внутри кластера, если оно отлично от названия менеджера очередей за пределами такового, задается атрибутом XMITQ.

Совместно пользоваться объектами-очередями с одним названием и одного или разных типов в одном кластере могут, располагая этими типами объектов-очередей, сразу несколько менеджеров. Об этом мы еще скажем в "Кластеры менеджеров очередей" "Балансировка нагрузки".

Для задания кластеров, в которых к объекту организован совместный доступ, служат атрибуты объектов-очередей "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).

Атрибут CLUSTER позволяет определить имя только одного кластера.

Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.

8.1.8. Идентификатор менеджера очередей (QMID)

При создании каждого менеджера очередей сообщений для него строится идентификатор менеджера QMID (queue manager identifier), значение которого определяют время создания и название менеджера. В этих условиях вероятность того, что два менеджера получат одинаковые QMID, очень невелика, даже если они будут названы одинаково.

Уникальность QMID позволяет различать менеджеры очередей в кластере, неповторяемость их названий для этого не используется. Два менеджера очередей сообщений с одинаковыми названиями вряд ли будут включены в кластер умышленно, и делать это определенно не стоит. Однако почему-либо менеджер может быть пересоздан, например после сбоя аппаратуры. При этом старый менеджер с тем же названием мог не пройти успешное отключение от кластера до присоединения к нему нового. Столкнувшись с подобными ситуациями, кластеру важно иметь возможность различать первый и второй менеджер.

Если это произошло и в кластере оказалось несколько менеджеров с одинаковыми названиями, то, приступая к разрешению ситуации, изучите документацию по команде MQSC RESET CLUSTER ACTION(FORCEREMOVE).

8.1.9. Подписки и публикации в кластере

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

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

Как только к кластеру подключается менеджер с частичным репозиторием, он публикует информацию о себе, включая предоставленную объектом – кластерным receiver-каналом, и адресует ее двум полным репозиториям внутри кластера.

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

Частичный репозиторий повторяет эти публикации каждые 27 дней, что позволяет полным репозиториям убедиться, что менеджер внутри кластера остается активным, а информация – актуальной. Также полным репозиториям адресуются любые публикации с изменениями этих совместно используемых в кластере менеджеров объектов.

Если публикация не повторяется в течение 30 дней, ее срок действия истекает, и на запрос сведений от частичных репозиториев полные репозитории перестают выдавать ее как ответ. Однако на случай временной недоступности менеджера по некоторой причине репозитории сохраняют ее в течение еще 60 дней. Если по окончании периода, длящегося в общей сложности 90 дней, менеджер не повторил публикацию информации, полный репозиторий больше не считает его частью своего кластера. Когда же частичный репозиторий повторно установит связь с полным, он станет известен кластеру снова.

Частичный репозиторий поддерживает сведения лишь о тех менеджерах и объектах очередей кластера, которые ему интересны, в частности:

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

Для получения информации менеджер с частичным репозиторием производит подписку на сведения от менеджеров с полным репозиторием. В ответ он получает все известные полному репозиторию публикации о соответствующих объектах или уведомление о том, что нужная информация недоступна.

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

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

Подписки имеют ограниченный 30-дневный период существования, на протяжении которого частичный репозиторий автоматически получает от менеджеров с полным репозиторием обновления по подписке. По истечении 27 дней подписку требуется продлить. Однако менеджер продлевает ее только в том случае, если обращался к публикациям по подписке с того момента, как продлевал ее в прошлый раз. Иначе он не препятствует тому, чтобы срок подписки истек. Впрочем, если приложение в очередной раз попытается открыть объект очереди, подписку можно инициировать вновь.

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

Репозиторий менеджера поддерживается входящим в менеджер очередей соответствующий компонент, называемый менеджером репозитория. Он управляет подписками и отсылает публикации полным репозиториям внутри кластера.

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

8.2. Просмотр сведений из репозитория кластера

Как мы уже говорили, записи состояния кластерных каналов сообщений хранятся в каждом менеджере подобно записям состояния распределенных каналов. Кластерные каналы сообщений также можно запускать, останавливать, активизировать и блокировать, используя команды START CHANNEL и STOP CHANNEL в MQSC.

Однако, воспользовавшись MQSC и WebSphere MQ Explorer, о кластерах можно узнать подробнее, если познакомиться с текущим содержимым частичного или полного репозиториев менеджера очередей сообщений.

8.2.1. Просмотр сведений из репозитория через MQSC

В составе MQSC есть две команды доступа к этим сведениям.

• DISPLAY QCLUSTER.

  Команда выводит информацию обо всех совместно используемых кластерами экземплярах объектов-очередей, о которых известно менеджеру. Например, запуск следующей команды в полном репозитории кластера отображает всю известную информацию обо всех разделяемых в нем объектах-очередях:

  DISPLAY QCLUSTER(*) CLUSTER('Cluster.Name') ALL

  Каждый разделяемый внутри кластера экземпляр объекта очереди называют кластерной очередью (cluster queue). Заметим, что, как показано в "Кластеры менеджеров очередей" "Балансировка нагрузки", для упрощения балансировки нагрузки в пределах кластера обобществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблокирована на запись.

  Примечание Эта же команда MQSC, поданная в частичном репозитории, может не вернуть полный список общих кластерных очередей кластера, что связано с обстоятельствами, рассмотренными нами в "Кластеры менеджеров очередей" "Подписки и публикации в кластере".
• DISPLAY CLUSQMGR.

  Команда выводит информацию об известных менеджеру очередей сообщений менеджерах очередей в кластере. Так, запуск следующей команды в полном репозитории кластера покажет всю известную информацию обо всех менеджерах очередей кластера:

  DISPLAY CLUSQMGR(*) CLUSTER('Cluster.Name') ALL

  Каждую выводимую при этом на экран запись называют записью кластерного менеджера очередей (cluster queue manager), или CLUSQMGR-записью. Одна из них содержит данные о локальном менеджере очередей сообщений, работая с которым вы запустили команду. Информация в этой записи содержит в себе название и подробное описание относящегося к данному менеджеру кластерного канала сообщений. Им может оказаться объект – кластерный receiver-канал локального менеджера или любой из типов кластерных sender-каналов из "Кластеры менеджеров очередей" "Кластерные sender-каналы". Тип кластерного канала сообщений представлен атрибутом "тип описания" ( DEFTYPE – definition type) записи кластерного менеджера очередей и содержит информацию о состоянии кластерных sender-каналов данного менеджера, ведущих к остальным менеджерам очередей внутри кластера.

Запись кластерного менеджера очередей также содержит подробные сведения о менеджере очередей сообщений, в том числе его QMID, и информацию о том, является ли он полным репозиторием кластера. В записи о полном репозитории атрибут "тип менеджера очередей" ( QMTYPE – queue manager type) принимает значение REPOS, в записи о частичном – значение NORMAL.

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

SYSTEM.TEMPQMGR.hostname(port)

Здесь hostname(port) – название соединения в описании канала. Подобный формат обусловлен тем, что имя менеджера очередей сообщений невозможно установить, пока канал к нему не будет успешно пущен.