15 оптимальных методик работы с очередями сообщений WebSphere MQ

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

Пэйлин Се, консультант по технологиям, IBM

Пэйлин Се (Peyling Hsieh) работает консультантом по технологиям в Инновационном Центре IBM для бизнес-партнеров (Уолтэм, штат Массачусетс). Она получила степень магистра по компьютерным технологиям и уже 19 лет работает в компании IBM: 8 лет занималась разработками AIX/SP2 для C/C++ /Java и еще 11 лет помогала бизнес-партнерам IBM разрабатывать собственные приложения для технологий IBM. Сейчас она продолжает помогать бизнес-партнерам IBM переносить и мигрировать приложения, а также тестировать их производительность на аппаратных платформах и связующем ПО IBM. Она также является специалистом по программам WebSphere Application Server, WebSphere MQ и среде Retail on Demand Store Integration Framework. Ей можно написать по адресу peyling@us.ibm.com.



Крис Клайн, архитектор связующего ПО, IBM

Крис Клайн (Chris Kline) работает архитектором по ИТ в подразделении интегрированных технологий системы оказания услуг IBM. Он имеет степень магистра по управлению информационными системами; в IBM работает с 2001 г., осуществляя поддержку продуктов WebSphere для крупнейших клиентов IBM. Крис с удовольствием разрабатывает средства автоматизации для управления различными продуктами связующего уровня, имеет патенты на некоторые из своих разработок. Он также является экспертом по продуктам WebSphere MQ для UNIX и Linux. Крису можно написать по адресу cnkline@us.ibm.com.



Майкл Райан, ИТ-архитектор ПО, IBM

Майкл Райан (Michael Ryan) ИТ-архитектор в нью-йоркском отделении IBM Software Business Unit. В круг его обязанностей входит использование повторяемых методов и приемов для трансформирования клиентских инициатив и задач в завершенную программную архитектуру. До этого Майкл был старшим ИТ-архитектором в отделе интеграции бизнес-приложений (EAI Practice) в составе подразделения Global Business Services корпорации IBM. За девять лет работы в GBS он помог более чем 20 клиентам, преимущественно из сферы финансовых услуг, в построении архитектуры, проектировании и разработке интеграционных бизнес-приложений (EAI). Майклу можно написать по адресу ryanmi@us.ibm.com.



23.07.2010

Введение

IBM® WebSphere® MQ (далее будем использовать аббревиатуру MQ) - продукт IBM связующего уровня для работы с сообщениями. Он позволяет общаться независимым и потенциально неодновременно работающим приложениям в гетерогенной системе. MQ поддерживается более чем 80 разными платформами и средами.Одна из сильных сторон MQ - высокая степень конфигурируемости и возможность настройки для различных клиентских сред и потребностей в передаче данных. Однако этот плюс может привести к созданию плохих конфигураций системы, делающих невозможным дальнейшее расширение, изменение стандартов разработки и протоколов, а также снижающих уровень безопасности. В данной статье мы опишем наиболее распространенные оптимальные методики проектирования, построения, использования и поддержки решений, связанных с MQ, которые помогут вам в полной мере использовать преимущества MQ. Помните, что не все эти рекомендации годятся для всех ситуаций, и мы предлагаем их лишь в качестве советов, а не жестких правил. Возможно, крупным и сложно структурированным предприятиям придется отвергнуть некоторые из наших методик. Данная статья написана для MQ версии V6 и предполагает, что вы уже имеете начальное представление об MQ.

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

Проектирование

Назначайте менеджерам очередей и MQ-объектам короткие имена

Иногда трудность вызывает уже то, как назвать очереди. Бывает, что создают столько очередей и других объектов, что выбранный способ наименования перестает работать или недостаточно четко описывает объект. Как правило, имена MQ-объектов содержат до 48 знаков, исключение - каналы, имена которых ограничены 20 знаками. Можно использовать как строчные, так и прописные буквы, цифры от 0 до 9, знаки подчеркивания (_) и точки (.), а также 2 специальных знака: наклонная черта вправо (/) и проценты (%). Если используется любой из этих знаков, имя следует заключать в двойные кавычки.

В дополнение к общим правилам есть еще рекомендации по наименованию менеджеров очередей и MQ-объектов:

  • Для объектов следует использовать ЗАГЛАВНЫЕ буквы (как и для менеджера очередей), чтобы не возникло проблем с их переносом в гетерогенную среду.
  • Имена менеджеров очередей должны быть уникальными в данной сети MQ и отражать местонахождение, функцию и среду этого менеджера очереди (dev, test и т.п.). Имена каналов должны отражать их функцию и направление движения относительно менеджера очередей (откуда или куда); используйте для всех каналов - отправителей и получателей - соответственно имена FROMQUEUEMANAGERNAME.TOQUEUEMANAGERNAME , а для узловых (clustered) каналов - TO.QUEUEMANAGERNAME. Если у вас к одному менеджеру подключено несколько каналов, расширьте имя указанием на другой приоритет или протокол, но используйте не более 20 знаков. Еще одно хорошее правило - использовать имя типа SOURCEQUEUEMANAGERNAME.TO.DESTQUEUEMANAGERNAME
  • Назначайте менеджерам очередей короткие имена (до 8 знаков) .
  • В именах очередей не должно содержаться слово QUEUE (поскольку это и так ясно) и обозначения топологии (local, remote, alias и т. п.).
  • Приложению нужен квалификатор высокого уровня из нескольких знаков, а после них - ограничитель (например, точка), чтобы эти имена легко было сортировать и разбираться в назначении каждой очереди (например, APPXYZ.SERVICE1.REQUEST).
  • Не используйте пробелы в именах MQ-объектов, в том числе в именах хост-узлов системы.
  • Несмотря на допустимость 20 знаков в именах групп и пользовательских ID, для авторизации MQ, не используйте больше 12 знаков, чтобы избежать сложностей.
  • Хотя использовать знаки прямого слэша (/) и процента (%) разрешается, избегайте их, чтобы не возникло межплатформенных расхождений.

Всегда назначайте менеджеру очередей очередь dead letter queue (DLQ)

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

Кроме того, следует проводить мониторинг DLQ, потому что поступающие в эту очередь сообщения скорее всего содержат ошибки. DLQ должна быть определена, доступна и рассчитана на самые крупные сообщения, которые ожидаются в этой системе. В более средах с более высокими требованиями к надежности следует устанавливать обработчик "мертвых" писем, который автоматически повторно запускает такие письма без вмешательства (оператора). Если повторный запуск не получается, сообщение посредством правил DLQ перенаправляют или удаляют. В MQ есть образец обработчика DLQ (runmqdlq/amqsdlq), и вы можете с ним поэкспериментировать.

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

Где возможно, пользуйтесь стандартами, такими как JMS.

Сегодняшние потребности динамичного бизнеса заставляют ИТ-отделы внедрять вычислительные системы, основанные на стандартах. JMS - это J2EE-стандарт на основе сообщений, который предоставляет стандартный API для работы приложений с сообщениями, обеспечивающий переносимость приложений. Хотя JMS является API-интерфейсом для Java-сообщений и не зависит от конкретного изготовителя, его реализации различаются у разных провайдеров, поэтому важно разбираться в имеющихся вариантах. Использование в решениях таких стандартов, как JMS, облегчает переносимость приложений и снижает зависимость от API конкретного производителя. Это, в свою очередь, упрощает интеграцию и уменьшает привязку к конкретным производителям. Сообщения SOAP/JMS все в большей степени становятся платформой, поддерживаемой в web-сервисах, и это помогает клиентам в работе с собственными реализациями на основе архитектуры SOA.

MQ сейчас входит в число самых востребованных JMS-провайдеров для J2EE-приложений. Реализации MQ JMS могут работать с другими программами MQ без связующих программ. Реализация MQ JMS поддерживает как модель сообщений point-to-point, так и publish/subscribe. В версиях MQ V5.3 Fix Pack 8 и выше MQ поставляется с интегрированным брокером. При помощи стандартизованных интерфейсов JMS API можно обновлять версии JMS-брокеров, например, устанавливая WebSphere Message Broker, не разрабатывая заново приложения и интерфейсы.

При построении рассчитывайте производительность

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

  • Размер и длина сообщения могут негативно сказаться на производительности приложения, которое его обрабатывает, а также на времени передачи данных через сети. Посылайте в сообщении только необходимые данные.
  • Пользуйтесь персистентными сообщениями только для самых важных и необходимых данных. Персистентные сообщения записываются в журнал на диск и могут снижать производительность вашего приложения.
  • Извлечение сообщений из очереди по идентификаторам сообщения или по корреляционным идентификаторам также снижает производительность вашего приложения. При этом менеджер очередей начинает искать все сообщения в очереди и делает это до тех пор, пока не найдет нужное. Если к приложению применяются высокие требования по производительности, приложения надо строить так, чтобы обработка сообщений шла последовательно.
  • Параметр MaxMsgLength задает максимальный размера сообщений в данной очереди. По умолчанию он равен 4 МБ, но его можно изменить в зависимости от ваших потребностей по обработке, чтобы использовать системные ресурсы наиболее эффективно.
  • Убедитесь, что приложения для работы с сообщениями созданы так, что могут работать параллельно и друг с другом, и с разными реализациями приложений. Менеджер очередей одновременно выполняет только один запрос сервиса, чтобы не нарушать единство процесса. Избегайте программ, которые используют несколько MQPUT-вызовов в точке синхронизации, не подтверждая их. Соответствующие очереди могут оказаться заполненными сообщениями, которые в данный момент недоступны, в то время как другие приложения или задания, возможно, будут ожидать получения этих сообщений.
  • Если приложения нуждаются в передаче сообщений лишь изредка, используйте MQPUT1-вызов для постановки в очередь одного сообщения. Для приложений большего объема, когда отправляется множество сообщений, обычно используют MQOPEN-вызов, а потом несколько MQPUT -вызовов и один MQCLOSE-вызов.
  • Оставляйте связи и очереди открытыми, если вам нужно будет их повторно использовать: это лучше, чем повторно их открывать и закрывать, устанавливать и разрывать связь.
  • Максимальное количество потоков, которые может запускать приложение, может повлиять на производительность решения, особенно под Windows®.
  • Конфигурируйте каналы так, чтобы присутствовал интервал разъединения и чтобы они могли деактивироваться при отсутствии активности в канале в течение какого-то времени. При этом сократятся непроизводительные издержки и повысится общая производительность.
  • Производительность MQ обычно ограничивается процессами записи ввода и вывода (I/O). Убедитесь, что команда проектировщиков процессов хранения учитывает схемы дисков, тогда запись на диск будет идти быстрее.

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

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

По возможности объединяйте MQ-серверы в кластеры

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

  • Диспетчеры очередей MQ не запускаются автоматически после сбоя системы, и вообще ни создание кластеров в MQ, ни аппаратное создание кластеров (например, HACMP) по умолчанию не приведут к таким действиям. Если такая возможность требуется, обычно можно специально конфигурировать аппаратные кластерные решения и провести обработку средствами системной автоматизации.
  • Привязка приложений к определенным сообщениям может порождать сложные процедуры администрирования нагрузки кластеров, что сложно и редко бывает оправданно. Если убрать такие привязки из приложения, можно улучшить готовность и масштабируемость приложения.
  • Если внутри вашего приложения отсутствуют привязки к сообщениям, не используйте опцию MQOO_BIND_ON_OPEN с MQOPEN-вызовом, которая направляет сообщения в конкретно указанное местонахождение. Если менеджер очередей сообщений будет недоступен, они не будут переданы другому менеджеру очередей из данного кластера.
  • Не используйте для канала типовые имена, такие как CONNAME. Нужно конкретизировать имя хост-узла или давать IP-адрес менеджера очередей.
  • Если это допускается, можно отправлять сообщения командой PUT с указанием любой очереди в кластере; однако для локального экземпляра очереди кластера сообщения можно задать только команду только GET.
  • Нужно выбрать по крайней мере один (лучше два) менеджер очередей из кластера, чтобы он служил полным репозиторием Если полных репозиториев больше двух, часто снижается общая производительность, потому что кластер должен будет отправлять дополнительный трафик и затрачивать больше времени на обслуживание всех репозиториев
  • Решая, какие серверы будут осуществлять хостинг полных репозиториев, выберите наиболее надежные серверы с хорошим управлением и статичным IP.
  • Используйте звездные или шинные модели для получения максимальной гибкости и производительности, особенно в объемной среде.

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

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

Построение

Фиксируйте коды завершения и причин во всех вызовах приложения MQI

Проектируйте свои приложения так, чтобы полностью использовать преимущества MQ-кодов. возвращаемых MQI-запросами; тогда приложение сможет определять, правильно ли произошли доставка и обработка сообщения или были проблемы Когда вам потребуется обратиться в отдел поддержки IBM, коды причин (reason codes), приложенные к описанию вашей проблемы, помогут ее выявить и разрешить.

Рекомендации по написанию кода разработчика для MQI-вызовов:

  • MQ-методы генерируют исключительные ситуации, если код завершения или код причины, произведенные MQ-вызовом, не равны нулю.
  • Используя не MQI, а другие API, обязательно фиксируйте связанные исключения. В случае JMS-реализации с помощью MQ последний выведет Java-исключение MQException, содержащее код завершения, код причины и подробности исключения. Не выдавайте одни лишь исключения, потому что в них не будет содержаться необходимых кодов завершения и причины.

Пишите приложения так, чтобы обработка сообщений осуществлялась непрерывно

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

Корректно подключайте и отключайте соединения

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

Не забывайте о том, что клиенты MQ имеют разные свойства

Не все клиенты MQ обладают одинаковыми свойствами. Решая, каким клиентом пользоваться, не забывайте о следующем:

  • Анализируйте варианты соединения, например, режимы клиентского связывания, серверного связывания, управляемого клиентского связывания и ограничения клиентов в отношении приложений C, JMS, Java и .NET. Например, MQ-клиент .Net не поддерживает шифрования SSL-каналов, XA-транзакции и компрессии каналов. А MQ-клиент Java поддерживает только трафик по протоколу TCP/IP и при запуске не считывает никаких переменных среды. В такой ситуации все переменные среды, включая информацию о соединении, хранятся в классе MQEnvironment файла qm.ini.ni.
  • •Проблемы с сетью и брандмауэрами могут мешать MQ-соединениям и могут ошибочно диагностироваться как проблемы MQ.
  • Назначайте для соединяемых приложений индивидуальные определения каналов, чтобы администраторы могли легко определить, какое приложение соединяется, а также реализовать сегментацию для повышения безопасности.
  • В промышленных системах каналу SYSTEM.DEF.SVRCONN нужно добавить в поле MCAUSER непривилегированного пользователя, и в дальнейшем можно перевести его в состояние "остановлен". Приложения нужно конфигурировать так, чтобы они не использовали этот канал, и каждому приложению следует назначать отдельный канал. Помимо того, что использовать системные объекты не рекомендуется, этот канал представляет известную угрозу безопасности.
  • Когда вы назначаете значение атрибуту MCAUSER, вводите его в одинарных кавычках, чтобы на распределенных платформах не возникло проблем с чувствительностью к регистру.

Исполнение

Используйте оптимальные методики в сфере безопасности

В распределенных системах группа mqm обеспечивает доступ администратора ко всем MQ-ресурсам системы. Поэтому число членов группы mqm следует ограничивать.

БеВопросы безопасности в MQ можно разделить на две большие группы: безопасность MQ-потребителей и безопасность MQ-администраторов. Как правило, потребители работают в качестве держателей определенного ID (идентификационного номера): они им пользуются при работе с приложениями, соединяющимися с MQ. Администраторы - это пользователи, которым нужно интерактивно опрашивать или модифицировать конфигурации MQ с помощью включенного в него инструментария (например, runmqsc). В некоторых средах учетные записи потребителей (клиентские ID) в приложениях помещают для простоты в группу mqm. В таких случаях эти ID следует блокировать так, чтобы ими нельзя было воспользоваться для интерактивного подключения, поскольку любой пользователь, получивший доступ к этим ID, получит полный административный контроль над MQ. Еще один вариант - использовать механизм WMQ OAM setmqaut, чтобы подробно указать разрешения уровня API для каждого ресурса или MQ-объекта (например, очередей). Этот метод позволяет осуществлять контроль на более детальном уровне и, если есть такая возможность, его следует применять.

Что касается прав администрирования, если предъявляются высокие требования к безопасности и контролю, для доступа к конфигурациям MQ и их и изменения следует использовать инструменты сторонних производителей, например бесплатно распространяемый SupportPac MS0E. При отсутствии этих средств контроля в группу mqm можно включать только членов команды администраторов MQ. Прочим пользователям следует назначать не столь высокий уровень полномочий; это можно сделать при помощи команд setmqaut OAM-уровня (эксплуатация, администрирование, сопровождение) или пакетов MQ SupportPacs, например, MS0E.

Ограничьте полномочия удаленного администрирования с помощью каналов SYSTEM.ADMIN.SVRCONN на уровне предприятия (ограниченный доступ)

В версиях MQ V5.3 или более ранних инструментарий администратора на основе Windows MQ Explorer соединяется с менеджером очередей при помощи канала SYSTEM.ADMIN.SVRCONN. Тогда еще не было дополнительных средств обеспечения безопасности этого канала, поэтому возникала опасность для систем с ограничением доступа, потому что любой человек, знающий менеджер очередей, мог осуществить соединение с полномочиями полного административного доступа, и никакого аудита не производилось бы (если использовался Explorer). Однако этот канал по умолчанию не создается, его надо добавлять вручную. Начиная с версии MQ V6.0 для административного доступа может использоваться любой клиентский канал, поэтому не забудьте предусмотреть дополнительные меры, например, SSL, если к производственным системам предоставляется доступ.

Не используйте образцы утилит get/put для производственных целей

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

Используйте runmqlsr вместо подписчика inetd

Начиная с версии MQ V5.3 программа-подписчик сетевых событий runmqlsr позволяет осуществлять многопоточные соединения. Преимуществом многопоточного процесса по сравнению с запуском нового потока для каждого соединения (с помощью amqcrsta) является снижение потребления ресурсов системы, а также исключение возможных административных простоев. Если ваши системы содержат большое количество соединений, например, интеграционный хаб или ESB, и существуют подписчики на основе UNIX-сервиса inetd (в сочетании с программой amqcrsta), подумайте, не стоит ли перевести эти подписчики на runmqlsr.

Поместите порт подписчика в разделе TCP файла qm.ini (или в реестре Windows), чтобы порты хорошо ассоциировались с менеджерами очередей. Тогда впоследствии при запуске подписчиков вам не потребуется указывать номер порта в командной строке. Подробнее о структуре раздела TCP читайте в документации MQ.

Используйте SupportPacs для расширения функциональности MQ

К MQ предлагается много бесплатно загружаемых плагинов для расширения функциональности, которые называются MQ SupportPacs:

  • MS03: менеджер savequeue - предоставляет код, который экспортирует все настройки объекта MQ из runmqsc в формат, который далее можно повторно использовать для импортирования конфигураций менеджера очередей и для создания новых конфигураций. В некоторых средах это может быть жизненно важно для вашего резервирования и восстановления данных.
  • MS0E: runmqadm - предоставляет оболочку для администрирования, которая дает доступ уровня runmqsc и администратора пользователям, не входящим в группу mqm, что позволит вам организовать доступ более избирательно.
  • MA01: утилита q - позволяет просматривать сообщения и перемещать их из одной очереди в другую.
  • MO03: утилита qload - позволяет перемещать сообщения в файлы и из файлов для транспортировки в другие системы или для повторного использования в дальнейшем.
  • MS81: MQIPT - дополнительный продукт, который совместно с MQ туннелирует соединения через брандмауэры по протоколам SSL или HTTP(S). Его можно использовать для агрегации соединений из нескольких менеджеров очередей в одном транспорте и порте.
  • MC91: высокая готовность - предоставляет скрипты и инструкции для конфигурирования MQ в UNIX -системах высокой готовности, например, HACMP и Sun Cluster.

Обслуживание

Если вы не используете конфигурационные инструменты от сторонних производителей, полностью автоматизируйте конфигурацию и все изменения с помощью скриптов MQSC

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

Используйте оптимальный механизм журналирования

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

Конфигурируйте автоматическое обслуживание менеджеров очередей

Подумайте, не создать ли вам скрипты для автоматизации регулярного обслуживания менеджеров очередей. В систему обслуживания следует включить менеджер сохранения очереди (MS03), резервирование настроек безопасности (amqoamd), очистку линейного журнала (если он используется) и резервирование других важных настроек, например, файлов .ini. Еще подумайте, не стоит ли просматривать директорию ошибок FDC: возможно, в ней окажутся старые файлы FDC, которые следует удалить, или новые, которые нужно изучить, потому что они информируют о критических ошибках MQ-системы.

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

Планируйте и регулярно осуществляйте установку пакетов с исправлениями

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=502077
ArticleTitle=15 оптимальных методик работы с очередями сообщений WebSphere MQ
publish-date=07232010