Средства поддержки очередей сообщений в WebSphere MQ

3.2.5. Предоставление услуг в инфраструктуре WebSphere MQ

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

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

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

3.2.6. Очереди WebSphere MQ как интерфейс доступа к службам

Для доступа к службе инфраструктуры очередей сообщений WebSphere MQ приложение требует нижеперечисленной информации.

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

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

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

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

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

3.2.7. Стандартизованные API-интерфейсы

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

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

Подробнее мы рассмотрим их в разделе 4.2.3 "Стандартизованные API-интерфейсы для WebSphere MQ".

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

Например, брокер, реализующий функции публикации-подписки в инфраструктуре WebSphere MQ, может быть обновлен с брокера публикации-подписки WebSphere MQ до WebSphere Business Integration Message Broker или WebSphere Business Integration Event Broker.

WebSphere Business Integration Message Broker и WebSphere Business Integration Event Broker – это независимые системы-брокеры, которые в процессе своей работы задействуют базовую функциональность обмена сообщениями WebSphere MQ и предлагают дополнительные возможности, максимально использующие модель сообщений публикации-подписки.

Широкому распространению этих API могут помочь многочисленные продукты. Так, API-интерфейс JMS – промышленный стандарт на API-интерфейсы обмена сообщениями в спецификации Java 2 Platform Enterprise Edition (J2EE™).

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

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

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

3.2.8. WebSphere MQ и WebSphere Application Server

Такие J2EE-совместимые серверы приложений, как IBM WebSphere Application Server, предоставляют структуру (framework) для разработки и размещения приложений.

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

Одним из множества стандартизованных API-интерфейсов в спецификации J2EE является интерфейс JMS, который описывает API межточечного обмена и приема-передачи сообщений по принципу публикации-подписки. Для обеспечения широкого спектра иных возможностей, в которых также могут нуждаться прикладные продукты, служат прочие интерфейсы. Так, приложение может получить внешний запрос по интерфейсу, доступному через сеть Интернет и Web-браузер, а может самостоятельно послать запрос и обновить информацию в базе данных.

Технологии, реализующие функциональность J2EE, могут быть встроены в сервер приложений J2EE, а могут быть выполнены как независимые продукты, настроенные на работу с сервером приложений J2EE как поставщики (provider) этих функций.

В поставку WebSphere Application Server Version 5 входит встроенный поставщик JMS-функций на базе WebSphere MQ.

В поставку WebSphere Application Server Version 6 входит встроенный поставщик JMS-функций WebSphere Platform Messaging. WebSphere Platform Messaging – это независимая от WebSphere MQ технология межточечного обмена и организации очередей сообщений по принципу публикации-подписки.

WebSphere MQ может быть настроен как JMS-поставщик для WebSphere Application Server V6.0. Инфраструктуры WebSphere Platform Messaging могут быть связаны с инфраструктурами WebSphere MQ.

3.2.9. Web-службы как интерфейс доступа к службам

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

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

Для описания Web-служб используется универсальный язык – Web Services Description Language (WSDL). WSDL-описание каждой Web-службы может содержать данные о том, каков порядок обращения к службе, какая информация требуется, каков возвращаемый результат, и способно дать общее представление о службе, к примеру описание действий, которые она выполняет.

WSDL-описание Web-службы может быть сгенерировано по коду реализации бизнес-логики самой службы. Такой подход называется "снизу – вверх".

Допускается и обратное: предварительно созданное WSDL-описание может служить основой при создании кода реализации службы. Такой подход называется "сверху – вниз".

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

WSDL-описание каждой входящей в состав системы Web-службы может храниться в общедоступном реестре (registry. Это дает возможность приложениям (разработчикам) запрашивать в реестре WSDL-описания служб, к которым они желают получить доступ, в том числе уточняя порядок взаимодействия.

Посредником в подобных взаимодействиях является функциональный слой, именуемый Simple Object Access Protocol (SOAP). Он описывает общий формат данных Web-службы и приложения, которое обращается к такой службе. Для обеспечения гарантии передачи только корректно заданной информации данные могут проверяться на соответствие WSDL-описанию.

Протокол SOAP описывает, как занятые в обмене данные определяются приложениями. Однако как таковой он не дает механизма взаимодействия приложений внутри сети. Для связи независимых приложений необходим транспортный слой.

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

Подробнее о Web-службах, включая правила пользования WebSphere MQ как транспортом для Web-служб, читайте в следующих руководствах:

3.2.10. Упрощенная обработка сбоев в WebSphere MQ

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

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

Предоставляемая WebSphere MQ гарантия однократной доставки снимает с приложения ответственность за обработку сбоев коммуникации.

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

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

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

3.3. Расширяемость и скорость работы

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

3.3.1. Расширяемость менеджеров очередей WebSphere MQ

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

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

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

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

3.3.2. Архитектура с одним менеджером очередей сообщений

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

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

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

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

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

3.3.3. Центрально-лучевая архитектура WebSphere MQ

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

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

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

Еще одним вариантом служит подключение обращающихся к работе служб приложений к менеджеру в роли клиентов по быстрому сетевому соединению; скажем, так можно подключить все приложения, вызывающие службу в офисе филиала. Благодаря наличию этого менеджера связь со службами на другом основном (hub) менеджере очередей становится асинхронной. При этом в реализации приложений как таковых может иметься внешний интерфейс к службе (к примеру, дающий возможность использовать ее через сеть Интернет и Web-браузер).

Те менеджеры очередей, которые предоставляют доступ к службам hub-менеджера, носят название spoke-менеджеров (spokes) центрально-лучевой ("hub and spoke") архитектуры WebSphere MQ.

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

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

Примером центрально-лучевой архитектуры служит рис 3.2.

3.3.4. Кластеры менеджеров как возможность гибкого расширения

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

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

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

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

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

Пример инфраструктуры WebSphere MQ на базе кластера менеджеров показан на рис 3.3.

3.4. Надежность служб и целостность данных

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

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

3.4.1. Постоянные и непостоянные сообщения

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

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

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

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

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

3.4.2. Единицы работы

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

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

Такие действия принято считать относящимися к одной единице работы (unit of work). Единицы работы, выполняемые приложением с доступом к инфраструктуре WebSphere MQ, могут включать в себя отправку и получение сообщений, а также обновления базы данных. Чтобы гарантированно фиксировать единицу работы лишь в случае успешного выполнения всех ее действий, WebSphere MQ может координировать все изменяемые ресурсы.

Также WebSphere MQ может участвовать в единицах работы, координируемых другими продуктами. Например, действия в инфраструктуре WebSphere MQ могут включаться в единицы работы, которые координирует WebSphere Application Server.

3.5. Безопасность

WebSphere MQ содержит функции обеспечения безопасности доступа, установления подлинности, а также защиты и целостности процесса коммуникации.

3.5.1. Object Authority Manager (OAM)

Все действия, производимые приложением с подключением к менеджеру, аутентифицируются менеджером очередей при помощи компонента, который носит название менеджера полномочий объектов OAM (Object Authority Manager).

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

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

3.5.2. SSL-протокол и защита транспортного уровня стека (TLS)

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

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

Отраслевыми технологическими стандартами обеспечения подлинности являются протокол SSL (Secure Sockets Layer) и защита транспортного уровня стека (TLS – Transport Layer Security). И тот и другой имеют аналогичные функции и строятся на схожих принципах установления подлинности. Как содержащий ряд дополнительных возможностей обеспечения безопасности, TLS часто считают преемником SSL. WebSphere MQ V6.0 реализует как функции TLS, так и функции SSL, введенные в WebSphere MQ V5.3. Для всех процессов коммуникации по сети в инфраструктуре WebSphere MQ можно использовать либо защиту транспортного уровня стека, либо SSL-протокол.

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

3.5.3. Защита коммуникаций по SSL-протоколу и технологии TLS

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

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

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

3.6. Высокая готовность системы

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

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

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

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

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

3.6.1. Роль кластеров менеджеров в работе служб высокой готовности

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

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

Аналогично, если менеджер очереди внезапно становится недоступен, к примеру из-за коснувшегося его сбоя сети связи или аппаратуры, запросы автоматически переправляются другим, оставшимся доступными экземплярам. Кластеры менеджеров позволяют инфраструктуре автоматически менять маршруты и обходить сбои.

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

3.6.2. Группы с разделением очередей на WebSphere MQ для z/OS

IBM WebSphere MQ для z/OS использует возможность объединения систем под z/OS в так называемый сисплекс (sysplex). Менеджеры очередей в одном сисплексе могут являться членами группы с разделением очередей (queue sharing group) и вместе получать доступ к сообщениям в одних и тех же общих очередях.

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

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

3.6.3. Кластеры высокой готовности

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

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

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

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

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

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

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

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

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

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

3.6.4. Восстановление после сбоя

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

Для создания резервной копии менеджера очередей на момент времени может быть создан полный "мгновенный снимок" всей его информации.

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

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

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

3.7. Мониторинг и учет операций

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

Этот раздел главы содержит самый общий обзор предоставляемых системой возможностей. Подробнее о функциях мониторинга и учета, их назначении и использовании см. руководство Monitoring WebSphere MQ, SC34-6593.

3.7.1. Мониторинг производительности

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

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

3.7.2. Учет

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

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

3.7.3. Трассировка маршрута сообщений

WebSphere MQ V6.0 содержит функции установления маршрута, которым движутся сообщения в инфраструктуре WebSphere MQ и в связанных с указанным продуктом системах.