Средства поддержки очередей сообщений в WebSphere MQ
3.6. Высокая готовность системы
Надежность WebSphere MQ делает этот продукт отличным решением для создания инфраструктуры очередей сообщений для служб высокой готовности.
В процессе использования WebSphere MQ должен сочетаться с контролирующей средой, близко напоминающей производственную среду и применяемой для разработки и проверки действия приложений, а также тестирования изменений в инфраструктуре и приложениях до внесения этих изменений в производственную среду.
Вложения в создание контролирующей среды позволяют проверять качество входящих в систему служб с целью гарантировать их наиболее полное соответствие характеру использования системы. Тестирование минимизирует вероятность того, что сбои программного или логического характера снизят доступность служб, которые предоставляет система.
Для служб, высокая готовность которых имеет критическое значение, необходимо предусмотреть порядок действий на период плановых и неплановых остановов. К причинам простоя служб относятся аппаратные сбои, а также профилактические работы и обновление приложений и компонентов инфраструктуры.
Подробнее обо всех темах, затронутых в этой главе, читайте в руководстве Understanding high availability with WebSphere MQ по адресу: http://www.ibm.com/developerworks/websphere/library/techarticles/0505_hiscock/0505_hiscock.html
3.6.1. Роль кластеров менеджеров в работе служб высокой готовности
Объединение менеджеров очередей в кластер, речь о котором шла в "Средства поддержки очередей сообщений в WebSphere MQ" "Кластеры менеджеров как возможность гибкого расширения", позволяет динамически устанавливать и разворачивать множество независимых экземпляров конкретной службы.
Менеджеры очередей в составе кластера менеджеров автоматически маршрутизируют сообщения всем доступным экземплярам интересующей службы. Если менеджер очереди помечен как недоступный, к примеру из-за профилактических действий в инфраструктуре 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) с первичного сервера на вторичный.
Надежное хранилище информации, которое для хранения данных используют все программные компоненты первичного сервера, также переключается на вторичный. Это дает возможность аналогичным компонентам вторичного сервера получить доступ к данным точно в том состоянии, которое они имели на момент сбоя.
5L™.В контексте 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 и в связанных с указанным продуктом системах.