В этой лекции мы обсудим следующие вопросы:
Обзор понятий кластеризации
Просмотр сведений о репозиториях кластеров
Работа с менеджерами очередей в кластере
Балансировка нагрузки
8.1. Обзор понятий кластеризации
Все менеджеры очередей в кластере располагают сведениями о том, какими ресурсами наделен кластер, причем ресурсы в его составе не требуют явного локального описания. Добавлять в кластер новые ресурсы, например менеджеры и очереди, которыми они управляют, вы можете динамически, автоматически делая их доступными для пользования всем менеджерам очередей сообщений, которые входят в кластер.
Это дает возможность добавлять в кластер или удалять из него дополнительные ресурсы аппаратуры с учетом меняющейся нагрузки на инфраструктуру очередей сообщений WebSphere MQ.
Менеджер очередей может являться членом нескольких кластеров, что позволяет подразделять компоненты инфраструктуры WebSphere MQ по характеру служб или организовывать группы. Менеджеры могут выступать в роли связующего звена между кластерами, а также между кластером и имеющейся инфраструктурой WebSphere MQ на основе распределенных каналов сообщений.
Примечание В процессе реализации новой инфраструктуры как базу для ее построения рекомендуется использовать кластер.
Для получения присущих кластерам преимуществ в виде дополнительной балансировки нагрузки и высокой готовности существующая инфраструктура может расширяться через создание связей между нею самой и расширенной инфраструктурой на базе кластера.
Изложенное в данной главе представление о кластерах кому-то покажется изначально сложным для понимания. Однако эти идеи приведут нас к такой инфраструктуре менеджеров очередей сообщений, администрировать которую значительно проще, чем построенную с использованием распределенных каналов, что и показывают практические примеры из раздела 10.4 "Создание кластеров менеджеров очередей".
Увеличиваясь в масштабе, такая инфраструктура может охватить тысячи менеджеров.
Примечание Вплоть до конца главы понятием "кластер" (cluster ) мы будем пользоваться, называя так кластеры менеджеров очередей сообщений. Не путайте его с кластерами высокой готовности – понятием, характерным не только для WebSphere MQ, о котором мы говорили в разделе 3.6 "Высокая готовность системы".
8.1.1. Менеджеры очередей с полным и частичным репозиторием
Любой менеджер очередей сообщений содержит репозиторий (repository) с данными о кластерах, в которых он состоит.
Каждый менеджер внутри кластера можно настроить так, чтобы он содержал частичный или полный репозиторий. Суть полных и частичных репозиториев такова.
Полный репозиторий.Содержит данные обо всех совместных ресурсах кластера. В их число входят все менеджеры и все объекты очередей в кластере, которые используются совместно. Для каждого кластера в составе инфраструктуры обычно настроено ровно два менеджера очередей сообщений, имеющих полный репозиторий.
Менеджер, содержащий полный репозиторий с представлением кластера, называется менеджером очередей с полным репозиторием (full repository queue manager).
Частичный репозиторий.Содержит информацию о менеджерах очередей с полным репозиторием кластера. В частичный репозиторий входят сведения лишь о тех объектах очередей и менеджерах с частичным репозиторием, которые необходимы самому менеджеру. Если подключенное к нему приложение попытается открыть очередь, название которой неизвестно для менеджера, то при попытке поиска указанного ресурса будут опрошены менеджеры очередей с полным репозиторием всех кластеров, где данный менеджер состоит.
Менеджер, содержащий частичный репозиторий своего кластера, называется менеджером очередей с частичным репозиторием (partial repository queue manager).
Для вхождения в кластер менеджер очередей должен "знать" его полный репозиторий. Поэтому каждый кластер обязан содержать два или более менеджера, в которых такой репозиторий будет храниться. Именно эти два менеджера очередей с полным репозиторием изначально и образуют кластер, организуя соединение между собой.
Иметь в составе кластера более двух полных репозиториев, как правило, не рекомендуется потому, что полный репозиторий содержит всю информацию о каждом из ресурсов, входящих в кластер, а значит, должен регулярно обмениваться сведениями с другими полными репозиториями. Увеличение же их числа повысит нагрузку на инфраструктуру из-за того, что обмен станет более интенсивным.
8.1.2. Названия кластеров
Любой кластер имеет свое название. Имена кластеров могут содержать до 48 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов ".", "/", "_", "%". Полезными могут оказаться короткие имена кластеров, длина которых позволит включать их в описание всех кластерных канальных объектов.
8.1.3. Настройка менеджера очередей с полным репозиторием
Примечание Этот шаг рекомендуется выполнить до того, как менеджер очередей будет подключен к кластеру с использованием описанных в этом разделе объектов кластерных sender- и receiver-каналов сообщений.
Для задания кластеров, полный репозиторий с информацией о которых содержит текущий менеджер, служат атрибуты объекта-менеджера "репозиторий" ( REPOS – repository) и "список названий репозиториев" ( REPOSNL – repository namelist).
Атрибут REPOS позволяет определить имя только одного кластера.
Атрибут REPOSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере объекта – списка имен. Определите объект-список так, чтобы он содержал перечень названий интересующих кластеров.
Примечание Поддержание полного репозитория кластера может оказаться причиной заметной вычислительной работы на менеджере, вызванной тем, что кластер может содержать множество менеджеров или очередей под управлением таковых. По этой причине мы советуем отказаться от размещения на менеджерах очередей с полным репозиторием служб, представляемых кластером.Если эта машина все-таки выделена для размещения служб, рекомендуем определить на ней ряд других менеджеров. Для размещения менеджеров с полным репозиторием крупных кластеров может оказаться разумным выделить отдельное оборудование.
Также рекомендуем не размещать оба менеджера с полным репозиторием на одной и той же машине. Поскольку менеджеры очередей с частичным репозиторием кластера могут по-прежнему получать о нем информацию, если одна машина даст сбой или окажется недоступной, разделив менеджеры, вы избежите возникновения в кластере единой точки отказа.
8.1.4. Кластерные каналы сообщений
Вся информация в кластере передается по кластерным каналам сообщений (cluster message channels). Это справедливо и для тех случаев, когда приложение отправляет сообщение во входящую в кластер очередь и когда менеджер запрашивает в полном репозитории информацию о ресурсах в составе кластера.
Кластерные и распределенные каналы сообщений очень напоминают друг друга. И те и другие передают сообщения из транспортной очереди на одном менеджере в очередь, управляемую другим менеджером из кластера. Однако важное различие между ними состоит в том, что все сообщения, отправляемые через кластерные каналы, посылаются из одной общей транспортной очереди. Название этой автоматически задаваемой на любом менеджере во время создания очереди:
SYSTEM.CLUSTER.TRANSMIT.QUEUE
Все сообщения, адресуемые менеджерам очередей в кластере, будут размещены в этой очереди сообщений автоматически.
WebSphere MQ автоматически создает и запускает кластерные каналы сообщений, когда в них возникает необходимость. Это означает, что после того, как менеджер подключается к кластеру, дальнейшее администрирование каналов вручную уже не требуется.
Кластерные каналы сообщений используют агенты каналов сообщений (MCA) отправления и получения и обладают теми же возможностями, что и любой распределенный канал. К примеру, они имеют интервалы разъединения, поддерживают пакетную обработку и записи состояния канала, могут пользоваться аутентификацией SSL. Описание распределенных каналов и передачи сообщений между MCA-отправителем и MCA-получателем см. в разделе 7.4 "Распределенные каналы сообщений".
Начальный шаг подключения менеджера очередей к кластеру должен производиться вручную. При вхождении в кластер менеджер задает атрибуты, которые любой другой менеджер очередей в кластере должен будет использовать для того, чтобы установить с ним соединение.
С этой целью в WebSphere MQ введены объекты – кластерные каналы. Они могут определяться в составе менеджера для инициирования процесса подключения его к кластеру.
8.1.5. Кластерные receiver-каналы
Объекты – кластерные receiver-каналы описывают атрибуты, которыми, определяя кластерные sender-каналы сообщений, адресованных текущему менеджеру, должны пользоваться все входящие в один или несколько кластеров менеджеры очередей сообщений.
Чтобы сообщить менеджерам очередей с полным репозиторием о менеджере, в составе которого описан кластерный receiver-канал, он публикуется внутри кластера. Это означает отправку сведений о нем в один из полных репозиториев кластера, который передаст их остальным менеджерам очередей с полным репозиторием. Полные репозитории, в свою очередь, опубликуют это определение на менеджерах с частичным репозиторием в этом кластере, как только те запросят ресурсы, которыми этот менеджер управляет.
Объекты – кластерные receiver-каналы описывают название и атрибуты, которыми во время установления направленного к данному менеджеру канала от других менеджеров пользуются как MCA-отправитель, так и MCA-получатель.
Так, в кластерном receiver-канале задан интервал разъединения кластерных каналов сообщений. Им пользуется каждый MCA-отправитель, производящий подключение к менеджеру.
Поскольку ряд атрибутов, к примеру конфигурация SSL, должен совпадать у агентов отправления и получения, администрирование может существенно упроститься. Работая с кластером, достаточно настроить лишь атрибуты одного менеджера, который подключается к кластеру, а не обоих – на каждом из концов подключения.
Чтобы вручную задать объекты – кластерные receiver-каналы, используйте один из следующих методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSRCVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Cluster-receiver Channel.
Обязательный атрибут – название соединения ( CONNAME ) с объектом – кластерным receiver-каналом. Значением атрибута должно являться название хоста или IP-адрес и порт, где выполняется слушатель того менеджера очередей сообщений, в составе которого описан этот объект. Именно этим названием соединения будут пользоваться другие менеджеры очередей в кластере, устанавливая связь с данным менеджером очередей сообщений.
Для задания кластеров, к которым применимо описание канала, служат атрибуты объекта – кластерного receiver-канала "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
Выход из кластера осуществляется самим менеджером очередей сообщений и происходит, если атрибут CLUSTER или CLUSNL receiver-канала, через который менеджер был подключен к кластеру, изменяется и больше не указывает на кластер или если название кластера удаляется из объекта списка имен, название которого задано в атрибуте CLUSNL того же кластерного receiver-канала.
Примечание Используя список названий кластеров (CLUSNL), менеджер очередей сообщений может опубликовать кластерный receiver-канал сразу в нескольких кластерах, что позволяет каналам, направленным к этому менеджеру в каждом из них, иметь одинаковое название. Канальные объекты такого типа обычно именуют следующим образом:TO.названиеменеджера
Другой подход заключается в публикации менеджером отдельных объектов – кластерных receiver-каналов в каждом кластере, для чего служит атрибут каждого из объектов-каналов CLUSTER. Канальные объекты такого типа обычно именуют следующим образом:TO.названиекластера.названиеменеджера
Второе соглашение об именах сокращает то количество символов, которое допустимо для обозначения менеджера очередей сообщений в 20-символьном названии канала.
8.1.6. Кластерные sender-каналы
Понятие " кластерный sender-канал" нередко служит для описания различных объектов.
Описанного вручную объекта – кластерного sender-канала, или CLUSSDR. Используется при подключении к кластеру для связи с его полным репозиторием.
Кластерного sender-канала, описанного автоматически, – CLUSSDRA – или автоматического кластерного sender-канала с явным определением (auto explicit cluster sender). Автоматически формируются менеджерами очередей сообщений с учетом определений кластерных receiver-каналов, опубликованных множеством входящих в кластер менеджеров для установления связи с ними.
Автоматически описанного кластерного sender-канала, заменяющего кластерный sender-канал, описанный вручную, – CLUSSDRB, – или автоматического кластерного sender-канала (auto cluster sender). Автоматически формируется менеджером очередей сообщений с учетом определения кластерного receiver-канала, опубликованного менеджером очередей с полным репозиторием, для которого объект – кластерный sender-канал был изначально описан при вхождении в кластер.
Вручную, или явно, определенный объект – кластерный sender-канал выполняет лишь одну функцию – начальное установление связи с одним из полных репозиториев во время подключения к кластеру.
Название объекта – кластерного sender-канала, описанного вручную, должно соответствовать названию объекта – кластерного receiver-канала, описанного в составе менеджера очередей с полным репозиторием и опубликованного этим же менеджером при вхождении в кластер.
Аналогично для успешного подключения ряд атрибутов описанного вручную кластерного sender-канала, к примеру конфигурация SSL, должны быть гарантированно корректны.
Чтобы вручную задать объект – кластерный sender-канал, используйте один из следующих методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSSDR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Cluster-sender Channel.
Обязательным атрибутом является название соединения ( CONNAME ) объекта – кластерного канала. Значением атрибута должно служить название хоста или IP-адрес и порт, где выполняется слушатель менеджера очередей с полным репозиторием кластера. При этом не имеет значения, какой именно полный репозиторий выбран. Тем не менее название канала должно соответствовать имени описанного в этом репозитории объекта – кластерного receiver-канала.
Для задания кластеров, в которых описание канала может использоваться для связи с полным репозиторием, служат атрибуты объекта – кластерного sender-канала "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
При описании объекта – кластерного sender-канала через него в полном репозитории публикуются любые объекты – кластерные receiver-каналы, что вызывает начало автоматического процесса установления членства менеджера в указанных кластерах.
Результатом осуществления такого процесса для каждого кластера является то, что определение кластерного receiver-канала сохраняется во всех полных репозиториях кластера. В них также заносятся и определения любых объектов-очередей, коллективный доступ к которым обеспечивает подключающийся к кластеру менеджер очередей сообщений. В свою очередь, менеджер получает представление обо всех полных репозиториях кластера.
По окончании описанного процесса явно определенный кластерный sender-канал более не используется. В дальнейшем менеджер очередей пользуется определениями кластерных receiver-каналов, совместный доступ к которым имеют все менеджеры очередей кластера. Это позволяет установить каналы ко всем менеджерам очередей сообщений с полным и частичным репозиторием. Аналогично и эти менеджеры очередей могут установить каналы к данному менеджеру, используя обобществленное в кластере определение кластерного receiver-канала.
Примечание Если в кластере существует более двух менеджеров очередей с полным репозиторием, кластерные sender-каналы должны быть заданы явно по схеме "из каждого полного репозитория – в каждый". Причина этого в том, что полные репозитории кластера получают информацию только от тех других полных репозиториев, с которыми они связаны явно определенным кластерным sender-каналом.Менеджерам очередей с частичным репозиторием достаточно одного явного кластерного sender-канала независимо от числа имеющихся в составе кластера менеджеров очередей с полным репозиторием. Описание на менеджере очередей с частичным репозиторием более одного явного кластерного sender-канала не дает никаких преимуществ.
8.1.7. Совместный доступ к объектам-очередям в кластерах
Менеджеры очередей с полным и частичным репозиторием в кластере могут пользоваться объектами-очередями кластера коллективно.
Это дает возможность автоматически распространять сведения об объектах-очередях по всем менеджерам очередей в кластере. Например, приложение, подключенное к одному менеджеру, может разместить сообщение в локальной очереди другого, причем сама очередь может совместно использоваться всем кластером без указания названия этого удаленного менеджера.
Совместный доступ допускают следующие типы объектов-очередей.
Объекты локальных очередей:Чаще всего совместный доступ в кластерах организуется именно к ним. Обобществление локальных очередей позволяет приложению, подключенному к любому менеджеру очередей в кластере, поместить сообщение в очередь, которая используется этим менеджером совместно с другим, указав только название очереди во время ее открытия.
Примечание Осуществить в кластере совместный доступ к динамически сформированным локальным очередям посредством коллективного пользования определением модельной очереди, на базе которой они построены, невозможно.Однако, если приложение размещает сообщение в очереди с произвольным названием с указанием конкретного менеджера, который является членом кластера, сообщение доставляется этому менеджеру. Сказанное означает, что приложение может послать ответ в динамически организованную очередь для ответов, используя название очереди ответов и ее менеджера, указанные в дескрипторе сообщения-запроса. Название менеджера очереди ответов автоматически подставляется тем менеджером очередей сообщений, к которому было подключено приложение-инициатор запроса.
В итоге приложения могут производить обмен сообщениями по принципу "запрос – ответ" со службой на основе разделяемой очереди в составе кластера аналогично тому, как если бы эта очередь находилась под управлением менеджера, к которому подключено приложение.
Объекты очередей-псевдонимов.Наличие в кластере очереди-псевдонима с совместным доступом позволяет менеджеру очередей сообщений обобществить в нем имеющийся в составе менеджера объект-очередь под другим именем. Локальное по отношению к менеджеру название очереди определяется атрибутом "целевая (базовая) очередь" ( TARGQ/base queue ), названием же объекта очереди-псевдонима служит название, под которым очередь доступа в составе кластера.
Объекты удаленных очередей.Совместный доступ к различным типам входящих в кластер объектов удаленных очередей, описанных в разделе 6.2.5 "Объекты удаленных очередей", дает различные результаты. Типичные примеры их использования следующие.
Локальное определение удаленной очереди.Предоставляет входящим в кластер менеджерам возможность совместно использовать очередь сообщений, находящуюся вне кластера, то есть в составе менеджера, который не является его членом. Названием объекта удаленной очереди является название, под которым организован совместный доступ к ней внутри кластера. Название целевой очереди в составе менеджера очередей назначения определяется атрибутом "удаленное имя" ( RNAME ), название управляющего ею менеджера – атрибутом "название удаленного менеджера очередей сообщений" ( RQMNAME ). Название транспортной очереди менеджера, на котором описана удаленная очередь, может быть задано атрибутом "транспортная очередь" ( XMITQ ) или по умолчанию принято равным названию удаленного менеджера.
Псевдоним менеджера очередей сообщений.В данном случае атрибут RNAME объекта удаленной очереди остается пустым. При этом возможны две ситуации.
Внутри кластера менеджер очередей может выбрать альтернативное имя. Им станет название обобществленного в кластере объекта удаленной очереди; реальное же название менеджера будет указано в атрибуте "название удаленного менеджера очередей сообщений" ( RQMNAME ).
Название менеджера вне кластера может быть известно внутри него, а транспортная очередь к этому менеджеру – задаваться в составе менеджера очередей сообщений, предоставляющего совместный доступ к определению объекта удаленной очереди. Название, под которым менеджер очередей сообщений должен быть известен в составе кластера, – это название обобществленного в нем объекта удаленной очереди. Название менеджера очередей вне кластера определяется атрибутом RQMNAME. Название транспортной очереди менеджера внутри кластера, если оно отлично от названия менеджера очередей за пределами такового, задается атрибутом XMITQ.
Примечание Еще один полезный способ применения объектов удаленных очередей в кластере – описание в составе менеджера очередей псевдонима с пустым значением атрибута "удаленное имя" ( RNAME ) без разделения объекта удаленной очереди в кластере.Такая схема ведет к балансировке нагрузки, создаваемой сообщениями, поступающими этому менеджеру очередей извне кластера и содержащими конкретное название менеджера очередей сообщений.
Совместно пользоваться объектами-очередями с одним названием и одного или разных типов в одном кластере могут, располагая этими типами объектов-очередей, сразу несколько менеджеров. Об этом мы еще скажем в разделе 8.4 "Балансировка нагрузки".
Для задания кластеров, в которых к объекту организован совместный доступ, служат атрибуты объектов-очередей "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
8.1.8. Идентификатор менеджера очередей (QMID)
При создании каждого менеджера очередей сообщений для него строится идентификатор менеджера QMID (queue manager identifier), значение которого определяют время создания и название менеджера. В этих условиях вероятность того, что два менеджера получат одинаковые QMID, очень невелика, даже если они будут названы одинаково.
Уникальность QMID позволяет различать менеджеры очередей в кластере, неповторяемость их названий для этого не используется. Два менеджера очередей сообщений с одинаковыми названиями вряд ли будут включены в кластер умышленно, и делать это определенно не стоит. Однако почему-либо менеджер может быть пересоздан, например после сбоя аппаратуры. При этом старый менеджер с тем же названием мог не пройти успешное отключение от кластера до присоединения к нему нового. Столкнувшись с подобными ситуациями, кластеру важно иметь возможность различать первый и второй менеджер.
Если это произошло и в кластере оказалось несколько менеджеров с одинаковыми названиями, то, приступая к разрешению ситуации, изучите документацию по команде MQSC RESET CLUSTER ACTION(FORCEREMOVE).
Примечание Описанные в ней действия предпринимайте только после прочтения соответствующих разделов в WebSphere MQ Queue Manager Clusters, SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.1.9. Подписки и публикации в кластере
В этом разделе мы коротко расскажем о том, как полные и частичные репозитории кластера поддерживают актуальную информацию, что послужит основой для понимания сведений, получаемых при просмотре той информации о кластере, которая в них содержится.
Все полные репозитории кластера общаются между собой, и это позволяет им обеспечить поддержание полной и одинаковой информации обо всех менеджерах и объектах-очередях в кластере.
Как только к кластеру подключается менеджер с частичным репозиторием, он публикует информацию о себе, включая предоставленную объектом – кластерным receiver-каналом, и адресует ее двум полным репозиториям внутри кластера.
Организуя совместный доступ к объекту очереди внутри кластера, менеджер с частичным репозиторием аналогично публикует сведения об объекте двум полным репозиториям кластера.
Частичный репозиторий повторяет эти публикации каждые 27 дней, что позволяет полным репозиториям убедиться, что менеджер внутри кластера остается активным, а информация – актуальной. Также полным репозиториям адресуются любые публикации с изменениями этих совместно используемых в кластере менеджеров объектов.
Если публикация не повторяется в течение 30 дней, ее срок действия истекает, и на запрос сведений от частичных репозиториев полные репозитории перестают выдавать ее как ответ. Однако на случай временной недоступности менеджера по некоторой причине репозитории сохраняют ее в течение еще 60 дней. Если по окончании периода, длящегося в общей сложности 90 дней, менеджер не повторил публикацию информации, полный репозиторий больше не считает его частью своего кластера. Когда же частичный репозиторий повторно установит связь с полным, он станет известен кластеру снова.
Частичный репозиторий поддерживает сведения лишь о тех менеджерах и объектах очередей кластера, которые ему интересны, в частности:
обо всех менеджерах с полным репозиторием, успешно подключившихся к кластеру;
об объектах-очередях, входящих в кластер и одноименных объектам, обобществленным менеджером очередей внутри кластера;
об объектах-очередях, входящих в кластер под именами, по адресу которых подключенные к менеджеру очередей приложения посылают сообщения;
о менеджерах с частичными репозиториями, под управлением которых находятся известные этому менеджеру объекты очередей.
Для получения информации менеджер с частичным репозиторием производит подписку на сведения от менеджеров с полным репозиторием. В ответ он получает все известные полному репозиторию публикации о соответствующих объектах или уведомление о том, что нужная информация недоступна.
Подписки формируются частичным репозиторием в момент организации коллективного доступа к новому объекту в составе кластера, а также при разрешении названий очередей, когда подключенные к менеджеру очередей приложения пытаются открыть их для размещения сообщений.
Если менеджеру с частичным репозиторием неизвестны названия объектов или менеджеров объектов-очередей, указанные при открытии таковых для размещения сообщений, подписки на информацию от полных репозиториев генерируются для всех кластеров, в которые входит данный частичный репозиторий.
Примечание Открывая неизвестную в частичном репозитории очередь сообщений, менеджер может до 10 секунд ждать отклика менеджера очередей с полным репозиторием. Если ожидание безрезультатно, то приложение, которое пытается поместить сообщение в очередь, будет не в состоянии это сделать. По этой причине возможность в любой момент времени установить связь хотя бы с одним из полных репозиториев кластера чрезвычайно важна.
Подписки имеют ограниченный 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). Заметим, что, как показано в разделе 8.4 "Балансировка нагрузки", для упрощения балансировки нагрузки в пределах кластера обобществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблокирована на запись.
Примечание Эта же команда MQSC, поданная в частичном репозитории, может не вернуть полный список общих кластерных очередей кластера, что связано с обстоятельствами, рассмотренными нами в разделе 8.1.9 "Подписки и публикации в кластере".
DISPLAY CLUSQMGR.Команда выводит информацию об известных менеджеру очередей сообщений менеджерах очередей в кластере. Так, запуск следующей команды в полном репозитории кластера покажет всю известную информацию обо всех менеджерах очередей кластера:
DISPLAY CLUSQMGR(*) CLUSTER('Cluster.Name') ALL
Каждую выводимую при этом на экран запись называют записью кластерного менеджера очередей (cluster queue manager), или CLUSQMGR-записью. Одна из них содержит данные о локальном менеджере очередей сообщений, работая с которым вы запустили команду. Информация в этой записи содержит в себе название и подробное описание относящегося к данному менеджеру кластерного канала сообщений. Им может оказаться объект – кластерный receiver-канал локального менеджера или любой из типов кластерных sender-каналов из раздела 8.1.6 "Кластерные sender-каналы". Тип кластерного канала сообщений представлен атрибутом "тип описания" ( DEFTYPE – definition type) записи кластерного менеджера очередей и содержит информацию о состоянии кластерных sender-каналов данного менеджера, ведущих к остальным менеджерам очередей внутри кластера.
Примечание Для получения информации о каналах, направленных к данному менеджеру очередей сообщений и установленных с помощью обобществленного в кластере определения кластерного receiver-канала используйте команду DISPLAY CHSTATUS. Направленные к менеджеру активные кластерные каналы могут иметь несколько менеджеров в кластере одновременно, причем название кластерного receiver-канала окажется одинаковым. Запись кластерного менеджера очередей может представлять каналы к менеджеру как неактивные в тот момент, когда на самом деле они реально работают.
Запись кластерного менеджера очередей также содержит подробные сведения о менеджере очередей сообщений, в том числе его QMID, и информацию о том, является ли он полным репозиторием кластера. В записи о полном репозитории атрибут "тип менеджера очередей" ( QMTYPE – queue manager type) принимает значение REPOS, в записи о частичном – значение NORMAL.
Примечание Эта же команда MQSC, поданная в частичном репозитории, может не вернуть полного списка менеджеров очередей в кластере, но должна показать все полные репозитории в нем. Такое поведение команды связано с обстоятельствами, рассмотренными в разделе 8.1.9 "Подписки и публикации в кластере".
Если при подключении к кластеру не удается запустить заданный вручную кластерный sender-канал, ведущий в полный репозиторий, название в записи кластерного менеджера очередей примет следующий вид:
SYSTEM.TEMPQMGR.hostname(port)
Здесь hostname(port) – название соединения в описании канала. Подобный формат обусловлен тем, что имя менеджера очередей сообщений невозможно установить, пока канал к нему не будет успешно пущен.
8.2.2. Просмотр сведений из репозитория в WebSphere MQ Explorer
Для представления информации из репозитория кластера в WebSphere MQ Explorer имеется папка Queue Manager Clusters в навигаторе инструмента.
Как только WebSphere MQ Explorer подключается к менеджеру из папки Queue Managers с полным репозиторием кластера, обозначения кластеров появляются в папке Queue Manager Clusters автоматически. Менеджеры, представляющие собой полные репозитории кластера, могут находиться на той же машине, что WebSphere MQ Explorer, или быть подключенными к нему удаленно.
Примечание WebSphere MQ Explorer не показывает информацию о кластерах, для которых подключенные из папки Queue Managers менеджеры очередей являются частичными репозиториями.Причина этого в том, что менеджеры с частичным репозиторием не содержат достаточно сведений о кластере для того, чтобы надежно установить информацию обо всех менеджерах очередей в нем, как было сказано в разделе 8.1.9 "Подписки и публикации в кластере".
Под каждым из значков кластера в навигаторе будут отображаться две папки.
Full Repositories.Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, которые входят в кластер и содержат его полные репозитории. Значок каждого менеджера очередей с полным репозиторием кластера расположен уровнем ниже.
Partial Repositories.Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, которые входят в кластер и содержат его частичные репозитории. Значок каждого менеджера очередей с частичным репозиторием кластера расположен уровнем ниже.
Папка Queue Manager Clusters в WebSphere MQ Explorer показана на рис 8.1. Взятый как пример кластер содержит четыре менеджера, локально работающих на машине с WebSphere MQ Explorer. Два менеджера содержат полный и два – частичный репозиторий.
(рис 8.1) Папка Queue Manager Clusters в WebSphere MQ ExplorerЕсли к WebSphere MQ Explorer подключено несколько менеджеров очередей с полными репозиториями одного кластера, WebSphere MQ Explorer выбирает один из них, чтобы сформировать содержимое папок кластера – Full Repositories и Partial Repositories. Используемый для этого менеджер называют источником кластерной информации.
Все полные репозитории менеджеров содержат идентичную информацию, о чем упоминалось в разделе 8.1.9 "Подписки и публикации в кластере". Тем не менее, если менеджер отключается от сети, или ведущие к нему кластерные каналы блокируются, в его полном репозитории может оказаться не вся необходимая информация о менеджерах очередей кластера. В этих условиях источником кластерной информации может стать другой менеджер, также содержащий полный репозиторий и подключенный из папки Queue Managers. Для его выбора выделите значок кластера в навигаторе и щелкните по кнопке Select на странице содержимого Cluster.
Просмотр репозитория единичного менеджера
После запроса источника кластерной информации для получения сведений о менеджерах очередей – членах кластера на экран может быть выведена информация из частичного или полного репозитория каждого входящего в кластер менеджера.
Если в папках Full Repositories или Partial Repositories определенного кластера выбрать конкретный менеджер, откроется страница содержимого с информацией, которую данный менеджер содержит в своем репозитории.
Информация на этой странице будет запрашиваться у менеджера, который вы выбрали, а не в источнике кластерной информации.
Если в папке Queue Managers удаленный менеджер не показан, хранящуюся в его репозитории информацию о кластере вы все же можете просмотреть. Значок менеджера будет изначально вам недоступен, а представленные таблицы не будут содержать данных. Для установления через кластер соединения с этим менеджером и вывода информации на экран щелкните правой кнопкой по недоступному значку менеджера в папке Partial Repositories или Full Repositories кластера в навигаторе и выберите Connect To Queue Manager.
Примечание Подключение к менеджеру для вывода данных репозитория, не показанному в используемой папке Queue Managers, происходит не напрямую, а посредством отправки и получения сообщений от него через кластер. Соединение, которым пользуется WebSphere MQ Explorer, адресовано выбранному для текущего кластера источнику кластерной информации.Чтобы это подключение было успешным, менеджер очередей сообщений, для которого нужно произвести вывод кластерной информации, должен иметь работающий командный сервер. Кроме того, должна быть возможна связь с этим менеджером очередей через кластер, реализующий двухсторонний обмен с выбранным как источник кластерной информации менеджером очередей с полным репозиторием. Если целевой менеджер не запущен, не работает его командный сервер, возникает ошибка авторизации или дает сбой соединение через кластер, выводимая на экран ошибка обычно имеет вид:
Command server not responding within timeout period. (AMQ4032)
Отображаемая после успешного подключения к менеджеру информация на странице содержимого репозитория делится на три вкладки.
Cluster Queues.Содержит сведения обо всех совместно используемых кластерами экземплярах объектов-очередей, о которых известно менеджеру. Информация идентична той, которая выводится на экран при запуске для данного менеджера команды MQSC DISPLAY QCLUSTER.
Каждый разделяемый внутри кластера экземпляр объекта очереди называют кластерной очередью (cluster queue). Заметим, что, как показано в разделе 8.4 "Балансировка нагрузки", для упрощения балансировки нагрузки в пределах кластера обобществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблокирована на запись.
Количество совместно используемых в кластере объектов-очередей, информация о которых хранится в репозитории менеджера, графически представлено над таблицей.
Каждой кластерной очереди в таблице отведено по строке. Столбцы таблицы показывают атрибуты записи данных о такой очереди. Дважды щелкнув по самой записи, вы увидите атрибуты записи в окне свойств.
Примечание Менять значения атрибутов объекта, представленного записью о кластерной очереди, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Чтобы изменить атрибуты, обязательно подключите менеджер очередей сообщений к WebSphere MQ из папки Queue Managers. Затем выберите в навигаторе папку Queues конкретного менеджера и дважды щелкните по разделяемому в кластере объекту очереди в таблице.
Cluster-sender channels.Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для всех удаленных менеджеров очередей кластера. Это записи обо всех известных данному менеджеру очередей сообщений менеджерах очередей в кластере, для связи с которыми он использует кластерный sender-канал. Типы таких каналов мы обсуждали в разделе 8.1.6 "Кластерные sender-каналы".
Для каждого менеджера очередей в кластере, известного текущему менеджеру, в таблице отводится по строке. Каждой строкой таблицы представлен направленный к менеджеру, работающий или способный работать кластерный sender-канал. Это – запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке. Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 "Просмотр сведений из репозитория через MQSC".
Примечание Менять значения атрибутов любых канальных объектов, к которым относятся записи кластерных менеджеров очередей, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Обсуждаемые здесь записи, хотя и показывают кластерные sender-каналы, как правило, представляют автоматически заданные каналы, созданные на основе кластерных receiver-каналов, которые описаны менеджером очередей сообщений при подключении к кластеру. Подробнее об этом см. в разделе 8.1.5 "Кластерные receiver-каналы". Вручную объекты – кластерные sender-каналы создаются только при подключении к кластеру для связи с полным репозиторием такового. Подробности см. в разделе 8.1.6 "Кластерные sender-каналы".
Cluster-receiver channels.Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для локального менеджера. Обычно это всего одна запись. Она содержит ту информацию, которая была опубликована менеджером очередей сообщений при подключении к кластеру и является описанием кластерного receiver-канала. Подробности читайте в разделе 8.1.5 "Кластерные receiver-каналы". Обычно эта таблица содержит одну строку, которая свидетельствует о публикации данным менеджером единственного объекта – кластерного receiver-канала. Это запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке.
Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 "Просмотр сведений из репозитория через MQSC".
Примечание Менять значения атрибутов канального объекта, к которому относится запись кластерного менеджера очередей, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Применение кластерных receiver-каналов при подключении к кластеру мы обсуждали в разделе 8.1.5 "Кластерные receiver-каналы".
8.3. Работа с менеджерами очередей в кластере
Этот раздел главы посвящен описанию общих действий, выполняемых в ходе администрирования или создания кластера менеджеров очередей сообщений. Процедура администрирования относительно несложна, однако чтобы остальные менеджеры очередей в кластере не содержали ложную информацию о данном менеджере очередей сообщений, а подключение к нему в кластере возможно установить, должна правильно выполняться.
8.3.1. Приостановка и возобновление работы менеджера очередей в кластере
Приостановка работы менеджера очередей в кластере отлична от его удаления. В результате приостановки доставка сообщений очередям, совместный доступ к которым в кластере организует текущий менеджер, становится практически невозможной. Она существенно сокращает вероятность того, что контролирующий работу остальных менеджеров алгоритм балансировки нагрузки выберет доставку сообщений очередям текущего менеджера. Вопросы балансировки нагрузки мы обсудим в разделе 8.4 "Балансировка нагрузки".
Приостановка работы менеджера очередей не мешает тому, чтобы специально предназначенные ему сообщения поступали к нему из кластера.
После выполнения приостановки работу менеджера можно снова возобновить.
Чтобы произвести приостановку или возобновление работы менеджера очередей в кластере, используйте один из следующих методов.
Для целей приостановки или возобновления работы менеджера очередей в одном кластере – команды MQSC SUSPEND QMGR CLUSTER или RESUME QMGR CLUSTER.
Для целей приостановки или возобновления работы менеджера очередей в нескольких кластерах – команды MQSC SUSPEND QMGR CLUSNL или RESUME QMGR CLUSNL.
WebSphere MQ Explorer:для выполнения приостановки менеджера с частичным репозиторием полный репозиторий кластера должен быть подключен из папки Queue Managers навигатора;
откройте в навигаторе папку Queue Manager Clusters ;
разверните дерево навигатора под значком с тем же названием, что и кластер;
в зависимости от того, полный или частичный репозиторий кластера содержит текущий менеджер, разверните в навигаторе папку Full Repositories или Partial Repositories ;
щелкните в навигаторе правой кнопкой по значку, одноименному менеджеру.Если работу менеджера в кластере необходимо остановить, выберите в меню Suspend Cluster Membership.
Если работу менеджера в кластере необходимо возобновить, выберите в меню Resume Cluster Membership. Заметим, что этот пункт доступен только в том случае, если менеджер в кластере был ранее приостановлен.
8.3.2. Сброс членства менеджера очередей в кластере
Для удаления из кластера всей информации о менеджере и обеспечения возможности нового запуска менеджера очередей в нем без выхода и повторного подключения воспользуйтесь командой MQSC RESET CLUSTER.
Это действие также доступно из WebSphere MQ Explorer, где нужно щелкнуть правой кнопкой мыши по значку менеджера очередей интересующего вас кластера.
Примечание Предпринимайте это действие только после прочтения соответствующих разделов руководства WebSphere MQ Queue Manager Clusters, SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.3.3. Этапы подключения менеджера очередей к кластеру
Опишем в этом разделе ручные операции добавления менеджера в существующий кластер или формирования нового. Для кластеров, не использующих списки имен в определениях каналов или атрибутах репозиториев менеджеров, перечисленные здесь действия также можно осуществить при помощи мастеров WebSphere MQ Explorer.
С применением мастеров WebSphere MQ Explorer
В мастерах WebSphere MQ Explorer создание кластера и добавление менеджера очередей в существующих – это разные операции. И в первом и во втором случае менеджеры очередей должны быть предварительно созданы и запущены, а также подключены к WebSphere MQ в папке Queue Managers.
Для доступа к мастеру создания кластера Create Cluster:
Убедитесь, что оба изначально образующих кластер менеджера очередей с полным репозиторием существуют и подключены из папки Queue Managers.
Щелкните правой кнопкой по расположенной в дереве навигатора папке Queue Manager Clusters.
Выберите в меню New -> Queue manager cluster.
Для доступа к мастеру добавления в кластер Add to cluster:
Убедитесь, что полный репозиторий кластера подключен к WebSphere MQ Explorer из папки Queue Managers.
Убедитесь, что из этой папки подключен и вводимый в состав кластера менеджер.
В представленной в навигаторе папке Queue Manager Clusters щелкните правой кнопкой по тому кластеру, к которому подключается менеджер.
Выберите в меню Add Queue Manager To Cluster.
Операции, выполняемые вручную
Чтобы вручную добавить менеджер в существующий кластер или сформировать новый, произведите следующую работу.
Убедитесь в том, что для менеджера описан слушатель на конкретный сетевой порт, а имя хоста или IP-адрес машины, где размещается менеджер, известны и доступны всем остальным менеджерам очередей в кластере.Примечание Не используйте имя хоста, равное localhost, и IP-адрес 127.0.0.1, так как они действуют только на локальной машине.
Убедитесь в том, что известно название подключения к полному репозиторию кластера, включая имя хоста или IP-адрес машины с менеджером и порт, на который настроен слушатель. Если эти шаги касаются одного из пары исходных менеджеров очередей с полным репозиторием, то речь идет о названии соединения с другим менеджером очередей сообщений, который содержит – или может содержать – полный репозиторий кластера.Примечание Если текущим менеджером планируется заменить прежний полный репозиторий, рекомендуем выбрать название соединения того полного репозитория кластера, который в нем остается.
Если текущий менеджер должен содержать полный репозиторий одного кластера, установите атрибут REPOS объекта-менеджера очередей сообщений равным названию такового.Если менеджер очередей должен содержать полные репозитории нескольких кластеров, определите объект – список имен с занесенными в атрибут NAMES названиями всех кластеров. Укажите название объекта – списка имен в атрибуте REPOSNL объекта – менеджера очередей сообщений.
Определите объект – кластерный receiver-канал, описав в нем порядок обращения к текущему менеджеру остальных менеджеров очередей внутри кластера.В атрибуте CONNAME задайте название соединения для связи с тем менеджером, который подключается к кластеру.
Если кластерный receiver-канал планируется использовать для подключения только к одному кластеру, заполните его названием атрибут CLUSTER.
Если один объект – кластерный receiver-канал, напротив, будет использоваться для подключения менеджера к целой серии кластеров, определите объект – список имен с названиями последних, перечислив их в атрибуте списка названий NAMES. Укажите имя объекта – списка имен в атрибуте CLUSNL объекта – кластерного receiver-канала.
Задайте любые дополнительные атрибуты, такие как интервал разъединения, размер пакета или конфигурация SSL, которыми должны пользоваться менеджеры очередей внутри кластера, отправляя сообщения вводимому в его состав менеджеру.
Определите объект – кластерный sender-канал, чтобы описать подключение к существующему полному репозиторию кластера, или выберите другой описанный менеджер очередей с полным репозиторием.В атрибуте CONNAME задайте название соединения для связи с тем менеджером, где расположен полный репозиторий кластера.
Если на удаленном менеджере с полным репозиторием расположен полный репозиторий только одного кластера – того, к которому текущий менеджер подключается, или для каждого из тех кластеров, полными репозиториями которых он управляет, менеджер имеет собственные объекты – кластерные receiver-каналы, заполните атрибут CLUSTER названием кластера.
Если в составе менеджера очередей с полным репозиторием, напротив, описан общий объект – кластерный receiver-канал для нескольких кластеров, к которым текущий менеджер должен быть подключен, определите объект – список имен с названиями последних, перечислив их как значение атрибута списка названий NAMES. Укажите имя объекта – списка имен в атрибуте CLUSNL объекта– кластерного sender-канала.
Задайте любые дополнительные атрибуты, к примеру конфигурацию SSL, которые необходимы определению кластерного receiver-канала на менеджере очередей с полным репозиторием.
Примечание Если подключающийся к кластеру менеджер является менеджером с полным репозиторием, а число прочих имеющихся в составе кластера полных репозиториев больше, чем единица, явно определите кластерные sender-каналы ко всем остальным менеджерам очередей сообщений с полным репозиторием кластера.
Наконец, менеджер очередей сообщений становится членом кластера и, пользуясь атрибутами "кластер" ( CLUSTER ) и "список названий кластеров" ( CLUSNL ) объектов, может организовывать общий доступ к объектам-очередям в кластере. При этом существующие объекты-очереди могут меняться, а новые – определяться впервые.Примечание До успешного окончания процесса подключения к кластеру в экранной выдаче команд DISPLAY CLUSQMGR и папке Clusters в WebSphere MQ Explorer вы увидите элементы вида:SYSTEM.TEMPQMGR.hostname(port)
Обратите на них внимание, если менеджер с полным репозиторием, явный кластерный sender-канал к которому вы описали, функционирует, имеет работающий на верном сетевом порту слушатель и уже введен в состав кластера. Если вы видите подобные элементы, тщательно проверьте атрибуты описанных кластерных канальных объектов и убедитесь, что слушатели настроены на правильные порты на каждом из менеджеров. Общие сведения об устранении проблем мы приведем в разделе 12.3.3 "Общие проблемы при построении инфраструктуры".
8.3.4. Этапы удаления менеджера из кластера
Теперь опишем ручные операции удаления менеджера из кластера. Для кластеров, не использующих списки имен в определениях каналов или атрибутах репозиториев менеджеров, перечисленные здесь действия также можно осуществить при помощи мастеров WebSphere MQ Explorer.
С применением мастеров WebSphere MQ Explorer
Для доступа к мастеру Remove Queue Manager from Cluster в составе WebSphere MQ Explorer используйте следующие шаги.
Под значком кластера на панели навигации в папке Queue Manager Clusters найдите соответствующий менеджеру значок. Его местом расположения окажется папка Full Repositories или Partial Repositories.
Щелкните правой кнопкой мыши по найденному значку и выберите в меню Remove Queue Manager From Cluster.
Операции, выполняемые вручную
Чтобы вручную удалить менеджер из кластера менеджеров, произведите следующую работу.
Если удаляемый менеджер содержит полный репозиторий, убедитесь, что еще два полных репозитория остаются в составе кластера.Примечание Если это не так, подключите к кластеру новый менеджер очередей с полным репозиторием прежде, чем перейдете к удалению существующего.
Если удаляемый менеджер содержит полный репозиторий, сообщите всем менеджерам очередей внутри кластера, что тот больше не управляет его полным репозиторием. Для этого:если в составе менеджера хранится репозиторий только одного кластера, очистите атрибут REPOS или REPOSNL объекта – менеджера очередей сообщений, выбрав для удаления значения тот атрибут, в котором оно содержится;Примечание В командах MQSC пустое значение должно записываться в одинарных кавычках:ALTER QMGR REPOS(' ')
если в составе менеджера хранится репозиторий нескольких кластеров, а он должен быть удален только из одного, модифицируйте заданный в атрибуте менеджера REPOSNL объект – список так, чтобы исключить данный кластер из перечня.
Произведите приостановку менеджера очередей, как описано в разделе 8.3.1 "Приостановка и возобновление работы менеджера очередей в кластере".
Сообщите менеджерам из кластера, что данный менеджер покидает его состав. Для этого:если послуживший для подключения кластерный receiver-канал использовался для подключения только к одному кластеру, очистите атрибут CLUSTER или CLUSNL объекта – кластерного receiver-канала, выбрав для удаления значения тот атрибут, в котором оно содержится;Примечание В командах MQSC пустое значение должно записываться в одинарных кавычках:ALTER CHANNEL('TO.QmgrName') CHLTYPE(CLUSRCVR) CLUSTER(' ')
если послуживший для подключения кластерный receiver-канал использовался для подключения к нескольким кластерам, а должен быть удален только из одного, модифицируйте заданный в атрибуте CLUSNL объекта – кластерного receiver-канала объект-список так, чтобы исключить данный кластер из перечня.
Выполните команду останова канала объекта – кластерного receiver-канала, который применялся при подключении менеджера очередей к кластеру. К примеру, в MQSC используйте следующую команду:STOP CHANNEL('TO.QmgrName')
Примечание По окончании этого шага любое сообщение, отосланное менеджеру очередей через кластер, останется в кластерной транспортной очереди менеджера-источника. Поэтому, прежде чем запустить указанную команду, дождитесь прекращения поступления менеджеру новых сообщений. Менеджеры из кластера уже "знают" о его удалении, а значит, алгоритмы балансировки нагрузки перестанут присылать новые сообщения в его адрес.
Если на протяжении этих этапов атрибут "кластер" или "список названий кластеров" был очищен, а потребности в кластерном receiver-канале для повторного подключения менеджера очередей к кластеру не возникнет, объект – кластерный receiver-канал может быть удален.
Если послуживший для подключения кластерный sender-канал использовался для подключения менеджера очередей только к одному кластеру, на этом шаге он может быть остановлен и удален. В противном случае для удаления ссылки на кластер из определения кластерного sender-канала или списка имен, в которых она содержится, следуйте процедуре, описанной для кластерного receiver-канала.
Выполните команду обновления кластера, из которого удаляется менеджер. Тем самым вы гарантируете очистку информации о кластере из репозитория этого менеджера очередей.Примечание Если покидающий кластер менеджер содержит полный репозиторий, возможно существование ведущих к этому менеджеру, явно описанных частичными репозиториями кластерных sender-каналов сообщений. В этом случае опишите на менеджерах частичных репозиториев новые объекты – кластерные каналы, направленные к оставшемуся полному репозиторию кластера, и удалите старый объект – кластерный sender-канал. Иначе такие менеджеры не смогут, если потребуется, покинуть кластер и снова войти в него в будущем. В числе прочих действий выполните команду REFRESH CLUSTER с параметром REPOS(YES).
8.4. Балансировка нагрузки
Мощнейшей из возможностей кластеров является балансировка нагрузки. Она дает возможность разместить службу в составе нескольких менеджеров очередей внутри кластера, распределяя запросы от обращающихся к ней приложений по экземплярам службы, – прозрачно для работы программ.
Производительность размещенных в кластере служб может эффективно наращиваться расширением ресурсов инфраструктуры. Новые запросы от приложений, подключившихся к менеджерам в составе кластера для того, чтобы воспользоваться предложенными им службами, автоматически адресуются новым машинам, где выполняются эти службы и менеджеры.
Автоматически обнаруживая, что менеджер очередей недоступен, балансировка нагрузки может обеспечить и высокую готовность реализуемых служб, новые запросы которых распределяются по оставшимся доступными менеджерам очередей внутри кластера.
Чтобы воспользоваться преимуществами балансировки нагрузки, особой настройки кластера не потребуется. Чтобы добавить в кластер экземпляр службы, подключите новый менеджер очередей, после чего откройте совместный доступ к очереди, представляющей службу, распознаваемую по имени очереди. Все менеджеры очередей внутри кластера, которые обращались – или в будущем обратятся – к названию этой очереди из кластера, автоматически получили или получат уведомление о вновь созданном экземпляре. С момента уведомления об экземпляре менеджеры могут посылать ему сообщения.
Выбор определенного экземпляра, которому будет адресовано сообщение, осуществляется менеджером, обычно с частичным репозиторием, к которому подключено приложение-отправитель.
При первом же обращении к очереди с определенным названием приложением, подключенным к менеджеру очередей он оформляет на полном репозитории подписку на информацию об имеющихся в составе кластера экземплярах интересующей очереди. В дальнейшем менеджер автоматически информируется об изменении экземпляров, их удалении или их добавлении.
Чтобы получить преимущества от балансировки нагрузки, приложение не должно задавать название конкретного менеджера при открытии очереди функцией MQOPEN.
Примечание Если при открытии очереди название менеджера указано, то в целях балансировки нагрузки можно воспользоваться описанными в разделе 8.1.7 "Совместный доступ к объектам-очередям в кластерах" объектами-очередями сообщений. Так часто и поступают с сообщениями, приходящими от менеджеров очередей извне кластера, когда агент-получатель открывает очередь, пользуясь названием менеджера, заданным в заголовке транспортной очереди.
8.4.1. Работа с привязкой при открытии и без фиксированной привязки
В процессе своего выполнения приложение может отослать множество сообщений, адресованных одной службе, реализованной внутри кластера и распознаваемой по названию очереди.
Нередко каждое сообщение может направляться различным экземплярам упомянутой службы, и это не окажет отрицательного воздействия на работу программы, инициировавшей запрос. Если служба-получатель сообщений действует по модели "запрос – ответ", каждое посланное отправителем сообщение содержит явное указание на то, кому конкретно служба должна ответить, и контекста в ее работе не требуется. Такой порядок функционирования очень эффективен с позиции балансировки нагрузки и может повышать устойчивость приложения к недоступности отдельного экземпляра интересующей службы.
Однако ведущийся двумя приложениями обмен может иметь характер диалога по схеме "запрос – ответ – запрос и т. д.", которая основана на контексте, сформированном предыдущими сообщениями. Взаимосвязь между ними называют сродством сообщений (message affinity). При наличии такового приложению может понадобиться привязка (bind) к конкретному экземпляру службы в составе кластера. Для обеспечения привязки приложение может явно указать одну из двух опций менеджера при открытии очереди.
Привязка при открытии.Все сообщения, отсылаемые при помощи описателя, полученного от функции MQOPEN, и до момента вызова MQCLOSE, направляются одному и тому же входящему в кластер экземпляру очереди сообщений. Балансировка нагрузки выполняется лишь однажды – при открытии очереди со стороны приложения.
Без фиксированной привязки.Балансировка нагрузки производится каждый раз, когда, используя описатель объекта, приложение размещает сообщение в очереди.
Поведение по умолчанию определяется атрибутом "привязка по умолчанию" ( DEFBIND – default bind) экземпляра очереди сообщений, входящего в состав кластера и выбранного при вызове MQOPEN. Этот атрибут задается в объекте очереди, разделяемом внутри кластера и расположенном на менеджере, который создал этот объект и обеспечил совместный доступ к нему из кластера.
Примечание Существующим приложениям, в которых применяется функция MQPUT1 или вызовы MQOPEN и MQCLOSE для размещения каждого сообщения, не удастся воспользоваться преимуществами привязки при открытии. Такие приложения необходимо модифицировать для многократного размещения сообщений с применением одного описателя или – что еще лучше – устранения сродства сообщений.
8.4.2. Алгоритм балансировки нагрузки
Каждый раз, когда менеджер выбирает место назначения сообщений в кластере по названию очередей, вызывается встроенный в него алгоритм балансировки нагрузки.
Упрощенно – при настройках по умолчанию и успешном установлении канала к каждому менеджеру очередей внутри кластера – балансировку нагрузки можно рассматривать как круговое распределение сообщений. В результате если приложение без привязки разместило 1000 сообщений, а на 10 кластерных менеджерах размещено 10 одноименных очередей, то приложениям на этих очередях под управлением каждого из 10 менеджеров поступит около 100 сообщений.
Впрочем, эта оценка не точна и зависит от многих факторов. В этом разделе мы только в общих чертах опишем, как работает алгоритм балансировки нагрузки и как можно его настроить, используя возможности WebSphere MQ V6.0. Подробности процесса выработки решения алгоритмом при каждом вызове такового читайте в руководстве WebSphere MQ Queue Manager Clusters, SC34-6589.
8.4.3. Порядковые номера мест назначения сообщений
Для выполнения кругового алгоритма балансировки менеджер очередей сообщений локально хранит порядковый номер места назначения сообщения для каждого известного ему кластерного менеджера очередей.
Примечание Присвоение номеров ведется на уровне кластерных каналов сообщений, однако в большинстве ситуаций каждый подобный известный менеджеру канал соответствует одному менеджеру очередей в кластере.
Алгоритм балансировки нагрузки отдает предпочтение такому подходящему менеджеру очередей назначения, порядковый номер которого наименьший.
Порядковый номер места назначения возрастает всякий раз, когда этому менеджеру поступает сообщение через кластер. Увеличение номеров не зависит от конкретной очереди, а значит, сообщения, приходящие экземпляру очереди с одним названием, влияют на балансировку нагрузки, создаваемой сообщениями из этого кластера, адресованными экземплярам очередей с другими названиями, но под управлением того же самого менеджера. Сюда относится и передача команд другим менеджерам для поддержания актуальности данных в репозиториях кластера, и указание конкретного менеджера очередей сообщений при отправке таковых приложениями.
В условиях настройки по умолчанию увеличение номера одинаково при передаче каждого сообщения. Поэтому в описанном выше элементарном примере сообщения распределяются равномерно.
Однако существует ряд других обстоятельств, влияющих на работу алгоритма балансировки нагрузки. Обсуждению таких факторов мы и посвятим окончание этой главы.
Расположим влияющие на алгоритм факторы в том порядке, в котором их анализирует алгоритм. Порядковый номер места назначения сообщения окажется в этом случае лишь последним, поскольку он обеспечивает балансировку только для подходящих мест назначения – "кандидатов".
Примечание Контроль порядковых номеров во время его работы ведется менеджером очередей сообщений WebSphere MQ V6.0. Задача менеджера – учитывать происходящие изменения, к примеру возобновление работы менеджеров очередей внутри кластера. Сброс порядковых номеров всех каналов без исключения можно принудительно провести, перезапустив менеджер.
8.4.4. Блокировка очереди на запись
Если обобществленная в кластере очередь блокирована на запись, информация об этом публикуется и передается всем заинтересованным в ней менеджерам очередей кластера.
Попытки отослать сообщение блокированным на запись экземплярам очередей предпринимаются лишь тогда, когда все прочие экземпляры очередей в кластере недоступны.
Примечание Если сообщения явно передаются данному менеджеру, а никаких прочих доступных экземпляров очередей с соответствующим названием в кластере не находится, сообщения доставляются этому менеджеру. Их обработкой занимается MCA-получатель, о чем рассказано в разделе 7.4.1 "Отправка сообщений".
8.4.5. Балансировка нагрузки и локальное размещение очередей
Если подключенное к менеджеру очередей приложение размещает сообщение, указав имя объекта – локальной очереди в составе своего менеджера, по умолчанию всегда используется локальный экземпляр очереди, если он не является заблокированным на запись.
В WebSphere MQ V6.0 поведение по умолчанию можно изменить для того, чтобы, задействовав балансировку нагрузки, обращаться с локальной и удаленными очередями кластера одинаково.
Поведение по умолчанию для всех очередей менеджера можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) объекта – менеджера очередей сообщений.
На уровне очереди принятое для всего менеджера поведение по умолчанию можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) конкретной локальной очереди сообщений.
8.4.6. Ранг менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджеры очередей в кластере могут ранжироваться заданием или изменением атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Пока в кластере существуют экземпляры очередей с соответствующим названием и разрешенной записью, экземпляры очередей на менеджерах с бо'льшим рангом при выборе всегда имеют приоритет над экземплярами на менеджерах с меньшим рангом.
Отдельные экземпляры очередей также могут ранжироваться при помощи атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки ранг отдельных очередей принимается во внимание после анализа ранга менеджеров.
Ранжирование способно принудительно выбрать итоговое место назначения в кластере. Оно полезно в процессе объединения нескольких кластеров и описания соединяющих их маршрутов. Ранжирование полезно для описания порядка маршрутизации сообщений между объединенными кластерами и выбора оптимального места назначения сообщений.
8.4.7. Приостановка менеджеров очередей в кластере
Если входящий в кластер менеджер приостановлен, как это описано в разделе 8.3.1 "Приостановка и возобновление работы менеджера очередей в кластере", то алгоритм балансировки нагрузки выбирает другие менеджеры, предпочитая их данному.
Приступая к плановому обслуживанию определенного менеджера, полезно обеспечить отсутствие адресуемых ему сообщений от приложений, которые не должны присылать их до тех пор, пока он снова не станет для них доступен.
Впрочем, если других доступных экземпляров очереди с соответствующим названием нет, сообщения будут по-прежнему поступать на приостановленный менеджер.
8.4.8. Состояние канала
Предпочтение перед другими при выборе имеют экземпляры очередей менеджеров, каналы к которым уже запущены или стали естественно неактивны.
Если такие экземпляры не обнаружены, выбираются экземпляры под управлением тех менеджеров, каналы к которым находятся в процессе установления.
Если найти их не удается, выбираются менеджеры очередей сообщений, каналы к которым ранее дали сбой и находятся в процессе повторного подключения. Того момента, когда канал будет перезапущен, сообщения ожидают в кластерной транспортной очереди.
Если экземпляры очередей находятся только в составе менеджеров, каналы к которым требуют перезапуска ручным способом, включая остановленные каналы, сообщения должны отсылаться подобным менеджерам и оставаться в транспортной очереди, пока ручной запуск каналов не будет произведен.
Такое поведение позволяет автоматически обходить сбои отдельных кластерных менеджеров.
8.4.9. Приоритет менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджерам очередей внутри кластера может назначаться приоритет, для чего задается или меняется атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Экземплярам очередей под управлением менеджера с бо'льшим приоритетом при выборе обычно отдается предпочтение над экземплярами очередей менеджера с меньшим приоритетом.
Однако в тех случаях, когда менеджер, имеющий больший приоритет, почему-либо считается недоступным, выбираются экземпляры очередей менеджера, приоритет которого меньше. Так нужные менеджеры могут оказаться приостановлены, или каналы к ним могут дать сбой.
Приоритет отдельных экземпляров очередей может устанавливать атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки приоритет отдельных очередей принимается во внимание после приоритета менеджеров.
Приоритеты позволяют размещать службы на вторичных – или резервных – ресурсах кластера. Такие ресурсы могут находиться на географически удаленных площадках, а значит, медленнее работать. При этом они могут выполнять функцию первичных ресурсов для других служб системы, так что отправка запросов им при нормальной работе ухудшит производительность данных первичных служб. Однако, если на тех ресурсах, где обычно размещена служба, произойдет сбой, резервные ресурсы дадут возможность обеспечить ее доступность.
8.4.10. Ограничение кластерных подключений от менеджера
Если к службе системы обращается множество приложений, а в целях управления нагрузкой организован ряд ее экземпляров, распределение нагрузки всех приложений по всем существующим экземплярам может оказаться неэффективным. Оно может привести к ситуации, когда количество активных каналов на каждом управляющем службой менеджере очередей сообщений будет достаточно велико.
WebSphere MQ V6.0 позволяет ограничить число участвующих в балансировке нагрузки экземпляров на одном менеджере. В итоге прочие экземпляры останутся не затронуты балансировкой по порядковым номерам.
Предельное значение определяется максимальным числом каналов, которые можно установить от одного менеджера в кластере к другим. Непосредственно для настройки служит атрибут "количество недавно использованных каналов менеджера кластерной балансировки нагрузки" ( CWMRUC – cluster workload manager recently used channel) объекта – менеджера очередей сообщений.
Установив предел для всех менеджеров, которые обращаются к службе, вы сможете сократить и количество одновременно установленных каналов, ведущих к менеджеру, где она выполняется.
8.4.11. Весовая оценка менеджеров
Одни машины, где работают службы, могут быть мощнее других, а стало быть, в состоянии обслужить больше запросов, чем остальные компьютеры с той же системной службой.
В WebSphere MQ V6.0 менеджерам очередей в кластере могут назначаться веса от 1 до 99, для чего задается или изменяется атрибут "вес кластерной балансировки нагрузки" ( CLWLWGHT – cluster workload weight) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Алгоритм кластерной балансировки нагрузки посылает больше сообщений тем менеджерам, чей вес выше. Количество получаемых ими сообщений пропорционально их весу.
Для получения этого результата алгоритм увеличивает порядковые номера мест назначения всех менеджеров на значение, привязанное к их весу. Чем выше вес менеджера, тем меньше прибавляет алгоритм к номеру, отправляя каждое сообщение. Величина приращения есть частное от деления 1000 на вес определенного менеджера.
К примеру, пусть нам доступны два менеджера очередей сообщений с весами 60 и 20, а номера мест назначения одинаковы. Между очередями с одним названием под управлением этих менеджеров распределим четыре сообщения. Три из них будут адресованы менеджеру, вес которого 60, и лишь одно – менеджеру, вес которого 20. Причина этого в том, что оба номера назначения станут больше на 50:
(1000 / 60) . 3 = 50;
(1000 / 20) . 1 = 50.
В этой лекции мы обсудим следующие вопросы:
Обзор понятий кластеризации
Просмотр сведений о репозиториях кластеров
Работа с менеджерами очередей в кластере
Балансировка нагрузки
8.1. Обзор понятий кластеризации
Все менеджеры очередей в кластере располагают сведениями о том, какими ресурсами наделен кластер, причем ресурсы в его составе не требуют явного локального описания. Добавлять в кластер новые ресурсы, например менеджеры и очереди, которыми они управляют, вы можете динамически, автоматически делая их доступными для пользования всем менеджерам очередей сообщений, которые входят в кластер.
Это дает возможность добавлять в кластер или удалять из него дополнительные ресурсы аппаратуры с учетом меняющейся нагрузки на инфраструктуру очередей сообщений WebSphere MQ.
Менеджер очередей может являться членом нескольких кластеров, что позволяет подразделять компоненты инфраструктуры WebSphere MQ по характеру служб или организовывать группы. Менеджеры могут выступать в роли связующего звена между кластерами, а также между кластером и имеющейся инфраструктурой WebSphere MQ на основе распределенных каналов сообщений.
Примечание В процессе реализации новой инфраструктуры как базу для ее построения рекомендуется использовать кластер.
Для получения присущих кластерам преимуществ в виде дополнительной балансировки нагрузки и высокой готовности существующая инфраструктура может расширяться через создание связей между нею самой и расширенной инфраструктурой на базе кластера.
Изложенное в данной главе представление о кластерах кому-то покажется изначально сложным для понимания. Однако эти идеи приведут нас к такой инфраструктуре менеджеров очередей сообщений, администрировать которую значительно проще, чем построенную с использованием распределенных каналов, что и показывают практические примеры из раздела 10.4 "Создание кластеров менеджеров очередей".
Увеличиваясь в масштабе, такая инфраструктура может охватить тысячи менеджеров.
Примечание Вплоть до конца главы понятием "кластер" (cluster ) мы будем пользоваться, называя так кластеры менеджеров очередей сообщений. Не путайте его с кластерами высокой готовности – понятием, характерным не только для WebSphere MQ, о котором мы говорили в разделе 3.6 "Высокая готовность системы".
8.1.1. Менеджеры очередей с полным и частичным репозиторием
Любой менеджер очередей сообщений содержит репозиторий (repository) с данными о кластерах, в которых он состоит.
Каждый менеджер внутри кластера можно настроить так, чтобы он содержал частичный или полный репозиторий. Суть полных и частичных репозиториев такова.
Полный репозиторий.Содержит данные обо всех совместных ресурсах кластера. В их число входят все менеджеры и все объекты очередей в кластере, которые используются совместно. Для каждого кластера в составе инфраструктуры обычно настроено ровно два менеджера очередей сообщений, имеющих полный репозиторий.
Менеджер, содержащий полный репозиторий с представлением кластера, называется менеджером очередей с полным репозиторием (full repository queue manager).
Частичный репозиторий.Содержит информацию о менеджерах очередей с полным репозиторием кластера. В частичный репозиторий входят сведения лишь о тех объектах очередей и менеджерах с частичным репозиторием, которые необходимы самому менеджеру. Если подключенное к нему приложение попытается открыть очередь, название которой неизвестно для менеджера, то при попытке поиска указанного ресурса будут опрошены менеджеры очередей с полным репозиторием всех кластеров, где данный менеджер состоит.
Менеджер, содержащий частичный репозиторий своего кластера, называется менеджером очередей с частичным репозиторием (partial repository queue manager).
Для вхождения в кластер менеджер очередей должен "знать" его полный репозиторий. Поэтому каждый кластер обязан содержать два или более менеджера, в которых такой репозиторий будет храниться. Именно эти два менеджера очередей с полным репозиторием изначально и образуют кластер, организуя соединение между собой.
Иметь в составе кластера более двух полных репозиториев, как правило, не рекомендуется потому, что полный репозиторий содержит всю информацию о каждом из ресурсов, входящих в кластер, а значит, должен регулярно обмениваться сведениями с другими полными репозиториями. Увеличение же их числа повысит нагрузку на инфраструктуру из-за того, что обмен станет более интенсивным.
8.1.2. Названия кластеров
Любой кластер имеет свое название. Имена кластеров могут содержать до 48 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов ".", "/", "_", "%". Полезными могут оказаться короткие имена кластеров, длина которых позволит включать их в описание всех кластерных канальных объектов.
8.1.3. Настройка менеджера очередей с полным репозиторием
Примечание Этот шаг рекомендуется выполнить до того, как менеджер очередей будет подключен к кластеру с использованием описанных в этом разделе объектов кластерных sender- и receiver-каналов сообщений.
Для задания кластеров, полный репозиторий с информацией о которых содержит текущий менеджер, служат атрибуты объекта-менеджера "репозиторий" ( REPOS – repository) и "список названий репозиториев" ( REPOSNL – repository namelist).
Атрибут REPOS позволяет определить имя только одного кластера.
Атрибут REPOSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере объекта – списка имен. Определите объект-список так, чтобы он содержал перечень названий интересующих кластеров.
Примечание Поддержание полного репозитория кластера может оказаться причиной заметной вычислительной работы на менеджере, вызванной тем, что кластер может содержать множество менеджеров или очередей под управлением таковых. По этой причине мы советуем отказаться от размещения на менеджерах очередей с полным репозиторием служб, представляемых кластером.Если эта машина все-таки выделена для размещения служб, рекомендуем определить на ней ряд других менеджеров. Для размещения менеджеров с полным репозиторием крупных кластеров может оказаться разумным выделить отдельное оборудование.
Также рекомендуем не размещать оба менеджера с полным репозиторием на одной и той же машине. Поскольку менеджеры очередей с частичным репозиторием кластера могут по-прежнему получать о нем информацию, если одна машина даст сбой или окажется недоступной, разделив менеджеры, вы избежите возникновения в кластере единой точки отказа.
8.1.4. Кластерные каналы сообщений
Вся информация в кластере передается по кластерным каналам сообщений (cluster message channels). Это справедливо и для тех случаев, когда приложение отправляет сообщение во входящую в кластер очередь и когда менеджер запрашивает в полном репозитории информацию о ресурсах в составе кластера.
Кластерные и распределенные каналы сообщений очень напоминают друг друга. И те и другие передают сообщения из транспортной очереди на одном менеджере в очередь, управляемую другим менеджером из кластера. Однако важное различие между ними состоит в том, что все сообщения, отправляемые через кластерные каналы, посылаются из одной общей транспортной очереди. Название этой автоматически задаваемой на любом менеджере во время создания очереди:
SYSTEM.CLUSTER.TRANSMIT.QUEUE
Все сообщения, адресуемые менеджерам очередей в кластере, будут размещены в этой очереди сообщений автоматически.
WebSphere MQ автоматически создает и запускает кластерные каналы сообщений, когда в них возникает необходимость. Это означает, что после того, как менеджер подключается к кластеру, дальнейшее администрирование каналов вручную уже не требуется.
Кластерные каналы сообщений используют агенты каналов сообщений (MCA) отправления и получения и обладают теми же возможностями, что и любой распределенный канал. К примеру, они имеют интервалы разъединения, поддерживают пакетную обработку и записи состояния канала, могут пользоваться аутентификацией SSL. Описание распределенных каналов и передачи сообщений между MCA-отправителем и MCA-получателем см. в разделе 7.4 "Распределенные каналы сообщений".
Начальный шаг подключения менеджера очередей к кластеру должен производиться вручную. При вхождении в кластер менеджер задает атрибуты, которые любой другой менеджер очередей в кластере должен будет использовать для того, чтобы установить с ним соединение.
С этой целью в WebSphere MQ введены объекты – кластерные каналы. Они могут определяться в составе менеджера для инициирования процесса подключения его к кластеру.
8.1.5. Кластерные receiver-каналы
Объекты – кластерные receiver-каналы описывают атрибуты, которыми, определяя кластерные sender-каналы сообщений, адресованных текущему менеджеру, должны пользоваться все входящие в один или несколько кластеров менеджеры очередей сообщений.
Чтобы сообщить менеджерам очередей с полным репозиторием о менеджере, в составе которого описан кластерный receiver-канал, он публикуется внутри кластера. Это означает отправку сведений о нем в один из полных репозиториев кластера, который передаст их остальным менеджерам очередей с полным репозиторием. Полные репозитории, в свою очередь, опубликуют это определение на менеджерах с частичным репозиторием в этом кластере, как только те запросят ресурсы, которыми этот менеджер управляет.
Объекты – кластерные receiver-каналы описывают название и атрибуты, которыми во время установления направленного к данному менеджеру канала от других менеджеров пользуются как MCA-отправитель, так и MCA-получатель.
Так, в кластерном receiver-канале задан интервал разъединения кластерных каналов сообщений. Им пользуется каждый MCA-отправитель, производящий подключение к менеджеру.
Поскольку ряд атрибутов, к примеру конфигурация SSL, должен совпадать у агентов отправления и получения, администрирование может существенно упроститься. Работая с кластером, достаточно настроить лишь атрибуты одного менеджера, который подключается к кластеру, а не обоих – на каждом из концов подключения.
Чтобы вручную задать объекты – кластерные receiver-каналы, используйте один из следующих методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSRCVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Cluster-receiver Channel.
Обязательный атрибут – название соединения ( CONNAME ) с объектом – кластерным receiver-каналом. Значением атрибута должно являться название хоста или IP-адрес и порт, где выполняется слушатель того менеджера очередей сообщений, в составе которого описан этот объект. Именно этим названием соединения будут пользоваться другие менеджеры очередей в кластере, устанавливая связь с данным менеджером очередей сообщений.
Для задания кластеров, к которым применимо описание канала, служат атрибуты объекта – кластерного receiver-канала "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
Выход из кластера осуществляется самим менеджером очередей сообщений и происходит, если атрибут CLUSTER или CLUSNL receiver-канала, через который менеджер был подключен к кластеру, изменяется и больше не указывает на кластер или если название кластера удаляется из объекта списка имен, название которого задано в атрибуте CLUSNL того же кластерного receiver-канала.
Примечание Используя список названий кластеров (CLUSNL), менеджер очередей сообщений может опубликовать кластерный receiver-канал сразу в нескольких кластерах, что позволяет каналам, направленным к этому менеджеру в каждом из них, иметь одинаковое название. Канальные объекты такого типа обычно именуют следующим образом:TO.названиеменеджера
Другой подход заключается в публикации менеджером отдельных объектов – кластерных receiver-каналов в каждом кластере, для чего служит атрибут каждого из объектов-каналов CLUSTER. Канальные объекты такого типа обычно именуют следующим образом:TO.названиекластера.названиеменеджера
Второе соглашение об именах сокращает то количество символов, которое допустимо для обозначения менеджера очередей сообщений в 20-символьном названии канала.
8.1.6. Кластерные sender-каналы
Понятие " кластерный sender-канал" нередко служит для описания различных объектов.
Описанного вручную объекта – кластерного sender-канала, или CLUSSDR. Используется при подключении к кластеру для связи с его полным репозиторием.
Кластерного sender-канала, описанного автоматически, – CLUSSDRA – или автоматического кластерного sender-канала с явным определением (auto explicit cluster sender). Автоматически формируются менеджерами очередей сообщений с учетом определений кластерных receiver-каналов, опубликованных множеством входящих в кластер менеджеров для установления связи с ними.
Автоматически описанного кластерного sender-канала, заменяющего кластерный sender-канал, описанный вручную, – CLUSSDRB, – или автоматического кластерного sender-канала (auto cluster sender). Автоматически формируется менеджером очередей сообщений с учетом определения кластерного receiver-канала, опубликованного менеджером очередей с полным репозиторием, для которого объект – кластерный sender-канал был изначально описан при вхождении в кластер.
Вручную, или явно, определенный объект – кластерный sender-канал выполняет лишь одну функцию – начальное установление связи с одним из полных репозиториев во время подключения к кластеру.
Название объекта – кластерного sender-канала, описанного вручную, должно соответствовать названию объекта – кластерного receiver-канала, описанного в составе менеджера очередей с полным репозиторием и опубликованного этим же менеджером при вхождении в кластер.
Аналогично для успешного подключения ряд атрибутов описанного вручную кластерного sender-канала, к примеру конфигурация SSL, должны быть гарантированно корректны.
Чтобы вручную задать объект – кластерный sender-канал, используйте один из следующих методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSSDR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Cluster-sender Channel.
Обязательным атрибутом является название соединения ( CONNAME ) объекта – кластерного канала. Значением атрибута должно служить название хоста или IP-адрес и порт, где выполняется слушатель менеджера очередей с полным репозиторием кластера. При этом не имеет значения, какой именно полный репозиторий выбран. Тем не менее название канала должно соответствовать имени описанного в этом репозитории объекта – кластерного receiver-канала.
Для задания кластеров, в которых описание канала может использоваться для связи с полным репозиторием, служат атрибуты объекта – кластерного sender-канала "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
При описании объекта – кластерного sender-канала через него в полном репозитории публикуются любые объекты – кластерные receiver-каналы, что вызывает начало автоматического процесса установления членства менеджера в указанных кластерах.
Результатом осуществления такого процесса для каждого кластера является то, что определение кластерного receiver-канала сохраняется во всех полных репозиториях кластера. В них также заносятся и определения любых объектов-очередей, коллективный доступ к которым обеспечивает подключающийся к кластеру менеджер очередей сообщений. В свою очередь, менеджер получает представление обо всех полных репозиториях кластера.
По окончании описанного процесса явно определенный кластерный sender-канал более не используется. В дальнейшем менеджер очередей пользуется определениями кластерных receiver-каналов, совместный доступ к которым имеют все менеджеры очередей кластера. Это позволяет установить каналы ко всем менеджерам очередей сообщений с полным и частичным репозиторием. Аналогично и эти менеджеры очередей могут установить каналы к данному менеджеру, используя обобществленное в кластере определение кластерного receiver-канала.
Примечание Если в кластере существует более двух менеджеров очередей с полным репозиторием, кластерные sender-каналы должны быть заданы явно по схеме "из каждого полного репозитория – в каждый". Причина этого в том, что полные репозитории кластера получают информацию только от тех других полных репозиториев, с которыми они связаны явно определенным кластерным sender-каналом.Менеджерам очередей с частичным репозиторием достаточно одного явного кластерного sender-канала независимо от числа имеющихся в составе кластера менеджеров очередей с полным репозиторием. Описание на менеджере очередей с частичным репозиторием более одного явного кластерного sender-канала не дает никаких преимуществ.
8.1.7. Совместный доступ к объектам-очередям в кластерах
Менеджеры очередей с полным и частичным репозиторием в кластере могут пользоваться объектами-очередями кластера коллективно.
Это дает возможность автоматически распространять сведения об объектах-очередях по всем менеджерам очередей в кластере. Например, приложение, подключенное к одному менеджеру, может разместить сообщение в локальной очереди другого, причем сама очередь может совместно использоваться всем кластером без указания названия этого удаленного менеджера.
Совместный доступ допускают следующие типы объектов-очередей.
Объекты локальных очередей:Чаще всего совместный доступ в кластерах организуется именно к ним. Обобществление локальных очередей позволяет приложению, подключенному к любому менеджеру очередей в кластере, поместить сообщение в очередь, которая используется этим менеджером совместно с другим, указав только название очереди во время ее открытия.
Примечание Осуществить в кластере совместный доступ к динамически сформированным локальным очередям посредством коллективного пользования определением модельной очереди, на базе которой они построены, невозможно.Однако, если приложение размещает сообщение в очереди с произвольным названием с указанием конкретного менеджера, который является членом кластера, сообщение доставляется этому менеджеру. Сказанное означает, что приложение может послать ответ в динамически организованную очередь для ответов, используя название очереди ответов и ее менеджера, указанные в дескрипторе сообщения-запроса. Название менеджера очереди ответов автоматически подставляется тем менеджером очередей сообщений, к которому было подключено приложение-инициатор запроса.
В итоге приложения могут производить обмен сообщениями по принципу "запрос – ответ" со службой на основе разделяемой очереди в составе кластера аналогично тому, как если бы эта очередь находилась под управлением менеджера, к которому подключено приложение.
Объекты очередей-псевдонимов.Наличие в кластере очереди-псевдонима с совместным доступом позволяет менеджеру очередей сообщений обобществить в нем имеющийся в составе менеджера объект-очередь под другим именем. Локальное по отношению к менеджеру название очереди определяется атрибутом "целевая (базовая) очередь" ( TARGQ/base queue ), названием же объекта очереди-псевдонима служит название, под которым очередь доступа в составе кластера.
Объекты удаленных очередей.Совместный доступ к различным типам входящих в кластер объектов удаленных очередей, описанных в разделе 6.2.5 "Объекты удаленных очередей", дает различные результаты. Типичные примеры их использования следующие.
Локальное определение удаленной очереди.Предоставляет входящим в кластер менеджерам возможность совместно использовать очередь сообщений, находящуюся вне кластера, то есть в составе менеджера, который не является его членом. Названием объекта удаленной очереди является название, под которым организован совместный доступ к ней внутри кластера. Название целевой очереди в составе менеджера очередей назначения определяется атрибутом "удаленное имя" ( RNAME ), название управляющего ею менеджера – атрибутом "название удаленного менеджера очередей сообщений" ( RQMNAME ). Название транспортной очереди менеджера, на котором описана удаленная очередь, может быть задано атрибутом "транспортная очередь" ( XMITQ ) или по умолчанию принято равным названию удаленного менеджера.
Псевдоним менеджера очередей сообщений.В данном случае атрибут RNAME объекта удаленной очереди остается пустым. При этом возможны две ситуации.
Внутри кластера менеджер очередей может выбрать альтернативное имя. Им станет название обобществленного в кластере объекта удаленной очереди; реальное же название менеджера будет указано в атрибуте "название удаленного менеджера очередей сообщений" ( RQMNAME ).
Название менеджера вне кластера может быть известно внутри него, а транспортная очередь к этому менеджеру – задаваться в составе менеджера очередей сообщений, предоставляющего совместный доступ к определению объекта удаленной очереди. Название, под которым менеджер очередей сообщений должен быть известен в составе кластера, – это название обобществленного в нем объекта удаленной очереди. Название менеджера очередей вне кластера определяется атрибутом RQMNAME. Название транспортной очереди менеджера внутри кластера, если оно отлично от названия менеджера очередей за пределами такового, задается атрибутом XMITQ.
Примечание Еще один полезный способ применения объектов удаленных очередей в кластере – описание в составе менеджера очередей псевдонима с пустым значением атрибута "удаленное имя" ( RNAME ) без разделения объекта удаленной очереди в кластере.Такая схема ведет к балансировке нагрузки, создаваемой сообщениями, поступающими этому менеджеру очередей извне кластера и содержащими конкретное название менеджера очередей сообщений.
Совместно пользоваться объектами-очередями с одним названием и одного или разных типов в одном кластере могут, располагая этими типами объектов-очередей, сразу несколько менеджеров. Об этом мы еще скажем в разделе 8.4 "Балансировка нагрузки".
Для задания кластеров, в которых к объекту организован совместный доступ, служат атрибуты объектов-очередей "кластер" ( CLUSTER – cluster) и "список названий кластеров" ( CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Определите объект-список так, чтобы он содержал перечень интересующих кластеров.
8.1.8. Идентификатор менеджера очередей (QMID)
При создании каждого менеджера очередей сообщений для него строится идентификатор менеджера QMID (queue manager identifier), значение которого определяют время создания и название менеджера. В этих условиях вероятность того, что два менеджера получат одинаковые QMID, очень невелика, даже если они будут названы одинаково.
Уникальность QMID позволяет различать менеджеры очередей в кластере, неповторяемость их названий для этого не используется. Два менеджера очередей сообщений с одинаковыми названиями вряд ли будут включены в кластер умышленно, и делать это определенно не стоит. Однако почему-либо менеджер может быть пересоздан, например после сбоя аппаратуры. При этом старый менеджер с тем же названием мог не пройти успешное отключение от кластера до присоединения к нему нового. Столкнувшись с подобными ситуациями, кластеру важно иметь возможность различать первый и второй менеджер.
Если это произошло и в кластере оказалось несколько менеджеров с одинаковыми названиями, то, приступая к разрешению ситуации, изучите документацию по команде MQSC RESET CLUSTER ACTION(FORCEREMOVE).
Примечание Описанные в ней действия предпринимайте только после прочтения соответствующих разделов в WebSphere MQ Queue Manager Clusters, SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.1.9. Подписки и публикации в кластере
В этом разделе мы коротко расскажем о том, как полные и частичные репозитории кластера поддерживают актуальную информацию, что послужит основой для понимания сведений, получаемых при просмотре той информации о кластере, которая в них содержится.
Все полные репозитории кластера общаются между собой, и это позволяет им обеспечить поддержание полной и одинаковой информации обо всех менеджерах и объектах-очередях в кластере.
Как только к кластеру подключается менеджер с частичным репозиторием, он публикует информацию о себе, включая предоставленную объектом – кластерным receiver-каналом, и адресует ее двум полным репозиториям внутри кластера.
Организуя совместный доступ к объекту очереди внутри кластера, менеджер с частичным репозиторием аналогично публикует сведения об объекте двум полным репозиториям кластера.
Частичный репозиторий повторяет эти публикации каждые 27 дней, что позволяет полным репозиториям убедиться, что менеджер внутри кластера остается активным, а информация – актуальной. Также полным репозиториям адресуются любые публикации с изменениями этих совместно используемых в кластере менеджеров объектов.
Если публикация не повторяется в течение 30 дней, ее срок действия истекает, и на запрос сведений от частичных репозиториев полные репозитории перестают выдавать ее как ответ. Однако на случай временной недоступности менеджера по некоторой причине репозитории сохраняют ее в течение еще 60 дней. Если по окончании периода, длящегося в общей сложности 90 дней, менеджер не повторил публикацию информации, полный репозиторий больше не считает его частью своего кластера. Когда же частичный репозиторий повторно установит связь с полным, он станет известен кластеру снова.
Частичный репозиторий поддерживает сведения лишь о тех менеджерах и объектах очередей кластера, которые ему интересны, в частности:
обо всех менеджерах с полным репозиторием, успешно подключившихся к кластеру;
об объектах-очередях, входящих в кластер и одноименных объектам, обобществленным менеджером очередей внутри кластера;
об объектах-очередях, входящих в кластер под именами, по адресу которых подключенные к менеджеру очередей приложения посылают сообщения;
о менеджерах с частичными репозиториями, под управлением которых находятся известные этому менеджеру объекты очередей.
Для получения информации менеджер с частичным репозиторием производит подписку на сведения от менеджеров с полным репозиторием. В ответ он получает все известные полному репозиторию публикации о соответствующих объектах или уведомление о том, что нужная информация недоступна.
Подписки формируются частичным репозиторием в момент организации коллективного доступа к новому объекту в составе кластера, а также при разрешении названий очередей, когда подключенные к менеджеру очередей приложения пытаются открыть их для размещения сообщений.
Если менеджеру с частичным репозиторием неизвестны названия объектов или менеджеров объектов-очередей, указанные при открытии таковых для размещения сообщений, подписки на информацию от полных репозиториев генерируются для всех кластеров, в которые входит данный частичный репозиторий.
Примечание Открывая неизвестную в частичном репозитории очередь сообщений, менеджер может до 10 секунд ждать отклика менеджера очередей с полным репозиторием. Если ожидание безрезультатно, то приложение, которое пытается поместить сообщение в очередь, будет не в состоянии это сделать. По этой причине возможность в любой момент времени установить связь хотя бы с одним из полных репозиториев кластера чрезвычайно важна.
Подписки имеют ограниченный 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). Заметим, что, как показано в разделе 8.4 "Балансировка нагрузки", для упрощения балансировки нагрузки в пределах кластера обобществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблокирована на запись.
Примечание Эта же команда MQSC, поданная в частичном репозитории, может не вернуть полный список общих кластерных очередей кластера, что связано с обстоятельствами, рассмотренными нами в разделе 8.1.9 "Подписки и публикации в кластере".
DISPLAY CLUSQMGR.Команда выводит информацию об известных менеджеру очередей сообщений менеджерах очередей в кластере. Так, запуск следующей команды в полном репозитории кластера покажет всю известную информацию обо всех менеджерах очередей кластера:
DISPLAY CLUSQMGR(*) CLUSTER('Cluster.Name') ALL
Каждую выводимую при этом на экран запись называют записью кластерного менеджера очередей (cluster queue manager), или CLUSQMGR-записью. Одна из них содержит данные о локальном менеджере очередей сообщений, работая с которым вы запустили команду. Информация в этой записи содержит в себе название и подробное описание относящегося к данному менеджеру кластерного канала сообщений. Им может оказаться объект – кластерный receiver-канал локального менеджера или любой из типов кластерных sender-каналов из раздела 8.1.6 "Кластерные sender-каналы". Тип кластерного канала сообщений представлен атрибутом "тип описания" ( DEFTYPE – definition type) записи кластерного менеджера очередей и содержит информацию о состоянии кластерных sender-каналов данного менеджера, ведущих к остальным менеджерам очередей внутри кластера.
Примечание Для получения информации о каналах, направленных к данному менеджеру очередей сообщений и установленных с помощью обобществленного в кластере определения кластерного receiver-канала используйте команду DISPLAY CHSTATUS. Направленные к менеджеру активные кластерные каналы могут иметь несколько менеджеров в кластере одновременно, причем название кластерного receiver-канала окажется одинаковым. Запись кластерного менеджера очередей может представлять каналы к менеджеру как неактивные в тот момент, когда на самом деле они реально работают.
Запись кластерного менеджера очередей также содержит подробные сведения о менеджере очередей сообщений, в том числе его QMID, и информацию о том, является ли он полным репозиторием кластера. В записи о полном репозитории атрибут "тип менеджера очередей" ( QMTYPE – queue manager type) принимает значение REPOS, в записи о частичном – значение NORMAL.
Примечание Эта же команда MQSC, поданная в частичном репозитории, может не вернуть полного списка менеджеров очередей в кластере, но должна показать все полные репозитории в нем. Такое поведение команды связано с обстоятельствами, рассмотренными в разделе 8.1.9 "Подписки и публикации в кластере".
Если при подключении к кластеру не удается запустить заданный вручную кластерный sender-канал, ведущий в полный репозиторий, название в записи кластерного менеджера очередей примет следующий вид:
SYSTEM.TEMPQMGR.hostname(port)
Здесь hostname(port) – название соединения в описании канала. Подобный формат обусловлен тем, что имя менеджера очередей сообщений невозможно установить, пока канал к нему не будет успешно пущен.
8.2.2. Просмотр сведений из репозитория в WebSphere MQ Explorer
Для представления информации из репозитория кластера в WebSphere MQ Explorer имеется папка Queue Manager Clusters в навигаторе инструмента.
Как только WebSphere MQ Explorer подключается к менеджеру из папки Queue Managers с полным репозиторием кластера, обозначения кластеров появляются в папке Queue Manager Clusters автоматически. Менеджеры, представляющие собой полные репозитории кластера, могут находиться на той же машине, что WebSphere MQ Explorer, или быть подключенными к нему удаленно.
Примечание WebSphere MQ Explorer не показывает информацию о кластерах, для которых подключенные из папки Queue Managers менеджеры очередей являются частичными репозиториями.Причина этого в том, что менеджеры с частичным репозиторием не содержат достаточно сведений о кластере для того, чтобы надежно установить информацию обо всех менеджерах очередей в нем, как было сказано в разделе 8.1.9 "Подписки и публикации в кластере".
Под каждым из значков кластера в навигаторе будут отображаться две папки.
Full Repositories.Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, которые входят в кластер и содержат его полные репозитории. Значок каждого менеджера очередей с полным репозиторием кластера расположен уровнем ниже.
Partial Repositories.Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, которые входят в кластер и содержат его частичные репозитории. Значок каждого менеджера очередей с частичным репозиторием кластера расположен уровнем ниже.
Папка Queue Manager Clusters в WebSphere MQ Explorer показана на рис 8.1. Взятый как пример кластер содержит четыре менеджера, локально работающих на машине с WebSphere MQ Explorer. Два менеджера содержат полный и два – частичный репозиторий.
(рис 8.1) Папка Queue Manager Clusters в WebSphere MQ ExplorerЕсли к WebSphere MQ Explorer подключено несколько менеджеров очередей с полными репозиториями одного кластера, WebSphere MQ Explorer выбирает один из них, чтобы сформировать содержимое папок кластера – Full Repositories и Partial Repositories. Используемый для этого менеджер называют источником кластерной информации.
Все полные репозитории менеджеров содержат идентичную информацию, о чем упоминалось в разделе 8.1.9 "Подписки и публикации в кластере". Тем не менее, если менеджер отключается от сети, или ведущие к нему кластерные каналы блокируются, в его полном репозитории может оказаться не вся необходимая информация о менеджерах очередей кластера. В этих условиях источником кластерной информации может стать другой менеджер, также содержащий полный репозиторий и подключенный из папки Queue Managers. Для его выбора выделите значок кластера в навигаторе и щелкните по кнопке Select на странице содержимого Cluster.
Просмотр репозитория единичного менеджера
После запроса источника кластерной информации для получения сведений о менеджерах очередей – членах кластера на экран может быть выведена информация из частичного или полного репозитория каждого входящего в кластер менеджера.
Если в папках Full Repositories или Partial Repositories определенного кластера выбрать конкретный менеджер, откроется страница содержимого с информацией, которую данный менеджер содержит в своем репозитории.
Информация на этой странице будет запрашиваться у менеджера, который вы выбрали, а не в источнике кластерной информации.
Если в папке Queue Managers удаленный менеджер не показан, хранящуюся в его репозитории информацию о кластере вы все же можете просмотреть. Значок менеджера будет изначально вам недоступен, а представленные таблицы не будут содержать данных. Для установления через кластер соединения с этим менеджером и вывода информации на экран щелкните правой кнопкой по недоступному значку менеджера в папке Partial Repositories или Full Repositories кластера в навигаторе и выберите Connect To Queue Manager.
Примечание Подключение к менеджеру для вывода данных репозитория, не показанному в используемой папке Queue Managers, происходит не напрямую, а посредством отправки и получения сообщений от него через кластер. Соединение, которым пользуется WebSphere MQ Explorer, адресовано выбранному для текущего кластера источнику кластерной информации.Чтобы это подключение было успешным, менеджер очередей сообщений, для которого нужно произвести вывод кластерной информации, должен иметь работающий командный сервер. Кроме того, должна быть возможна связь с этим менеджером очередей через кластер, реализующий двухсторонний обмен с выбранным как источник кластерной информации менеджером очередей с полным репозиторием. Если целевой менеджер не запущен, не работает его командный сервер, возникает ошибка авторизации или дает сбой соединение через кластер, выводимая на экран ошибка обычно имеет вид:
Command server not responding within timeout period. (AMQ4032)
Отображаемая после успешного подключения к менеджеру информация на странице содержимого репозитория делится на три вкладки.
Cluster Queues.Содержит сведения обо всех совместно используемых кластерами экземплярах объектов-очередей, о которых известно менеджеру. Информация идентична той, которая выводится на экран при запуске для данного менеджера команды MQSC DISPLAY QCLUSTER.
Каждый разделяемый внутри кластера экземпляр объекта очереди называют кластерной очередью (cluster queue). Заметим, что, как показано в разделе 8.4 "Балансировка нагрузки", для упрощения балансировки нагрузки в пределах кластера обобществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблокирована на запись.
Количество совместно используемых в кластере объектов-очередей, информация о которых хранится в репозитории менеджера, графически представлено над таблицей.
Каждой кластерной очереди в таблице отведено по строке. Столбцы таблицы показывают атрибуты записи данных о такой очереди. Дважды щелкнув по самой записи, вы увидите атрибуты записи в окне свойств.
Примечание Менять значения атрибутов объекта, представленного записью о кластерной очереди, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Чтобы изменить атрибуты, обязательно подключите менеджер очередей сообщений к WebSphere MQ из папки Queue Managers. Затем выберите в навигаторе папку Queues конкретного менеджера и дважды щелкните по разделяемому в кластере объекту очереди в таблице.
Cluster-sender channels.Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для всех удаленных менеджеров очередей кластера. Это записи обо всех известных данному менеджеру очередей сообщений менеджерах очередей в кластере, для связи с которыми он использует кластерный sender-канал. Типы таких каналов мы обсуждали в разделе 8.1.6 "Кластерные sender-каналы".
Для каждого менеджера очередей в кластере, известного текущему менеджеру, в таблице отводится по строке. Каждой строкой таблицы представлен направленный к менеджеру, работающий или способный работать кластерный sender-канал. Это – запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке. Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 "Просмотр сведений из репозитория через MQSC".
Примечание Менять значения атрибутов любых канальных объектов, к которым относятся записи кластерных менеджеров очередей, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Обсуждаемые здесь записи, хотя и показывают кластерные sender-каналы, как правило, представляют автоматически заданные каналы, созданные на основе кластерных receiver-каналов, которые описаны менеджером очередей сообщений при подключении к кластеру. Подробнее об этом см. в разделе 8.1.5 "Кластерные receiver-каналы". Вручную объекты – кластерные sender-каналы создаются только при подключении к кластеру для связи с полным репозиторием такового. Подробности см. в разделе 8.1.6 "Кластерные sender-каналы".
Cluster-receiver channels.Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для локального менеджера. Обычно это всего одна запись. Она содержит ту информацию, которая была опубликована менеджером очередей сообщений при подключении к кластеру и является описанием кластерного receiver-канала. Подробности читайте в разделе 8.1.5 "Кластерные receiver-каналы". Обычно эта таблица содержит одну строку, которая свидетельствует о публикации данным менеджером единственного объекта – кластерного receiver-канала. Это запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке.
Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 "Просмотр сведений из репозитория через MQSC".
Примечание Менять значения атрибутов канального объекта, к которому относится запись кластерного менеджера очередей, из окна свойств нельзя. Это справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue Managers.Применение кластерных receiver-каналов при подключении к кластеру мы обсуждали в разделе 8.1.5 "Кластерные receiver-каналы".
8.3. Работа с менеджерами очередей в кластере
Этот раздел главы посвящен описанию общих действий, выполняемых в ходе администрирования или создания кластера менеджеров очередей сообщений. Процедура администрирования относительно несложна, однако чтобы остальные менеджеры очередей в кластере не содержали ложную информацию о данном менеджере очередей сообщений, а подключение к нему в кластере возможно установить, должна правильно выполняться.
8.3.1. Приостановка и возобновление работы менеджера очередей в кластере
Приостановка работы менеджера очередей в кластере отлична от его удаления. В результате приостановки доставка сообщений очередям, совместный доступ к которым в кластере организует текущий менеджер, становится практически невозможной. Она существенно сокращает вероятность того, что контролирующий работу остальных менеджеров алгоритм балансировки нагрузки выберет доставку сообщений очередям текущего менеджера. Вопросы балансировки нагрузки мы обсудим в разделе 8.4 "Балансировка нагрузки".
Приостановка работы менеджера очередей не мешает тому, чтобы специально предназначенные ему сообщения поступали к нему из кластера.
После выполнения приостановки работу менеджера можно снова возобновить.
Чтобы произвести приостановку или возобновление работы менеджера очередей в кластере, используйте один из следующих методов.
Для целей приостановки или возобновления работы менеджера очередей в одном кластере – команды MQSC SUSPEND QMGR CLUSTER или RESUME QMGR CLUSTER.
Для целей приостановки или возобновления работы менеджера очередей в нескольких кластерах – команды MQSC SUSPEND QMGR CLUSNL или RESUME QMGR CLUSNL.
WebSphere MQ Explorer:для выполнения приостановки менеджера с частичным репозиторием полный репозиторий кластера должен быть подключен из папки Queue Managers навигатора;
откройте в навигаторе папку Queue Manager Clusters ;
разверните дерево навигатора под значком с тем же названием, что и кластер;
в зависимости от того, полный или частичный репозиторий кластера содержит текущий менеджер, разверните в навигаторе папку Full Repositories или Partial Repositories ;
щелкните в навигаторе правой кнопкой по значку, одноименному менеджеру.Если работу менеджера в кластере необходимо остановить, выберите в меню Suspend Cluster Membership.
Если работу менеджера в кластере необходимо возобновить, выберите в меню Resume Cluster Membership. Заметим, что этот пункт доступен только в том случае, если менеджер в кластере был ранее приостановлен.
8.3.2. Сброс членства менеджера очередей в кластере
Для удаления из кластера всей информации о менеджере и обеспечения возможности нового запуска менеджера очередей в нем без выхода и повторного подключения воспользуйтесь командой MQSC RESET CLUSTER.
Это действие также доступно из WebSphere MQ Explorer, где нужно щелкнуть правой кнопкой мыши по значку менеджера очередей интересующего вас кластера.
Примечание Предпринимайте это действие только после прочтения соответствующих разделов руководства WebSphere MQ Queue Manager Clusters, SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.3.3. Этапы подключения менеджера очередей к кластеру
Опишем в этом разделе ручные операции добавления менеджера в существующий кластер или формирования нового. Для кластеров, не использующих списки имен в определениях каналов или атрибутах репозиториев менеджеров, перечисленные здесь действия также можно осуществить при помощи мастеров WebSphere MQ Explorer.
С применением мастеров WebSphere MQ Explorer
В мастерах WebSphere MQ Explorer создание кластера и добавление менеджера очередей в существующих – это разные операции. И в первом и во втором случае менеджеры очередей должны быть предварительно созданы и запущены, а также подключены к WebSphere MQ в папке Queue Managers.
Для доступа к мастеру создания кластера Create Cluster:
Убедитесь, что оба изначально образующих кластер менеджера очередей с полным репозиторием существуют и подключены из папки Queue Managers.
Щелкните правой кнопкой по расположенной в дереве навигатора папке Queue Manager Clusters.
Выберите в меню New -> Queue manager cluster.
Для доступа к мастеру добавления в кластер Add to cluster:
Убедитесь, что полный репозиторий кластера подключен к WebSphere MQ Explorer из папки Queue Managers.
Убедитесь, что из этой папки подключен и вводимый в состав кластера менеджер.
В представленной в навигаторе папке Queue Manager Clusters щелкните правой кнопкой по тому кластеру, к которому подключается менеджер.
Выберите в меню Add Queue Manager To Cluster.
Операции, выполняемые вручную
Чтобы вручную добавить менеджер в существующий кластер или сформировать новый, произведите следующую работу.
Убедитесь в том, что для менеджера описан слушатель на конкретный сетевой порт, а имя хоста или IP-адрес машины, где размещается менеджер, известны и доступны всем остальным менеджерам очередей в кластере.Примечание Не используйте имя хоста, равное localhost, и IP-адрес 127.0.0.1, так как они действуют только на локальной машине.
Убедитесь в том, что известно название подключения к полному репозиторию кластера, включая имя хоста или IP-адрес машины с менеджером и порт, на который настроен слушатель. Если эти шаги касаются одного из пары исходных менеджеров очередей с полным репозиторием, то речь идет о названии соединения с другим менеджером очередей сообщений, который содержит – или может содержать – полный репозиторий кластера.Примечание Если текущим менеджером планируется заменить прежний полный репозиторий, рекомендуем выбрать название соединения того полного репозитория кластера, который в нем остается.
Если текущий менеджер должен содержать полный репозиторий одного кластера, установите атрибут REPOS объекта-менеджера очередей сообщений равным названию такового.Если менеджер очередей должен содержать полные репозитории нескольких кластеров, определите объект – список имен с занесенными в атрибут NAMES названиями всех кластеров. Укажите название объекта – списка имен в атрибуте REPOSNL объекта – менеджера очередей сообщений.
Определите объект – кластерный receiver-канал, описав в нем порядок обращения к текущему менеджеру остальных менеджеров очередей внутри кластера.В атрибуте CONNAME задайте название соединения для связи с тем менеджером, который подключается к кластеру.
Если кластерный receiver-канал планируется использовать для подключения только к одному кластеру, заполните его названием атрибут CLUSTER.
Если один объект – кластерный receiver-канал, напротив, будет использоваться для подключения менеджера к целой серии кластеров, определите объект – список имен с названиями последних, перечислив их в атрибуте списка названий NAMES. Укажите имя объекта – списка имен в атрибуте CLUSNL объекта – кластерного receiver-канала.
Задайте любые дополнительные атрибуты, такие как интервал разъединения, размер пакета или конфигурация SSL, которыми должны пользоваться менеджеры очередей внутри кластера, отправляя сообщения вводимому в его состав менеджеру.
Определите объект – кластерный sender-канал, чтобы описать подключение к существующему полному репозиторию кластера, или выберите другой описанный менеджер очередей с полным репозиторием.В атрибуте CONNAME задайте название соединения для связи с тем менеджером, где расположен полный репозиторий кластера.
Если на удаленном менеджере с полным репозиторием расположен полный репозиторий только одного кластера – того, к которому текущий менеджер подключается, или для каждого из тех кластеров, полными репозиториями которых он управляет, менеджер имеет собственные объекты – кластерные receiver-каналы, заполните атрибут CLUSTER названием кластера.
Если в составе менеджера очередей с полным репозиторием, напротив, описан общий объект – кластерный receiver-канал для нескольких кластеров, к которым текущий менеджер должен быть подключен, определите объект – список имен с названиями последних, перечислив их как значение атрибута списка названий NAMES. Укажите имя объекта – списка имен в атрибуте CLUSNL объекта– кластерного sender-канала.
Задайте любые дополнительные атрибуты, к примеру конфигурацию SSL, которые необходимы определению кластерного receiver-канала на менеджере очередей с полным репозиторием.
Примечание Если подключающийся к кластеру менеджер является менеджером с полным репозиторием, а число прочих имеющихся в составе кластера полных репозиториев больше, чем единица, явно определите кластерные sender-каналы ко всем остальным менеджерам очередей сообщений с полным репозиторием кластера.
Наконец, менеджер очередей сообщений становится членом кластера и, пользуясь атрибутами "кластер" ( CLUSTER ) и "список названий кластеров" ( CLUSNL ) объектов, может организовывать общий доступ к объектам-очередям в кластере. При этом существующие объекты-очереди могут меняться, а новые – определяться впервые.Примечание До успешного окончания процесса подключения к кластеру в экранной выдаче команд DISPLAY CLUSQMGR и папке Clusters в WebSphere MQ Explorer вы увидите элементы вида:SYSTEM.TEMPQMGR.hostname(port)
Обратите на них внимание, если менеджер с полным репозиторием, явный кластерный sender-канал к которому вы описали, функционирует, имеет работающий на верном сетевом порту слушатель и уже введен в состав кластера. Если вы видите подобные элементы, тщательно проверьте атрибуты описанных кластерных канальных объектов и убедитесь, что слушатели настроены на правильные порты на каждом из менеджеров. Общие сведения об устранении проблем мы приведем в разделе 12.3.3 "Общие проблемы при построении инфраструктуры".
8.3.4. Этапы удаления менеджера из кластера
Теперь опишем ручные операции удаления менеджера из кластера. Для кластеров, не использующих списки имен в определениях каналов или атрибутах репозиториев менеджеров, перечисленные здесь действия также можно осуществить при помощи мастеров WebSphere MQ Explorer.
С применением мастеров WebSphere MQ Explorer
Для доступа к мастеру Remove Queue Manager from Cluster в составе WebSphere MQ Explorer используйте следующие шаги.
Под значком кластера на панели навигации в папке Queue Manager Clusters найдите соответствующий менеджеру значок. Его местом расположения окажется папка Full Repositories или Partial Repositories.
Щелкните правой кнопкой мыши по найденному значку и выберите в меню Remove Queue Manager From Cluster.
Операции, выполняемые вручную
Чтобы вручную удалить менеджер из кластера менеджеров, произведите следующую работу.
Если удаляемый менеджер содержит полный репозиторий, убедитесь, что еще два полных репозитория остаются в составе кластера.Примечание Если это не так, подключите к кластеру новый менеджер очередей с полным репозиторием прежде, чем перейдете к удалению существующего.
Если удаляемый менеджер содержит полный репозиторий, сообщите всем менеджерам очередей внутри кластера, что тот больше не управляет его полным репозиторием. Для этого:если в составе менеджера хранится репозиторий только одного кластера, очистите атрибут REPOS или REPOSNL объекта – менеджера очередей сообщений, выбрав для удаления значения тот атрибут, в котором оно содержится;Примечание В командах MQSC пустое значение должно записываться в одинарных кавычках:ALTER QMGR REPOS(' ')
если в составе менеджера хранится репозиторий нескольких кластеров, а он должен быть удален только из одного, модифицируйте заданный в атрибуте менеджера REPOSNL объект – список так, чтобы исключить данный кластер из перечня.
Произведите приостановку менеджера очередей, как описано в разделе 8.3.1 "Приостановка и возобновление работы менеджера очередей в кластере".
Сообщите менеджерам из кластера, что данный менеджер покидает его состав. Для этого:если послуживший для подключения кластерный receiver-канал использовался для подключения только к одному кластеру, очистите атрибут CLUSTER или CLUSNL объекта – кластерного receiver-канала, выбрав для удаления значения тот атрибут, в котором оно содержится;Примечание В командах MQSC пустое значение должно записываться в одинарных кавычках:ALTER CHANNEL('TO.QmgrName') CHLTYPE(CLUSRCVR) CLUSTER(' ')
если послуживший для подключения кластерный receiver-канал использовался для подключения к нескольким кластерам, а должен быть удален только из одного, модифицируйте заданный в атрибуте CLUSNL объекта – кластерного receiver-канала объект-список так, чтобы исключить данный кластер из перечня.
Выполните команду останова канала объекта – кластерного receiver-канала, который применялся при подключении менеджера очередей к кластеру. К примеру, в MQSC используйте следующую команду:STOP CHANNEL('TO.QmgrName')
Примечание По окончании этого шага любое сообщение, отосланное менеджеру очередей через кластер, останется в кластерной транспортной очереди менеджера-источника. Поэтому, прежде чем запустить указанную команду, дождитесь прекращения поступления менеджеру новых сообщений. Менеджеры из кластера уже "знают" о его удалении, а значит, алгоритмы балансировки нагрузки перестанут присылать новые сообщения в его адрес.
Если на протяжении этих этапов атрибут "кластер" или "список названий кластеров" был очищен, а потребности в кластерном receiver-канале для повторного подключения менеджера очередей к кластеру не возникнет, объект – кластерный receiver-канал может быть удален.
Если послуживший для подключения кластерный sender-канал использовался для подключения менеджера очередей только к одному кластеру, на этом шаге он может быть остановлен и удален. В противном случае для удаления ссылки на кластер из определения кластерного sender-канала или списка имен, в которых она содержится, следуйте процедуре, описанной для кластерного receiver-канала.
Выполните команду обновления кластера, из которого удаляется менеджер. Тем самым вы гарантируете очистку информации о кластере из репозитория этого менеджера очередей.Примечание Если покидающий кластер менеджер содержит полный репозиторий, возможно существование ведущих к этому менеджеру, явно описанных частичными репозиториями кластерных sender-каналов сообщений. В этом случае опишите на менеджерах частичных репозиториев новые объекты – кластерные каналы, направленные к оставшемуся полному репозиторию кластера, и удалите старый объект – кластерный sender-канал. Иначе такие менеджеры не смогут, если потребуется, покинуть кластер и снова войти в него в будущем. В числе прочих действий выполните команду REFRESH CLUSTER с параметром REPOS(YES).
8.4. Балансировка нагрузки
Мощнейшей из возможностей кластеров является балансировка нагрузки. Она дает возможность разместить службу в составе нескольких менеджеров очередей внутри кластера, распределяя запросы от обращающихся к ней приложений по экземплярам службы, – прозрачно для работы программ.
Производительность размещенных в кластере служб может эффективно наращиваться расширением ресурсов инфраструктуры. Новые запросы от приложений, подключившихся к менеджерам в составе кластера для того, чтобы воспользоваться предложенными им службами, автоматически адресуются новым машинам, где выполняются эти службы и менеджеры.
Автоматически обнаруживая, что менеджер очередей недоступен, балансировка нагрузки может обеспечить и высокую готовность реализуемых служб, новые запросы которых распределяются по оставшимся доступными менеджерам очередей внутри кластера.
Чтобы воспользоваться преимуществами балансировки нагрузки, особой настройки кластера не потребуется. Чтобы добавить в кластер экземпляр службы, подключите новый менеджер очередей, после чего откройте совместный доступ к очереди, представляющей службу, распознаваемую по имени очереди. Все менеджеры очередей внутри кластера, которые обращались – или в будущем обратятся – к названию этой очереди из кластера, автоматически получили или получат уведомление о вновь созданном экземпляре. С момента уведомления об экземпляре менеджеры могут посылать ему сообщения.
Выбор определенного экземпляра, которому будет адресовано сообщение, осуществляется менеджером, обычно с частичным репозиторием, к которому подключено приложение-отправитель.
При первом же обращении к очереди с определенным названием приложением, подключенным к менеджеру очередей он оформляет на полном репозитории подписку на информацию об имеющихся в составе кластера экземплярах интересующей очереди. В дальнейшем менеджер автоматически информируется об изменении экземпляров, их удалении или их добавлении.
Чтобы получить преимущества от балансировки нагрузки, приложение не должно задавать название конкретного менеджера при открытии очереди функцией MQOPEN.
Примечание Если при открытии очереди название менеджера указано, то в целях балансировки нагрузки можно воспользоваться описанными в разделе 8.1.7 "Совместный доступ к объектам-очередям в кластерах" объектами-очередями сообщений. Так часто и поступают с сообщениями, приходящими от менеджеров очередей извне кластера, когда агент-получатель открывает очередь, пользуясь названием менеджера, заданным в заголовке транспортной очереди.
8.4.1. Работа с привязкой при открытии и без фиксированной привязки
В процессе своего выполнения приложение может отослать множество сообщений, адресованных одной службе, реализованной внутри кластера и распознаваемой по названию очереди.
Нередко каждое сообщение может направляться различным экземплярам упомянутой службы, и это не окажет отрицательного воздействия на работу программы, инициировавшей запрос. Если служба-получатель сообщений действует по модели "запрос – ответ", каждое посланное отправителем сообщение содержит явное указание на то, кому конкретно служба должна ответить, и контекста в ее работе не требуется. Такой порядок функционирования очень эффективен с позиции балансировки нагрузки и может повышать устойчивость приложения к недоступности отдельного экземпляра интересующей службы.
Однако ведущийся двумя приложениями обмен может иметь характер диалога по схеме "запрос – ответ – запрос и т. д.", которая основана на контексте, сформированном предыдущими сообщениями. Взаимосвязь между ними называют сродством сообщений (message affinity). При наличии такового приложению может понадобиться привязка (bind) к конкретному экземпляру службы в составе кластера. Для обеспечения привязки приложение может явно указать одну из двух опций менеджера при открытии очереди.
Привязка при открытии.Все сообщения, отсылаемые при помощи описателя, полученного от функции MQOPEN, и до момента вызова MQCLOSE, направляются одному и тому же входящему в кластер экземпляру очереди сообщений. Балансировка нагрузки выполняется лишь однажды – при открытии очереди со стороны приложения.
Без фиксированной привязки.Балансировка нагрузки производится каждый раз, когда, используя описатель объекта, приложение размещает сообщение в очереди.
Поведение по умолчанию определяется атрибутом "привязка по умолчанию" ( DEFBIND – default bind) экземпляра очереди сообщений, входящего в состав кластера и выбранного при вызове MQOPEN. Этот атрибут задается в объекте очереди, разделяемом внутри кластера и расположенном на менеджере, который создал этот объект и обеспечил совместный доступ к нему из кластера.
Примечание Существующим приложениям, в которых применяется функция MQPUT1 или вызовы MQOPEN и MQCLOSE для размещения каждого сообщения, не удастся воспользоваться преимуществами привязки при открытии. Такие приложения необходимо модифицировать для многократного размещения сообщений с применением одного описателя или – что еще лучше – устранения сродства сообщений.
8.4.2. Алгоритм балансировки нагрузки
Каждый раз, когда менеджер выбирает место назначения сообщений в кластере по названию очередей, вызывается встроенный в него алгоритм балансировки нагрузки.
Упрощенно – при настройках по умолчанию и успешном установлении канала к каждому менеджеру очередей внутри кластера – балансировку нагрузки можно рассматривать как круговое распределение сообщений. В результате если приложение без привязки разместило 1000 сообщений, а на 10 кластерных менеджерах размещено 10 одноименных очередей, то приложениям на этих очередях под управлением каждого из 10 менеджеров поступит около 100 сообщений.
Впрочем, эта оценка не точна и зависит от многих факторов. В этом разделе мы только в общих чертах опишем, как работает алгоритм балансировки нагрузки и как можно его настроить, используя возможности WebSphere MQ V6.0. Подробности процесса выработки решения алгоритмом при каждом вызове такового читайте в руководстве WebSphere MQ Queue Manager Clusters, SC34-6589.
8.4.3. Порядковые номера мест назначения сообщений
Для выполнения кругового алгоритма балансировки менеджер очередей сообщений локально хранит порядковый номер места назначения сообщения для каждого известного ему кластерного менеджера очередей.
Примечание Присвоение номеров ведется на уровне кластерных каналов сообщений, однако в большинстве ситуаций каждый подобный известный менеджеру канал соответствует одному менеджеру очередей в кластере.
Алгоритм балансировки нагрузки отдает предпочтение такому подходящему менеджеру очередей назначения, порядковый номер которого наименьший.
Порядковый номер места назначения возрастает всякий раз, когда этому менеджеру поступает сообщение через кластер. Увеличение номеров не зависит от конкретной очереди, а значит, сообщения, приходящие экземпляру очереди с одним названием, влияют на балансировку нагрузки, создаваемой сообщениями из этого кластера, адресованными экземплярам очередей с другими названиями, но под управлением того же самого менеджера. Сюда относится и передача команд другим менеджерам для поддержания актуальности данных в репозиториях кластера, и указание конкретного менеджера очередей сообщений при отправке таковых приложениями.
В условиях настройки по умолчанию увеличение номера одинаково при передаче каждого сообщения. Поэтому в описанном выше элементарном примере сообщения распределяются равномерно.
Однако существует ряд других обстоятельств, влияющих на работу алгоритма балансировки нагрузки. Обсуждению таких факторов мы и посвятим окончание этой главы.
Расположим влияющие на алгоритм факторы в том порядке, в котором их анализирует алгоритм. Порядковый номер места назначения сообщения окажется в этом случае лишь последним, поскольку он обеспечивает балансировку только для подходящих мест назначения – "кандидатов".
Примечание Контроль порядковых номеров во время его работы ведется менеджером очередей сообщений WebSphere MQ V6.0. Задача менеджера – учитывать происходящие изменения, к примеру возобновление работы менеджеров очередей внутри кластера. Сброс порядковых номеров всех каналов без исключения можно принудительно провести, перезапустив менеджер.
8.4.4. Блокировка очереди на запись
Если обобществленная в кластере очередь блокирована на запись, информация об этом публикуется и передается всем заинтересованным в ней менеджерам очередей кластера.
Попытки отослать сообщение блокированным на запись экземплярам очередей предпринимаются лишь тогда, когда все прочие экземпляры очередей в кластере недоступны.
Примечание Если сообщения явно передаются данному менеджеру, а никаких прочих доступных экземпляров очередей с соответствующим названием в кластере не находится, сообщения доставляются этому менеджеру. Их обработкой занимается MCA-получатель, о чем рассказано в разделе 7.4.1 "Отправка сообщений".
8.4.5. Балансировка нагрузки и локальное размещение очередей
Если подключенное к менеджеру очередей приложение размещает сообщение, указав имя объекта – локальной очереди в составе своего менеджера, по умолчанию всегда используется локальный экземпляр очереди, если он не является заблокированным на запись.
В WebSphere MQ V6.0 поведение по умолчанию можно изменить для того, чтобы, задействовав балансировку нагрузки, обращаться с локальной и удаленными очередями кластера одинаково.
Поведение по умолчанию для всех очередей менеджера можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) объекта – менеджера очередей сообщений.
На уровне очереди принятое для всего менеджера поведение по умолчанию можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) конкретной локальной очереди сообщений.
8.4.6. Ранг менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджеры очередей в кластере могут ранжироваться заданием или изменением атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Пока в кластере существуют экземпляры очередей с соответствующим названием и разрешенной записью, экземпляры очередей на менеджерах с бо'льшим рангом при выборе всегда имеют приоритет над экземплярами на менеджерах с меньшим рангом.
Отдельные экземпляры очередей также могут ранжироваться при помощи атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки ранг отдельных очередей принимается во внимание после анализа ранга менеджеров.
Ранжирование способно принудительно выбрать итоговое место назначения в кластере. Оно полезно в процессе объединения нескольких кластеров и описания соединяющих их маршрутов. Ранжирование полезно для описания порядка маршрутизации сообщений между объединенными кластерами и выбора оптимального места назначения сообщений.
8.4.7. Приостановка менеджеров очередей в кластере
Если входящий в кластер менеджер приостановлен, как это описано в разделе 8.3.1 "Приостановка и возобновление работы менеджера очередей в кластере", то алгоритм балансировки нагрузки выбирает другие менеджеры, предпочитая их данному.
Приступая к плановому обслуживанию определенного менеджера, полезно обеспечить отсутствие адресуемых ему сообщений от приложений, которые не должны присылать их до тех пор, пока он снова не станет для них доступен.
Впрочем, если других доступных экземпляров очереди с соответствующим названием нет, сообщения будут по-прежнему поступать на приостановленный менеджер.
8.4.8. Состояние канала
Предпочтение перед другими при выборе имеют экземпляры очередей менеджеров, каналы к которым уже запущены или стали естественно неактивны.
Если такие экземпляры не обнаружены, выбираются экземпляры под управлением тех менеджеров, каналы к которым находятся в процессе установления.
Если найти их не удается, выбираются менеджеры очередей сообщений, каналы к которым ранее дали сбой и находятся в процессе повторного подключения. Того момента, когда канал будет перезапущен, сообщения ожидают в кластерной транспортной очереди.
Если экземпляры очередей находятся только в составе менеджеров, каналы к которым требуют перезапуска ручным способом, включая остановленные каналы, сообщения должны отсылаться подобным менеджерам и оставаться в транспортной очереди, пока ручной запуск каналов не будет произведен.
Такое поведение позволяет автоматически обходить сбои отдельных кластерных менеджеров.
8.4.9. Приоритет менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджерам очередей внутри кластера может назначаться приоритет, для чего задается или меняется атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Экземплярам очередей под управлением менеджера с бо'льшим приоритетом при выборе обычно отдается предпочтение над экземплярами очередей менеджера с меньшим приоритетом.
Однако в тех случаях, когда менеджер, имеющий больший приоритет, почему-либо считается недоступным, выбираются экземпляры очередей менеджера, приоритет которого меньше. Так нужные менеджеры могут оказаться приостановлены, или каналы к ним могут дать сбой.
Приоритет отдельных экземпляров очередей может устанавливать атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки приоритет отдельных очередей принимается во внимание после приоритета менеджеров.
Приоритеты позволяют размещать службы на вторичных – или резервных – ресурсах кластера. Такие ресурсы могут находиться на географически удаленных площадках, а значит, медленнее работать. При этом они могут выполнять функцию первичных ресурсов для других служб системы, так что отправка запросов им при нормальной работе ухудшит производительность данных первичных служб. Однако, если на тех ресурсах, где обычно размещена служба, произойдет сбой, резервные ресурсы дадут возможность обеспечить ее доступность.
8.4.10. Ограничение кластерных подключений от менеджера
Если к службе системы обращается множество приложений, а в целях управления нагрузкой организован ряд ее экземпляров, распределение нагрузки всех приложений по всем существующим экземплярам может оказаться неэффективным. Оно может привести к ситуации, когда количество активных каналов на каждом управляющем службой менеджере очередей сообщений будет достаточно велико.
WebSphere MQ V6.0 позволяет ограничить число участвующих в балансировке нагрузки экземпляров на одном менеджере. В итоге прочие экземпляры останутся не затронуты балансировкой по порядковым номерам.
Предельное значение определяется максимальным числом каналов, которые можно установить от одного менеджера в кластере к другим. Непосредственно для настройки служит атрибут "количество недавно использованных каналов менеджера кластерной балансировки нагрузки" ( CWMRUC – cluster workload manager recently used channel) объекта – менеджера очередей сообщений.
Установив предел для всех менеджеров, которые обращаются к службе, вы сможете сократить и количество одновременно установленных каналов, ведущих к менеджеру, где она выполняется.
8.4.11. Весовая оценка менеджеров
Одни машины, где работают службы, могут быть мощнее других, а стало быть, в состоянии обслужить больше запросов, чем остальные компьютеры с той же системной службой.
В WebSphere MQ V6.0 менеджерам очередей в кластере могут назначаться веса от 1 до 99, для чего задается или изменяется атрибут "вес кластерной балансировки нагрузки" ( CLWLWGHT – cluster workload weight) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.
Алгоритм кластерной балансировки нагрузки посылает больше сообщений тем менеджерам, чей вес выше. Количество получаемых ими сообщений пропорционально их весу.
Для получения этого результата алгоритм увеличивает порядковые номера мест назначения всех менеджеров на значение, привязанное к их весу. Чем выше вес менеджера, тем меньше прибавляет алгоритм к номеру, отправляя каждое сообщение. Величина приращения есть частное от деления 1000 на вес определенного менеджера.
К примеру, пусть нам доступны два менеджера очередей сообщений с весами 60 и 20, а номера мест назначения одинаковы. Между очередями с одним названием под управлением этих менеджеров распределим четыре сообщения. Три из них будут адресованы менеджеру, вес которого 60, и лишь одно – менеджеру, вес которого 20. Причина этого в том, что оба номера назначения станут больше на 50:
(1000 / 60) . 3 = 50;
(1000 / 20) . 1 = 50.
