Опубликован: 10.06.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Компания IBM
Лекция 8:

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

< Лекция 7 || Лекция 8: 123456 || Лекция 9 >
Аннотация: Эта лекция дает начальное представление о кластерах менеджеров очередей и показывает, как, пользуясь ими, вы можете сократить объем работы по администрированию инфраструктуры WebSphere MQ и получить дополнительные возможности, позволяющие повысить готовность служб и сбалансировать нагрузку между несколькими экземплярами службы в составе кластера

В этой лекции мы обсудим следующие вопросы:

  • Обзор понятий кластеризации
  • Просмотр сведений о репозиториях кластеров
  • Работа с менеджерами очередей в кластере
  • Балансировка нагрузки

8.1. Обзор понятий кластеризации

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

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

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

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

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

Изложенное в данной главе представление о кластерах кому-то покажется изначально сложным для понимания. Однако эти идеи приведут нас к такой инфраструктуре менеджеров очередей сообщений, администрировать которую значительно проще, чем построенную с использованием распределенных каналов, что и показывают практические примеры из "Построение инфраструктуры WebSphere MQ: практическое руководство" "Создание кластеров менеджеров очередей".

Увеличиваясь в масштабе, такая инфраструктура может охватить тысячи менеджеров.

Примечание Вплоть до конца главы понятием "кластер" (cluster ) мы будем пользоваться, называя так кластеры менеджеров очередей сообщений. Не путайте его с кластерами высокой готовности – понятием, характерным не только для WebSphere MQ, о котором мы говорили в "Средства поддержки очередей сообщений в WebSphere MQ" "Высокая готовность системы".

8.1.1. Менеджеры очередей с полным и частичным репозиторием

Любой менеджер очередей сообщений содержит репозиторий (repository) с данными о кластерах, в которых он состоит.

Каждый менеджер внутри кластера можно настроить так, чтобы он содержал частичный или полный репозиторий. Суть полных и частичных репозиториев такова.

  • Полный репозиторий.

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

    Менеджер, содержащий полный репозиторий с представлением кластера, называется менеджером очередей с полным репозиторием (full repository queue manager).

  • Частичный репозиторий.

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

    Менеджер, содержащий частичный репозиторий своего кластера, называется менеджером очередей с частичным репозиторием (partial repository queue manager).

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

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

8.1.2. Названия кластеров

Любой кластер имеет свое название. Имена кластеров могут содержать до 48 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов ".", "/", "_", "%". Полезными могут оказаться короткие имена кластеров, длина которых позволит включать их в описание всех кластерных канальных объектов.

8.1.3. Настройка менеджера очередей с полным репозиторием

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

Для задания кластеров, полный репозиторий с информацией о которых содержит текущий менеджер, служат атрибуты объекта-менеджера "репозиторий" ( REPOSrepository) и "список названий репозиториев" ( REPOSNLrepository namelist).

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

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

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

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

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

8.1.4. Кластерные каналы сообщений

Вся информация в кластере передается по кластерным каналам сообщений (cluster message channels). Это справедливо и для тех случаев, когда приложение отправляет сообщение во входящую в кластер очередь и когда менеджер запрашивает в полном репозитории информацию о ресурсах в составе кластера.

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

SYSTEM.CLUSTER.TRANSMIT.QUEUE

Все сообщения, адресуемые менеджерам очередей в кластере, будут размещены в этой очереди сообщений автоматически.

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

Кластерные каналы сообщений используют агенты каналов сообщений (MCA) отправления и получения и обладают теми же возможностями, что и любой распределенный канал. К примеру, они имеют интервалы разъединения, поддерживают пакетную обработку и записи состояния канала, могут пользоваться аутентификацией SSL. Описание распределенных каналов и передачи сообщений между MCA-отправителем и MCA-получателем см. в "Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ" "Распределенные каналы сообщений".

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

С этой целью в 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-канала не дает никаких преимуществ.

< Лекция 7 || Лекция 8: 123456 || Лекция 9 >
Михаил Завалко
Михаил Завалко
Беларусь, Минск
Artem Bardakov
Artem Bardakov
Россия